linux-stable.git/drivers, branch v5.14.2

media: stkwebcam: fix memory leak in stk_camera_probe

2021-09-08T06:52:41+00:00

commit 514e97674400462cc09c459a1ddfb9bf39017223 upstream.

My local syzbot instance hit memory leak in usb_set_configuration().
The problem was in unputted usb interface. In case of errors after
usb_get_intf() the reference should be putted to correclty free memory
allocated for this interface.

Fixes: ec16dae5453e ("V4L/DVB (7019): V4L: add support for Syntek DC1125 webcams")
Cc: stable@vger.kernel.org
Signed-off-by: Pavel Skripkin 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

HID: usbhid: Fix warning caused by 0-length input reports

2021-09-08T06:52:40+00:00

commit 0a824efdb724e07574bafcd2c2486b2a3de35ff6 upstream.

Syzbot found a warning caused by hid_submit_ctrl() submitting a
control request to transfer a 0-length input report:

	usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType a1

(The warning message is a little difficult to understand.  It means
that the control request claims to be for an IN transfer but this
contradicts the USB spec, which requires 0-length control transfers
always to be in the OUT direction.)

Now, a zero-length report isn't good for anything and there's no
reason for a device to have one, but the fuzzer likes to pick out
these weird edge cases.  In the future, perhaps we will decide to
reject 0-length reports at probe time.  For now, the simplest approach
for avoiding these warnings is to pretend that the report actually has
length 1.

Signed-off-by: Alan Stern 
Reported-and-tested-by: syzbot+9b57a46bf1801ce2a2ca@syzkaller.appspotmail.com
Tested-by: Oleksandr Natalenko 
Tested-by: Benjamin Tissoires 
Acked-by: Benjamin Tissoires 
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: usbhid: Fix flood of "control queue full" messages

2021-09-08T06:52:39+00:00

commit 5049307d37a760e304ad191c5dc7c6851266d2f8 upstream.

[patch description by Alan Stern]

Commit 7652dd2c5cb7 ("USB: core: Check buffer length matches wLength
for control transfers") causes control URB submissions to fail if the
transfer_buffer_length value disagrees with the setup packet's wLength
valuel.  Unfortunately, it turns out that the usbhid can trigger this
failure mode when it submits a control request for an input report: It
pads the transfer buffer size to a multiple of the maxpacket value but
does not increase wLength correspondingly.

These failures have caused problems for people using an APS UPC, in
the form of a flood of log messages resembling:

	hid-generic 0003:051D:0002.0002: control queue full

This patch fixes the problem by setting the wLength value equal to the
padded transfer_buffer_length value in hid_submit_ctrl().  As a nice
bonus, the code which stores the transfer_buffer_length value is now
shared between the two branches of an "if" statement, so it can be
de-duplicated.

Signed-off-by: Michal Kubecek 
Signed-off-by: Alan Stern 
Fixes: 7652dd2c5cb7 ("USB: core: Check buffer length matches wLength for control transfers")
Tested-by: Oleksandr Natalenko 
Tested-by: Benjamin Tissoires 
Acked-by: Benjamin Tissoires 
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

USB: serial: cp210x: fix flow-control error handling

2021-09-08T06:52:39+00:00

commit ba4bbdabecd11530dca78dbae3ee7e51ffdc0a06 upstream.

Make sure that the driver crtscts state is not updated in the unlikely
event that the flow-control request fails. Not doing so could break RTS
control.

Fixes: 5951b8508855 ("USB: serial: cp210x: suppress modem-control errors")
Cc: stable@vger.kernel.org	# 5.11
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: serial: cp210x: fix control-characters error handling

2021-09-08T06:52:39+00:00

commit 2d9a00705910ccea2dc5d9cba5469ff2de72fc87 upstream.

In the unlikely event that setting the software flow-control characters
fails the other flow-control settings should still be updated (just like
all other terminal settings).

Move out the error message printed by the set_chars() helper to make it
more obvious that this is intentional.

Fixes: 7748feffcd80 ("USB: serial: cp210x: add support for software flow control")
Cc: stable@vger.kernel.org	# 5.11
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: serial: pl2303: fix GL type detection

2021-09-08T06:52:39+00:00

commit dcf097e7d21fbdfbf20e473ac155f4d154018374 upstream.

At least some PL2303GL have a bcdDevice of 0x405 instead of 0x100 as the
datasheet claims. Add it to the list of known release numbers for the
HXN (G) type.

Fixes: 894758d0571d ("USB: serial: pl2303: tighten type HXN (G) detection")
Signed-off-by: Robert Marko 
Cc: stable@vger.kernel.org	# 5.13
Link: https://lore.kernel.org/r/20210826110239.5269-1-robert.marko@sartura.hr
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

Revert "floppy: reintroduce O_NDELAY fix"

2021-09-03T08:24:02+00:00

commit c7e9d0020361f4308a70cdfd6d5335e273eb8717 upstream.

The patch breaks userspace implementations (e.g. fdutils) and introduces
regressions in behaviour. Previously, it was possible to O_NDELAY open a
floppy device with no media inserted or with write protected media without
an error. Some userspace tools use this particular behavior for probing.

It's not the first time when we revert this patch. Previous revert is in
commit f2791e7eadf4 (Revert "floppy: refactor open() flags handling").

This reverts commit 8a0c014cd20516ade9654fc13b51345ec58e7be8.

Link: https://lore.kernel.org/linux-block/de10cb47-34d1-5a88-7751-225ca380f735@compro.net/
Reported-by: Mark Hounschell 
Cc: Jiri Kosina 
Cc: Wim Osterholt 
Cc: Kurt Garloff 
Cc: 
Signed-off-by: Denis Efremov 
Signed-off-by: Greg Kroah-Hartman

net: dsa: mt7530: fix VLAN traffic leaks again

2021-09-03T08:24:01+00:00

commit 7428022b50d0fbb4846dd0f00639ea09d36dff02 upstream.

When a port leaves a VLAN-aware bridge, the current code does not clear
other ports' matrix field bit. If the bridge is later set to VLAN-unaware
mode, traffic in the bridge may leak to that port.

Remove the VLAN filtering check in mt7530_port_bridge_leave.

Fixes: 474a2ddaa192 ("net: dsa: mt7530: fix VLAN traffic leaks")
Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530")
Signed-off-by: DENG Qingfang 
Reviewed-by: Vladimir Oltean 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: btusb: check conditions before enabling USB ALT 3 for WBS

2021-09-03T08:24:01+00:00

commit 55981d3541812234e687062926ff199c83f79a39 upstream.

Some USB BT adapters don't satisfy the MTU requirement mentioned in
commit e848dbd364ac ("Bluetooth: btusb: Add support USB ALT 3 for WBS")
and have ALT 3 setting that produces no/garbled audio. Some adapters
with larger MTU were also reported to have problems with ALT 3.

Add a flag and check it and MTU before selecting ALT 3, falling back to
ALT 1. Enable the flag for Realtek, restoring the previous behavior for
non-Realtek devices.

Tested with USB adapters (mtu<72, no/garbled sound with ALT3, ALT1
works) BCM20702A1 0b05:17cb, CSR8510A10 0a12:0001, and (mtu>=72, ALT3
works) RTL8761BU 0bda:8771, Intel AX200 8087:0029 (after disabling
ALT6). Also got reports for (mtu>=72, ALT 3 reported to produce bad
audio) Intel 8087:0a2b.

Signed-off-by: Pauli Virtanen 
Fixes: e848dbd364ac ("Bluetooth: btusb: Add support USB ALT 3 for WBS")
Tested-by: Michał Kępień 
Tested-by: Jonathan Lampérth 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Greg Kroah-Hartman

vt_kdsetmode: extend console locking

2021-09-03T08:24:01+00:00

commit 2287a51ba822384834dafc1c798453375d1107c7 upstream.

As per the long-suffering comment.

Reported-by: Minh Yuan 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman