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

            Bug ID: 33897
           Summary: readelf: UBSan undefined-behavior (unsigned offset
                    overflow) in display_debug_frames() via crafted ELF
                    (-w)
           Product: binutils
           Version: 2.46
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: takaosato1997 at gmail dot com
  Target Milestone: ---

Created attachment 16619
  --> https://sourceware.org/bugzilla/attachment.cgi?id=16619&action=edit
poc.min - minimized ELF testcase that triggers UBSan unsigned offset overflow
in display_debug_frames() with readelf -w

Overview
========
A crafted ELF input triggers UndefinedBehaviorSanitizer: undefined-behavior in
binutils/dwarf.c inside display_debug_frames() when running GNU readelf with
DWARF dump enabled (-w). In UBSan-instrumented builds this terminates the
program (SIGILL/abort depending on sanitizer configuration). In a fuzzing build
this appears as SIGILL (sig:04) because UBSan uses trap (__builtin_trap) in
halt mode.

This issue is reproducible with the attached minimized testcase (poc.min).

Affected Component
==================
binutils/readelf DWARF frame parsing (display_debug_frames in binutils/dwarf.c)

Version
=======
GNU Binutils readelf 2.46 (my build reports: 2.46.0.20260210)

Impact
======
At minimum: Denial of Service (crash/abort) when parsing untrusted ELF input
with -w.
Because the UB is an overflow in pointer arithmetic, it may also lead to
incorrect bounds and potentially out-of-bounds memory access depending on
compiler/runtime/optimization choices. (I have not confirmed a direct OOB
read/write in a non-UBSan build.)

Reproducer
==========
1) Build (ASAN+UBSAN) example
----------------------------
Commands used (out-of-tree build):

cd ~/targets/binutils-2.46.0
rm -rf build-asan
mkdir build-asan
cd build-asan
CC=clang CXX=clang++ CFLAGS="-O1 -g -fno-omit-frame-pointer
-fsanitize=address,undefined" CXXFLAGS="-O1 -g -fno-omit-frame-pointer
-fsanitize=address,undefined" LDFLAGS="-fsanitize=address,undefined"
../configure --disable-nls --disable-shared --enable-static
make -j"$(nproc)" -C bfd
make -j"$(nproc)" -C libiberty
make -j"$(nproc)" -C binutils readelf

2) Run
------
ASAN_OPTIONS=abort_on_error=1:detect_leaks=0:symbolize=1:print_stacktrace=1
UBSAN_OPTIONS=halt_on_error=1:print_stacktrace=1 ./binutils/readelf -w poc.min
>/dev/null

Observed Result
===============
readelf prints some warnings about malformed sections and then UBSan reports:

../../binutils/dwarf.c:9775:29: runtime error: addition of unsigned offset to
0xXXXXXXXX overflowed to 0xYYYYYYYYYYYY
  #0 ... in display_debug_frames .../binutils/dwarf.c:9775:29
  #1 ... in display_debug_section .../binutils/readelf.c:18064:18
  #2 ... in process_section_contents .../binutils/readelf.c:18219:10
  #3 ... in process_object .../binutils/readelf.c:24961:9
  #4 ... in process_file .../binutils/readelf.c:25387:13
  #5 ... in main .../binutils/readelf.c:25453:11
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
../../binutils/dwarf.c:9775:29

In my AFL/UBSan fuzz build the same testcase terminates with SIGILL (signal 4)
at display_debug_frames(). A gdb backtrace points to dwarf.c around the frame
parsing code path.

Expected Result
===============
readelf should handle malformed/untrusted DWARF/ELF data safely, report parsing
errors, and exit cleanly without triggering undefined behavior or terminating
with SIGILL/abort.

Notes on duplicates / related issues
====================================
I searched Bugzilla with keywords related to "display_debug_frames", "DW_CFA",
and "overflow" and reviewed several historical issues in similar areas (e.g.
reports involving display_debug_frames or aborts in DWARF processing). I did
not find an existing report that matches this specific UBSan "addition of
unsigned offset overflow" at dwarf.c:9775 in this code path, but maintainers
may know of related fixes. If this is a duplicate of a known issue, please
point me to the correct bug ID and I will retest against the current tree.

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

Reply via email to