commit 4f508aa9dd3bde7a1c5e4e6de72abb8a03fd504a Author: Greg Kroah-Hartman Date: Wed Oct 20 11:40:18 2021 +0200 Linux 5.4.155 Link: https://lore.kernel.org/r/20211018132329.453964125@linuxfoundation.org Link: https://lore.kernel.org/r/20211018143049.664480980@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Tested-by: Hulk Robot Signed-off-by: Greg Kroah-Hartman commit 32d2ce0b94994fd739d87a9c30ca6a742992227c Author: Shannon Nelson Date: Fri Oct 8 12:38:01 2021 -0700 ionic: don't remove netdev->dev_addr when syncing uc list commit 5c976a56570f29aaf4a2f9a1bf99789c252183c9 upstream. Bridging, and possibly other upper stack gizmos, adds the lower device's netdev->dev_addr to its own uc list, and then requests it be deleted when the upper bridge device is removed. This delete request also happens with the bridging vlan_filtering is enabled and then disabled. Bonding has a similar behavior with the uc list, but since it also uses set_mac to manage netdev->dev_addr, it doesn't have the same the failure case. Because we store our netdev->dev_addr in our uc list, we need to ignore the delete request from dev_uc_sync so as to not lose the address and all hope of communicating. Note that ndo_set_mac_address is expressly changing netdev->dev_addr, so no limitation is set there. Fixes: 2a654540be10 ("ionic: Add Rx filter and rx_mode ndo support") Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit abaf8e8b9081b55a5e24f198c8ae04d4d1e519ad Author: Vegard Nossum Date: Mon Oct 11 17:22:49 2021 +0200 r8152: select CRC32 and CRYPTO/CRYPTO_HASH/CRYPTO_SHA256 commit 9973a43012b6ad1720dbc4d5faf5302c28635b8c upstream. Fix the following build/link errors by adding a dependency on CRYPTO, CRYPTO_HASH, CRYPTO_SHA256 and CRC32: ld: drivers/net/usb/r8152.o: in function `rtl8152_fw_verify_checksum': r8152.c:(.text+0x2b2a): undefined reference to `crypto_alloc_shash' ld: r8152.c:(.text+0x2bed): undefined reference to `crypto_shash_digest' ld: r8152.c:(.text+0x2c50): undefined reference to `crypto_destroy_tfm' ld: drivers/net/usb/r8152.o: in function `_rtl8152_set_rx_mode': r8152.c:(.text+0xdcb0): undefined reference to `crc32_le' Fixes: 9370f2d05a2a1 ("r8152: support request_firmware for RTL8153") Fixes: ac718b69301c7 ("net/usb: new driver for RTL8152") Signed-off-by: Vegard Nossum Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a4f7d2246e3b7f16646dae74964f4ffc62a798e5 Author: chongjiapeng Date: Sat Oct 9 16:09:26 2021 +0800 qed: Fix missing error code in qed_slowpath_start() commit a5a14ea7b4e55604acb0dc9d88fdb4cb6945bc77 upstream. The error code is missing in this code scenario, add the error code '-EINVAL' to the return value 'rc'. Eliminate the follow smatch warning: drivers/net/ethernet/qlogic/qed/qed_main.c:1298 qed_slowpath_start() warn: missing error code 'rc'. Reported-by: Abaci Robot Fixes: d51e4af5c209 ("qed: aRFS infrastructure support") Signed-off-by: chongjiapeng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 62d96bb68b4e7c13d17de7ce9f572581a8c63ef0 Author: Sebastian Andrzej Siewior Date: Thu Oct 7 19:49:57 2021 +0200 mqprio: Correct stats in mqprio_dump_class_stats(). commit 14132690860e4d06aa3e1c4d7d8e9866ba7756dd upstream. Introduction of lockless subqueues broke the class statistics. Before the change stats were accumulated in `bstats' and `qstats' on the stack which was then copied to struct gnet_dump. After the change the `bstats' and `qstats' are initialized to 0 and never updated, yet still fed to gnet_dump. The code updates the global qdisc->cpu_bstats and qdisc->cpu_qstats instead, clobbering them. Most likely a copy-paste error from the code in mqprio_dump(). __gnet_stats_copy_basic() and __gnet_stats_copy_queue() accumulate the values for per-CPU case but for global stats they overwrite the value, so only stats from the last loop iteration / tc end up in sch->[bq]stats. Use the on-stack [bq]stats variables again and add the stats manually in the global case. Fixes: ce679e8df7ed2 ("net: sched: add support for TCQ_F_NOLOCK subqueues to sch_mqprio") Cc: John Fastabend Signed-off-by: Sebastian Andrzej Siewior https://lore.kernel.org/all/20211007175000.2334713-2-bigeasy@linutronix.de/ Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fa272e8353259c657c8a25c2c2b8eb978968d164 Author: Jackie Liu Date: Mon Aug 23 17:25:26 2021 +0800 acpi/arm64: fix next_platform_timer() section mismatch error commit 596143e3aec35c93508d6b7a05ddc999ee209b61 upstream. Fix modpost Section mismatch error in next_platform_timer(). [...] WARNING: modpost: vmlinux.o(.text.unlikely+0x26e60): Section mismatch in reference from the function next_platform_timer() to the variable .init.data:acpi_gtdt_desc The function next_platform_timer() references the variable __initdata acpi_gtdt_desc. This is often because next_platform_timer lacks a __initdata annotation or the annotation of acpi_gtdt_desc is wrong. WARNING: modpost: vmlinux.o(.text.unlikely+0x26e64): Section mismatch in reference from the function next_platform_timer() to the variable .init.data:acpi_gtdt_desc The function next_platform_timer() references the variable __initdata acpi_gtdt_desc. This is often because next_platform_timer lacks a __initdata annotation or the annotation of acpi_gtdt_desc is wrong. ERROR: modpost: Section mismatches detected. Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them. make[1]: *** [scripts/Makefile.modpost:59: vmlinux.symvers] Error 1 make[1]: *** Deleting file 'vmlinux.symvers' make: *** [Makefile:1176: vmlinux] Error 2 [...] Fixes: a712c3ed9b8a ("acpi/arm64: Add memory-mapped timer support in GTDT driver") Signed-off-by: Jackie Liu Acked-by: Hanjun Guo Link: https://lore.kernel.org/r/20210823092526.2407526-1-liu.yun@linux.dev Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 32ac4ed32b9a8015a971db8828633519a193ed23 Author: Dan Carpenter Date: Fri Oct 1 15:34:09 2021 +0300 drm/msm/dsi: fix off by one in dsi_bus_clk_enable error handling commit c8f01ffc83923a91e8087aaa077de13354a7aa59 upstream. This disables a lock which wasn't enabled and it does not disable the first lock in the array. Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list") Signed-off-by: Dan Carpenter Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20211001123409.GG2283@kili Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 46200989580cf0b32c11bace8630958f72bd32e4 Author: Dan Carpenter Date: Fri Oct 1 15:33:08 2021 +0300 drm/msm/dsi: Fix an error code in msm_dsi_modeset_init() commit 739b4e7756d3301dd673ca517afca46a5f635562 upstream. Return an error code if msm_dsi_manager_validate_current_config(). Don't return success. Fixes: 8b03ad30e314 ("drm/msm/dsi: Use one connector for dual DSI mode") Signed-off-by: Dan Carpenter Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20211001123308.GF2283@kili Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit f302be08e3de94db8863a0b2958b2bb3e8e998e6 Author: Colin Ian King Date: Wed Sep 29 13:18:57 2021 +0100 drm/msm: Fix null pointer dereference on pointer edp commit 2133c4fc8e1348dcb752f267a143fe2254613b34 upstream. The initialization of pointer dev dereferences pointer edp before edp is null checked, so there is a potential null pointer deference issue. Fix this by only dereferencing edp after edp has been null checked. Addresses-Coverity: ("Dereference before null check") Fixes: ab5b0107ccf3 ("drm/msm: Initial add eDP support in msm drm driver (v5)") Signed-off-by: Colin Ian King Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210929121857.213922-1-colin.king@canonical.com Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 0d5ef1e87554c94fb94c52ef713c1b2df3b406c0 Author: Vegard Nossum Date: Tue Oct 12 13:52:42 2021 +0200 drm/panel: olimex-lcd-olinuxino: select CRC32 commit a14bc107edd0c108bda2245e50daa22f91c95d20 upstream. Fix the following build/link error by adding a dependency on the CRC32 routines: ld: drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.o: in function `lcd_olinuxino_probe': panel-olimex-lcd-olinuxino.c:(.text+0x303): undefined reference to `crc32_le' Fixes: 17fd7a9d324fd ("drm/panel: Add support for Olimex LCD-OLinuXino panel") Cc: Arnd Bergmann Signed-off-by: Vegard Nossum Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20211012115242.10325-1-vegard.nossum@oracle.com Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 9225d57f51e2af57ca317fd2481880221a6b3362 Author: Vadim Pasternak Date: Mon Sep 27 17:22:13 2021 +0300 platform/mellanox: mlxreg-io: Fix argument base in kstrtou32() call commit 9b024201693e397441668cca0d2df7055fe572eb upstream. Change kstrtou32() argument 'base' to be zero instead of 'len'. It works by chance for setting one bit value, but it is not supposed to work in case value passed to mlxreg_io_attr_store() is greater than 1. It works for example, for: echo 1 > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable But it will fail for: echo n > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable, where n > 1. The flow for input buffer conversion is as below: _kstrtoull(const char *s, unsigned int base, unsigned long long *res) calls: rv = _parse_integer(s, base, &_res); For the second case, where n > 1: - _parse_integer() converts 's' to 'val'. For n=2, 'len' is set to 2 (string buffer is 0x32 0x0a), for n=3 'len' is set to 3 (string buffer 0x33 0x0a), etcetera. - 'base' is equal or greater then '2' (length of input buffer). As a result, _parse_integer() exits with result zero (rv): rv = 0; while (1) { ... if (val >= base)-> (2 >= 2) break; ... rv++; ... } And _kstrtoull() in their turn will fail: if (rv == 0) return -EINVAL; Fixes: 5ec4a8ace06c ("platform/mellanox: Introduce support for Mellanox register access driver") Signed-off-by: Vadim Pasternak Link: https://lore.kernel.org/r/20210927142214.2613929-2-vadimp@nvidia.com Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit ae0993739e14a102d506aa09e11b0065f3144f10 Author: Ido Schimmel Date: Tue Oct 12 20:49:55 2021 +0300 mlxsw: thermal: Fix out-of-bounds memory accesses commit 332fdf951df8b870e3da86b122ae304e2aabe88c upstream. Currently, mlxsw allows cooling states to be set above the maximum cooling state supported by the driver: # cat /sys/class/thermal/thermal_zone2/cdev0/type mlxsw_fan # cat /sys/class/thermal/thermal_zone2/cdev0/max_state 10 # echo 18 > /sys/class/thermal/thermal_zone2/cdev0/cur_state # echo $? 0 This results in out-of-bounds memory accesses when thermal state transition statistics are enabled (CONFIG_THERMAL_STATISTICS=y), as the transition table is accessed with a too large index (state) [1]. According to the thermal maintainer, it is the responsibility of the driver to reject such operations [2]. Therefore, return an error when the state to be set exceeds the maximum cooling state supported by the driver. To avoid dead code, as suggested by the thermal maintainer [3], partially revert commit a421ce088ac8 ("mlxsw: core: Extend cooling device with cooling levels") that tried to interpret these invalid cooling states (above the maximum) in a special way. The cooling levels array is not removed in order to prevent the fans going below 20% PWM, which would cause them to get stuck at 0% PWM. [1] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x271/0x290 Read of size 4 at addr ffff8881052f7bf8 by task kworker/0:0/5 CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122 Hardware name: Mellanox Technologies Ltd. "MSN2410-CB2FO"/"SA000874", BIOS 4.6.5 03/08/2016 Workqueue: events_freezable_power_ thermal_zone_device_check Call Trace: dump_stack_lvl+0x8b/0xb3 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x7f/0x11b thermal_cooling_device_stats_update+0x271/0x290 __thermal_cdev_update+0x15e/0x4e0 thermal_cdev_update+0x9f/0xe0 step_wise_throttle+0x770/0xee0 thermal_zone_device_update+0x3f6/0xdf0 process_one_work+0xa42/0x1770 worker_thread+0x62f/0x13e0 kthread+0x3ee/0x4e0 ret_from_fork+0x1f/0x30 Allocated by task 1: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 thermal_cooling_device_setup_sysfs+0x153/0x2c0 __thermal_cooling_device_register.part.0+0x25b/0x9c0 thermal_cooling_device_register+0xb3/0x100 mlxsw_thermal_init+0x5c5/0x7e0 __mlxsw_core_bus_device_register+0xcb3/0x19c0 mlxsw_core_bus_device_register+0x56/0xb0 mlxsw_pci_probe+0x54f/0x710 local_pci_probe+0xc6/0x170 pci_device_probe+0x2b2/0x4d0 really_probe+0x293/0xd10 __driver_probe_device+0x2af/0x440 driver_probe_device+0x51/0x1e0 __driver_attach+0x21b/0x530 bus_for_each_dev+0x14c/0x1d0 bus_add_driver+0x3ac/0x650 driver_register+0x241/0x3d0 mlxsw_sp_module_init+0xa2/0x174 do_one_initcall+0xee/0x5f0 kernel_init_freeable+0x45a/0x4de kernel_init+0x1f/0x210 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff8881052f7800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 1016 bytes inside of 1024-byte region [ffff8881052f7800, ffff8881052f7c00) The buggy address belongs to the page: page:0000000052355272 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1052f0 head:0000000052355272 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x200000000010200(slab|head|node=0|zone=2) raw: 0200000000010200 ffffea0005034800 0000000300000003 ffff888100041dc0 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8881052f7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8881052f7c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [2] https://lore.kernel.org/linux-pm/9aca37cb-1629-5c67-1895-1fdc45c0244e@linaro.org/ [3] https://lore.kernel.org/linux-pm/af9857f2-578e-de3a-e62b-6baff7e69fd4@linaro.org/ CC: Daniel Lezcano Fixes: a50c1e35650b ("mlxsw: core: Implement thermal zone") Fixes: a421ce088ac8 ("mlxsw: core: Extend cooling device with cooling levels") Signed-off-by: Ido Schimmel Tested-by: Vadim Pasternak Link: https://lore.kernel.org/r/20211012174955.472928-1-idosch@idosch.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 97e6dcb41625dce2947e0911725539461e7f163c Author: Wang Hai Date: Wed Oct 13 14:16:31 2021 +0800 ata: ahci_platform: fix null-ptr-deref in ahci_platform_enable_regulators() commit 776c75010803849c1cc4f11031a2b3960ab05202 upstream. I got a null-ptr-deref report: KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] ... RIP: 0010:regulator_enable+0x84/0x260 ... Call Trace: ahci_platform_enable_regulators+0xae/0x320 ahci_platform_enable_resources+0x1a/0x120 ahci_probe+0x4f/0x1b9 platform_probe+0x10b/0x280 ... entry_SYSCALL_64_after_hwframe+0x44/0xae If devm_regulator_get() in ahci_platform_get_resources() fails, hpriv->phy_regulator will point to NULL, when enabling or disabling it, null-ptr-deref will occur. ahci_probe() ahci_platform_get_resources() devm_regulator_get(, "phy") // failed, let phy_regulator = NULL ahci_platform_enable_resources() ahci_platform_enable_regulators() regulator_enable(hpriv->phy_regulator) // null-ptr-deref commit 962399bb7fbf ("ata: libahci_platform: Fix regulator_get_optional() misuse") replaces devm_regulator_get_optional() with devm_regulator_get(), but PHY regulator omits to delete "hpriv->phy_regulator = NULL;" like AHCI. Delete it like AHCI regulator to fix this bug. Fixes: commit 962399bb7fbf ("ata: libahci_platform: Fix regulator_get_optional() misuse") Reported-by: Hulk Robot Signed-off-by: Wang Hai Reviewed-by: Hans de Goede Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit b9352ed9b983054daebc1d0189ef4a5575ebfb74 Author: Dan Carpenter Date: Wed Oct 6 10:34:19 2021 +0300 pata_legacy: fix a couple uninitialized variable bugs commit 013923477cb311293df9079332cf8b806ed0e6f2 upstream. The last byte of "pad" is used without being initialized. Fixes: 55dba3120fbc ("libata: update ->data_xfer hook for ATAPI") Signed-off-by: Dan Carpenter Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 2bde4aca56db9fe25405d39ddb062531493a65db Author: Ziyang Xuan Date: Wed Oct 13 15:50:32 2021 +0800 NFC: digital: fix possible memory leak in digital_in_send_sdd_req() commit 291c932fc3692e4d211a445ba8aa35663831bac7 upstream. 'skb' is allocated in digital_in_send_sdd_req(), but not free when digital_in_send_cmd() failed, which will cause memory leak. Fix it by freeing 'skb' if digital_in_send_cmd() return failed. Fixes: 2c66daecc409 ("NFC Digital: Add NFC-A technology support") Signed-off-by: Ziyang Xuan Reviewed-by: Krzysztof Kozlowski Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7ab488d7228a9dceb2456867f1f0919decf6efed Author: Ziyang Xuan Date: Wed Oct 13 15:50:12 2021 +0800 NFC: digital: fix possible memory leak in digital_tg_listen_mdaa() commit 58e7dcc9ca29c14e44267a4d0ea61e3229124907 upstream. 'params' is allocated in digital_tg_listen_mdaa(), but not free when digital_send_cmd() failed, which will cause memory leak. Fix it by freeing 'params' if digital_send_cmd() return failed. Fixes: 1c7a4c24fbfd ("NFC Digital: Add target NFC-DEP support") Signed-off-by: Ziyang Xuan Reviewed-by: Krzysztof Kozlowski Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 69b3a13f0d082c5b90cd36f31fc8149d1d2d8489 Author: Ziyang Xuan Date: Wed Oct 13 11:49:32 2021 +0800 nfc: fix error handling of nfc_proto_register() commit 0911ab31896f0e908540746414a77dd63912748d upstream. When nfc proto id is using, nfc_proto_register() return -EBUSY error code, but forgot to unregister proto. Fix it by adding proto_unregister() in the error handling case. Fixes: c7fe3b52c128 ("NFC: add NFC socket family") Signed-off-by: Ziyang Xuan Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20211013034932.2833737-1-william.xuanziyang@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2731eaac19656161161439f929b01a82402842f3 Author: Arnd Bergmann Date: Wed Oct 13 16:35:49 2021 +0200 ethernet: s2io: fix setting mac address during resume commit 40507e7aada8422c38aafa0c8a1a09e4623c712a upstream. After recent cleanups, gcc started warning about a suspicious memcpy() call during the s2io_io_resume() function: In function '__dev_addr_set', inlined from 'eth_hw_addr_set' at include/linux/etherdevice.h:318:2, inlined from 's2io_set_mac_addr' at drivers/net/ethernet/neterion/s2io.c:5205:2, inlined from 's2io_io_resume' at drivers/net/ethernet/neterion/s2io.c:8569:7: arch/x86/include/asm/string_32.h:182:25: error: '__builtin_memcpy' accessing 6 bytes at offsets 0 and 2 overlaps 4 bytes at offset 2 [-Werror=restrict] 182 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n) | ^~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/netdevice.h:4648:9: note: in expansion of macro 'memcpy' 4648 | memcpy(dev->dev_addr, addr, len); | ^~~~~~ What apparently happened is that an old cleanup changed the calling conventions for s2io_set_mac_addr() from taking an ethernet address as a character array to taking a struct sockaddr, but one of the callers was not changed at the same time. Change it to instead call the low-level do_s2io_prog_unicast() function that still takes the old argument type. Fixes: 2fd376884558 ("S2io: Added support set_mac_address driver entry point") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20211013143613.2049096-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4c2eb80fc90b05559ce6ed1b8dfb2348420b5644 Author: Nanyong Sun Date: Tue Oct 12 20:59:01 2021 +0800 net: encx24j600: check error in devm_regmap_init_encx24j600 commit f03dca0c9e2297c84a018e306f8a9cd534ee4287 upstream. devm_regmap_init may return error which caused by like out of memory, this will results in null pointer dereference later when reading or writing register: general protection fault in encx24j600_spi_probe KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540 Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00 RSP: 0018:ffffc900010476b8 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000 RDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094 RBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a R10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001 R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08 FS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459 spi_probe drivers/spi/spi.c:397 really_probe drivers/base/dd.c:517 __driver_probe_device drivers/base/dd.c:751 driver_probe_device drivers/base/dd.c:782 __device_attach_driver drivers/base/dd.c:899 bus_for_each_drv drivers/base/bus.c:427 __device_attach drivers/base/dd.c:971 bus_probe_device drivers/base/bus.c:487 device_add drivers/base/core.c:3364 __spi_add_device drivers/spi/spi.c:599 spi_add_device drivers/spi/spi.c:641 spi_new_device drivers/spi/spi.c:717 new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e] dev_attr_store drivers/base/core.c:2074 sysfs_kf_write fs/sysfs/file.c:139 kernfs_fop_write_iter fs/kernfs/file.c:300 new_sync_write fs/read_write.c:508 (discriminator 4) vfs_write fs/read_write.c:594 ksys_write fs/read_write.c:648 do_syscall_64 arch/x86/entry/common.c:50 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113 Add error check in devm_regmap_init_encx24j600 to avoid this situation. Fixes: 04fbfce7a222 ("net: Microchip encx24j600 driver") Reported-by: Hulk Robot Signed-off-by: Nanyong Sun Link: https://lore.kernel.org/r/20211012125901.3623144-1-sunnanyong@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0904e1be2a92157dd7a98ce780f502a2848e9429 Author: Herve Codina Date: Fri Oct 8 12:34:37 2021 +0200 net: stmmac: fix get_hw_feature() on old hardware commit 075da584bae2da6a37428d59a477b6bdad430ac3 upstream. Some old IPs do not provide the hardware feature register. On these IPs, this register is read 0x00000000. In old driver version, this feature was handled but a regression came with the commit f10a6a3541b4 ("stmmac: rework get_hw_feature function"). Indeed, this commit removes the return value in dma->get_hw_feature(). This return value was used to indicate the validity of retrieved information and used later on in stmmac_hw_init() to override priv->plat data if this hardware feature were valid. This patch restores the return code in ->get_hw_feature() in order to indicate the hardware feature validity and override priv->plat data only if this hardware feature is valid. Fixes: f10a6a3541b4 ("stmmac: rework get_hw_feature function") Signed-off-by: Herve Codina Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 06251ea8d1d9c1c4c0f48b9fe1e9600836ce3e7e Author: Aya Levin Date: Sun Sep 26 17:55:41 2021 +0300 net/mlx5e: Mutually exclude RX-FCS and RX-port-timestamp commit 0bc73ad46a76ed6ece4dcacb28858e7b38561e1c upstream. Due to current HW arch limitations, RX-FCS (scattering FCS frame field to software) and RX-port-timestamp (improved timestamp accuracy on the receive side) can't work together. RX-port-timestamp is not controlled by the user and it is enabled by default when supported by the HW/FW. This patch sets RX-port-timestamp opposite to RX-FCS configuration. Fixes: 102722fc6832 ("net/mlx5e: Add support for RXFCS feature flag") Signed-off-by: Aya Levin Reviewed-by: Tariq Toukan Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 19a01522c5d0b7f7e2ae591edd0b7134b3299d82 Author: Vegard Nossum Date: Tue Oct 12 17:25:09 2021 +0200 net: korina: select CRC32 commit 427f974d9727ca681085ddcd0530c97ab5811ae0 upstream. Fix the following build/link error by adding a dependency on the CRC32 routines: ld: drivers/net/ethernet/korina.o: in function `korina_multicast_list': korina.c:(.text+0x1af): undefined reference to `crc32_le' Fixes: ef11291bcd5f9 ("Add support the Korina (IDT RC32434) Ethernet MAC") Cc: Arnd Bergmann Signed-off-by: Vegard Nossum Acked-by: Florian fainelli Link: https://lore.kernel.org/r/20211012152509.21771-1-vegard.nossum@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 32b57d897eff861deec60c900f12db4875dd1e1a Author: Vegard Nossum Date: Tue Oct 12 11:34:46 2021 +0200 net: arc: select CRC32 commit e599ee234ad4fdfe241d937bbabd96e0d8f9d868 upstream. Fix the following build/link error by adding a dependency on the CRC32 routines: ld: drivers/net/ethernet/arc/emac_main.o: in function `arc_emac_set_rx_mode': emac_main.c:(.text+0xb11): undefined reference to `crc32_le' The crc32_le() call comes through the ether_crc_le() call in arc_emac_set_rx_mode(). [v2: moved the select to ARC_EMAC_CORE; the Makefile is a bit confusing, but the error comes from emac_main.o, which is part of the arc_emac module, which in turn is enabled by CONFIG_ARC_EMAC_CORE. Note that arc_emac is different from emac_arc...] Fixes: 775dd682e2b0ec ("arc_emac: implement promiscuous mode and multicast filtering") Cc: Arnd Bergmann Signed-off-by: Vegard Nossum Link: https://lore.kernel.org/r/20211012093446.1575-1-vegard.nossum@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2880dc1302360c186c52b9270abcd49ddce43e4a Author: Andy Shevchenko Date: Fri Sep 24 01:46:40 2021 +0300 gpio: pca953x: Improve bias setting commit 55a9968c7e139209a9e93d4ca4321731bea5fc95 upstream. The commit 15add06841a3 ("gpio: pca953x: add ->set_config implementation") introduced support for bias setting. However this, due to being half-baked, brought potential issues: - the turning bias via disabling makes the pin floating for a while; - once enabled, bias can't be disabled. Fix all these by adding support for bias disabling and move the disabling part under the corresponding conditional. While at it, add support for default setting, since it's cheap to add. Fixes: 15add06841a3 ("gpio: pca953x: add ->set_config implementation") Cc: Thomas Petazzoni Signed-off-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit d88774539539dcbf825a25e61234f110513f5963 Author: Eiichi Tsukata Date: Wed Oct 13 17:27:29 2021 -0300 sctp: account stream padding length for reconf chunk commit a2d859e3fc97e79d907761550dbc03ff1b36479c upstream. sctp_make_strreset_req() makes repeated calls to sctp_addto_chunk() which will automatically account for padding on each call. inreq and outreq are already 4 bytes aligned, but the payload is not and doing SCTP_PAD4(a + b) (which _sctp_make_chunk() did implicitly here) is different from SCTP_PAD4(a) + SCTP_PAD4(b) and not enough. It led to possible attempt to use more buffer than it was allocated and triggered a BUG_ON. Cc: Vlad Yasevich Cc: Neil Horman Cc: Greg KH Fixes: cc16f00f6529 ("sctp: add support for generating stream reconf ssn reset request chunk") Reported-by: Eiichi Tsukata Signed-off-by: Eiichi Tsukata Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: Marcelo Ricardo Leitner Reviewed-by: Xin Long Link: https://lore.kernel.org/r/b97c1f8b0c7ff79ac4ed206fc2c49d3612e0850c.1634156849.git.mleitner@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 232c485c6bcd50345d6b0564f56bfe69ccaa6f1a Author: Dan Carpenter Date: Mon Aug 16 21:39:54 2021 +0300 iio: dac: ti-dac5571: fix an error code in probe() commit f7a28df7db84eb3410e9eca37832efa5aed93338 upstream. If we have an unexpected number of channels then return -EINVAL instead of returning success. Fixes: df38a4a72a3b ("iio: dac: add TI DAC5571 family support") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20210816183954.GB2068@kili Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 69696951de5a473f44e98c5573782886213b14a7 Author: Dan Carpenter Date: Tue Sep 14 13:53:33 2021 +0300 iio: ssp_sensors: fix error code in ssp_print_mcu_debug() commit 4170d3dd1467e9d78cb9af374b19357dc324b328 upstream. The ssp_print_mcu_debug() function should return negative error codes on error. Returning "length" is meaningless. This change does not affect runtime because the callers only care about zero/non-zero. Reported-by: Jonathan Cameron Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20210914105333.GA11657@kili Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 10ecff1522eb8dc523844ae4fcc5e0c088f54837 Author: Dan Carpenter Date: Thu Sep 9 12:13:36 2021 +0300 iio: ssp_sensors: add more range checking in ssp_parse_dataframe() commit 8167c9a375ccceed19048ad9d68cb2d02ed276e0 upstream. The "idx" is validated at the start of the loop but it gets incremented during the iteration so it needs to be checked again. Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20210909091336.GA26312@kili Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ac0688bcd151cef5e4131850a1a5a245c8eae6a0 Author: Jiri Valek - 2N Date: Mon Sep 20 14:53:48 2021 +0200 iio: light: opt3001: Fixed timeout error when 0 lux commit 26d90b5590579def54382a2fc34cfbe8518a9851 upstream. Reading from sensor returned timeout error under zero light conditions. Signed-off-by: Jiri Valek - 2N Fixes: ac663db3678a ("iio: light: opt3001: enable operation w/o IRQ") Link: https://lore.kernel.org/r/20210920125351.6569-1-valek@2n.cz Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3c00d93297ff4117942a174e6784332984851667 Author: Hui Liu Date: Sun Sep 26 15:30:28 2021 +0800 iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSED commit c2980c64c7fd4585d684574c92d1624d44961edd upstream. The previous driver does't apply the necessary scaling to take the voltage range into account. We change readback value from raw data to input voltage to fix case IIO_CHAN_INFO_PROCESSED. Fixes: ace4cdfe67be ("iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.") Signed-off-by: Hui Liu Link: https://lore.kernel.org/r/20210926073028.11045-2-hui.liu@mediatek.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit cf4b39907a82c82f27d5ce15382ae8b1337e218b Author: Christophe JAILLET Date: Sat Aug 21 12:37:24 2021 +0200 iio: adc128s052: Fix the error handling path of 'adc128_probe()' commit bbcf40816b547b3c37af49168950491d20d81ce1 upstream. A successful 'regulator_enable()' call should be balanced by a corresponding 'regulator_disable()' call in the error handling path of the probe, as already done in the remove function. Update the error handling path accordingly. Fixes: 913b86468674 ("iio: adc: Add TI ADC128S052") Signed-off-by: Christophe JAILLET Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/85189f1cfcf6f5f7b42d8730966f2a074b07b5f5.1629542160.git.christophe.jaillet@wanadoo.fr Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 580c09a9ef9e0f7ece299efc30a29768fe946f66 Author: Billy Tsai Date: Tue Aug 31 15:14:44 2021 +0800 iio: adc: aspeed: set driver data when adc probe. commit eb795cd97365a3d3d9da3926d234a7bc32a3bb15 upstream. Fix the issue when adc remove will get the null driver data. Fixed: commit 573803234e72 ("iio: Aspeed ADC") Signed-off-by: Billy Tsai Link: https://lore.kernel.org/r/20210831071458.2334-2-billy_tsai@aspeedtech.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 1904050cacd71629fcee2664b962077c551da4a1 Author: Cédric Le Goater Date: Mon Oct 11 09:02:03 2021 +0200 powerpc/xive: Discard disabled interrupts in get_irqchip_state() commit 6f779e1d359b8d5801f677c1d49dcfa10bf95674 upstream. When an interrupt is passed through, the KVM XIVE device calls the set_vcpu_affinity() handler which raises the P bit to mask the interrupt and to catch any in-flight interrupts while routing the interrupt to the guest. On the guest side, drivers (like some Intels) can request at probe time some MSIs and call synchronize_irq() to check that there are no in flight interrupts. This will call the XIVE get_irqchip_state() handler which will always return true as the interrupt P bit has been set on the host side and lock the CPU in an infinite loop. Fix that by discarding disabled interrupts in get_irqchip_state(). Fixes: da15c03b047d ("powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race") Cc: stable@vger.kernel.org #v5.4+ Signed-off-by: Cédric Le Goater Tested-by: seeteena Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211011070203.99726-1-clg@kaod.org Signed-off-by: Greg Kroah-Hartman commit 5683ed468fa080d3ec1d11fea67ac6667e964821 Author: Borislav Petkov Date: Wed Oct 6 19:34:55 2021 +0200 x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT automatically commit 711885906b5c2df90746a51f4cd674f1ab9fbb1d upstream. This Kconfig option was added initially so that memory encryption is enabled by default on machines which support it. However, devices which have DMA masks that are less than the bit position of the encryption bit, aka C-bit, require the use of an IOMMU or the use of SWIOTLB. If the IOMMU is disabled or in passthrough mode, the kernel would switch to SWIOTLB bounce-buffering for those transfers. In order to avoid that, 2cc13bb4f59f ("iommu: Disable passthrough mode when SME is active") disables the default IOMMU passthrough mode so that devices for which the default 256K DMA is insufficient, can use the IOMMU instead. However 2, there are cases where the IOMMU is disabled in the BIOS, etc. (think the usual hardware folk "oops, I dropped the ball there" cases) or a driver doesn't properly use the DMA APIs or a device has a firmware or hardware bug, e.g.: ea68573d408f ("drm/amdgpu: Fail to load on RAVEN if SME is active") However 3, in the above GPU use case, there are APIs like Vulkan and some OpenGL/OpenCL extensions which are under the assumption that user-allocated memory can be passed in to the kernel driver and both the GPU and CPU can do coherent and concurrent access to the same memory. That cannot work with SWIOTLB bounce buffers, of course. So, in order for those devices to function, drop the "default y" for the SME by default active option so that users who want to have SME enabled, will need to either enable it in their config or use "mem_encrypt=on" on the kernel command line. [ tlendacky: Generalize commit message. ] Fixes: 7744ccdbc16f ("x86/mm: Add Secure Memory Encryption (SME) support") Reported-by: Paul Menzel Signed-off-by: Borislav Petkov Acked-by: Alex Deucher Acked-by: Tom Lendacky Cc: Link: https://lkml.kernel.org/r/8bbacd0e-4580-3194-19d2-a0ecad7df09c@molgen.mpg.de Signed-off-by: Greg Kroah-Hartman commit 0594f1d048d8dc338eb9a240021b1d00ae1eb082 Author: Stephen Boyd Date: Wed Oct 13 13:45:11 2021 +0100 nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells commit 5d388fa01fa6eb310ac023a363a6cb216d9d8fe9 upstream. If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0); will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we subtract one from that making a large number that is then shifted more than the number of bits that fit into an unsigned long. UBSAN reports this problem: UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20 Fix it by making sure there are any bits to mask out. Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Cc: Douglas Anderson Cc: stable@vger.kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20211013124511.18726-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit d07571672c903c88dc5b003f9355ee6b08379aba Author: Hans Potsch Date: Wed Oct 6 14:13:32 2021 +0200 EDAC/armada-xp: Fix output of uncorrectable error counter commit d9b7748ffc45250b4d7bcf22404383229bc495f5 upstream. The number of correctable errors is displayed as uncorrectable errors because the "SBE" error count is passed to both calls of edac_mc_handle_error(). Pass the correct uncorrectable error count to the second edac_mc_handle_error() call when logging uncorrectable errors. [ bp: Massage commit message. ] Fixes: 7f6998a41257 ("ARM: 8888/1: EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC") Signed-off-by: Hans Potsch Signed-off-by: Borislav Petkov Cc: Link: https://lkml.kernel.org/r/20211006121332.58788-1-hans.potsch@nokia.com Signed-off-by: Greg Kroah-Hartman commit dba8834baed31e2f506c6f0effc49c40f8881308 Author: Halil Pasic Date: Mon Oct 11 07:39:21 2021 +0200 virtio: write back F_VERSION_1 before validate commit 2f9a174f918e29608564c7a4e8329893ab604fb4 upstream. The virtio specification virtio-v1.1-cs01 states: "Transitional devices MUST detect Legacy drivers by detecting that VIRTIO_F_VERSION_1 has not been acknowledged by the driver." This is exactly what QEMU as of 6.1 has done relying solely on VIRTIO_F_VERSION_1 for detecting that. However, the specification also says: "... the driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device ..." before setting FEATURES_OK. In that case, any transitional device relying solely on VIRTIO_F_VERSION_1 for detecting legacy drivers will return data in legacy format. In particular, this implies that it is in big endian format for big endian guests. This naturally confuses the driver which expects little endian in the modern mode. It is probably a good idea to amend the spec to clarify that VIRTIO_F_VERSION_1 can only be relied on after the feature negotiation is complete. Before validate callback existed, config space was only read after FEATURES_OK. However, we already have two regressions, so let's address this here as well. The regressions affect the VIRTIO_NET_F_MTU feature of virtio-net and the VIRTIO_BLK_F_BLK_SIZE feature of virtio-blk for BE guests when virtio 1.0 is used on both sides. The latter renders virtio-blk unusable with DASD backing, because things simply don't work with the default. See Fixes tags for relevant commits. For QEMU, we can work around the issue by writing out the feature bits with VIRTIO_F_VERSION_1 bit set. We (ab)use the finalize_features config op for this. This isn't enough to address all vhost devices since these do not get the features until FEATURES_OK, however it looks like the affected devices actually never handled the endianness for legacy mode correctly, so at least that's not a regression. No devices except virtio net and virtio blk seem to be affected. Long term the right thing to do is to fix the hypervisors. Cc: #v4.11 Signed-off-by: Halil Pasic Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config space") Fixes: fe36cbe0671e ("virtio_net: clear MTU when out of range") Reported-by: markver@us.ibm.com Reviewed-by: Cornelia Huck Link: https://lore.kernel.org/r/20211011053921.1198936-1-pasic@linux.ibm.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 1b39a67856cca3406484ab66b2aea7b4553f02ca Author: Tomaz Solc Date: Wed Oct 6 14:57:50 2021 +0200 USB: serial: option: add prod. id for Quectel EG91 commit c184accc4a42c7872dc8e8d0fc97a740dc61fe24 upstream. Adding support for Quectel EG91 LTE module. The interface layout is same as for EG95. usb-devices output: T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0191 Rev=03.18 S: Manufacturer=Android S: Product=Android C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan Interfaces: 0: Diag 1: GNSS 2: AT-command interface/modem 3: Modem 4: QMI Signed-off-by: Tomaz Solc Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 41e178c138d9e4c566154c8a5f7c237bfb10998c Author: Daniele Palmas Date: Mon Oct 4 12:56:55 2021 +0200 USB: serial: option: add Telit LE910Cx composition 0x1204 commit f5a8a07edafed8bede17a95ef8940fe3a57a77d5 upstream. Add the following Telit LE910Cx composition: 0x1204: tty, adb, mbim, tty, tty, tty, tty Signed-off-by: Daniele Palmas Link: https://lore.kernel.org/r/20211004105655.8515-1-dnlplm@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 848eac2cb7855c93bd3f29244ce21ef420e69d56 Author: Yu-Tung Chang Date: Thu Sep 30 10:11:12 2021 +0800 USB: serial: option: add Quectel EC200S-CN module support commit 2263eb7370060bdb0013bc14e1a7c9bf33617a55 upstream. Add usb product id of the Quectel EC200S-CN module. usb-devices output for 0x6002: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=6002 Rev=03.18 S: Manufacturer=Android S: Product=Android S: SerialNumber=0000 C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Signed-off-by: Yu-Tung Chang Link: https://lore.kernel.org/r/20210930021112.330396-1-mtwget@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 958e98ca522c1da51d5b4180689274ff16a2a327 Author: Aleksander Morgado Date: Thu Oct 7 14:25:01 2021 +0200 USB: serial: qcserial: add EM9191 QDL support commit 11c52d250b34a0862edc29db03fbec23b30db6da upstream. When the module boots into QDL download mode it exposes the 1199:90d2 ids, which can be mapped to the qcserial driver, and used to run firmware upgrades (e.g. with the qmi-firmware-update program). T: Bus=01 Lev=03 Prnt=08 Port=03 Cnt=01 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1199 ProdID=90d2 Rev=00.00 S: Manufacturer=Sierra Wireless, Incorporated S: Product=Sierra Wireless EM9191 S: SerialNumber=8W0382004102A109 C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=2mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=10 Driver=qcserial Signed-off-by: Aleksander Morgado Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 733dcc08e97b05d3058eab1f2ee94f4606a8d28b Author: Michael Cullen Date: Fri Oct 15 13:17:50 2021 -0700 Input: xpad - add support for another USB ID of Nacon GC-100 commit 3378a07daa6cdd11e042797454c706d1c69f9ca6 upstream. The Nacon GX100XF is already mapped, but it seems there is a Nacon GC-100 (identified as NC5136Wht PCGC-100WHITE though I believe other colours exist) with a different USB ID when in XInput mode. Signed-off-by: Michael Cullen Link: https://lore.kernel.org/r/20211015192051.5196-1-michael@michaelcullen.name Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 9ab5d539bc975b8dcde86eca1b58d836b657732e Author: Miquel Raynal Date: Wed Oct 6 00:16:31 2021 +0200 usb: musb: dsps: Fix the probe error path commit c2115b2b16421d93d4993f3fe4c520e91d6fe801 upstream. Commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after initializing musb") has inverted the calls to dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without updating correctly the error path. dsps_create_musb_pdev() allocates and registers a new platform device which must be unregistered and freed with platform_device_unregister(), and this is missing upon dsps_setup_optional_vbus_irq() error. While on the master branch it seems not to trigger any issue, I observed a kernel crash because of a NULL pointer dereference with a v5.10.70 stable kernel where the patch mentioned above was backported. With this kernel version, -EPROBE_DEFER is returned the first time dsps_setup_optional_vbus_irq() is called which triggers the probe to error out without unregistering the platform device. Unfortunately, on the Beagle Bone Black Wireless, the platform device still living in the system is being used by the USB Ethernet gadget driver, which during the boot phase triggers the crash. My limited knowledge of the musb world prevents me to revert this commit which was sent to silence a robot warning which, as far as I understand, does not make sense. The goal of this patch was to prevent an IRQ to fire before the platform device being registered. I think this cannot ever happen due to the fact that enabling the interrupts is done by the ->enable() callback of the platform musb device, and this platform device must be already registered in order for the core or any other user to use this callback. Hence, I decided to fix the error path, which might prevent future errors on mainline kernels while also fixing older ones. Fixes: 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after initializing musb") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20211005221631.1529448-1-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 278e483dc79311a56304f97585d3dc7db5876282 Author: Zhang Jianhua Date: Thu Sep 23 10:53:40 2021 +0800 efi: Change down_interruptible() in virt_efi_reset_system() to down_trylock() commit 38fa3206bf441911258e5001ac8b6738693f8d82 upstream. While reboot the system by sysrq, the following bug will be occur. BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:90 in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 10052, name: rc.shutdown CPU: 3 PID: 10052 Comm: rc.shutdown Tainted: G W O 5.10.0 #1 Call trace: dump_backtrace+0x0/0x1c8 show_stack+0x18/0x28 dump_stack+0xd0/0x110 ___might_sleep+0x14c/0x160 __might_sleep+0x74/0x88 down_interruptible+0x40/0x118 virt_efi_reset_system+0x3c/0xd0 efi_reboot+0xd4/0x11c machine_restart+0x60/0x9c emergency_restart+0x1c/0x2c sysrq_handle_reboot+0x1c/0x2c __handle_sysrq+0xd0/0x194 write_sysrq_trigger+0xbc/0xe4 proc_reg_write+0xd4/0xf0 vfs_write+0xa8/0x148 ksys_write+0x6c/0xd8 __arm64_sys_write+0x18/0x28 el0_svc_common.constprop.3+0xe4/0x16c do_el0_svc+0x1c/0x2c el0_svc+0x20/0x30 el0_sync_handler+0x80/0x17c el0_sync+0x158/0x180 The reason for this problem is that irq has been disabled in machine_restart() and then it calls down_interruptible() in virt_efi_reset_system(), which would occur sleep in irq context, it is dangerous! Commit 99409b935c9a("locking/semaphore: Add might_sleep() to down_*() family") add might_sleep() in down_interruptible(), so the bug info is here. down_trylock() can solve this problem, cause there is no might_sleep. -------- Cc: Signed-off-by: Zhang Jianhua Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 27a847dbc9627d22f539a027ffab5b3a016c3448 Author: Ard Biesheuvel Date: Wed Sep 1 08:33:19 2021 +0200 efi/cper: use stack buffer for error record decoding commit b3a72ca80351917cc23f9e24c35f3c3979d3c121 upstream. Joe reports that using a statically allocated buffer for converting CPER error records into human readable text is probably a bad idea. Even though we are not aware of any actual issues, a stack buffer is clearly a better choice here anyway, so let's move the buffer into the stack frames of the two functions that refer to it. Cc: Reported-by: Joe Perches Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 6e35a5e9267d4e0adf77393258c7745398ac0dd0 Author: Arnd Bergmann Date: Mon Sep 27 14:13:57 2021 +0200 cb710: avoid NULL pointer subtraction commit 42641042c10c757fe10cc09088cf3f436cec5007 upstream. clang-14 complains about an unusual way of converting a pointer to an integer: drivers/misc/cb710/sgbuf2.c:50:15: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction] return ((ptr - NULL) & 3) != 0; Replace this with a normal cast to uintptr_t. Fixes: 5f5bac8272be ("mmc: Driver for CB710/720 memory card reader (MMC part)") Cc: stable Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210927121408.939246-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit e71ce4a81ed4ee86b44c3f37fce2c7390a248960 Author: Nikolay Martynov Date: Fri Oct 8 12:25:47 2021 +0300 xhci: Enable trust tx length quirk for Fresco FL11 USB controller commit ea0f69d8211963c4b2cc1998b86779a500adb502 upstream. Tested on SD5200T TB3 dock which has Fresco Logic FL1100 USB 3.0 Host Controller. Before this patch streaming video from USB cam made mouse and keyboard connected to the same USB bus unusable. Also video was jerky. With this patch streaming video doesn't have any effect on other periferals and video is smooth. Cc: stable@vger.kernel.org Signed-off-by: Nikolay Martynov Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20211008092547.3996295-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 01c2dcb67e71c351006dd17cbba86c26b7f61eaf Author: Pavankumar Kondeti Date: Fri Oct 8 12:25:46 2021 +0300 xhci: Fix command ring pointer corruption while aborting a command commit ff0e50d3564f33b7f4b35cadeabd951d66cfc570 upstream. The command ring pointer is located at [6:63] bits of the command ring control register (CRCR). All the control bits like command stop, abort are located at [0:3] bits. While aborting a command, we read the CRCR and set the abort bit and write to the CRCR. The read will always give command ring pointer as all zeros. So we essentially write only the control bits. Since we split the 64 bit write into two 32 bit writes, there is a possibility of xHC command ring stopped before the upper dword (all zeros) is written. If that happens, xHC updates the upper dword of its internal command ring pointer with all zeros. Next time, when the command ring is restarted, we see xHC memory access failures. Fix this issue by only writing to the lower dword of CRCR where all control bits are located. Cc: stable@vger.kernel.org Signed-off-by: Pavankumar Kondeti Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20211008092547.3996295-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 7ce7d4a46d6eb29fdc94dae8fb67d1ea2908a3bf Author: Jonathan Bell Date: Fri Oct 8 12:25:43 2021 +0300 xhci: guard accesses to ep_state in xhci_endpoint_reset() commit a01ba2a3378be85538e0183ae5367c1bc1d5aaf3 upstream. See https://github.com/raspberrypi/linux/issues/3981 Two read-modify-write cycles on ep->ep_state are not guarded by xhci->lock. Fix these. Fixes: f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset") Cc: stable@vger.kernel.org Signed-off-by: Jonathan Bell Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20211008092547.3996295-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 783579057c901b03582eccb1039fba8fdaf02a43 Author: Andy Shevchenko Date: Fri Oct 1 20:36:44 2021 +0300 mei: me: add Ice Lake-N device id. commit 75c10c5e7a715550afdd51ef8cfd1d975f48f9e1 upstream. Add Ice Lake-N device ID. The device can be found on MacBookPro16,2 [1]. [1]: https://linux-hardware.org/?probe=f1c5cf0c43 Signed-off-by: Andy Shevchenko Cc: stable Link: https://lore.kernel.org/r/20211001173644.16068-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 9264bd22d7012a6269e73a04bebd31674d9b6641 Author: James Morse Date: Fri Sep 17 16:59:58 2021 +0000 x86/resctrl: Free the ctrlval arrays when domain_setup_mon_state() fails commit 64e87d4bd3201bf8a4685083ee4daf5c0d001452 upstream. domain_add_cpu() is called whenever a CPU is brought online. The earlier call to domain_setup_ctrlval() allocates the control value arrays. If domain_setup_mon_state() fails, the control value arrays are not freed. Add the missing kfree() calls. Fixes: 1bd2a63b4f0de ("x86/intel_rdt/mba_sc: Add initialization support") Fixes: edf6fa1c4a951 ("x86/intel_rdt/cqm: Add RMID (Resource monitoring ID) management") Signed-off-by: James Morse Signed-off-by: Borislav Petkov Acked-by: Reinette Chatre Cc: Link: https://lkml.kernel.org/r/20210917165958.28313-1-james.morse@arm.com Signed-off-by: Greg Kroah-Hartman commit 10b77e16b35bd58794d6b120b6f1534ec3f0e438 Author: Chris Packham Date: Fri Mar 13 16:13:12 2020 +1300 watchdog: orion: use 0 for unset heartbeat commit bb914088bd8a91c382f54d469367b2e5508b5493 upstream. If the heartbeat module param is not specified we would get an error message watchdog: f1020300.watchdog: driver supplied timeout (4294967295) out of range watchdog: f1020300.watchdog: falling back to default timeout (171) This is because we were initialising heartbeat to -1. By removing the initialisation (thus letting the C run time initialise it to 0) we silence the warning message and the default timeout is still used. Signed-off-by: Chris Packham Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20200313031312.1485-1-chris.packham@alliedtelesis.co.nz Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Marek Behún Signed-off-by: Greg Kroah-Hartman commit 9acf1c10f1da058461855b2a42cd2c8662234b7c Author: Filipe Manana Date: Fri Oct 1 13:48:18 2021 +0100 btrfs: check for error when looking up inode during dir entry replay commit cfd312695b71df04c3a2597859ff12c470d1e2e4 upstream. At replay_one_name(), we are treating any error from btrfs_lookup_inode() as if the inode does not exists. Fix this by checking for an error and returning it to the caller. CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 625565fd80ae82d0a7256fca103fde0faada4d14 Author: Filipe Manana Date: Fri Oct 1 13:52:32 2021 +0100 btrfs: deal with errors when adding inode reference during log replay commit 52db77791fe24538c8aa2a183248399715f6b380 upstream. At __inode_add_ref(), we treating any error returned from btrfs_lookup_dir_item() or from btrfs_lookup_dir_index_item() as meaning that there is no existing directory entry in the fs/subvolume tree. This is not correct since we can get errors such as, for example, -EIO when reading extent buffers while searching the fs/subvolume's btree. So fix that and return the error to the caller when it is not -ENOENT. CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 6e2ac49b21eaf84d1f2cac8927eb1bb89d7fe782 Author: Filipe Manana Date: Fri Oct 1 13:52:31 2021 +0100 btrfs: deal with errors when replaying dir entry during log replay commit e15ac6413745e3def00e663de00aea5a717311c1 upstream. At replay_one_one(), we are treating any error returned from btrfs_lookup_dir_item() or from btrfs_lookup_dir_index_item() as meaning that there is no existing directory entry in the fs/subvolume tree. This is not correct since we can get errors such as, for example, -EIO when reading extent buffers while searching the fs/subvolume's btree. So fix that and return the error to the caller when it is not -ENOENT. CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 005a07c9acd6cf8a40555884f0650dfd4ec23fbe Author: Qu Wenruo Date: Tue Sep 14 14:57:59 2021 +0800 btrfs: unlock newly allocated extent buffer after error commit 19ea40dddf1833db868533958ca066f368862211 upstream. [BUG] There is a bug report that injected ENOMEM error could leave a tree block locked while we return to user-space: BTRFS info (device loop0): enabling ssd optimizations FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 0 PID: 7579 Comm: syz-executor Not tainted 5.15.0-rc1 #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 fail_dump lib/fault-inject.c:52 [inline] should_fail+0x13c/0x160 lib/fault-inject.c:146 should_failslab+0x5/0x10 mm/slab_common.c:1328 slab_pre_alloc_hook.constprop.99+0x4e/0xc0 mm/slab.h:494 slab_alloc_node mm/slub.c:3120 [inline] slab_alloc mm/slub.c:3214 [inline] kmem_cache_alloc+0x44/0x280 mm/slub.c:3219 btrfs_alloc_delayed_extent_op fs/btrfs/delayed-ref.h:299 [inline] btrfs_alloc_tree_block+0x38c/0x670 fs/btrfs/extent-tree.c:4833 __btrfs_cow_block+0x16f/0x7d0 fs/btrfs/ctree.c:415 btrfs_cow_block+0x12a/0x300 fs/btrfs/ctree.c:570 btrfs_search_slot+0x6b0/0xee0 fs/btrfs/ctree.c:1768 btrfs_insert_empty_items+0x80/0xf0 fs/btrfs/ctree.c:3905 btrfs_new_inode+0x311/0xa60 fs/btrfs/inode.c:6530 btrfs_create+0x12b/0x270 fs/btrfs/inode.c:6783 lookup_open+0x660/0x780 fs/namei.c:3282 open_last_lookups fs/namei.c:3352 [inline] path_openat+0x465/0xe20 fs/namei.c:3557 do_filp_open+0xe3/0x170 fs/namei.c:3588 do_sys_openat2+0x357/0x4a0 fs/open.c:1200 do_sys_open+0x87/0xd0 fs/open.c:1216 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x46ae99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f46711b9c48 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX: 000000000078c0a0 RCX: 000000000046ae99 RDX: 0000000000000000 RSI: 00000000000000a1 RDI: 0000000020005800 RBP: 00007f46711b9c80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000017 R13: 0000000000000000 R14: 000000000078c0a0 R15: 00007ffc129da6e0 ================================================ WARNING: lock held when returning to user space! 5.15.0-rc1 #16 Not tainted ------------------------------------------------ syz-executor/7579 is leaving the kernel with locks still held! 1 lock held by syz-executor/7579: #0: ffff888104b73da8 (btrfs-tree-01/1){+.+.}-{3:3}, at: __btrfs_tree_lock+0x2e/0x1a0 fs/btrfs/locking.c:112 [CAUSE] In btrfs_alloc_tree_block(), after btrfs_init_new_buffer(), the new extent buffer @buf is locked, but if later operations like adding delayed tree ref fail, we just free @buf without unlocking it, resulting above warning. [FIX] Unlock @buf in out_free_buf: label. Reported-by: Hao Sun Link: https://lore.kernel.org/linux-btrfs/CACkBjsZ9O6Zr0KK1yGn=1rQi6Crh1yeCRdTSBxx9R99L4xdn-Q@mail.gmail.com/ CC: stable@vger.kernel.org # 5.4+ Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit e9f457f056c55aaa3ef15f4ad0fbbf6ef99c0520 Author: Guo Ren Date: Fri Sep 24 15:33:38 2021 +0800 csky: Fixup regs.sr broken in ptrace commit af89ebaa64de726ca0a39bbb0bf0c81a1f43ad50 upstream. gpr_get() return the entire pt_regs (include sr) to userspace, if we don't restore the C bit in gpr_set, it may break the ALU result in that context. So the C flag bit is part of gpr context, that's why riscv totally remove the C bit in the ISA. That makes sr reg clear from userspace to supervisor privilege. Signed-off-by: Guo Ren Cc: Al Viro Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a6f4ea748aa803565ed37d1f5ed8dea422fd027b Author: Al Viro Date: Fri Sep 24 00:35:42 2021 +0000 csky: don't let sigreturn play with priveleged bits of status register commit fbd63c08cdcca5fb1315aca3172b3c9c272cfb4f upstream. csky restore_sigcontext() blindly overwrites regs->sr with the value it finds in sigcontext. Attacker can store whatever they want in there, which includes things like S-bit. Userland shouldn't be able to set that, or anything other than C flag (bit 0). Do the same thing other architectures with protected bits in flags register do - preserve everything that shouldn't be settable in user mode, picking the rest from the value saved is sigcontext. Signed-off-by: Al Viro Signed-off-by: Guo Ren Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 98544ca6cbae8b439b73a429a310dfa66bd58fc4 Author: Roberto Sassu Date: Tue Oct 5 14:08:36 2021 +0200 s390: fix strrchr() implementation commit 8e0ab8e26b72a80e991c66a8abc16e6c856abe3d upstream. Fix two problems found in the strrchr() implementation for s390 architectures: evaluate empty strings (return the string address instead of NULL, if '\0' is passed as second argument); evaluate the first character of non-empty strings (the current implementation stops at the second). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Heiko Carstens (incorrect behavior with empty strings) Signed-off-by: Roberto Sassu Link: https://lore.kernel.org/r/20211005120836.60630-1-roberto.sassu@huawei.com Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 5959e22e0767bc164dd357d2510c90c31f9f8d28 Author: Steven Rostedt Date: Thu Oct 14 14:35:07 2021 -0400 nds32/ftrace: Fix Error: invalid operands (*UND* and *UND* sections) for `^' commit be358af1191b1b2fedebd8f3421cafdc8edacc7d upstream. I received a build failure for a new patch I'm working on the nds32 architecture, and when I went to test it, I couldn't get to my build error, because it failed to build with a bunch of: Error: invalid operands (*UND* and *UND* sections) for `^' issues with various files. Those files were temporary asm files that looked like: kernel/.tmp_mc_fork.s I decided to look deeper, and found that the "mc" portion of that name stood for "mcount", and was created by the recordmcount.pl script. One that I wrote over a decade ago. Once I knew the source of the problem, I was able to investigate it further. The way the recordmcount.pl script works (BTW, there's a C version that simply modifies the ELF object) is by doing an "objdump" on the object file. Looks for all the calls to "mcount", and creates an offset of those locations from some global variable it can use (usually a global function name, found with <.*>:). Creates a asm file that is a table of references to these locations, using the found variable/function. Compiles it and links it back into the original object file. This asm file is called ".tmp_mc_.s". The problem here is that the objdump produced by the nds32 object file, contains things that look like: 0000159a <.L3^B1>: 159a: c6 00 beqz38 $r6, 159a <.L3^B1> 159a: R_NDS32_9_PCREL_RELA .text+0x159e 159c: 84 d2 movi55 $r6, #-14 159e: 80 06 mov55 $r0, $r6 15a0: ec 3c addi10.sp #0x3c Where ".L3^B1 is somehow selected as the "global" variable to index off of. Then the assembly file that holds the mcount locations looks like this: .section __mcount_loc,"a",@progbits .align 2 .long .L3^B1 + -5522 .long .L3^B1 + -5384 .long .L3^B1 + -5270 .long .L3^B1 + -5098 .long .L3^B1 + -4970 .long .L3^B1 + -4758 .long .L3^B1 + -4122 [...] And when it is compiled back to an object to link to the original object, the compile fails on the "^" symbol. Simple solution for now, is to have the perl script ignore using function symbols that have an "^" in the name. Link: https://lkml.kernel.org/r/20211014143507.4ad2c0f7@gandalf.local.home Cc: stable@vger.kernel.org Acked-by: Greentime Hu Fixes: fbf58a52ac088 ("nds32/ftrace: Add RECORD_MCOUNT support") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 2e41b9c8461f2a58f33a22a64bfe7b37d0ec3153 Author: Hui Wang Date: Tue Oct 12 19:47:48 2021 +0800 ALSA: hda/realtek: Fix the mic type detection issue for ASUS G551JW commit a3fd1a986e499a06ac5ef95c3a39aa4611e7444c upstream. We need to define the codec pin 0x1b to be the mic, but somehow the mic doesn't support hot plugging detection, and Windows also has this issue, so we set it to phantom headset-mic. Also the determine_headset_type() often returns the omtp type by a mistake when we plug a ctia headset, this makes the mic can't record sound at all. Because most of the headset are ctia type nowadays and some machines have the fixed ctia type audio jack, it is possible this machine has the fixed ctia jack too. Here we set this mic jack to fixed ctia type, this could avoid the mic type detection mistake and make the ctia headset work stable. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214537 Reported-and-tested-by: msd Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20211012114748.5238-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 90cf96afa34727ba664871a8baa8f94020bc2f08 Author: Kailang Yang Date: Tue Oct 5 14:35:14 2021 +0800 ALSA: hda/realtek - ALC236 headset MIC recording issue commit 5aec98913095ed3b4424ed6c5fdeb6964e9734da upstream. In power save mode, the recording voice from headset mic will 2s more delay. Add this patch will solve this issue. [ minor coding style fix by tiwai ] Signed-off-by: Kailang Yang Tested-by: Kai-Heng Feng Cc: Link: https://lore.kernel.org/r/ccb0cdd5bbd7486eabbd8d987d384cb0@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 33627fa4db3ea7b98606ec334ef3d1d6f67c791a Author: Werner Sembach Date: Fri Oct 1 15:31:11 2021 +0200 ALSA: hda/realtek: Add quirk for Clevo X170KM-G commit cc03069a397005da24f6783835c274d5aedf6043 upstream. This applies a SND_PCI_QUIRK(...) to the Clevo X170KM-G barebone. This fixes the issue of the devices internal Speaker not working. Signed-off-by: Werner Sembach Cc: Link: https://lore.kernel.org/r/20211001133111.428249-3-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e96079ab1c4e4508bb692a7a0e677eb12f0653fe Author: Werner Sembach Date: Fri Oct 1 15:31:10 2021 +0200 ALSA: hda/realtek: Complete partial device name to avoid ambiguity commit 1f8d398e1cd8813f8ec16d55c086e8270a9c18ab upstream. The string "Clevo X170" is not enough to unambiguously identify the correct device. Fixing it so another Clevo barebone name starting with "X170" can be added without causing confusion. Signed-off-by: Werner Sembach Cc: Link: https://lore.kernel.org/r/20211001133111.428249-2-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit dd3f048315232d0ccfb38961905151da7bd75edc Author: Takashi Iwai Date: Thu Sep 30 13:41:14 2021 +0200 ALSA: seq: Fix a potential UAF by wrong private_free call order commit 1f8763c59c4ec6254d629fe77c0a52220bd907aa upstream. John Keeping reported and posted a patch for a potential UAF in rawmidi sequencer destruction: the snd_rawmidi_dev_seq_free() may be called after the associated rawmidi object got already freed. After a deeper look, it turned out that the bug is rather the incorrect private_free call order for a snd_seq_device. The snd_seq_device private_free gets called at the release callback of the sequencer device object, while this was rather expected to be executed at the snd_device call chains that runs at the beginning of the whole card-free procedure. It's been broken since the rewrite of sequencer-device binding (although it hasn't surfaced because the sequencer device release happens usually right along with the card device release). This patch corrects the private_free call to be done in the right place, at snd_seq_device_dev_free(). Fixes: 7c37ae5c625a ("ALSA: seq: Rewrite sequencer device binding with standard bus") Reported-and-tested-by: John Keeping Cc: Link: https://lore.kernel.org/r/20210930114114.8645-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 825786f7232601f95d5bf8ccc68b100e7c2c2c85 Author: Jonas Hahnfeld Date: Tue Oct 12 22:09:07 2021 +0200 ALSA: usb-audio: Add quirk for VF0770 commit 48827e1d6af58f219e89c7ec08dccbca28c7694e upstream. The device advertises 8 formats, but only a rate of 48kHz is honored by the hardware and 24 bits give chopped audio, so only report the one working combination. This fixes out-of-the-box audio experience with PipeWire which otherwise attempts to choose S24_3LE (while PulseAudio defaulted to S16_LE). Signed-off-by: Jonas Hahnfeld Cc: Link: https://lore.kernel.org/r/20211012200906.3492-1-hahnjo@hahnjo.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 43d93325265bc3579625e5936e831f16622a8324 Author: Miklos Szeredi Date: Mon Dec 14 15:26:14 2020 +0100 ovl: simplify file splice commit 82a763e61e2b601309d696d4fa514c77d64ee1be upstream. generic_file_splice_read() and iter_file_splice_write() will call back into f_op->iter_read() and f_op->iter_write() respectively. These already do the real file lookup and cred override. So the code in ovl_splice_read() and ovl_splice_write() is redundant. In addition the ovl_file_accessed() call in ovl_splice_write() is incorrect, though probably harmless. Fix by calling generic_file_splice_read() and iter_file_splice_write() directly. Signed-off-by: Miklos Szeredi [reported to resolve issues with 1a980b8cbf00 ("ovl: add splice file read write helper")] Signed-off-by: Greg Kroah-Hartman