Bug 250623 - CVE-2006-6058 minix_bmap denial of service
CVE-2006-6058 minix_bmap denial of service
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
http://projects.info-pull.com/mokb/MO...
impact=low,source=internet,reported=2...
: Security
Depends On: CVE-2006-6058
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-02 10:53 EDT by Lubomir Kundrak
Modified: 2007-12-02 22:57 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-02 22:57:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lubomir Kundrak 2007-08-02 10:53:06 EDT
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.
Comment 1 Chuck Ebbert 2007-08-02 17:22:39 EDT
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
Comment 2 Eric Sandeen 2007-08-06 16:58:04 EDT
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....
Comment 3 Lubomir Kundrak 2007-08-07 08:38:03 EDT
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.
Comment 4 Eric Sandeen 2007-08-08 11:10:03 EDT
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?
Comment 5 Eric Sandeen 2007-08-08 11:11:13 EDT
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
Comment 6 Eric Sandeen 2007-08-08 12:16:13 EDT
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 :)
Comment 7 Eric Sandeen 2007-08-09 14:51:19 EDT
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
Comment 8 Eric Sandeen 2007-08-16 15:36:20 EDT
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...?
Comment 9 Eric Sandeen 2007-08-16 15:53:23 EDT
patch sent to -stable as well.
Comment 10 Eric Sandeen 2007-10-30 12:52:04 EDT
In Linus' tree now, and re-proposed for -stable
Comment 11 Eric Sandeen 2007-12-02 22:57:05 EST
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... :)

Note You need to log in before you can comment on or make changes to this bug.