From: Xishi Qiu <qiuxishi@huawei.com>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Michal Hocko <mhocko@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Mel Gorman <mgorman@techsingularity.net>,
Michal Hocko <mhocko@suse.com>, Vlastimil Babka <vbabka@suse.cz>,
Minchan Kim <minchan@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
aarcange@redhat.com, sumeet.keswani@hpe.com,
Rik van Riel <riel@redhat.com>, Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
zhong jiang <zhongjiang@huawei.com>
Subject: Re: mm, something wring in page_lock_anon_vma_read()?
Date: Sat, 20 May 2017 10:18:54 +0800 [thread overview]
Message-ID: <591FA78E.9050307@huawei.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1705191852360.11060@eggly.anvils>
On 2017/5/20 10:02, Hugh Dickins wrote:
> On Sat, 20 May 2017, Xishi Qiu wrote:
>> On 2017/5/20 6:00, Hugh Dickins wrote:
>>>
>>> You're ignoring the rcu_read_lock() on entry to page_lock_anon_vma_read(),
>>> and the SLAB_DESTROY_BY_RCU (recently renamed SLAB_TYPESAFE_BY_RCU) nature
>>> of the anon_vma_cachep kmem cache. It is not safe to muck with anon_vma->
>>> root in anon_vma_free(), others could still be looking at it.
>>>
>>> Hugh
>>>
>>
>> Hi Hugh,
>>
>> Thanks for your reply.
>>
>> SLAB_DESTROY_BY_RCU will let it call call_rcu() in free_slab(), but if the
>> anon_vma *reuse* by someone again, access root_anon_vma is not safe, right?
>
> That is safe, on reuse it is still a struct anon_vma; then the test for
> !page_mapped(page) will show that it's no longer a reliable anon_vma for
> this page, so page_lock_anon_vma_read() returns NULL.
>
> But of course, if page->_mapcount has been corrupted or misaccounted,
> it may think page_mapped(page) when actually page is not mapped,
> and the anon_vma is not good for it.
>
Hi Hugh,
Here is a bug report form redhat: https://bugzilla.redhat.com/show_bug.cgi?id=1305620
And I meet the bug too. However it is hard to reproduce, and
624483f3ea82598("mm: rmap: fix use-after-free in __put_anon_vma") is not help.
>From the vmcore, it seems that the page is still mapped(_mapcount=0 and _count=2),
and the value of mapping is a valid address(mapping = 0xffff8801b3e2a101),
but anon_vma has been corrupted.
Any ideas?
Thanks,
Xishi Qiu
>>
>> e.g. if I clean the root pointer before free it, then access root_anon_vma
>> in page_lock_anon_vma_read() is NULL pointer access, right?
>
> Yes, cleaning root pointer before free may result in NULL pointer access.
>
> Hugh
>
>>
>> anon_vma_free()
>> ...
>> anon_vma->root = NULL;
>> kmem_cache_free(anon_vma_cachep, anon_vma);
>> ...
>>
>> Thanks,
>> Xishi Qiu
>
> .
>
--
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: Xishi Qiu <qiuxishi@huawei.com>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Michal Hocko <mhocko@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
"Mel Gorman" <mgorman@techsingularity.net>,
Michal Hocko <mhocko@suse.com>, Vlastimil Babka <vbabka@suse.cz>,
Minchan Kim <minchan@kernel.org>,
"David Rientjes" <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>, <aarcange@redhat.com>,
<sumeet.keswani@hpe.com>, Rik van Riel <riel@redhat.com>,
Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
zhong jiang <zhongjiang@huawei.com>
Subject: Re: mm, something wring in page_lock_anon_vma_read()?
Date: Sat, 20 May 2017 10:18:54 +0800 [thread overview]
Message-ID: <591FA78E.9050307@huawei.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1705191852360.11060@eggly.anvils>
On 2017/5/20 10:02, Hugh Dickins wrote:
> On Sat, 20 May 2017, Xishi Qiu wrote:
>> On 2017/5/20 6:00, Hugh Dickins wrote:
>>>
>>> You're ignoring the rcu_read_lock() on entry to page_lock_anon_vma_read(),
>>> and the SLAB_DESTROY_BY_RCU (recently renamed SLAB_TYPESAFE_BY_RCU) nature
>>> of the anon_vma_cachep kmem cache. It is not safe to muck with anon_vma->
>>> root in anon_vma_free(), others could still be looking at it.
>>>
>>> Hugh
>>>
>>
>> Hi Hugh,
>>
>> Thanks for your reply.
>>
>> SLAB_DESTROY_BY_RCU will let it call call_rcu() in free_slab(), but if the
>> anon_vma *reuse* by someone again, access root_anon_vma is not safe, right?
>
> That is safe, on reuse it is still a struct anon_vma; then the test for
> !page_mapped(page) will show that it's no longer a reliable anon_vma for
> this page, so page_lock_anon_vma_read() returns NULL.
>
> But of course, if page->_mapcount has been corrupted or misaccounted,
> it may think page_mapped(page) when actually page is not mapped,
> and the anon_vma is not good for it.
>
Hi Hugh,
Here is a bug report form redhat: https://bugzilla.redhat.com/show_bug.cgi?id=1305620
And I meet the bug too. However it is hard to reproduce, and
624483f3ea82598("mm: rmap: fix use-after-free in __put_anon_vma") is not help.
>From the vmcore, it seems that the page is still mapped(_mapcount=0 and _count=2),
and the value of mapping is a valid address(mapping = 0xffff8801b3e2a101),
but anon_vma has been corrupted.
Any ideas?
Thanks,
Xishi Qiu
>>
>> e.g. if I clean the root pointer before free it, then access root_anon_vma
>> in page_lock_anon_vma_read() is NULL pointer access, right?
>
> Yes, cleaning root pointer before free may result in NULL pointer access.
>
> Hugh
>
>>
>> anon_vma_free()
>> ...
>> anon_vma->root = NULL;
>> kmem_cache_free(anon_vma_cachep, anon_vma);
>> ...
>>
>> Thanks,
>> Xishi Qiu
>
> .
>
next prev parent reply other threads:[~2017-05-20 2:24 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 9:46 mm, something wring in page_lock_anon_vma_read()? Xishi Qiu
2017-05-18 9:46 ` Xishi Qiu
2017-05-19 8:52 ` Xishi Qiu
2017-05-19 8:52 ` Xishi Qiu
2017-05-19 9:44 ` Xishi Qiu
2017-05-19 9:44 ` Xishi Qiu
2017-05-19 22:00 ` Hugh Dickins
2017-05-19 22:00 ` Hugh Dickins
2017-05-20 1:21 ` Xishi Qiu
2017-05-20 1:21 ` Xishi Qiu
2017-05-20 2:02 ` Hugh Dickins
2017-05-20 2:02 ` Hugh Dickins
2017-05-20 2:18 ` Xishi Qiu [this message]
2017-05-20 2:18 ` Xishi Qiu
2017-05-20 2:40 ` Hugh Dickins
2017-05-20 2:40 ` Hugh Dickins
2017-05-20 3:01 ` zhong jiang
2017-05-20 3:01 ` zhong jiang
2017-05-22 16:51 ` Vlastimil Babka
2017-05-22 16:51 ` Vlastimil Babka
2017-05-23 9:21 ` zhong jiang
2017-05-23 9:21 ` zhong jiang
2017-05-23 9:33 ` Vlastimil Babka
2017-05-23 9:33 ` Vlastimil Babka
2017-05-23 10:32 ` zhong jiang
2017-05-23 10:32 ` zhong jiang
2017-06-08 13:44 ` Xishi Qiu
2017-06-08 13:44 ` Xishi Qiu
2017-06-08 13:59 ` Vlastimil Babka
2017-06-08 13:59 ` Vlastimil Babka
2017-06-08 14:11 ` zhong jiang
2017-06-08 14:11 ` zhong jiang
2017-07-18 10:59 ` mm, something wrong " Xishi Qiu
2017-07-18 10:59 ` Xishi Qiu
2017-07-19 8:40 ` Vlastimil Babka
2017-07-19 8:40 ` Vlastimil Babka
2017-07-19 9:59 ` Xishi Qiu
2017-07-19 9:59 ` Xishi Qiu
2017-07-20 12:58 ` Andrea Arcangeli
2017-07-20 12:58 ` Andrea Arcangeli
2017-07-20 16:15 ` Andrea Arcangeli
2017-07-20 16:15 ` Andrea Arcangeli
2017-05-22 9:48 ` mm, something wring " Xishi Qiu
2017-05-22 9:48 ` Xishi Qiu
2017-05-22 19:26 ` Hugh Dickins
2017-05-22 19:26 ` Hugh Dickins
2017-05-23 2:19 ` Xishi Qiu
2017-05-23 2:19 ` Xishi Qiu
2017-05-23 2:51 ` Hugh Dickins
2017-05-23 2:51 ` Hugh Dickins
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=591FA78E.9050307@huawei.com \
--to=qiuxishi@huawei.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=sumeet.keswani@hpe.com \
--cc=tj@kernel.org \
--cc=vbabka@suse.cz \
--cc=zhongjiang@huawei.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.