linux-stable.git/drivers/usb/core, branch v4.4.7

USB: usb_driver_claim_interface: add sanity checking

2016-04-12T16:08:41+00:00

commit 0b818e3956fc1ad976bee791eadcbb3b5fec5bfd upstream.

Attacks that trick drivers into passing a NULL pointer
to usb_driver_claim_interface() using forged descriptors are
known. This thwarts them by sanity checking.

Signed-off-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman

usb: hub: fix a typo in hub_port_init() leading to wrong logic

2016-04-12T16:08:40+00:00

commit 0d5ce778c43bf888328231bcdce05d5c860655aa upstream.

A typo of j for i led to a logic bug. To rule out future
confusion, the variable names are made meaningful.

Signed-off-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman

usb: retry reset if a device times out

2016-04-12T16:08:40+00:00

commit 264904ccc33c604d4b3141bbd33808152dfac45b upstream.

Some devices I got show an inability to operate right after
power on if they are already connected. They are beyond recovery
if the descriptors are requested multiple times. So in case of
a timeout we rather bail early and reset again. But it must be
done only on the first loop lest we get into a reset/time out
spiral that can be overcome with a retry.

This patch is a rework of a patch that fell through the cracks.
http://www.spinics.net/lists/linux-usb/msg103263.html

Signed-off-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman

usb: hub: do not clear BOS field during reset device

2016-02-17T20:31:01+00:00

commit d8f00cd685f5c8e0def8593e520a7fef12c22407 upstream.

In function usb_reset_and_verify_device, the old BOS descriptor may
still be used before allocating a new one. (usb_unlocked_disable_lpm
function uses it under the situation that it fails to disable lpm.)
So we cannot set the udev->bos to NULL before that, just keep what it
was. It will be overwrite when allocating a new one.

Crash log:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000010
IP: [] usb_enable_link_state+0x2d/0x2f0
Call Trace:
[] ? usb_set_lpm_timeout+0x12b/0x140
[] usb_enable_lpm+0x81/0xa0
[] usb_disable_lpm+0xa8/0xc0
[] usb_unlocked_disable_lpm+0x2c/0x50
[] usb_reset_and_verify_device+0xc3/0x710
[] ? usb_sg_wait+0x13d/0x190
[] usb_reset_device+0x133/0x280
[] usb_stor_port_reset+0x61/0x70
[] usb_stor_invoke_transport+0x88/0x520

Signed-off-by: Du, Changbin 
Signed-off-by: Greg Kroah-Hartman

usb: core: lpm: fix usb3_hardware_lpm sysfs node

2016-01-31T19:28:58+00:00

commit bf5ce5bf3cc7136fd7fe5e8999a580bc93a9c8f6 upstream.

Commit 655fe4effe0f ("usbcore: add sysfs support to xHCI usb3
hardware LPM") introduced usb3_hardware_lpm sysfs node. This
doesn't show the correct status of USB3 U1 and U2 LPM status.

This patch fixes this by replacing usb3_hardware_lpm with two
nodes, usb3_hardware_lpm_u1 (for U1) and usb3_hardware_lpm_u2
(for U2), and recording the U1/U2 LPM status in right places.

This patch should be back-ported to kernels as old as 4.3,
that contains Commit 655fe4effe0f ("usbcore: add sysfs support
to xHCI usb3 hardware LPM").

Signed-off-by: Lu Baolu 
Signed-off-by: Greg Kroah-Hartman

USB: fix invalid memory access in hub_activate()

2015-12-18T17:30:34+00:00

Commit 8520f38099cc ("USB: change hub initialization sleeps to
delayed_work") changed the hub_activate() routine to make part of it
run in a workqueue.  However, the commit failed to take a reference to
the usb_hub structure or to lock the hub interface while doing so.  As
a result, if a hub is plugged in and quickly unplugged before the work
routine can run, the routine will try to access memory that has been
deallocated.  Or, if the hub is unplugged while the routine is
running, the memory may be deallocated while it is in active use.

This patch fixes the problem by taking a reference to the usb_hub at
the start of hub_activate() and releasing it at the end (when the work
is finished), and by locking the hub interface while the work routine
is running.  It also adds a check at the start of the routine to see
if the hub has already been disconnected, in which nothing should be
done.

Signed-off-by: Alan Stern 
Reported-by: Alexandru Cornea 
Tested-by: Alexandru Cornea 
Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work")
CC: 
Signed-off-by: Greg Kroah-Hartman

USB: add quirk for devices with broken LPM

2015-12-11T23:40:51+00:00

Some USB device / host controller combinations seem to have problems
with Link Power Management.  For example, Steinar found that his xHCI
controller wouldn't handle bandwidth calculations correctly for two
video cards simultaneously when LPM was enabled, even though the bus
had plenty of bandwidth available.

This patch introduces a new quirk flag for devices that should remain
disabled for LPM, and creates quirk entries for Steinar's devices.

Signed-off-by: Alan Stern 
Reported-by: Steinar H. Gunderson 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usb: Quiet down false peer failure messages

2015-12-04T16:19:55+00:00

My recent Intel box is spewing these messages:

xhci_hcd 0000:00:14.0: xHCI Host Controller
xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: xHCI Host Controller
usb usb2: Manufacturer: Linux 4.3.0+ xhci-hcd
usb usb2: SerialNumber: 0000:00:14.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 6 ports detected
usb: failed to peer usb2-port2 and usb1-port1 by location (usb2-port2:none) (usb1-port1:usb2-port1)
usb usb2-port2: failed to peer to usb1-port1 (-16)
usb: port power management may be unreliable
usb: failed to peer usb2-port3 and usb1-port1 by location (usb2-port3:none) (usb1-port1:usb2-port1)
usb usb2-port3: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port5 and usb1-port1 by location (usb2-port5:none) (usb1-port1:usb2-port1)
usb usb2-port5: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port6 and usb1-port1 by location (usb2-port6:none) (usb1-port1:usb2-port1)
usb usb2-port6: failed to peer to usb1-port1 (-16)

Diving into the acpi tables, I noticed the EHCI hub has 12 ports while the XHCI
hub has 8 ports.  Most of those ports are of connect type USB_PORT_NOT_USED
(including port 1 of the EHCI hub).

Further the unused ports have location data initialized to 0x80000000.

Now each unused port on the xhci hub walks the port list and finds a matching
peer with port1 of the EHCI hub because the zero'd out group id bits falsely match.
After port1 of the XHCI hub, each following matching peer will generate the
above warning.

These warnings seem to be harmless for this scenario as I don't think it
matters that unused ports could not create a peer link.

The attached patch utilizes that assumption and just turns the pr_warn into
pr_debug to quiet things down.

Tested on my Intel box.

Signed-off-by: Don Zickus 
Acked-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message

2015-12-01T22:45:52+00:00

usb_parse_ss_endpoint_companion() now decodes the burst multiplier
correctly in order to check that it's <= 3, but still uses the wrong
expression if warning that it's > 3.

Fixes: ff30cbc8da42 ("usb: Use the USB_SS_MULT() macro to get the ...")
Signed-off-by: Ben Hutchings 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usb: core : hub: Fix BOS 'NULL pointer' kernel panic

2015-12-01T22:45:52+00:00

When a USB 3.0 mass storage device is disconnected in transporting
state, storage device driver may handle it as a transport error and
reset the device by invoking usb_reset_and_verify_device()
and following could happen:

in usb_reset_and_verify_device():
   udev->bos = NULL;

For U1/U2 enabled devices, driver will disable LPM, and in some
conditions:
   from usb_unlocked_disable_lpm()
    --> usb_disable_lpm()
    --> usb_enable_lpm()
        udev->bos->ss_cap->bU1devExitLat;

And it causes 'NULL pointer' and 'kernel panic':

[  157.976257] Unable to handle kernel NULL pointer dereference
at virtual address 00000010
...
[  158.026400] PC is at usb_enable_link_state+0x34/0x2e0
[  158.031442] LR is at usb_enable_lpm+0x98/0xac
...
[  158.137368] [] usb_enable_link_state+0x34/0x2e0
[  158.143451] [] usb_enable_lpm+0x94/0xac
[  158.148840] [] usb_disable_lpm+0xa8/0xb4
...
[  158.214954] Kernel panic - not syncing: Fatal exception

This commit moves 'udev->bos = NULL' behind usb_unlocked_disable_lpm()
to prevent from NULL pointer access.

Issue can be reproduced by following setup:
1) A SS pen drive behind a SS hub connected to the host.
2) Transporting data between the pen drive and the host.
3) Abruptly disconnect hub and pen drive from host.
4) With a chance it crashes.

Signed-off-by: Hans Yang 
Acked-by: Alan Stern 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman