linux-kernel - Re: Linux 3.0 oopses when pulling a USB CDROM

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 1 Jul 2011 17:04:34 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	Dave Jones <davej@...hat.com>, Andi Kleen <andi@...stfloor.org>,
	<linux-scsi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<axboe@...nel.dk>, <rjw@...k.pl>, <linux-usb@...r.kernel.org>
Subject: Re: Linux 3.0 oopses when pulling a USB CDROM

On Fri, 1 Jul 2011, James Bottomley wrote:

> On Fri, 2011-07-01 at 14:14 -0400, Dave Jones wrote:
> > On Fri, Jul 01, 2011 at 10:05:31AM -0700, Andi Kleen wrote:
> > 
> >  > I found I can reliably crash a 3.0 system by pulling the
> >  > USB cable of a mounted USB cdrom (or rather a USB device which
> >  > has a builtin fake CD-ROM) 
> >  > 
> >  > I suspect it's a regression too.
> > 
> > We've been seeing a lot of similar bugs in Fedora since we pushed
> > a 2.6.38.8 update.  Some of the traces are different, but some
> > look to be the same as yours. (here's one for eg: https://bugzilla.redhat.com/show_bug.cgi?id=712830)
> > 
> > The common cause seems to be 'device went away'. So USB CD drives,
> > USB memory sticks, and for some reason virtualbox shutdown.
> 
> I think it's something specific in the USB path.  I can't reproduce on
> 3.0-rc5 with a SATA DVD hot unplug.  USB cc's added.

I just took a look at the Red Hat bugzilla entry mentioned above.  It 
seems to be quite different from the issue addressed by the patch I 
just posted -- a crash with invalid memory access rather than a lockdep 
violation and hang of the khubd thread.

It's also notable that the stack dump in the bugzilla report doesn't 
contain any functions in the USB subsystem.  Of course this doesn't 
prove anything, but it is suggestive.

Evidently the sdev argument to scsi_prep_state_check() was NULL.  This
looks like the problem that cropped up before, where q->queuedata was
getting set to NULL while the queue was still in use.  I can't imagine
how anything in usb-storage could have caused that.

Alan Stern

--
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/