linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Robin Holt <holt@sgi.com>
To: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Cc: Robin Holt <holt@sgi.com>, 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: Thu, 17 Jan 2013 20:48:56 -0600	[thread overview]
Message-ID: <20130118024856.GC3460@sgi.com> (raw)
In-Reply-To: <50F8B67F.4090901@linux.vnet.ibm.com>

On Fri, Jan 18, 2013 at 10:42:07AM +0800, Xiao Guangrong wrote:
> 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.

How does that address the calling of the ->release() method twice?

Thanks,
Robin

--
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:48 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
2013-01-18  2:48               ` Robin Holt [this message]
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=20130118024856.GC3460@sgi.com \
    --to=holt@sgi.com \
    --cc=aarcange@redhat.com \
    --cc=avi@redhat.com \
    --cc=haggaie@mellanox.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 \
    --cc=xiaoguangrong@linux.vnet.ibm.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 NNTP newsgroup(s).