Re: [BUG] 2.6.39.1 crash in scsi_dispatch_cmd()

Heiko Carstens
2011-06-16T18:40:32Z

On Thu, Jun 16, 2011 at 12:37:55PM -0400, James Bottomley wrote:
> On Thu, 2011-06-16 at 18:01 +0200, Heiko Carstens wrote:
> > cc'ing Jens (full quote of the original bug report at the end).
> >
> > I patched the SLUB debugging code so that it includes full call traces
> > instead of just the address of the caller of kfree/kmalloc. So here is
> > yet another incarnation of what I think is the same use-after-free bug:
> >
> > What we can see here: while scsi_dispatch_cmd() operates on a scsi_cmnd
> > it gets freed via blk_done_softirq().
> > In this specific case scsi_send_log() crashes while trying to dereference
> > the SLAB/SLUB poison value.
>
> But you're crashing in the submit path, not the completion path.
> scsi_send_log() is called *before* we dispatch the command, so how on
> earth did the command get freed in the completion (softirq) path?

Well, I was hoping you would point to something obviously wrong ;)
So the only way I can think this could have happened then seems to
be something like this sequence:

User A -- allocs command
User A -- somehow frees command (but still has a reference)
User B -- submit path allocs command (gets freed slab again)
User A -- frees it again
User B -- submit path crashes

So looks like I need to add more trace and/or debug code. Sigh.
Dunno.. maybe zfcp returns the command twice or something like that; even
though there is code in place which should prevent exactly this scenario.