https://sourceware.org/bugzilla/show_bug.cgi?id=33919
Bug ID: 33919
Summary: Out-of-bounds read in XCOFF relocation processing
(coff-rs6000.c, coff64-rs6000.c)
Product: binutils
Version: 2.46
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: 1286484614 at qq dot com
Target Milestone: ---
Created attachment 16627
--> https://sourceware.org/bugzilla/attachment.cgi?id=16627&action=edit
the report of the bug
In xcoff64_ppc_relocate_section() and xcoff_ppc_relocate_section(), the
relocation type field rel->r_type is used as an array index into
xcoff64_howto_table / xcoff_howto_table WITHOUT bounds validation.
r_type is read from the input file as an 8-bit value (range 0-255) in
xcoff64_swap_reloc_in() (coff64-rs6000.c:727), but the howto tables only
contain 50 entries (index 0x00-0x31).
Vulnerable code (coff64-rs6000.c:1582):
memcpy(&howto, &xcoff64_howto_table[rel->r_type], sizeof(howto));
The bounds check at line 1671 occurs 89 lines AFTER the OOB access:
if (rel->r_type >= XCOFF_MAX_CALCULATE_RELOCATION ...
The corrupted howto structure is then used to index xcoff_complain_overflow[]
(only 4 entries) at line 1705, potentially calling an arbitrary function
pointer.
Both XCOFF32 (coff-rs6000.c:3771) and XCOFF64 (coff64-rs6000.c:1582) are
affected.
Impact: OOB read, potential code execution via corrupted function pointer.
Trigger: Processing a crafted XCOFF object file with ld.
Suggested fix: Add "if (rel->r_type > R_TOCL) return false;" before the memcpy
in both files.
Note: This is NOT a duplicate of Bug 21786, 27795, or 27798. Those bugs
addressed different overflow issues at different code locations. This bug
is specifically about missing bounds validation of rel->r_type before
indexing xcoff64_howto_table at line 1582 (coff64-rs6000.c) and
xcoff_howto_table at line 3771 (coff-rs6000.c).
--
You are receiving this mail because:
You are on the CC list for the bug.
