Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 104602 Details for
Bug 158784
Linux 2.6.x ext3fs_dirhash denial of service (CVE-2006-6053)
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
[patch]
Patch for 2.6.18 and 2.6.19
patch (text/plain), 3.11 KB, created by
Daniel Drake (RETIRED)
on 2006-12-22 11:46:33 UTC
(
hide
)
Description:
Patch for 2.6.18 and 2.6.19
Filename:
MIME Type:
Creator:
Daniel Drake (RETIRED)
Created:
2006-12-22 11:46:33 UTC
Size:
3.11 KB
patch
obsolete
>From: Eric Sandeen <sandeen@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-rc1 >X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;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@redhat.com> >Cc: <linux-ext4@vger.kernel.org> >Signed-off-by: Andrew Morton <akpm@osdl.org> >Signed-off-by: Linus Torvalds <torvalds@osdl.org> >--- > >--- a/fs/ext3/dir.c >+++ b/fs/ext3/dir.c >@@ -154,6 +154,9 @@ static int ext3_readdir(struct file * fi > 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; > } >--- a/fs/ext3/namei.c >+++ b/fs/ext3/namei.c >@@ -552,6 +552,15 @@ static int htree_dirblock_to_tree(struct > 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) &&
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 158784
: 104602