source: trunk/server/common/patches/cve-2014-3153-2.patch @ 2560

Last change on this file since 2560 was 2557, checked in by achernya, 10 years ago
Kernel patches against cve-2014-3153 (old, uncommitted changes)
File size: 1.9 KB

  • kernel/futex.c 

    From 63d6ad59dd43f44249150aa8c72eeb01bbe0a599 Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <tglx@linutronix.de>
Date: Tue, 3 Jun 2014 12:27:06 +0000
Subject: [PATCH 2/4] futex: Validate atomic acquisition in
 futex_lock_pi_atomic()

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 <dvhart@linux.intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 kernel/futex.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 93e522f..8c1e6d0 100644
    a b retry: 
    762762                return -EDEADLK;
    763763
    764764        /*
    765          * Surprise - we got the lock. Just return to userspace:
     765         * Surprise - we got the lock, but we do not trust user space at all.
    766766         */
    767         if (unlikely(!curval))
    768                 return 1;
     767        if (unlikely(!curval)) {
     768                /*
     769                 * We verify whether there is kernel state for this
     770                 * futex. If not, we can safely assume, that the 0 ->
     771                 * TID transition is correct. If state exists, we do
     772                 * not bother to fixup the user space state as it was
     773                 * corrupted already.
     774                 */
     775                return futex_top_waiter(hb, key) ? -EINVAL : 1;
     776        }
    769777
    770778        uval = curval;
    771779
Note: See TracBrowser for help on using the repository browser.