blob: 3da53cb0acb51991cb3f90ba13bc9bf3b2b408f0 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
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
|
