Messages in this thread | | | Date | Wed, 13 Feb 2013 16:24:19 -0800 | Subject | BUG: bd_set_size NULL deref | From | Kees Cook <> |
| |
Hi,
I've encountered the same bug as described here: http://lkml.indiana.edu/hypermail/linux/kernel/1208.0/01804.html
[93652.097167] BUG: unable to handle kernel NULL pointer dereference at 0000000000000398 [93652.097197] IP: [<ffffffff810fdc67>] bd_set_size+0x10/0x6f ... [93652.102098] [<ffffffff812d31c7>] loop_clr_fd+0x15e/0x201 [93652.102114] [<ffffffff812d3ce0>] lo_ioctl+0x462/0x5e1 [93652.102133] [<ffffffff811c9d2c>] __blkdev_driver_ioctl+0x28/0x2a [93652.102150] [<ffffffff811ca644>] blkdev_ioctl+0x66c/0x684 [93652.102165] [<ffffffff810fdd06>] block_ioctl+0x40/0x44 [93652.102183] [<ffffffff810e1b9c>] do_vfs_ioctl+0x469/0x4aa [93652.102201] [<ffffffff810d7911>] ? sys_newfstat+0x2a/0x33 [93652.102216] [<ffffffff810e1c33>] sys_ioctl+0x56/0x7b [93652.102234] [<ffffffff8145f512>] system_call_fastpath+0x16/0x1b
It looks like bdev->bd_disk is NULL while running loop_clr_fd with a non-NULL bdev. Looking around at things that clear bd_disk, it's not obvious what could be racing this. It happens while cleaning up a loopback used under dm-crypt -- are there delayed cleanups happening on release that could possibly race the loop_clr_fd call?
I've had a hard time reproducing the problem too, unfortunately. Does anyone have ideas on what this could be?
Thanks,
-Kees
-- Kees Cook Chrome OS Security
| |