Re: BUG: KASAN: use-after-free in scsi_exit_rq

["tj@kernel.org" <tj@kernel.org>]

(cc'ing Jan)

Hello, Bart.

On Fri, Apr 21, 2017 at 09:49:17PM +0000, Bart Van Assche wrote:
> On Thu, 2017-04-20 at 15:18 -0600, Scott Bauer wrote:
> > [  642.638860] BUG: KASAN: use-after-free in scsi_exit_rq+0xf3/0x120 at addr ffff8802b7fedf00
> > [  642.639362] Read of size 1 by task rcuos/5/53
> > [  642.639713] CPU: 7 PID: 53 Comm: rcuos/6 Not tainted 4.11.0-rc5+ #13
> > [  642.640170] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
> > [  642.640923] Call Trace:
> > [  642.641080]  dump_stack+0x63/0x8f
> > [  642.641289]  kasan_object_err+0x21/0x70
> > [  642.641531]  kasan_report.part.1+0x231/0x500
> > [  642.641823]  ? scsi_exit_rq+0xf3/0x120
> > [  642.642054]  ? _raw_spin_unlock_irqrestore+0xe/0x10
> > [  642.642353]  ? free_percpu+0x1b7/0x340
> > [  642.642586]  ? put_task_stack+0x117/0x2b0
> > [  642.642837]  __asan_report_load1_noabort+0x2e/0x30
> > [  642.643138]  scsi_exit_rq+0xf3/0x120
> > [  642.643366]  free_request_size+0x44/0x60
> > [  642.643614]  mempool_destroy.part.6+0x9b/0x150
> > [  642.643899]  ? kasan_slab_free+0x87/0xb0
> > [  642.644152]  mempool_destroy+0x13/0x20
> > [  642.644394]  blk_exit_rl+0x36/0x40
> > [  642.644614]  blkg_free+0x146/0x200
> > [  642.644836]  __blkg_release_rcu+0x121/0x220
> > [  642.645112]  rcu_nocb_kthread+0x61f/0xca0
> > [  642.645376]  ? get_state_synchronize_rcu+0x20/0x20
> > [  642.645690]  ? pci_mmcfg_check_reserved+0x110/0x110
> > [  642.646011]  kthread+0x298/0x390
> > [  642.646224]  ? get_state_synchronize_rcu+0x20/0x20
> > [  642.646535]  ? kthread_park+0x160/0x160
> > [  642.646787]  ret_from_fork+0x2c/0x40
> 
> I'm not familiar with cgroups but seeing this makes me wonder whether it would
> be possible to move the blk_exit_rl() calls from blk_release_queue() into
> blk_cleanup_queue()? The SCSI core frees a SCSI host after blk_cleanup_queue()
> has finished for all associated SCSI devices. This is why I think that calling
> blk_exit_rl() earlier would be sufficient to avoid that scsi_exit_rq()
> dereferences a SCSI host pointer after it has been freed.

Hmm... I see.  Didn't know request put path involved derefing those
structs.  The blk_exit_rl() call just replaced open coded
mempool_destroy call, so the destruction order was always like this.
We shouldn't have any request in flight by cleanup, so moving it there
should be fine.

Thanks.

-- 
tejun