bug-binutils
[Top][All Lists]
Advanced

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

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


From: address@hidden
Subject: [Bug binutils/29171] New: Invalid read during processing of program input causing SIGSEGV
Date: Mon, 23 May 2022 17:20:19 +0000

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

            Bug ID: 29171
           Summary: Invalid read during processing of program input
                    causing SIGSEGV
           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 14113
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14113&action=edit
Reproduction scripts and bug triggering input.

Invalid read during processing of program input causing SIGSEGV

# Description
During processing of the attached input file via
```
/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
```
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 image. Run ./build_upstream.sh
to build the Docker image and ./reproduce-upstream.sh to reproduce the crash. 
If you need further assistance, 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 0xedff04f0

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .debug_names  00000100  00001d00  00001d00  00000034  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
SYMBOL TABLE:
no symbols


DYNAMIC SYMBOL TABLE:
00000006      DO *UND*  00000002 
00050000 l    D  *UND*  00000000 
00000000 l    D  *UND*  0000ff00 
fff60000 l    D  *UND*  00000010 
3e000000      D  *ABS*  823e3e3e 0x3e (null)
a8a8a8a8 u    D  *ABS*  a8a8a8a8 0xa8 (null)
3e3e3e3e      D  *ABS*  3e3e3e3e 0x3e (null)
3e3e3e3e      df *ABS*  2e3e3e3e 0x65 (null)
0073656d l    D  *UND*  76000000 (null)
00000000 l    D  *ABS*  00000000 (null)
00000000 l    D  *UND*  0000d064 
0000000b l    D  *UND*  0000000b (null)
00000034 l    D  *UND*  00000100 (null)
00000001 l    DO *UND*  00000010 
00000000      df *UND*  00020600 (null)


Contents of section .debug_names:  (Starting at file offset: 0x34)
 1d00 7d000000 05000000 00000000 01000000  }...............
 1d10 00000000 06000000 02000000 15000000  ................
 1d20 00000000 00000500 00000000 00000000  ................
 1d30 00000000 00000000 00ff0000 00000000  ................
 1d40 00000000 0000f6ff 10000000 06000000  ................
 1d50 0d000000 0000003e 3e3e3e82 3e3e3e3e  .......>>>>.>>>>
 1d60 a8a8a8a8 a8a8a8a8 a8a8a8a8 a8a8a8a8  ................
 1d70 3e3e3e3e 3e3e3e3e 3e3e3e3e 3e3e3e3e  >>>>>>>>>>>>>>>>
 1d80 3e3e3e3e 3e3e3e3e 3e3e3e2e 64656275  >>>>>>>>>>>.debu
 1d90 675f6e61 6d657300 00000076 00000000  g_names....v....
 1da0 000015f0 00000000 00000000 0000002a  ...............*
 1db0 00000000 00000000 64d00000 00000000  ........d.......
 1dc0 00000f00 0b000000 0b000000 00000000  ................
 1dd0 001d0000 34000000 00010000 00000000  ....4...........
 1de0 00000000 01000000 10000000 01000000  ................
 1df0 03000000 00000000 00060200 b4000000  ................
/binutils-gdb/binutils/objdump: can't disassemble for architecture UNKNOWN!

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

Version 5
/binutils-gdb/binutils/objdump: Warning: Compilation unit count must be >= 1 in
.debug_names
/binutils-gdb/binutils/objdump: Error: Augmentation string:  ("")
CU table:

TU table:
[  0] 0x50000

Foreign TU table:

Used 1 of 6 buckets.
Out of 2 items there are 1 bucket clashes (longest of 1 entries).
end of data encountered whilst reading LEB
/binutils-gdb/binutils/objdump: Error: end of data encountered whilst reading
LEB
/binutils-gdb/binutils/objdump: Error: end of data encountered whilst reading
LEB
/binutils-gdb/binutils/objdump: Error: end of data encountered whilst reading
LEB

Symbol table:
[  0] #00000000 <no .debug_str section>:/binutils-gdb/binutils/objdump:
Warning: Unrecognized form: 0x3e
/binutils-gdb/binutils/objdump: Error: end of data encountered whilst reading
LEB
/binutils-gdb/binutils/objdump: Warning: Unrecognized form: 0x2850a142850a1428
/binutils-gdb/binutils/objdump: Error: end of data encountered whilst reading
LEB
/binutils-gdb/binutils/objdump: Error: end of data encountered whilst reading
LEB
==1== Invalid read of size 8
==1==    at 0x18054B: read_and_display_attr_value.part.0 (dwarf.c:2667)
==1==    by 0x189699: read_and_display_attr_value (dwarf.h:276)
==1==    by 0x189699: display_debug_names (dwarf.c:9934)
==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 0x18 is not stack'd, malloc'd or (recently) free'd
==1== 
==1== 
==1== Process terminating with default action of signal 11 (SIGSEGV): dumping
core
==1==  Access not within mapped region at address 0x18
==1==    at 0x18054B: read_and_display_attr_value.part.0 (dwarf.c:2667)
==1==    by 0x189699: read_and_display_attr_value (dwarf.h:276)
==1==    by 0x189699: display_debug_names (dwarf.c:9934)
==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==  If you believe this happened as a result of a stack
==1==  overflow in your program's main thread (unlikely but
==1==  possible), you can try to increase the size of the
==1==  main thread stack using the --main-stacksize= flag.
==1==  The main thread stack size used in this run was 8388608.

        <62> Unknown TAG value: 0x3e Unknown IDX value: 3e==1== 
==1== HEAP SUMMARY:
==1==     in use at exit: 50,049 bytes in 13 blocks
==1==   total heap usage: 31 allocs, 18 frees, 136,875 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: 50,049 bytes in 13 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)

valgrind: the 'impossible' happened:
   main(): signal was supposed to be fatal

host stacktrace:
==1==    at 0x58046FFA: ??? (in
/usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==1==    by 0x58047127: ??? (in
/usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==1==    by 0x58047390: ??? (in
/usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==1==    by 0x580473C0: ??? (in
/usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==1==    by 0x580BA566: ??? (in
/usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==1==    by 0x580F6117: ??? (in
/usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)

sched status:
  running_tid=1

-- 
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]