commit bbdd3de144fc142f2f4b9834c9241cc4e7f3d3fc Author: Greg Kroah-Hartman Date: Wed Sep 8 08:52:41 2021 +0200 Linux 5.14.2 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 commit f05cec9e08080a59f8ca8e39c5a8612747571008 Author: Pavel Skripkin Date: Wed Jul 7 19:54:30 2021 +0200 media: stkwebcam: fix memory leak in stk_camera_probe 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 commit 8ab355d672f95aac1e77b714e98b7c8b4a15e078 Author: Takashi Iwai Date: Fri Aug 27 22:33:11 2021 +0200 ALSA: usb-audio: Work around for XRUN with low latency playback 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 commit d789944b05ad8f98a6ebdef705d29eb1c0021d5c Author: Zubin Mithra Date: Fri Aug 27 08:37:35 2021 -0700 ALSA: pcm: fix divide error in snd_pcm_lib_ioctl 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 commit 5f9aadda1d05482cdb0f6d09322f390e888236e6 Author: Takashi Iwai Date: Fri Aug 20 16:32:14 2021 +0200 ALSA: hda/realtek: Workaround for conflicting SSID on ASUS ROG Strix G17 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 commit 476081ac2afeaffe0b53b59519afab46b3c41ce0 Author: Takashi Iwai Date: Tue Aug 24 07:47:00 2021 +0200 ALSA: usb-audio: Fix regression on Sony WALKMAN NW-A45 DAC 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 commit b0406dde5e5f3c8061c666dddd5322c8e97a1077 Author: Johnathon Clark Date: Mon Aug 23 17:21:10 2021 +0100 ALSA: hda/realtek: Quirk for HP Spectre x360 14 amp setup 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 commit 9260f15e0ad0a8140b2b43b2c02d0cc1296a05d9 Author: Alan Stern Date: Wed Sep 1 12:36:00 2021 -0400 HID: usbhid: Fix warning caused by 0-length input reports 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 commit dbf698e1f4ad49029775529977d30c56d929be48 Author: Michal Kubecek Date: Wed Sep 1 12:35:49 2021 -0400 HID: usbhid: Fix flood of "control queue full" messages 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 commit bb6eb160c0d043e798b508b00b28ff658110320d Author: Johan Hovold Date: Mon Jul 5 10:20:11 2021 +0200 USB: serial: cp210x: fix flow-control error handling 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 commit 363715aee0ef89bdd871dfbf7ba6ce25de18bb40 Author: Johan Hovold Date: Mon Jul 5 10:20:10 2021 +0200 USB: serial: cp210x: fix control-characters error handling 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 commit 8c3084b21f95a005a2e4ede58cabbd66a8c3e695 Author: Robert Marko Date: Thu Aug 26 13:02:39 2021 +0200 USB: serial: pl2303: fix GL type detection 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 commit 1dc13eed10fefc6603586cf4d3011191ba961c74 Author: Randy Dunlap Date: Wed May 26 00:03:37 2021 -0700 xtensa: fix kconfig unmet dependency warning for HAVE_FUTEX_CMPXCHG commit ed5aacc81cd41efc4d561e14af408d1003f7b855 upstream. XTENSA should only select HAVE_FUTEX_CMPXCHG when FUTEX is set/enabled. This prevents a kconfig warning. WARNING: unmet direct dependencies detected for HAVE_FUTEX_CMPXCHG Depends on [n]: FUTEX [=n] Selected by [y]: - XTENSA [=y] && !MMU [=n] Fixes: d951ba21b959 ("xtensa: nommu: select HAVE_FUTEX_CMPXCHG") Signed-off-by: Randy Dunlap Cc: Max Filippov Cc: Chris Zankel Cc: linux-xtensa@linux-xtensa.org Message-Id: <20210526070337.28130-1-rdunlap@infradead.org> Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit f50c411452ab4eaa03f599729f037739a81c92b6 Author: Jan Kara Date: Thu Aug 12 14:47:37 2021 +0200 ext4: fix e2fsprogs checksum failure for mounted filesystem commit b2bbb92f7042e8075fb036bf97043339576330c3 upstream. Commit 81414b4dd48 ("ext4: remove redundant sb checksum recomputation") removed checksum recalculation after updating superblock free space / inode counters in ext4_fill_super() based on the fact that we will recalculate the checksum on superblock writeout. That is correct assumption but until the writeout happens (which can take a long time) the checksum is incorrect in the buffer cache and if programs such as tune2fs or resize2fs is called shortly after a file system is mounted can fail. So return back the checksum recalculation and add a comment explaining why. Fixes: 81414b4dd48f ("ext4: remove redundant sb checksum recomputation") Cc: stable@kernel.org Reported-by: Boyang Xue Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Link: https://lore.kernel.org/r/20210812124737.21981-1-jack@suse.cz Signed-off-by: Greg Kroah-Hartman commit f8ea208b3fbbc0546d71b47e8abaf98b0961dec1 Author: Theodore Ts'o Date: Fri Aug 20 23:44:17 2021 -0400 ext4: fix race writing to an inline_data file while its xattrs are changing commit a54c4613dac1500b40e4ab55199f7c51f028e848 upstream. The location of the system.data extended attribute can change whenever xattr_sem is not taken. So we need to recalculate the i_inline_off field since it mgiht have changed between ext4_write_begin() and ext4_write_end(). This means that caching i_inline_off is probably not helpful, so in the long run we should probably get rid of it and shrink the in-memory ext4 inode slightly, but let's fix the race the simple way for now. Cc: stable@kernel.org Fixes: f19d5870cbf72 ("ext4: add normal write support for inline data") Reported-by: syzbot+13146364637c7363a7de@syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman