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

xhci: fix finding correct bus_state structure for USB 3.1 hosts

2017-10-12T07:18:02+00:00

commit 5a838a13c9b4e5dd188b7a6eaeb894e9358ead0c upstream.

xhci driver keeps a bus_state structure for each hcd (usb2 and usb3)

The structure is picked based on hcd speed, but driver only compared
for HCD_USB3 speed, returning the wrong bus_state for HCD_USB31 hosts.

This caused null pointer dereference errors in bus_resume function.

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

USB: fix out-of-bounds in usb_set_configuration

2017-10-12T07:18:02+00:00

commit bd7a3fe770ebd8391d1c7d072ff88e9e76d063eb upstream.

Andrey Konovalov reported a possible out-of-bounds problem for a USB interface
association descriptor.  He writes:
	It seems there's no proper size check of a USB_DT_INTERFACE_ASSOCIATION
	descriptor. It's only checked that the size is >= 2 in
	usb_parse_configuration(), so find_iad() might do out-of-bounds access
	to intf_assoc->bInterfaceCount.

And he's right, we don't check for crazy descriptors of this type very well, so
resolve this problem.  Yet another issue found by syzkaller...

Reported-by: Andrey Konovalov 
Tested-by: Andrey Konovalov 
Signed-off-by: Greg Kroah-Hartman

usb: Increase quirk delay for USB devices

2017-10-12T07:18:01+00:00

commit b2a542bbb3081dbd64acc8929c140d196664c406 upstream.

Commit e0429362ab15
("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
introduced quirk to workaround an issue with some Logitech webcams.

The workaround is introducing delay for some USB operations.

According to our testing, delay introduced by original commit
is not long enough and in rare cases we still see issues described
by the aforementioned commit.

This patch increases delays introduced by original commit.
Having this patch applied we do not see those problems anymore.

Signed-off-by: Dmitry Fleytman 
Signed-off-by: Greg Kroah-Hartman

USB: uas: fix bug in handling of alternate settings

2017-10-12T07:18:01+00:00

commit 786de92b3cb26012d3d0f00ee37adf14527f35c4 upstream.

The uas driver has a subtle bug in the way it handles alternate
settings.  The uas_find_uas_alt_setting() routine returns an
altsetting value (the bAlternateSetting number in the descriptor), but
uas_use_uas_driver() then treats that value as an index to the
intf->altsetting array, which it isn't.

Normally this doesn't cause any problems because the various
alternate settings have bAlternateSetting values 0, 1, 2, ..., so the
value is equal to the index in the array.  But this is not guaranteed,
and Andrey Konovalov used the syzkaller fuzzer with KASAN to get a
slab-out-of-bounds error by violating this assumption.

This patch fixes the bug by making uas_find_uas_alt_setting() return a
pointer to the altsetting entry rather than either the value or the
index.  Pointers are less subject to misinterpretation.

Signed-off-by: Alan Stern 
Reported-by: Andrey Konovalov 
Tested-by: Andrey Konovalov 
CC: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

USB: devio: Don't corrupt user memory

2017-10-12T07:18:01+00:00

commit fa1ed74eb1c233be6131ec92df21ab46499a15b6 upstream.

The user buffer has "uurb->buffer_length" bytes.  If the kernel has more
information than that, we should truncate it instead of writing past
the end of the user's buffer.  I added a WARN_ONCE() to help the user
debug the issue.

Reported-by: Alan Stern 
Signed-off-by: Dan Carpenter 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

USB: dummy-hcd: fix infinite-loop resubmission bug

2017-10-12T07:18:01+00:00

commit 0173a68bfb0ad1c72a6ee39cc485aa2c97540b98 upstream.

The dummy-hcd HCD/UDC emulator tries not to do too much work during
each timer interrupt.  But it doesn't try very hard; currently all
it does is limit the total amount of bulk data transferred.  Other
transfer types aren't limited, and URBs that transfer no data (because
of an error, perhaps) don't count toward the limit, even though on a
real USB bus they would consume at least a minimum overhead.

This means it's possible to get the driver stuck in an infinite loop,
for example, if the host class driver resubmits an URB every time it
completes (which is common for interrupt URBs).  Each time the URB is
resubmitted it gets added to the end of the pending-URBs list, and
dummy-hcd doesn't stop until that list is empty.  Andrey Konovalov was
able to trigger this failure mode using the syzkaller fuzzer.

This patch fixes the infinite-loop problem by restricting the URBs
handled during each timer interrupt to those that were already on the
pending list when the interrupt routine started.  Newly added URBs
won't be processed until the next timer interrupt.  The problem of
properly accounting for non-bulk bandwidth (as well as packet and
transaction overhead) is not addressed here.

Signed-off-by: Alan Stern 
Reported-by: Andrey Konovalov 
Tested-by: Andrey Konovalov 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

USB: dummy-hcd: fix connection failures (wrong speed)

2017-10-12T07:18:01+00:00

commit fe659bcc9b173bcfdd958ce2aec75e47651e74e1 upstream.

The dummy-hcd UDC driver is not careful about the way it handles
connection speeds.  It ignores the module parameter that is supposed
to govern the maximum connection speed and it doesn't set the HCD
flags properly for the case where it ends up running at full speed.

The result is that in many cases, gadget enumeration over dummy-hcd
fails because the bMaxPacketSize byte in the device descriptor is set
incorrectly.  For example, the default settings call for a high-speed
connection, but the maxpacket value for ep0 ends up being set for a
Super-Speed connection.

This patch fixes the problem by initializing the gadget's max_speed
and the HCD flags correctly.

Signed-off-by: Alan Stern 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: pci-quirks.c: Corrected timeout values used in handshake

2017-10-12T07:18:01+00:00

commit 114ec3a6f9096d211a4aff4277793ba969a62c73 upstream.

Servers were emitting failed handoff messages but were not
waiting the full 1 second as designated in section 4.22.1 of
the eXtensible Host Controller Interface specifications. The
handshake was using wrong units so calls were made with milliseconds
not microseconds. Comments referenced 5 seconds not 1 second as
in specs.

The wrong units were also corrected in a second handshake call.

Signed-off-by: Jim Dickerson 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: renesas_usbhs: fix usbhsf_fifo_clear() for RX direction

2017-10-12T07:18:01+00:00

commit 0a2ce62b61f2c76d0213edf4e37aaf54a8ddf295 upstream.

This patch fixes an issue that the usbhsf_fifo_clear() is possible
to cause 10 msec delay if the pipe is RX direction and empty because
the FRDY bit will never be set to 1 in such case.

Fixes: e8d548d54968 ("usb: renesas_usbhs: fifo became independent from pipe.")
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: renesas_usbhs: fix the BCLR setting condition for non-DCP pipe

2017-10-12T07:18:01+00:00

commit 6124607acc88fffeaadf3aacfeb3cc1304c87387 upstream.

This patch fixes an issue that the driver sets the BCLR bit of
{C,Dn}FIFOCTR register to 1 even when it's non-DCP pipe and
the FRDY bit of {C,Dn}FIFOCTR register is set to 1.

Fixes: e8d548d54968 ("usb: renesas_usbhs: fifo became independent from pipe.")
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman