public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* SHT_RELR sh_link and sh_info
@ 2022-08-23 11:56 Alan Modra
  0 siblings, 0 replies; only message in thread
From: Alan Modra @ 2022-08-23 11:56 UTC (permalink / raw)
  To: binutils

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2022-08-23 11:57 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-23 11:56 SHT_RELR sh_link and sh_info Alan Modra

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).