From 1c072f8a5423c008ff5201d0434c4bd155981d5d Mon Sep 17 00:00:00 2001 From: Moritz Muehlenhoff Date: Tue, 1 May 2007 00:23:01 +0000 Subject: moving to ignored, this is way too intrusive to backport git-svn-id: svn+ssh://svn.debian.org/svn/kernel-sec@797 e094ebfe-e918-0410-adfb-c712417f3574 --- active/CVE-2005-3527 | 34 ---------------------------------- ignored/CVE-2005-3527 | 34 ++++++++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+), 34 deletions(-) delete mode 100644 active/CVE-2005-3527 create mode 100644 ignored/CVE-2005-3527 diff --git a/active/CVE-2005-3527 b/active/CVE-2005-3527 deleted file mode 100644 index 3da53cb0..00000000 --- a/active/CVE-2005-3527 +++ /dev/null @@ -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 - diff --git a/ignored/CVE-2005-3527 b/ignored/CVE-2005-3527 new file mode 100644 index 00000000..3da53cb0 --- /dev/null +++ b/ignored/CVE-2005-3527 @@ -0,0 +1,34 @@ +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 + -- cgit v1.2.3