diff options
author | Alan Modra <amodra@gmail.com> | 2025-05-09 13:16:24 +0930 |
---|---|---|
committer | Alan Modra <amodra@gmail.com> | 2025-05-11 22:51:14 +0930 |
commit | f7b623952aa74fcc6b1672453b11289010a48da1 (patch) | |
tree | 54ff242eeaf01d00eddb6edccba982f69905bedf /gdb/python/python.c | |
parent | 04b8dfff701edbc70459e30308b02320172492a1 (diff) | |
download | gdb-f7b623952aa74fcc6b1672453b11289010a48da1.zip gdb-f7b623952aa74fcc6b1672453b11289010a48da1.tar.gz gdb-f7b623952aa74fcc6b1672453b11289010a48da1.tar.bz2 |
msan: use of uninitialised data in get_cie_info
This completely bogus oss-fuzz x86 testcase results in a read from an
uninitialised (at the time check_eh_frame is called) part of an insn
frag:
.section .debug_frame
orl $1,x
.long x
.uleb128 0,x,0
x:
Fix the problem by verifying the assumption in get_cie_info that a CIE
starts at the beginning of .eh_frame or .debug_frame. Or at least
exclude silliness involving instructions placed there. That seems a
useful sanity check. Also sanity check sizes of initial FDE fields.
Yes, this doesn't completely stop the problem since you could place an
insn with a relocated field later in the CIE. If fuzzers find such a
testcase I'll ignore it.
* ehopt.c (struct cie_info): Add "f" field.
(get_cie_info): Return a bool. Verify frag at start of chain
is one with the CIE size found by check_eh_frame.
(check_eh_frame): Save CIE start frag. Only accept 4 or 8
byte fields in state_saw_size, state_saw_cie_offset and
state_saw_pc_begin. Formatting. Localise "fix" variable.
Diffstat (limited to 'gdb/python/python.c')
0 files changed, 0 insertions, 0 deletions