Bugzilla – Bug 527865
VUL-1: CVE-2009-2848: kernel: execve: must clear current->clear_child_tid
Last modified: 2020-04-20 12:29:05 UTC
Hi. There is a security bug in 'kernel'. This information is from 'oss-security'. This bug is public. There is no coordinated release date (CRD) set. More information can be found here: http://article.gmane.org/gmane.linux.kernel/871942 Original posting: ----- Forwarded message from Eugene Teo <eugene@redhat.com> ----- Reply-To: oss-security@lists.openwall.com Date: Tue, 04 Aug 2009 16:09:09 +0800 From: Eugene Teo <eugene@redhat.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090320) To: oss-security@lists.openwall.com Cc: "Steven M. Christey" <coley@linus.mitre.org> Subject: [oss-security] CVE request - kernel: execve: must clear current->clear_child_tid 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. References: http://article.gmane.org/gmane.linux.kernel/871942 https://bugzilla.redhat.com/show_bug.cgi?id=515423 Patch is not in upstream kernel yet. Thanks, Eugene ----- End forwarded message -----
====================================================== Name: CVE-2009-2848 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2848 Reference: MLIST:[linux-kernel] 20090801 [PATCH v2] execve: must clear current->clear_child_tid Reference: URL:http://article.gmane.org/gmane.linux.kernel/871942 Reference: MLIST:[oss-security] 20090804 CVE request - kernel: execve: must clear current->clear_child_tid Reference: URL:http://www.openwall.com/lists/oss-security/2009/08/04/2 Reference: MLIST:[oss-security] 20090805 Re: CVE request - kernel: execve: must clear current->clear_child_tid Reference: URL:http://www.openwall.com/lists/oss-security/2009/08/05/10 The execve function in the Linux kernel, possibly 2.6.30-rc6 and earlier, does not properly clear the current->clear_child_tid pointer, which allows local users to cause a denial of service (memory corruption) via a clone system call with CLONE_CHILD_SETTID or CLONE_CHILD_CLEARTID enabled, which is not properly handled during thread creation and exit.
This fix will be part of the next SLE11 update via the 2.6.27.30 sync. Applied to SL110_BRANCH, SLES10_SP2_BRANCH, SLES10_SP3_BRANCH, and SLES9_SP4_BRANCH.
CVE-2009-2848: CVSS v2 Base Score: 4.7 (AV:L/AC:M/Au:N/C:N/I:N/A:C)
Update released for: kernel-debug, kernel-debug-debuginfo, kernel-default, kernel-default-debuginfo, kernel-source, kernel-source-debuginfo, kernel-syms Products: SLE-DEBUGINFO 10-SP2 (ia64) SLE-SDK 10-SP2 (ia64) SLE-SERVER 10-SP2 (ia64)
Update released for: kernel-default, kernel-default-debuginfo, kernel-source, kernel-syms Products: SLE-DEBUGINFO 10-SP2 (s390x) SLE-SERVER 10-SP2 (s390x)
A kernel update fixing / mentioning this bug was released on Tuesday, kernel version 2.6.16.60-0.42.7.
Update released for: kernel-s390, kernel-s390-debug, kernel-source, kernel-syms, um-host-kernel, kernel-update.ycp, install-kernel-non-interactive.sh Products: SUSE-CORE 9 (s390)
A Linux kernel update for SUSE Linux Enterprise Server 9 was released Friday that fixes/mentions this bug. Its version is 2.6.5-7.321.
Update released for: kernel-bigsmp, kernel-bigsmp-debug, kernel-debug, kernel-debug-debug, kernel-default, kernel-default-debug, kernel-smp, kernel-smp-debug, kernel-source, kernel-syms, kernel-um, kernel-um-debug, kernel-xen, kernel-xen-debug, kernel-xenpae, kernel-xenpae-debug, um-host-install-initrd, um-host-kernel, xen-kmp Products: Novell-Linux-Desktop 9 (i386) Open-Enterprise-Server 9 (i386)
Starting L3 here
Both patches have been scheduled for the next TD rollup release: - sles9sp3 - bug 426350 comment 158 and bug 426350 comment 159 - sles10sp1 - bug 434477 comment 121 and bug 434477 comment 122
L3 done here
We released it already in the 2.6.27.37 update it was fixed in 2.6.27.30 stable patch from upstream, and we missed listing the bug in the changes entry: ------------------------------------------------------------------- Mon Aug 17 17:56:23 CEST 2009 - gregkh@suse.de - Update to 2.6.27.30 and 2.6.27.31 - security fixes - lots of bugfixes - obsoletes: - patches.fixes/net-make-sock_sendpage-use-kernel_sendpage - patches.fixes/page-allocator-preserve-pfn-ordering-when-__gfp_cold-is-set.patch I think its all done.
Update released for: acerhk-kmp-debug, acx-kmp-debug, appleir-kmp-debug, at76_usb-kmp-debug, atl2-kmp-debug, aufs-kmp-debug, dazuko-kmp-debug, drbd-kmp-debug, gspcav-kmp-debug, iscsitarget-kmp-debug, ivtv-kmp-debug, kernel-debug, kernel-default, kernel-docs, kernel-kdump, kernel-pae, kernel-ppc64, kernel-ps3, kernel-source, kernel-syms, kernel-vanilla, kernel-xen, kqemu-kmp-debug, nouveau-kmp-debug, omnibook-kmp-debug, pcc-acpi-kmp-debug, pcfclock-kmp-debug, tpctl-kmp-debug, uvcvideo-kmp-debug, virtualbox-ose-kmp-debug, vmware-kmp-debug, wlan-ng-kmp-debug Products: openSUSE 11.0 (debug, i386, ppc, x86_64)