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

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

2016-06-01T19:18:02+00:00

commit feb26ac31a2a5cb88d86680d9a94916a6343e9e6 upstream.

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

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

2016-06-01T19:18:02+00:00

commit 6fb650d43da3e7054984dc548eaa88765a94d49f upstream.

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

Revert "USB / PM: Allow USB devices to remain runtime-suspended when sleeping"

2016-05-02T15:44:31+00:00

This reverts commit e3345db85068ddb937fc0ba40dfc39c293dad977, which
broke system resume for a large class of devices.

Devices that after having been reset during resume need to be rebound
due to a missing reset_resume callback, are now left in a suspended
state. This specifically broke resume of common USB-serial devices,
which are now unusable after system suspend (until disconnected and
reconnected) when USB persist is enabled.

During resume, usb_resume_interface will set the needs_binding flag for
such interfaces, but unlike system resume, run-time resume does not
honour it.

Cc: stable 	# 4.5
Signed-off-by: Johan Hovold 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: hcd: out of bounds access in for_each_companion

2016-04-13T19:06:18+00:00

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

usb: fix regression in SuperSpeed endpoint descriptor parsing

2016-03-31T04:57:58+00:00

commit b37d83a6a414 ("usb: Parse the new USB 3.1 SuperSpeedPlus Isoc
endpoint companion descriptor") caused a regression in 4.6-rc1 and fails
to parse SuperSpeed endpoint companion descriptors.

The new SuperSpeedPlus Isoc endpoint companion parsing code incorrectly
decreased the the remaining buffer size before comparing the size with the
expected length of the descriptor.

This lead to possible failure in reading the SuperSpeed endpoint companion
descriptor of the last endpoint, displaying a message like:

"No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0
 ep 129: using minimum values"

Fix it by decreasing the size after comparing it.
Also finish all the SS endpoint companion parsing before calling SSP isoc
endpoint parsing function.

Fixes: b37d83a6a414
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

USB: usb_driver_claim_interface: add sanity checking

2016-03-18T16:19:02+00:00

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

usb/core: usb_alloc_dev(): fix setting of ->portnum

2016-03-18T16:19:02+00:00

With commit 69bec7259853 ("USB: core: let USB device know device node"),
the port1 argument of usb_alloc_dev() gets overwritten as follows:

  ... usb_alloc_dev(..., unsigned port1)
  {
    ...
    if (!parent->parent) {
      port1 = usb_hcd_find_raw_port_number(..., port1);
    }
    ...
  }

Later on, this now overwritten port1 gets assigned to ->portnum:

  dev->portnum = port1;

However, since xhci_find_raw_port_number() isn't idempotent, the
aforementioned commit causes a number of KASAN splats like the following:

  BUG: KASAN: slab-out-of-bounds in xhci_find_raw_port_number+0x98/0x170
                                       at addr ffff8801d9311670
  Read of size 8 by task kworker/2:1/87
  [...]
  Workqueue: usb_hub_wq hub_event
   0000000000000188 000000005814b877 ffff8800cba17588 ffffffff8191447e
   0000000041b58ab3 ffffffff82a03209 ffffffff819143a2 ffffffff82a252f4
   ffff8801d93115e0 0000000000000188 ffff8801d9311628 ffff8800cba17588
  Call Trace:
   [] dump_stack+0xdc/0x15e
   [] ? _atomic_dec_and_lock+0xa2/0xa2
   [] ? print_section+0x61/0xb0
   [] print_trailer+0x179/0x2c0
   [] object_err+0x34/0x40
   [] kasan_report_error+0x2f8/0x8b0
   [] ? __slab_alloc+0x5e/0x90
   [] ? __lock_is_held+0x90/0x130
   [] kasan_report+0x71/0xa0
   [] ? kmem_cache_alloc_trace+0x212/0x560
   [] ? xhci_find_raw_port_number+0x98/0x170
   [] __asan_load8+0x64/0x70
   [] xhci_find_raw_port_number+0x98/0x170
   [] xhci_setup_addressable_virt_dev+0x235/0xa10
   [] xhci_setup_device+0x3c1/0x1430
   [] ? trace_hardirqs_on+0xd/0x10
   [] ? xhci_setup_device+0x1430/0x1430
   [] xhci_address_device+0x13/0x20
   [] hub_port_init+0x55a/0x1550
   [] hub_event+0xef5/0x24d0
   [] ? hub_port_debounce+0x2f0/0x2f0
   [] ? debug_object_deactivate+0x1be/0x270
   [] ? print_rt_rq+0x53/0x2d0
   [] ? trace_hardirqs_off+0xd/0x10
   [] ? _raw_spin_unlock_irqrestore+0x5b/0x60
   [] ? irq_domain_set_hwirq_and_chip+0x30/0xb0
   [] ? debug_lockdep_rcu_enabled+0x39/0x40
   [] ? __lock_is_held+0x90/0x130
   [] process_one_work+0x567/0xec0
  [...]

Afterwards, xhci reports some functional errors:

  xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion
                                code 0x11.
  xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion
                                code 0x11.
  usb 4-3: device not accepting address 2, error -22

Fix this by not overwriting the port1 argument in usb_alloc_dev(), but
storing the raw port number as required by OF in an additional variable,
raw_port.

Fixes: 69bec7259853 ("USB: core: let USB device know device node")
Signed-off-by: Nicolai Stange 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'usb-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

2016-03-17T21:24:26+00:00

Pull USB updates from Greg KH:
 "Here is the big USB patchset for 4.6-rc1.

  The normal mess is here, gadget and xhci fixes and updates, and lots
  of other driver updates and cleanups as well.  Full details are in the
  shortlog.

  All have been in linux-next for a while with no reported issues"

* tag 'usb-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (266 commits)
  USB: core: let USB device know device node
  usb: devio: Add ioctl to disallow detaching kernel USB drivers.
  usb: gadget: f_acm: Fix configfs attr name
  usb: udc: lpc32xx: remove USB PLL and USB OTG clock management
  usb: udc: lpc32xx: remove direct access to clock controller registers
  usb: udc: lpc32xx: switch to clock prepare/unprepare model
  usb: renesas_usbhs: gadget: fix giveback status code in usbhsg_pipe_disable()
  usb: gadget: renesas_usb3: Use ARCH_RENESAS
  usb: dwc2: Fix issues in dwc2_complete_non_isoc_xfer_ddma()
  usb: dwc2: Add support for Lantiq ARX and XRX SoCs
  usb: phy: generic: Handle late registration of gadget
  usb: gadget: bdc_udc: fix race condition in bdc_udc_exit()
  usb: musb: core: added missing const qualifier to musb_hdrc_platform_data::config
  usb: dwc2: Move host-specific core functions into hcd.c
  usb: dwc2: Move register save and restore functions
  usb: dwc2: Use kmem_cache_free()
  usb: dwc2: host: If using uframe scheduler, end splits better
  usb: dwc2: host: Totally redo the microframe scheduler
  usb: dwc2: host: Properly set even/odd frame
  usb: dwc2: host: Add dwc2_hcd_get_future_frame_number() call
  ...

USB: core: let USB device know device node

2016-03-05T20:05:01+00:00

Although most of USB devices are hot-plug's, there are still some devices
are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
If these kinds of USB devices are multiple functions, and they can supply
other interfaces like i2c, gpios for other devices, we may need to
describe these at device tree.

In this commit, it uses "reg" in dts as physical port number to match
the phyiscal port number decided by USB core, if they are the same,
then the device node is for the device we are creating for USB core.

Signed-off-by: Peter Chen 
Acked-by: Philipp Zabel 
Acked-by: Alan Stern 
Acked-by: Rob Herring 
Acked-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

usb: devio: Add ioctl to disallow detaching kernel USB drivers.

2016-03-05T20:05:01+00:00

The new USBDEVFS_DROP_PRIVILEGES ioctl allows a process to voluntarily
relinquish the ability to issue other ioctls that may interfere with
other processes and drivers that have claimed an interface on the
device.

This commit also includes a simple utility to be able to test the
ioctl, located at Documentation/usb/usbdevfs-drop-permissions.c

Example (with qemu-kvm's input device):

    $ lsusb
    ...
    Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd

    $ usb-devices
    ...
    C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=02 Driver=usbhid

    $ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
    OK: privileges dropped!
    Available options:
    [0] Exit now
    [1] Reset device. Should fail if device is in use
    [2] Claim 4 interfaces. Should succeed where not in use
    [3] Narrow interface permission mask
    Which option shall I run?: 1
    ERROR: USBDEVFS_RESET failed! (1 - Operation not permitted)
    Which test shall I run next?: 2
    ERROR claiming if 0 (1 - Operation not permitted)
    ERROR claiming if 1 (1 - Operation not permitted)
    ERROR claiming if 2 (1 - Operation not permitted)
    ERROR claiming if 3 (1 - Operation not permitted)
    Which test shall I run next?: 0

After unbinding usbhid:

    $ usb-devices
    ...
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=02 Driver=(none)

    $ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
    ...
    Which option shall I run?: 2
    OK: claimed if 0
    ERROR claiming if 1 (1 - Operation not permitted)
    ERROR claiming if 2 (1 - Operation not permitted)
    ERROR claiming if 3 (1 - Operation not permitted)
    Which test shall I run next?: 1
    OK: USBDEVFS_RESET succeeded
    Which test shall I run next?: 0

After unbinding usbhid and restricting the mask:

    $ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
    ...
    Which option shall I run?: 3
    Insert new mask: 0
    OK: privileges dropped!
    Which test shall I run next?: 2
    ERROR claiming if 0 (1 - Operation not permitted)
    ERROR claiming if 1 (1 - Operation not permitted)
    ERROR claiming if 2 (1 - Operation not permitted)
    ERROR claiming if 3 (1 - Operation not permitted)

Signed-off-by: Reilly Grant 
Acked-by: Alan Stern 
Signed-off-by: Emilio López 
Signed-off-by: Greg Kroah-Hartman