This is a note to let you know that I've just added the patch titled
futex: Validate atomic acquisition in futex_lock_pi_atomic()
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
futex-validate-atomic-acquisition-in-futex_lock_pi_atomic.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From b3eaa9fc5cd0a4d74b18f6b8dc617aeaf1873270 Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <[email protected]>
Date: Tue, 3 Jun 2014 12:27:06 +0000
Subject: futex: Validate atomic acquisition in futex_lock_pi_atomic()
From: Thomas Gleixner <[email protected]>
commit b3eaa9fc5cd0a4d74b18f6b8dc617aeaf1873270 upstream.
We need to protect the atomic acquisition in the kernel against rogue
user space which sets the user space futex to 0, so the kernel side
acquisition succeeds while there is existing state in the kernel
associated to the real owner.
Verify whether the futex has waiters associated with kernel state. If
it has, return -EINVAL. The state is corrupted already, so no point in
cleaning it up. Subsequent calls will fail as well. Not our problem.
[ tglx: Use futex_top_waiter() and explain why we do not need to try
restoring the already corrupted user space state. ]
Signed-off-by: Darren Hart <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Will Drewry <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/futex.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -758,10 +758,18 @@ retry:
return -EDEADLK;
/*
- * Surprise - we got the lock. Just return to userspace:
+ * Surprise - we got the lock, but we do not trust user space at all.
*/
- if (unlikely(!curval))
- return 1;
+ if (unlikely(!curval)) {
+ /*
+ * We verify whether there is kernel state for this
+ * futex. If not, we can safely assume, that the 0 ->
+ * TID transition is correct. If state exists, we do
+ * not bother to fixup the user space state as it was
+ * corrupted already.
+ */
+ return futex_top_waiter(hb, key) ? -EINVAL : 1;
+ }
uval = curval;
Patches currently in stable-queue which might be from [email protected] are
queue-3.4/futex-always-cleanup-owner-tid-in-unlock_pi.patch
queue-3.4/futex-prevent-requeue-pi-on-same-futex.patch-futex-forbid-uaddr-uaddr2-in-futex_requeue-...-requeue_pi-1.patch
queue-3.4/futex-validate-atomic-acquisition-in-futex_lock_pi_atomic.patch
queue-3.4/futex-add-another-early-deadlock-detection-check.patch
queue-3.4/futex-make-lookup_pi_state-more-robust.patch
queue-3.4/futex-prevent-attaching-to-kernel-threads.patch
queue-3.4/hrtimer-prevent-all-reprogramming-if-hang-detected.patch
queue-3.4/hrtimer-prevent-remote-enqueue-of-leftmost-timers.patch
queue-3.4/hrtimer-set-expiry-time-before-switch_hrtimer_base.patch
queue-3.4/timer-prevent-overflow-in-apply_slack.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
