Sophie

Sophie

distrib > Scientific%20Linux > 5x > x86_64 > by-pkgid > 27922b4260f65d317aabda37e42bbbff > files > 1936

kernel-2.6.18-238.el5.src.rpm

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);