linux-kernel - Re: [PATCH] JMicron JM20337 USB-SATA data corruption bugfix

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]

Message-ID: <Pine.LNX.4.44L0.0809021654330.5583-100000@iolanthe.rowland.org>
Date:	Tue, 2 Sep 2008 17:06:52 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Thiago Galesi <thiagogalesi@...il.com>
cc:	Alex Buell <alex.buell@...ted.org.uk>,
	<linux-kernel@...r.kernel.org>, Robert Hancock <hancockr@...w.ca>,
	Tomas Styblo <tripie@...n.org>, <linux-usb@...r.kernel.org>,
	<usb-storage@...ts.one-eyed-alien.net>
Subject: Re: [PATCH] JMicron JM20337 USB-SATA data corruption bugfix - device
 152d:2338

On Tue, 2 Sep 2008, Thiago Galesi wrote:

> > However what finally caused the failure was a command (0xAC) which I
> > don't recognize and apparently your drive doesn't recognize either.
> 
> Is this it? dfbb5d80 1845367929 C Bi:6:002:1 0 13 = 55534253 acc90100
> 00000000 00

No, it was this:

dfbb5d80 1845397954 S Bo:6:002:2 -115 31 = 55534243 dac90100 08000000 80000cac 00000000 00000000 01030000 000000

The initial sign of a problem is the -104 error code about five lines 
farther down in the log.

The odd thing is that the device did give an 8-byte response to that 
command (as it was supposed to) but then apparently crashed and didn't 
provide any status.  After that everything failed.

I don't know; maybe it was just a coincidence that the failure occurred 
the first time this command was used.

> Any idea who may be sending this? I mean,  can this be send via a
> simple IOCTL to /dev/sr0 or it is something else?
> Maybe stracing the program would be a good idea.

Maybe.  If you were trying to write a DVD during the test then almost 
certainly the command was sent by an IOCTL like you said.  You could 
probably figure out what the command was supposed to do by looking 
through the source code for the program.

> If I were to place a trace inside a driver, were would it be better?
> sr_mod, sd_mod, usb-storage, cdrom? or somewhere else?

It depends on what you want to trace.  Although in this case it's safe 
to ignore sd_mod since your device uses sr_mod.

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/