bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/29169] New: Invalid read during processing of program inpu


From: address@hidden
Subject: [Bug binutils/29169] New: Invalid read during processing of program input via objdump
Date: Mon, 23 May 2022 17:14:14 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=29169

            Bug ID: 29169
           Summary: Invalid read during processing of program input via
                    objdump
           Product: binutils
           Version: 2.38
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: nils_bars@t-online.de
  Target Milestone: ---

Created attachment 14111
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14111&action=edit
Reproduction scripts and bug triggering input.

Invalid read during processing of program input

# Description
During processing of the attached input file via
```
objdump -a -C -g -D -f -F -h -l -p -r -R -s -S -G -t --dynamic-syms
--special-syms -x /testcase
```
an out-of-bounds read is triggered. This possibly opens up
other attack vectors to an attacker if files from untrusted sources are
processed.

For reproduction of the crash, I attach a Docker container. Run
./build_upstream.sh to build the Docker image and ./reproduce-upstream.sh to
reproduce the crash. 
If you need further details, please do not hesitate to ask.

# Version
The input was tested on branch binutils-2_38 of
git://sourceware.org/git/binutils-gdb.git commit
20756b0fbe065a84710aa38f2457563b57546440.

# Valgrind
==1== Memcheck, a memory error detector
==1== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==1== Command: /binutils-gdb/binutils/objdump -a -C -g -D -f -F -h -l -p -r -R
-s -S -G -t --dynamic-syms --special-syms -x /testcase
==1== 
/binutils-gdb/binutils/objdump: warning: /testcase has a section extending past
end of file

/testcase:     file format elf32-little
/testcase
architecture: UNKNOWN!, flags 0x00000010:
HAS_SYMS
start address 0x020210ff

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .gdb_index    00000100  00000000  00000000  00000034  2**0
                  CONTENTS, READONLY, DEBUGGING, EXCLUDE
SYMBOL TABLE:
no symbols


DYNAMIC SYMBOL TABLE:
00000100      D  *ABS*  ff000000 0xff (null)
00e70000 l    D  *ABS*  0000b400 0x16 (null)
00000000 l    D  *ABS*  00bc0060 (null)
ffffff00      D  *UND*  000000f4 0x80 (null)
0000000b      D  *UND*  f742c000 0x7f 
00800000 l    D  *UND*  00bb4330 (null)
00000000 l    D  *UND*  00000005 (null)
74727473      D  *ABS*  2e006261 0x64 (null)
00000078 g    D  *ABS*  ffe40019 (null)
040000ff l    D  .gdb_index     00000000 0x60 (null)
7fff0000 l    D  *UND*  000000fa (null)
0000000b l    D  *UND*  de000000 (null)
00000100 l    D  *UND*  00000000 (null)
00000010 l    d  *UND*  00000001 (null)
01000000      D  *UND*  000000b4 (null)


Contents of section .gdb_index:  (Starting at file offset: 0x34)
 0000 04000000 00000000 8f000000 00010000  ................
 0010 00010000 00010000 000000ff fffff600  ................
 0020 00000080 0000e700 00b40000 0016faff  ................
 0030 00000400 00000000 6000bc00 00001600  ........`.......
 0040 26000100 00ffffff f4000000 ff800000  &...............
 0050 00000000 0b000000 00c042f7 ff7f0000  ..........B.....
 0060 00d00000 00008000 3043bb00 00000000  ........0C......
 0070 05000000 00000000 05000000 00000000  ................
 0080 002e7368 73747274 6162002e 6764625f  ..shstrtab..gdb_
 0090 696e6465 78000000 1900e4ff 100000e3  index...........
 00a0 000016fa ff000004 00000000 00600100  .............`..
 00b0 22000000 0000ff7f fa000000 00000000  "...............
 00c0 0b000000 0b000000 000000de 00000000  ................
 00d0 34000000 00010000 00000000 08000000  4...............
 00e0 01000000 10000000 01000000 03000000  ................
 00f0 00008000 00000001 b4000000 16000000  ................
/binutils-gdb/binutils/objdump: can't disassemble for architecture UNKNOWN!

Contents of the .gdb_index section (loaded from /testcase):

Version 4
/binutils-gdb/binutils/objdump: Warning: Version 4 does not support case
insensitive lookups.
/binutils-gdb/binutils/objdump: Warning: Version 5 does not include inlined
functions.
/binutils-gdb/binutils/objdump: Warning: Version 6 does not include symbol
attributes.
==1== Invalid read of size 8
==1==    at 0x1B2AC8: byte_get_little_endian (elfcomm.c:162)
==1==    by 0x177BB1: display_gdb_index (dwarf.c:10157)
==1==    by 0x173EE3: dump_dwarf_section (objdump.c:3982)
==1==    by 0x1F10D6: bfd_map_over_sections (section.c:1383)
==1==    by 0x16CB53: dump_dwarf (objdump.c:4020)
==1==    by 0x16FAC8: dump_bfd (objdump.c:5184)
==1==    by 0x16FCEC: display_object_bfd (objdump.c:5221)
==1==    by 0x16FCEC: display_any_bfd (objdump.c:5311)
==1==    by 0x169C57: display_file (objdump.c:5332)
==1==    by 0x169C57: display_file (objdump.c:5315)
==1==    by 0x169C57: main (objdump.c:5700)
==1==  Address 0x4a6ae9f is 255 bytes inside a block of size 257 alloc'd
==1==    at 0x483B7F3: malloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1==    by 0x2AC518: xmalloc (xmalloc.c:149)
==1==    by 0x173A1F: load_specific_debug_section.part.0 (objdump.c:3781)
==1==    by 0x173E6A: load_specific_debug_section (objdump.c:3761)
==1==    by 0x173E6A: dump_dwarf_section (objdump.c:3979)
==1==    by 0x1F10D6: bfd_map_over_sections (section.c:1383)
==1==    by 0x16CB53: dump_dwarf (objdump.c:4020)
==1==    by 0x16FAC8: dump_bfd (objdump.c:5184)
==1==    by 0x16FCEC: display_object_bfd (objdump.c:5221)
==1==    by 0x16FCEC: display_any_bfd (objdump.c:5311)
==1==    by 0x169C57: display_file (objdump.c:5332)
==1==    by 0x169C57: display_file (objdump.c:5315)
==1==    by 0x169C57: main (objdump.c:5700)
==1== 

CU table:
[  0] 0x4 - 0x10000000092
[  1] 0x10000000100 - 0xf700ffff0000ff
[  2] 0xe7000080000000 - 0xe116008000b3ff
[  3] 0x40000 - 0x16000000c0005f
[  4] 0xffffff0000010026 - 0x7fff00010119
[  5] 0xb00000000 - 0x800af742bfff
[  6] 0x8000000000d000 - 0x80000000bc132f
[  7] 0x5 - 0x9
[  8] 0x7472747368732e00 - 0xd3d4d8da96739060

TU table:
[  0] 0x7865646e695f 0x10ffe4001900 0000fffa160000e3 
[  1] 0x160000000000004 0xff00000000002200 000000000000fa7f 
[  2] 0xb0000000b00 0xde00000000 0001000000003400 
[  3] 0x80000000000 0x100000000100 0000030000000100 
[  4] 0x80000000 0x16000000b401 0000000000000000 

Address table:

Symbol table:
==1== 
==1== HEAP SUMMARY:
==1==     in use at exit: 120 bytes in 1 blocks
==1==   total heap usage: 30 allocs, 29 frees, 132,779 bytes allocated
==1== 
==1== LEAK SUMMARY:
==1==    definitely lost: 0 bytes in 0 blocks
==1==    indirectly lost: 0 bytes in 0 blocks
==1==      possibly lost: 0 bytes in 0 blocks
==1==    still reachable: 120 bytes in 1 blocks
==1==         suppressed: 0 bytes in 0 blocks
==1== Rerun with --leak-check=full to see details of leaked memory
==1== 
==1== For lists of detected and suppressed errors, rerun with: -s
==1== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]