• Phillip Lougher's avatar
    hfs: fix hfs_find_init() sb->ext_tree NULL ptr oops · 434a964d
    Phillip Lougher authored
    Clement Lecigne reports a filesystem which causes a kernel oops in
    hfs_find_init() trying to dereference sb->ext_tree which is NULL.
    
    This proves to be because the filesystem has a corrupted MDB extent
    record, where the extents file does not fit into the first three extents
    in the file record (the first blocks).
    
    In hfs_get_block() when looking up the blocks for the extent file
    (HFS_EXT_CNID), it fails the first blocks special case, and falls
    through to the extent code (which ultimately calls hfs_find_init())
    which is in the process of being initialised.
    
    Hfs avoids this scenario by always having the extents b-tree fitting
    into the first blocks (the extents B-tree can't have overflow extents).
    
    The fix is to check at mount time that the B-tree fits into first
    blocks, i.e.  fail if HFS_I(inode)->alloc_blocks >=
    HFS_I(inode)->first_blocks
    
    Note, the existing commit 47f365eb ("hfs: fix oops on mount with
    corrupted btree extent records") becomes subsumed into this as a special
    case, but only for the extents B-tree (HFS_EXT_CNID), it is perfectly
    acceptable for the catalog B-Tree file to grow beyond three extents,
    with the remaining extent descriptors in the extents overfow.
    
    This fixes CVE-2011-2203
    Reported-by: default avatarClement LECIGNE <clement.lecigne@netasq.com>
    Signed-off-by: default avatarPhillip Lougher <plougher@redhat.com>
    Cc: Jeff Mahoney <jeffm@suse.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    434a964d
btree.c 8.78 KB