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

USB: change bInterval default to 10 ms

2016-11-20T01:01:41+00:00

commit 08c5cd37480f59ea39682f4585d92269be6b1424 upstream.

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

USB: avoid left shift by -1

2016-11-20T01:01:34+00:00

commit 53e5f36fbd2453ad69a3369a1db62dc06c30a4aa upstream.

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 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

USB: fix typo in wMaxPacketSize validation

2016-11-20T01:01:34+00:00

commit 6c73358c83ce870c0cf32413e5cadb3b9a39c606 upstream.

The maximum value allowed for wMaxPacketSize of a high-speed interrupt
endpoint is 1024 bytes, not 1023.

Signed-off-by: Alan Stern 
Fixes: aed9d65ac327 ("USB: validate wMaxPacketValue entries in endpoint descriptors")
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

USB: validate wMaxPacketValue entries in endpoint descriptors

2016-11-20T01:01:32+00:00

commit aed9d65ac3278d4febd8665bd7db59ef53e825fe upstream.

Erroneous or malicious endpoint descriptors may have non-zero bits in
reserved positions, or out-of-bounds values.  This patch helps prevent
these from causing problems by bounds-checking the wMaxPacketValue
entries in endpoint descriptors and capping the values at the maximum
allowed.

This issue was first discovered and tests were conducted by Jake Lamberson
, an intern working for Rosie Hall.

Signed-off-by: Alan Stern 
Reported-by: roswest 
Tested-by: roswest 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: drop the USB_SPEED_SUPER_PLUS case]
Signed-off-by: Ben Hutchings

USB: usbfs: fix potential infoleak in devio

2016-08-22T21:37:18+00:00

commit 681fef8380eb818c0b845fca5d2ab1dcbab114ee upstream.

The stack object “ci” has a total size of 8 bytes. Its last 3 bytes
are padding bytes which are not initialized and leaked to userland
via “copy_to_user”.

Signed-off-by: Kangjie Lu 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

usb: hcd: out of bounds access in for_each_companion

2016-06-15T20:28:11+00:00

commit e86103a75705c7c530768f4ffaba74cf382910f2 upstream.

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.

Signed-off-by: Robert Dobrowolski 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

USB: usb_driver_claim_interface: add sanity checking

2016-04-30T22:05:19+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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

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

2016-04-30T22:05:16+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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

usb: retry reset if a device times out

2016-04-30T22:05:14+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 
Signed-off-by: Ben Hutchings

USB: fix invalid memory access in hub_activate()

2016-01-22T21:40:07+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")
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: add prototype for hub_release() before first use]
Signed-off-by: Ben Hutchings