FreeType commit 1e2eb65048f75c64b68708efed6ce904c31f3b2f was discovered to contain a heap buffer overflow via the function sfnt_init_face.

I compile freetype with ASAN and call FT_New_Face with the following code:

    #include "ft2build.h"
    #include FT_FREETYPE_H
    
    int main (int argc, char **argv) {
        FT_Library lib;
        FT_Face face;
    
        FT_Init_FreeType(&lib);
        FT_New_Face(lib, argv[1], -4939615758108852224, &face);
    }

and run with this file testface

I think FT_New_Face should return a non-zero value. However, ASAN reports like following:

    ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000088 at pc 0x7fd51dd1048d bp 0x7ffdffb48a10 sp 0x7ffdffb48a08
    READ of size 8 at 0x602000000088 thread T0
        #0 0x7fd51dd1048c in sfnt_init_face
        #1 0x7fd51dd60277 in tt_face_init
        #2 0x7fd51db84bf1 in open_face
        #3 0x7fd51db583c2 in ft_open_face_internal
        #4 0x7fd51db5764a in FT_New_Face
        #5 0x4c6c0b in main
        #6 0x7fd51d4f80b2 in __libc_start_main
        #7 0x41c2fd in _start
    
    0x602000000088 is located 8 bytes to the left of 8-byte region [0x602000000090,0x602000000098)
    allocated by thread T0 here:
        #0 0x494a3d in malloc
        #1 0x7fd51dbb8ea4 in ft_alloc
        #2 0x7fd51db7c1b1 in ft_mem_qalloc
        #3 0x7fd51db4cdb3 in ft_mem_alloc
        #4 0x7fd51dd298f3 in sfnt_open_font
        #5 0x7fd51dd1018c in sfnt_init_face
        #6 0x7fd51dd60277 in tt_face_init
        #7 0x7fd51db84bf1 in open_face
        #8 0x7fd51db583c2 in ft_open_face_internal
        #9 0x7fd51db5764a in FT_New_Face
        #10 0x4c6c0b in main
        #11 0x7fd51d4f80b2 in __libc_start_main 
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow in sfnt_init_face
    Shadow bytes around the buggy address:
      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 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
    =>0x0c047fff8010: fa[fa]00 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
      0x0c047fff8060: 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
    ==3906462==ABORTING

Edited Mar 17, 2022 by

CVE-2022-27404: heap-buffer-overflow on creating a face with strange file and invalid index (#1138) · Issues · FreeType / FreeType

In GNOME Epiphany before 41.4 and 42.x before 42.2, an HTML document can trigger a client buffer overflow (in ephy_string_shorten in the UI process) via a long page title. The issue occurs because the number of bytes for a UTF-8 ellipsis character is not properly considered.

Merged requested to merge mcatanzaro/memory-corruption into master Apr 15, 2022

This reverts commit 232c6134.

I got my browser stuck in a crash loop today while visiting a website with a page title greater than ephy-embed.c's MAX\_TITLE\_LENGTH, the only condition in which ephy\_string\_shorten() is ever used. Turns out this commit is wrong: an ellipses is a multibyte character (three bytes in UTF-8) and so we're writing past the end of the buffer when calling strcat() here. Ooops.

Shame it took nearly four years to notice and correct this.

Edited Apr 15, 2022 by Michael Catanzaro

CVE-2022-29536: Fix memory corruption in ephy_string_shorten() (!1106) · Merge requests · GNOME / Epiphany · GitLab

An exploitable code execution vulnerability exists in the file format parsing functionality of Graphisoft BIMx Desktop Viewer 2019.2.2328. A specially crafted file can cause a heap buffer overflow resulting in a code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

An exploitable code execution vulnerability exists in the file format parsing functionality of Graphisoft BIMx Desktop Viewer 2019.2.2328. A specially crafted file can cause a heap buffer overflow resulting in a code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

Graphisoft BIMx Desktop Viewer 2019.2.2328

**Product URLs**

https://www.graphisoft.com/downloads/bimx/bimx\_desktop.html

**CVSSv3 Score**

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

**CWE**

CWE-680 - Integer Overflow to Buffer Overflow

**Details**

BIMx Desktop Viewer allows for models created by Graphisoft ArchiCad to be shared and viewed by anyone. With Desktop Viewer, clients can view their prospective models without the need of having to install the entire suite of tools needed to create the model itself.

The modules used in this vulnerability are below:

    00007ff77c5f0000 00007ff77c818000   BIMx       (deferred)
        Image path: BIMx.exe
        Image name: BIMx.exe
        Timestamp:        Wed Jun  5 08:09:29 2019 (5CF7BF09)
        CheckSum:         00000000
        ImageSize:        00228000
        File version:     2019.2.2328.0
        Product version:  2019.2.2328.0
    

The BIMx file format is composed of a variety of resource files which are read and written to disk before processed. To begin processing a given resource file, a 520 byte chunk is read from the file.

    bimx+55c20
    .text:0000000000055C20  mov  r9, r14                 ; Input File Stream
    .text:0000000000055C23  mov  edx, 208h               ; Number of elements to read
    .text:0000000000055C28  mov  r8d, 1                  ; Size of each elements
    .text:0000000000055C2E  lea  rcx, [rbp+3F0h+var_470] ; Output buffer
    .text:0000000000055C32  call cs:fread                ; Call fread
    

This file chunk contains the name of the resource along with the number of bytes contained in this resource. This chunk looks like the following struct:

    struct ResourceHeader {
        name: [u8; 512],
        offset_to_struct: u32,
        length_of_data: u32,
    }
    

The application then allocates enough memory to fill with the resource bytes. Along with the resource bytes, themselves, the allocation can also contain an attribute or note of what the allocation is for.

    bimx+78572
    .text:0000000000078572  inc     rbx                    ; Increment note pointer
    .text:0000000000078575  cmp     byte ptr [rdx+rbx], 0  ; Check if we found the end of the note
    .text:0000000000078579  jnz     short loc_78572        ; Continue incrementing
    

The application then calculates the length of the note and then adds that to the found number of bytes for this resource for the final allocation.

    bimx+78589
    .text:0000000000078589  lea     eax, [rbx+6]
    .text:000000000007858C  cdq
    .text:000000000007858D  and     edx, 0Fh
    .text:0000000000078590  lea     edi, [rdx+rax]
    .text:0000000000078593  sar     edi, 4
    .text:0000000000078596  inc     edi
    .text:0000000000078598  shl     edi, 4
    .text:000000000007859B  lea     ecx, [rdi+r15]  ; Final add of resource bytes and note length
    .text:000000000007859F  movsxd  rcx, ecx        
    .text:00000000000785A2  call    cs:__imp_malloc
    

Assuming there is no problem with the allocation, the entire allocation is set to 0 and then filled with the resource bytes.

    bimx+785b0
    .text:00000000000785B0                 movsxd  rdi, edi        ;
    .text:00000000000785B3                 mov     edx, 0AAh       ; Memset the note bytes to 0xaa
    .text:00000000000785B8                 mov     r8, rdi         ; Allocation note size
    .text:00000000000785BB                 mov     [rsp+38h+arg_0], rbp
    .text:00000000000785C0                 mov     rcx, r14        ; void *
    .text:00000000000785C3                 call    memset
    .text:00000000000785C8                 lea     rbp, [rdi+r14]  ; Address after the allocation note
    .text:00000000000785CC                 mov     r8, r15         ; Number of resource bytes
    .text:00000000000785CF                 mov     rcx, rbp          
    .text:00000000000785D2                 xor     edx, edx        ; Fill with 0
    .text:00000000000785D4                 call    memset
    .text:00000000000785D9                 movzx   edi, bl
    .text:00000000000785DC                 mov     rdx, rsi        ; Allocation note
    .text:00000000000785DF                 mov     r8d, edi        ; Allocation note length
    .text:00000000000785E2                 mov     rcx, r14        ; New allocation
    .text:00000000000785E5                 call    memcpy
    

It is possible for an attacker to overflow the malloc allocation size after adding the resource length. This will result in an allocation that is smaller than requested. Since the allocation is smaller than expected, the memset and the memcpy cause an out of bounds write on a heap buffer, potentially resulting in a code execution.

**Crash Information**

(1bd9c.1bda4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. \*\*\* WARNING: Unable to verify checksum for BIMx.exe VCRUNTIME140!memset\_repmovs+0x9: 00007ffb\`d8f91689 f3aa rep stos byte ptr \[rdi\]

**Timeline**

2020-03-26 - Initial contact  
2020-03-31 - Vendor disclosure  
2020-06-30 - 90 day notice  
2020-07-03 - Vendor advised reports filtered as spam  
2020-07-07 - Issued copy of reports & vendor confirmed  
2020-07-28 - Vendor advised new version will address issue mid September  
2020-09-15 - Follow up with vendor; no response  
2020-11-06 - Public Release

Discovered by Cory Duplantis of Cisco Talos.

CVE-2020-6099: TALOS-2020-1032 || Cisco Talos Intelligence Group

**SUMMARY**

An exploitable code execution vulnerability exists in the file format parsing functionality of Graphisoft BIMx Desktop Viewer 2019.2.2328. A specially crafted file can cause a heap buffer overflow resulting in a code execution. 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.

Graphisoft BIMx Desktop Viewer 2019.2.2328

**PRODUCT URLS**

BIMx Desktop Viewer - https://www.graphisoft.com/downloads/bimx/bimx\_desktop.html

**CVSSv3 SCORE**

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

**CWE**

CWE-680 - Integer Overflow to Buffer Overflow

**DETAILS**

BIMx Desktop Viewer allows for models created by Graphisoft ArchiCad to be shared and viewed by anyone. With Desktop Viewer, clients can view their prospective models without the need of having to install the entire suite of tools needed to create the model itself.

The modules used in this vulnerability are below:

    00007ff77c5f0000 00007ff77c818000   BIMx       (deferred)
        Image path: BIMx.exe
        Image name: BIMx.exe
        Timestamp:        Wed Jun  5 08:09:29 2019 (5CF7BF09)
        CheckSum:         00000000
        ImageSize:        00228000
        File version:     2019.2.2328.0
        Product version:  2019.2.2328.0
    

The BIMx file format is composed of a variety of resource files which are read and written to disk before processed. To begin processing a given resource file, a 520 byte chunk is read from the file.

    bimx+55c20
    .text:0000000000055C20  mov  r9, r14                 ; Input File Stream
    .text:0000000000055C23  mov  edx, 208h               ; Number of elements to read
    .text:0000000000055C28  mov  r8d, 1                  ; Size of each elements
    .text:0000000000055C2E  lea  rcx, [rbp+3F0h+var_470] ; Output buffer
    .text:0000000000055C32  call cs:fread                ; Call fread
    

This file chunk contains the name of the resource along with the number of bytes contained in this resource. This chunk looks like the following struct:

    struct ResourceHeader {
        name: [u8; 512],
        offset_to_struct: u32,
        length_of_data: u32,
    }
    

The application then allocates enough memory to fill with the resource bytes. Along with the resource bytes, themselves, the allocation can also contain an attribute or note of what the allocation is for.

    bimx+78572
    .text:0000000000078572  inc     rbx                    ; Increment note pointer
    .text:0000000000078575  cmp     byte ptr [rdx+rbx], 0  ; Check if we found the end of the note
    .text:0000000000078579  jnz     short loc_78572        ; Continue incrementing
    

The application then calculates the length of the note and then adds that to the found number of bytes for this resource for the final allocation.

    bimx+78589
    .text:0000000000078589  lea     eax, [rbx+6]
    .text:000000000007858C  cdq
    .text:000000000007858D  and     edx, 0Fh
    .text:0000000000078590  lea     edi, [rdx+rax]
    .text:0000000000078593  sar     edi, 4
    .text:0000000000078596  inc     edi
    .text:0000000000078598  shl     edi, 4
    .text:000000000007859B  lea     ecx, [rdi+r15]  ; Final add of resource bytes and note length
    .text:000000000007859F  movsxd  rcx, ecx        
    .text:00000000000785A2  call    cs:__imp_malloc
    

Assuming there is no problem with the allocation, the entire allocation is set to 0 and then filled with the resource bytes.

    bimx+785b0
    .text:00000000000785B0                 movsxd  rdi, edi        ;
    .text:00000000000785B3                 mov     edx, 0AAh       ; Memset the note bytes to 0xaa
    .text:00000000000785B8                 mov     r8, rdi         ; Allocation note size
    .text:00000000000785BB                 mov     [rsp+38h+arg_0], rbp
    .text:00000000000785C0                 mov     rcx, r14        ; void *
    .text:00000000000785C3                 call    memset
    .text:00000000000785C8                 lea     rbp, [rdi+r14]  ; Address after the allocation note
    .text:00000000000785CC                 mov     r8, r15         ; Number of resource bytes
    .text:00000000000785CF                 mov     rcx, rbp          
    .text:00000000000785D2                 xor     edx, edx        ; Fill with 0
    .text:00000000000785D4                 call    memset
    .text:00000000000785D9                 movzx   edi, bl
    .text:00000000000785DC                 mov     rdx, rsi        ; Allocation note
    .text:00000000000785DF                 mov     r8d, edi        ; Allocation note length
    .text:00000000000785E2                 mov     rcx, r14        ; New allocation
    .text:00000000000785E5                 call    memcpy
    

It is possible for an attacker to overflow the malloc allocation size after adding the resource length. This will result in an allocation that is smaller than requested. Since the allocation is smaller than expected, the memset and the memcpy cause an out of bounds write on a heap buffer, potentially resulting in a code execution.

**Crash Information**

(1bd9c.1bda4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. \*\*\* WARNING: Unable to verify checksum for BIMx.exe VCRUNTIME140!memset\_repmovs+0x9: 00007ffb\`d8f91689 f3aa rep stos byte ptr \[rdi\]

**TIMELINE**

2020-03-26 - Initial contact  
2020-03-31 - Vendor disclosure  
2020-06-30 - 90 day notice  
2020-07-03 - Vendor advised reports filtered as spam  
2020-07-07 - Issued copy of reports & vendor confirmed  
2020-07-28 - Vendor advised new version will address issue mid September  
2020-09-15 - Follow up with vendor; no response  
2020-11-06 - Public Release

Discovered by Cory Duplantis of Cisco Talos.

Heap buffer overflow issues were found in Opensc before version 0.22.0 in pkcs15-oberthur.c that could potentially crash programs using the library.

'2016439?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2021-42781: Invalid Bug ID

Stack buffer overflow issues were found in Opensc before version 0.22.0 in various places that could potentially crash programs using the library.

@@ -159,7 +159,7 @@ static int cardos\_have\_2048bit\_package(sc\_card\_t \*card)

sc\_apdu\_t apdu;

u8 rbuf\[SC\_MAX\_APDU\_BUFFER\_SIZE\];

int r;

const u8 \*p = rbuf, \*q;

const u8 \*p = rbuf, \*q, \*pp;

size\_t len, tlen = 0, ilen = 0;

  

sc\_format\_apdu(card, &apdu, SC\_APDU\_CASE\_2\_SHORT, 0xca, 0x01, 0x88);

@@ -175,10 +175,10 @@ static int cardos\_have\_2048bit\_package(sc\_card\_t \*card)

return 0;

  

while (len != 0) {

p = sc\_asn1\_find\_tag(card->ctx, p, len, 0xe1, &tlen);

if (p == NULL)

pp = sc\_asn1\_find\_tag(card->ctx, p, len, 0xe1, &tlen);

if (pp == NULL)

return 0;

q = sc\_asn1\_find\_tag(card->ctx, p, tlen, 0x01, &ilen);

q = sc\_asn1\_find\_tag(card->ctx, pp, tlen, 0x01, &ilen);

if (q == NULL || ilen != 4)

return 0;

if (q\[0\] == 0x1c)

CVE-2021-42782: cardos: Correctly calculate the left bytes to avoid buffer overrun · OpenSC/OpenSC@1252aca

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

Buffer Overflow in uudecoder in Mutt affecting all versions starting from 0.94.13 before 2.2.3 allows read past end of input line

**Commit e5ed080c** authored Apr 05, 2022 by 

Browse files

**Fix uudecode buffer overflow.**

mutt\_decode\_uuencoded() used each line's initial "length character"
without any validation.  It would happily read past the end of the
input line, and with a suitable value even past the length of the
input buffer.

As I noted in ticket 404, there are several other changes that could
be added to make the parser more robust.  However, to avoid
accidentally introducing another bug or regression, I'm restricting
this patch to simply addressing the overflow.

Thanks to Tavis Ormandy for reporting the issue, along with a sample
message demonstrating the problem.

*   Changes 1

...

...

@@ -404,9 +404,9 @@ static void mutt\_decode\_uuencoded (STATE \*s, LOFF\_T len, int istext, iconv\_t cd)

pt \= tmps;

linelen \= decode\_byte (\*pt);

pt++;

for (c \= 0; c < linelen;)

for (c \= 0; c < linelen && \*pt;)

{

for (l \= 2; l <= 6; l += 2)

for (l \= 2; l <= 6 && \*pt && \*(pt + 1); l += 2)

{

out \= decode\_byte (\*pt) << l;

pt++;

...

...

*   mentioned in issue #404 (closed)
    
    mentioned in issue #404
    
*   mentioned in commit renatoaguiar/openbsd-ports@24d300b2b9ce07d6e212820528619b6f770fb475
    
*   mentioned in commit neomutt/neomutt@ee7cb4e461c1cdf0ac14817b03687d5908b85f84

CVE-2022-1328: Fix uudecode buffer overflow. (e5ed080c) · Commits · Mutt Project / mutt · GitLab

Two heap-based buffer overflow vulnerabilities exist in the TIFF parser functionality of Accusoft ImageGear 19.10. A specially-crafted file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger these vulnerabilities.This heap-based buffer oveflow takes place trying to copy the first 12 bits from local variable.

**Summary**

Two heap-based buffer overflow vulnerabilities exist in the TIFF parser functionality of Accusoft ImageGear 19.10. A specially-crafted file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger these vulnerabilities.

**Tested Versions**

Accusoft ImageGear 19.10

**Product URLs**

ImageGear - https://www.accusoft.com/products/imagegear-collection/

**CVSSv3 Score**

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

**CWE**

CWE-122 - Heap-based Buffer Overflow

**Details**

The ImageGear library is a document-imaging developer toolkit that offers image conversion, creation, editing, annotation and more. It supports more than 100 formats such as DICOM, PDF, Microsoft Office and others.

When a TIFF file, with specific tag requirements, is loaded, its data are parsed by the FUN_10074d50 function.

The essential tags required to reach this “parser”:

*   The value of the SamplesPerPixel tag, greater than 2
*   The value of the BitsPerSample tag should be 0xc (we will focus on this, but different values are parsed by the same function)
*   The value of the PlanarConfiguration tag should be 2
*   The presence of either TileOffsets or StripOffsets tag with N greater than 1

The funtion FUN_10074d50:

    dword __cdecl
    FUN_10074d50(uint ID_TIF_SAMPLES_PER_PIXEL,int sample_index,uint ID_TIF_BITS_PER_SAMPLE,
                int ID_TIF_IMAGE_WIDTH,byte *src_buff,void *dest_buff,size_t source_size)
    
    {
     [...]
    
      if (true) {
        switch(ID_TIF_BITS_PER_SAMPLE) {
       [...]
        case 0xc:
          alternate_branch = false;
          loop_index = 0;
          width_index = ID_TIF_IMAGE_WIDTH;
          if (0 < ID_TIF_IMAGE_WIDTH) {
            do {
              if (0 < (int)ID_TIF_SAMPLES_PER_PIXEL) {
                ID_TIF_BITS_PER_SAMPLE = ID_TIF_SAMPLES_PER_PIXEL;
                do {
                  if (alternate_branch) {
                    if (alternate_branch) {
                      curren_src_byte_cur = src_buff + loop_index;
                      loop_index_+1 = loop_index + 1;
                      loop_index = loop_index + 2;
                      *(ushort *)((int)dest_buff + sample_index * 2) =
                           CONCAT11(*curren_src_byte_cur,src_buff[loop_index_+1]) & 0xfff;                  [1]
                      sample_index = sample_index + ID_TIF_SAMPLES_PER_PIXEL;
                      alternate_branch = false;
                    }
                  }
                  else {
                    *(ushort *)((int)dest_buff + sample_index * 2) =
                         (ushort)(src_buff[loop_index + 1] >> 4) | 
                                 (ushort)src_buff[loop_index] << 4;                                         [2]
                    sample_index = sample_index + ID_TIF_SAMPLES_PER_PIXEL;
                    loop_index = loop_index + 1;
                    alternate_branch = true;
                  }
    [...]
    }
    

In this function the src_buff, which represents a “row” of data, is copied into the dest_buff. This function implements the data parsing for the supported BitsPerSample values. When BitsPerSample is 0xc the copy of the data is perfomed in a loop iterated SamplesPerPixel times. For every two iterations, there is a writing pattern where for each 3 bytes read from src_buff, there are 4 written into dest_buff. That loop is then iterated ImageWidth times.

The idea is that 16 bits (i.e., 2 bytes) of dest_buff are filled with 12 bits of src_buff. At [2] the first 12 bits of the source are manipulated, and the remaining 12, in order to complete 3 bytes read, are manipulated at [1]. It is important to note that the acess to dest_buff is not sequential, but instead, it is calculated using sample_index as base offset, incremented each iteration by SamplesPerPixel, a value taken from the homonymous TIFF tag.

The call to FUN_10074d50 is originated by the TIFF_parse function, the “main” TIFF parser:

    void TIFF_parse(mys_table_function *param_1,uint param_2,mys_tags_data *TIFF_tags,undefined4 param_4
                   ,HIGDIBINFO param_5,subsapling_Y_Cb_Cr *YCbCr_subsamp)
    
    {
      [...]
    
      dst_buff = (byte *)0x0;
      width_buff_size = 0;
      local_c = 0;
      multipler = (byte *)0x0;
      arr_of_dest_buff = (byte **)0x0;
      if (*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL == 0) {
        AF_err_record_set("..\\..\\..\\..\\Common\\Formats\\tifread.c",0x1793,-0x80d,0,0,0,(LPCHAR)0x0);
        AF_error_check();
        return;
      }
      io_buff = (io_buffer *)
                AF_memm_alloc(param_2,(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL * 0x34);
      if (io_buff == (io_buffer *)0x0) {
        AF_err_record_set("..\\..\\..\\..\\Common\\Formats\\tifread.c",0x1799,-1000,0,0,0,(LPCHAR)0x0);
        AF_error_check();
        return;
      }
      src_buff = (byte **)AF_memm_alloc(param_2,(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL <<
                                                2);
      if (src_buff == (byte **)0x0) {
        sample_per_pixel_index = 0x17a1;
        lpExtraText_00 = src_buff;
      }
      else {
        OS_memset(src_buff,0,(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL << 2);
        lpExtraText_00 =
             (byte **)AF_memm_alloc(param_2,(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL << 2);
        if (lpExtraText_00 != (byte **)0x0) {
          if (TIFF_tags->ID_TIF_PHOTO_INTERP == IG_TIF_PHOTO_YCBCR) {
            [...]
          }
          else {
    LAB_10177d86:
            if (TIFF_tags->ID_TIF_PLANAR_CONFIG == 1) {
              [...]
            }
            else {
              if (TIFF_tags->ID_TIF_PLANAR_CONFIG == 2) {
                if (TIFF_tags->ID_TIF_PHOTO_INTERP == IG_TIF_PHOTO_YCBCR) {
                  [...]
                }
                else {
                  sample_per_pixel_index = 0;
                  if (*(short *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL != 0) {
                    do {
                      loop_index = sample_per_pixel_index + 1;
                      iVar1 = (int)*(short *)((TIFF_tags->ID_TIF_BITS_PER_SAMPLE - 2) + loop_index * 2)
                              * TIFF_tags->ID_TIF_IMAGE_WIDTH + 7;
                      lpExtraText_00[sample_per_pixel_index] =
                           (byte *)((int)(iVar1 + (iVar1 >> 0x1f & 7U)) >> 3);                              [3]
                      sample_per_pixel_index = loop_index;
                    } while (loop_index < (int)(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL);
                  }
                  width_buff_size = IO_raster_size_get(param_5);
                  dst_buff = (byte *)AF_memm_alloc(param_2,width_buff_size);                                [4]
                  if (dst_buff == (byte *)0x0) {
                    AF_err_record_set("..\\..\\..\\..\\Common\\Formats\\tifread.c",0x1843,-1000,0,
                                      param_2,width_buff_size,(LPCHAR)0x0);
                    goto LAB_10178379;
                  }
                }
                dVar3 = 0;
                sample_size_index = 0;
                piVar4 = io_buff;
                if (*(short *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL != 0) {
                  do {
                    dVar2 = IOb_init(param_1,param_2,piVar4,(int)lpExtraText_00[sample_size_index] * 5,1
                                    );                                                                      [5]
                    if (0 < (int)dVar2) {
                      dVar3 = 1;
                      local_c = 1;
                      break;
                    }
                    sample_size_index = sample_size_index + 1;
                    piVar4 = (io_buffer *)&piVar4->size_buffer;
                  } while (sample_size_index <
                           (int)(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL);
                }
                sample_per_pixel_index = 0;
                param_5 = (HIGDIBINFO)0x0;
                for (local_18 = 0;
                    (dVar3 == 0 &&
                    (local_18 < (int)TIFF_tags->from_ID_TIF_STRIP_OFFSET_or_ID_TIF_TILE_OFFSETS));
                    local_18 = local_18 + 1) {
                  if ((TIFF_tags->ID_TIF_TILE_OFFSETS != 0) &&
                     (*(short *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL != 0)) {
                    iVar1 = 0;
                    piVar4 = io_buff;
                    do {
                      perform_some_read_or_write_intofile
                                (piVar4,*(int *)(TIFF_tags->ID_TIF_TILE_OFFSETS +
                                           (TIFF_tags->
                                           result_strip_tile_offset_divided_sample_per_pixel *
                                           iVar1 + local_18) * 4) + TIFF_tags->IFD_Offset,0,0);             [6]
                      iVar1 = iVar1 + 1;
                      piVar4 = (io_buffer *)&piVar4->size_buffer;
                      dVar3 = local_c;
                      sample_per_pixel_index = (int)param_5;
                    } while (iVar1 < (int)(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL);
                  }
                  local_28 = 0;
                  if (0 < (int)TIFF_tags->ID_TIF_ROWS_PER_STRIP) {
                    do {
                      local_c = dVar3;
                      if ((int)TIFF_tags->ID_TIF_IMAGE_HEIGHT <= sample_per_pixel_index) break;
                      iVar1 = 0;
                      sample_per_pixel_index = (int)param_5;
                      if (TIFF_tags->ID_TIF_PHOTO_INTERP == IG_TIF_PHOTO_YCBCR) {
                        [...]
                      }
                      else {
                        piVar4 = io_buff;
                        if (*(short *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL != 0) {
                          do {
                            vert_buff = (byte *)get_data_from_file(piVar4,(uint)*lpExtraText_00);
                            src_buff[iVar1] = vert_buff;
                            if (vert_buff == (byte *)0x0) {
                              AF_err_record_set("..\\..\\..\\..\\Common\\Formats\\tifread.c",0x1887,
                                                -0x803,0,(AT_INT)*lpExtraText_00,0,(LPCHAR)0x0);
                              dVar3 = dVar3 + 1;
                              break;
                            }
                            iVar1 = iVar1 + 1;
                            piVar4 = (io_buffer *)&piVar4->size_buffer;
                          } while (iVar1 < (int)(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL);
                        }
                        local_c = dVar3;
                        if (dVar3 != 0) break;
                        FUN_1017c970(TIFF_tags,param_4,src_buff,lpExtraText_00,dst_buff);                   [7]
    
                        [...]
    }
    

This function is responsible for preparing the src_buff and dest_buff and calling the correct TIFF “sub-parser”. At [5], SamplesPerPixel buffers are allocated, each with size calcualted at [3]. These buffers, in this specific scenario, are the same sizes, and each individually will be used as src_buff. The size of a src_buff is:

    src_size = (((BitsPerSample & 0xffff) * width + 7) >> 3) * 5
    

Eventually, at [6] these buffers are filled.

At [4] the dest_buff is allocated, using as size the return value of the function IO_raster_size_get. The return value of IO_raster_size_get, in this specific case, can be simplified as:

    dest_size = (((next_mult_of_8_of_BitsPerSample * SamplesPerPixel * ImageWidth) + 0x1f) >> 3) & 0xfffffffc
    

Where ImageWidth and SamplesPerPixel correspond to the homonymous TIFF tags. Instead, next_mult_of_8_of_BitsPerSample is the next multiple of 8 of BitsPerSample. That is, like the other two, a value directly taken from a TIFF tag.

The TIFF_parse then calls at [7] the FUN_1017c970 function, that essentially calls FUN_10074d50 with each dest_buff and sample_index, the variable used as base offset to access the src_buff that goes from 0 to SamplesPerPixel.

**CVE-2021-21944 - TIFF parser - planar format. First 12 bits**

A specially-crafted TIFF file can lead to a heap-based buffer overflow in the TIFF image parser, due to a missing boundary check.

Trying to load a malicious TIFF file, we end up in the following situation:

    (dcc.182c): Access violation - code c0000005 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=00000036 ebx=00000007 ecx=0bd58e08 edx=00000414 esi=000000fc edi=0bd5eef0
    eip=70104f1f esp=0019f588 ebp=0019f5ac iopl=0         nv up ei pl nz na pe nc
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
    igCore19d!IG_mpi_page_set+0x8eef:
    70104f1f 66891471        mov     word ptr [ecx+esi*2],dx  ds:002b:0bd59000=????
    

This access violation take place at [2] in the FUN_10074d50 function, when trying to copy the first 12 bits from src_buff to dest_buff.

From the allocation of src_buff and dest_buff, in the TIFF_parse, to [2], the program does not check, taking into account the writing pattern used, a possible out-of-bounds access.

For example:

    sample_index    = 0
    ImageWidth      = 0x24
    SamplesPerPixel = 0x7
    BitsPerSample   = 0xc
    

We will obtain a dest_size of 0x1f8 and src_size of 0x10e.

At the fifth iteration of the outer loop in FUN_10074d50 (i.e., ImageWidth loop iteration 5) and the first of the inner one (i.e., SamplesPerPixel loop iteration 1) the element accessed at that iteration would be:

    (sample_index + SamplesPerPixel*SamplesPerPixel) * width_iteration + 
            sample_index + (sample_per_pixel_iteration * SamplesPerPixel) =
    (0 + 7 * 7) * 5 + (0 + 1 * 7) = 0xfc
    

Because the dest_size is a 16 bits buffer, the element 0xfc is located at offset 0x1f8 and 0x1f9, and because the dest_size is only 0x1f8 bytes long we are accessing that heap buffer out-of-bound.

So based on the specific TIFF tags, the dest_buff could be bigger or smaller than a single src_buff. In either case a heap-base buffer oveflow could occur due to the specific writting pattern and the missing boundary check.

**CVE-2021-21945 - TIFF parser - planar format. Second 12 bits**

Trying to load a malicious TIFF file, we end up in the following situation:

    (22a8.1bbc): Access violation - code c0000005 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=00000006 ebx=00000007 ecx=0bd28fe0 edx=00000141 esi=00000015 edi=0bd48ff0
    eip=6f3b4efd esp=0019f588 ebp=0019f5ac iopl=0         nv up ei pl nz na pe nc
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
    igCore19d!IG_mpi_page_set+0x8ecd:
    6f3b4efd 66891471        mov     word ptr [ecx+esi*2],dx  ds:002b:0bd2900a=????
    

This access violation takes place at [1] in the FUN_10074d50 function, when trying to copy the second 12 bits from src_buff to dest_buff.

From the allocation of src_buff and dest_buff, in the TIFF_parse, to [1], the program does not check, taking into account the writing pattern used, a possible out-of-bounds access.

For example with:

    sample_index    = 0
    ImageWidth      = 0x4
    SamplesPerPixel = 0x7
    BitsPerSample   = 0xc
    

We will obtain a dest_size of 0x38 and src_size of 0x1e

At the first iteration of the outer loop in FUN_10074d50 (i.e., ImageWidth loop iteration 0) and the fourth one of the inner one (i.e., SamplesPerPixel loop iteration 4) the element accessed at that iteration would be:

    (sample_index + SamplesPerPixel*SamplesPerPixel) * width_iteration +
            sample_index + (sample_per_pixel_iteration * SamplesPerPixel) =
            7 * 4 = 0x1c
    

Because the dest_size is a 16 bits buffer, the element 0x1c is located at offset 0x38 and 0x39 and because the dest_size is only 0x38 bytes long we are accessing that heap buffer out-of-bound.

**Timeline**

2021-09-10 - Initial contact  
2021-09-14 - Vendor acknowledged and created support ticket  
2021-09-21 - Vendor closed support ticket and confirmed under review with engineering team  
2021-11-30 - 60 day follow up  
2021-12-02 - Vendor advised release planned for Q1 2022  
2021-12-07 - 30 day disclosure extension granted  
2022-01-06 - Final disclosure notification  
2022-02-23 - Public disclosure

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2021-21944: TALOS-2021-1374 || Cisco Talos Intelligence Group

Two heap-based buffer overflow vulnerabilities exists in the JPEG-JFIF lossless Huffman image parser functionality of Accusoft ImageGear 19.10. A specially-crafted file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger these vulnerabilities.This heap-based buffer overflow takes place when the `SOF3` precision is lower than 9.

Tag

#buffer_overflow