Skip to content

Commit 44854c1

Browse files
Peter Zijlstragregkh
authored andcommitted
futex: Fix potential use-after-free in FUTEX_REQUEUE_PI
commit c236c8e95a3d395b0494e7108f0d41cf36ec107c upstream. While working on the futex code, I stumbled over this potential use-after-free scenario. Dmitry triggered it later with syzkaller. pi_mutex is a pointer into pi_state, which we drop the reference on in unqueue_me_pi(). So any access to that pointer after that is bad. Since other sites already do rt_mutex_unlock() with hb->lock held, see for example futex_lock_pi(), simply move the unlock before unqueue_me_pi(). Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Darren Hart <dvhart@linux.intel.com> Cc: juri.lelli@arm.com Cc: bigeasy@linutronix.de Cc: xlpang@redhat.com Cc: rostedt@goodmis.org Cc: mathieu.desnoyers@efficios.com Cc: jdesfossez@efficios.com Cc: dvhart@infradead.org Cc: bristot@redhat.com Link: http://lkml.kernel.org/r/20170304093558.801744246@infradead.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1 parent 62f5704 commit 44854c1

1 file changed

Lines changed: 11 additions & 9 deletions

File tree

kernel/futex.c

Lines changed: 11 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -2690,7 +2690,6 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
26902690
{
26912691
struct hrtimer_sleeper timeout, *to = NULL;
26922692
struct rt_mutex_waiter rt_waiter;
2693-
struct rt_mutex *pi_mutex = NULL;
26942693
struct futex_hash_bucket *hb;
26952694
union futex_key key2 = FUTEX_KEY_INIT;
26962695
struct futex_q q = futex_q_init;
@@ -2782,6 +2781,8 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
27822781
spin_unlock(q.lock_ptr);
27832782
}
27842783
} else {
2784+
struct rt_mutex *pi_mutex;
2785+
27852786
/*
27862787
* We have been woken up by futex_unlock_pi(), a timeout, or a
27872788
* signal. futex_unlock_pi() will not destroy the lock_ptr nor
@@ -2805,18 +2806,19 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
28052806
if (res)
28062807
ret = (res < 0) ? res : 0;
28072808

2809+
/*
2810+
* If fixup_pi_state_owner() faulted and was unable to handle
2811+
* the fault, unlock the rt_mutex and return the fault to
2812+
* userspace.
2813+
*/
2814+
if (ret && rt_mutex_owner(pi_mutex) == current)
2815+
rt_mutex_unlock(pi_mutex);
2816+
28082817
/* Unqueue and drop the lock. */
28092818
unqueue_me_pi(&q);
28102819
}
28112820

2812-
/*
2813-
* If fixup_pi_state_owner() faulted and was unable to handle the
2814-
* fault, unlock the rt_mutex and return the fault to userspace.
2815-
*/
2816-
if (ret == -EFAULT) {
2817-
if (pi_mutex && rt_mutex_owner(pi_mutex) == current)
2818-
rt_mutex_unlock(pi_mutex);
2819-
} else if (ret == -EINTR) {
2821+
if (ret == -EINTR) {
28202822
/*
28212823
* We've already been requeued, but cannot restart by calling
28222824
* futex_lock_pi() directly. We could restart this syscall, but

0 commit comments

Comments
 (0)