linux-stable.git/drivers/usb, branch v3.18.37

USB: usbip: fix potential out-of-bounds write

2016-07-12T12:47:50+00:00

[ Upstream commit b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb ]

Fix potential out-of-bounds write to urb->transfer_buffer
usbip handles network communication directly in the kernel. When receiving a
packet from its peer, usbip code parses headers according to protocol. As
part of this parsing urb->actual_length is filled. Since the input for
urb->actual_length comes from the network, it should be treated as untrusted.
Any entity controlling the network may put any value in the input and the
preallocated urb->transfer_buffer may not be large enough to hold the data.
Thus, the malicious entity is able to write arbitrary data to kernel memory.

Signed-off-by: Ignat Korchagin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: don't free bandwidth_mutex too early

2016-07-12T12:47:15+00:00

[ Upstream commit ab2a4bf83902c170d29ba130a8abb5f9d90559e1 ]

The USB core contains a bug that can show up when a USB-3 host
controller is removed.  If the primary (USB-2) hcd structure is
released before the shared (USB-3) hcd, the core will try to do a
double-free of the common bandwidth_mutex.

The problem was described in graphical form by Chung-Geol Kim, who
first reported it:

=================================================
     At *remove USB(3.0) Storage
     sequence <1> --> <5> ((Problem Case))
=================================================
                                  VOLD
------------------------------------|------------
                                 (uevent)
                            ________|_________
                           |<1>               |
                           |dwc3_otg_sm_work  |
                           |usb_put_hcd       |
                           |peer_hcd(kref=2)|
                           |__________________|
                            ________|_________
                           |<2>               |
                           |New USB BUS #2    |
                           |                  |
                           |peer_hcd(kref=1)  |
                           |                  |
                         --(Link)-bandXX_mutex|
                         | |__________________|
                         |
    ___________________  |
   |<3>                | |
   |dwc3_otg_sm_work   | |
   |usb_put_hcd        | |
   |primary_hcd(kref=1)| |
   |___________________| |
    _________|_________  |
   |<4>                | |
   |New USB BUS #1     | |
   |hcd_release        | |
   |primary_hcd(kref=0)| |
   |                   | |
   |bandXX_mutex(free) |<-
   |___________________|
                               (( VOLD ))
                            ______|___________
                           |<5>               |
                           |      SCSI        |
                           |usb_put_hcd       |
                           |peer_hcd(kref=0)  |
                           |*hcd_release      |
                           |bandXX_mutex(free*)|<- double free
                           |__________________|

=================================================

This happens because hcd_release() frees the bandwidth_mutex whenever
it sees a primary hcd being released (which is not a very good idea
in any case), but in the course of releasing the primary hcd, it
changes the pointers in the shared hcd in such a way that the shared
hcd will appear to be primary when it gets released.

This patch fixes the problem by changing hcd_release() so that it
deallocates the bandwidth_mutex only when the _last_ hcd structure
referencing it is released.  The patch also removes an unnecessary
test, so that when an hcd is released, both the shared_hcd and
primary_hcd pointers in the hcd's peer will be cleared.

Signed-off-by: Alan Stern 
Reported-by: Chung-Geol Kim 
Tested-by: Chung-Geol Kim 
CC: 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: common: otg-fsm: add license to usb-otg-fsm

2016-07-11T15:16:23+00:00

[ Upstream commit ea1d39a31d3b1b6060b6e83e5a29c069a124c68a ]

Fix warning about tainted kernel because usb-otg-fsm has no license.
WARNING: with this patch usb-otg-fsm module can be loaded
but then the kernel will hang. Tested with a udoo quad board.

Cc:  #v4.1+
Signed-off-by: Oscar 
Signed-off-by: Peter Chen 
Signed-off-by: Sasha Levin

usb: host: ehci-tegra: Grab the correct UTMI pads reset

2016-07-11T15:10:44+00:00

[ Upstream commit f8a15a9650694feaa0dabf197b0c94d37cd3fb42 ]

There are three EHCI controllers on Tegra SoCs, each with its own reset
line. However, the first controller contains a set of UTMI configuration
registers that are shared with its siblings. These registers will only
be reset as part of the first controller's reset. For proper operation
it must be ensured that the UTMI configuration registers are reset
before any of the EHCI controllers are enabled, irrespective of the
probe order.

Commit a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to
broken USB") introduced code that ensures the first controller is always
reset before setting up any of the controllers, and is never again reset
afterwards.

This code, however, grabs the wrong reset. Each EHCI controller has two
reset controls attached: 1) the USB controller reset and 2) the UTMI
pads reset (really the first controller's reset). In order to reset the
UTMI pads registers the code must grab the second reset, but instead it
grabbing the first.

Fixes: a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to broken USB")
Acked-by: Jon Hunter 
Cc: stable@vger.kernel.org
Signed-off-by: Thierry Reding 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: musb: Stop bulk endpoint while queue is rotated

2016-07-11T15:10:34+00:00

[ Upstream commit 7b2c17f829545df27a910e8d82e133c21c9a8c9c ]

Ensure that the endpoint is stopped by clearing REQPKT before
clearing DATAERR_NAKTIMEOUT before rotating the queue on the
dedicated bulk endpoint.
This addresses an issue where a race could result in the endpoint
receiving data before it was reprogrammed resulting in a warning
about such data from musb_rx_reinit before it was thrown away.
The data thrown away was a valid packet that had been correctly
ACKed which meant the host and device got out of sync.

Signed-off-by: Andrew Goodbody 
Cc: stable@vger.kernel.org
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: musb: Ensure rx reinit occurs for shared_fifo endpoints

2016-07-11T15:10:27+00:00

[ Upstream commit f3eec0cf784e0d6c47822ca6b66df3d5812af7e6 ]

shared_fifo endpoints would only get a previous tx state cleared
out, the rx state was only cleared for non shared_fifo endpoints
Change this so that the rx state is cleared for all endpoints.
This addresses an issue that resulted in rx packets being dropped
silently.

Signed-off-by: Andrew Goodbody 
Cc: stable@vger.kernel.org
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: xhci: Add broken streams quirk for Frescologic device id 1009

2016-07-11T15:10:21+00:00

[ Upstream commit d95815ba6a0f287213118c136e64d8c56daeaeab ]

I got one of these cards for testing uas with, it seems that with streams
it dma-s all over the place, corrupting memory. On my first tests it
managed to dma over the BIOS of the motherboard somehow and completely
bricked it.

Tests on another motherboard show that it does work with streams disabled.

Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: quirks: Add no-lpm quirk for Acer C120 LED Projector

2016-07-11T15:10:15+00:00

[ Upstream commit 32cb0b37098f4beeff5ad9e325f11b42a6ede56c ]

The Acer C120 LED Projector is a USB-3 connected pico projector which
takes both its power and video data from USB-3.

In combination with some hubs this device does not play well with
lpm, so disable lpm for it.

Signed-off-by: Hans de Goede 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: quirks: Fix sorting

2016-07-11T15:10:09+00:00

[ Upstream commit 81099f97bd31e25ff2719a435b1860fc3876122f ]

Properly sort all the entries by vendor id.

Signed-off-by: Hans de Goede 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: xhci-plat: properly handle probe deferral for devm_clk_get()

2016-07-11T15:10:02+00:00

[ Upstream commit de95c40d5beaa47f6dc8fe9ac4159b4672b51523 ]

On some platforms, the clocks might be registered by a platform
driver. When this is the case, the clock platform driver may very well
be probed after xhci-plat, in which case the first probe() invocation
of xhci-plat will receive -EPROBE_DEFER as the return value of
devm_clk_get().

The current code handles that as a normal error, and simply assumes
that this means that the system doesn't have a clock for the XHCI
controller, and continues probing without calling
clk_prepare_enable(). Unfortunately, this doesn't work on systems
where the XHCI controller does have a clock, but that clock is
provided by another platform driver. In order to fix this situation,
we handle the -EPROBE_DEFER error condition specially, and abort the
XHCI controller probe(). It will be retried later automatically, the
clock will be available, devm_clk_get() will succeed, and the probe()
will continue with the clock prepared and enabled as expected.

In practice, such issue is seen on the ARM64 Marvell 7K/8K platform,
where the clocks are registered by a platform driver.

Cc: 
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin