linux-kernel - Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 18 Oct 2011 11:29:40 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Heiko Carstens <heiko.carstens@...ibm.com>
Cc:	Jun'ichi Nomura <j-nomura@...jp.nec.com>,
	Steffen Maier <maier@...ux.vnet.ibm.com>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	Jens Axboe <axboe@...nel.dk>, Hannes Reinecke <hare@...e.de>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Thadeu Lima de Souza Cascardo <cascardo@...ux.vnet.ibm.com>,
	"Taraka R. Bodireddy" <tarak.reddy@...ibm.com>,
	"Seshagiri N. Ippili" <seshagiri.ippili@...ibm.com>,
	"Manvanthara B. Puttashankar" <mputtash@...ibm.com>
Subject: Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue
 resources at blk_release_queue())

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/