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.