BUG: bd_set_size NULL deref

[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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/