Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leak when decoding LZMA #1165

Closed
rohanpadhye opened this issue Mar 28, 2019 · 6 comments

Comments

@rohanpadhye
Copy link

@rohanpadhye rohanpadhye commented Mar 28, 2019

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

This comment has been minimized.

Copy link
Contributor

@jsonn jsonn commented Mar 28, 2019

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

@rohanpadhye

This comment has been minimized.

Copy link
Author

@rohanpadhye rohanpadhye commented Mar 28, 2019

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

This comment has been minimized.

Copy link
Member

@mmatuska mmatuska commented Apr 20, 2019

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

@mmatuska mmatuska closed this in ba641f7 Apr 20, 2019
@rohanpadhye

This comment has been minimized.

Copy link
Author

@rohanpadhye rohanpadhye commented Apr 23, 2019

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

@mmatuska

This comment has been minimized.

Copy link
Member

@mmatuska mmatuska commented Apr 23, 2019

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

@rohanpadhye

This comment has been minimized.

Copy link
Author

@rohanpadhye rohanpadhye commented Apr 23, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.