From 37c49d0d63f7bc1f0a3c4e639df586df5f3a8e80 Mon Sep 17 00:00:00 2001 From: Alan Modra Date: Tue, 23 Aug 2022 20:50:18 +0930 Subject: [PATCH] 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 ): Always just make a normal section, don't treat it as a reloc section. --- bfd/elf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/bfd/elf.c b/bfd/elf.c index f186a2cffe9..8aba36acb3c 100644 --- 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 -- 2.30.2