Fedora Account System
Red Hat Associate
Red Hat Customer
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 _bfd_elf_slurp_version_tables in elf.c. Reference: https://sourceware.org/bugzilla/show_bug.cgi?id=24233
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.