Fix buffer overflow in FR30 i20/i32 relocation handlers (PR 34159)
Patches a fuzzer-discovered buffer overflow in FR30's custom relocation functions by adding bounds checking.
The FR30 ELF backend’s custom relocation handlers for i20 and i32 relocations lacked offset validation, allowing malformed object files to trigger out-of-bounds memory access. The patch replaces partial generic-reloc logic with a proper call to bfd_elf_generic_reloc for relocatable links and adds bfd_reloc_offset_in_range checks before accessing section data. This hardens the linker against crafted inputs that previously could cause crashes or potentially worse memory corruption during relocation processing.
In Details
BFD's per-architecture ELF backends implement special_function callbacks for relocations that don't fit the standard bfd_elf_generic_reloc pattern. FR30's elf32-fr30.c provides custom handlers for split-field i20 and i32 immediate relocations where bits are scattered across the instruction word. The old code hand-rolled partial generic-reloc behavior for ld -r but skipped range validation, trusting reloc_entry->address to point within the input section's allocated buffer. With fuzzed objects, an out-of-range offset leads directly to heap corruption when bfd_get_32 / bfd_put_32 d…
For Context
When a linker processes object files, it must adjust addresses embedded in machine code—a process called relocation. Most architectures use standard patterns the Binary File Descriptor (BFD) library handles generically, but some CPUs encode immediates in non-contiguous bit fields that require custom logic. The FR30 (a Fujitsu embedded RISC architecture) splits 20-bit and 32-bit constants across multiple instruction words, so BFD's FR30 backend supplies specialized functions to extract, modify, and rewrite those fields. These functions receive a relocation entry specifying an offset into a section's raw bytes, then read the existing instruction, apply the relocation math, and write the updated bits back. Without validation, a malicious or corrupted object file can supply an offset that points outside allocated memory, causing the linker to read or write arbitrary heap locations when it dereferences that offset.