SHT_RELR sh_link and sh_info
authorAlan Modra <amodra@gmail.com>
Tue, 23 Aug 2022 11:20:18 +0000 (20:50 +0930)
committerAlan Modra <amodra@gmail.com>
Tue, 23 Aug 2022 11:40:51 +0000 (21:10 +0930)
commit37c49d0d63f7bc1f0a3c4e639df586df5f3a8e80
treeead4df98893cb39b345ee3b022d69dc856dc6e15
parent6ecc36f7b7a29952579a49dc3d90f6871c6ab238
SHT_RELR sh_link and sh_info

I don't think it makes any sense for a SHT_RELR section to specify a
symbol table with sh_link.  SHT_RELR relocations don't use symbols.
There is no real need to specify sh_info either, SHT_RELR is not for
relocatable object files.  Anyway, fuzzers of course don't restrict
themselves to even half-sensible objects.  So they found a hole in
objcopy using a non-alloc SHT_RELR in an ET_EXEC.  In that case BFD
set up the SHT_RELR section as if it were a SHT_REL against the
sh_info target section.  When it came to reading in the target section
relocs, the count was horribly wrong which caused a buffer overflow.

* elf.c (bfd_section_from_shdr <SHT_RELR>): Always just make a
normal section, don't treat it as a reloc section.
bfd/elf.c