linux-stable.git/drivers/usb/storage, branch v3.16.52

usb-storage: unusual_devs entry to fix write-access regression for Seagate external drives

2018-01-01T20:51:36+00:00

commit 113f6eb6d50cfa5e2a1cdcf1678b12661fa272ab upstream.

Kris Lindgren reports that without the NO_WP_DETECT flag, his Seagate
external disk drive fails all write accesses.  This regresssion dates
back approximately to the start of the 4.x kernel releases.

Signed-off-by: Alan Stern 
Reported-by: Kris Lindgren 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

usb-storage: fix bogus hardware error messages for ATA pass-thru devices

2018-01-01T20:51:36+00:00

commit a4fd4a724d6c30ad671046d83be2e9be2f11d275 upstream.

Ever since commit a621bac3044e ("scsi_lib: correctly retry failed zero
length REQ_TYPE_FS commands"), people have been getting bogus error
messages for USB disk drives using ATA pass-thru.  For example:

[ 1344.880193] sd 6:0:0:0: [sdb] Attached SCSI disk
[ 1345.069152] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[ 1345.069159] sd 6:0:0:0: [sdb] tag#0 Sense Key : Hardware Error [current] [descriptor]
[ 1345.069162] sd 6:0:0:0: [sdb] tag#0 Add. Sense: No additional sense information
[ 1345.069168] sd 6:0:0:0: [sdb] tag#0 CDB: ATA command pass through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00
[ 1345.172252] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[ 1345.172258] sd 6:0:0:0: [sdb] tag#0 Sense Key : Hardware Error [current] [descriptor]
[ 1345.172261] sd 6:0:0:0: [sdb] tag#0 Add. Sense: No additional sense information
[ 1345.172266] sd 6:0:0:0: [sdb] tag#0 CDB: ATA command pass through(12)/Blank a1 06 20 da 00 00 4f c2 00 b0 00 00

These messages can be quite annoying, because programs like udisks2
provoke them every 10 minutes or so.  Other programs can also have
this effect, such as those in smartmontools.

I don't fully understand how that commit induced the SCSI core to log
these error messages, but the underlying cause for them is code added
to usb-storage by commit f1a0743bc0e7 ("USB: storage: When a device
returns no sense data, call it a Hardware Error").  At the time it was
necessary to do this, in order to prevent an infinite retry loop with
some not-so-great mass storage devices.

However, the ATA pass-thru protocol uses SCSI sense data to return
command status values, and some devices always report Check Condition
status for ATA pass-thru commands to ensure that the host retrieves
the sense data, even if the command succeeded.  This violates the USB
mass-storage protocol (Check Condition status is supposed to mean the
command failed), but we can't help that.

This patch attempts to mitigate the problem of these bogus error
reports by changing usb-storage.  The HARDWARE ERROR sense key will be
inserted only for commands that aren't ATA pass-thru.

Thanks to Ewan Milne for pointing out that this mechanism was present
in usb-storage.  8 years after writing it, I had completely forgotten
its existence.

Signed-off-by: Alan Stern 
Tested-by: Kris Lindgren 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1351305
CC: Ewan D. Milne 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

USB: uas: fix bug in handling of alternate settings

2017-11-11T13:33:39+00:00

commit 786de92b3cb26012d3d0f00ee37adf14527f35c4 upstream.

The uas driver has a subtle bug in the way it handles alternate
settings.  The uas_find_uas_alt_setting() routine returns an
altsetting value (the bAlternateSetting number in the descriptor), but
uas_use_uas_driver() then treats that value as an index to the
intf->altsetting array, which it isn't.

Normally this doesn't cause any problems because the various
alternate settings have bAlternateSetting values 0, 1, 2, ..., so the
value is equal to the index in the array.  But this is not guaranteed,
and Andrey Konovalov used the syzkaller fuzzer with KASAN to get a
slab-out-of-bounds error by violating this assumption.

This patch fixes the bug by making uas_find_uas_alt_setting() return a
pointer to the altsetting entry rather than either the value or the
index.  Pointers are less subject to misinterpretation.

Signed-off-by: Alan Stern 
Reported-by: Andrey Konovalov 
Tested-by: Andrey Konovalov 
CC: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

uas: Add US_FL_IGNORE_RESIDUE for Initio Corporation INIC-3069

2017-11-11T13:33:11+00:00

commit 89f23d51defcb94a5026d4b5da13faf4e1150a6f upstream.

Similar to commit d595259fbb7a ("usb-storage: Add ignore-residue quirk for
Initio INIC-3619") for INIC-3169 in unusual_devs.h but INIC-3069 already
present in unusual_uas.h. Both in same controller IC family.

Issue is that MakeMKV fails during key exchange with installed bluray drive
with following error:

002004:0000 Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED'
occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:0'

Signed-off-by: Alan Swanson 
Acked-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

usb: storage: return on error to avoid a null pointer dereference

2017-11-11T13:32:57+00:00

commit 446230f52a5bef593554510302465eabab45a372 upstream.

When us->extra is null the driver is not initialized, however, a
later call to osd200_scsi_to_ata is made that dereferences
us->extra, causing a null pointer dereference.  The code
currently detects and reports that the driver is not initialized;
add a return to avoid the subsequent dereference issue in this
check.

Thanks to Alan Stern for pointing out that srb->result needs setting
to DID_ERROR << 16

Detected by CoverityScan, CID#100308 ("Dereference after null check")

Signed-off-by: Colin Ian King 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

USB: ene_usb6250: fix DMA to the stack

2017-09-15T17:29:40+00:00

commit 628c2893d44876ddd11602400c70606ade62e129 upstream.

The ene_usb6250 sub-driver in usb-storage does USB I/O to buffers on
the stack, which doesn't work with vmapped stacks.  This patch fixes
the problem by allocating a separate 512-byte buffer at probe time and
using it for all of the offending I/O operations.

Signed-off-by: Alan Stern 
Reported-and-tested-by: Andreas Hartmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

usb: storage: unusual_uas: Add JMicron JMS56x to unusual device

2017-03-16T02:26:51+00:00

commit 674aea07e38200ea6f31ff6d5f200f0cf6cdb325 upstream.

This device gives the following error on detection.
xhci_hcd 0000:00:11.0: ERROR Transfer event for disabled endpoint or
incorrect stream ring

The same error is not seen when it is added to unusual_device
list with US_FL_NO_REPORT_OPCODES passed.

Signed-off-by: George Cherian 
Signed-off-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

Fix USB CB/CBI storage devices with CONFIG_VMAP_STACK=y

2017-02-23T03:54:33+00:00

commit 2ce9d2272b98743b911196c49e7af5841381c206 upstream.

Some code (all error handling) submits CDBs that are allocated
on the stack.  This breaks with CB/CBI code that tries to create
URB directly from SCSI command buffer - which happens to be in
vmalloced memory with vmalloced kernel stacks.

Let's make copy of the command in usb_stor_CB_transport.

Signed-off-by: Petr Vandrovec 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

USB: uas: Add a new NO_REPORT_LUNS quirk

2016-06-15T20:29:23+00:00

commit 1363074667a6b7d0507527742ccd7bbed5e3ceaa upstream.

Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with
an usb-id of: 0bc2:331a, as these will fail to respond to a
REPORT_LUNS command.

Reported-and-tested-by: David Webb 
Signed-off-by: Hans de Goede 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

USB: uas: Reduce can_queue to MAX_CMNDS

2016-04-30T22:06:02+00:00

commit 55ff8cfbc4e12a7d2187df523938cc671fbebdd1 upstream.

The uas driver can never queue more then MAX_CMNDS (- 1) tags and tags
are shared between luns, so there is no need to claim that we can_queue
some random large number.

Not claiming that we can_queue 65536 commands, fixes the uas driver
failing to initialize while allocating the tag map with a "Page allocation
failure (order 7)" error on systems which have been running for a while
and thus have fragmented memory.

Reported-and-tested-by: Yves-Alexis Perez 
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: add definition of MAX_CMNDS from upstream commit
 5e61aede477e ("uas: Do not use scsi_host_find_tag")]
Signed-off-by: Ben Hutchings