Bug 21301

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))
     {

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>

Mitre assigned CVE-2017-7609 to this issue.