public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: Lancelot SIX via Gdb-patches <gdb-patches@sourceware.org>,
	gdb-patches@sourceware.org
Cc: lsix@lancelotsix.com, Lancelot SIX <lancelot.six@amd.com>
Subject: Re: [PATCH 2/3] gdb/varobj: Fix use after free in varobj
Date: Fri, 17 Jun 2022 17:09:25 +0100	[thread overview]
Message-ID: <87v8szclvu.fsf@redhat.com> (raw)
In-Reply-To: <20220617101024.2830260-3-lancelot.six@amd.com>

Lancelot SIX via Gdb-patches <gdb-patches@sourceware.org> writes:

> Varobj object contains references to types, variables (i.e. struct
> variable) and expression.  All of those can reference data on an
> objfile's obstack.  It is possible for this objfile to be deleted (and
> the obstack to be feed), while the varobj remains valid.  Later, if the
> user uses the varobj, this will result in a use-after-free error.  With
> address sanitizer build, this leads to a plain error.  For non address
> sanitizer build we might see undefined behaviour, which manifest
> themself as assertion failures when accessing data backed by feed
> memory.
>
> This can be observed if we create a varobj that refers to ta symbol in a
> shared library, after either the objfile gets reloaded (using the `file`
> command) or after the shared library is unloaded (with a call to dlclose
> for example).
>
> This patch fixes those issues by:
>
> - Adding cleanup procedure to the free_objfile observable.  When
>   activated this observer clears expressions referencing the objfile
>   being freed, and removes references to blocks belonging to this
>   objfile.
> - Adding varobj support in the `preserve_values` (gdb.value.c).  This
>   ensures that before the objfile is unloaded, any type owned by the
>   objfile referenced by the varobj is replaced by an equivalent type
>   not owned by the objfile.  This process is done here instead of in the
>   free_objfile observer in order to reuse the type hash table already
>   used for similar purpose when replacing types of values kept in the
>   value history.
>
> A consequence of those changes is that the varobj->root->exp field of a
> varobj can now be NULL.  The rest of the changes ensure that the varobj
> machinery is able to support such situation when re-evaluating the var
> (under varobj_update).
>
> When the varobj->root->exp is initialized, this patch also makes sure to
> keep a reference to its gdbarch and language_defn members.  Those
> structures outlive the objfile, so this is safe.  This is done because
> those references might be used initialize a python context even after
> exp is invalidated.  Another approach could have been to initialize the
> python context with default gdbarch and language_defn (i.e. nullptr) if
> expr is NULL, but since we might still try to display the value which
> was obtained by evaluating exp when it was still valid, keeping track of
> the context which was used at this time seems reasonable.
>
> Tested on x86_64-Linux.
> ---
>  .../gdb.mi/mi-var-invalidate-shlib-lib.c      | 30 +++++++
>  .../gdb.mi/mi-var-invalidate-shlib.c          | 27 +++++++
>  .../gdb.mi/mi-var-invalidate-shlib.exp        | 80 +++++++++++++++++++
>  gdb/testsuite/lib/mi-support.exp              |  2 +-
>  gdb/value.c                                   | 21 +++++
>  gdb/varobj.c                                  | 66 ++++++++++++++-
>  6 files changed, 224 insertions(+), 2 deletions(-)
>  create mode 100644 gdb/testsuite/gdb.mi/mi-var-invalidate-shlib-lib.c
>  create mode 100644 gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.c
>  create mode 100644 gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp
>
> diff --git a/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib-lib.c b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib-lib.c
> new file mode 100644
> index 00000000000..0abbdbdf9c6
> --- /dev/null
> +++ b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib-lib.c
> @@ -0,0 +1,30 @@
> +/* Copyright 2022 Free Software Foundation, Inc.
> +
> +   This file is part of GDB.
> +
> +   This program is free software; you can redistribute it and/or modify
> +   it under the terms of the GNU General Public License as published by
> +   the Free Software Foundation; either version 3 of the License, or
> +   (at your option) any later version.
> +
> +   This program is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +   GNU General Public License for more details.
> +
> +   You should have received a copy of the GNU General Public License
> +   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
> +
> +struct bar
> +{
> +  int a;
> +  int b;
> +};
> +
> +static struct bar global_var = { 2, 2 };
> +
> +void
> +foo ()
> +{
> +  struct bar local_var = { 1, 1 };
> +}
> diff --git a/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.c b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.c
> new file mode 100644
> index 00000000000..10101bb8d22
> --- /dev/null
> +++ b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.c
> @@ -0,0 +1,27 @@
> +/* Copyright 2022 Free Software Foundation, Inc.
> +
> +   This file is part of GDB.
> +
> +   This program is free software; you can redistribute it and/or modify
> +   it under the terms of the GNU General Public License as published by
> +   the Free Software Foundation; either version 3 of the License, or
> +   (at your option) any later version.
> +
> +   This program is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +   GNU General Public License for more details.
> +
> +   You should have received a copy of the GNU General Public License
> +   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
> +
> +#include <dlfcn.h>
> +
> +int
> +main (int argc, char *argv [])
> +{
> +  void *shlib = dlopen (SHLIB_PATH, RTLD_LAZY);
> +  void (*foo)() = dlsym (shlib, "foo");
> +  foo ();
> +  dlclose (shlib);
> +}
> diff --git a/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp
> new file mode 100644
> index 00000000000..5219946d845
> --- /dev/null
> +++ b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp
> @@ -0,0 +1,80 @@
> +# Copyright 2007-2022 Free Software Foundation, Inc.
> +
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program.  If not, see <http://www.gnu.org/licenses/>.
> +#
> +# Test that varobj are invalidated after the shlib they point to goes
> +# away.
> +
> +
> +load_lib mi-support.exp
> +set MIFLAGS "-i=mi"
> +
> +if { [skip_shlib_tests] } {
> +    return 0
> +}
> +
> +standard_testfile .c -lib.c
> +set shlib_path [standard_output_file ${testfile}-lib.so]
> +
> +if { [gdb_compile_shlib $srcdir/$subdir/$srcfile2 $shlib_path {debug}] != "" } {
> +    untested "failed to compile"
> +    return -1
> +}
> +
> +set opts [list shlib_load debug additional_flags=-DSHLIB_PATH="${shlib_path}"]
> +if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable $opts] != "" } {
> +    untested "failed to compile"
> +    return -1
> +}
> +
> +gdb_exit
> +if { [mi_gdb_start] } {
> +    return 0
> +}

Could/should the gdb_exit and mi_gdb_start calls be replaced with:

  if { [mi_clean_restart] } {
    # Should we have an unsupported call in here maybe?
    return
  }

> +
> +# Start the process once and create varobjs referencing the loaded objfiles.
> +with_test_prefix "setup" {
> +    mi_load_shlibs $shlib_path
> +    mi_delete_breakpoints
> +    mi_gdb_reinitialize_dir $srcdir/$subdir
> +    mi_gdb_load $binfile
> +
> +    mi_runto foo -pending
> +
> +    mi_create_varobj global_var global_var "create global gloal_var"
> +    mi_create_floating_varobj floating_local local_var "create floating local_var"
> +
> +    # Get ourself in a frame where the floating var is invalid.
> +    mi_gdb_test "-exec-finish" ".*"
> +    mi_expect_stop "function-finished" main ".*" ".*" "\[0-9\]+" { ".*" } "out of foo"
> +}
> +
> +# Reload the entire process

Missing '.' at the end.

> +with_test_prefix "restart process" {
> +    mi_delete_breakpoints
> +    mi_gdb_load ${binfile}
> +    mi_runto_main
> +}
> +
> +with_test_prefix "in new process" {
> +    # The global var was invalidated when the objfile got unloaded.
> +    mi_gdb_test "-var-update global_var" \
> +	"\\^done,changelist=\\\[\{name=\"global_var\",in_scope=\"invalid\",has_more=\"0\"\}\]" \
> +	"global invalidated"
> +
> +    # Floating varobj should still be valid, but out of scope at the moment.
> +    mi_gdb_test "-var-update floating_local" \
> +	"\\^done,changelist=\\\[{name=\"floating_local\",in_scope=\"false\",type_changed=\"false\",has_more=\"0\"}\\\]" \
> +	"floating_local still valid but not in scope"

For me, this test is failing, the output looks like:

  -var-update floating_local
  ^done,changelist=[{name="floating_local",in_scope="invalid",has_more="0"}]
  (gdb) 
  FAIL: gdb.mi/mi-var-invalidate-shlib.exp: in new process: floating_local still valid but not in scope (unexpected output)

But, once the next patch is applied, the test starts to pass.  So maybe
this test just needs moving into the next patch?

> +}
> diff --git a/gdb/testsuite/lib/mi-support.exp b/gdb/testsuite/lib/mi-support.exp
> index e724b2eeb51..ca56e12b06b 100644
> --- a/gdb/testsuite/lib/mi-support.exp
> +++ b/gdb/testsuite/lib/mi-support.exp
> @@ -1121,7 +1121,7 @@ proc mi_runto_helper {func run_or_continue args} {
>    global mi_gdb_prompt expect_out
>    global hex decimal fullname_syntax
>  
> -  parse_args {{qualified}}
> +  parse_args {{qualified} {pending}}
>  
>    set test "mi runto $func"
>    if {$pending} {
> diff --git a/gdb/value.c b/gdb/value.c
> index 022fca91a42..b9d2937c608 100644
> --- a/gdb/value.c
> +++ b/gdb/value.c
> @@ -46,6 +46,7 @@
>  #include "cli/cli-style.h"
>  #include "expop.h"
>  #include "inferior.h"
> +#include "varobj.h"
>  
>  /* Definition of a user function.  */
>  struct internal_function
> @@ -2596,6 +2597,21 @@ preserve_one_internalvar (struct internalvar *var, struct objfile *objfile,
>      }
>  }
>  
> +static void
> +preserve_one_varobj (struct varobj *varobj, struct objfile *objfile,
> +		     htab_t copied_types)

This function should have a comment before it.

> +{
> +  if (varobj->type->is_objfile_owned ()
> +      && varobj->type->objfile_owner () == objfile)
> +    {
> +      varobj->type
> +	= copy_type_recursive (objfile, varobj->type, copied_types);
> +    }
> +
> +  if (varobj->value != nullptr)
> +    preserve_one_value (varobj->value.get (), objfile, copied_types);
> +}
> +
>  /* Update the internal variables and value history when OBJFILE is
>     discarded; we must copy the types out of the objfile.  New global types
>     will be created for every convenience variable which currently points to
> @@ -2617,6 +2633,11 @@ preserve_values (struct objfile *objfile)
>    for (var = internalvars; var; var = var->next)
>      preserve_one_internalvar (var, objfile, copied_types.get ());
>  
> +  /* For the remaining varobj, check that none has type owned by OBJFILE.  */
> +  all_root_varobjs ([&copied_types, objfile](struct varobj *varobj)
> +		    { preserve_one_varobj (varobj, objfile,
> +					   copied_types.get ()); });
> +

I think the formatting here is a little off.  Looking through other
examples in GDB I think the most common layout would be:

  all_root_varobjs ([&copied_types, objfile] (struct varobj *varobj)
                    {
		      preserve_one_varobj (varobj, objfile,
					   copied_types.get ());
		    });


>    preserve_ext_lang_values (objfile, copied_types.get ());
>  }
>  
> diff --git a/gdb/varobj.c b/gdb/varobj.c
> index 1aca015a21a..caaffe4ea70 100644
> --- a/gdb/varobj.c
> +++ b/gdb/varobj.c
> @@ -32,6 +32,7 @@
>  #include "parser-defs.h"
>  #include "gdbarch.h"
>  #include <algorithm>
> +#include "observable.h"
>  
>  #if HAVE_PYTHON
>  #include "python/python.h"
> @@ -72,6 +73,12 @@ struct varobj_root
>    /* The expression for this parent.  */
>    expression_up exp;
>  
> +  /* Cached arch from exp, for use in case exp gets invalidated.  */
> +  struct gdbarch *gdbarch = nullptr;
> +
> +  /* Cached language from exp, for use in case exp gets invalidated.  */
> +  const struct language_defn *language_defn = nullptr;
> +
>    /* Block for which this expression is valid.  */
>    const struct block *valid_block = NULL;
>  
> @@ -206,7 +213,7 @@ is_root_p (const struct varobj *var)
>  
>  /* See python-internal.h.  */
>  gdbpy_enter_varobj::gdbpy_enter_varobj (const struct varobj *var)
> -: gdbpy_enter (var->root->exp->gdbarch, var->root->exp->language_defn)
> +: gdbpy_enter (var->root->gdbarch, var->root->language_defn)
>  {
>  }
>  
> @@ -303,6 +310,11 @@ varobj_create (const char *objname,
>        try
>  	{
>  	  var->root->exp = parse_exp_1 (&p, pc, block, 0, &tracker);
> +
> +	  /* Cache gdbarch and language_defn as they might be used even
> +	     after var is invalidated and var->root->exp cleared.  */
> +	  var->root->gdbarch = var->root->exp->gdbarch;
> +	  var->root->language_defn = var->root->exp->language_defn;
>  	}
>  
>        catch (const gdb_exception_error &except)
> @@ -2071,6 +2083,12 @@ value_of_root (struct varobj **var_handle, bool *type_changed)
>    {
>      struct value *value;
>  
> +    /* The expression have been invalidated (because it did reference an

'...expression HAS been invalidated (because IT REFERENCED an ...'

> +       objfile which is not available anymore) and we did not manage to
> +       recerate it for a floating varobj.  */

'... RECREATE ...'

> +    if ((*var_handle)->root->exp == nullptr)
> +      return nullptr;
> +

I notice that non of the tests in either this patch, or the next one,
exercise this condition.

Is it possible to create a test for this case?


>      value = value_of_root_1 (var_handle);
>      if (var->value == NULL || value == NULL)
>        {
> @@ -2373,6 +2391,49 @@ varobj_invalidate (void)
>    all_root_varobjs (varobj_invalidate_iter);
>  }
>  
> +/* Ensure that no varobj keep references to OBJFILE.  */
> +
> +static void
> +varobj_invalidate_if_uses_objfile (struct objfile *objfile)
> +{
> +  auto varobj_invalidate_if_uses_objfile_worker
> +    = [objfile](struct varobj *var)
> +      {
> +	if (var->root->valid_block != nullptr
> +	    && block_objfile (var->root->valid_block) == objfile)
> +	  {
> +	    /* The varobj is tied to a block which is going away.  There is
> +	       no way to reconstruct something later, so invalidate the
> +	       varobj completly and drop the reference to the block which is
> +	       being freed.  */
> +	    var->root->is_valid = false;
> +	    var->root->valid_block = nullptr;
> +	  }
> +
> +	if (var->root->exp != nullptr
> +	    && exp_uses_objfile (var->root->exp.get (), objfile))
> +	  {
> +	    /* The varobj's current expression references the objfile.  For
> +	       globals and floating, it is possible that when we try to
> +	       re-evaluate the expression later it is still valid with
> +	       whatever is in scope at this moment.  Just invalidate the
> +	       expression for now.  */

maybe '....is in scope at THAT moment.' ?

> +	    var->root->exp.reset ();
> +
> +	    /* It only makes sense to keep a floating varobj around.  */
> +	    if (!var->root->floating)
> +	      var->root->is_valid = false;
> +	  }
> +
> +	/* var->value->type and var->type might also reference the objfile.
> +	   This is taken care of in value.c:preserve_values which deals with
> +	   making sure that objfile-owend types are changed with gdbarch-owned
> +	   equivalents.  */

maybe ' ...types are REPLACED with .... ' ?

Thanks,
Andrew

> +      };
> +
> +  all_root_varobjs (varobj_invalidate_if_uses_objfile_worker);
> +}
> +
>  /* A hash function for a varobj.  */
>  
>  static hashval_t
> @@ -2407,4 +2468,7 @@ _initialize_varobj ()
>  			     _("When non-zero, varobj debugging is enabled."),
>  			     NULL, show_varobjdebug,
>  			     &setdebuglist, &showdebuglist);
> +
> +  gdb::observers::free_objfile.attach (varobj_invalidate_if_uses_objfile,
> +				       "varobj");
>  }
> -- 
> 2.25.1


  reply	other threads:[~2022-06-17 16:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-17 10:10 [PATCH 0/3] Fix some use-after-free errors in varobj code Lancelot SIX
2022-06-17 10:10 ` [PATCH 1/3] MI: mi_runto -pending Lancelot SIX
2022-06-17 10:10 ` [PATCH 2/3] gdb/varobj: Fix use after free in varobj Lancelot SIX
2022-06-17 16:09   ` Andrew Burgess [this message]
2022-06-17 16:38     ` Lancelot SIX
2022-06-20 15:52       ` Lancelot SIX
2022-06-30 18:43     ` Formatting/indentation of lambdas (Re: [PATCH 2/3] gdb/varobj: Fix use after free in varobj) Pedro Alves
2022-07-05 13:33       ` Lancelot SIX
2022-06-17 10:10 ` [PATCH 3/3] gdb/varobj: Fix varobj_invalidate_iter Lancelot SIX

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=87v8szclvu.fsf@redhat.com \
    --to=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=lancelot.six@amd.com \
    --cc=lsix@lancelotsix.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).