[Bug gas/16908] #line directives are ignored inside macros

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Jan Beulich :

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

commit 22a8433e00fd33efcb1fa4961eb826cd97f2cd8b
Author: Jan Beulich 
Date:   Fri Dec 16 09:01:14 2022 +0100

gas: restore Dwarf info generation after macro diagnostic adjustments

While 6fdb723799e2 ("gas: re-work line number tracking for macros and
their expansions") was meant to leave generated Dwarf as is, it really
didn't (and the testcase intended to catch that wasn't covering the case
which broke). Its adjustment to buffer_and_nest() didn't go far enough,
leading to the "linefile" directive inserted at the top to also be
processed later in the PR gas/16908 workaround (which clearly isn't
intended - it's being put there for processing during macro expansion
only). That unnoticed flaw in turn led me to work around it by a
(suspicious to me already at the time) conditional in as_where().

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

[Bug binutils/29893] SEGV of objdump caused by heap-buffer-overflow at dwarf.c:7740 in display_debug_addr()

[13579and24680 at gmail dot com]

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

曾思維 <13579and24680 at gmail dot com> changed:

   What|Removed |Added

Summary|SEGV of objdump caused by   |SEGV of objdump caused by
   |heap-buffer-overflow at |heap-buffer-overflow at
   |elfcomm.c:124 in|dwarf.c:7740 in
   |byte_get_little_endian()|display_debug_addr()

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

[Bug binutils/29908] New: SEGV of objdump caused by heap-buffer-overflow at dwarf.c:7756 in display_debug_addr()

[13579and24680 at gmail dot com]

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

Bug ID: 29908
   Summary: SEGV of objdump caused by heap-buffer-overflow at
dwarf.c:7756 in display_debug_addr()
   Product: binutils
   Version: 2.39
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: 13579and24680 at gmail dot com
  Target Milestone: ---

Created attachment 14520
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14520&action=edit
Generated by my fuzzer and afl-tmin

# version

$ ./binutils-gdb/binutils/objdump --version
GNU objdump (GNU Binutils) 2.39.50.20221213
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

-
# git log

$ git log --oneline -1
d0d41b77c0c (HEAD -> master, origin/master, origin/HEAD) Replace
gdbpy_should_stop with gdbpy_breakpoint_cond_says_stop

-
# make

$ git clone git://sourceware.org/git/binutils-gdb.git
$ cd binutils-gdb
$ ./configure
$ make

-
# crash

$ ./binutils-gdb/binutils/objdump -W poc
./binutils-gdb/binutils/objdump: Warning: Corrupt attribute block length:
0x30303030

poc: file format elf64-x86-64

Contents of the .eh_frame section:


 0014  CIE
  Version:   1
  Augmentation:  "zR"
  Code alignment factor: 48

(... too long ignore)

49894:  
49895:  
49896:  
49897:  
49898:  
49899:  
49900:  
49901:  
49902:  
49903:  
49904:  
49905:  
49906:  
49907:  
49908:  
49909:  
49910:  
49911:  
49912:  
49913:  
fish: Job 1, './binutils-gdb/binutils/objdump…' terminated by signal SIGSEGV
(Address boundary error)

-
# ASAN report

$ ./binutils-gdb_asan/binutils/objdump -W poc
./binutils-gdb_asan/binutils/objdump: Warning: Corrupt attribute block length:
0x30303030

poc: file format elf64-x86-64

Contents of the .eh_frame section:


 0014  CIE
  Version:   1
  Augmentation:  "zR"
  Code alignment factor: 48

(... too long ignore)

300:3030303030303030
301:3030303030303030
302:3030303030303030
303:3030303030303030
304:3030303030303030
305:3030303030303030
306:3030303030303030
307:3030303030303030
308:3030303030303030
309:3030303030303030
310:3030303030303030
311:3030303030303030
312:3030303030303030
313:3030303030303030
314:3030303030303030
315:3030303030303030
=
==2848799==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x61e00ab1 at pc 0x55f9366f07ac bp 0x7ffc73f785f0 sp 0x7ffc73f785e0
READ of size 1 at 0x61e00ab1 thread T0
#0 0x55f9366f07ab in byte_get_little_endian
/home/a13579/fuzz_binutils-gdb/binutils-gdbnew/binutils-gdb_asan/binutils/elfcomm.c:149
#1 0x55f936695768 in display_debug_addr dwarf.c:7756
#2 0x55f9366588c4 in dump_dwarf_section objdump.c:4396
#3 0x55f9367a72d9 in bfd_map_over_sections
/home/a13579/fuzz_binutils-gdb/binutils-gdbnew/binutils-gdb_asan/bfd/section.c:1366
#4 0x55f936658af3 in dump_dwarf objdump.c:4434
#5 0x55f93665f110 in dump_bfd objdump.c:5636
#6 0x55f93665f4e5 in display_object_bfd objdump.c:5715
#7 0x55f93665f816 in display_any_bfd objdump.c:5801
#8 0x55f93665f890 in display_file objdump.c:5822
#9 0x55f9366611b9 in main objdump.c:6230
#10 0x7fae0f154082 in __libc_start_main ../csu/libc-start.c:308
#11 0x55f93664539d in _start
(/home/a13579/fuzz_binutils-gdb/binutils-gdbnew/binutils-gdb_asan/binutils/objdump+0x13b39d)

0x61e00ab1 is located 0 bytes to the right of 2609-byte region
[0x61e00080,0x61e00ab1)
allocated by thread T0 here:
#0 0x7fae0f435808 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x55f936a3bc7c in xmalloc xmalloc.c:149
#2 0x55f9366579c8 in load_specific_d

[Bug binutils/29908] SEGV of objdump caused by heap-buffer-overflow at dwarf.c:7756 in display_debug_addr()

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-12-16
   Assignee|unassigned at sourceware dot org   |nickc at redhat dot com
 Ever confirmed|0   |1
 CC||nickc at redhat dot com

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

[Bug binutils/29908] SEGV of objdump caused by heap-buffer-overflow at dwarf.c:7756 in display_debug_addr()

[cvs-commit at gcc dot gnu.org]

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

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

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

commit fa501b69309ccb03ec957101f24109ed7f737733
Author: Nick Clifton 
Date:   Fri Dec 16 12:06:43 2022 +

Fix a potential illegal memory access when parsing corrupt DWARF
information.

PR 29908
* dwarf.c (display_debug_addr): Check for corrupt header lengths.

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

[Bug binutils/29908] SEGV of objdump caused by heap-buffer-overflow at dwarf.c:7756 in display_debug_addr()

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #2 from Nick Clifton  ---
Hi,

  Thanks for reporting this bug.  I have applied a small patch to add a check
  for an undersized length field in the address range header.

Cheers
  Nick

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

Built "gprofng" from source, it hangs forever during collection on multithreaded program, strace shows "futex(0x..., FUTEX_WAIT_PRIVATE, 1, NULL)"

[Gavin Ray]

Hey all,

This is my first time reporting a bug on this list, please let me know if
there's a standard format to follow.
I heard about "gprofng" and wanted to try it; it sounded exciting. The
first program I tried it on didn't work unfortunately.

It hung forever at collection:

[user@MSI] $ gprofng collect app ./learning_db
Creating experiment directory test.7.er (Process ID: 2327699) ...

Running strace shows the hang at:

gettid()= 2327847
futex(0x5622e2d3cfc4, FUTEX_WAIT_PRIVATE, 1, NULL

Here is the source code to the application, and the strace output:

gprofng hang reproduction (github.com)


I hope this is helpful (it seems to work on some other programs I've tried)
Thank you =)

- Gavin Ray