On Tue, 2011-10-18 at 17:45 +0200, Heiko Carstens wrote: > On Tue, Oct 18, 2011 at 10:31:20PM +0900, Jun'ichi Nomura wrote: > > On 10/17/11 23:06, James Bottomley wrote: > > > On Mon, 2011-10-17 at 17:46 +0900, Jun'ichi Nomura wrote: > > >> On 10/15/11 01:03, James Bottomley wrote: > > >>> On Thu, 2011-10-13 at 15:09 +0200, Steffen Maier wrote: > > >>>> Initially, we encountered use-after-free bugs in > > >>>> scsi_print_command / scsi_dispatch_cmd > > >>>> http://marc.info/?l=linux-scsi&m=130824013229933&w=2 > > >> > > >> It is interesting that both this and the older report > > >> got oopsed in scsi_log_send(), while there are other > > >> dereferences of 'cmd' around scsi_dispatch_cmd(). > > >> Are there any reason they are special? Just by accident? > > > > > > Right, that's why it looks like the command area got freed rather than > > > the command pointer was bogus (6b is a poison free pattern). Perhaps if > > > the reporter could pin down the failing source line, we'd know better > > > what was going on? > > > > Yeah, that might be useful. > > The struct scsi_cmnd that was passed to scsi_log_send() was already freed > (contents completely 6b6b6b...). > Since SLUB debugging was turned on we can see that it was freed from > __scsi_put_command(). Not too much of a surprise. But it does tell us the put must be racing with dispatch, since dereferencing the command to find the device worked higher up in scsi_dispatch_cmd(). There is one way to invalidate the theory that we cloned something with an attached command, and that's to put BUG_ON(rq->special) in blk_insert_cloned_request(). I think we're careful about clearing it, so it should work (perhaps a warn on just in case). James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
