linux-stable.git, branch v5.14.2

Linux 5.14.2

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

Link: https://lore.kernel.org/r/20210906125448.160263393@linuxfoundation.org
Tested-by: Fox Chen 
Tested-by: Linux Kernel Functional Testing 
Tested-by: Jon Hunter 
Tested-by: Florian Fainelli 
Tested-by: Shuah Khan 
Tested-by: Salvatore Bonaccorso 
Tested-by: Justin M. Forbes 
Tested-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

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

ALSA: usb-audio: Work around for XRUN with low latency playback

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

commit 4267c5a8f3133db0572cd9abee059b42cafbbdad upstream.

The recent change for low latency playback works in most of test cases
but it turned out still to hit errors on some use cases, most notably
with JACK with small buffer sizes.  This is because USB-audio driver
fills up and submits full URBs at the beginning, while the URBs would
return immediately and try to fill more -- that can easily trigger
XRUN.  It was more or less expected, but in the small buffer size, the
problem became pretty obvious.

Fixing this behavior properly would require the change of the
fundamental driver design, so it's no trivial task, unfortunately.
Instead, here we work around the problem just by switching back to the
old method when the given configuration is too fragile with the low
latency stream handling.  As a threshold, we calculate the total
buffer bytes in all plus one URBs, and check whether it's beyond the
PCM buffer bytes.  The one extra URB is needed because XRUN happens at
the next submission after the first round.

Fixes: 307cc9baac5c ("ALSA: usb-audio: Reduce latency at playback start, take#2")
Cc: 
Link: https://lore.kernel.org/r/20210827203311.5987-1-tiwai@suse.de
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: pcm: fix divide error in snd_pcm_lib_ioctl

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

commit f3eef46f0518a2b32ca1244015820c35a22cfe4a upstream.

Syzkaller reported a divide error in snd_pcm_lib_ioctl. fifo_size
is of type snd_pcm_uframes_t(unsigned long). If frame_size
is 0x100000000, the error occurs.

Fixes: a9960e6a293e ("ALSA: pcm: fix fifo_size frame calculation")
Signed-off-by: Zubin Mithra 
Reviewed-by: Guenter Roeck 
Cc: 
Link: https://lore.kernel.org/r/20210827153735.789452-1-zsm@chromium.org
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda/realtek: Workaround for conflicting SSID on ASUS ROG Strix G17

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

commit 13d9c6b998aaa76fd098133277a28a21f2cc2264 upstream.

ASUS ROG Strix G17 has the very same PCI and codec SSID (1043:103f) as
ASUS TX300, and unfortunately, the existing quirk for TX300 is broken
on ASUS ROG.  Actually the device works without the quirk, so we'll
need to clear the quirk before applying for this device.
Since ASUS ROG has a different codec (ALC294 - while TX300 has
ALC282), this patch adds a workaround for the device, just clearing
the codec->fixup_id by checking the codec vendor_id.

It's a bit ugly to add such a workaround there, but it seems to be the
simplest way.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214101
Cc: 
Link: https://lore.kernel.org/r/20210820143214.3654-1-tiwai@suse.de
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: Fix regression on Sony WALKMAN NW-A45 DAC

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

commit 7af5a14371c1cf94a41f08eabb62a3faceec8911 upstream.

We've got a regression report for USB-audio with Sony WALKMAN NW-A45
DAC device where no sound is audible on recent kernel.  The bisection
resulted in the code change wrt endpoint management, and the further
debug session revealed that it was caused by the order of the USB
audio interface.  In the earlier code, we always set up the USB
interface at first before other setups, but it was changed to be done
at the last for UAC2/3, which is more standard way, while keeping the
old way for UAC1.  OTOH, this device seems requiring the setup of the
interface at first just like UAC1.

This patch works around the regression by applying the interface setup
specifically for the WALKMAN at the beginning of the endpoint setup
procedure.  This change is written straightforwardly to be easily
backported in old kernels.  A further cleanup to move the workaround
into a generic quirk section will follow in a later patch.

Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Cc: 
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214105
Link: https://lore.kernel.org/r/20210824054700.8236-1-tiwai@suse.de
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda/realtek: Quirk for HP Spectre x360 14 amp setup

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

commit 93ab3eafb0b3551c54175cb38afed3b82356a047 upstream.

This patch extends support for the HP Spectre x360 14
amp enable quirk to support a model of the device with
an additional subdevice ID.

Signed-off-by: Johnathon Clark 
Link: https://lore.kernel.org/r/20210823162110.8870-1-john.clark@cantab.net
Cc: 
Signed-off-by: Takashi Iwai 
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