BUG: bd_set_size NULL deref

From: Kees Cook
Date: Wed Feb 13 2013 - 19:24:35 EST


I've encountered the same bug as described here:

[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?



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/