linux-kernel - Re: [linux-usb-devel] 2.6.19-rc1-mm1 - locks when using "dd bs=1M" from card reader

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:	Thu, 19 Oct 2006 14:40:17 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Helge Hafting <helge.hafting@...el.hist.no>
cc:	Christopher Monty Montgomery <xiphmont@...il.com>,
	Paolo Ornati <ornati@...twebnet.it>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>
Subject: Re: [linux-usb-devel] 2.6.19-rc1-mm1 - locks when using "dd bs=1M"
 from card reader

On Thu, 19 Oct 2006, Helge Hafting wrote:

> Alan Stern wrote:
> > On Wed, 18 Oct 2006, Helge Hafting wrote:
> >   
> [...]
> > That's why I asked for the USB debugging logs (which you forgot to include
> > here).
> >   
> Attached dmesg.gz with lots of usb messages.

But no messages from the time just before the BUG occurred.  :-(

> >> To bring it down:
> >>
> >> dd if=/dev/sdc of=sdc.dump bs=1M
> >>     
> This time, it seems to have crashed on the first megabyte.
> I mounted the filesystem synchronously, and still I had 0 bytes
> in the dumpfile.  The crash also came with no delay after
> pressing enter.
> 
> > It's possible that both of these are caused by something unrelated 
> > overwriting kernel memory.
> >   
> something like a function pointer mistaken for a data pointer?

After looking at the debugging output, no.  That "invalid opcode" is a red 
herring.  What you encountered this time was a BUG() in the source code of 
start_unlink_async() in drivers/usb/host/ehci-q.c:

#ifdef DEBUG
	assert_spin_locked(&ehci->lock);
	if (ehci->reclaim
			|| (qh->qh_state != QH_STATE_LINKED
				&& qh->qh_state != QH_STATE_UNLINK_WAIT)
			)
		BUG ();
#endif

You could try putting a printk() just before the BUG() to display the 
values of ehci->reclaim and qh->qh_state.  Maybe also change the BUG() to 
WARN(), which might help prevent your system from crashing so badly.

Monty has been making changes to this driver recently; maybe he has some 
ideas about the problem.

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/