I find there is use after free issue in multithread processing in stream.c in the newest master branch 597be1f.
The reason is that the buffer is unchecked during a multithread stream read.
Here is the detailed explanation:
The high-level reason is similar to issue #164, but the program behavior/path is different.
To reproduce, run
lrzip -t uaf-stream546.lrz
Since it is a problem in the multithread program, you might need to run this command multiple times to trigger.
Decompressing...
Bad checksum: 0x5b496f91 - expected: 0x2000210c
Segmentation fault
This is the trace reported by ASAN:
==163048==ERROR: AddressSanitizer: heap-use-after-free on address 0x62000000f0e0 at pc 0x000000440f8c bp 0x7ff7bdffdd70 sp 0x7ff7bdffdd60
Fatal error - exiting
WRITE of size 8 at 0x62000000f0e0 thread T3
#0 0x440f8b in lzma_decompress_buf ../stream.c:546
#1 0x440f8b in ucompthread ../stream.c:1526
#2 0x7ff7c1d366b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
#3 0x7ff7c116841c in clone (/lib/x86_64-linux-gnu/libc.so.6+0x10741c)
0x62000000f0e0 is located 96 bytes inside of 3936-byte region [0x62000000f080,0x62000000ffe0)
freed by thread T0 here:
#0 0x7ff7c263032a in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9832a)
#1 0x454a42 in close_stream_in ../stream.c:1870
previously allocated by thread T0 here:
#0 0x7ff7c26307fa in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x987fa)
#1 0x44c8f0 in open_stream_in ../stream.c:1080
Thread T3 created by T0 here:
#0 0x7ff7c25ce1e3 in pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x361e3)
#1 0x4516f3 in create_pthread ../stream.c:133
#2 0x4516f3 in fill_buffer ../stream.c:1699
#3 0x4516f3 in read_stream ../stream.c:1786
SUMMARY: AddressSanitizer: heap-use-after-free ../stream.c:546 lzma_decompress_buf
Shadow bytes around the buggy address:
0x0c407fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c407fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c407fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c407fff9df0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c407fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c407fff9e10: fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd
0x0c407fff9e20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c407fff9e30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c407fff9e40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c407fff9e50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c407fff9e60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
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
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
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
==163048==ABORTING
Hi, there.
I find there is use after free issue in multithread processing in stream.c in the newest master branch 597be1f. The reason is that the buffer is unchecked during a multithread stream read. Here is the detailed explanation:
The high-level reason is similar to issue #164, but the program behavior/path is different.
To reproduce, run
Since it is a problem in the multithread program, you might need to run this command multiple times to trigger.
POC (unzip first): uaf-stream546.lrz.zip
Here is the output from the terminal:
This is the trace reported by ASAN: