Re: [PATCH v2] elf: Set this_idx to -1 for invalid relocations
Jan Beulich <[email protected]> Tue, 4 Aug 2026 09:42:26 +0200
| Newsgroups | gmane.comp.gnu.binutils |
|---|---|
| Message-ID | <[email protected]> |
On 04.08.2026 00:20, H.J. Lu wrote: > On Mon, Aug 3, 2026 at 8:51 PM Alan Modra <[email protected]> wrote: >> >> On Mon, Aug 03, 2026 at 07:58:27AM +0800, H.J. Lu wrote: >>> On Mon, Aug 3, 2026 at 7:43 AM Alan Modra <[email protected]> wrote: >>>> >>>> On Sun, Aug 02, 2026 at 08:55:00AM +0800, H.J. Lu wrote: >>>>> On Sun, Aug 2, 2026 at 6:18 AM H.J. Lu <[email protected]> wrote: >>>>>> >>>>>> When invalid relocation is reported by elf_link_read_relocs_from_section >>>>>> called from lang_gc_sections: >>>>>> >>>>>> ld: pr34448-bug_18.o: bad reloc symbol index (0xf2000005 >= 0x13) for >>>>>> offset 0x4 in section `.text.get_tls[get_tls]' >>>>>> >>>>>> the same error is reported again: >>>>>> >>>>>> ld: pr34448-bug_18.o: bad reloc symbol index (0xf2000005 >= 0x13) for >>>>>> offset 0x4 in section `.text.get_tls[get_tls]' >>>> >>>> Using this_idx as a flag is a bad idea. >>>> >>>> I also think that no one should be too concerned about error messages >>>> from fuzzed object files, so if you are going to fix this minor >>>> problem do so in a way that won't potentially break the linker. >>>> >>> >>> Then should linker stop when seeing a fuzzed object file, instead of keep >>> going and crash later? >> >> How is this relevant to a patch about duplicate error messages? > > If we don't care too much about fuzzed object files, why doesn't linker > stop when seeing them? How would you (non-heuristically, i.e. entirely reliably) tell a fuzzed object from a "real" one? Jan