From: Andrew Burgess <aburgess@redhat.com>
To: Simon Marchi <simark@simark.ca>,
Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
Cc: Simon Marchi <simon.marchi@efficios.com>
Subject: Re: [PATCH] gdb: fix use-after-free in check_longjmp_breakpoint_for_call_dummy
Date: Fri, 12 May 2023 11:19:35 +0100 [thread overview]
Message-ID: <87v8gx6edk.fsf@redhat.com> (raw)
In-Reply-To: <b4646d98-a5f0-c85d-4267-86935d1c4dcf@simark.ca>
Simon Marchi <simark@simark.ca> writes:
> On 5/10/23 05:12, Andrew Burgess via Gdb-patches wrote:
>>> @@ -7608,9 +7609,13 @@ set_longjmp_breakpoint_for_call_dummy (void)
>>> void
>>> check_longjmp_breakpoint_for_call_dummy (struct thread_info *tp)
>>> {
>>> - for (struct breakpoint *b : all_breakpoints_safe ())
>>> + /* We would need to delete breakpoints other than the current one while
>>> + iterating, so all_breakpoints_safe is not sufficient to make that safe.
>>> + Save all breakpoints to delete in that set and delete them at the end. */
>>> + std::unordered_set<breakpoint *> to_delete;
>>
>> Hi,
>>
>> For my own education: why did you choose a std::unordered_set here? I
>> would assume that we will never find the same related breakpoint more
>> than once. Indeed, if we did then I suspect the old code would have
>> resulted in a double free.
>>
>> So why choose a set over a vector?
>
> We look for bp_longjmp_call_dummy breakpoints, which are documented like
> this:
>
> /* Breakpoint placed to the same location(s) like bp_longjmp but used to
> protect against stale DUMMY_FRAME. Multiple bp_longjmp_call_dummy and
> one bp_call_dummy are chained together by related_breakpoint for each
> DUMMY_FRAME. */
>
> I can imagine this happening: suppose X and Y are two related
> bp_longjmp_call_dummy breakpoints, following each other in
> breakpoint_chain. When looking at X, we will insert X and Y in
> to_delete. We will then look at X, and we will try to insert X and Y
> again in to_delete.
>
> The old code wouldn't double free or use-after-free, because of its
> special handling of B_TMP. When looking at X, we would delete Y and
> then X. And if Y happened to be the next iteration value (saved in the
> B_TMP variable), we would modify B_TMP to avoid iterating on Y.
Thanks for the explanation.
Andrew
prev parent reply other threads:[~2023-05-12 10:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-08 14:59 Simon Marchi
2023-05-09 14:21 ` Tom Tromey
2023-05-09 17:48 ` Simon Marchi
2023-05-10 9:12 ` Andrew Burgess
2023-05-10 11:50 ` Simon Marchi
2023-05-12 10:19 ` Andrew Burgess [this message]
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=87v8gx6edk.fsf@redhat.com \
--to=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
--cc=simon.marchi@efficios.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).