All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: Robin Holt <holt@sgi.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	linux-mm@kvack.org, Wanpeng Li <liwanp@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, Hugh Dickins <hughd@google.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sagi Grimberg <sagig@mellanox.co.il>,
	Haggai Eran <haggaie@mellanox.com>
Subject: Re: [PATCH] [Patch] mmu_notifier_unregister NULL Pointer deref fix.
Date: Fri, 18 Jan 2013 10:42:07 +0800	[thread overview]
Message-ID: <50F8B67F.4090901@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130117134523.GN3438@sgi.com>

On 01/17/2013 09:45 PM, Robin Holt wrote:
> On Thu, Jan 17, 2013 at 08:19:55PM +0800, Xiao Guangrong wrote:
>> On 01/17/2013 07:12 PM, Robin Holt wrote:
>>> On Thu, Jan 17, 2013 at 10:45:32AM +0800, Xiao Guangrong wrote:
>>>> On 01/17/2013 05:01 AM, Robin Holt wrote:
>>>>>
>>>>> There is a race condition between mmu_notifier_unregister() and
>>>>> __mmu_notifier_release().
>>>>>
>>>>> Assume two tasks, one calling mmu_notifier_unregister() as a result
>>>>> of a filp_close() ->flush() callout (task A), and the other calling
>>>>> mmu_notifier_release() from an mmput() (task B).
>>>>>
>>>>>                 A                               B
>>>>> t1                                              srcu_read_lock()
>>>>> t2              if (!hlist_unhashed())
>>>>> t3                                              srcu_read_unlock()
>>>>> t4              srcu_read_lock()
>>>>> t5                                              hlist_del_init_rcu()
>>>>> t6                                              synchronize_srcu()
>>>>> t7              srcu_read_unlock()
>>>>> t8              hlist_del_rcu()  <--- NULL pointer deref.
>>>>
>>>> The detailed code here is:
>>>> 	hlist_del_rcu(&mn->hlist);
>>>>
>>>> Can mn be NULL? I do not think so since mn is always the embedded struct
>>>> of the caller, it be freed after calling mmu_notifier_unregister.
>>>
>>> If you look at __mmu_notifier_release() it is using hlist_del_init_rcu()
>>> which will set the hlist->pprev to NULL.  When hlist_del_rcu() is called,
>>> it attempts to update *hlist->pprev = hlist->next and that is where it
>>> takes the NULL pointer deref.
>>
>> Yes, sorry for my careless. So, That can not be fixed by using
>> hlist_del_init_rcu instead?
> 
> The problem is the race described above.  Thread 'A' has checked to see
> if n->pprev != NULL.  Based upon that, it did called the mn->release()
> method.  While it was trying to call the release method, thread 'B' ended
> up calling hlist_del_init_rcu() which set n->pprev = NULL.  Then thread
> 'A' got to run again and now it tries to do the hlist_del_rcu() which, as
> part of __hlist_del(), the pprev will be set to n->pprev (which is NULL)
> and then *pprev = n->next; hits the NULL pointer deref hits.

I mean using hlist_del_init_rcu instead of hlist_del_rcu in
mmu_notifier_unregister(), hlist_del_init_rcu is aware of ->pprev.

--
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>

  reply	other threads:[~2013-01-18  2:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-15 16:29 Question/problem with mmu_notifier_unregister Robin Holt
2013-01-16 20:00 ` Robin Holt
2013-01-16 21:01   ` [PATCH] [Patch] mmu_notifier_unregister NULL Pointer deref fix Robin Holt
2013-01-17  2:45     ` Xiao Guangrong
2013-01-17 11:12       ` Robin Holt
2013-01-17 12:19         ` Xiao Guangrong
2013-01-17 13:45           ` Robin Holt
2013-01-18  2:42             ` Xiao Guangrong [this message]
2013-01-18  2:48               ` Robin Holt
2013-01-18  3:04                 ` Xiao Guangrong
2013-01-18 12:14                   ` Robin Holt
2013-01-18 12:51                     ` Xiao Guangrong
2013-01-18 15:14                       ` Robin Holt
2013-01-23  2:00                         ` Wanpeng Li
2013-01-23  2:00                         ` Wanpeng Li

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=50F8B67F.4090901@linux.vnet.ibm.com \
    --to=xiaoguangrong@linux.vnet.ibm.com \
    --cc=aarcange@redhat.com \
    --cc=avi@redhat.com \
    --cc=haggaie@mellanox.com \
    --cc=holt@sgi.com \
    --cc=hughd@google.com \
    --cc=linux-mm@kvack.org \
    --cc=liwanp@linux.vnet.ibm.com \
    --cc=mtosatti@redhat.com \
    --cc=sagig@mellanox.co.il \
    /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.