rpms/kernel/F-11 execve-must-clear-current-clear_child_tid.patch, NONE, 1.1.2.1 kernel.spec, 1.1679.2.9, 1.1679.2.10
Kyle McMartin
kyle at fedoraproject.org
Wed Aug 19 01:49:15 UTC 2009
Author: kyle
Update of /cvs/pkgs/rpms/kernel/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv16837
Modified Files:
Tag: private-fedora-11-2_6_29_6
kernel.spec
Added Files:
Tag: private-fedora-11-2_6_29_6
execve-must-clear-current-clear_child_tid.patch
Log Message:
* Sat Aug 15 2009 Kyle McMartin <kyle at redhat.com> 2.6.29.6-217.2.8
- CVE-2009-2767: Fix clock_nanosleep NULL ptr deref.
execve-must-clear-current-clear_child_tid.patch:
fork.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
--- NEW FILE execve-must-clear-current-clear_child_tid.patch ---
From: Eric Dumazet <eric.dumazet at gmail.com>
Date: Thu, 6 Aug 2009 22:09:28 +0000 (-0700)
Subject: execve: must clear current->clear_child_tid
X-Git-Tag: v2.6.31-rc6~52
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=9c8a8228d0827e0d91d28527209988f672f97d28
execve: must clear current->clear_child_tid
While looking at Jens Rosenboom bug report
(http://lkml.org/lkml/2009/7/27/35) about strange sys_futex call done from
a dying "ps" program, we found following problem.
clone() syscall has special support for TID of created threads. This
support includes two features.
One (CLONE_CHILD_SETTID) is to set an integer into user memory with the
TID value.
One (CLONE_CHILD_CLEARTID) is to clear this same integer once the created
thread dies.
The integer location is a user provided pointer, provided at clone()
time.
kernel keeps this pointer value into current->clear_child_tid.
At execve() time, we should make sure kernel doesnt keep this user
provided pointer, as full user memory is replaced by a new one.
As glibc fork() actually uses clone() syscall with CLONE_CHILD_SETTID and
CLONE_CHILD_CLEARTID set, chances are high that we might corrupt user
memory in forked processes.
Following sequence could happen:
1) bash (or any program) starts a new process, by a fork() call that
glibc maps to a clone( ... CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID
...) syscall
2) When new process starts, its current->clear_child_tid is set to a
location that has a meaning only in bash (or initial program) context
(&THREAD_SELF->tid)
3) This new process does the execve() syscall to start a new program.
current->clear_child_tid is left unchanged (a non NULL value)
4) If this new program creates some threads, and initial thread exits,
kernel will attempt to clear the integer pointed by
current->clear_child_tid from mm_release() :
if (tsk->clear_child_tid
&& !(tsk->flags & PF_SIGNALED)
&& atomic_read(&mm->mm_users) > 1) {
u32 __user * tidptr = tsk->clear_child_tid;
tsk->clear_child_tid = NULL;
/*
* We don't check the error code - if userspace has
* not set up a proper pointer then tough luck.
*/
<< here >> put_user(0, tidptr);
sys_futex(tidptr, FUTEX_WAKE, 1, NULL, NULL, 0);
}
5) OR : if new program is not multi-threaded, but spied by /proc/pid
users (ps command for example), mm_users > 1, and the exiting program
could corrupt 4 bytes in a persistent memory area (shm or memory mapped
file)
If current->clear_child_tid points to a writeable portion of memory of the
new program, kernel happily and silently corrupts 4 bytes of memory, with
unexpected effects.
Fix is straightforward and should not break any sane program.
Reported-by: Jens Rosenboom <jens at mcbone.net>
Acked-by: Linus Torvalds <torvalds at linux-foundation.org>
Signed-off-by: Eric Dumazet <eric.dumazet at gmail.com>
Signed-off-by: Oleg Nesterov <oleg at redhat.com>
Cc: Peter Zijlstra <peterz at infradead.org>
Cc: Sonny Rao <sonnyrao at us.ibm.com>
Cc: Ingo Molnar <mingo at elte.hu>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ulrich Drepper <drepper at redhat.com>
Cc: Oleg Nesterov <oleg at redhat.com>
Cc: <stable at kernel.org>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
---
diff --git a/kernel/fork.c b/kernel/fork.c
index 466531e..021e113 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -568,18 +568,18 @@ void mm_release(struct task_struct *tsk, struct mm_struct *mm)
* the value intact in a core dump, and to save the unnecessary
* trouble otherwise. Userland only wants this done for a sys_exit.
*/
- if (tsk->clear_child_tid
- && !(tsk->flags & PF_SIGNALED)
- && atomic_read(&mm->mm_users) > 1) {
- u32 __user * tidptr = tsk->clear_child_tid;
+ if (tsk->clear_child_tid) {
+ if (!(tsk->flags & PF_SIGNALED) &&
+ atomic_read(&mm->mm_users) > 1) {
+ /*
+ * We don't check the error code - if userspace has
+ * not set up a proper pointer then tough luck.
+ */
+ put_user(0, tsk->clear_child_tid);
+ sys_futex(tsk->clear_child_tid, FUTEX_WAKE,
+ 1, NULL, NULL, 0);
+ }
tsk->clear_child_tid = NULL;
-
- /*
- * We don't check the error code - if userspace has
- * not set up a proper pointer then tough luck.
- */
- put_user(0, tidptr);
- sys_futex(tidptr, FUTEX_WAKE, 1, NULL, NULL, 0);
}
}
Index: kernel.spec
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/F-11/kernel.spec,v
retrieving revision 1.1679.2.9
retrieving revision 1.1679.2.10
diff -u -p -r1.1679.2.9 -r1.1679.2.10
--- kernel.spec 17 Aug 2009 13:15:50 -0000 1.1679.2.9
+++ kernel.spec 19 Aug 2009 01:49:14 -0000 1.1679.2.10
@@ -821,6 +821,9 @@ Patch11130: via-hwmon-temp-sensor.patch
Patch12000: security-use-mmap_min_addr-indepedently-of-security-models.patch
Patch12010: personality-fix-per_clear_on_setid.patch
+# CVE-2009-2848
+Patch12020: execve-must-clear-current-clear_child_tid.patch
+
# make gcc stop optimizing away null pointer tests
Patch13000: add-fno-delete-null-pointer-checks-to-gcc-cflags.patch
@@ -1541,6 +1544,9 @@ ApplyPatch linux-2.6-x86-delay-tsc-barri
ApplyPatch security-use-mmap_min_addr-indepedently-of-security-models.patch
ApplyPatch personality-fix-per_clear_on_setid.patch
+# CVE-2009-2848
+ApplyPatch execve-must-clear-current-clear_child_tid.patch
+
# don't optimize out null pointer tests
ApplyPatch add-fno-delete-null-pointer-checks-to-gcc-cflags.patch
@@ -2144,6 +2150,9 @@ fi
# and build.
%changelog
+* Tue Aug 18 2009 Kyle McMartin <kyle at redhat.com>
+- CVE-2009-2848: execve: must clear current->clear_child_tid
+
* Mon Aug 17 2009 Jarod Wilson <jarod at redhat.com> 2.6.29.6-217.2.9
- Fix flub in prior lirc patch update that resulted in no lirc
drivers getting built
More information about the fedora-extras-commits
mailing list