Memory leak when decoding LZMA

[rohanpadhye]

I've encountered a memory leak while fuzzing libarchive. A 32-byte reproducer input is attached:
input.zip. Do not extract this zip file -- it is the fuzzed input itself.

To reproduce, build latest libarchive with ASAN (clang -fsanitize=address) and run:

$ ./bsdtar -xOf input.zip  # bsdtar compiled with ASAN
a: Invalid lzma data
bsdtar: Error exit delayed from previous errors.

=================================================================
==15753==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 96 byte(s) in 1 object(s) allocated from:
    #0 0x7f4c0b1dfb50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50)
    #1 0x7f4c0a85dced  (/lib/x86_64-linux-gnu/liblzma.so.5+0x2ced)

Indirect leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x7f4c0b1dfb50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50)
    #1 0x7f4c0a864274  (/lib/x86_64-linux-gnu/liblzma.so.5+0x9274)

SUMMARY: AddressSanitizer: 320 byte(s) leaked in 2 allocation(s).

Without ASAN, this can also be reproduced using Valgrind:

$ valgrind --leak-check=full ./bsdtar -xOf input.zip 
a: Invalid lzma data
bsdtar: Error exit delayed from previous errors.
==619== 
==619== HEAP SUMMARY:
==619==     in use at exit: 396 bytes in 4 blocks
==619==   total heap usage: 274 allocs, 270 frees, 342,257 bytes allocated
==619== 
==619== 320 (96 direct, 224 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 4
==619==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==619==    by 0x54BECED: ??? (in /lib/x86_64-linux-gnu/liblzma.so.5.2.2)
==619==    by 0x54C52E2: lzma_alone_decoder (in /lib/x86_64-linux-gnu/liblzma.so.5.2.2)
==619==    by 0x14EEAC: zipx_lzma_alone_init (archive_read_support_format_zip.c:1455)
==619==    by 0x14EEAC: zip_read_data_zipx_lzma_alone (archive_read_support_format_zip.c:1660)
==619==    by 0x14EEAC: archive_read_format_zip_read_data (archive_read_support_format_zip.c:2670)
==619==    by 0x1219BB: archive_read_data_into_fd (archive_read_data_into_fd.c:101)
==619==    by 0x114D70: read_archive (read.c:369)
==619==    by 0x1153F6: tar_mode_x (read.c:112)
==619==    by 0x113A3F: main (bsdtar.c:880)
==619== 
==619== LEAK SUMMARY:
==619==    definitely lost: 96 bytes in 1 blocks
==619==    indirectly lost: 224 bytes in 1 blocks
==619==      possibly lost: 0 bytes in 0 blocks
==619==    still reachable: 76 bytes in 2 blocks
==619==         suppressed: 0 bytes in 0 blocks
==619== Reachable blocks (those to which a pointer was found) are not shown.

[jsonn]

Yeah, it's not freeing the decoder on error.

[rohanpadhye]

Note that calling archive_read_free() does not free this memory. I tried writing my own driver based on the tutorials in the wiki (see this gist), and the leak remains even after calling archive_read_free().

For the test driver in the gist, I see the output:

entry name: a
Error reading data: Invalid lzma data

=================================================================
==27645==ERROR: LeakSanitizer: detected memory leaks
...

[mmatuska]

Thank you there is a ugly preprocessor typo in archive_read_format_zip_cleanup()!

[rohanpadhye]

Thanks for the fix! This has been assigned CVE-2019-11463 by MITRE.

[mmatuska]

@rohanpadhye This is very interesting because the zipx lzma support code was not released yet, so an affected version doesn't exist.

[rohanpadhye]

Oops. This is my bad, since I filed the report. I referenced the release date of v3.3.3 rather than the commit date. I see now that the bug appears only in 3.3.4dev. I'll request to have the CVE record amended at once.