Protect mips_hi16_list from fuzzed debug info

[Alan Modra]

On Wed, Feb 08, 2023 at 11:28:08PM +0000, Maciej W. Rozycki wrote:
> On Wed, 8 Feb 2023, Alan Modra wrote:
> > A number of the error/warning handlers in ldmain.c use %C.  This can
> > cause debug info to be parsed for the first time in order to print
> > file/function/line.
> 
>  Hmm, I find it an interesting general phenomenon.  What it means the 
> order sections are processed in can change depending on whether a warning 
> has been issued in the course or not.  Is it not a problem in the first 
> place?  Shouldn't we give priority to debugs sections and parse them first 
> then before moving on to the other sections?

The normal linker processing of sections occurs as usual.  Parsing of
the debug info is separate to this, relocations being applied to
.debug_info by bfd_simple_get_relocated_section_contents for the
error/warning message.  That relocated copy of .debug_info is not used
by the linker to produce the output file .debug_info.

> >  If one of those warnings is triggered after some
> > hi16 relocs have been processed but before the matching lo16 reloc is
> > handled, *and* the debug info is corrupted with a lo16 reloc, then the
> > mips_hi16_list will be flushed with the result that printing a warning
> > changes linker output.
> 
>  OK, but wouldn't these relocs be resolved in the same problematic way 
> anyway when the turn came to processing debug sections?
> 
> >  It is also possible that corrupted debug info
> > adds to the hi16 list, with the result that when the linker handles a
> > later lo16 reloc in a text section, ld will segfault accessing
> > mips_hi16.data after the debug buffers have be freed.
> 
>  This smells a HI16/LO16 pair processing bug to me by itself.  Such pairs 
> must come from the same relocation section, so any HI16/LO16 relocations 
> in a relocation section associated with a debug section are not supposed 
> to influence any such relocations referring to the text section.  I think 
> I need to look into it (though see above as to my availability).

If it is really true that hi16/lo16 pairs are always in the same
section, then we wouldn't need freeze_mips_hi16_list.  Instead it
would be much better to attach the list to mips_elf_section_data.  I
wasn't sure enough to do that, given things like gcc's hot/cold
section partitioning, when I moved the mip_hi16_list to be per-bfd.

-- 
Alan Modra
Australia Development Lab, IBM