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

USB: leave LPM alone if possible when binding/unbinding interface drivers

2016-06-03T23:15:42+00:00

[ Upstream commit 6fb650d43da3e7054984dc548eaa88765a94d49f ]

When a USB driver is bound to an interface (either through probing or
by claiming it) or is unbound from an interface, the USB core always
disables Link Power Management during the transition and then
re-enables it afterward.  The reason is because the driver might want
to prevent hub-initiated link power transitions, in which case the HCD
would have to recalculate the various LPM parameters.  This
recalculation takes place when LPM is re-enabled and the new
parameters are sent to the device and its parent hub.

However, if the driver does not want to prevent hub-initiated link
power transitions then none of this work is necessary.  The parameters
don't need to be recalculated, and LPM doesn't need to be disabled and
re-enabled.

It turns out that disabling and enabling LPM can be time-consuming,
enough so that it interferes with user programs that want to claim and
release interfaces rapidly via usbfs.  Since the usbfs kernel driver
doesn't set the disable_hub_initiated_lpm flag, we can speed things up
and get the user programs to work by leaving LPM alone whenever the
flag isn't set.

And while we're improving the way disable_hub_initiated_lpm gets used,
let's also fix its kerneldoc.

Signed-off-by: Alan Stern 
Tested-by: Matthew Giassa 
CC: Mathias Nyman 
CC: 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: core: hub: hub_port_init lock controller instead of bus

2016-06-03T23:15:35+00:00

[ Upstream commit feb26ac31a2a5cb88d86680d9a94916a6343e9e6 ]

The XHCI controller presents two USB buses to the system - one for USB2
and one for USB3. The hub init code (hub_port_init) is reentrant but
only locks one bus per thread, leading to a race condition failure when
two threads attempt to simultaneously initialise a USB2 and USB3 device:

[    8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[   13.183701] usb 3-3: device descriptor read/all, error -110

On a test system this failure occurred on 6% of all boots.

The call traces at the point of failure are:

Call Trace:
 [] schedule+0x37/0x90
 [] usb_kill_urb+0x8d/0xd0
 [] ? wake_up_atomic_t+0x30/0x30
 [] usb_start_wait_urb+0xbe/0x150
 [] usb_control_msg+0xbc/0xf0
 [] hub_port_init+0x51e/0xb70
 [] hub_event+0x817/0x1570
 [] process_one_work+0x1ff/0x620
 [] ? process_one_work+0x15f/0x620
 [] worker_thread+0x64/0x4b0
 [] ? rescuer_thread+0x390/0x390
 [] kthread+0x105/0x120
 [] ? kthread_create_on_node+0x200/0x200
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x200/0x200

Call Trace:
 [] xhci_setup_device+0x53d/0xa40
 [] xhci_address_device+0xe/0x10
 [] hub_port_init+0x1bf/0xb70
 [] ? trace_hardirqs_on+0xd/0x10
 [] hub_event+0x817/0x1570
 [] process_one_work+0x1ff/0x620
 [] ? process_one_work+0x15f/0x620
 [] worker_thread+0x64/0x4b0
 [] ? rescuer_thread+0x390/0x390
 [] kthread+0x105/0x120
 [] ? kthread_create_on_node+0x200/0x200
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x200/0x200

Which results from the two call chains:

hub_port_init
 usb_get_device_descriptor
  usb_get_descriptor
   usb_control_msg
    usb_internal_control_msg
     usb_start_wait_urb
      usb_submit_urb / wait_for_completion_timeout / usb_kill_urb

hub_port_init
 hub_set_address
  xhci_address_device
   xhci_setup_device

Mathias Nyman explains the current behaviour violates the XHCI spec:

 hub_port_reset() will end up moving the corresponding xhci device slot
 to default state.

 As hub_port_reset() is called several times in hub_port_init() it
 sounds reasonable that we could end up with two threads having their
 xhci device slots in default state at the same time, which according to
 xhci 4.5.3 specs still is a big no no:

 "Note: Software shall not transition more than one Device Slot to the
  Default State at a time"

 So both threads fail at their next task after this.
 One fails to read the descriptor, and the other fails addressing the
 device.

Fix this in hub_port_init by locking the USB controller (instead of an
individual bus) to prevent simultaneous initialisation of both buses.

Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel")
Link: https://lkml.org/lkml/2016/2/8/312
Link: https://lkml.org/lkml/2016/2/4/748
Signed-off-by: Chris Bainbridge 
Cc: stable 
Acked-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

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

2016-05-13T02:00:58+00:00

This reverts commit 522dc09ca0451d118795e8a05c7b3717f3d1ad8b..

Tony writes:

This upstream commit is causing an oops:
d8f00cd685f5 ("usb: hub: do not clear BOS field during reset device")

This patch has already been included in several -stable kernels.  Here
are the affected kernels:
4.5.0-rc4 (current git)
4.4.2
4.3.6 (currently in review)
4.1.18
3.18.27
3.14.61

How to reproduce the problem:
Boot kernel with slub debugging enabled (otherwise memory corruption
will cause random oopses later instead of immediately)
Plug in USB 3.0 disk to xhci USB 3.0 port
dd if=/dev/sdc of=/dev/null bs=65536
(where /dev/sdc is the USB 3.0 disk)
Unplug USB cable while dd is still going
Oops is immediate:

Reported-by: Tony Battersby 
Signed-off-by: Sasha Levin

usb: hcd: out of bounds access in for_each_companion

2016-04-20T05:13:12+00:00

[ Upstream commit e86103a75705c7c530768f4ffaba74cf382910f2 ]

On BXT platform Host Controller and Device Controller figure as
same PCI device but with different device function. HCD should
not pass data to Device Controller but only to Host Controllers.
Checking if companion device is Host Controller, otherwise skip.

Cc: 
Signed-off-by: Robert Dobrowolski 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: usb_driver_claim_interface: add sanity checking

2016-04-18T12:51:03+00:00

[ Upstream commit 0b818e3956fc1ad976bee791eadcbb3b5fec5bfd ]

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 
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

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

2016-04-18T12:50:47+00:00

[ Upstream commit 0d5ce778c43bf888328231bcdce05d5c860655aa ]

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 
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: retry reset if a device times out

2016-04-18T12:50:36+00:00

[ Upstream commit 264904ccc33c604d4b3141bbd33808152dfac45b ]

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 
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

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

2016-02-15T20:45:20+00:00

[ Upstream commit d8f00cd685f5c8e0def8593e520a7fef12c22407 ]

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 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: fix invalid memory access in hub_activate()

2016-01-31T19:23:35+00:00

commit e50293ef9775c5f1cf3fcc093037dd6a8c5684ea upstream.

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: Use the USB_SS_MULT() macro to decode burst multiplier for log message

2016-01-23T04:54:11+00:00

commit 5377adb092664d336ac212499961cac5e8728794 upstream.

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 
Signed-off-by: Greg Kroah-Hartman