linux-kernel - Re: [usb-storage] [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.0807301707350.2322-100000@iolanthe.rowland.org>
Date:	Wed, 30 Jul 2008 17:18:10 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Matthew Dharm <mdharm-kernel@...-eyed-alien.net>
cc:	Robert Hancock <hancockr@...w.ca>,
	<usb-storage@...ts.one-eyed-alien.net>,
	Tomas Styblo <tripie@...n.org>, <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [usb-storage] [PATCH] JMicron JM20337 USB-SATA data corruption
 bugfix - device 152d:2338

On Wed, 30 Jul 2008, Matthew Dharm wrote:

> The code path to supress the reporting of an error when auto-sense shows no
> ASC/ASCQ was added for a reason.  That reason has likely been lost to time,
> but I worry about devices that are out there that rely on the current
> behavior to function properly....

In this case we shouldn't have to worry about that code path.  It 
applies to situations where there actually is no error.  In fact, if 
you follow the logic flow you'll see that the supression code gets 
invoked only for CB-like transports, i.e., unsolicited auto-sense.

But in this situation there really _is_ an error: We get an underflow.  
The existing logic checks for underflow only when the device reports 
Okay status; my patch changes the logic so that it also checks for 
underflow when the device reports Check Condition status with no sense 
data.

The idea is that the higher SCSI layers don't know what to do with
Check Condition plus no-sense -- so they treat the transfer as a
success.  But that's definitely the wrong thing to do when there was an
underflow; in that situation we want to report the underflow so that
the midlayer will retry the command.

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/