[kernel-sec-discuss] r797 - active ignored

Moritz Muehlenhoff jmm at alioth.debian.org
Tue May 1 00:23:01 UTC 2007


Author: jmm
Date: 2007-05-01 00:23:01 +0000 (Tue, 01 May 2007)
New Revision: 797

Added:
   ignored/CVE-2005-3527
Removed:
   active/CVE-2005-3527
Log:
moving to ignored, this is way too intrusive to backport


Deleted: active/CVE-2005-3527
===================================================================
--- active/CVE-2005-3527	2007-05-01 00:21:44 UTC (rev 796)
+++ active/CVE-2005-3527	2007-05-01 00:23:01 UTC (rev 797)
@@ -1,34 +0,0 @@
-Candidate: CVE-2005-3527
-References: 
- CONFIRM:http://www.kernel.org/git/?p=linux/kernel/git/davem/sparc-2.6.git;a=commitdiff;h=788e05a67c343fa22f2ae1d3ca264e7f15c25eaf
-Description:
- Race condition in signal handling
- Race condition in do_coredump in signal.c in Linux kernel 2.6 allows local
- users to cause a denial of service by triggering a core dump in one thread
- while another thread has a pending SIGSTOP
-Notes: 
- dannf> The changed code doesn't exist in 2.6.8.  That code was added later in:
-        http://linux.bkbits.net:8080/linux-2.6/cset@41db7d2cBjKGtCZDlUmwwo2dgMZ6Wg?nav=index.html|src/|src/kernel|related/kernel/signal.c
-        Its unclear to me whether or not that patch added the bug, or just made it
-        look different.
-        Applying all the prereq changes to get our code to resemble the fixed
-        code does not look feasible; there are a lot, and some add new features.
- horms> This specific problem seems to haev been introduced by the
-        changeset above. That changeset fixed a problem where STOP signals
-	weren't correctly canceled if SIGTERM or SIGCONT arrived.
-	However, that problem seems a lot more mild than CVE-2005-3527.
-	And I agree with dannf's analysis that backporting is too hard.
-	To support this, look at how many times STOP signal races
-	have been fixed since 2.6.8 and note that problems are still
-	being found.
- dannf> Same with 2.4.27.
- horms> I'm not entirely sure that 2.4.27 suffers from any of these
-	problems. But I think it is fair to say that if it does, 
-	backporting is too hard for the same reasons as 2.6.8.
-Bugs: 
-upstream: released (2.6.14)
-linux-2.6: N/A
-2.6.8-sarge-security: ignored (2.6.8-16sarge5)
-2.4.27-sarge-security: ignored (2.4.27-10sarge5)
-2.6.18-etch-security: N/A
-

Copied: ignored/CVE-2005-3527 (from rev 790, active/CVE-2005-3527)




More information about the kernel-sec-discuss mailing list