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

--- Comment #1 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jan Beulich <[email protected]>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3f5a0261d23ca400aaa8f0c27b061b6a4d9bf35f

commit 3f5a0261d23ca400aaa8f0c27b061b6a4d9bf35f
Author: Harshit Kumar <[email protected]>
Date:   Fri Nov 6 14:13:17 2026 +0100

    bfd: elfxx-x86: reject non-x86 target ids in elf_x86_hash_table

    PR ld/34874

    A linker script can retarget the output BFD, for example with
    OUTPUT_FORMAT("elf64-bpfle").  The x86 emulation still calls
    bfd_elf_linker_x86_set_options, which takes the target id from the
    output BFD's backend data.  The id and the link hash table then both
    belong to the foreign backend, so the id comparison in
    elf_x86_hash_table passes and struct elf_x86_link_hash_table is the
    wrong layout of that table.  The write to htab->params then overflows
    the heap block (AddressSanitizer, write of size 8, 424 bytes after an
    1848-byte region).

    Check the id after is_elf_hash_table, and accept only the x86 ids.
    is_elf_hash_table must stay the first test in the macro: for a
    non-ELF output format the hash table is not an ELF one, so it
    short-circuits and bed->target_id is never read.  A format such as
    "binary" has no ELF backend data at all, so reading the id first
    segfaults.  This order keeps both properties: non-ELF outputs never
    reach the read, and foreign ELF ids are rejected.

    The other elf_x86_hash_table callers pass X86_64_ELF_DATA,
    I386_ELF_DATA, or bed->target_id of an x86 output, so they are
    unaffected.  No change to bfd_elf_linker_x86_set_options is needed.

    Add ld-x86-64/arch-confusion.exp and its input arch-confusion.s.  The
    foreign ELF case reports the overflow only under AddressSanitizer.

    Signed-off-by: Harshit Kumar <[email protected]>

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

Reply via email to