Bugzilla – Bug 804154
VUL-0: CVE-2013-0871: kernel: stack corruption via PTRACE_SETREGS (potential code execution)
Last modified: 2014-05-07 07:23:29 UTC
is public, via oss-security From: Julien Tinnes <julien@cr0.org> Subject: [oss-security] Linux kernel race condition with PTRACE_SETREGS (CVE-2013-0871) Date: Fri, 15 Feb 2013 12:24:18 -0800 Linux kernel stack corruption due to race condition with PTRACE_SETREGS ----------------------------------------------------------------------- A race conditon in ptrace can lead to kernel stack corruption and arbitrary kernel-mode code execution. This should be tracked as CVE-2013-0871. Solution ------------ The following commits from Oleg Nesterov should address the issue: - 910ffdb18a6408e14febbb6e4b6840fd2c928c82 - 9899d11f654474d2d54ea52ceaa2a1f4db3abd68 - 9067ac85d533651b98c2ff903182a20cbb361fcb Credit --------- This was discovered by Suleiman Souhlal and Salman Qazi of Google, with help from Aaron Durbin and Michael Davidson, also of Google. Code -------- Salman Qazi provided the following PoC code: (attached below) Kernel patch for easy reproduction: (attached below)
Created attachment 524981 [details] kernel-easy-reproduce.patch patch for the kernel that widens the race window
Created attachment 524982 [details] CVE-2013-0871.c reproducer C code.
please apply to all affected branches asap
bugbot adjusting priority
*** Bug 804227 has been marked as a duplicate of this bug. ***
The reproducer doesn't work with SLES kernel as ulimit for RLIMIT_RTPRIO is set to 0 which means that no unprivileged process can run in SCHED_FIFO (minimum priority is 1). This, however, doesn't mean we are not vulnerable. The race is harder to hit[1] but the issue is still there AFAIU (at least in 11sp2 I am looking at ATM). --- [1] the attacker would need to force the process (called V in the reproducer) to use almost its whole timeslice before it went asleep so that the process would get preempted before it reaches schedule before it exits.
(FWIW I will mention RealtimeKit aka rtkit here ... it will only give out a limited realtime slot, but it will give out realtime priority and so could make this more effective. rtkit is only active in openSUSE 12.2 and newer )
Sorry for the delay. I wasn't able to reproduce the issue with the testcase so I've tried to understand the race (thanks Jiri for his help here). Anyway, the fix is pushed to 11sp2 for now as this one has the highest priority ATM and all other branches will follow.
openSUSE-12.3 already has this from 3.7.5 stable kernel. openSUSE-12.2 already has this from 3.4.28 stable kernel pushed to openSUSE-12.1 That should cover all supported opensuse kernels.
SLES 11 SP2 kernel update is being started right now with a fix. Other kernels pending investigation and backporting.
Created attachment 525700 [details] fix candidate for sles10sp4 This is a "meta" patch that is applicable on top of SLES10_SP4_BRANCH in our kernel tree. There are two patches. One preparatory which converts wake_up_process to ptrace_wake_up_process for ptrace code - nothing exciting. The other one is the fix - at least I hope so ;). Review is really welcome!
Created attachment 525705 [details] fix for sle11-sp1-td This is a fix (metapatch applicable on top of SLE11-SP1-TD branch in our kernel tree) for sle11-sp1-td (I will push the same patches to the 11sp1-ltss branch once I am sure this is correct). The backport is little bit tricky because we are missing PTRACE vs. TASK_STOPPED rework mentioned in patches.fixes/ptrace-ensure-arch_ptrace-ptrace_request-can-never-r.patch. I guess we should be safe to unconditionally change state to TASK_TRACED because we have been doing this already so we should be at least bug compatible. Please look at the patch for more details. Again, review is highly welcome.
Created attachment 525729 [details] updated fix candidate for sles10sp4 Ouch, there is much more going on in the arch code than I thought. I hope I covered all of them
Created attachment 525776 [details] fix candidate for sles10sp4 v3 Sorry for the noise but I just found out that patches.arch/ia64-ptrace-lockup-fix which was applied later in the patch stack changes ia64 specific ptrace and luckily it gets rid of ptrace_check_attach usage in hread_matches which also helps to get rid of __ptrace_check_attach braindamage in my previous patch. Phew... Anyway I found another issue in my patch. ++ spin_lock_irq(&child->sighand->siglock); ++ if (child->state & TASK_PTRACE_IGNORE_KILL) { ++ /* TASK_PTRACE_IGNORE_KILL is cleared by ptrace_wake_up_process */ ++ ptrace_wake_up_process(child); ++ } woke up every task with the flag set while we want to wake only those which have SIGKILL pending. Fixed in this version and I also added helper so that the above excerpt is not duplicated all over the arch code.
I have sles9sp4 patch ready as well. It looks almost the same as the one for sles10 but I won't attach it until I am sure sles10 one is correct.
sle11 sp1 released
sle11 sp2 released
Update released for: cluster-network-kmp-default, cluster-network-kmp-trace, gfs2-kmp-default, gfs2-kmp-trace, kernel-default, kernel-default-base, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-devel-debuginfo, kernel-default-extra, kernel-default-hmac, kernel-default-man, kernel-source, kernel-source-debuginfo, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-devel-debuginfo, kernel-trace-extra, kernel-trace-hmac, kernel-trace-man, ocfs2-kmp-default, ocfs2-kmp-trace Products: SLE-DEBUGINFO 11-SP2 (s390x) SLE-HAE 11-SP2 (s390x) SLE-SERVER 11-SP2 (s390x)
Update released for: cluster-network-kmp-default, cluster-network-kmp-ppc64, cluster-network-kmp-trace, gfs2-kmp-default, gfs2-kmp-ppc64, gfs2-kmp-trace, kernel-default, kernel-default-base, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-extra, kernel-default-hmac, kernel-ppc64, kernel-ppc64-base, kernel-ppc64-debuginfo, kernel-ppc64-debugsource, kernel-ppc64-devel, kernel-ppc64-extra, kernel-ppc64-hmac, kernel-source, kernel-source-debuginfo, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-extra, kernel-trace-hmac, ocfs2-kmp-default, ocfs2-kmp-ppc64, ocfs2-kmp-trace Products: SLE-DEBUGINFO 11-SP2 (ppc64) SLE-HAE 11-SP2 (ppc64) SLE-SERVER 11-SP2 (ppc64)
Update released for: cluster-network-kmp-default, cluster-network-kmp-trace, cluster-network-kmp-xen, gfs2-kmp-default, gfs2-kmp-trace, gfs2-kmp-xen, kernel-default, kernel-default-base, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-devel-debuginfo, kernel-default-extra, kernel-default-hmac, kernel-desktop-devel, kernel-ec2, kernel-ec2-base, kernel-ec2-debuginfo, kernel-ec2-debugsource, kernel-ec2-devel, kernel-ec2-devel-debuginfo, kernel-ec2-extra, kernel-ec2-hmac, kernel-source, kernel-source-debuginfo, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-devel-debuginfo, kernel-trace-extra, kernel-trace-hmac, kernel-xen, kernel-xen-base, kernel-xen-debuginfo, kernel-xen-debugsource, kernel-xen-devel, kernel-xen-devel-debuginfo, kernel-xen-extra, kernel-xen-hmac, ocfs2-kmp-default, ocfs2-kmp-trace, ocfs2-kmp-xen, xen-kmp-default, xen-kmp-pae, xen-kmp-trace Products: SLE-DEBUGINFO 11-SP2 (x86_64) SLE-DESKTOP 11-SP2 (x86_64) SLE-HAE 11-SP2 (x86_64) SLE-SERVER 11-SP2 (x86_64) SLES4VMWARE 11-SP2 (x86_64)
Update released for: cluster-network-kmp-default, cluster-network-kmp-trace, gfs2-kmp-default, gfs2-kmp-trace, kernel-default, kernel-default-base, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-devel-debuginfo, kernel-default-extra, kernel-default-hmac, kernel-source, kernel-source-debuginfo, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-devel-debuginfo, kernel-trace-extra, kernel-trace-hmac, ocfs2-kmp-default, ocfs2-kmp-trace Products: SLE-DEBUGINFO 11-SP2 (ia64) SLE-HAE 11-SP2 (ia64) SLE-SERVER 11-SP2 (ia64)
Update released for: cluster-network-kmp-default, cluster-network-kmp-pae, cluster-network-kmp-trace, cluster-network-kmp-xen, gfs2-kmp-default, gfs2-kmp-pae, gfs2-kmp-trace, gfs2-kmp-xen, kernel-default, kernel-default-base, kernel-default-devel, kernel-default-extra, kernel-default-hmac, kernel-desktop-devel, kernel-ec2, kernel-ec2-base, kernel-ec2-devel, kernel-ec2-extra, kernel-ec2-hmac, kernel-pae, kernel-pae-base, kernel-pae-devel, kernel-pae-extra, kernel-pae-hmac, kernel-source, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-devel, kernel-trace-extra, kernel-trace-hmac, kernel-xen, kernel-xen-base, kernel-xen-devel, kernel-xen-extra, kernel-xen-hmac, ocfs2-kmp-default, ocfs2-kmp-pae, ocfs2-kmp-trace, ocfs2-kmp-xen Products: SLE-DEBUGINFO 11-SP2 (i386) SLE-DESKTOP 11-SP2 (i386) SLE-HAE 11-SP2 (i386) SLE-SERVER 11-SP2 (i386) SLES4VMWARE 11-SP2 (i386)
The SWAMPID for this issue is 51373. This issue was rated as important. Please submit fixed packages until 2013-03-04. Also create a patchinfo file using this link: https://swamp.suse.de/webswamp/wf/51373
Update released for: ext4-writeable-kmp-default, ext4-writeable-kmp-trace, ext4-writeable-kmp-xen, kernel-default-extra, kernel-xen-extra Products: SLE-SERVER 11-EXTRA (x86_64)
Update released for: ext4-writeable-kmp-default, ext4-writeable-kmp-ppc64, ext4-writeable-kmp-trace, kernel-default-extra, kernel-ppc64-extra Products: SLE-SERVER 11-EXTRA (ppc64)
Update released for: ext4-writeable-kmp-default, ext4-writeable-kmp-pae, ext4-writeable-kmp-trace, ext4-writeable-kmp-xen, kernel-default-extra, kernel-pae-extra, kernel-xen-extra Products: SLE-SERVER 11-EXTRA (i386)
Update released for: ext4-writeable-kmp-default, ext4-writeable-kmp-trace, kernel-default-extra Products: SLE-SERVER 11-EXTRA (s390x)
Update released for: ext4-writeable-kmp-default, ext4-writeable-kmp-trace, kernel-default-extra Products: SLE-SERVER 11-EXTRA (ia64)
for openSUSE 12.2 already released with: http://lists.opensuse.org/opensuse-updates/2013-02/msg00018.html
the patch is in SLE11-SP1-TD already. So we are currently waiting for SLES10* and SLES9*
can you also merge it to SLE11-SP1-LTSS ? Should be in the next ltss udpate.
(In reply to comment #37) > can you also merge it to SLE11-SP1-LTSS ? Should be in the next ltss udpate. done
Michal, what is the SLES 10 status of this patch? what needs to be done to get this forward?
(In reply to comment #39) > Michal, what is the SLES 10 status of this patch? > > what needs to be done to get this forward? I think this should get deep review. Petr and Jiri Kosina are looking at it. I really do not want to cause some subtle regressions in this highly subtle area.
I have reviewed the patches, and they seem fine, except ptrace_untrace(). This function is called when a tracer exits (without releasing the children first). I'm not sure whether or not that can happen while TASK_PTRACE_IGNORE_KILL is set in the tracee, because the tracer would have to exit while still executing sys_ptrace(), IIUC. Michal, have you given it a thought?
(Resetting NEEDINFO, since the bug is already assigned to Michal). I'm also unable to validate all places where a task state is compared directly with a value, such as if (child->state == TASK_TRACED) Maybe they should be converted into something like: if ((child->state & ~TASK_PTRACE_IGNORE_KILL) == TASK_TRACED) Or maybe it's not necessary... Related to this, can the TASK_PTRACE_IGNORE_KILL bit be set together with a different task state than TASK_TRACED? I think not, but maybe I missed something.
(In reply to comment #44) > I have reviewed the patches, and they seem fine, except ptrace_untrace(). This > function is called when a tracer exits (without releasing the children first). > I'm not sure whether or not that can happen while TASK_PTRACE_IGNORE_KILL is > set in the tracee, because the tracer would have to exit while still executing > sys_ptrace(), IIUC. Michal, have you given it a thought? Hmm, __ptrace_detach could miss to wake up the tracee if the task was EXIT_ZOMBIE. Is this a problem? All other paths seem to be on the exit which shouldn't race with ptrace as the task is stopped. Anyway, I think we should be careful here and introduce ptrace_signal_wake_up and call it from ptrace_untrace. (In reply to comment #45) > (Resetting NEEDINFO, since the bug is already assigned to Michal). > > I'm also unable to validate all places where a task state is compared directly > with a value, such as > > if (child->state == TASK_TRACED) > > Maybe they should be converted into something like: > > if ((child->state & ~TASK_PTRACE_IGNORE_KILL) == TASK_TRACED) Ouch. We definitely need it for ptrace_untrace. But we should rather be careful here and replace all those tests with a helper. I will add a patch on top of the fix. Thanks for pointing this out Petr! Well spotted. I will attach a new version of the patchlet.
Created attachment 527554 [details] fix candidate for sles10sp4 v4 I have added a new patch which transforms TASK_TRACED tests and ptrace_wake_up_signal has been introduced. Sles9 should be updated in the same way.
Created attachment 527561 [details] fix candidate for sles9sp4 updated patch series in a similar way as sles10sp4. Except that sles9 uses TASK_STOPPED because it doesn't know about TASK_TRACED yet. Please give it a serious look, I didn't get even to compile test it as this would require playing with mbuild and I am running out of time. I hope I will get to this tomorrow for a while but I will be mostly offline and on vacation for the whole next week.
Update released for: kernel-default, kernel-default-base, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-devel-debuginfo, kernel-default-extra, kernel-source, kernel-source-debuginfo, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-devel-debuginfo, kernel-trace-extra, kernel-xen, kernel-xen-base, kernel-xen-debuginfo, kernel-xen-debugsource, kernel-xen-devel, kernel-xen-devel-debuginfo, kernel-xen-extra, xen-kmp-default, xen-kmp-trace Products: SLE-SERVER 11-SP1-TERADATA (x86_64)
openSUSE-SU-2013:0396-1: An update that solves 10 vulnerabilities and has 25 fixes is now available. Category: security (important) Bug References: 714906,720226,733148,755546,762693,765524,768506,769784,769896,770695,773406,773831,774285,774523,774859,776144,778630,779432,781134,783515,784192,786013,787168,792500,793671,797175,799209,800280,801178,801782,802153,802642,804154,804652,804738 CVE References: CVE-2012-0957,CVE-2012-2745,CVE-2012-3412,CVE-2012-4530,CVE-2013-0160,CVE-2013-0216,CVE-2013-0231,CVE-2013-0268,CVE-2013-0309,CVE-2013-0871 Sources used: openSUSE 12.1 (src): kernel-docs-3.1.10-1.19.2, kernel-source-3.1.10-1.19.1, kernel-syms-3.1.10-1.19.1
Created attachment 528401 [details] old kernel results
Created attachment 528402 [details] New kernel results It seems that the fix cause some regressions with the ptrace testsuite, at least on ppc64. A PTF kernel for SP1 with only this fix show different results and the testsuite hangs completely (ctrl-C works) in a test. I did run the test suite 3 times on a unmodified kernel, 6 tests did fail, this was expected. On the modified kernel the suite did hang after few tests.
From the kernel log with the ppc64 PTF kernel: Mar 6 09:24:18 p6024 kernel: Badness at /usr/src/packages/BUILD/kernel-ppc64-2.6.32.59/linux-2.6.32/kernel/sched.c:2651 Mar 6 09:24:18 p6024 kernel: NIP: c0000000000a9110 LR: c0000000000bc7cc CTR: c00000000000a8a4 Mar 6 09:24:18 p6024 kernel: REGS: c00000168d43f8c0 TRAP: 0700 Tainted: G W X (2.6.32.59-0.7.1.5253.0.PTF-ppc64) Mar 6 09:24:18 p6024 kernel: MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 22000288 XER: 20000020 Mar 6 09:24:18 p6024 kernel: TASK = c00000168e0572e0[12768] 'ptrace_event_cl' THREAD: c00000168d43c000 CPU: 50 Mar 6 09:24:18 p6024 kernel: GPR00: 0000000000000001 c00000168d43fb40 c000000000e94f30 c000001e1fc88c00 Mar 6 09:24:18 p6024 kernel: GPR04: 0000000000000018 0000000000000000 0000000000000000 e200000000000000 Mar 6 09:24:18 p6024 kernel: GPR08: 2000000000000000 c000001e04c6c080 c0000000013b0000 0000000000008001 Mar 6 09:24:18 p6024 kernel: GPR12: 0000000022000282 c000000000f68a00 0000000000000046 00000000100dd880 Mar 6 09:24:18 p6024 kernel: GPR16: 00000000100cb9d8 00000000100933c8 00000000100dd880 0000000000000000 Mar 6 09:24:18 p6024 kernel: GPR20: 0000000000000000 00000000100e96c0 00000000100ce1d8 0000000000000000 Mar 6 09:24:18 p6024 kernel: GPR24: 00000000100e7360 0000000000000000 0000000000000000 0000000000000018 Mar 6 09:24:18 p6024 kernel: GPR28: 0000000000000000 0000000000000000 c000000000e03920 c000001e1fc88c00 Mar 6 09:24:18 p6024 kernel: NIP [c0000000000a9110] .wake_up_process+0x10/0x20 Mar 6 09:24:18 p6024 kernel: LR [c0000000000bc7cc] .ptrace_resume+0x74/0xd0 Mar 6 09:24:18 p6024 kernel: Call Trace: Mar 6 09:24:18 p6024 kernel: [c00000168d43fb40] [c00000075f041f10] 0xc00000075f041f10 (unreliable) Mar 6 09:24:18 p6024 kernel: [c00000168d43fbd0] [c0000000000bdb30] .ptrace_request+0x2e8/0x330 Mar 6 09:24:18 p6024 kernel: [c00000168d43fcf0] [c00000000000a8b0] .arch_ptrace+0x40/0x6d0 Mar 6 09:24:18 p6024 kernel: [c00000168d43fd80] [c0000000000bd284] .SyS_ptrace+0xbc/0x1c0 Mar 6 09:24:18 p6024 kernel: [c00000168d43fe30] [c0000000000085f4] syscall_exit+0x0/0x40 Mar 6 09:24:18 p6024 kernel: Instruction dump: Mar 6 09:24:18 p6024 kernel: 3929ffff f92b0820 4bfffc4c 60000000 e8630008 4bfffa7c 38a00000 4bfffa74 Mar 6 09:24:18 p6024 kernel: e8030000 5400073a 7c0000d0 78000fe0 <0b000000> 38800003 38a00000 4bfffa54 Mar 6 09:24:18 p6024 kernel: ------------[ cut here ]------------
(In reply to comment #52) >[...] > It seems that the fix cause some regressions with the ptrace testsuite I think it hasn't been mentioned in this bug yet. The URL is: http://sourceware.org/systemtap/wiki/utrace/tests Some background: Redhat wrote a ptrace testsuite as part of their utrace project. It was intended to validate their ptrace-by-utrace compatibility layer, so it may not be complete, but it checks many corner cases, nevertheless. I'm not sure if the test suite is still maintained after the utrace project failed to go mainline, but that shouldn't matter. There should be no regressions, and there should definitely be no "kernel badness" messages.
Created attachment 528514 [details] patch to get the tests compile under ppc64 To compile and run the tests in a ppc64 environment I did change 2 of the tests (these tests are now marked as skipped). As Petr mentioned, I would expect the the testsuite should run and give the same results. It maybe accepted if one specific test will fail with the new kernel, if this could be explained by the fix. But for now it seems that ptrace is completely broken.
Not related to the ppc64 failure, I have reviewed the proposed SLES10 patches, and there are issues: - As soon as the TASK_PTRACE_IGNORE_KILL bit is cleared, ptrace_unfreeze_task() should not be called again, because the child may be woken up and attached by another tracer in between, re-introducing the original race condition for this other tracer. Unfreezing should be skipped: - after a successful ptrace_detach() - after ptrace_wake_up_process() - The unfreeze should not be performed from arch_ptrace(), but instead from the generic sys_ptrace(). However, there are still architectures that don't use the generic syscall at all (those which define __ARCH_SYS_PTRACE). All of them call ptrace_check_attach(), so they must also call ptrace_unfreeze_task(). It's these architectures: alpha, ia64, m32r, s390, sparc, sparc64 Since Michal is on FTO this week, I'll try to address the above issues myself. I'm not sure I can find time to handle the ppc64 cases as well.
Thanks Petr. I will try to look at the ppc64 failures tonight and tomorrow.
Created attachment 528997 [details] fix candidate for sles10 v5 I haven't observed any regression with the test suite after applying the attached patch set. I would appreciate it if someone can review it for silly mistakes, though.
Thanks a lot Petr for looking into this while I was on vacation. I will review your changes today.
(In reply to comment #56) > Not related to the ppc64 failure, I have reviewed the proposed SLES10 patches, > and there are issues: > > - As soon as the TASK_PTRACE_IGNORE_KILL bit is cleared, ptrace_unfreeze_task() > should not be called again, because the child may be woken up and attached by > another tracer in between, re-introducing the original race condition for > this > other tracer. Unfreezing should be skipped: > - after a successful ptrace_detach() > - after ptrace_wake_up_process() You are right. Thanks for catching this. (In reply to comment #58) > Created an attachment (id=528997) [details] > fix candidate for sles10 v5 > > I haven't observed any regression with the test suite after applying the > attached patch set. I would appreciate it if someone can review it for silly > mistakes, though. The updated patches look good to me - except for sparc64 where your goto cleanup is changed the semantic because break from PTRACE_{GET,SET}REGS{64} for loop would call pt_succ_return even on the failure. Maybe it's no biggie as sparc doesn't bother with handling __{get,put}_user at all and moreover we do not support it. Just a nit. ptrace_unfreeze_task has BUG_ON right now so the condition for the flag is pointless now. We should either make it WARN_ON or remove the if (task->state & TASK_PTRACE_IGNORE_KILL) part. I would vote for the first option. Follow up diff is: Index: linux-2.6.16-bnc804154-10sp4/arch/sparc64/kernel/ptrace.c =================================================================== --- linux-2.6.16-bnc804154-10sp4.orig/arch/sparc64/kernel/ptrace.c +++ linux-2.6.16-bnc804154-10sp4/arch/sparc64/kernel/ptrace.c @@ -309,7 +309,7 @@ asmlinkage void do_ptrace(struct pt_regs for (rval = 1; rval < 16; rval++) if (__put_user(cregs->u_regs[rval], (&pregs->u_regs[rval - 1]))) { pt_error_return(regs, EFAULT); - break; + goto out_ptrace_cleanup; } pt_succ_return(regs, 0); #ifdef DEBUG_PTRACE @@ -336,7 +336,7 @@ asmlinkage void do_ptrace(struct pt_regs for (rval = 1; rval < 16; rval++) if (__put_user(cregs->u_regs[rval], (&pregs->u_regs[rval - 1]))) { pt_error_return(regs, EFAULT); - break; + goto out_ptrace_cleanup; } pt_succ_return(regs, 0); #ifdef DEBUG_PTRACE @@ -372,7 +372,7 @@ asmlinkage void do_ptrace(struct pt_regs for (i = 1; i < 16; i++) { if (__get_user(cregs->u_regs[i], (&pregs->u_regs[i-1]))) { pt_error_return(regs, EFAULT); - break; + goto out_ptrace_cleanup; } } pt_succ_return(regs, 0); @@ -410,7 +410,7 @@ asmlinkage void do_ptrace(struct pt_regs for (i = 1; i < 16; i++) { if (__get_user(cregs->u_regs[i], (&pregs->u_regs[i-1]))) { pt_error_return(regs, EFAULT); - break; + goto out_ptrace_cleanup; } } pt_succ_return(regs, 0); @@ -608,6 +608,7 @@ asmlinkage void do_ptrace(struct pt_regs break; } } +out_ptrace_cleanup: ptrace_cleanup_unfreeze(child, request, regs->tstate & (TSTATE_ICARRY | TSTATE_XCARRY)); out_tsk: Index: linux-2.6.16-bnc804154-10sp4/kernel/ptrace.c =================================================================== --- linux-2.6.16-bnc804154-10sp4.orig/kernel/ptrace.c +++ linux-2.6.16-bnc804154-10sp4/kernel/ptrace.c @@ -134,7 +134,7 @@ int ptrace_check_attach(struct task_stru static void ptrace_unfreeze_task(struct task_struct *task) { spin_lock_irq(&task->sighand->siglock); - BUG_ON(! (task->state & TASK_PTRACE_IGNORE_KILL) ); + WARN_ON(! (task->state & TASK_PTRACE_IGNORE_KILL) ); if (task->state & TASK_PTRACE_IGNORE_KILL) { task->state &= ~TASK_PTRACE_IGNORE_KILL; if (__fatal_signal_pending(task))
Created attachment 529134 [details] fix candidate for sles10sp4 v5.1 Updated version based on the Petr's latest one. Karsten, could you help me with powepc testing, please?
My testing with the current SLES10-SP4 (as in git) + patchset from comment 61 onx86_64 shows the following: ptrace-cont-sigstop-detach hangs with or without patches so I've killed it: 20957 pts/0 S+ 0:00 make check 20959 pts/0 S+ 0:00 /bin/sh -c fail= failcom='exit 1'; for f in x $MAKEFLAGS; do case $f in *=* | --[!k]*);; *k*) failcom='fail=yes';; esac; done; dot_seen=no; targe 20963 pts/0 S+ 0:00 /bin/sh -c fail= failcom='exit 1'; for f in x $MAKEFLAGS; do case $f in *=* | --[!k]*);; *k*) failcom='fail=yes';; esac; done; dot_seen=no; tar 20964 pts/0 S+ 0:00 make check 20965 pts/0 S+ 0:00 make check-am 20966 pts/0 S+ 0:00 make check-TESTS 20967 pts/0 S+ 0:00 /bin/sh -c failed=0; all=0; xfail=0; xpass=0; skip=0; srcdir=.; export srcdir; list=' ptrace-on-job-control-stopped attach-wait-on-stopped de 12206 pts/0 S+ 0:00 ./ptrace_event_clone 12207 pts/0 T+ 0:00 ./ptrace_event_clone 20958 pts/0 S+ 0:00 tee before Other than that it still seems that we have a regression here: -PASS: bogus-echild +bogus-echild: bogus-echild.c:154: reproduce: Assertion `ptrace(0x10, child, 0, 0) == 0' failed. +bogus-echild: bogus-echild.c:90: handler_fail: Assertion `0' failed. +/bin/sh: line 1: 6609 Aborted ${dir}$tst +FAIL: bogus-echild I will check what the test does and why it fails.
(In reply to comment #66) [...] > +bogus-echild: bogus-echild.c:90: handler_fail: Assertion `0' failed. > +/bin/sh: line 1: 6609 Aborted ${dir}$tst > +FAIL: bogus-echild > > I will check what the test does and why it fails. OK, so it is assert(ptrace(PTRACE_ATTACH, child, 0, 0) == 0) which fails. I have updated the testcase to show the error code but then couldn't reproduce it which suggests it is timing sensitive.
And it failed with the unpatched kernel right after I hit commit button. So this is not regression either. So from x86_64 it seems the patchset doesn't brake more than it was b0rked already. I am waiting for Karsten and ppc testing (which is waiting for a new PTF in bug 795039).
Ouch, I was definitely confused. I thought we were talking about SLES10SP4, Karsten. But now that I have looked more closely you have reported an 11sp1 regresssion. I will double check 11sp1 tomorrow.
Just for reference. I have tested sle11sp1 kernel and there don't seem any problems on x86_64. Karsten, could you test with kotd ppc build without any additional patches? I will try some ppc machine as well.
(In reply to comment #70) > Just for reference. I have tested sle11sp1 kernel and there don't seem any > problems on x86_64. And it seems that I managed to screw 11SP1-LTSS submission and hasn't included all 3 patches. With all three of them applied I am getting WARNING: at /usr/src/packages/BUILD/kernel-default-2.6.32.59/linux-2.6.32/kernel/sched.c:2651 wake_up_process+0x39/0x40() which is not unexpected because We are missing 0666fb51. I am checking whether more is missing.
All tests passed with SLE11-SP1-LTSS now (after 0666fb51 has been added) and I have pushed the missing part to SLE11-SP1-TD as well. TD kernel will need a new submission (LTSS kernel hasn't been submitted AFAIK) because the tracee could hang without the missing patch (as TASK_NORMAL wouldn't wake up it). SP2 backport (and newer) are safe because the missing patch has been introduced in 3.0. So to sum up and clean up the mess I produced. * SLES11SP2 and newer are fine * SLE11-SP1* - were updated and pass testing. -TD need to be resubmitted. * SLES10 - passed my testing and should go in as soon as another pair of eyes confirm that I haven't screwed anything and boy I am creative in that area as you can see * SLES9 - needs to be updated to mimic SLES10 changes P.S. It's sad that I didn't know about the test suite during the first round of backporting.
The SWAMPID for this issue is 51624. This issue was rated as important. Please submit fixed packages until 2013-03-19. Also create a patchinfo file using this link: https://swamp.suse.de/webswamp/wf/51624
Ok, so I have spent quite some time reviewing the patches, and didn't spot any outstanding issues. Therefore -- Michal, given the results of the regression tests, please push it. Thanks a lot.
Thanks a lot for double checking, Jiri! I have pushed the patchset to SLES10_SP4_BRANCH and SLES10-SP3-TD branches. So Sles9 is the only one left on the plate. Will work on it today.
Created attachment 529922 [details] fix for sles9 I had some troubles with testing on sles9 but everything seems to be fine now. The test suite passed all tests it passed without the patches: 17 of 57 tests failed (6 tests were not run) Please report to utrace-devel@redhat.com I had to * kill ptrace-cont-sigstop-detach same as for sles10 * disable eintr-on-attach because INOTIFY was not present in sles9 * modify fpregs-smp because __float80 was an unknown type - I have used float instead. I have pushed the patches to SLES9_SP4_BRANCH and as soon as dear BS builds SLES9-SP3-TD kernel so that I can test it I will do the same for that branch as well.
(In reply to comment #78) [...] > I have pushed the patches to SLES9_SP4_BRANCH Ouch, this is an outdated branch. Nevermind, pushed to SLES9_SP4_LTSS.
I have finally test sles9-sp3-td as well. Everything seems to be good (or at least not worse than before). ======================================== 18 of 57 tests failed (6 tests were not run) Please report to utrace-devel@redhat.com ======================================== An additional test (wrt. sles9sp4) which fails is step-to-breakpoint but this one fails without patches applied as well - and worth noting that not all the time. Pushed to sles9-sp3-td. What a relief, Can I close the bug, pleeeeeaz?
Update released for: kernel-debug, kernel-debug-debuginfo, kernel-default, kernel-default-debuginfo, kernel-kdump, kernel-kdump-debuginfo, kernel-smp, kernel-smp-debuginfo, kernel-source, kernel-source-debuginfo, kernel-syms, kernel-xen, kernel-xen-debuginfo Products: SLE-SERVER 10-SP3-TERADATA (x86_64)
The SWAMPID for this issue is 51776. This issue was rated as important. Please submit fixed packages until 2013-03-27. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
Update released for: kernel-default, kernel-default-debug, kernel-smp, kernel-smp-debug, kernel-source, kernel-syms, um-host-kernel, kernel-update.ycp, install-kernel-non-interactive.sh Products: SUSE-CORE 9-SP3-TERADATA (x86_64)
The SWAMPID for this issue is 51849. This issue was rated as important. Please submit fixed packages until 2013-04-01. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
SLE 10 kernel released. I assume we are done.
Update released for: kernel-bigsmp, kernel-bigsmp-debuginfo, kernel-debug, kernel-debug-debuginfo, kernel-default, kernel-default-debuginfo, kernel-kdump, kernel-kdump-debuginfo, kernel-kdumppae, kernel-kdumppae-debuginfo, kernel-smp, kernel-smp-debuginfo, kernel-source, kernel-source-debuginfo, kernel-syms, kernel-syms-debuginfo, kernel-vmi, kernel-vmi-debuginfo, kernel-vmipae, kernel-vmipae-debuginfo, kernel-xen, kernel-xen-debuginfo, kernel-xenpae, kernel-xenpae-debuginfo Products: SLE-DEBUGINFO 10-SP4 (i386) SLE-DESKTOP 10-SP4 (i386) SLE-SDK 10-SP4 (i386) SLE-SERVER 10-SP4 (i386)
Update released for: kernel-debug, kernel-debug-debuginfo, kernel-default, kernel-default-debuginfo, kernel-source, kernel-source-debuginfo, kernel-syms Products: SLE-DEBUGINFO 10-SP4 (ia64) SLE-SDK 10-SP4 (ia64) SLE-SERVER 10-SP4 (ia64)
Update released for: kernel-debug, kernel-debug-debuginfo, kernel-default, kernel-default-debuginfo, kernel-kdump, kernel-kdump-debuginfo, kernel-smp, kernel-smp-debuginfo, kernel-source, kernel-source-debuginfo, kernel-syms, kernel-xen, kernel-xen-debuginfo Products: SLE-DEBUGINFO 10-SP4 (x86_64) SLE-DESKTOP 10-SP4 (x86_64) SLE-SDK 10-SP4 (x86_64) SLE-SERVER 10-SP4 (x86_64)
Update released for: kernel-default, kernel-default-debuginfo, kernel-source, kernel-syms Products: SLE-DEBUGINFO 10-SP4 (s390x) SLE-SERVER 10-SP4 (s390x)
Update released for: kernel-default, kernel-default-debuginfo, kernel-iseries64, kernel-iseries64-debuginfo, kernel-kdump, kernel-kdump-debuginfo, kernel-ppc64, kernel-ppc64-debuginfo, kernel-source, kernel-source-debuginfo, kernel-syms Products: SLE-DEBUGINFO 10-SP4 (ppc) SLE-SDK 10-SP4 (ppc) SLE-SERVER 10-SP4 (ppc)
We have just released a kernel update for SUSE Linux Enterprise 11 SP2 that mentions/fixes this bug. The released kernel version is 3.0.74-0.6.6.2.
Update released for: cluster-network-kmp-rt, cluster-network-kmp-rt_trace, drbd-kmp-rt, drbd-kmp-rt_trace, iscsitarget-kmp-rt, iscsitarget-kmp-rt_trace, kernel-rt, kernel-rt-base, kernel-rt-debuginfo, kernel-rt-debugsource, kernel-rt-devel, kernel-rt-devel-debuginfo, kernel-rt-extra, kernel-rt-hmac, kernel-rt_trace, kernel-rt_trace-base, kernel-rt_trace-debuginfo, kernel-rt_trace-debugsource, kernel-rt_trace-devel, kernel-rt_trace-devel-debuginfo, kernel-rt_trace-extra, kernel-rt_trace-hmac, kernel-source-rt, kernel-syms-rt, lttng-modules-kmp-rt, lttng-modules-kmp-rt_trace, ocfs2-kmp-rt, ocfs2-kmp-rt_trace, ofed-kmp-rt, ofed-kmp-rt_trace Products: SLE-RT 11-SP2 (x86_64)
openSUSE-SU-2013:0925-1: An update that solves 21 vulnerabilities and has 87 fixes is now available. Category: security (important) Bug References: 578046,651219,714604,722398,730117,736149,738210,744692,754583,754898,758243,761849,762424,763494,767612,768052,773577,776787,777616,777746,779577,780977,786150,786814,786900,787821,788826,789235,789311,789359,790867,792674,792793,793139,793671,794513,794529,794805,795269,795928,795957,795961,796412,796418,796823,797042,797175,798921,799197,799209,799270,799275,799578,799926,800280,800701,801038,801178,801713,801717,801720,801782,802153,802353,802445,802712,803056,803067,803394,803674,803712,804154,804220,804609,805823,806138,806395,806404,806431,806466,806469,806492,806631,806825,806847,806908,806976,806980,807431,807517,807560,807853,808166,808307,808829,808966,808991,809155,809166,809375,809493,809748,812281,812315,813963,816443,819789,89359 CVE References: CVE-2010-3873,CVE-2011-4131,CVE-2011-4604,CVE-2011-4622,CVE-2012-1601,CVE-2012-2119,CVE-2012-2137,CVE-2012-4461,CVE-2012-5517,CVE-2013-0160,CVE-2013-0216,CVE-2013-0231,CVE-2013-0871,CVE-2013-0913,CVE-2013-1767,CVE-2013-1774,CVE-2013-1796,CVE-2013-1797,CVE-2013-1798,CVE-2013-1848,CVE-2013-2094 Sources used: openSUSE 11.4 (src): iscsitarget-1.4.19-18.2, kernel-docs-3.0.74-34.2, kernel-source-3.0.74-34.1, kernel-syms-3.0.74-34.1, ndiswrapper-1.57rc1-20.1, omnibook-20100406-13.1, open-vm-tools-2012.8.8.1-41.1, pcfclock-0.44-250.1, preload-1.2-6.29.1, systemtap-1.4-1.11.1, virtualbox-4.0.12-0.58.1, xen-4.0.3_05-57.1, xtables-addons-1.37-0.22.1
We have just released a kernel update for SUSE Linux Enterprise 11 SP2 that mentions/fixes this problem. Released kernel version is 3.0.80-0.5.1.
The SWAMPID for this issue is 54954. This issue was rated as moderate. Please submit fixed packages until 2013-11-20. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
Update released for: kernel-default, kernel-default-debuginfo, kernel-source, kernel-syms Products: SLE-DEBUGINFO 10-SP3 (s390x) SLE-SERVER 10-SP3-LTSS (s390x)
Update released for: kernel-bigsmp, kernel-bigsmp-debuginfo, kernel-debug, kernel-debug-debuginfo, kernel-default, kernel-default-debuginfo, kernel-kdump, kernel-kdump-debuginfo, kernel-kdumppae, kernel-kdumppae-debuginfo, kernel-smp, kernel-smp-debuginfo, kernel-source, kernel-source-debuginfo, kernel-syms, kernel-syms-debuginfo, kernel-vmi, kernel-vmi-debuginfo, kernel-vmipae, kernel-vmipae-debuginfo, kernel-xen, kernel-xen-debuginfo, kernel-xenpae, kernel-xenpae-debuginfo Products: SLE-DEBUGINFO 10-SP3 (i386) SLE-SERVER 10-SP3-LTSS (i386)
Update released for: btrfs-kmp-default, btrfs-kmp-pae, btrfs-kmp-trace, btrfs-kmp-xen, cluster-network-kmp-default, cluster-network-kmp-pae, cluster-network-kmp-trace, cluster-network-kmp-xen, ext4dev-kmp-default, ext4dev-kmp-pae, ext4dev-kmp-trace, ext4dev-kmp-xen, gfs2-kmp-default, gfs2-kmp-pae, gfs2-kmp-trace, gfs2-kmp-xen, hyper-v-kmp-default, hyper-v-kmp-pae, hyper-v-kmp-trace, kernel-default, kernel-default-base, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-devel-debuginfo, kernel-default-extra, kernel-desktop-devel, kernel-ec2, kernel-ec2-base, kernel-ec2-debuginfo, kernel-ec2-debugsource, kernel-ec2-devel, kernel-ec2-devel-debuginfo, kernel-ec2-extra, kernel-pae, kernel-pae-base, kernel-pae-debuginfo, kernel-pae-debugsource, kernel-pae-devel, kernel-pae-devel-debuginfo, kernel-pae-extra, kernel-source, kernel-source-debuginfo, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-devel-debuginfo, kernel-trace-extra, kernel-xen, kernel-xen-base, kernel-xen-debuginfo, kernel-xen-debugsource, kernel-xen-devel, kernel-xen-devel-debuginfo, kernel-xen-extra, ocfs2-kmp-default, ocfs2-kmp-pae, ocfs2-kmp-trace, ocfs2-kmp-xen Products: SLE-DEBUGINFO 11-SP1 (i386) SLE-SERVER 11-SP1-LTSS (i386)
Update released for: btrfs-kmp-default, btrfs-kmp-trace, cluster-network-kmp-default, cluster-network-kmp-trace, ext4dev-kmp-default, ext4dev-kmp-trace, gfs2-kmp-default, gfs2-kmp-trace, kernel-default, kernel-default-base, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-devel-debuginfo, kernel-default-extra, kernel-default-man, kernel-source, kernel-source-debuginfo, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-devel-debuginfo, kernel-trace-extra, kernel-trace-man, ocfs2-kmp-default, ocfs2-kmp-trace Products: SLE-DEBUGINFO 11-SP1 (s390x) SLE-SERVER 11-SP1-LTSS (s390x)
Update released for: btrfs-kmp-default, btrfs-kmp-trace, btrfs-kmp-xen, cluster-network-kmp-default, cluster-network-kmp-trace, cluster-network-kmp-xen, ext4dev-kmp-default, ext4dev-kmp-trace, ext4dev-kmp-xen, gfs2-kmp-default, gfs2-kmp-trace, gfs2-kmp-xen, hyper-v-kmp-default, hyper-v-kmp-trace, kernel-default, kernel-default-base, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-devel-debuginfo, kernel-default-extra, kernel-desktop-devel, kernel-ec2, kernel-ec2-base, kernel-ec2-debuginfo, kernel-ec2-debugsource, kernel-ec2-devel, kernel-ec2-devel-debuginfo, kernel-ec2-extra, kernel-source, kernel-source-debuginfo, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-devel-debuginfo, kernel-trace-extra, kernel-xen, kernel-xen-base, kernel-xen-debuginfo, kernel-xen-debugsource, kernel-xen-devel, kernel-xen-devel-debuginfo, kernel-xen-extra, ocfs2-kmp-default, ocfs2-kmp-trace, ocfs2-kmp-xen Products: SLE-DEBUGINFO 11-SP1 (x86_64) SLE-SERVER 11-SP1-LTSS (x86_64)
SUSE-SU-2014:0287-1: An update that solves 84 vulnerabilities and has 41 fixes is now available. Category: security (moderate) Bug References: 714906,715250,735347,744955,745640,748896,752544,754898,760596,761774,762099,762366,763463,763654,767610,767612,768668,769644,769896,770695,771706,771992,772849,773320,773383,773577,773640,773831,774523,775182,776024,776144,776885,777473,780004,780008,780572,782178,785016,786013,787573,787576,789648,789831,795354,797175,798050,800280,801178,802642,803320,804154,804653,805226,805227,805945,806138,806976,806977,806980,807320,808358,808827,809889,809891,809892,809893,809894,809898,809899,809900,809901,809902,809903,810045,810473,811354,812364,813276,813735,814363,814716,815352,815745,816668,817377,818337,818371,820338,822575,822579,823260,823267,823618,824159,824295,825227,826707,827416,827749,827750,828012,828119,833820,835094,835481,835839,840226,840858,845028,847652,847672,848321,849021,851095,851103,852558,852559,853050,853051,853052,856917,858869,858870,858872 CVE References: CVE-2011-1083,CVE-2011-3593,CVE-2012-1601,CVE-2012-2137,CVE-2012-2372,CVE-2012-2745,CVE-2012-3375,CVE-2012-3412,CVE-2012-3430,CVE-2012-3511,CVE-2012-4444,CVE-2012-4530,CVE-2012-4565,CVE-2012-6537,CVE-2012-6538,CVE-2012-6539,CVE-2012-6540,CVE-2012-6541,CVE-2012-6542,CVE-2012-6544,CVE-2012-6545,CVE-2012-6546,CVE-2012-6547,CVE-2012-6548,CVE-2012-6549,CVE-2013-0160,CVE-2013-0216,CVE-2013-0231,CVE-2013-0268,CVE-2013-0310,CVE-2013-0343,CVE-2013-0349,CVE-2013-0871,CVE-2013-0914,CVE-2013-1767,CVE-2013-1773,CVE-2013-1774,CVE-2013-1792,CVE-2013-1796,CVE-2013-1797,CVE-2013-1798,CVE-2013-1827,CVE-2013-1928,CVE-2013-1943,CVE-2013-2015,CVE-2013-2141,CVE-2013-2147,CVE-2013-2164,CVE-2013-2232,CVE-2013-2234,CVE-2013-2237,CVE-2013-2634,CVE-2013-2851,CVE-2013-2852,CVE-2013-2888,CVE-2013-2889,CVE-2013-2892,CVE-2013-2893,CVE-2013-2897,CVE-2013-2929,CVE-2013-3222,CVE-2013-3223,CVE-2013-3224,CVE-2013-3225,CVE-2013-3228,CVE-2013-3229,CVE-2013-3231,CVE-2013-3232,CVE-2013-3234,CVE-2013-3235,CVE-2013-4345,CVE-2013-4470,CVE-2013-4483,CVE-2013-4511,CVE-2013-4587,CVE-2013-4588,CVE-2013-4591,CVE-2013-6367,CVE-2013-6368,CVE-2013-6378,CVE-2013-6383,CVE-2014-1444,CVE-2014-1445,CVE-2014-1446 Sources used: SUSE Linux Enterprise Server 11 SP1 LTSS (src): btrfs-0-0.3.151, ext4dev-0-7.9.118, hyper-v-0-0.18.37, kernel-default-2.6.32.59-0.9.1, kernel-ec2-2.6.32.59-0.9.1, kernel-pae-2.6.32.59-0.9.1, kernel-source-2.6.32.59-0.9.1, kernel-syms-2.6.32.59-0.9.1, kernel-trace-2.6.32.59-0.9.1, kernel-xen-2.6.32.59-0.9.1 SLE 11 SERVER Unsupported Extras (src): kernel-default-2.6.32.59-0.9.1, kernel-pae-2.6.32.59-0.9.1, kernel-xen-2.6.32.59-0.9.1
Update released for: kernel-default-extra, kernel-xen-extra Products: SLE-SERVER 11-EXTRA (x86_64)
Update released for: kernel-default-extra, kernel-pae-extra, kernel-xen-extra Products: SLE-SERVER 11-EXTRA (i386)
Update released for: kernel-default-extra Products: SLE-SERVER 11-EXTRA (s390x)