aboutsummaryrefslogtreecommitdiff
path: root/gdb/frame.c
diff options
context:
space:
mode:
authorAlan Modra <amodra@gmail.com>2022-08-23 20:50:18 +0930
committerAlan Modra <amodra@gmail.com>2022-08-23 21:10:51 +0930
commit37c49d0d63f7bc1f0a3c4e639df586df5f3a8e80 (patch)
treeead4df98893cb39b345ee3b022d69dc856dc6e15 /gdb/frame.c
parent6ecc36f7b7a29952579a49dc3d90f6871c6ab238 (diff)
downloadbinutils-37c49d0d63f7bc1f0a3c4e639df586df5f3a8e80.zip
binutils-37c49d0d63f7bc1f0a3c4e639df586df5f3a8e80.tar.gz
binutils-37c49d0d63f7bc1f0a3c4e639df586df5f3a8e80.tar.bz2
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 <SHT_RELR>): Always just make a normal section, don't treat it as a reloc section.
Diffstat (limited to 'gdb/frame.c')
0 files changed, 0 insertions, 0 deletions