From: Darren Hart <dvhart@linux.intel.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: linux-kernel@vger.kernel.org, Dave Jones <davej@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: potential NULL dereference in futex_wait_requeue_pi()
Date: Wed, 18 Jul 2012 09:03:22 -0700 [thread overview]
Message-ID: <5006DE4A.4020905@linux.intel.com> (raw)
In-Reply-To: <20120718142514.GA18850@elgon.mountain>
On 07/18/2012 07:25 AM, Dan Carpenter wrote:
> Hi Darren,
>
> The patch 52400ba94675: "futex: add requeue_pi functionality" from
> Apr 3, 2009, leads to the following warning:
> kernel/futex.c:2373 futex_wait_requeue_pi()
> error: potential NULL dereference 'pi_mutex'.
>
> 2330 if (!q.rt_waiter) {
> 2331 /*
> 2332 * Got the lock. We might not be the anticipated owner if we
> 2333 * did a lock-steal - fix up the PI-state in that case.
> 2334 */
> 2335 if (q.pi_state && (q.pi_state->owner != current)) {
> 2336 spin_lock(q.lock_ptr);
> 2337 ret = fixup_pi_state_owner(uaddr2, &q, current);
>
> pi_mutex is NULL here and it looks like fixup_pi_state_owner() can
> return -EFAULT.
>
>
> 2338 spin_unlock(q.lock_ptr);
> 2339 }
> 2340 } else {
>
> [snipped]
>
> 2366 }
> 2367
> 2368 /*
> 2369 * If fixup_pi_state_owner() faulted and was unable to handle the
> 2370 * fault, unlock the rt_mutex and return the fault to userspace.
> 2371 */
> 2372 if (ret == -EFAULT) {
> 2373 if (rt_mutex_owner(pi_mutex) == current)
> ^^^^^^^^
> This will oops if pi_mutex is NULL.
>
> 2374 rt_mutex_unlock(pi_mutex);
> 2375 } else if (ret == -EINTR) {
Nice Dan, thanks for taking a closer look. This appears to be a simple fix, can
you try the following:
futex: Test for pi_mutex on fault in futex_wait_requeue_pi
If fixup_pi_state_owner() faults, pi_mutex may be NULL. Test
for pi_mutex != NULL before testing the owner against current
and possibly unlocking it.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Dave Jones <davej@redhat.com>
CC: Dan Carpenter <dan.carpenter@oracle.com>
CC: Thomas Gleixner <tglx@linutronix.de>
diff --git a/kernel/futex.c b/kernel/futex.c
index e2b0fb9..05018bf 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2370,7 +2370,7 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
* fault, unlock the rt_mutex and return the fault to userspace.
*/
if (ret == -EFAULT) {
- if (rt_mutex_owner(pi_mutex) == current)
+ if (pi_mutex && rt_mutex_owner(pi_mutex) == current)
rt_mutex_unlock(pi_mutex);
} else if (ret == -EINTR) {
/*
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
next prev parent reply other threads:[~2012-07-18 16:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-18 14:25 potential NULL dereference in futex_wait_requeue_pi() Dan Carpenter
2012-07-18 15:31 ` Dave Jones
2012-07-18 15:41 ` Darren Hart
2012-07-18 15:55 ` Dan Carpenter
2012-07-18 16:03 ` Darren Hart [this message]
2012-07-18 18:01 ` Dave Jones
2012-07-19 4:21 ` Darren Hart
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=5006DE4A.4020905@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=dan.carpenter@oracle.com \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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.