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