From: Andrey Ryabinin <a.ryabinin@samsung.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
dvyukov@google.com, koct9i@gmail.com
Subject: Re: [PATCH] mm: rmap: fix use-after-free in __put_anon_vma
Date: Fri, 06 Jun 2014 18:16:58 +0400 [thread overview]
Message-ID: <5391CD5A.20503@samsung.com> (raw)
In-Reply-To: <20140606115620.GS3213@twins.programming.kicks-ass.net>
On 06/06/14 15:56, Peter Zijlstra wrote:
> On Fri, Jun 06, 2014 at 03:30:55PM +0400, Andrey Ryabinin wrote:
>> While working address sanitizer for kernel I've discovered use-after-free
>> bug in __put_anon_vma.
>> For the last anon_vma, anon_vma->root freed before child anon_vma.
>> Later in anon_vma_free(anon_vma) we are referencing to already freed anon_vma->root
>> to check rwsem.
>> This patch puts freeing of child anon_vma before freeing of anon_vma->root.
>
> Yes, I think that is right indeed.
>
> Very hard to hit, but valid since not all callers hold rcu_read_lock().
>
>>
>> Cc: stable@vger.kernel.org # v3.0+
>> Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
>> ---
>> mm/rmap.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index 9c3e773..161bffc7 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -1564,10 +1564,11 @@ void __put_anon_vma(struct anon_vma *anon_vma)
>> {
>> struct anon_vma *root = anon_vma->root;
>>
>> - if (root != anon_vma && atomic_dec_and_test(&root->refcount))
>> + if (root != anon_vma && atomic_dec_and_test(&root->refcount)) {
>> + anon_vma_free(anon_vma);
>> anon_vma_free(root);
>> -
>> - anon_vma_free(anon_vma);
>> + } else
>> + anon_vma_free(anon_vma);
>> }
>
> Why not simply move the freeing of anon_vma before the root, like:
>
> anon_vma_free(anon_vma);
> if (root != anon_vma && atomic_dec_and_test(&root->refcount))
> anon_vma_free(root);
>
> ?
>
IMO It looks more logical to decrement root's refcounter before freeing child vma.
In fact I wasn't completely sure that it is safe to do so. But after some digging,
now it looks safe to me.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Andrey Ryabinin <a.ryabinin@samsung.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
dvyukov@google.com, koct9i@gmail.com
Subject: Re: [PATCH] mm: rmap: fix use-after-free in __put_anon_vma
Date: Fri, 06 Jun 2014 18:16:58 +0400 [thread overview]
Message-ID: <5391CD5A.20503@samsung.com> (raw)
In-Reply-To: <20140606115620.GS3213@twins.programming.kicks-ass.net>
On 06/06/14 15:56, Peter Zijlstra wrote:
> On Fri, Jun 06, 2014 at 03:30:55PM +0400, Andrey Ryabinin wrote:
>> While working address sanitizer for kernel I've discovered use-after-free
>> bug in __put_anon_vma.
>> For the last anon_vma, anon_vma->root freed before child anon_vma.
>> Later in anon_vma_free(anon_vma) we are referencing to already freed anon_vma->root
>> to check rwsem.
>> This patch puts freeing of child anon_vma before freeing of anon_vma->root.
>
> Yes, I think that is right indeed.
>
> Very hard to hit, but valid since not all callers hold rcu_read_lock().
>
>>
>> Cc: stable@vger.kernel.org # v3.0+
>> Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
>> ---
>> mm/rmap.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index 9c3e773..161bffc7 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -1564,10 +1564,11 @@ void __put_anon_vma(struct anon_vma *anon_vma)
>> {
>> struct anon_vma *root = anon_vma->root;
>>
>> - if (root != anon_vma && atomic_dec_and_test(&root->refcount))
>> + if (root != anon_vma && atomic_dec_and_test(&root->refcount)) {
>> + anon_vma_free(anon_vma);
>> anon_vma_free(root);
>> -
>> - anon_vma_free(anon_vma);
>> + } else
>> + anon_vma_free(anon_vma);
>> }
>
> Why not simply move the freeing of anon_vma before the root, like:
>
> anon_vma_free(anon_vma);
> if (root != anon_vma && atomic_dec_and_test(&root->refcount))
> anon_vma_free(root);
>
> ?
>
IMO It looks more logical to decrement root's refcounter before freeing child vma.
In fact I wasn't completely sure that it is safe to do so. But after some digging,
now it looks safe to me.
next prev parent reply other threads:[~2014-06-06 14:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-06 11:30 [PATCH] mm: rmap: fix use-after-free in __put_anon_vma Andrey Ryabinin
2014-06-06 11:30 ` Andrey Ryabinin
2014-06-06 11:56 ` Peter Zijlstra
2014-06-06 14:16 ` Andrey Ryabinin [this message]
2014-06-06 14:16 ` Andrey Ryabinin
2014-06-06 15:09 ` [PATCH v2] " Andrey Ryabinin
2014-06-06 15:09 ` Andrey Ryabinin
2014-06-06 15:30 ` Peter Zijlstra
2014-06-06 15:30 ` Peter Zijlstra
2014-06-07 21:50 ` David Rientjes
2014-06-07 21:50 ` David Rientjes
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=5391CD5A.20503@samsung.com \
--to=a.ryabinin@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=koct9i@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.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 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.