linux-stable.git/drivers/usb, branch v4.14.80

USB: fix the usbfs flag sanitization for control transfers

2018-11-10T15:48:36+00:00

commit 665c365a77fbfeabe52694aedf3446d5f2f1ce42 upstream.

Commit 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more") checks the
transfer flags for URBs submitted from userspace via usbfs.  However,
the check for whether the USBDEVFS_URB_SHORT_NOT_OK flag should be
allowed for a control transfer was added in the wrong place, before
the code has properly determined the direction of the control
transfer.  (Control transfers are special because for them, the
direction is set by the bRequestType byte of the Setup packet rather
than direction bit of the endpoint address.)

This patch moves code which sets up the allow_short flag for control
transfers down after is_in has been set to the correct value.

Signed-off-by: Alan Stern 
Reported-and-tested-by: syzbot+24a30223a4b609bb802e@syzkaller.appspotmail.com
Fixes: 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more")
CC: Oliver Neukum 
CC: 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: storage: Fix Spectre v1 vulnerability

2018-11-10T15:48:35+00:00

commit 9ae24af3669111d418242caec8dd4ebd9ba26860 upstream.

num can be indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/usb/gadget/function/f_mass_storage.c:3177 fsg_lun_make() warn:
potential spectre issue 'fsg_opts->common->luns' [r] (local cap)

Fix this by sanitizing num before using it to index
fsg_opts->common->luns

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
Acked-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: usbip: Fix BUG: KASAN: slab-out-of-bounds in vhci_hub_control()

2018-11-10T15:48:35+00:00

commit 81f7567c51ad97668d1c3a48e8ecc482e64d4161 upstream.

vhci_hub_control() accesses port_status array with out of bounds port
value. Fix it to reference port_status[] only with a valid rhport value
when invalid_rhport flag is true.

The invalid_rhport flag is set early on after detecting in port value
is within the bounds or not.

The following is used reproduce the problem and verify the fix:
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000

Reported-by: syzbot+bccc1fe10b70fadc78d0@syzkaller.appspotmail.com
Cc: stable 
Signed-off-by: Shuah Khan (Samsung OSG) 
Signed-off-by: Greg Kroah-Hartman

cdc-acm: fix race between reset and control messaging

2018-11-10T15:48:35+00:00

commit 9397940ed812b942c520e0c25ed4b2c64d57e8b9 upstream.

If a device splits up a control message and a reset() happens
between the parts, the message is lost and already recieved parts
must be dropped.

Signed-off-by: Oliver Neukum 
Fixes: 1aba579f3cf51 ("cdc-acm: handle read pipe errors")
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

cdc-acm: correct counting of UART states in serial state notification

2018-11-10T15:48:35+00:00

commit f976d0e5747ca65ccd0fb2a4118b193d70aa1836 upstream.

The usb standard ("Universal Serial Bus Class Definitions for Communication
Devices") distiguishes between "consistent signals" (DSR, DCD), and
"irregular signals" (break, ring, parity error, framing error, overrun).
The bits of "irregular signals" are set, if this error/event occurred on
the device side and are immeadeatly unset, if the serial state notification
was sent.
Like other drivers of real serial ports do, just the occurence of those
events should be counted in serial_icounter_struct (but no 1->0
transitions).

Signed-off-by: Tobias Herzog 
Acked-by: Oliver Neukum 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

cdc-acm: do not reset notification buffer index upon urb unlinking

2018-11-10T15:48:35+00:00

commit dae3ddba36f8c337fb59cef07d564da6fc9b7551 upstream.

Resetting the write index of the notification buffer on urb unlink (e.g.
closing a cdc-acm device from userspace) may lead to wrong interpretation
of further received notifications, in case the index is not 0 when urb
unlink happens (i.e. when parts of a notification already have been
transferred). On the device side there is no "reset" of the notification
transimission and thus we would get out of sync with the device.

Signed-off-by: Tobias Herzog 
Acked-by: Oliver Neukum 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

USB: serial: option: add two-endpoints device-id flag

2018-11-10T15:48:34+00:00

commit 35aecc02b5b621782111f64cbb032c7f6a90bb32 upstream

Allow matching on interfaces having two endpoints by adding a new
device-id flag.

This allows for the handling of devices whose interface numbers can
change (e.g. Quectel EP06) to be contained in the device-id table.

The upstream commit removes a variable that is still in use in the 4.14
version of the option-driver, so the removal is undone.

Tested-by: Kristian Evensen 
Cc: stable 
Signed-off-by: Johan Hovold 
Signed-off-by: Kristian Evensen 
Signed-off-by: Sasha Levin

USB: serial: option: improve Quectel EP06 detection

2018-11-10T15:48:33+00:00

commit 36cae568404a298a19a6e8a3f18641075d4cab04 upstream

The Quectel EP06 (and EM06/EG06) LTE modem supports updating the USB
configuration, without the VID/PID or configuration number changing.
When the configuration is updated and interfaces are added/removed, the
interface numbers are updated. This causes our current code for matching
EP06 not to work as intended, as the assumption about reserved
interfaces no longer holds. If for example the diagnostic (first)
interface is removed, option will (try to) bind to the QMI interface.

This patch improves EP06 detection by replacing the current match with
two matches, and those matches check class, subclass and protocol as
well as VID and PID. The diag interface exports class, subclass and
protocol as 0xff. For the other serial interfaces, class is 0xff and
subclass and protocol are both 0x0.

The modem can export the following devices and always in this order:
diag, nmea, at, ppp. qmi and adb. This means that diag can only ever be
interface 0, and interface numbers 1-5 should be marked as reserved. The
three other serial devices can have interface numbers 0-3, but I have
not marked any interfaces as reserved. The reason is that the serial
devices are the only interfaces exported by the device where subclass
and protocol is 0x0.

QMI exports the same class, subclass and protocol values as the diag
interface. However, the two interfaces have different number of
endpoints, QMI has three and diag two. I have added a check for number
of interfaces if VID/PID matches the EP06, and we ignore the device if
number of interfaces equals three (and subclass is set).

The upstream commit does not apply cleanly to the 4.14-tree because of
differences in option_probe(). In order to make the commit apply, a
slight reshuffeling of the code was needed.

Signed-off-by: Kristian Evensen 
Acked-by: Dan Williams 
[ johan: drop uneeded RSVD(5) for ADB ]
Cc: stable 
Signed-off-by: Johan Hovold 
Signed-off-by: Kristian Evensen 
Signed-off-by: Sasha Levin

usbip: vhci_hcd: update 'status' file header and format

2018-11-04T13:52:42+00:00

[ Upstream commit 5468099c747240ed97dbb34340fece8ca87be34f ]

Commit 2f2d0088eb93
("usbip: prevent vhci_hcd driver from leaking a socket pointer address")
in the /sys/devices/platform/vhci_hcd/status.

Fix the header and field alignment to reflect the changes and make it
easier to read.

Signed-off-by: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xhci: Don't print a warning when setting link state for disabled ports

2018-10-18T07:16:25+00:00

commit 1208d8a84fdcae6b395c57911cdf907450d30e70 upstream.

When disabling a USB3 port the hub driver will set the port link state to
U3 to prevent "ejected" or "safely removed" devices that are still
physically connected from immediately re-enumerating.

If the device was really unplugged, then error messages were printed
as the hub tries to set the U3 link state for a port that is no longer
enabled.

xhci-hcd ee000000.usb: Cannot set link state.
usb usb8-port1: cannot disable (err = -32)

Don't print error message in xhci-hub if hub tries to set port link state
for a disabled port. Return -ENODEV instead which also silences hub driver.

Signed-off-by: Mathias Nyman 
Tested-by: Yoshihiro Shimoda 
Signed-off-by: Ross Zwisler 
Signed-off-by: Greg Kroah-Hartman