https://sourceware.org/bugzilla/show_bug.cgi?id=34596
Aaron Merey <amerey at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amerey at redhat dot com
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Aaron Merey <amerey at redhat dot com> ---
Fixed in the following commit
commit 4037fb052e8c7f06139fee36a73d7b9afdfd0750
Author: Sujal Tuladhar <[email protected]>
Date: Sun Sep 20 20:30:55 2026 -0400
readelf: fix 4-byte out-of-bounds read of CU-vector count in
print_gdb_index_section
In the symbol table loop of print_gdb_index_section, the constant-pool
offset `vector` taken from the file is validated only with
if ((size_t) (dataend - const_start) < vector)
goto invalid_data;
which permits `vector == dataend - const_start`, i.e. `readcus == dataend`.
The following fixed-width read
uint32_t cus = read_4ubyte_unaligned (dbg, readcus);
then reads 4 bytes at `readcus`, up to 4 bytes past the end of the section
buffer whenever `vector` is within 3 bytes of the constant pool's end.
The immediately following inner loop already guards its own read with
`if (readcus + 4 > dataend) goto invalid_data;`, and the DW_FORM_sec_offset
/
str_offsets code paths use the same `(end - ptr) < width` idiom; only this
initial count read omitted the read-width term. Add it.
Reproducible with `eu-readelf --debug-dump=gdb_index` on a crafted ELF
whose
`.gdb_index` (version 4-9) symbol slot sets `vector` to the constant-pool
size.
AddressSanitizer reports a heap-buffer-overflow READ of size 4 at the count
read.
Signed-off-by: Sujal Tuladhar <[email protected]>
--
You are receiving this mail because:
You are on the CC list for the bug.
