Bug 22166 - big memory allocation failure
Summary: big memory allocation failure
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.30
: P2 normal
Target Milestone: 2.30
Assignee: Alan Modra
: 22174 (view as bug list)
Depends on:
Reported: 2017-09-21 12:47 UTC by Agostino Sarubbo
Modified: 2017-09-24 06:56 UTC (History)
0 users

See Also:
Last reconfirmed: 2017-09-23 00:00:00

screenshot of the issue (50.13 KB, image/png)
2017-09-21 12:47 UTC, Agostino Sarubbo
testcase (10.84 KB, application/x-executable)
2017-09-21 12:49 UTC, Agostino Sarubbo

Note You need to log in before you can comment on or make changes to this bug.
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)
Comment 1 Agostino Sarubbo 2017-09-21 12:49:00 UTC
Created attachment 10437 [details]
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 Sourceware Commits 2017-09-24 06:49:49 UTC
The master branch has been updated by Alan Modra <amodra@sourceware.org>:


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
Comment 5 Alan Modra 2017-09-24 06:56:26 UTC