diff options
author | Alan Modra <amodra@gmail.com> | 2022-08-23 20:50:18 +0930 |
---|---|---|
committer | Alan Modra <amodra@gmail.com> | 2022-08-23 21:10:51 +0930 |
commit | 37c49d0d63f7bc1f0a3c4e639df586df5f3a8e80 (patch) | |
tree | ead4df98893cb39b345ee3b022d69dc856dc6e15 /gdb/frame.c | |
parent | 6ecc36f7b7a29952579a49dc3d90f6871c6ab238 (diff) | |
download | binutils-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