• Thomas Gleixner's avatar
    futex: Handle user space corruption gracefully · 51246bfd
    Thomas Gleixner authored
    If the owner of a PI futex dies we fix up the pi_state and set
    pi_state->owner to NULL. When a malicious or just sloppy programmed
    user space application sets the futex value to 0 e.g. by calling
    pthread_mutex_init(), then the futex can be acquired again. A new
    waiter manages to enqueue itself on the pi_state w/o damage, but on
    unlock the kernel dereferences pi_state->owner and oopses.
    
    Prevent this by checking pi_state->owner in the unlock path. If
    pi_state->owner is not current we know that user space manipulated the
    futex value. Ignore the mess and return -EINVAL.
    
    This catches the above case and also the case where a task hijacks the
    futex by setting the tid value and then tries to unlock it.
    Reported-by: default avatarJermome Marchand <jmarchan@redhat.com>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Acked-by: default avatarDarren Hart <dvhltc@us.ibm.com>
    Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: <stable@kernel.org>
    51246bfd
futex.c 67.9 KB