linux-stable.git/drivers/usb, branch linux-3.12.y

usb: hub: Wait for connection to be reestablished after port reset

2017-04-28T17:30:39+00:00

commit 22547c4cc4fe20698a6a85a55b8788859134b8e4 upstream.

On a system with a defective USB device connected to an USB hub,
an endless sequence of port connect events was observed. The sequence
of events as observed is as follows:

- Port reports connected event (port status=USB_PORT_STAT_CONNECTION).
- Event handler debounces port and resets it by calling hub_port_reset().
- hub_port_reset() calls hub_port_wait_reset() to wait for the reset
  to complete.
- The reset completes, but USB_PORT_STAT_CONNECTION is not immediately
  set in the port status register.
- hub_port_wait_reset() returns -ENOTCONN.
- Port initialization sequence is aborted.
- A few milliseconds later, the port again reports a connected event,
  and the sequence repeats.

This continues either forever or, randomly, stops if the connection
is already re-established when the port status is read. It results in
a high rate of udev events. This in turn destabilizes userspace since
the above sequence holds the device mutex pretty much continuously
and prevents userspace from actually reading the device status.

To prevent the problem from happening, let's wait for the connection
to be re-established after a port reset. If the device was actually
disconnected, the code will still return an error, but it will do so
only after the long reset timeout.

Cc: Douglas Anderson 
Signed-off-by: Guenter Roeck 
Acked-by: Alan Stern 
Signed-off-by: Sumit Semwal 
Signed-off-by: Jiri Slaby

usb: dwc3: gadget: delay unmap of bounced requests

2017-04-28T17:30:37+00:00

commit de288e36fe33f7e06fa272bc8e2f85aa386d99aa upstream.

In the case of bounced ep0 requests, we must delay DMA operation until
after ->complete() otherwise we might overwrite contents of req->buf.

This caused problems with RNDIS gadget.

Signed-off-by: Janusz Dziedzic 
Signed-off-by: Felipe Balbi 
Signed-off-by: Jiri Slaby

USB: OHCI: Fix race between ED unlink and URB submission

2017-04-11T06:04:34+00:00

commit 7d8021c967648accd1b78e5e1ddaad655cd2c61f upstream.

This patch fixes a bug introduced by commit 977dcfdc6031 ("USB: OHCI:
don't lose track of EDs when a controller dies").  The commit changed
ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had
been called.  The user-visible consequence is that the driver
occasionally crashes or locks up when an URB is submitted while
another URB for the same endpoint is being unlinked.

This patch moves the ED state change later, to the right place.  The
drawback is that now we may unnecessarily execute some instructions
multiple times when a controller dies.  Since controllers dying is an
exceptional occurrence, a little wasted time won't matter.

Signed-off-by: Alan Stern 
Reported-by: Heiko Przybyl 
Tested-by: Heiko Przybyl 
Fixes: 977dcfdc60311e7aa571cabf6f39c36dde13339e
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby

USB: fix linked-list corruption in rh_call_control()

2017-04-10T12:21:31+00:00

commit 1633682053a7ee8058e10c76722b9b28e97fb73f upstream.

Using KASAN, Dmitry found a bug in the rh_call_control() routine: If
buffer allocation fails, the routine returns immediately without
unlinking its URB from the control endpoint, eventually leading to
linked-list corruption.

This patch fixes the problem by jumping to the end of the routine
(where the URB is unlinked) when an allocation failure occurs.

Signed-off-by: Alan Stern 
Reported-and-tested-by: Dmitry Vyukov 
Signed-off-by: Jiri Slaby

USB: usbtmc: add missing endpoint sanity check

2017-04-07T08:38:27+00:00

commit 687e0687f71ec00e0132a21fef802dee88c2f1ad upstream.

USBTMC devices are required to have a bulk-in and a bulk-out endpoint,
but the driver failed to verify this, something which could lead to the
endpoint addresses being taken from uninitialised memory.

Make sure to zero all private data as part of allocation, and add the
missing endpoint sanity check.

Note that this also addresses a more recently introduced issue, where
the interrupt-in-presence flag would also be uninitialised whenever the
optional interrupt-in endpoint is not present. This in turn could lead
to an interrupt urb being allocated, initialised and submitted based on
uninitialised values.

Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.")
Fixes: 5b775f672cc9 ("USB: add USB test and measurement class driver")
Signed-off-by: Johan Hovold 
[ johan: backport to v4.4 ]
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby

usb: hub: Fix crash after failure to read BOS descriptor

2017-04-07T08:38:26+00:00

commit 7b2db29fbb4e766fcd02207eb2e2087170bd6ebc upstream.

If usb_get_bos_descriptor() returns an error, usb->bos will be NULL.
Nevertheless, it is dereferenced unconditionally in
hub_set_initial_usb2_lpm_policy() if usb2_hw_lpm_capable is set.
This results in a crash.

usb 5-1: unable to get BOS descriptor
...
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = ffffffc00165f000
[00000008] *pgd=000000000174f003, *pud=000000000174f003,
		*pmd=0000000001750003, *pte=00e8000001751713
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac [ ... ]
CPU: 5 PID: 3353 Comm: kworker/5:3 Tainted: G    B 4.4.52 #480
Hardware name: Google Kevin (DT)
Workqueue: events driver_set_config_work
task: ffffffc0c3690000 ti: ffffffc0ae9a8000 task.ti: ffffffc0ae9a8000
PC is at hub_port_init+0xc3c/0xd10
LR is at hub_port_init+0xc3c/0xd10
...
Call trace:
[] hub_port_init+0xc3c/0xd10
[] usb_reset_and_verify_device+0x15c/0x82c
[] usb_reset_device+0xe4/0x298
[] rtl8152_probe+0x84/0x9b0 [r8152]
[] usb_probe_interface+0x244/0x2f8
[] driver_probe_device+0x180/0x3b4
[] __device_attach_driver+0xb4/0xe0
[] bus_for_each_drv+0xb4/0xe4
[] __device_attach+0xd0/0x158
[] device_initial_probe+0x24/0x30
[] bus_probe_device+0x50/0xe4
[] device_add+0x414/0x738
[] usb_set_configuration+0x89c/0x914
[] driver_set_config_work+0xc0/0xf0
[] process_one_work+0x390/0x6b8
[] worker_thread+0x480/0x610
[] kthread+0x164/0x178
[] ret_from_fork+0x10/0x40

Since we don't know anything about LPM capabilities without BOS descriptor,
don't attempt to enable LPM if it is not available.

Fixes: 890dae886721 ("xhci: Enable LPM support only for hardwired ...")
Cc: Mathias Nyman 
Signed-off-by: Guenter Roeck 
Acked-by: Mathias Nyman 
Signed-off-by: Jiri Slaby

USB: wusbcore: fix NULL-deref at probe

2017-04-07T08:38:26+00:00

commit 03ace948a4eb89d1cf51c06afdfc41ebca5fdb27 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

This specifically fixes the NULL-pointer dereference when probing HWA HC
devices.

Fixes: df3654236e31 ("wusb: add the Wire Adapter (WA) core")
Cc: Inaky Perez-Gonzalez 
Cc: David Vrabel 
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby

USB: idmouse: fix NULL-deref at probe

2017-04-07T08:38:26+00:00

commit b0addd3fa6bcd119be9428996d5d4522479ab240 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby

USB: uss720: fix NULL-deref at probe

2017-04-07T08:38:25+00:00

commit f259ca3eed6e4b79ac3d5c5c9fb259fb46e86217 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

Note that the endpoint access that causes the NULL-deref is currently
only used for debugging purposes during probe so the oops only happens
when dynamic debugging is enabled. This means the driver could be
rewritten to continue to accept device with only two endpoints, should
such devices exist.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby

usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk

2017-04-07T08:38:25+00:00

commit 3243367b209faed5c320a4e5f9a565ee2a2ba958 upstream.

Some USB 2.0 devices erroneously report millisecond values in
bInterval. The generic config code manages to catch most of them,
but in some cases it's not completely enough.

The case at stake here is a USB 2.0 braille device, which wants to
announce 10ms and thus sets bInterval to 10, but with the USB 2.0
computation that yields to 64ms.  It happens that one can type fast
enough to reach this interval and get the device buffers overflown,
leading to problematic latencies.  The generic config code does not
catch this case because the 64ms is considered a sane enough value.

This change thus adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk
to mark devices which actually report milliseconds in bInterval,
and marks Vario Ultra devices as needing it.

Signed-off-by: Samuel Thibault 
Acked-by: Alan Stern 
Signed-off-by: Jiri Slaby