linux-toradex.git/drivers/usb, branch v4.9.64

USB: serial: garmin_gps: fix memory leak on probe errors

2017-11-21T08:23:30+00:00

commit 74d471b598444b7f2d964930f7234779c80960a0 upstream.

Make sure to free the port private data before returning after a failed
probe attempt.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: serial: garmin_gps: fix I/O after failed probe and remove

2017-11-21T08:23:29+00:00

commit 19a565d9af6e0d828bd0d521d3bafd5017f4ce52 upstream.

Make sure to stop any submitted interrupt and bulk-out URBs before
returning after failed probe and when the port is being unbound to avoid
later NULL-pointer dereferences in the completion callbacks.

Also fix up the related and broken I/O cancellation on failed open and
on close. (Note that port->write_urb was never submitted.)

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update

2017-11-21T08:23:29+00:00

commit 771394a54148f18926ca86414e51c69eda27d0cd upstream.

Add USB PID/VID for Sierra Wireless EM7355 LTE modem QDL firmware update
mode.

Signed-off-by: Douglas Fischer 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_fs: Fix use-after-free in ffs_free_inst

2017-11-21T08:23:29+00:00

commit cdafb6d8b8da7fde266f79b3287ac221aa841879 upstream.

KASAN enabled configuration reports an error

BUG: KASAN: use-after-free in ffs_free_inst+... [usb_f_fs] at addr ...
Write of size 8 by task ...

This is observed after "ffs-test" is run and interrupted. If after that
functionfs is unmounted and g_ffs module is unloaded, that use-after-free
occurs during g_ffs module removal.

Although the report indicates ffs_free_inst() function, the actual
use-after-free condition occurs in _ffs_free_dev() function, which
is probably inlined into ffs_free_inst().

This happens due to keeping the ffs_data reference in device structure
during functionfs unmounting, while ffs_data itself is freed as no longer
needed. The fix is to clear that reference in ffs_closed() function,
which is a counterpart of ffs_ready(), where the reference is stored.

Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference")
Signed-off-by: Andrew Gabbasov 
Acked-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

USB: Add delay-init quirk for Corsair K70 LUX keyboards

2017-11-21T08:23:29+00:00

commit a0fea6027f19c62727315aba1a7fae75a9caa842 upstream.

Without this patch, K70 LUX keyboards don't work, saying
usb 3-3: unable to read config index 0 descriptor/all
usb 3-3: can't read configurations, error -110
usb usb3-port3: unable to enumerate USB device

Signed-off-by: Bernhard Rosenkraenzer 
Signed-off-by: Greg Kroah-Hartman

USB: usbfs: compute urb->actual_length for isochronous

2017-11-21T08:23:29+00:00

commit 2ef47001b3ee3ded579b7532ebdcf8680e4d8c54 upstream.

The USB kerneldoc says that the actual_length field "is read in
non-iso completion functions", but the usbfs driver uses it for all
URB types in processcompl().  Since not all of the host controller
drivers set actual_length for isochronous URBs, programs using usbfs
with some host controllers don't work properly.  For example, Minas
reports that a USB camera controlled by libusb doesn't work properly
with a dwc2 controller.

It doesn't seem worthwhile to change the HCDs and the documentation,
since the in-kernel USB class drivers evidently don't rely on
actual_length for isochronous transfers.  The easiest solution is for
usbfs to calculate the actual_length value for itself, by adding up
the lengths of the individual packets in an isochronous transfer.

Signed-off-by: Alan Stern 
CC: Minas Harutyunyan 
Reported-and-tested-by: wlf 
Signed-off-by: Greg Kroah-Hartman

usb: usbtest: fix NULL pointer dereference

2017-11-18T10:22:24+00:00

commit 7c80f9e4a588f1925b07134bb2e3689335f6c6d8 upstream.

If the usbtest driver encounters a device with an IN bulk endpoint but
no OUT bulk endpoint, it will try to dereference a NULL pointer
(out->desc.bEndpointAddress).  The problem can be solved by adding a
missing test.

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

usb: hcd: initialize hcd->flags to 0 when rm hcd

2017-11-15T14:53:15+00:00

[ Upstream commit 76b8db0d480e8045e1a1902fc9ab143b3b9ef115 ]

On some platforms(e.g. rk3399 board), we can call hcd_add/remove
consecutively without calling usb_put_hcd/usb_create_hcd in between,
so hcd->flags can be stale.

If the HC dies due to whatever reason then without this patch we get
the below error on next hcd_add.

[173.296154] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
[173.296209] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[173.296762] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 6
[173.296931] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.
[173.297179] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003
[173.297203] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[173.297222] usb usb6: Product: xHCI Host Controller
[173.297240] usb usb6: Manufacturer: Linux 4.4.21 xhci-hcd
[173.297257] usb usb6: SerialNumber: xhci-hcd.2.auto
[173.298680] hub 6-0:1.0: USB hub found
[173.298749] hub 6-0:1.0: 1 port detected
[173.299382] rockchip-dwc3 usb@fe800000: USB HOST connected
[173.395418] hub 5-0:1.0: activate --> -19
[173.603447] irq 228: nobody cared (try booting with the "irqpoll" option)
[173.603493] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.21 #9
[173.603513] Hardware name: Google Kevin (DT)
[173.603531] Call trace:
[173.603568] [] dump_backtrace+0x0/0x160
[173.603596] [] show_stack+0x20/0x28
[173.603623] [] dump_stack+0x90/0xb0
[173.603650] [] __report_bad_irq+0x48/0xe8
[173.603674] [] note_interrupt+0x1e8/0x28c
[173.603698] [] handle_irq_event_percpu+0x1d4/0x25c
[173.603722] [] handle_irq_event+0x4c/0x7c
[173.603748] [] handle_fasteoi_irq+0xb4/0x124
[173.603777] [] generic_handle_irq+0x30/0x44
[173.603804] [] __handle_domain_irq+0x90/0xbc
[173.603827] [] gic_handle_irq+0xcc/0x188
...
[173.604500] [] el1_irq+0x80/0xf8
[173.604530] [] cpu_startup_entry+0x38/0x3cc
[173.604558] [] rest_init+0x8c/0x94
[173.604585] [] start_kernel+0x3d0/0x3fc
[173.604607] [<0000000000b16000>] 0xb16000
[173.604622] handlers:
[173.604648] [] usb_hcd_irq
[173.604673] Disabling IRQ #228

Signed-off-by: William wu 
Acked-by: Roger Quadros 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: Handle error condition in xhci_stop_device()

2017-11-02T08:49:13+00:00

commit b3207c65dfafae27e7c492cb9188c0dc0eeaf3fd upstream.

xhci_stop_device() calls xhci_queue_stop_endpoint() multiple times
without checking the return value. xhci_queue_stop_endpoint() can
return error if the HC is already halted or unable to queue commands.
This can cause a deadlock condition as xhci_stop_device() would
end up waiting indefinitely for a completion for the command that
didn't get queued. Fix this by checking the return value and bailing
out of xhci_stop_device() in case of error. This patch happens to fix
potential memory leaks of the allocated command structures as well.

Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,")
Signed-off-by: Mayank Rana 
Signed-off-by: Jack Pham 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: Identify USB 3.1 capable hosts by their port protocol capability

2017-10-27T08:38:06+00:00

commit ea7d0d69426cab6747ed311c53f4142eb48b9454 upstream.

Many USB 3.1 capable hosts never updated the Serial Bus Release Number
(SBRN) register to USB 3.1 from USB 3.0

xhci driver identified USB 3.1 capable hosts based on this SBRN register,
which according to specs "contains the release of the Universal Serial
Bus Specification with which this Universal Serial Bus Host Controller
module is compliant." but still in october 2017 gives USB 3.0 as
the only possible option.

Make an additional check for USB 3.1 support and enable it if the xHCI
supported protocol capablity lists USB 3.1 capable ports.

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