Open clesmian opened 11 months ago
Thank you for reporting this. I'll try to fix it as as soon as possible.
I've fixed it by recent patches.
4ff53b1e5abbe00ff4e558b779ecc388877e2bd1 partially fixes the issue.
This file poc2.txt still leads to a heap use-after-free.
poc2.txt:0:0: warning -- no end of line at file end
=================================================================
==631532==ERROR: AddressSanitizer: heap-use-after-free on address 0x608000000020 at pc 0x5637c40eda59 bp 0x7f6ec6dfe040 sp 0x7f6ec6dfe030
READ of size 8 at 0x608000000020 thread T1
#0 0x5637c40eda58 in get_next_pptoken_1 c2mir/c2mir.c:1530
#1 0x5637c40fbf91 in get_next_pptoken c2mir/c2mir.c:1712
#2 0x5637c40fbf91 in processing c2mir/c2mir.c:3560
#3 0x5637c414f533 in pre c2mir/c2mir.c:3801
#4 0x5637c414f533 in c2mir_compile c2mir/c2mir.c:13468
#5 0x5637c4152d6a in compile c2mir/c2mir-driver.c:498
#6 0x7f6eca3e2608 in start_thread /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_create.c:477
#7 0x7f6eca307132 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x11f132)
0x608000000020 is located 0 bytes inside of 88-byte region [0x608000000020,0x608000000078)
freed by thread T1 here:
#0 0x7f6eca65f40f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:122
#1 0x5637c40e80ca in free_stream c2mir/c2mir.c:894
#2 0x5637c40e80ca in get_next_pptoken_1 c2mir/c2mir.c:1529
previously allocated by thread T1 here:
#0 0x7f6eca65f808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x5637c4077b58 in new_stream c2mir/c2mir.c:905
#2 0x5637c4077b58 in add_stream c2mir/c2mir.c:926
Thread T1 created by T0 here:
#0 0x7f6eca58c815 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cc:208
#1 0x5637c40676f8 in init_compilers c2mir/c2mir-driver.c:540
#2 0x5637c40676f8 in main c2mir/c2mir-driver.c:656
SUMMARY: AddressSanitizer: heap-use-after-free c2mir/c2mir.c:1530 in get_next_pptoken_1
Shadow bytes around the buggy address:
0x0c107fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c107fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c107fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c107fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c107fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c107fff8000: fa fa fa fa[fd]fd fd fd fd fd fd fd fd fd fd fa
0x0c107fff8010: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
0x0c107fff8020: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
0x0c107fff8030: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 02 fa
0x0c107fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c107fff8050: 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
==631532==ABORTING
Sorry for the delay. I fixed this PR in my recent commit https://github.com/vnmakarov/mir/commit/55ec6a7eaf33f6fc6d6a6c71fdec5c6abade972d
This has been found while fuzzing c2m compiled from commit d51b45f6c76d2ca03a5b2e1968c195b867eaed30 with ASAN.
Running
c2m poc.txt
with an input file containing#define\
(without trailing newline) leads to a hang. Compilation with ASAN shows that it the underlying problem is a heap-use-after-free inget_next_pptoken_1
. This also happens with#ifdef
or#include
poc.txt
ASAN Output