blob: 5fb5a10eb54c23c9bc2db185cb26d9d5d386d487 (
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-2006-6060
References:
MISC:http://projects.info-pull.com/mokb/MOKB-19-11-2006.html
Description:
The NTFS filesystem code in Linux kernel 2.6.x up to 2.6.18, and possibly
other versions, allows local users to cause a denial of service (CPU
consumption) via a malformed NTFS file stream that triggers an infinite loop
in the __find_get_block_slow function.
Ubuntu-Description:
Notes:
fixed by patch for CVE-2006-5757 since the bug is in the common
__find_get_block_slow() function.
dannf> reproducer at http://projects.info-pull.com/mokb/MOKB-19-11-2006.html
dannf> I mounted the reproducer fs on an ia64/2.4.27 system and though
it didn't cause an infinite loop, the system did lock up hard
jmm> e5657933863f43cc6bb76a54d659303dafaa9e58 in Linus git
dannf> The reproducer causes i386/2.4.36 to oops; but if this patch is
backported and applied it will print:
NTFS: Problem with runlist in extended record
... and then oops.
So, I'm guessing this patch makes things better, but I don't think
its worth the risk of applying it unless the other oops gets fixed
as well.
dannf> Unpatched 2.4.27 oopses and prints the same runlist message that
patched 2.4.36 prints
Bugs:
upstream: released (2.6.19)
linux-2.6: released (2.6.18.dfsg.1-10) [2.6.16.38]
2.6.18-etch-security: released (2.6.18.dfsg.1-10) [2.6.16.38]
2.6.8-sarge-security: released (2.6.8-16sarge7) [__find_get_block_slow-race.dpatch]
2.4.27-sarge-security: ignored (2.4.27-10sarge6) "Fixes an oops, only to hit another oops"
2.6.15-dapper-security: N/A - fixed in CVE-2006-5757
2.6.17-edgy-security: N/A - already applied.
2.6.20-feisty-security: N/A
|
