[kernel] r8410 - in
dists/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian:
. patches patches/series
Dann Frazier
dannf at alioth.debian.org
Sat Mar 31 21:45:57 UTC 2007
Author: dannf
Date: Sat Mar 31 21:45:56 2007
New Revision: 8410
Added:
dists/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/ext3-fsfuzz.dpatch
Modified:
dists/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian/changelog
dists/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/series/2.6.8-16sarge7
Log:
* ext3-fsfuzz.dpatch
[SECURITY] Fix a DoS vulnerability that can be triggered by a local
user with the ability to mount a corrupted ext3 filesystem
See CVE-2006-6053
Modified: dists/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian/changelog
==============================================================================
--- dists/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian/changelog (original)
+++ dists/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian/changelog Sat Mar 31 21:45:56 2007
@@ -43,8 +43,12 @@
for users that compile their own kernels with the Debian source and
enable/use huge pages.
See CVE-2005-4811
+ * ext3-fsfuzz.dpatch
+ [SECURITY] Fix a DoS vulnerability that can be triggered by a local
+ user with the ability to mount a corrupted ext3 filesystem
+ See CVE-2006-6053
- -- dann frazier <dannf at debian.org> Sat, 31 Mar 2007 14:38:33 -0600
+ -- dann frazier <dannf at debian.org> Sat, 31 Mar 2007 15:43:28 -0600
kernel-source-2.6.8 (2.6.8-16sarge6) stable-security; urgency=high
Added: dists/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/ext3-fsfuzz.dpatch
==============================================================================
--- (empty file)
+++ dists/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/ext3-fsfuzz.dpatch Sat Mar 31 21:45:56 2007
@@ -0,0 +1,82 @@
+From: Eric Sandeen <sandeen at redhat.com>
+Date: Thu, 7 Dec 2006 04:36:26 +0000 (-0800)
+Subject: [PATCH] handle ext3 directory corruption better
+X-Git-Tag: v2.6.20~683^2^2~203
+X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=40b851348fe9bf49c26025b34261d25142269b60
+
+[PATCH] handle ext3 directory corruption better
+
+I've been using Steve Grubb's purely evil "fsfuzzer" tool, at
+http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz
+
+Basically it makes a filesystem, splats some random bits over it, then
+tries to mount it and do some simple filesystem actions.
+
+At best, the filesystem catches the corruption gracefully. At worst,
+things spin out of control.
+
+As you might guess, we found a couple places in ext3 where things spin out
+of control :)
+
+First, we had a corrupted directory that was never checked for
+consistency... it was corrupt, and pointed to another bad "entry" of
+length 0. The for() loop looped forever, since the length of
+ext3_next_entry(de) was 0, and we kept looking at the same pointer over and
+over and over and over... I modeled this check and subsequent action on
+what is done for other directory types in ext3_readdir...
+
+(adding this check adds some computational expense; I am testing a followup
+patch to reduce the number of times we check and re-check these directory
+entries, in all cases. Thanks for the idea, Andreas).
+
+Next we had a root directory inode which had a corrupted size, claimed to
+be > 200M on a 4M filesystem. There was only really 1 block in the
+directory, but because the size was so large, readdir kept coming back for
+more, spewing thousands of printk's along the way.
+
+Per Andreas' suggestion, if we're in this read error condition and we're
+trying to read an offset which is greater than i_blocks worth of bytes,
+stop trying, and break out of the loop.
+
+With these two changes fsfuzz test survives quite well on ext3.
+
+Signed-off-by: Eric Sandeen <sandeen at redhat.com>
+Cc: <linux-ext4 at vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm at osdl.org>
+Signed-off-by: Linus Torvalds <torvalds at osdl.org>
+---
+
+diff --git a/fs/ext3/dir.c b/fs/ext3/dir.c
+index d0b54f3..5a9313e 100644
+--- a/fs/ext3/dir.c
++++ b/fs/ext3/dir.c
+@@ -154,6 +154,9 @@ static int ext3_readdir(struct file * filp,
+ ext3_error (sb, "ext3_readdir",
+ "directory #%lu contains a hole at offset %lu",
+ inode->i_ino, (unsigned long)filp->f_pos);
++ /* corrupt size? Maybe no more blocks to read */
++ if (filp->f_pos > inode->i_blocks << 9)
++ break;
+ filp->f_pos += sb->s_blocksize - offset;
+ continue;
+ }
+diff --git a/fs/ext3/namei.c b/fs/ext3/namei.c
+index 906731a..60d2f9d 100644
+--- a/fs/ext3/namei.c
++++ b/fs/ext3/namei.c
+@@ -552,6 +552,15 @@ static int htree_dirblock_to_tree(struct file *dir_file,
+ dir->i_sb->s_blocksize -
+ EXT3_DIR_REC_LEN(0));
+ for (; de < top; de = ext3_next_entry(de)) {
++ if (!ext3_check_dir_entry("htree_dirblock_to_tree", dir, de, bh,
++ (block<<EXT3_BLOCK_SIZE_BITS(dir->i_sb))
++ +((char *)de - bh->b_data))) {
++ /* On error, skip the f_pos to the next block. */
++ dir_file->f_pos = (dir_file->f_pos |
++ (dir->i_sb->s_blocksize - 1)) + 1;
++ brelse (bh);
++ return count;
++ }
+ ext3fs_dirhash(de->name, de->name_len, hinfo);
+ if ((hinfo->hash < start_hash) ||
+ ((hinfo->hash == start_hash) &&
Modified: dists/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/series/2.6.8-16sarge7
==============================================================================
--- dists/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/series/2.6.8-16sarge7 (original)
+++ dists/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/series/2.6.8-16sarge7 Sat Mar 31 21:45:56 2007
@@ -8,3 +8,4 @@
+ listxattr-mem-corruption.dpatch
+ aio-fix-nr_pages-init.dpatch
+ unmap_hugepage_area-check-null-pte.dpatch
++ ext3-fsfuzz.dpatch
More information about the Kernel-svn-changes
mailing list