https://sourceware.org/bugzilla/show_bug.cgi?id=34053
Bug ID: 34053
Summary: Heap-buffer-overflow READ in xcoff_link_add_symbols()
via unvalidated n_numaux index (CWE-125)
Product: binutils
Version: 2.46
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: takaosato1997 at gmail dot com
Target Milestone: ---
Created attachment 16680
--> https://sourceware.org/bugzilla/attachment.cgi?id=16680&action=edit
payload
Product: binutils
Component: bfd
Version: 2.46
Summary: Heap-buffer-overflow READ in xcoff_link_add_symbols() via unvalidated
n_numaux index (CWE-125)
Severity: normal
Priority: P2
Keywords: security
Full Technical Report:
=================================================================
1. SUMMARY
=================================================================
A security-relevant heap-buffer-overflow (READ) has been identified in
libbfd/xcofflink.c within the xcoff_link_add_symbols() function. When
processing a malformed XCOFF 32-bit object file, the linker retrieves the
'n_numaux' field directly from the untrusted input. This field is subsequently
used as an array index to locate auxiliary symbol entries without verifying
that the resulting pointer remains within the bounds of the allocated
symbol table buffer.
This allows a specifically crafted input to trigger an out-of-bounds read
of approximately 1458 to 3348+ bytes past the heap buffer, potentially
accessing adjacent heap allocations.
=================================================================
2. ROOT CAUSE ANALYSIS
=================================================================
The vulnerability is located at bfd/xcofflink.c:1589. While the implementation
correctly validates that n_numaux is non-zero, it lacks an upper-bound
check against the end of the symbol buffer ('esym_end').
Technical Flow:
1. f_nsyms is retrieved from the file header and determines the buffer size.
2. During symbol iteration, 'n_numaux' is fetched from the object file.
3. Vulnerable code path (bfd/xcofflink.c:1589):
bfd_coff_swap_aux_in (abfd, (void *) (esym + symesz * sym.n_numaux), ...);
The index calculation (esym + symesz * sym.n_numaux) can point significantly
beyond the allocated memory, leading to an OOB read during the swap-in
process (coff-rs6000.c:510 and libbfd.c:833).
=================================================================
3. SECURITY IMPACT (CWE-125)
=================================================================
This issue provides a stable and deterministic OOB read primitive:
- Information Disclosure: The OOB region contains live heap data from
concurrent BFD allocations (such as sym_hash, csect_cache, and reloc_info).
This could be leveraged to infer heap layout or leak sensitive pointers.
- Logic Divergence: The data read OOB is stored in the 'aux' structure
and influences subsequent linker behavior, which may lead to
undefined behavior or further memory corruption downstream.
=================================================================
4. COMPARISON WITH RELATED XCOFF VULNERABILITIES
=================================================================
To ensure clarity, this report was compared against existing XCOFF
vulnerabilities and appears to be a distinct issue:
- vs CVE-2026-4647: That report focuses on relocation type indices in
coff-rs6000.c, whereas this issue affects auxiliary symbol indices.
- vs CVE-2026-3441: That issue involves x_scnlen/csects indexing at a
different code region (~line 2282).
- vs CVE-2026-3442: That relates to r_symndx bounds in the relocation path.
This is a new observation regarding the n_numaux-driven path in
xcoff_link_add_symbols() at line 1589.
=================================================================
5. ASAN REPORT & REPRODUCTION
=================================================================
Verified on binutils 2.46 and HEAD (2026-04-07).
ASAN Trace Snapshot:
#0 bfd_getb32 bfd/libbfd.c:833
#1 _bfd_xcoff_swap_aux_in bfd/coff-rs6000.c:510
#2 xcoff_link_add_symbols bfd/xcofflink.c:1589
Reproduction Steps:
$ ld-new --gc-sections -o /dev/null payload.c
=================================================================
6. PROPOSED MITIGATION
=================================================================
Introducing a boundary validation before the bfd_coff_swap_aux_in call:
+ if ((bfd_byte *) esym + symesz * (bfd_size_type)(sym.n_numaux + 1) >
esym_end)
+ {
+ _bfd_error_handler(_("%pB: symbol `%s' has invalid n_numaux (%d)"),
+ abfd, name, sym.n_numaux);
+ bfd_set_error (bfd_error_bad_value);
+ goto error_return;
+ }
bfd_coff_swap_aux_in (abfd, (void *) (esym + symesz * sym.n_numaux), ...);
--
You are receiving this mail because:
You are on the CC list for the bug.
