This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: pr21665
- From: Nick Clifton <nickc at redhat dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Hans-Peter Nilsson <hp at bitrange dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Fri, 30 Jun 2017 11:03:25 +0100
- Subject: Re: pr21665
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nickc at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7C52C1E2F0
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7C52C1E2F0
- References: <20170630082308.GE25242@bubble.grove.modra.org>
Hi Alan,
> Nick, your commit cfd14a500 for pr21665 blows up mmo, and if there
> were tests for it, probably other encoded formats like ihex and srec.
>
> mmix +FAIL: ld-mmix/getaa12b
You are right. Sorry for not catching this myself when I originally created
the patch.
I am going to check in the patch below as a workaround for this problem. It
fixes the MMIX failures and still catches the problematic binary in PR 21665,
but it also places an arbitrary upper limit of 2Gb on the size of a section
that can be disassembled. I think that this is a reasonable limit for now,
although if not, I am sure that someone will complain. (Unless you happen
to know of a way to determine beforehand whether a call to xmalloc will fail ?)
Cheers
Nick
binutils/ChangeLog
2017-06-30 Nick Clifton <nickc@redhat.com>
PR binutils/21665
* objdump.c (disassemble_section): Move check for an overlarge
section to just before the allocation of memory. Do not check
section size against file size, but instead use an arbitrary 2Gb
limit. Issue a warning message if the section is too big.
diff --git a/binutils/objdump.c b/binutils/objdump.c
index 0b72818..d70882e 100644
--- a/binutils/objdump.c
+++ b/binutils/objdump.c
@@ -2114,7 +2114,7 @@ disassemble_section (bfd *abfd, asection *section, void *inf)
return;
datasize = bfd_get_section_size (section);
- if (datasize == 0 || datasize >= (bfd_size_type) bfd_get_file_size (abfd))
+ if (datasize == 0)
return;
if (start_address == (bfd_vma) -1
@@ -2178,6 +2178,29 @@ disassemble_section (bfd *abfd, asection *section, void *inf)
}
rel_ppend = rel_pp + rel_count;
+ /* PR 21665: Check for overlarge datasizes.
+ Note - we used to check for "datasize > bfd_get_file_size (abfd)" but
+ this fails when using compressed sections or compressed file formats
+ (eg MMO, tekhex).
+
+ The call to xmalloc below will fail if too much memory is requested,
+ which will catch the problem in the normal use case. But if a memory
+ checker is in use, eg valgrind or sanitize, then an exception will
+ be still generated, so we try to catch the problem first.
+
+ Unfortunately there is no simple way to determine how much memory can
+ be allocated by calling xmalloc. So instead we use a simple, arbitrary
+ limit of 2Gb. Hopefully this should be enough for most users. If
+ someone does start trying to disassemble sections larger then 2Gb in
+ size they will doubtless complain and we can increase the limit. */
+#define MAX_XMALLOC (1024 * 1024 * 1024 * 2UL) /* 2Gb */
+ if (datasize > MAX_XMALLOC)
+ {
+ non_fatal (_("Reading section %s failed because it is too big (%#lx)"),
+ section->name, (unsigned long) datasize);
+ return;
+ }
+
data = (bfd_byte *) xmalloc (datasize);
if (!bfd_get_section_contents (abfd, section, data, 0, datasize))