kernel/linux.git, branch v5.10.63

Linux 5.10.63

2021-09-08T06:49:02+00:00

Link: https://lore.kernel.org/r/20210906125449.756437409@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Fox Chen Tested-by: Linux Kernel Functional Testing Tested-by: Hulk Robot Tested-by: Sudip Mukherjee Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Salvatore Bonaccorso

media: stkwebcam: fix memory leak in stk_camera_probe

2021-09-08T06:49:02+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

fuse: fix illegal access to inode with reused nodeid

2021-09-08T06:49:02+00:00

commit 15db16837a35d8007cb8563358787412213db25e upstream. Server responds to LOOKUP and other ops (READDIRPLUS/CREATE/MKNOD/...) with ourarg containing nodeid and generation. If a fuse inode is found in inode cache with the same nodeid but different generation, the existing fuse inode should be unhashed and marked "bad" and a new inode with the new generation should be hashed instead. This can happen, for example, with passhrough fuse filesystem that returns the real filesystem ino/generation on lookup and where real inode numbers can get recycled due to real files being unlinked not via the fuse passthrough filesystem. With current code, this situation will not be detected and an old fuse dentry that used to point to an older generation real inode, can be used to access a completely new inode, which should be accessed only via the new dentry. Note that because the FORGET message carries the nodeid w/o generation, the server should wait to get FORGET counts for the nlookup counts of the old and reused inodes combined, before it can free the resources associated to that nodeid. Stable backport notes: * This is not a regression. The bug has been in fuse forever, but only a certain class of low level fuse filesystems can trigger this bug * Because there is no way to check if this fix is applied in runtime, libfuse test_examples.py tests this fix with hardcoded check for kernel version >= 5.14 * After backport to stable kernel(s), the libfuse test can be updated to also check minimal stable kernel version(s) * Depends on "fuse: fix bad inode" which is already applied to stable kernels v5.4.y and v5.10.y * Required backporting helper inode_wrong_type() Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-fsdevel/CAOQ4uxi8DymG=JO_sAU+wS8akFdzh+PuXwW3Ebgahd2Nwnh7zA@mail.gmail.com/ Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman

new helper: inode_wrong_type()

2021-09-08T06:49:01+00:00

commit 6e3e2c4362e41a2f18e3f7a5ad81bd2f49a47b85 upstream. inode_wrong_type(inode, mode) returns true if setting inode->i_mode to given value would've changed the inode type. We have enough of those checks open-coded to make a helper worthwhile. Signed-off-by: Al Viro Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman

spi: Switch to signed types for *_native_cs SPI controller fields

2021-09-08T06:49:01+00:00

commit 35f3f8504c3b60a1ae5576e178b27fc0ddd6157d upstream. While fixing undefined behaviour the commit f60d7270c8a3 ("spi: Avoid undefined behaviour when counting unused native CSs") missed the case when all CSs are GPIOs and thus unused_native_cs will be evaluated to -1 in unsigned representation. This will falsely trigger a condition in the spi_get_gpio_descs(). Switch to signed types for *_native_cs SPI controller fields to fix above. Fixes: f60d7270c8a3 ("spi: Avoid undefined behaviour when counting unused native CSs") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210510131242.49455-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Nobuhiro Iwamatsu (CIP) Signed-off-by: Greg Kroah-Hartman

serial: 8250: 8250_omap: Fix possible array out of bounds access

2021-09-08T06:49:01+00:00

commit d4548b14dd7e5c698f81ce23ce7b69a896373b45 upstream. k3_soc_devices array is missing a sentinel entry which may result in out of bounds access as reported by kernel KASAN. Fix this by adding a sentinel entry. Fixes: 439c7183e5b9 ("serial: 8250: 8250_omap: Disable RX interrupt after DMA enable") Reported-by: Naresh Kamboju Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20201111112653.2710-1-vigneshr@ti.com Signed-off-by: Nobuhiro Iwamatsu (CIP) Signed-off-by: Greg Kroah-Hartman

ALSA: pcm: fix divide error in snd_pcm_lib_ioctl

2021-09-08T06:49:01+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:49:01+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: hda/realtek: Quirk for HP Spectre x360 14 amp setup

2021-09-08T06:49:01+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

cryptoloop: add a deprecation warning

2021-09-08T06:49:01+00:00

[ Upstream commit 222013f9ac30b9cec44301daa8dbd0aae38abffb ] Support for cryptoloop has been officially marked broken and deprecated in favor of dm-crypt (which supports the same broken algorithms if needed) in Linux 2.6.4 (released in March 2004), and support for it has been entirely removed from losetup in util-linux 2.23 (released in April 2013). Add a warning and a deprecation schedule. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20210827163250.255325-1-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin