diff options
author | Alan Modra <amodra@gmail.com> | 2024-12-16 07:45:34 +1030 |
---|---|---|
committer | Alan Modra <amodra@gmail.com> | 2024-12-16 09:13:16 +1030 |
commit | 35701ef3ea4a220d456d5ae1053a8630b24db388 (patch) | |
tree | 78431b520e4eed90321aef14212a572e05a159f2 /gdb/python/py-varobj.c | |
parent | 552ac612a3af0f11cbd0b2cad62e7952d401a268 (diff) | |
download | gdb-35701ef3ea4a220d456d5ae1053a8630b24db388.zip gdb-35701ef3ea4a220d456d5ae1053a8630b24db388.tar.gz gdb-35701ef3ea4a220d456d5ae1053a8630b24db388.tar.bz2 |
Move modification of bfd abs and und back to gas
In commit f592407e4d75 I deleted gas' obj_sec_set_private_data, and
instead put the gas modification of bfd's *ABS* and *UND* sections in
bfd_make_section_old_way. More recently in commit 8b5a21249537 I made
tekhex symbol creation use bfd_make_section_old_way for symbol
sections. After that we saw numerous non-repeatable oss-fuzz reports
of accesses to freed memory involving relocation symbols. I think
what is happening is:
A tekhex testcase with an absolute symbol is run through the tool,
modifying bfd_abs_section.symbol to point to a symbol on the bfd's
objalloc memory. On closing that bfd bfd_abs_section.symbol points to
freed memory.
A second testcase is run through the tool with some access to the
*ABS* symbol. This triggers the invalid memory access.
The same thing could happen if a user runs objdump or nm with two
files on the command line, the first being a tekhex file with absolute
symbols, or if ld is given tekhex input among other files. Clearly,
it's a bad idea to modify the *ABS* or *UND* sections for input files.
bfd/
* section.c (bfd_make_section_old_way): Don't call
_new_section_hook for standard abs, com, und and ind sections.
gas/
* as.c (bfd_std_section_init): New function.
(perform_an_assembly_pass): Move section initialisation to..
(gas_init): ..here. Use bfd_std_section_init.
Diffstat (limited to 'gdb/python/py-varobj.c')
0 files changed, 0 insertions, 0 deletions