SHT_RELR sh_link and sh_info

Alan Modra amodra@gmail.com
Tue Aug 23 11:56:57 GMT 2022


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.

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

-- 
Alan Modra
Australia Development Lab, IBM


More information about the Binutils mailing list