Re: [PATCH v2] elf: Set this_idx to -1 for invalid relocations

On 04.08.2026 10:57, H.J. Lu wrote:
> On Tue, Aug 4, 2026 at 3:42 PM Jan Beulich <[email protected]> wrote:
>>
>> 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
> 
> When linker reaches the following code
> 
>       if (nsyms > 0)
>         {
>           if ((size_t) r_symndx >= nsyms)
>             {
>               _bfd_error_handler
>                 /* xgettext:c-format */
>                 (_("%pB: bad reloc symbol index (%#" PRIx64 " >= %#lx)"
>                    " for offset %#" PRIx64 " in section `%pA'"),
>                  abfd, (uint64_t) r_symndx, (unsigned long) nsyms,
>                  (uint64_t) irela->r_offset, sec);
>               elf_section_data (sec)->this_idx
>                 = ELF_SECTION_WITH_INVALID_RELOCATION;
>               bfd_set_error (bfd_error_bad_value);
>               return false;
>             }
>         }
>       else if (r_symndx != STN_UNDEF)
>         {
>           _bfd_error_handler
>             /* xgettext:c-format */
>             (_("%pB: non-zero symbol index (%#" PRIx64 ")"
>                " for offset %#" PRIx64 " in section `%pA'"
>                " when the object file has no symbol table"),
>              abfd, (uint64_t) r_symndx,
>              (uint64_t) irela->r_offset, sec);
>           elf_section_data (sec)->this_idx
>             = ELF_SECTION_WITH_INVALID_RELOCATION;
>           bfd_set_error (bfd_error_bad_value);
>           return false;
>         }
> 
> in elf_link_read_relocs_from_section, the input isn't a valid
> ELF object file.   It could be a fuzzed object.

Right. And whether to continue after such an error is indeed a policy
question. I'm inclined to say that upon encountering broken input, a
fatal error is pretty reasonable.

Jan