https://sourceware.org/bugzilla/show_bug.cgi?id=33701
Sunil Dora <SunilKumar.Dora at windriver dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |SunilKumar.Dora at windriver
dot c
| |om
--- Comment #4 from Sunil Dora <SunilKumar.Dora at windriver dot com> ---
Hi,
I was backporting 44b79abd0fa1 to binutils 2.42 for our distro and ran
into a problem that may be worth noting here for others doing the same.
On binutils-2_42-branch the fix on its own is not enough. It sets
debug_info_p to NULL when the debug info is DEBUG_INFO_UNAVAILABLE, but
in 2.42 process_debug_info() still passes debug_info_p to read_bases()
and then reads debug_info_p->rnglists_base without checking for NULL.
That check was added by these two commits, which went into 2.43 and are
on binutils-2_44-branch, but never made it onto binutils-2_42-branch:
301bfc45abb5 Fix null pointer dereference in process_debug_info()
0f8adbf77dd3 Re: Fix null pointer dereference in process_debug_info()
In fact the 2_42 branch tip (f9488b0d92b5) already segfaults there on
attachment 16507 with "readelf -w", before applying anything:
Program received signal SIGSEGV, Segmentation fault.
#0 read_bases (..., dwarf_version=5, debug_info_p=0x0, ...) dwarf.c
#1 process_debug_info (...) dwarf.c
What I see on x86_64 with the 2_42 branch:
- as is: SIGSEGV in read_bases()
- with 44b79abd0fa1 only: still SIGSEGV in read_bases()
- with 301bfc45abb5, 0f8adbf77dd3 and then 44b79abd0fa1: readelf
reports the errors and exits normally. readelf.exp and nm.exp pass.
If a 2.42 tree also carries e51fdff7d2e5 ("binutils/dwarf.c
debug_information leak"), as ours does, the testcase hits the abort from
this PR first, and applying 44b79abd0fa1 by itself just turns the abort
into the segfault above.
The two older commits cherry-pick cleanly onto binutils-2_42-branch.
44b79abd0fa1 needs a small context fix-up because the debug_info_p
initialiser is wrapped differently in 2.42. 2.38 and 2.40 don't have the
read_bases() call, so they only need the fix itself.
Is binutils-2_42-branch still open for this kind of backport? If so I
can send the three commits to the binutils list. If not, hopefully this
note saves someone else the same detour.
--
You are receiving this mail because:
You are on the CC list for the bug.
