#12 Heap-based Buffer Overflow in the parse_line() function

[Frederic Cambus]

Heap-based Buffer Overflow in the parse_line() function

Hi,

While fuzzing mcpp with American Fuzzy Lop, I found a Heap-based
Buffer Overflow in the parse_line() function, in support.c L1748.

Attaching a reproducer, issue can be reproduced by running:

mcpp test-parse_line

Regards,
Frederic Cambus.

=================================================================
==13892==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6310000287ff at pc 0x000000559f06 bp 0x7fff9884d810 sp 0x7fff9884d808
READ of size 1 at 0x6310000287ff thread T0
#0 0x559f05 in parse_line /home/fcambus/mcpp-2.7.2/src/support.c:1748:38
#1 0x550214 in get_ch /home/fcambus/mcpp-2.7.2/src/support.c:1580:13
#2 0x513c1b in mcpp_main /home/fcambus/mcpp-2.7.2/src/main.c:626:17
#3 0x513396 in main /home/fcambus/mcpp-2.7.2/src/main.c:421:5
#4 0x7fc025cfab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#5 0x41a149 in _start (/home/fcambus/tmp-mcpp/mcpp+0x41a149)

0x6310000287ff is located 1 bytes to the left of 65536-byte region [0x631000028800,0x631000038800)
allocated by thread T0 here:
#0 0x4da000 in malloc (/home/fcambus/tmp-mcpp/mcpp+0x4da000)
#1 0x556ae4 in xmalloc /home/fcambus/mcpp-2.7.2/src/support.c:2336:28
#2 0x558e9f in parse_line /home/fcambus/mcpp-2.7.2/src/support.c:1666:17
#3 0x550214 in get_ch /home/fcambus/mcpp-2.7.2/src/support.c:1580:13
#4 0x513c1b in mcpp_main /home/fcambus/mcpp-2.7.2/src/main.c:626:17
#5 0x513396 in main /home/fcambus/mcpp-2.7.2/src/main.c:421:5
#6 0x7fc025cfab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/fcambus/mcpp-2.7.2/src/support.c:1748:38 in parse_line
Shadow bytes around the buggy address:
0x0c627fffd0a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c627fffd0b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c627fffd0c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c627fffd0d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c627fffd0e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c627fffd0f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]
0x0c627fffd100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c627fffd110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c627fffd120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c627fffd130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c627fffd140: 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
==13892==ABORTING

[John Brandwood]

For anyone looking at this thread currently ... this was fixed back in 2019 by the Debian maintainers with 03-gniibe-fix-11.patch

I have applied a slightly modified version of that patch here ...
https://github.com/jbrandwood/mcpp/commit/f6f6e7363101e4fd948bea5626d6ba74efa45b73