Created attachment 10436 [details] screenshot of the issue To reproduce: # nm -A -a -l -S -s --special-syms --synthetic --with-symbol-versions -D $FILE I don't get failures but it eats ~230GB of ram. # nm -V GNU nm (Gentoo git) 2.29.51.20170921
Created attachment 10437 [details] testcase
I'm inclined to think that fuzzed binaries that cause huge memory allocations are not something that the binutils project should be concerned about. Your binary says it has 3909091329 verneed entries, which on a 64-bit host are stored internally in a 64 byte struct. That's 250181845056 bytes. On my system bfd_zalloc2 (abfd=abfd@entry=0x714290, nmemb=3909091329, size=size@entry=64) fails with ENOMEM. I think that is a quite reasonable result. However, this particular case can be easily detected so I'll fix it
*** Bug 22174 has been marked as a duplicate of this bug. ***
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bd61e135492ecf624880e6b78e5fcde3c9716df6 commit bd61e135492ecf624880e6b78e5fcde3c9716df6 Author: Alan Modra <amodra@gmail.com> Date: Sun Sep 24 14:34:57 2017 +0930 PR22166, SHT_GNU_verneed memory allocation The sanity check covers the previous minimim size, plus that the size is at least enough for sh_info verneed entries. Also, since we write all verneed fields or exit with an error, there isn't any need to zero the memory allocated for verneed entries. PR 22166 * elf.c (_bfd_elf_slurp_version_tables): Test sh_info on SHT_GNU_verneed section for sanity. Don't zalloc memory for verref.
Fixed