[Patch] Fix another bug in hfsplus when reading a corrupted image - Kernel

This is a discussion on [Patch] Fix another bug in hfsplus when reading a corrupted image - Kernel ; hi, another bug that popped up when testing hfsplus with corrupted images. [ 144.632017] BUG: unable to handle kernel NULL pointer dereference at 00000034 [ 144.633047] IP: [ ] hfsplus_find_init+0x24/0x5a [ 144.633047] *pde = 00000000 [ 144.633047] Oops: 0000 [#1] ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: [Patch] Fix another bug in hfsplus when reading a corrupted image

  1. [Patch] Fix another bug in hfsplus when reading a corrupted image

    hi,

    another bug that popped up when testing hfsplus with corrupted images.

    [ 144.632017] BUG: unable to handle kernel NULL pointer dereference at 00000034
    [ 144.633047] IP: [] hfsplus_find_init+0x24/0x5a
    [ 144.633047] *pde = 00000000
    [ 144.633047] Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
    [ 144.633047] Modules linked in:
    [ 144.633047]
    [ 144.633047] Pid: 4845, comm: mount Not tainted (2.6.27-rc4-00131-g83097ac-dirty #32)
    [ 144.633047] EIP: 0060:[] EFLAGS: 00010202 CPU: 0
    [ 144.633047] EIP is at hfsplus_find_init+0x24/0x5a
    [ 144.633047] EAX: 0000001d EBX: c6eaca84 ECX: c011bf0c EDX: 000000d0
    [ 144.633047] ESI: 00000000 EDI: c6eb810c EBP: c6eaca74 ESP: c6eaca60
    [ 144.633047] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
    [ 144.633047] Process mount (pid: 4845, ti=c6eac000 task=c6e80000 task.ti=c6eac000)
    [ 144.633047] Stack: c0801a93 00000000 c6eaca84 c6eaca84 c6eb8000 c6eacab4 c022c900 00000000
    [ 144.633047] c022ce68 00000000 c6eb8004 00000000 00000000 22222222 22222222 22222222
    [ 144.633047] 22222222 22222222 00000000 c1098a40 c6eb8000 c6eacae0 c022ce72 c6eb82ac
    [ 144.633047] Call Trace:
    [ 144.633047] [] ? hfsplus_ext_read_extent+0x47/0x12a
    [ 144.633047] [] ? hfsplus_get_block+0xb3/0x19d
    [ 144.633047] [] ? hfsplus_get_block+0xbd/0x19d
    [ 144.633047] [] ? block_read_full_page+0x172/0x2b4
    [ 144.633047] [] ? hfsplus_get_block+0x0/0x19d
    [ 144.633047] [] ? add_to_page_cache_locked+0xa9/0xc4
    [ 144.633047] [] ? lru_cache_add+0x53/0x69
    [ 144.633047] [] ? hfsplus_readpage+0xf/0x11
    [ 144.633047] [] ? read_cache_page_async+0x79/0x108
    [ 144.633047] [] ? hfsplus_readpage+0x0/0x11
    [ 144.633048] [] ? read_cache_page+0xc/0x3f
    [ 144.633048] [] ? hfsplus_btree_open+0x104/0x267
    [ 144.633048] [] ? hfsplus_fill_super+0x211/0x447
    [ 144.633048] [] ? trace_hardirqs_off_caller+0x14/0x9b
    [ 144.633048] [] ? trace_hardirqs_off+0xb/0xd
    [ 144.633048] [] ? native_sched_clock+0x82/0x96
    [ 144.633048] [] ? trace_hardirqs_on+0xb/0xd
    [ 144.633048] [] ? trace_hardirqs_on+0xb/0xd
    [ 144.633048] [] ? trace_hardirqs_on_caller+0xf4/0x12f
    [ 144.633048] [] ? trace_hardirqs_on+0xb/0xd
    [ 144.633048] [] ? mutex_unlock+0x8/0xa
    [ 144.633048] [] ? do_open+0x20b/0x280
    [ 144.633048] [] ? __blkdev_get+0x7d/0x88
    [ 144.633048] [] ? string+0x2b/0x74
    [ 144.633048] [] ? vsnprintf+0x2e9/0x512
    [ 144.633048] [] ? dump_trace+0xca/0xd6
    [ 144.633048] [] ? save_stack_trace+0x1c/0x3a
    [ 144.633048] [] ? save_stack_trace+0x1c/0x3a
    [ 144.633048] [] ? save_trace+0x37/0x8d
    [ 144.633048] [] ? add_lock_to_list+0x67/0x8d
    [ 144.633048] [] ? validate_chain+0x8a4/0x9f4
    [ 144.633048] [] ? up+0xc/0x2f
    [ 144.633048] [] ? __lock_acquire+0x68a/0x6e0
    [ 144.633048] [] ? trace_hardirqs_off+0xb/0xd
    [ 144.633048] [] ? trace_hardirqs_off_caller+0x14/0x9b
    [ 144.633048] [] ? trace_hardirqs_off+0xb/0xd
    [ 144.633048] [] ? native_sched_clock+0x82/0x96
    [ 144.633048] [] ? snprintf+0x1b/0x1d
    [ 144.633048] [] ? disk_name+0x25/0x67
    [ 144.633048] [] ? get_sb_bdev+0xcd/0x10b
    [ 144.633048] [] ? kstrdup+0x2a/0x4c
    [ 144.633048] [] ? hfsplus_get_sb+0x13/0x15
    [ 144.633048] [] ? hfsplus_fill_super+0x0/0x447
    [ 144.633048] [] ? vfs_kern_mount+0x3b/0x76
    [ 144.633048] [] ? do_kern_mount+0x32/0xba
    [ 144.633048] [] ? do_new_mount+0x46/0x74
    [ 144.633048] [] ? do_mount+0x175/0x193
    [ 144.633048] [] ? trace_hardirqs_on_caller+0xf4/0x12f
    [ 144.633048] [] ? __get_free_pages+0x1e/0x24
    [ 144.633048] [] ? lock_kernel+0x19/0x8c
    [ 144.633048] [] ? sys_mount+0x51/0x9b
    [ 144.633048] [] ? sys_mount+0x64/0x9b
    [ 144.633048] [] ? sysenter_do_call+0x12/0x31
    [ 144.633048] =======================
    [ 144.633048] Code: 00 00 00 00 5b 5d c3 55 89 e5 56 89 c6 53 89 d3 52 50 68 93 1a 80 c0 e8 f2 24 ef ff
    ba d0 00 00 00 89 73 08 c7 43 0c 00 00 00 00 <8b> 46 34 8d 44 00 04 e8 f9 e0 f4 ff ba f4 ff ff ff 83 c4 0
    c 85
    [ 144.633048] EIP: [] hfsplus_find_init+0x24/0x5a SS:ESP 0068:c6eaca60
    [ 144.659114] ---[ end trace 3e5c566484eaaae5 ]---


    Problem is that there is no ext_tree, causing the NULL-pointer
    dereference in hfsplus_init(). This fixes the issue by checking the ext_tree in
    hfsplus_get_block() and aborting early enoug.

    Signed-off-by: Eric Sesterhenn


    --- linux/fs/hfsplus/extents.orig 2008-08-26 14:51:08.000000000 +0200
    +++ linux/fs/hfsplus/extents.c 2008-08-26 14:51:48.000000000 +0200
    @@ -199,6 +199,9 @@ int hfsplus_get_block(struct inode *inod
    goto done;
    }

    + if (HFSPLUS_SB(inode->i_sb).ext_tree == NULL)
    + return -EIO;
    +
    mutex_lock(&HFSPLUS_I(inode).extents_lock);
    res = hfsplus_ext_read_extent(inode, ablock);
    if (!res) {
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [Patch] Fix another bug in hfsplus when reading a corrupted image

    Hi,

    On Tue, 26 Aug 2008, Eric Sesterhenn wrote:

    > Problem is that there is no ext_tree, causing the NULL-pointer
    > dereference in hfsplus_init(). This fixes the issue by checking the ext_tree in
    > hfsplus_get_block() and aborting early enoug.


    The problem is worse, a corrupted extent for the extent file itself may
    try to get an impossible extent, causing a deadlock if I see it correctly.
    A better fix would be to check the inode number after the first_blocks
    checks and fail if it's the extent file, as according to the spec the
    extent file should have no extent for itself.

    bye, Roman
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [Patch] Fix another bug in hfsplus when reading a corrupted image

    * Roman Zippel (zippel@linux-m68k.org) wrote:
    > Hi,
    >
    > On Tue, 26 Aug 2008, Eric Sesterhenn wrote:
    >
    > > Problem is that there is no ext_tree, causing the NULL-pointer
    > > dereference in hfsplus_init(). This fixes the issue by checking the ext_tree in
    > > hfsplus_get_block() and aborting early enoug.

    >
    > The problem is worse, a corrupted extent for the extent file itself may
    > try to get an impossible extent, causing a deadlock if I see it correctly.
    > A better fix would be to check the inode number after the first_blocks
    > checks and fail if it's the extent file, as according to the spec the
    > extent file should have no extent for itself.


    I guess you had something in mind like this, which also fixes the issue
    for me.

    Signed-off-by: Eric Sesterhenn


    --- linux/fs/hfsplus/extents.orig 2008-08-26 14:51:08.000000000 +0200
    +++ linux/fs/hfsplus/extents.c 2008-09-03 17:58:35.000000000 +0200
    @@ -199,6 +199,9 @@ int hfsplus_get_block(struct inode *inod
    goto done;
    }

    + if (inode->i_ino == HFSPLUS_EXT_CNID)
    + return -EIO;
    +
    mutex_lock(&HFSPLUS_I(inode).extents_lock);
    res = hfsplus_ext_read_extent(inode, ablock);
    if (!res) {
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread