ed8eee7ab5
Backport upstream commit 54392c4df604f20 to fix an incorrect obstack allocation that wold lead to memory corruption (RHBZ 2237392).
69 lines
2.6 KiB
Diff
69 lines
2.6 KiB
Diff
From FEDORA_PATCHES Mon Sep 17 00:00:00 2001
|
|
From: Andrew Burgess <aburgess@redhat.com>
|
|
Date: Thu, 14 Sep 2023 13:06:26 +0100
|
|
Subject: gdb-bz2237392-dwarf-obstack-allocation.patch
|
|
|
|
;; Backport upstream commit 54392c4df604f20 to fix an incorrect
|
|
;; obstack allocation that wold lead to memory corruption.
|
|
|
|
gdb: fix buffer overflow in DWARF reader
|
|
|
|
In this commit:
|
|
|
|
commit 48ac197b0c209ccf1f2de9704eb6cdf7c5c73a8e
|
|
Date: Fri Nov 19 10:12:44 2021 -0700
|
|
|
|
Handle multiple addresses in call_site_target
|
|
|
|
a buffer overflow bug was introduced when the following code was
|
|
added:
|
|
|
|
CORE_ADDR *saved = XOBNEWVAR (&objfile->objfile_obstack, CORE_ADDR,
|
|
addresses.size ());
|
|
std::copy (addresses.begin (), addresses.end (), saved);
|
|
|
|
The definition of XOBNEWVAR is (from libiberty.h):
|
|
|
|
#define XOBNEWVAR(O, T, S) ((T *) obstack_alloc ((O), (S)))
|
|
|
|
So 'saved' is going to point to addresses.size () bytes of memory,
|
|
however, the std::copy will write addresses.size () number of
|
|
CORE_ADDR sized entries to the address pointed to by 'saved', this is
|
|
going to result in memory corruption.
|
|
|
|
The mistake is that we should have used XOBNEWVEC, which allocates a
|
|
vector of entries, the definition of XOBNEWVEC is:
|
|
|
|
#define XOBNEWVEC(O, T, N) \
|
|
((T *) obstack_alloc ((O), sizeof (T) * (N)))
|
|
|
|
Which means we will have set aside enough space to create a copy of
|
|
the contents of the addresses vector.
|
|
|
|
I'm not sure how to create a test for this problem, this issue cropped
|
|
up when debugging a particular i686 built binary, which just happened
|
|
to trigger a glibc assertion (likely due to random memory corruption),
|
|
debugging the same binary built for x86-64 appeared to work just fine.
|
|
|
|
Using valgrind on the failing GDB binary pointed straight to the cause
|
|
of the problem, and with this patch in place there are no longer
|
|
valgrind errors in this area.
|
|
|
|
If anyone has ideas for a test I'm happy to work on something.
|
|
|
|
Co-Authored-By: Keith Seitz <keiths@redhat.com>
|
|
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
|
|
--- a/gdb/dwarf2/read.c
|
|
+++ b/gdb/dwarf2/read.c
|
|
@@ -12506,7 +12506,7 @@ read_call_site_scope (struct die_info *die, struct dwarf2_cu *cu)
|
|
std::vector<CORE_ADDR> addresses;
|
|
dwarf2_ranges_read_low_addrs (ranges_offset, target_cu,
|
|
target_die->tag, addresses);
|
|
- CORE_ADDR *saved = XOBNEWVAR (&objfile->objfile_obstack, CORE_ADDR,
|
|
+ CORE_ADDR *saved = XOBNEWVEC (&objfile->objfile_obstack, CORE_ADDR,
|
|
addresses.size ());
|
|
std::copy (addresses.begin (), addresses.end (), saved);
|
|
call_site->target.set_loc_array (addresses.size (), saved);
|