Bug 1680660 (CVE-2019-9072) - CVE-2019-9072 binutils: excessive memory allocation in function setup_group in elf.c
Summary: CVE-2019-9072 binutils: excessive memory allocation in function setup_group i...
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2019-9072
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1680661
Blocks: 1680680
TreeView+ depends on / blocked
 
Reported: 2019-02-25 13:31 UTC by Dhananjay Arunesh
Modified: 2019-09-29 15:08 UTC (History)
13 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-03-18 21:12:31 UTC
Embargoed:


Attachments (Terms of Use)

Description Dhananjay Arunesh 2019-02-25 13:31:56 UTC
An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.32. It is an attempted excessive memory allocation in setup_group in elf.c.

Reference:
https://sourceware.org/bugzilla/show_bug.cgi?id=24232

Comment 1 Dhananjay Arunesh 2019-02-25 13:32:14 UTC
Created binutils tracking bugs for this issue:

Affects: fedora-all [bug 1680661]

Comment 4 Scott Gayou 2019-03-18 21:08:56 UTC
This does not appear to be an actual issue. Yes, ASAN warns that the allocation fails, but the binutils tool handles that case correctly.

Here's a Red Hat Enterprise Linux 7 valgrind run for grins:

```
==27914== Memcheck, a memory error detector
==27914== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==27914== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==27914== Command: objdump -x poc
==27914== 
objdump: poc: corrupt size field in group section header: 0x6072740080
objdump: poc: no valid group sections found
objdump: poc: no group info for section 
objdump: poc: Bad value
==27914== 
==27914== HEAP SUMMARY:
==27914==     in use at exit: 19,620 bytes in 10 blocks
==27914==   total heap usage: 72 allocs, 62 frees, 31,164 bytes allocated
==27914== 
==27914== LEAK SUMMARY:
==27914==    definitely lost: 0 bytes in 0 blocks
==27914==    indirectly lost: 0 bytes in 0 blocks
==27914==      possibly lost: 0 bytes in 0 blocks
==27914==    still reachable: 19,620 bytes in 10 blocks
==27914==         suppressed: 0 bytes in 0 blocks
==27914== Rerun with --leak-check=full to see details of leaked memory
==27914== 
==27914== For counts of detected and suppressed errors, rerun with: -v
==27914== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
```

Comment 5 Scott Gayou 2019-03-18 21:11:05 UTC
Red Hat Enterprise Linux 6 (objdump version 2.20.51.0.2-5.48.el6 20100205) is slightly different, but still looks to process the file "correctly" -- i.e., no memory corruption, no impact to confidentiality, integrity, or availability.

```
valgrind objdump -x poc
==27815== Memcheck, a memory error detector
==27815== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==27815== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==27815== Command: objdump -x poc
==27815== 
BFD: poc: Corrupt size field in group section header: 0x6072740080
objdump: poc: Bad value
==27815== 
==27815== HEAP SUMMARY:
==27815==     in use at exit: 0 bytes in 0 blocks
==27815==   total heap usage: 20 allocs, 20 frees, 123,610 bytes allocated
==27815== 
==27815== All heap blocks were freed -- no leaks are possible
==27815== 
==27815== For counts of detected and suppressed errors, rerun with: -v
==27815== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 6)
```


Note You need to log in before you can comment on or make changes to this bug.