linux-stable.git/drivers/usb/core, branch v3.18.52

USB: fix linked-list corruption in rh_call_control()

2017-04-18T05:55:54+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: Greg Kroah-Hartman

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

2017-04-18T05:55:54+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: Greg Kroah-Hartman

usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk

2017-04-18T05:55:53+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: Greg Kroah-Hartman

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

2017-04-18T05:55:52+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: Greg Kroah-Hartman

usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices

2017-01-15T14:49:49+00:00

[ Upstream commit 37be66767e3cae4fd16e064d8bb7f9f72bf5c045 ]

USB-3 does not have any link state that will avoid negotiating a connection
with a plugged-in cable but will signal the host when the cable is
unplugged.

For USB-3 we used to first set the link to Disabled, then to RxDdetect to
be able to detect cable connects or disconnects. But in RxDetect the
connected device is detected again and eventually enabled.

Instead set the link into U3 and disable remote wakeups for the device.
This is what Windows does, and what Alan Stern suggested.

Cc: stable@vger.kernel.org
Cc: Alan Stern 
Acked-by: Alan Stern 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: change bInterval default to 10 ms

2016-10-06T02:40:20+00:00

[ Upstream commit 08c5cd37480f59ea39682f4585d92269be6b1424 ]

Some full-speed mceusb infrared transceivers contain invalid endpoint
descriptors for their interrupt endpoints, with bInterval set to 0.
In the past they have worked out okay with the mceusb driver, because
the driver sets the bInterval field in the descriptor to 1,
overwriting whatever value may have been there before.  However, this
approach was never sanctioned by the USB core, and in fact it does not
work with xHCI controllers, because they use the bInterval value that
was present when the configuration was installed.

Currently usbcore uses 32 ms as the default interval if the value in
the endpoint descriptor is invalid.  It turns out that these IR
transceivers don't work properly unless the interval is set to 10 ms
or below.  To work around this mceusb problem, this patch changes the
endpoint-descriptor parsing routine, making the default interval value
be 10 ms rather than 32 ms.

Signed-off-by: Alan Stern 
Tested-by: Wade Berrier 
CC: 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: avoid left shift by -1

2016-09-12T22:59:55+00:00

[ Upstream commit 53e5f36fbd2453ad69a3369a1db62dc06c30a4aa ]

UBSAN complains about a left shift by -1 in proc_do_submiturb().  This
can occur when an URB is submitted for a bulk or control endpoint on
a high-speed device, since the code doesn't bother to check the
endpoint type; normally only interrupt or isochronous endpoints have
a nonzero bInterval value.

Aside from the fact that the operation is illegal, it shouldn't matter
because the result isn't used.  Still, in theory it could cause a
hardware exception or other problem, so we should work around it.
This patch avoids doing the left shift unless the shift amount is >= 0.

The same piece of code has another problem.  When checking the device
speed (the exponential encoding for interrupt endpoints is used only
by high-speed or faster devices), we need to look for speed >=
USB_SPEED_SUPER as well as speed == USB_SPEED HIGH.  The patch adds
this check.

Signed-off-by: Alan Stern 
Reported-by: Vittorio Zecca 
Tested-by: Vittorio Zecca 
Suggested-by: Bjørn Mork 
CC: 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: hub: Fix unbalanced reference count/memory leak/deadlocks

2016-08-31T23:26:30+00:00

[ Upstream commit 6bb47e8ab98accb1319bd43c64966340ba3bba9a ]

Memory leak and unbalanced reference count:

If the hub gets disconnected while the core is still activating it, this
can result in leaking memory of few USB structures.

This will happen if we have done a kref_get() from hub_activate() and
scheduled a delayed work item for HUB_INIT2/3. Now if hub_disconnect()
gets called before the delayed work expires, then we will cancel the
work from hub_quiesce(), but wouldn't do a kref_put(). And so the
unbalance.

kmemleak reports this as (with the commit e50293ef9775 backported to
3.10 kernel with other changes, though the same is true for mainline as
well):

unreferenced object 0xffffffc08af5b800 (size 1024):
  comm "khubd", pid 73, jiffies 4295051211 (age 6482.350s)
  hex dump (first 32 bytes):
    30 68 f3 8c c0 ff ff ff 00 a0 b2 2e c0 ff ff ff  0h..............
    01 00 00 00 00 00 00 00 00 94 7d 40 c0 ff ff ff  ..........}@....
  backtrace:
    [] create_object+0x148/0x2a0
    [] kmemleak_alloc+0x80/0xbc
    [] kmem_cache_alloc_trace+0x120/0x1ac
    [] hub_probe+0x120/0xb84
    [] usb_probe_interface+0x1ec/0x298
    [] driver_probe_device+0x160/0x374
    [] __device_attach+0x28/0x4c
    [] bus_for_each_drv+0x78/0xac
    [] device_attach+0x6c/0x9c
    [] bus_probe_device+0x28/0xa0
    [] device_add+0x324/0x604
    [] usb_set_configuration+0x660/0x6cc
    [] generic_probe+0x44/0x84
    [] usb_probe_device+0x54/0x74
    [] driver_probe_device+0x160/0x374
    [] __device_attach+0x28/0x4c

Deadlocks:

If the hub gets disconnected early enough (i.e. before INIT2/INIT3 are
finished and the init_work is still queued), the core may call
hub_quiesce() after acquiring interface device locks and it will wait
for the work to be cancelled synchronously. But if the work handler is
already running in parallel, it may try to acquire the same interface
device lock and this may result in deadlock.

Fix both the issues by removing the call to cancel_delayed_work_sync().

CC:  #4.4+
Fixes: e50293ef9775 ("USB: fix invalid memory access in hub_activate()")
Reported-by: Manu Gautam 
Signed-off-by: Viresh Kumar 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: quirks: Add no-lpm quirk for Elan

2016-08-22T16:23:09+00:00

[ Upstream commit 25b1f9acc452209ae0fcc8c1332be852b5c52f53 ]

BugLink: http://bugs.launchpad.net/bugs/1498667

As reported in BugLink, this device has an issue with Linux Power
Management so adding a quirk.  This quirk was reccomended by Alan Stern:

http://lkml.iu.edu/hypermail/linux/kernel/1606.2/05590.html

Signed-off-by: Joseph Salisbury 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: quirks: Fix another ELAN touchscreen

2016-08-22T16:23:08+00:00

[ Upstream commit df36c5bede207f734e4750beb2b14fb892050280 ]

Like other buggy models that had their fixes [1], the touchscreen with
id 04f3:21b8 from ELAN Microelectronics needs the device-qualifier
quirk. Otherwise, it fails to respond, blocks the boot for a random
amount of time and pollutes dmesg with:

[ 2887.373196] usb 1-5: new full-speed USB device number 41 using xhci_hcd
[ 2889.502000] usb 1-5: unable to read config index 0 descriptor/start: -71
[ 2889.502005] usb 1-5: can't read configurations, error -71
[ 2889.654571] usb 1-5: new full-speed USB device number 42 using xhci_hcd
[ 2891.783438] usb 1-5: unable to read config index 0 descriptor/start: -71
[ 2891.783443] usb 1-5: can't read configurations, error -71

[1]: See commits c68929f, 876af5d, d749947, a32c99e and dc703ec.

Tested-by: Adrien Vergé 
Signed-off-by: Adrien Vergé 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin