Bug 22166

Summary: big memory allocation failure
Product: binutils Reporter: Agostino Sarubbo <ago>
Component: binutilsAssignee: Alan Modra <amodra>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P2    
Version: 2.30   
Target Milestone: 2.30   
Host: Target:
Build: Last reconfirmed: 2017-09-23 00:00:00
Attachments: screenshot of the issue
testcase

Description Agostino Sarubbo 2017-09-21 12:47:50 UTC
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
Comment 1 Agostino Sarubbo 2017-09-21 12:49:00 UTC
Created attachment 10437 [details]
testcase
Comment 2 Alan Modra 2017-09-23 05:03:23 UTC
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
Comment 3 Alan Modra 2017-09-23 08:45:27 UTC
*** Bug 22174 has been marked as a duplicate of this bug. ***
Comment 4 cvs-commit@gcc.gnu.org 2017-09-24 06:49:49 UTC
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.
Comment 5 Alan Modra 2017-09-24 06:56:26 UTC
Fixed