From: Jerome Marchand <jmarchan@redhat.com> Date: Fri, 12 Feb 2010 16:18:42 -0500 Subject: [misc] futex: handle user space corruption gracefully Message-id: <4B757F62.4090508@redhat.com> Patchwork-id: 23252 O-Subject: [RHEL5 PATCH 2/3] Futex: Handle user space corruption gracefully Bugzilla: 480396 CVE: CVE-2010-0622 RH-Acked-by: Amerigo Wang <amwang@redhat.com> RH-Acked-by: Jarod Wilson <jarod@redhat.com> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=480396 Description: This is the actual bug which lead to the kernel crash. More detailed description (from upstream): 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. Upstream status: commit 51246bfd189064079c54421507236fd2723b18f3 Regards, Jerome Signed-off-by: Jarod Wilson <jarod@redhat.com> diff --git a/kernel/futex.c b/kernel/futex.c index db35706..53d0a14 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -631,6 +631,13 @@ static int wake_futex_pi(u32 __user *uaddr, u32 uval, struct futex_q *this) if (!pi_state) return -EINVAL; + /* + * If current does not own the pi_state then the futex is + * inconsistent and user space fiddled with the futex value. + */ + if (pi_state->owner != current) + return -EINVAL; + spin_lock(&pi_state->pi_mutex.wait_lock); new_owner = rt_mutex_next_owner(&pi_state->pi_mutex);