This issue also affects Fedora: +++ This bug was initially created as a clone of Bug #217007 +++ From MOKB-17-11-2006: http://projects.info-pull.com/mokb/MOKB-17-11-2006.html The 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. This also affects 2.4 kernels.
MINIX-fs: mounting unchecked file system, running fsck is recommended Buffer I/O error on device loop0, logical block 53248 Buffer I/O error on device loop0, logical block 53248 Buffer I/O error on device loop0, logical block 63744 Buffer I/O error on device loop0, logical block 63744 Buffer I/O error on device loop0, logical block 29952 Buffer I/O error on device loop0, logical block 29952 Buffer I/O error on device loop0, logical block 8960 Buffer I/O error on device loop0, logical block 8960 Buffer I/O error on device loop0, logical block 33024 Buffer I/O error on device loop0, logical block 33024 minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big minix_bmap: block>big (... infinite loop ....) 334 static sector_t minix_bmap(struct address_space *mapping, sector_t block) 335 { 336 return generic_block_bmap(mapping,block,minix_get_block); 337 } 338 static const struct address_space_operations minix_aops = { 339 .readpage = minix_readpage, 340 .writepage = minix_writepage, 341 .sync_page = block_sync_page, 342 .prepare_write = minix_prepare_write, 343 .commit_write = generic_commit_write, 344 .bmap = minix_bmap 345 }; 23 static int block_to_path(struct inode * inode, long block, int offsets[DEPTH]) 24 { 25 int n = 0; 26 27 if (block < 0) { 28 printk("minix_bmap: block<0\n"); 29 } else if (block >= (minix_sb(inode->i_sb)->s_max_size/BLOCK_SIZE)) { 30 printk("minix_bmap: block>big\n"); 31 } else if (block < 7) { 32 offsets[n++] = block; 33 } else if ((block -= 7) < 256) { 34 offsets[n++] = 7; 35 offsets[n++] = block; 36 } else if ((block -= 256) < 256*256) { 37 offsets[n++] = 8; 38 offsets[n++] = block>>8; 39 offsets[n++] = block & 255; 40 } else { 41 block -= 256*256; 42 offsets[n++] = 9; 43 offsets[n++] = block>>16; 44 offsets[n++] = (block>>8) & 255; 45 offsets[n++] = block & 255; 46 } 47 return n; 27 #define BLOCK_SIZE_BITS 10
Huh, ok, I wasn't able to reproduce this one... looks like Chuck could though... oh, or was that just a paste from the original report....
It is likely that upstream rebase to usptream 2.6.19 (or some other) fixed the issue. Though we are still tracking this as nonresolved for Fedora, as no update referenced CVE-2006-6058. Unless it would take too much time, could you please tell which kernel update fixed this issue? Otherwise just close this as RESOLVED CURRENTRELEASE.
I have not been able to hit this on RHEL5/x86 or F8/x86_64 I also tested it on the exact kernel reported, kernel-2.6.18-1.2798.fc6.i686.rpm, and I did not hit the problem. I don't see anything in the changelogs that suggests a fix for this exact problem; closest seems to be http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f5fb09fa3392ad43fbcfc2f4580752f383ab5996 but that went in well before the MOKB report. Any problem with closing as RESOLVED WORKSFORME?
Ugh, spoke too soon. original report says "mount" causes the problem; in fact mount followed by ls -R *will* trip it. Ok, I'll look into this. -Eric
So, the problem here is that the corrupted image has a directory that claims to be manymanymany pages long. minix_read_dir tries to read them all, and if it gets an error on any one, it tries the next. Printk'ing along the way, all under the BKL. It *should* actually finish... eventually :)
Ok, sent a patch for this, we'll see what the minix gods say (if there are any left besides Linus) :) http://lkml.org/lkml/2007/8/9/382
Patch now in -mm as "limit-minixfs-printks-on-corrupted-dir-i_size.patch" Dave, you want me to send FC patches or can we just pick this up via upstream...?
patch sent to -stable as well.
In Linus' tree now, and re-proposed for -stable
So, this didn't make it to 2.6.22 stable branches, but it is in 2.6.24-rc1. It doesn't strike me as a particularly horrible exploit, so I'm going to slyly change the release to F7, and close it since it'll be in 2.6.24 once that's released, and finally get it off my bug list, which is quite long enough without it... :)