[Bug ld/27180] New: RISC-V far relocations for auipc instructions may cause segfault with --emit-relocs

[jwerner at chromium dot org]

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

            Bug ID: 27180
           Summary: RISC-V far relocations for auipc instructions may
                    cause segfault with --emit-relocs
           Product: binutils
           Version: 2.35.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: jwerner at chromium dot org
  Target Milestone: ---

I have run into a segfault in GNU ld for the RISC-V architecture. I'm using
2.35.1, but I also briefly tried out the latest Git tree and saw it there as
well. The following minimal testcase can reproduce it:

======== test.c ========
extern int mysymbol[0];
int *_start(void) {
        return mysymbol;
}
========================

======= test.ld ========
ENTRY(_start)
SECTIONS
{
        mysymbol = 0x1000;

        .text 0x90000000 : {
                *(.text)
        }
}
========================

$ riscv64-elf-gcc -nostdlib -T test.ld -Wl,--emit-relocs -mcmodel=medany -o
test test.c
collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
compilation terminated.

I have debugged the segfault a bit and found that it happens at `rh =
elf_sym_hashes (input_bfd)[indx];` in elflink.c:11232, because indx is
completely out of range. The problem is that this code assumes that r_symndx
(computed from `irela->r_info >> r_sym_shift`) can always be trusted to be a
symbol index. However, for some absolute relocations in the RISC-V
architecture, it is actually an absolute offset.

In my testcase, the problematic relocation starts out as an R_RISCV_PCREL_HI20
relocation (where the high 32 bytes would be a symbol index, so this code would
work correctly). However, when calling into the riscv_elf_relocate_section()
backend, the relocation ends up being transformed into an R_RISCV_HI20 absolute
relocation, where the high 32 bytes of r_info are simply an absolute address.
(It's possible that this bug also exists for normal R_RISCV_HI20 relocations in
the source file, or maybe that case would've been caught earlier and it's only
the late transformation of the relocation that causes the problem... I didn't
test that far.)

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