* [Bug libelf/21301] New: memory allocation failure in __libelf_decompress @ 2017-03-24 9:20 ago at gentoo dot org 2017-03-24 13:53 ` [Bug libelf/21301] " mjw at redhat dot com ` (2 more replies) 0 siblings, 3 replies; 4+ messages in thread From: ago at gentoo dot org @ 2017-03-24 9:20 UTC (permalink / raw) To: elfutils-devel https://sourceware.org/bugzilla/show_bug.cgi?id=21301 Bug ID: 21301 Summary: memory allocation failure in __libelf_decompress Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libelf Assignee: unassigned at sourceware dot org Reporter: ago at gentoo dot org CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 9938 --> https://sourceware.org/bugzilla/attachment.cgi?id=9938&action=edit stacktrace AN IMPORTANT NOTE: as the stacktrace said this can be a false positive, so if you think that there isn't anything to fix, feel free to close. On elfutils-0.168: # eu-readelf -a $FILE ==1927==WARNING: AddressSanitizer failed to allocate 0x280065041580 bytes #5 0x7f85fb88dd1e in __libelf_decompress /tmp/portage/dev-libs/elfutils-0.168/work/elfutils-0.168/libelf/elf_compress.c:214 Compiled with: gcc-6.3.0 Reproducer: https://github.com/asarubbo/poc/blob/master/00227-elfutils-memallocfailure Stacktrace attached. -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libelf/21301] memory allocation failure in __libelf_decompress 2017-03-24 9:20 [Bug libelf/21301] New: memory allocation failure in __libelf_decompress ago at gentoo dot org @ 2017-03-24 13:53 ` mjw at redhat dot com 2017-04-03 21:54 ` mark at klomp dot org 2017-04-10 7:31 ` ago at gentoo dot org 2 siblings, 0 replies; 4+ messages in thread From: mjw at redhat dot com @ 2017-03-24 13:53 UTC (permalink / raw) To: elfutils-devel https://sourceware.org/bugzilla/show_bug.cgi?id=21301 Mark Wielaard <mjw at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjw at redhat dot com --- Comment #1 from Mark Wielaard <mjw at redhat dot com> --- That is slightly tricky. We do have to trust the input data to give us the expected output size. We won't know if that was correct till we decompressed the input. We do actually double check the given output size was correct at the end of the decompression. But we could catch some really bogus sizes before trying to allocate a giant amount of memory and decompressing stuff for nothing (like in this case). diff --git a/libelf/elf_compress.c b/libelf/elf_compress.c index dac0ac6..711be59 100644 --- a/libelf/elf_compress.c +++ b/libelf/elf_compress.c @@ -211,6 +211,15 @@ void * internal_function __libelf_decompress (void *buf_in, size_t size_in, size_t size_out) { + /* Catch highly unlikely compression ratios so we don't allocate + some giant amount of memory for nothing. The max compression + factor 1032:1 comes from http://www.zlib.net/zlib_tech.html */ + if (unlikely (size_out / 1032 > size_in)) + { + __libelf_seterrno (ELF_E_INVALID_DATA); + return NULL; + } + void *buf_out = malloc (size_out); if (unlikely (buf_out == NULL)) { -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libelf/21301] memory allocation failure in __libelf_decompress 2017-03-24 9:20 [Bug libelf/21301] New: memory allocation failure in __libelf_decompress ago at gentoo dot org 2017-03-24 13:53 ` [Bug libelf/21301] " mjw at redhat dot com @ 2017-04-03 21:54 ` mark at klomp dot org 2017-04-10 7:31 ` ago at gentoo dot org 2 siblings, 0 replies; 4+ messages in thread From: mark at klomp dot org @ 2017-04-03 21:54 UTC (permalink / raw) To: elfutils-devel https://sourceware.org/bugzilla/show_bug.cgi?id=21301 Mark Wielaard <mark at klomp dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |mark at klomp dot org Resolution|--- |FIXED --- Comment #2 from Mark Wielaard <mark at klomp dot org> --- commit 8dcc4bf791469a32c3a09ebcc23b309bf75c795f Author: Mark Wielaard <mark@klomp.org> Date: Fri Mar 24 15:06:04 2017 +0100 libelf: Check compression ratio before trying to allocate output buffer. The maximum compression factor (http://www.zlib.net/zlib_tech.html) is 1032:1. Add a sanity check for that before trying to allocate lots of memory and trying to decompress lots of bogus data. https://sourceware.org/bugzilla/show_bug.cgi?id=21301 Signed-off-by: Mark Wielaard <mark@klomp.org> -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libelf/21301] memory allocation failure in __libelf_decompress 2017-03-24 9:20 [Bug libelf/21301] New: memory allocation failure in __libelf_decompress ago at gentoo dot org 2017-03-24 13:53 ` [Bug libelf/21301] " mjw at redhat dot com 2017-04-03 21:54 ` mark at klomp dot org @ 2017-04-10 7:31 ` ago at gentoo dot org 2 siblings, 0 replies; 4+ messages in thread From: ago at gentoo dot org @ 2017-04-10 7:31 UTC (permalink / raw) To: elfutils-devel https://sourceware.org/bugzilla/show_bug.cgi?id=21301 --- Comment #3 from Agostino Sarubbo <ago at gentoo dot org> --- Mitre assigned CVE-2017-7609 to this issue. -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-04-10 7:31 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-24 9:20 [Bug libelf/21301] New: memory allocation failure in __libelf_decompress ago at gentoo dot org 2017-03-24 13:53 ` [Bug libelf/21301] " mjw at redhat dot com 2017-04-03 21:54 ` mark at klomp dot org 2017-04-10 7:31 ` ago at gentoo dot org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).