OpenEXR 3.1.x before 3.1.4 has a heap-based buffer overflow in Imf_3_1::LineCompositeTask::execute (called from IlmThread_3_1::NullThreadPoolProvider::addTask and IlmThread_3_1::ThreadPool::addGlobalTask). NOTE: db217f2 may be inapplicable.

CVE-2021-45942

MDB Tools (aka mdbtools) 0.9.2 has a stack-based buffer overflow (at 0x7ffd6e029ee0) in mdb_numeric_to_string (called from mdb_xfer_bound_data and _mdb_attempt_bind).

@@ -1,45 +1,28 @@ Version 0.9.3, Beta 4 \=============  
libmdb: \* Fix build failure with emscripten #299  
Version 0.9.3, Beta 3 \=============  
libmdb / libmdbsql: \* Fix build when \_XOPEN\_SOURCE was already defined on the platform #298  
Version 0.9.3, Beta 2 \=============  
libmdb: \* Migrate to g\_memdup2 #287 #288  
libmdbsql: \* Allow double quoted (") database names #291 \* Allow spaces in database names #292 #293  
Docs: \* Add JET version for access 2013/2016/2019 to docs #286  
Version 0.9.3, Beta 1 Version 0.9.3 \=============  
libmdb: \* Support files created with Access 2019 #260 #277 \* Fix a warning when reading in binary property values #262 \* Fix signed-unsigned comparison warning #269 \* Migrate to \`g\_memdup2\` #287 #288 \* Fix build when \`\_XOPEN\_SOURCE\` was already defined on the platform #298 \* Fix build failure with emscripten #299  
libmdbsql: \* Support negative floating point literals #274 #279 \* Comparison operators behaved incorrectly when the constant was on the left #283 #285 \* Improved support for file paths in \`CONNECT TO\` statements #275 #280 #282 \* Comparison operators behaved incorrectly when the constant was on the left #283 #285 \* Allow double quoted (") database names #291 \* Allow spaces in database names #292 #293  
ODBC: \* unixODBC now uses the \`--libdir\` passed at configure-time #261 \* Fix a segfault in PyODBC when \`SQLGetTypeInfo\` is called on an unsupported data type #278  
Docs: \* Add JET version for access 2013/2016/2019 to docs #286  
Version 0.9.2 \=============

CVE-2021-45927: Version 0.9.3, final · mdbtools/mdbtools@373b7ff

UltraJSON (aka ujson) through 5.1.0 has a stack-based buffer overflow in Buffer_AppendIndentUnchecked (called from encode). Exploitation can, for example, use a large amount of indentation.

id: OSV-2021-955

summary: Stack-buffer-overflow in Buffer\_AppendIndentUnchecked

details: |

OSS-Fuzz report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36009

\`\`\`

Crash type: Stack-buffer-overflow WRITE 1

Crash state:

Buffer\_AppendIndentUnchecked

encode

encode

\`\`\`

modified: '2022-05-19T00:45:08.957102Z'

published: '2021-07-11T00:01:05.153778Z'

references:

\- type: REPORT

url: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36009

affected:

\- package:

name: ujson

ecosystem: PyPI

ranges:

\- type: GIT

repo: https://github.com/ultrajson/ultrajson.git

events:

\- introduced: 0c52200eb4e2d97e548a765d5f089858c41967b0

\- fixed: f6860f1f3d8d4e92b9be0e5815355a8976c6e75b

\- fixed: 5525f8c9ef8bb879dadd0eb942d524827d1b0362

versions:

\- 2.0.0

\- 2.0.1

\- 2.0.2

\- 2.0.3

\- 3.0.0

\- 3.1.0

\- 3.2.0

\- 4.0.0

\- 4.0.1

\- 4.0.2

\- 4.1.0

\- 4.2.0

\- 4.3.0

\- 5.0.0

\- 5.1.0

\- v1.34

\- v1.35

ecosystem\_specific:

severity: HIGH

CVE-2021-45958: oss-fuzz-vulns/OSV-2021-955.yaml at main · google/oss-fuzz-vulns

Open Asset Import Library (aka assimp) 5.1.0 and 5.1.1 has a heap-based buffer overflow in _m3d_safestr (called from m3d_load and Assimp::M3DWrapper::M3DWrapper).

CVE-2021-45948

A stack-based buffer overflow vulnerability exists in the CMA check_udp_crc function of Garrett Metal Detectors’ iC Module CMA Version 5.0. A specially-crafted packet can lead to a stack-based buffer overflow during a call to memcpy. An attacker can send a malicious packet to trigger this vulnerability.

**Summary**

A stack-based buffer overflow vulnerability exists in the CMA check\_udp\_crc function of Garrett Metal Detectors’ iC Module CMA Version 5.0. A specially-crafted packet can lead to a stack-based buffer overflow during a call to memcpy. An attacker can send a malicious packet to trigger this vulnerability.

**Tested Versions**

Garrett Metal Detectors iC Module CMA Version 5.0

**Product URLs**

https://garrett.com/security/walk-through/accessories

**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-120 - Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

**Details**

The Garrett iC Module provides network connectivity to either the Garrett PD 6500i or Garrett MZ 6100 models of walk-through metal detectors. This module enables a remote user to monitor statistics such as alarm and visitor counts in real time as well as make configuration changes to metal detectors.

The Garrett iC Module exposes a discovery service on UDP port 6877. The “CMA Connect” software, used to interact with the iC modules from a remote system, can broadcast a particularly formatted UDP packet onto the network and iC modules that receive this packet will reply with various descriptors such as MAC address, serial number, and location. A function call to memcpy within the CRC validation logic of these UDP packets is vulnerable to a stack-based buffer overflow.

This buffer overflow occurs due to a mismatch in maximum buffer sizes between the function responsible for handling incoming UDP packets, udp_thread, and the function responsible for validating the message’s checksum, check_udp_crc. When a UDP message is received inside of udp_thread, a msghdr struct is populated with an iovec struct whose message attribute points to a 512-byte long character array called msgbuf.

    .text:0001D730                 SUB     R3, R11, #-msgbuf                        [1] uint8_t msgbuf[512]
    .text:0001D734                 MOV     R0, R3          ; s
    .text:0001D738                 MOV     R1, #0          ; c
    .text:0001D73C                 MOV     R2, #0x200      ; n
    .text:0001D740                 BL      memset                                   [2] memset(msgbuf, 0, 512)
    .text:0001D744                 SUB     R3, R11, #-msgbuf
    .text:0001D748                 STR     R3, [R11,#iov]                           [3] iov[0].iov_base = msgbuf
    .text:0001D74C                 MOV     R3, #0x200 
    .text:0001D750                 STR     R3, [R11,#iov.iov_len]                   [4] iov[0].iov_len = 512
    .text:0001D754                 SUB     R3, R11, #-(src_addr.__ss_padding+4)
    .text:0001D758                 SUB     R3, R3, #0xC
    .text:0001D75C                 STR     R3, [R11,#message]
    .text:0001D760                 MOV     R3, #0x80
    .text:0001D764                 STR     R3, [R11,#message.msg_namelen]
    .text:0001D768                 SUB     R3, R11, #-iov                      
    .text:0001D76C                 STR     R3, [R11,#message.msg_iov]               [5] message.msg_iov = iov
    .text:0001D770                 MOV     R3, #1
    .text:0001D774                 STR     R3, [R11,#message.msg_iovlen]            [6] message.msg_iovlen = 1
    .text:0001D778                 SUB     R3, R11, #-(cmbuf+0xC)
    .text:0001D77C                 SUB     R3, R3, #0xC
    .text:0001D780                 STR     R3, [R11,#message.msg_control]
    .text:0001D784                 MOV     R3, #0x100
    .text:0001D788                 STR     R3, [R11,#message.msg_controllen]
    .text:0001D78C                 SUB     R3, R11, #-message
    .text:0001D790                 LDR     R0, [R11,#udpFd] ; fd
    .text:0001D794                 MOV     R1, R3          ; message
    .text:0001D798                 MOV     R2, #0          ; flags
    .text:0001D79C                 BL      recvmsg                                  [7] recvmsg(udpFd, &message, 0);
    

After a successful call to recvmsg, the udp_thread function will null-terminate the msgbuf buffer at the first instance of \r\n. The msgbuf buffer is then passed to check_udp_crc to confirm the payload’s CRC is valid.

    .text:0001D7C8                 SUB     R3, R11, #-msgbuf
    .text:0001D7CC                 MOV     R0, R3          ; s
    .text:0001D7D0                 LDR     R1, =asc_2FCD8  ; "\r\n"
    .text:0001D7D4                 BL      strcspn                                  [8] $r0 = strcspn(msgbuf, "\r\n")
    .text:0001D7D8                 MOV     R2, R0
    .text:0001D7DC                 LDR     R3, =0xFFFFFC8C
    .text:0001D7E0                 SUB     R0, R11, #-var_C
    .text:0001D7E4                 ADD     R2, R0, R2
    .text:0001D7E8                 ADD     R3, R2, R3
    .text:0001D7EC                 MOV     R2, #0
    .text:0001D7F0                 STRB    R2, [R3]                                 [9] msgbuf[$r0] = '\0'
    .text:0001D7F4                 SUB     R3, R11, #-msgbuf
    .text:0001D7F8                 MOV     R0, R3          ; msg
    .text:0001D7FC                 BL      check_udp_crc                            [10] check_udp_crc(msgbuf)
    

While the maximum length of the UDP payload in udp_thread is 512 bytes, the check_udp_crc function only allocates 256 bytes for its internal copy of the payload. A memcpy is executed which will copy strlen(msg) bytes from msgbuf into msg, resulting in a very straightforward buffer overflow.

    .text:0001D134                 PUSH    {R11,LR}
    .text:0001D138                 ADD     R11, SP, #4
    .text:0001D13C                 SUB     SP, SP, #0x128
    .text:0001D140                 STR     R0, [R11,#msg]
    .text:0001D144                 SUB     R3, R11, #-msg_buf
    .text:0001D148                 MOV     R0, R3          ; s
    .text:0001D14C                 MOV     R1, #0          ; c
    .text:0001D150                 MOV     R2, #0x100      ; n
    .text:0001D154                 BL      memset                                   [11] memset(msg, 0, 256)
    .text:0001D158                 LDR     R0, [R11,#msg]  ; s
    .text:0001D15C                 BL      strlen                                   
    .text:0001D160                 MOV     R3, R0                                   [12] msglen = strlen(msg)
    .text:0001D164                 SUB     R2, R11, #-msg_buf
    .text:0001D168                 MOV     R0, R2          ; dest
    .text:0001D16C                 LDR     R1, [R11,#msg]  ; src
    .text:0001D170                 MOV     R2, R3          ; n                      
    .text:0001D174                 BL      memcpy                                   [13] memcpy(msg, msgbuf, msglen)
    

As shown above, a maliciously crafted UDP packet with a significantly long payload will result in a buffer overflow. This overflow directly leads to attacker control of the program counter, which may be seen in the debugger output below.

**Crash Information**

    Thread 2 "cma" received signal SIGSEGV, Segmentation fault.
    0x4d4d4d4c in ?? ()
    ──────────────────────────────────────────────────────────────────────────────────────────────── registers ────
    $r0  : 0x1       
    $r1  : 0x3b      
    $r2  : 0x1       
    $r3  : 0x1       
    $r4  : 0x0       
    $r5  : 0xb636b6b0  →  "eth0"
    $r6  : 0x0       
    $r7  : 0x152     
    $r8  : 0xbefffbe0  →  0x00000000
    $r9  : 0xb6ff86d0  →  0xb6ff8db8  →  0x00000001
    $r10 : 0xb636c460  →  0x00000001
    $r11 : 0x4d4d4d4d ("MMMM"?)
    $r12 : 0xb636b6a8  →  0x00000000
    $sp  : 0xb636b6a0  →  0xb636b7d0  →  0x00000018
    $lr  : 0xb6bf7898  →  <strrchr+40> cmp r0,  #0
    $pc  : 0x4d4d4d4c ("LMMM"?)
    $cpsr: [negative ZERO CARRY overflow interrupt fast THUMB]
    ─────────────────────────────────────────────────────────────────────────────────────────── code:arm:THUMB ────
    [!] Cannot disassemble from $PC
    [!] Cannot access memory at address 0x4d4d4d4c
    ───────────────────────────────────────────────────────────────────────────────────────────────────────────────
    

**Timeline**

2021-08-17 - Vendor Disclosure  
2021-11-10 - Talos granted disclosure extension  
2021-12-13 - Vendor patched  
2021-12-15 - Talos tested patch  
2021-12-20 - Public Release

Discovered by Matt Wiseman of Cisco Talos.

CVE-2021-21901: TALOS-2021-1353 || Cisco Talos Intelligence Group

A stack-based buffer overflow vulnerability exists in the CMA check_udp_crc function of Garrett Metal Detectors’ iC Module CMA Version 5.0. A specially-crafted packet can lead to a stack-based buffer overflow during a call to strcpy. An attacker can send a malicious packet to trigger this vulnerability.

**Summary**

A stack-based buffer overflow vulnerability exists in the CMA check\_udp\_crc function of Garrett Metal Detectors’ iC Module CMA Version 5.0. A specially-crafted packet can lead to a stack-based buffer overflow during a call to strcpy. An attacker can send a malicious packet to trigger this vulnerability.

**Tested Versions**

Garrett Metal Detectors iC Module CMA Version 5.0

**Product URLs**

https://garrett.com/security/walk-through/accessories

**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-120 - Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

**Details**

The Garrett iC Module provides network connectivity to either the Garrett PD 6500i or Garrett MZ 6100 models of walk-through metal detectors. This module enables a remote user to monitor statistics such as alarm and visitor counts in real time as well as make configuration changes to metal detectors.

The Garrett iC Module exposes a discovery service on UDP port 6877. The “CMA Connect” software, used to interact with the iC modules from a remote system, can broadcast a particularly formatted UDP packet onto the network. iC modules that receive this packet will reply with various descriptors such as MAC address, serial number, and location. A function call to strcpy within the CRC validation logic of these UDP packets is vulnerable to a stack-based buffer overflow.

The UDP packet is composed of a set of text fields, delimited by semi-colons and terminated with a CRC value. The CRC is represented as the ASCII-encoded decimal representation of the CRC. For example, if the calculated CRC of the payload is 0xA7CF then the UDP packet will be terminated with the string “42959”.

The following chunk of code is responsible for identifying the offset of the CRC field and copying it into a fixed-size buffer.

    .text:0001D178                 SUB     R3, R11, #-msg_buf
    .text:0001D17C                 MOV     R0, R3          ; s
    .text:0001D180                 MOV     R1, #0x3B ; ';' ; c
    .text:0001D184                 BL      strrchr                                   
    .text:0001D188                 STR     R0, [R11,#end_of_data]					[1] v2 = strrchr(msg, ';')  // Find the last 
    .text:0001D18C                 LDR     R3, [R11,#end_of_data]
    .text:0001D190                 ADD     R2, R3, #1
    .text:0001D194                 STR     R2, [R11,#end_of_data] 					[2] end_of_data = v2 + 1 
    .text:0001D198                 CMP     R3, #0 									[3] if ( !v2 ) { return 1 }
    .text:0001D19C                 BEQ     loc_1D23C
    .text:0001D1A0                 SUB     R3, R11, #-input_crc_str 				[4] char input_crc_str[8]
    .text:0001D1A4                 MOV     R0, R3          ; s
    .text:0001D1A8                 MOV     R1, #0          ; c
    .text:0001D1AC                 MOV     R2, #8          ; n
    .text:0001D1B0                 BL      memset 									[4] memset(input_crc_str, 0, 8)
    .text:0001D1B4                 SUB     R3, R11, #-input_crc_str
    .text:0001D1B8                 MOV     R0, R3          ; dest
    .text:0001D1BC                 LDR     R1, [R11,#end_of_data] ; src
    .text:0001D1C0                 BL      strcpy 									[5] strcpy(input_crc_str, end_of_data)
    

The function identifies the CRC field by searching for the last semi-colon in the packet and then moving the pointer forward one byte. This is referred to in the code as end_of_data but may also be thought of as start_of_crc. The software allocates an 8-byte character array, called input_crc_str, on the stack and then will strcpy the CRC into input_crc_str. The call to strcpy is unbounded and no validation occurs to ensure the data following the last semi-colon is appropriately sized.

Therefore, supplying a UDP packet whose CRC field is sufficiently longer than expected will cause a straightforward buffer overflow. This overflow directly leads to attacker control of the program counter, which may be seen in the debugger output below.

**Crash Information**

    Thread 2 "cma" received signal SIGSEGV, Segmentation fault.
    0x4d4d4d4c in ?? ()
    ──────────────────────────────────────────────────────────────────────────────────────────────── registers ────
    $r0  : 0x1       
    $r1  : 0x0       
    $r2  : 0x6b251d4c
    $r3  : 0x1       
    $r4  : 0x0       
    $r5  : 0xb636b6b0  →  "eth0"
    $r6  : 0x0       
    $r7  : 0x152     
    $r8  : 0xbefffbe0  →  0xb6ff86d0  →  0xb6ff8db8  →  0x00000001
    $r9  : 0xb6ff86d0  →  0xb6ff8db8  →  0x00000001
    $r10 : 0xb636c460  →  0x00000001
    $r11 : 0x4d4d4d4d ("MMMM"?)
    $r12 : 0xa       
    $sp  : 0xb636b6a0  →  0xb636b700  →  0x00000000
    $lr  : 0x0001d22c  →  <check_udp_crc+248> mov r3,  #1
    $pc  : 0x4d4d4d4c ("LMMM"?)
    $cpsr: [negative ZERO CARRY overflow interrupt fast THUMB]
    ─────────────────────────────────────────────────────────────────────────────────────────── code:arm:THUMB ────
    [!] Cannot disassemble from $PC
    [!] Cannot access memory at address 0x4d4d4d4c
    ────────────────────────────────────────────────────────────────────────────────────────────────────────────────
    

**Timeline**

2021-08-17 - Vendor Disclosure  
2021-11-10 - Talos granted disclosure extension  
2021-12-13 - Vendor patched  
2021-12-15 - Talos tested patch  
2021-12-20 - Public Release

Discovered by Matt Wiseman of Cisco Talos.

CVE-2021-21903: TALOS-2021-1355 || Cisco Talos Intelligence Group

A carefully crafted request body can cause a buffer overflow in the mod_lua multipart parser (r:parsebody() called from Lua scripts). The Apache httpd team is not aware of an exploit for the vulnerabilty though it might be possible to craft one. This issue affects Apache HTTP Server 2.4.51 and earlier.

CVE-2021-44790: Apache HTTP Server 2.4 vulnerabilities

vim is vulnerable to Heap-based Buffer Overflow

CVE-2021-4136: Heap-based Buffer Overflow in vim

** DISPUTED ** Buffer overflow in the array_from_pyobj function of fortranobject.c in NumPy < 1.19, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally).

CVE-2021-41496: Potential buffer-overflow from string operations in function array_from_pyobj of fortranobject.c · Issue #19000 · numpy/numpy

An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless."

Tag

#buffer_overflow