Protect mips_hi16_list from fuzzed debug info
Maciej W. Rozycki
macro@orcam.me.uk
Fri Feb 10 18:13:05 GMT 2023
On Thu, 9 Feb 2023, Alan Modra wrote:
> > Two consecutive entries must come from a single .rel.* section or they
> > wouldn't be consecutive (there's no relationship between different .rel.*
> > sections).
>
> Yes, but see the comment before _bfd_mips_elf_hi16_reloc
>
> The ABI requires that the *LO16 immediately follow the *HI16.
> However, as a GNU extension, we permit an arbitrary number of
> *HI16s to be associated with a single *LO16. This significantly
> simplies the relocation handling in gcc.
Yes, I am aware of this GNU extension, but it does not change anything
for this consideration. There's just meant not to be any predefined HI16
value at the beginning of any relocation section (IOW any initial orphan
LO16 reloc has to resolve with the high part of the addend implied zero).
> > That sounds like a plan to me, but it's unrealistic for me to commit to
> > it in the next two days (and then I head out to California for a week).
>
> Patch attached. Note the FIXME.
I think there's no need to bail out on unmatched HI16 relocs. These
relocs are used with the LUI instruction as the first part of an address
load sequence. If the low part is never referred, then the address will
not have been fully loaded anyway, so such code won't do anything harmful.
I think such orphan HI16 relocs used to appear in harmless leftovers from
optimised code with certain versions of GCC, so adding such an error would
cause a regression as such code wouldn't link anymore. I wouldn't add any
extra error cases here beyond what we might already have.
I'll have a look into this issue and dive into code to better understand
it once I'm back from California. I'll try to address the RELA side too.
Thank you for your patches and your involvement with this issue, really
appreciated. And as I say, more proper support is required with the MIPS
target given it's still commercially active. It's not like say VAX, which
only has a bunch of enthusiasts to fiddle with.
Maciej
More information about the Binutils
mailing list