[Bug binutils/29799] New: A heap buffer overflow was fould in display_debug_section in binutils-2.40 (HEAD)

[15664243668 at 163 dot com]

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

Bug ID: 29799
   Summary: A heap buffer overflow was fould in
display_debug_section in binutils-2.40 (HEAD)
   Product: binutils
   Version: 2.40 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: 15664243668 at 163 dot com
  Target Milestone: ---
 Flags: security?

Created attachment 14460
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14460&action=edit
readelf poc file

Hi

There is a heap buffer overflow bug in binutils-2.40 (commit ab11c890).

The bug is triggered in display_debug_section() at binutils/readelf.c:16319
when parsing the debug sections of a malformed ELF file.

To reproduce this bug, use:

1. compile binutils-2.39 with clang-6.0 and address sanitizer:
```sh
./configure --disable-shared --disable-gdb --disable-werror
make
```

2. use readelf to process the PoC file (see attachment):
```sh
readelf -w ./poc2
```

The address sanitizer reports are as follows.
```
===
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e000e3 at pc
0x556ef069 bp 0x7fffe040 sp 0x7fffe030
READ of size 1 at 0x60e000e3 thread T0
#0 0x556ef068 in byte_get_little_endian ../../binutils/elfcomm.c:118
#1 0x556e88ff in display_gdb_index ../../binutils/dwarf.c:10548
#2 0x5567410a in display_debug_section ../../binutils/readelf.c:16319
#3 0x55674606 in process_section_contents
../../binutils/readelf.c:16415
#4 0x5569169e in process_object ../../binutils/readelf.c:22438
#5 0x55693930 in process_file ../../binutils/readelf.c:22861
#6 0x55693d8f in main ../../binutils/readelf.c:22932
#7 0x76a48c86 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
#8 0x5561ba79 in _start
(/home/binutils-gdb/obj-asan/binutils/readelf+0xc7a79)

0x60e000e3 is located 10 bytes to the right of 153-byte region
[0x60e00040,0x60e000d9)
allocated by thread T0 here:
#0 0x76ef6b40 in __interceptor_malloc
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x55627377 in get_data ../../binutils/readelf.c:498
#2 0x55672b0b in load_specific_debug_section
../../binutils/readelf.c:15940
#3 0x556740ad in display_debug_section ../../binutils/readelf.c:16313
#4 0x55674606 in process_section_contents
../../binutils/readelf.c:16415
#5 0x5569169e in process_object ../../binutils/readelf.c:22438
#6 0x55693930 in process_file ../../binutils/readelf.c:22861
#7 0x55693d8f in main ../../binutils/readelf.c:22932
#8 0x76a48c86 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

SUMMARY: AddressSanitizer: heap-buffer-overflow ../../binutils/elfcomm.c:118 in
byte_get_little_endian
Shadow bytes around the buggy address:
  0x0c1c7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
=>0x0c1c7fff8010: 00 00 00 00 00 00 00 00 00 00 00 01[fa]fa fa fa
  0x0c1c7fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
```

More detailed causes of this bug is to be analyzed.

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

[Bug binutils/29799] A heap buffer overflow was found in display_debug_section in binutils-2.40 (HEAD)

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

Summary|A heap buffer overflow was  |A heap buffer overflow was
   |fould in|found in
   |display_debug_section in|display_debug_section in
   |binutils-2.40 (HEAD)|binutils-2.40 (HEAD)

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

[Bug ld/29797] error while loading shared libraries: unexpected PLT reloc type 0x00

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by H.J. Lu :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=25d17459e337a4cc9856f36c55a88b072c8709c9

commit 25d17459e337a4cc9856f36c55a88b072c8709c9
Author: H.J. Lu 
Date:   Wed Nov 16 15:06:37 2022 -0800

ld: Always call elf_backend_output_arch_local_syms

Always call elf_backend_output_arch_local_syms since only the backend
knows if elf_backend_output_arch_local_syms is needed when all symbols
are striped.  elf_backend_output_arch_local_syms is defined only for
x86, ARM and AARCH64.  On x86, elf_backend_output_arch_local_syms must
be called to handle local IFUNC symbols even if all symbols are striped.
Update ARM and AARCH64 to skip elf_backend_output_arch_local_syms when
symbols aren't needed.

bfd/

PR ld/29797
* elf32-arm.c (elf32_arm_output_arch_local_syms): Skip if symbols
aren't needed.
* elfnn-aarch64.c (elfNN_aarch64_output_arch_local_syms):
Likewise.
* elflink.c (bfd_elf_final_link): Always call
elf_backend_output_arch_local_syms if available.

ld/

PR ld/29797
* testsuite/ld-elf/linux-x86.exp: Run PR ld/29797 test.
* testsuite/ld-elf/pr29797.c: New file.

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

[Bug ld/29797] error while loading shared libraries: unexpected PLT reloc type 0x00

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |2.40
 Resolution|--- |FIXED

--- Comment #6 from H.J. Lu  ---
Fixed for 2.40.

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

[Bug binutils/26219] support DWARF5 split dwarf in dwp

[jordan at jwillikers dot com]

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

Jordan Williams  changed:

   What|Removed |Added

 CC||jordan at jwillikers dot com

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

[Bug gold/15447] dwp crashes with fseek(NULL) when executable without any .dwo files is specified

[jordan at jwillikers dot com]

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

Jordan Williams  changed:

   What|Removed |Added

 CC||jordan at jwillikers dot com

--- Comment #3 from Jordan Williams  ---
I only see this crash when attempting to use the DWARF 5 format. DWP seems to
be able to find the .dwo files necessary for the DWARF 4 format when given the
executable.

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

[Bug binutils/26219] support DWARF5 split dwarf in dwp

[jordan at jwillikers dot com]

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

--- Comment #2 from Jordan Williams  ---
This would be really great to have, especially since newer versions of GCC
default to DWARF 5.

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

[Bug ld/29802] New: Segmentation fault in _bfd_elf_strtab_add

[danglin at gcc dot gnu.org]

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

Bug ID: 29802
   Summary: Segmentation fault in _bfd_elf_strtab_add
   Product: binutils
   Version: 2.39
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

I've been working on getting 64-bit GNU ld on hppa64-hpux to work with
gcc. I hit a segmentation fault linking libquadmath in _bfd_elf_strtab_add:

bash-5.1$ gdb -c core /opt/gnu64/bin/ld
GNU gdb (GDB) 7.11.50.20160723-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "hppa64-hp-hpux11.11".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/gnu64/bin/ld...done.
[New ]

warning: Private mapping of shared library text was not specified
by the executable; setting a breakpoint in a shared library which
is not privately mapped will not work.  See the HP-UX 11i v3 chatr
manpage for methods to privately map shared library text.
Unable to modify dynamic linker flags.
(gdb) bt
#0  0x4010cf7c in _bfd_elf_strtab_add (tab=0x800100050228,
str=0x0, copy=false) at ../../src/bfd/elf-strtab.c:150
#1  0x400fa1b4 in bfd_elf_link_record_local_dynamic_symbol (
info=0x80010001b238 , input_bfd=0x8001001db158,
input_indx=-9223372032559480280) at ../../src/bfd/elflink.c:841
#2  0x400cfeb4 in allocate_global_data_dlt (eh=0x8001001db158,
data=0x800100050228) at ../../src/bfd/elf64-hppa.c:974
#3  0x400bcb50 in bfd_link_hash_traverse (htab=0x80010004e888,
func=0x800100050228, info=0x0) at ../../src/bfd/linker.c:671
#4  0x400d119c in elf_link_hash_traverse (info=0x83ffbfff21e8,
f=, table=0x800100050228) at ../../src/bfd/elf-bfd.h:749
#5  elf64_hppa_size_dynamic_sections (output_bfd=0x0, info=0x8001001db158)
at ../../src/bfd/elf64-hppa.c:1702
#6  0x401000f0 in bfd_elf_size_dynamic_sections (
output_bfd=0x80010001b238 , soname=,
rpath=0x0, filter_shlib=0x0, audit=0x0, depaudit=0x0,
auxiliary_filters=, info=0x800100050228,
sinterpptr=) at ../../src/bfd/elflink.c:7398
#7  0x400ac5f4 in ldelf_before_allocation (
audit=0x80010001b238  "\300,\001H\004@A\206",
depaudit=,
default_interpreter_name=0x ) at ../../src/ld/ldelf.c:1835
#8  0x400a8048 in gldelf64hppa_before_allocation () at eelf64hppa.c:102
#9  0x400a06d8 in ldemul_before_allocation ()
at ../../src/ld/ldemul.c:96
#10 0x40096fb4 in lang_process () at ../../src/ld/ldlang.c:8318
#11 0x4017b8e8 in main (argc=, argv=)
at ../../src/ld/ldmain.c:497

Problem is str=0x0. If I return 0 when str is NULL, libquadmath will link
successfully. Whether it works is another matter. Probably, there's a better
fix.

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

[Bug binutils/29799] A heap buffer overflow was found in display_debug_section in binutils-2.40 (HEAD)

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

   Assignee|unassigned at sourceware dot org   |amodra at gmail dot com

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

[Bug binutils/29799] A heap buffer overflow was found in display_debug_section in binutils-2.40 (HEAD)

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-18
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

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

[Bug binutils/29799] A heap buffer overflow was found in display_debug_section in binutils-2.40 (HEAD)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Alan Modra :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=69bfd1759db41c8d369f9dcc98a135c5a5d97299

commit 69bfd1759db41c8d369f9dcc98a135c5a5d97299
Author: Alan Modra 
Date:   Fri Nov 18 11:29:13 2022 +1030

PR29799 heap buffer overflow in display_gdb_index dwarf.c:10548

PR 29799
* dwarf.c (display_gdb_index): Typo fix.

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

[Bug binutils/29799] A heap buffer overflow was found in display_debug_section in binutils-2.40 (HEAD)

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Alan Modra  ---
Fixed

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

[Bug ld/29803] New: Relax failed between different output section

[lifang_xia at linux dot alibaba.com]

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

Bug ID: 29803
   Summary: Relax failed between different output section
   Product: binutils
   Version: 2.40 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: lifang_xia at linux dot alibaba.com
  Target Milestone: ---

Hi all,
I have met a problem in risc-v relaxation. But I think it would be generic bug,
not only in risc-v.
Here is a case for riscv:
```
section .text.main
.global main
main:
call foo
call foo
call foo
call foo
call foo
call foo
call foo
.size main, . - main

.section .text.foo
.global foo
foo:
.option norvc
.rept 504
nop
.endr
call bar
.option rvc

ret
.size foo, . - foo

.section .bar.text
.global bar
bar:
ret
.size bar, . - bar
```

build with as:
```
./gas/as-new -o 1.o 1.s -march=rv32gc -mabi=ilp32d -mrelax
```

link file:
```
MEMORY
{
RAM1 : ORIGIN = 0x0, LENGTH = 0x1000
RAM2 : ORIGIN = 0x1000, LENGTH = 0x400
}

SECTIONS
{
.text :
{
*(.text)
*(.text.*)
} > RAM1

.bar.text :
{
*(.bar.text)
} > RAM2
}
```

link command:
```
./ld/ld-new -o 1 1.o  -T1.ld -m elf32lriscv
```

It will get an error: 
(.text.foo+0x7e0): relocation truncated to fit: R_RISCV_RVC_JUMP against symbol
`bar' defined in .bar.text section in 1.o

Because of the .foo.text's output_offset(base address) doest not update after
the relaxtion in main in time. (ldlang.c -> lang_size_sections_1 -> case
lang_input_section_enum)
```
 case lang_input_section_enum:
   {
 asection *i;

 i = s->input_section.section;
 if (relax)
   {
 bool again;

 if (!bfd_relax_section (i->owner, i, &link_info, &again))
   einfo (_("%F%P: can't relax section: %E\n"));
 if (again)
   *relax = true;
   }

 dot = size_input_section (prev, output_section_statement,
   fill, &removed, dot);
   }
   break;

```
the size_input_section only update the size of current input section. But it
doest not update the next input section's offset(base address).

How about add lang_size_sections_1 after bfd_relax_section?

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

[Bug ld/29803] Relax failed between different output section

[lifang_xia at linux dot alibaba.com]

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

--- Comment #1 from lifang_xia at linux dot alibaba.com ---
diff --git a/ld/ldlang.c b/ld/ldlang.c
index 03daba6ef7f..a63e73850c3 100644
--- a/ld/ldlang.c
+++ b/ld/ldlang.c
@@ -6138,8 +6138,14 @@ lang_size_sections_1
if (!bfd_relax_section (i->owner, i, &link_info, &again))
  einfo (_("%F%P: can't relax section: %E\n"));
if (again)
- *relax = true;
+ {
+   /* Update vma and size after finishing relax for sectino i.
 */
+   lang_size_sections_1 (prev, output_section_statement,
+ fill, dot, false, check_regions);
+   *relax = true;
+ }
  }
+
dot = size_input_section (prev, output_section_statement,
  fill, &removed, dot);
  }

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

[Bug ld/29803] Relax failed between different output section

[amodra at gmail dot com]

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

--- Comment #2 from Alan Modra  ---
Calling lang_size_sections_1 recursively seems more than a little dangerous. 
Why doesn't the relax_again loop in lang_relax_sections work for you?

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

[Bug ld/29803] Relax failed between different output section

[lifang_xia at linux dot alibaba.com]

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

--- Comment #3 from lifang_xia at linux dot alibaba.com ---
> Calling lang_size_sections_1 recursively seems more than a little dangerous.
Yes, an other way to avoid this:
Do not relax it if the caller and the dest function are not in same output
sections.
But it is not a good choice.

> Why doesn't the relax_again loop in lang_relax_sections work for you?
It will traverse all the input section and do relax if *relax* is true in
lang_size_sections_1. So in first relax pass, the relaxtion of function "main"
has done, but the address of "foo" does not be updated, so the relaxation in
foo still use the old address(before relaxation of main) to calculate the
offset to the dest symbol.

The *realx_again* can not affect the first relax pass.

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