public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tromey@adacore.com>, Andrew Burgess <aburgess@redhat.com>
Subject: [PATCH] gdb: fix buffer overflow in DWARF reader
Date: Thu, 14 Sep 2023 16:48:09 +0100	[thread overview]
Message-ID: <281fdfc6ef3997cfab17d2379b51b208c0e00070.1694706424.git.aburgess@redhat.com> (raw)

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.
---
 gdb/dwarf2/read.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 98bedbc5d49..0f4d99109fb 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -10548,7 +10548,7 @@ read_call_site_scope (struct die_info *die, struct dwarf2_cu *cu)
 	  std::vector<unrelocated_addr> addresses;
 	  dwarf2_ranges_read_low_addrs (ranges_offset, target_cu,
 					target_die->tag, addresses);
-	  unrelocated_addr *saved = XOBNEWVAR (&objfile->objfile_obstack,
+	  unrelocated_addr *saved = XOBNEWVEC (&objfile->objfile_obstack,
 					       unrelocated_addr,
 					       addresses.size ());
 	  std::copy (addresses.begin (), addresses.end (), saved);

base-commit: d7680f13df105aa8fa0edbdf8efae31a5411f579
-- 
2.25.4


             reply	other threads:[~2023-09-14 15:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-14 15:48 Andrew Burgess [this message]
2023-09-14 16:03 ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=281fdfc6ef3997cfab17d2379b51b208c0e00070.1694706424.git.aburgess@redhat.com \
    --to=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@adacore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).