aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/python.c
diff options
context:
space:
mode:
authorAlan Modra <amodra@gmail.com>2025-05-09 13:16:24 +0930
committerAlan Modra <amodra@gmail.com>2025-05-11 22:51:14 +0930
commitf7b623952aa74fcc6b1672453b11289010a48da1 (patch)
tree54ff242eeaf01d00eddb6edccba982f69905bedf /gdb/python/python.c
parent04b8dfff701edbc70459e30308b02320172492a1 (diff)
downloadgdb-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