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