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)
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

index f186a2cffe9cbba978243fb23eafdd406aa659d4..8aba36acb3cd137a93900951c3a27effcc28e6b6 100644 (file)
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -2409,6 +2409,7 @@ bfd_section_from_shdr (bfd *abfd, unsigned int shindex)
           its sh_link points to the null section.  */
        if (((abfd->flags & (DYNAMIC | EXEC_P)) != 0
             && (hdr->sh_flags & SHF_ALLOC) != 0)
+           || hdr->sh_type == SHT_RELR
            || hdr->sh_link == SHN_UNDEF
            || hdr->sh_link != elf_onesymtab (abfd)
            || hdr->sh_info == SHN_UNDEF