Created attachment 10436 [details]
screenshot of the issue
# 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) 18.104.22.16870921
Created attachment 10437 [details]
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 <firstname.lastname@example.org>:
Author: Alan Modra <email@example.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.
* elf.c (_bfd_elf_slurp_version_tables): Test sh_info on
SHT_GNU_verneed section for sanity. Don't zalloc memory for