public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] gdb: fix nullptr dereference in block::ranges() Date: Thu, 28 Apr 2022 14:10:03 +0000 (GMT) [thread overview] Message-ID: <20220428141003.6C3CE3856DE8@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c42dd30d73ec441ed9cab207597c7f5ce88ee231 commit c42dd30d73ec441ed9cab207597c7f5ce88ee231 Author: Andrew Burgess <aburgess@redhat.com> Date: Thu Apr 28 11:37:51 2022 +0100 gdb: fix nullptr dereference in block::ranges() This commit: commit f5cb8afdd297dd68273d98a10fbfd350dff918d8 Date: Sun Feb 6 22:27:53 2022 -0500 gdb: remove BLOCK_RANGES macro introduces a potential nullptr dereference in block::ranges, this is breaking most tests, e.g. gdb.base/break.exp is failing for me. In the above patch BLOCK_CONTIGUOUS_P is changed from this: #define BLOCK_CONTIGUOUS_P(bl) (BLOCK_RANGES (bl) == nullptr \ || BLOCK_NRANGES (bl) <= 1) to this: #define BLOCK_CONTIGUOUS_P(bl) ((bl)->ranges ().size () == 0 \ || (bl)->ranges ().size () == 1) So, before the commit we checked for the block ranges being nullptr, but afterwards we just call block::ranges() in all cases. The problem is that block::ranges() looks like this: /* Return a view on this block's ranges. */ gdb::array_view<blockrange> ranges () { return gdb::make_array_view (m_ranges->range, m_ranges->nranges); } where m_ranges is: struct blockranges *m_ranges; And so, we see that the nullptr check has been lost, and we might end up dereferencing a nullptr. My proposed fix is to move the nullptr check into block::ranges, and return an explicit empty array_view if m_ranges is nullptr. After this, everything seems fine again. Diff: --- gdb/block.h | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/gdb/block.h b/gdb/block.h index b9f4e974c04..038ce7bd2f3 100644 --- a/gdb/block.h +++ b/gdb/block.h @@ -157,11 +157,21 @@ struct block /* Return a view on this block's ranges. */ gdb::array_view<blockrange> ranges () - { return gdb::make_array_view (m_ranges->range, m_ranges->nranges); } + { + if (m_ranges == nullptr) + return {}; + else + return gdb::make_array_view (m_ranges->range, m_ranges->nranges); + } /* Const version of the above. */ gdb::array_view<const blockrange> ranges () const - { return gdb::make_array_view (m_ranges->range, m_ranges->nranges); } + { + if (m_ranges == nullptr) + return {}; + else + return gdb::make_array_view (m_ranges->range, m_ranges->nranges); + } /* Set this block's ranges array. */ void set_ranges (blockranges *ranges)
reply other threads:[~2022-04-28 14:10 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20220428141003.6C3CE3856DE8@sourceware.org \ --to=aburgess@sourceware.org \ --cc=gdb-cvs@sourceware.org \ /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: linkBe 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).