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