| [2557] | 1 | From 63d6ad59dd43f44249150aa8c72eeb01bbe0a599 Mon Sep 17 00:00:00 2001 | 
|---|
|  | 2 | From: Thomas Gleixner <tglx@linutronix.de> | 
|---|
|  | 3 | Date: Tue, 3 Jun 2014 12:27:06 +0000 | 
|---|
|  | 4 | Subject: [PATCH 2/4] futex: Validate atomic acquisition in | 
|---|
|  | 5 | futex_lock_pi_atomic() | 
|---|
|  | 6 |  | 
|---|
|  | 7 | commit b3eaa9fc5cd0a4d74b18f6b8dc617aeaf1873270 upstream. | 
|---|
|  | 8 |  | 
|---|
|  | 9 | We need to protect the atomic acquisition in the kernel against rogue | 
|---|
|  | 10 | user space which sets the user space futex to 0, so the kernel side | 
|---|
|  | 11 | acquisition succeeds while there is existing state in the kernel | 
|---|
|  | 12 | associated to the real owner. | 
|---|
|  | 13 |  | 
|---|
|  | 14 | Verify whether the futex has waiters associated with kernel state.  If | 
|---|
|  | 15 | it has, return -EINVAL.  The state is corrupted already, so no point in | 
|---|
|  | 16 | cleaning it up.  Subsequent calls will fail as well.  Not our problem. | 
|---|
|  | 17 |  | 
|---|
|  | 18 | [ tglx: Use futex_top_waiter() and explain why we do not need to try | 
|---|
|  | 19 | restoring the already corrupted user space state. ] | 
|---|
|  | 20 |  | 
|---|
|  | 21 | Signed-off-by: Darren Hart <dvhart@linux.intel.com> | 
|---|
|  | 22 | Cc: Kees Cook <keescook@chromium.org> | 
|---|
|  | 23 | Cc: Will Drewry <wad@chromium.org> | 
|---|
|  | 24 | Signed-off-by: Thomas Gleixner <tglx@linutronix.de> | 
|---|
|  | 25 | Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 
|---|
|  | 26 | Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 
|---|
|  | 27 | --- | 
|---|
|  | 28 | kernel/futex.c |   14 +++++++++++--- | 
|---|
|  | 29 | 1 file changed, 11 insertions(+), 3 deletions(-) | 
|---|
|  | 30 |  | 
|---|
|  | 31 | diff --git a/kernel/futex.c b/kernel/futex.c | 
|---|
|  | 32 | index 93e522f..8c1e6d0 100644 | 
|---|
|  | 33 | --- a/kernel/futex.c | 
|---|
|  | 34 | +++ b/kernel/futex.c | 
|---|
|  | 35 | @@ -762,10 +762,18 @@ retry: | 
|---|
|  | 36 | return -EDEADLK; | 
|---|
|  | 37 |  | 
|---|
|  | 38 | /* | 
|---|
|  | 39 | -        * Surprise - we got the lock. Just return to userspace: | 
|---|
|  | 40 | +        * Surprise - we got the lock, but we do not trust user space at all. | 
|---|
|  | 41 | */ | 
|---|
|  | 42 | -       if (unlikely(!curval)) | 
|---|
|  | 43 | -               return 1; | 
|---|
|  | 44 | +       if (unlikely(!curval)) { | 
|---|
|  | 45 | +               /* | 
|---|
|  | 46 | +                * We verify whether there is kernel state for this | 
|---|
|  | 47 | +                * futex. If not, we can safely assume, that the 0 -> | 
|---|
|  | 48 | +                * TID transition is correct. If state exists, we do | 
|---|
|  | 49 | +                * not bother to fixup the user space state as it was | 
|---|
|  | 50 | +                * corrupted already. | 
|---|
|  | 51 | +                */ | 
|---|
|  | 52 | +               return futex_top_waiter(hb, key) ? -EINVAL : 1; | 
|---|
|  | 53 | +       } | 
|---|
|  | 54 |  | 
|---|
|  | 55 | uval = curval; | 
|---|
|  | 56 |  | 
|---|
|  | 57 | -- | 
|---|
|  | 58 | 1.7.10.4 | 
|---|
|  | 59 |  | 
|---|