Linux 2.6.x minix filesystem code fails to properly handle corrupted data structures, leading to an exploitable denial of service issue when a crafted fs stream is being mounted. Note: Many of these DoS related issues are actually caused by integer overflow and signedness problems, although, as these are extremely common (in the Linux kernel, that is), it became a tedious task to track them all. Have fun grep'ing around.
Appears to be unfixed upstream, sent a mail to security@kernel.org
No response, filed bug at http://bugzilla.kernel.org/show_bug.cgi?id=7758
*** Bug 155534 has been marked as a duplicate of this bug. ***
Seems this is fixed with 2.6.24: commit f44ec6f3f89889a469773b1fd894f8fcc07c29cf Author: Eric Sandeen <sandeen@redhat.com> Date: Tue Oct 16 23:27:15 2007 -0700 limit minixfs printks on corrupted dir i_size This attempts to address CVE-2006-6058 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6058 first reported at http://projects.info-pull.com/mokb/MOKB-17-11-2006.html Essentially a corrupted minix dir inode reporting a very large i_size will loop for a very long time in minix_readdir, minix_find_entry, etc, because on EIO they just move on to try the next page. This is under the BKL, printk-storming as well. This can lock up the machine for a very long time. Simply ratelimiting the printks gets things back under control. Make the message a bit more informative while we're here. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Cc: Bodo Eggert <7eggert@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
proposed metadata: [linux < 2.6.24-1][gp < 2.6.24][gentoo < 2.6.24] kernel.org commit id f44ec6f3f89889a469773b1fd894f8fcc07c29cf
*sigh* metadata correction: [linux < 2.6.24][gp < 2.6.24-1][gentoo < 2.6.24]
