An issue was discovered in swftools through 20201222. A heap-buffer-overflow exists in the function handleEditText() located in swfdump.c. It allows an attacker to cause code Execution.

**system info**

Ubuntu x86\_64, clang 6.0, swfdump (latest master a9d5082)

**Command line**

./src/swfdump -D @@

**AddressSanitizer output**

\==44192==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60600000e8d3 at pc 0x000000410aca bp 0x7fffffffdee0 sp 0x7fffffffded0  
READ of size 1 at 0x60600000e8d3 thread T0  
#0 0x410ac9 in handleEditText /test/swftools-asan/src/swfdump.c:549  
#1 0x408624 in main /test/swftools-asan/src/swfdump.c:1511  
#2 0x7ffff68a683f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#3 0x40c168 in \_start (/test/swftools-asan/src/swfdump+0x40c168)

0x60600000e8d3 is located 0 bytes to the right of 51-byte region \[0x60600000e8a0,0x60600000e8d3)  
allocated by thread T0 here:  
#0 0x7ffff6f02602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)  
#1 0x532fa7 in rfx\_alloc /test/swftools-asan/lib/mem.c:30  
#2 0x541396 (/test/swftools-asan/src/swfdump+0x541396)

SUMMARY: AddressSanitizer: heap-buffer-overflow /test/swftools-asan/src/swfdump.c:549 handleEditText  
Shadow bytes around the buggy address:  
0x0c0c7fff9cc0: 00 00 00 00 00 00 02 fa fa fa fa fa 00 00 00 00  
0x0c0c7fff9cd0: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa  
0x0c0c7fff9ce0: fa fa fa fa 00 00 00 00 00 00 00 05 fa fa fa fa  
0x0c0c7fff9cf0: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00  
0x0c0c7fff9d00: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa  
\=>0x0c0c7fff9d10: fa fa fa fa 00 00 00 00 00 00\[03\]fa fa fa fa fa  
0x0c0c7fff9d20: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00  
0x0c0c7fff9d30: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa  
0x0c0c7fff9d40: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa  
0x0c0c7fff9d50: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00  
0x0c0c7fff9d60: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa  
Shadow byte legend (one shadow byte represents 8 application bytes):  
Addressable: 00  
Partially addressable: 01 02 03 04 05 06 07  
Heap left redzone: fa  
Heap right redzone: fb  
Freed heap region: fd  
Stack left redzone: f1  
Stack mid redzone: f2  
Stack right redzone: f3  
Stack partial redzone: f4  
Stack after return: f5  
Stack use after scope: f8  
Global redzone: f9  
Global init order: f6  
Poisoned by user: f7  
Container overflow: fc  
Array cookie: ac  
Intra object redzone: bb  
ASan internal: fe  
\==44192==ABORTING

POC  
handleEditText\_poc

CVE-2021-42195: heap-buffer-overflow exists in the function handleEditText in swfdump.c · Issue #174 · matthiaskramm/swftools

USR IOT 4G LTE Industrial Cellular VPN Router v1.0.36 was discovered to contain hard-coded credentials for its highest privileged account. The credentials cannot be altered through normal operation of the device.

Title: USR IOT 4G LTE Industrial Cellular VPN Router 1.0.36 Remote Root Backdoor  
Advisory ID: ZSL-2022-5705  
Type: Local/Remote  
Impact: Exposure of Sensitive Information, Security Bypass, System Access, DoS  
Risk: (5/5)  
Release Date: 20.04.2022

**Summary**

USR-G806 is a industrial 4G wireless LTE router which provides a solution for users to connect own device to 4G network via WiFi interface or Ethernet interface. USR-G806 adopts high performance embedded CPU which can support 580MHz working frequency and can be widely used in Smart Grid, Smart Home, public bus and Vending machine for data transmission at high speed. USR-G806 supports various functions such as APN card, VPN, WIFIDOG, flow control and has many advantages including high reliability, simple operation, reasonable price. USR-G806 supports WAN interface, LAN interface, WLAN interface, 4G interface. USR-G806 provides various networking mode to help user establish own network.

**Description**

The USR IOT industrial router is vulnerable to hard-coded credentials within its Linux distribution image. These sets of credentials are never exposed to the end-user and cannot be changed through any normal operation of the device. The 'usr' account with password 'www.usr.cn' has the highest privileges on the device. The password is also the default WLAN password.

**Vendor**

Jinan USR IOT Technology Limited - https://www.pusr.com

**Affected Version**

1.0.36 (USR-G800V2, USR-G806, USR-G807, USR-G808)  
1.2.7 (USR-LG220-L)

**Tested On**

GNU/Linux 3.10.14 (mips)  
OpenWrt/Linaro GCC 4.8-2014.04  
Ralink SoC MT7628 PCIe RC mode  
BusyBox v1.22.1  
uhttpd  
Lua

**Vendor Status**

\[10.04.2022\] Vulnerability discovered.  
\[14.04.2022\] Vendor contacted.  
\[19.04.2022\] No response from the vendor.  
\[20.04.2022\] Public security advisory released.

**PoC**

usriot\_root.py

**Credits**

Vulnerability discovered by Gjoko Krstic - <gjoko@zeroscience.mk\>

**References**

\[1\] https://packetstormsecurity.com/files/166813/  
\[2\] https://cxsecurity.com/issue/WLB-2022040086  
\[3\] https://exchange.xforce.ibmcloud.com/vulnerabilities/224930  
\[4\] https://www.exploit-db.com/exploits/50894  
\[5\] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29730  
\[6\] https://nvd.nist.gov/vuln/detail/CVE-2022-29730

**Changelog**

\[20.04.2022\] - Initial release  
\[03.05.2022\] - Added reference \[1\], \[2\] and \[3\]  
\[13.05.2022\] - Added reference \[4\]  
\[29.05.2022\] - Added reference \[5\] and \[6\]

**Contact**

Zero Science Lab

Web: https://www.zeroscience.mk  
e-mail: lab@zeroscience.mk

CVE-2022-29730: Zero Science Lab » USR IOT 4G LTE Industrial Cellular VPN Router 1.0.36 Remote Root Backdoor

Onlyoffice Document Server v6.0.0 and below and Core 6.1.0.26 and below were discovered to contain a stack overflow via the component DesktopEditor/common/File.cpp.

@@ -159,60 +159,90 @@ namespace NSFile else if (0x00 == (byteMain & 0x20)) { // 2 byte int val = (int)(((byteMain & 0x1F) << 6) | (pBuffer\[lIndex + 1\] & 0x3F)); int val = 0; if ((lIndex + 1) < lCount) { val = (int)(((byteMain & 0x1F) << 6) | (pBuffer\[lIndex + 1\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 2; } else if (0x00 == (byteMain & 0x10)) { // 3 byte int val = (int)(((byteMain & 0x0F) << 12) | ((pBuffer\[lIndex + 1\] & 0x3F) << 6) | (pBuffer\[lIndex + 2\] & 0x3F)); int val = 0; if ((lIndex + 2) < lCount) { val = (int)(((byteMain & 0x0F) << 12) | ((pBuffer\[lIndex + 1\] & 0x3F) << 6) | (pBuffer\[lIndex + 2\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 3; } else if (0x00 == (byteMain & 0x0F)) { // 4 byte int val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); int val = 0; if ((lIndex + 3) < lCount) { val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 4; } else if (0x00 == (byteMain & 0x08)) { // 4 byte int val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); int val = 0; if ((lIndex + 3) < lCount) { val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 4; } else if (0x00 == (byteMain & 0x04)) { // 5 byte int val = (int)(((byteMain & 0x03) << 24) | ((pBuffer\[lIndex + 1\] & 0x3F) << 18) | ((pBuffer\[lIndex + 2\] & 0x3F) << 12) | ((pBuffer\[lIndex + 3\] & 0x3F) << 6) | (pBuffer\[lIndex + 4\] & 0x3F)); int val = 0; if ((lIndex + 4) < lCount) { val = (int)(((byteMain & 0x03) << 24) | ((pBuffer\[lIndex + 1\] & 0x3F) << 18) | ((pBuffer\[lIndex + 2\] & 0x3F) << 12) | ((pBuffer\[lIndex + 3\] & 0x3F) << 6) | (pBuffer\[lIndex + 4\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 5; } else { // 6 byte int val = (int)(((byteMain & 0x01) << 30) | ((pBuffer\[lIndex + 1\] & 0x3F) << 24) | ((pBuffer\[lIndex + 2\] & 0x3F) << 18) | ((pBuffer\[lIndex + 3\] & 0x3F) << 12) | ((pBuffer\[lIndex + 4\] & 0x3F) << 6) | (pBuffer\[lIndex + 5\] & 0x3F)); int val = 0; if ((lIndex + 5) < lCount) { val = (int)(((byteMain & 0x01) << 30) | ((pBuffer\[lIndex + 1\] & 0x3F) << 24) | ((pBuffer\[lIndex + 2\] & 0x3F) << 18) | ((pBuffer\[lIndex + 3\] & 0x3F) << 12) | ((pBuffer\[lIndex + 4\] & 0x3F) << 6) | (pBuffer\[lIndex + 5\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 5; } @@ -242,64 +272,89 @@ namespace NSFile else if (0x00 == (byteMain & 0x20)) { // 2 byte int val = (int)(((byteMain & 0x1F) << 6) | (pBuffer\[lIndex + 1\] & 0x3F)); int val = 0; if ((lIndex + 1) < lCount) { val = (int)(((byteMain & 0x1F) << 6) | (pBuffer\[lIndex + 1\] & 0x3F)); }  
\*pUnicodeString++ = (WCHAR)(val); lIndex += 2; } else if (0x00 == (byteMain & 0x10)) { // 3 byte int val = (int)(((byteMain & 0x0F) << 12) | ((pBuffer\[lIndex + 1\] & 0x3F) << 6) | (pBuffer\[lIndex + 2\] & 0x3F)); int val = 0; if ((lIndex + 2) < lCount) { val = (int)(((byteMain & 0x0F) << 12) | ((pBuffer\[lIndex + 1\] & 0x3F) << 6) | (pBuffer\[lIndex + 2\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 3; } else if (0x00 == (byteMain & 0x0F)) { // 4 byte int val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); int val = 0; if ((lIndex + 3) < lCount) { val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 4; } else if (0x00 == (byteMain & 0x08)) { // 4 byte int val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); int val = 0; if ((lIndex + 3) < lCount) { val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 4; } else if (0x00 == (byteMain & 0x04)) { // 5 byte int val = (int)(((byteMain & 0x03) << 24) | ((pBuffer\[lIndex + 1\] & 0x3F) << 18) | ((pBuffer\[lIndex + 2\] & 0x3F) << 12) | ((pBuffer\[lIndex + 3\] & 0x3F) << 6) | (pBuffer\[lIndex + 4\] & 0x3F)); int val = 0; if ((lIndex + 4) < lCount) { val = (int)(((byteMain & 0x03) << 24) | ((pBuffer\[lIndex + 1\] & 0x3F) << 18) | ((pBuffer\[lIndex + 2\] & 0x3F) << 12) | ((pBuffer\[lIndex + 3\] & 0x3F) << 6) | (pBuffer\[lIndex + 4\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 5; } else { // 6 byte int val = (int)(((byteMain & 0x01) << 30) | ((pBuffer\[lIndex + 1\] & 0x3F) << 24) | ((pBuffer\[lIndex + 2\] & 0x3F) << 18) | ((pBuffer\[lIndex + 3\] & 0x3F) << 12) | ((pBuffer\[lIndex + 4\] & 0x3F) << 6) | (pBuffer\[lIndex + 5\] & 0x3F)); int val = 0; if ((lIndex + 5) < lCount) { val = (int)(((byteMain & 0x01) << 30) | ((pBuffer\[lIndex + 1\] & 0x3F) << 24) | ((pBuffer\[lIndex + 2\] & 0x3F) << 18) | ((pBuffer\[lIndex + 3\] & 0x3F) << 12) | ((pBuffer\[lIndex + 4\] & 0x3F) << 6) | (pBuffer\[lIndex + 5\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 5;

CVE-2022-29776: Fix 25 errors · ONLYOFFICE/core@88cf60a

This is an exciting time for the Internet of Things. According to Deloitte research, the average U.S. household now has 25 connected devices — and new products are being launched every day. This rush of demand means that many tech companies are looking for developers with IoT knowledge. And even if you don’t want to specialize in this field, the programming skills are transferable.
Featuring

This is an exciting time for the Internet of Things. According to Deloitte research, the average U.S. household now has 25 connected devices — and new products are being launched every day. This rush of demand means that many tech companies are looking for developers with IoT knowledge. And even if you don't want to specialize in this field, the programming skills are transferable.

Featuring nine full-length video courses, The 2022 Complete Raspberry Pi & Arduino Developer Bundle provides a really good introduction to this world. The included training is worth a total of $1,800, but readers of The Hacker News can currently pick up the bundle for only $39.99.

**Special Offer** — _For a limited time, you can get lifetime access to nine courses on Arduino and Raspberry Pi development_ _for just $39.99__. That's a massive 97% off the total price._

Both the Raspberry Pi and the Arduino were specifically designed to help people learn how to code. But both devices have also been used in exciting DIY projects, from cryptocurrency mining to controlling mini-satellites.

In this bundle, you discover how to program both devices for almost any purpose. You also learn how to write Python and C++, and work with ROS2 — the operating system of choice for robotics developers. All of the courses are beginner-friendly, meaning you don't need any previous experience. In addition, they have great reviews from past students.

Your instructor is Edouard Renard, a trained software engineer who founded his own robotics startup. He has helped over 23,000 students to date, picking up an average rating of 4.2 out of 5 stars.

Order today for just $39.99 to get lifetime access to all nine courses on desktop and mobile devices, saving a massive 97% on the total price!

_Prices subject to change_

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Learn Raspberry Pi and Arduino with 9 Online Developer Training Courses

Buffer Over-read in GitHub repository bfabiszewski/libmobi prior to 0.11.

**Description**

heap-buffer-overflow /home/ubuntu/libmobi-public/src/parse\_rawml.c:110 in mobi\_search\_links\_kf7

**Environment**

    Distributor ID: Ubuntu
    Description:    Ubuntu 20.04 LTS
    Release:    20.04
    Codename:   focal
    mobitool build: Apr 29 2022 20:52:30 (gcc 9.3.0)
    libmobi: 0.10
    

**Build**

    export CC=gcc CXX=g++ CFLAGS="-fsanitize=address -static-libasan" CXXFLAGS="-fsanitize=address -static-libasan" LDFLAGS="-fsanitize=address -static-libasan"
    autogen.sh &&  ./configure && make
    

**POC**

    ./mobitool -e -o ./tmp/ ./poc5
    

poc5

**ASAN**

    ==1028892==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62500000748f at pc 0x5631f27052e4 bp 0x7ffe6493c610 sp 0x7ffe6493c600
    READ of size 1 at 0x62500000748f thread T0
        #0 0x5631f27052e3 in mobi_search_links_kf7 /home/ubuntu/libmobi-public/src/parse_rawml.c:110
        #1 0x5631f27052e3 in mobi_search_links_kf7 /home/ubuntu/libmobi-public/src/parse_rawml.c:63
        #2 0x5631f2714a31 in mobi_reconstruct_links_kf7 /home/ubuntu/libmobi-public/src/parse_rawml.c:1679
        #3 0x5631f27180d0 in mobi_reconstruct_links /home/ubuntu/libmobi-public/src/parse_rawml.c:1849
        #4 0x5631f27180d0 in mobi_parse_rawml_opt /home/ubuntu/libmobi-public/src/parse_rawml.c:2153
        #5 0x5631f27180d0 in mobi_parse_rawml /home/ubuntu/libmobi-public/src/parse_rawml.c:2009
        #6 0x5631f25bbe00 in loadfilename /home/ubuntu/libmobi-public/tools/mobitool.c:852
        #7 0x5631f25bbe00 in main /home/ubuntu/libmobi-public/tools/mobitool.c:1051
        #8 0x7f5bf47900b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #9 0x5631f25c76fd in _start (/home/ubuntu/libmobi-public/tools/mobitool+0x266fd)
    
    0x62500000748f is located 0 bytes to the right of 9103-byte region [0x625000005100,0x62500000748f)
    allocated by thread T0 here:
        #0 0x5631f26b2748 in malloc (/home/ubuntu/libmobi-public/tools/mobitool+0x111748)
        #1 0x5631f270cfc0 in mobi_reconstruct_parts /home/ubuntu/libmobi-public/src/parse_rawml.c:805
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ubuntu/libmobi-public/src/parse_rawml.c:110 in mobi_search_links_kf7
    Shadow bytes around the buggy address:
      0x0c4a7fff8e40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c4a7fff8e50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c4a7fff8e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c4a7fff8e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c4a7fff8e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c4a7fff8e90: 00[07]fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a7fff8ea0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a7fff8eb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a7fff8ec0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a7fff8ed0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a7fff8ee0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==1028892==ABORTING
    

**Impact**

The bug causes the program reads data past the end of the intented buffer. Typically, this can allow attackers to read sensitive information from other memory locations or cause a crash.

**Occurrences**

CVE-2022-1908: Heap-buffer-overflow  in mobi_search_links_kf7 in libmobi

**Description**

heap-buffer-overflow /home/ubuntu/libmobi-public/src/parse\_rawml.c:357 in mobi\_get\_attribute\_value

**Environment**

    Distributor ID: Ubuntu
    Description:    Ubuntu 20.04 LTS
    Release:    20.04
    Codename:   focal
    mobitool build: Apr 29 2022 20:52:30 (gcc 9.3.0)
    libmobi: 0.10
    

**Build**

    export CC=gcc CXX=g++ CFLAGS="-fsanitize=address -static-libasan" CXXFLAGS="-fsanitize=address -static-libasan" LDFLAGS="-fsanitize=address -static-libasan"
    autogen.sh &&  ./configure && make
    

**POC**

    ./mobitool -e -o ./tmp/ ./poc4
    

poc4

**ASAN**

    =================================================================
    ==150005==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b00000141f at pc 0x55dae390a641 bp 0x7ffefa5218a0 sp 0x7ffefa521890
    READ of size 1 at 0x61b00000141f thread T0
        #0 0x55dae390a640 in mobi_get_attribute_value /home/ubuntu/libmobi-public/src/parse_rawml.c:357
        #1 0x55dae391760d in mobi_get_filepos_array /home/ubuntu/libmobi-public/src/parse_rawml.c:1003
        #2 0x55dae391760d in mobi_reconstruct_links_kf7 /home/ubuntu/libmobi-public/src/parse_rawml.c:1660
        #3 0x55dae391b0d0 in mobi_reconstruct_links /home/ubuntu/libmobi-public/src/parse_rawml.c:1849
        #4 0x55dae391b0d0 in mobi_parse_rawml_opt /home/ubuntu/libmobi-public/src/parse_rawml.c:2153
        #5 0x55dae391b0d0 in mobi_parse_rawml /home/ubuntu/libmobi-public/src/parse_rawml.c:2009
        #6 0x55dae37bee00 in loadfilename /home/ubuntu/libmobi-public/tools/mobitool.c:852
        #7 0x55dae37bee00 in main /home/ubuntu/libmobi-public/tools/mobitool.c:1051
        #8 0x7feb6690f0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #9 0x55dae37ca6fd in _start (/home/ubuntu/libmobi-public/tools/mobitool+0x266fd)
    
    0x61b00000141f is located 0 bytes to the right of 1439-byte region [0x61b000000e80,0x61b00000141f)
    allocated by thread T0 here:
        #0 0x55dae38b5748 in malloc (/home/ubuntu/libmobi-public/tools/mobitool+0x111748)
        #1 0x55dae390ffc0 in mobi_reconstruct_parts /home/ubuntu/libmobi-public/src/parse_rawml.c:805
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ubuntu/libmobi-public/src/parse_rawml.c:357 in mobi_get_attribute_value
    Shadow bytes around the buggy address:
      0x0c367fff8230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c367fff8240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c367fff8250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c367fff8260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c367fff8270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c367fff8280: 00 00 00[07]fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c367fff8290: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c367fff82a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c367fff82b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c367fff82c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c367fff82d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==150005==ABORTING
    

**Impact**

The bug causes the program reads data past the end of the intented buffer. Typically, this can allow attackers to read sensitive information from other memory locations or cause a crash.

**Occurrences**

CVE-2022-1907: heap-buffer-overflow  in mobi_get_attribute_value in libmobi

ChromeOS uses usbguard when the screen is locked but appears to suffer from bypass issues.

    ChromeOS' usage of usbguard is bypassableVULNERABILITY DETAILSChromeOS uses https://usbguard.github.io/ when the screen is locked (but noton the login screen, perhaps because it is expected that code execution is muchless helpful when the disk is still encrypted?).When the screen is locked, a policy is applied that might look like this(example from my Pixelbook):```allow id 0bda:564b serial \"\\x07LOE65001063010A78M015CFAI06BF12000\" name \"WebCamera\" hash \"KsByWtMB5JtGNDimauArXMiZOThFwagdTWeQsMAZ48c=\" with-interface { 0e:01:00 0e:02:00 0e:02:00 0e:02:00 0e:02:00 0e:02:00 0e:02:00 0e:02:00 0e:02:00 } with-connect-type \"hardwired\"allow id 1d6b:0002 serial \"0000:00:14.0\" name \"xHCI Host Controller\" hash \"jEP/6WzviqdJ5VSeTUY8PatCNBKeaREvo2OqdplND/o=\" with-interface 09:00:00 with-connect-type \"\"allow id 1d6b:0003 serial \"0000:00:14.0\" name \"xHCI Host Controller\" hash \"3Wo3XWDgen1hD5xM3PSNl3P98kLp1RUTgGQ5HSxtf8k=\" with-interface 09:00:00 with-connect-type \"\"allow id 8087:0a2a serial \"\" name \"\" hash \"AyPZWy2XK0931kB9A/owYfk5xHEqnpDsJfdeLSGIyuk=\" with-interface { e0:01:01 e0:01:01 e0:01:01 e0:01:01 e0:01:01 e0:01:01 e0:01:01 } with-connect-type \"hardwired\"##################################################################################################### Footer.####################################################################################################block with-interface one-of { 05:*:* 06:*:* 07:*:* 08:*:* } # physical, image, printer, storageallow```As you can see, it mostly just allowlists specific devices with full hashes ofthe expected USB configuration descriptors, and internal USB devices are markedsuch that they won't be accepted on external USB ports.(Which, by the way, might not actually be necessary, since the USB subsystem's`authorized_default` flag is set to 2 when the screen is locked, not 0, meaninginternal USB devices are automatically allowed anyway?)But then at the bottom is this footer that blocks USB devices with interfacedescriptors that contain the following `bInterfaceClass` values: - USB_CLASS_PHYSICAL (5) - USB_CLASS_STILL_IMAGE (6) - USB_CLASS_PRINTER (7) - USB_CLASS_MASS_STORAGE (8)Afterwards, anything else is permitted.This configuration footer comes from<https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/chromiumos-overlay/sys-apps/usbguard/files/99-rules.conf>.The interface-based classification of devices was introduced in<https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1217622/>.Apart from the problem that there is a large amount of attack surface in driversfor devices that don't belong into those USB interface classes, there is anotherissue with this approach:The kernel often doesn't care what USB class a device claims to be. The way USBdrivers tend to work, even for standardized protocols, is that the driverspecifies with low priority that it would like to bind to standards-compliantdevices using the proper USB interface class, but also specifies with highpriority that it would like to bind to specific USB devices based on Vendor IDand Product ID, without caring about their USB interface class.As an example, USB_CLASS_MASS_STORAGE is blocklisted, so a USB stick insertedwhile the screen is locked doesn't get past the authorization check:[ 6411.611320] usb 1-1: new high-speed USB device number 31 using xhci_hcd[ 6411.738900] usb 1-1: New USB device found, idVendor=0781, idProduct=5580, bcdDevice= 0.10[ 6411.738910] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3[ 6411.738916] usb 1-1: Product: [...][ 6411.738921] usb 1-1: Manufacturer: SanDisk[ 6411.738926] usb 1-1: SerialNumber: [...][ 6411.740583] usb 1-1: Device is not authorized for usage[ 6414.875133] cros-ec-sensorhub [...][ 6418.603609] usb 1-1: USB disconnect, device number 31But if we use a Linux machine with appropriate hardware (I'm using a NET2380 devboard, but you could probably also do it with an unlocked Pixel phone or aRaspberry Pi Zero W or something like that) to emulate a USB Mass Storagedevice, using <https://docs.kernel.org/usb/mass-storage.html>, and patch oneline in the attacker kernel so that it claims to be a billboard, not a storagedevice:diff --git a/drivers/usb/gadget/function/storage_common.c b/drivers/usb/gadget/function/storage_common.cindex b859a158a414..d7452c8458a9 100644--- a/drivers/usb/gadget/function/storage_common.c+++ b/drivers/usb/gadget/function/storage_common.c@@ -34,7 +34,7 @@ struct usb_interface_descriptor fsg_intf_desc = {   .bDescriptorType =  USB_DT_INTERFACE,    .bNumEndpoints =  2,    /* Adjusted during fsg_bind() */-  .bInterfaceClass =  USB_CLASS_MASS_STORAGE,+  .bInterfaceClass =  USB_CLASS_BILLBOARD,   .bInterfaceSubClass =  USB_SC_SCSI,  /* Adjusted during fsg_bind() */   .bInterfaceProtocol =  USB_PR_BULK,  /* Adjusted during fsg_bind() */   .iInterface =    FSG_STRING_INTERFACE,Then we can connect just fine even while the screen is locked - first we get a\"Device is not authorized\" message on the initial connection, then usbguardunblocks us and the kernel probes the device as a mass storage device and scansthe partition table:[ 6432.752906] usb 1-1: new high-speed USB device number 32 using xhci_hcd[ 6432.885635] usb 1-1: New USB device found, idVendor=0525, idProduct=a4a5, bcdDevice= 5.17[ 6432.885647] usb 1-1: New USB device strings: Mfr=3, Product=4, SerialNumber=0[ 6432.885653] usb 1-1: Product: Mass Storage Gadget[ 6432.885658] usb 1-1: Manufacturer: Linux 5.17.0-rc4+ with net2280[ 6432.886121] usb 1-1: Device is not authorized for usage[ 6432.891672] usb-storage 1-1:1.0: USB Mass Storage device detected[ 6432.891985] usb-storage 1-1:1.0: Quirks match for vid 0525 pid a4a5: 10000[ 6432.892090] scsi host0: usb-storage 1-1:1.0[ 6432.892567] usb 1-1: authorized to connect[ 6433.920354] scsi 0:0:0:0: Direct-Access     Linux    File-Stor Gadget 0517 PQ: 0 ANSI: 2[ 6433.922585] sd 0:0:0:0: Power-on or device reset occurred[ 6433.923533] sd 0:0:0:0: [sda] 204800 512-byte logical blocks: (105 MB/100 MiB)[ 6434.030869] sd 0:0:0:0: [sda] Write Protect is off[ 6434.030876] sd 0:0:0:0: [sda] Mode Sense: 0f 00 00 00[ 6434.136540] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA[ 6434.363462]  sda: sda1 sda2[ 6434.585367] cros-ec-sensorhub [...][ 6434.588541] sd 0:0:0:0: [sda] Attached SCSI diskI haven't looked at how this issue applies to other USB subsystems in detail,but from a quick glance: - USB_CLASS_PHYSICAL doesn't really show up in the Linux kernel outside of some   number-to-string translation table, so I don't think it matters to the kernel. - Same thing with USB_CLASS_STILL_IMAGE. - The usblp subsystem does have an explicit check for USB_CLASS_PRINTER - but   that check is intentionally bypassed for known devices that are marked in   the kernel as USBLP_QUIRK_BAD_CLASS, and that flag is set for the   \"Seiko Epson Receipt Printer M129C\" (vendor 0x04b8, device 0x0202), so you   can probably also bypass the blocking of the printer interface class that way.I think the best way forward would be to look into whether it is feasible torely exclusively on a trust-on-first-use approach. If that is infeasible, youmay have to talk to upstream about how userspace can reliably determine whichdriver(s) a given USB device might be bound to, since I'm not aware of anyinterface that would let you do that.VERSIONGoogle Chrome  98.0.4758.107 (Official Build) (64-bit) Revision  a2ef32d533baed737df9fc2ed8d505405ecf0c66-refs/branch-heads/4758@{#1167}Platform  14388.61.0 (Official Build) stable-channel eveFirmware Version  Google_Eve.9584.230.0Customization ID  GOOGLE-EVEARC  8165997CREDIT INFORMATIONReporter credit: Jann Horn of Google Project ZeroThis bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2022-05-25.Found by: jannh@google.com

ChromeOS usbguard Bypass

A stack buffer overflow exists in Mini-XML v3.2. When inputting an unformed XML string to the mxmlLoadString API, it will cause a stack-buffer-overflow in mxml_string_getc:2611.

Hi,

We have used Mini-xml in our project, so I test v3.2 and master branch and found something:

Fisrt, there are some memory leaks in v3.2 and master:

    =================================================================
    ==111401==ERROR: LeakSanitizer: detected memory leaks
    
    Direct leak of 6 byte(s) in 1 object(s) allocated from:
        #0 in strdup (/opt/mnt/software/mxml32/a.out+0x46f260)
        #1 in mxmlSaveAllocString /opt/mnt/software/mxml32/mxml-file.c:227:13
        #2 in LLVMFuzzerTestOneInput /opt/mnt/software/mxml32/mxml_fuzzer.cpp:23:8
        #3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/opt/mnt/software/mxml32/a     .out+0x42f357)
        #4 in fuzzer::Fuzzer::MutateAndTestOne() (/opt/mnt/software/mxml32/a.out+0x439bc4)
        #5 in fuzzer::Fuzzer::Loop(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::a     llocator<char> >, fuzzer::fuzzer_allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<     char> > > > const&) (/opt/mnt/software/mxml32/a.out+0x43b22f)
        #6 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/opt/mnt/soft     ware/mxml32/a.out+0x42a5ec)
        #7 in main (/opt/mnt/software/mxml32/a.out+0x41d4b2)
        #8 in __libc_start_main /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
    
    SUMMARY: AddressSanitizer: 6 byte(s) leaked in 1 allocation(s).
    INFO: to ignore leaks on libFuzzer side use -detect_leaks=0.
    

and :  
this is your testmxml.c:

    ...
    Creating libmxml.so.1.6...
    Creating libmxml.a...
    a - mxml-attr.o
    a - mxml-entity.o
    a - mxml-file.o
    a - mxml-get.o
    a - mxml-index.o
    a - mxml-node.o
    a - mxml-search.o
    a - mxml-set.o
    a - mxml-private.o
    a - mxml-string.o
    Compiling testmxml.c
    Linking testmxml...
    Testing library...
    
    =================================================================
    ==113129==ERROR: LeakSanitizer: detected memory leaks
    
    Direct leak of 88 byte(s) in 1 object(s) allocated from:
        #0 in calloc (/opt/mnt/software/mxml32/testmxml+0x4da178)
        #1 in mxml_new /opt/mnt/software/mxml32/mxml-node.c:841:15
        #2 in mxmlNewElement /opt/mnt/software/mxml32/mxml-node.c:382:15
        #3 in mxml_load_data /opt/mnt/software/mxml32/mxml-file.c:1783:14
        #4 in mxmlSAXLoadFile /opt/mnt/software/mxml32/mxml-file.c:467:11
        #5 in main /opt/mnt/software/mxml32/testmxml.c:676:5
        #6 in __libc_start_main /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
    
    Indirect leak of 37 byte(s) in 1 object(s) allocated from:
        #0 in __interceptor_strdup (/opt/mnt/software/mxml32/testmxml+0x436770)
        #1 in mxmlNewElement /opt/mnt/software/mxml32/mxml-node.c:383:32
        #2 in mxml_load_data /opt/mnt/software/mxml32/mxml-file.c:1783:14
        #3 in mxmlSAXLoadFile /opt/mnt/software/mxml32/mxml-file.c:467:11
        #4 in main /opt/mnt/software/mxml32/testmxml.c:676:5
        #5 in __libc_start_main /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
    
    SUMMARY: AddressSanitizer: 125 byte(s) leaked in 2 allocation(s).
    Makefile:271: recipe for target 'testmxml' failed
    make: *** [testmxml] Error 1
    

also ,we I input an unformed string to mxmlLoadString, there will be a stack-buffer-overflow and heap-buffer-overflow. I think if you add a longth check in mxml\_string\_getc when every pointer change("like (\*s)++"), will be better? Of course Maybe I have use it in a wrong . you can check it here:  
this is my testcase:

    #include <string>
    #include <vector>
    #include <assert.h>
    #include "mxml.h"
    
    extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    
    std::string c(reinterpret_cast<const char *>(data), size);
    
    char *ptr;
    
    mxml_node_t *tree;
    
    tree = mxmlLoadString(NULL, c.c_str(), MXML_NO_CALLBACK);
    
    if(tree){
            ptr = mxmlSaveAllocString(tree, MXML_NO_CALLBACK);
            if(!ptr) assert(false);
            mxmlDelete(tree);
    }
    
    return 0;
    }
    
    

you can compile your lib with  
CFLAGS =+ "-g -O0 -fno-omit-frame-pointer -gline-tables-only -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link" and  
LDFLAGS =+"-fsanitize=fuzzer-no-link -fsanitize=address"  
and  
clang++ -g -O1 -fno-omit-frame-pointer -gline-tables-only -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link mxml\_fuzzer.cpp -I ./ -fsanitize=fuzzer ./libmxml.a

run and these are the backtrace:

    =================================================================
    ==2858==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffed9190220 at pc 0x00000055a6f2 bp 0x7ffed918edc0 sp 0x7ffed918edb8
    READ of size 1 at 0x7ffed9190220 thread T0
        #0 in mxml_string_getc /opt/mnt/software/mxml32/mxml-file.c:2611:16
        #1 in mxml_parse_element /opt/mnt/software/mxml32/mxml-file.c:2141:16
        #2 in mxml_load_data /opt/mnt/software/mxml32/mxml-file.c:1977:14
        #3 in mxmlLoadString /opt/mnt/software/mxml32/mxml-file.c:180:11
        #4 in LLVMFuzzerTestOneInput /opt/mnt/software/mxml32/mxml_fuzzer.cpp:12:8
        #5 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/opt/mnt/software/mxml32/a.out+0x42f357)
        #6 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/opt/mnt/software/mxml32/a.out+0x41f7ea)
        #7 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/opt/mnt/software/mxml32/a.out+0x42a7b0)
        #8 in main (/opt/mnt/software/mxml32/a.out+0x41d4b2)
        #9 in __libc_start_main /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
        #10 in _start (/opt/mnt/software/mxml32/a.out+0x41d529)
    

    =================================================================
    ==6265==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x612000000a73 at pc 0x000000558e2d bp 0x7ffe13e2caa0 sp 0x7ffe13e2ca98
    READ of size 1 at 0x612000000a73 thread T0
        #0 in mxml_string_getc /opt/mnt/software/mxml32/mxml-file.c:2422:13
        #1 in mxml_load_data /opt/mnt/software/mxml32/mxml-file.c:1558:20
        #2 in mxmlLoadString /opt/mnt/software/mxml32/mxml-file.c:180:11
        #3 in LLVMFuzzerTestOneInput /opt/mnt/software/mxml32/mxml_fuzzer.cpp:12:8
        #4 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/opt/mnt/software/mxml32/a.out+0x42f357)
        #5 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/opt/mnt/software/mxml32/a.out+0x41f7ea)
        #6 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/opt/mnt/software/mxml32/a.out+0x42a7b0)
        #7 in main (/opt/mnt/software/mxml32/a.out+0x41d4b2)
        #8 in __libc_start_main /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
        #9 in _start (/opt/mnt/software/mxml32/a.out+0x41d529)

CVE-2021-42860: stack-buffer-overflow and heap-buffer-overflow · Issue #286 · michaelrsweet/mxml

There is a stack-overflow vulnerability in tinytoml v0.4 that can cause a crash or DoS.

Hi,

I have found a bug when I fuzzing . When I enter an input file to a program use toml.h with parseFile, it cause a stack-overflow at parseFile function. I think there maybe too much loop or other bug cause this . my stack size is 8192kbs.

I know that we can avoid it by ulimit -s , but I think parse a toml file about 32k that cause 8M stack overflow maybe not a good way. If I make a file follow some pattern , the file may be minimized and smaller than 10k.

Here is the backtrace：

    #0 __asan_memset ()
        at /src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:26
    #1  std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__zero() () at /usr/local/bin/../include/c++/v1/string:1563
    #2  std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string() () at /usr/local/bin/../include/c++/v1/string:1812
    #3  toml::internal::Token::Token(toml::internal::TokenType) () at ./include/toml/toml.h:272
    #4  toml::internal::Lexer::nextToken(bool) () at ./include/toml/toml.h:1022
    #5  toml::internal::Lexer::nextValueToken() () at ./include/toml/toml.h:967
    #6  toml::internal::Parser::nextValue() () at ./include/toml/toml.h:347
    #7  toml::internal::Parser::consumeForValue(toml::internal::TokenType) ()
        at ./include/toml/toml.h:1740
    

(and maybe 20000 times repeat below two lines)

    toml::internal::Parser::parseArray(toml::Value*) () at ./include/toml/toml.h:1978
    toml::internal::Parser::parseValue(toml::Value*) () at ./include/toml/toml.h:1919
    

and this below:

    toml::internal::Parser::parseKeyValue(toml::Value*) () at ./include/toml/toml.h:1883
    toml::internal::Parser::parse() () at ./include/toml/toml.h:1790
    toml::parse(std::__1::basic_istream<char, std::__1::char_traits<char> >&) ()
        at ./include/toml/toml.h:385
    toml::parseFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) () at ./include/toml/toml.h:401
    LLVMFuzzerTestOneInput () at /src/parse_file.cc:16
    fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) ()
    RunOneTest () at /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323
    fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) ()
    main () at /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20
    

the testcase I use is like parse\_file.cc in your project. you can just compile use your code and input my file to the parse\_file. stack size is 8192kbs. And you will get a segment fault caused by stack overflow. I have upload the file causes this.  
crashcase.zip

CVE-2021-42692: stack-overflow at  "parseFile"  · Issue #49 · mayah/tinytoml

In SoX 14.4.2, there is an assertion failure in rate_init in rate.c in libsox.a.

**summary**

Hello, I was testing my new fuzzer and found two bugs: a reachable assertion in rate\_init, rate.c:303 and a float point exception in lsx\_aiffstartwrite.

**environment**

sox latest commit 42b3557e13e0fe01a83465b672d89faddbe65f49,  
clang 12.0.1,  
Ubuntu 21.10

**step to reproduce**

compile sox with CC=clang, CFLAGS="-fsanitize=address -g"  
run command ./sox --single-threaded @@ -t aiff /dev/null

**BUG1**

sox:rate.c:303:voidrate_init(rate_t*,rate_shared_t*,double,double,double,double,double,rolloff_t,sox_bool,sox_bool,int,int,sox_bool):Assertion`factor>0'failed.
Aborted

**BUG2**

AddressSanitizer:DEADLYSIGNAL
=================================================================
==3050061==ERROR:AddressSanitizer:FPEonunknownaddress0x000000591211(pc0x000000591211bp0x7ffd7929b6b0sp0x7ffd7929b660T0)
#00x591211inlsx_aiffstartwrite(/home/kdsj/workspace/fuzz/sox-aiff/sox+0x591211)
#10x83e26finopen_write(/home/kdsj/workspace/fuzz/sox-aiff/sox+0x83e26f)
#20x83b303insox_open_write(/home/kdsj/workspace/fuzz/sox-aiff/sox+0x83b303)
#30x8a4ae8inopen_output_file(/home/kdsj/workspace/fuzz/sox-aiff/sox+0x8a4ae8)
#40x8952e1inprocess(/home/kdsj/workspace/fuzz/sox-aiff/sox+0x8952e1)
#50x887e23inmain(/home/kdsj/workspace/fuzz/sox-aiff/sox+0x887e23)
#60x7fac08e4afcfin__libc_start_call_main../sysdeps/nptl/libc_start_call_main.h:58
#70x7fac08e4b07cin__libc_start_main_impl../csu/libc-start.c:409
#80x408864in_start(/home/kdsj/workspace/fuzz/sox-aiff/sox+0x408864)

AddressSanitizercannotprovideadditionalinfo.
SUMMARY:AddressSanitizer:FPE(/home/kdsj/workspace/fuzz/sox-aiff/sox+0x591211)inlsx_aiffstartwrite
==3050061==ABORTING

**POC**

as shown in attachment poc.zip

**Credit**

NCNIPC of China  
Hexhive

Tag

#c++