Bug 1680662 (CVE-2019-9073)
Summary: | CVE-2019-9073 binutils: excessive memory allocation in function _bfd_elf_slurp_version_tables in elf.c | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Dhananjay Arunesh <darunesh> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | unspecified | CC: | abhgupta, aoliva, dbaker, dvlasenk, fweimer, jakub, jokerman, law, mprchlik, nickc, ohudlick, sthangav, trankin |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-03-19 14:53:10 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1680663 | ||
Bug Blocks: | 1680680 |
Description
Dhananjay Arunesh
2019-02-25 13:36:57 UTC
Created binutils tracking bugs for this issue: Affects: fedora-all [bug 1680663] This initially looks like nothing. Trying to dive in a bit: ``` │1525 _bfd_elf_print_private_bfd_data (bfd *abfd, void *farg) │ │1526 { │ │1527 FILE *f = (FILE *) farg; │ │1528 Elf_Internal_Phdr *p; │ │1529 asection *s; │ │1530 bfd_byte *dynbuf = NULL; │ │1531 │ │1532 p = elf_tdata (abfd)->phdr; │ >│1533 if (p != NULL) │ │1534 { ``` p is null in this case. ``` (gdb) print p $3 = (Elf_Internal_Phdr *) 0x0 ``` Later drop into here: ``` >│1709 if ((elf_dynverdef (abfd) != 0 && elf_tdata (abfd)->verdef == NULL) │ │1710 || (elf_dynverref (abfd) != 0 && elf_tdata (abfd)->verref == NULL)) │ │1711 { │ │1712 if (! _bfd_elf_slurp_version_tables (abfd, FALSE)) │ │1713 return FALSE; │ │1714 } ``` Keep following into _bfd_elf_slurp_version_tables and we get: ``` >│8109 contents = (bfd_byte *) bfd_malloc (hdr->sh_size); │ │8110 if (contents == NULL) │ │8111 goto error_return_verdef; ``` (gdb) print hdr->sh_size $7 = 1099511594752 My system is unable to malloc 1.09 terabytes of ram, so we ``` │8288 error_return: │ >│8289 if (contents != NULL) │ │8290 free (contents); │ │8291 return FALSE; │ │8292 } ``` return false. This all looks correct, a malloc fails and is checked, thus returns. Upstream looks like they added a warning letting the user know that a function silently failed and presumably didn't print specific data, but I don't see that as a security issue. Valgrind for grins. ``` valgrind objdump -x poc ==27977== Memcheck, a memory error detector ==27977== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==27977== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==27977== Command: objdump -x poc ==27977== poc: file format elf64-k1om poc architecture: k1om, flags 0x00000010: HAS_SYMS start address 0xf0ffffff03100000 Sections: Idx Name Size VMA LMA File off Algn 0 00000001 0000000000000000 0000000000000000 ffe90af8ff 2**45 CONTENTS, READONLY 1 00000000 0000000000002200 0000000000002200 00000000 2**0 CONTENTS, READONLY 2 ffffff7f00 0000000000000000 0000000000000000 deffffff00 2**48 CONTENTS, READONLY SYMBOL TABLE: no symbols ==27977== ==27977== HEAP SUMMARY: ==27977== in use at exit: 19,620 bytes in 10 blocks ==27977== total heap usage: 79 allocs, 69 frees, 67,966 bytes allocated ==27977== ==27977== LEAK SUMMARY: ==27977== definitely lost: 0 bytes in 0 blocks ==27977== indirectly lost: 0 bytes in 0 blocks ==27977== possibly lost: 0 bytes in 0 blocks ==27977== still reachable: 19,620 bytes in 10 blocks ==27977== suppressed: 0 bytes in 0 blocks ==27977== Rerun with --leak-check=full to see details of leaked memory ==27977== ==27977== For counts of detected and suppressed errors, rerun with: -v ==27977== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ``` Downgraded this to notabug, this seems to have no impact and probably doesn't need a CVE. |