This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Commit: PR 22508: Objdump: check reloc count before allocating memory.
- From: Nick Clifton <nickc at redhat dot com>
- To: binutils at sourceware dot org
- Date: Wed, 29 Nov 2017 12:40:15 +0000
- Subject: Commit: PR 22508: Objdump: check reloc count before allocating memory.
- Authentication-results: sourceware.org; auth=none
Hi Guys,
I am checking in the patch below to stop objdump from attempting to
allocate a huge chunk of memory when dumping relocs from a corrupt
COFF/PE binary and running in a 32-bit environment.
Cheers
Nick
PS. I am wondering if it would be better to catch this kind of problem
earlier, say in the ...get_reloc_upper_bound() functions, but I am not
sure if that would break something. Need to think more about it.
binutils/ChangeLog
2017-11-29 Nick Clifton <nickc@redhat.com>
PR 22508
* objdump.c (dump_relocs_in_section): Also check the section's
relocation count to make sure that it is reasonable before
attempting to allocate space for the relocs.
diff --git a/binutils/objdump.c b/binutils/objdump.c
index 40b4acf49f..e7d91e8d57 100644
--- a/binutils/objdump.c
+++ b/binutils/objdump.c
@@ -3427,7 +3427,16 @@ dump_relocs_in_section (bfd *abfd,
}
if ((bfd_get_file_flags (abfd) & (BFD_IN_MEMORY | BFD_LINKER_CREATED)) == 0
- && (ufile_ptr) relsize > bfd_get_file_size (abfd))
+ && (((ufile_ptr) relsize > bfd_get_file_size (abfd))
+ /* Also check the section's reloc count since if this is negative
+ (or very large) the computation in bfd_get_reloc_upper_bound
+ may have resulted in returning a small, positive integer.
+ See PR 22508 for a reproducer.
+
+ Note - we check against file size rather than section size as
+ it is possible for there to be more relocs that apply to a
+ section than there are bytes in that section. */
+ || (section->reloc_count > bfd_get_file_size (abfd))))
{
printf (" (too many: 0x%x)\n", section->reloc_count);
bfd_set_error (bfd_error_file_truncated);