All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreea Bernat <bernat.ada@gmail.com>
To: David Howells <dhowells@redhat.com>
Cc: shemming@brocade.com, linux-kernel@vger.kernel.org,
	paulmck@linux.vnet.ibm.com
Subject: Re: [PATCH RFC] rcu: assoc_array: Add critical section to avoid a bug
Date: Fri, 29 Aug 2014 20:57:18 +0300	[thread overview]
Message-ID: <20140829175718.GA860@ada> (raw)
In-Reply-To: <3614.1409225551@warthog.procyon.org.uk>

On Thu, Aug 28, 2014 at 12:32:31PM +0100, David Howells wrote:
> Andreea-Cristina Bernat <bernat.ada@gmail.com> wrote:
> 
> > * The function "assoc_array_gc()" could be preempted between the call to
> > "assoc_array_apply_edit()" call and the assignment
> > "edit->array->nr_leaves_on_tree = nr_leaves_on_tree;", so the grace
> > period could complete.
> 
> The bug is real, but this patch isn't the right solution.
> 
> The edit script should be considered inaccessible to a function the moment it
> calls assoc_array_apply_edit() or assoc_array_cancel_edit().  I think this is
> a better way.
> 
> David
> ---
>  assoc_array.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> commit 10c26fcc224c0515e15272515e7b9006cb08adc8
> Author: David Howells <dhowells@redhat.com>
> Date:   Wed Aug 27 18:39:44 2014 +0100
> 
>     KEYS: Fix use-after-free in assoc_array_gc()
>     
>     An edit script should be considered inaccessible by a function once it has
>     called assoc_array_apply_edit() or assoc_array_cancel_edit().
>     
>     However, assoc_array_gc() is accessing the edit script just after the
>     gc_complete: label.
>     
>     Reported-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
>     Signed-off-by: David Howells <dhowells@redhat.com>
> 
> diff --git a/lib/assoc_array.c b/lib/assoc_array.c
> index c0b1007011e1..ae146f0734eb 100644
> --- a/lib/assoc_array.c
> +++ b/lib/assoc_array.c
> @@ -1735,7 +1735,7 @@ ascend_old_tree:
>  gc_complete:
>  	edit->set[0].to = new_root;
>  	assoc_array_apply_edit(edit);
> -	edit->array->nr_leaves_on_tree = nr_leaves_on_tree;
> +	array->nr_leaves_on_tree = nr_leaves_on_tree;
>  	return 0;

Looks good to me.

Regards,
Andreea

>  
>  enomem:

  reply	other threads:[~2014-08-29 17:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-26 15:41 [PATCH RFC] rcu: assoc_array: Add critical section to avoid a bug Andreea-Cristina Bernat
2014-08-28 11:32 ` David Howells
2014-08-29 17:57   ` Andreea Bernat [this message]
2014-08-29 22:49     ` David Howells
2014-08-29 23:08       ` Andreea Bernat

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=20140829175718.GA860@ada \
    --to=bernat.ada@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=shemming@brocade.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.