public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug python/30044] Flawed logic when releasing values from all_values buffer
Date: Mon, 27 Feb 2023 22:56:25 +0000	[thread overview]
Message-ID: <bug-30044-4717-pLT8Q7XPWk@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-30044-4717@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=30044

--- Comment #12 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f3d3bbbcdd8af6295458eee3b023447c13edabd3

commit f3d3bbbcdd8af6295458eee3b023447c13edabd3
Author: Tom Tromey <tom@tromey.com>
Date:   Wed Feb 8 13:59:36 2023 -0700

    Fix value chain use-after-free

    Hannes filed a bug showing a crash, where a pretty-printer written in
    Python could cause a use-after-free.  He sent a patch, but I thought a
    different approach was needed.

    In a much earlier patch (see bug #12533), we changed the Python code
    to release new values from the value chain when constructing a
    gdb.Value.  The rationale for this is that if you write a command that
    does a lot of computations in a loop, all the values will be kept live
    by the value chain, resulting in gdb using a large amount of memory.

    However, suppose a value is passed to Python from some code in gdb
    that needs to use the value after the call into Python.  In this
    scenario, value_to_value_object will still release the value -- and
    because gdb code doesn't generally keep strong references to values (a
    consequence of the ancient decision to use the value chain to avoid
    memory management), this will result in a use-after-free.

    This scenario can happen, as it turns out, when a value is passed to
    Python for pretty-printing.  Now, normally this route boxes the value
    via value_to_value_object_no_release, avoiding the problematic release
    from the value chain.  However, if you then call Value.cast, the
    underlying value API might return the same value, when is then
    released from the chain.

    This patch fixes the problem by changing how value boxing is done.
    value_to_value_object no longer removes a value from the chain.
    Instead, every spot in gdb that might construct new values uses a
    scoped_value_mark to ensure that the requirements of bug #12533 are
    met.  And, because incoming values aren't ever released from the chain
    (the Value.cast one comes earlier on the chain than the
    scoped_value_mark), the bug can no longer occur.  (Note that many
    spots in the Python layer already take this approach, so not many
    places needed to be touched.)

    In the future I think we should replace the use of raw "value *" with
    value_ref_ptr pretty much everywhere.  This will ensure lifetime
    safety throughout gdb.

    The test case in this patch comes from Hannes' original patch.  I only
    made a trivial ("require") change to it.  However, while this fails
    for him, I can't make it fail on this machine; nevertheless, he tried
    my patch and reported the bug as being fixed.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30044

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2023-02-27 22:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-24 18:59 [Bug python/30044] New: " ssbssa at sourceware dot org
2023-01-24 19:00 ` [Bug python/30044] " ssbssa at sourceware dot org
2023-01-24 19:01 ` ssbssa at sourceware dot org
2023-01-24 19:01 ` ssbssa at sourceware dot org
2023-01-24 19:02 ` ssbssa at sourceware dot org
2023-01-24 19:02 ` ssbssa at sourceware dot org
2023-01-24 19:03 ` ssbssa at sourceware dot org
2023-01-24 19:04 ` ssbssa at sourceware dot org
2023-01-24 19:07 ` tromey at sourceware dot org
2023-01-30 22:16 ` tromey at sourceware dot org
2023-01-30 23:22 ` tromey at sourceware dot org
2023-01-31  1:46 ` tromey at sourceware dot org
2023-01-31  2:04 ` tromey at sourceware dot org
2023-01-31 18:29 ` ssbssa at sourceware dot org
2023-02-11  1:13 ` tromey at sourceware dot org
2023-02-27 22:56 ` cvs-commit at gcc dot gnu.org [this message]
2023-02-27 22:57 ` tromey at sourceware dot org

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=bug-30044-4717-pLT8Q7XPWk@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@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: 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).