commit 5d86a7f529f5a5559fcb95acd76d62e4758b539f Author: Alexandre Frade Date: Mon Sep 14 22:15:12 2026 +0000 Linux 6.18.52-rt-xanmod1 Signed-off-by: Alexandre Frade commit 936a9302783c8a63e54ee3ae4cd020424e1e7e44 Merge: f3c8448605b9 55053f36aba3 Author: Alexandre Frade Date: Mon Sep 14 22:14:09 2026 +0000 Merge branch '6.18' into 6.18-rt commit 55053f36aba3dbf3146a58b483cdb27ba6353045 Author: Alexandre Frade Date: Mon Sep 14 22:11:26 2026 +0000 Linux 6.18.52-xanmod1 Signed-off-by: Alexandre Frade commit f746e3f18288c6e208e2097b70b706c35f2c70c1 Merge: f2573c2a3326 8f3741e6feb0 Author: Alexandre Frade Date: Mon Sep 14 22:04:14 2026 +0000 Merge tag 'v6.18.52' into 6.18 This is the 6.18.52 stable release commit 8f3741e6feb045da5b406df0a80b42a1adfb289b Author: Greg Kroah-Hartman Date: Mon Sep 14 13:36:19 2026 +0200 Linux 6.18.52 Link: https://lore.kernel.org/r/20260912065623.398859879@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Wentao Guan Tested-by: Barry K. Nathan Tested-by: Ron Economos Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 0d0c637410df620a2626bf8272a5204c1b24823b Author: Arnd Bergmann Date: Fri Jun 12 22:13:19 2026 +0200 wifi: mt76: fix airoha_npu dependency tracking commit 7cd57ff6c6263519e6e463cbc2e0898828a70c42 upstream. There is a new build failure with MT7996E=m MT76_CORE=y and NET_AIROHA_NPU=m: ld.lld: error: undefined symbol: airoha_npu_get ld.lld: error: undefined symbol: airoha_npu_put >>> referenced by npu.c >>> drivers/net/wireless/mediatek/mt76/npu.o:(mt76_npu_init) in archive vmlinux.a Fix this by reworking the dependency for the MT7996_NPU to only allow enabling that when mt76_core can link against the npu driver. To make sure this gets caught more easily in the future when additional mt76 variants need the same dependency, also turn CONFIG_MT76_NPU into a tristate symbol that has the same dependency. Fixes: 7fb554b1b623 ("wifi: mt76: Introduce the NPU generic layer") Acked-by: Lorenzo Bianconi Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260612201519.4054683-1-arnd@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 637e0ea73f690028796ee2fc72a2ac4ec32968c6 Author: Salman Alghamdi Date: Wed May 13 23:34:40 2026 +0300 staging: rtl8723bs: rtw_mlme: add bounds checks before ie_length subtraction commit 88e994c57a79f62d5338231d8d37ee8dd98baffe upstream. Add guards to ensure ie_length is large enough before subtracting fixed IE offsets to prevent unsigned integer underflow. Fixes: 2038fe84b8bd ("staging: rtl8723bs: fix spacing around operators") Fixes: d3fcee1b78a5 ("staging: rtl8723bs: fix camel case in struct wlan_bssid_ex") Closes: https://lore.kernel.org/linux-staging/DI2H39EAAFBZ.3KI5NWN02AQ2S@linux.dev/ Cc: stable Signed-off-by: Salman Alghamdi Reviewed-by: Luka Gejak Link: https://patch.msgid.link/20260513203455.31792-1-me@cipherat.com Signed-off-by: Greg Kroah-Hartman commit 7d4024037ee309a8f0cb86b4093d59da0e135db8 Author: Shyam Sunder Reddy Padira Date: Tue Apr 14 12:43:06 2026 +0530 staging: rtl8723bs: os_dep: avoid NULL pointer dereference in rtw_cbuf_alloc commit bc851db06045a40c18233dd76ef0562d7f8bb6db upstream. The return value of kzalloc_flex() is used without ensuring that the allocation succeeded, and the pointer is dereferenced unconditionally. Guard the access to the allocated structure to avoid a potential NULL pointer dereference if the allocation fails. Fixes: 980cd426a257 ("staging: rtl8723bs: replace rtw_zmalloc() with kzalloc()") Cc: stable Signed-off-by: Shyam Sunder Reddy Padira Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20260414071308.4781-2-shyamsunderreddypadira@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7bca33d6f6e00ea7f9c31bffbfecd4f2713fb2cb Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:40 2026 +0300 pinctrl: airoha: an7583: add missed gpio22 pin group [ Upstream commit 9ef86358855d5fd89db019ace33c097d2d752b9d ] gpio22 pin group is missed, fix it. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 9aa021b63ab7356f442cf0f997955d933b01efa3 Author: Tony W Wang-oc Date: Tue Jun 9 03:03:59 2026 +0800 ACPI: processor: Add cpuidle driver check in acpi_processor_register_idle_driver() [ Upstream commit 66c62e6773c54ce5233eb21c6d48999c3747bd13 ] Commit 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") moved the ACPI idle driver registration to acpi_processor_driver_init(), but it didn't check whether a cpuidle driver was already registered. For example, on Intel platforms, if the intel_idle driver is already loaded, the code would still evaluate the _CST object in the ACPI table and attempt to register the acpi_idle driver. This registration would fail with -EBUSY due to the existing check in cpuidle_register_driver. Add a check at the beginning of acpi_processor_register_idle_driver() to avoid unnecessary _CST evaluate and potential registration failures. Fixes: 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") Signed-off-by: Tony W Wang-oc Link: https://patch.msgid.link/20260608190359.3254-1-TonyWWang-oc@zhaoxin.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4ba887b2bacc84f79d1067cc2d25e4bc9ecba7f5 Author: Huisong Li Date: Wed Mar 11 14:50:38 2026 +0800 ACPI: processor: idle: Remove redundant static variable and rename cstate check function [ Upstream commit 4d613fb1ea0516e1f69d3a4ebfbf2572d5da5368 ] The function acpi_processor_cstate_first_run_checks() is currently called only once during initialization in acpi_processor_register_idle_driver(). Since its execution is already limited by the caller's lifecycle, the internal static 'first_run' variable is redundant and can be safely removed. Additionally, the current function name is no longer descriptive of its behavior, so rename the function to acpi_processor_update_max_cstate() to better reflect its actual purpose. Signed-off-by: Huisong Li Link: https://patch.msgid.link/20260311065038.4151558-4-lihuisong@huawei.com [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Stable-dep-of: 66c62e6773c5 ("ACPI: processor: Add cpuidle driver check in acpi_processor_register_idle_driver()") Signed-off-by: Sasha Levin commit e1cfb85ab258ce05df6ebdf466d597de2f636e4e Author: Huisong Li Date: Wed Mar 11 14:50:37 2026 +0800 ACPI: processor: idle: Move max_cstate update out of the loop [ Upstream commit 1f23194c8b8208bf3a43beb6c97d4c843197b6f6 ] The acpi_processor_cstate_first_run_checks() function, which updates max_cstate on certain platforms, only needs to be executed once. Move this call outside of the loop to avoid redundant executions. Signed-off-by: Huisong Li Link: https://patch.msgid.link/20260311065038.4151558-3-lihuisong@huawei.com Signed-off-by: Rafael J. Wysocki Stable-dep-of: 66c62e6773c5 ("ACPI: processor: Add cpuidle driver check in acpi_processor_register_idle_driver()") Signed-off-by: Sasha Levin commit fcc577939931aa5a25266df80bc19cd033c33142 Author: Huisong Li Date: Wed Mar 11 14:50:36 2026 +0800 ACPI: processor: idle: Remove redundant cstate check in acpi_processor_power_init [ Upstream commit db19103ea847ed139da59a2fb71773081c12cd40 ] The function acpi_processor_cstate_first_run_checks() is responsible for updating max_cstate and performing initial hardware validation. Currently, this function is invoked within acpi_processor_power_init(). However, the initialization flow already ensures this is called during acpi_processor_register_idle_driver(). Therefore, the call in acpi_processor_power_init() is redundant and effectively performs no work, so remove it. Signed-off-by: Huisong Li Link: https://patch.msgid.link/20260311065038.4151558-2-lihuisong@huawei.com [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Stable-dep-of: 66c62e6773c5 ("ACPI: processor: Add cpuidle driver check in acpi_processor_register_idle_driver()") Signed-off-by: Sasha Levin commit 8ddc1da7736443f3eb76104c4495028786373a31 Author: K Prateek Nayak Date: Fri May 8 05:17:45 2026 +0000 cpufreq/amd-pstate: Allow writes to dynamic_epp when state isn't modified [ Upstream commit c5eed6ddc757e477f52b3d99bfde9e59975c72ca ] Writing the current "dynamic_epp" state to sysfs fails with -EINVAL even though the desired result was achieved. Allow writes to "dynamic_epp" that does not modify the state. Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference") Reviewed-by: Mario Limonciello Signed-off-by: K Prateek Nayak Link: https://lore.kernel.org/r/20260508051748.10484-4-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit 9c178eba1542a9c9bc3b6cc6ad3f8602b76e4942 Author: K Prateek Nayak Date: Fri May 8 05:17:47 2026 +0000 cpufreq/amd-pstate: Use "epp_default_dc" as default when dynamic_epp is disabled [ Upstream commit caa822d312be54e3fe1a3b52c887e0888e149c12 ] If "dynamic_epp" is disabled, the driver initialization and the default EPP selection from sysfs currently sets the EPP based on the power supply state of the system at that time but there is no power supply callbacks registered to toggle it when the power supply state changes. This can lead to faster battery drain on platforms that start off while being plugged to the wall but later move to battery power since the EPP stays at AMD_CPPC_EPP_PERFORMANCE. Use "epp_default_dc" as the default EPP selection when dynamic_epp is disabled, restoring older behavior. On servers, this defaults to AMD_CPPC_EPP_PERFORMANCE and on other platforms, it defaults to AMD_CPPC_EPP_BALANCE_PERFORMANCE. Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference") Reviewed-by: Mario Limonciello Signed-off-by: K Prateek Nayak Link: https://lore.kernel.org/r/20260508051748.10484-6-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit bf897a1fa96cb99ec3bd21a57099b88ae73eb43e Author: Mario Limonciello (AMD) Date: Sun Mar 29 15:38:10 2026 -0500 cpufreq/amd-pstate: Add support for raw EPP writes [ Upstream commit 6927f21852f38db2975b5d5539cbe5241c25a99b ] The energy performance preference field of the CPPC request MSR supports values from 0 to 255, but the strings only offer 4 values. The other values are useful for tuning the performance of some workloads. Add support for writing the raw energy performance preference value to the sysfs file. If the last value written was an integer then an integer will be returned. If the last value written was a string then a string will be returned. Reviewed-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello (AMD) Stable-dep-of: caa822d312be ("cpufreq/amd-pstate: Use "epp_default_dc" as default when dynamic_epp is disabled") Signed-off-by: Sasha Levin commit b461ae97f2e4469bb3aae54b7815288b4899042f Author: Mario Limonciello (AMD) Date: Thu Oct 9 11:17:56 2025 -0500 cpufreq/amd-pstate: Add static asserts for EPP indices [ Upstream commit 077f23573d29d063a950e90aa77c8e1f79580147 ] In case a new index is introduced add a static assert to make sure that strings and values are updated. Reviewed-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello (AMD) Stable-dep-of: caa822d312be ("cpufreq/amd-pstate: Use "epp_default_dc" as default when dynamic_epp is disabled") Signed-off-by: Sasha Levin commit 8f8db9af24b9a8933720665fe7a8c20d0f06aa5f Author: Mario Limonciello (AMD) Date: Thu Oct 9 11:17:55 2025 -0500 cpufreq/amd-pstate: Fix some whitespace issues [ Upstream commit e9d62ca86a5525a742742fe69e9aa316cfd4f471 ] Add whitespace around the equals and remove leading space. Reviewed-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello (AMD) Stable-dep-of: caa822d312be ("cpufreq/amd-pstate: Use "epp_default_dc" as default when dynamic_epp is disabled") Signed-off-by: Sasha Levin commit a3d24aed0a3e75ead9d6ebb559d96d8afa1ed66d Author: Jens Axboe Date: Mon Jan 19 19:46:26 2026 -0700 io_uring/waitid: fix KCSAN warning on io_waitid->head [ Upstream commit b994ace83a2bc7699420f6a4c6b860c8da133159 ] Storing of the iw->head entry inside the wait_queue callback, or when removing a waitid item, really should use proper load/store acquire/release semantics, and KCSAN correctly warns of that. Ensure that they do so. Reported-by: syzbot+eb441775f4f948a0902f@syzkaller.appspotmail.com Fixes: a48c0cbf28c0 ("io_uring/waitid: have io_waitid_complete() remove wait queue entry") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 934ffdd1cdef232eb125e63c2ebafb7f2deff6af Author: Jens Axboe Date: Thu Oct 9 10:55:08 2025 -0600 io_uring/waitid: use io_waitid_remove_wq() consistently [ Upstream commit ab673c1bcaf20ac70352eeb6bf5b828462676693 ] Use it everywhere that the wait_queue_entry is removed from the head, and be a bit more cautious in zeroing out iw->head whenever the entry is removed from the list. Signed-off-by: Jens Axboe Stable-dep-of: b994ace83a2b ("io_uring/waitid: fix KCSAN warning on io_waitid->head") Signed-off-by: Sasha Levin commit 798283cd0fe7ba997f67e5a917f14ab40afa8d9f Author: Jamal Hadi Salim Date: Tue Sep 1 17:39:22 2026 -0400 net/sched: fq: clamp quantum and initial_quantum in change path [ Upstream commit 094cc07f98dfe70a34e2a1923af17fd29b8cf622 ] The fq change path accepts TCA_FQ_QUANTUM in [1, INT_MAX] and TCA_FQ_INITIAL_QUANTUM up to INT_MAX, while fq_init() already clamps to [1, 1<<20]. A user can override the init clamp via tc qdisc change, restoring the small-quantum deficit spin that the init clamp prevents. Narrow iq_range.max to 1<<20 so TCA_FQ_INITIAL_QUANTUM is rejected at parse time. Clamp TCA_FQ_QUANTUM to [256, 1<<20] in fq_change() and fq_init() quantum to [256, 1<<20] for tiny-MTU devices. Conditions to recreate the bug: CONFIG_NET_SCH_FQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq tc qdisc change dev dummy0 root fq quantum 1 stab data 32768 size_log 15 cell_log 0 Fixes: 709f34f7c28d ("net/sched: fq: add overflow bounds to quantum and initial quantum") Reported-by: Vega Reviewed-by: Toke Høiland-Jørgensen Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/QDISC-0CFC.v3.20260901204856@mojatatu.com.2 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9289c94fcfe04f374206e69994ce2e45ca258fb8 Author: Arnd Bergmann Date: Thu Apr 2 16:11:15 2026 +0200 Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array [ Upstream commit 81f971c6abec59240e2bcfc38756bda8172fa788 ] When USB support is disabled, the array is not referenced anywhere, causing a warning: drivers/bluetooth/btmtk.c:35:3: error: 'btmtk_mt6639_devs' defined but not used [-Werror=unused-const-variable=] 35 | } btmtk_mt6639_devs[] = { | ^~~~~~~~~~~~~~~~~ Move it into the #ifdef block. Fixes: 28b7c5a6db74 ("Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support") Signed-off-by: Arnd Bergmann Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 2151b2bcf6fcec52665f606eed20da068447f0b7 Author: Pavel Begunkov Date: Fri Sep 4 14:43:07 2026 +0100 tcp: reject non zerocopy devmem tx [ Upstream commit 125755776bc6d4dd53eaf551c87e3d460625d638 ] Devmem tcp tx doesn't work without zero-copy, however it's not currently enforced if NETIF_F_SG isn't present. In this case, tcp_sendmsg_locked() will try the copy path and try to copy data from an iovec which consists of offsets into the dma-buf and would normally fail. Moreover, d9c56501c72fd ("net: tcp: block mixing readable and unreadable frags") relies on that and assumes that the devmem binding is present IFF we're using the zero-copy path, which can be used to mix net-iov and pages in a single skb, and break invariants. Let's reject devmem tx without zero-copy. Note, the parameter check the patch is modifying is too loose, we can create an io_uring request with dmabuf_id and all ZC flags, but which won't have the binding. We replace it with stricter validation. Fixes: bd61848900bff ("net: devmem: Implement TX path") Fixes: d9c56501c72fd ("net: tcp: block mixing readable and unreadable frags") Signed-off-by: Pavel Begunkov Reviewed-by: Mina Almasry Link: https://patch.msgid.link/fdc2478d8f21268d7078556409887d8e6ba0ad32.1788529053.git.asml.silence@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 384907f29dd1e49c5ede45214a8ce0480d7643b9 Author: Kuniyuki Iwashima Date: Sat May 2 18:07:47 2026 +0000 ipmr: Add __rcu to netns_ipv4.mrt. [ Upstream commit a6039776c7994dd0b9a4acce23a3f897d1688cbf ] kernel test robot reported this Sparse warning: $ make C=1 net/ipv4/ipmr.o net/ipv4/ipmr.c:312:24: error: incompatible types in comparison expression (different address spaces): net/ipv4/ipmr.c:312:24: struct mr_table [noderef] __rcu * net/ipv4/ipmr.c:312:24: struct mr_table * Let's add __rcu annotation to netns_ipv4.mrt. Fixes: b3b6babf4751 ("ipmr: Free mr_table after RCU grace period.") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202605030032.glNApko7-lkp@intel.com/ Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260502180755.359554-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7708973e268c4fb09fc91293ad82355308b9be5c Author: Kuniyuki Iwashima Date: Wed May 6 06:59:53 2026 +0000 ipmr: Call ipmr_fib_lookup() under RCU. [ Upstream commit 019c892e46544af0ae94ec833f79aa903c837666 ] Yi Lai reported RCU splat in reg_vif_xmit() below. [0] When CONFIG_IP_MROUTE_MULTIPLE_TABLES=n, ipmr_fib_lookup() uses rcu_dereference() without explicit rcu_read_lock(). Although rcu_read_lock_bh() is already held by the caller __dev_queue_xmit(), lockdep requires explicit rcu_read_lock() for rcu_dereference(). Let's move up rcu_read_lock() in reg_vif_xmit() to cover ipmr_fib_lookup(). [0]: WARNING: suspicious RCU usage 7.1.0-rc2-next-20260504-9d0d467c3572 #1 Not tainted ----------------------------- net/ipv4/ipmr.c:329 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz.2.17/1779: #0: ffffffff87896440 (rcu_read_lock_bh){....}-{1:3}, at: local_bh_disable include/linux/bottom_half.h:20 [inline] #0: ffffffff87896440 (rcu_read_lock_bh){....}-{1:3}, at: rcu_read_lock_bh include/linux/rcupdate.h:891 [inline] #0: ffffffff87896440 (rcu_read_lock_bh){....}-{1:3}, at: __dev_queue_xmit+0x239/0x4140 net/core/dev.c:4792 #1: ffff88801a199d18 (_xmit_PIMREG#2){+...}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline] #1: ffff88801a199d18 (_xmit_PIMREG#2){+...}-{3:3}, at: __netif_tx_lock include/linux/netdevice.h:4795 [inline] #1: ffff88801a199d18 (_xmit_PIMREG#2){+...}-{3:3}, at: __dev_queue_xmit+0x1d5d/0x4140 net/core/dev.c:4865 stack backtrace: CPU: 1 UID: 0 PID: 1779 Comm: syz.2.17 Not tainted 7.1.0-rc2-next-20260504-9d0d467c3572 #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x121/0x150 lib/dump_stack.c:120 dump_stack+0x19/0x20 lib/dump_stack.c:129 lockdep_rcu_suspicious+0x15b/0x1f0 kernel/locking/lockdep.c:6878 ipmr_fib_lookup net/ipv4/ipmr.c:329 [inline] reg_vif_xmit+0x2ee/0x3c0 net/ipv4/ipmr.c:540 __netdev_start_xmit include/linux/netdevice.h:5382 [inline] netdev_start_xmit include/linux/netdevice.h:5391 [inline] xmit_one net/core/dev.c:3889 [inline] dev_hard_start_xmit+0x170/0x700 net/core/dev.c:3905 __dev_queue_xmit+0x1df1/0x4140 net/core/dev.c:4871 dev_queue_xmit include/linux/netdevice.h:3423 [inline] packet_xmit+0x252/0x370 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3082 [inline] packet_sendmsg+0x39ad/0x5650 net/packet/af_packet.c:3114 sock_sendmsg_nosec net/socket.c:797 [inline] __sock_sendmsg net/socket.c:812 [inline] ____sys_sendmsg+0xa21/0xba0 net/socket.c:2716 ___sys_sendmsg+0x121/0x1c0 net/socket.c:2770 __sys_sendmsg+0x177/0x220 net/socket.c:2802 __do_sys_sendmsg net/socket.c:2807 [inline] __se_sys_sendmsg net/socket.c:2805 [inline] __x64_sys_sendmsg+0x80/0xc0 net/socket.c:2805 x64_sys_call+0x1d9c/0x21c0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc1/0x1020 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f37e563ee5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d 93 af 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe5caa7fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00000000005c5fa0 RCX: 00007f37e563ee5d RDX: 0000000000000000 RSI: 00002000000012c0 RDI: 0000000000000004 RBP: 00000000005c5fa0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000005c5fac R15: 00000000005c5fa0 Fixes: b3b6babf4751 ("ipmr: Free mr_table after RCU grace period.") Reported-by: syzkaller Reported-by: Yi Lai Closes: https://lore.kernel.org/netdev/afrY34dLXNUboevf@ly-workstation/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260506065955.1695753-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5029156b99bd92d9230f47ff8101b5309b0dfc2d Author: Zhan Xusheng Date: Mon Jun 1 16:51:36 2026 +0800 erofs: fix EFSCORRUPTED on multi-algorithm images in z_erofs_map_sanity_check() [ Upstream commit 27f2d085bd72abe4235689d34d8654cfc876d568 ] Commit a5242d37c83a ("erofs: error out obviously illegal extents in advance") changed the per-extent algorithm presence check from "is the bit set" to "is the only bit set": - !(sbi->available_compr_algs & (1 << map->m_algorithmformat)) + (sbi->available_compr_algs ^ BIT(map->m_algorithmformat)) `available_compr_algs` is a bitmap of every compression algorithm available in the image (z_erofs_parse_cfgs() iterates it with for_each_set_bit()), so an image that enables more than one algorithm has multiple bits set. XOR is zero only when the bitmap is exactly BIT(map->m_algorithmformat); for any image with two or more algorithms the test is non-zero for every extent and the read fails with -EFSCORRUPTED ("inconsistent algorithmtype %u"). Reproducer (mkfs.erofs from erofs-utils 1.7.1): $ mkdir src $ yes A | head -c 100K > src/a $ head -c 64K /dev/zero > src/b $ mkfs.erofs -zlz4:deflate multi.erofs src $ mount -t erofs -o loop multi.erofs /mnt $ cat /mnt/a >/dev/null cat: /mnt/a: Structure needs cleaning $ dmesg | tail erofs (device loop0): inconsistent algorithmtype 0 for nid 46 erofs (device loop0): read error -117 @ 0 of nid 46 The erofs on-disk format (Z_EROFS_COMPRESSION_MAX = 4 with LZ4, LZMA, DEFLATE, ZSTD) and the kernel parser explicitly support multi-algorithm images, and erofs-utils 1.7.1 generates them via the "-z X:Y" syntax. Restore the original per-bit presence check. Fixes: a5242d37c83a ("erofs: error out obviously illegal extents in advance") Signed-off-by: Zhan Xusheng Reviewed-by: Gao Xiang Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit a295f239dee45ae5df025c2fc7f0702004748758 Author: Gao Xiang Date: Wed Jul 8 11:18:45 2026 +0800 erofs: relax sanity check for tail pclusters due to ztailpacking [ Upstream commit d3386e17393bec1341cfeedb9d08d6846ccd6fb2 ] If the tail data can be inlined into the inode meta block, it should be converted into a regular tail pcluster. In principle, it should be converted into an uncompressed pcluster if there is not enough gain to use compression (map->m_llen < map->m_plen); but since there are various shipped images, relax the condition for ztailpacking tail pcluster fallback instead of reporting corruption incorrectly. Reported-and-tested-by: Yifan Zhao Reported-by: Alberto Salvia Novella Closes: https://github.com/erofs/erofs-utils/issues/51 Fixes: a5242d37c83a ("erofs: error out obviously illegal extents in advance") Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit bf8601feeb469f517054efa274ba39c1c811b244 Author: Keith Busch Date: Tue Nov 11 06:06:20 2025 -0800 block: fix merging data-less bios [ Upstream commit fd9ecd005252b595fd02ff7fcc4056251027404d ] The data segment gaps the block layer tracks doesn't apply to bio's that don't have data. Skip calculating this to fix a NULL pointer access. Fixes: 2f6b2565d43cdb5 ("block: accumulate memory segment gaps per bio") Reported-by: Matthew Wilcox Signed-off-by: Keith Busch Reviewed-by: Yu Kuai Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 43a4c2afcb5ab7a0d5bf80c792c318853bebe83c Author: Keith Busch Date: Wed Dec 10 02:43:46 2025 -0800 blk-mq-dma: always initialize dma state [ Upstream commit a0750fae73c55112ea11a4867bee40f11e679405 ] Ensure the dma state is initialized when we're not using the contiguous iova, otherwise the caller may be using a stale state from a previous request that could use the coalesed iova allocation. Fixes: 2f6b2565d43cdb5 ("block: accumulate memory segment gaps per bio") Reported-by: Sebastian Ott Tested-by: Sebastian Ott Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f54f709bfb5e47782e6bb7ef4b19c889a60f6e9b Author: Keith Busch Date: Wed Aug 19 08:49:37 2026 -0700 block: save page offset gaps in cloned bio [ Upstream commit 96c8ea3c5add7920b3c43840d1ea76b3354c8d2d ] The cloned bio needs to inherit the accumulated gaps between vectors so that we can know if this bio can subscribe to the iova coalescing optimization. When cloning for a split, the gap only applies to the front bio since that's as far as has been processed. The remaining bio can reset its gaps to 0 since it advanced past the checked vectors, and will start its accounting from there on the next split check. Fixes: 2f6b2565d43c ("block: accumulate memory segment gaps per bio") Reported-by: Eric Auger Tested-by: Eric Auger Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260819154937.3903312-1-kbusch@meta.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0268313b5de3ece197efc155840eb43dbed018a7 Author: Nathan Chancellor Date: Mon Mar 9 13:37:02 2026 -0700 integrity: Eliminate weak definition of arch_get_secureboot() [ Upstream commit 7caedbb5ade345df0eec0bf01035c780919a9f56 ] security/integrity/secure_boot.c contains a single __weak function, which breaks recordmcount when building with clang: $ make -skj"$(nproc)" ARCH=powerpc LLVM=1 ppc64_defconfig security/integrity/secure_boot.o Cannot find symbol for section 2: .text. security/integrity/secure_boot.o: failed Introduce a Kconfig symbol, CONFIG_HAVE_ARCH_GET_SECUREBOOT, to indicate that an architecture provides a definition of arch_get_secureboot(). Provide a static inline stub when this symbol is not defined to achieve the same effect as the __weak function, allowing secure_boot.c to be removed altogether. Move the s390 definition of arch_get_secureboot() out of the CONFIG_KEXEC_FILE block to ensure it is always available, as it does not actually depend on KEXEC_FILE. Reported-by: Arnd Bergmann Fixes: 31a6a07eefeb ("integrity: Make arch_ima_get_secureboot integrity-wide") Signed-off-by: Nathan Chancellor Acked-by: Arnd Bergmann Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 60aee9cbb82e0bff4407c1f5a702164dfdd13c9d Author: John Johansen Date: Mon Feb 2 03:37:18 2026 -0800 apparmor: fix kernel-doc comments for inview [ Upstream commit 3734b9463bd4fb5ac350842db55e2e0ccbf1b7a5 ] subns was renamed inview to better reflect the function of the flag. Unfortunately the kernel-doc was not properly updated in 2 places. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202602020737.vGCZFds1-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202602021427.PvvDjgyL-lkp@intel.com/ Fixes: 796c146fa6c82 ("apparmor: split xxx_in_ns into its two separate semantic use cases") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit caf1e44e672b5c8751f7fbef1708204771d9bb8e Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:36 2026 +0300 pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin function [ Upstream commit e20c85c79cc2f45b87eb3dab38d4c641bbf83ed6 ] phy4_led1 pin function maps led incorrectly. It uses the same map as phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1). Fixes: 579839c9548c ("pinctrl: airoha: convert PHY LED GPIO to macro") Signed-off-by: Mikhail Kshevetskiy Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 0ca274a45eaead8284fb86ebc1782b4488cfd072 Author: Nathan Chancellor Date: Wed Nov 12 11:44:30 2025 -0700 pinctrl: airoha: Fix AIROHA_PINCTRL_CONFS_DRIVE_E2 in an7583_pinctrl_match_data [ Upstream commit 0341d1b1ebf10bcbb9f35e174e83dbb21068387d ] Clang warns (or errors with CONFIG_WERROR=y / W=e): pinctrl/mediatek/pinctrl-airoha.c:2064:41: error: variable 'an7583_pinctrl_drive_e2_conf' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration] 2064 | static const struct airoha_pinctrl_conf an7583_pinctrl_drive_e2_conf[] = { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ Due to a typo, an7583_pinctrl_drive_e2_conf is only used within ARRAY_SIZE() (hence no instance of -Wunused-variable), which is evaluated at compile time, so it will not be needed in the final object file. Fix the .confs assignment for AIROHA_PINCTRL_CONFS_DRIVE_E2 in an7583_pinctrl_match_data to clear up the warning. Closes: https://github.com/ClangBuiltLinux/linux/issues/2142 Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Nathan Chancellor Acked-by: Christian Marangi Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2e7c3c433fd791b95bc2264cab3c27f34e3b88b9 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:33 2026 +0300 pinctrl: airoha: an7583: add missed gpio32 pin group [ Upstream commit 81cc2285cea84e3ed8688d353e1250cf8899c80a ] gpio32 pin group is missed for an7583 SoC. This patch add it. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 46bae3189cf5c4e37d72a542a717c52b579638c4 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:35 2026 +0300 pinctrl: airoha: an7583: fix misprint in gpio19 pinconf [ Upstream commit a7f3e2b7730fc1d6c7431af49e0dc1ee97589795 ] Pin 21 (gpio19) duplicate pinconf settings of pin 20. Fix it using a proper bit number in the configuration register. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 591424f9f5d51acde3ec478ea6c80ad20c6cec87 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:37 2026 +0300 pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin function [ Upstream commit a3602577fdfc49c6dc08d67304426d5ef6d7dec6 ] phy4_led1 pin function maps led incorrectly. It uses the same map as phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1). Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Reviewed-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit cf2e698957b65038ed0bfd27b95aa7baff3d3703 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:39 2026 +0300 pinctrl: airoha: an7583: fix gpio21 pin group [ Upstream commit abf92c45cc82e9a01aa581f9fbc790e78250a4d4 ] gpio21 pin group refers to gpio22 pin, this is wrong. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6d0bcb2153128976038b61220a3297c80d273b22 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:41 2026 +0300 pinctrl: airoha: an7583: fix phy1_led1 pin function [ Upstream commit dbe28a2a22a3455d1adbf9fd61d3537603ac3072 ] phy1_led1 pin function wrongly refers to gpio1 instead of gpio11. Fix it. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5331bf0d5ca05e1d79386e41aeb9622e1a6cadf8 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:42 2026 +0300 pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin function [ Upstream commit 7b87a686a5ab138b3f8ca3d7e3489d8371c02695 ] pcm_spi_int, pcm_spi_cs2, pcm_spi_cs3, pcm_spi_cs4 pin groups are not defined, so pcm_spi function can't be applied to these groups. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fc00a596268a0c2f4ea955a594fd47908039bdf5 Author: Arnd Bergmann Date: Mon Feb 2 10:51:14 2026 +0100 phy: renesas: rcar-gen3-usb2: add regulator dependency [ Upstream commit 3a03a0e47cf2e0ec7ce7ca9e0bf4c59ec537ad09 ] The driver start registering a regulator, but can still be enabled even when it is unable to call into the regulator subsystem: aarch64-linux-ld: drivers/phy/renesas/phy-rcar-gen3-usb2.o: in function `rcar_gen3_phy_usb2_probe': phy-rcar-gen3-usb2.c:(.text+0x2884): undefined reference to `devm_regulator_register' Add a Kconfig dependency to avoid this configuration. Fixes: b6d7dd157763 ("phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control") Signed-off-by: Arnd Bergmann Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260202095118.1233046-1-arnd@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit e97bd4417010c648acf9b1e509cfb77fc506e09e Author: Namhyung Kim Date: Tue Oct 21 12:07:50 2025 +0900 perf annotate: Fix build with NO_SLANG=1 [ Upstream commit 0e6c07a3c30cdc4509fc5e7dc490d4cc6e5c241a ] The recent change for perf c2c annotate broke build without slang support like below. builtin-annotate.c: In function 'hists__find_annotations': builtin-annotate.c:522:73: error: 'NO_ADDR' undeclared (first use in this function); did you mean 'NR_ADDR'? 522 | key = hist_entry__tui_annotate(he, evsel, NULL, NO_ADDR); | ^~~~~~~ | NR_ADDR builtin-annotate.c:522:73: note: each undeclared identifier is reported only once for each function it appears in builtin-annotate.c:522:31: error: too many arguments to function 'hist_entry__tui_annotate' 522 | key = hist_entry__tui_annotate(he, evsel, NULL, NO_ADDR); | ^~~~~~~~~~~~~~~~~~~~~~~~ In file included from util/sort.h:6, from builtin-annotate.c:28: util/hist.h:756:19: note: declared here 756 | static inline int hist_entry__tui_annotate(struct hist_entry *he __maybe_unused, | ^~~~~~~~~~~~~~~~~~~~~~~~ And I noticed that it missed to update the other side of #ifdef HAVE_SLANG_SUPPORT. Let's fix it. Cc: Tianyou Li Fixes: cd3466cd2639783d ("perf c2c: Add annotation support to perf c2c report") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit fe44ae31ca78a4185995a514bd01833c6a04014b Author: Johannes Berg Date: Tue Mar 3 15:16:15 2026 +0100 wifi: nl80211: fix UHR capability validation [ Upstream commit a140826caa2c14aa5a9a6990e514c5edbdb7eafd ] The ieee80211_uhr_capa_size_ok() function returns a boolean, but we need an error code here. Fix that. Fixes: 072e6f7f416f ("wifi: cfg80211: add initial UHR support") Cc: # no drivers with UHR yet Link: https://patch.msgid.link/20260303151614.e87ea9995be5.Ie164040a51855a3e548f05f0d0291d7d7993c7ee@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 3ca32b70e825f43d664511d09e72fe485563ed9c Author: Lorenzo Bianconi Date: Thu Jan 22 11:39:46 2026 +0100 wifi: mt76: npu: Add missing rx_token_size initialization [ Upstream commit 25e3203a2192f2b0d697b2410126bad87e62d4f0 ] Add missing rx_token_size initialization for NPU offloading. Fixes: 7fb554b1b623 ("wifi: mt76: Introduce the NPU generic layer") Tested-by: Kang Yang Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260122-mt76-npu-eagle-offload-v2-2-2374614c0de6@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b0af766d64bc2b9ff8efb8b221d3e94cf31eded4 Author: Devin Wittmayer Date: Mon Jul 20 16:27:36 2026 -0700 wifi: mt76: restrict NPU/PPE active checks to MMIO devices [ Upstream commit 7981aca2bd28a1f7ad7eeab89715442a95b1f72e ] mt76_npu_device_active() and mt76_ppe_device_active() read dev->mmio.npu and dev->mmio.ppe_dev. The mmio, usb and sdio bus structs share a union in struct mt76_dev, so on USB and SDIO these read unrelated data from the usb/sdio struct, which is non-NULL in practice. mt76_npu_device_active() then returns true on USB, and mt76_rx_poll_complete() takes the offload path and skips mt76_rx_aggr_reorder(). RX A-MPDU subframes are delivered out of order and the peer's TCP stack treats that as loss: heavy retransmissions and reduced throughput in AP mode. Seen on mt7921u, mt7925u, mt76x2u and mt76x0u. Gate both helpers on mt76_is_mmio() so they only run for the bus type that owns the mmio union member. Fixes: 7fb554b1b623 ("wifi: mt76: Introduce the NPU generic layer") Cc: stable@vger.kernel.org Tested-by: Nick Morrow Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260720232640.41293-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 15a9acc5e6553b548758c2fc749e66d14184cb77 Author: Vasily Gorbik Date: Mon Feb 23 23:33:52 2026 +0100 s390/kexec: Disable stack protector in s390_reset_system() [ Upstream commit 1623a554c68f352c17d0a358bc62580dc187f06b ] s390_reset_system() calls set_prefix(0), which switches back to the absolute lowcore. At that point the stack protector canary no longer matches the canary from the lowcore the function was entered with, so the stack check fails. Mark s390_reset_system() __no_stack_protector. This is safe here since its callers (__do_machine_kdump() and __do_machine_kexec()) are effectively no-return and fall back to disabled_wait() on failure. Fixes: f5730d44e05e ("s390: Add stackprotector support") Reported-by: Nikita Dubrovskii Reviewed-by: Heiko Carstens Acked-by: Alexander Gordeev Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit adf8f940e450dea8c64f47317b5048f8c9492e72 Author: Thomas Weißschuh Date: Thu Jan 15 14:56:52 2026 +0100 selftests: vDSO: getrandom: Fix path to s390 chacha implementation [ Upstream commit d045e166d3c51b7aec069669bb243e057d80d04f ] The s390 vDSO source directory was recently moved, but this reference was not updated. Fixes: c0087d807ae8 ("s390/vdso: Rename vdso64 to vdso") Signed-off-by: Thomas Weißschuh Acked-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit dffea40a832bb56c49c54b157743640604d4b0d4 Author: Mario Limonciello (AMD) Date: Sat May 30 17:04:34 2026 +0200 cpufreq/amd-pstate: Fix setting EPP in performance mode [ Upstream commit 5629eec1a2829871d496f3042884cdc267612f6a ] EPP 0 is the only supported value in the performance policy. commit 798c47593cca ("cpufreq/amd-pstate: Add support for platform profile class") changed this while adding platform profile support to the dynamic EPP feature, but this actually wasn't necessary since platform profile writes disable manual EPP writes. Restore allowing writing EPP of 0 when in performance mode. Reviewed-by: Marco Scardovi Tested-by: Marco Scardovi Reported-by: Stuart Meckle Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221473 Closes: https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/work_items/190 Fixes: 798c47593cca ("cpufreq/amd-pstate: Add support for platform profile class") Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit 3b4b39f8bfb9bfb13fc86b083e1f53d65d108374 Author: Mario Limonciello Date: Tue Apr 7 14:49:49 2026 -0500 cpufreq/amd-pstate: Add POWER_SUPPLY select for dynamic EPP [ Upstream commit 679343977588781bd3effba79e9644aee4ee046c ] The dynamic EPP feature uses power_supply_reg_notifier() and power_supply_unreg_notifier() but doesn't declare a dependency on POWER_SUPPLY, causing linker errors when POWER_SUPPLY is not enabled. Add POWER_SUPPLY to the selects. Suggested-by: K Prateek Nayak Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202604040742.ySEdkuAa-lkp@intel.com/ Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260407194949.310114-1-mario.limonciello@amd.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c6584e98b60ee64bc3e8b2739b2ef101ea5f4bc1 Author: K Prateek Nayak Date: Fri May 8 05:17:43 2026 +0000 cpufreq/amd-pstate: Grab "amd_pstate_driver_lock" when toggling dynamic_epp [ Upstream commit 9228169d2ae055ed09a163887fc59a710a5eb73b ] Concurrently changing driver mode and dynamic_epp with: echo passive > /sys/devices/system/cpu/amd_pstate/status& echo disable > /sys/devices/system/cpu/amd_pstate/dynamic_epp& hits the WARN_ON_ONCE() in static_key_disable_cpuslocked() and hangs the system since both sysfs writes are trying to do amd_pstate_change_driver_mode() without any synchronization. Grab the "amd_pstate_driver_lock" mutex when modifying "dynamic_epp" to prevent the two paths from racing with each other. Add a lockdep assertion for "amd_pstate_driver_lock" in amd_pstate_change_driver_mode() to formalize the dependency. Since "cppc_mode" is stable under "amd_pstate_driver_lock", only reload the driver when in "AMD_PSTATE_ACTIVE" mode and reject all writes when in passive or guided mode, or if the driver is not loaded, since only active mode operates on EPP. Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference") Reviewed-by: Mario Limonciello Signed-off-by: K Prateek Nayak Link: https://lore.kernel.org/r/20260508051748.10484-2-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit eee67e91751e093ed51da6ec5e737151c777af91 Author: K Prateek Nayak Date: Fri May 8 05:17:44 2026 +0000 cpufreq/amd-pstate: Return -ENOMEM on failure to allocate profile_name [ Upstream commit 87d2a8dec0f02b200eb3527da0ab11ba4d4e7deb ] Failure to allocate profile name will return -EINVAL from platform_profile_register() while in fact, it is a failure to allocate memory for the profile_name string. Return -ENOMEM when kasprintf() fails to allocate profile_name string. Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference") Reviewed-by: Mario Limonciello Signed-off-by: K Prateek Nayak Link: https://lore.kernel.org/r/20260508051748.10484-3-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit c9d79e27eaefb3ffe088029b1b1b123934518bf8 Author: K Prateek Nayak Date: Fri May 8 05:17:46 2026 +0000 cpufreq/amd-pstate: Reorder notifier unregistration and floor perf reset [ Upstream commit f3acf7ff113007557538b278ccb0e4ab7ae513ea ] An active power supply notifier can race with amd_pstate_epp_cpu_exit() trying to reset the floor perf and can overwrite the floor perf set in MSR_AMD_CPPC_REQ. Unregister the notifier before setting the floor perf to prevent the rare race. Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference") Reviewed-by: Mario Limonciello Signed-off-by: K Prateek Nayak Link: https://lore.kernel.org/r/20260508051748.10484-5-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit 70c8c8b50d80f681f50ddcc66a9400dd87508913 Author: EDAMAMEX Date: Wed May 20 16:02:11 2026 +0900 cpufreq/amd-pstate: handle missing policy in dynamic EPP callbacks [ Upstream commit 39c0cf62fc7851a17782e7efe8dfb2948739c681 ] cpufreq_cpu_get() returns NULL when no cpufreq policy is associated with the requested CPU, for example because the CPU is offline or the policy has already been torn down. Both amd_pstate_power_supply_notifier() and amd_pstate_profile_set() acquire a policy via cpufreq_cpu_get() and then pass that pointer to amd_pstate_get_balanced_epp() and amd_pstate_set_epp(), which dereference it unconditionally. A racing CPU hotplug or driver teardown can therefore lead to a NULL pointer dereference on either of these dynamic EPP paths. The third cpufreq_cpu_get() caller in this file, amd_pstate_verify(), already handles the NULL case. Bring the two new callers in line with that pattern: return NOTIFY_OK from the power-supply notifier (matching the other "nothing to do" exits) and -ENODEV from amd_pstate_profile_set() (the usual cpufreq error for a missing CPU policy). Found by code inspection; not tested on hardware. Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference") Fixes: 798c47593cca ("cpufreq/amd-pstate: Add support for platform profile class") Signed-off-by: EDAMAMEX Link: https://lore.kernel.org/r/20260520070211.2753183-1-edame8080@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit be5d0964da97f69e1279eec0ac1fb78004164f95 Author: Arnd Bergmann Date: Thu Jun 18 16:33:14 2026 +0200 usb: ucsi: huawei_gaokun: move typec_altmode off stack [ Upstream commit c7eaea5c6eeb391d445583fa6419c957ca74a86b ] The typec_altmode structure contains a 'struct device' object that cannot be allocated on the stack because of its size, even when ignoring the lifetime rules: drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c:326:13: error: stack frame size (1456) exceeds limit (1280) in 'gaokun_ucsi_usb_notify_ind' [-Werror,-Wframe-larger-than] 326 | static void gaokun_ucsi_usb_notify_ind(struct gaokun_ucsi *uec) Since the altmode is always associated with a port here, move it into the port object and avoid at least the stack allocation issue. Fixes: 1c2b66a7d725 ("usb: ucsi: huawei_gaokun: support mode switching") Signed-off-by: Arnd Bergmann Reviewed-by: Pengyu Luo Link: https://patch.msgid.link/20260618143341.1900221-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 65d97c3d9060faa6b623b49203afe94f53f27c29 Author: John Ogness Date: Tue Jul 7 16:16:04 2026 +0206 serial: 8250: Ignore flow control on suspend/resume with no_console_suspend [ Upstream commit 302fbbb4fcbdeac2dc8c63a56c1c4e38c4781958 ] If no_console_suspend is specified, on suspend the 8250 console driver uses a scratch register (UART_SCR) to store a special canary value. This is used during the resume path to identify a printk() call before the driver's own ->resume() callback. In this case, serial8250_console_restore() is called to quickly re-init the 8250 for console printing. See commit 4516d50aabed ("serial: 8250: Use canary to restart console after suspend") for the original motivation. Unfortunately, this canary workaround does not work in all cases (such as suspend to mem) because the scratch register will not reset. This has not been a real issue until now because it could simply lead to some garbage characters upon resume. However, with the introduction of console flow control it becomes a real problem because a failed suspend/resume detection when flow control is enabled leads to all characters hitting the flow control timeout. Workaround this issue by temporarily ignoring console flow control when the debug canary suspend/resume detection is active. Fixes: 5e6dfb87b191 ("serial: 8250: Add support for console flow control") Signed-off-by: John Ogness Link: https://patch.msgid.link/20260707141032.5074-1-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a79848859b1a82937ced219e7507f4e7889af751 Author: Rafael J. Wysocki Date: Tue May 12 16:12:27 2026 +0200 platform/x86: lg-laptop: Check ACPI_COMPANION() against NULL [ Upstream commit 7e169326c2263ebc4878baae536c956fa3118eff ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the platform/x86 lg-laptop driver. Fixes: 2d9cb20610f7 ("platform/x86: lg-laptop: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/3706551.iIbC2pHGDl@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit bd8946ddbe9a327c14b1f5c0b1ce2e878b871944 Author: Ian Rogers Date: Thu Dec 4 14:55:21 2025 -0800 perf tests kvm: Avoid leaving perf.data.guest file around [ Upstream commit b3d1dcd02c8cc1da723c1e9a6b74849ed94b6d30 ] Ensure the perf.data output when checking permissions is written to /dev/null so that it isn't left in the directory the test is run. Fixes: b58261584d2f ("perf test kvm: Add some basic perf kvm test coverage") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 3641a3aed2ecc3f447ba92e1891ae867f8810a2f Author: Steven Rostedt Date: Mon Feb 9 19:46:31 2026 -0500 tracing: Move d_max_latency out of CONFIG_FSNOTIFY protection [ Upstream commit b4bade506b18eb2e5e34ac84f915d7ee6156d4e2 ] The tracing_max_latency shouldn't be limited if CONFIG_FSNOTIFY is defined or not and it was moved out of that protection to be always available with CONFIG_TRACER_MAX_TRACE. All was moved out except the dentry descriptor for it (d_max_latency) and it failed to build on some configs. Move that out of the CONFIG_FSNOTIFY protection too. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260209194631.788bfc85@fedora Fixes: ba73713da50e ("tracing: Clean up use of trace_create_maxlat_file()") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202602092133.fTdojd95-lkp@intel.com/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 3e3fb150abad9b9e74b9692089e93823126aa936 Author: Miquel Raynal (DAVE) Date: Fri May 29 18:29:58 2026 +0200 mtd: rawnand: pl353: Fix debug prints [ Upstream commit 2b7baaddf1bc3e39206a0354449fdc349945b86b ] They are partially incorrect since "software" engine does not mean hamming, the "none" cae is also falling into this print, and on-die means there is some kind of hardware support; we prefer to use the wording on-host vs. on-die. Fix all those prints. Fixes: 1e06dbfdfb85 ("mtd: rawnand: pl353: Add message about ECC mode") Signed-off-by: Miquel Raynal (DAVE) Acked-by: Michal Simek Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 9988c1c9e0d1c78391e3d8e2817beb667470c76f Author: Ben Cressey Date: Thu Aug 20 21:44:57 2026 +0000 dm-integrity: fix buffer overflow with keyed discard commit 59e6f919d77d72ec79cbf171256f2f7819737580 upstream. Since commit 68c5c42567bc ("dm-integrity: replace forgeable discard filler with a keyed sector marker"), integrity_metadata computes a checksum for every discarded block into the "checksums" buffer. integrity_sector_checksum always writes the whole digest. So if the tag size is smaller than the digest size, the checksum of the last block that fits into the buffer is written past the end of it. For example, with hmac(sha256) and tag size 16, a 4MiB discard writes 16 bytes past the kmalloc'ed page. Fix this by subtracting extra_space from the buffer size when computing max_blocks, like we do for writes. Fixes: 68c5c42567bc ("dm-integrity: replace forgeable discard filler with a keyed sector marker") Reviewed-by: Jose Fernandez (Anthropic) Signed-off-by: Ben Cressey Assisted-by: Claude:unspecified Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit e54be9aa503a0297b63aec530fbf760350effd45 Author: Jamal Hadi Salim Date: Wed Aug 26 11:33:39 2026 -0300 net/sched: sch_htb: limit htb_classify inner-class filter hops [ Upstream commit 729c4896ab829169f95915d65edd530325910b37 ] htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent. The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification. htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Vega Co-developed-by: Victor Nogueira Signed-off-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260826143339.271935-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b8f08a94b2a4addc39249dcf9c792e786108621b Author: Jiayuan Chen Date: Wed Aug 26 22:11:26 2026 +0800 tcp: fix corruption of urgent data on multi-segment retransmit [ Upstream commit ce2b807f42ed5e55567b8864ab72963f90779270 ] On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: /* tcp_write_xmit() */ limit = mss_now; if (tso_segs > 1 && !tcp_urg_mode(tp)) limit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: /* __tcp_retransmit_skb() */ len = cur_mss * segs; /* segs > 1, no urg_mode check */ ... /* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: seg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) seg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) seg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode. Fixes: 10d3be569243 ("tcp-tso: do not split TSO packets at retransmit time") Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260826141145.67823-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ff7f77a234f7b74e5955a6e34fa74eca4c9ca44c Author: Deepanshu Kartikey Date: Wed Aug 26 19:02:58 2026 +0530 usb: atm: usbatm: fix invalid ci_range initialization [ Upstream commit a60fd8c6dbaa76da4163cf225ed2b9e982540f39 ] syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci. Fixes: c59bba75fa50 ("[PATCH] USB ATM: new usbatm core") Reported-by: syzbot+6665d3db5fef15914802@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6665d3db5fef15914802 Suggested-by: Eric Dumazet Link: https://lore.kernel.org/all/20260824024620.23485-1-kartikey406@gmail.com/T/ [v1] Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260826133258.8306-1-kartikey406@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1f9639caeece703012bdb23975ebedf70f426269 Author: bui duc phuc Date: Wed Aug 26 17:34:28 2026 +0700 net: fec: only stop PTP if it was initialized [ Upstream commit dd890ae29299636fb037276fc1b5238698d08b03 ] fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized. Fixes: 32cba57ba74b ("net: fec: introduce fec_ptp_stop and use in probe fail path") Reviewed-by: Wei Fang Reviewed-by: Frank Li Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260826103428.32807-1-phucduc.bui@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ddbc5dc5a2e29b3934da09c1ba3c930fd8a40fd6 Author: Eric Dumazet Date: Wed Aug 26 10:52:38 2026 +0000 slip: remove slip_hangup() to fix use-after-free in slip_receive_buf() [ Upstream commit 23c53269f2baaedf2d92784290cb9ef6db2a3bce ] Jaeyoung Chung and Eulgyu Kim reported a slab-use-after-free read in slip_receive_buf() when racing against tty hangup. tty_ldisc_hangup() calls ld->ops->hangup() while holding only a read lock on tty->ldisc_sem (via tty_ldisc_ref()). Because slip_hangup() simply called slip_close(), it ran concurrently with reader functions such as slip_receive_buf(). slip_close() unregisters and frees the net device and its private struct slip, causing concurrent reader threads in slip_receive_buf() to dereference freed memory. Line discipline close() is already guaranteed to be called under the write lock of tty->ldisc_sem during hangup processing (in tty_ldisc_reinit() or tty_ldisc_kill()). Remove slip_hangup() so teardown is serialized cleanly by slip_close(). Fixes: 5342b77c4123 ("slip: Clean up create and destroy") Reported-by: Jaeyoung Chung Reported-by: Eulgyu Kim Closes: https://lore.kernel.org/netdev/20260825150655.1450271-1-jjy600901@snu.ac.kr/ Cc: Qingfang Deng Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260826105238.3323436-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1a5c26e586481bc82abc19ac92c3d9f10518f525 Author: Jamal Hadi Salim Date: Tue Aug 25 04:14:03 2026 -0400 net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup [ Upstream commit 8f735d64382dcf162f4276d6699d03ad2f859c0b ] qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai. Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted. Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260825081403.133992-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2ea42936416b29cca42b2c7bc7d3d3768f77c199 Author: Pascal Kneuper Date: Mon Aug 24 14:50:14 2026 +0200 net: stmmac: restore NET_IP_ALIGN in the RX DMA offset [ Upstream commit 23680bf5f8c69c923546b84a8e6c401bef8b88fe ] Since the RX path was converted to zero-copy, the page pool page is handed to the stack directly as the skb head, and the offset the DMA engine writes at is what determines the alignment of the packet headers. Before the conversion the payload was copied into an skb obtained from napi_alloc_skb(), which reserves NET_SKB_PAD + NET_IP_ALIGN. The conversion moved the headroom into stmmac_rx_offset() but did not carry over NET_IP_ALIGN, so on architectures where NET_IP_ALIGN is 2 the IP header now lands misaligned: 64 (NET_SKB_PAD) + 14 (ethernet) + 20 (IP) = 98 Same for the XDP branch: 256 (XDP_PACKET_HEADROOM) + 14 (ethernet) + 20 (IP) = 290 On ARM32 this is fatal, because ldm and ldrd trap on unaligned addresses even when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set. Any received echo request panics the machine, e.g: Unhandled fault: alignment exception (0x001) at 0x81873062 Internal error: : 1 [#1] SMP ARM Hardware name: Altera SOCFPGA Arria10 PC is at icmp_echo+0x38/0xa8 LR is at icmp_rcv+0x22c/0x370 Call trace: icmp_echo from icmp_rcv+0x22c/0x370 icmp_rcv from ip_protocol_deliver_rcu+0x2c/0x224 ip_protocol_deliver_rcu from ip_local_deliver+0xc8/0x1a0 ip_local_deliver from ip_sublist_rcv_finish+0x3c/0x50 ip_sublist_rcv_finish from ip_list_rcv_finish+0x110/0x118 ip_list_rcv_finish from ip_list_rcv+0xc8/0xdc ip_list_rcv from __netif_receive_skb_list_core+0x170/0x1c0 ... napi_complete_done from stmmac_napi_poll_rx+0xcb0/0x1030 Code: e24dd068 e59020a0 e28dc010 e0822001 (e8920003) Kernel panic - not syncing: Fatal exception in interrupt The faulting instruction is the ldm of *icmp_hdr(skb) in icmp_echo(). Fix by adding NET_IP_ALIGN back to the RX offset, which restores the alignment the stack used to get. Note that commit a955318fe67e ("stmmac: align RX buffers") made a similar change in 2021 and was reverted by commit 12d125b4574b ("stmmac: Revert "stmmac: align RX buffers"") because it caused packet corruption. That patch raised the offset from 0 without adjusting the buffer size accounting, so the DMA engine could arguably write past the end of the RX buffers, though this was never root caused. Commit df542f669307 ("net: stmmac: Switch to zero-copy in non-XDP RX path") since derives the page pool allocation from stmmac_rx_offset(), so the extra bytes are accounted for. Fixes: df542f669307 ("net: stmmac: Switch to zero-copy in non-XDP RX path") Cc: Daniel Baldin Signed-off-by: Pascal Kneuper Link: https://patch.msgid.link/20260824125014.47862-1-PKneuper@dspace.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6257ec22f617381211ea8ba56f88f460879ebc59 Author: Maxime Chevallier Date: Wed Aug 26 16:04:57 2026 +0200 net: stmmac: selftests: Account for the UC filter list for filtering tests [ Upstream commit cd8c3b2752c684141eab2282e294cae2971a9759 ] On dwmac, one of the Unicast filter entries is used to store the local HW addr. This means that we have to use promisc mode for any kind of unicast filtering if we only have one slot in our unicast filter. The number of slots available depends on how the IP is integrated, and we can't autodiscover how many of these slots we have available, so the DT property snps,perfect-filter-entries can be used to specify how many are available. Most IP variants default to 1 if this isn't specified, which is the case for the amlogic variants (in this case, S905X3). The stmmac selftests for UC filtering look if we have enough slots in the filter to store the dev->uc list, but doesn't account for the device's own MAC address. The dev->uc list's size we get with netdev_uc_count() also doesn't account for the HW addr. As the selftest only requires one available slot, in the case of single-slot platforms, that means we erroneously consider we have enough room for the test, when we actually don't, and the filtering test fails. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-6-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f09abff67d1f26956f67d69c9c9ea90ea7e98e60 Author: Maxime Chevallier Date: Wed Aug 26 16:04:56 2026 +0200 net: stmmac: dwxgmac: Account for the primary MAC address for UC filtering [ Upstream commit 2739d6f9a2b8729b0d85cbe0dc93e1d68670b6f2 ] The same filter slots are used to store the main MAC address as well as the address for the unicast filter. Let's account for that when deciding whether or not to use promisc when programming the UC list in hardware. Fixes: 0efedbf11f07 ("net: stmmac: xgmac: Fix XGMAC selftests") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-5-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit edce4b5a76dd7d1ead0c7547c90ffb2cad7aa476 Author: Maxime Chevallier Date: Wed Aug 26 16:04:55 2026 +0200 net: stmmac: dwmac4: Account for the primary MAC address for UC filtering [ Upstream commit 82187f42c014d22520b9c3c4e2cfb519223fb29b ] The same filter slots are used to store the main MAC address as well as the address for the unicast filter. Let's account for that when deciding whether or not to use promisc when programming the UC list in hardware. Fixes: 477286b53f55 ("stmmac: add GMAC4 core support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-4-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f64902e8ae1fa0db71d5f98fbe2523ae117172bd Author: Maxime Chevallier Date: Wed Aug 26 16:04:54 2026 +0200 net: stmmac: dwmac1000: Account for the primary MAC address for UC filtering [ Upstream commit 9698b6da3714fd2ef47846cb63098d2b2d252e25 ] The same filter slots are used to store the main MAC address as well as the address for the unicast filter. Let's account for that when deciding whether or not to use promisc when programming the UC list in hardware. Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers.") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-3-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 57f598f312f919ad678dc5124428648ddd64eda9 Author: Maxime Chevallier Date: Wed Aug 26 16:04:53 2026 +0200 net: stmmac: selftests: Check multiple MMC counters [ Upstream commit d29b399150b07796dfa81d8778d4804c08c2a41d ] The MMC counters report MAC statistics. Multiple counters can be enabled when the IP is integrated, however there's no way to know exactly which ones. Un-implemented counters seem to report 0. It was found that on StarFive JH7110 and Amlogic SM1, the counter that's used by the selftest (mmc_tx_framecount_g) isn't implemented, triggering an MMC selftest failure. Both the above SoCs seem to implement mmc_rx_framecount_gb, let's use this counter as well for MMC counter validation. Note that this doesn't guarantee that we won't encounter the same issue again if another IP implements yet another set of counters that don't include that new one. If the game of whack-a-mole with implemented counters becomes too hard to maintain, we may simply consider removing the MMC selftest entirely. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 66cfb39635529ea74094fb9d00524f33b0797445 Author: Daniel Pawlik Date: Thu Aug 20 10:59:40 2026 +0200 net: airoha: npu: fix missing streaming DMA mask [ Upstream commit 6fe7e31a45e3418a39e6343a85126124feec1c2f ] The driver calls dma_set_coherent_mask() but never dma_set_mask(), leaving the streaming DMA mask at the bus default. On the non-coherent EN7581 platform (Cortex-A53), this causes the NPU mailbox to hang after approximately 41 calls when using streaming DMA mappings. Replace dma_set_coherent_mask() with dma_set_mask_and_coherent() to set both the streaming and coherent DMA masks, matching standard driver practice. Fixes: 6f884eb87a79 ("net: airoha: Fix DMA direction for NPU mailbox buffer") Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260814110017.2795022-1-pawlik.dan@gmail.com/ Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260809152813.585797-1-pawlik.dan@gmail.com/ Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260805070851.2885888-1-pawlik.dan@gmail.com/ Signed-off-by: Daniel Pawlik Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260820085941.380401-1-pawlik.dan@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 99036078abd965462518787e0c8a5736c56e8182 Author: Muhammad Usama Anjum Date: Tue Aug 25 12:18:36 2026 +0100 selftests/arm64: Fix MTE prctl TAP plan [ Upstream commit bb52892f9234e4ecd982fa51222aab33ce282f79 ] The MTE prctl test emits one result from check_basic_read() followed by one result for each of the seven entries in mte_modes[]. However, the TAP plan only accounts for the array entries, producing: # Planned tests != run tests (7 != 8) Include the basic read check in the plan so that all eight emitted results are declared. Reviewed-by: Mark Brown Fixes: 1f488fb91378 ("kselftest/arm64/mte: Add MTE_STORE_ONLY testcases") Signed-off-by: Muhammad Usama Anjum Reviewed-by: Vincenzo Frascino Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit d3bb129dad152aa5067535d516e75d697d047c9c Author: Muhammad Usama Anjum Date: Tue Aug 25 12:18:35 2026 +0100 selftests/arm64: Treat KSM merge_across_nodes as optional [ Upstream commit 1a0dba077f34a2f8faa98308d30d4b546d073145 ] The MTE KSM test requires write access to KSM sysfs but does not check that it is running as root. It also unconditionally saves, enables and restores the merge_across_nodes attribute. The kernel only creates this attribute when CONFIG_NUMA=y, so a non-NUMA kernel prints the following message three times even though every KSM subtest passes: # ERR: missing /sys/kernel/mm/ksm/merge_across_nodes Skip the test when it is not running as root. Check that the optional attribute is readable and writable, treating ENOENT as its expected absence on non-NUMA kernels and skipping the test for other access failures. Only save, enable and restore the attribute when it is available. Check MTE availability before the privilege and sysfs checks so systems without MTE retain the existing feature-unavailable skip result. This preserves the existing behavior on NUMA kernels without requiring NUMA or reducing KSM coverage on single-node systems. Fixes: f981d8fa2646 ("kselftest/arm64: Verify KSM page merge for MTE pages") Signed-off-by: Muhammad Usama Anjum Reviewed-by: Vincenzo Frascino Reviewed-by: Mark Brown Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 1c6940784c556f7398e83c359b9b93ebdfd48c26 Author: Muhammad Usama Anjum Date: Tue Aug 25 12:18:34 2026 +0100 selftests/arm64: Print missing MTE TAP headers [ Upstream commit 8d2237e9d6902e234bb89aabb9cd6a9e91357223 ] Most MTE tests set a TAP plan and emit results without first printing the TAP version header. Direct execution therefore starts with a plan such as "1..20" instead of "TAP version 13". The problem is particularly visible in the GCR_EL1 context-switch test. It prints its plan before forking 1,024 child processes. When stdout is fully buffered, the plan remains in the stdio buffer. Each child inherits the pending "1..1" line and flushes its copy from exit(), producing repeated plan lines. ksft_print_header() prints the TAP header and enables line buffering. Call it in every MTE test that is missing it. In the GCR_EL1 test, call it before the plan so the plan is flushed before the children are forked. In the remaining tests, call it before setup and prerequisite checks so early failures and whole-test skips also retain the header. Fixes: 29f080881601 ("kselftest/arm64: check GCR_EL1 after context switch") Signed-off-by: Muhammad Usama Anjum Reviewed-by: Vincenzo Frascino Reviewed-by: Mark Brown Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2f0c97b1a32fba8e81a69f6231aa0b3c9b6bc581 Author: Takashi Iwai Date: Thu Aug 27 13:39:03 2026 +0200 ALSA: control: Don't add invalid kcontrols to LED layer [ Upstream commit 74e3b979ce8b78a690f8b94ccf2e2c965f7f5c11 ] The kcontrol LED state layer tries to track the all associated kcontrol elements with naive assumptions that they are readable. But one can create a write-only element that has no get callback (even a user element can do it), and this may lead to a NULL dereference at the call chain of snd_ctl_led_notify(), as found by syzkaller. For avoiding the Oops, add a sanity check of the kcontrol's info and get callbacks, and just skip the invalid kcontrols before assigning the kctl to the LED layer. Reported-by: syzbot+b7fe2760ea6f1ee44b4d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a9007b3.1d9ded08.62e62.00cd.GAE@google.com Fixes: 22d8de62f11b ("ALSA: control - add generic LED trigger module as the new control layer") Reviewed-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260827113951.893291-1-tiwai@suse.de Signed-off-by: Sasha Levin commit 67dd5a6c449b4f83c65f5b88eabfab367dc07364 Author: Pablo Neira Ayuso Date: Tue Aug 18 10:31:24 2026 +0200 netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited() [ Upstream commit 793d9eda4821f75b5f7cc9e6a870b72a58b44c2b ] Several xtables extension still use pr_err() or pr_info() without ratelimit. For xt_cgroup, while at this, remove redundant "xt_cgroup:" prefix since pr_fmt is already set on. Fixes: c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3b1066a859dbba379993def7607e766fdac75713 Author: Marino Dzalto Date: Fri Apr 3 22:59:07 2026 +0200 netfilter: xt_HL: add pr_fmt and checkentry validation [ Upstream commit 24bd5c2679caf8a228d90cafa221da4b47fd6642 ] Add pr_fmt to prefix log messages with the module name for easier debugging in dmesg. Add checkentry functions for IPv4 (ttl_mt_check) and IPv6 (hl_mt6_check) to validate the match mode at rule registration time, rejecting invalid modes with -EINVAL. The evaluation function returns false in case the mode is unknown, so this is a cleanup, not a bug fix. Signed-off-by: Marino Dzalto Signed-off-by: Florian Westphal Stable-dep-of: 793d9eda4821 ("netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited()") Signed-off-by: Sasha Levin commit d5497644329d3a01e951aba76561bbd883ff6b0c Author: Pablo Neira Ayuso Date: Thu Aug 13 02:16:02 2026 +0200 netfilter: nf_tables: move hardware offload step after building the chain blob [ Upstream commit b1881d362e1924b66f6016c3efd28807032b41bf ] Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ. Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 0e5ed3b98d1d8d251acfdccfeaa607453ad12954 Author: Alice Mikityanska Date: Sat Aug 22 15:01:16 2026 +0300 virtio-net: Ensure that TCP packets don't overflow gso_segs [ Upstream commit c27c449d455aafd9018a3cbab150f1c42c87923f ] The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649. Fixes: 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") Signed-off-by: Alice Mikityanska Suggested-by: Eric Dumazet Link: https://patch.msgid.link/20260822120117.1163423-2-alice.kernel@fastmail.im Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 023f06c98e031f71f3b4d76066d543639138530a Author: Balasubramani Vivekanandan Date: Wed Aug 19 13:04:58 2026 +0530 drm/xe/xe_gt_idle: Add CCS to the powergating info print [ Upstream commit 369ba0d1efe91cccabe98ae53c53b7425f327edf ] While reading the main GT powergating info from debugfs, include both RCS and CCS engine masks. Fixes: 0914c1e45d3a1 ("drm/xe/xe_gt_idle: add debugfs entry for powergating info") Signed-off-by: Balasubramani Vivekanandan Link: https://patch.msgid.link/20260819073457.1812722-2-balasubramani.vivekanandan@intel.com Reviewed-by: Matt Roper Signed-off-by: Matt Roper (cherry picked from commit 8899e413c5ab85443ec9bbc50cffe924c6b596de) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit c826e980f27678280d8b47bd0a005a3b5db3c7c2 Author: Maxime Chevallier Date: Tue Aug 25 23:17:46 2026 +0200 net: stmmac: selftests: Pass the IP proto mask in the TC selftest [ Upstream commit 9a56a27e6002e29a6707dc4238d469ec84c3a68e ] The stmmac TC filtering rules have recently gained sanity checks to make sure the passed keys and their respective masks are aligned with the HW filtering abilities. The stmmac selftests failed to pass the mask in the match data for L4 filtering tests, and are now failing consistently with -EINVAL : $ ethtool -t eth1 [...] 23. L4 DA TCP Filtering -22 24. L4 SA TCP Filtering -22 25. L4 DA UDP Filtering -22 26. L4 SA UDP Filtering -22 Let's pass the ip_proto mask in the l4 filtering tests match data. Found on imx8mp, which now have passing L4 tests : $ ethtool -t eth1 [...] 23. L4 DA TCP Filtering 0 24. L4 SA TCP Filtering 0 25. L4 DA UDP Filtering 0 26. L4 SA UDP Filtering 0 While at it, initialize the masks and keys to avoid re-using whatever was on the stack. Fixes: 5536d7c84363 ("net: stmmac: fix l3l4 filter rejecting unsupported offload requests") Reviewed-by: Andrew Lunn Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260825211748.360935-1-maxime.chevallier@bootlin.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 30be8c9d598f3e667f95fb231d4e10abb94254bc Author: Jiawen Wu Date: Mon Aug 24 15:21:19 2026 +0800 net: wangxun: use BIT_ULL() to prevent shift overflow on 32-bit archs [ Upstream commit 63c885688f38a757947d7050b1ee4171215269ce ] The macros TXGBE_INTR_MISC() and WX_INTR_Q() rely on the standard BIT() macro to generate interrupt masks based on the queue vector index. On 32-bit architectures, BIT() evaluates to a 32-bit `unsigned long`. Since the number of queue vectors can be up to 63 on txgbe devices, performing a left shift of 32 or more results in an integer overflow and undefined behavior. This causes incorrect interrupt masking and unmasking logic for both the queue and miscellaneous interrupts on 32-bit systems. Fix this by replacing BIT() with BIT_ULL() in these macros. This ensures that the bitwise shift is always performed safely on a 64-bit `unsigned long long` type, regardless of the underlying architecture. Fixes: e37546ad1f9b ("net: wangxun: revert the adjustment of the IRQ vector sequence") Signed-off-by: Jiawen Wu Reviewed-by: Aleksandr Loktionov Link: https://patch.msgid.link/45F5565CE6AC4329+20260824072119.48399-1-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 84180988a455fd8e147c6b35c8df65d8b8cc76c2 Author: Yifei Chu Date: Mon Aug 24 10:27:19 2026 +0800 net/smc: release the internal TCP sock on IPPROTO_SMC socket creation failure [ Upstream commit cec261b0b4c5c0b044165303198d10ffcdf3414c ] IPPROTO_SMC sockets create an internal TCP sock ("clcsock") from the proto->init hook. When socket creation fails after proto->init has run - e.g. a cgroup BPF program attached to BPF_CGROUP_INET_SOCK_CREATE denies the socket - sk_common_release() only invokes sk_prot->destroy if it is set, but neither smc_inet_prot nor smc_inet6_prot defines it, and smc_destruct() returns early unless sk_state is SMC_CLOSED. As a result, every failing socket(AF_INET, SOCK_STREAM, IPPROTO_SMC) call leaks one tcp_sock, so an unprivileged task able to attach a deny-all BPF_CGROUP_INET_SOCK_CREATE program to its own cgroup can grow kernel memory unboundedly. Add a .destroy hook to both protos that releases the clcsock via smc_clcsock_release(). smc_sk_init() hashes the sock into the smc hashinfo before the clcsock is created, and smc_diag dumps walk that hash dereferencing smc->clcsock without taking clcsock_release_lock, while sk_common_release() calls .destroy before .unhash. Unhash the sock before releasing the clcsock, as __smc_release() does, so a concurrent dump cannot observe the release; the second unhash in sk_common_release() is a no-op. Fixes: d25a92ccae6b ("net/smc: Introduce IPPROTO_SMC") Reported-by: Abaci Assisted-by: abaci:qwen3.8-max Signed-off-by: Yifei Chu Reviewed-by: Dust Li Link: https://patch.msgid.link/178753843966.342810.566471390946765094@linux.alibaba.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 557599edb522af60ffb4275bf4747a210d643d3a Author: bui duc phuc Date: Mon Aug 24 17:09:01 2026 +0700 net: ethernet: sun4i-emac: Fix IRQ error handling [ Upstream commit 991c2be78257cba5bf53cf935fe70f8836964288 ] irq_of_parse_and_map() returns 0 when parsing or mapping an IRQ fails. The current code checks for -ENXIO and therefore does not detect the failure. Check for a zero return value and convert it to -ENXIO. Fixes: 492205050d77 ("net: Add EMAC ethernet driver found on Allwinner A10 SoC's") Signed-off-by: bui duc phuc Reviewed-by: Andre Przywara Link: https://patch.msgid.link/20260824100901.31675-1-phucduc.bui@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 626614df9080d7052fbe24dc90b5434717ab7a9f Author: Haotian Zhang Date: Wed Aug 26 09:50:50 2026 +0800 samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-modify [ Upstream commit 6727b7618f49401acf373fa3ec5712e2ec52e5cf ] ftrace_direct_multi_init() assigns kthread_run()'s return value to simple_tsk without an IS_ERR() check. When kthread_run() fails it returns ERR_PTR(-ENOMEM), but init still returns 0, so the module loads with simple_tsk holding an error pointer. On unload, ftrace_direct_multi_exit() then passes that ERR_PTR to kthread_stop(), leading to a null-pointer-dereference. Check the return value of kthread_run() with IS_ERR(); on failure, unregister the ftrace direct call and propagate the error code. Link: https://patch.msgid.link/20260826015050.10772-1-vulab@iscas.ac.cn Fixes: e1067a07cfbc ("ftrace/samples: Add module to test multi direct modify interface") Suggested-by: Steven Rostedt Signed-off-by: Haotian Zhang Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 8de8e5476be39406720216b50238db80bcce9f33 Author: Haotian Zhang Date: Wed Aug 26 09:50:34 2026 +0800 samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-modify [ Upstream commit d79fb758e7e2e7a181eab630c0545a56041c473d ] ftrace_direct_init() assigns kthread_run()'s return value to simple_tsk without an IS_ERR() check. When kthread_run() fails it returns ERR_PTR(-ENOMEM), but init still returns 0, so the module loads with simple_tsk holding an error pointer. On unload, ftrace_direct_exit() then passes that ERR_PTR to kthread_stop(), leading to a null-pointer-dereference. Check the return value of kthread_run() with IS_ERR(); on failure, unregister the ftrace direct call and propagate the error code. Link: https://patch.msgid.link/20260826015034.10755-1-vulab@iscas.ac.cn Fixes: ae0cc3b7e7f5 ("ftrace/samples: Add a sample module that implements modify_ftrace_direct()") Suggested-by: Steven Rostedt Signed-off-by: Haotian Zhang Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 6d1c6f228854aa89844fd0152d7ed7ac72a55e89 Author: Aleksandr Nogikh Date: Fri Jul 31 10:14:50 2026 +0000 libceph: validate banner payload length [ Upstream commit f374967fcdf04001c9b66df1c19106fa83cd91f7 ] When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (`server_feat` and `server_req_feat`). Therefore, `payload_len` must be at least 16 bytes. Fix this by adding a check in `process_banner_prefix()` to reject a `payload_len` smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error. Fixes: cd1a677cad99 ("libceph, ceph: implement msgr2.1 protocol (crc and secure modes)") Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+87c7c2d63c44e41c77a3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=87c7c2d63c44e41c77a3 Link: https://syzkaller.appspot.com/ai_job?id=c8ca3d63-717a-4933-89ec-f3d761b8690d Signed-off-by: Aleksandr Nogikh Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 792bfe803228cfab7f2dc7f08ea5749235f6a5f7 Author: Xiubo Li Date: Tue Jul 21 13:06:53 2026 +0800 ceph: revalidate ki_pos for O_APPEND writes after cap acquisition [ Upstream commit d2a8d446a09c74c8ddfe108b50dd791c889983fc ] For O_APPEND writes, ki_pos is set to the current EOF via generic_write_checks() after fetching i_size from the MDS. However, ceph_get_caps() may need to wait for Fwx exclusive caps if the write extends the file (endoff > i_max_size). While waiting for Fwx, the previous Fwx holder (another client) may have already extended the file. When the MDS grants us Fwx, the cap grant message updates the local i_size, but ki_pos remains at the old EOF, causing the append write to land at a stale offset and overwrite data from the other client. Fix by re-reading i_size_read(inode) after ceph_get_caps() returns. At this point we hold Fwx exclusive caps, no other client can modify the file, and i_size reflects the true EOF from the MDS cap grant. No extra MDS round-trip is needed. Only adjust ki_pos when the EOF has actually changed. After adjusting ki_pos forward, the write range [pos, pos+count) may now exceed the i_max_size that was validated by ceph_get_caps() for the old range. Re-check against i_max_size and truncate the write if necessary to stay within the MDS-granted limit. Link: https://tracker.ceph.com/issues/7333 Fixes: 8e4473bb50a1 ("ceph: do not execute direct write in parallel if O_APPEND is specified") Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 33b3dc47202d063dc1e8b79b4ce33041bdd1f965 Author: Hongling Zeng Date: Thu Jun 4 15:43:25 2026 +0800 ceph: Fix ERR_PTR(0) in ceph_mkdir() [ Upstream commit 4f49c3f8a5a86d237bb202ecb17c2802ddc8fd2f ] When mkdir succeeds, ceph_mkdir() sets ret to ERR_PTR(0) which is incorrect. It should return NULL instead for success. Fixes: 88d5baf69082 ("Change inode_operations.mkdir to return struct dentry *") Signed-off-by: Hongling Zeng Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 10a36512c21f861a03fba461a7ead09023df9c1b Author: HyeongJun An Date: Tue Aug 25 21:57:45 2026 +0900 ASoC: dapm: Fix off-by-one check on the second enum channel [ Upstream commit 14511c9b54ceeeef487409d73947c89ee8563590 ] The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80x_mux_values. The core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which defaults off. Fixes: 3727b4968453 ("ASoC: dapm: Consolidate MUXs and value MUXs") Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260825125745.932832-1-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5449f715f24e86648f8cc8fba8d97ff6b5d04981 Author: John Johansen Date: Mon Aug 24 11:01:18 2026 -0700 apparmor: policy_int make sure list heads are initialized before fail path [ Upstream commit 3daad923a8685adb66087e0d819559b7eb6ba975 ] If profile create fails before policy_init is complete the list heads are not properly initialized causing profile_free() sanity checks to trigger the following splat. AppArmor WARN aa_policy_destroy: (((!list_empty(&policy->profiles) && (&policy->profiles)->prev != ((void *) 0x122 + (0xdead000000000000UL))))): WARNING: security/apparmor/lib.c:509 at aa_policy_destroy+0x164/0x1b0 security/apparmor/lib.c:509, CPU#0: syz.0.17/5541 Modules linked in: CPU: 0 UID: 0 PID: 5541 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:aa_policy_destroy+0x16b/0x1b0 security/apparmor/lib.c:509 Code: 85 ed 7e 4d e8 96 bc 37 fd 5b 41 5c 41 5e 41 5f 5d e9 19 27 4e 07 cc e8 83 bc 37 fd 48 8d 3d 0c f0 d3 0b 48 c7 c6 a4 eb 38 8e <67> 48 0f b9 3a e9 04 ff ff ff e8 66 bc 37 fd 48 8d 3d ff ef d3 0b RSP: 0018:ffffc9000345eaa0 EFLAGS: 00010293 RAX: ffffffff848f530d RBX: ffff88803f734800 RCX: ffff88801af2a580 RDX: 0000000000000000 RSI: ffffffff8e38eba4 RDI: ffffffff90634320 RBP: 0000000000000000 R08: 0000000000000cc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d95913 R12: dead000000000122 R13: ffff88803f734800 R14: ffff88803f734828 R15: dffffc0000000000 FS: 00007f5f6a1836c0(0000) GS:ffff88808c519000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d02407b048 CR3: 0000000012aa9000 CR4: 0000000000352ef0 Call Trace: aa_free_profile+0x9d/0x9f0 security/apparmor/policy.c:334 aa_alloc_profile+0x1e4/0x3e0 security/apparmor/policy.c:416 unpack_profile security/apparmor/policy_unpack.c:1153 [inline] aa_unpack+0x17db/0x7430 security/apparmor/policy_unpack.c:1748 aa_replace_profiles+0x226/0x2a20 security/apparmor/policy.c:1183 policy_update+0x234/0x4a0 security/apparmor/apparmorfs.c:505 profile_load+0x1cb/0x320 security/apparmor/apparmorfs.c:522 vfs_write+0x296/0xba0 fs/read_write.c:685 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f6939e0d9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f5f6a183028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f5f69625fa0 RCX: 00007f5f6939e0d9 RDX: 0000000000000041 RSI: 0000200000000400 RDI: 0000000000000003 RBP: 00007f5f6a183090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f5f69626038 R14: 00007f5f69625fa0 R15: 00007ffe23725c18 Reported-by: syzbot+faed97c4ed43bfe7fee5@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=faed97c4ed43bfe7fee5 Fixes: fe6bb31f590c9 ("apparmor: split out shared policy_XXX fns to lib") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 59fba1d249dceae0eaba1b169ad2e30b797f3392 Author: Thorsten Blum Date: Sat Nov 22 12:55:51 2025 +0100 apparmor: Replace sprintf/strcpy with scnprintf/strscpy in aa_policy_init [ Upstream commit b31d3f7385fbb49681d44e7104cfa033cba4b1e8 ] strcpy() is deprecated and sprintf() does not perform bounds checking either. Although an overflow is unlikely, it's better to proactively avoid it by using the safer strscpy() and scnprintf(), respectively. Additionally, unify memory allocation for 'hname' to simplify and improve aa_policy_init(). Closes: https://github.com/KSPP/linux/issues/88 Reviewed-by: Serge Hallyn Signed-off-by: Thorsten Blum Signed-off-by: John Johansen Stable-dep-of: 3daad923a868 ("apparmor: policy_int make sure list heads are initialized before fail path") Signed-off-by: Sasha Levin commit d48197cbd5d3476c7deea644972e9ec510865ec2 Author: Jérémy Jean Date: Sat Aug 15 10:09:18 2026 +0000 crypto: acomp - allocate async request context when cloning [ Upstream commit ee440d4fc0d2f15894ab1f64c474a3adbc858880 ] ACOMP_REQUEST_ON_STACK() reserves only enough storage for the synchronous fallback. When an async implementation is selected, callers clone that stack request before retrying, but acomp_request_clone() currently copies only the stack-sized object. The clone therefore has no storage for the async provider request context, and providers such as QAT write past the allocation through acomp_request_ctx(). KASAN does report a slab OOB write. Allocate a zeroed clone large enough for the runtime acomp request size, copy only the bytes present in the source object, and preserve the existing fallback-on-allocation-failure behavior. Use the runtime reqsize because an implementation may adjust it during tfm initialization. Fixes: 097c432caaa6 ("crypto: acomp - Add ACOMP_REQUEST_CLONE") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit fdc992f4bc45f4e11110eeb530ca61679ac2b2fc Author: Ruoyu Wang Date: Thu Aug 13 23:30:32 2026 +0800 tpm: st33zp24: Validate locality read result [ Upstream commit 264216889d39df509b9c8045df53529480b0b718 ] check_locality() treats every nonzero transport return as success. SPI errors remain negative, while the I2C path can convert a negative write error through its byte-sized status variable. Either result is nonzero even though the TPM_ACCESS byte can remain unwritten, so indeterminate ACTIVE_LOCALITY and VALID bits can falsely report an active locality. Require recv() to return exactly the requested byte before examining TPM_ACCESS. Transport errors and short reads now report an inactive locality, while successful reads retain the existing behavior. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 251a7b08213a ("TPM: STMicroelectronics ST33 I2C KERNEL 3.x") Signed-off-by: Ruoyu Wang Link: https://lore.kernel.org/r/20260813153032.3951878-2-ruoyuw560@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 14feaa498c20c1b7ddefe27de5329aaff822cc0d Author: Ruoyu Wang Date: Fri Aug 21 04:38:05 2026 +0300 tpm: st33zp24: Return zero on status read failure [ Upstream commit 8b92687708f5ef980de01c2042dbd76d11f78547 ] st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or error path instead of acting on an invalid status value. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 251a7b08213a ("TPM: STMicroelectronics ST33 I2C KERNEL 3.x") Signed-off-by: Ruoyu Wang Link: https://lore.kernel.org/r/20260813153032.3951878-1-ruoyuw560@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 96bc345a3f17543d0d92ada609e02198d6380e26 Author: Victor Nogueira Date: Mon Aug 24 08:59:28 2026 -0300 net/sched: sch_teql: restore skb->dev on the slave failure path [ Upstream commit dc4b95b8fee95113587e93ca116356032d271371 ] teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration. Fixes: 0cc0c2e661af ("net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit") Reported-by: Vega Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260824115928.4099988-1-victor@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit aeb8196ecb95146e3410f635628e6cd47352b3e5 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:09 2026 -0400 net/sched: sfq: clamp quantum to avoid signed overflow soft lockup [ Upstream commit 816e90057ab1879562a5b7cc688e35bb9027ae97 ] sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-7-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 99770b5d8e0e1c69b996f74a19d71afd2c4a9aa4 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:08 2026 -0400 net/sched: hhf: clamp quantum before hhf_change() to avoid overflow [ Upstream commit 2164b512b97bb053e8ce4d6e95576f11bed6a005 ] hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare "tc qdisc add ... hhf" succeeds with a clamped quantum but "tc qdisc add ... hhf limit 1000" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-6-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 044fa2498bbc2900f0c48a6ef2fdd5b2bdfc3795 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:07 2026 -0400 net/sched: fq_pie: clamp default quantum to avoid signed overflow [ Upstream commit c86cd7ed0b0e44779a3d1683f03e4353baf4bdc9 ] fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-5-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7ca8a8717a9fe35235c119ece6bc76ec9234859d Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:06 2026 -0400 net/sched: sch_codel: clamp default mtu to avoid disabling CoDel [ Upstream commit 6439461f1618ae176c048673ad28bdb6c68efbfc ] codel_init() sets q->params.mtu = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000. In codel_should_drop() the test "*backlog <= params->mtu" then compares the backlog against ~2 GiB; with the default sch->limit of DEFAULT_CODEL_LIMIT (1000) packets the backlog can never reach it, so the test is always true and CoDel is silently and completely disabled i.e no drops, no ECN marking, codel degrades to a tail-drop FIFO. codel_change() never updates params.mtu, so the init path is the only place to clamp it. Constrain to [256, 1 << 20], matching the fq_codel bound; 256 is a sane floor that only makes CoDel slightly more willing to act on very small queues, which is the safe direction. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-4-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit dfb4b61db886917244284b18b44b23d2254b82c2 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:05 2026 -0400 net/sched: fq_codel: clamp default quantum and mtu [ Upstream commit d9ebd8f9aa8b2773235889cb903fafd61f2d8585 ] fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests "*backlog <= params->mtu"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memory_limit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double psched_mtu() call. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: 4b549a2ef4be ("fq_codel: Fair Queue Codel AQM") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-3-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f6b3e3848a5fca63438984acd6d9eceac80814c1 Author: Jamal Hadi Salim Date: Sat Aug 22 15:55:04 2026 -0400 net/sched: fq: add overflow bounds to quantum and initial quantum [ Upstream commit 709f34f7c28dc4dd6c40343d101850f11e172312 ] fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 * psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill loop adds 0 to f->credit (which stays <= 0) and goto begin loops forever under the qdisc lock, creating a soft lockup. Clamp psched_mtu() to [1, 1 << 20] before multiplying so the product cannot wrap, then cap the result at 1 << 20, matching the bound already enforced on TCA_FQ_QUANTUM in fq_change(). Conditions to recreate the bug: a device whose MTU (plus hard_header_len) is large enough that 2 * psched_mtu() wraps (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace. Fixes: afe4fd062416 ("pkt_sched: fq: Fair Queue packet scheduler") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260822195509.112717-2-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 76c847e80d2b6be047707d58e8e05eedbe2593ad Author: Tetsuo Handa Date: Sat Aug 22 17:18:31 2026 +0900 net: fix a resource leak in copy_net_ns() error handling path [ Upstream commit 3220b62fbb8a55feebd2a826d5ead0f49f09ed5a ] Currently, preinit_net() does two things: (1) call ns_common_init() which might fail (2) initialize resources which does not fail However, preinit_net() is returning early when (1) fails, and copy_net_ns() is jumping to the dec_ucounts: label. As a result, resources allocated by net_alloc() are leaking. We need to call key_remove_domain() and net_passive_dec() in order to release resources allocated by net_alloc(). We cannot simply jump to the put_userns: label when preinit_net() failed, for (2) is not yet done. But we can reorder (1) and (2), for there is no dependency between (1) and (2). Therefore, this patch decouples (1) from preinit_net() and changes preinit_net() back to a void function, and calls ns_common_init() after preinit_net() succeeded. Then, we can jump to immediately after ns_common_free() of the put_userns: label. Reported-by: sashiko (no mail address) Closes: https://sashiko.dev/#/patchset/af7dabf3-d0d7-46dc-a878-e1715b3c9ac6%40I-love.SAKURA.ne.jp Fixes: 08027f6b790b ("net: use ns_common_init()") Signed-off-by: Tetsuo Handa Link: https://patch.msgid.link/c182cf90-1ed7-435b-88f7-9f00e88a0487@I-love.SAKURA.ne.jp Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d1c084d4e9f033654225d345c521f95b27240d91 Author: Mina Almasry Date: Sun Aug 23 18:36:01 2026 +0000 net: core: check skb_frags_readable before uncloning in skb_copy_ubufs [ Upstream commit 00e11ee9831b3439264e0ae6762a0470126515af ] skb_copy_ubufs drops clones and modifies the SKB via pskb_expand_head() before checking for !skb_frags_readable(skb). This alters the SKB geometry prior to throwing an -EFAULT on an invalid SKB. Check readability first. Fixes: 65249feb6b3d ("net: add support for skbs with unreadable frags") Signed-off-by: Mina Almasry Link: https://patch.msgid.link/20260823183602.1051453-1-almasrymina@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1719865b20b22c88d2a55e922eff5ca31b0841f6 Author: Eric Dumazet Date: Sun Aug 23 18:22:41 2026 +0000 net/sched: act_skbmod: fix length calculations and avoid invalid header warnings [ Upstream commit 81d0d1e64f30d9989c829c0953cd6e6c68d9c5fb ] syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act(): !skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55 There are a few issues in tcf_skbmod_act(): 1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets). Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER. Fixes: 56af5e749f20 ("net/sched: act_skbmod: Add SKBMOD_F_ECN option support") Reported-by: syzbot+1d56f14f95c0480cfdc9@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a8b39c0.dbb3a75c.13dd47.0051.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260823182241.1958695-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3e07d284ef085cfff5cbba1596aa1bcc0d9ae74a Author: Karl Mehltretter Date: Sat Aug 8 22:03:12 2026 +0200 selftests/proc: make proc-maps-race work with READ_IMPLIES_EXEC [ Upstream commit 0685630fdccb62dcb0e3f44525a40578da5f6dc8 ] test_maps_tearing_from_split times out when READ_IMPLIES_EXEC is set. This happens by default on pre-ARMv6 CPUs, which lack no-execute support. split_vma() re-maps the first page with mod_info->prot | PROT_EXEC to make it differ from its neighbours. With READ_IMPLIES_EXEC the original mapping is already executable, so no split occurs and the test hangs waiting for the modifier child. Use PROT_NONE for the split mapping, which always differs from its readable neighbours. Link: https://lore.kernel.org/20260808200312.6326-1-kmehltretter@gmail.com Fixes: beb69e817246 ("selftests/proc: add /proc/pid/maps tearing from vma split test") Assisted-by: Codex:gpt-5.6-terra Signed-off-by: Karl Mehltretter Acked-by: Suren Baghdasaryan Cc: Alexey Dobriyan Cc: Jann Horn Cc: Liam R. Howlett Cc: Shuah Khan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 4e70c064213ef4bd22cea26ea7b044fd57ea4411 Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:25 2026 -0400 maple_tree: fix argument name in header [ Upstream commit 00f67814a14e614b749ebe54076ef1e3e6454f2b ] The mas_prev_range() function takes a min and not a max. Link: https://lore.kernel.org/20260821192627.4085470-18-liam@infradead.org Fixes: 6b9e93e01020 ("maple_tree: add mas_prev_range() and mas_find_range_rev interface") Signed-off-by: Liam R. Howlett (Oracle) Cc: Boqun Feng Cc: Breno Leitao Cc: Chris Mason Cc: Chuck Lever Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 64ae85a3a29de3738760d951b95c78c50b1d5058 Author: Liam R. Howlett (Oracle) Date: Fri Aug 21 15:26:20 2026 -0400 maple_tree: catch race in mas_alloc_cyclic() [ Upstream commit 35f1342e5b893a740eff2ef9ab337bfaa63ab76d ] If mas_alloc_cyclic() is called during a low memory situation, it is possible the lock may be dropped so reclaim can occur. There is a window where some other task may allocate the same id and cause the mas_insert() to fail with -EEXIST. In this scenario the function will return -EEXIST, which is not expected. Modifying the retry on mas_nomem() to re-search for a slot means that any race with other writes will not matter as the lock will be held between finding the index and writing the index. Moving the flag logic avoids cases where the flag is modified on drop lock/reacquire or when the write fails after clearing the flag. No existing users are exposed to this issue. Link: https://lore.kernel.org/20260821192627.4085470-13-liam@infradead.org Fixes: 9b6713cc7522 ("maple_tree: Add mtree_alloc_cyclic()") Signed-off-by: Liam R. Howlett (Oracle) Reported-by: Chris Mason Reviewed-by: Chuck Lever Cc: Boqun Feng Cc: Breno Leitao Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: Waiman Long Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 005343e0c329433a3d6b2ac70ebf8f5669c981d0 Author: Muhammad Usama Anjum Date: Mon Jul 27 10:52:17 2026 +0100 selftests/mm: skip COW tmpfile cases when fallocate() is unsupported [ Upstream commit 4004c130c358b1561a55323b0e747f20f5133f7b ] Patch series "selftests/mm: Handle unsupported and transient test conditions", v3. Several MM selftests report failures when the test environment lacks an underlying prerequisite, such as fallocate() support, MADV_REMOVE, local page-cache semantics, or swap. This series converts those unsupported cases to SKIP while preserving failures for unexpected errors. It also allows migration tests to retry transient move_pages() failures. This patch (of 4): The tmpfile-backed COW cases allocate a one-page file with fallocate() before exercising private and shared mappings. When the filesystem backing tmpfile() does not implement fallocate(), setup fails with EOPNOTSUPP and no COW behavior is exercised. This occurs when the temporary directory resides on a filesystem with limited allocation support, such as NFSv3. Reporting a failure adds noise because the test prerequisite is absent rather than the COW implementation being broken. Report EOPNOTSUPP as a skip. Continue treating every other fallocate() error as a failure so unexpected setup regressions remain visible. Link: https://lore.kernel.org/20260727095225.372655-1-usama.anjum@arm.com Link: https://lore.kernel.org/20260727095225.372655-2-usama.anjum@arm.com Fixes: f8664f3c4a08 ("selftests/vm: cow: basic COW tests for non-anonymous pages") Signed-off-by: Muhammad Usama Anjum Tested-by: Sarthak Sharma Acked-by: Usama Arif Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 3d1b2d84b49091afc5c6c169e509ce180b3ca6ba Author: Frank Sorenson Date: Sat Aug 8 15:29:03 2026 -0500 cifs: fix clearing stats for fastest execution of each smb2 command [ Upstream commit 48cab1fd5720508148673f59d8ed52c7c7fffca2 ] The code to clear the 'fastest_cmd' statistics has a typo that repeatedly clears the stat for cmd 0, rather than iterating through each cmd. Fix the typo (0->i). Fixes: 433b8dd7672be ("SMB3: Track total time spent on roundtrips for each SMB3 command") Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit b003d5b4e46ca5033859db601e12d36da24d0e40 Author: Suman Ghosh Date: Fri Aug 21 16:25:35 2026 +0530 octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup [ Upstream commit b09a0503c755b6609fad59a84cc7f05b6843a03c ] af_xdp_zc_qidx tracks receive queues using AF_XDP zero-copy and is allocated during PF/VF probe. Representors and other non-AF_XDP paths leave the pointer NULL, but several call sites used test_bit() on it unconditionally. Switching to devlink eswitch mode creates representors and runs otx2_init_hw_resources(), which reaches otx2_pool_aq_init() and oopses when dereferencing the NULL bitmap. Add NULL checks before every af_xdp_zc_qidx test_bit() use in the RSS, ethtool, XSK, and pool init paths. Fixes: efabce290151 ("octeontx2-pf: AF_XDP zero copy receive support") Signed-off-by: Suman Ghosh Signed-off-by: Geetha sowjanya Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260821105536.2998765-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bf2b8130723efcb5b86c3ddb6317c3a9b2a9cfc5 Author: Allison Henderson Date: Fri Aug 21 22:26:47 2026 -0700 net/rds: use wq_has_sleeper() in rds_cong_map_updated() [ Upstream commit d4f484661961636eb90d287050959e613795f73a ] rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern. Fixes: 922cb17a5c81 ("RDS: Congestion-handling code") Signed-off-by: Allison Henderson Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260822052647.88318-1-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d218ea7df6eba076171f2d4897a429a31f2139f0 Author: Victor Nogueira Date: Fri Aug 21 13:40:31 2026 -0300 net/sched: act_ife: Only operate on Ethernet frames [ Upstream commit 5b483f7791b079bb97d411f1066652ff659207ff ] act_ife encapsulates/decapsulates the original Ethernet header and uses skb->dev->hard_header_len as the length of that header. That is only correct for Ethernet devices: on a device where hard_header_len does not match the L2 header that was actually pulled (PPP reports PPP_HDRLEN while nothing is stripped on ingress), the ingress skb_push()/skb_pull() use the wrong length and can hit skb_under_panic when headroom is tight. IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites h_source/h_dest/h_proto, and calls eth_type_trans() on decode - so instead of trying to make the offsets work for arbitrary link types, simply drop packets that do not carry an Ethernet header. Checking skb->dev->type alone is not enough. We have to cater for a corner case where mirred can redirect an skb from a non-Ethernet device to an Ethernet one, and skb->dev then says nothing about the framing the skb actually has: an skb redirected from ppp0 reaches the target's ingress hook with mac_len 0 and no Ethernet header at all. So at ingress also require mac_len to be ETH_HLEN. On egress mac_len is not maintained, so the device type is all we have; a bogus redirect there yields a malformed frame rather than an out-of-bounds push, and it would be malformed with or without IFE. That corner case is not theoretical - redirecting from ppp0 into a veth that has an ife encode action on its ingress hook panics without this patch: skbuff: skb_under_panic: len:98 put:14 head:ffff88800e410000 data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3 kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657) tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874) tc_run (net/core/dev.c:4463) netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522) tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328) tcf_mirred_act (net/sched/act_mirred.c:489) tc_run (net/core/dev.c:4463) process_backlog (net/core/dev.c:6728) With Ethernet framing guaranteed, use ETH_HLEN instead of hard_header_len. Fixes: 295a6e06d21e ("net/sched: act_ife: Change to use ife module") Reported-by: vega@nebusec.ai Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Link: https://patch.msgid.link/20260821164031.32824-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 936e33035d54d8e78bf8e0817a20e0b7b825c9d7 Author: Eric Dumazet Date: Fri May 1 13:59:16 2026 +0000 net/sched: add qstats_cpu_drop_inc() helper [ Upstream commit 3f3aa77ff1c8b45ec8c9e40212f1a24a93e00df3 ] 1) Using this_cpu_inc() is better than going through this_cpu_ptr(): - Single instruction on x86. - Store tearing prevention. 2) Change tcf_action_update_stats() to use this_cpu_add(). 3) Add WRITE_ONCE() to __qdisc_qstats_drop() and qstats_drop_inc() in preparation for lockless "tc qdisc show". $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 3/17 up/down: 72/-216 (-144) Function old new delta dualpi2_enqueue_skb 462 511 +49 tcf_ife_act 1061 1077 +16 taprio_enqueue 613 620 +7 codel_qdisc_enqueue 149 143 -6 tcf_vlan_act 684 676 -8 tcf_skbedit_act 626 618 -8 tcf_police_act 725 717 -8 tcf_mpls_act 1297 1289 -8 tcf_gate_act 310 302 -8 tcf_gact_act 222 214 -8 tcf_csum_act 2438 2430 -8 tcf_bpf_act 709 701 -8 tcf_action_update_stats 124 115 -9 pie_qdisc_enqueue 865 856 -9 pfifo_enqueue 116 107 -9 choke_enqueue 2069 2059 -10 plug_enqueue 139 128 -11 bfifo_enqueue 121 110 -11 tcf_nat_act 1501 1489 -12 gred_enqueue 1743 1668 -75 Total: Before=24388609, After=24388465, chg -0.00% Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260501135916.2566766-1-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5b483f7791b0 ("net/sched: act_ife: Only operate on Ethernet frames") Signed-off-by: Sasha Levin commit ab8e0164c0fee4677aae40b6c982d144c5bf9a61 Author: Wei Fang Date: Fri Aug 21 14:41:39 2026 +0800 net: enetc: restore RX ring congestion mode after ring reconfiguration [ Upstream commit 9e94d8e14ae45e3fda8c0919f745db3ed3715433 ] The RX ring congestion mode (CM) is only configured in the phylink .mac_link_up() callback enetc_pl_mac_link_up(), which sets the ENETC_RBMR_CM bit when tx_pause is enabled. This callback runs only when the link status changes. However, enetc_reconfigure() tears down and re-creates the RX BD rings at runtime without any link status change, for example when attaching or detaching an XDP program, or when enabling/disabling PTP RX hardware timestamping. The rings are rebuilt from a cleared RBMR, so the CM bit is lost. Since the link status does not change, enetc_pl_mac_link_up() is not called again and the CM bit is never restored. As a result, the ENETC MAC can no longer generate PAUSE frames on ingress congestion, and flow control stops working after such a reconfiguration. Track the desired CM state in a software flag ENETC_RXBDR_CM. Set or clear this flag in enetc_pl_mac_link_up() according to tx_pause. When the RX BD rings are (re)enabled, enetc_enable_rxbdr() consults this flag and restores the ENETC_RBMR_CM bit accordingly, so flow control survives ring reconfiguration even when the link status does not change. RBMR is now written as a whole word from enetc_enable_rxbdr() rather than by read-modify-write from several call sites. Serialize the remaining RBMR read-modify-write paths, the congestion mode update and the RX VLAN offload update, with the new si->gen_lock so they cannot race each other. Fixes: 5093406c784f ("net: enetc: implement ring reconfiguration procedure for PTP RX timestamping") Signed-off-by: Wei Fang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821064140.1315611-2-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 276e74737317072e4b9b2a59555eb5fdfabd8d79 Author: Naveen Mamindlapalli Date: Fri Aug 21 11:24:45 2026 +0530 octeontx2-af: Fix TL3/TL2 link config ENA clearing [ Upstream commit 9edf8d4876e8a2471e66f54d36208eaff2858392 ] Clear and restore the ENA bit for each TL3/TL2 link entry during SMQ flush instead of repeatedly using the same link index. Fixes: 019aba04f08c ("octeontx2-af: Modify SMQ flush sequence to drop packets") Signed-off-by: Nitin Shetty J Signed-off-by: Naveen Mamindlapalli Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260821055445.2517568-1-nshettyj@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7abe769e72c792e5f9eb273813eb3ecd8389854c Author: Xiang Mei Date: Thu Aug 20 12:52:40 2026 -0700 net: qualcomm: rmnet: restore skb->dev on deaggregated frames [ Upstream commit a66734a1c5e36525ea07e9f4547fddc51e916de3 ] rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt Fixes: 378e25357ac7 ("net: qualcomm: rmnet: Remove unnecessary device assignment") Reported-by: co+4638111fe2a12980@bugs.sh Closes: https://lore.kernel.org/netdev/ijg79FFMfIvKJbivdJEKvTO90Q9dTvyBkJck@bugs.sh/T/#u Signed-off-by: Xiang Mei Reviewed-by: Subash Abhinov Kasiviswanathan Link: https://patch.msgid.link/20260820195240.1631458-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 42a139332ce81a907dac987f1494d30e0a8ab149 Author: Anshumali Gaur Date: Thu Aug 20 14:06:34 2026 +0530 octeontx2-vf: fix workqueue and netdev race in probe/remove [ Upstream commit 3ba97ff4f873481d370bee7f7dfb87f8296af9be ] Initialize the VF workqueue before register_netdev() so ndo_set_rx_mode does not queue work on a NULL workqueue. Unregister the netdev before destroying the workqueue, and add proper probe error cleanup. Fixes: cbc100aa2205 ("octeontx2-nicvf: add ndo_set_rx_mode support for multicast & promisc") Signed-off-by: Nitin Shetty J Signed-off-by: Anshumali Gaur Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260820083634.1641740-1-nshettyj@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 537e11a1700f64dc6754108f0e1333ad63d4f548 Author: Anshumali Gaur Date: Thu Aug 20 10:33:33 2026 +0530 octeontx2-af: fix NULL deref in NIX TM tree debugfs read path [ Upstream commit ec65631bd5ec251cdf67a4919fac7a3149a6e235 ] rvu_dbg_nix_tm_tree_display() dereferences pfvf->sq_ctx without checking whether the SQ context has been allocated. Reading /sys/kernel/debug/octeontx2/nix/tm_tree for a NIX LF whose transmit queues are not set up triggers a kernel oops. Guard the read path the same way rvu_dbg_nix_tm_tree_write() already does and return -EINVAL with a seq_file message when sq_ctx is NULL. Fixes: b907194a5d5b ("octeontx2-af: Add debugfs support to dump NIX TM topology") Signed-off-by: Anshumali Gaur Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260820050333.2606095-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7677eb2cbf2cc7446de474c01a6b06277c0051e5 Author: Cen Zhang (Microsoft) Date: Wed Aug 19 22:07:35 2026 -0400 gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free [ Upstream commit d989e22ae9802c52c56ad4284d0caf26696cf6ae ] gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets(). Fixes: 459aa660eb1d8ce6 ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Xiang Mei (Microsoft) Reported-by: Cen Zhang (Microsoft) Signed-off-by: Cen Zhang (Microsoft) Link: https://patch.msgid.link/20260820020735.59474-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 53a5b262d706b572840cbe8feae392538077ee19 Author: Stanislav Fomichev Date: Wed Aug 19 09:05:34 2026 -0700 xsk: honor XDP_TX_METADATA in zero-copy path [ Upstream commit a6e4b9a6deb9362ef7a0706c70d674e92fe1411a ] The zero-copy path reads TX metadata whenever the UMEM has metadata space, even if the descriptor does not set XDP_TX_METADATA. Pass descriptor options through the metadata helpers and ignore metadata unless the option is set. This does not fix the existing per-WQE metadata handling for mlx5 MPWQEs. Only the descriptor that starts a session passes through xsk_tx_metadata_request() and configures offload state shared by the batch. Metadata on descriptors joining an open session is therefore not validated and does not configure its requested offloads. In addition, a non-NULL metadata pointer from such a descriptor is treated as a timestamp completion request even when XDP_TXMD_FLAGS_TIMESTAMP is not set, so its metadata union can be overwritten with an unrequested timestamp. Fixing mixed metadata states within one MPWQE requires a separate change. Fixes: 48eb03dd2630 ("xsk: Add TX timestamp and TX checksum offload support") Reviewed-by: Alexander Lobakin Signed-off-by: Stanislav Fomichev Reviewed-by: Maciej Fijalkowski Reviewed-by: Aleksandr Loktionov Link: https://patch.msgid.link/20260819160535.1472459-3-sdf@fomichev.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5b913e87af4b23af4496894633a9ca6725f9b8ec Author: Stanislav Fomichev Date: Wed Aug 19 09:05:33 2026 -0700 xsk: align TX metadata layout across ABIs [ Upstream commit bd7d30bd1d3856d8354b5acef947d68ad1faf886 ] Add explicit padding before launch_time so xsk_tx_metadata has the same layout on 32-bit and 64-bit systems. On several architectures (csky, i386, nios2, m65k, openrisc, sh), the old native 32-bit layout put launch_time at offset 12 and had a natural size of 20 bytes. Using sizeof(struct xsk_tx_metadata) as tx_metadata_len was already rejected because the length must be a multiple of eight, so the straightforward use of the interface was broken on those ABIs. Userspace could still register a padded length of 24 bytes, though; mixing the old and new layouts then silently reads launch_time from the wrong offset and misprograms packet launch times. This intentionally replaces that incompatible layout because the affected architectures are unlikely to have any notable users. (x86_64 and arm64 have the most users and are _not_ affected) Fixes: ca4419f15abd ("xsk: Add launch time hardware offload support to XDP Tx metadata") Reviewed-by: Simon Horman Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20260819160535.1472459-2-sdf@fomichev.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aeee917a4878af95f0c63e18c5f22eaf6299c7b8 Author: Hyunwoo Kim Date: Fri Mar 20 00:14:58 2026 +0900 Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop [ Upstream commit 44c98fd082eafd49d55a8a4077ff488175b2fe24 ] rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Hyunwoo Kim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a644b8df94966b672ac656577df98bd01bc88393 Author: Ali Ahmet Memis Date: Fri Aug 14 18:28:48 2026 +0000 Bluetooth: btnxpuart: Validate the FW dump header length [ Upstream commit 060fa7592bdc043a93b6b7870f5b8551206d315d ] nxp_process_fw_dump() pulls the ACL header off the frame and then reads seq_num and buf_len from a struct nxp_fw_dump_hdr placed at skb->data, without checking that the ACL payload is long enough to contain it. h4_recv_buf() collects HCI_ACL_HDR_SIZE bytes of header followed by the number of payload bytes named in that header, so skb->len is 4 + dlen with dlen supplied by the controller and possibly smaller than the 8 byte dump header, or zero. A short frame with connection handle 0xfff therefore reads both fields from beyond the received data. Beyond the read itself, buf_len is what terminates a dump: a value of zero makes the driver call hci_devcd_complete() and reset the controller, so a truncated frame can end a dump early. Use skb_pull_data() to validate and pull the FW dump header before accessing its fields. Warn and reject the chunk if the header is truncated. Fixes: 998e447f443f ("Bluetooth: btnxpuart: Add support for HCI coredump feature") Signed-off-by: Ali Ahmet Memis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7b37556d7d801b79096c7ba8ea92db2338aa8b00 Author: Chris Lu Date: Mon Aug 17 17:53:32 2026 +0800 Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path [ Upstream commit fa0ad2d277c7adead61d1c22411c55cea6990c2a ] btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size of 256 bytes, but hands the host controller the SKB buffer as is: err = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data, round_up(skb->len, MTK_SDIO_BLOCK_SIZE)); Only skb->len bytes hold packet data, so the controller reads up to 255 bytes of uninitialised memory and sends it to the device over the SDIO bus. Depending on how much tailroom slack the SKB allocation happens to carry, that read can also extend past the end of the buffer. Compute the padded length up front, ensure the SKB has tailroom for it, and zero-fill the padding with skb_put_zero(). skb->len then covers the padding, so sdio_writesb() no longer needs to round up. byte_tx keeps counting the header and the payload only, and the error path restores the SKB so that the caller can requeue it. Writing behind skb->tail is only safe because the driver owns the buffer, which "Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX" ensures. Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Signed-off-by: Chris Lu Assisted-by: Claude:claude-opus-5 Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 566da1197d34010b8853981162b20ab5decbe0be Author: Chris Lu Date: Mon Aug 17 17:53:31 2026 +0800 Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX [ Upstream commit 155e3003d1e614f85566b636973df7118e1b4851 ] btmtksdio_tx_packet() prepends the MediaTek SDIO header with skb_push() and writes into that space after only checking the headroom size. On a cloned SKB that headroom belongs to a buffer shared with the other owner, which the driver has no right to write to. Cloned SKBs do reach this path: hci_send_cmd_sync() keeps a clone of every HCI command in hdev->sent_cmd before handing the SKB to the driver, and l2cap_ertm_send() clones SKBs for retransmission. Replace the open-coded headroom check with skb_cow_head(), which both guarantees the headroom and reallocates a private buffer when the SKB is cloned. The cost is one reallocation and copy per cloned packet, the usual price of this pattern in network drivers. This has no observable effect on its own, as the driver only writes in front of skb->data where no other owner looks. It is a prerequisite for "Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path", which writes padding behind skb->tail, and carries the same Fixes: tag so that both are backported together. Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Signed-off-by: Chris Lu Assisted-by: Claude:claude-opus-5 Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3818502f2f69d1aa559da3ceee3a69a72a5bd00b Author: Ismail Tarim Date: Sat Aug 15 14:56:24 2026 +0300 Bluetooth: btmtk: Do not discard the subsystem reset timeout [ Upstream commit 21b50c24843b51f88ac4316dd470d2803da0c42f ] When the MTK_BT_RST_DONE poll times out, btmtk_usb_subsys_reset() logs "Reset timeout" and keeps the error in err, but err is then overwritten by the return value of the following btmtk_usb_id_get() call, so the timeout is never reported to the caller. Commit 25b6d7593a3a ("Bluetooth: btmtk: introduce btmtk reset work") discarded the return value of the chip id read, so the function returned the timeout error as intended. Commit 3dcb122b3064 ("Bluetooth: btusb: mediatek: return error for failed reg access") started assigning err at that call and silently dropped it. Keep the timeout in a separate variable and return it, restoring the original behaviour without changing the control flow. Fixes: 3dcb122b3064 ("Bluetooth: btusb: mediatek: return error for failed reg access") Signed-off-by: Ismail Tarim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f3465a143c87c1191a4d17ae62ca96f03433255f Author: Ismail Tarim Date: Sat Aug 15 14:56:23 2026 +0300 Bluetooth: btmtk: Do not report success when subsys reset fails [ Upstream commit 59c3ee19ca88210bfc0e22ce59218091cb1a3c48 ] btmtk_usb_subsys_reset() validates the subsystem reset by reading the chip id back. When that read succeeds at the bus level but yields an id of zero, the reset has demonstrably not taken effect: the function logs "Can't get device id, subsys reset fail." and then returns the return value of btmtk_usb_id_get(), which in that case is zero, i.e. success. btusb_mtk_reset() returns that value unchanged, so its caller cannot tell a completed reset from a failed one. Return -ENODEV when the chip id reads back as zero, leaving the existing MT6639 exemption intact. Observed on an MT7902 [13d3:3579]. The path can be reached on demand by asking the controller for a coredump, since btmtk requests a reset once the dump completes: # echo 1 > /sys/class/bluetooth/hci0/device/coredump Bluetooth: hci0: Mediatek coredump end Bluetooth: hci0: Can't get device id, subsys reset fail. usb 3-10: reset high-speed USB device number 5 using xhci_hcd usb 3-10: device descriptor read/64, error -110 usb usb3-port10: attempt power cycle usb usb3-port10: unable to enumerate USB device The same sequence occurs unprompted when the controller firmware asserts on its own. Note that this corrects the error reporting only; it does not by itself make the controller recoverable in the case above. Fixes: 25b6d7593a3a ("Bluetooth: btmtk: introduce btmtk reset work") Signed-off-by: Ismail Tarim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 9fc4fd78bc650cdf2ff6db01c5574b807255e23c Author: Greg Kroah-Hartman Date: Mon Jul 27 17:57:33 2026 +0200 Bluetooth: btmtk: Fix short read errors in btmtk_usb_reg_read() [ Upstream commit 0cc4b5649ae83deb8222100dba31aa0f100a19cd ] If btmtk_usb_reg_read() gets a "short" read from a device, it will accidentally treat that as a "real" read and populate the returned value with some unknown and probably totally invalid data. Fix this logic error up by calling usb_control_msg_recv() which guarantees a "full" read happens, and then simplify the error checking for when btmtk_usb_reg_read() is called (it's really just btmtk_usb_id_get() that calls btmtk_usb_reg_read(), so fix up those return sites. Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 59c3ee19ca88 ("Bluetooth: btmtk: Do not report success when subsys reset fails") Signed-off-by: Sasha Levin commit 5a2cb90e23587e4dc46b856267b70354b549b77f Author: Javier Tia Date: Mon Mar 30 14:39:23 2026 -0600 Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support [ Upstream commit 28b7c5a6db74e9305c6cbcbe52f259ff1cf85158 ] The MediaTek MT7927 (Filogic 380) combo WiFi 7 + BT 5.4 module uses hardware variant 0x6639 for its Bluetooth subsystem. Without this patch, the chip fails with "Unsupported hardware variant (00006639)" or hangs during firmware download. Three changes are needed to support MT6639: 1. CHIPID workaround: On some boards the BT USB MMIO register reads 0x0000 for dev_id, causing the driver to skip the 0x6639 init path. Force dev_id to 0x6639 only when the USB VID/PID matches a known MT6639 device, avoiding misdetection if a future chip also reads zero. This follows the WiFi-side pattern that uses PCI device IDs to scope the same workaround. 2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of "1_1" used by MT7925 and other variants. The firmware path is mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin, using the mt7927 directory to match the WiFi firmware convention. The filename will likely change to use MT7927 once MediaTek submits a dedicated Linux firmware binary. 3. Section filtering: The MT6639 firmware binary contains 9 sections, but only sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related. Sending the remaining WiFi/other sections causes an irreversible BT subsystem hang requiring a full power cycle. This matches the Windows driver behavior observed via USB captures. Also add 0x6639 to the reset register (CONNV3) and firmware setup switch cases alongside the existing 0x7925 handling. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Reported-by: Ryan Gilbert Signed-off-by: Javier Tia Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 59c3ee19ca88 ("Bluetooth: btmtk: Do not report success when subsys reset fails") Signed-off-by: Sasha Levin commit 61d5ddbd524c715b224cbe7e9f01da4e05098b19 Author: Pauli Virtanen Date: Sat Aug 8 12:08:45 2026 +0300 Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan [ Upstream commit 66d6ef18548ae6d7dd452b84115fc82c0a73a4ea ] For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read. [Task 1] [Task 2 (hdev->workqueue)] l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref) Task 1 may observe NULL which causes null-ptr-deref. Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL. Clarify code comments vs. locking. Fixes: 6fef032af009 ("Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()") Reported-by: syzbot+e6382a2f53f5fc7453ac@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e6382a2f53f5fc7453ac Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c3f63610bceaa182e4683b23cc47baf36b5f1496 Author: Pavel Shpakovskiy Date: Sat Aug 8 19:31:11 2026 +0300 Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereference [ Upstream commit 59eecbe2f2f38d8f3e1104bd11da97f9a2c58998 ] 'uuid_count' member of struct 'discovery_state' is assigned and read without any locks, so there is a chance of situation when uuid_count != 0, but uuids is NULL and there will be NULL pointer dereference. Possible race: 'hci_update_passive_scan_sync' 'hci_discovery_filter_clear' hdev->discovery.uuid_count = 0; <----------------------preempted-----------------------------> 'start_service_discovery' // Set uuid_count to value != 0 hdev->discovery.uuid_count = uuid_count; hdev->discovery.uuids = kmemdup(...); <----------------------preempted-----------------------------> spin_lock(&hdev->discovery.lock); kfree(hdev->discovery.uuids); hdev->discovery.uuids = NULL; spin_unlock(&hdev->discovery.lock); Now uuids == NULL and uuid_count != 0. So 'mgmt_device_found' -> 'is_filter_match' -> 'eir_has_uuids' receives non consistent discovery state, where NULL dereference of uuids happens. To fix it let's add discovery.lock around every read/write of uuid_count, uuids pair of struct members. It is also important to assign uuid_count value only after success kmemdup() allocation in start_service_discovery(), otherwise uuids is NULL, because kmemdup failed, but uuid_count is already assigned to non zero value. The following panic happens: [ ] ------------[ cut here ]------------ [ ] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ ] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP [ ] CPU: 0 PID: 15056 Comm: kworker/u9:2 [ ] Workqueue: hci0 hci_rx_work [ ] pstate: 10400009 (nzcV daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : eir_has_uuids+0x2d8/0x590 [ ] lr : is_filter_match+0x258/0x320 ... [ ] Call trace: [ ] eir_has_uuids+0x2d8/0x590 [ ] is_filter_match+0x258/0x320 [ ] mgmt_device_found+0x5b0/0xafc [ ] process_adv_report.part.0+0x8c8/0xf14 [ ] hci_le_adv_report_evt+0x338/0x3f0 [ ] hci_le_meta_evt+0x1f0/0x4c8 [ ] hci_event_packet+0x440/0xc9c [ ] hci_rx_work+0x44c/0xaf8 [ ] process_one_work+0x54c/0x103c [ ] worker_thread+0x6c4/0x10c4 [ ] kthread+0x274/0x2ec [ ] ret_from_fork+0x10/0x20 [ ] Code: 14000004 91004021 eb14003f 54000180 (f9400024) [ ] ---[ end trace 0000000000000000 ]--- Fixes: 2935e556850e ("Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'") Signed-off-by: Pavel Shpakovskiy Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 87276dc15b559d32757a43b4415c8445fbae06c4 Author: Pauli Virtanen Date: Sun Aug 9 01:06:05 2026 +0300 Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN [ Upstream commit d4bfa78fd67929b62b02013c107973e0c5b7aa9a ] New sk should not be added to parent socket accept queue after last l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and state set to BT_CLOSED, as that can result to UAF on dereferencing the dangling parent reference. l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking: [Task 1] [Task 2] l2cap_sock_release(parent) l2cap_connect l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm l2cap_chan_lock(pchan) l2cap_chan_close l2cap_sock_teardown_cb pchan->state = BT_CLOSED l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan) l2cap_new_connection l2cap_sock_new_connection_cb l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan) l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */ Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes where missing, to avoid data races. Although the data races on pchan->state should be fixed too, this defensive sk_state check probably makes sense in any case. Fixes: 2ff1a41a912d ("Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()") Reported-by: syzbot+9265e754091c2d27ea29@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9265e754091c2d27ea29 Signed-off-by: Pauli Virtanen Reported-by: syzbot+9265e754091c2d27ea29@syzkaller.appspotmail.com Tested-by: syzbot+9265e754091c2d27ea29@syzkaller.appspotmail.com Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 00a73ce437e27fdc636a5ede445a4a491e01788d Author: Vladimir Murzin Date: Wed Aug 19 15:48:59 2026 +0100 arm64: process: Fix context switching MTE store-only tag check [ Upstream commit b8f070ac3167595069feb1f794c127b805115645 ] SCTLR_EL1.TCSO0 is set when user opt-in for MTE store-only tag check mode. However, it is not part of SCTLR_USER_MASK which imply that on context switch we never clear SCTLR_EL1.TCSO0, so we are leaking that setting into another task. Fix that by including SCTLR_EL1_TCSO0_MASK into SCTLR_USER_MASK Fixes: 4d51ff5bba00 ("arm64/kernel: Support store-only mte tag check") Signed-off-by: Vladimir Murzin Reviewed-by: Catalin Marinas Reviewed-by: Yeoreum Yun Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 4a888ccb33d0c4dba39ac0cd85ef820d47f028bf Author: Wei-Lin Chang Date: Fri Aug 14 23:24:57 2026 +0100 arm64: ptdump: Make note_page_flush() range aware [ Upstream commit 902caade3cfd60f99bf71b355e7c86344bd831e5 ] note_page_flush() calls note_page() with addr == 0 and level == -1 to dump the last row of a ptdump. addr == 0 (1 << 64 wrapped around) renders a huge region with enormous size for address spaces with IA bits < 64. For example the stage-2 page tables and the EFI runtime page table. More importantly, the last region of the address space and everything after the address space up to 1 << 64 are merged into one row of output. If the last region within the address space is valid, it will appear to remain valid up to 1 << 64 with the same attributes. Currently only the EFI runtime ptdump is affected by this, but KVM will soon fix its stage-2 ptdump by using note_page_flush(). Here is an example of an EFI runtime ptdump (last row): 0x0000008000000000-0x0000000000000000 17179868672G PGD With this patch: 0x0000008000000000-0x0001000000000000 261632G PGD To fix this, cache the end address of a ptdump in ptdump_pg_state so note_page_flush() can call the final note_page() with the correct end address. Fixes: 9d80448ac92b ("efi/arm64: Add debugfs node to dump UEFI runtime page tables") Signed-off-by: Wei-Lin Chang Reviewed-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f365f36bbb5ac3b68e4436628607246009db5f31 Author: Geert Uytterhoeven Date: Thu Aug 20 12:00:23 2026 +0200 erofs: Fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS default logic [ Upstream commit ab74edaeb1ae7c7194e79007e6afdfe788111a3f ] When NR_CPUS is less than 16, or when SMP is disabled, the default value of 16 is invalid. While actual configuration picks up a sensible and valid default (NR_CPUS or 1), "make savedefconfig" will still write a line like CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1 to the defconfig file, even if that matches the sensible default. Avoid needlessly enlarging the defconfig files, and reduce churn for updating them, by specifying valid defaults depending on SMP and NR_CPUS. While at it, make the prompt depend on SMP, as there is no point in asking the user about the maximum number of decompression streams if there is only one valid answer. Fixes: c9b47e6b23114e93 ("erofs: cap LZMA stream pool size") Signed-off-by: Geert Uytterhoeven Reviewed-by: Guenter Roeck Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit f30c8905abdae9fecae4f31e3ff1ee49394f0473 Author: Dan Carpenter Date: Thu Aug 13 10:09:53 2026 +0300 scsi: qla2xxx: Fix an loop timeout test [ Upstream commit 11e48f5201fd86ffa038809dd9c41144d43ee2e4 ] This loop timeout with "retries" set to -1, not 0. Fix the test for failure. Fixes: 7ec0effd30bb ("[SCSI] qla2xxx: Add support for ISP8044.") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/an1twcxTYSFkkUTA@stanley.mountain Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit aa17842bbccaeaba7d05c166019d1c96a41bca54 Author: Michael Kelley Date: Wed Aug 12 07:52:23 2026 -0700 Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition [ Upstream commit cee0d90bceae1dee3bcc70f8d6b2ceb5b87deb42 ] The VMBus module initialization function, hv_acpi_init(), currently does nothing when running in the root partition and root is not nested in another VM. But the initialization function reports success, so the VMBus module is indeed loaded. VMBus functionality is not actually needed, but the VMBus module must be loaded so that hv_vmbus_exists() can answer correctly. Furthermore, the mshv_root dependency on the VMBus module is needed as described in the commit message for 840b740a35bf ("mshv: Add conditional VMBus dependency"). Loading the VMBus module without actually initializing it causes failures if the module should later be unloaded. The module unload code tries to clean up things that were never initialized, resulting in memory faults and a panic. Fix this by having VMBus module exit function perform the same check for non-nested root partition, and do nothing in such a case, just like hv_acpi_init(). In the long run, the code that manages the Hyper-V provided SynIC should be refactored to better coordinate the requirements of root partition scenarios and normal VM scenarios, and to hopefully remove the hv_vmbus_exists() dependnecy between mshv_root and VMBus modules. Preventing the current unload failure scenario is an expediency until such a refactoring is done. Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hyperv/20260721154943.A09BD1F00A3D@smtp.kernel.org/ Fixes: 7e279d78664aa ("Drivers: hv: vmbus: skip VMBus initialization if Linux is root") Signed-off-by: Michael Kelley Reviewed-by: Easwar Hariharan Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit ff422b8597c287dbbac1d444330770114131dfba Author: Thierry Reding Date: Wed Oct 29 17:33:30 2025 +0100 syscore: Pass context data to callbacks [ Upstream commit a97fbc3ee3e2a536fafaff04f21f45472db71769 ] Several drivers can benefit from registering per-instance data along with the syscore operations. To achieve this, move the modifiable fields out of the syscore_ops structure and into a separate struct syscore that can be registered with the framework. Add a void * driver data field for drivers to store contextual data that will be passed to the syscore ops. Acked-by: Rafael J. Wysocki (Intel) Signed-off-by: Thierry Reding Stable-dep-of: cee0d90bceae ("Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition") Signed-off-by: Sasha Levin commit f7914ff92e4aa8653fb6474c7b52c4aed752470f Author: Eric Dumazet Date: Thu Aug 20 08:06:25 2026 -0400 net_sched: sch_fq: fix pacing delay underflow with pacing offload [ Upstream commit 137b8ae233cabe7fc77cce86f5ba33bf1b369e26 ] When pacing offload is enabled (q->offload_horizon > 0), FQ can dequeue packets early (now < f->time_next_packet). In this case, the drift calculation (now - f->time_next_packet) underflows to a large unsigned value. min(len/2, now - f->time_next_packet) then evaluates to len/2, incorrectly halving the pacing delay for the next packet. Fix this by only applying drift compensation if now > f->time_next_packet. This bug was triggered when flow_max_rate was set on the qdisc or for non EDT packets (packets with a zero skb->tstamp). Fixes: f26080d47007 ("net_sched: sch_fq: add the ability to offload pacing") Reported-by: Willem de Bruijn Closes: https://lore.kernel.org/netdev/CANn89iK6O7ujR9zCJzd04MNLQoDi3mA+HWsR-hgQWYzLS3gZfw@mail.gmail.com/ Signed-off-by: Eric Dumazet Signed-off-by: Willem de Bruijn Link: https://patch.msgid.link/20260820120706.1995449-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9c5d7bdb29ef113c24f3e8904f8144a0650f075c Author: Rong Zhang Date: Fri Aug 21 01:41:25 2026 +0800 net: page_pool: Remove zone/policy GFP flags when allocating XArray entries [ Upstream commit 039f248a6cc1f4dec895c001de2c600842022e58 ] Net drivers request GFP flags according to both the current context and the device constraints, but the XArray entry itself is by no mean used by the device. Passing though device constraints to XArray allocation is a bug and will be warned and fixed up by slab, e.g.: Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0x82820 (GFP_ATOMIC|__GFP_NOWARN|__GFP_NOMEMALLOC). Fix your code! CPU: 2 UID: 0 PID: 1071629 Comm: kworker/u80:1 Not tainted 7.2.0-rc7+ #1 PREEMPT(lazy) Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN27WW 10/20/2025 Workqueue: mt76 mt792x_pm_wake_work [mt792x_lib] Call Trace: dump_stack_lvl+0x6e/0x90 kmalloc_fix_flags+0x4d/0x6a refill_objects+0x10a/0x330 __pcs_replace_empty_main+0x292/0x5c0 kmem_cache_alloc_lru_noprof+0x4c2/0x680 ? __xas_nomem+0x3a/0x120 __xas_nomem+0x3a/0x120 __xa_alloc+0xd4/0x190 page_pool_dma_map+0xef/0x400 __page_pool_alloc_netmems_slow+0xed/0x480 ? lock_release+0x280/0x490 page_pool_alloc_frag_netmem+0xe0/0x3a0 page_pool_alloc_frag+0xe/0x20 mt76_dma_rx_fill_buf+0x1f6/0x580 [mt76] mt76_dma_rx_reset+0x1cf/0x230 [mt76] mt792x_wpdma_reset+0x183/0x1b0 [mt792x_lib] mt792x_wpdma_reinit_cond+0x5e/0xa0 [mt792x_lib] mt792xe_mcu_drv_pmctrl+0x28/0x60 [mt792x_lib] mt792x_mcu_drv_pmctrl+0x3e/0x90 [mt792x_lib] mt792x_pm_wake_work+0x2d/0x1d0 [mt792x_lib] ? process_one_work+0x20e/0x600 process_one_work+0x230/0x600 ? process_one_work+0x256/0x600 worker_thread+0x1ec/0x3c0 ? rescuer_thread+0x610/0x610 kthread+0xf2/0x130 ? kthread_affine_node+0x140/0x140 ret_from_fork+0x2a5/0x380 ? kthread_affine_node+0x140/0x140 ret_from_fork_asm+0x11/0x20 Currently mt76 and stmmac may allocate page pool pages with GFP_DMA32. Fix it by removing zone/policy GFP flags when allocating XArray entries. This is inspired by commit 96d578088085 ("iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()"). Fixes: ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool") Signed-off-by: Rong Zhang Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260821-page-pool-xa-drop-dma32-v1-1-6eab295c3478@rong.moe Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b9838b655b70864aa25d5eb0e4fd7220e1b44d48 Author: Jiawen Wu Date: Tue Aug 18 15:47:21 2026 +0800 net: libwx: fix concurrent bitmap overwrite in PTP setup [ Upstream commit f05516dd7b865666ea7d67e90d0edb588ae9ad18 ] In wx_ptp_set_timestamp_mode(), the driver copies the global `wx->flags` bitmap to a local variable, modifies the PTP-related bits, and then writes the entire bitmap back using memcpy(). This Read-Copy-Update pattern is unsafe and introduces a critical race condition. Other asynchronous contexts (such as Tx timeout routines or GPIO IRQ handlers) update individual bits in `wx->flags` concurrently using atomic bitops like set_bit() or clear_bit(). The memcpy() write-back can silently overwrite and drop these concurrent changes, potentially causing the driver to miss critical module reset or PCIe recovery requests. Fix this by removing the local bitmap copy. Instead, evaluate the intended PTP flag states locally and apply them directly to `wx->flags` using atomic set_bit() and clear_bit() operations only after the hardware is successfully configured. Fixes: 06e75161b9d4 ("net: wangxun: Add support for PTP clock") Signed-off-by: Jiawen Wu Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/6C7EC12D69217315+20260818074721.45536-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a13a63558e5c89eda4326b6592fcf6e3631e48b9 Author: Jiawen Wu Date: Tue Aug 18 10:30:26 2026 +0800 net: txgbe: fix MISC interrupt unmasking in non-MSI-X mode and device shutdown [ Upstream commit 7bf29145d7a9564162c6b18f8d23760e141e2d15 ] In txgbe_misc_irq_thread_fn(), the driver unmasks the miscellaneous interrupt at the end of the handler using TXGBE_INTR_MISC(wx) (which resolves to BIT(wx->num_q_vectors)). While this is correct for MSI-X mode, it is incorrect for legacy INTx or single MSI modes. Due to hardware behavior, the WX_PX_MISC_IVAR register is completely ignored by the hardware when MSI-X is disabled. In non-MSI-X mode, the hardware forcibly merges all interrupt causes (both Queue and MISC) into a single bit: BIT(0) of the interrupt register. Unconditionally unmasking TXGBE_INTR_MISC(wx) (e.g., BIT(1)) in non-MSI-X mode means the actual MISC interrupt bit (BIT(0)) is not unmasked promptly at the end of the MISC thread. Instead, it remains masked until NAPI completes its polling and unmasks the shared BIT(0). This delays the assertion of subsequent MISC interrupts, preventing timely handling of events like link state changes. Fix this by explicitly checking `pdev->msix_enabled` and falling back to BIT(0) as the interrupt mask for the MISC cause when MSI-X is disabled. Additionally, unconditionally unmasking the interrupt at the end of the thread introduces a race condition during device teardown. Guarding the wx_intr_enable() call with a check for the WX_STATE_DOWN bit, to prevent re-arming the interrupt during device shutdown. Fixes: e37546ad1f9b ("net: wangxun: revert the adjustment of the IRQ vector sequence") Signed-off-by: Jiawen Wu Reviewed-by: Simon Horman Link: https://patch.msgid.link/56A53978B83EEDE9+20260818023026.6631-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 38fa06f9ccccc7269f66df497fbfea4e2776b5d7 Author: Jiawen Wu Date: Mon May 25 18:05:41 2026 +0800 net: wangxun: introduce WX_STATE_DOWN to serialize device shutdown state [ Upstream commit 7116ffb48ad0af7a6d066c3e80329270920858fe ] Replace various netif_running() checks with an explicit WX_STATE_DOWN state bit to track whether the device datapath and interrupt handling are operational. The previous logic relied on netif_running() to gate interrupt reenablement, queue wakeups, statistics updates, and service task execution. However, netif_running() only reflects the administrative state of the netdevice and does not fully serialize against teardown and reset paths. During device shutdown and reset flows, asynchronous contexts such as interrupt handlers, NAPI poll, and service work could still observe netif_running() as true while device resources were already being disabled or freed. Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20260525100543.27140-2-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Stable-dep-of: 7bf29145d7a9 ("net: txgbe: fix MISC interrupt unmasking in non-MSI-X mode and device shutdown") Signed-off-by: Sasha Levin commit 6bf50b58f40d025335df569cf0d79cef13a47e5c Author: Jiawen Wu Date: Tue Apr 7 10:56:14 2026 +0800 net: wangxun: schedule hardware stats update in watchdog [ Upstream commit dc33e52b8ce6f2d42dce18da12dc47d6c21f2e8b ] Hardware statistics should be updated periodically in the watchdog to prevent 32-bit registers from overflowing. This is also required for the upcoming pause frame accounting logic, which relies on regular statistics sampling. Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20260407025616.33652-8-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Stable-dep-of: 7bf29145d7a9 ("net: txgbe: fix MISC interrupt unmasking in non-MSI-X mode and device shutdown") Signed-off-by: Sasha Levin commit b1d311224479ea5b77ba67e3d999d70f03f8396a Author: Jiawen Wu Date: Tue Apr 7 10:56:11 2026 +0800 net: wangxun: replace busy-wait reset flag with kernel mutex [ Upstream commit d48df7e7c3fb456d2dc907707a124dab8462eb19 ] Replace the busy-wait loop using test_and_set_bit(WX_STATE_RESETTING) with a proper per-device mutex to serialize reset operations. The reset flag is reserved for other code paths (like watchdog), which need tocheck if a reset is in process. Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20260407025616.33652-5-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Stable-dep-of: 7bf29145d7a9 ("net: txgbe: fix MISC interrupt unmasking in non-MSI-X mode and device shutdown") Signed-off-by: Sasha Levin commit 71adad90236b118992d7abe92331d63afbe9ed98 Author: Jiawen Wu Date: Thu Oct 23 09:45:38 2025 +0800 net: txgbe: support RSC offload [ Upstream commit eaed17770637af6d35d9b5465d91f1256a5eaacf ] Support to enable and disable RSC for txgbe devices. Signed-off-by: Jiawen Wu Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20251023014538.12644-4-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Stable-dep-of: 7bf29145d7a9 ("net: txgbe: fix MISC interrupt unmasking in non-MSI-X mode and device shutdown") Signed-off-by: Sasha Levin commit 80fd6d42f07cebf87cd21a974c59b8d41ec5bc6b Author: Jiawen Wu Date: Thu Oct 23 09:45:36 2025 +0800 net: txgbe: support RX desc merge mode [ Upstream commit a71e367773482a78566abd862dfee9cc3bb9332e ] RX descriptor merge mode is supported on AML devices. When it is enabled, the hardware process the RX descriptors in batches. Signed-off-by: Jiawen Wu Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20251023014538.12644-2-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Stable-dep-of: 7bf29145d7a9 ("net: txgbe: fix MISC interrupt unmasking in non-MSI-X mode and device shutdown") Signed-off-by: Sasha Levin commit 51fe3fe0ffec033bd831c71d9bee3dee827e491c Author: Wei Fang Date: Fri Aug 21 11:24:49 2026 +0800 ptp: netc: fix period truncation and potential divide-by-zero in PEROUT [ Upstream commit 777dbc9914b2f003f1d44af80c7a4a395c5961b2 ] The max_period bound in net_timer_enable_perout() was computed as: max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period; which exceeds U32_MAX when integral_period > 0 (e.g. 0x100000002 for the default 333333333 Hz clock). A period_ns that passes this check but exceeds U32_MAX is then silently truncated when stored into the u32 struct netc_pp::period field. A truncated value of zero can reach netc_timer_set_perout_alarm(), where the local u32 period variable would also be 0, causing a divide-by-zero in roundup_u64(delta, period) whenever the stime < min_time branch is taken (which always happens for a start time of {0, 0}). Additionally, netc_timer_enable_periodic_pulse() and netc_timer_enable_fiper() both compute: fiper = pp->period - integral_period; A zero pp->period results in an unsigned wraparound to 0xFFFFFFFD, mis-programming the FIPER hardware register. Fix all three issues by capping max_period at NETC_TMR_DEFAULT_FIPER (0xFFFFFFFF). This ensures that any period_ns passing the range check fits in a u32 without truncation, so the stored value is always valid and non-zero. The accepted range is reduced by integral_period ns (typically only a few nanoseconds), which is negligible in practice. Fixes: 671e266835b8 ("ptp: netc: add periodic pulse output support") Signed-off-by: Wei Fang Reviewed-by: Abel Vesa Link: https://patch.msgid.link/20260821032449.1235065-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 430afa27beb924299775be0954c1559a214aeab6 Author: Thomas Walsh Date: Thu Aug 20 18:05:44 2026 -0400 bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check [ Upstream commit a70859cf31214e546cb73da7142f190138dae9ab ] In bnxt_request_irq(), pcie_enable_tph() is called unconditionally to enable PCIe TPH when setting up interrupts. If the NIC hardware or firmware capabilities do not support queue ops, attempting to enable TPH during bnxt_request_irq() is unnecessary. As a result a flood of "RX queue restart failed: err=-95" messages is seen upon boot. Older NICs (pre-Thor / BCM57414) do not support TPH or queue management. TPH requires queue management to restart the queue. NICs that support queue management (with updated FW) all support TPH. Gate the call to pcie_enable_tph() and setting of bp->tph_mode behind BNXT_SUPPORTS_QUEUE_API(bp) to ensure TPH is only initialized on devices capable of supporting queue ops. This prevents a guaranteed -EOPNOTSUPP error from occurring due to NULL operations. Fixes: c214410c47d6 ("bnxt_en: Add TPH support in BNXT driver") Suggested-by: Michal Schmidt Signed-off-by: Thomas Walsh Reviewed-by: Michael Chan Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/20260820220544.1240879-1-thwalsh@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 001ff5d8e68aacd91768b824b930dd7e68db6688 Author: Guenter Roeck Date: Thu Aug 20 21:45:12 2026 -0700 bnxt_en: Fix call to hardware monitoring event handler [ Upstream commit 622d698df4239fef3e0eb51fe59f4198f957f28a ] The first parameter of hwmon_notify_event() is supposed to be the hardware monitoring device. The bnxt driver calls it with the platform device as first parameter instead. This API break results in undefined behavior and may result in a crash. Pass the hardware monitoring device as parameter instead to fix the problem. Fixes: a19b4801457b0 ("bnxt_en: Event handler for Thermal event") Signed-off-by: Guenter Roeck Reviewed-by: Kalesh AP Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260821044512.663941-1-linux@roeck-us.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 012bebc8611060377133dff291453c9d1b37fee2 Author: Cosmo Chou Date: Sat Jul 18 03:37:05 2026 +0800 rtc: pcf85363: Add error checking to regmap calls in probe() [ Upstream commit 78acddfde75177a27000f076e3e828743e38877e ] The probe() function ignores errors returned by regmap operations. If an I2C transport error occurs (e.g., -ENXIO), the driver continues probing and may register a non-functional RTC device. Propagate errors from all unchecked regmap calls in probe() using dev_err_probe(). Fixes: fd9a6a13949a ("rtc: pcf85363: add support for the quartz-load-femtofarads property") Signed-off-by: Cosmo Chou Link: https://lore.kernel.org/linux-rtc/20260716125142.1801599-1-chou.cosmo@gmail.com/ Link: https://patch.msgid.link/20260717193705.2003175-1-chou.cosmo@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 27f640cd92eebf5c2f64336be7ca24f4636390cb Author: Junrui Luo Date: Sun Aug 16 16:01:28 2026 +0800 NFSv4/pnfs: key the data server cache on the NFS version [ Upstream commit 13c23c5cb977f66390795437fd3837887ce1fd75 ] nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4. Two deviceids on one address with different ds_versions[0].version therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL. Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time. Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 3815b894b922e9b4f40b8b6f6d67bf80d44141c9 Author: Junrui Luo Date: Sun Aug 16 16:01:27 2026 +0800 NFSv4.2: fix LAYOUTSTATS send buffer exhaustion [ Upstream commit c75ef2137e749f2673f0617cfdaae53b2bb7195a ] encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that. ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for. The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held. Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation. Fixes: 27c430644369 ("pnfs/flexfiles: encode LAYOUTSTATS flexfiles specific data") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 0879ea157acc1ac6752f6fcb755d1f91a2359238 Author: Mahanta Jambigi Date: Tue Aug 18 09:39:43 2026 +0200 net/smc: free pending qentry in smc_llc_flow_stop() before memset [ Upstream commit 5ee0ceddc7785c6dcf4a8107fef01f0414a354f4 ] smc_llc_flow_stop() resets a flow struct with a blind memset: spin_lock_bh(&lgr->llc_flow_lock); memset(flow, 0, sizeof(*flow)); flow->type = SMC_LLC_FLOW_NONE; spin_unlock_bh(&lgr->llc_flow_lock); If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object. A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct. Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op. Fixes: 555da9af827d ("net/smc: add event-based llc_flow framework") Reviewed-by: Hidayath Khan Signed-off-by: Mahanta Jambigi Link: https://patch.msgid.link/20260818073943.1108383-1-mjambigi@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0fb9a513766071ea9d5f3bf988e39241b8e9ee3b Author: Mahanta Jambigi Date: Tue Aug 18 09:31:07 2026 +0200 net/smc: free stashed qentry before overwrite in REQ_ADD_LINK to ADD_LINK transition [ Upstream commit 036322025d6e440cb75fc6fecbba9a16b271a2ae ] When smc_llc_event_handler() transitions the local LLC flow from SMC_LLC_FLOW_REQ_ADD_LINK to SMC_LLC_FLOW_ADD_LINK on arrival of an ADD_LINK request, it calls smc_llc_flow_qentry_set() unconditionally: if (lgr->llc_flow_lcl.type == SMC_LLC_FLOW_REQ_ADD_LINK) { lgr->llc_flow_lcl.type = SMC_LLC_FLOW_ADD_LINK; smc_llc_flow_qentry_set(&lgr->llc_flow_lcl, qentry); ... } A CONFIRM_LINK or ADD_LINK_CONT arriving while flow->type is SMC_LLC_FLOW_REQ_ADD_LINK is stashed into flow->qentry via the SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT handler (which stores into flow->qentry for any non-NONE flow type). When the subsequent ADD_LINK arrives, the REQ_ADD_LINK branch overwrites flow->qentry with the new pointer without first freeing the stashed allocation, leaking one kmalloc object. The stashed entry has no consumer: smc_llc_wait() is only called from llc_add_link_work, which is not yet scheduled while the flow type remains REQ_ADD_LINK. No waiter is sleeping on llc_msg_waiter at this point. It is safe to unconditionally free any stashed qentry before the overwrite. Call smc_llc_flow_qentry_del() before smc_llc_flow_qentry_set() in the REQ_ADD_LINK branch. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal path where no entry is stashed is a no-op. Fixes: b4ba4652b3f8 ("net/smc: extend LLC layer for SMC-Rv2") Reviewed-by: Hidayath Khan Signed-off-by: Mahanta Jambigi Link: https://patch.msgid.link/20260818073107.466506-1-mjambigi@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8b2d8c70b969bf84f9e248bfaf2a7135129f2eb6 Author: Jamal Hadi Salim Date: Tue Aug 18 05:59:27 2026 -0400 net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue [ Upstream commit 4c660ee8c809637909f4f7eb1017f7b9401c75c4 ] gred_enqueue(), bfifo_enqueue() and plug_enqueue() admit a packet when the current backlog plus the packet length fits within the queue limit: sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (gred default VQ) gred_backlog+qdisc_pkt_len(skb) <= q->limit (gred configured VQ) sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (bfifo) sch->qstats.backlog + skb->len <= q->limit (plug) sch->qstats.backlog and q->backlog are u32, and qdisc_pkt_len()/skb->len are unsigned int, so all sums are computed in 32 bits and wrap at 2^32. Once the true backlog exceeds 4 GiB the wrapped sum becomes small and admission keeps succeeding, so the queue grows without bound and the kernel can be driven to OOM. Promote the sums to u64 so admission stops once the true backlog exceeds the limit. The limit is u32, so the bounded queue stays below 2^32 and the stored u32 backlog never wraps. The bug can only be reproduced as root (albeit with ridiculous setup): attach a gred (or bfifo/plug) qdisc with a limit near 4 GiB, leaving the default VQ unconfigured (for gred), and drive >4 GiB of queued traffic (e.g. via a size table / stab to inflate qdisc_pkt_len, or sustained high-rate traffic). The u32 backlog+len sum wraps at 2^32, admission keeps succeeding, and the queue grows unboundedly to OOM. Fixes: a3eb95f891d6 ("net_sched: gred: add TCA_GRED_LIMIT attribute") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260818095927.15901-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 220cfdb17ff6a7d979359fc23d0ff1991c73d20e Author: Mina Almasry Date: Fri Aug 14 19:13:31 2026 +0000 net: tcp: block mixing readable and unreadable frags [ Upstream commit d9c56501c72fdac937e8b770f31655c46832f1a5 ] Protect tcp_sendmsg_locked() from mistakenly mixing readable and unreadable page fragments in the same SKB. Check that the devmem binding matches the existing SKB's readability. If a mismatch is detected, avoid collapsing and create a new segment. Fixes: bd61848900bff ("net: devmem: Implement TX path") Suggested-by: Eric Dumazet Cc: Pavel Begunkov Cc: Stanislav Fomichev Cc: Bobby Eshleman Signed-off-by: Mina Almasry Link: https://patch.msgid.link/20260814191336.187243-2-almasrymina@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 857681f6835d5b0a7bc4a34a026baeaaf5215623 Author: Eric Dumazet Date: Tue Aug 18 15:12:13 2026 +0000 inetpeer: randomize RB-tree node comparison using SipHash [ Upstream commit 2ee66e9487172fcd189bc52a767c30dad7141c09 ] The inetpeer rate limiting system stores peer entries in a Red-Black tree keyed deterministically on the remote IP address. Because tree lookups walk the RB-tree using standard lexicographical comparisons (inetpeer_addr_cmp), an off-path adversary can predict the exact topology of the tree and the sequence of nodes traversed during lookups (the gc_stack candidate list). By combining deterministic tree traversal with aggressive garbage collection (triggered when tree size exceeds inet_peer_threshold), an attacker can selectively force the eviction of targeted inet_peer nodes. When an evicted node is subsequently re-created upon receiving a new packet, its rate-limiting token bucket (rate_tokens, rate_last) is reset to full capacity. This creates a side-channel primitive allowing off-path attackers to bypass IP-keyed ICMP rate limits and infer open UDP ports (similar to SAD DNS style attacks). Mitigate this by randomizing the RB-tree node comparison logic using SipHash with a secret key (inetpeer_hash_key) initialized via net_get_random_once(). Nodes are ordered in the tree by SipHash(addr, key) rather than raw IP addresses. Because the secret key is unknown to external entities, the tree layout and lookup traversal paths are unpredictable to off-path adversaries, breaking the deterministic eviction gadget. Cache the computed 64-bit SipHash (hash) in struct inet_peer and compute the target hash (dhash) once at the beginning of inet_getpeer() to avoid recomputing SipHash at every step of the RB-tree walk. Fixes: b145425f269a ("inetpeer: remove AVL implementation in favor of RB tree") Reported-by: Michael Blunt Suggested-by: Michael Blunt Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260818151213.3953963-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c7f9740f7a1b2240ef6f2e5f6045d2a4a92368cb Author: Eric Dumazet Date: Thu Apr 30 07:40:04 2026 +0000 ip6mr: plug drop_reason to ip6mr_cache_report() [ Upstream commit 8d59a7a188c0a7f6d52e4a829f3ce75534255d76 ] - Check mrt->mroute_sk earlier in the function. - Use sock_queue_rcv_skb_reason() instead of sock_queue_rcv_skb(). - Use sk_skb_reason_drop() instead of kfree_skb(). Note that we return -ENOMEM if sock_queue_rcv_skb_reason() failed, as the precise error is not really needed for callers. - Remove one net_warn_ratelimited(). Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260430074004.4133602-1-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 235b42b58601 ("ip6mr: do not clone dst in ip6mr_cache_report()") Signed-off-by: Sasha Levin commit 38778f6abdbda3fdc8b8e175dbc38b9fac841836 Author: Kuniyuki Iwashima Date: Thu Apr 23 05:34:54 2026 +0000 ipmr: Free mr_table after RCU grace period. [ Upstream commit b3b6babf47517fde6b6de2493dea28e8831b9347 ] With CONFIG_IP_MROUTE_MULTIPLE_TABLES=n, ipmr_fib_lookup() does not check if net->ipv4.mrt is NULL. Since default_device_exit_batch() is called after ->exit_rtnl(), a device could receive IGMP packets and access net->ipv4.mrt during/after ipmr_rules_exit_rtnl(). If ipmr_rules_exit_rtnl() had already cleared it and freed the memory, the access would trigger null-ptr-deref or use-after-free. Let's fix it by using RCU helper and free mrt after RCU grace period. In addition, check_net(net) is added to mroute_clean_tables() and ipmr_cache_unresolved() to synchronise via mfc_unres_lock. This prevents ipmr_cache_unresolved() from putting skb into c->_c.mfc_un.unres.unresolved after mroute_clean_tables() purges it. For the same reason, timer_shutdown_sync() is moved after mroute_clean_tables(). Since rhltable_destroy() holds mutex internally, rcu_work is used, and it is placed as the first member because rcu_head must be placed within <4K offset. mr_table is alraedy 3864 bytes without rcu_work. Note that IP6MR is not yet converted to ->exit_rtnl(), so this change is not needed for now but will be. Fixes: b22b01867406 ("ipmr: Convert ipmr_net_exit_batch() to ->exit_rtnl().") Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260423053456.4097409-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 235b42b58601 ("ip6mr: do not clone dst in ip6mr_cache_report()") Signed-off-by: Sasha Levin commit 65f87de5f3c3b3bd611553ff11434a899ca1bc2a Author: Eric Dumazet Date: Thu Apr 9 14:56:20 2026 +0000 net: change sock_queue_rcv_skb_reason() to return a drop_reason [ Upstream commit 900f27fb797c7eaf0b84b7a6516613e19746bc4e ] Change sock_queue_rcv_skb_reason() to return the drop_reason directly instead of using a reference. This is part of an effort to remove stack canaries and reduce bloat. $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 3/7 up/down: 79/-301 (-222) Function old new delta vsock_queue_rcv_skb 50 79 +29 ipmr_cache_report 1290 1315 +25 ip6mr_cache_report 1322 1347 +25 packet_rcv_spkt 329 327 -2 sock_queue_rcv_skb_reason 166 128 -38 raw_rcv_skb 122 80 -42 ping_queue_rcv_skb 109 61 -48 ping_rcv 215 162 -53 rawv6_rcv_skb 278 224 -54 raw_rcv 591 527 -64 Total: Before=29722890, After=29722668, chg -0.00% Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260409145625.2306224-2-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 235b42b58601 ("ip6mr: do not clone dst in ip6mr_cache_report()") Signed-off-by: Sasha Levin commit 84264cb4e541ff7e97649c2f586e9ba3a7c6382c Author: Kuniyuki Iwashima Date: Sat Feb 28 22:17:28 2026 +0000 ipmr: Remove RTNL in ipmr_rules_init() and ipmr_net_init(). [ Upstream commit 4a11adcd9eefb841d4595267bbd4df304a98ded6 ] When ipmr_free_table() is called from ipmr_rules_init() or ipmr_net_init(), the netns is not yet published. Thus, no device should have been registered, and mroute_clean_tables() will not call vif_delete(), so unregister_netdevice_many() is unnecessary. unregister_netdevice_many() does nothing if the list is empty, but it requires RTNL due to the unconditional ASSERT_RTNL() at the entry of unregister_netdevice_many_notify(). Let's remove unnecessary RTNL and ASSERT_RTNL() and instead add WARN_ON_ONCE() in ipmr_free_table(). Note that we use a local list for the new WARN_ON_ONCE() because dev_kill_list passed from ipmr_rules_exit_rtnl() may have some devices when other ops->init() fails after ipmr durnig setup_net(). Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260228221800.1082070-11-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 235b42b58601 ("ip6mr: do not clone dst in ip6mr_cache_report()") Signed-off-by: Sasha Levin commit 53eefb9db0b277aa9f5523ae73aa448198b7c69c Author: Kuniyuki Iwashima Date: Sat Feb 28 22:17:27 2026 +0000 ipmr: Convert ipmr_net_exit_batch() to ->exit_rtnl(). [ Upstream commit b22b01867406bcafbf61b61dccdf5b0afbd89fdc ] ipmr_net_ops uses ->exit_batch() to acquire RTNL only once for dying network namespaces. ipmr does not depend on the ordering of ->exit_rtnl() and ->exit_batch() of other pernet_operations (unlike fib_net_ops). Once ipmr_free_table() is called and all devices are queued for destruction in ->exit_rtnl(), later during NETDEV_UNREGISTER, ipmr_device_event() will not see anything in vif table and just do nothing. Let's convert ipmr_net_exit_batch() to ->exit_rtnl(). Note that fib_rules_unregister() does not need RTNL and we will remove RTNL and unregister_netdevice_many() in ipmr_net_init(). Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260228221800.1082070-10-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 235b42b58601 ("ip6mr: do not clone dst in ip6mr_cache_report()") Signed-off-by: Sasha Levin commit b30f0801b91879cb6ac64a6a6a7810122893c7fa Author: Kuniyuki Iwashima Date: Sat Feb 28 22:17:26 2026 +0000 ipmr: Move unregister_netdevice_many() out of ipmr_free_table(). [ Upstream commit b7fdc3cfb60a4dd80bb71c818fe433d8b3449cf3 ] This is a prep commit to convert ipmr_net_exit_batch() to ->exit_rtnl(). Let's move unregister_netdevice_many() in ipmr_free_table() to its callers. Now ipmr_rules_exit() can do batching all tables per netns. Note that later we will remove RTNL and unregister_netdevice_many() in ipmr_rules_init(). Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260228221800.1082070-9-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 235b42b58601 ("ip6mr: do not clone dst in ip6mr_cache_report()") Signed-off-by: Sasha Levin commit 4012a0656797d208ade3c07a4c990f934a8543a4 Author: Kuniyuki Iwashima Date: Sat Feb 28 22:17:25 2026 +0000 ipmr: Move unregister_netdevice_many() out of mroute_clean_tables(). [ Upstream commit 3810f9529dc7f784b5b958b2a018bb6996cf9077 ] This is a prep commit to convert ipmr_net_exit_batch() to ->exit_rtnl(). Let's move unregister_netdevice_many() in mroute_clean_tables() to its callers. As a bonus, mrtsock_destruct() can do batching for all tables. Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260228221800.1082070-8-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 235b42b58601 ("ip6mr: do not clone dst in ip6mr_cache_report()") Signed-off-by: Sasha Levin commit 4be733a450c86938c91f9c70a56802ef5069764c Author: Pengpeng Hou Date: Sun Aug 16 13:21:09 2026 +0800 net: qlcnic: validate unified ROM sections before loading [ Upstream commit 5e8076e4e4124dae75a3e080ddc20404700d7585 ] The unified ROM parser reads directory, product, and data-descriptor fields from the firmware file. Existing validation forms table and data ends with unchecked additions and multiplications. Malformed values can wrap before they are compared with the firmware size. The parser also dereferences typed pointers at firmware-controlled offsets. Valid descriptor extents alone are insufficient for the consumers. The loader reads a fixed-size bootloader regardless of its declared size, the version parser assumes a 17-byte tail, and a partial final firmware word is read as a full u64. A truncated image can therefore make the driver read beyond the firmware allocation during validation or loading. Replace the pointer-returning parser with bounded range helpers. Validate table entry sizes, descriptor indices, section ranges, the fixed bootloader load length, and the version tail before exposing any section. Read all file fields with unaligned little-endian accessors and assemble a partial final word from only the bytes that remain. Apply the same range checks to the legacy image before reading its fixed fields. Fixes: af19b49152bd ("qlcnic: Qlogic ethernet driver for CNA devices") Signed-off-by: Pengpeng Hou Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816052109.4607-1-pengpeng@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bf87e4c1e58a0839607378f008d3a3aadf963c3a Author: Tetsuo Handa Date: Mon Aug 17 23:08:15 2026 +0900 net: add missing ref_tracker_dir_exit() to net_passive_dec() [ Upstream commit f85dc137aabf357bf3d9fe4c9712121039d83798 ] I found that trying to read /sys/kernel/debug/ref_tracker/* causes NULL pointer dereference crash when alloc_netdev_mqs() via unshare() returned NULL, for commit 9ba74e6c9e9d ("net: add networking namespace refcount tracker") added ref_tracker_dir_exit(&net->refcnt_tracker) to only __put_net() path whereas commit 65b584f53611 ("ref_tracker: automatically register a file in debugfs for a ref_tracker_dir") added ref_tracker_dir_debugfs() to ref_tracker_dir_init() path. Since preinit_net() calls ref_tracker_dir_init(&net->refcnt_tracker) and ref_tracker_dir_init(&net->notrefcnt_tracker), we need to make sure that both ref_tracker_dir_exit(&net->refcnt_tracker) and ref_tracker_dir_exit(&net->notrefcnt_tracker) are called before net_passive_dec() schedules for kmem_cache_free() via net_complete_free(). ref_tracker_dir_exit(&net->refcnt_tracker) is called via put_net() when ns_ref_put() returned true. But put_net() is not called when copy_net_ns() fails. Therefore, call ref_tracker_dir_exit() from net_passive_dec() if put_net() is not yet called. Link: https://sashiko.dev/#/patchset/b06ce35d-e7bc-47a5-8e0a-e82be7e4dd08%40I-love.SAKURA.ne.jp Fixes: 9ba74e6c9e9d ("net: add networking namespace refcount tracker") Reviewed-by: Eric Dumazet Signed-off-by: Tetsuo Handa Link: https://patch.msgid.link/64254d80-9248-466c-8108-95f43bd71117@I-love.SAKURA.ne.jp Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f30cf8fd9872299c0c27f9916252ba2b9f422dce Author: Cen Zhang (Microsoft) Date: Sun Aug 16 21:32:37 2026 -0400 ipv6: avoid divide by zero in rt6_multipath_rebalance [ Upstream commit d2c26c2911dd1a363c488add4fb63eb5f0f28f87 ] rt6_multipath_rebalance() calculates the total eligible nexthop weight in one pass and programs upper bounds in a second pass. Since RTM_NEWROUTE is RTNL-free, a concurrent ignore_routes_with_linkdown update can make the first pass return zero while the second sees an eligible nexthop, causing rt6_upper_bound_set() to divide by zero. UBSAN: division-overflow in net/ipv6/route.c:4845:17 Oops: divide error: 0000 [#1] SMP KASAN NOPTI rt6_upper_bound_set() net/ipv6/route.c:4845 rt6_multipath_rebalance() fib6_add_rt2node() ip6_route_multipath_add() inet6_rtm_newroute() Skip upper-bound calculation when the first pass reports a zero total. This respects the lock-free performance considerations here and solves insecure scenarios. Fixes: bd11ff421d36 ("ipv6: Get rid of RTNL for SIOCDELRT and RTM_DELROUTE.") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Xiang Mei (Microsoft) Reported-by: Cen Zhang (Microsoft) Signed-off-by: Cen Zhang (Microsoft) Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260817013237.2797-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b8f32b0804b4bf0cba0ee0a093e3fd74f11d7166 Author: Eric Dumazet Date: Mon Aug 17 08:25:11 2026 +0000 netdevsim: update queue NAPI association on queue reset [ Upstream commit 07e98a4d5e9c292eae97c9cc5ab0937384e48492 ] In netdevsim, receive queues (struct nsim_rq) embed their own struct napi_struct. When queue reset is performed (e.g. via queue_reset debugfs), nsim_queue_start() swaps in a newly allocated struct nsim_rq, and nsim_queue_mem_free() later deletes and frees the old one. However, nsim_queue_start() failed to update the queue-to-NAPI mapping via netif_queue_set_napi(). As a result, dev->_rx[idx].napi continued to point to the old NAPI struct. After the old queue was freed, a subsequent queue dump via Netlink (NETDEV_CMD_QUEUE_GET) triggered a KASAN slab-use-after-free read in nla_put_napi_id() when accessing rxq->napi->napi_id. Fix this by calling netif_queue_set_napi() in nsim_queue_start() to associate the new NAPI with the RX queue, and clear the association with netif_queue_set_napi(..., NULL) in nsim_del_napi() during teardown. Fixes: 5bc8e8dbef27 ("netdevsim: add queue management API support") Reported-by: syzbot+483a6efbc4882c1201ee@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a82c3d4.f7a79266.2f965f.0024.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260817082511.2300402-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9d7b6916d5f856e0a007f3cc1b0bacc6234a4c6f Author: Ruoyu Wang Date: Sat Aug 15 23:17:37 2026 +0800 net: ipa: balance runtime PM reference on remove error [ Upstream commit 6b9eaa61ff2df63c6eb35d5cd025e2cef0861d76 ] ipa_remove() takes a runtime PM reference before accessing IPA hardware during teardown. If a concurrent modem start or stop keeps ipa_modem_stop() busy across both attempts, the callback intentionally returns without releasing the remaining resources because proceeding with teardown could crash. That return also skips the matching pm_runtime_put_noidle(), leaving the callback's usage-count reference held. Drop only this runtime PM reference before returning. pm_runtime_put_noidle() does not request an idle transition, so the hardware and resources retained on this exceptional path remain untouched while the usage count stays balanced. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 923a6b698447 ("net: ipa: get clock in ipa_probe()") Signed-off-by: Ruoyu Wang Reviewed-by: Alex Elder Link: https://patch.msgid.link/20260815151737.3758320-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5a66873d04b0f95bdecbb9439944956b556dc745 Author: Marek Czernohous Date: Sat Aug 15 21:54:38 2026 +0200 forcedeth: stop the tx_timeout register dump past the requested window [ Upstream commit cfa9178ce2e5b4f2e2a9e8b577a6cff841665aa0 ] nv_tx_timeout() dumps the register window in rows of eight dwords: for (i = 0; i <= np->register_size; i += 32) { netdev_info(dev, "%3x: %08x ... %08x\n", i, readl(base + i + 0), ..., readl(base + i + 28)); The loop bound only checks the row's starting offset, so the final row reads a full 32 bytes from a position that is below the end of the window but too close to it. base is mapped with exactly that length: np->base = ioremap(addr, np->register_size); so the tail of that row is read from beyond the length the driver asked for. Per variant, the last iteration reads past register_size by: NV_PCI_REGSZ_VER1 (0x270): row 0x260 reads to 0x27f, 16 bytes over NV_PCI_REGSZ_VER2 (0x2d4): row 0x2c0 reads to 0x2df, 12 bytes over NV_PCI_REGSZ_VER3 (0x604): row 0x600 reads to 0x61f, 28 bytes over This happens on every supported device, not just one of them. Note that it is not a consequence of the sizes being odd: with i <= register_size the offending row is reached whatever the size, and a size that were a multiple of 32 would overrun by a full row rather than by a remainder. To be precise about the severity: the reads stay inside the BAR. Memory BAR sizes are powers of two, the driver only accepts a region with pci_resource_len() >= register_size (forcedeth.c:5757-5762), and the next power of two at or above each register_size already covers the offending row: 0x400 for 0x270 and 0x2d4, 0x800 for 0x604. ioremap() also rounds the mapped length up to page granularity, so the reads land inside the mapping the CPU has as well. What they leave is the window the driver asked for, not the BAR and not the mapping. That is still a driver reading registers it did not ask for, and it is trivial to avoid, but nobody should expect a fault from it. Changing <= to < is not enough: register_size is a length and every size above is larger than its last row start, so i still reaches the offending row. Check that the whole row fits instead. The trade-off is that a partial trailing row is no longer dumped: 16 bytes for VER1, 20 for VER2, 4 for VER3. That seemed preferable to reading outside the requested window, and to open-coding a second, narrower dump for the remainder in what is a debug-only path. Extending the dump to cover the tail can be done on top if anyone misses those registers. Only reachable with the debug_tx_timeout module parameter, which defaults to false. It has not been observed at runtime: forcing a genuine TX timeout on the reference machine is not something I can do safely, so this rests on the arithmetic above and on a build test, not on a reproduction. UBSAN does not catch it either, since these are MMIO reads rather than an array access. It was found by reading the function while fixing the saved_config_space off-by-one in nv_suspend() and nv_resume(). The dump was introduced with a fixed 0x400 bound while ioremap() mapped only NV_PCI_REGSZ (0x270), so it read about 0x190 bytes too far from the start. Commit 86a0f04387bf ("[PATCH] forcedeth: fix initialization") later replaced 0x400 with np->register_size, which shrank the overrun to the remainder but did not remove it. Fixes: c2dba06dae7d ("[PATCH] forcedeth: rewritten tx irq handling") Signed-off-by: Marek Czernohous Reviewed-by: Simon Horman Reviewed-by: Zhu Yanjun Link: https://patch.msgid.link/178682367886.3748309.6978554332066826294@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bcf88c039af86fdc5e11f0090d62b395919e35b8 Author: Or Har-Toov Date: Sun Aug 16 09:50:15 2026 +0300 net/mlx5: E-Switch, preserve max tx speed on vport state modification [ Upstream commit ad0ae7aefa7a6ede28a549d8dac87456d87ef6d4 ] When modifying vport state, the firmware interprets a zero in the max tx speed field as an intentional reset, which can overwrite previously set values. This patch attempts to fix this by querying the current max tx speed from firmware before modifying the vport state and passing it back in the modification command. If the query fails, fall back to the cached agg_max_tx_speed value to avoid inadvertently resetting the speed. Fixes: 50f1d188c580 ("net/mlx5: Propagate LAG effective max_tx_speed to vports") Signed-off-by: Or Har-Toov Reviewed-by: Mark Bloch Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816065015.3280733-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 38354e591e3efb9a43e063a4706affb4d0353c7a Author: Or Har-Toov Date: Sun Aug 16 09:50:14 2026 +0300 net/mlx5: Move vport DOWN state check out of mlx5_query_vport_max_tx_speed() [ Upstream commit 20f11b5cfa429ba3a2b8ef463d47e820687b4d2e ] mlx5_query_vport_max_tx_speed() was introduced to serve the query_port_speed path, which uses max_tx_speed == 0 when port is down. This is incorrect for callers that need the actual configured speed regardless of vport state, such as modify-vport-state helpers that must preserve the speed across state transitions. Move this logic to the caller function in the verb flow and let mlx5_query_vport_max_tx_speed() return the raw firmware value unconditionally. Fixes: aaecff5e13cd ("RDMA/mlx5: Implement query_port_speed callback") Signed-off-by: Or Har-Toov Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816065015.3280733-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: ad0ae7aefa7a ("net/mlx5: E-Switch, preserve max tx speed on vport state modification") Signed-off-by: Sasha Levin commit 55d18f3ead831ffd96bb96cf13243de487215968 Author: Or Har-Toov Date: Wed May 13 09:36:40 2026 +0300 net/mlx5: Skip disabled vports when setting max TX speed [ Upstream commit c6df9a65cbb0fe7808a4b2872095f4c849b3196a ] When setting vports max TX speed during LAG activation or bond state changes, the code iterates over all eswitch vports. However, some vports may not be enabled yet. Skip vports that are not enabled to avoid sending FW commands for uninitialized vports. Save the LAG aggregated speed in the vport struct so it can be applied when the vport is enabled later. Fixes: 50f1d188c580 ("net/mlx5: Propagate LAG effective max_tx_speed to vports") Signed-off-by: Or Har-Toov Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260513063640.334132-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: ad0ae7aefa7a ("net/mlx5: E-Switch, preserve max tx speed on vport state modification") Signed-off-by: Sasha Levin commit 6f4adc05c788d8a16f70cddff3b95fb0a1356e6c Author: Or Har-Toov Date: Thu Dec 18 17:59:00 2025 +0200 RDMA/mlx5: Implement query_port_speed callback [ Upstream commit aaecff5e13cd98d9a9260bf2ec83ef3a1bda86a6 ] Implement the query_port_speed callback for mlx5 driver to support querying effective port bandwidth. For LAG configurations, query the aggregated speed from the LAG layer or from the modified vport max_tx_speed. Signed-off-by: Or Har-Toov Reviewed-by: Mark Bloch Signed-off-by: Edward Srouji Signed-off-by: Leon Romanovsky Stable-dep-of: ad0ae7aefa7a ("net/mlx5: E-Switch, preserve max tx speed on vport state modification") Signed-off-by: Sasha Levin commit 9137881591f2270801263c6b581d82aa9a82f0c4 Author: Or Har-Toov Date: Thu Dec 18 17:58:46 2025 +0200 IB/core: Add query_port_speed verb [ Upstream commit 51a07ce2fefd061edf4ba552a741c85f07b3e6dd ] Add new ibv_query_port_speed() verb to enable applications to query the effective bandwidth of a port. This verb is particularly useful when the speed is not a multiplication of IB speed and width where width is 2^n. Signed-off-by: Or Har-Toov Reviewed-by: Mark Bloch Signed-off-by: Edward Srouji Signed-off-by: Leon Romanovsky Stable-dep-of: ad0ae7aefa7a ("net/mlx5: E-Switch, preserve max tx speed on vport state modification") Signed-off-by: Sasha Levin commit 0864bab42677c5c2690f750d1134d2a28ff81600 Author: Or Har-Toov Date: Thu Dec 18 17:58:32 2025 +0200 IB/core: Add helper to convert port attributes to data rate [ Upstream commit 2941abac6d0bffd6bf8f438135505b39168a0a08 ] Introduce ib_port_attr_to_rate() to compute the data rate in 100 Mbps units (deci-Gb/sec) from a port's active_speed and active_width attributes. This generic helper removes duplicated speed-to-rate calculations, which are used by sysfs and the upcoming new verb. Signed-off-by: Or Har-Toov Reviewed-by: Mark Bloch Signed-off-by: Edward Srouji Signed-off-by: Leon Romanovsky Stable-dep-of: ad0ae7aefa7a ("net/mlx5: E-Switch, preserve max tx speed on vport state modification") Signed-off-by: Sasha Levin commit 361dfb9322fdc845880bc118b9fbe0093395d9f1 Author: Or Har-Toov Date: Thu Dec 18 17:58:20 2025 +0200 net/mlx5: Add support for querying bond speed [ Upstream commit f0b2fde98065e49795ce6824837b3f53fdf16e5d ] Add mlx5_lag_query_bond_speed() to query the aggregated speed of lag configurations with a bond device. Signed-off-by: Or Har-Toov Reviewed-by: Mark Bloch Signed-off-by: Edward Srouji Signed-off-by: Leon Romanovsky Stable-dep-of: ad0ae7aefa7a ("net/mlx5: E-Switch, preserve max tx speed on vport state modification") Signed-off-by: Sasha Levin commit 70cd46d12d7cccfaa44020ea3e949d74cee827a8 Author: Or Har-Toov Date: Thu Dec 18 17:58:13 2025 +0200 net/mlx5: Handle port and vport speed change events in MPESW [ Upstream commit 28ea6036dad268a055b693d9c06a6f3d126096d3 ] Add port change event handling logic for MPESW LAG mode, ensuring VFs are updated when the speed of LAG physical ports changes. This triggers a speed update workflow when relevant port state changes occur, enabling consistent and accurate reporting of VF bandwidth. Signed-off-by: Or Har-Toov Reviewed-by: Maher Sanalla Reviewed-by: Mark Bloch Signed-off-by: Edward Srouji Signed-off-by: Leon Romanovsky Stable-dep-of: ad0ae7aefa7a ("net/mlx5: E-Switch, preserve max tx speed on vport state modification") Signed-off-by: Sasha Levin commit e59b43028345568b3aacb17b5da9ceb3fc734000 Author: Mark Bloch Date: Sun Aug 16 09:50:13 2026 +0300 net/mlx5: E-Switch, use state lock for vport state changes [ Upstream commit ff0f9b7aa1c756e24a8023eaf684e93774c64194 ] Protect vport admin state modifications and vport iteration with the eswitch state_lock mutex to ensure proper serialization of concurrent vport state changes. Currently, calls to mlx5_modify_vport_admin_state() and loops iterating over eswitch vports can race with each other, potentially leading to inconsistent vport state. Fix this by acquiring esw->state_lock Fixes: 7d0314b11cdd ("net/mlx5e: Modify uplink state on interface up/down") Signed-off-by: Mark Bloch Reviewed-by: Shay Drori Reviewed-by: Or Har-Toov Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816065015.3280733-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 99300ea5c4365b587617b70ed7e826acda880f3e Author: Or Har-Toov Date: Thu Dec 18 17:58:05 2025 +0200 net/mlx5: Propagate LAG effective max_tx_speed to vports [ Upstream commit 50f1d188c580222d7a73e96a338a5dc82360ccc0 ] Currently, vports report only their parent's uplink speed, which in LAG setups does not reflect the true aggregated bandwidth. This makes it hard for upper-layer software to optimize load balancing decisions based on accurate bandwidth information. Fix the issue by calculating the possible maximum speed of a LAG as the sum of speeds of all active uplinks that are part of the LAG. Propagate this effective max speed to vports associated with the LAG whenever a relevant event occurs, such as physical port link state changes or LAG creation/modification. With this change, upper-layer components receive accurate bandwidth information corresponding to the active members of the LAG and can make better load balancing decisions. Signed-off-by: Or Har-Toov Reviewed-by: Maher Sanalla Reviewed-by: Mark Bloch Signed-off-by: Edward Srouji Signed-off-by: Leon Romanovsky Stable-dep-of: ff0f9b7aa1c7 ("net/mlx5: E-Switch, use state lock for vport state changes") Signed-off-by: Sasha Levin commit 409dc14183ad18cd22902dd67b7f138bb5a4f2d1 Author: Or Har-Toov Date: Thu Dec 18 17:57:58 2025 +0200 net/mlx5: Add max_tx_speed and its CAP bit to IFC [ Upstream commit 3df5dd46fca4b20efc4767c61d8ecc7249e83f5b ] Introduce the max_tx_speed field to the query and modify_vport_state structures. Add the esw_vport_state_max_tx_speed capability bit, indicating the firmware support modifying the max_tx_speed field via the MODIFY_VPORT_STATE command. Signed-off-by: Or Har-Toov Reviewed-by: Maher Sanalla Reviewed-by: Mark Bloch Signed-off-by: Edward Srouji Signed-off-by: Leon Romanovsky Stable-dep-of: ff0f9b7aa1c7 ("net/mlx5: E-Switch, use state lock for vport state changes") Signed-off-by: Sasha Levin commit 4d3fb6977248dbbbcd0624c55f55fbc99bbace70 Author: Saeed Mahameed Date: Fri Nov 7 23:04:04 2025 -0800 net/mlx5: E-Switch, support eswitch inactive mode [ Upstream commit 9da611df15aa8d519f9947b88a5c733267cba888 ] Add support for eswitch switchdev inactive mode Inactive mode: Drop all traffic going to FDB, Remove mpfs l2 rules and disconnect adjacent vports. Active mode: Traffic flows through FDB, mpfs table populated, and adjacent vports are connected. Signed-off-by: Saeed Mahameed Signed-off-by: Adithya Jayachandran Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20251108070404.1551708-4-saeed@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: ff0f9b7aa1c7 ("net/mlx5: E-Switch, use state lock for vport state changes") Signed-off-by: Sasha Levin commit ed246bad28d4eb6e49d97f64612707d2cfffd3d0 Author: Saeed Mahameed Date: Fri Nov 7 23:04:03 2025 -0800 net/mlx5: MPFS, add support for dynamic enable/disable [ Upstream commit 9902b6381d76ccd2e08e2703390e8c8a3bcda482 ] MPFS (Multi PF Switch) is enabled by default in Multi-Host environments, the driver keeps a list of desired unicast mac addresses of all vports (vfs/Sfs) and applied to HW via L2_table FW command. Add API to dynamically apply the list of MACs to HW when needed for next patches, to utilize this new API in devlink eswitch active/in-active uAPI. Signed-off-by: Saeed Mahameed Signed-off-by: Adithya Jayachandran Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20251108070404.1551708-3-saeed@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: ff0f9b7aa1c7 ("net/mlx5: E-Switch, use state lock for vport state changes") Signed-off-by: Sasha Levin commit 01677786ed4f01e8f0fbcab2bff2a60be17dcb90 Author: Saeed Mahameed Date: Fri Nov 7 23:04:02 2025 -0800 devlink: Introduce switchdev_inactive eswitch mode [ Upstream commit 0e535824d0bcf7c9bb0532d902283c31c78cd6f3 ] Adds DEVLINK_ESWITCH_MODE_SWITCHDEV_INACTIVE attribute to UAPI and documentation. Before having traffic flow through an eswitch, a user may want to have the ability to block traffic towards the FDB until FDB is fully programmed and the user is ready to send traffic to it. For example: when two eswitches are present for vports in a multi-PF setup, one eswitch may take over the traffic from the other when the user chooses. Before this take over, a user may want to first program the inactive eswitch and then once ready redirect traffic to this new eswitch. switchdev modes transition semantics: legacy->switchdev_inactive: Create switchdev mode normally, traffic not allowed to flow yet. switchdev_inactive->switchdev: Enable traffic to flow. switchdev->switchdev_inactive: Block traffic on the FDB, FDB and representros state and content is preserved. When eswitch is configured to this mode, traffic is ignored/dropped on this eswitch FDB, while current configuration is kept, e.g FDB rules and netdev representros are kept available, FDB programming is allowed. Example: # start inactive switchdev devlink dev eswitch set pci/0000:08:00.1 mode switchdev_inactive # setup TC rules, representors etc .. # activate devlink dev eswitch set pci/0000:08:00.1 mode switchdev Signed-off-by: Saeed Mahameed Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20251108070404.1551708-2-saeed@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: ff0f9b7aa1c7 ("net/mlx5: E-Switch, use state lock for vport state changes") Signed-off-by: Sasha Levin commit ec750e1f82385bb2ea55b05b79de1ea5be29aedd Author: Fan Ye Date: Sat Aug 15 10:21:52 2026 +0000 net: thunderbolt: Count delivered packets in rx_packets and rx_bytes [ Upstream commit c5ae83ee02c04487b1be1d143b791ec2caca888e ] tbnet_poll() increments rx_packets once per received frame because that is the NAPI work unit, and then adds the same number to stats.rx_packets. An skb is handed to the stack only when the last frame of a packet arrives, so once the MTU exceeds TBNET_MAX_PAYLOAD_SIZE the statistic reports frames. tx_packets is bumped once per skb, so the two ends of a link disagree: at MTU 65330 the receiver reports 16 times the packets its sender sent. rx_bytes has the matching problem: frames of a packet that is later dropped mid-assembly are already accounted, so it does not correspond to rx_packets as documented. Account for both where the packet is completed, and leave the NAPI work counter alone. Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Signed-off-by: Fan Ye Reviewed-by: Simon Horman Acked-by: Mika Westerberg Link: https://patch.msgid.link/20260815-tbnet-rx-stats-v1-1-8da375c2cd09@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ac2201b484822793c4e2b2269743708307a3e82a Author: Victor Nogueira Date: Sun Aug 16 17:13:27 2026 -0300 net/sched: add get_fill_size callbacks for actions missing them [ Upstream commit 8e2efb3f45a5c6f7c8f68685c1c4709040aa2fa0 ] Several tc actions - act_police, act_bpf, act_pedit, act_ife, act_sample, act_ct, act_ctinfo and act_tunnel_key among them - provide no get_fill_size() callback, so tcf_action_fill_size() falls back to tcf_action_shared_attrs_size() which does not account for the action-specific netlink attributes emitted inside TCA_ACT_OPTIONS by their dump functions. When an RTM_NEWACTION request with NLM_F_ECHO (or an RTNLGRP_TC listener) creates several actions, tcf_add_notify_msg() allocates the echo skb from this underestimated size. When this happens, the act_api code fails to add all of the fields to the netlink message and, thus, fails to send it. Issue is that, when that happens, this failure doesn't stop the action instances from being added. So any user watching these events will be under the false impression that no actions were created at all. For example, act_pedit overruns with 32 actions of four munge keys each, act_police with 32 policers once the optional rate/peakrate/result/avrate attributes are present. To fix this, add the missing get_fill_size callbacks returning the worst-case size of each action's dump attributes, following the pattern used by act_gact/act_skbedit/act_vlan. Also widen the TCA_GACT_TM accounting in tcf_action_shared_attrs_size() to nla_total_size_64bit(), since actions dump their tcf_t with nla_put_64bit(), which may be preceded by an NLA_PAD attribute. Note: We only provided fixes for the actions we reproduced this bug with as of today. We can send a separate hardening patch for the remaining actions to net-next later. The other pre-existing issues, pointed out by Clashiko [1], will be fixed in upcoming patches. [1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260810164357.1653956-1-victor%40mojatatu.com Fixes: 4e76e75d6aba ("net sched actions: calculate add/delete event message size") Reported-by: Vega Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260816201327.2435335-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c0444d7499f113d6b7803ef0175591464e17525e Author: Ruoyu Wang Date: Fri Aug 14 21:40:53 2026 +0800 net: bridge: Reject descending VLAN tunnel ranges [ Upstream commit b74a072d8fb71d3c9ffba4a17d5943e63266fb38 ] A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 94339443686b ("net: bridge: notify on vlan tunnel changes done via the old api") Signed-off-by: Ruoyu Wang Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260814134053.1387275-1-ruoyuw560@gmail.com Signed-off-by: David S. Miller Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 214fb79b0379cb0214905632a2537c0c33f594eb Author: Cen Zhang (Microsoft) Date: Thu Aug 13 17:53:28 2026 -0400 xsk: fix NULL pointer dereference in __xsk_rcv() [ Upstream commit e37b2abca80473e106176e41712a369fd2f72117 ] In the __xsk_rcv() multi-buffer path, xsk_buff_alloc() is called in a loop without checking its return value. xsk_buff_can_alloc() only counts fill queue entries without validating their addresses, so it can succeed while xsk_buff_alloc() rejects all remaining entries and returns NULL. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:__xsk_rcv+0x426/0xc20 (net/xdp/xsk.c:350) Call Trace: xsk_generic_rcv+0x26d/0x5f0 xdp_do_generic_redirect+0x3c5/0xcf0 do_xdp_generic+0x92f/0xe70 __netif_receive_skb_core.constprop.0+0xf7e/0x2b30 Fix this with a two-stage transaction. First allocate and stage all buffers required for the packet, recycling all staged buffers with xsk_buff_free() if any allocation fails. Only after this stage succeeds, copy the data, reserve the RX descriptors, and release the buffers in an error-free loop. Fixes: 804627751b42 ("xsk: add support for AF_XDP multi-buffer on Rx path") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft) Reviewed-by: Simon Horman Reviewed-by: Jason Xing Link: https://patch.msgid.link/20260813215328.99311-1-blbllhy@gmail.com Signed-off-by: David S. Miller Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4585691b28614bbe33704b0f197fae847627bae8 Author: Maciej Fijalkowski Date: Wed Feb 18 16:00:00 2026 +0100 xsk: avoid double checking against rx queue being full [ Upstream commit f620af11c27b8ec9994a39fe968aa778112d1566 ] Currently non-zc xsk rx path for multi-buffer case checks twice if xsk rx queue has enough space for producing descriptors: 1. if (xskq_prod_nb_free(xs->rx, num_desc) < num_desc) { xs->rx_queue_full++; return -ENOBUFS; } 2. __xsk_rcv_zc(xs, xskb, copied - meta_len, rem ? XDP_PKT_CONTD : 0); -> err = xskq_prod_reserve_desc(xs->rx, addr, len, flags); -> if (xskq_prod_is_full(q)) Second part is redundant as in 1. we already peeked onto rx queue and checked that there is enough space to produce given amount of descriptors. Provide helper functions that will skip it and therefore optimize code. Signed-off-by: Maciej Fijalkowski Acked-by: Stanislav Fomichev Reviewed-by: Jason Xing Link: https://lore.kernel.org/r/20260218150000.301176-1-maciej.fijalkowski@intel.com Signed-off-by: Alexei Starovoitov Stable-dep-of: e37b2abca804 ("xsk: fix NULL pointer dereference in __xsk_rcv()") Signed-off-by: Sasha Levin commit 5f02599590a4e4eb1dde3d17367b2b58dfe5ac4b Author: Rustam Adilov Date: Thu Aug 20 21:20:17 2026 +0500 irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of readl()/writel() [ Upstream commit 58b34b72b64bfbfc5f8ad4d8f229942aff76597e ] When CONFIG_SWAP_IO_SPACE is enabled, readl() performs a swap from little endian device to big endian CPU and vice versa for writel(). This is incorrect for Realtek Interrupt controller as that is a big endian device and so the LE to BE conversions are unwanted. Fix this by converting the MMIO accesses to readl_be() and writel_be(). Fixes: 9f3a0f34b84a ("irqchip: Add support for Realtek RTL838x/RTL839x interrupt controller") Signed-off-by: Rustam Adilov Signed-off-by: Thomas Gleixner Tested-by: Carlo Szelinsky Link: https://patch.msgid.link/20260820162017.28507-1-adilov@disroot.org Signed-off-by: Sasha Levin commit 5aa7bbe0bac89e7b127f0742e5536d02db491c74 Author: Markus Stockhausen Date: Fri Jun 5 23:16:43 2026 +0200 irqchip/irq-realtek-rtl: Add mask for interrupt handling [ Upstream commit 2a3fa7f31f43580edcba5ee9f97473801aa3deec ] When using multiple domains for the Interrupt controller, each one must know which hardware interrupts it serves. Add a mask that is filled during setup and apply it during interrupt handling. Signed-off-by: Markus Stockhausen Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260605211646.2101652-5-markus.stockhausen@gmx.de Stable-dep-of: 58b34b72b64b ("irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of readl()/writel()") Signed-off-by: Sasha Levin commit 2aa9fcf31f3877311d90ed4519df999e6e684d31 Author: Markus Stockhausen Date: Fri Jun 5 23:16:42 2026 +0200 irqchip/irq-realtek-rtl: Add interrupt data structure [ Upstream commit 2568f6926c667e0b4ecf523cb4015acefc40409a ] To prepare for multiple parent interrupt domains add an intermediate data structure. For now this will only host the link to the domain. Additionally adapt a deviating variable name to driver standard "hw_irq". Signed-off-by: Markus Stockhausen Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260605211646.2101652-4-markus.stockhausen@gmx.de Stable-dep-of: 58b34b72b64b ("irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of readl()/writel()") Signed-off-by: Sasha Levin commit 421615e833d73b4c3bd49953a14fdfc5386c93b2 Author: Markus Stockhausen Date: Fri Jun 5 23:16:41 2026 +0200 irqchip/irq-realtek-rtl: Split out parent setup code [ Upstream commit d36c1d1657113fcf442c50e074593d7b712bada1 ] The parent interrupt setup will be extended to support multiple parents. To prepare for that, relocate the code into a separate helper. Although it still works only for a single interrupt prepare the coding so it can be easily extended with a loop for multi parent support. For this reduce the line lengths so that the upcoming indentation still leaves the width below 100 characters. Signed-off-by: Markus Stockhausen Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260605211646.2101652-3-markus.stockhausen@gmx.de Stable-dep-of: 58b34b72b64b ("irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of readl()/writel()") Signed-off-by: Sasha Levin commit f7d818afcc22532cb9e854b204970a8d790576bf Author: Markus Stockhausen Date: Thu Jun 4 20:25:06 2026 +0200 irqchip/irq-realtek-rtl: Add multicore support [ Upstream commit a1a35c09241f0577cc40f65d7372fed01138619d ] The Realtek interrupt driver currently supports only single core systems. So the higher end devices like RTL839x and RTL930x with dual VPEs must be driven with NR_CPU=1. Enhance the driver to support multicore (dual VPE) systems. For this: - Extend the register map for multiple cores - Search for multiple CPU cores in the devicetree - Improve the register helpers to support multiple cores - Add an affinity setter - Enhance the IRQ handler for multiple cores Signed-off-by: Markus Stockhausen Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260604182506.1113440-3-markus.stockhausen@gmx.de Stable-dep-of: 58b34b72b64b ("irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of readl()/writel()") Signed-off-by: Sasha Levin commit a9be52993526640e99b5c49163e9efa9e7f4d93d Author: Markus Stockhausen Date: Thu Jun 4 20:25:05 2026 +0200 irqchip/irq-realtek-rtl: Add/simplify register helpers [ Upstream commit 167883f75f83088a2b32c85ce5e3d0cd1cef157b ] The Realtek interrupt controller has two important registers that are used by the driver in several places - GIMR: global interrupt mask register - IRR: Interrupt routing registers The usage of these registers is very inconsistent. GIMR is addressed directly while IRR has a helper that needs a macro as an input. Harmonize this by providing consistent helpers that improve code readability. The callers of these helpers use classic lock/unlock functions and sometimes use the wrong locking helper. E.g. irqsave variants are used in mask/unmask although not needed. Adapt and fix the surrounding call locations. Signed-off-by: Markus Stockhausen Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260604182506.1113440-2-markus.stockhausen@gmx.de Stable-dep-of: 58b34b72b64b ("irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of readl()/writel()") Signed-off-by: Sasha Levin commit 94834742ef1950d0b6f8726ac6b492f6ccd90b64 Author: Namjae Jeon Date: Thu Aug 20 16:43:15 2026 +0900 smb: server: remove unused DES crypto header [ Upstream commit c5e640fe346177372ff4a51a45b01fcd48c29207 ] The DES crypto header is no longer used after the removal of NTLMv1 authentication. Remove it now that the server no longer selects CRYPTO_LIB_DES. Fixes: ce812992f239 ("ksmbd: remove NTLMv1 authentication") Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 72a3e6e0c8248bb6d305f4fe01f3955a6e9e19fb Author: Thomas Huth Date: Thu Aug 20 08:58:15 2026 +0200 smb: server: Remove obsolete "select CRYPTO_LIB_DES" from Kconfig file [ Upstream commit ed91d80242358ffdf127a34e3b7c9fc445c9e5d1 ] The DES encryption in the smb server code has been removed in 2021 with the removal of the insecure NTLMv1 authentication code. Thus we don't need this "select" statement here anymore. Fixes: ce812992f239f ("ksmbd: remove NTLMv1 authentication") Signed-off-by: Thomas Huth Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 392c985c6b03dfdf4904c0d464f18735ca3c4df8 Author: Runyu Xiao Date: Thu Aug 20 19:27:49 2026 +0800 ALSA: mtpav: shut down output timer before card teardown [ Upstream commit c73cb5b7c159246dd572277c668851a56e516019 ] snd_mtpav_output_timer() rearms chip->timer while holding chip->spinlock and accesses the card-private mtpav state. snd_mtpav_free() currently takes the same lock and calls timer_delete() when the timer is active. This only removes a pending timer; it does not wait for a callback that is already running and does not prevent the callback from rearming the timer. A callback running on another CPU can therefore continue after snd_mtpav_free() releases the lock and access the card-private state while the card is being torn down. It can also rearm the timer after timer_delete() has returned. Call timer_shutdown_sync() without holding chip->spinlock. This waits for any running callback to finish and prevents further rearming before the card-private mtpav state is released. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260820112749.9195-1-runyu.xiao@seu.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bfce0f324efaa605e606cbb3f0bdb8fe5c910c11 Author: Geert Uytterhoeven Date: Wed Aug 19 21:05:19 2026 +0200 spi: amlogic-spisg: Make sure clk_init_data is fully initialized [ Upstream commit b2702908ee23ef31bfcf241a2e07ace0eb76bd71 ] The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. aml_spisg_clk_init() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: cef9991e04aed330 ("spi: Add Amlogic SPISG driver") Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Reviewed-by: Xianwei Zhao Link: https://patch.msgid.link/9fb35ae0aedb7a6db0db6c78a8193c7602dd9d44.1787165329.git.geert+renesas@glider.be Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4d99a477e61fcc779cf8a671f0474d0ea07abca6 Author: Serhat Kumral Date: Thu Aug 6 23:13:58 2026 +0300 RDMA/ucma: Allow path records to exactly fit the output buffer [ Upstream commit 8049741ac93acd3a590dac070e12571fddf0e294 ] ucma_query_path() emits a path record only when the remaining output buffer is strictly larger than struct ib_path_rec_data. A buffer sized exactly for the response header and N complete records therefore gets only N - 1 records, while resp->num_paths still advertises N. A caller sizing its buffer for a single record gets a header claiming one path and no path data at all. ucma_query_ib_service() in the same file computes the record count with a plain division and so accepts an exact fit; make ucma_query_path() behave the same way. Current librdmacm is unaffected because it always sizes the response for six records while the kernel currently reports at most two paths. Other users of the UAPI that provide an exactly sized buffer can observe the truncated response. Fixes: ac53b264b2f3 ("RDMA/ucma: Support querying when IB paths are not reversible") Signed-off-by: Serhat Kumral Link: https://patch.msgid.link/20260806201358.147478-1-serhatkumral1@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b15782627b6562f7b6d628f4699316f26340f835 Author: Haotian Zhang Date: Thu Aug 20 09:41:17 2026 +0800 ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup [ Upstream commit d736eba9c453fedce664fdf592c8b71ecff1932b ] snd_ice1712_probe() performs multiple initialization steps after snd_card_new(), but directly returns on failures from later steps without releasing the ALSA card, causing resource leaks when probing fails. Use snd_devm_card_new() together with scope-based cleanup via __free(snd_card_unref), and clear the card pointer after successful registration to keep it alive. Fixes: ca642da4b33d ("ALSA: ice1712: Allocate resources with device-managed APIs") Suggested-by: Takashi Iwai Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20260820014117.14044-1-vulab@iscas.ac.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 735384a9dd5998933f2b8f75ef8996781c3b47d0 Author: Cássio Gabriel Date: Thu Jun 4 01:48:13 2026 -0300 ALSA: core: Add scoped cleanup helper for card references [ Upstream commit c6c6f0aec6fb4cbcc547bb265315fd76f18be731 ] Several ALSA paths acquire temporary card references with snd_card_ref() and release them manually with snd_card_unref(). control_led.c already defines a local cleanup helper for this pattern, while other core paths still open-code the release. Move the helper to the common ALSA core header and use it in control-layer card-reference paths. This makes the ownership rule explicit and avoids future missing-unref mistakes when adding early exits. No functional change is intended. Signed-off-by: Cássio Gabriel Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260604-alsa-scoped-cleanups-v1-2-10c43152a728@gmail.com Stable-dep-of: d736eba9c453 ("ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup") Signed-off-by: Sasha Levin commit dca93566f0e200344d7636653b18c4d28f093f3f Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:34 2026 +0200 irqchip/gic-v5: Use logical cpu 0 irs_data for dynamic IST allocation [ Upstream commit 9dfcc2187282816d42b9f8aa2b689c732ebbcc01 ] In set-ups with a 2-level IST, L1 table entries are created dynamically when LPIs are allocated. The L1 allocation and mapping, implemented in gicv5_irs_iste_alloc() is carried out in preemtible context and can be carried out on any IRS in the system. Current code indexes the per_cpu_irs_data per cpu array using smp_processor_id() to retrieve the IRS that is local to the core executing gicv5_irs_iste_alloc(). Since that's preemptible context, the core executing that function can change on preemption. Given that every IRS in the system is equivalent to each core, this is not really an issue in that even if the thread is preempted and resumed on a different cpu, the table allocation and mapping to an IRS would work seamlessly regardless. On the other hand, smp_processor_id() spits a legitimate splat on DEBUG_PREEMPT kernels when used in preemtible context and this should be fixed. Given that all IRSes are equivalent from a core perspective in terms of IST initialization, always choose as a policy the IRS local to logical cpu 0, preventing the smp_processor_id() splat. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-6-3743e82c69a4@kernel.org Signed-off-by: Sasha Levin commit 265fdce1efb1b2dbda9f3a9329827a6d36ab2461 Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:32 2026 +0200 irqchip/gic-v5: Fix gicv5_init_common() error paths [ Upstream commit 183750b276c229c5253b3b11581f6cd8877b753e ] Current code fails to disable interrupts on gicv5_starting_cpu() failure and to set the handle_arch_irq pointer to NULL if gicv5_irs_enable() fails. Update the respective error paths to fix them. Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-4-3743e82c69a4@kernel.org Signed-off-by: Sasha Levin commit 76ed544059cae6bd3de02e0afba7ff84ff866872 Author: Lorenzo Pieralisi Date: Wed Aug 12 11:10:30 2026 +0200 irqchip/gic-v5: Check for NULL LPI domain on domain teardown [ Upstream commit aa079dbf4c2598c2613a0e464efcb2c232753c51 ] In gicv5_free_lpi_domain() the LPI domain being freed can be NULL. Check it and return before trying to free it if it is. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-2-3743e82c69a4@kernel.org Signed-off-by: Sasha Levin commit 099772e948cc7dc9bb8b63cc559b2da5cd50995f Author: Sascha Bischoff Date: Tue Aug 11 15:27:31 2026 +0000 irqchip/gic-v5: Synchronize CPU interface disable [ Upstream commit ac6db0e0bee18cd4385418c752a007e1aba4ec14 ] The write disabling the GICv5 CPU interface is only guaranteed to take effect after a context synchronization event. Without one, execution can return from gicv5_cpu_disable_interrupts() while an interrupt is still able to be taken. Add an ISB after the ICC_CR0_EL1 write to ensure interrupts are disabled before the function returns. No corresponding ISB is added when enabling the interface, as interrupt delivery is asynchronous and there is no obvious benefit to waiting for it. Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support") Signed-off-by: Sascha Bischoff Signed-off-by: Thomas Gleixner Reviewed-by: Lorenzo Pieralisi Link: https://sashiko.dev/#/patchset/20260724104819.1296803-1-sascha.bischoff@arm.com?part=6 Link: https://patch.msgid.link/20260811152630.942023-3-sascha.bischoff@arm.com Signed-off-by: Sasha Levin commit 8f7980033e9f7ecaaecd873a0b5bf6b6c87d7e5a Author: Geert Uytterhoeven Date: Wed Aug 19 21:05:16 2026 +0200 clk: visconti: Make sure clk_init_data is fully initialized [ Upstream commit 39c0e6c844a14945040cca4ccf6997792ab764c4 ] The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. visconti_clk_register_gate() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: b4cbe606dc3674b2 ("clk: visconti: Add support common clock driver and reset driver") Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Reviewed-by: Nobuhiro Iwamatsu Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 58c368552f83068d8952f6e10928c5f65c547300 Author: Geert Uytterhoeven Date: Wed Aug 19 21:05:15 2026 +0200 clk: ti: Make sure clk_init_data is fully initialized [ Upstream commit 3ae1674975d48fb6d343d03ff7961abd6904af1a ] The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. _register_mux() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter is uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: 667f420c09f1417c ("clk: ti: mux: resolve parent clocks by DT index, not by name") Closes: https://lore.kernel.org/CAMuHMdU3yVqoyHC4eNF2NuYo8wy+6ODLoYat4R71X99Mxc_=kw@mail.gmail.com Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Reviewed-by: Mathieu Dubois-Briand Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 41c2ccf0d740eca9c6d34df9777d1aca9fc83d33 Author: Bradley Morgan Date: Sun Aug 9 00:29:01 2026 +0000 prctl: fix PR_SET_MM_AUXV losing the forced AT_NULL terminator [ Upstream commit 5146e0688d86f0654263e4b0e4ff1719b4072f16 ] prctl_set_auxv() copies the user vector into a stack buffer, forces AT_NULL on the last two entries there, and then copies only len bytes into mm->saved_auxv. Which is fine until the vector is shorter than the buffer, because then the forced terminator sits past the end of the copy and never lands in saved_auxv at all. The code even says /* Make sure the last entry is always AT_NULL */ and it does, just not in the part that gets copied. So mm->saved_auxv keeps the stale tail from exec. Reproducing it is easy: from a process with CAP_SYS_RESOURCE (just run it as root), call prctl(PR_SET_MM, PR_SET_MM_AUXV, ...) with a vector that has a couple of entries and no AT_NULL inside len (32 bytes on arm64), and then hexdump /proc/self/auxv, or gcore the process and look at the AUXV note with readelf -n. This is arm64, the new vector was just { AT_UID, 0x1111, AT_GID, 0x2222 }: idx before (from exec) after the prctl [0] AT_SYSINFO_EHDR 0x7ed1d6e000 AT_UID 0x1111 <- new [1] AT_MINSIGSTKSZ 0x1270 AT_GID 0x2222 <- new [2] AT_HWCAP 0x119fff AT_HWCAP 0x119fff <- stale [3] AT_PAGESZ 0x1000 AT_PAGESZ 0x1000 <- stale ... 16 more entries ... <- stale [20] AT_NULL 0x0 AT_NULL 0x0 21 entries before the prctl, still 21 after: the two new ones plus all 19 left over from exec. Every consumer walks the vector until AT_NULL, so what they get now is a vector that never existed at exec, the head from the prctl glued onto the tail of the old binary. gdb and crash pull the AUXV note out of coredumps to find AT_PHDR, AT_ENTRY, AT_SYSINFO_EHDR and friends, and a mixed vector points them at the wrong layout. /proc//auxv and PR_GET_AUXV hand the same mess out to live processes too. Nothing crashes, everything just quietly reads a frankenstein auxv. And callers that terminate their own vector hide the whole thing, which is likely why nobody noticed since PR_SET_MM_AUXV landed in 2012. Nothing exciting security wise either, I mean it needs CAP_SYS_RESOURCE to begin with. prctl_set_mm_map() right above already copies the whole buffer for exactly this reason, so just do the same here. user_auxv is zero initialized and only partially filled from userspace, so the rest is zeros and nothing leaks. Link: https://lore.kernel.org/20260809002901.32591-1-include@grrlz.net Fixes: fe8c7f5cbf91 ("c/r: prctl: extend PR_SET_MM to set up more mm_struct entries") Signed-off-by: Bradley Morgan Cc: Alexey Dobriyan Cc: Cyrill Gorcuno Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 589f8d44c9dca38577eb59edff2b7a74f269a099 Author: Karl Mehltretter Date: Sat Aug 8 14:36:08 2026 +0200 lib/interval_tree: fix allocation warning messages [ Upstream commit d9c0fd5533fb23bc445bd581feb140e966195936 ] WARN_ON_ONCE() takes a condition, not a message. The string literals are always true, so the warnings still trigger but the messages are never printed. Use WARN_ONCE(1, ...) instead to print the messages and keep the once-only behavior. Found with a Coccinelle script. Clang's -Wstring-conversion also flags such calls but is not enabled in kernel builds. Link: https://lore.kernel.org/20260808123608.73613-1-kmehltretter@gmail.com Fixes: 82114e45131f ("lib/interval_tree: add test case for interval_tree_iter_xxx() helpers") Assisted-by: Claude:claude-fable-5 coccinelle Signed-off-by: Karl Mehltretter Reviewed-by: Andrew Morton Reviewed-by: Wei Yang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 5a8f18a7d36919710c622beb8af19fd6f4965e79 Author: Linkai Gong Date: Fri Jul 31 16:04:58 2026 +0800 rtc: gamecube: check return value of devm_rtc_register_device() [ Upstream commit ca45cfa74370644d371b552bef57938c19e3c80c ] gamecube_rtc_probe() ignored the return value of devm_rtc_register_device() and always returned success. Propagate the error so probe fails when RTC registration fails. Fixes: 86559400b3ef ("rtc: gamecube: Add a RTC driver for the GameCube, Wii and Wii U") Signed-off-by: Linkai Gong Link: https://patch.msgid.link/20260731080458.417532-1-gonglinkai@kylinos.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit fdc4b500071a271387a83e55ab544b64a423f8a3 Author: Ruoyu Wang Date: Thu Aug 13 23:31:55 2026 +0800 i2c: ocores: Disable clock on failed resume [ Upstream commit 43eb13f13385a1e7251978a1977ac61b99edef01 ] ocores_i2c_resume() enables the controller clock before reinitializing the hardware. If the clock rate changed while the device was suspended, ocores_init() may reject the resulting prescaler. The callback then returns an error with the clock still enabled, while the controller itself remains disabled. Disable and unprepare the clock when ocores_init() fails so the failed resume path balances the successful clk_prepare_enable() call. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: e961a094afe0 ("i2c: ocores: add common clock support") Signed-off-by: Ruoyu Wang Reviewed-by: Max Filippov Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260813153155.3953577-1-ruoyuw560@gmail.com Signed-off-by: Sasha Levin commit 38c6831fefde0ff89f8d2dcb924f957a89dec414 Author: Biju Das Date: Tue Aug 18 12:09:33 2026 +0100 irqchip/renesas-rzg2l: Fix loss of interrupt [ Upstream commit 50b10bd0c2d721ad38abd1abe3acdefb6caa0944 ] rzg2l_clear_irq_int() and rzg2l_clear_tint_int() perform a read-modify-write on the ISCR/TSCR status registers to clear the bit for the interrupt just handled. Since these registers are write-0-to-clear per bit, this is racy: If another interrupt's status bit gets set between the read and the write, that bit is written back as 0 by the software-constructed value, clearing an interrupt that hasn't been serviced yet and losing it. This can be reproduced by triggering multiple interrupts at once, e.g.: gpioset -c gpiochip0 355=0 353=0 328=0 352=0 Fix this by writing back only the bit being cleared, with all other bits set to 1, instead of read-modify-writing the whole register. Since 1-bits are left unchanged by hardware, concurrently-set status bits for other interrupts are preserved. Fixes: 3fed09559cd8 ("irqchip: Add RZ/G2L IA55 Interrupt Controller driver") Signed-off-by: Biju Das Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260818110937.5816-1-biju.das.jz@bp.renesas.com Signed-off-by: Sasha Levin commit 367dbc320b27d2b3378754d39a835496a9c56b71 Author: Pengpeng Hou Date: Wed Jun 24 13:55:24 2026 +0800 rtc: zynqmp: Return optional clock lookup errors [ Upstream commit 5904c4109554582ce8ded6a4dcfede48b21dbe4d ] devm_clk_get_optional() returns NULL when the optional clock is absent, but returns an ERR_PTR when the clock provider lookup fails. Probe currently keeps the ERR_PTR and then passes it to clk_get_rate(). Return the lookup error instead. A truly absent optional clock still reaches the existing calibration fallback through clk_get_rate(NULL). Signed-off-by: Pengpeng Hou Fixes: 07dcc6f9c762 ("rtc: zynqmp: Add calibration set and get support") Reviewed-by: Michal Simek Link: https://patch.msgid.link/20260624055524.38522-1-pengpeng@iscas.ac.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit dbaca07f78a82d8d8d6908736c2b8c360bd0ee40 Author: Frank Sorenson Date: Fri Jul 31 12:12:31 2026 -0500 cifs: remove dead size-update blocks in cifs_setattr_unix/nounix [ Upstream commit 60be95527bc8d1b33dca25d2a849268cca11d139 ] Commit 110fee6b9bb5 ("smb: client: fix missing timestamp updates with O_TRUNC") introduced cifs_file_set_size(), which calls netfs_resize_file() and cifs_setsize() on success. cifs_setsize() calls i_size_write(), updating i_size to the new value. The subsequent blocks in both cifs_setattr_unix() and cifs_setattr_nounix(): if ((attrs->ia_valid & ATTR_SIZE) && attrs->ia_size != i_size_read(inode)) { truncate_setsize(inode, attrs->ia_size); netfs_resize_file(&cifsInode->netfs, attrs->ia_size, true); fscache_resize_cookie(cifs_inode_cookie(inode), attrs->ia_size); } are therefore unreachable on the success path: attrs->ia_size == i_size_read(inode) always holds after cifs_file_set_size() succeeds. On the failure path, execution jumps to out/cifs_setattr_exit before reaching these blocks. truncate_setsize() and netfs_resize_file() are redundant with what cifs_file_set_size() already did; fscache_resize_cookie() was moved there by commit fa724e235cfd ("cifs: add fscache_resize_cookie() to cifs_setsize()"). Remove both dead blocks. Fixes: 110fee6b9bb5 ("smb: client: fix missing timestamp updates with O_TRUNC") Signed-off-by: Frank Sorenson Reviewed-by: Huiwen He Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 442c5f1358ced0d4e716778ac06f1e323a7e4f21 Author: Christopher Lusk Date: Wed Jul 29 18:00:17 2026 -0400 smb: client: fix request buffer leak in smb2_new_read_req() [ Upstream commit deb6468f4164640e4dc875f008aa449cf55987a5 ] smb2_new_read_req() allocates the request buffer with smb2_plain_req_init() but only publishes it to the caller with *buf = req at the very end of the function. Two error returns sit in between: rc = smb2_plain_req_init(SMB2_READ, io_parms->tcon, server, (void **) &req, total_len); if (rc) return rc; if (server == NULL) return -ECONNABORTED; [...] rdata->mr = smbd_register_mr(server->smbd_conn, &rdata->subreq.io_iter, true, need_invalidate); if (!rdata->mr) return -EAGAIN; On either of them the buffer is neither released nor handed back, so it is leaked. The caller cannot clean up after it: smb2_async_readv() does 'goto out' on a non-zero return, which skips the cifs_small_buf_release(buf) at async_readv_out, and buf has not been assigned at that point in any case. The write path has never had this problem. smb2_async_writev() registers the memory region inline and jumps to its release label instead of returning: wdata->mr = smbd_register_mr(...); if (!wdata->mr) { rc = -EAGAIN; goto async_writev_out; } Commit b7972092199f ("cifs: smbd: Retry on memory registration failure") changed both sides from -ENOBUFS to -EAGAIN in a single patch, which puts the two shapes next to each other. Only the -EAGAIN return is reachable in practice, because smb2_plain_req_init() calls smb2_reconnect() first and that already fails with -EIO when server is NULL, before anything is allocated. Both returns are given the same treatment here rather than leaving one of them correct only by accident. Because -EAGAIN is a replayable error, the failure also reaches the retry block at the end of smb2_async_readv(), which marks the subrequest NETFS_SREQ_NEED_RETRY, so a failing registration can be retried rather than ending the I/O, and every attempt that reaches it leaks another buffer. smb2_should_replay() short-circuits on tcon->retry, so on a hard mount the attempt count is not bounded by the retrans setting. Only the asynchronous read path is affected. The synchronous SMB2_read() caller passes rdata == NULL and the memory registration block is guarded on rdata. The memory registration failure path was pointed out by the Sashiko AI reviewer while it was reviewing an unrelated patch to smb2_async_readv(). Fixes: bd3dcc6a22a9 ("CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration") Link: https://sashiko.dev/#/patchset/20260729192002.876156-1-clusk%40northecho.dev Link: https://lore.kernel.org/all/20260729192002.876156-1-clusk@northecho.dev/ Assisted-by: Claude:claude-opus-5 Signed-off-by: Christopher Lusk Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 6fd823a8872dca5c02af3e95db3436dcb8d0fa47 Author: Surendra Singh Chouhan Date: Fri Jul 24 19:28:03 2026 +0530 rtc: spacemit: handle regmap_test_bits() error return [ Upstream commit 092755367e1a5fcf0f5405e9425e86907199dfce ] p1_rtc_read_time() called if (!regmap_test_bits(regmap, RTC_CTRL, RTC_EN)) to check if the RTC was enabled. regmap_test_bits() returns 1 if the bit is set, 0 if not set, and a negative error code (e.g. -EIO) if reading the control register fails. Using !regmap_test_bits(...) evaluates a negative error code as boolean false, causing I2C/regmap read failures to be ignored and incorrectly proceeding to read time registers from a failing device. Fix this by capturing the return value of regmap_test_bits() and returning the error code if negative, or -EINVAL if the RTC is disabled. Fixes: a6de182daa2b ("rtc: spacemit: support the SpacemiT P1 RTC") Reviewed-by: Alex Elder Signed-off-by: Surendra Singh Chouhan Link: https://patch.msgid.link/20260724135803.81223-1-kr494167@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 08a59c28c2bdbcd655e99526c86a41dc83834283 Author: Yi Ding Date: Mon Jun 1 20:51:35 2026 -0700 rtc: pcf8563: fix clock provider leak on unbind [ Upstream commit 9c48a53685040bb0de45a640b34055cbbfc69d4f ] pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference. The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own). Fixes: a39a6405d5f9 ("rtc: pcf8563: add CLKOUT to common clock framework") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yi Ding Link: https://patch.msgid.link/20260602035135.62264-1-yi.s.ding@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 28701b74c22d2a43ddf7aebb6378e60c18323865 Author: GuoHan Zhao Date: Tue Jul 14 10:43:52 2026 +0800 virtio: rtc: time out alarm requests [ Upstream commit 68e00d9212929805b40dcb9166755610f4f4acee ] RTC class operations run with rtc_device.ops_lock held. The virtio RTC alarm requests currently wait without a timeout for the device to return their requestq buffers. On surprise removal, virtio-pci marks the virtqueues broken before unregistering the virtio device. If an alarm request is waiting when the device stops responding, viortc_remove() blocks in viortc_class_stop() while trying to acquire ops_lock. The request cannot complete and device removal hangs until the waiting task is signalled. Use the same 60-second timeout as clock read requests for alarm reads, alarm programming, and alarm interrupt enable requests. The existing message reference counting keeps a timed-out request alive until a late response or device teardown. Fixes: 9d4f22fd563e ("virtio_rtc: Add RTC class driver") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: GuoHan Zhao Reviewed-by: Peter Hilber Signed-off-by: Michael S. Tsirkin Message-ID: <20260714024352.71307-1-zhaoguohan@kylinos.cn> Signed-off-by: Sasha Levin commit 6ca752850de3b8162f030793cc15001aec85c4cf Author: Li RongQing Date: Wed Jul 1 19:36:08 2026 +0800 vdpa/mlx5: fix wrong list iterated in add_direct_chain error path [ Upstream commit 23ae56d9e74c122f95cae71ae3b9fc259fb88446 ] In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path. Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code") Signed-off-by: Li RongQing Acked-by: Eugenio Pérez Reviewed-by: Dragos Tatulea Signed-off-by: Michael S. Tsirkin Message-ID: <20260701113608.1972-1-lirongqing@baidu.com> Signed-off-by: Sasha Levin commit 4d059e7af5e92142348acba6a68194b90b7117f5 Author: Li RongQing Date: Mon Jun 29 11:35:38 2026 +0800 virtio_pci: fix wrong queue index for admin vq in intx path [ Upstream commit dc3f1eef9ab678c396baf5df12aba61db061aa8c ] In vp_find_vqs_intx(), the admin vq was set up using the local queue_idx counter instead of avq->vq_index (the actual queue index obtained from the device). This differs from vp_find_vqs_msix() which correctly uses avq->vq_index. Using the wrong index causes the admin virtqueue to be mapped to an incorrect hardware queue. Fix it by using avq->vq_index consistent with the msix path. Fixes: af22bbe1f4a5 ("virtio: create admin queues alongside other virtqueues") Signed-off-by: Li RongQing Message-ID: <20260629033538.2476-1-lirongqing@baidu.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 4f723111a852bb11e47ec86546207096879db193 Author: Yufeng Wang Date: Fri Jun 26 15:04:38 2026 +0800 vhost/net: fix clear_user start address in VHOST_GET_FEATURES_ARRAY [ Upstream commit 92a7b138f2453bf067628de0c5ec563cc8ad16d5 ] The clear_user() call in VHOST_GET_FEATURES_ARRAY incorrectly starts at argp, which is the beginning of the features array, overwriting the data just written by copy_to_user(). It should start after the copied elements at argp + copied * sizeof(u64) to only zero the trailing unused space. Use size_mul() for both the offset and length calculations so the arithmetic stays consistent with the surrounding code and remains overflow-safe. Fixes: 333c515d1896 ("vhost-net: allow configuring extended features") Signed-off-by: Yufeng Wang Acked-by: Eugenio Pérez Signed-off-by: Michael S. Tsirkin Message-ID: <20260626070438.59149-1-r4o5m6e8o@163.com> Signed-off-by: Sasha Levin commit 6dd28e32f4d81a0d57c732b9900de24184e60a7d Author: Denis V. Lunev Date: Wed Jun 24 16:08:45 2026 +0200 virtio_balloon: quiesce balloon work before device shutdown [ Upstream commit 7e17eef04600c399c7e0f5ce765da5cf9d40d8e1 ] Commit 8bd2fa086a04 ("virtio: break and reset virtio devices on device_shutdown()") added a generic virtio bus .shutdown handler that breaks and resets every virtio device during device_shutdown(), i.e. on reboot and kexec. virtio_balloon provides no .shutdown of its own, so that generic path runs while the balloon's asynchronous work is still armed. Once the device has been broken, virtqueue_add_inbuf() in virtballoon_free_page_report() returns -EIO and trips its WARN_ON_ONCE(). On a kernel booted with panic_on_warn that turns an ordinary reboot, for example a kexec based upgrade, into a fatal panic in the middle of device_shutdown(), so the machine never reaches the new kernel. Relaxing that single WARN_ON_ONCE() would only hide the symptom: the inflate/deflate and OOM paths do not warn, they call wait_event(vb->acked, ...) and would instead block forever on a broken queue that can no longer complete. The device has to be quiesced, not just kept quiet. Add a .shutdown handler that quiesces the balloon via the shared virtballoon_quiesce() helper while the device is still alive, and only then breaks and resets it via virtio_device_shutdown(). Unlike virtballoon_remove() the balloon workqueue is not destroyed, as shutdown does not free the device and cancel_work_sync() together with stop_update already prevent any further work from being queued. Fixes: 8bd2fa086a04 ("virtio: break and reset virtio devices on device_shutdown()") Signed-off-by: Denis V. Lunev Reviewed-by: David Hildenbrand (Arm) Signed-off-by: Michael S. Tsirkin Message-ID: <20260624140846.2616797-4-den@openvz.org> Signed-off-by: Sasha Levin commit 808b1751540dd6c269e7e7cece8a0c12fab4880e Author: Denis V. Lunev Date: Wed Jun 24 16:08:44 2026 +0200 virtio_balloon: factor out virtballoon_quiesce() [ Upstream commit 29536a923a9412812eb3e378258019b54538a220 ] virtballoon_remove() stops all of the balloon's asynchronous work (the free page reporting worker, the inflate/deflate and stats workers, the OOM notifier and the free page shrinker) before tearing the device down. A following change needs the same teardown from a .shutdown handler, so move it into a virtballoon_quiesce() helper. No functional change. Signed-off-by: Denis V. Lunev Reviewed-by: David Hildenbrand (Arm) Signed-off-by: Michael S. Tsirkin Message-ID: <20260624140846.2616797-3-den@openvz.org> Stable-dep-of: 7e17eef04600 ("virtio_balloon: quiesce balloon work before device shutdown") Signed-off-by: Sasha Levin commit 0d7b20057d4fde993d5cc7c50cf30dee5d72dea5 Author: Denis V. Lunev Date: Wed Jun 24 16:08:43 2026 +0200 virtio: add virtio_device_shutdown() helper [ Upstream commit 0d8aebe089b4ba887e792884cf041ce9f1040ff4 ] The generic virtio bus .shutdown handler, virtio_dev_shutdown(), breaks and resets a device once it has established that the driver has no .shutdown of its own. A driver that does implement .shutdown, to quiesce its own activity first, still needs the same break and reset afterwards and would otherwise have to open code it. Factor the break + synchronize_cbs + reset sequence out of virtio_dev_shutdown() into an exported virtio_device_shutdown() helper so such drivers can reuse it instead of duplicating the core logic. No functional change. Signed-off-by: Denis V. Lunev Reviewed-by: David Hildenbrand (Arm) Signed-off-by: Michael S. Tsirkin Message-ID: <20260624140846.2616797-2-den@openvz.org> Stable-dep-of: 7e17eef04600 ("virtio_balloon: quiesce balloon work before device shutdown") Signed-off-by: Sasha Levin commit 68b726b3a01fb02a68843781b17d05ef3d759987 Author: Linfeng Sun  Date: Sat Jun 20 18:09:59 2026 +0800 vdpa_sim: fix cleanup after worker creation failure [ Upstream commit bd670e5dfd2b01fd9692f61fa1456434c54026a4 ] vdpasim_create() leaves vdpasim->worker as an ERR_PTR when kthread_run_worker() fails. The error path then drops the device reference, which releases the partially initialized simulator. vdpasim_free() unconditionally passes the worker pointer to kthread_destroy_worker(), so the ERR_PTR is dereferenced and can trigger a general protection fault. Store the worker error, clear the pointer, and only clean up the worker when it was successfully initialized. Also make the release path tolerate partially initialized objects by guarding virtqueue and IOTLB cleanup, since the same release path can be reached from other initialization failures. I found this bug myself, though the patch was written with AI assistance. Fixes: 76acfa7bc54f ("vdpa_sim: use kthread worker") Assisted-by: OpenAI-Codex:GPT-5 Reviewed-by: Eugenio Pérez Signed-off-by: Linfeng Sun  Message-ID: <20260620100959.2070316-1-slf@hdu.edu.cn> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 8b3edaa10a3039fe01c9f34629cdfe5fccc3db79 Author: Michael S. Tsirkin Date: Sun Jul 5 02:24:18 2026 -0400 virtio_balloon: disable indirect descriptors [ Upstream commit 281eb4732aae5473141b84e106fe906c69b2ff3d ] The page reporting callback submits an sg list to the reporting virtqueue. With VIRTIO_RING_F_INDIRECT_DESC negotiated and total_sg > 1 (which it typically is), virtqueue_add reports it to the host by allocating an indirect descriptor via kmalloc(GFP_KERNEL). This is not pretty: the reporting worker isolates potentially hundreds of MB of free pages from the buddy allocator (reported pages are at least pageblock_order, and the sg can contain up to PAGE_REPORTING_CAPACITY entries of varying orders). As the result, very theoretically, the kmalloc might trigger OOM when we have in fact a ton of free memory. Clear VIRTIO_RING_F_INDIRECT_DESC, to avoid using indirect descriptors. Fixes: b0c504f15471 ("virtio-balloon: add support for providing free page reports to host") Assisted-by: Claude:claude-opus-4-6 Acked-by: David Hildenbrand (Arm) Signed-off-by: Michael S. Tsirkin Message-ID: <73fac8a629fd9aca7bb3265ac243a769c28af25d.1783232420.git.mst@redhat.com> Signed-off-by: Sasha Levin commit 5fe03b5257095e2beef0bc79e1f068fbd09a24c7 Author: Tetsuo Handa Date: Sat Aug 15 15:50:13 2026 +0900 net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs() [ Upstream commit 0b1c2af8a22c35cb099c735c2f63ea3ba757557d ] sashiko is reporting that trying to read /sys/kernel/debug/ref_tracker/* causes use-afer-free crash when either alloc_percpu() or dev_addr_init() in alloc_netdev_mqs() failed, for commit 4d92b95ff2f9 ("net: add net device refcount tracker infrastructure") added ref_tracker_dir_exit() to only free_netdev() path. Closes: https://sashiko.dev/#/patchset/56c707e7-1fb0-43ec-b8fb-cf6f451e513e%40I-love.SAKURA.ne.jp Fixes: 4d92b95ff2f9 ("net: add net device refcount tracker infrastructure") Signed-off-by: Tetsuo Handa Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/b06ce35d-e7bc-47a5-8e0a-e82be7e4dd08@I-love.SAKURA.ne.jp Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4f80425ad5a06a124026bcdcda48803bfa44f697 Author: Ruoyu Wang Date: Thu Aug 13 23:31:26 2026 +0800 bonding: initialize err for empty target lists [ Upstream commit 8ccc9bf9afeeb46a437081c07154fbf5964682b2 ] Empty NLA_NESTED attributes are valid, and bonding uses them to clear the ARP and NS target lists. When either target attribute is empty, nla_for_each_nested() does not execute, so err retains an uninitialized value before it is tested. The request can consequently return an unpredictable error after clearing the targets. Initialize err to zero so an empty target list completes successfully. Non-empty lists still propagate errors from __bond_opt_set() unchanged. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 4fb0ef585eb2 ("bonding: convert arp_ip_target to use the new option API") Signed-off-by: Ruoyu Wang Reviewed-by: Nikolay Aleksandrov Acked-by: Jay Vosburgh Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260813153126.3952893-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 795e7b3a356e85a5ebfabb636089dae4091e4c29 Author: Nikolay Kulikov Date: Mon Aug 10 22:10:02 2026 +0300 mlxbf-bootctl: fix the build error with FIELD_PREP() [ Upstream commit 46b14c6f11f558362391e308f4f184ee867ef58f ] rsh_log_store() calls the FIELD_PREP() macro without including the required header file, resulting a build error: CC drivers/platform/mellanox/mlxbf-bootctl.o drivers/platform/mellanox/mlxbf-bootctl.c: In function ‘rsh_log_store’: drivers/platform/mellanox/mlxbf-bootctl.c:429:16: error: implicit declaration of function ‘FIELD_PREP’ [-Wimplicit-function-declaration] 429 | data = FIELD_PREP(MLXBF_RSH_LOG_TYPE_MASK, MLXBF_RSH_LOG_TYPE_MSG); | ^~~~~~~~~~ Fix this by including the file. Fixes: e9d1b2d0f7d0 ("mlxbf-bootctl: Add sysfs file for BlueField boot log") Signed-off-by: Nikolay Kulikov Link: https://patch.msgid.link/20260810-mellanox_fix_implicit_declaration-v1-1-352e647b8f28@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 2c09cadec116eba3fdbcb5d8d8641f6777d4a11f Author: Hemanth Selam Date: Wed Aug 12 14:30:12 2026 +0530 platform/x86/amd/hsmp: Reject negative power cap writes in hwmon [ Upstream commit 3921bb8635ff2836622df1cdf3194d4f3c1835a4 ] hsmp_hwmon_write() takes the user-supplied hwmon value as a signed long and assigns "val / MICROWATT_PER_MILLIWATT" to msg.args[0], which is a __u32. MICROWATT_PER_MILLIWATT is an unsigned long, so a negative write to power1_cap (e.g. "echo -1 > power1_cap") is first converted to a huge unsigned value by the division and then stored into the u32 argument. As a result a nonsensical, multi-gigawatt socket power limit is sent to the SMU via HSMP_SET_SOCKET_POWER_LIMIT instead of the write being rejected. Reject negative values with -EINVAL before the conversion. Tested with HSMP enabled: CAP=$(dirname $(grep -l amd_hsmp_hwmon \ /sys/class/hwmon/hwmon*/name | head -1))/power1_cap # negative write echo -1000000 > $CAP ; echo "ret=$?" # valid positive write must still work echo 400000000 > $CAP ; echo "ret=$?" Before: # echo -1000000 > $CAP ; echo "ret=$?" ret=0 <- accepted; bogus limit sent to SMU # echo 400000000 > $CAP ; echo "ret=$?" ret=0 After: # echo -1000000 > $CAP ; echo "ret=$?" bash: echo: write error: Invalid argument ret=1 <- rejected with -EINVAL # echo 400000000 > $CAP ; echo "ret=$?" ret=0 <- valid write still works Fixes: 92c025db52bb ("platform/x86/amd/hsmp: Report power via hwmon sensors") Signed-off-by: Hemanth Selam Link: https://patch.msgid.link/20260812090012.140193-1-hemanth.selam@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit ace1ba5fca0ab775b3641e154bcbc3ccde26a71a Author: Guangshuo Li Date: Wed Jul 8 17:09:37 2026 +0800 platform/x86: hp-bioscfg: fix password encoding bounds check [ Upstream commit e213939ed9e6e6badf7aa48c4c8dd9a9cdf00615 ] The password PSWD_ENCODINGS parser reads password_obj[elem + pos_values] while copying the supported password encodings from the ACPI package. The outer loop only guarantees that elem is within password_obj_count. The encoding count is bounded by MAX_ENCODINGS_SIZE, but that does not guarantee that the ACPI package contains enough entries for all elem + pos_values accesses. A malformed package can therefore declare a non-zero encoding count without providing enough string objects, causing the parser to read past the ACPI package array and pass an out-of-bounds string pointer and length to hp_convert_hexstr_to_str(). Add the same computed-index bounds check used by the other offset-based package parsing loops before reading password_obj[elem + pos_values]. Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes") Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260708090937.740435-1-lgs201920130244@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 4d35c6d6980855b2053d42d3d0ac69f222b3dd4d Author: Nguyen Dinh Phi Date: Fri Aug 14 01:30:20 2026 +0800 vsock: use sock_error() to consume sk_err after a failed connect [ Upstream commit 96cbf89993091a163bfedec52a3bd683dc94b3b4 ] vsock_connect() returns sk_err to userspace but does not clear it: if (sk->sk_err) { err = -sk->sk_err; For a blocking connect() the error has already been delivered as connect()'s return value, so leaving it set causes subsequent operations like poll()/epoll() to keep reporting POLLERR even though the connect failure was already delivered. The error should be consumed once it has been returned to userspace. Switch to sock_error(), which reads and clears sk_err atomically, matching the behavior of other protocol implementations such as __inet_stream_connect(). Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Tested-by: Wupeng Ma Reviewed-by: Stefano Garzarella Signed-off-by: Nguyen Dinh Phi Link: https://patch.msgid.link/20260813173024.2362935-4-phind.uet@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 36e5fa009f98a4edbe1783ac11c0df672b224742 Author: Nguyen Dinh Phi Date: Fri Aug 14 01:30:18 2026 +0800 vsock: don't check the listener's sk_err in vsock_accept() [ Upstream commit b8c899cf5e7be29840a172c183dedd8d3e7a0287 ] Syzbot reported an issue which can be reproduced with these steps: r0 = socket(AF_VSOCK, SOCK_STREAM, 0) bind(r0, {VMADDR_CID_ANY, PORT}) connect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (self-connect) listen(r0, backlog) -> 0 r1 = socket(AF_VSOCK, SOCK_STREAM, 0) connect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0 accept(r0) -> -1, EPROTO (stale sk_err) Basically, it creates a socket (r0) and triggers a self-connect after binding it. This self-connect fails with EPROTO because it loops back to r0 while the socket is still in the TCP_SYN_SENT state, causing it to be incorrectly dispatched to the connecting-client path. The unexpected packet type encountered there sets sk_err to EPROTO. After that, it invokes a listen() call on the same socket. This listen() call succeeds because the kernel's listening path never inspects or clears sk_err. Then, a new socket (r1) is created as a normal client and connects to r0. However, vsock_accept() rejects this incoming connection because the listener's sk_err still holds the EPROTO error from the earlier failed self-connect. This rejection causes the child socket created for r1's connection to never be freed on virtio or hyperv transports; only the VMCI transport implements pending_work to revisit and clean up a rejected socket. For a non-blocking connect(), vsock_connect() may return -EINPROGRESS immediately, and vsock_connect_timeout() can later set sk->sk_err asynchronously. Since no vsock transport ever sets sk_err on a socket while it is in TCP_LISTEN state, checking it in vsock_accept() serves no purpose and only carries forward errors left behind by earlier, unrelated connection attempts on the same socket. Remove the checks so accept() no longer rejects valid incoming connections because of a stale error, which also avoids the resource leak described above. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678 Suggested-by: Michal Luczaj Signed-off-by: Nguyen Dinh Phi Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20260813173024.2362935-2-phind.uet@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 06c95182234ae8df609411190ded11b506ad8360 Author: Laurence Rowe Date: Thu Apr 2 13:49:18 2026 -0700 vsock: avoid timeout for non-blocking accept() with empty backlog [ Upstream commit 98f28d8d6e5a5ed058dd37854c19e9b3bae72eff ] A common pattern in epoll network servers is to eagerly accept all pending connections from the non-blocking listening socket after epoll_wait indicates the socket is ready by calling accept in a loop until EAGAIN is returned indicating that the backlog is empty. Scheduling a timeout for a non-blocking accept with an empty backlog meant AF_VSOCK sockets used by epoll network servers incurred hundreds of microseconds of additional latency per accept loop compared to AF_INET or AF_UNIX sockets. Signed-off-by: Laurence Rowe Reviewed-by: Bobby Eshleman Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20260402204918.130395-1-laurencerowe@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: b8c899cf5e7b ("vsock: don't check the listener's sk_err in vsock_accept()") Signed-off-by: Sasha Levin commit df8f661b4f32976e4b69b6b732307a82020c28e9 Author: HyeongJun An Date: Fri Aug 14 22:25:35 2026 +0900 platform/x86: dell-wmi-sysman: Fix instance ID bounds [ Upstream commit 5ab078e3241da0beec2022254b5811a8a52cff84 ] The get_instance_id() macro walks the per-type attribute array with 'i <= instances_count'. Each array is allocated with exactly instances_count entries, so the valid range is [0, instances_count) and the last iteration reads one element past the end. On a name miss that out-of-bounds attribute_name is handed to strcmp(), which reads on until it finds a NUL byte. Every kobject in these ksets is built from an entry that was populated, so a miss does not look reachable from sysfs today. The bound is wrong either way and the read is out of bounds. The matching macro in hp-bioscfg carried the same off-by-one and was corrected by commit 25150715e0b0 ("platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro"). That macro takes a kobject pointer out of the out-of-bounds element and dereferences it, so it could fault. This one reads a char array. Use '<' to match the allocation. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260814132535.4169956-1-sammiee5311@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 3e8fe6503d0c14f9d7dc7d5957afc66491c5b23d Author: Mahanta Jambigi Date: Thu Aug 13 09:43:15 2026 +0200 net/smc: hash socket only after full initialisation in smc_sk_init() [ Upstream commit 8acf691d8017012e1476c30e7381513c1e929c94 ] smc_sk_init() calls sk->sk_prot->hash(sk) before several fields are fully initialised: clcsock_release_lock, the saved clcsk_* callbacks, use_fallback/fallback_rsn, and conn.close_work. Once hash() returns the socket is visible to concurrent hash walkers, which can then observe uninitialised state. Move hash(sk) to the end of smc_sk_init() so the socket is published only after it is fully constructed. Fixes: d0e35656d834 ("net/smc: refactoring initialization of smc sock") Reviewed-by: Hidayath Khan Reviewed-by: Sidraya Jayagond Signed-off-by: Mahanta Jambigi Link: https://patch.msgid.link/20260813074315.554926-1-mjambigi@linux.ibm.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6ea95c886d7037b8755a78c0df1d1fe3e62231d5 Author: Karl Mehltretter Date: Mon Aug 17 06:30:57 2026 +0200 8139cp: fix Rx and Tx not being disabled in cp_suspend [ Upstream commit cb7643b78d35392f0f434774d78b4c77b80f677f ] On QEMU rtl8139 model, frames that arrive while the interface is suspended still end up in the stack after resume. With pm_test=devices, which keeps devices suspended for 5s, 200 frames sent to interface during that time and 50 frames after resume, eth0 reports 113 received frames. cp_suspend() is supposed to stop receiver and the transmitter, but the mask is wrong: (~RxOn | ~TxOn) is ~0, nothing is cleared and Cmd still reads 0x0d when cp_suspend() returns. Use ~(RxOn | TxOn) so both bits are actually cleared. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Karl Mehltretter Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260817043057.20099-1-kmehltretter@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3e6b705bc162fc7257645725a7d2cf6c71250318 Author: Baul Lee Date: Sat Aug 15 00:35:47 2026 +0900 vxlan: mdb: Fix use-after-free in vxlan_mdb_flush() [ Upstream commit bc2dc66a6693a78f8c1e6ca2dbebd50f16e2c366 ] vxlan_mdb_flush() iterates over the MDB entries using hlist_for_each_entry_safe(), which only tolerates the removal of the current entry. Contrary to the comment above the loop, the removal of an entry can trigger the removal of another entry. Flushing the remotes of a (*, G) entry also removes the (S, G) entries that were created for its source list, once they are left without remotes: vxlan_mdb_remotes_flush() -> vxlan_mdb_remote_del() -> vxlan_mdb_remote_srcs_del() -> vxlan_mdb_remote_src_del() -> vxlan_mdb_remote_src_fwd_del() -> __vxlan_mdb_del() -> vxlan_mdb_entry_put() Such an entry can be located after the (*, G) entry in the list, as vxlan_mdb_entry_get() returns an existing entry without moving it to the head of the list. This order is obtained by adding the (S, G) entry before the (*, G) entry, the latter with NLM_F_REPLACE, as the addition of the source otherwise fails with -EEXIST. The (S, G) entry is then the entry saved by hlist_for_each_entry_safe() and it is freed while the (*, G) entry is processed. The next iteration calls hlist_del() on it again, writing LIST_POISON1 to LIST_POISON2 [1]. Besides device deletion, the flush is also reachable from RTM_DELMDB with NLM_F_BULK. Fix by re-reading the next entry after the remotes were flushed. The current entry cannot be removed by this flush, as source lists can only be configured on (*, G) entries and the removed entries are (S, G) entries. It is therefore still linked and its next pointer reflects the removals. [1] BUG: KASAN: wild-memory-access in vxlan_mdb_entry_put.part.0+0x328/0x588 Write of size 8 at addr dead000000000122 by task ip/327 CPU: 3 UID: 1000 PID: 327 Comm: ip Not tainted 7.2.0-rc7 #2 PREEMPT Call trace: vxlan_mdb_entry_put.part.0+0x328/0x588 vxlan_mdb_flush+0x1d8/0x25c vxlan_mdb_fini+0x8c/0x100 vxlan_uninit+0x1c/0x7c unregister_netdevice_many_notify+0x954/0xd4c rtnl_dellink+0x210/0x530 rtnetlink_rcv_msg+0x434/0x4d0 netlink_rcv_skb+0xc4/0x204 rtnetlink_rcv+0x18/0x24 netlink_unicast+0x4b8/0x548 netlink_sendmsg+0x29c/0x560 ____sys_sendmsg+0x390/0x3ec ___sys_sendmsg+0x114/0x188 __sys_sendmsg+0xf0/0x178 __arm64_sys_sendmsg+0x48/0x60 invoke_syscall.constprop.0+0x58/0x180 el0_svc_common.constprop.0+0x74/0x140 do_el0_svc+0x30/0x40 el0_svc+0x38/0x98 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Fixes: a3a48de5eade ("vxlan: mdb: Add MDB control path support") Signed-off-by: Baul Lee Reviewed-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260814153547.29567-1-baul.lee@xbow.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5f22943cd2c84687b1a5bbe8da795ae96fe4d1e0 Author: Xu Rao Date: Tue Aug 18 16:38:08 2026 +0800 ALSA: hda: Fix connection list comparison in proc output [ Upstream commit c139e7e44f58a6f8ddc9d850ea9924d34963b5da ] print_conn_list() compares the raw hardware connection list with the connection list cached by the HDA driver. When they differ, it prints an additional "In-driver Connection" line so that /proc/asound/card*/codec#* shows the topology actually used by the driver. The comparison currently passes conn_len directly to memcmp(). However, conn_len is a number of connection-list entries, while memcmp() expects a size in bytes. Both list and conn are arrays of hda_nid_t, which is u16, so only half of the connection data is compared. For example, for two-entry lists such as: hardware: 0x0c 0x0d cached: 0x0c 0x0e conn_len is 2, and the current comparison checks only the first hda_nid_t. The lists are therefore incorrectly treated as identical even though the second connection differs. This can happen legitimately when codec fixups replace a cached connection list with snd_hda_override_conn_list(). The codec routing used by the driver is not affected, but the proc output can hide the overridden driver-visible routing and provide misleading topology information during codec debugging. Convert the entry count to a byte size so that memcmp() covers the complete connection list. Fixes: 8b2c7a5c404d ("ALSA: hda - Add In-driver connection info") Signed-off-by: Xu Rao Link: https://patch.msgid.link/7B802A4E225CC808+20260818083808.2735120-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a5129155ca9fba40d77ff19ffead8244e88d6f9c Author: Baokun Li Date: Sat Aug 8 12:13:39 2026 +0800 fuse: check for NULL root inode in fuse_fill_super_submount [ Upstream commit 928f659a3e3650978a5b4829cc982324f72b474b ] fuse_iget() can return NULL when its inode allocation fails, but fuse_fill_super_submount() passed the result straight to get_fuse_inode() and decremented fi->nlookup without checking it: root = fuse_iget(sb, parent_fi->nodeid, ...); fi = get_fuse_inode(root); fi->nlookup--; Inside fuse_iget() the inode allocation can fail and return NULL. The submount root takes the iget5_locked() path, whose alloc_inode() can fail under memory pressure (the auto-submount branch can fail the same way in new_inode() or fuse_alloc_submount_lookup()): inode = iget5_locked(sb, nodeid, fuse_inode_eq, fuse_inode_set, &nodeid); if (!inode) return NULL; A NULL root makes get_fuse_inode() a container_of() on NULL and the nlookup decrement a write to a bogus address, oopsing the mount. With CONFIG_KASAN the following null pointer dereference is reported when the root inode allocation of an auto-submount fails (e.g. under memory pressure): ================================================================== BUG: KASAN: null-ptr-deref in fuse_get_tree_submount+0x656/0x8b0 Read of size 8 at addr 00000000000002b0 by task ls/942 CPU: 0 PID: 942 Comm: ls Tainted: G W 6.6 #15 Call Trace: fuse_get_tree_submount+0x656/0x8b0 vfs_get_tree+0x48/0x140 fc_mount+0x13/0x50 fuse_dentry_automount+0x7a/0xb0 __traverse_mounts+0xca/0x330 step_into+0x339/0xac0 path_lookupat+0xc5/0x2f0 filename_lookup+0x163/0x2a0 vfs_statx+0xd5/0x200 do_statx+0x83/0xd0 __x64_sys_statx+0xa0/0xc0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ================================================================== Return -ENOMEM instead; the caller tears down the partially built superblock on error, matching the other error returns in this function. Fixes: 1866d779d5d2 ("fuse: Allow fuse_fill_super_common() for submounts") Signed-off-by: Baokun Li Reviewed-by: Jingbo Xu Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 5559dd7888d2c9b508f1b7d830a7dc2f4400978a Author: Daniel Baluta Date: Mon Aug 17 15:35:41 2026 +0300 soc: qcom: ubwc: Fix missing include [ Upstream commit c6441becf4d064bb1dcbccbd3e2276833804cff5 ] When CONFIG_QCOM_UBWC_CONFIG=n, compiler needs to know the definition of ERR_PTR otherwise there will be a compilation error: In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp_v13.c:7: ./include/linux/soc/qcom/ubwc.h: In function ‘qcom_ubwc_config_get_data’: ./include/linux/soc/qcom/ubwc.h:45:16: error: implicit declaration of function ‘ERR_PTR’ [-Wimplicit-function-declaration] Fix this by including Fixes: 1924272b9ce1 ("soc: qcom: Add UBWC config provider") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Daniel Baluta Tested-by: Nathan Chancellor # build Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit aab1880058ac767d3ea9388a9a7221c776c22c44 Author: Weiming Shi Date: Wed Jun 24 21:00:38 2026 -0700 fs/ntfs3: validate ef->size covers the record's name and value [ Upstream commit c22f91d82cb9a29d22bdffdce6c803467984ad0c ] When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to cover it. Fixes: 0e8235d28f3a ("fs/ntfs3: Check fields while reading") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 74a83aa05f73033af719771ab1f0c269928b4865 Author: Konstantin Komarov Date: Tue Aug 4 15:01:43 2026 +0200 fs/ntfs3: fix out-of-bounds read in read_log_rec_buf() [ Upstream commit de603b9d377fab57a5e6432fa84a9f36b32c1636 ] read_log_rec_buf() copies a log record into a caller buffer starting at u32 off = lsn_to_page_off(log, lsn) + log->record_header_len; log->record_header_len (and log->data_off, used for the following pages) comes verbatim from the on-disk restart area and is only checked for 8-byte alignment in is_rst_area_valid(), so off can exceed log->page_size. "tail = log->page_size - off" then underflows and memcpy() reads past the page_size-sized buffer returned by read_log_page(), spilling adjacent slab memory into the replay buffer. This is reachable by mounting a crafted NTFS image: BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580 Read of size 64 at addr ffff88800a877ff8 by task exploit/127 read_log_rec_buf fs/ntfs3/fslog.c:2299 log_replay fs/ntfs3/fslog.c:4216 ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324 ntfs_fill_super fs/ntfs3/super.c:1392 get_tree_bdev_flags fs/super.c:1694 __x64_sys_mount fs/namespace.c:4360 The buggy address is located 4088 bytes to the right of the 4096-byte region [ffff88800a876000, ffff88800a877000) Reject an in-page offset outside the current page before the copy. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Assisted-by: Claude:claude-opus-4-8 Reported-by: Xiang Mei Signed-off-by: Weiming Shi [almaz.alexandrovich@paragon-software.com: replaced the >= sign with >] Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 389bd349ddbcf90dbd8a4f2a4ab6e552d53df134 Author: Baokun Li Date: Fri Aug 14 21:40:15 2026 +0800 cuse: wait for pending RCU callbacks on module exit [ Upstream commit 4deb3edead0c0e172cc7349e8855d741d3c5e162 ] Since commit 053fc4f755ad ("fuse: fix UAF in rcu pathwalks"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory: userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text! The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour). Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed. Fixes: 053fc4f755ad ("fuse: fix UAF in rcu pathwalks") Signed-off-by: Baokun Li Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit fdb9cd16f8b6e5649cb95e92356378f31f07fd19 Author: Nikolay Aleksandrov Date: Fri Aug 14 17:16:40 2026 +0300 net: bridge: vlan: fix inverted default vlan notification [ Upstream commit 21040c7f931502070dcc66bb0f1aeed07dec032b ] A notification should be emitted only when the vlan delete was successful and not otherwise. The proper check is if br/nbp_vlan_delete returned 0. Fixes: f545923b4a6b ("net: bridge: vlan: notify on vlan add/delete/change flags") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260814141640.64958-1-razor@blackwall.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a34d2e0bfb74ae1d515406eed55002d5207b6441 Author: Maximilian Immanuel Brandtner Date: Thu Aug 13 14:09:44 2026 +0200 tls: fix RX desync on overlapping skbs [ Upstream commit 9466ef3ec972bee926731a766f73533dec590065 ] The TCP receive queue can hold adjacent skbs whose sequence ranges overlap. The tls fast-path reads the record header with skb_copy_bits() by byte offset, which assumes skbs do not overlap, so a header split across the overlap is misread and the connection aborts (-EMSGSIZE/-EINVAL). tls_strp_check_queue_ok() detects such overlaps but only ran after the header was parsed, never covering the header itself. Observed with parallel kTLS connections on: - ConnectX-7 + IPsec crypto offload + GRO - VirtIO (8 queues) + GRO Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser") Signed-off-by: Maximilian Immanuel Brandtner Link: https://patch.msgid.link/20260813121337.3300688-1-maxbr@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f3b6834c13edd4958edc2bd2c298d437a5e05fb4 Author: Ruoyu Wang Date: Thu Aug 13 23:31:31 2026 +0800 net: dsa: mv88e6xxx: Fix PCS link check on CMODE read error [ Upstream commit 7b196e27ad58e612ad1c04b347d0c2135045aa14 ] mv88e6352_pcs_link_check() ignores errors returned by port_get_cmode(). If the port status register read fails, mv88e6352_port_get_cmode() returns without setting cmode. The link check then compares an uninitialized value and may incorrectly treat the PCS as active. Save the return value and fail the link check after releasing the register lock. marvell_c22_pcs_get_state() initializes the reported link state to down before calling the check, so a read failure is handled safely until a later poll succeeds. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 85764555442f ("net: dsa: mv88e6xxx: convert 88e6352 to phylink_pcs") Signed-off-by: Ruoyu Wang Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260813153131.3952970-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit daebc7064a1b4c12c98e52c4bceede7f2fcd573c Author: Xiang Mei Date: Wed Aug 12 14:53:41 2026 -0700 vxlan: vnifilter: enforce exact length of GROUP/GROUP6 attributes [ Upstream commit 984f831dda31b3a18f47454cf64989f65402879e ] The VXLAN VNI filter entry policy declares the GROUP/GROUP6 address attributes as NLA_BINARY with only a maximum length, so validate_nla() accepts a payload shorter than the address. The GROUP consumer reads it with nla_get_in_addr(), an unconditional 4-byte load, so a short attribute over-reads up to 3 bytes of uninitialised slab data, which are stored into remote_ip and echoed back via RTM_GETTUNNEL, disclosing kernel memory. Switch both entries to NLA_POLICY_EXACT_LEN() so the validator rejects any GROUP/GROUP6 that is not exactly 4 / 16 bytes; a valid address is always sent at full width. Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260812215341.763123-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4aed450adaee3a021db27be94c61fe025b0d05ff Author: Joas Antonio dos Santos Date: Thu Aug 13 15:34:24 2026 -0300 ipvs: fix integer overflow in ftp helper port/address parsing [ Upstream commit e625a9477d12baaff4025c5f9989184a907ea8fc ] ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16 (hport) and into unsigned char (p[]) without checking for overflow. A crafted FTP PASV/EPSV response with an over-long port or address octet wraps the value, so the helper configures the data connection with a truncated port/address. The netfilter conntrack FTP helper had the same defect, fixed in commit 2b413fc689ba ("netfilter: nf_conntrack_ftp: avoid u16 overflows"). Apply the equivalent fix here: widen the port accumulator to u32 and reject values above 65535, and reject address octets above 255. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Joas Antonio dos Santos Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 448f505e19241c1d38d0aa17b89524aad2531f29 Author: Chao Yu Date: Wed Aug 12 12:20:08 2026 +0000 f2fs: fix to avoid pinfile fragment on fragment:{block, segment} mode [ Upstream commit 0a1703eba23707e3b2edfa2a2329352e7abc0ffa ] pinfile fallocate() conflicts w/ mode=fragment:{block,segment} mount option, result in fragment blocks in pinfile, it violate semantics of pinfile introduced in commit f5a53edcf01e ("f2fs: support aligned pinned file"). mkfs.f2fs -f /dev/vdb mount -t f2fs -o mode=fragment:block /dev/vdb /mnt/f2fs/ dd if=/dev/zero of=/mnt/f2fs/file bs=1M count=3900 sync touch /mnt/f2fs/pinfile f2fs_io pinfile set /mnt/f2fs/pinfile f2fs_io fallocate 0 0 $((1024*1024*16)) /mnt/f2fs/pinfile sync f2fs_io fiemap 0 $((1024*1024*16)) /mnt/f2fs/pinfile [Before] fallocate failed: No space left on device Fiemap: offset = 0 len = 16777216 logical addr. physical addr. length flags 0 0000000000000000 00000000d7200000 0000000000004000 00001000 1 0000000000004000 00000000d7207000 0000000000001000 00001000 2 0000000000005000 00000000d720c000 0000000000002000 00001000 3 0000000000007000 00000000d7211000 0000000000001000 00001000 4 0000000000008000 00000000d7214000 0000000000001000 00001000 5 0000000000009000 00000000d7218000 0000000000001000 00001000 6 000000000000a000 00000000d721d000 0000000000001000 00001000 7 000000000000b000 00000000d721f000 0000000000004000 00001000 ... 96 00000000000f1000 00000000d73e9000 0000000000004000 00001000 97 00000000000f5000 00000000d73f1000 0000000000003000 00001000 98 00000000000f8000 00000000d73f5000 0000000000004000 00001000 99 00000000000fc000 00000000d73fa000 0000000000001000 00001000 100 00000000000fd000 00000000d73ff000 0000000000001000 00001001 [After] fallocated a file: i_size=16777216, i_blocks=32808 Fiemap: offset = 0 len = 16777216 logical addr. physical addr. length flags 0 0000000000000000 0000000018a00000 0000000000400000 00001000 1 0000000000400000 0000000019000000 0000000000400000 00001000 2 0000000000800000 0000000032400000 0000000000200000 00001000 3 0000000000a00000 0000000038000000 0000000000200000 00001000 4 0000000000c00000 0000000039c00000 0000000000200000 00001000 5 0000000000e00000 0000000044c00000 0000000000200000 00001001 Let's ignore mode=fragment:{block,segment} mount option while fallocate() on pinfile. Fixes: 6691d940b0e0 ("f2fs: introduce fragment allocation mode mount option") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 32ee27946f0974b2ddabd70dd398cbe337827426 Author: Chao Yu Date: Wed Aug 12 12:20:07 2026 +0000 f2fs: cleanup w/ f2fs_need_rand_{blk, seg, seg_blk} [ Upstream commit 6da62bbde487d4678702ef004a911cd1c7a5c746 ] No logic changes. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: 0a1703eba237 ("f2fs: fix to avoid pinfile fragment on fragment:{block, segment} mode") Signed-off-by: Sasha Levin commit dd5d8f4a9c67f5dda1cda108a860d16b70009689 Author: liujinbao1 Date: Fri Feb 13 20:26:30 2026 +0800 f2fs:Fix incomplete search range in f2fs_get_victim when f2fs_need_rand_seg is enabled [ Upstream commit 5604129b6504c2d6dfbc02515c43e6186a1285e7 ] During the f2fs_get_victim process, when the f2fs_need_rand_seg is enabled in select_policy, p->offset is a random value, and the search range is from p->offset to MAIN_SECS. When segno >= last_segment, the loop breaks and exits directly without searching the range from 0 to p->offset.This results in an incomplete search when the random offset is not zero. Signed-off-by: liujinbao1 Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: 0a1703eba237 ("f2fs: fix to avoid pinfile fragment on fragment:{block, segment} mode") Signed-off-by: Sasha Levin commit 65702339b3e9fd792f65d4b740928798194d86ce Author: Xin Xie Date: Sat Aug 8 13:08:14 2026 +0200 net: hsr: free learned nodes on device setup failure [ Upstream commit 7f16289b91eb316f170a6bd22d32e6c632f6a5b6 ] hsr_dev_finalize() can fail after a lower-device RX handler has already been registered (slave A is added before the failable slave B and interlink adds). RX handlers run in softirq regardless of the master's state, so frames received in that window can learn dynamic nodes into node_db, and the error unwind never releases them. Free both owned dynamic databases in the unwind, mirroring hsr_dellink(). proxy_node_db is provably empty on every current error exit (only interlink RX feeds it, and the interlink add is the last failable step) and is freed for symmetry. The order is safe: hsr_del_port() unregisters each RX handler with synchronize_net() before hsr_del_nodes() runs, which removes remaining entries with list_del_rcu() and defers their release with call_rcu() for readers already under RCU. Fixes: 81ba6afd6e64 ("net/hsr: Switch from dev_add_pack() to netdev_rx_handler_register()") Signed-off-by: Xin Xie Link: https://patch.msgid.link/20260808110814.1637-1-xiexinet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 54bc96aeee05025a8b40011c60412489fe6497e9 Author: Qingfang Deng Date: Tue Aug 11 11:53:10 2026 +0800 pppox: drain queued packets on channel handoff [ Upstream commit 92c1bf630abf0af646562398eaa36f80b5ff677d ] PPPIOCGCHAN both returns the channel index and marks a PPPOX socket as bound to generic PPP, despite its getter semantic. Packets received before that transition are queued on sk_receive_queue, but a bound socket is no longer readable. Such packets therefore remain queued until the socket is destroyed. After marking a socket bound, wait for receive paths that observed the old state to finish queueing packets, and then drain the queue into generic PPP. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Qingfang Deng Link: https://patch.msgid.link/20260811035314.302878-1-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fb511bf117edd74303e9d879df1e44d7a745e15d Author: Vladimir Oltean Date: Wed Aug 12 23:11:21 2026 +0300 net: dsa: b53: fix error propagation from b53_fdb_dump() [ Upstream commit 4f1d06cf8aaa9d2cb18e5ee8835aff6177256bc6 ] The blamed commit replaced "return ret" statements in b53_fdb_dump() with "break;" which jumps to the mutex_unlock() -> return 0 section. This is notably problematic because it swallows errors from the b53_fdb_copy() -> cb() path, and this will result in FDB dump truncation when the netlink skb overflows - see commit 21b52fed928e ("net: dsa: sja1105: fix broken backpressure in .port_fdb_dump"). Let's go back to "return ret". We don't need to preinitialize "ret" with 0, because the "do {} while" block guarantees we cannot reach the end of the function without at least once calling b53_arl_search_wait(), which will have initialized ret to some valid value. Fixes: f7eb4a1c0864 ("net: dsa: b53: serialize access to the ARL table") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260812201121.2012356-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 292846223eaddba890e40699d2ab82ee5671798c Author: Junseo Lim Date: Thu Aug 13 12:51:36 2026 +0900 net: kcm: Hold RCU read lock while running BPF parser [ Upstream commit b0346dd64e4905291cc9c479f2e6cf1884ced4e6 ] kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser program. Hold the RCU read lock while running the program. Fixes: 9b73896a81dc ("kcm: Use stream parser") Reported-by: Sechang Lim Signed-off-by: Junseo Lim Link: https://patch.msgid.link/20260813035136.106167-1-zirajs7@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 31fbed0b409a617a51b7aab46cf1aa330a3c910a Author: Prabu Thayalan Date: Tue Aug 11 12:50:39 2026 -0700 ionic: fix completion descriptor access with 2x desc size [ Upstream commit 5da6ec6f06f235166bd084466b3386c638e26675 ] The old ionic_rx_service() and ionic_tx_service() used array indexing to access completion descriptors: comp = &((struct ionic_rxq_comp *)cq->base)[cq->tail_idx]; This assumes the stride is sizeof(struct ionic_rxq_comp) = 16 bytes. However, when the IONIC_Q_F_2X_CQ_DESC flag is set, the actual completion descriptor size is 32 bytes (2 * sizeof(comp)), and the completion itself is located at the end of that 32-byte slot. Array indexing with a 16-byte stride would access the wrong offset. Use pointer arithmetic that accounts for the actual descriptor size from cq->desc_size: comp = cq->base + cq->desc_size * cq->tail_idx + cq->desc_size - sizeof(*comp); This correctly calculates the completion location regardless of descriptor size. For the common case where desc_size equals sizeof(*comp), use array indexing in a likely() fast path to avoid performance regression. Fixes: 65e548f6b0ff ("ionic: remove the cq_info to save more memory") Signed-off-by: Prabu Thayalan Signed-off-by: Eric Joyner Reviewed-by: Brett Creeley Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260811195039.1315045-3-eric.joyner@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3ec0225b9d7507281e4b1e6b46f6020e75cf5402 Author: Wei Fang Date: Tue Aug 11 16:36:14 2026 +0800 ptp: netc: skip PEROUT disable if channel is not enabled [ Upstream commit 273480bb836e515353f30a1e70b21a2382de666e ] When userspace calls ioctl(PTP_PEROUT_REQUEST) with period = 0 to disable a PEROUT channel that is not enabled, the driver incorrectly enters the disable path. Since the channel's struct netc_pp was previously zeroed, pp->alarm_id evaluates to 0, causing priv->fs_alarm_bitmap &= ~BIT(0) to silently revoke the alarm 0 allocation from whichever channel is actively using it. This can cause two channels conflict over the same hardware alarm configuration and corrupt their periodic output signals. Therefore, guard the disable path with a check on pp->enabled and return early if the channel is not enabled. Fixes: 671e266835b8 ("ptp: netc: add periodic pulse output support") Reported-by: Sashiko Closes: https://sashiko.dev/#/message/20260809031908.46EBF1F00A3A%40smtp.kernel.org Signed-off-by: Wei Fang Link: https://patch.msgid.link/20260811083614.3589967-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 00f1000a644e847b1f360ce55c370587579483e9 Author: Dan Carpenter Date: Thu Aug 13 10:09:47 2026 +0300 drm/xe: tests: fix error message in xe_migrate_sanity_test() [ Upstream commit 3d318fe4e99a627aa3c2980699e2e9f13ad18516 ] This is supposed to print the error code but there is a copy and paste bug so it prints "bo" instead of "err". Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/an1tu0z3T-qX1ogn@stanley.mountain Signed-off-by: Rodrigo Vivi (cherry picked from commit 28a4198c52a1468fc1b620a9837557ea1dc1766d) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit e794cdc5c369c1b06359e2fe03a8d9270f56bead Author: Fan Gong Date: Tue Aug 11 19:43:59 2026 +0800 hinic3: Fix skb linearization mismatch and drop skb when skb_checksum_help() failed [ Upstream commit d0c2bed6927cbfa2cb51f240b4812bf6916bce0e ] Previously, hinic3_send_one_skb() cached the skb fragment count before calling hinic3_tx_offload(). If hinic3_tx_csum() falls back to skb_checksum_help() for unsupported tunnel packets, the skb may be linearized. Continuing to build the TX descriptor with the stale fragment count leads to a descriptor mismatch, which can trigger out-of-bounds DMA reads or IOMMU faults. Furthermore, the old code ignored the return value of skb_checksum_help(), transmitting corrupted packets with incomplete checksums upon failure. Fix this by: 1. Moving the hinic3_tx_offload() call before calculating 'num_sge' to ensure the correct fragment count is used if the SKB is linearized. 2. Propagating skb_checksum_help() errors and returning HINIC3_TX_OFFLOAD_INVALID to properly drop the skb. Fixes: 17fcb3dc12bb ("hinic3: module initialization and tx/rx logic") Co-developed-by: Teng Peisen Signed-off-by: Teng Peisen Co-developed-by: Wu Di Signed-off-by: Wu Di Signed-off-by: Fan Gong Reviewed-by: Simon Horman Link: https://patch.msgid.link/78d8c61cab588240948eaddcb437d59add9f77ae.1786448013.git.tengpeisen@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c0f208d8a57267d79c94cfbd22524c44e4840c7e Author: Karl Mehltretter Date: Wed Aug 12 08:07:30 2026 +0200 octeontx2-af: initialize lmac_bmap in rvu_mcs_set_lmac_bmap() [ Upstream commit 4b92a3710d4a1d850ed6421c773e735cdca69b07 ] rvu_mcs_set_lmac_bmap() declares lmac_bmap without initializing it and only sets bits for valid lmacs with set_bit(), which ORs into the word without clearing it first. Bits for invalid or skipped ports keep whatever was on the stack, and the garbage is stored into mcs->hw->lmac_bmap. Initialize lmac_bmap to 0 so only valid lmacs are marked. Found with Clang's -Wconditional-uninitialized. Fixes: ca7f49ff8846 ("octeontx2-af: cn10k: Introduce driver for macsec block.") Signed-off-by: Karl Mehltretter Reviewed-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260812060730.6181-1-kmehltretter@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ea7b35dcc9430293b861bc7bad0c546f193c85f9 Author: Jiayuan Chen Date: Wed Aug 12 14:36:11 2026 +0800 bpf, xdp: move offload check into dev_xdp_install() [ Upstream commit ad27ed7d2309419a129078d781504f486b1b469a ] bpf_xdp_link_update() calls dev_xdp_install() directly and skips dev_xdp_attach(), so the checks in dev_xdp_attach() do not run. A user can make an XDP link with a normal program and then swap in an offloaded or device-bound program with BPF_LINK_UPDATE, which puts it on the software path. dev_xdp_install() is the one place all three paths go through: "ip link set xdp" and BPF_LINK_CREATE reach it via dev_xdp_attach(), and BPF_LINK_UPDATE calls it directly. So move the program checks (offloaded, bound to another device, device-bound in generic mode, native vs generic, DEVMAP and CPUMAP) there, and keep only the netlink-flag check (XDP_FLAGS_UPDATE_IF_NOEXIST) in dev_xdp_attach(). Fixes: 026a4c28e1db3 ("bpf, xdp: Implement LINK_UPDATE for BPF XDP link") Signed-off-by: Jiayuan Chen Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9e5e2ccc51dfcbc59ac5bf3093ca349b71491601 Author: Mathieu Dubois-Briand Date: Mon Jul 27 09:41:40 2026 +0200 clk: ti: mux: resolve parent clocks by DT index, not by name [ Upstream commit 667f420c09f1417c9f07798e32432c901915209d ] Resolve parent clocks by their index into the device tree "clocks" property rather than matching names as strings. Name-based matching is fragile because a clock's "clock-output-names" value in its provider node can differ from the name used to reference it in a consumer node, and because names must be globally unique across all clock providers. On AM335x, this caused broken clock trees where some clocks failed to enable because their parents could not be found. Replace of_clk_parent_fill() with a clk_parent_data array that sets .index to the array position. Fixes: ec7aa25fa483 ("ARM: dts: Use clock-output-names for am3") Signed-off-by: Mathieu Dubois-Briand Reviewed-by: Brian Masney Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 9d4843f1051259854f724e9cdc5b9eac56327037 Author: Onur Özkan Date: Sat Aug 1 14:16:34 2026 +0300 clk: devres: fix cleanup in devm_clk_get_optional_enabled_with_rate() [ Upstream commit 0d4d262c1664365e17e0a5ba2ab79f4db484b44e ] devm_clk_get_optional_enabled_with_rate() registers its cleanup action before setting the clock rate. If setting the rate fails, it attempts to disable and unprepare a clock that was never enabled. This issue was spotted while reviewing "rust: clk: add devres-managed clks" [1]. Register the cleanup action only after successfully preparing and enabling the clock. [1]: https://lore.kernel.org/rust-for-linux/20260706-clk-type-state-v5-3-67c5f326a16c@collabora.com Fixes: 9934a1bd45b2 ("clk: provide devm_clk_get_optional_enabled_with_rate()") Signed-off-by: Onur Özkan Reviewed-by: Brian Masney Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 4c067f5ffb4697847a056f8d6d12b0a5de7dca65 Author: Michael Nemanov Date: Thu Aug 6 13:13:58 2026 +0000 nfs: fix ENXIO on O_CREAT open of existing symlink over NFSv3 [ Upstream commit 10f307e525a1783570a39eb9ac146d45f4f16b3e ] When open(2) is called with O_CREAT on a path that already exists as a symlink, over an NFSv3 mount with a cold dcache, the kernel returns ENXIO instead of following the symlink to its target. Reproducer script (MNT is an NFSv3 mount, kernel is 7.1-rc6): MNT=/mnt/export ln -sf /tmp/target $MNT/mylink echo 3 | sudo tee /proc/sys/vm/drop_caches # cold dcache python3 - <<'EOF' import os fd = os.open('/mnt/export/mylink', os.O_WRONLY | os.O_CREAT | os.O_APPEND, 0o666) os.close(fd) EOF Expected: success (follow symlink, open target) Actual: OSError: [Errno 6] No such device or address The bug does not trigger when the dcache is warm (e.g. after a prior stat(2)), because lookup_open() then finds a positive dentry and skips atomic_open entirely, leaving symlink resolution to the VFS. Root cause: nfs_atomic_open_v23(), registered as inode->i_op->atomic_open for NFSv3, handles O_CREAT by sending a CREATE UNCHECKED RPC. As implemented in nfsd3_create_file() (fs/nfsd/nfs3proc.c) and as required by RFC 1813 (3.3.8), when the name already exists as a non-regular file the server returns NFS3_OK with the existing object's file handle rather than NFS3ERR_EXIST causing nfs_do_create() to return 0 with the dentry now pointing to a symlink. The code then unconditionally calls finish_open(), which dispatches through inode->i_fop->open(). Symlink inodes never have i_fop set — the VFS initialises it to &no_open_fops because POSIX requires open(2) to follow symlinks, never open them directly. no_open() returns -ENXIO. Fix: After nfs_do_create() succeeds, verify the returned inode is a regular file before calling finish_open(). If the object is not regular, return finish_no_open(file, NULL) so the VFS follows the symlink through the normal open path. NULL is passed because nfs_do_create() instantiates the inode on the dentry already owned by the caller; passing dentry back would cause atomic_open() to dput() it a second time. !S_ISREG() is used rather than S_ISLNK() to cover any other non-regular types a server might return. Changes in v2: - Pass NULL to finish_no_open() per Trond's feedback. Fixes: 7c6c5249f061 ("NFS: add atomic_open for NFSv3 to handle O_TRUNC correctly.") Link: https://lore.kernel.org/linux-nfs/20260614122911.3485467-1-michael.nemanov@vastdata.com/ (v1) Signed-off-by: Michael Nemanov Tested-by: Michael Nemanov [trond.myklebust@hammerspace.com: use d_is_reg() to catch negative dentries] Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit d148a652d52fd6aee96daf798922eb800ebb3018 Author: Zhansong Gao Date: Thu Jul 23 04:00:59 2026 +0800 NFSv4: Fix incorrect argument passed to nfs4_delete_lease() in nfs4_add_lease() [ Upstream commit 468e458ffde907ba19acd2102ca1fbb8f6fbede2 ] When nfs4_add_lease() races with a delegation return, it calls nfs4_delete_lease() to clean up. Previously, it passed priv, which can legitimately be NULL. Passing a NULL priv eventually leads to a NULL pointer dereference in generic_setlease(). Fixes: e93a5e9306a5 ("NFSv4: Add support for application leases underpinned by a delegation") Signed-off-by: Zhansong Gao Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 163c16e01f53fc8eb8d0f3484ae6c382265ecbbd Author: Jeuk Kim Date: Wed Jul 8 16:44:32 2026 +0900 NFSv4/flexfiles: fix NULL dereference for NFSv4.0 data servers [ Upstream commit 2b03ebbf8d5e8f6af4ecd6c65375232dd1ec32cc ] flexfiles accepts NFSv4.0 data servers, but two NFSv4 code paths assume the data server client has a session. Unlike NFSv4.1+, an NFSv4.0 client has no session (clp->cl_session is NULL; it uses clp->cl_slot_tbl), so I/O to a v4.0 flexfiles DS oopses: - nfs4_init_ds_session() dereferences clp->cl_session->session_state while seeding the DS lease. It also only seeds cl_lease_time when NFS4_SESSION_INITING is set; without a session that never happens, so cl_lease_time stays 0 and nfs4_renew_state() busy-loops, requeuing every 5 seconds. Seed the lease whenever there is no session and return before touching session state. - ff_layout_async_handle_error_v4() dereferences clp->cl_session->fc_slot_table on every DS I/O error. Fall back to the v4.0 transport slot table (clp->cl_slot_tbl) when there is no session. Fixes: a7878ca14008 ("nfs: flexfilelayout: remove v3-only data server limitation") Signed-off-by: Jeuk Kim Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 1e1c36b206c659cf94c6755a1d821ed1babd32bc Author: ZhangGuoDong Date: Thu Jun 25 11:20:38 2026 +0800 pnfs/blocklayout: Fix device leaks on parse failure [ Upstream commit c056f817e4200fb18079d5052c273a22f191ff0a ] bl_parse_concat() and bl_parse_stripe() allocate a child device array and then parse each child in turn. If parsing a child fails, the failed child is not counted in nr_children and the parent may be left with a children array that bl_free_device() will not release when nr_children is zero. Release the failed child and the already parsed children before returning the error. Also make bl_free_device() release the child array whenever the children pointer is set, so that partially initialised concat or stripe devices are cleaned up correctly. bl_parse_scsi() can also fail after assigning d->bdev_file and dropping the file reference. Clear the pointer after fput() so that an outer cleanup path does not put it again. Fixes: 5c83746a0cf2 ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing") Signed-off-by: ZhangGuoDong Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 3f2387e8bfbc4efda5d77c3a11a028d0a119c48f Author: Ruoyu Wang Date: Wed Jun 24 11:58:58 2026 +0800 NFSv4: remove callback IDR entry on client allocation failure [ Upstream commit d05c2007b3d84ccba11dc6e9cb3202768cc72f14 ] nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown. A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it. Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client. This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection. Fixes: f4eecd5da342 ("NFS implement v4.0 callback_ident") Signed-off-by: Ruoyu Wang Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 4c59aca79da0eb0d52847e7f14968d53991f7d6e Author: Arnaud Bonnet Date: Mon Jun 22 19:55:11 2026 +0200 nfs: refactor pNFS functions using clear_and_wake_up_bit [ Upstream commit 187bfc974eefa9e5d88a0b4ee9d08ae8fe485df4 ] Commit 8236b0ae31c83 ("bdi: wake up concurrent wb_shutdown() callers.") introduces the clear_and_wake_up_bit() helper as a wrapper for the common clear -> barrier -> wake up bitops sequence. The file pnfs.c has several helpers with identical contents. Thus they are replaced with the more recent clean_and_wake_up_bit() global helper which describes accurately its effects at the call and still specifies the cleared bit. This also homogenizes the code with other subsystems. Since the helpers are no longer used after this, they can be safely removed. Suggested-by: Agatha Isabelle Moreira Link: https://kernelnewbies.org/Beginner%20Cleanup%20and%20Refactor%20Tasks%20by%20Agatha%20Isabelle%20Moreira#task_007 Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver") Signed-off-by: Arnaud Bonnet Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 8179b8a1d636bd04f4ad09556fc56b9c43a2e967 Author: Arnaud Bonnet Date: Mon Jun 22 19:55:10 2026 +0200 nfs: replace atomic bitops sequence with clear_and_wake_up_bit helper [ Upstream commit 61461050da42401b484d03e0fdac02878d235fe6 ] Commit 8236b0ae31c83 ("bdi: wake up concurrent wb_shutdown() callers.") introduces the clear_and_wake_up_bit() helper as a wrapper for the common clear -> barrier -> wake up bitops sequence. Use the helper in nfs_clear_invalid_mapping as inode.c already relies on functions from and to homogenize with other subsystems. Suggested-by: Agatha Isabelle Moreira Link: https://kernelnewbies.org/Beginner%20Cleanup%20and%20Refactor%20Tasks%20by%20Agatha%20Isabelle%20Moreira#task_007 Fixes: d529ef83c355 ("NFS: fix the handling of NFS_INO_INVALID_DATA flag in nfs_revalidate_mapping") Signed-off-by: Arnaud Bonnet Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit b967a595fb735d313a8676b2ca6a4cba38506482 Author: Ze Tan Date: Fri Aug 14 13:51:42 2026 +0000 smb/server: fix session leak in ksmbd_session_register() [ Upstream commit 99b25b046e47e4904373cfeb445c5483f1633d88 ] See the procedure below: smb2_sess_setup ksmbd_smb2_session_create __session_create atomic_set(&sess->refcnt, 2) hash_add(sessions_table, &sess->hlist, sess->id) ksmbd_session_register xa_store(&conn->sessions, sess->id, sess) // fail ksmbd_user_session_put atomic_dec(&sess->refcnt) // refcnt is 1, session is not freed Remove the session from sessions_table and drop its table reference if xa_store() fails. Fixes: f5c779b7ddbd ("ksmbd: fix racy issue from session setup and logoff") Signed-off-by: Ze Tan Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit a4a307d149327dad5fb25187e1b03cebd1b04de6 Author: Hang Nan <2122295973@qq.com> Date: Mon Aug 17 09:52:45 2026 +0900 ksmbd: bound smb_check_perm_dacl() ACE walks by DACL size [ Upstream commit 79decd88dd3f0d42e7fb0689b1a7853bfa302459 ] smb_check_perm_dacl() validates that the DACL fits inside the NT security descriptor, but then bounds its two ACE walks by the remaining NTSD length (acl_size) rather than the DACL's declared size (pdacl_size). When pdacl->size is smaller than the trailing NTSD buffer, bytes after the declared DACL boundary - still inside the stored security descriptor - are parsed as ACEs during access checks. A crafted DACL can place an access-granting ACE beyond pdacl->size, and the current code accepts it during SMB2_CREATE access validation, while parse_dacl() and smb_inherit_dacl() stop at pdacl_size. Bound both ACE walks by pdacl_size to match the DACL boundary semantics used elsewhere in the server. Validation: - semantic KUnit harness shows the post-boundary ACE is selected before the fix and rejected (EACCES) after it - linux master (7.2-rc6), x86_64 Fixes: 8f0541186e9a ("ksmbd: fix heap-based overflow in set_ntacl_dacl()") Signed-off-by: Hang Nan <2122295973@qq.com> Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit a21597b5730bc585abb31339f5c395d5e890118f Author: Namjae Jeon Date: Thu Aug 13 17:05:49 2026 +0900 ksmbd: disconnect on SMB3 decryption failure [ Upstream commit 12a6680ce59bcd431730c9f049caddb017964c64 ] MS-SMB2 requires the server to disconnect a connection when an encrypted transform cannot be associated with a session or fails authenticated decryption. This includes an encrypted request that still carries a SessionId invalidated through PreviousSessionId. Move the connection to EXITING and shut down its transport when decrypt_req() fails. Add the missing TCP shutdown callback so a receive blocked in kernel_recvmsg() is released; SMB Direct already provides the corresponding callback. Plaintext requests using an invalidated SessionId do not take this path and continue to receive STATUS_USER_SESSION_DELETED. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 2bdbe00454200fcb0110f31eeca8d906a3515e74 Author: Junseo Lim Date: Tue Aug 11 23:19:07 2026 +0900 bpf: Reject negative optlen in cgroup getsockopt hook [ Upstream commit 1b5aacd5b2419b0790e955e466d389a61c79b4b1 ] A cgroup getsockopt BPF program can shrink ctx->optlen after the kernel getsockopt handler has run. The kernel-buffer variant, used by TCP_ZEROCOPY_RECEIVE, only rejects values larger than the original length. If BPF writes a negative optlen, that value is accepted and propagated back to the TCP getsockopt code. It can then be passed to copy_to_sockptr() as a size_t and trigger the hardened usercopy bytes > INT_MAX warning. Reject negative ctx.optlen in __cgroup_bpf_run_filter_getsockopt_kern(), matching the lower-bound validation already present in the sockptr-based getsockopt hook. Fixes: 9cacf81f8161 ("bpf: Remove extra lock_sock for TCP_ZEROCOPY_RECEIVE") Reported-by: Sechang Lim Signed-off-by: Junseo Lim Signed-off-by: Daniel Borkmann Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/187a4d756275aaaee5d65eecb63c1477b3b66554.1786448307.git.zirajs7@gmail.com Signed-off-by: Sasha Levin commit be98f92fc244688a6bdecbc834cf2cd243056d9d Author: Andreas Schwab Date: Sat Aug 15 09:24:22 2026 +0200 m68k: nfcon: Do not call console_is_registered() in nfcon_device() [ Upstream commit 2f8e3cad53b5c36ab0ed5d3195bfc55c59ea61a5 ] Since 7c2af0f634f1 ("tty: tty_io: use console_list_lock for list synchronization") show_cons_active() calls the .device() method under the console_list_lock, but console_is_registered() tries to acquire console_list_lock as well, causing a deadlock. It should not be necessary to check console_is_registered() here since the function should not be called in the fist place when the console is not registered. Fixes: 7c2af0f634f1 ("tty: tty_io: use console_list_lock for list synchronization") Signed-off-by: Andreas Schwab Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/87ecfzsv6h.fsf@igel.home Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit fe91c3f64a738dd97e8542ad5bdfbe5ac430edf6 Author: Junseo Lim Date: Wed Aug 12 18:16:54 2026 +0900 bpf: Disallow bpf_{g,s}etsockopt() in cgroup UNIX getname hooks [ Upstream commit 84473a7e1813a2da7b759ab1d098a84998c8d3f5 ] _bpf_setsockopt() and _bpf_getsockopt() call sock_owned_by_me() for full sockets, so these helpers expect the socket lock to be held. BPF_CGROUP_UNIX_GETPEERNAME and BPF_CGROUP_UNIX_GETSOCKNAME run BPF programs without acquiring the socket lock. A program attached to either hook can therefore trigger the sock_owned_by_me() warning by calling bpf_setsockopt() or bpf_getsockopt(). Disallow bpf_setsockopt() and bpf_getsockopt() for CGROUP_UNIX_GETPEERNAME and CGROUP_UNIX_GETSOCKNAME. Fixes: 859051dd165e ("bpf: Implement cgroup sockaddr hooks for unix sockets") Reported-by: Sechang Lim Signed-off-by: Junseo Lim Signed-off-by: Daniel Borkmann Reviewed-by: Kuniyuki Iwashima Link: https://lore.kernel.org/bpf/20260812091654.244752-1-zirajs7@gmail.com Signed-off-by: Sasha Levin commit 64eec7314e289e5629f66e087b41418daa37d411 Author: Ojaswin Mujoo Date: Sun Aug 16 18:37:09 2026 +0530 erofs: fix unused pcluster_pools for higher page sizes [ Upstream commit 988c3c186c730590a71df8adc1424c5578ef8bae ] pcluster_pool[] hardcodes {1,4,16,64,128,Z_EROFS_PCLUSTER_MAX_PAGES+1}, but the assumption of Z_EROFS_PCLUSTER_MAX_PAGES == 256 is only right for 4k page sizes. For higher page sizes like 16k or 64k, This results in us ending up with clusters bigger than what we will ever use, since we only support upto 1MB of compressed data. For example, on 64k page size we will only ever use clusters with nrpages= 1, 4 and 17. This patch fixes the allocation for such higher pages sizes by adding some compile time checks. Below are the clusters created right after boot on a 64KB page size machine $cat /proc/slabinfo | grep pcluster | cut -d" " -f1: Before the patch: erofs_pcluster-1 erofs_pcluster-4 erofs_pcluster-16 erofs_pcluster-17 erofs_pcluster-64 erofs_pcluster-128 After the patch: erofs_pcluster-1 erofs_pcluster-4 erofs_pcluster-17 Fixes: 9f6cc76e6ff0 ("erofs: introduce physical cluster slab pools") Reported-by: Shirisha G Signed-off-by: Ojaswin Mujoo Reviewed-by: Gao Xiang Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 7cf561843ed0ad57501892a65abb77957e6c800f Author: Junseo Lim Date: Tue Aug 11 13:41:49 2026 +0900 lwt_bpf: Restore reserved headroom after xmit program [ Upstream commit 5fe7007aed9ad069b2bd77e5d0c875c64f5c0269 ] ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output. That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise. On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb. Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit. Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure") Reported-by: Sechang Lim Suggested-by: Daniel Borkmann Signed-off-by: Junseo Lim Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260811044149.118235-1-zirajs7@gmail.com Signed-off-by: Sasha Levin commit a3d6e590268ee8bc7be8b4aea48362fb2bf3fd40 Author: Gao Xiang Date: Fri Aug 14 16:14:37 2026 +0800 erofs: guard on-disk algorithm IDs against Z_EROFS_COMPRESSION_MAX [ Upstream commit 6847d4d1a24a686ca6c8a0f68501a984f9a0d059 ] All on-disk algorithm IDs should be validated against supported Z_EROFS_COMPRESSION_MAX. This includes a partial revert of a previous commit and also adds validation for encoded extents. Fixes: 131897c65e2b ("erofs: fix invalid algorithm for encoded extents") Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit ddb7ea4fd99bf6c4314d1dfca18aec6945ce8054 Author: Gao Xiang Date: Fri Aug 14 14:59:46 2026 +0800 erofs: fix interlaced ztailpacking pclusters [ Upstream commit 862427ebb81d1f6abbf74d799790e1694b37b187 ] On-disk sizes of interlaced pclusters should be block-aligned, and ztailpacking interlaced pclusters should be invalid at all. Currently, mkfs.erofs won't generate any interlaced pcluster with ztailpacking enabled, so this doesn't affect any existing valid filesystems. However, crafted images can contain invalid interlaced ztailpacking pclusters, resulting in an out-of-bounds read from a kmap'd page and copying irrelevant kernel memory into userspace-visible page cache. Reported-by: Haiyang Huang Closes: https://lore.kernel.org/r/20260806065253.1083865-1-huanghaiyang83@gmail.com Fixes: fdffc091e6f9 ("erofs: support interlaced uncompressed data for compressed files") Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 7f10dc9a7a496feb0637f2e88b84003102cffaf6 Author: Gao Xiang Date: Fri Apr 10 16:48:38 2026 +0800 erofs: error out obviously illegal extents in advance [ Upstream commit a5242d37c83abe86df95c6941e2ace9f9055ffcb ] Detect some corrupted extent cases during metadata parsing rather than letting them result in harmless decompression failures later: - For full-reference compressed extents, the compressed size must not exceed the decompressed size, which is a strict on-disk layout constraint; - For plain (shifted/interlaced) extents, the decoded size must not exceed the encoded size, even accounting for partial decoding. Both ways work but it should be better to report illegal extents as metadata layout violations rather than deferring as decompression failure. Signed-off-by: Gao Xiang Stable-dep-of: 862427ebb81d ("erofs: fix interlaced ztailpacking pclusters") Signed-off-by: Sasha Levin commit 169f6633d2a3513218e953111a9f73e88f2e8074 Author: Gao Xiang Date: Fri Apr 10 16:48:37 2026 +0800 erofs: clean up encoded map flags [ Upstream commit 5c40d2e9e3ce9e81d76773c68756e9b07cce802c ] - Remove EROFS_MAP_ENCODED since it was always set together with EROFS_MAP_MAPPED for compressed extents and checked redundantly; - Replace the EROFS_MAP_FULL_MAPPED flag with the opposite EROFS_MAP_PARTIAL_MAPPED flag so that extents are implicitly fully mapped initially to simplify the logic; - Make fragment extents independent of EROFS_MAP_MAPPED since they are not directly allocated on disk; thus fragment extents are no longer twisted with mapped extents. Signed-off-by: Gao Xiang Stable-dep-of: 862427ebb81d ("erofs: fix interlaced ztailpacking pclusters") Signed-off-by: Sasha Levin commit 892048f595505f00bf378cea02a089fc6c6236e2 Author: ZhangGuoDong Date: Fri Jul 31 11:50:08 2026 +0000 smb/server: preserve error status in smb2_handle_negotiate() [ Upstream commit 73541bd2bab77e7e8e89b1edb5d342f4190dd4d0 ] smb2_handle_negotiate() records specific failures such as STATUS_INVALID_PARAMETER or STATUS_NOT_SUPPORTED. Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Signed-off-by: ZhangGuoDong Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit b2d78c199dfd983638662ace0612d4fade3dbea1 Author: ZhangGuoDong Date: Fri Jul 31 11:50:05 2026 +0000 smb/server: fix invalid pointer dereference in ksmbd_stop_durable_scavenger() [ Upstream commit bef46b604732d83f8da29f782868de4d25bf972c ] See the procedure below: ksmbd_launch_ksmbd_durable_scavenger durable_scavenger_running = true server_conf.dh_task = kthread_run() // fail, dh_task is an ERR_PTR() server_ctrl_handle_reset ksmbd_stop_durable_scavenger kthread_stop(server_conf.dh_task) // invalid pointer Fixes: d484d621d40f ("ksmbd: add durable scavenger timer") Signed-off-by: ZhangGuoDong Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 8461f27902727ad434375caf13a0100aafc0340f Author: ZhangGuoDong Date: Fri Jul 31 11:50:03 2026 +0000 smb/server: fix null-ptr-deref in ksmbd_ipc_tree_connect_request() [ Upstream commit d2ccf905f47d2344270749f4dfa905afcd3edeb0 ] See the procedure below: ksmbd_tree_conn_connect ksmbd_share_config_get share->name = kstrdup() // fail if (!test_share_config_flag(share, KSMBD_SHARE_FLAG_PIPE)) // false // do not check `share->name` ksmbd_ipc_tree_connect_request strlen(share->name) // null-ptr-deref Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: ZhangGuoDong Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit a41a98ee16ae038751b6639decadaa3ce15ca18a Author: Namjae Jeon Date: Fri Jul 24 11:17:30 2026 +0900 ksmbd: free preauth sessions on connection teardown [ Upstream commit 06c7b1d731bc105a8644f1b70165ba8b9416cbab ] SMB3.1.1 multichannel binding preserves the preauthentication hash in a preauth_session between the NTLM negotiate and authenticate requests. The binding NTLM negotiate allocates this object and returns STATUS_MORE_PROCESSING_REQUIRED. If the client disconnects before it sends the authenticate request, neither the authenticate nor error cleanup paths free the object. Release any remaining preauthentication sessions when tearing down the connection. Initialize the list when allocating the connection so that this cleanup is safe regardless of the negotiated dialect. Reported-by: Runa Takemoto Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel") Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 9f37719d6be823cc626e486af09f09a9752cb897 Author: Namjae Jeon Date: Fri Jul 17 12:31:00 2026 +0900 ksmbd: do not advertise unimplemented CA support [ Upstream commit eebdd3f1157e35a50df5ff2d3d9a305901df3254 ] ksmbd durable handles are currently in-memory state. There is no persistent open recovery, cluster ownership epoch, fencing, or failover implementation behind the continuous-availability share flag. Do not advertise SMB2 persistent-handle or continuous-availability capabilities until those guarantees exist. A client requesting DH2Q then falls back to the existing durable V2 behavior rather than being promised a persistent handle that cannot survive a server failure. Signed-off-by: Namjae Jeon Stable-dep-of: 06c7b1d731bc ("ksmbd: free preauth sessions on connection teardown") Signed-off-by: Sasha Levin commit 0aa8f94bfd4d818284c8a7ce0040d40ca1ec3595 Author: Yunseong Kim Date: Wed Jul 22 22:31:06 2026 +0200 ksmbd: validate ipc response length before dereferencing its fields [ Upstream commit e9b33376bd07bca4175f7bcc2d6034ef250f8181 ] ipc_validate_msg() computes the expected message size by reading length fields out of the response buffer supplied by the userspace ksmbd daemon (payload_sz, session_key_len, ngroups, ...). Those fields are read before the buffer is verified to be large enough to contain the struct they belong to, so a short response makes the read land past the end of the allocation. handle_response() sizes entry->response purely from the netlink attribute length (nla_len()) and only guards the leading handle read, so the daemon can install a response as small as the kmalloc-8 object seen below. When ipc_msg_send_request() then calls ipc_validate_msg() for a KSMBD_EVENT_RPC_REQUEST, the cast to struct ksmbd_rpc_command reads resp->payload_sz at offset 8 of an 8-byte allocation: [ 3697.841381] ================================================================== [ 3697.844099] BUG: KASAN: slab-out-of-bounds in ipc_msg_send_request+0x763/0x800 [ 3697.846604] Read of size 4 at addr ffff888105f95910 by task kworker/4:3/20682 [ 3697.849061] [ 3697.849801] CPU: 4 UID: 0 PID: 20682 Comm: kworker/4:3 Not tainted 7.2.0-rc3-next-20260717-virtme #117 PREEMPT(lazy) [ 3697.850077] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3697.850303] Workqueue: ksmbd-io handle_ksmbd_work [ 3697.850592] Call Trace: [ 3697.850794] [ 3697.850952] __dump_stack+0x21/0x60 [ 3697.851239] dump_stack_lvl+0xc2/0x100 [ 3697.851528] print_address_description+0x77/0x200 [ 3697.851816] ? ipc_msg_send_request+0x763/0x800 [ 3697.852024] print_report+0x58/0x70 [ 3697.852316] kasan_report+0x117/0x150 [ 3697.852585] ? down_write+0x146/0x1f0 [ 3697.852809] ? ipc_msg_send_request+0x763/0x800 [ 3697.853082] ipc_msg_send_request+0x763/0x800 [ 3697.853385] ? __pfx_ipc_msg_send_request+0x10/0x10 [ 3697.853604] ? kasan_unpoison+0x48/0x70 [ 3697.853936] ? __pfx___up_read+0x10/0x10 [ 3697.854221] ksmbd_rpc_ioctl+0x380/0x520 [ 3697.854542] ? __pfx_ksmbd_rpc_ioctl+0x10/0x10 [ 3697.854757] ? kasan_unpoison+0x48/0x70 [ 3697.854962] ? copy_from_kernel_nofault+0x32c/0x4e0 [ 3697.855166] ? kasan_unpoison+0x48/0x70 [ 3697.855416] fsctl_pipe_transceive+0x139/0x7a0 [ 3697.855705] ? __pfx_copy_from_kernel_nofault+0x10/0x10 [ 3697.855937] ? __pfx_fsctl_pipe_transceive+0x10/0x10 [ 3697.856388] ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 3697.856620] smb2_ioctl+0x1141/0x3420 [ 3697.856994] ? __pfx_smb2_ioctl+0x10/0x10 [ 3697.857182] ? get_smb2_cmd_val+0xe3/0x1c0 [ 3697.857655] handle_ksmbd_work+0x9ad/0x15e0 [ 3697.858034] ? __pfx_handle_ksmbd_work+0x10/0x10 [ 3697.858251] ? lock_release+0xf7/0x360 [ 3697.858466] ? process_scheduled_works+0x954/0x1600 [ 3697.858698] ? process_scheduled_works+0x954/0x1600 [ 3697.858905] process_scheduled_works+0xc22/0x1600 [ 3697.859368] ? __pfx_process_scheduled_works+0x10/0x10 [ 3697.859637] ? __pfx_assign_work+0x10/0x10 [ 3697.859896] ? lock_is_held_type+0x7b/0x110 [ 3697.860146] worker_thread+0x975/0xee0 [ 3697.860524] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 3697.860830] ? __kthread_parkme+0x21e/0x260 [ 3697.861105] kthread+0x3a6/0x490 [ 3697.861423] ? __pfx_worker_thread+0x10/0x10 [ 3697.861643] ? __pfx_kthread+0x10/0x10 [ 3697.861878] ret_from_fork+0x55a/0xa20 [ 3697.862194] ? __pfx_ret_from_fork+0x10/0x10 [ 3697.862480] ? __pfx_kthread+0x10/0x10 [ 3697.862714] ret_from_fork_asm+0x1a/0x30 [ 3697.862965] [ 3697.863039] [ 3697.938882] Allocated by task 20761: [ 3697.940257] kasan_save_track+0x3e/0x80 [ 3697.941782] __kasan_kmalloc+0x72/0x90 [ 3697.943228] __kvmalloc_node_noprof+0x3e9/0x6a0 [ 3697.944948] handle_generic_event+0x59b/0x750 [ 3697.946592] genl_family_rcv_msg_doit+0x3d6/0x560 [ 3697.946977] genl_rcv_msg+0x67c/0x900 [ 3697.947224] netlink_rcv_skb+0x286/0x580 [ 3697.947488] genl_rcv+0x2d/0x80 [ 3697.947706] netlink_unicast+0x937/0xb70 [ 3697.947993] netlink_sendmsg+0x977/0xc10 [ 3697.948268] __sock_sendmsg+0x264/0x2d0 [ 3697.948536] __sys_sendto+0x4de/0x690 [ 3697.948789] __x64_sys_sendto+0x173/0x380 [ 3697.949069] do_syscall_64+0x13d/0x420 [ 3697.949328] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 3697.949662] [ 3697.949779] The buggy address belongs to the object at ffff888105f95908 [ 3697.949779] which belongs to the cache kmalloc-8 of size 8 [ 3697.950550] The buggy address is located 0 bytes to the right of [ 3697.950550] allocated 8-byte region [ffff888105f95908, ffff888105f95910) [ 3697.951455] [ 3697.951574] The buggy address belongs to the physical page: [ 3697.951958] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888105f951b8 pfn:0x105f95 [ 3697.952571] flags: 0x100000000000200(workingset|node=0|zone=2) [ 3697.952973] page_type: f5(slab) [ 3697.953198] raw: 0100000000000200 ffff888100042640 ffffea0004063610 ffff888100040588 [ 3697.953707] raw: ffff888105f951b8 00000000001c000e 00000000f5000000 0000000000000000 [ 3697.954240] page dumped because: kasan: bad access detected [ 3697.954616] [ 3697.954734] Memory state around the buggy address: [ 3697.955063] ffff888105f95800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fa [ 3697.955534] ffff888105f95880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 3697.956006] >ffff888105f95900: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 3697.956477] ^ [ 3697.956728] ffff888105f95980: fc fc fc fa fc fc fc fc fc fc fc fc fc fc fc fc [ 3697.957202] ffff888105f95a00: fc fc fc fc fc fa fc fc fc fc fc fc fc fc fc fc [ 3697.957671] ================================================================== The final "entry->msg_sz != msg_sz" comparison cannot help: the offending read has already happened by the time it runs. Every case in the switch shares this pattern. Floor entry->msg_sz against the base struct of each event type before dereferencing any of its length fields. On failure ipc_msg_send_request() already frees the response and returns NULL, so callers stay safe. The malformed message originates from the ksmbd.mountd daemon over genl netlink rather than a remote SMB client, so triggering it requires a buggy or compromised daemon; it is still an out-of-bounds read the validator is meant to prevent. Fixes: d6a6aa81eac2 ("ksmbd: validate response sizes in ipc_validate_msg()") Signed-off-by: Yunseong Kim Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 7a98c3b903b10c4d6176948254012b5ca24b071b Author: Enzo Matsumiya Date: Wed Jul 8 09:59:12 2026 -0300 smb: server: fix leak of ksmbd_ipc_login_request_ext() returned buffer [ Upstream commit 1c3ebf832d010c08afe1359215d4121cb1ed2de5 ] Free it unconditionally after ksmbd_alloc_user() calls. kmemleak splat: unreferenced object 0xffff888103b83540 (size 192): comm "pool-0", pid 16970, jiffies 4377290937 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 408ccc66): __kvmalloc_node_noprof+0x730/0x920 handle_generic_event+0xec/0x1a0 [ksmbd] genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x181/0x290 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x1e6/0x2c0 netlink_sendmsg+0x20a/0x450 ____sys_sendmsg+0x2e8/0x310 ___sys_sendmsg+0x78/0xc0 __sys_sendmsg+0x63/0xc0 do_syscall_64+0xa1/0x670 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: a77e0e02af1c ("ksmbd: add support for supplementary groups") Signed-off-by: Enzo Matsumiya Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 84c2d8e807ac489f5c91769293fb15dfdae8bae8 Author: Guangshuo Li Date: Sun Jul 5 19:34:35 2026 +0800 ksmbd: Do not skip lock checks for single-byte ranges [ Upstream commit d40c24634fe077a0dc91fd11fccf44ce12b454d5 ] check_lock_range() uses inclusive ranges. Its callers pass the end offset as start + length - 1, so start == end represents a valid single-byte range rather than an empty range. The start == end shortcut therefore skips mandatory byte-range lock checks for one-byte reads, writes, copychunk operations and one-byte truncate ranges. A conflicting lock covering that byte is not checked and the operation is allowed to proceed. Remove the shortcut. The truncate size == inode->i_size case is already handled by only calling check_lock_range() when the new size differs from the current file size. Fixes: 5d510ac31626 ("ksmbd: skip lock-range check on equal size to avoid size==0 underflow") Signed-off-by: Guangshuo Li Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit db141a5ebcb04acb6c5e5daacd795e3de5603f35 Author: Marius Cristea Date: Thu Aug 13 11:40:07 2026 +0300 hwmon: (emc1403) Drop hysteresis for low limit temperature [ Upstream commit 75f2c0b3690702c90863c2e138cb5520670845ea ] Remove the hysteresis for low temperature limit, in hardware the hysteresis is applied only to the maxim limit and the critical limit temperature. Fixes: 54392ce4446e3 ("hwmon: (emc1403) Add support for min_hyst attributes") Signed-off-by: Marius Cristea Link: https://lore.kernel.org/r/20260813-emc1403_remove_min_hyst-v1-1-43a0d05d9f49@microchip.com [groeck: Updated subject] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit c38cc41bb9dc2ba7d859a360c8b0efa6991530d4 Author: Guenter Roeck Date: Thu Jun 5 17:35:04 2025 -0700 hwmon: (emc1403) Rely on subsystem locking [ Upstream commit 61e9b50ffa2390a2927051d335b2ba04b8f791ce ] Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck Stable-dep-of: 75f2c0b36907 ("hwmon: (emc1403) Drop hysteresis for low limit temperature") Signed-off-by: Sasha Levin commit 86c1617b7d4b001b20a71deda3c791538a4fa6aa Author: Szymon Wilczek Date: Mon Aug 10 21:23:44 2026 +0200 hwmon: (coretemp) Fix core_data leak on CPUs without PTS [ Upstream commit 0cd8450c257faa0cece0e0c43d3b55d1a389acc7 ] pdata->core_data is allocated in init_temp_data() when the first core temp_data of a package is created, but it is only released from destroy_temp_data(), and only in the branch that handles the package temp_data. Package temp_data is created solely when the CPU supports X86_FEATURE_PTS. On a CPU without it, coretemp_cpu_online() never calls coretemp_add_core() with pkg_flag set, so pdata->pkg_data stays NULL. coretemp_cpu_offline() then skips the removal of the package interface, destroy_temp_data() is never called for package data, and the array is still allocated when coretemp_device_remove() frees the platform data that pointed at it. Release the array in coretemp_device_remove(). destroy_temp_data() sets pdata->core_data to NULL when it frees it, so the added kfree() is a no-op on CPUs that do have PTS. Tested on an Intel Core i5-1135G7. The driver was instrumented to log every allocation and release of pdata->core_data, and the PTS check in coretemp_cpu_online() was patched out to emulate a CPU without package thermal support. Without this change the array was allocated and never released, and coretemp_device_remove() still saw a non-NULL pointer. With it the array is released and the pointer accounting balances. On an unmodified build the release still happens via the package temp_data and the added kfree() sees NULL, with no slab warnings over repeated module load and unload cycles. Fixes: 1a793caf6f69 ("hwmon: (coretemp) Use dynamic allocated memory for core temp_data") Signed-off-by: Szymon Wilczek Link: https://lore.kernel.org/r/20260810192344.3733721-1-swilczek.lx@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 00cce5e457cb690a3b3b3d334e76e71049ec8ae5 Author: John Johansen Date: Wed Aug 12 02:27:15 2026 -0700 apparmor: fix deadlock in complain-mode change_hat [ Upstream commit 4ec11f14d1d6fdda787d991b142537be7841d395 ] The use of change_hat when in complain mode can cause a deadlock when the hat doesn't exist and a new learning profile is created for the missing profile. This is because change_hat() has taken the lock to search the hat list and creating the new learning profile needs to take the lock to add it to the list. From the bug report: Originally found in 7.0.0 in LTS ubuntu 26.04 with pam_apparmor + su in complain mode set to change hats. Then verified in newest available vanilla kernel I've compiled to see if still present: 7.2-rc7 vanilla -> affected checked also some other kernels: 6.18.44 vanilla -> affected 6.12.95 with debian patches -> unaffected On systems without bug (for example 6.12.95 debian) it just prints: aa_change_hat rc=0 On systems with bug, the executable always hangs, prints nothing and becomes unkillable. (And once stuck this way, it will cause any further hat changes to also cause the changing process to get stuck) Then in syslog you can find hint about cause: kernel: INFO: task hat:3409 blocked for more than 483 seconds. kernel: Not tainted 7.2.0-rc7 #1 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: task:hat state:D stack:0 pid:3409 tgid:3409 ppid:2605 task_flags:0x400000 flags:0x00080800 kernel: Call Trace: kernel: kernel: __schedule+0x48f/0xfe0 kernel: schedule+0x27/0xa0 kernel: schedule_preempt_disabled+0x15/0x30 kernel: __mutex_lock.constprop.0+0x569/0xa10 kernel: aa_new_learning_profile+0x15f/0x210 kernel: build_change_hat+0x19f/0x3b0 kernel: change_hat.isra.0+0x5dd/0xd60 kernel: aa_change_hat+0x2f3/0x710 kernel: aa_setprocattr_changehat+0x121/0x1f0 kernel: do_setattr+0x28c/0x340 kernel: apparmor_setselfattr+0x20/0x50 kernel: security_setselfattr+0xf6/0x110 kernel: __x64_sys_lsm_set_self_attr+0x53/0x90 kernel: do_syscall_64+0xdd/0x5e0 kernel: ? __mod_memcg_lruvec_state+0xfd/0x260 kernel: ? lruvec_stat_mod_folio+0x8d/0xd0 kernel: ? __folio_mod_stat+0x2d/0x90 kernel: ? map_anon_folio_pte_nopf+0xd1/0x1f0 kernel: ? do_anonymous_page+0x184/0xa10 kernel: ? __handle_mm_fault+0x805/0x870 kernel: ? count_memcg_events+0xef/0x230 kernel: ? handle_mm_fault+0x1f0/0x2f0 kernel: ? do_user_addr_fault+0x2bb/0x7b0 kernel: ? do_syscall_64+0x94/0x5e0 kernel: ? exc_page_fault+0x75/0x160 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e kernel: RIP: 0033:0x7f815e134c8d kernel: RSP: 002b:00007fff6df94ea8 EFLAGS: 00000246 ORIG_RAX: 00000000000001cc kernel: RAX: ffffffffffffffda RBX: 0000556d8c81d040 RCX: 00007f815e134c8d kernel: RDX: 0000000000000046 RSI: 0000556d8c81d040 RDI: 0000000000000064 kernel: RBP: 00007fff6df94ef0 R08: 00007f815e212ac8 R09: 000000000000000c kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000556d8c81d010 kernel: R13: 0000000000000026 R14: 0000000000000046 R15: 0000000000000064 kernel: kernel: INFO: task hat:3409 is blocked on a mutex likely owned by task hat:3409. To fix the issue, lift the locking out of the core of aa_new_learning_profile(), introduce a wrapper function that takes the lock where needed, and have build_change_hat() call the core function that no longer takes the lock. In addition fix 4 other issues introduced by commit 32e92764d6f8d ("apparmor: grab ns lock and refresh when looking up changehat child profiles") - aa_get_profile_rcu() was replaced-by: aa_get_profile without the accompanying rcu_dereference_protected() - an extra aa_get_label(label) was introduced at the start of change_hat() without an accompanying aa_put_label() causing a reference count leak. - a reference count leak was introduced in the label_is_stale(label) case, where the newest profile would be leaked instead of the label passed to the function. - a potential UAF when the lookup walks up the tree with new_ns != ns the new label reference is put, and then used for the next lookup. The mutex_lock, will block replacement, and removal in the locked ns. However there are two cases where putting the reference can result in the label being freed even with the lock held. 1. the label does not have a list reference (possible for temporary or special profiles) in which case the put can trigger the cleanup. 2. the new label reference is in a different namespace, which does not have a lock held on it. This extends case 1 to also include replacement, and removal that could be occurring in the namespace new is in. Reported-by: Martin Petricek Link: https://lists.ubuntu.com/archives/apparmor/2026-August/014907.html Fixes: 32e92764d6f8d ("apparmor: grab ns lock and refresh when looking up changehat child profiles") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 4609e0e0be709e974bec9b52c5022136d25e97d3 Author: Hongyan Xu Date: Thu Aug 6 14:04:41 2026 +0800 block: mtip32xx: synchronize ioctls with device removal [ Upstream commit 68940f841d013192086a0f6d7cfbac2cd079e228 ] The ioctl handlers only test REMOVE_PENDING before entering mtip_hw_ioctl(). Removal can set that bit immediately afterwards and free dd->port in mtip_hw_exit() while an ioctl still dereferences it. An already open block device can reach the handlers while del_gendisk() is in progress. Serialize both native and compat ioctls with removal. Set REMOVE_PENDING before taking the mutex so new callers fail after an in-flight ioctl has drained, and hold the mutex until the port has been torn down. Fixes: 88523a61558a ("block: Add driver for Micron RealSSD pcie flash cards") Signed-off-by: Hongyan Xu Link: https://patch.msgid.link/20260806060441.676-1-getshell@seu.edu.cn Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7e3e5273fc9ec47a183353b9b3ab9aa8e93832c5 Author: Yao Sang Date: Fri Aug 14 10:32:24 2026 +0800 ublk: reject non-power-of-2 zone sizes in SET_PARAMS [ Upstream commit 2707acf1856da266139986c9398ad722fd4f48c0 ] UBLK_F_ZONED uses params.basic.chunk_sectors as zone size. ublk uses ilog2(chunk_sectors) to get number of zones, so the value must be power of 2. If chunk_sectors is 96 and dev_sectors is 96 * 16, userspace asks for 16 zones. But the shift calculation gets 24 zones. Block layer rejects such zone size when the disk is started. But SET_PARAMS has already returned success, which is confusing for userspace. Reject it in SET_PARAMS with other zoned parameter checks. Fixes: 29802d7ca33b ("ublk: enable zoned storage support") Signed-off-by: Yao Sang Link: https://patch.msgid.link/20260814023226.354288-2-sangyao@kylinos.cn Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 32456a85995579e56c60cc53c357cda75a9d4f7c Author: Niklas Cassel Date: Thu Aug 13 16:14:56 2026 +0200 null_blk: serialize configfs attribute updates with device setup [ Upstream commit 4e1f23f9c33c156be7e313b40695af5a3a834739 ] The attribute store methods generated with NULLB_DEVICE_ATTR() refuse to change the configuration of a live device by testing NULLB_DEV_FL_CONFIGURED, but that flag is only set by nullb_device_power_store() after null_add_dev() has returned, and the store methods take no lock at all. configfs only serializes writes to the same open file (buffer->mutex), so a write to any attribute can run concurrently with null_add_dev() and change the device configuration while it is being used. null_add_dev() reads the configuration several times, e.g. dev->zoned is read once to set up the queue limits and once to initialize the zone resources: CPU0: echo 1 > nullb0/power CPU1: echo 1 > nullb0/zoned nullb_device_power_store() mutex_lock(&lock) null_add_dev() if (dev->zoned) -> false /* no BLK_FEAT_ZONED */ nullb_device_zoned_store() test_bit(FL_CONFIGURED) -> 0 dev->zoned = true blk_mq_alloc_disk() /* queue is not zoned */ if (nullb->dev->zoned) -> true null_register_zoned_dev() blk_revalidate_disk_zones() blk_revalidate_disk_zones() is then called for a queue that does not have BLK_FEAT_ZONED set, which triggers its WARN_ON_ONCE() and fails the device setup with -EIO: WARNING: CPU: 2 PID: 322 at block/blk-zoned.c:2357 blk_revalidate_disk_zones+0x4c/0x560 Clearing dev->zoned in the same window is worse: the queue is created with BLK_FEAT_ZONED but the zone resources are never initialized, so add_disk() succeeds for a zoned disk that has no zones. And a store that lands after the last dev->zoned test leaves dev->zoned set while dev->zones is still NULL, which null_process_zoned_cmd() dereferences on the first write. Fix this by taking the global lock, which nullb_device_power_store() already holds across null_add_dev() and null_del_dev(), around both the NULLB_DEV_FL_CONFIGURED test and the update of the device configuration. The submit_queues and poll_queues apply callbacks are now called with that lock held, so remove the locking they did themselves. Since the store methods can run as soon as configfs_register_subsystem() returns, that is, before null_init() gets to mutex_init(&lock), also initialize the lock statically with DEFINE_MUTEX(). Fixes: 3bf2bd20734e ("nullb: add configfs interface") Reported-by: syzbot+643a6dd130546afdf1fb@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-block/6a7d0b3f.ac361c09.22ff0a.004c.GAE@google.com/ Signed-off-by: Niklas Cassel Reviewed-by: Damien Le Moal Link: https://patch.msgid.link/20260813141456.1625857-2-cassel@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 65cae82fd3c39b53430672cb9e3ecd267471a6ce Author: Zizhi Wo Date: Sat Jul 25 10:25:08 2026 +0800 null_blk: serialize configfs attribute stores with the lock [ Upstream commit 7e7fff51808237703a3a1df6dd5cae1dfd1db86d ] The NULLB_DEVICE_ATTR _store takes no lock: apply_fn attributes (submit_queues, poll_queues) get dev->NAME written again after apply_fn returns, outside its lock; APPLY=NULL attributes are entirely lockless. configfs only serializes stores per-open-file, so concurrent stores on separate fds race. For apply_fn attributes, once one store's apply_fn has reconfigured the hardware, a second (losing) store can still overwrite dev->NAME afterwards. This leaves dev->submit_queues out of sync with the live queue count, which is later caught by the WARN_ON_ONCE() in null_map_queues(). For !apply_fn attributes, power_store()'s null_add_dev() validates and builds the device under "lock" but only sets CONFIGURED afterwards. A store slipping in during this window can change a field mid-setup -- for example, zone_nr_conv can be pushed above nr_zones after it has already been clamped, leading to an out-of-bounds dev->zones[] access. Take "lock" in the macro around the apply_fn call, the CONFIGURED test and the field write, and move it out of nullb_apply_submit_queues()/ nullb_apply_poll_queues() so both paths are covered once. This serializes stores with power_store's setup and with each other. Fixes: 45919fbfe1c4 ("null_blk: Enable modifying 'submit_queues' after an instance has been configured") Suggested-by: Bart Van Assche Signed-off-by: Zizhi Wo Reviewed-by: Nilay Shroff Link: https://patch.msgid.link/20260725022509.714271-10-wozizhi@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3e35ad503386a2e8a0e0460530dcbf421c79f6f2 Author: Zizhi Wo Date: Sat Jul 25 10:25:06 2026 +0800 null_blk: reject per-device queue resize for shared tag set [ Upstream commit 1cdfe2fa62b48728a9b436fbbd3dbe4c11593e24 ] When shared_tags is enabled, null_setup_tagset() makes the device use the global tag_set, whose driver_data stays NULL. null_map_queues() therefore falls back to the module-wide g_submit_queues/g_poll_queues instead of any per-device value. Resizing submit_queues or poll_queues via configfs on such a device calls blk_mq_update_nr_hw_queues() on the shared set, shrinking set->nr_hw_queues. __blk_mq_realloc_hw_ctxs() only grows the q->queue_hw_ctx[] allocation, so on shrink it merely exits and NULLs the now-excess hctx slots. null_map_queues(), however, keeps mapping CPUs with the unchanged g_submit_queues/g_poll_queues, so mq_map[] ends up pointing at those NULLed hctx slots. blk_mq_map_swqueue() then dereferences the NULL hctx (hctx->cpumask), crashing the kernel: [ 460.218374] KASAN: null-ptr-deref in range [0x0000000000000098-0x000000000000009f] [ 460.219003] CPU: 24 UID: 0 PID: 1492 Comm: sh Not tainted 7.2.0-rc2+ #67 PREEMPT(full) [ 460.219792] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 [ 460.220452] RIP: 0010:blk_mq_map_swqueue+0x4db/0x1430 ...... [ 460.228977] Call Trace: [ 460.229175] [ 460.229354] blk_mq_update_nr_hw_queues+0xd49/0x11c0 [ 460.229779] ? __pfx_blk_mq_update_nr_hw_queues+0x10/0x10 [ 460.230200] nullb_update_nr_hw_queues+0x1a9/0x370 [null_blk] [ 460.230694] nullb_device_submit_queues_store+0xd9/0x170 [null_blk] [ 460.231190] ? __pfx_nullb_device_submit_queues_store+0x10/0x10 [null_blk] [ 460.231776] ? configfs_write_iter+0x35c/0x4e0 [ 460.232122] configfs_write_iter+0x286/0x4e0 [ 460.232460] vfs_write+0x52d/0xd00 [ 460.232779] ? __x64_sys_openat+0x108/0x1d0 [ 460.233106] ? __pfx_vfs_write+0x10/0x10 [ 460.233413] ? fdget_pos+0x1cf/0x4c0 [ 460.233745] ? fput_close+0x133/0x190 [ 460.234038] ? __pfx_expand_files+0x10/0x10 [ 460.234368] ksys_write+0xfc/0x1d0 Reproducer: modprobe null_blk shared_tags=1 submit_queues=64 poll_queues=1 mkdir /sys/kernel/config/nullb/dev echo 1 > /sys/kernel/config/nullb/dev/power echo 1 > /sys/kernel/config/nullb/dev/submit_queues A per-device resize of a shared tag set is meaningless anyway, so reject it with -EINVAL in nullb_update_nr_hw_queues() when the device is bound to the global tag_set. Fixes: 45919fbfe1c4 ("null_blk: Enable modifying 'submit_queues' after an instance has been configured") Suggested-by: Nilay Shroff Assisted-by: Claude-Code:GLM-5.2 Signed-off-by: Zizhi Wo Reviewed-by: Nilay Shroff Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260725022509.714271-8-wozizhi@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b2437d37fcc31fce8a5da1cc1739e284814d2491 Author: Zizhi Wo Date: Sat Jul 25 10:25:04 2026 +0800 null_blk: free zones array on device power-off [ Upstream commit 2a6357a9b935a34f5508618fee8a7fffbf7722a8 ] null_init_zoned_dev() allocates dev->zones when a zoned device is powered on, but null_del_dev() never frees it on power-off; dev->zones is only freed later in null_free_dev(), when the configfs directory is removed. If the device is powered off and then on again, null_init_zoned_dev() allocates a new array and overwrites the dev->zones pointer, leaking the previous allocation each power cycle. Free dev->zones in null_del_dev() via null_free_zoned_dev() to solve it. And calling null_free_zoned_dev() in null_free_dev() is no longer necessary because every caller already invokes null_del_dev() first: via nullb_group_drop_item() before nullb_device_release(), in the null_add_dev() error path of null_create_dev(), and in null_destroy_dev(). Remove the redundant call. And take &lock around zone_cond_store() in the two store wrappers to serialize dev->zones check-and-deref against its alloc/free, which already run under &lock. The reason there was no problem before is that only nullb_device_release() or null_exit() frees the dev->zones, which guarantees that subsequent users won't access the configfs interface. Fixes: ca4b2a011948 ("null_blk: add zone support") Assisted-by: Claude-Code:GLM-5.2 Signed-off-by: Zizhi Wo Reviewed-by: Nilay Shroff Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260725022509.714271-6-wozizhi@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2b59484ac1e64dd78dbe8c6140891c6308085a75 Author: Zizhi Wo Date: Sat Jul 25 10:25:03 2026 +0800 null_blk: free global tag_set on init error path [ Upstream commit 5a1c5ff3a49ba93a1fd0b70537e7a0164071760d ] If shared_tags is enabled, null_setup_tagset() allocates the global tag_set via null_init_global_tag_set(). If device creation later fails, err_dev destroys the default devices and calls unregister_blkdev(), but never frees the global tag_set. Since module init failed, null_exit() is never invoked, so the global tag_set's tags and maps are permanently leaked. Free the global tag_set in err_dev, matching null_exit() which does if (tag_set.ops) blk_mq_free_tag_set(&tag_set). Fixes: 82f402fefa50 ("null_blk: add support for shared tags") Signed-off-by: Zizhi Wo Reviewed-by: Damien Le Moal Reviewed-by: Bart Van Assche Reviewed-by: Nilay Shroff Link: https://patch.msgid.link/20260725022509.714271-5-wozizhi@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d761be1b8f2bbabc41252deb79a426d3f0d4fa10 Author: Zizhi Wo Date: Sat Jul 25 10:25:01 2026 +0800 null_blk: register configfs subsystem after creating default devices [ Upstream commit c9d293d6bb0575fcb1f3408129453187e2a28a4e ] In null_init(), configfs_register_subsystem() currently runs before register_blkdev(), so when null_blk is built as a module, a racing mkdir() + poweron from userspace can reach null_add_dev() while null_major is still 0. __add_disk() then hits WARN_ON(disk->minors) (major=0 with minors!=0) and fails: [root@fedora ~]# [ 2366.521436] WARNING: block/genhd.c:476 at __add_disk+0x8a7/0xde0, [ 2366.523552] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib [ 2366.529081] CPU: 26 UID: 0 PID: 1600 Comm: sh Not tainted 7.2.0-rc1+ #66 PREEMPT(full) ...... [ 2366.547251] Call Trace: [ 2366.547575] [ 2366.547831] ? _raw_spin_lock+0x84/0xe0 [ 2366.548260] add_disk_fwnode+0x114/0x560 [ 2366.548739] null_add_dev+0x102d/0x1b80 [null_blk] [ 2366.549310] ? __pfx_null_add_dev+0x10/0x10 [null_blk] [ 2366.549906] ? mutex_lock+0xde/0x1c0 [ 2366.550361] ? __pfx_mutex_lock+0x10/0x10 [ 2366.550827] nullb_device_power_store+0x1e7/0x280 [null_blk] [ 2366.551499] ? __pfx_nullb_device_power_store+0x10/0x10 [null_blk] [ 2366.552177] ? __kmalloc_cache_noprof+0x1f5/0x470 [ 2366.552748] ? configfs_write_iter+0x35c/0x4e0 [ 2366.553242] configfs_write_iter+0x286/0x4e0 [ 2366.553787] vfs_write+0x52d/0xd00 [ 2366.554169] ? __pfx_vfs_write+0x10/0x10 [ 2366.554679] ? __pfx___css_rstat_updated+0x10/0x10 [ 2366.555196] ? fdget_pos+0x1cf/0x4c0 [ 2366.555649] ksys_write+0xfc/0x1d0 ...... Additionally, the err_dev path destroys all devices on nullb_list while configfs is still registered. If a racing mkdir() + poweron puts a user device on the list, null_destroy_dev()->null_free_dev() kfrees the user device's nullb_device but /sys/kernel/config/nullb/ is still reachable. Any userspace access to the item will trigger a UAF. For simplicity, move configfs_register_subsystem() to the end to solve the problems above. Fixes: 3bf2bd20734e ("nullb: add configfs interface") Signed-off-by: Zizhi Wo Reviewed-by: Damien Le Moal Reviewed-by: Bart Van Assche Reviewed-by: Nilay Shroff Link: https://patch.msgid.link/20260725022509.714271-3-wozizhi@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c7dea90c9b4ef1dfbd2e4df36de180c76fd7c33c Author: Zizhi Wo Date: Sat Jul 25 10:25:00 2026 +0800 null_blk: use DEFINE_MUTEX for the file-scope mutex [ Upstream commit 017dac7670909eaea3eb36e6b3b5a8be9ce0a14d ] In null_init(), mutex_init(&lock) currently happens after configfs_register_subsystem(), which exposes the nullb subsystem to userspace. A racing mkdir() into /sys/kernel/config/nullb/ can reach null_find_dev_by_name() -> mutex_lock(&lock) before the mutex is initialized, trigger warning: [ 123.137788] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 123.137796] WARNING: kernel/locking/mutex.c:159 at mutex_lock+0x171/0x1c0, CPU#13: mkdir/1301 [ 123.140090] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 ...... [ 123.154926] Call Trace: [ 123.155172] [ 123.155419] ? __pfx_mutex_lock+0x10/0x10 [ 123.156181] ? __pfx__raw_spin_lock+0x10/0x10 [ 123.156571] nullb_group_make_group+0x20/0x100 [null_blk] [ 123.157011] configfs_mkdir+0x47b/0xc70 [ 123.157337] ? __pfx_configfs_mkdir+0x10/0x10 [ 123.157719] ? may_create_dentry+0x242/0x2e0 [ 123.158061] vfs_mkdir+0x2a9/0x6c0 [ 123.158352] filename_mkdirat+0x3dc/0x500 [ 123.158710] ? __pfx_filename_mkdirat+0x10/0x10 [ 123.159070] ? strncpy_from_user+0x3a/0x1d0 [ 123.159413] __x64_sys_mkdir+0x6b/0x90 [ 123.159760] do_syscall_64+0xea/0x600 Replace the runtime mutex_init(&lock) with a static DEFINE_MUTEX(lock) declaration to fix this issue. Fixes: 49c3b9266a71 ("block: null_blk: Improve device creation with configfs") Suggested-by: Bart Van Assche Signed-off-by: Zizhi Wo Reviewed-by: Bart Van Assche Reviewed-by: Damien Le Moal Reviewed-by: Nilay Shroff Link: https://patch.msgid.link/20260725022509.714271-2-wozizhi@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cbc24bce70dfd91c7b2f53b4fa896e9a4b6d6a6b Author: Pengpeng Hou Date: Fri Aug 14 16:02:15 2026 +0800 mailbox: riscv-sbi-mpxy: validate RPMI notification lengths [ Upstream commit 11d5af151bcbe78f5a579e0faecd3be9cea0399a ] The SBI return value controls how many bytes are copied from shared memory into the RPMI notification buffer. It is not validated against the negotiated shared-memory size before that copy. The event walker also uses a reversed loop condition and can inspect a short event record. Validate the complete notification length before copying it, iterate only while a full event header remains, and stop when a declared event payload extends beyond the copied notification data. Fixes: bf3022a4eb11 ("mailbox: Add RISC-V SBI message proxy (MPXY) based mailbox driver") Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 1bd910aae6abd5992729b7673a8ce3ec8091c9ea Author: Huisong Li Date: Thu Jul 23 15:39:28 2026 +0100 mailbox: pcc: Fix command timeout due to missed interrupt [ Upstream commit 3360b088175dc5d5c9166685836158470d00571e ] PCC command execution can time out when a fast platform completes a transaction and signals the platform interrupt before pcc_send_data() marks the channel as in use. For shared platform interrupts, the type 3 handler uses chan_in_use to decide whether the interrupt belongs to the channel. If it observes false, it ignores the completion and the caller waits until timeout. Publish chan_in_use before ringing the doorbell. Use WRITE_ONCE() for the lockless flag updates and READ_ONCE() in the interrupt handler. The following ordered I/O accessor orders the flag store before the platform is notified. Clear chan_in_use if ringing the doorbell fails. Otherwise, leave it set until the interrupt handler completes the transaction, clearing it before the mailbox core can submit another transfer. Fixes: 3db174e478cb ("mailbox: pcc: Support shared interrupt for multiple subspaces") Signed-off-by: Huisong Li Signed-off-by: Sudeep Holla Tested-by: Adam Young Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit d255b6575650b1a53d2b802369068d67a79ce660 Author: Linmao Li Date: Tue Jul 28 17:16:22 2026 +0800 mailbox: rockchip: disable pclk on probe failure and unbind [ Upstream commit ded48fcbdc1e3ed1dc8e1974b7fe9639fcea6dd6 ] rockchip_mbox_probe() enables the peripheral clock and then keeps going. None of the later failure paths - platform_get_irq(), devm_request_threaded_irq() and devm_mbox_controller_register() - disables it again. The driver has no remove callback either, so the clock also stays prepared and enabled once the device is unbound, and its enable count keeps growing over bind/unbind cycles. Use devm_clk_get_enabled() to tie disabling and unpreparing the clock to the device lifetime. It is registered before the interrupts and the mailbox controller, so devres releases it after both are gone. While rewriting the error path, switch it to dev_err_probe() so that a deferred probe is not reported as an error. Fixes: f70ed3b5dc8b ("mailbox: rockchip: Add Rockchip mailbox driver") Signed-off-by: Linmao Li Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 413b0b94d6d06b8d49735280e86a01dac90cf177 Author: Jia Yang Date: Thu Aug 6 15:03:57 2026 +0800 mailbox: qcom-cpucp: handle NULL data in send_data callback [ Upstream commit fc4f2f99530298a1739226947aa76525142d421d ] mailbox_clear_channel() calls mbox_send_message() with NULL data to notify the remote side that the RX channel has been cleared. qcom_cpucp_mbox_send_data() blindly dereferenced the data pointer, causing a NULL pointer dereference kernel panic when invoked from this path under PREEMPT_RT. Add an explicit NULL check and return early without writing to the TX register, which is the correct behaviour for a channel-clear notification. Fixes: 0e2a9a03106c ("mailbox: Add support for QTI CPUCP mailbox controller") Signed-off-by: Jia Yang Reviewed-by: Dmitry Baryshkov Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 8b8de6400c86937ed57d680d06d716e167b381de Author: Jia Yang Date: Thu Aug 6 15:03:56 2026 +0800 mailbox: qcom-cpucp: fix PREEMPT_RT self-deadlock in IRQ handler [ Upstream commit 3690aaa6d18f6775c3e7932fb8af8c5bf6a6b69c ] qcom_cpucp_mbox_irq_fn() calls mbox_chan_received_data() while holding chan->lock. Under PREEMPT_RT, spin_lock_irqsave() is converted to an rt_spinlock (rtmutex-based), which tracks ownership and can sleep. The callback chain triggered by mbox_chan_received_data() eventually reaches mailbox_clear_channel() -> mbox_send_message() -> add_to_rbuf(), which attempts to re-acquire the same chan->lock. Since rtmutex detects the re-entrant lock attempt by the same owner, the thread blocks waiting for a lock it already holds, causing a permanent deadlock. This deadlock manifests as 'irq/N-apss_cpucp_mbox' stuck in D state with the following call trace: rt_spin_lock -> mbox_send_message -> mailbox_clear_channel -> scmi_rx_callback -> mbox_chan_received_data [<- held chan->lock here] Fix by saving chan->cl locally and clearing the HW interrupt register inside the lock, then invoking mbox_chan_received_data() after releasing the lock. This preserves the mutual exclusion for chan->cl access while avoiding the lock re-entrancy that causes the PREEMPT_RT deadlock. Fixes: 0e2a9a03106c ("mailbox: Add support for QTI CPUCP mailbox controller") Signed-off-by: Jia Yang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit eb05c19dfb36dff00c157eb5aa031eb9cae78272 Author: Arnaldo Carvalho de Melo Date: Thu Aug 13 12:11:46 2026 -0300 perf dso: Replace assert with runtime check in dso__read_symbol() [ Upstream commit 62972e5644e48255dcc715e6ec4401882f8b37d1 ] dso__read_symbol() asserts that len <= jited_prog_len, where len comes from sym->end - sym->start (parsed from PERF_RECORD_KSYMBOL in perf.data). Both values originate from untrusted file input. With NDEBUG (production builds), the assert is compiled out, allowing an out-of-bounds heap read when the BPF program buffer is accessed. Without NDEBUG, a crafted perf.data crashes perf with an assertion failure. Replace the assert with a runtime bounds check that returns NULL with an appropriate error code, matching the existing error handling pattern in this function. Fixes: aa04707f507e ("perf dso: Support BPF programs in dso__read_symbol()") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Song Liu Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit ac09bbbde1d4953f6c0b1f2ff05ba1c716f9bfdb Author: Arnaldo Carvalho de Melo Date: Thu Aug 13 12:11:45 2026 -0300 perf dso: Guard against cache underflow on short reads in dso_cache__memcpy() [ Upstream commit 390a9461cd73bdd13acc0f6d763618ae1ff8fa17 ] dso_cache__memcpy() computes cache_offset = offset - cache->offset, then cache_size = min(cache->size - cache_offset, size). The RB tree lookup in __dso_cache__find() matches using the full DSO__DATA_CACHE_SIZE window, but cache->size reflects the actual pread return value from dso_cache__populate(). A short pread (e.g. near end-of-file) makes cache->size smaller than DSO__DATA_CACHE_SIZE. If a subsequent access targets an offset past cache->offset + cache->size but within the DSO__DATA_CACHE_SIZE window, the cache entry is found but cache_offset exceeds cache->size. Since both are u64, the subtraction cache->size - cache_offset wraps to a large value, min() selects the caller's size, and memcpy reads out of bounds. Return 0 for an offset past the valid cached data. For a regular file a short pread only happens at end-of-file, so 0 is what a direct pread() at that offset would return: cached_io() stops its read loop as on EOF. Re-reading from the backing file would not help — a second pread at the same offset returns the same short count. Fixes: 366df72657e0 ("perf dso: Refactor dso_cache__read()") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit d3eaeabc08ae92fc67c1806915b5e79b38b94d96 Author: Arnaldo Carvalho de Melo Date: Thu Aug 13 12:11:44 2026 -0300 perf dso: Use stored fd error instead of stale errno in file_read() and file_size() [ Upstream commit 075d2c32353ded0fe5f3b62f4aa4e98dccb3fb29 ] file_read() and file_size() use ret = -errno when dso__data(dso)->fd is negative after try_to_open_dso() fails. By this point errno has been through mutex_lock(), nsinfo__mountns_enter(), and multiple open() attempts inside try_to_open_dso() — it no longer reflects the actual open failure. If errno happens to be 0, ret = 0 looks like EOF rather than an error, and file_size() callers like dso__data_size() would then report a zero-sized file instead of failing. dso__data(dso)->fd is always negative on failure — -errno from __open_dso() when no filename could be built (e.g. -EINVAL, -ENOENT), or -1 when do_open() itself failed — and never 0, so use it directly instead of reading the stale global errno. No assert() or comment is needed after the assignment: the enclosing if (dso__data(dso)->fd < 0) already guarantees ret < 0 [Namhyung Kim review]. Fixes: 33bdedcea2d7 ("perf tools: Protect dso cache fd with a mutex") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit dd9560c7b46e2e893316a760af35d31d0ac15eb7 Author: Arnaldo Carvalho de Melo Date: Thu Aug 13 12:11:43 2026 -0300 perf dso: Guard close() against invalid fd in dso__decompress_kmodule_path() [ Upstream commit 10f452dc2de401be76ae8e7395c9663313df8b53 ] dso__decompress_kmodule_path() unconditionally calls close(fd) on the return value of decompress_kmodule(). When decompression fails or the DSO is not compressed, decompress_kmodule() returns -1. close(-1) fails with EBADF and clobbers errno, which callers up the chain (dso__get_filename → __open_dso) depend on for error propagation. Guard the close() call with fd >= 0 so only valid file descriptors are closed. Fixes: 42b3fa670825 ("perf tools: Introduce dso__decompress_kmodule_{fd,path}") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b40859b3257721ade8e07314dd90cf01689ff8aa Author: Arnaldo Carvalho de Melo Date: Thu Aug 13 12:11:42 2026 -0300 perf dso: Guard against errno==0 when dso__get_filename() returns NULL [ Upstream commit 51a7a9ddcb3ebc86615886b1f44e85bdea9df326 ] __open_dso() computes fd = -errno when dso__get_filename() returns NULL. Some failure paths in dso__get_filename() (e.g. binary type mismatch) return NULL without making a syscall, leaving errno at 0 from a prior successful call. fd = -0 = 0, which is stdin — subsequent code treats it as a valid file descriptor. Fall back to ENOENT when errno is 0, ensuring fd is always negative on failure. The forced ENOENT stays in errno for the callers that check it after a negative fd. It must not misdirect the try_to_open_dso() fallback loop, though: dso__get_filename()'s chroot fallback used to accept a stale ENOENT even when stat() succeeded on a non-regular file (e.g. a directory). Re-stat() there and only take the chroot path when stat() actually failed with ENOENT [sashiko-bot review of PATCH 1/5]. Fixes: eba5102d2f0b ("perf tools: Add global list of opened dso objects") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b8f8642178656cecfcca012185a95c7096e0e785 Author: Tao Cui Date: Sat Aug 15 12:59:05 2026 +0800 sched_ext/scx_flatcg: Fix cvtime true-up on slice expiry [ Upstream commit 9b4243d30469e7733730e786792d1560442e229e ] fcg_dispatch() true-ups the current cgroup's cvtime when its slice expires or its DSQ runs empty while the slice is still active: __sync_fetch_and_add(&cgc->cvtime_delta, (cpuc->cur_at + cgrp_slice_ns - now) * FCG_HWEIGHT_ONE / (cgc->hweight ?: 1)); The true-up should be actual minus charged: on CNS_EXPIRE, the overrun (now - cur_at - cgrp_slice_ns) should be added; on CNS_EMPTY, the unused portion of the slice should be subtracted. The expression above has the sign inverted, and in the CNS_EXPIRE case now is already past cur_at + cgrp_slice_ns, so the u64 subtraction wraps. The multiplication preserves the two's complement encoding but the unsigned division by hweight destroys it, adding roughly 2^64/hweight per expiry instead of a small correction. Under saturation the hweight budget clamp in cgrp_cap_budget() masks most of the garbage, so the weight distribution barely moves, but the accounting is broken all the same. Compute the delta as a signed value and use fetch_and_add()/fetch_and_sub() so that the dividends stay positive, as BPF division is unsigned. Instrumented the true-up and ran a saturated three-leaf cgroup tree on a 4-CPU VM: without the fix, each expiry added ~5e15 (2^64/hweight territory) to cvtime_delta; with it, the corrections are back to slice scale, with the overrun added and the unused portion subtracted. Fixes: a4103eacc2ab ("sched_ext: Add a cgroup scheduler which uses flattened hierarchy") Suggested-by: Tejun Heo Signed-off-by: Tao Cui Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 9d634e8f9e20ae0b08e78c918f277f308760338f Author: Karl Mehltretter Date: Sat Aug 8 13:48:48 2026 +0200 crypto: lskcipher - propagate errors from unaligned crypt [ Upstream commit 7537036a2e6fe96f8ed82034f755c54714a0e417 ] The while loop declares a second err variable that shadows the outer one. When the crypt callback fails, the goto out path returns the outer err, which still holds the -ENOMEM value assigned before the successful allocation check. The real error from the cipher is discarded and the caller sees -ENOMEM instead. Drop the inner declaration so the callback error reaches the caller. Verified with a test module that registers an lskcipher whose encrypt callback fails with -EIO and calls it through a misaligned buffer. An unpatched kernel returns -ENOMEM, a patched kernel returns -EIO. Found with Clang's -Wshadow. Fixes: 31865c4c4db2b ("crypto: skcipher - Add lskcipher") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8c9b0a3a6d27f8980d382e3f4c7b2ae37f18d624 Author: Zhushuai Yin Date: Tue Aug 4 10:22:07 2026 +0800 crypto: hisilicon/sec2 - fix CCM algorithm long packet failure [ Upstream commit b82f60be50c87b3d75e207852c5ca74fa18f66cf ] In the CCM B0 block the message-length field Q spans L bytes, where L (cl in the driver) is derived from the cipher IV flags byte as c_ivin[0] + 1. set_aead_auth_iv() hardcoded writing only the last 2 bytes of a_ivin with cryptlen, implicitly assuming cl = 2. When cl = 3 (a shorter nonce yielding a 3-byte length field) and the packet is longer than 65535 bytes, cryptlen no longer fits in 2 bytes. The dropped high byte made the auth IV built by the driver differ from the one consumed by the hardware, so the software/hardware comparison failed and the CCM request errored out. Write the last cl bytes of a_ivin in a loop driven by the IV's CL value, so the length-field width always matches the algorithm configuration instead of assuming a fixed 2-byte field. Fixes: c16a70c1f253 ("crypto: hisilicon/sec - add new algorithm mode for AEAD") Signed-off-by: Zhushuai Yin Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit efcfda20b7b7fb0520625c321a9cb61d98ed8d6e Author: Michal Blaszczyk Date: Tue Aug 11 14:13:58 2026 +0000 selftests/sched_ext: Fix flaky ddsp failure tests on busy systems [ Upstream commit e72979d3264a87a6a2dfb44fe0f5723a17d2ef84 ] The ddsp_vtimelocal_fail and ddsp_bogus_dsq_fail tests skip calling scx_bpf_dsq_insert_vtime() if scx_bpf_pick_idle_cpu() fails to find an idle CPU (returns a negative error code). On loaded systems, this results in the tests skipping the very assertions they are meant to verify. Eliminate this flakiness by falling back to prev_cpu if no idle CPU is found, ensuring the illegal dispatch operations are unconditionally attempted and tested. Fixes: a5db7817af78 ("sched_ext: Add selftests") Signed-off-by: Michal Blaszczyk Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 6b019f0daa613ecd74d5b39ec845d6e9954fabd0 Author: Israel Téllez García Date: Fri Aug 14 14:48:40 2026 +0200 bpf: Fix pending_pos walk on 32-bit ring position wrap [ Upstream commit 6ff5b56a50c5351aeeb180e34327736576c038fa ] The reservation path caches the position of the oldest not-yet-committed record in rb->pending_pos and advances it past already committed records on every reservation: while (pend_pos < prod_pos) { consumer_pos, producer_pos and pending_pos are unsigned long, i.e. 32-bit on 32-bit architectures, and Documentation/bpf/ringbuf.rst states that these counters may wrap around there. Every other comparison in the file is written as a difference, so modular arithmetic keeps them correct across the wrap. This one is an ordering comparison, and it is not wrap-safe. Once producer_pos wraps past 2^32, prod_pos is small while pend_pos still holds its pre-wrap value, so the loop condition is false and pending_pos is never advanced again. Reservations keep succeeding for a while, because bpf_ringbuf_has_space() uses differences, but new_prod_pos - pend_pos grows as the producer advances, and once it exceeds rb->mask every subsequent __bpf_ringbuf_reserve() call fails: the kernel believes a pending record spans the whole buffer. The ring never recovers, bpf_ringbuf_output() drops every event from then on, and nothing is logged. Observed on four armv7 devices (i.MX7 Dual, 6.6.52) running a tracepoint-based collector with a 512 KiB ring and 160-byte records. Every one of them stopped delivering after exactly 26846821 records and 4295491360 bytes had passed through the ring, at event rates between 441 and 862 records/s, that is after 8 h to 17 h of uptime: the trigger is the byte count, not time or load. That figure is 2^32 plus 524064 bytes, and the excess is one ring's worth of grace period, as expected while new_prod_pos - pend_pos is still below rb->mask. The last reservation that fits is the largest record boundary X with X + 160 <= 524287, and since 2^32 mod 160 = 96 the boundaries after the wrap sit at X = 64 (mod 160), giving X = 524064. Userspace kept consuming normally until the producer stopped, then read zero records for good. With this patch applied, one of the four devices took 10 GiB through the same ring with no stall, while the three unpatched ones kept wedging at the same byte count. 64-bit hosts are unaffected in practice: their counters would need 16 EiB to wrap. Compare the two positions as a difference instead. pending_pos never runs ahead of producer_pos, so the unsigned difference is the real distance between them and stays correct across the wrap. Fixes: cfa1a2329a69 ("bpf: Fix overrunning reservations in ringbuf") Signed-off-by: Israel Téllez García Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260814124843.22041-2-i.tellez@btesa.com Signed-off-by: Sasha Levin commit 15512c6b5dea72fb5f1f41c1aa96f3f32531ca03 Author: Hongyan Xu Date: Sat Aug 8 16:59:42 2026 +0800 ACPI: scan: fix bus ID cleanup on device_add() failures [ Upstream commit a414485ebc2aa50907d0ce97cde2b1a353696897 ] When device_add() fails after acpi_device_set_name() has allocated an instance ID and a new acpi_device_bus_id has been linked into acpi_bus_id_list, the rollback path only removes wakeup_list and detaches the ACPI handle data. That leaves the bus-ID bookkeeping behind and keeps the allocated instance number consumed. Move the bus-ID cleanup and wakeup-list removal into a single helper. Use it from both the normal device teardown path and the device_add() rollback path. The wakeup list node is initialized before registration, so it can be deleted without checking whether the device is wakeup- capable like in the original teardown path. Fixes: d783156ea384 ("ACPI / scan: Define non-empty device removal handler") Signed-off-by: Hongyan Xu [ rjw: Rename acpi_device_del_list() to acpi_device_cleanup() ] [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260808085943.526-1-getshell@seu.edu.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 04a43c321e10620a30a5c61d3bf559591e03c744 Author: Vincent Donnefort Date: Thu Aug 13 14:11:50 2026 +0100 ring-buffer: Remove trace_buffer::cpus [ Upstream commit d9b5e22bf24d5c82522475306cd332b287ac43bc ] The 'cpus' field in struct trace_buffer became useless in commit 8e7b58c27b3c ("ring-buffer: Just update the subbuffers when changing their allocation order"). Remove it Link: https://patch.msgid.link/20260813131152.3589632-9-vdonnefort@google.com Fixes: 8e7b58c27b3c ("ring-buffer: Just update the subbuffers when changing their allocation order") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 801ae90f8ce099187e6224cec7d72d07a4df0324 Author: Pu Lehui Date: Fri Aug 14 06:47:26 2026 +0000 riscv, bpf: Fix missing sign-ext for signed 1-byte and 2-byte kfunc args [ Upstream commit f2aaa621591093cfe8224a25ef2f04a3b1e304b0 ] On RV64, the ABI requires sign-extension for signed 1-byte and 2-byte kfunc args. However, the RV64 JIT currently does not perform sign-extension for such kfunc args. Before commit 7ce090afbf72 ("bpf: Infer zext_dst based on static register liveness analysis"), state pruning could potentially omit zero-extension of 32-bit subregisters, which inadvertently masked the above issue by making the args appear as if they had been properly sign-extended. After that commit, the problem is exposed, causing the kfunc_call/kfunc_call_test4 selftest to fail. Fix this by extending the existing sign-extension logic to handle signed 1-byte and 2-byte kfunc args as well. Fixes: 443574b03387 ("riscv, bpf: Fix kfunc parameters incompatibility between bpf and riscv abi") Signed-off-by: Pu Lehui Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260814064726.3607615-1-pulehui@huaweicloud.com Signed-off-by: Sasha Levin commit 5a19c3fccc7e39f11a693b19535ba417acb08ad4 Author: Andrii Nakryiko Date: Thu Aug 13 14:35:58 2026 -0700 selftests/bpf: Use ping_command() for IPv6 pings in lwt_ip_encap [ Upstream commit 073574da7a8e6055b1687c256bea070ab4b4ebea ] lwt_ip_encap hardcodes the ping6 binary for its IPv6 pings. iputils merged ping6 into ping long ago and distros have started dropping the compat symlink -- Arch's iputils 20250605 ships only arping, clockdiff, ping and tracepath. There, every lwt_ip_encap subtest fails: check_ping_ok:FAIL:ip netns exec ns-lwt-ip-encap-1-0101330 ping6 -c 1 \ -W1 -I veth1 fb04::1 > /dev/null unexpected error: 256 (errno 2) #217/1 lwt_ip_encap_ipv4/egress:FAIL The IPv4 subtests fail too, because check_ping_ok() pings both families. SYS() runs the command through system(), so a missing binary is indistinguishable from an unreachable peer. network_helpers.c has had ping_command() for exactly this since commit 372642ea83ff ("selftests/bpf: Move netcnt test under test_progs"): it falls back to "ping -6" when ping6 is not present. lwt_ip_encap.c is the last hardcoded ping6 user. Fix that. Fixes: f5e288943e2c ("selftests/bpf: Move test_lwt_ip_encap to test_progs") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20260813213558.3103179-1-andrii@kernel.org Signed-off-by: Sasha Levin commit 17a4dd3b0e6dafb731bbc25817d3c45ac2b2d535 Author: Leon Hwang Date: Tue Jun 2 23:09:31 2026 +0800 selftests/bpf: Add tests to verify the fix of encapsulating VxLAN in lwt [ Upstream commit 5477d55f351fea3eeb2c5c77a9224eed0fd4d6a9 ] Add two tests to verify the transport header of skb has been set when encapsulate VxLAN using bpf_lwt_push_encap() helper. 1. VxLAN over IPv4. 2. VxLAN over IPv6. Without the fix, the tests would fail: lwt_ip_encap_vxlan:FAIL:transport_hdr offset unexpected transport_hdr offset: actual 70 != expected 20 #208 lwt_ip_encap_vxlan_ipv4:FAIL lwt_ip_encap_vxlan:FAIL:transport_hdr offset unexpected transport_hdr offset: actual 110 != expected 40 #209 lwt_ip_encap_vxlan_ipv6:FAIL The unexpected offsets are: outer encap headers (IPv4: iphdr+udp+vxlan+eth = 50 bytes, IPv6: ipv6hdr+udp+vxlan+eth = 70 bytes) plus the inner IP header (20 or 40 bytes), because without the fix transport_header still points at the inner transport layer instead of the outer UDP header. Assisted-by: Claude:claude-sonnet-4-6 Cc: Leon Hwang Signed-off-by: Leon Hwang Link: https://lore.kernel.org/r/20260602150931.49629-3-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov Stable-dep-of: 073574da7a8e ("selftests/bpf: Use ping_command() for IPv6 pings in lwt_ip_encap") Signed-off-by: Sasha Levin commit 54bff7c8e410a7180b769c83121badbce42e335f Author: Xianglin Lin <1021538027@qq.com> Date: Sat Jul 11 22:22:55 2026 +0800 HID: multitouch: reclassify HTIX5288 to WIN_8_FORCE_MULTI_INPUT_NSMU [ Upstream commit 69226cd6fad7a07370ec9a009af1c174de7635c5 ] Commit b5e65ae557da ("HID: multitouch: Add quirk for Hantick 5288 touchpad") assigned MT_CLS_NSMU to the HTIX5288 (0911:5288). This was necessary because the device sometimes fails to send touch release signals when transitioning from >=2 fingers to <2 fingers, and MT_QUIRK_NOT_SEEN_MEANS_UP fixes stuck touches by treating missing contacts as released. However, MT_CLS_NSMU only carries MT_QUIRK_NOT_SEEN_MEANS_UP. It lacks MT_QUIRK_CONTACT_CNT_ACCURATE and MT_QUIRK_IGNORE_DUPLICATES. As a result, after a two-finger scroll finger lift, the device still reports stale coordinates from the released contact in subsequent frames, and the driver overwrites the remaining active slot with those frozen coordinates. The remaining finger appears stuck at the lift position until all fingers are lifted. This was confirmed via evtest on Arch Linux 7.1.3: after TRACKING_ID=-1 for the released slot, every subsequent frame contained duplicate position pairs -- the real moving finger's coordinates followed by the lifted finger's frozen position, both attributed to the active slot. Reclassify the device to MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU (0x0018), which preserves the original MT_QUIRK_NOT_SEEN_MEANS_UP fix while adding the necessary Win8 quirks (CONTACT_CNT_ACCURATE, IGNORE_DUPLICATES), preventing stale coordinate contamination. The additional FORCE_MULTI_INPUT flag is harmless here: it separates the mouse and touchpad collections into distinct input devices, which is the standard behavior libinput already expects. Fixes: b5e65ae557da ("HID: multitouch: Add quirk for Hantick 5288 touchpad") Signed-off-by: Xianglin Lin <1021538027@qq.com> Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit d2f41287b51a3261d447ae38000f7a6f5860663a Author: Pengpeng Hou Date: Fri Aug 14 16:12:38 2026 +0800 ASoC: SOF: validate topology volume range before allocation [ Upstream commit a698e4a60fa54268a38f4e66378851a196cb139b ] SOF treats the topology mixer min and max values as non-negative indices into its volume table. It stores them in signed fields, allocates max + 1 entries through an int argument, and later indexes the table with the stored range. An inverted range is invalid, while a maximum at or above INT_MAX cannot be represented safely after the increment or in the signed fields. Validate the complete range before storing it or allocating the table. Fixes: 311ce4fe7637 ("ASoC: SOF: Add support for loading topologies") Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou Acked-by: Peter Ujfalusi Link: https://patch.msgid.link/20260814081238.25434-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e30214289e623068c3de73f462055bc9d7a6b13b Author: Steven Rostedt Date: Thu Aug 13 20:42:26 2026 -0400 tracing: Have trace_event_update_all() only handle module that is loading [ Upstream commit ae70b04ab9c7f6162a8c0fdd18a62a945c133142 ] The function trace_event_update_all() does a scan of events looking to replace enums with their values in the strings that get exported to the event format files. It's run at boot up on all events and again when a module loads. The issue is that when a module loads, it still runs on *all* events. There's no reason to process every event when a module loads as the previous events have already been processed. Only execute on the events that are loaded with the module. Link: https://patch.msgid.link/20260813204226.29563591@gandalf.local.home Fixes: 3673b8e4ce723 ("tracing: Allow for modules to convert their enums to values") Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 324cc98b71f0d3dee7367ef3c669fd80747e71b6 Author: Karl Mehltretter Date: Sat Aug 8 21:04:17 2026 +0200 HID: haptic: don't write an uninitialized value to unhandled usages [ Upstream commit 3efb7f6491526f5012f9ec94769e9ed832feeef8 ] fill_effect_buf() initializes value only for the four haptic usages handled by its switch, but writes it to field->value[] for every usage. An unhandled usage can therefore receive either an uninitialized value or one left over from the previous usage. hid_output_report() then serializes that value into the effect's report buffer. Skip unhandled usages instead. This also matches switch_mode(), which only updates fields it recognizes. Found with Clang's -Wconditional-uninitialized. Fixes: 344ff3584957 ("HID: haptic: initialize haptic device") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit a561012868ae37c28f61fdf658bf6f251bc0e8e8 Author: Aleksandr Nogikh Date: Fri Aug 14 12:05:43 2026 +0000 ALSA: core: Fix use-after-free in snd_card_do_free() [ Upstream commit 5ae1a690c522fea2900ff56c8c2ace7b059f5e04 ] A use-after-free was detected in snd_card_do_free() when a sound card managed by devres is unbound while a user-space application still holds an open file descriptor. For managed cards, the memory is allocated using devres_alloc(), and its release function is set to __snd_card_release(), which calls snd_card_free(). When the device is unbound, the unbind thread calls snd_card_free(), which drops a reference to the card's device. If the user thread still has an open file descriptor, the reference count does not reach zero, and the unbind thread blocks on wait_for_completion(&released). When the user thread closes the file descriptor, it drops the final reference, invoking the device release callback release_card_device(), which calls snd_card_do_free(). snd_card_do_free() performs cleanup and calls complete(card->release_completion). This wakes up the unbind thread, which returns from snd_card_free() and __snd_card_release(). The devres core then immediately frees the memory block containing the snd_card structure. Meanwhile, the user thread continues execution in snd_card_do_free() and evaluates `if (!card->managed)`. It reads the `managed` boolean from the snd_card structure that was just freed by the unbind thread, triggering a KASAN use-after-free. Fix this by caching the value of card->managed in a local variable before calling complete(). This ensures that the card pointer is not dereferenced after the unbind thread has been woken up and potentially freed the card. BUG: KASAN: use-after-free in snd_card_do_free sound/core/init.c:604 [inline] BUG: KASAN: use-after-free in release_card_device+0x1ab/0x1b0 sound/core/init.c:153 Read of size 1 at addr ffff8881912ec909 by task syz-executor130/5857 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description+0x55/0x1e0 mm/kasan/report.c:378 print_report+0x58/0x70 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 snd_card_do_free sound/core/init.c:604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c:153 device_release+0xc4/0x1f0 drivers/base/core.c:-1 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x222/0x550 lib/kobject.c:737 snd_card_file_remove+0x331/0x390 sound/core/init.c:1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c:2986 __fput+0x418/0xa50 fs/file_table.c:512 fput_close_sync+0x11f/0x240 fs/file_table.c:617 __do_sys_close fs/open.c:1511 [inline] __se_sys_close fs/open.c:1496 [inline] __x64_sys_close+0x7e/0x110 fs/open.c:1496 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: e8ad415b7a55 ("ALSA: core: Add managed card creation") Assisted-by: Gemini:gemini-3.6-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+7061d72c26b7daebe2b4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7061d72c26b7daebe2b4 Link: https://syzkaller.appspot.com/ai_job?id=24752a23-f0b6-49c1-bf20-4fa89c2e7eb2 Signed-off-by: Aleksandr Nogikh Link: https://patch.msgid.link/02042186-27b7-42a9-b64e-f93ce8fbe05a@mail.kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ce9a619c432b9a4044fee115c5483fbed946c131 Author: Zhan Xusheng Date: Wed Jun 24 11:44:30 2026 +0800 fs/ntfs3: reject out-of-range evcn in mi_enum_attr() [ Upstream commit 20fd9f64c0050658f2031e6bd5d552c6f0c8f7e3 ] In mi_enum_attr(), the start/end VCN validation for non-resident attributes is: if (svcn > evcn + 1) goto out; When evcn is U64_MAX the "evcn + 1" expression wraps to 0 and any svcn passes the check. For evcn values close to U64_MAX (but not equal to it) the right-hand side is still a meaningless near-wrap upper bound, so a malformed on-disk attribute with svcn == 0 and evcn near U64_MAX can pass mi_enum_attr() unrejected. VCN (virtual cluster number) is a cluster index, so any valid evcn is bounded by the volume's total cluster count, which ntfs3 holds in sbi->used.bitmap.nbits (set up in ntfs_init_from_boot() before any caller of mi_enum_attr() runs). Reject evcn values that fall outside this range. However, an empty non-resident attribute (no allocated clusters) is legitimately encoded with svcn == 0 and evcn == -1 (U64_MAX), e.g. via attr->nres.evcn = cpu_to_le64((u64)vcn - 1) with vcn == 0. That sentinel must keep passing, so exclude evcn == U64_MAX from the range check. The existing "svcn > evcn + 1" test still tolerates the sentinel ("0 > 0" is false) and continues to require svcn == 0 for it, while the range check rejects every other out-of-range evcn and thereby also defuses the "evcn + 1" wraparound. svcn does not need its own bound: once evcn < nbits, "svcn > evcn + 1" implies svcn <= nbits. Fixes: 013ff63b6494 ("fs/ntfs3: Add more attributes checks in mi_enum_attr()") Signed-off-by: Zhan Xusheng [almaz.alexandrovich@paragon-software.com: fixed evcn check] Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit dc6d85de7e2656e56e10ff5ba514f2583a4f612b Author: Zhan Xusheng Date: Wed Jun 24 11:41:33 2026 +0800 fs/ntfs3: fix integer overflow in MFT cluster validation [ Upstream commit c510c63873103a5da6a498fe537bdb5d6f8d03a2 ] In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are validated against the volume size with: if (mlcn * sct_per_clst >= sectors || mlcn2 * sct_per_clst >= sectors) goto out; mlcn and mlcn2 are u64 fields read directly from the boot sector. sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus the is_power_of_2() check below it), but the multiplication is done in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn near 2^62 with sct_per_clst == 4 wraps to 0, which compares below any non-zero 'sectors', so the check is bypassed and the malformed record is accepted. The accepted mlcn is then used unchanged in sbi->mft.lbo = mlcn << cluster_bits; In practice the resulting reads fail at the block layer (sb_bread() returns NULL via grow_buffers()'s check_mul_overflow() guard), so today this manifests as mount failing in odd places rather than as something more dangerous, but the validation step is still wrong and there is no reason for callers to rely on the block layer to catch a value that should never have been accepted in the first place. Use check_mul_overflow() to compute the two sector positions and fail the mount if either multiplication wraps; this preserves the existing semantics (mlcn * sct_per_clst >= sectors) instead of switching to division (mlcn >= sectors / sct_per_clst), which would tighten the check at edge cases where 'sectors' is not a multiple of sct_per_clst. The check_*_overflow() style is the one ntfs3 already uses for similar on-disk arithmetic in fs/ntfs3/run.c. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Zhan Xusheng Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 863e10c4508cfbfb08e2c71c250836d42c8c5f4e Author: Puranjay Mohan Date: Thu Aug 13 12:03:48 2026 -0700 bpf, arm64: Fix stack-passed arguments for indirect trampolines [ Upstream commit 50de1c47a41d4031f6002969e71dc6954dedb6b2 ] save_args() reads stack-passed arguments relative to FP assuming the trampoline is entered through the fentry call from a traced function, in which case both the parent frame (FP/x9) and the traced function frame (FP/LR) are saved before FP is set, so the arguments start at FP + 32. An indirect trampoline for a struct_ops callback is entered through a function pointer (blr), so only the FP/LR frame is pushed and the arguments start at FP + 16, not FP + 32. Every stack-passed argument of a struct_ops callback with more than eight argument slots is read two slots off. This went unnoticed because no struct_ops member passed arguments on the stack until bpf_testmod_ops3::test_arena_stack, added by commit 2d4de9a493a0 ("selftests/bpf: Test stack-passed struct_ops arena arguments"). That member covers this on arm64 once the JIT gains arena argument support later in this series. Pass is_struct_ops into save_args() and pick the offset accordingly, mirroring the x86 fix. Fixes: 9014cf56f13d ("bpf, arm64: Support up to 12 function arguments") Signed-off-by: Puranjay Mohan Reviewed-by: Xu Kuohai Link: https://lore.kernel.org/bpf/20260813190356.335181-2-puranjay@kernel.org Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 424a9fc4876cc7f28e9cb0aa8d92e920d726e350 Author: Jijie Shao Date: Fri Aug 7 19:48:30 2026 +0800 net: page_pool: fix UAF in __page_pool_release_netmem_dma on xa_cmpxchg race [ Upstream commit 24ef02f934eeb48830cff6b739abc3c62b1d107b ] This bug was discovered while testing the hns3 driver under channel reconfiguration (`ethtool -L` / `ethtool -G`) with iperf3 traffic on arm64. The race is intermittently triggered when page_pool_destroy() runs page_pool_scrub() concurrently with page return via page_pool_put_netmem() on a different CPU. A WARN in page_pool_clear_pp_info() surfaced the dangling DMA index bits left by the cmpxchg loser, which led to the investigation. page_pool_scrub() iterates pool->dma_mapped via xa_for_each() with no page ref held. __page_pool_release_netmem_dma() currently reads and writes netmem fields (dma_addr, DMA index bits in pp_magic) after xa_cmpxchg() returns. The unref path calls put_page() unconditionally regardless of the cmpxchg outcome; when it loses the cmpxchg, it still frees the page before the scrub winner finishes these netmem accesses, so scrub touches a freed page -- a Use-After-Free. Fix this by splitting the DMA release into two functions: 1. __page_pool_unmap_netmem_dma() caches dma_addr before xa_cmpxchg(), does the cmpxchg to remove the DMA mapping, and calls dma_unmap on the cached address. It never touches netmem fields after the cmpxchg, making it safe for the scrub path which holds no page ref. 2. __page_pool_release_netmem_dma() wraps the above and additionally clears dma_addr and DMA index bits in netmem fields. This is safe only when the caller holds a page ref, so it is used by the return path (page_pool_return_netmem). The scrub path calls __page_pool_unmap_netmem_dma() directly; the return path calls __page_pool_release_netmem_dma(). Fixes: ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool") Suggested-by: Mina Almasry Reviewed-by: Mina Almasry Signed-off-by: Jijie Shao Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260807114830.344336-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e44b3b35bb153e459931798e2e7d1cea157d3b18 Author: Bart Van Assche Date: Fri Aug 7 15:49:46 2026 -0700 scsi: ufs: core: Set task state before io_schedule_timeout() [ Upstream commit 720d8b2f2457f4962ca353dd90395e2660d9a10d ] Set the task state to TASK_UNINTERRUPTIBLE before calling io_schedule_timeout() in ufshcd_wait_for_pending_cmds(). Without setting the task state, io_schedule_timeout() returns immediately because the task state remains TASK_RUNNING. This results in a busy loop that wastes CPU cycles. Fixes: 2000bc309703 ("scsi: ufs: core: Reduce the clock scaling latency") Reviewed-by: Peter Wang Reported-by: Sashiko Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/8fe4526ce272811b28e99048b42358dd8f7c48af.1786142946.git.bvanassche@acm.org Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 2dbdd025b228110ccbfbab95fe16e098313a14af Author: Chandrakanth Patil Date: Sat Aug 8 20:40:10 2026 +0530 scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers [ Upstream commit b9f679dfe629004b593f018df33b330d799bcee4 ] _base_release_memory_pools() unconditionally frees every ioc->pcie_sg_lookup[] entry, including ones the setup loop never allocated after a partial failure, causing a "bad dma" warning on debug kernels or a NULL pointer dereference otherwise. Fixes: dbec4c9040ed ("scsi: mpt3sas: lockless command submission") Reported-by: Laurence Oberman Signed-off-by: Chandrakanth Patil Link: https://patch.msgid.link/20260808151010.185603-1-chandrakanth.patil@broadcom.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit b6273cd8dc55fd41031a0b6e40e3c9fdd20b9754 Author: Eduard Zingerman Date: Tue Aug 11 23:05:42 2026 -0700 selftests/bpf: Fix for veristat file/prog filters processing [ Upstream commit 98d309ec8189fd91698d1a72946c3d888270c57e ] At the moment veristat filtering behaves unexpectedly for the following filter expression: -f !file/prog The expression rejects all programs with name 'prog', and all programs in a file with name 'file'. This commit fixes the expression to exclude only a program 'prog' from a file 'file'. Additionally, the commit makes empty filters like '-f ""' or '-f "/"' and error. Here is the filtering behaviour compared old versus new: | filter | file | prog | old verdict | new verdict | |----------+------+------+-------------+-------------| | !foo | foo | bar | skipped | skipped | | !foo | bar | foo | skipped | skipped | | !foo | bar | bar | processed | processed | | !foo/bar | foo | bar | skipped | skipped | | !foo/bar | foo | buz | skipped | processed | (!) | !foo/bar | bar | bar | skipped | processed | (!) | !foo/ | foo | bar | skipped | skipped | | !foo/ | bar | bar | processed | processed | | !/bar | foo | bar | skipped | skipped | | !/bar | foo | foo | processed | processed | | !/ | foo | bar | processed | error | (!) | ! | foo | bar | processed | error | (!) |----------+------+------+-------------+-------------| | foo | foo | bar | processed | processed | | foo | bar | foo | processed | processed | | foo | bar | bar | skipped | skipped | | foo/bar | foo | bar | processed | processed | | foo/bar | foo | buz | skipped | skipped | | foo/bar | bar | bar | skipped | skipped | | foo/ | foo | bar | processed | processed | | foo/ | bar | bar | skipped | skipped | | /bar | foo | bar | processed | processed | | /bar | foo | foo | skipped | skipped | | / | foo | bar | processed | error | (!) | | foo | bar | skipped | error | (!) Fixes: 10b1b3f3e56a ("selftests/bpf: consolidate and improve file/prog filtering in veristat") Signed-off-by: Eduard Zingerman Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260811-veristat-filter-fix-v2-1-6c234c4cd6ef@gmail.com Signed-off-by: Sasha Levin commit d0a3729d464fcf516416a41cf304c0c92126ee03 Author: Phillip Lougher Date: Fri Aug 7 17:29:51 2026 +0100 Squashfs: check block offset is not negative [ Upstream commit e300eb5002925b29be803d2661af07266cfa267e ] If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset. Link: https://lore.kernel.org/20260807162951.672510-1-phillip@squashfs.org.uk Fixes: f400e12656ab ("Squashfs: cache operations") Signed-off-by: Phillip Lougher Reported-by: Yuejie Shi Closes: https://lore.kernel.org/all/20260803032735.81785-1-syjcnss@gmail.com/ Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f8747d81aa6d3efe3ee339a9d912ff3ca6e4d758 Author: Krystian Kaniewski Date: Thu Jul 30 07:42:21 2026 +0000 ocfs2: fix circular locking dependency in ocfs2_init_acl() [ Upstream commit bd7c05fb4a4776dff5a87b19008d28458647d15d ] A lockdep warning indicates a circular locking dependency between `&oi->ip_xattr_sem` and `&journal->j_trans_barrier`: WARNING: possible circular locking dependency detected is trying to acquire lock: (&oi->ip_xattr_sem){++++}-{4:4}, at: ocfs2_init_acl+0x2fd/0x7e0 fs/ocfs2/acl.c:367 but task is already holding lock: (&journal->j_trans_barrier){.+.+}-{4:4}, at: ocfs2_start_trans+0x3ab/0x700 fs/ocfs2/journal.c:369 The deadlock involves two code paths: Path 1 (setxattr) where `ocfs2_xattr_set()` acquires `ip_xattr_sem` (write) and then starts a transaction, which acquires `j_trans_barrier` (read); and Path 2 (mkdir/mknod) where `ocfs2_mknod()` starts a transaction (`j_trans_barrier` read) and then calls `ocfs2_init_acl()`, which attempts to acquire `ip_xattr_sem` (read) on the parent directory to retrieve the default ACL. Because rw_semaphores are subject to writer priority, a pending writer on `j_trans_barrier` (e.g., the journal commit thread) can cause Path 1 to block, while Path 2 is blocked waiting for Path 1 to release `ip_xattr_sem`. The patch fixes the lock ordering by precomputing the ACL state before starting the OCFS2 transaction, while preserving POSIX ACL storage semantics and the existing inode/security initialization order. By reading the parent directory's default ACL and preparing the new inode's ACLs outside the transaction, `ip_xattr_sem` is always acquired before `j_trans_barrier`. `struct ocfs2_acl_state` encapsulates the prepared ACL state, while `ocfs2_acl_init_prepare()` and `ocfs2_acl_init_release()` avoid code duplication between `ocfs2_mknod()` and `ocfs2_init_security_and_acl()`. `ocfs2_calc_xattr_init()` and `ocfs2_init_acl()` use this precomputed state, removing internal `ip_xattr_sem` acquisition and redundant disk reads. Additionally, remove the `ip_xattr_sem` acquisition from `ocfs2_xattr_set_handle()`. This function is only used while initializing a new inode that has not yet been inserted into the inode hash or attached to a dentry, meaning there is no risk of concurrent access and the lock is unnecessary. Link: https://lore.kernel.org/4094de06-9b69-4174-b2ee-08126dffc693@mail.kernel.org Fixes: 16c8d569f570 ("ocfs2/acl: use 'ip_xattr_sem' to protect getting extended attribute") Signed-off-by: Krystian Kaniewski Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+4007ab5229e732466d9f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4007ab5229e732466d9f Link: https://syzkaller.appspot.com/ai_job?id=cc75363d-c672-499e-8fc5-44bcdc1cee39 Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e35fa6eb4d2a39f8049f62361a4b44930882b5f8 Author: ZhengYuan Huang Date: Mon Aug 3 11:00:07 2026 +0800 ocfs2: validate DIO orphan slot during inode read [ Upstream commit bb88131c9831075b8dc08cdd375743e5d44c7ca2 ] [BUG] A corrupted append-DIO dinode (high byte at offset 0xa1 corrupted from 0 to 1) can carry an i_dio_orphaned_slot outside the mounted filesystem slot range and trigger a use-after-free error: BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace: ... ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840 ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline] ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295 evict+0x38e/0x8f0 fs/inode.c:810 iput_final fs/inode.c:1914 [inline] iput fs/inode.c:1966 [inline] iput+0x55b/0x8b0 fs/inode.c:1926 ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374 ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373 ... [CAUSE] ocfs2_del_inode_from_orphan() uses i_dio_orphaned_slot to index the slot-local system inode cache. The dinode validator does not check this active slot, so an out-of-range value produces an invalid cache entry pointer that is dereferenced as an inode pointer. [FIX] Reject an active i_dio_orphaned_slot outside the slot range during dinode validation, before DIO orphan recovery can consume it. Link: https://lore.kernel.org/20260803030007.3993199-3-gality369@gmail.com Fixes: 06ee5c75b575 ("ocfs2: add functions to add and remove inode in orphan dir") Signed-off-by: ZhengYuan Huang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit c6c908f9b4edfb04534b15573168ae038f7a9cbf Author: ZhengYuan Huang Date: Mon Aug 3 11:00:06 2026 +0800 ocfs2: validate orphan slot during inode read [ Upstream commit b2d31acbd3b182755b019183fb46949ba5e39b9f ] Patch series "ocfs2: validate active orphan slots during inode read". OCFS2 trusts active ordinary and append-DIO orphan slots read from dinodes. A corrupted slot can therefore index osb_orphan_wipes or the slot-local system-inode cache outside their allocations before the corruption is reported. Patch 1 validates the ordinary orphan slot used by inode wipe processing. Patch 2 validates the append-DIO orphan slot used by DIO completion and orphan recovery. Both checks reject corrupt metadata at the existing inode validation boundary. This patch (of 2): [BUG] A corrupted dinode with OCFS2_ORPHANED_FL can carry an i_orphaned_slot outside the mounted filesystem slot range. ocfs2_wipe_inode() uses it to index osb_orphan_wipes before looking up the orphan directory, causing an out-of-bounds memory access. BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace: ... ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840 ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline] ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295 evict+0x38e/0x8f0 fs/inode.c:810 iput_final fs/inode.c:1914 [inline] iput fs/inode.c:1966 [inline] iput+0x55b/0x8b0 fs/inode.c:1926 ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374 ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373 ... [CAUSE] ocfs2_validate_inode_block() validates i_suballoc_slot but leaves the active ordinary orphan slot unchecked. Downstream consumers assume that the value is smaller than osb->max_slots. [FIX] Reject an active i_orphaned_slot outside the slot range during dinode validation, before the inode reaches orphan wipe processing. Link: https://lore.kernel.org/20260803030007.3993199-1-gality369@gmail.com Link: https://lore.kernel.org/20260803030007.3993199-2-gality369@gmail.com Fixes: b4df6ed8db0c ("[PATCH] ocfs2: fix orphan recovery deadlock") Signed-off-by: ZhengYuan Huang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 508907eb8ea4a1b9c299e1cbecb7708fbf995962 Author: Yuan Chen Date: Mon Aug 10 22:22:22 2026 +0800 bpftool: Fix double close in map dump [ Upstream commit 259d60f5bfa41056fe01cbf2ba3f6f0331865a16 ] map_dump() closes the map fd in its error path, and do_dump() then closes the same fd again after a successful dump. Closing an already closed fd leaves errno set to EBADF, which poisons later errno checks such as the batch file read check in do_batch(). Let do_dump() own the fd and remove the close from map_dump(). The same double-close pattern exists in do_show_subset(): both show_map_close_json() and show_map_close_plain() already close the fd, so drop the extra close() there as well. Also propagate the error when bpf_map_get_info_by_fd() fails on a subsequent map in do_dump(): set err = -1 before breaking out of the loop, so a later failure is not silently hidden after an earlier iteration succeeded. Fixes: 99f9863a0c45f ("bpftool: Match maps by name") Signed-off-by: Yuan Chen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260810142224.2907373-2-chenyuan_fl@163.com Signed-off-by: Sasha Levin commit b000458cab95849a67420257091dd256f3ab3eae Author: Bijan Tabatabai Date: Thu Jul 16 17:06:04 2026 -0500 x86/pkeys: Fix pkey_alloc() return value when pkeys are not supported [ Upstream commit dee87e09b0dd63da9b1e1876167ccae37842dfd0 ] The man page for pkey_alloc(2) specifies that it should return -1 with the errno set to ENOSPC when pkeys are not supported [1]. However, on x86 pkey_alloc() sets errno to EINVAL when called for the first time on a CPU that does not support pkeys. The root cause of this is the x86 implementation of mm_pkey_alloc() not directly checking if pkeys are supported. It only checks if all the pkeys have been allocated by comparing the allocation map against all_pkeys_mask. When OSPKE is not enabled, init_new_context() skips the initialization of the allocation map, leaving it as 0, while all_pkeys_mask is 1. mm_pkey_alloc() interprets this as there being a pkey available and it returns pkey 0. Then, pkey_alloc() fails with -EINVAL from arch_set_user_pkey_access() instead of returning -ENOSPC. Subsequent calls to pkey_alloc() do return -ENOSPC because pkey 0 is left marked as allocated. Change mm_pkey_alloc() to directly check if OSPKE is enabled, and return -1 if it is not, which causes pkey_alloc() to return -ENOSPC. The arm64 and powerpc implementations of mm_pkey_alloc() already do this check. [1] https://man7.org/linux/man-pages/man2/pkey_alloc.2.html [ dhansen: use arch_pkeys_enabled() to follow arm ] Fixes: e8c24d3a23a4 ("x86/pkeys: Allocation/free syscalls") Signed-off-by: Bijan Tabatabai Signed-off-by: Dave Hansen Link: https://patch.msgid.link/20260716220604.26452-1-bijan311@gmail.com Signed-off-by: Sasha Levin commit 0ef3f5629051f8435354a3fbbd32f5b5c635de13 Author: Rui Qi Date: Thu Aug 13 21:28:07 2026 +0800 selftests/cgroup: Preserve CPU hotplug write errors [ Upstream commit ddabc5dbd262f3ca981e679ddae99ed7a9adb279 ] The cpuset partition root state selftest checks several CPU hotplug transitions. If writing to a CPU online file fails, the helper still runs pause afterwards and returns the status of pause instead of the failed write. This hides the real hotplug failure and can make later checks run against expectations for a transition that never happened. Move the write before the bookkeeping and return when it fails, so callers can observe the hotplug error and the test does not record a CPU as offline unless the offline operation actually succeeded. Also change the O* command handler in set_ctrl_state() to use "eval $COMM $REDIRECT" like all other handlers. The previous version set COMM but still called write_cpu_online directly, bypassing the redirect that captures stderr for error reporting. Changes since v1: - Use eval $COMM $REDIRECT in the O* handler instead of calling write_cpu_online directly (Waiman Long) Fixes: a8c52eba880a ("kselftest/cgroup: Add cpuset v2 partition root state test") Signed-off-by: Rui Qi Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 210c193a9ef1312fab153948c6928e4cfaa1f03b Author: John Keeping Date: Thu Aug 13 16:08:08 2026 +0100 ALSA: seq: midi: Serialize input teardown with event_input [ Upstream commit 403f7f3ad3808a0096d84cf228fab68dc253fd9d ] snd_midi_input_event() must not be running while a rawmidi substream is closing, since this can lead to the trigger state becoming out-of-step through this sequence in snd_rawmidi_input_trigger(): snd_rawmidi_input_trigger(up=0) snd_midi_input_event() -> snd_rawmidi_kernel_read() -> snd_rawmidi_input_trigger(up=1) -> cancel_work_sync() which ends with the underlying device being active unexpectedly. When this is called from close_substream(), further input can re-trigger the input event leaving it running after rawmidi_release_priv() has set rfile->rmidi to NULL which leads to: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b0 Call trace: snd_midi_input_event+0x3c/0x134 [snd_seq_midi] (P) snd_rawmidi_input_event_work+0x1c/0x2c process_one_work+0x150/0x3a4 worker_thread+0x190/0x318 Apply a similar approach to commit ef7607ab1c8ad ("ALSA: seq: midi: Serialize output teardown with event_input") which fixed the same issue in the output direction, but updated to use RCU following Takashi Iwai's proposed follow-on patch [1]. With this change in place, midisynth_unsubscribe() clears the input file so snd_midi_input_event() will not re-trigger the stream and will be quiesced by the cancel_work_sync() in snd_rawmidi_input_trigger(). [1] https://lore.kernel.org/linux-sound/20260813144224.753399-1-tiwai@suse.de/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: John Keeping Link: https://patch.msgid.link/20260813150810.795393-1-jkeeping@inmusicbrands.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5c94ea1e64d3b8e19916640b965880a04dbcd796 Author: Takashi Iwai Date: Thu Aug 13 16:42:16 2026 +0200 ALSA: seq: midi: Optimize event_input locking with RCU [ Upstream commit 4cc25cdd3cffa475edb8dec8199b3227038ebcfb ] The recent fix for serializing the output teardown introduced a spinlock invocation at every MIDI output event via event_process_midi. Since this is a hot path, let's do performance optimization with RCU. The new output_substream __rcu pointer is published via rcu_assign_pointer() in midisynth_use() after output_rfile is set, and cleared in midisynth_unuse() before the resource teardown. event_process_midi() reads it under rcu_read_lock() and bumps output_use_lock inside that section, which is necessary to close the window between the pointer dereference and the refcount increment. midisynth_unuse() calls synchronize_rcu() before snd_use_lock_sync(): this guarantees that any reader who obtained a non-NULL pointer has already called atomic_inc (output_use_lock), so the subsequent snd_use_lock_sync() sees the correct in-flight count. Fixes: ef7607ab1c8a ("ALSA: seq: midi: Serialize output teardown with event_input") Link: https://patch.msgid.link/20260813144224.753399-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1f6d28c428caea583ebb7880ff2b61a367f8d5dd Author: Yuho Choi Date: Sun Aug 2 17:35:45 2026 -0400 clocksource/drivers/armada: Unwind timer clock on init failure [ Upstream commit 8b4127f6db40381229f3564d34ac35f36311c201 ] The Armada timer init paths enable their clock before calling the common initialization routine. If that routine returns an error, the clock is left enabled even though the timer was not initialized successfully. Fixes: 12549e27c63c ("clocksource/drivers/time-armada-370-xp: Convert init function to return error") Signed-off-by: Yuho Choi Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260802213545.565913-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin commit fa0901c1c5551177410b07097f8dada01fb66ac7 Author: Guangshuo Li Date: Sun Jul 5 01:54:51 2026 +0800 clocksource/drivers/clps711x: Do not unmap clocksource MMIO [ Upstream commit e998c6300ef4e062a704ee17b5a812c0b595cf42 ] clps711x_clksrc_init() stores the timer base address in the static tcd pointer and registers it as both the clocksource MMIO address and the sched_clock read address. The clocksource init path must therefore keep the mapping alive after clps711x_timer_init() returns. However, the shared unmap_io exit path is also reached after successful clocksource registration, so the MMIO mapping is torn down while the clocksource and sched_clock readers may still access it. Return directly after successful clocksource registration and leave the mapping alive for the registered readers. Keep the unmap_io path for the error paths and for the clockevent init path. Fixes: cd32e596f02f ("clocksource/drivers/clps711x: Fix resource leaks in error paths") Signed-off-by: Guangshuo Li Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260704175451.256364-1-lgs201920130244@gmail.com Signed-off-by: Sasha Levin commit 5d83f3faa3fb7f23f298cfd40382611999de5d1d Author: Peter Oberparleiter Date: Wed Aug 12 09:53:19 2026 +0200 s390/debug: Fix deadlock during unregister [ Upstream commit 445c31ac638fd1af203d79bdf25fc0cb3149fbbc ] Unregistering an s390dbf debug area while one of the associated debugfs files is being written to can cause a deadlock: $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs write debugfs_file_get() debug_unregister() mutex_lock(debug_mutex) debugfs_remove() wait for debugfs_file_put() debug_file_ops.write() debug_input() mutex_lock(debug_mutex) ==> DEADLOCK Fix this by splitting debug_unregister() into an s390dbf and debugfs part, and running only the s390dbf part with debug_mutex locked. Fixes: 9372a82892c2 ("s390/debug: fix debug area life cycle") Signed-off-by: Peter Oberparleiter Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit e0cb87f438854b72045f14bc5bfc8f746aca0dc1 Author: Yuho Choi Date: Thu Aug 6 23:23:26 2026 -0400 xenbus: Unregister reboot notifier on init failure [ Upstream commit d330fb86a7170f845123ae82d95df440fad9b707 ] xs_init() registers xs_reboot_nb before initializing XenStore communications and starting xenwatch. If either operation fails, the notifier remains registered and a later initialization attempt can hit a duplicate registration. Check the notifier registration result and unregister it on every subsequent failure path. Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses") Signed-off-by: Yuho Choi Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260807032326.940377-1-dbgh9129@gmail.com> Signed-off-by: Sasha Levin commit ac7b10121140af52dee2f3b12f4f7c54b971161e Author: Henrik Grimler Date: Tue Aug 11 13:47:47 2026 +0200 power: supply: bq27xxx: bq27z561: fix invalid AverageEnergy address [ Upstream commit 2da28b059e0ddcd2e1956eeae383246207965573 ] bq27z561 currently uses the AveragePower reg, 0x22, for reading both AveragePower and AvailableEnergy. The technical reference manual does not mention AvailableEnergy, and it does not make sense to read a cumulative, always positive, property like AvailableEnergy from a rate property like AveragePower. Set REG_AE as invalid to fix it. Fixes: 6f24ff97e323 ("power: supply: bq27xxx_battery: Add the BQ27Z561 Battery monitor") Signed-off-by: Henrik Grimler Link: https://patch.msgid.link/20260811-bq27z746-v1-5-3a4fa38205cc@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit b3827f2e7b609d3e9e16dcf2e2823ff16429662c Author: Henrik Grimler Date: Tue Aug 11 13:47:46 2026 +0200 power: supply: bq27xxx: bq28z610: fix invalid AverageEnergy address [ Upstream commit e9387e9ab5121f330d313afb90430c02200f9782 ] bq28z610 currently uses the AveragePower reg, 0x22, for reading both AveragePower and AvailableEnergy. The technical reference manual does not mention AvailableEnergy, and it does not make sense to read a cumulative, always positive, property like AvailableEnergy from a rate property like AveragePower. Set REG_AE as invalid to fix it. Fixes: 707d678a5c7c ("power: supply: bq27xxx_battery: Add the BQ28z610 Battery monitor") Signed-off-by: Henrik Grimler Link: https://patch.msgid.link/20260811-bq27z746-v1-4-3a4fa38205cc@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 2f890ba8521f7cd9ef7bd7d66113750e59d9a91b Author: Henrik Grimler Date: Tue Aug 11 13:47:45 2026 +0200 power: supply: bq27xxx: bq27520g4: fix REG_TTES address [ Upstream commit c774a623c821a173c950e1297f8e8c85a89455be ] According to the technical reference manual the StandbyTimeToEmpty (TTES) register is at 0x1a, not 0x1c. At 0x1c StateOfHealth instead resides. Fixes: 8835cae5f2ab ("power: supply: bq27xxx: adds specific support for bq27520-g4 revision.") Signed-off-by: Henrik Grimler Link: https://patch.msgid.link/20260811-bq27z746-v1-3-3a4fa38205cc@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 7d181b48da3ff8c3b7940e2c779a87997c41fca0 Author: Matti Vaittinen Date: Mon Aug 10 13:10:03 2026 +0300 power: supply: bd99954: Drop bad register fields [ Upstream commit 177299384a224377b4152242d875e752e5958c02 ] The bd99954 driver creates regmap fields for all the registers. All the fields for VBUS_UCD_FCTRL_SET (extended command 0x33) are accidentally created for VCC_UCD_FCTRL_SET (extended command 0x2b), causing all reads/writes for the fields to access wrong register. Luckily the fields for VBUS_UCD_FCTRL_SET are unused. Taking a look at the data-sheet all the fields in the VBUS_UCD_FCTRL_SET are marked as: "In normal operation, please don’t set these registers" with not much of additional documentation. As the fields are wrong and because there seems to be no users of the fields - it is better to just drop them. This will also decrease the memory footprint. Drop incorrect VBUS_UCD_FCTRL_SET fields. Datasheet: https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/battery_management/bd99954xxx-e.pdf Signed-off-by: Matti Vaittinen Fixes: 0902f8366491 ("power: supply: Support ROHM bd99954 charger") Tested-by: Kalle Niemi Link: https://patch.msgid.link/758fd430d02286a6f18603a8aecfe443f5ddeb8e.1786356145.git.mazziesaccount@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 3ab6f4eccbbf508bd5a52fa6ad10d1e52f609788 Author: Krishna Chaitanya Chundru Date: Tue Aug 11 21:19:41 2026 -0500 PCI/ASPM: Disable/restore ASPM on every function for multi-function devices [ Upstream commit 733cd811b3ac50586164a0864c4351fe23e21890 ] pcie_aspm_cap_init() disables ASPM L0s/L1 before touching L1SS config, then restores the pre-existing state afterward. Both steps only ever touched link->downstream, i.e. function 0 of the downstream component, leaving sibling functions (>0) on a multi-function device untouched. This means the "disable" step does not actually disable ASPM link-wide on a multi-function device: a sibling function can still have L1 enabled even after this step runs. PCIe r7.0, sec 7.5.3.7, recommends programming the same ASPM Control value for all functions of a multi-function device, and pcie_config_aspm_link() already loops over every function on the bus for exactly this reason. Loop over every function on linkbus->devices for both the disable and restore steps, keeping the existing sec 7.5.3.7 ordering (disable downstream functions before upstream, restore upstream before downstream functions). The masked pcie_capability_clear_and_set_word() accessor from the previous commit makes this safe: it only ever touches the ASPM Control bits, so function-specific bits elsewhere in LNKCTL (e.g. Read Completion Boundary, CLKREQ Enable) on sibling functions are left untouched. Fixes: 7447990137bf ("PCI/ASPM: Disable L1 before disabling L1 PM Substates") Closes: https://lore.kernel.org/all/20260721143945.86E7D1F000E9@smtp.kernel.org/ Signed-off-by: Krishna Chaitanya Chundru Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260727-aspm-v6-2-2ebb3ee7ef71@oss.qualcomm.com Signed-off-by: Sasha Levin commit a3040b9e90eb430860cb28c2b1398add4c3559e9 Author: Felix Gu Date: Sat Aug 8 01:41:43 2026 +0800 spi: img-spfi: don't disable runtime PM on DMA deferred probe [ Upstream commit 923e41ed59511cffe98357c7d58d0294a1c157ee ] When dma_request_chan() returns -EPROBE_DEFER, the error path jumps to disable_pm and calls pm_runtime_disable() even though pm_runtime_enable() was never called, leaving disable_depth unbalanced and the device permanently PM-disabled. Route the defer path through free_dma to skip pm_runtime_disable(). Fixes: 6bfbf4d0aa0c ("spi: img-spfi: Use dma_request_chan() instead dma_request_slave_channel()") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260808-spfi-v1-1-6bc4345be430@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 41849630000ecc22ccc0deba2ef2469f650d88ce Author: Vineet Gupta Date: Fri Aug 7 13:44:34 2026 -0700 selftests/bpf: vmtest.sh: Preserve command quoting when running in the VM [ Upstream commit 3a59f11e0f989bdd637c87151992605a6559a7cb ] vmtest.sh captures the trailing command with command="$@", which flattens the arguments into a single space-separated string, and then pastes it into the generated guest init script: cd /root/bpf echo ${command} stdbuf -oL -eL ${command} That here-doc is unquoted, so the host expands ${command} and the flattened text lands in the script verbatim. The guest bash then parses those lines as shell source, re-splitting the text on whitespace and glob-expanding it against /root/bpf. As a result any command with a glob or an argument containing spaces is corrupted before it reaches the test binary. For example: vmtest.sh -- ./test_progs -a 'verifier_*' has 'verifier_*' expanded in the guest into the matching object/skeleton files (verifier_align.bpf.o verifier_align.skel.h ...), so test_progs is handed a list of filenames instead of the intended name filter and runs no matching tests. Quote each argument with printf '%q ' so the command is reproduced verbatim inside the VM: the escaped text goes through exactly one round of quote removal when the guest parses the init script, yielding the original argv with globs and special characters intact. The common case (e.g. -t ) is unaffected. Only do this when there is a command to quote. printf '%q ' with no arguments still applies the format once and emits '', which the -s (debug shell) path would take for a real command and try to run. Note this makes the trailing command strictly an argv rather than a shell snippet: passing it pre-quoted as one word, e.g. vmtest.sh -- "./test_progs -t foo" no longer works, and neither does embedding guest-side shell syntax such as ';' or a redirection. 'sh -c ...' still works. The RV64 recipe in README.rst does depend on the old double parse: it wraps the denylist in \" so the literal quotes reach the guest, whose second parse of the init script removes them. Under %q those quotes now survive into argv, and parse_test_list() strtok_r()s on ',' turns them into junk filters: -d ",exceptions," -> ["] [exceptions] ["] That is harmless for DENYLIST.riscv64 only because its first line is a comment, so the leading field is empty. A denylist starting with a real entry would silently lose it - ["*arena*] never matches - so drop the backslashes and let the host consume the quotes instead. Fixes: c9709f52386d ("bpf: Helper script for running BPF presubmit tests") Signed-off-by: Vineet Gupta Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260807204434.1036279-5-vineet.gupta@linux.dev Signed-off-by: Sasha Levin commit 5e41939ae49297496b009b2a27f36107071f25d8 Author: David Matlack Date: Mon Jul 6 18:31:54 2026 +0000 selftests: harness: Mark test fixture objects __maybe_unused [ Upstream commit 37ffa24c9d07edcd414d34283e02af3f3866cf12 ] Mark _##fixture_name##_##test_name##_object __maybe_unused since it may not ever be read. This pointer is only read in XFAIL_ADD(), which tests are not required to use. clang made a change to -Wunused-but-set-variable (split out into its own subwarning, -Wunused-but-set-global) that causes this warning to be emitted for various selftests and can be upgraded to an error in selftest that set -Werror. VFIO selftests have been broken since commit ff556bd98348 ("vfio: selftests: Add -Wall and -Werror to the Makefile"), and the net selftests builds have been noisy due to -Wall. Fixes: 24cf65a62266 ("selftests/harness: Share _metadata between forked processes") Reported-by: Kuniyuki Iwashima Reported-by: Aaron Lewis Reviewed-by: Alex Williamson Reviewed-by: Kuniyuki Iwashima Signed-off-by: David Matlack Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20260706183154.2660394-1-dmatlack@google.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit d97cb1421c944afe2c042855efacbd157d92cbd2 Author: Thomas Weißschuh Date: Wed Apr 22 14:32:33 2026 +0200 selftests: harness: Restore order of test functions [ Upstream commit 465b05bae5ac553c13315681c1490dc565337771 ] The recent addition of explicit constructor orders for fixture tests broke the ordering of those relative to non-fixture tests and the reverse-constructor-order detection. Restore the ordering of the test functions relative to each other by using the same explicit test order for all test registrations and __constructor_order_first(). Rename the constant, as it is not specific to TEST_F() anymore. Link: https://lore.kernel.org/r/20260422-kselftests-harness-order-v2-1-93ea980ea3ac@linutronix.de Fixes: 6be268151426 ("selftests/harness: order TEST_F and XFAIL_ADD constructors") Signed-off-by: Thomas Weißschuh Reviewed-by: Kees Cook Signed-off-by: Shuah Khan Stable-dep-of: 37ffa24c9d07 ("selftests: harness: Mark test fixture objects __maybe_unused") Signed-off-by: Sasha Levin commit e17ba89f8b78f64755b4ab694327d7205b7e882b Author: Mohammad Abu-Khader Date: Mon Aug 3 19:02:17 2026 +0000 kunit: tool: fix _list_tests filtering wrong variable when list has TAP prefix [ Upstream commit dea754ded9518b51740c417d2c1e02ff540784c6 ] `_list_tests()` runs the kernel to list tests, strips printk timestamp lines via `extract_tap_lines()`, then drops the dummy TAP header from the cleaned `lines`. However the subsequent regex filter mistakenly operates on the original `output` instead of the cleaned `lines`. When the kernel output includes timestamp prefixes (common with UML or slower setups), e.g.: [ 0.100000] suite.test1 [ 0.100000] suite.test2 the anchored regex `^[^\s.]+\.[^\s.]+$` rejects them and `--list_tests` returns an empty list. Filter `lines` instead of `output`, matching the behavior of the adjacent `_list_tests_attr()` which already returns the cleaned list. Add a regression test with timestamp-prefixed input to verify the fix. Link: https://lore.kernel.org/r/20260803190059.36491-1-mohammad.abukhader@hotmail.com Fixes: 723c8258c8fe ("kunit: tool: Add command line interface to filter and report attributes") Signed-off-by: Mohammad Abu-Khader Reviewed-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit afc211a2939997b2dd8509ec3fc8f574fa3df05a Author: Arnaldo Carvalho de Melo Date: Tue Aug 11 15:28:59 2026 -0300 perf build: Remove leftover feature tests for removed cxx and clang support [ Upstream commit b60f6bc128b972e018de6bcfa7007b4021f4a31a ] 56b11a2126bf2f42 ("perf bpf: Remove support for embedding clang for compiling BPF events (-e foo.c)") removed the test-cxx.cpp and test-clang.cpp sources, but left behind their entries in the feature test FILES list, the build rules and the cxx and clang entries in FEATURE_TESTS_EXTRA. Since the sources no longer exist, those rules would always fail, making the artificial feature-cxx and feature-clang results to be perpetually disabled/absent, remove the leftover entries, making the feature test scripts list match the available sources. Fixes: 56b11a2126bf2f42 ("perf bpf: Remove support for embedding clang for compiling BPF events (-e foo.c)") Cc: Ian Rogers Assisted-by: opencode:deepseek-v4-flash-free Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 1e94e67483e01f1f8e1c59abe3e7226c2830ee98 Author: Karl Mehltretter Date: Sat Aug 8 14:38:02 2026 +0200 super: fix dying superblock warning messages [ Upstream commit 9ac8fd831252e52aa78399eaccc11a72f6c2af1a ] WARN_ON_ONCE() takes a condition, not a message. The string literals are always true, so the warnings still trigger but the messages are never printed. Use WARN_ONCE(1, ...) instead to print the messages and keep the once-only behavior. Found with a Coccinelle script. Clang's -Wstring-conversion also flags such calls but is not enabled in kernel builds. Fixes: f0cd988016f6 ("fs: massage locking helpers") Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260808123802.73687-1-kmehltretter@gmail.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit c01652db11c29c04fda2f2ea63b29413d372c3cc Author: Krishna Chaitanya Chundru Date: Mon Jul 27 19:32:36 2026 +0530 PCI/ASPM: Use pcie_capability_clear_and_set_word() for ASPM disable/restore [ Upstream commit 75a3b50ad9dc99ce9693a0086b968c6d3501db21 ] pcie_aspm_cap_init() disables ASPM L0s/L1 on both ends of the Link before touching L1SS config, then later restores the LNKCTL state that was in effect beforehand. Both steps use raw pcie_capability_write_word() calls: the disable step computes the new value by hand from a snapshot taken earlier in the function, and the restore step writes that same snapshot straight back. Switch both steps to pcie_capability_clear_and_set_word(), masked to PCI_EXP_LNKCTL_ASPMC, matching the accessor pcie_config_aspm_dev() already uses elsewhere in this file for the exact same register. This does a live read-modify-write of just the ASPM Control bits instead of relying on a stale snapshot for the rest of the word, and is consistent with how the rest of the file already touches this register. No functional change. Fixes: 7447990137bf ("PCI/ASPM: Disable L1 before disabling L1 PM Substates") Closes: https://lore.kernel.org/all/20260721143945.86E7D1F000E9@smtp.kernel.org/ Signed-off-by: Krishna Chaitanya Chundru Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260727-aspm-v6-1-2ebb3ee7ef71@oss.qualcomm.com Signed-off-by: Sasha Levin commit d6037e42aa4dd29bb9d9f67ef438128c5bfe3448 Author: Takashi Sakamoto Date: Tue Aug 11 21:09:28 2026 +0900 firewire: core: fix memory leak in error path of build_tree() [ Upstream commit 05bfb1327dc5fb61528bab31cd8f0c1e4bddec23 ] In the error path of build_tree(), node instances can remain in the local linked list when the function returns. Whenever an invalid value is detected in the self ID sequence, each allocated node instance is either an entry in the linked list or an entry in the ports array of its parent node. Therefore, the allocate node instances can be safely released by traversing the linked list from its head. Release the remaining node instances with for_each_fw_node() before returning to the caller. Fixes: 3038e353cfaf ("firewire: Add core firewire stack.") Reported-by: Abdun Nihaal Link: https://lore.kernel.org/all/20260727095955.104972-1-nihaal@cse.iitm.ac.in/ Link: https://lore.kernel.org/r/20260811120928.700577-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Signed-off-by: Sasha Levin commit 4679bf3517cec1abd7e4b5fcb8768b17550f3dd1 Author: Takashi Sakamoto Date: Tue Aug 11 21:09:27 2026 +0900 firewire: core: validate parent port count before allocating nodes in build_tree() [ Upstream commit a563a7cb645a79a3a7e31bed8cbf95980ef5feb1 ] The node tree requires each child node to have exactly one port connected to a parent node, while the root node must have no such port. This can be validated by comparing the parent port count for a PHY with the rest of the self ID sequence. Currently, this validation is done after the node has been allocated. Move it before the allocation so that an invalid self ID sequence can cause an error without having to clean up the newly allocated node. Link: https://lore.kernel.org/r/20260811120928.700577-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Stable-dep-of: 05bfb1327dc5 ("firewire: core: fix memory leak in error path of build_tree()") Signed-off-by: Sasha Levin commit 861e6dd1f59399b26bb4b8b6aea743766bbb0bec Author: Takashi Sakamoto Date: Tue Aug 11 21:09:26 2026 +0900 firewire: core: consolidate port counting in build_tree() [ Upstream commit 87c48e54f28d410af0c12b5dd339307bb43abeea ] The self ID sequence describes the state of each port for each PHY. Currently, build_tree() counts the ports in two separate places. Consolidate the port counting in one place. Link: https://lore.kernel.org/r/20260811120928.700577-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Stable-dep-of: 05bfb1327dc5 ("firewire: core: fix memory leak in error path of build_tree()") Signed-off-by: Sasha Levin commit 6d2eba5cdb81538316d198216ad15a245c83f1c1 Author: Takashi Sakamoto Date: Mon Aug 10 15:41:19 2026 +0900 firewire: core: add KUnit tests for failure of tree building [ Upstream commit f744022705b7eb479a1931ddd95aae4e9a4be221 ] Abdun Nihaal has reported a memory leak when tree building fails in the middle of self ID sequence enumeration. This is caused by an invalid self ID sequence and is not a common occurrence. This commit is intended to assist in fixing the issue by adding KUnit tests to show the cases in which the memory leak is triggered. The leak occurs internally in the build_tree() function, therefore it cannot be detected directly by the tests. Link: https://lore.kernel.org/r/20260810064119.410324-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Stable-dep-of: 05bfb1327dc5 ("firewire: core: fix memory leak in error path of build_tree()") Signed-off-by: Sasha Levin commit d7d075f17d612b90fa7c45ef36854d5d0e58d905 Author: Takashi Sakamoto Date: Mon Aug 10 15:41:18 2026 +0900 firewire: core: add KUnit tests for successful tree building [ Upstream commit 7b763ea17152cf61ede5289c3c66bf133c8aafa7 ] After a bus reset, self ID sequence is captured by 1394 OHCI hardware and passed to software through SelfID DMA context. The core parses the sequence to build an internal cache of the node tree for the current generation of the bus. This is the first step in managing resources on the bus. The tree is build by the build_tree() function. This commit adds KUnit tests for the function, covering several successful scenarios. Link: https://lore.kernel.org/r/20260810064119.410324-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Stable-dep-of: 05bfb1327dc5 ("firewire: core: fix memory leak in error path of build_tree()") Signed-off-by: Sasha Levin commit b5d3c30d03dbc4dd225ac6e561b0f3936396af9f Author: Takashi Sakamoto Date: Mon Aug 10 15:41:17 2026 +0900 firewire: core: add KUnit test skeleton for node tree [ Upstream commit 1f9b65cf57081035547b4d3ca1805df20892e9db ] Some issues have been reported in node tree management. Refactoring the topology-related code in the core is required. Adding unit tests would help ensure that the refactoring does not introduce regressions. This commit adds a KUnit test skeleton for this purpose. Link: https://lore.kernel.org/r/20260810064119.410324-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Stable-dep-of: 05bfb1327dc5 ("firewire: core: fix memory leak in error path of build_tree()") Signed-off-by: Sasha Levin commit 3216ff97d329a93829f3bd8a50e6ec8af5542b16 Author: Ran Hongyun Date: Thu Jul 23 10:02:32 2026 +0800 UBI: fix two issues in the ubi.mtd MODULE_PARM_DESC [ Upstream commit ff7937d14f5333ec7e6fb50d00a152d7974f4105 ] Fix two issues introduced before: - The parameter format string was missing the enable_fm and need_resv_pool tokens introduced in an earlier commit. - The bad-block reservation note was misplaced after Example 5 instead of after Example 3. It was misplaced due to an earlier patch. Fixes: 83ff59a06663 ("UBI: support ubi_num on mtd.ubi command line") Signed-off-by: Ran Hongyun Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 8b30628dfc2b2fad3b55a9441776a226035045fa Author: Rosen Penev Date: Tue Aug 11 11:51:40 2026 -0700 ASoC: xilinx: formatter_pcm: fix stream_data leak on open error [ Upstream commit b992511180e126150c6ad3580a6fd568c385f4c6 ] In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream. Free stream_data and clear the stream pointer on the error paths. Fixes: 6f6c3c36f091 ("ASoC: xlnx: add pcm formatter platform driver") Assisted-by: opencode:deepseek-v4-flash-free Signed-off-by: Rosen Penev Reviewed-by: Michal Simek Link: https://patch.msgid.link/20260811185140.27149-1-rosenp@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e065960366b55ab21e6c643c30dec2a41451900b Author: Yuho Choi Date: Fri Aug 7 16:45:50 2026 -0400 mtd: ubi: Release device reference on busy detach [ Upstream commit 31dd710cd84d5dd63c49f640d3a9f36c9699ca95 ] ubi_detach_mtd_dev() obtains a device reference through ubi_get_device() before checking whether the UBI device is busy. The busy return path drops ubi->ref_count but leaves the device reference held, so the device object cannot be released after a later detach. Drop the device reference before returning -EBUSY. Fixes: 7e84c961b2eb ("mtd: ubi: introduce pre-removal notification for UBI volumes") Signed-off-by: Yuho Choi Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit e3f7e58189bc222971ddc860f1716f37e51ba996 Author: Yuho Choi Date: Mon Jun 8 00:06:39 2026 -0400 ubi: Fix rollback for explicit UBI device numbers [ Upstream commit 5b0a6b554e12a97f9771a9a9f4ea1f5457373c73 ] ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored. Fixes: 83ff59a06663 ("UBI: support ubi_num on mtd.ubi command line") Signed-off-by: Yuho Choi Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit e6d77e2ea55f11a69b3663d2d28386172c2b81b0 Author: Zhihao Cheng Date: Sat Jul 4 16:30:41 2026 +0800 UBI: fastmap: Pass to_be_tortured when reusing old fastmap PEBs [ Upstream commit be04fce9945aac2a843f5d16725391eb80d948ef ] In ubi_update_fastmap(), when no fresh PEB is available to replace an old fastmap PEB, the old PEB is reused by erasing it synchronously via ubi_sync_erase() with the torture flag hardcoded to zero. However, old_fm->to_be_tortured[] may be non-zero: it is set during fastmap scanning when ubi_io_read_data()/ubi_io_read_ec_hdr() reports UBI_IO_BITFLIPS, meaning the PEB showed signs of bit decay and should be tortured to verify it is still reliable. When the old PEB is instead returned to the WL sub-system via ubi_wl_put_fm_peb(), the to_be_tortured flag is honored. The synchronous reuse path is inconsistent: it silently skips the torture test for PEBs that exhibited bit-flips. Fix it by passing &old_fm->to_be_tortured[i] to ubi_sync_erase(). Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 34b180031021f0574cd708767b00a2c7315417c9 Author: Zhihao Cheng Date: Sat Jul 4 16:30:40 2026 +0800 UBI: Preserve torture flag when rescheduling failed erasures [ Upstream commit 420477a84f1e52babfe60a43dbdd0988ed956845 ] In __erase_worker(), when ubi_sync_erase() returns -EINTR, -ENOMEM, -EAGAIN, or -EBUSY, the physical eraseblock is rescheduled for erasure via schedule_erase() with the torture flag hardcoded to 0. This unconditionally drops the torture request. If the error occurred before torture_peb() completed (e.g., -ENOMEM from the ec_hdr allocation in ubi_sync_erase(), errors from self_check_not_bad()/nor_erase_prepare() in ubi_io_sync_erase(), or torture_peb() failing mid-test because its internal do_sync_erase()/ ubi_io_read()/ubi_io_write() returned one of the above error codes), the torture test was never finished. Such a PEB may reach the free pool without being tortured, defeating the purpose of the torture test for detecting marginally-bad eraseblocks. If the error occurred after torture_peb() succeeded (the final do_sync_erase() in ubi_io_sync_erase() or ubi_io_write_ec_hdr() in ubi_sync_erase() failed), the torture has already been done and need not be repeated. Pass the torture flag by pointer to ubi_sync_erase() and ubi_io_sync_erase(), and clear it to zero once torture_peb() has completed successfully. __erase_worker() then forwards the updated wl_wrk->torture to schedule_erase(): torture already done is dropped, torture not completed is preserved across the reschedule. Fixes: 784c145444e7 ("UBI: fix error handling in erase worker") Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit e06806a8f4cf2758b1cb0a6ca011a2532f8c2652 Author: LiangCheng Wang Date: Wed Aug 5 15:55:43 2026 +0800 ASoC: fsl-asoc-card: defer probe when the CPU DAI device is not ready [ Upstream commit 0286324da660875dc504fd65b3be87e9c8b9a547 ] fsl_asoc_card_probe() hard-fails with -EINVAL when the CPU DAI (SAI) platform device is not found. Like the codec, the CPU DAI may just be probed later than the machine driver; the order is not guaranteed and varies across kernel versions, so a permanent -EINVAL leaves the card unregistered with no analog playback or capture. Defer probe instead, mirroring commit e396dec46c56 ("ASoC: fsl-asoc-card: Defer probe when fail to find codec device"). Tested on i.MX8MP with an ALC5672 on SAI3: the card that failed to register on v6.18 now comes up during boot. Fixes: 708b4351f08c ("ASoC: fsl: Add Freescale Generic ASoC Sound Card with ASRC support") Signed-off-by: LiangCheng Wang Link: https://patch.msgid.link/20260805-fsl-asoc-defer-cpu-dai-v1-1-43f7f538e384@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit efc40977e7104044d45eb7e911629ebe26029243 Author: bui duc phuc Date: Tue Aug 11 17:09:49 2026 +0700 ASoC: pxa: Use devm_clk_get_optional() for extclk clock [ Upstream commit 6ec64d757af9b75a3c64f9f7dad76bdc1efc06ca ] The Device Tree binding defines the extclk clock as an optional property, but the driver currently uses devm_clk_get() and manually handles the absence of the clock. Use devm_clk_get_optional() to match the binding and simplify the optional clock handling. This also propagates errors other than the absence of the optional clock, including -EPROBE_DEFER. This changes the existing behavior for errors other than -EPROBE_DEFER. RFC to discuss whether these errors should cause probe to fail rather than being treated as an unavailable optional clock. Fixes: 90eb6b59d311 ("ASoC: pxa-ssp: add support for an external clock in devicetree") Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260811100949.61142-1-phucduc.bui@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 99c554f193478c1b8175aae021dda978c1e7bec1 Author: Willem de Bruijn Date: Mon Aug 3 17:06:23 2026 -0400 idpf: add missing cpu_to_le32 in idpf_tx_splitq_build_flow_desc [ Upstream commit b802a8c1ca16f9490fa0cb3110c00c10d52b392d ] idpf_tx_splitq_build_flow_desc performs a 32-bit store to &cmd_dtype to set the 8-bit cmd_dtype and zero the adjacent 3-byte timestamp field in a single operation. Descriptors are in little endian. Add missing cpu_to_le32 and cast to __le32 to ensure the fields are written correctly also on big endian platforms. Fixes: 1a49cf814fe1 ("idpf: add Tx timestamp flows") Signed-off-by: Willem de Bruijn Reviewed-by: Jason Xing Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit f06d77436aab6c43f25577ca4925c56f45f85f9b Author: Robert Malz Date: Tue Aug 4 10:35:36 2026 +0200 ice: acquire NVM lock around each flash read [ Upstream commit df88d6f1ed653993bd5c8647aef0e6498f4b1647 ] FW caps the NVM read lock at a maximum of 3000ms regardless of the timeout requested via ice_acquire_nvm(). ice_read_flat_nvm() splits a read into multiple ice_aq_read_nvm() commands, one per 4KB sector, all issued under a single lock taken by the caller. Reading a large region can exceed 3000ms, so FW reclaims the lock mid-read and the remaining commands might fail. Move the lock acquire/release into ice_read_flat_nvm() so it brackets each individual ice_aq_read_nvm() command, ensuring the lock is never held across more than one FW read. ice_release_nvm() issues its own AQ command and overwrites hw->adminq.sq_last_status, which some callers inspect after a failed read. Add an optional read_aq_err output parameter to ice_read_flat_nvm() to capture the failing read's AQ error before the release; callers that need it (ice_discover_flash_size() and the ethtool/devlink log paths) use it instead of sq_last_status, others pass NULL. Callers that previously took the lock around ice_read_flat_nvm(), ice_read_sr_word() or ice_read_flash_module() now call them without it. The now-redundant per-block locking in ice_devlink_nvm_snapshot() is dropped. ice_read_sr_word() is now a thin wrapper, so ice_read_sr_word_aq() is folded into it. Fixes: e94509906d6b ("ice: create function to read a section of the NVM and Shadow RAM") Signed-off-by: Robert Malz Reviewed-by: Przemek Kitszel Reviewed-by: Marcin Szycik Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 42ff18e407e9c195e09e1c827cb1b4dcb31dc739 Author: Jesse Brandeburg Date: Thu Oct 16 23:08:41 2025 -0700 ice: refactor to use helpers [ Upstream commit a308ea9721122d632d1ce2af4cec1c008aff512a ] Use the ice_netdev_to_pf() helper in more places and remove a bunch of boilerplate code. Not every instance could be replaced due to use of the netdev_priv() output or the vsi variable within a bunch of functions. Signed-off-by: Jesse Brandeburg Reviewed-by: Simon Horman Reviewed-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20251016-jk-iwl-next-2025-10-15-v2-12-ff3a390d9fc6@intel.com Signed-off-by: Jakub Kicinski Stable-dep-of: df88d6f1ed65 ("ice: acquire NVM lock around each flash read") Signed-off-by: Sasha Levin commit c0fcef8e24a8b179c684c20765a67ffa2658c83a Author: Petr Oros Date: Mon Jun 22 10:10:30 2026 +0200 ice: clear the default forwarding VSI rule when releasing a VSI [ Upstream commit d04287e27bf1c0b879a10d929c163f2da69715b6 ] When a VSI is configured as the switch's default forwarding VSI (ICE_SW_LKUP_DFLT) and is then torn down, the rule is left behind in the switch. ice_vsi_release() no longer removes it, and the SR-IOV VF free path (ice_free_vfs() -> ice_free_vf_res() -> ice_vf_vsi_release() -> ice_vsi_release()) does not disable promiscuous mode either, which only happens on VF reset in ice_vf_clear_all_promisc_modes(). A trusted VF that enters unicast promiscuous mode becomes the default forwarding VSI (this is the default mode, when the PF does not have VF true-promiscuous mode enabled). If the VFs are then destroyed without the VF first leaving promiscuous mode, the ICE_SW_LKUP_DFLT rule for the now-freed VSI is leaked. When VFs are recreated, a VSI reuses the freed hw_vsi_id. If it is assigned a different VSI handle than the leaked rule holds, ice_set_dflt_vsi() does not recognize it as already-default, and ice_add_update_vsi_list() folds the dangling (freed) handle into a VSI list, which the firmware rejects. The VSI handle assigned on re-creation varies, so the failure is intermittent rather than every cycle. Reproduce by repeatedly running the cycle below on the two ports of the same card, where $VF0 and $VF1 are the netdevs of vf 15 once they appear. The VF must be brought up so iavf actually pushes the unicast promiscuous request, and the rule must settle before the VFs are torn down again: echo 16 > /sys/class/net/$PF0/device/sriov_numvfs echo 16 > /sys/class/net/$PF1/device/sriov_numvfs ip link set $PF0 vf 15 trust on ip link set $PF1 vf 15 trust on ip link set $VF0 up ip link set $VF1 up ip link set $VF0 promisc on ip link set $VF1 promisc on sleep 1 echo 0 > /sys/class/net/$PF0/device/sriov_numvfs echo 0 > /sys/class/net/$PF1/device/sriov_numvfs Within a few cycles the ice PF and iavf VF log: Failed to set VSI 25 as the default forwarding VSI, error -22 Turning on/off promiscuous mode for VF 63 failed, error: -22 PF returned error -53 (IAVF_ERR_ADMIN_QUEUE_ERROR) to our request 14 This cleanup used to live in ice_vsi_release() but was dropped by the referenced refactor. Restore it. Clear the default forwarding VSI rule in ice_vsi_release() when this VSI owns it, which covers every teardown path. Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions") Signed-off-by: Petr Oros Reviewed-by: Marcin Szycik Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit f5071e3ad4ca310544306c48cd2ccce5a371e6d4 Author: Przemyslaw Korba Date: Fri Jun 5 14:06:26 2026 +0200 ice: fall back to SBQ when LL PHY timer interface times out [ Upstream commit 6959fbdc940f62d8eef2a171d3a3342d7c248855 ] The low-latency (LL) PHY timer interface relies on a tight, atomic poll of the PF_SB_ATQBAL register with a 2ms timeout. After an NVM update / EMPR, FW may need significantly longer than 2ms to start responding to ATQBAL commands. The first PHY adjust or incval write issued by ice_ptp_rebuild_owner() fails with -ETIMEDOUT. Fix this by falling back to the existing SBQ-based PHY register write path when LL times out. This makes sure PTP is initialized when FW takes longer than expected to come back online. Steps to reproduce: ./nvmupdate64e -if devlink -f Update E810 card with nvmupdate64e, and observe dmesg errors: Failed to write PHC increment value, status -110 PTP reset failed, error: -110 (-ETIMEDOUT) Fixes: ef9a64c07294 ("ice: implement low latency PHY timer updates") Signed-off-by: Przemyslaw Korba Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 544e40805dbb6cfe64916bd4c8b238fec585ac2a Author: Zhu Yanjun Date: Tue Aug 11 00:01:23 2026 +0200 RDMA/cma: Fix WARNING in res_to_rt [ Upstream commit c6d1ec4fbe56492bb88987d577f04a5fb6955f26 ] syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via addr_handler() during asynchronous address resolution: " WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ib_addr process_one_req RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c:624 process_one_work kernel/workqueue.c:3375 [inline] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c:3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 " In addr_handler(), cma_acquire_dev_by_src_ip() is called to populate id_priv->cma_dev and bind the associated ib_device to id_priv->id.device. If cma_acquire_dev_by_src_ip() returns an error (non-zero status), the ID remains unassociated with any RDMA device. Previously, rdma_restrack_add(&id_priv->res) was invoked unconditionally even when cma_acquire_dev_by_src_ip() failed, passing a resource with a NULL dev pointer and triggering the WARN_ON assertion in res_to_rt(). Fix this by only adding the resource to restrack when acquiring the device succeeds. Reported-by: syzbot+72eddfbadda3e3928e72@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=72eddfbadda3e3928e72 Tested-by: syzbot+72eddfbadda3e3928e72@syzkaller.appspotmail.com Fixes: cb5cd0ea4eb3 ("RDMA/core: Add CM to restrack after successful attachment to a device") Link: https://patch.msgid.link/r/20260810220123.191696-1-yanjun.zhu@linux.dev Signed-off-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 046425412529dbfca1433c8bef5641b271b4ab2a Author: Fan Wu Date: Thu Aug 6 13:01:28 2026 +0000 RDMA/cxgb4: Free debugfs on registration failure [ Upstream commit fe5c16bb6252dea6025b748257ddc3b2665495b0 ] c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev. Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree. Fixes: 49ea0c036ede ("RDMA/iw_cxgb4: cleanup device debugfs entries on ULD remove") Link: https://patch.msgid.link/r/20260806130128.465460-2-fanwu01@zju.edu.cn Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3c9c9b56fbaff1d8bc9c951654dfaaf780339787 Author: Guangshuo Li Date: Sat Aug 8 19:06:42 2026 +0800 dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal [ Upstream commit a50184171235045d96104811414b25cf5338cf86 ] bam_dma_probe() calls pm_runtime_use_autosuspend(), but bam_dma_remove() does not call the matching pm_runtime_dont_use_autosuspend() when removing the device. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before forcing the device into runtime suspend during removal. This issue was found by manual code inspection. Fixes: 7d2545599f5b ("dmaengine: qcom-bam-dma: Add pm_runtime support") Signed-off-by: Guangshuo Li Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260808110642.2770355-1-lgs201920130244@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b1e8d40663997aacaa198f37ce6893e07aaba77a Author: HyeongJun An Date: Tue Aug 11 22:18:35 2026 +0900 ALSA: seq: Don't leak the extension cell pointer in the bounce payload [ Upstream commit 59e1592d3c270ff4642d5d6dc55c545306eb0693 ] The bounce_error_event() embeds the failed event in the bounce payload by pointing data.ext.ptr at it. When that event is a queued variable-length event, its own data.ext.ptr holds the address of its first extension cell, put there by snd_seq_event_dup(). The payload goes out verbatim through snd_seq_expand_var_event(), so the address reaches userspace. That is the same address commit 705dd6dcbc0e ("ALSA: seq: Clear variable event pointer on read") removed from the event header. The read path still clears it there, just above the call that expands the payload. Embed a sanitised copy instead, treated exactly as snd_seq_read() treats the header. A stack copy is enough because delivery is synchronous and snd_seq_event_dup() copies before returning. An unprivileged client reaches this by setting SNDRV_SEQ_FILTER_BOUNCE, queueing a variable-length event to a port that does not exist and reading the bounce back. Eight bytes on 64-bit, from its own pool. Fixes: efc86691e4d8 ("ALSA: seq: Fix kernel heap address leak in bounce_error_event()") Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260811131835.3837024-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4f0483bbcdaccc9d4aee30df7351863334cecfa7 Author: Yun Zhou Date: Wed May 27 13:26:25 2026 +0800 nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing [ Upstream commit d56575a2595ee1f597f39e8a1cfb67ed3501678d ] nci_core_init_rsp_packet_v1() and nci_core_init_rsp_packet_v2() parse the CORE_INIT_RSP packet without validating that the skb contains enough data. A malformed response (e.g. injected via virtual_ncidev) can declare a large num_supported_rf_interfaces while providing insufficient data, causing reads of uninitialized slab memory. This is later used in nci_init_complete_req(), triggering a KMSAN uninit-value warning. Add skb length checks before accessing packet fields: - Validate the skb has at least 1 byte for the status field. - Validate the skb can hold the fixed-size header before parsing. - In v2, bounds-check each variable-length rf_interface entry and its extension parameters within the parsing loop. - In v1, verify the skb is large enough for both the variable-length rf_interfaces array and the trailing rsp_2 structure. Reported-by: syzbot+46ca2592193f2fb3debc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=46ca2592193f2fb3debc Fixes: bcd684aace34 ("net/nfc/nci: Support NCI 2.x initial sequence") Signed-off-by: Yun Zhou Link: https://patch.msgid.link/20260527052625.3309581-1-yun.zhou@windriver.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 9cfe74542b544109fa0acbf5f8fcc52baf836321 Author: Linmao Li Date: Fri Jul 10 14:12:54 2026 +0800 nfc: digital: Do not dump a NULL response in command completion [ Upstream commit 1c7dd70c0adfa58fd66b5cbd03efb747ad6d8d8d ] digital_wq_cmd_complete() dumps the response data whenever cmd->resp is not an error pointer. However, a driver can legitimately complete a command with no response skb at all. digital_tg_send_psl_res() is the only caller that passes timeout=0, meaning no response is expected once the command has been transmitted. On that path trf7970a completes the command with trf->rx_skb = ERR_PTR(0); which evaluates to NULL. IS_ERR(NULL) is false, so the NULL response passes the !IS_ERR() check and cmd->resp->data and cmd->resp->len are dereferenced whenever the debug print site is enabled. The driver guards its own dump with "trf->rx_skb && !IS_ERR(trf->rx_skb)"; the digital layer is missing the NULL half of that test. Use IS_ERR_OR_NULL() so that NULL responses are skipped as well. The callback on that path, digital_tg_send_psl_res_complete(), never dereferences resp and dev_kfree_skb() accepts NULL, so only the debug dump needs fixing. Fixes: 59ee2361c924 ("NFC Digital: Implement driver commands mechanism") Signed-off-by: Linmao Li Reviewed-by: Przemek Kitszel Link: https://patch.msgid.link/20260710061254.80975-1-lilinmao@kylinos.cn Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 7a8e0a7aef80721da287ac246349aba7d98f6aed Author: Yinhao Hu Date: Fri Jun 26 00:34:34 2026 -0700 nfc: pn533: hold a reference to the request skb during send_frame [ Upstream commit 47792358a624ea066455ef86b744159928cd7716 ] __pn533_send_async() publishes the command and then calls dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame can be matched to this command: the I2C threaded IRQ runs pn533_recv_frame(), which queues cmd_complete_work, and pn533_send_async_complete() frees cmd->req with consume_skb(). On the I2C transport, pn533_i2c_send_frame() still dereferences the same skb after i2c_master_send() returns, so a completion that races the send can free the skb while the transport is still using it. The request skb is owned by the command object and may be freed by command completion at any time after dev->cmd is published, so the transport send path must not assume it stays alive. Hold a temporary reference to the request skb across the send_frame() call so the transport always sees a live skb even if completion races the send. Add a pn533_send_cmd_frame() helper and use it from all three send paths. Fixes: 9815c7cf22da ("NFC: pn533: Separate physical layer from the core implementation") Signed-off-by: Yinhao Hu Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260626073434.3977525-1-dddddd@hust.edu.cn Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 749a9048bf51a668ec3ab6c0392ba32325607281 Author: Doruk Tan Ozturk Date: Tue Jun 9 22:25:43 2026 +0200 nfc: llcp: bound SNL TLV parsing to the skb and add length checks [ Upstream commit f4c7f37f0ab990952539dc68d931d65c3657600a ] nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed: - For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made "service_name_len = length - 1" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2). Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 19cfe5843e86 ("NFC: Initial SNL support") Signed-off-by: Doruk Tan Ozturk Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260609202543.42282-1-doruk@0sec.ai Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit ba4c776af3dc21ed04e315e6545e99703bb1b53a Author: Zhenghang Xiao Date: Tue May 26 18:31:21 2026 +0800 nfc: nci: fix double completion race in nci_data_exchange_complete [ Upstream commit 8265a626cc14a48e46e6dc8c47667e72b4232ac2 ] nci_close_device() and nci_rx_work can both call nci_data_exchange_complete() concurrently. After commit 4527025d440ce8 ("nfc: nci: fix circular locking dependency in nci_close_device") moved flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock), rx_work is no longer serialized with the explicit completion call in the close path. Both callers read the non-NULL callback pointer and invoke rawsock_data_exchange_complete(), which calls sock_put() -- but only one sock_hold() was taken, so the second sock_put() underflows the refcount and frees the socket while it is still in use. Replace the bare clear_bit(NCI_DATA_EXCHANGE) with test_and_clear_bit() so that only the first caller proceeds to invoke the callback. Fixes: 4527025d440c ("nfc: nci: fix circular locking dependency in nci_close_device") Signed-off-by: Zhenghang Xiao Link: https://patch.msgid.link/20260526103121.47957-1-kipreyyy@gmail.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 156e65bd29307f5053835bff60bc1ba342fa010f Author: Breno Leitao Date: Thu May 21 07:32:10 2026 -0700 nfc: llcp: read llcp_sock->local under the socket lock in getsockopt [ Upstream commit 36812527052c5bfb1ec6c1e292d67a5bf76b750f ] nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and then dereferenced the cached pointer inside the locked region. llcp_sock_bind() assigns and clears llcp_sock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on lock_sock(), and then dereference a freed nfc_llcp_local once bind() has unwound. Move the llcp_sock->local read and the NULL check inside the lock_sock(sk) region so bind() cannot mutate or free the pointer between the load and the use. Fixes: 26fd76cab2e6 ("NFC: llcp: Implement socket options") Signed-off-by: Breno Leitao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260521-fix_llc-v2-2-ab44cc09179c@debian.org Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 8bf228fa02b1ed8ce622fb81fa8edc42be9aeb67 Author: Breno Leitao Date: Thu May 21 07:32:09 2026 -0700 nfc: llcp: avoid userspace overflow on invalid optlen [ Upstream commit 99985bfa8336fadcc69190ba2dcbd5386af3d661 ] nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare. Fixes: 26fd76cab2e6 ("NFC: llcp: Implement socket options") Signed-off-by: Breno Leitao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260521-fix_llc-v2-1-ab44cc09179c@debian.org Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 4b59f93cf4baa64dccc7b801837d30b915877883 Author: Chao Shi Date: Wed Jul 15 11:57:52 2026 -0400 nvme: reject passthrough of driver-managed Set Features [ Upstream commit 1161be71d1ecf7dc785382114c71afed0349531e ] Since commit b58da2d270db ("nvme: update keep alive interval when kato is modified"), a Set Features (KATO) passthrough command lets userspace start keep-alive on any transport. nvme_keep_alive_work() allocates with BLK_MQ_REQ_RESERVED, but nvme_alloc_admin_tag_set() reserves admin tags only for fabrics, so on other transports the allocation trips WARN_ON_ONCE() in blk_mq_get_tag() and fails: nvme nvme0: keep-alive failed: -11 Several Set Features change controller state the driver manages itself and cannot react to when set behind its back. Reject these in nvme_admin_cmd_allowed(): - KATO on non-fabrics (keep-alive is only armed for fabrics; on PCIe it has no reserved tag and harms idle power states) - Host Behavior Support, Host Memory Buffer, Number of Queues, and Autonomous Power State Transition (all driver-managed) Keep Alive on fabrics is unchanged; I/O commands are unaffected as the check is confined to the admin path (ns == NULL). Link: https://lore.kernel.org/linux-nvme/20260523225629.3964037-1-coshi036@gmail.com/ Fixes: b58da2d270db ("nvme: update keep alive interval when kato is modified") Found by FuzzNvme. Acked-by: Sungwoo Kim Acked-by: Dave Tian Acked-by: Weidong Zhu Signed-off-by: Chao Shi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 736b7c6adc7a65c4411beff197b6a634f7a6ca27 Author: Yang Xiuwei Date: Mon Jul 20 14:03:05 2026 +0800 nvme/ioctl: check SUBMIT_IO with nvme_cmd_allowed() [ Upstream commit b53d495c7f0db46b6748b5ade48371a10dd5d3bc ] Unlike IO_CMD / IO64_CMD, NVME_IOCTL_SUBMIT_IO never calls nvme_cmd_allowed(). Unprivileged callers can thus issue I/O on a partition device or write through a read-only file descriptor. Pass flags and open_for_write through and reject disallowed commands with -EACCES. Reviewed-by: Christoph Hellwig Signed-off-by: Yang Xiuwei Signed-off-by: Keith Busch Stable-dep-of: 1161be71d1ec ("nvme: reject passthrough of driver-managed Set Features") Signed-off-by: Sasha Levin commit 1fb1236312ee1a600de6b3ca560f0b3fd5a50471 Author: Guixin Liu Date: Tue Aug 4 11:36:05 2026 +0800 nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() [ Upstream commit f594863967d87b7fcbff6e724d51135fd701a13d ] When a host issues an Identify command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device. Fixes: aaf2e048af27 ("nvmet: add ZBD over ZNS backend support") Reviewed-by: Damien Le Moal Reviewed-by: Christoph Hellwig Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit a2cf452ba71092d9df0c253e7cfec8df89b5828a Author: Sven Peter Date: Thu Aug 6 17:27:38 2026 +0200 nvme-apple: Drop the PRP null check chicken bit [ Upstream commit 8ce883fd068b7ba9ab493cd3ecca3a7ea868c375 ] Now that we program the DMA direction correctly the NULL check that used to make commands fail passes. Another side effect of this bit was that non-align buffers on the admin queue were silently allowed and that's been fixed now as well and we this don't need this chicken bit anymore. More importantly, starting with the firmware installed with macOS 15, which is required for M4 but can also be installed on the previous SoCs, the controller no longer exposes this control register and any access SErrors instead. Just drop the write entirely. Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Tested-by: Joshua Peisach Tested-by: Janne Grunau Tested-by: Nick Chan Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit 311e4e21ffd413b5cdd68274e9f8e5a1e116fdb2 Author: Sven Peter Date: Thu Aug 6 17:27:37 2026 +0200 nvme-apple: Require page aligned buffers on the admin queue [ Upstream commit ea2160c7b78187ea9ab08c3190eef237c4ee99a7 ] Now that we have a quick to align buffers on the admin queue to the NVMe controller page size use it for Apple controllers. This fixes pre-M1 controllers, which always rejected unaligned requests, and also makes this driver work for M4 SoCs and for M1/M2/M3 SoCs that have been updated to the firmware shipped with macOS 15. Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Tested-by: Joshua Peisach Tested-by: Janne Grunau Tested-by: Nick Chan Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit 5ee7e381b1bc8110ff84d907e8f094f4396b3a74 Author: Sven Peter Date: Thu Aug 6 17:27:36 2026 +0200 nvme: Add a quirk for page aligned admin queue buffers [ Upstream commit 69d22a6b2f6984200d92dac689f8b00cc3d7d736 ] Apple controllers seem to require any queue buffers on the admin queue to be aligned to the NVMe controller page size. Weirdly, this constraint does not apply to the i/o queue where any alignment is fine. This has always been required on pre-M1 controllers and is required starting with macOS 15 firmware or post-M4 controllers again. On M1/M2/M3 we only got away with this because there was a chicken bit to disable this requirement. Let's add a quirk that enforces this alignment. Tested-by: Joshua Peisach Tested-by: Janne Grunau Tested-by: Nick Chan Signed-off-by: Sven Peter Stable-dep-of: ea2160c7b781 ("nvme-apple: Require page aligned buffers on the admin queue") Signed-off-by: Sasha Levin commit 25c76e0c07f2ae06fa2b11b5e4423e6c10d18297 Author: Maurizio Lombardi Date: Mon Nov 3 15:44:06 2025 +0100 nvme: expose active quirks in sysfs [ Upstream commit ddfb8b322bbd8ae996f4ac0192f0190feb0a01ce ] Currently, there is no straightforward way for a user to inspect which quirks are active for a given device from userspace. Add a new "quirks" sysfs attribute to the nvme controller device. Reading this file will display a human-readable list of all active quirks, with each quirk name on a new line. If no quirks are active, it will display "none". Tested-by: John Meneghini Reviewed-by: John Meneghini Reviewed-by: Sagi Grimberg Reviewed-by: Martin K. Petersen Reviewed-by: Chaitanya Kulkarni Signed-off-by: Maurizio Lombardi Signed-off-by: Keith Busch Stable-dep-of: ea2160c7b781 ("nvme-apple: Require page aligned buffers on the admin queue") Signed-off-by: Sasha Levin commit 95e93ee7053b817140c2103e9a9722ae8c56fa2e Author: Keith Busch Date: Tue Oct 14 08:04:56 2025 -0700 nvme: remove virtual boundary for sgl capable devices [ Upstream commit bc840b21a25a50f00e2b240329c09281506df387 ] The nvme virtual boundary is only required for the PRP format. Devices that can use SGL for DMA don't need it for IO queues. Drop reporting it for such devices; rdma fabrics controllers will continue to use the limit as they currently don't report any boundary requirements, but tcp and fc never needed it in the first place so they get to report no virtual boundary. Applications may continue to align to the same virtual boundaries for optimization purposes if they want, and the driver will continue to decide whether to use the PRP format the same as before if the IO allows it. Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Reviewed-by: Martin K. Petersen Signed-off-by: Jens Axboe Stable-dep-of: ea2160c7b781 ("nvme-apple: Require page aligned buffers on the admin queue") Signed-off-by: Sasha Levin commit 85571e5a37ff2e0577c2663810c4b005f88a7d9c Author: Keith Busch Date: Tue Oct 14 08:04:55 2025 -0700 block: accumulate memory segment gaps per bio [ Upstream commit 2f6b2565d43cdb5087cac23d530cca84aa3d897e ] The blk-mq dma iterator has an optimization for requests that align to the device's iommu merge boundary. This boundary may be larger than the device's virtual boundary, but the code had been depending on that queue limit to know ahead of time if the request is guaranteed to align to that optimization. Rather than rely on that queue limit, which many devices may not report, save the lowest set bit of any boundary gap between each segment in the bio while checking the segments. The request stores the value for merging and quickly checking per io if the request can use iova optimizations. Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Reviewed-by: Martin K. Petersen Signed-off-by: Jens Axboe Stable-dep-of: ea2160c7b781 ("nvme-apple: Require page aligned buffers on the admin queue") Signed-off-by: Sasha Levin commit 897184def60c9aebf4d2f7b9ba28f78971c74224 Author: Sven Peter Date: Thu Aug 6 17:27:35 2026 +0200 nvme-apple: Never set the opcode in the NVMMU TCB [ Upstream commit cc0fec9b42cfbc69d70cb4c4b616408a7037b445 ] macOS always sets this to zero and the firmware starting with macOS 15 has started to complain about what we're doing here. Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Tested-by: Joshua Peisach Tested-by: Janne Grunau Tested-by: Nick Chan Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit 751e8e18be0a4656ca59b29a2cd5c5856186a797 Author: Sven Peter Date: Thu Aug 6 17:27:34 2026 +0200 nvme-apple: Don't set a DMA direction for commands without a data transfer [ Upstream commit 94dd5804938d6681dbf26f023b1356d511f4fc48 ] Setting the DMA direction for commands that don't do any transfer likely triggered the PRP NULL check for which we needed a chicken bit. That bit has disappeared starting with macOS 15 so let's just do this correctly instead. Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Tested-by: Joshua Peisach Tested-by: Janne Grunau Tested-by: Nick Chan Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit 215d1682f0bae495f3f9cf692b358116b7a18602 Author: Sven Peter Date: Thu Aug 6 17:27:33 2026 +0200 nvme-apple: Destroy the admin queue on removal [ Upstream commit 87d5b9864c8118d26f54de4b66d2bddf2c659272 ] The admin queue is allocated with blk_mq_alloc_queue() but never destroyed. nvme_free_ctrl() only drops the last reference and blk_mq_exit_queue() and blk_sync_queue() never run: the hctx is never moved to q->unused_hctx_list and the timeout timer and work stay armed on a queue that is about to be freed which will eventually oops inside blk_mq_timeout_work(). This can only be triggered when the controller fails to come up and is then immediately torn down again which is why no one ever ran into this before. Let's just copy what the pcie driver does: unquiesce and destroy the admin queue before nvme_uninit_ctrl(). With this the following WARN followed by a panic no longer happens: WARNING: block/blk-mq.c:4390 at blk_mq_release+0x194/0x238, CPU#4: kworker/u34:4/119 CPU: 4 UID: 0 PID: 119 Comm: kworker/u34:4 Not tainted 7.2.0-rc1-dirty #248 PREEMPT Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: nvme-wq apple_nvme_remove_dead_ctrl_work pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : blk_mq_release+0x194/0x238 lr : blk_mq_release+0x58/0x238 sp : ffffc000833a3b50 x29: ffffc000833a3b50 x28: ffff80001d0450f8 x27: ffff800020c95200 x26: 0000000000000088 x25: 0000000000000000 x24: ffff800020f36805 x23: 0000000000000000 x22: ffffc00081a86878 x21: ffff800020be9c60 x20: 0000000000000000 x19: ffff800022501698 x18: 000000000000000a x17: 7365757165722066 x16: 666f7265776f7020 x15: 0000000000000000 x14: 0000000000000028 x13: 0000000000004def x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000805b4fc8 x8 : ffffc00081915820 x7 : ffffc00081c4f3c8 x6 : 0000000000000001 x5 : 0000000000000004 x4 : ffff800022498d80 x3 : ffffc000833a3b14 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800022501698 Call trace: blk_mq_release+0x194/0x238 (P) blk_put_queue+0x8c/0xf0 nvme_free_ctrl+0x4c/0x260 device_release+0x44/0x128 kobject_put+0xa0/0x120 put_device+0x1c/0x40 nvme_uninit_ctrl+0x48/0x60 apple_nvme_remove+0x54/0xb0 platform_remove+0x28/0x40 device_remove+0x54/0x98 device_release_driver_internal+ device_release_driver+0x20/0x38 apple_nvme_remove_dead_ctrl_wor process_one_work+0x1f4/0x770 worker_thread+0x1b8/0x360 kthread+0x140/0x160 ret_from_fork+0x10/0x20 irq event stamp: 448 hardirqs last enabled at (447):in_unlock_irqrestore+0x74/0x80 hardirqs last disabled at (448): [] el1_brk64+0x20/0x60 softirqs last enabled at (0): [ess+0xb28/0x2698 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 0000000000000000 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagA GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [0000000000000000] user address Internal error: Oops: 0000000096000005 [#1] SMP CPU: 7 UID: 0 PID: 54 Comm: kwor 7.2.0-rc1-dirty #248PREEMPT Tainted: [W]=WARN Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: kblockd blk_mq_timeou pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : percpu_ref_tryget_many.cons lr : percpu_ref_tryget_many.constprop.0+0xc0/0x168 sp : ffffc000829cbce0 x29: ffffc000829cbce0 x28: ffff800020be9f48 x27: ffff800013e503c0 x26: 0000000000000108 x25: 000009c05 x23: 0000000000000000 x22: ffffc000819f5000 x21: ffff800020be9f48 x20: ffff8001deda4808 x19: ffff8000a x17: 00000000580e1fac x16: ffffc00082bbbb7c x15: 0000000000000000 x14: 0000000000000028 x13: 000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000829cbc20 x8 : ffffc00081915820 x7 : ffffc0001 x5 : ffff80001ca77d08 x4 : 0000000000000000 x3 : ffff80001ca77cb8 x2 : 0000000000000000 x1 : 000000007 Call trace: percpu_ref_tryget_many.constpro blk_mq_timeout_work+0x48/0x298 process_one_work+0x1f4/0x770 worker_thread+0x1b8/0x360 kthread+0x140/0x160 ret_from_fork+0x10/0x20 Code: 91282000 97ed44b2 17ffffd2 ---[ end trace 0000000000000000 ]--- Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Tested-by: Joshua Peisach Tested-by: Janne Grunau Tested-by: Nick Chan Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit c38a8186326799957d293d370136c128cd113916 Author: Guixin Liu Date: Tue Aug 4 11:38:00 2026 +0800 nvmet: fix heap out-of-bounds read in nvmet_auth_negotiate() [ Upstream commit 5bb96cc218835769ab74ec7f3ea2bf81fbffe955 ] nvmet_execute_auth_send() allocates the DH-HMAC-CHAP message buffer with the host-supplied transfer length (tl) and hands it to nvmet_auth_negotiate() without passing tl along. nvmet_auth_negotiate() then reads the negotiate header and, for each of the halen hash identifiers and dhlen DH group identifiers, indexes into the fixed idlist[60] array (hashes at idlist[0..halen), groups at idlist[30..]). Neither the transfer length nor halen/dhlen is validated. A malicious or non-conformant host can report a tl smaller than the negotiate structure, or a halen/dhlen larger than the array (both are u8, up to 255), making the loops read past the end of the allocated buffer (heap out-of-bounds read). The sibling nvmet_auth_reply() already validates tl against the structure size; the negotiate path did not. Pass tl into nvmet_auth_negotiate(), reject a tl that does not cover the negotiate data plus one full protocol descriptor, and reject halen/dhlen larger than NVME_AUTH_DHCHAP_MAX_DH_IDS. Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit cb30449ee9a9c2689f65d1b54bfefea180da6486 Author: Alistair Francis Date: Fri Mar 20 10:20:44 2026 +1000 nvme: Add the DHCHAP maximum HD IDs [ Upstream commit 09e8f0f93491c6be867f32d4edc0b16fb5da785e ] In preperation for using DHCHAP length in upcoming host and target patches let's add the hash and diffie-hellman ID length macros. Reviewed-by: Christoph Hellwig Reviewed-by: Yunje Shin Reviewed-by: Hannes Reinecke Reviewed-by: Chris Leech Signed-off-by: Alistair Francis Signed-off-by: Keith Busch Stable-dep-of: 5bb96cc21883 ("nvmet: fix heap out-of-bounds read in nvmet_auth_negotiate()") Signed-off-by: Sasha Levin commit a3453d50130cb57cb2adbf439e3af6be2220784b Author: Ilya Leoshkevich Date: Thu Aug 6 21:04:45 2026 +0200 s390/irqflags: Add out-of-line definitions of arch_local_irq_*() for KMSAN [ Upstream commit 3f7c9f9c36b47a2a5cdbc56597eddf32662ef7fa ] Inline KMSAN arch_local_irq_*() definitions run afoul of -Wstatic-in-inline. Move them out-of-line. Make sure decompressor and non-GPL modules see the out-of-line definitions. Cc: Boqun Feng Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202607131219.euJHPSJ5-lkp@intel.com/ Suggested-by: Heiko Carstens Fixes: 1b301f5f28ba ("s390/irqflags: do not instrument arch_local_irq_*() with KMSAN") Signed-off-by: Ilya Leoshkevich Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit af20646a329e63f117a838c4510245ad41d6ad3f Author: Coiby Xu Date: Fri Feb 13 09:28:48 2026 +0800 s390: Drop unnecessary CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT [ Upstream commit a2e507afd9a25e333b7a58082f5db8c4de2bd12d ] Commit b5ca117365d9 ("ima: prevent kexec_load syscall based on runtime secureboot flag") and commit 268a78404973 ("s390/kexec_file: Disable kexec_load when IPLed secure") disabled the kexec_load syscall based on the secureboot mode. Commit 9e2b4be377f0 ("ima: add a new CONFIG for loading arch-specific policies") needed to detect the secure boot mode, not to load an IMA architecture specific policy. Since there is the new CONFIG_INTEGRITY_SECURE_BOOT, drop CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT for s390. Signed-off-by: Coiby Xu Tested-by: Alexander Egorenkov [Vasily Gorbik: Fix missing arch_get_secureboot() prototype warning] link: https://lore.kernel.org/linux-integrity/c00-01.ttbfdx5@ub.hpns/ Signed-off-by: Mimi Zohar Stable-dep-of: 3f7c9f9c36b4 ("s390/irqflags: Add out-of-line definitions of arch_local_irq_*() for KMSAN") Signed-off-by: Sasha Levin commit 283d2d61c4a3bbebfa18b8f1e6b4ce2512aaba92 Author: Coiby Xu Date: Fri Feb 13 09:28:46 2026 +0800 integrity: Make arch_ima_get_secureboot integrity-wide [ Upstream commit 31a6a07eefeb4c84bd6730fbe9e95fd9221712cf ] EVM and other LSMs need the ability to query the secure boot status of the system, without directly calling the IMA arch_ima_get_secureboot function. Refactor the secure boot status check into a general function named arch_get_secureboot. Reported-and-suggested-by: Mimi Zohar Suggested-by: Roberto Sassu Signed-off-by: Coiby Xu Acked-by: Ard Biesheuvel Signed-off-by: Mimi Zohar Stable-dep-of: 3f7c9f9c36b4 ("s390/irqflags: Add out-of-line definitions of arch_local_irq_*() for KMSAN") Signed-off-by: Sasha Levin commit d408d69f92b8c7e0d8efd56c8790fb8188fb699c Author: Josh Poimboeuf Date: Tue Aug 11 14:11:44 2026 +0000 arm64: bti: Disable in-kernel BTI with recent versions of Clang [ Upstream commit d3359af21fc9e7a47577ff90e821b6510ec34dee ] The following BTI exception was seen when loading a livepatch module: Internal error: Oops - BTI: 0000000036000001 [#1] SMP pstate: 634004c9 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=jc) pc : kill_orphaned_pgrp+0x0/0x150 lr : do_exit+0x498/0xaf0 [livepatch_combined] The problem is that the patch module's do_exit() is branching to a static function in vmlinux using a module PLT veneer (indirect branch), but the target function doesn't have a BTI landing pad. Clang 21+ omits the landing pad for static functions which can only be reached by a direct branch. That's normally fine for ordinary modules which only branch to global exported functions, but Mark Brown points out [1] that this isn't guaranteed if the module branches between sections. Futhermore, livepatch modules use klp relocations to reference arbitrary kernel symbols, so with CONFIG_RANDOMIZE_MODULE_REGION_FULL the module is far enough from the kernel that every R_AARCH64_CALL26 needs a PLT. Put Clang 21+ in the naughty corner alongside GCC, which suffers from the same issue, by disabling CONFIG_ARM64_BTI_KERNEL until we have a version of the toolchain with the problem resolved. Cc: Ard Biesheuvel Link: https://lore.kernel.org/r/da06bbd3-d04b-4d0f-b331-f5b91bc373a5@sirena.org.uk [1] Fixes: fd1e0fd71f65 ("arm64: Implement HAVE_LIVEPATCH") Signed-off-by: Josh Poimboeuf [will: Stitched together commit message, diff and bug number] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit bc34d10432303dd6db0470c8bfcf34e7d9b0315e Author: Jorijn van der Graaf Date: Sun Jul 26 23:12:26 2026 +0200 ASoC: qcom: q6apm: keep the graph start count in sync with the DSP [ Upstream commit daa7ffd765ae67a83e77dae32c66ce2d6d995d19 ] q6apm_graph_start() increments start_count even when APM_CMD_GRAPH_START fails, leaving the graph counted as running while the DSP never started it. A later start - a retried prepare, or a resume after a failed start - then finds a non-zero count, skips the command and returns success with no data flowing. Count the graph only once the DSP has accepted the start. The count then stays at zero for a graph that never started, so also stop decrementing below zero in q6apm_graph_stop(): the compressed free path stops unconditionally, and a negative count would make the next start skip the command in the same way. Fixes: 5477518b8a0e ("ASoC: qdsp6: audioreach: add q6apm support") Assisted-by: Claude:claude-opus-5 Signed-off-by: Jorijn van der Graaf Link: https://patch.msgid.link/20260726211226.94059-1-jorijnvdgraaf@catcrafts.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 79c05936be12cecde003f061c6fbb3aa91868adb Author: Babanpreet Singh Date: Wed Jul 29 05:35:43 2026 +0000 spi: sprd-adi: Fix probe succeeding without registering the controller [ Upstream commit f092e1c935015ee0a0fea1a0374f4cab7b71953c ] With CONFIG_HWSPINLOCK=n the of_hwspin_lock_get_id() stub returns 0 unconditionally. In sprd_adi_probe() the guard if (ret > 0 || (IS_ENABLED(CONFIG_HWSPINLOCK) && ret == 0)) is false for that 0, so it takes the else branch, where the switch has no case for 0 and lands in default: return dev_err_probe(&pdev->dev, ret, "failed to find hwlock id\n"); dev_err_probe() returns its err argument unchanged, so probe logs "failed to find hwlock id" and then returns 0, reporting success. sprd_adi_hw_init(), the restart handler and devm_spi_register_controller() are all skipped: the device binds but no SPI controller is ever registered. The hardware spinlock is optional for this controller and the -ENOENT arm already covers "no hardware spinlock supplied". Treat the stub's 0 the same way and continue without a lock; all four users of sadi->hwlock already test it for NULL. This is not reachable on production kernels. Kconfig has depends on HWSPINLOCK || (COMPILE_TEST && !HWSPINLOCK) so the affected configuration exists only under COMPILE_TEST, where no real hardware is present. Found by smatch: drivers/spi/spi-sprd-adi.c:560 sprd_adi_probe() warn: passing zero to 'dev_err_probe' Fixes: f9adf61e983f ("spi: sprd: adi: Change hwlock to be optional") Assisted-by: Claude:claude-opus-5 Reviewed-by: Baolin Wang Signed-off-by: Babanpreet Singh Link: https://patch.msgid.link/20260729053543.7-1-bbnpreetsingh@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b68d3a7a14585f216ce61a0d33c59a134afbb6d2 Author: Esteban Urrutia Date: Sat Jul 11 23:13:18 2026 -0400 phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy [ Upstream commit 8fd2b30d187fa33e5dd30699d3e3a3662c1610c9 ] There are no downstream device trees that specify five values in the qcom,aux-cfg1-settings array. Plus, after cross referencing both downstream device trees and entries which refer this function, only 0x13 is specified. Since 0x13 is written at initialization time, drop this function as a whole, and remove now unused variable assignations. Fixes: aff188feb5e1 ("phy: qcom-qmp: add support for sm8250-usb3-dp phy") Reviewed-by: Dmitry Baryshkov Signed-off-by: Esteban Urrutia Link: https://patch.msgid.link/20260711-sm8450-qol-qmp-v2-2-d14353bd6ff4@proton.me Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b499e89a828edf2f4d824515d30c4ddaab10c76c Author: Abel Vesa Date: Tue Dec 9 15:09:45 2025 -0800 phy: qualcomm: qmp-combo: Add DP offsets and settings for Glymur platforms [ Upstream commit d10736db98d25c97bdffacaca69ae0a8d7ca64e3 ] Starting with Glymur, the PCIe and DP PHYs qserdes register offsets differ for the same version number. So in order to be able to differentiate between them, add these ones with DP prefix. Add the necessary PHY setting tables for enabling the DP path within the QMP subsystem. Introduced some new callbacks for v8 specific sequences, such as for clock configurations based on the different link speeds. Wesley Cheng added some updated settings from the hardware programming guides on existing PHY tables and clock settings. Co-developed-by: Wesley Cheng Signed-off-by: Abel Vesa Signed-off-by: Wesley Cheng Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20251209-linux-next-12825-v8-9-42133596bda0@oss.qualcomm.com Signed-off-by: Vinod Koul Stable-dep-of: 8fd2b30d187f ("phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy") Signed-off-by: Sasha Levin commit becb8b30d9da6eb06472e6183a811e9c68f4ed6b Author: Wesley Cheng Date: Tue Dec 9 15:09:44 2025 -0800 phy: qualcomm: qmp-combo: Update QMP PHY with Glymur settings [ Upstream commit 5b289913959b9bc93bab9e0beeab269c33c969b7 ] For SuperSpeed USB to work properly, there is a set of HW settings that need to be programmed into the USB blocks within the QMP PHY. Ensure that these settings follow the latest settings mentioned in the HW programming guide. The QMP USB PHY on Glymur is a USB43 based PHY that will have some new ways to define certain registers, such as the replacement of TXA/RXA and TXB/RXB register sets. This was replaced with the LALB register set. There are also some PHY init updates to modify the PCS MISC register space. Without these, the QMP PHY PLL locking fails. Signed-off-by: Wesley Cheng Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20251209-linux-next-12825-v8-8-42133596bda0@oss.qualcomm.com Signed-off-by: Vinod Koul Stable-dep-of: 8fd2b30d187f ("phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy") Signed-off-by: Sasha Levin commit e1ce0661c0ce82c563183a977b625b0e7ea5dd22 Author: Wesley Cheng Date: Tue Dec 9 15:09:43 2025 -0800 phy: qualcomm: Update the QMP clamp register for V6 [ Upstream commit c9543cca9417d83f8ca6a8ce0a5279a3fba7a02b ] QMP combo phy V6 and above use the clamp register from the PCS always on (AON) address space. Update the driver accordingly. Reviewed-by: Dmitry Baryshkov Signed-off-by: Elson Roy Serrao Signed-off-by: Wesley Cheng Reviewed-by: Abel Vesa Link: https://patch.msgid.link/20251209-linux-next-12825-v8-7-42133596bda0@oss.qualcomm.com Signed-off-by: Vinod Koul Stable-dep-of: 8fd2b30d187f ("phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy") Signed-off-by: Sasha Levin commit aa615671f486ae719bc0c45d969d6a3b3b527aff Author: Faisal Hassan Date: Mon Sep 22 19:29:01 2025 +0530 phy: qcom-qmp-combo: Use regulator_bulk_data with init_load_uA for regulator setup [ Upstream commit 81d75558406609f311766a37ec4b2c74d7b11ea0 ] Replace the custom qmp_regulator_data structure with the standard regulator_bulk_data and use the init_load_uA field to set regulator load during initialization. This change simplifies the regulator setup by removing manual allocation and load configuration logic, and leverages devm_regulator_bulk_get_const() to automatically apply load settings before enabling regulators. Signed-off-by: Faisal Hassan Reviewed-by: Dmitry Baryshkov Reviewed-by: Neil Armstrong Reviewed-by: Bjorn Andersson Link: https://patch.msgid.link/20250922135901.2067-1-faisal.hassan@oss.qualcomm.com Signed-off-by: Vinod Koul Stable-dep-of: 8fd2b30d187f ("phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy") Signed-off-by: Sasha Levin commit 660b56537e180f9729746cd528b96c072f7b8a6d Author: Esteban Urrutia Date: Sat Jul 11 23:13:17 2026 -0400 phy: qcom: qmp-combo: Correct pre-emphasis table for QMP v4 DP PHYs [ Upstream commit 481807f939077059db278edd0467e7e609b6c9a7 ] Comparing sm8350 and sm8450 tables, this seems to be a typo. Fixes: ef14aff107bd ("phy: qcom: com-qmp-combo: add SM8350 & SM8450 support") Signed-off-by: Esteban Urrutia Link: https://patch.msgid.link/20260711-sm8450-qol-qmp-v2-1-d14353bd6ff4@proton.me Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 31b8b620a8aa13e2241158a3c7e2a01c53875711 Author: Lad Prabhakar Date: Thu Jul 2 13:58:55 2026 +0100 phy: renesas: rcar-gen3-usb2: Ignore missing VBUS regulator [ Upstream commit 9ea8d49c6cc6e217f5f5818369f659dc25bf89bf ] Commit b6d7dd157763 ("phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control") introduced support for controlling OTG VBUS through the regulator framework. As part of this change, the driver started requesting an exclusive "vbus" regulator for OTG-capable PHYs with no_adp_ctrl set. The lookup failure was propagated unconditionally, causing probe to fail on platforms where no VBUS regulator is described. On RZ/V2H and RZ/V2N, which do not use a VBUS regulator, this results in the following error: phy_rcar_gen3_usb2 15800200.usb-phy: dummy supplies not allowed for exclusive requests (id=vbus) This failure completely prevents the USB 2.0 interface from initializing. Fix this by allowing the probe to continue if an external VBUS regulator is missing. Only propagate the error if the internal vbus-regulator node is explicitly present, or if the lookup returns -EPROBE_DEFER. For all other missing regulator errors, gracefully assume no external VBUS regulator is available and return 0. Fixes: b6d7dd157763 ("phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control") Signed-off-by: Lad Prabhakar Tested-by: Tommaso Merciai Reviewed-by: Tommaso Merciai Link: https://patch.msgid.link/20260702125855.3157253-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 832022bb2ba5ae1d356efbbfc85e951494cd85ff Author: Mukesh Kumar Chaurasiya (IBM) Date: Tue Aug 11 12:03:45 2026 +0530 rust: uapi: replace direct asm-generic/ioctl.h include with linux/ioctl.h [ Upstream commit cdfcaa36ac93aa96df8310d7e57860f7600b2861 ] rust/uapi/uapi_helper.h was directly including instead of the proper . On powerpc, pulls in first, which defines _IOC_SIZEBITS, _IOC_DIRBITS, _IOC_NONE, and _IOC_WRITE with the arch-specific values, before falling through to . By bypassing that chain and including directly, the arch-specific overrides never ran first, so when other headers in the compilation later brought in the full arch-aware chain, Clang saw those four macros being defined a second time and emitted: clang diag: arch/powerpc/include/uapi/asm/ioctl.h:5:9: warning: '_IOC_SIZEBITS' macro redefined [-Wmacro-redefined] clang diag: arch/powerpc/include/uapi/asm/ioctl.h:6:9: warning: '_IOC_DIRBITS' macro redefined [-Wmacro-redefined] clang diag: arch/powerpc/include/uapi/asm/ioctl.h:8:9: warning: '_IOC_NONE' macro redefined [-Wmacro-redefined] clang diag: arch/powerpc/include/uapi/asm/ioctl.h:10:9: warning: '_IOC_WRITE' macro redefined [-Wmacro-redefined] Fix this by replacing the direct include of with , which is the correct arch-aware entry point and already maintains the intended include order. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202608050618.9dekfjtF-lkp@intel.com/ Signed-off-by: Mukesh Kumar Chaurasiya (IBM) Fixes: 4e1746656839 ("rust: uapi: Add UAPI crate") Link: https://patch.msgid.link/20260811063345.685884-1-mkchauras@gmail.com Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 218c36fdd5c635503b2a84588076797d01584cf0 Author: Vasant Hegde Date: Tue Aug 11 04:08:56 2026 +0000 iommu/amd: Fix incorrect device ID in invalid PASID error message [ Upstream commit 5322e19fc5acf013784207bc38191cd418a8bb48 ] The IO page fault notifier handler logs pdev->dev.id when reporting an invalid PASID, but pdev->dev.id is the kernel-internal device ID and not the IOMMU device ID (BDF). Use dev_data->devid instead, which reflects actual devid. Fixes: 978d626b8f1a ("iommu/amd: Add IO page fault notifier handler") Signed-off-by: Vasant Hegde Reviewed-by: Ankit Soni Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 7d1099b86356df81c379159bfb8a598aaf83ce81 Author: John Johansen Date: Fri May 8 22:30:07 2026 -0700 apparmor: fix unconfined user namespace restriction forced stack [ Upstream commit 08c2f7c8d4b1434cfae006f3daf4d1bce330b57b ] If a task is already confined by a stack the unprivileged transition restriction on unconfined is not correctly, applied. This results in an escape if two transitions through an unconfined profile can be executed. Fix this by pushing the check into the per profile label build. The check will always be done against unconfined and result in a stack of just the unconfined component when necessary. Fixes: 2d9da9b188b8 ("apparmor: allow restricting unprivileged change_profile") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 07485821b20b2ee9f538510da9ce88f987d4010c Author: John Johansen Date: Tue Feb 17 08:54:10 2026 -0700 apparmor: change fn_label_build() call to not return NULL [ Upstream commit ed7cc1c6f240a0c2838c0617afb2b0466edd236f ] Previously fn_label_build() was accepting a NULL which represented ENOMEM return and ERR_PTR for errors. Clean this up by requiring the cb fn to return an ERR_PTR or valid value. Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Stable-dep-of: 08c2f7c8d4b1 ("apparmor: fix unconfined user namespace restriction forced stack") Signed-off-by: Sasha Levin commit ab64b1584a9052755daa75fa66f46bf0657c47dc Author: John Johansen Date: Thu Dec 25 01:21:23 2025 -0800 apparmor: split xxx_in_ns into its two separate semantic use cases [ Upstream commit 796c146fa6c8289afc9e18004c21bfe05c75a487 ] This patch doesn't change current functionality, it switches the two uses of the in_ns fns and macros into the two semantically different cases they are used for. xxx_in_scope for checking mediation interaction between profiles xxx_in_view to determine which profiles are visible.The scope will always be a subset of the view as profiles that can not see each other can not interact. The split can not be completely done for label_match because it has to distinct uses matching permission against label in scope, and checking if a transition to a profile is allowed. The transition to a profile can include profiles that are in view but not in scope, so retain this distinction as a parameter. While at the moment the two uses are very similar, in the future there will be additional differences. So make sure the semantics differences are present in the code. Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Stable-dep-of: 08c2f7c8d4b1 ("apparmor: fix unconfined user namespace restriction forced stack") Signed-off-by: Sasha Levin commit c7f53d35455d1b11f174ab6f94c4094975f2c275 Author: Michael Walle Date: Thu Jul 30 12:52:18 2026 +0200 powerpc/configs: enable CONFIG_RAS to fix EDAC support [ Upstream commit 3921cfc2e8155a767235801be88cbd0e4c73508d ] Before commit e3c4ff6d8c94 ("EDAC: Remove EDAC_MM_EDAC") EDAC_MM_EDAC selected RAS, after that commit, EDAC depends on RAS, but nobody enables it. Enable it in the config again. Fixes: e3c4ff6d8c94 ("EDAC: Remove EDAC_MM_EDAC") Signed-off-by: Michael Walle Acked-by: Borislav Petkov (AMD) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260730105546.3658570-1-mwalle@kernel.org Signed-off-by: Sasha Levin commit 569eb11f0990849ba48706a2bfa743273707e254 Author: Kuniyuki Iwashima Date: Fri Aug 7 02:03:23 2026 +0000 amt: Don't support cross-netns setup. [ Upstream commit e99ecc3046ea5f5c6b5e1f8b4ef854c6c6998e06 ] When a lower device is unregistered, amt_device_event() tries to unregister its upper AMT device, but it has two problems. 1. amt_lookup_upper_dev() looks up an upper device in the lower device's netns only 2. amt_device_event() unregisters a single upper device only If AMT device is created on a lower device in another netns, removing the lower device triggers the splat below and gets stuck until all upper devices are removed. [0] The cross-netns setup seems unintentional considering 1. and the following points: * amt_link_setup() sets dev->netns_immutable to true * skb_scrub_packet() is not called in the fast path * iproute2 binary fails to find cross-netns lower device via link-netns: # ip -n ns1 link add amt0 link-netns ns2 type amt dev veth1 Cannot find device "veth1" Instead of supporting it properly and preparing for per-netns netdev unreg, let's forbid cross-netns setup. Note that the problem 2. needs a separate fix. [0]: WARNING: net/core/dev.c:12518 at unregister_netdevice_many_notify+0x1cce/0x2250, CPU#48: ip/2031 Modules linked in: CPU: 48 UID: 0 PID: 2031 Comm: ip Not tainted 7.2.0-rc5+ #27 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:unregister_netdevice_many_notify (net/core/dev.c:12518) Code: 89 ef e8 d5 52 ae fe e9 d0 f4 ff ff 48 8d 3d f9 3b 9c 02 48 c7 c6 c0 0b 63 84 ba ab 1f 00 00 67 48 0f b9 3a e9 65 ff ff ff 90 <0f> 0b 90 eb 81 48 8d 3d f6 3b 9c 02 48 c7 c6 c0 0b 63 84 ba e2 1f RSP: 0018:ffffc90004abf160 EFLAGS: 00010212 RAX: ffff888104d38260 RBX: ffff88800b0911b8 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff85b9f880 RBP: ffffc90004abf2d0 R08: ffffffff85b9f887 R09: 1ffffffff0b73f10 R10: dffffc0000000000 R11: fffffbfff0b73f11 R12: ffff88800b091d08 R13: ffff88800b091178 R14: dffffc0000000000 R15: ffff88800b091000 FS: 00007f555b86c600(0000) GS:ffff8881942a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562107d489c0 CR3: 0000000109a40002 CR4: 0000000000372ef0 Call Trace: rtnl_dellink (net/core/rtnetlink.c:3632 net/core/rtnetlink.c:3674) rtnetlink_rcv_msg (net/core/rtnetlink.c:7112) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1319) netlink_sendmsg (net/netlink/af_netlink.c:1900) ____sys_sendmsg (net/socket.c:775) __sys_sendmsg (net/socket.c:2738) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... unregister_netdevice: waiting for veth0 to become free. Usage count = 7 ref_tracker: netdev@ffff88800d7496d8 has 3/3 users at __netdev_adjacent_dev_insert (./include/linux/netdevice.h:4525 ./include/linux/netdevice.h:4554 net/core/dev.c:8791) __netdev_upper_dev_link (net/core/dev.c:8879 net/core/dev.c:8963) netdev_upper_dev_link (net/core/dev.c:9009) amt_newlink (drivers/net/amt.c:3321) Fixes: b9022b53adad ("amt: add control plane of amt interface") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Taehee Yoo Link: https://patch.msgid.link/20260807020326.2519445-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6033cc02fe27d7440f5a97b2fb0cb333dab6c7c0 Author: Liang Luo Date: Fri Aug 7 09:39:12 2026 +0800 selftests/sched_ext: Check skeleton open failure in exit test [ Upstream commit 4dc310b41aba43e9d8dfafe46dce86f8b55c0354 ] exit.c does not check the return value of exit__open(). If it returns NULL, which happens when the skeleton wrapper fails to allocate the object or open the BPF ELF, the very next line dereferences it via SCX_ENUM_INIT(). That macro expands to SCX_ENUM_SET(), which accesses skel->rodata, causing a NULL pointer dereference. Every other selftest guards this with SCX_FAIL_IF(!skel, ...); exit.c is the only one missing it. Fixes: a5db7817af78 ("sched_ext: Add selftests") Signed-off-by: Liang Luo Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit f1872cddf12ab3952018860d3f8714a6088da5f3 Author: Guopeng Zhang Date: Mon Aug 10 17:55:59 2026 +0800 cgroup/cpuset: Use WRITE_ONCE() for shared prs_err updates [ Upstream commit 26d3a59e0241c3ef9f66ae1ae990f9326acbc059 ] cpuset_partition_show() reads cs->prs_err without cpuset_mutex using READ_ONCE(). The field is documented as not lock protected, but several updates to live cpusets still use plain stores. Convert the remaining prs_err stores on live cpusets to WRITE_ONCE(). Fixes: 0c7f293efc87 ("cgroup/cpuset: Add cpuset.cpus.exclusive.effective for v2") Assisted-by: LLM Signed-off-by: Guopeng Zhang Reviewed-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 474da0e00d0c9816a6a007d89fb43c053dee5be5 Author: Waiman Long Date: Tue Nov 4 23:38:45 2025 -0500 cgroup/cpuset: Fail if isolated and nohz_full don't leave any housekeeping [ Upstream commit 103b08709e8a59876980a8edddf4e68f3a23e34e ] Currently the user can set up isolated cpus via cpuset and nohz_full in such a way that leaves no housekeeping CPU (i.e. no CPU that is neither domain isolated nor nohz full). This can be a problem for other subsystems (e.g. the timer wheel imgration). Prevent this configuration by blocking any assignation that would cause the union of domain isolated cpus and nohz_full to covers all CPUs. [longman: Remove isolated_cpus_should_update() and rewrite the checking in update_prstate() and update_parent_effective_cpumask()] Originally-by: Gabriele Monaco Signed-off-by: Waiman Long Reviewed-by: Chen Ridong Signed-off-by: Tejun Heo Stable-dep-of: 26d3a59e0241 ("cgroup/cpuset: Use WRITE_ONCE() for shared prs_err updates") Signed-off-by: Sasha Levin commit 4fd62a9418ab918475edb183ca7f57efcf1ef61c Author: Gabriele Monaco Date: Tue Nov 4 23:38:44 2025 -0500 cgroup/cpuset: Rename update_unbound_workqueue_cpumask() to update_isolation_cpumasks() [ Upstream commit 55939cf28a48dad27d6906e57d3b45905bb0d001 ] update_unbound_workqueue_cpumask() updates unbound workqueues settings when there's a change in isolated CPUs, but it can be used for other subsystems requiring updated when isolated CPUs change. Generalise the name to update_isolation_cpumasks() to prepare for other functions unrelated to workqueues to be called in that spot. [longman: Change the function name to update_isolation_cpumasks()] Acked-by: Frederic Weisbecker Acked-by: Waiman Long Signed-off-by: Gabriele Monaco Signed-off-by: Waiman Long Reviewed-by: Chen Ridong Reviewed-by: Chen Ridong Signed-off-by: Tejun Heo Stable-dep-of: 26d3a59e0241 ("cgroup/cpuset: Use WRITE_ONCE() for shared prs_err updates") Signed-off-by: Sasha Levin commit c25b6b28a35f9e36ce5dd6da5905bcddb2128707 Author: Guixin Liu Date: Tue Aug 4 10:18:59 2026 +0800 nvme-pci: release descriptor pools on probe failure [ Upstream commit cb144c2f67128abfa5c7ba33318617d19f192156 ] The per-NUMA-node descriptor DMA pools are created lazily from nvme_init_hctx_common() once the admin tag set is allocated, but they are only destroyed in nvme_remove() via nvme_release_descriptor_pools(). Any probe failure after the admin tag set has been allocated unwinds through the out_disable label and nvme_pci_free_ctrl(), neither of which releases the pools, leaking the dma_pool objects. Release the descriptor pools in the out_disable error path. It must not be added to nvme_pci_free_ctrl(), as that would double-free against nvme_remove() on the normal teardown path. Fixes: d977506f8863 ("nvme-pci: make PRP list DMA pools per-NUMA-node") Signed-off-by: Guixin Liu Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Kanchan Joshi Reviewed-by: Nilay Shroff Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 9e489dc3fbbf4dee13fe0ee654b87a3b992d2124 Author: Guixin Liu Date: Tue Aug 4 10:18:58 2026 +0800 nvmet: propagate percpu_ref_init() failure in nvmet_ns_enable() [ Upstream commit 751709592d2626eaa8dc17ef8137796758a3c37f ] The return value of percpu_ref_init() is discarded. At this point ret is 0 from the preceding successful steps, so when the allocation inside percpu_ref_init() fails the code jumps to the out_pr_exit cleanup chain which ends with "return ret", i.e. reports success. The configfs enable store then tells userspace the namespace was enabled even though it was not and its backing device has already been torn down. Capture the return value so the failure is propagated. Fixes: 408232680707 ("nvmet: Fix crash when a namespace is disabled") Signed-off-by: Guixin Liu Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Nilay Shroff Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 33f07f8fbb9cb40fdbe4028d60d3ee4c25bc88d2 Author: Zhengrong Li Date: Tue Jul 28 16:26:01 2026 +0800 nvmet: fix Reservation Register Replace for unregistered host with IEKEY [ Upstream commit 0a96b9e440331bffbf049f80d7e5c96417d37e36 ] When a host sends a Reservation Register command with RREGA=Replace and IEKEY=1 without being previously registered, nvmet returns Reservation Conflict. The NVMe specification states: "A host may replace its reservation key without regard to its registration status or current reservation key value by setting the Ignore Existing Key (IEKEY) bit to '1' in the Reservation Register command." Fix nvmet_pr_replace() to add a new registrant when the host is not found in the registrant list and IEKEY is set with a non-zero NRKEY. If IEKEY is set but NRKEY is zero, return Invalid Field since there is no valid reservation key to register. Tested with nvme-cli against nvmet-tcp: # no prior registration nvme resv-register /dev/nvmeXn1 -n 1 --rrega=2 --iekey --nrkey=0x9999 Before: RESERVATION_CONFLICT (0x4083) After: success, registrant created with rkey 0x9999 Fixes: 5a47c2080a73 ("nvmet: support reservation feature") Reviewed-by: Christoph Hellwig Reviewed-by: Guixin Liu Signed-off-by: Zhengrong Li Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit da652cb17f9faeea1fa44b7215e8869a0b10b664 Author: Runyu Xiao Date: Thu Jun 11 13:35:56 2026 +0800 sunrpc: xprtsock: annotate shared socket callbacks with READ_ONCE/WRITE_ONCE [ Upstream commit 33930840b5f0a79f826e7c69dc6cd78f72a67481 ] xprtsock replaces and restores sk->sk_data_ready and sk->sk_write_space on live sockets with plain stores, and xs_udp_do_set_buffer_size() invokes sk->sk_write_space via a plain load. These callback pointers are shared with generic socket and protocol paths that may read or invoke them concurrently, so xprtsock needs the same READ_ONCE()/WRITE_ONCE() callback visibility contract that the validated 4022 family applied elsewhere. When SUNRPC takes over an AF_LOCAL, UDP, or TCP socket and later restores the lower-socket callbacks during teardown, another CPU may still hold an earlier callback snapshot. The plain replace/restore pattern leaves the same visibility hole as the validated 4022 family, so a stale snapshot can still invoke xs_data_ready() or xs_udp_write_space() after the live callback fields have already been restored to the lower-socket handlers. Use WRITE_ONCE() for the shared sk_data_ready and sk_write_space stores in xs_local_finish_connecting(), xs_udp_finish_connecting(), xs_tcp_finish_connecting(), and xs_restore_old_callbacks(). Use READ_ONCE() for the direct sk_write_space invocation in xs_udp_do_set_buffer_size(). This matches the required callback visibility contract while leaving adjacent sk_state_change and sk_error_report handling unchanged. Fixes: a246b0105bbd ("[PATCH] RPC: introduce client-side transport switch") Signed-off-by: Runyu Xiao Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit cda4aacfb0bbf5c0f90fd0b42c72c749635d1368 Author: Weiming Shi Date: Sun Jun 7 07:06:46 2026 -0700 SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6 [ Upstream commit fd22370226a0d8109045d0831fd5aaadee921693 ] rpcb_register_inet4() and rpcb_register_inet6() store the result of rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL. rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROC_SET encode path: rpcb_register_call() -> rpc_call_sync() -> rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel. The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890) rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910) rpcauth_wrap_req_encode (net/sunrpc/auth.c:745) call_encode (net/sunrpc/clnt.c:1966) __rpc_execute (net/sunrpc/sched.c:952) rpc_run_task (net/sunrpc/clnt.c:1243) rpc_call_sync (net/sunrpc/clnt.c:1272) rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500) svc_generic_rpcbind_set nfsd_rpcbind_set svc_register svc_setup_socket svc_addsock write_ports nfsctl_transaction_write vfs_write The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFP_KERNEL kstrdup() in rpc_sockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check. Mirror that handling: bail out with -ENOMEM when rpc_sockaddr2uaddr() returns NULL, before the address is fed into the encoder. Fixes: d77385f23830 ("SUNRPC: Fix rpc_sockaddr2uaddr") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi Reviewed-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 7d0554350d884455ad619ef54bc47ab467dffa0d Author: Thomas Weißschuh Date: Sat Jul 11 11:59:07 2026 +0200 hwmon: (cros_ec) Synchronize EC access from the thermal device callbacks [ Upstream commit 26db273640887276a24ca2546b06e334508871f8 ] To guarantee consistency for the read-modify-write access in cros_ec_hwmon_cooling_set_cur_state(), locking is necessary. Use the existing hwmon device lock to do so. Fixes: 5798b62867b4 ("hwmon: (cros_ec) register fans into thermal framework cooling devices") Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20260711-cros_ec-hwmon-locking-v1-3-cb6d0fdbb2d3@weissschuh.net Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 13ad7a04b97a689426e4ce65a9a67e2e0b27d75a Author: Thomas Weißschuh Date: Sat Jul 11 11:59:06 2026 +0200 hwmon: (cros_ec) Store the hwmon device in cros_ec_hwmon_priv [ Upstream commit 434baf3aea987ae61d0d54b6cdf8fccf78383b4e ] The upcoming locking scheme for thermal devices will require access to the hwmon device. Add it do the priv struct. Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20260711-cros_ec-hwmon-locking-v1-2-cb6d0fdbb2d3@weissschuh.net Signed-off-by: Guenter Roeck Stable-dep-of: 26db27364088 ("hwmon: (cros_ec) Synchronize EC access from the thermal device callbacks") Signed-off-by: Sasha Levin commit 49390d9d8eaf04a8a29ad9e37e6fa584ac50f996 Author: Thomas Weißschuh Date: Sat Jul 11 11:59:05 2026 +0200 hwmon: (cros_ec) Register the thermal devices after the hwmon ones [ Upstream commit 9f1012119f2a4cb5a7f589dc77d5e15dbab49d00 ] To guarantee consistency for the read-modify-write access in cros_ec_hwmon_cooling_set_cur_state(), locking is necessary. The locking will use standard hwmon device locks, which requires the hwmon device to be ready before the fan devices are set up. Reorder the initialization so this works. Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20260711-cros_ec-hwmon-locking-v1-1-cb6d0fdbb2d3@weissschuh.net Signed-off-by: Guenter Roeck Stable-dep-of: 26db27364088 ("hwmon: (cros_ec) Synchronize EC access from the thermal device callbacks") Signed-off-by: Sasha Levin commit 786409d4dcd1b5132ec362bdf511dcc20e1a6998 Author: Guenter Roeck Date: Wed May 13 07:14:33 2026 -0700 hwmon: Support guard() and scoped_guard for subsystem locks [ Upstream commit d1e720c7328e046049b792d03fae093d4d3a72e4 ] Add support for guard() and scoped_guard() for the hwmon subsystem lock to simplify its use. Signed-off-by: Guenter Roeck Stable-dep-of: 26db27364088 ("hwmon: (cros_ec) Synchronize EC access from the thermal device callbacks") Signed-off-by: Sasha Levin commit 1a010fcc0f1b08f2249eb328234e461afbde560a Author: Thomas Weißschuh Date: Sun Jan 18 10:45:58 2026 +0100 hwmon: (cros_ec) Add support for temperature thresholds [ Upstream commit afa7c56ec447315ab38182bb9c185d8ea712c3ad ] Implement reading temperature thresholds through EC_CMD_THERMAL_GET_THRESHOLD/EC_CMD_THERMAL_SET_THRESHOLD. Thresholds are mapped as follows between the EC and hwmon: hwmon_temp_max - EC_TEMP_THRESH_WARN hwmon_temp_crit - EC_TEMP_THRESH_HIGH hwmon_temp_emergency - EC_TEMP_THRESH_HALT Signed-off-by: Thomas Weißschuh Reviewed-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20260118-cros_ec-hwmon-pwm-v2-4-77eb1709b031@weissschuh.net [groeck: Rearrange code to no longer use unreachable() since that causes a hiccup with some versions of gcc and objtool] Signed-off-by: Guenter Roeck Stable-dep-of: 26db27364088 ("hwmon: (cros_ec) Synchronize EC access from the thermal device callbacks") Signed-off-by: Sasha Levin commit 14ec2662754198123442ad667f33ac2e2737ef21 Author: Thomas Weißschuh Date: Sun Jan 18 10:45:57 2026 +0100 hwmon: (cros_ec) Move temperature channel params to a macro [ Upstream commit 11c5802d28dd71fffb4df0720eafe840a953dc92 ] An upcoming change will add more channel parameters. This leads to a lot of churn and very long lines. Use a macro to encapsulate all of the shared values. Signed-off-by: Thomas Weißschuh Reviewed-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20260118-cros_ec-hwmon-pwm-v2-3-77eb1709b031@weissschuh.net Signed-off-by: Guenter Roeck Stable-dep-of: 26db27364088 ("hwmon: (cros_ec) Synchronize EC access from the thermal device callbacks") Signed-off-by: Sasha Levin commit 6fa77dea178e79ed675784bbd6bc0e82f882eb0f Author: Thomas Weißschuh Date: Sun Jan 18 10:45:55 2026 +0100 hwmon: (cros_ec) Split up supported features in the documentation [ Upstream commit 18ccf48656e010838075fd00caa6d93d3f95d106 ] The wall of text of supported features is hard to read and messy to extend. Split it into a definition list with an explanations for each supported feature. Signed-off-by: Thomas Weißschuh Reviewed-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20260118-cros_ec-hwmon-pwm-v2-1-77eb1709b031@weissschuh.net Signed-off-by: Guenter Roeck Stable-dep-of: 26db27364088 ("hwmon: (cros_ec) Synchronize EC access from the thermal device callbacks") Signed-off-by: Sasha Levin commit 28e9bcb654f19bd267f66d850f7ad55e4a15b620 Author: Marco Elver Date: Fri Aug 7 13:37:32 2026 +0000 arm64: Disable KCSAN instrumentation in delay.o [ Upstream commit 5eaec4cf41a8f5ac1a0c69a607cdc5035a797f73 ] KCSAN relies on udelay() for injecting delays. To avoid recursively triggering a watchpoint, where KCSAN sets up watchpoint on an address that is accessed by udelay() in the same thread, disable instrumentation in arm64's delay implementation. Paul found a manifestation of this as follows: | BUG: KCSAN: data-race in __delay / set_need_resched_current | | read (marked) to 0xffff000005899b48 of 8 bytes by interrupt on cpu 8: | __delay+0xb0/0x378 | __udelay+0x4c/0x60 | kcsan_setup_watchpoint+0x3b4/0x820 | __tsan_unaligned_write4+0x228/0x26c | set_need_resched_current+0x138/0x1a8 | rcu_exp_handler+0x418/0x4a0 | __flush_smp_call_function_queue+0x36c/0x4a0 | generic_smp_call_function_single_interrupt+0x20/0x30 | ipi_handler+0xec/0x558 | handle_percpu_devid_irq+0x220/0x2a0 | generic_handle_domain_irq+0x84/0xb4 | gic_handle_irq+0x64/0x144 | call_on_irq_stack+0x30/0x48 | do_interrupt_handler+0x80/0xb8 | el1_interrupt+0x3c/0x60 | el1h_64_irq_handler+0x18/0x24 | el1h_64_irq+0x6c/0x70 | smp_call_function_single+0x18c/0x25c | sync_rcu_exp_select_node_cpus+0x534/0x8bc | rcu_exp_sel_wait_wake+0x358/0xef4 | wait_rcu_exp_gp+0x30/0x44 | kthread_worker_fn+0x1b4/0x5dc | kthread+0x1d8/0x204 | ret_from_fork+0x10/0x20 | | write to 0xffff000005899b4c of 4 bytes by interrupt on cpu 8: | set_need_resched_current+0x138/0x1a8 | [...] This matches what is already done in arch/x86/lib/Makefile. Reported-by: "Paul E. McKenney" Fixes: dd03762ab608 ("arm64: Enable KCSAN") Signed-off-by: Marco Elver Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 0f7f363cc6cebd2f4e9396d8efc850101ed7df48 Author: Chuck Lever Date: Sun Jul 12 15:31:22 2026 -0400 xdrgen: Fix opaque and string encoders for unbounded members [ Upstream commit daa52e37851a5a1b5890e7a250a27e94a8b9f273 ] The variable-length opaque and string encoder templates emit an unconditional bound check, "if (value->NAME.len > MAXSIZE) return false". XDR represents an unbounded specifier (opaque foo<>, string foo<>) as a maxsize of 0, so for an unbounded member the check degenerates to "len > 0" and the generated encoder refuses every non-empty value. The decoder does not share this defect. It delegates to xdrgen_decode_opaque() and xdrgen_decode_string(), which treat a maxlen of 0 as unbounded and skip the length check. The sibling variable-length array templates already guard their bound check with maxsize != "0". Guard the bound check the same way in each affected template -- the struct and pointer forms of both the opaque and string encoders -- so an unbounded member encodes a payload of any length while a bounded member keeps its limit. An explicit zero-length bound (foo<0>) parses to the same maxsize of 0 and so also skips the check; xdrgen does not distinguish it from the unbounded form, matching the decoder and the array encoders. Fixes: 4b132aacb076 ("tools: Add xdrgen") Link: https://patch.msgid.link/20260712193122.116845-6-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 97c12f3e24e7dd797f6e31e0f814997c91172780 Author: Chuck Lever Date: Sun Jul 12 15:31:20 2026 -0400 xdrgen: Do not declare union XDR functions in the definitions header [ Upstream commit d4ca0b0a6c62bc12407060754df11b23a90f3e57 ] Unlike the struct, enum, typedef, and pointer templates, the union definitions template also emits xdrgen_decode_*() and xdrgen_encode_*() prototypes for a public union into that header. Those prototypes name struct xdr_stream, which the definitions header neither includes nor forward-declares, so any translation unit that includes the definitions header without xdr.h already in scope draws -Wvisibility warnings. The same public prototypes are emitted into the declarations header, which does include , making the definitions-header copies redundant. Drop the prototype emission from the union definitions template so it matches the other type templates. Public unions keep their encode and decode prototypes through the declarations header. Fixes: 4b132aacb076 ("tools: Add xdrgen") Link: https://patch.msgid.link/20260712193122.116845-4-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 184a3e5bbc01baadc67633fc4efee2030939c3fd Author: Chuck Lever Date: Mon Dec 1 17:19:46 2025 -0500 xdrgen: Address some checkpatch whitespace complaints [ Upstream commit 4329010ad9c36775e7092e451c37c24c4f90243f ] This is a roll-up of three template fixes that eliminate noise from checkpatch output so that it's easier to spot non-trivial problems. To follow conventional kernel C style, when a union declaration is marked with "pragma public", there should be a blank line between the emitted "union xxx { ... };" and the decoder and encoder function declarations. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Stable-dep-of: d4ca0b0a6c62 ("xdrgen: Do not declare union XDR functions in the definitions header") Signed-off-by: Sasha Levin commit 221a025fb6aa637db6fb6d5fe0d7839712934702 Author: Karl Mehltretter Date: Thu Jul 23 06:10:55 2026 +0200 m68k: Fix backtraces for non-running tasks [ Upstream commit 09f71dbeb287e367beea56d9ac8a3d356ef5e02a ] When no stack pointer is supplied, show_stack() starts at thread.esp0. This is the saved userspace register frame, not where a task was switched out. For kernel threads it points to the zeroed frame created by copy_thread(), so sched_show_task() prints no useful backtrace. Use thread.ksp for non-current tasks. It is saved by switch_to() and is already used by __get_wchan(). For current, start at the current stack frame, as is already done when no task is supplied. Tested on qemu-system-m68k -M virt using SysRq-t. All task dumps contained resolved frames. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Karl Mehltretter Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260723041055.47289-1-kmehltretter@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 0fdc6aaea29655acd323c7f56785a537fea90001 Author: Yuho Choi Date: Sun Aug 2 18:22:59 2026 -0400 hwrng: imx-rngc - Disable clock on registration failure [ Upstream commit 188bb9ad86c3b2d527385328a30c1d9510253202 ] The RNGC clock is enabled manually before runtime PM is configured. If devm_hwrng_register() fails, probe returns without disabling the clock. The devm_pm_runtime_enable() cleanup only disables runtime PM and does not call imx_rngc_suspend(). Disable the clock before returning from this failure path. Fixes: 7a96a64e8689 ("hwrng: imx-rngc - add runtime pm") Signed-off-by: Yuho Choi Reviewed-by: Martin Kaiser Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5067a5fbbd02509a6e46a66d268e1fd0409bbf8b Author: Ahsan Atta Date: Fri Jul 31 13:48:32 2026 +0100 crypto: qat - remove dead ADF_HEX code [ Upstream commit 61135c1597af56eb454d53c9d7cda90d5e5dc566 ] The ADF_HEX value type is defined in the adf_cfg_val_type enum and handled in adf_cfg_add_key_value_param(), but no caller in the tree uses it. Remove the unused ADF_HEX enum value and its dead handling code. Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework") Reviewed-by: Giovanni Cabiddu Reviewed-by: Svyatoslav Pankratov Signed-off-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0c68bf6b4842eab2b4f61bf4afa886ce1c1bba1f Author: Thorsten Blum Date: Sat Jun 6 01:11:02 2026 +0200 crypto: qat - use 2-arg strscpy where destination size is known [ Upstream commit 4525ac14115d07c3e4c57a8cd5c154916e9d1172 ] To simplify the code, drop explicit and hard-coded size arguments from strscpy() where the destination buffer has a fixed size and strscpy() can automatically determine it using sizeof(). Acked-by: Giovanni Cabiddu Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Stable-dep-of: 61135c1597af ("crypto: qat - remove dead ADF_HEX code") Signed-off-by: Sasha Levin commit a803141597d61dc0511f7cd849625e17d042ca8a Author: Lu Baolu Date: Wed Aug 5 07:43:13 2026 +0800 iommu/vt-d: Flush context cache with correct SID when tearing down aliases [ Upstream commit c54e4ae971b98e8d650400137d332cee56c03f55 ] domain_context_clear_one() and device_pasid_table_teardown() are both invoked once per DMA alias of a device. Each function locates the context entry using the bus/devfn pair provided by the pci_for_each_dma_alias() callback, then calls intel_context_flush_no_pasid(), which constructs a device-selective context-cache invalidation from info->bus and info->devfn (that is, always the requester ID of the device itself). As a result, for every alias other than the device’s own RID, the context entry that was just cleared in memory is never invalidated in the context cache. Hardware may continue using that stale cached entry. In the scalable-mode teardown path, intel_pasid_free_table() can then free the PASID directory still referenced by that stale entry, allowing the IOMMU to walk freed memory. Fix this by passing the source ID of the entry being torn down to intel_context_flush_no_pasid(), instead of deriving it from @info. Fixes: f90584f4beb84 ("iommu/vt-d: Add helper to flush caches for context change") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40linux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Reviewed-by: Samiullah Khawaja Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit d0e978ced7429b516358bb4d41d337214768ae98 Author: Lu Baolu Date: Wed Aug 5 07:43:12 2026 +0800 iommu/vt-d: Tear down scalable-mode context on probe failure [ Upstream commit c509fb73a1093a15accd7d43a61645d4b520f6ac ] intel_pasid_setup_sm_context() walks a PCI device’s DMA aliases via pci_for_each_dma_alias() and programs a scalable-mode context entry for each RID. For a device with a dma_alias_mask, the callback is invoked once for the device’s own RID and once for each alias bit, all with the same pci_dev, so device_pasid_table_setup() runs for multiple RIDs. pci_for_each_dma_alias() stops at the first callback error. Therefore, a failure partway through the walk can leave context entries for already processed RIDs present and still pointing to the device’s PASID table. On this error path, intel_iommu_probe_device() currently jumps directly to intel_pasid_free_table(), which frees the PASID table without first tearing down those context entries. The IOMMU may then walk a present context entry whose PASID table pointer references freed memory. intel_iommu_release_device() already performs teardown before freeing the table. Apply the same ordering on the probe failure path. device_pasid_table_teardown() safely handles RIDs that were never programmed: iommu_context_addr() returns NULL when no context table has been allocated, and clearing the Present bit of an already non-present entry is a no-op. So unwind is safe for both the alias that failed and any aliases not yet reached. Fixes: 301f1a80487fd ("iommu/vt-d: Setup scalable mode context entry in probe path") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40linux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 3c88cfedc7768b1ae2dc7ddc71547ae9a1aaff7d Author: Lu Baolu Date: Wed Aug 5 07:43:10 2026 +0800 iommu/vt-d: Clear Present bit before tearing down copied context entry [ Upstream commit f532c57985b1a7d6b7e37e05506b46d413e5cca4 ] copied_context_tear_down() zeroes the 128-bit context entry with context_clear_entry() while the Present bit is still set, and only then issues the context-cache and IOTLB invalidations. This leaves a window in which hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behaviour or spurious faults. While x86 provides strong write ordering, the compiler may reorder the writes to the two 64-bit halves of the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. There is no cacheline flush before the invalidation either, so on an IOMMU without coherent access to the context table the zeroed entry may not be visible to hardware at the point the invalidation is submitted. Apply the same ownership handshake described in the VT-d spec, Section 6.5.3.3 ("Guidance to Software for Invalidations"): clear only the Present bit, flush it out to the IOMMU, perform the invalidations, and only then zero the remainder of the entry. Fixes: c7191984e5aad ("iommu/vt-d: Factor out helpers from domain_context_mapping_one()") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40linux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 686bd59429ffef95b1e6959ad7b2a43d6143b0f2 Author: Desnes Nunes Date: Wed Aug 5 07:42:55 2026 +0800 iommu/vt-d: Fix UCTP context table slot when copying root entries [ Upstream commit c6e63fc8e8fcefa5c32145dc0a3c82975b0ce152 ] When translation is already enabled at boot (e.g. kdump), the vt-d driver copies context tables from the previous kernel's root table. In scalable mode, buses that only populate the upper root half (UCTP, devfn >= 0x80) should be written to ctxt_tbls[tbl_idx + 1] through copy_context_table(). However, the current copy path always uses tbl[tbl_idx + 0] in this situa- tion. Since idx wraps to 0 at devfn 0x80 due to a zeroed LCTP, new_ce for LCTP will be NULL and keep pos equals to 0. Thus, UCTP entries will be co- pied into tbl[tbl_idx + 0] instead of tbl[tbl_idx + 1], and written after- wards to root_entry[bus].lo instead of .hi in copy_translation_tables(). In short, devices on bus 0x80 with devfn >= 0x80 fail DMA with fault 0x39, which will break drivers running in kernels with translation pre-enabled. This fixes NO_PASID DMAR faults for UCTP-only buses such as: DMAR: [DMA Read NO_PASID] Request device [80:14.0] fault addr 0xe81759000 [fault reason 0x39] SM: Present bit in Root Entry is clear For instance, this fault yielded to locking issues between systemd and xHCI, blocking a system's reboot after a vmcore was captured with kdump: systemd-udevd[246]: usb3: Worker [255] processing SEQNUM=2193 is taking a long time dracut-initqueue[277]: Timed out while waiting for udev queue to empty. systemd-udevd[246]: usb3: Worker [255] processing SEQNUM=2193 killed systemd-udevd[246]: usb3: Worker [255] terminated by signal 9 (KILL). ... kdump[569]: saving vmcore complete ... systemd-shutdown[1]: Rebooting. INFO: task kworker/0:1:11 blocked for more than 122 seconds. Not tainted 7.0.0-clean #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208160 flags:0x00080000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0x299/0x5c0 schedule+0x27/0x80 schedule_timeout+0xbd/0x100 __wait_for_common+0x97/0x1b0 ? __pfx_schedule_timeout+0x10/0x10 xhci_alloc_dev+0x9e/0x2b0 usb_alloc_dev+0x7a/0x3b0 hub_port_connect+0x285/0x960 hub_port_connect_change+0x94/0x290 port_event+0x4bb/0x840 hub_event+0x141/0x460 process_one_work+0x196/0x390 worker_thread+0x1af/0x320 ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 INFO: task systemd-shutdow:1 blocked for more than 122 seconds. Not tainted 7.0.0-clean #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:systemd-shutdow state:D stack:0 pid:1 tgid:1 ppid:0 task_flags:0x400100 flags:0x00080000 Call Trace: __schedule+0x299/0x5c0 schedule+0x27/0x80 schedule_preempt_disabled+0x15/0x30 __mutex_lock.constprop.0+0x547/0xac0 device_shutdown+0xac/0x1b0 kernel_restart+0x3a/0x70 __do_sys_reboot+0x147/0x240 do_syscall_64+0x11b/0x6a0 ? handle_mm_fault+0x110/0x350 ? do_user_addr_fault+0x206/0x680 ? irqentry_exit+0x7a/0x4d0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fe2958da917 RSP: 002b:00007ffc5c458618 EFLAGS: 00000206 ORIG_RAX: 00000000000000a9 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe2958da917 RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead RBP: 00007ffc5c458790 R08: 0000000000000069 R09: 00000000ffffffff R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000 R13: 0000000000000000 R14: 00007ffc5c4588b8 R15: 0000000000000000 INFO: task systemd-shutdow:1 is blocked on a mutex likely owned by task kworker/0:1:11. Fixes: 091d42e43d21 ("iommu/vt-d: Copy translation tables from old kernel") Signed-off-by: Desnes Nunes Tested-by: Tao Liu Signed-off-by: Lu Baolu Reviewed-by: Samiullah Khawaja Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit e3c53e9173a47d5ce1fae020f2c6b1fb3c1123c2 Author: Andrew Jones Date: Thu Jul 30 15:23:23 2026 +0200 iommu/dma: Restore locking around msi_page_list [ Upstream commit 5a9e89ea34e0e34ac5d7e949042d665533549e40 ] Unlike a group's default domain, which is always freshly allocated and privately owned (iommu_group_alloc_default_domain()), VFIO type1's legacy container merges any newly attached group into an existing domain whenever their iommu_ops and cache-coherency enforcement match. iommu_dma_get_msi_page() only asserts the caller's own group mutex is held (iommu_group_mutex_assert()). On an IOMMU that publishes IOMMU_RESV_SW_MSI, e.g. ARM SMMU, a VM with two such devices assigned through the legacy container can have their guest drivers probe and allocate MSIs in parallel; each host-side VFIO_DEVICE_SET_IRQS lands on a different device fd and group mutex, but both devices' domains are the same merged domain, so both can enter iommu_dma_get_msi_page() concurrently and corrupt msi_page_list. commit 288683c92b1a ("iommu: Make iommu_dma_prepare_msi() into a generic operation") dropped the prior msi_prepare_lock on the reasoning that "each iommu_domain is unique to a group," which holds for default domains but not this VFIO type1 case. Restore the static lock, since it's only guarding a corner case and will likely never be contended. iommufd avoids the equivalent problem by having its own callers (iommufd_sw_map_msi()) take a ctx-wide sw_msi_lock before ever reaching the shared list. VFIO type1 can't mirror that since it dispatches to iommu_dma_sw_msi() which is outside VFIO's jurisdiction. Fixes: 288683c92b1a ("iommu: Make iommu_dma_prepare_msi() into a generic operation") Signed-off-by: Andrew Jones Reviewed-by: Jason Gunthorpe Reviewed-by: Nutty Liu Reviewed-by: Robin Murphy Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 7508654e409ed6afcafc2a1d72be0c0d3e925cc2 Author: Karl Mehltretter Date: Sat Aug 8 16:41:14 2026 +0200 fbdev: clps711x-fb: Remove unreachable unregister_framebuffer() call [ Upstream commit 39dd7598fbe90c5b4bb77fb34d8f3dad8385d11c ] The unregister_framebuffer() call in clps711x_fb_probe() is unreachable. register_framebuffer() failure jumps to the unwind label, while success returns immediately. Remove it. Found with Clang's -Wunreachable-code. Fixes: 36462ac193088 ("fbdev: clps711x-fb: Replace check_fb in favor of struct fb_info.lcd_dev") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Acked-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 33e54e3e0b2ca959304e62c3d84f0ad49bbe1afe Author: Danila Chernetsov Date: Fri Jul 24 00:42:45 2026 +0000 fbdev: kyro: Validate overlay viewport coordinates [ Upstream commit 7b5c7bc55e13e7f5ac7b1eaf5c6d690389ea5ee3 ] The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Danila Chernetsov Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 656e580c19ca1aea8c97b42ce6a210c69a9060fe Author: Myeonghun Pak Date: Wed Jul 1 20:21:47 2026 +0900 fbdev: tdfxfb: fix PCI enable cleanup with pcim_enable_device() [ Upstream commit 95a627143a696f70e17be5ed3b1e733bb6724b46 ] tdfxfb_probe() enables the PCI device with pci_enable_device(), but several failure paths after that point return without disabling it. The framebuffer_alloc() failure path returns -ENOMEM directly, and the later shared out_err path releases the framebuffer and returns -ENXIO without balancing the PCI enable state. The successful probe path has the same imbalance because tdfxfb_remove() releases the framebuffer, mappings and regions, but never calls pci_disable_device(). Use pcim_enable_device() so the PCI device is disabled automatically on probe failure and driver detach. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 656e43f7afabb8deceb5eedf60fb328cc1cbd9e1 Author: Ian Rogers Date: Sun Aug 9 00:14:54 2026 -0700 perf synthetic-events: Fix divide by zero in perf_event__synthesize_threads [ Upstream commit 16a12a54e9a1151a37aab74914a51b86f7f58d0e ] If scandir() finds no matching tasks in /proc, n is 0. If thread_nr is > 1, we bypass the single-thread fast path and then clamp thread_nr to n, making it 0. This results in a divide by zero when calculating num_per_thread. Handle n <= 1 early to use the single-thread fast path and prevent the crash. Fixes: 340b47f510bb ("perf top: Implement multithreading for perf_event__synthesize_threads") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit e0b01aedf85f8d3c56f48f866ce21cbebf2ac72d Author: Ian Rogers Date: Sun Aug 9 00:14:53 2026 -0700 perf python: Fix memory leak in pyrf__metrics_cb [ Upstream commit 1ec13016ba36f1bf7dc61e054068fe00f2f628c7 ] In pyrf__metrics_cb, PyDict_SetItem does not steal the reference of the key and value, so they need to be decref'ed after successful insertion to avoid memory leaks. Fixes: 47b3e95728eb ("perf python: Add metrics function") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 9eebbaf7a33bee156089d73cda82dd5cc6734845 Author: Ian Rogers Date: Sun Aug 9 00:14:47 2026 -0700 perf python: Validate CPU and thread maps in pyrf_evsel__open [ Upstream commit 9a142beb1eba42b986dc7016f4fc1a3bc28b8c09 ] Add explicit Py_TYPE checks to ensure the arguments passed are actually of the correct pyrf_thread_map and pyrf_cpu_map types. Fixes: 877108e42b1b ("perf tools: Initial python binding") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit ce4c4c03ef5bdc961a3af6a950f0716d00eed293 Author: Ian Rogers Date: Mon Jun 15 18:15:40 2026 -0700 perf python: Handle Py_None for thread and cpu maps [ Upstream commit 054d1c7717b95d9089cd3b80e9e85fe1f2ea0471 ] The python stubs allow passing None for threads and cpus to the perf.parse_events() and perf.parse_metrics() bindings. However, PyArg_ParseTuple parses None into a Py_None object, which is not a NULL pointer. Because the C code lacked an explicit check for Py_None, it would cast Py_None to a pyrf_thread_map/pyrf_cpu_map struct pointer and dereference it, causing a memory corruption crash. Fix this pre-existing issue by explicitly checking for Py_None alongside NULL in pyrf__parse_events, pyrf__parse_metrics, and pyrf_evsel__open. Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alice Rogers Cc: Dapeng Mi Cc: Ingo Molnar Cc: James Clark Cc: Leo Yan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Richter Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Stable-dep-of: 9a142beb1eba ("perf python: Validate CPU and thread maps in pyrf_evsel__open") Signed-off-by: Sasha Levin commit 2fef75555c0aa55381a7f78b84efc8c9cf1fb36c Author: Ian Rogers Date: Sun Aug 9 00:14:46 2026 -0700 perf python: Check counts_values size in set_values [ Upstream commit 612aca22a978d43f6e6765272676a17afdba8572 ] The set_values function incorrectly assumed the list contained exactly 5 elements. Add a check to prevent out-of-bounds access. Fixes: 877108e42b1b ("perf tools: Initial python binding") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit aba46bc65e083bfd93856198873b7633b690d053 Author: Ian Rogers Date: Sun Aug 9 00:14:45 2026 -0700 perf test: Fix skiplist leak in cmd_test [ Upstream commit 44e82c4d2ff37f073946b594840fd549ab6b9fb8 ] Fix a memory leak in cmd_test() where skiplist was not freed on exit paths. Assisted-by: Antigravity:gemini-3.1-pro Fixes: 2ae828786c65 ("perf test: Allow skipping tests") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 02ffce64f7ad6df19f99e9325eccc9cbe266ec9a Author: Ian Rogers Date: Tue Jun 2 10:41:16 2026 -0700 perf test: Support dynamic test suites with setup callback and private data [ Upstream commit 8c8d61c38d8e1755a4325f8acb396137bbd5371a ] Add void *priv to struct test_case to allow passing per-test context. Add int (*setup)(struct test_suite *) to struct test_suite to allow dynamic generation of test cases. Update build_suites() to invoke the setup callback for each suite if present, ensuring dynamic cases are available before listing or running. Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 44e82c4d2ff3 ("perf test: Fix skiplist leak in cmd_test") Signed-off-by: Sasha Levin commit 122c64347d9a429c6f188210d6b84660c5c0a154 Author: Ian Rogers Date: Sun Aug 9 00:14:44 2026 -0700 perf synthetic-events: Fix uninitialized pthread_join [ Upstream commit 54ba44db4dddc4ca06b49bae0f9d6c5861430b18 ] In perf_event__synthesize_threads(), fix an uninitialized pthread_join() call when thread creation fails by only joining the successfully created threads. Assisted-by: Antigravity:gemini-3.1-pro Fixes: 340b47f510bb ("perf top: Implement multithreading for perf_event__synthesize_threads") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit a9ee5e8eae20dbce4b87ae7181edd00cd0cff1f8 Author: Ian Rogers Date: Sun Aug 9 00:14:41 2026 -0700 perf stat: Fix evsel_list leak in cmd_stat [ Upstream commit 340641a4b5fff4f4b12261c9d92169f6e2ea11f4 ] Fix a memory leak in cmd_stat() where evsel_list is leaked if an error occurs while opening the output file. Assisted-by: Antigravity:gemini-3.1-pro Fixes: 361c99a661a7 ("perf evsel: Introduce perf_evlist") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b567e25ffda7bd31a042cab2aa322a141ffd380b Author: Rosen Penev Date: Wed Jul 8 17:50:05 2026 -0700 ARM: dts: helios4: add SATA regulator supplies [ Upstream commit 7a90520e8c9a8f48fe6f3e741cf34d8c2b6dbc61 ] The ahci-mvebu driver and libahci_platform request three supplies on SATA controller and port nodes: - ahci-supply (controller power) - phy-supply (PHY power) - target-supply (disk power per port) Without them the regulator core prints notices at boot, e.g.: supply ahci not found, using dummy regulator supply phy not found, using dummy regulator supply target not found, using dummy regulator The SATA controller and PHY inside the Armada 388 SoC are powered by the 3.3V I/O rail; the four disk bays are powered by the 5V HDD rail. Wire the existing fixed regulators accordingly. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 37dac96549d9142cf9f3b3cac0b48e2322fc3764 Author: Rosen Penev Date: Wed Jul 8 17:50:04 2026 -0700 ARM: dts: helios4: add vcc-supply to GPIO expander [ Upstream commit c23988f84496e937dd255564cb30bec67608dcc6 ] The pca953x driver requests a 'vcc' supply, producing: pca953x 0-0020: supply vcc not found, using dummy regulator The PCA9655 (PCA9555-compatible) expander is powered by the same always-on 3.3V rail as the other I2C devices on the bus. Add vcc-supply = <®_3p3v> to silence the warning. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 5934c1c8670701d501e2bc0f9c9eecbd6410ad81 Author: Rosen Penev Date: Wed Jul 8 17:50:03 2026 -0700 ARM: dts: helios4: add vcc-supply to EEPROM [ Upstream commit ef65cf08bd1aa723de2854d02fb8eb8cca273c90 ] The at24 driver requests a 'vcc' supply for the EEPROM, producing 'supply vcc not found, using dummy regulator' at boot when the property is missing. The EEPROM sits on the Helios 4 and is powered by the same always-on 3.3V rail used by other on-board I2C devices. Add vcc-supply = <®_3p3v> to silence the warning. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 19ebf0422fe916304220d33f701c5fd8ed7532da Author: Tomáš Macholda Date: Tue Jul 7 23:08:29 2026 +0200 arm64: dts: turris-mox: fix usb3 phys [ Upstream commit 0c2a8eed95160e41b367a1fa605a2c1b24a9639a ] After commit 00e6d608fe80b0f6 ("arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node") swapped USB3 PHY order, USB initialization breaks on Turris MOX. This regression was exposed by commit 91ddf6f722084383 ("phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register access") which made USB2 devices not work at all. Fix the issue by explicitly adding all USB3 PHYs and PHY names to Turris MOX device-tree. Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox") Signed-off-by: Tomáš Macholda Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit c2178137a789326a1424f2b10a20735c30fca7d9 Author: Tommaso Merciai Date: Fri Jul 31 09:01:46 2026 +0200 i3c: renesas: Don't register devices when ENTDAA times out [ Upstream commit b6e56fd8c8a8ac7992868a28702192372ab04015 ] renesas_i3c_daa() derives the number of newly assigned dynamic addresses from cmd->rx_count, which the response ISR sets to the number of address slots ENTDAA left unassigned. It starts out as zero, which already means "every address was assigned", so a timed out transfer leaves that value in place and it gets used as a result. On a bus with no target connected the ENTDAA times out and the driver registers RENESAS_I3C_MAX_DEVS devices that are not there, each costing the core two seconds on a GETPID that can only time out: i3c i3c-0: Failed to add I3C device at address 9, error -110 ... i3c i3c-0: Failed to add I3C device at address 16, error -110 Start from maxdevs instead: no address is assigned before ENTDAA runs, and the existing rx_count >= maxdevs check then reports an empty bus. Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Signed-off-by: Tommaso Merciai Reviewed-by: Claudiu Beznea Tested-by: Claudiu Beznea # on RZ/G3S Reviewed-by: Frank Li Link: https://patch.msgid.link/20260731070150.2519825-1-tommaso.merciai.xr@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 8ca083c0fe2c23e18c1425dafc1d80c039a041ab Author: Claudiu Beznea Date: Mon Jul 13 16:05:39 2026 +0300 i3c: renesas: Follow a unified pattern for transfer and command initialization [ Upstream commit 234a26e6febcf789d9f6779d67c01e3d0c1df5bc ] Follow a unified pattern for transfer and command initialization across the driver. This keeps the code cleaner and easier to follow. Also, in some cases the I3C device was enabled before the transfer data structure was even allocated. Reviewed-by: Frank Li Signed-off-by: Claudiu Beznea Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260713130545.568657-12-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni Stable-dep-of: b6e56fd8c8a8 ("i3c: renesas: Don't register devices when ENTDAA times out") Signed-off-by: Sasha Levin commit 4e2b33373a0f3a07c44610c351e0406538eebd7d Author: Claudiu Beznea Date: Mon Jul 13 16:05:38 2026 +0300 i3c: renesas: Return immediately if there is no transfer [ Upstream commit 33b5ecc5a16e270c8e0dd9835e7d9d2522f64129 ] There is no need to allocate a transfer structure when i2c_nxfers is zero. Return immediately instead of unnecessarily allocating memory. Signed-off-by: Claudiu Beznea Reviewed-by: Frank Li Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260713130545.568657-11-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni Stable-dep-of: b6e56fd8c8a8 ("i3c: renesas: Don't register devices when ENTDAA times out") Signed-off-by: Sasha Levin commit a052ad5edccf5319f50ed955de4368f8318a9f20 Author: Sanghyun Park Date: Wed Aug 5 12:14:25 2026 +0900 bpf: Fix mmap_lock leak in irq_work path [ Upstream commit fa9dcacdcdf487f0ffef64bf67622f1caed509f1 ] stack_map_get_build_id_offset() introduced a per-CPU irq_work to defer mmap_read_unlock() from NMI context, and bpf_find_vma() later reused the same mmap_unlock_work. Both callers only check whether the work is busy before taking mmap_lock, so a nested caller can reuse the slot before the first caller queues it. Two read locks may then be acquired while only one deferred unlock runs, leaking a read lock and blocking exit_mmap(). Reserve the per-CPU slot before mmap_read_trylock(). Use the same wrapper in stackmap and bpf_find_vma() so both callers release the reservation on trylock failure. Keep rejecting the slot while the irq_work remains busy. Release it after the irq_work callback unlocks the mm. Fixes: eac9153f2b58 ("bpf/stackmap: Fix deadlock with rq_lock in bpf_get_stack()") Reported-by: syzbot+cdd6c0925e12b0af60cc@syzkaller.appspotmail.com Reported-by: sashiko-bot@kernel.org Signed-off-by: Sanghyun Park Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Closes: https://syzkaller.appspot.com/bug?extid=cdd6c0925e12b0af60cc Closes: https://lore.kernel.org/r/20260630033745.B80201F000E9@smtp.kernel.org Link: https://lore.kernel.org/bpf/20260805031425.2157475-2-sanghyun.park.cnu@gmail.com Signed-off-by: Sasha Levin commit cc1c1c70d203ac902b7ed7b519cb3a9dc269272b Author: Ihor Solodrai Date: Mon May 25 15:39:47 2026 -0700 bpf: Avoid faultable build ID reads under mm locks [ Upstream commit fad3021faf7b0b64e9daea41c5662b65c8ad7379 ] Sleepable build ID parsing can block in __kernel_read() [1], so the stackmap sleepable path must not call it while holding mmap_lock or a per-VMA read lock. The issue and the fix are conceptually similar to a recent procfs patch [2]. A similar VMA locking pattern has already been used in PROCMAP_QUERY [3]. Resolve each covered VMA with a stable read-side reference, preferring lock_vma_under_rcu() and falling back to mmap_read_trylock() only long enough to acquire the VMA read lock. Take a reference to the backing file, drop the VMA lock, and then parse the build ID through (sleepable) build_id_parse_file(). We have to use mmap_read_trylock() (and give up on failure) in this context because taking mmap_read_lock() is generally unsafe on code paths reachable from BPF programs [4], and may lead to deadlocks. [1] https://lore.kernel.org/all/20251218005818.614819-1-shakeel.butt@linux.dev/ [2] https://lore.kernel.org/all/20260128183232.2854138-1-andrii@kernel.org/ [3] https://lore.kernel.org/all/20250808152850.2580887-1-surenb@google.com/ [4] https://lore.kernel.org/bpf/2895ecd8-df1e-4cc0-b9f9-aef893dc2360@linux.dev/ Fixes: d4dd9775ec24 ("bpf: wire up sleepable bpf_get_stack() and bpf_get_task_stack() helpers") Suggested-by: Puranjay Mohan Signed-off-by: Ihor Solodrai Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260525223948.1920986-3-ihor.solodrai@linux.dev Stable-dep-of: fa9dcacdcdf4 ("bpf: Fix mmap_lock leak in irq_work path") Signed-off-by: Sasha Levin commit b25ce833d8f12f87de243b23c37067e290007bba Author: Ihor Solodrai Date: Mon May 25 15:39:46 2026 -0700 bpf: Factor out stack_map build ID helpers [ Upstream commit fc99547a8bda22a6a489284641385d8dcfb3ecd8 ] Factor out helpers from stack_map_get_build_id_offset() in preparation for adding a sleepable build ID resolution path: stack_map_build_id_set_ip(), stack_map_build_id_offset(), and stack_map_build_id_set_valid(). While here, refactor stack_map_get_build_id_offset(): * use continue-driven control flow in the main loop and remove build_id_valid label * update prev_vma and prev_build_id on the fall-back-to-IP branch so the cache reflects the actual VMA seen on the previous IP [1] * guard fetch_build_id() with vma_is_anonymous() [2] to skip parse attempts that would otherwise fail the ELF magic check [1] https://lore.kernel.org/bpf/CAEf4Bzac9uWWqBvzH0iFzKvJcq3vxscZ3pKm0sUHmN-F-z9wVQ@mail.gmail.com/ [2] https://lore.kernel.org/bpf/226398c1ff3f2b686c0aeb010408d85fb15df13f9ff60a045bee31e79b9e41e9@mail.kernel.org/ Signed-off-by: Ihor Solodrai Signed-off-by: Andrii Nakryiko Acked-by: Mykyta Yatsenko Link: https://lore.kernel.org/bpf/20260525223948.1920986-2-ihor.solodrai@linux.dev Stable-dep-of: fa9dcacdcdf4 ("bpf: Fix mmap_lock leak in irq_work path") Signed-off-by: Sasha Levin commit c1d79bb9c4662d5b57900b03e5a8df6e1cb64e02 Author: Guodong Xu Date: Fri Aug 7 19:24:33 2026 -0600 riscv: cpufeature: Clarify ISA spec version for canonical order [ Upstream commit fdef048705daa3d4ed1fa212ee071bcbdac02d80 ] Specify that chapter 27 refers to version 20191213 of the RISC-V ISA Unprivileged Architecture. The chapter numbering differs across specification versions - for example, in version 20250508, the ISA Extension Naming Conventions is chapter 36, not chapter 27. Historical versions of the RISC-V specification can be found via Link [1]. Acked-by: Conor Dooley Link: https://riscv.org/specifications/ratified/ [1] Fixes: 99e2266f2460 ("RISC-V: clarify ISA string ordering rules in cpu.c") Signed-off-by: Guodong Xu Link: https://patch.msgid.link/20260125-supm-ext-id-v2-3-1e3b9714c860@riscstar.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit bbe2fd6d77df630356185406a97317f6aa6a92cf Author: Victor Nogueira Date: Wed Aug 5 10:40:49 2026 -0300 net/sched: cls_api: fix teardown of an adopted proto on insert-race loss [ Upstream commit d4e359b3608a0e184bbe8d61a5c3b50d0831c44a ] In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com Fixes: 8b64678e0af8 ("net: sched: refactor tp insert/delete for concurrent execution") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com Acked-by: Jamal Hadi Salim Signed-off-by: Victor Nogueira Reported-by: TencentOS Corvus AI Tested-by: Aohan Mei Link: https://patch.msgid.link/20260805134049.927864-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 457ee7219c9ee2d3f495a3f06d01841205955fe5 Author: Nikhil Gautam Date: Wed Jul 22 21:52:46 2026 +0530 iio: light: gp2ap002: re-enable irq if runtime suspend fails [ Upstream commit 5d89e7cbac40057f5241a0832a86ce0fe97e4818 ] gp2ap002_runtime_suspend() disables the irq before writing OPMOD. If the write fails, the callback returns an error with the irq still disabled while the PM core marks the device active again. re-enable the irq before returning the error so the irq state matches the active state the PM core restores. Fixes: 97d642e23037c ("iio: light: Add a driver for Sharp GP2AP002x00F") Signed-off-by: Nikhil Gautam Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 0fc740c25c9abb25113398ebb58e2f2ce57741a7 Author: Nikhil Gautam Date: Wed Jul 22 21:52:45 2026 +0530 iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes [ Upstream commit 579c049b4cb6fc72ce2c505fc5334540be0efcd3 ] The IIO core does not filter duplicate writes to the event enable attribute, so writing the same value twice invokes write_event_config() twice. Enabling twice leaks a runtime PM reference, preventing the device from ever suspending again; disabling twice underflows the usage count and triggers a "Runtime PM usage count underflow" warning. Bail out early when the requested state matches the current state. While at it, switch to pm_runtime_resume_and_get() so a failed resume is propagated to userspace instead of silently marking the event enabled. Fixes: 97d642e23037c ("iio: light: Add a driver for Sharp GP2AP002x00F") Signed-off-by: Nikhil Gautam Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 1ab7ef7ccfb86a9206c9022c42a09623661a9684 Author: Vidhu Sarwal Date: Wed Jul 15 06:45:43 2026 +0530 iio: light: opt4060: Fix pointer type passed to div_u64_rem() [ Upstream commit 0ba0ed0d42ebd3144f0050c48374817f5f3f07d6 ] div_u64_rem() expects a u32 * for the remainder, but opt4060_read_ev_period() passes val2, which is declared as an int *. While this has no functional impact, it triggers a pointer type mismatch. There is no behavioural change because int and u32 have the same size and representation on all supported architectures, and the remainder is always less than MICRO, so it fits within the positive range of int. Use a local u32 to receive the remainder before assigning it to *val2. Fixes: 0c6db4506ad0 ("iio: light: Add support for TI OPT4060 color sensor") Signed-off-by: Vidhu Sarwal Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 1ab3da12061d7ccb099f7e925fa2d865967a316a Author: Pu Lehui Date: Fri Aug 7 10:44:03 2026 +0000 bpf, cgroup: Fix storage null-ptr-deref after replacing prog [ Upstream commit 3f562c537e9ecf4bc5e206cfffc2cc047f1b7e94 ] Syzkaller reported a storage null-ptr-deref issue after replacing prog. This occurs in the following scenario: 1. prog A, an empty prog, is attached to a cgrp. 2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the bpf_get_local_storage helper. 3. link_update is called to replace prog A with prog B. The reason is that __cgroup_bpf_replace fails to alloc and assign the required cgrp storage for the incoming replacement prog. Consequently, the new prog inherits an uninit storage, leading to null-ptr-deref panic when kick the new prog. Fix this by rejecting a link update if new_prog's cgroup storage is incompatible with link->prog. Fixes: 0c991ebc8c69 ("bpf: Implement bpf_prog replacement for an active bpf_cgroup_link") Signed-off-by: Pu Lehui Signed-off-by: Andrii Nakryiko Reviewed-by: Amery Hung Acked-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260728132336.2857800-1-pulehui@huaweicloud.com [0] Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweicloud.com [1] Link: https://lore.kernel.org/bpf/20260807104403.1013064-1-pulehui@huaweicloud.com Signed-off-by: Sasha Levin commit 7c2658023d839b651368a5b8b781bf9a817647cb Author: Ali Ahmet Memis Date: Fri Aug 7 01:25:54 2026 +0000 Bluetooth: MSFT: validate evt_prefix_len against the response length [ Upstream commit 0079e1a944634ab2dc1c7cdec1144486d096407e ] read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: if (skb->len < sizeof(*rp)) { bt_dev_err(hdev, "MSFT supported features length mismatch"); goto failed; } evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so msft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes ("skb->len=11 evt_prefix_len=255", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with "MSFT event prefix length mismatch" and msft->evt_prefix is left unset. Fixes: 145373cb1b1f ("Bluetooth: Add framework for Microsoft vendor extension") Signed-off-by: Ali Ahmet Memis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7efd7fb4c9c77bc9837a539fd7860f37714be441 Author: Guangshuo Li Date: Fri Aug 7 23:14:47 2026 +0800 Bluetooth: btmtksdio: fix usage_count leak when autosuspend_delay is negative [ Upstream commit b0c0b37940115383e7ea65d4d988f9b9e613ab92 ] btmtksdio_setup() calls pm_runtime_use_autosuspend() when runtime PM is supported, but btmtksdio_remove() does not call the matching pm_runtime_dont_use_autosuspend() when removing the device. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during driver teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call in the remove path before restoring the runtime PM usage reference. This issue was found by manual code inspection. Fixes: 7f3c563c575e ("Bluetooth: btmtksdio: Add runtime PM support to SDIO based Bluetooth") Signed-off-by: Guangshuo Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e1fc9c5878f03e1bc91271addee3141ab31bdc71 Author: Sean Wang Date: Tue Feb 24 00:13:25 2026 -0600 Bluetooth: btmtk: add MT7902 SDIO support [ Upstream commit 7f2c3c49ba0d3fead557a8026a021ebe23f919d6 ] Add MT7902 Bluetooth SDIO support by introducing chip data and registering the device ID. Runtime PM is not yet supported by the driver, but normal operation is unaffected. Signed-off-by: Sean Wang Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: b0c0b3794011 ("Bluetooth: btmtksdio: fix usage_count leak when autosuspend_delay is negative") Signed-off-by: Sasha Levin commit 534d3efd59b3cccc7ab0f91f691b5b6c1ca7bde2 Author: Sean Wang Date: Tue Feb 24 00:13:19 2026 -0600 Bluetooth: btmtk: add MT7902 MCU support [ Upstream commit aab25984e55972e53f3e58821cb85a7101876056 ] Add MT7902 device ID and firmware filename to enable MCU firmware loading. Signed-off-by: Sean Wang Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: b0c0b3794011 ("Bluetooth: btmtksdio: fix usage_count leak when autosuspend_delay is negative") Signed-off-by: Sasha Levin commit c00556fbe75eb586f21782b4cc09abace2fec955 Author: Sean Wang Date: Tue Feb 24 00:13:18 2026 -0600 mmc: sdio: add MediaTek MT7902 SDIO device ID [ Upstream commit cde32a92d4562b686f730fc08d4d558ecc99d516 ] Add SDIO device ID (0x790a) for MediaTek MT7902 to sdio_ids.h. Acked-by: Ulf Hansson Signed-off-by: Sean Wang Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: b0c0b3794011 ("Bluetooth: btmtksdio: fix usage_count leak when autosuspend_delay is negative") Signed-off-by: Sasha Levin commit e0cd7b34dc6b5414cac3d4cd376f73d3e9ffbd93 Author: Linmao Li Date: Thu Aug 6 20:59:57 2026 +0800 Bluetooth: MGMT: free the HCI command when it is cancelled [ Upstream commit 414b365ecea6c30357adee6b8a7c5edc03a03575 ] mgmt_hci_cmd_sync() queues the pending command with a NULL destroy callback, so it is only freed if send_hci_cmd_sync() runs. A cancelled entry is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Nothing else reclaims it either: mgmt_pending_new() does not put the command on hdev->mgmt_pending. The leak also pins the socket reference taken by mgmt_pending_new(), so the mgmt socket is never released. Free the command from a destroy callback. The now-empty done label is replaced by a direct return. Fixes: 827af4787e74 ("Bluetooth: MGMT: Add initial implementation of MGMT_OP_HCI_CMD_SYNC") Signed-off-by: Linmao Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 05438d338a875a9daa08ca3f6a35b4480cf13de4 Author: Linmao Li Date: Thu Aug 6 20:59:56 2026 +0800 Bluetooth: MGMT: free the mesh send cancel command when it is cancelled [ Upstream commit 3c742feda8fcabf741a17bcf668b63c8f606f9c5 ] mesh_send_cancel() queues the pending command with a NULL destroy callback, so it is only freed if send_cancel() runs. A cancelled entry is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Nothing else reclaims it either: mgmt_pending_new() does not put the command on hdev->mgmt_pending. The leak also pins the socket reference taken by mgmt_pending_new(), so the mgmt socket is never released. Free the command from a destroy callback. Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh") Signed-off-by: Linmao Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 9c3b6c1413bd0b4993642d987616331f84d9b7f5 Author: Linmao Li Date: Thu Aug 6 20:59:55 2026 +0800 Bluetooth: hci_sync: free the advertising instance on the failure and cancel paths [ Upstream commit 120d8dc042e3d45073bb6e50ee7b058a0b182627 ] adv_timeout_expire() hands a kmalloc()ed instance byte to hci_cmd_sync_queue() with a NULL destroy callback, and only adv_timeout_expire_sync() frees it. That leaks on two paths: - the return value is not checked, and hci_cmd_sync_queue() does not take ownership when it fails (-ENETDOWN, -ENODEV, -ENOMEM); - a cancelled entry is not released, as _hci_cmd_sync_cancel_entry() does not free entry->data when there is no destroy callback. hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Free the buffer from a destroy callback, and in the caller when the entry could not be queued at all. Fixes: c249ea9b4309 ("Bluetooth: Move Adv Instance timer to hci_sync") Signed-off-by: Linmao Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c1fe3c74a89a7749cba3caa0dd91236049c66116 Author: Linmao Li Date: Thu Aug 6 20:59:54 2026 +0800 Bluetooth: hci_conn: fix the SCO setup context lifetime [ Upstream commit 42de40abe25db9211107af8896d0fd741f10648d ] hci_setup_sync() queues a conn_handle_t with a NULL destroy callback, so the context is only freed if hci_enhanced_setup_sync() actually runs. An entry that is cancelled instead is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. The context also stores a bare hci_conn pointer, so the connection can be freed while the work is queued. The dequeue in hci_conn_del() does not cover it either, as it matches on entry->data == conn and entry->data is the wrapper here. Same problem as commit 2f5d635ad590 ("Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks"). Hold the connection and release both from a destroy callback. The submission failure path drops both, since hci_cmd_sync_submit() does not call the destroy callback when it fails to queue. Fixes: e07a06b4eb41 ("Bluetooth: Convert SCO configure_datapath to hci_sync") Signed-off-by: Linmao Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 2f907608cbcfc02eab5bca2d1700ce6a67d55ac6 Author: Zijun Hu Date: Sat Aug 1 23:31:36 2026 -0700 Bluetooth: btintel: Fix diagnostics event detection [ Upstream commit ad0e7ac7da9a9a0095570bd6add3e27f259de104 ] For a diagnostics VSE, diagnostics_hdr[] sits at the start of the event payload, skb->data[2], but btintel_recv_event() wrongly guards its memcmp with @len, which is measured from skb->data[3] for the earlier INTEL_BOOTLOADER check. Fix by using (@len + 1) instead, which == (skb->len - HCI_EVENT_HDR_SIZE) exactly. Fixes: af395330abed ("Bluetooth: btintel: Add Intel devcoredump support") Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit be1e3df2c49c91b0a052c6563884e8d39bd768b2 Author: HyeongJun An Date: Thu Jul 30 10:57:28 2026 +0900 Bluetooth: virtio_bt: avoid OOB read of build info string [ Upstream commit 502adc06ba76dee19c292ae4a07d74d202fe734d ] The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read Build Information) and hands the response to bt_dev_info() and hci_set_fw_info() as a "%s" string starting at skb->data + 1, without checking the length. A backend that answers with status only leaves that pointer past the end of the received data, so the walk reads adjacent slab memory until it meets a NUL. Those bytes reach the kernel log and the firmware-info debugfs file. To fix this, print the string with a bounded "%.*s" limited to skb->len - 1. A short or unterminated response then prints as much as arrived instead of failing setup. This mirrors commit dd068ef04412 ("Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()"), which fixed the identical pattern. Fixes: afd2daa26c7a ("Bluetooth: Add support for virtio transport driver") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 244d0299008144e5c8f0c52cd23f85e4876ad993 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:59 2026 +0300 pinctrl: airoha: fix edge-triggered interrupts handling [ Upstream commit 3de4686cdf0ccf6d78ca96ccaea621cbcf69fc3a ] Edge-triggered interrupts are handled incorrectly because of * no irq_ack() handler was defined, * no handle_level_irq() handler was used, This patch probably fixes an issue Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Acked-by: Lorenzo Bianconi Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c7596135e7e9a77db9b34e61e24c7ac4562f88a3 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:58 2026 +0300 pinctrl: airoha: fix IRQ mask/unmask code [ Upstream commit 20b996280640f492ebdd41c2d2c991801df75e61 ] When using IRQCHIP_IMMUTABLE, airoha_irq_unmask() must manually call gpiochip_enable_irq() and airoha_irq_mask() must call gpiochip_disable_irq(). Without these calls, gpiolib never sets the GPIOD_FLAG_IRQ_IS_ENABLED bit. Because this bit is missing, gpiod_direction_output() will not realize the pin is actively used as an interrupt. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Acked-by: Lorenzo Bianconi Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fda7350f257e59eee1bc7537c202e36bd56aea97 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:57 2026 +0300 pinctrl: airoha: add missed IRQ resource helpers [ Upstream commit a02fa031b9520e46e98bff17e12b472eba770670 ] Without hooking .irq_request_resources, gpiolib cannot set GPIOD_FLAG_USED_AS_IRQ. This breaks pin direction locking and can allow userspace or another driver to reconfigure an active IRQ pin as an output Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Acked-by: Lorenzo Bianconi Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 9ea692247ee2485e2fdd325bbe40d08fd0606a22 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:56 2026 +0300 pinctrl: airoha: fix getting gpiochip/pinctrl pointers in the IRQ handling code [ Upstream commit b8dd30554847bde27e8a4584dd447c1c3ac585ce ] airoha_irq_unmask(), airoha_irq_mask(), airoha_irq_type() functions impements brain damaged logic to retrieve gpiochip and pinctrl pointers. Details: gpiochip = irq_data_get_irq_chip_data(data); will initialize gpiochip variable with data->chip_data value. This value initialized inside gpiochip_irq_map() function static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq, irq_hw_number_t hwirq) { struct gpio_chip *gc = d->host_data; ... irq_set_chip_data(irq, gc); ... } Thus gpiochip variable of 'struct airoha_pinctrl_gpiochip *' type will be initialized with a pointer to a variable of 'struct gpio_chip' type. Luckily, gpio_chip is the first element of airoha_pinctrl_gpiochip, so gpiochip pointer will get a correct value. This patch implements correct logic of getting gpiochip and pinctrl pointers. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f3b8fe04dbfe3e9aaa00bd1febf2a6a1d600b79a Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:53 2026 +0300 pinctrl: airoha: add missed get_direction() function for gpio_chip [ Upstream commit d6392502a9e6b11c3a93eb4c987672a8c638d749 ] This patch adds missed get_direction() function for gpio_chip. Also it reimplements pinconf's get_direction() function using newly defined function. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 7d2b3f8a996d1c3dceb95a10e766769f2951b92e Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:52 2026 +0300 pinctrl: airoha: an7583: fix spi group pins [ Upstream commit ccc41d25590645096bdbf420b43e7c22627b3f59 ] pcm pins were used insted of spi pins. This patch fixes an issue. Thanks to Daniel Schwierzeck for noticing it. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 38a2a4d6c7ac7d183a91f8d95a483884269b8059 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:47 2026 +0300 pinctrl: airoha: an7583: fix muxing of non-gpio default pins [ Upstream commit aaa41d8010c04635e035a9d334885b07edc8af21 ] Current an7583 pinmux implementation have following issues: * pins 51 and 52 can't be set as pcie_reset, current pcie_reset code will sets pins to gpio mode instead. * there is no proper way to set pins 41--54 to gpio mode. * pins 41--53 can't be actually set as pwm pins. These pins must be muxed to gpio mode as well. This patch fixes above issues. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2313f262999c72fbc940b3db9fa7e500ff9f7b96 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:45 2026 +0300 pinctrl: airoha: an7581: fix mux/conf of pcie_reset pins [ Upstream commit 739bc85aed14b739dca5b7aff4241b778af80220 ] In the an7581 case * gpio47 and pcie_reset0 shares pin 60, * gpio48 and pcie_reset1 shares pin 61, * gpio49 and pcie_reset2 shares pin 62. but current driver treat them as pins 61--63. This is wrong. Also current an7581 pinmux implementation have following issues: * current pcie_reset pin function actually sets corresponding pins as gpios. * there is no proper way to set pcie_reset pins as gpios. * there is no way to set pcie_reset pins as pwm. This patch fixes above issues. WARNING: There is a contradiction in the Airoha documentation. AN7581 programming guide claims: - gpio44 and pcie_reset0 shares the same pin - gpio45 and pcie_reset1 shares the same pin - gpio46 and pcie_reset2 shares the same pin While AN7581 datasheet claims: - gpio47 and pcie_reset0 shares the same pin - gpio48 and pcie_reset1 shares the same pin - gpio49 and pcie_reset2 shares the same pin The datasheet should be considered as a more reliable source. Thanks to Benjamin Larsson for clarification. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2ad214708259220add587f5a0bd3d7823fc3ed81 Author: Mikhail Kshevetskiy Date: Sat Jun 6 05:03:38 2026 +0300 pinctrl: airoha: fix pwm pin function for an7581 and an7583 [ Upstream commit 08a5af468e613b6d8cd9725d284c9e6be288d364 ] AN7581 have 47 valid GPIOs only (gpio0-gpio46), so gpio47 is a fiction. AN7583 have 49 valid GPIOs (gpio0-gpio48), so gpio48 is missed To fix an issue * create AN7583 specific pwm pin function, * remove gpio47 from AN7581 pwm pin function. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Stable-dep-of: 739bc85aed14 ("pinctrl: airoha: an7581: fix mux/conf of pcie_reset pins") Signed-off-by: Sasha Levin commit cfe4350fdcb53a31cb91faef26af200c6b8e18c7 Author: Christian Marangi Date: Fri Nov 7 00:57:06 2025 +0100 pinctrl: airoha: convert PWM GPIO to macro [ Upstream commit 1552ad5d649cff9d170e5bc1d13ab1487333b4b7 ] The PWM GPIO struct definition follow the same pattern for every GPIO pin hence it can be converted to a macro. Create 2 macro one for normal mux and one for ext mux and convert all the entry to these new macro to reduce code size. Signed-off-by: Christian Marangi Signed-off-by: Linus Walleij Stable-dep-of: 739bc85aed14 ("pinctrl: airoha: an7581: fix mux/conf of pcie_reset pins") Signed-off-by: Sasha Levin commit fa27ddca660225863b3c301ad9f52b082af5bba6 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:43 2026 +0300 pinctrl: airoha: an7583: fix I2C0_SDA_PD register bit order [ Upstream commit d560e28bdca824781898023496658404df01be9f ] I2C1_SCL_PD and RG_I2C1_SDA_PD bits are swapped, fix it. Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit cbde1169bdd2cfda7b53f31bb0f6a32839c4d04e Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:42 2026 +0300 pinctrl: airoha: an7581: fix pinconf of i2c_scl/i2c_sda pins [ Upstream commit 65ce9d5d781f872596194771d62ad6e1260fcf4f ] Pinconfs of i2c_sda/i2c_scl pins are swapped, this needs to be fixed. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 75ceddfa7df7ef1cee3f8d2b2095eb3b5f61a501 Author: Mikhail Kshevetskiy Date: Fri Aug 7 01:05:41 2026 +0300 pinctrl: airoha: fix mdio bitfield names [ Upstream commit a8454680a6ce75fbbd8086bcb654eacf7897bc0f ] Fix misprint in mdio bitfield name of GPIO_2ND_I2C_MODE register. While at it also fix an7583 mdio. It should use an7583 specific mdio bitfield. Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC") Signed-off-by: Mikhail Kshevetskiy Acked-by: Lorenzo Bianconi Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 4bf51df55d7bdbd5f6a694a54fc0a82e41df483a Author: Christian Marangi Date: Fri Nov 7 00:57:08 2025 +0100 pinctrl: airoha: add support for Airoha AN7583 PINs [ Upstream commit 3ffeb17a9a27a668efb6fbd074835e187910a9bb ] Add all the required entry to add suppot for Airoha AN7583 PINs. Where possible the same function group are used from Airoha EN7581 to reduce code duplication. Signed-off-by: Christian Marangi Signed-off-by: Linus Walleij Stable-dep-of: a8454680a6ce ("pinctrl: airoha: fix mdio bitfield names") Signed-off-by: Sasha Levin commit 74c2c5b459b42e23e8b06e5685efb6a4ab39bea1 Author: Christian Marangi Date: Fri Nov 7 00:57:05 2025 +0100 pinctrl: airoha: convert PHY LED GPIO to macro [ Upstream commit 579839c9548cf2a85e873ad787bc2fa6610bf8ab ] PHY LED GPIO pinctrl struct definition is very similar across the different 4 PHY and 2 LED and it can be generelized to a macro. To reduce code size, convert them to a common macro. Signed-off-by: Christian Marangi Signed-off-by: Linus Walleij Stable-dep-of: a8454680a6ce ("pinctrl: airoha: fix mdio bitfield names") Signed-off-by: Sasha Levin commit e6edde29990af8064b9d12217ec03db231ccd55d Author: Qu Wenruo Date: Tue Jul 28 12:09:26 2026 +0930 btrfs: qgroup: fix a wrong length calculation in qgroup_free_reserved_data() [ Upstream commit 9102b179512e11644fb0489ae62010a09afa199c ] In that function, we round down the start position and round up the ending position. But during the calculation of @len, we use "round_up(start + len, sectorsize)", which is the rounded up end position, not the rounded up length. Which results a much larger length, and later we are still using "start + len", which is completely incorrect. Fix it by declaring a local @aligned_start and @aligned_len and use them instead. Fixes: bc42bda22345 ("btrfs: qgroup: Fix qgroup reserved space underflow by only freeing reserved ranges") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit b0059242735ea6bd893a40ae3856af293e6bdcb2 Author: Leo Martins Date: Thu Mar 19 16:49:08 2026 -0700 btrfs: avoid GFP_ATOMIC allocations in qgroup free paths [ Upstream commit e0a85137a882db789b1bccc1e7db06356ac8c69f ] When qgroups are enabled, __btrfs_qgroup_release_data() and qgroup_free_reserved_data() pass an extent_changeset to btrfs_clear_record_extent_bits() to track how many bytes had their EXTENT_QGROUP_RESERVED bits cleared. Inside the extent IO tree spinlock, add_extent_changeset() calls ulist_add() with GFP_ATOMIC to record each changed range. If this allocation fails, it hits a BUG_ON and panics the kernel. However, both of these callers only read changeset.bytes_changed afterwards — the range_changed ulist is populated and immediately freed without ever being iterated. The GFP_ATOMIC allocation is entirely unnecessary for these paths. Introduce extent_changeset_init_bytes_only() which uses a sentinel value (EXTENT_CHANGESET_BYTES_ONLY) on the ulist's prealloc field to signal that only bytes_changed should be tracked. add_extent_changeset() checks for this sentinel and returns early after updating bytes_changed, skipping the ulist_add() call entirely. This eliminates the GFP_ATOMIC allocation and makes the BUG_ON unreachable for these paths. Callers that need range tracking (qgroup_reserve_data, qgroup_unreserve_range, btrfs_qgroup_check_reserved_leak) continue to use extent_changeset_init() and are unaffected. Reviewed-by: Qu Wenruo Signed-off-by: Leo Martins Signed-off-by: David Sterba Stable-dep-of: 9102b179512e ("btrfs: qgroup: fix a wrong length calculation in qgroup_free_reserved_data()") Signed-off-by: Sasha Levin commit f44616db1dbcec56a23d93af1ecca9173eef8c5f Author: Qu Wenruo Date: Tue Jul 28 19:34:09 2026 +0930 btrfs: use aligned range for locking in extent_fiemap() [ Upstream commit 681e073614515b892cacef0eeec0c761a2c2ab87 ] The @end parameter for all extent io tree helpers is inclusive, but the call site in extent_fiemap() is passing an exclusive end into btrfs_lock_extent(), which will step into the next block unexpectedly. Pass the inclusive end into btrfs_lock_extent() and btrfs_unlock_extent(). Fixes: ac3c0d36a2a2 ("btrfs: make fiemap more efficient and accurate reporting extent sharedness") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 92484ad014f2e2b0e0e7bbc1610951e978cf557c Author: Johannes Thumshirn Date: Thu Jul 23 17:54:28 2026 +0200 btrfs: zoned: don't clobber the extent buffer when zeroing it out [ Upstream commit db4b9eefc8ee0bcaeee4d5e6a7313905f6a2fe7c ] On a zoned filesystem a freed-but-still-dirty tree block is written out as zeros (EXTENT_BUFFER_ZONED_ZEROOUT) only to keep the zone write pointer advancing. btree_csum_one_bio() implemented this by memzeroing the extent buffer's own folios before submission. That destroys the in-memory buffer while it may still be referenced. In particular btrfs_free_tree_block() can run on it afterwards and reads the header to add a delayed reference; once the header has been zeroed it frees bytenr 0 and corrupts the extent tree (the btrfs_header_bytenr(buf) != 0 ASSERT in btrfs_free_tree_block(), or an "unable to find ref" abort). It is flaky and reproduces under fsstress, e.g. generic/461 and generic/013. Write the zeros to disk from the shared zero page instead and leave the extent buffer content untouched, so any later reference - including the delayed reference from btrfs_free_tree_block() - still sees a valid header. end_bbio_meta_write() now clears writeback on the buffer's own folios, as the bio no longer carries them. Fixes: aa6313e6ff2b ("btrfs: zoned: don't clear dirty flag of extent buffer") Assisted-by: LLM (debugging, commit message) Reviewed-by: Boris Burkov Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 12b6d1a1715cbced2e445ca353f9c9987b8636e2 Author: Yichong Chen Date: Wed Jul 22 10:54:35 2026 +0800 btrfs: retry verity reads for not-uptodate Merkle folios [ Upstream commit 8cc569696dac51fc62bb39b3b8f530582b916d29 ] btrfs_read_merkle_tree_page() can find a folio in the mapping that is not uptodate. After taking the folio lock, the current code treats that state as a read error and returns -EIO. That can make a previous transient read failure sticky. If the failed read left a not-uptodate folio in the mapping, later callers find that folio and fail instead of retrying the read. Keep the existing page-cache insertion and locking order, but retry the Merkle item read when a not-uptodate folio is found in the mapping. Also unlock the folio when read_key_bytes() fails so that a later caller can lock it and retry the read. Fixes: 06ed09351b67 ("btrfs: convert btrfs_read_merkle_tree_page() to use a folio") Reviewed-by: Boris Burkov Signed-off-by: Yichong Chen Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 58ce50b1802a446d3b26df1b9c58be1ab8913d0e Author: Qu Wenruo Date: Sat Jun 27 09:02:21 2026 +0930 btrfs: always wait for ordered extents to avoid OE races [ Upstream commit ec78575dde998c21be7e0cb2503b5620f34b6255 ] [BUG] Syzbot reported a bug that there can be conflicting OEs for the same range: BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object alrea[ 179.162726][ T6897] BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object already exists) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ordered-data.c:264! Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026 RIP: 0010:btrfs_alloc_ordered_extent+0x943/0xad0 Call Trace: cow_file_range+0x744/0x12a0 fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20 writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560 filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30 btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990 __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f ---[ end trace 0000000000000000 ]--- [CAUSE] Since commit ff66fe666233 ("btrfs: fix incorrect buffered IO fallback for append direct writes"), if the direct IO finished short, we will revert the isize back to the original one, so that append writes can be respected during the buffered fallback. Normally we rely on lock_and_cleanup_extent_if_need() function during buffered writeback to wait for any existing ordered extents. But that ordered extent waiting only happens if the start_pos is inside the isize. Since we have reverted the isize during failed direct IO, we will not wait for any ordered extents. This means we can have a race where the direct IO OE is still in the tree, finished but not yet removed, then we're inserting the OE for the buffered write, causing the above crash. [FIX] Make the OE wait to be unconditional, to handle the reverted isize situation. And since lock_and_cleanup_extent_if_need() now either lock the extents or return -EAGAIN, also remove the branches that handles no-extent-locked cases, and rename it to remove the "_if_need" suffix. The following micro benchmark shows the runtime difference for btrfs_buffered_write(), doing `xfs_io -f -c "pwrite 0 1m"` workload, all values are the average runtime in nano seconds. function runtime | before | after -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need() | 58.2 | 183.0 btrfs_buffered_write() | 2115.6 | 2973.3 The overall runtime of btrfs_buffered_write() is still pretty tiny (still less than 3 micro seconds), I'd say the extra cost is still acceptable. An alternative to fix this problem is to wait ordered extents during iomap_end() where the isize revert is done. But that solution will break nowait requirement, as if a nowait direct IO finished short, we have to wait for the OEs unconditionally or the next append buffered IO can still hit the same problem. So here we have to move the wait cost to buffered write, but at least the code is slightly more streamline. Reported-by: syzbot+ba2afde329fc27e3f22e@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=ba2afde329fc27e3f22e Fixes: ff66fe666233 ("btrfs: fix incorrect buffered IO fallback for append direct writes") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 76b7c505c74f4e5e77b39fc387d3306b58076de8 Author: David Sterba Date: Tue Dec 9 20:06:49 2025 +0100 btrfs: merge setting ret and return ret [ Upstream commit 4b117be65ff41efae3694df449b9badb4e9d142e ] In many places we have pattern: ret = ...; return ret; This can be simplified to a direct return, removing 'ret' if not otherwise needed. The places in self tests are not converted so we can add more test cases without changing surrounding code (extent-map-tests.c:test_case_4()). Signed-off-by: David Sterba Stable-dep-of: ec78575dde99 ("btrfs: always wait for ordered extents to avoid OE races") Signed-off-by: Sasha Levin commit 8a34b30bd1bfc2870fff1904a685888847a8b56e Author: Qu Wenruo Date: Tue Nov 11 09:11:59 2025 +1030 btrfs: make btrfs_repair_io_failure() handle bs > ps cases without large folios [ Upstream commit 2574e9011018a1d6d3da8d03d0bfc4e2675dee2a ] Currently btrfs_repair_io_failure() only accept a single @paddr parameter, and for bs > ps cases it's required that @paddr is backed by a large folio. That assumption has quite some limitations, preventing us from utilizing true zero-copy direct-io and encoded read/writes. To address the problem, enhance btrfs_repair_io_failure() by: - Accept an array of paddrs, up to 64K / PAGE_SIZE entries This kind of acts like a bio_vec, but with very limited entries, as the function is only utilized to repair one fs data block, or a tree block. Both have an upper size limit (BTRFS_MAX_BLOCK_SIZE, i.e. 64K), so we don't need the full bio_vec thing to handle it. - Allocate a bio with multiple slots Previously even for bs > ps cases, we only passed in a contiguous physical address range, thus a single slot will be enough. But not anymore, so we have to allocate a bio structure, other than using the on-stack one. - Use on-stack memory to allocate @paddrs array It's at most 16 pages (4K page size, 64K block size), will take up at most 128 bytes. I think the on-stack cost is still acceptable. - Add one extra check to make sure the repair bio is exactly one block - Utilize btrfs_repair_io_failure() to submit a single bio for metadata This should improve the read-repair performance for metadata, as now we submit a node sized bio then wait, other than submit each block of the metadata and wait for each submitted block. - Add one extra parameter indicating the step This is due to the fact that metadata step can be as large as nodesize, instead of sectorsize. So we need a way to distinguish metadata and data repair. - Reduce the width of @length parameter of btrfs_repair_io_failure() Since we only call btrfs_repair_io_failure() on a single data or metadata block, u64 is overkilled. Use u32 instead and add one extra ASSERT()s to make sure the length never exceed BTRFS_MAX_BLOCK_SIZE. Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Stable-dep-of: ec78575dde99 ("btrfs: always wait for ordered extents to avoid OE races") Signed-off-by: Sasha Levin commit a9701dd06e82c345fe70debdf8835b7eb5000c59 Author: Filipe Manana Date: Tue Jun 23 16:56:15 2026 +0100 btrfs: defrag: fix deadlock between defrag and delalloc space reservation [ Upstream commit ba02eab28041f9a4bbe9fc90c7249644fef6de0f ] While running fsstress with autodefrag and flushoncommit, hit a deadlock due to the fact that defrag reserves delalloc space while it's holding dirty and locked folios, besides the extent range lock. The stack traces are the following: [958.624] task:kworker/u50:3 state:D stack:0 pid:20365 tgid:20365 ppid:2 task_flags:0x4208060 flags:0x00080000 [958.626] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs] [958.627] Call Trace: [958.628] [958.628] __schedule+0x4be/0x10f0 [958.629] ? preempt_count_add+0x69/0xa0 [958.630] schedule+0x26/0xd0 [958.631] wait_current_trans+0x102/0x160 [btrfs] [958.632] ? __pfx_autoremove_wake_function+0x10/0x10 [958.633] start_transaction+0x374/0x900 [btrfs] [958.634] btrfs_commit_current_transaction+0x1d/0x70 [btrfs] [958.635] flush_space+0xca/0x5e0 [btrfs] [958.636] ? _raw_spin_unlock+0x15/0x30 [958.637] ? btrfs_reduce_alloc_profile+0x8c/0x190 [btrfs] [958.639] ? _raw_spin_unlock+0x15/0x30 [958.640] ? calc_available_free_space.isra.0+0x6f/0x110 [btrfs] [958.641] do_async_reclaim_metadata_space+0x84/0x190 [btrfs] [958.642] btrfs_async_reclaim_metadata_space+0x64/0x80 [btrfs] [958.644] process_one_work+0x19d/0x3a0 [958.644] worker_thread+0x1c4/0x330 [958.645] ? __pfx_worker_thread+0x10/0x10 [958.646] kthread+0xfc/0x130 [958.647] ? __pfx_kthread+0x10/0x10 [958.648] ret_from_fork+0x1f7/0x2c0 [958.648] ? __pfx_kthread+0x10/0x10 [958.649] ret_from_fork_asm+0x1a/0x30 [958.650] [958.651] task:kworker/u49:7 state:D stack:0 pid:52990 tgid:52990 ppid:2 task_flags:0x4208060 flags:0x00080000 [958.653] Workqueue: writeback wb_workfn (flush-btrfs-334) [958.655] Call Trace: [958.655] [958.656] __schedule+0x4be/0x10f0 [958.657] ? __blk_flush_plug+0xe9/0x140 [958.658] schedule+0x26/0xd0 [958.658] io_schedule+0x42/0x70 [958.659] folio_wait_bit_common+0x12b/0x330 [958.660] ? folio_wait_bit_common+0x100/0x330 [958.662] ? __pfx_wake_page_function+0x10/0x10 [958.663] extent_write_cache_pages+0x599/0x830 [btrfs] [958.664] ? acpi_fwnode_get_reference_args+0x1fa/0x270 [958.665] btrfs_writepages+0x77/0x130 [btrfs] [958.666] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] [958.667] do_writepages+0xc6/0x160 [958.668] __writeback_single_inode+0x42/0x310 [958.669] writeback_sb_inodes+0x231/0x570 [958.670] wb_writeback+0x8a/0x340 [958.671] wb_workfn+0xbf/0x450 [958.672] ? finish_task_switch.isra.0+0xc1/0x350 [958.673] process_one_work+0x19d/0x3a0 [958.673] worker_thread+0x1c4/0x330 [958.674] ? __pfx_worker_thread+0x10/0x10 [958.675] kthread+0xfc/0x130 [958.676] ? __pfx_kthread+0x10/0x10 [958.676] ret_from_fork+0x1f7/0x2c0 [958.677] ? __pfx_kthread+0x10/0x10 [958.678] ret_from_fork_asm+0x1a/0x30 [958.679] [958.679] task:btrfs-cleaner state:D stack:0 pid:296750 tgid:296750 ppid:2 task_flags:0x208040 flags:0x00080000 [958.681] Call Trace: [958.682] [958.682] __schedule+0x4be/0x10f0 [958.683] schedule+0x26/0xd0 [958.684] handle_reserve_ticket+0x1b9/0x2c0 [btrfs] [958.685] ? __pfx_autoremove_wake_function+0x10/0x10 [958.686] reserve_bytes+0x283/0x4c0 [btrfs] [958.687] btrfs_reserve_metadata_bytes+0x18/0xb0 [btrfs] [958.688] btrfs_delalloc_reserve_metadata+0x121/0x320 [btrfs] [958.690] btrfs_delalloc_reserve_space+0x46/0xb0 [btrfs] [958.691] btrfs_defrag_file+0x903/0x1110 [btrfs] [958.692] btrfs_run_defrag_inodes+0x334/0x430 [btrfs] [958.694] cleaner_kthread+0x97/0x1c0 [btrfs] [958.694] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] [958.696] kthread+0xfc/0x130 [958.696] ? __pfx_kthread+0x10/0x10 [958.697] ret_from_fork+0x1f7/0x2c0 [958.698] ? __pfx_kthread+0x10/0x10 [958.699] ret_from_fork_asm+0x1a/0x30 [958.700] [958.716] task:fsstress state:D stack:0 pid:296769 tgid:296769 ppid:296768 task_flags:0x400140 flags:0x00080000 [958.718] Call Trace: [958.719] [958.719] __schedule+0x4be/0x10f0 [958.720] ? preempt_count_add+0x69/0xa0 [958.721] schedule+0x26/0xd0 [958.722] wb_wait_for_completion+0x79/0xc0 [958.723] ? __pfx_autoremove_wake_function+0x10/0x10 [958.724] __writeback_inodes_sb_nr+0xc5/0xf0 [958.725] try_to_writeback_inodes_sb+0x55/0x70 [958.726] btrfs_commit_transaction+0x19d/0xeb0 [btrfs] [958.727] ? start_transaction+0x343/0x900 [btrfs] [958.728] btrfs_mksubvol+0x28b/0x4e0 [btrfs] [958.729] btrfs_mksnapshot+0x74/0xa0 [btrfs] [958.730] __btrfs_ioctl_snap_create+0x194/0x210 [btrfs] [958.732] btrfs_ioctl_snap_create_v2+0xef/0x150 [btrfs] [958.733] btrfs_ioctl+0x7ec/0x2a70 [btrfs] [958.734] ? __virt_addr_valid+0xe4/0x180 [958.735] ? __check_object_size+0x1cd/0x1f0 [958.736] ? kmem_cache_free+0x146/0x380 [958.737] ? _raw_spin_unlock+0x15/0x30 [958.738] ? do_sys_openat2+0x83/0xd0 [958.739] __x64_sys_ioctl+0x92/0xe0 [958.740] do_syscall_64+0x60/0x590 [958.741] ? clear_bhb_loop+0x60/0xb0 [958.742] entry_SYSCALL_64_after_hwframe+0x76/0x7e [958.743] RIP: 0033:0x7f4431e108db [958.744] RSP: 002b:00007ffcd147db20 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [958.746] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f4431e108db [958.747] RDX: 00007ffcd147eb90 RSI: 0000000050009417 RDI: 0000000000000005 [958.749] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [958.751] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcd147fbf0 [958.752] R13: 00007ffcd147eb90 R14: 0000000000000005 R15: 0000000000000003 [958.754] What happens is the following: 1) The cleaner kthread is running autodefrag, and in defrag_one_range() it acquired all the folios for the range and locked them. Then it locked the extent range in the inode's iotree. It got two subranges from defrag_collect_targets(), the first one with folio A and the second one with folio B. After it defragged the first subrange, folio A remains locked and dirty - it's only unlocked when defrag_one_range() returns. When it attempts to defrag the second subrange (containing folio B), btrfs_delalloc_reserve_space() creates a space reservation ticket, due to lack of free metadata space and blocks waiting for the async metadata reclaim task to free space and wake it up; 2) The async reclaim metadata task attempts to commit the current transaction, but it blocks because there is another task that started the commit first; 3) A task creating a snapshot is committing the transaction and because the fs was mounted with flushoncommit, it calls try_to_writeback_inodes_sb(), which spawns a task to flush delalloc and waits for it to complete; 4) The task flushing delalloc (kworker/u49:7), finds that folio A for the inode being defragged is dirty, so it tries to lock it... But it blocks because folio A is locked by the defrag task (the cleaner kthread) which is blocked waiting for the reservation ticket to be served, but the async reclaim metadata task is blocked waiting for the transaction commit, which in turn is blocked waiting for the delalloc flush task, which is trying to lock folio A, resulting in a deadlock. The same type of problem can happen if the async reclaim task starts to flush delalloc, as that requires both locking the folio and the extent range in the inode's io tree, and in this case we don't need the fs to be mounted with flushoncommit. This type of problem has ocurred several times in the past with reflinks for example, where we had a dirty folio while holding the extent range locked and then starting a transaction blocked waiting for the async reclaim task due to lack of free metadata space. So fix this by reserving delalloc space before locking folios and locking the extent range in the inode's iotree. We can not simply unlock the folios for each subrange given by defrag_collect_targets() after we defrag it because the same folio may be present too in the next subrange (due to large folios). Fixes: 22b398eeeed4 ("btrfs: defrag: introduce helper to defrag a contiguous prepared range") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 34f67cfb15fa568128e849de3367de077339e37d Author: Yang Xiuwei Date: Tue Jul 7 11:03:33 2026 +0800 scsi: sd: Fix sd_done() sense handling condition [ Upstream commit a640d4546b11be5709a82bdc63d7dafd8ddc6c9e ] Only enter the sense_key switch when the command returned CHECK CONDITION with valid, non-deferred sense. The old condition let deferred or invalid sense fall through and mis-handle the I/O. Fixes: 03aba2f79594 ("[SCSI] sd/scsi_lib simplify sd_rw_intr and scsi_io_completion") Reviewed-by: Damien Le Moal Signed-off-by: Yang Xiuwei Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260707030333.22245-4-yangxiuwei@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 8bd807995dd5dd74daecced5b3e9c51aee9df225 Author: Tanushree Shah Date: Sun Jul 26 00:19:50 2026 +0530 perf trace-event: Fix integer truncation in do_read() and skip() [ Upstream commit c108c1391be0826920991d24532fbae8f6373ddc ] The do_read() and skip() functions use 'int' for size parameters, truncating 64-bit sizes from callers. This causes two issues: 1. Uninitialized memory dump: do_read() reads fewer bytes than allocated, leaving uninitialized heap memory that gets written to output files. 2. Out-of-bounds read: Parsing functions process the full 64-bit size while only partial data was read into the buffer. Change do_read(), __do_read(), and skip() to use size_t for size parameters and ssize_t for return values (where applicable), matching read()/write() system calls. Update callers to use ssize_t for storing return values. Fixes: 4a31e56599d4 ("perf tools: Get rid of read_or_die() in trace-event-read.c") Signed-off-by: Tanushree Shah Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 14470bc005ec657df299fc480c108a338252dab0 Author: Zijun Hu Date: Thu Jun 25 22:19:49 2026 -0700 Bluetooth: btusb: QCA: Fix populating devcoredump fields on unenabled devices [ Upstream commit 33c6a8d01889a84cc773c0c20c8323bce84af27d ] Devcoredump is not enabled for ATH3012 or QCA_ROME, but they unconditionally populate devcoredump fields in btusb_setup_qca(). Fix by populating devcoredump fields only when BTUSB_QCA_WCN6855 is set, which marks the first generation of QCA BT SoCs for which devcoredump is enabled. Fixes: 20981ce2d5a5 ("Bluetooth: btusb: Add WCN6855 devcoredump support") Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4ea16cbcc58e30c3aa3f1d68be27e5ac40994ebc Author: Zijun Hu Date: Thu Jun 25 22:19:48 2026 -0700 Bluetooth: btusb: Record matched usb_device_id into btusb_data [ Upstream commit ff50db7a522e7bd3bd1c4db6da715e4bdb53af97 ] Add @match_id to btusb_data to record the matched usb_device_id which will be used later. Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 33c6a8d01889 ("Bluetooth: btusb: QCA: Fix populating devcoredump fields on unenabled devices") Signed-off-by: Sasha Levin commit 5ca4aa51ab3787bf6d1469ecd5bd84a8b0a45318 Author: Johan Hovold Date: Mon Mar 30 11:41:33 2026 +0200 Bluetooth: btusb: refactor endpoint lookup [ Upstream commit 5c31aaa05624b54dc18c9e313bcee5a88c025593 ] Use the common USB helper for looking up bulk and interrupt endpoints instead of open coding. Signed-off-by: Johan Hovold Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 33c6a8d01889 ("Bluetooth: btusb: QCA: Fix populating devcoredump fields on unenabled devices") Signed-off-by: Sasha Levin commit dc849d11a7d2b55685d8de9cb74a314be21510da Author: Zijun Hu Date: Thu Jun 25 22:19:47 2026 -0700 Bluetooth: btusb: Fix BD_ADDR byte order in btusb_set_bdaddr_wcn6855() [ Upstream commit d0b15d812688d3f0f3fe1c4426e12814d0c294dc ] btusb_set_bdaddr_wcn6855() sends the address without swapping byte order for VSC 0xFC14, but the command expects the address in reversed byte order compared to other HCI commands like HCI_Create_Connection, resulting in a wrong BD_ADDR being set. btmon log on WCN6855 shows VSC 0xFC14 is sent with swapped bytes 11 22 33 44 55 66, and Read BD ADDR returns the expected address 11:22:33:44:55:66: < HCI Command: Vendor (0x3f|0x0014) plen 6 #3 [hci0] 11 22 33 44 55 66 > HCI Event: Command Complete (0x0e) plen 4 #4 [hci0] Vendor (0x3f|0x0014) ncmd 1 Status: Success (0x00) < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 #11 [hci0] > HCI Event: Command Complete (0x0e) plen 10 #12 [hci0] Read BD ADDR (0x04|0x0009) ncmd 1 Status: Success (0x00) Address: 11:22:33:44:55:66 (OUI 11-22-33) Fix by swapping the input address before issuing the command. Fixes: b40f58b97386 ("Bluetooth: btusb: Add Qualcomm Bluetooth SoC WCN6855 support") Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4ea53de3e47fae0b7f6dca5e8f74e98f73f1e5ed Author: Zijun Hu Date: Thu Jun 25 22:19:46 2026 -0700 Bluetooth: btqca: Fix qca_set_bdaddr() waiting for wrong HCI event [ Upstream commit cf81f0a3db2a5c34ee6e4ea379c631fab6d13e01 ] qca_set_bdaddr() waits for HCI_EV_VENDOR when sending EDL_WRITE_BD_ADDR_OPCODE (0xFC14), but the controller responds with Command Complete event as confirmed by btmon on WCN7850: < HCI Command: Vendor (0x3f|0x0014) plen 6 #3 [hci0] 11 22 33 44 55 66 > HCI Event: Command Complete (0x0e) plen 4 #4 [hci0] Vendor (0x3f|0x0014) ncmd 1 Status: Success (0x00) Fix by passing 0 as the event parameter to __hci_cmd_sync_ev() to wait for the command complete event instead. Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address") Reviewed-by: Bartosz Golaszewski Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1403beab27c649dc99269617b996eeab779f04b1 Author: Ricardo Neri Date: Mon Jul 20 19:43:19 2026 -0700 sched/fair: Check CPU capacity before comparing group types during load balance [ Upstream commit 50b101f6e586b4417d060a976fd831cd87e86e2b ] update_sd_pick_busiest() may incorrectly select a fully_busy group as the busiest group when its per-CPU capacity exceeds that of the destination CPU. This happens because the type of busiest group is initialized to group_has_spare and allows the fully_busy group to win the type comparison. update_sd_pick_busiest() should not choose a candidate scheduling group with at most one runnable task if its per-CPU capacity is greater than that of the destination CPU. Such a check already exists, but it is done too late: after the type comparison, preventing a subsequent fully_busy group of equal per-CPU capacity from being correctly selected. Move this check to occur before comparing group types. Fixes: 0b0695f2b34a ("sched/fair: Rework load_balance()") Signed-off-by: Ricardo Neri Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Christian Loehle Reviewed-by: Chen Yu Reviewed-by: Tim Chen Reviewed-by: Vincent Guittot Tested-by: Christian Loehle Tested-by: Andrea Righi Link: https://patch.msgid.link/20260720-rneri-fix-cas-clusters-v6-3-bb500bf4afd4@linux.intel.com Signed-off-by: Sasha Levin commit ce065b76c89cbaac5ddbc60f706570c138a7266d Author: Ricardo Neri Date: Mon Jul 20 19:43:18 2026 -0700 sched/fair: Also gate overloaded status update for SD_ASYM_CPUCAPACITY [ Upstream commit 6060d61d13a10da8c90da4eadf4a421825149883 ] The argument sg_overloaded of update_sg_lb_stats() is only consumed when balancing at the root domain. It only makes sense to update it in such a case. Commit 3229adbe7875 ("sched/fair: Do not compute overloaded status unnecessarily during lb") updated the logic accordingly but missed the case in which the root domain has the SD_ASYM_CPUCAPACITY flag. Fix this. Fixes: 3229adbe7875 ("sched/fair: Do not compute overloaded status unnecessarily during lb") Reported-by: Chen Yu Signed-off-by: Ricardo Neri Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Tested-by: Christian Loehle Tested-by: Andrea Righi Link: https://patch.msgid.link/20260720-rneri-fix-cas-clusters-v6-2-bb500bf4afd4@linux.intel.com Signed-off-by: Sasha Levin commit cab5015ee3f25f789b4a368f2abfa65536576b78 Author: Adrian Hunter Date: Tue Jul 21 10:02:54 2026 +0300 perf/x86/intel/pt: Fix stop/start with no update [ Upstream commit 2e17bf3a469a41457a3bc31b1f8fd66b6ce94a6d ] If pt_event_stop() is called without PERF_EF_UPDATE flag, then perf_aux_output_end() is not called. A subsequent call to pt_event_start() will call perf_aux_output_begin() again which violates the rule against nesting and triggers a WARNING in perf_aux_output_begin(). Originally, pt_event_stop() was never called without PERF_EF_UPDATE, because the only code paths to do so are from event overflow, and Intel PT does not do that. However the introduction of group throttling by commit 9734e25fbf5ae ("perf: Fix the throttle logic for a group") meant that an Intel PT event could be throttled if it was part of a group. Throttling calls PMU ->stop() / ->start() callbacks without flags. An example is when AUX area sampling is used. The following commands hit the issue: echo 10000 > /proc/sys/kernel/perf_event_max_sample_rate perf record -F32000 --aux-sample -e '{intel_pt//u,cycles:u}' \ -- bash -c 'for i in `seq 1 100000` ; do true ; done' Use PERF_HES_UPTODATE to track whether perf_aux_output_begin() and perf_aux_output_end() are balanced. A cleared PERF_HES_UPTODATE bit indicates that an AUX output context is still open. Amend pt_event_start() / pt_event_stop() accordingly so that begin/end stay balanced: - In non-snapshot mode, stop() always closes the buffer (the buffer may have run out of space, and that accounting is done by the update), so a following start() opens a fresh one as before. - In snapshot/overwrite mode, stop() without PERF_EF_UPDATE leaves the buffer open so that pt_event_snapshot_aux() can still copy from it, and start() then only re-enables tracing instead of calling perf_aux_output_begin() again. Note that pt_event_del() calls pt_event_stop() with PERF_EF_UPDATE flag set (as is required by the documentation), so a final call to perf_aux_output_end() is assured. Fixes: 52ca9ced3f707 ("perf/x86/intel/pt: Add Intel PT PMU driver") Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Tested-by: Yi Lai Link: https://patch.msgid.link/20260721070254.13557-4-adrian.hunter@intel.com Signed-off-by: Sasha Levin commit b53e430f8eab897980b5c9061d3a45e08613e9c2 Author: Adrian Hunter Date: Tue Jul 21 10:02:53 2026 +0300 perf/x86/intel/pt: Use bitwise access for PERF_HES_STOPPED [ Upstream commit 265bb4ef75fa657f4957d72087a6a246b89d5f0d ] The Intel PT driver reads and writes event->hw.state as a whole value, assuming it is either 0 or PERF_HES_STOPPED. That is true today, but a subsequent fix needs to also track an open AUX output buffer using the PERF_HES_UPTODATE bit of the same field. When more than one bit can be set, whole-value assignments would overwrite the other bits and whole-value comparisons would fail to match. Convert all accesses to set, clear and test the PERF_HES_STOPPED bit individually, in preparation for that change. No functional change intended: event->hw.state currently only ever holds 0 or PERF_HES_STOPPED, so the bitwise forms are equivalent. Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Tested-by: Yi Lai Link: https://patch.msgid.link/20260721070254.13557-3-adrian.hunter@intel.com Stable-dep-of: 2e17bf3a469a ("perf/x86/intel/pt: Fix stop/start with no update") Signed-off-by: Sasha Levin commit ad9d3402f4b05c5de63e83165f481dd8b67ae209 Author: Adrian Hunter Date: Tue Jul 21 10:02:52 2026 +0300 perf/x86/intel/pt: Factor out pt_config_enable() [ Upstream commit c6df517796189723ffbdd7679206c97d3642c2ef ] pt_config() enables tracing by allowing NMIs and pause/resume, issuing the necessary barriers, and calling pt_config_start(). A later change needs to re-enable tracing on a (re-)start path without repeating the full pt_config() setup (filters, RTIT_CTL, buffer configuration). Factor that enabling sequence out into a new helper, pt_config_enable(), so it can be called on its own. No functional change intended. Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Tested-by: Yi Lai Link: https://patch.msgid.link/20260721070254.13557-2-adrian.hunter@intel.com Stable-dep-of: 2e17bf3a469a ("perf/x86/intel/pt: Fix stop/start with no update") Signed-off-by: Sasha Levin commit 54eb9b2d18f8b149176a32980a3f0955cad3d690 Author: Yuho Choi Date: Thu Aug 6 21:57:34 2026 -0400 ACPI: video: Release PCI device reference after lookup [ Upstream commit 3d7ed9b8ef47b8bcae1fc3e12f7590a217862a89 ] video_detect_portege_r100() uses pci_get_device() only as a boolean check for the Trident CyberBlade XP4m32 device. pci_get_device() takes a reference on a matching PCI device, but the callback returns without releasing it. Drop the reference after selecting the vendor backlight quirk so the PCI device can be released normally. Fixes: 35a341c9b25d ("ACPI: video: Add acpi_backlight=vendor quirk for Toshiba Portégé R100") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260807015734.913361-1-dbgh9129@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 679b862781010d5d9cf5030d661035d2060ab814 Author: Kamal Wadhwa Date: Sat Aug 1 13:30:28 2026 +0530 regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handling [ Upstream commit abd14bebb87e0fa2749371272c8b31d6ee5f0a36 ] Currently, when `rpmh_regulator_set_mode_bypass()` helper function is called to set bypass mode, it sends PMIC4's BOB bypass mode value for even if its a PMIC5 BOB. To fix this, introduce new hw_data parameter`pmic_bypass_mode` to store bypass mode value. Use it to send correct PMIC bypass mode value that corresponds to PMIC4/5 BOB regulators from the helper function. Fixes: 610f29e5cc0e8d58 ("regulator: qcom-rpmh: Update PMIC modes for PMIC5") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Kamal Wadhwa Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-2-9fcb54928523@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 053ec85cb9f2611c0d26a635f5c2af27d2805344 Author: Daniel Borkmann Date: Thu Aug 6 22:10:45 2026 +0200 bpf, arm64: Fix exception table metadata for arena load-acquire [ Upstream commit af22d273aa1f61fb86ec712b3ed785da73c3296e ] Same problem as on x86-64: add_exception_handler() decides whether an instruction is a load by its class, and a load-acquire is of BPF_STX class even though it reads from src_reg into dst_reg. As a result ... if (BPF_CLASS(insn->code) != BPF_LDX) dst_reg = DONT_CLEAR; ... drops the register to clear, and ... if (BPF_CLASS(insn->code) == BPF_LDX) arena_reg = bpf2a64[insn->src_reg]; else arena_reg = bpf2a64[insn->dst_reg]; ... hands ex_handler_bpf() the value register instead of the address register. A load-acquire from an arena pointer that faults on an unmapped page is therefore reported as a WRITE at a bogus address, and dst_reg keeps its previous value instead of being cleared to 0. Note that emit_atomic_ld_st() already picks src_reg as the address for BPF_LOAD_ACQ, so only the exception table metadata was out of sync with the emitted access. Same as on x86-64, use bpf_atomic_is_load_acq() so a load-acquire takes the load path. Fixes: 9bb12368d539 ("bpf, arm64: Support load-acquire and store-release instructions") Signed-off-by: Daniel Borkmann Reviewed-by: Puranjay Mohan Link: https://lore.kernel.org/bpf/20260806201047.333389-4-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 415257c38a3fcedde120ed0cd6f2cfb0368ccee1 Author: Daniel Borkmann Date: Thu Aug 6 22:10:44 2026 +0200 bpf, x86: Fix exception table metadata for arena load-acquire [ Upstream commit 4cf8def58b779ad2827f81760837b7a844d6c7d6 ] A load-acquire from an arena pointer is converted to BPF_PROBE_ATOMIC and gets an exception table entry, but the entry is filled in as if it were a store, since populate_extable() decides based on instruction class alone and a load-acquire is of BPF_STX class: if (BPF_CLASS(insn->code) == BPF_LDX) { arena_reg = reg2pt_regs[src_reg]; fixup_reg = reg2pt_regs[dst_reg]; } else { arena_reg = reg2pt_regs[dst_reg]; fixup_reg = DONT_CLEAR; } For a load-acquire dst_reg holds the loaded value and src_reg holds the address, so both assignments in the else branch are wrong. On a fault over an unmapped arena page ex_handler_bpf() then: - computes the reported address from the value register instead of the address register - reports the access as a WRITE, since it derives the direction from fixup_reg == DONT_CLEAR - leaves dst_reg untouched, so the program continues with a stale value instead of the 0 that BPF_PROBE_* loads deliver The access itself is emitted correctly, emit_atomic_ld_st_index() uses src_reg as the address, so this is a broken probe contract and a wrong diagnostic rather than a memory safety issue. Use bpf_atomic_is_load_acq() helper so a load-acquire takes the load path. Fixes: 5341c9a4d833 ("bpf, x86: Support load-acquire and store-release instructions") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260806201047.333389-3-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 5f13a844d0c9bd366ed7403a08f1622d4dc7825d Author: Daniel Borkmann Date: Thu Aug 6 22:10:43 2026 +0200 bpf, riscv: Add and use bpf_atomic_is_load_acq() helper [ Upstream commit e2577cd62060be91a3d7d11a56e5a61faae4b7f7 ] A load-acquire is the only BPF_STX class instruction that reads from src_reg into dst_reg, that is, it has the operand roles of a BPF_LDX. JIT code which tells loads from stores apart by instruction class alone has to special case it, for example when deciding which register holds the faulting address and which one to clear from an exception handler. riscv64 already does so, open coded as a bare insn->imm test. Add a bpf_atomic_is_load_acq() helper and convert riscv64 over to it, so that the x86-64 and arm64 JITs can use the same helper in subsequent patches. Unlike bpf_atomic_is_load_store(), which presumes that its argument is already known to be a BPF_ATOMIC instruction, the new helper is called from code which still sees all instruction classes, so it checks class and mode itself. Also, move bpf_atomic_is_load_store() to filter.h next to BPF_ATOMIC_OP, so that both helpers stay together. No functional change intended. Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260806201047.333389-2-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Stable-dep-of: 4cf8def58b77 ("bpf, x86: Fix exception table metadata for arena load-acquire") Signed-off-by: Sasha Levin commit c4c8de3bf48d3756ab0f910fe5cc4937d70efdcd Author: Daniel Borkmann Date: Thu Aug 6 22:10:42 2026 +0200 bpf: Reject load-acquire from pointers requiring fault protection [ Upstream commit 7db0a00445f1a40bacfe9b747405c11cb5f10fc9 ] A BPF_LOAD_ACQ is not rewritten to a BPF_PROBE_MEM load by the verifier, unlike a regular BPF_LDX, so the JIT emits a plain load with no exception table entry and a fault panics the kernel instead of being handled. Reject the source pointer types that a BPF_LDX would have had that fault protection applied to, i.e. the ones bpf_convert_ctx_accesses() turns into BPF_PROBE_MEM: a bare PTR_TO_BTF_ID, PTR_TO_BTF_ID | PTR_UNTRUSTED, PTR_TO_BTF_ID | MEM_ALLOC | PTR_UNTRUSTED and PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED. This is reachable e.g. by loading ->mm out of a trusted task_struct yields an untrusted pointer to mm_struct, and it is NULL for a kernel thread: [...] SEC("tp_btf/sched_switch") int BPF_PROG(demo, bool preempt, struct task_struct *prev, struct task_struct *next) { struct mm_struct *mm = next->mm; /* untrusted */ out_ldx = (__u64)mm->pgd; /* BPF_LDX */ out_acq = load_acquire(&mm->pgd); /* BPF_LOAD_ACQ */ return 0; } [...] Both dereference the same pointer, but only the BPF_LDX is protected (x86-64 JIT, jump targets shown prog-relative): [...] ; out_ldx = (__u64)mm->pgd; 17: movq $-10485760, %r10 1e: movq %rsi, %r11 21: addq $184, %r11 28: subq %r10, %r11 2b: movabsq $140737498841088, %r10 35: cmpq %r10, %r11 38: ja 0x3e <-- kernel addr? 3a: xorl %edi, %edi <-- no: dst = 0, skip the load 3c: jmp 0x45 3e: movq 184(%rsi), %rdi <-- yes: load + extable entry [...] ; load_acquire(&mm->pgd) 53: movq %rsi, %rdi 56: movq 184(%rdi), %rax <-- no check, no extable entry [...] Note that BPF_PROBE_MEM is not visible in a bpftool xlated dump, as bpf_insn_prepare_dump() rewrites it back to BPF_MEM. A PTR_TRUSTED pointer is deliberately not on the list. Such a load is not converted either, but it does not need to be, since the pointer is guaranteed live, so load-acquire from it stays allowed. The check is gated on BPF_LOAD_ACQ so that atomic RMW and store-release error messages are unchanged; writes (RMW / store-release) to such pointers are already rejected elsewhere, so only load-acquire needs this. Fixes: 880442305a39 ("bpf: Introduce load-acquire and store-release instructions") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260806201047.333389-1-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 57b72442c1672963fd51ab441ca1b71f6dc79b66 Author: James Clark Date: Fri Aug 7 10:14:59 2026 +0100 perf: arm_pmuv3: Zero initialize hw_id branch stack field [ Upstream commit 7c3b63386c27bed8d59a4b4c283d02860420eb0a ] PERF_SAMPLE_BRANCH_HW_INDEX is supported by BRBE so hw_id is passed to userspace, but it's never set by the BRBE driver. Zero initialize it as it should be according to the docs: * For the architectures whose raw branch records are * already stored in age order, the hw_idx should be 0. It's probably too risky to remove PERF_SAMPLE_BRANCH_HW_INDEX from BRBE now in case anyone is setting it and reading the value, but zero initializing the whole struct also protects against the same issue with new fields that are added in the future. Fixes: 58074a0fce66 ("perf: arm_pmuv3: Add support for the Branch Record Buffer Extension (BRBE)") Signed-off-by: James Clark Reviewed-by: Anshuman Khandual Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f61f65fc81dcd5785f949a6ebc65cfce0393c2f2 Author: James Clark Date: Fri Nov 28 11:55:15 2025 +0000 coresight: Refactor etm4_config_timestamp_event() [ Upstream commit b02450de6ba6309c66e2e056ccfbfce4bd3b0352 ] Remove some of the magic numbers and try to clarify some of the documentation so it's clearer how this sets up the timestamp interval. Return errors directly instead of jumping to out and returning ret, nothing needs to be cleaned up at the end and it only obscures the flow and return value. Add utilities for programming resource selectors that do compile time checks for constants or WARN_ONs for non-constant values. FIELD_PREP includes compile time checks so we only need to add an additional BUILD_BUG_ON for resource == 0 in pair mode. Tested-by: Leo Yan Signed-off-by: James Clark Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20251128-james-cs-syncfreq-v8-3-4d319764cc58@linaro.org Stable-dep-of: 0a47f0be6557 ("coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable") Signed-off-by: Sasha Levin commit 9e804dbe28b746e8ed8682f93c5d5ad82e058e21 Author: Yeoreum Yun Date: Sat Jul 25 12:36:35 2026 +0100 coresight: etm4x: fix leaked trace id [ Upstream commit 467e5862ccb0eed907002f4c6d3badfe34360940 ] If etm4_enable_sysfs() fails in cscfg_csdev_enable_active_config(), the trace ID may be leaked because it is not released. To address this, call etm4_release_trace_id() when etm4_enable_sysfs() fails in cscfg_csdev_enable_active_config(). Fixes: 7ebd0ec6cf94 ("coresight: configfs: Allow configfs to activate configuration") Reviewed-by: Jie Gan Reviewed-by: Leo Yan Signed-off-by: Yeoreum Yun Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260725113645.57519-4-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit 1ade9a335c69fc735cb7b3f222ed35ab135540fb Author: Yeoreum Yun Date: Sat Jul 25 12:36:34 2026 +0100 coresight: etm4x: fix underflow for usage of (nrseqstate - 1) [ Upstream commit 1674d9bff8073bdee5dbc200f56fc3caa28d0566 ] According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR is implemented only when TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000. IOW, the number of usage in the initialisation or setting TRCSEQEVR with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000. Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR relevant fields setup. Link: https://developer.arm.com/documentation/ihi0064/latest/ [0] Fixes: 2e1cdfe184b5 ("coresight-etm4x: Adding CoreSight ETM4x driver") Suggested-by: Leo Yan Suggested-by: Suzuki K Poulose Signed-off-by: Yeoreum Yun Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260725113645.57519-3-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit 9241edfb84a0d37aba0c81e033547dfd99875732 Author: James Clark Date: Fri Nov 28 11:55:13 2025 +0000 coresight: Change syncfreq to be a u8 [ Upstream commit 10d4dbdc8fbce586b17be07b8138e025381453dd ] TRCSYNCPR.PERIOD is the only functional part of TRCSYNCPR and it only has 5 valid bits so it can be stored in a u8. Reviewed-by: Mike Leach Reviewed-by: Leo Yan Tested-by: Leo Yan Signed-off-by: James Clark Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20251128-james-cs-syncfreq-v8-1-4d319764cc58@linaro.org Stable-dep-of: 1674d9bff807 ("coresight: etm4x: fix underflow for usage of (nrseqstate - 1)") Signed-off-by: Sasha Levin commit a29d753e9d83b60d9a1a55043a6d18806837b565 Author: Yeoreum Yun Date: Sat Jul 25 12:36:33 2026 +0100 coresight: etm4x: fix wrong check of etm4x_sspcicrn_present() [ Upstream commit 0e1cd4270b42a257c139165622091e1e8c7104a7 ] According to Embedded Trace Macrocell Architecture Specification ETMv4.0 to ETM4.6 [0], TRCSSPCICR is present only if all of the following are true: - TRCIDR4.NUMSSCC > n. - TRCIDR4.NUMPC > 0b0000. - TRCSSCSR.PC == 0b1. Comment for etm4x_sspcicrn_present() is align with the specification. However, the check should use drvdata->nr_pe_cmp to check TRCIDR4.NUMPC not nr_pe. Link: https://developer.arm.com/documentation/ihi0064/latest/ [0] Fixes: f6a18f354c58 ("coresight: etm4x: Handle access to TRCSSPCICRn") Reviewed-by: Leo Yan Signed-off-by: Yeoreum Yun Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260725113645.57519-2-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit f9cdb5bb8efbf401e84d850828271af87e6be2dc Author: Bruce Johnston Date: Mon Aug 3 14:02:39 2026 -0400 md/raid1: don't set array_frozen in raid1_takeover() [ Upstream commit dc386aa0ac0a3ec06c9a3ea9b064b073fb72a916 ] raid1_takeover() sets conf->array_frozen = 1 on the newly-allocated r1conf and nothing ever clears it, so every I/O to the array stalls permanently once _wait_barrier() sees it stuck at 1. This used to be harmless: level_store() called mddev_resume() right after pers->run(), which called raid1_quiesce(mddev, 0) and cleared array_frozen back to 0 regardless of what raid1_takeover() set. Commit b39f35ebe86d ("md: don't quiesce in mddev_suspend()") removed that quiesce(mddev, 0) call, so the pre-set now sticks. setup_conf() already zero-initializes the new r1conf via kzalloc, so just don't set array_frozen here. Same class of bug as commit 892da88d1cd9 ("md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()"), also triggered by b39f35ebe86d. Fixes: b39f35ebe86d ("md: don't quiesce in mddev_suspend()") Link: https://issues.redhat.com/browse/RHEL-191802 Signed-off-by: Bruce Johnston Link: https://patch.msgid.link/20260803180240.1177104-1-bjohnsto@redhat.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit c55aa6c17f019b6296952d336939891efa084c06 Author: Yu Kuai Date: Mon Aug 3 03:50:18 2026 +0800 md/md-llbitmap: stop daemon timer rearm on destroy [ Upstream commit 5553d64e01d9a995be6c3de38501c6dd4ceede3b ] llbitmap_destroy() deletes pending_timer before flushing md_llbitmap_io_wq. However, daemon_work can still be queued or running after the timer has been deleted, and the daemon path can arm pending_timer again when it finds dirty chunks that are not ready to flush yet. If that happens during teardown, pending_timer can remain armed after llbitmap is freed and later dereference freed memory. Add a BITMAP_SHUTDOWN bit to llbitmap->flags, set it before deleting the timer, and make the timer and daemon paths stop queueing or rearming work once teardown starts. Cancel daemon_work before flushing the shared workqueue so no already queued daemon instance can race with the free. Use timer_shutdown_sync() so a daemon instance that passed the shutdown check before teardown cannot rearm the timer afterward. BITMAP_SHUTDOWN is a runtime-only state. Mask it out when reading and updating the llbitmap superblock so the shutdown state is never loaded from disk or persisted to disk. Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-10-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 930cc4f1af5a1afcd545a6ba00e38921ff8401e0 Author: Yu Kuai Date: Mon Aug 3 03:50:17 2026 +0800 md/md-llbitmap: prevent create failure bitmap UAF [ Upstream commit 2116c2f0a0e547615886900e2ed8c529c016499b ] llbitmap_create() publishes mddev->bitmap before reading the bitmap superblock. This is needed because llbitmap_read_sb() can initialize a new bitmap and flush it through helpers that use mddev->bitmap. If llbitmap_read_sb() fails, the old cleanup dropped bitmap_info.mutex and freed llbitmap before clearing mddev->bitmap. Readers such as /proc/mdstat rely on bitmap_info.mutex to keep the bitmap pointer stable while collecting bitmap stats, so they could observe the stale pointer after the failed create path released the mutex. Clear mddev->bitmap while still holding bitmap_info.mutex, then free the failed llbitmap after dropping the mutex. This makes mutex-protected readers see either a live bitmap or no bitmap. Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-9-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit d81822fd5fa8123b8250fd97a7ba9bdf43ab3c4a Author: Yu Kuai Date: Mon Aug 3 03:50:16 2026 +0800 md: avoid stale clone I/O accounting timestamps [ Upstream commit 45102fc8330525d35675b1c193242bba101df5ee ] md_clone_bio() always allocates the clone from mddev->io_clone_set, even when queue I/O stats are disabled. In that case it does not call bio_start_io_acct(), but it also left md_io_clone->start_time untouched. The clone private data comes from a mempool and can contain data from a previous user. md_end_clone_io() checks start_time to decide whether it needs to call bio_end_io_acct(), so a stale non-zero value can make the completion path end accounting that was never started for this bio. Set start_time to 0 in the no-stats branch. This keeps the end path tied to whether bio_start_io_acct() actually ran. Fixes: c687297b8845 ("md: also clone new io if io accounting is disabled") Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-8-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 73881ff7a75913f919a1ce9d9571bfaab8e8588d Author: Yu Kuai Date: Mon Aug 3 03:50:15 2026 +0800 md: wait for behind writes before destroying bitmap [ Upstream commit 2a79365b2278f16e163e4024086105693b421601 ] __md_stop() destroyed the bitmap before calling mddev_detach(). That made mddev_detach() skip bitmap_ops->wait_behind_writes(), because the bitmap was already disconnected from mddev. This was still safe for the legacy bitmap because bitmap_destroy() waits for behind writes itself. llbitmap keeps that wait in its ->wait_behind_writes() operation instead, while ->destroy() tears down the llbitmap storage. With the old ordering, RAID1 behind-write completions could still run after llbitmap storage had been freed. Call mddev_detach() before md_bitmap_destroy() so the common detach path can wait for behind writes while the bitmap is still alive. Only destroy the bitmap after those users are gone. Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-7-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 02c10581866d08822c6348e299881485fc546185 Author: Yu Kuai Date: Mon Aug 3 03:50:14 2026 +0800 md/raid5: round bitmap stripes with sector division [ Upstream commit 17ea021ae74987d6064c8195c4922fa025753892 ] raid5_bitmap_sector_map() aligns the array range to full RAID5 stripe widths before converting it to component sectors. That width is chunk_sectors multiplied by the number of data disks, and it is not always a power of two. Reproduce with a 4-disk RAID5, 1024-sector chunks, and three data disks. The full-stripe width is 3072 sectors. For a one-sector write at array sector 3072, correct rounding gives array range [3072, 6144), which maps to component range [1024, 2048). The old round_down()/round_up() logic instead gives [1024, 4096), which maps to [0, 1024). Use sector_div() based arithmetic so the rounded range is aligned to the actual RAID5 stripe width. The deterministic mapper test now reports the fixed component range as [1024, 2048), while the old mask-based range was [0, 1024). Fixes: 9c89f604476c ("md/raid5: implement pers->bitmap_sector()") Reported-by: Mykola Marzhan Link: https://lore.kernel.org/all/20260726185916.2223460-1-mykola@meshstor.io/ Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-6-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit d2c069ddaec7936b1ddf046a78f54b12f6ba2210 Author: Esteban Urrutia Date: Wed Jul 15 02:37:47 2026 -0400 phy: qcom: qmp-pcie: Add pcs_lane1 offset to V5 offsets [ Upstream commit f8b4493d5e7e19682abcf538a9faad012b5ef69e ] Some SoCs such as SM8475 write data to registers using this offset, specifically SW_CTRL2 and MX_CTRL2. Add pcs_lane1 offset to V5 offsets to support this. Signed-off-by: Esteban Urrutia Fixes: 0fd0b31965b0 ("phy: qualcomm: qmp-pcie: add support for SAR2130P") Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20260715-sm8475-bup-pcie-v2-2-48bd91a19abf@proton.me Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5547fd950d6bf72de861b6934341e7bb0888640c Author: Loic Poulain Date: Wed Jul 22 15:45:19 2026 +0200 phy: qcom: qmp-usb: Fix possible NULL-deref on early runtime suspend [ Upstream commit 142c5593379273264474f31d5956b1a0065cd576 ] There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {` This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized. Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer. Fixes: e464a3180a43 ("phy: qcom-qmp-usb: split off the legacy USB+dp_com support") Signed-off-by: Loic Poulain Link: https://patch.msgid.link/20260722-qcom-usb-phy-fix-null-v6-6-534f7e61b9a6@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 61749681e4a3629ec20b04ba2443b91016af3d2f Author: Loic Poulain Date: Wed Jul 22 15:45:18 2026 +0200 phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend [ Upstream commit c271a6926ea7d3c9566b033d63fd4e8c488dc860 ] Runtime PM must be enabled before creating the PHY, since phy_create() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference. Take a runtime PM usage reference with pm_runtime_get_noresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup. Fixes: 0d75f508a9d5 ("phy: qcom-snps: Add runtime suspend and resume handlers") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Abel Vesa Signed-off-by: Loic Poulain Link: https://patch.msgid.link/20260722-qcom-usb-phy-fix-null-v6-5-534f7e61b9a6@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 52ad86ea5f98d29a7a29d9ba12e24276c6e30acd Author: Loic Poulain Date: Wed Jul 22 15:45:16 2026 +0200 phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend [ Upstream commit 8e3687f7e18fe84372e86875709d56c37e7525a8 ] There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {` This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized. Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer. Fixes: e464a3180a43 ("phy: qcom-qmp-usb: split off the legacy USB+dp_com support") Reviewed-by: Abel Vesa Reviewed-by: Dmitry Baryshkov Signed-off-by: Loic Poulain Link: https://patch.msgid.link/20260722-qcom-usb-phy-fix-null-v6-3-534f7e61b9a6@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f67686d82675519a6d436a775cb519593436b974 Author: Mohd Ayaan Anwar Date: Tue Aug 4 00:57:58 2026 +0530 phy: qcom: sgmii-eth: vote for both voltage rails with correct current loads [ Upstream commit 4f81684a1d1018d7d0e5579f08d95e7701279358 ] The SerDes PHY has two voltage supply rails, vdda-0p9 and vdda-1p2, that must both be enabled for calibration to succeed. Without them: qcom-dwmac-sgmii-phy 8909000.phy: QSERDES_COM_C_READY_STATUS timed-out qcom-ethqos 23040000.ethernet eth0: __stmmac_open: Serdes powerup failed The driver relied solely on the PHY framework's implicit enable of 'phy-supply', which only voted for a single rail and set no current load. Use devm_regulator_bulk_get_const() to acquire both supplies and set the peak current loads (46 mA for vdda-0p9, 15 mA for vdda-1p2) as required by the hardware. Fixes: 601d06277007 ("phy: qcom: add the SGMII SerDes PHY driver") Signed-off-by: Mohd Ayaan Anwar Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260804-b4-sgmiieth_serdes_regulator-v2-2-c4bc688177dd@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 12d35c6572622454fd804d32c0117daf33d58702 Author: Russell King (Oracle) Date: Tue Mar 3 15:54:01 2026 +0000 phy: qcom-sgmii-eth: relax order of .power_on() vs .set_mode*() [ Upstream commit ebe8b48b88ad012cf6067226e184e9173b7ea9d6 ] Allow any order of the .power_on() and .set_mode*() methods as per the recent discussion. This means phy_power_on() with this SerDes will now restore the previous setup without requiring a subsequent phy_set_mode*() call. Tested-by: Mohd Ayaan Anwar Acked-by: Vinod Koul Reviewed-by: Vladimir Oltean Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1vxS4P-0000000BQXs-0vGB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Stable-dep-of: 4f81684a1d10 ("phy: qcom: sgmii-eth: vote for both voltage rails with correct current loads") Signed-off-by: Sasha Levin commit a834458ecaadb0566b16d22ce854be2ceff6b01b Author: Linkai Gong Date: Fri Jul 31 17:46:08 2026 +0800 soc: fsl: qe: check platform_driver_register() in qe_ic_of_init() [ Upstream commit fbdba2a67fa7c0e7570bcbf9f28b782d6100270d ] qe_ic_of_init() ignored the return value of platform_driver_register() and always returned success. Propagate the error to the initcall. Fixes: be7ecbd240b2 ("soc: fsl: qe: convert QE interrupt controller to platform_device") Signed-off-by: Linkai Gong Reviewed-by: Maxim Kochetkov Link: https://lore.kernel.org/r/20260731094608.1883391-1-gonglinkai@kylinos.cn Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit dfe848cadfde4179a0691da34f4bed36ff7185b5 Author: Yichong Chen Date: Mon Jul 20 10:18:59 2026 +0800 hugetlbfs: release subpool on fill_super failure [ Upstream commit 308ab73e97c87bd0e142b11758faab7f88d82854 ] hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size mount options are specified. hugepage_new_subpool() may also reserve huge pages for min_size. If root dentry creation fails after the subpool is created, the failure path frees the subpool with kfree(). This bypasses hugepage_put_subpool() and can leave min_size reservations charged. Use hugepage_put_subpool() on the failure path, matching the normal put_super path. Link: https://lore.kernel.org/20260720021900.1376309-1-chenyichong@uniontech.com Fixes: 7ca02d0ae586 ("hugetlbfs: accept subpool min_size mount option and setup accordingly") Signed-off-by: Yichong Chen Cc: David Hildenbrand Cc: Muchun Song Cc: Oscar Salvador Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 2177c04ca0684aec8058feac0dc2b989d0a5a557 Author: Simon Glass Date: Mon Aug 3 08:10:23 2026 -0600 pinctrl: rockchip: Reset the pin count when recalculating SoC data [ Upstream commit 5b695c191cc85f0fd62eec885b55d01468dc9f2c ] rockchip_pinctrl_get_soc_data() mutates the static per-SoC data. The iomux and drive offsets are recalculated idempotently, since a rerun anchors at the values calculated before, but the total pin count only accumulates: each run adds every bank's pins again. When the probe is deferred and runs a second time, nr_pins doubles and every bank's pin_base shifts, so later pin lookups resolve to the wrong bank and the wrong registers. Reset the pin count at the start of the calculation, so that a rerun produces the same values. This is verified on a Luckfox Pico Mini B (RV1103, with the pending RV1106 series applied) by forcing the probe to defer once: without this patch the second probe calculates nr_pins=304 instead of 152 and no GPIO bank comes up; with it the recalculation matches the first run and all banks work. Fixes: d3e5116119bd ("pinctrl: add pinctrl driver for Rockchip SoCs") Link: https://sashiko.dev/#/patchset/20260729132736.3807082-1-sjg@chromium.org?part=4 Assisted-by: Claude:claude-opus-5 Signed-off-by: Simon Glass Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6eaa632d0ed7bbb84f9cb670e5ec4e2cecf4cc7b Author: Mukesh Ojha Date: Thu Jul 16 13:46:01 2026 +0530 firmware_loader: do not queue completed sysfs fallback requests [ Upstream commit b48373c901951fad1a26bd7c33ad91172b3945b5 ] fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to pending_fw_head. device_add() publishes the fallback loading interface, so a userspace helper which discovers the device by scanning sysfs can write 0 to the loading attribute and complete the request before it is queued as pending. In that interleaving firmware_loading_store() calls fw_state_done() while pending_list still points to itself, so it cannot remove an entry from pending_fw_head. The subsequent unconditional list_add() then queues an already-completed fw_priv. Once the request is released, pending_fw_head can retain a pointer to freed memory and the next fallback request can fault while validating the list. Only in-flight fallback requests need suspend or reboot abort handling. If the request is already DONE after device_add(), return success from the fallback path without sending another uevent, waiting again, or queueing it as pending. This preserves the invariant that pending_fw_head contains only active fallback requests. Fixes: 75d95e2e39b2 ("firmware_loader: fix use-after-free in firmware_fallback_sysfs") Signed-off-by: Mukesh Ojha Link: https://patch.msgid.link/20260716081601.1674470-1-mukesh.ojha@oss.qualcomm.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 067504c00fe175864652764308922d99e199828f Author: Manish Rangankar Date: Thu Jul 23 10:33:23 2026 +0530 scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path [ Upstream commit 5cbc49d5c4cd20c18041e86958103045216d2190 ] qla2x00_sysfs_read_vpd() called ha->isp_ops->read_optrom() a second time after releasing optrom_mutex. The repeated read is redundant and, unlike the first, runs without optrom_mutex held, exposing flash access to concurrent optrom operations. Drop the duplicate call. Fixes: 5fa8774c7f38 ("scsi: qla2xxx: Add 28xx flash primary/secondary status/image mechanism") Signed-off-by: Manish Rangankar Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-7-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 8d752f1bb73fabe5a425acbf5c767c0fe68bf3c5 Author: Timur Kristóf Date: Mon Aug 3 15:23:02 2026 +0200 drm/amdgpu/gfx6: Use PFP on the compute queues too [ Upstream commit 60f20946cd318518ddc2c0da12103c666b2b9564 ] On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well. Fixes: 2cd46ad22383 ("drm/amdgpu: add graphic pipeline implementation for si v8") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 375adae128dd0b068e917db3abc90a07e3ae3a8f Author: Timur Kristóf Date: Mon Aug 3 15:23:01 2026 +0200 drm/amdgpu/gfx6: Fixup emitting SWITCH_BUFFER packets [ Upstream commit 7aac4242a11991d530eee3e141d6e445d5f11c22 ] Implement the emit_switch_buffer() function instead of emitting them duing emit_ib, emit_pipeline_sync and emit_vm_flush. Note that it isn't necessary to emit these in both emit_pipeline_sync() and emit_vm_flush() because amdgpu_vm_flush() already calls these when calling either of those functions. Fixes: 2cd46ad22383 ("drm/amdgpu: add graphic pipeline implementation for si v8") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1a1ea9738c41d80d1d81db9cfea060e845f46c03 Author: Tanushree Shah Date: Sun Jul 26 00:19:49 2026 +0530 perf trace-event: Fix buffer overflow in read_string() [ Upstream commit 1121a7af1833f8b5723f1e32685b461614353d5d ] read_string() writes into buf[BUFSIZ] one byte at a time without checking 'size' against the buffer bound before each write. A string longer than BUFSIZ in the input overflows the stack buffer. Add a bounds check before each write to prevent overflow. On overflow the function returns NULL, matching its other error paths. Fixes: 9215545e99d8 ("perf: Convert perf tracing data into a tracing_data event") Signed-off-by: Tanushree Shah Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b8ae06ccde3ff09411d23198db8c4b3754eb27b3 Author: Gerald Loacker Date: Sat Jul 25 18:56:03 2026 +0200 phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table [ Upstream commit 4fae43e33a7c10951fbdc6baf409d51bd66aaefb ] The rk1808 hsfreq table capped at 2499 Mbps, preventing a data rate of exactly 2500 Mbps. Extend the final entry to 2500 Mbps to support this rate. This is essential for RK3588 reusing this array and fully supporting rates up to 2500 Mbps. Fixes: bd1f775d6027 ("phy/rockchip: add Innosilicon-based CSI dphy") Reviewed-by: Michael Riesch Signed-off-by: Gerald Loacker Link: https://patch.msgid.link/20260725-feature-mipi-csi-dphy-4k60-v4-1-5b2c4626d31e@wolfvision.net Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 1489b694b1f3265cd5363100642a22190033f4b0 Author: Felix Gu Date: Mon Aug 3 23:15:17 2026 +0800 phy: sunplus: fix error handling in sp_uphy_init() [ Upstream commit 8b2683bc4cc18c581b7cd24f227cbe61abca7f4d ] Fix the error paths of sp_uphy_init() to undo exactly what each stage did: return directly if clk_prepare_enable() fails, release only the clock if reset_control_deassert() fails, and jump to err_reset if update_disc_vol() fails so the clock and reset are not leaked. Fixes: 99d9ccd97385 ("phy: usb: Add USB2.0 phy driver for Sunplus SP7021") Signed-off-by: Felix Gu Reviewed-by: Philipp Zabel Link: https://patch.msgid.link/20260803-sunplus-usb3-v1-1-5a562524c869@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit bf7fefbc26e292c08cfe7b6496b879109ef1475a Author: Biju Das Date: Thu Aug 6 11:22:27 2026 +0100 phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for disabled VBUS regulator [ Upstream commit 49c9b71b45081e5e5eeb507a2d6edb80d332dc59 ] devm_regulator_get_exclusive() initialises the regulator with enable_count = 1, requiring the consumer to disable it before release. The devm disable action was previously only registered when the caller explicitly requested enable, so when the regulator was left in its initial enabled state without an explicit enable call, the cleanup path skipped decrementing enable_count, triggering a WARN_ON during regulator release on device removal. Fix this by always registering the devm disable action based on the actual enabled state via regulator_is_enabled(), regardless of whether the caller requested an explicit enable. This covers both the explicitly enabled case and the initial state set by devm_regulator_get_exclusive(). Fixes: 24843404efe4 ("phy: renesas: phy-rcar-gen3-usb2: Control VBUS for RZ/G2L SoCs") Signed-off-by: Biju Das Link: https://patch.msgid.link/20260806102236.149159-9-biju.das.jz@bp.renesas.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b464367d7397ba98be6bad012f8fc7a1bb0c1931 Author: Tommaso Merciai Date: Mon Dec 22 14:43:46 2025 +0100 phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control [ Upstream commit b6d7dd157763e0c8937f60241fb4af9eb546a7fb ] Enable OTG VBUS control on R-Car Gen3 USB2 PHY by registering a regulator driver that manages the VBOUT line. This change allows the controller to handle VBUS output for OTG ports using the regulator framework when the platform requires hardware-based VBUS control. Without this, some platforms cannot properly manage VBUS power on OTG- capable ports, leading to potential USB functionality issues. Signed-off-by: Tommaso Merciai Link: https://patch.msgid.link/6c1aebf60b4d8ff0c51a8243c68b397c1a384867.1766405010.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Vinod Koul Stable-dep-of: 49c9b71b4508 ("phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for disabled VBUS regulator") Signed-off-by: Sasha Levin commit 733d3c1f3f51324ad43f74e464457b4fe11ca2b7 Author: Tommaso Merciai Date: Mon Dec 22 14:43:44 2025 +0100 phy: renesas: rcar-gen3-usb2: Factor out VBUS control logic [ Upstream commit d6db3b3af74a26b65d1ec1e86f9738c784e7ae29 ] Refactor the VBUS control logic into a new helper function to improve code clarity and reduce duplication. This makes it easier to handle different VBUS control register cases and aids future maintenance. Signed-off-by: Tommaso Merciai Link: https://patch.msgid.link/2d94c9876b965bdf7cd74cdbbc0c54689e122798.1766405010.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Vinod Koul Stable-dep-of: 49c9b71b4508 ("phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for disabled VBUS regulator") Signed-off-by: Sasha Levin commit 66ef9160e878af2a5925e4bdab57bc245cceb4a6 Author: Meghana Malladi Date: Mon Jul 6 14:52:29 2026 +0530 arm64: dts: ti: k3-am64: Fix MDIO clock reference for ICSSG0 node [ Upstream commit 197df050a10fe216971b45a79f07195c86a02236 ] MDIO clock index changed from 62:3 to 81:0 to match proper clock definition in the SoC device tree. Clock Id 81:0 belongs to ICSSG0 core clock, where as 62 belongs to EQEP2 device. See: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/clocks.html Fixes: c9087e3898a1d0 ("arm64: dts: ti: k3-am64-main: Add ICSSG nodes") Signed-off-by: Meghana Malladi Link: https://patch.msgid.link/20260706092229.82674-1-m-malladi@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 7c4c228b0cc3e2ad930ea9eb66a81031a2a5cc4a Author: Jan Kara Date: Mon Aug 3 18:00:38 2026 +0200 ext4: fix spurious message about orphan cleanup on RO fs [ Upstream commit 5aa98f874c013bcce9bb84ffded2f0ef886e4e33 ] When orphan_file feature is enabled, ext4_orphan_cleanup() was always walking through the orphan file looking for orphan inodes. This is mostly harmless but for read-only filesystem it results in spurious "orphan cleanup on readonly fs" message and in other cornercases it could result in similar somewhat misleading messages. Skip orphan cleanup if the orphan file is empty to avoid confusing messages. Fixes: 02f310fcf47f ("ext4: Speedup ext4 orphan inode handling") Reported-by: Tigran Aivazian Signed-off-by: Jan Kara Reviewed-by: Baokun Li Link: https://patch.msgid.link/20260803160037.64285-2-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit d2d543f9313fa31baa13509dba58bc38994eacf2 Author: Timur Kristóf Date: Mon Aug 3 15:23:00 2026 +0200 drm/amdgpu/gfx6: Fixup emit_cntxcntl() [ Upstream commit 1edb323406aaf05739804d2faa2561f2d43bcd09 ] Set bits on dword 2 like GFX7-8 except load_global_uconfig which doesn't exist on GFX6. Emit VS_PARTIAL_FLUSH before VGT_FLUSH like GFX7-8. For reference see old PAL which explains the bit fields in this register and that load_global_uconfig doesn't exist on GFX6 and also see gfx_v7_ring_emit_cntxcntl() for the GFX7 code which this commit follows. Fixes: 2cd46ad22383 ("drm/amdgpu: add graphic pipeline implementation for si v8") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 037d9babf6c6b1659573b538ef9662447846a970 Author: Steve Dunnagan Date: Fri Jul 24 14:04:12 2026 -0400 leds: gpio: Clear error pointers for skipped LEDs [ Upstream commit 942901eeda934f1bebf2605a781155e9d6bc7f6e ] gpio_led_get_gpiod() returns an error pointer when a platform-data LED's GPIO is unavailable. gpio_led_probe() skips registration in that case, but leaves the error pointer in led_dat->gpiod. The skipped entry remains included in priv->num_leds. During shutdown, gpio_led_shutdown() walks those entries and passes the error pointer to gpio_led_set(), producing: gpiod_set_value: invalid GPIO (errorpointer: -ENOENT) Clear led_dat->gpiod before skipping the LED so skipped entries do not retain error-valued descriptors. Fixes: 45d4c6de4e49 ("leds: gpio: Try to lookup gpiod from device") Suggested-by: Lee Jones Assisted-by: ChatGPT:GPT-5.5-Thinking Signed-off-by: Steve Dunnagan Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260724180412.43150-1-sdunnaga@redhat.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit b75f84c010274461e981bf0bb33c343a1452135f Author: Sven Peter Date: Sun Jul 19 15:00:32 2026 +0200 mfd: macsmc: Fix key count endianness annotation [ Upstream commit 0a29aa605286bcd01632eb6b61f59b9053312347 ] SMC firmware returns the value of the #KEY key in big-endian unlike most other keys. Reading it through apple_smc_read_u32() into a plain u32 and then converting with be32_to_cpu() makes sparse complain: drivers/mfd/macsmc.c:462:26: sparse: cast to restricted __be32 Read the raw value into a __be32 using apple_smc_read() instead. Fixes: e038d985c982 ("mfd: Add Apple Silicon System Management Controller") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202607181046.OANjIoqR-lkp@intel.com/ Signed-off-by: Sven Peter Reviewed-by: Janne Grunau Reviewed-by: Joshua Peisach Link: https://patch.msgid.link/20260719-b4-macsmc-be32-fix-v1-1-c7b1936307fa@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f59ccd8eeaa09cb40f914adcf5856093a359f345 Author: Pengpeng Hou Date: Mon Jul 20 19:54:23 2026 +0800 mfd: iqs62x: Reject zero-length firmware records [ Upstream commit 08ea045e0b82cbcadb7a2efc43a23561489a00f2 ] struct iqs62x_fw_rec includes the first data byte in its fixed-size header, so the parser advances by len - 1 bytes after that header. A zero len makes the size_t cursor update move back by one byte, so the next record overlaps the current record instead of following a valid declared extent. Reject zero-length records and express the remaining-size check without an offset addition. Fixes: 4d9cf7df8d35 ("mfd: Add support for Azoteq IQS620A/621/622/624/625") Signed-off-by: Pengpeng Hou Link: https://lore.kernel.org/all/20260706091034.75865-1-pengpeng@iscas.ac.cn/ Link: https://patch.msgid.link/20260720115423.94994-1-pengpeng@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 8ae4d0ff3e35723bd650e09fedc2b48d7e294612 Author: Pengpeng Hou Date: Mon Jul 20 19:55:23 2026 +0800 mfd: rave-sp: validate received frame payload lengths [ Upstream commit 0be718b5451bd83865d6e2a8d750ca7886c4772a ] A received RAVE-SP frame contains protocol data followed by a variant-specific one- or two-byte checksum. rave_sp_receive_frame() derives a checksum pointer before proving that the frame contains the checksum, then passes the checksum-inclusive length to handlers that index the command, acknowledgment ID and event-data bytes or derive a reply payload length. Name those protocol field offsets, prove the checksum extent before deriving the protocol-data length, pass only that data length to the handlers, and require the complete event or reply prefix before consuming it. Fixes: 538ee27290fa ("mfd: Add driver for RAVE Supervisory Processor") Signed-off-by: Pengpeng Hou Link: https://lore.kernel.org/all/20260706092337.78754-1-pengpeng@iscas.ac.cn/ Link: https://patch.msgid.link/20260720115523.99956-1-pengpeng@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 519e7de2c4c7b92ef57d4404b7e564aa9be24143 Author: Vladimir Murzin Date: Mon Jul 27 17:34:12 2026 +0100 arm64: hibernate: Restore DAIF state on error [ Upstream commit 541549827889d0380fd73f8aacb5de6ef7a5a1ac ] Sashiko AI has reported that if swsusp_mte_save_tags() for some reason fails we return from swsusp_arch_suspend() with DAIF being masked - that is not what we'd expect. Restore the saved DAIF state before returning from the error path. Fixes: ee11f332af96 ("arm64: mte: Save tags when hibernating") Signed-off-by: Vladimir Murzin Reviewed-by: Jinjie Ruan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 012823494e20c3cce622982ebd3fd6971be39ad2 Author: Ada Couprie Diaz Date: Mon Jul 27 17:34:11 2026 +0100 arm64: hibernate: mask DAIF before restoring hibernated kernel [ Upstream commit 684bde100117931f4c51c644a95f42f2dab041bc ] The arm64 hibernate code manages the exception masking in an unsound way, leading to potential crashes and/or warnings during resume. When a hibernation image is saved in `swsusp_arch_suspend()`, all DAIF exceptions are masked (by virtue of `local_daif_save()`), and the suspended image is saved assuming that all DAIF exceptions will remain masked when the image is restored. When a hibernation image is resumed by `swsusp_arch_resume()`, only interrupts are masked (by virtue of `local_irq_disable()` in `resume_target_kernel()`). When pseudo-NMI is enabled the DAIF.IF bits will be clear, and regardless of pseudo-NMI the DAIF.DA bits will be clear. This means that there are two problems: (1) It is possible to take Debug, SError, or pseudo-NMI exceptions during the resume process. This is unsafe, as during the resume process both the old ane new kernels will tranisently be in an inconsistent state, and swsusp_arch_suspend_exit() won't retain an executable mapping of any exception vectors. Any exception taken here will be fatal and silent. (2) When re-entering the resumed kernel, some DAIF bits will be clear unexpectedly. This permits Debug, SError, or pseudo-NMI exceptions to be taken for a short period while the resumed kernel is not yet in a consistent state. This is detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING. Avoid these issues by masking all DAIF exceptions during resume. Fixes: 82869ac57b5d ("arm64: kernel: Add support for hibernate/suspend-to-disk") Signed-off-by: Ada Couprie Diaz Signed-off-by: Vladimir Murzin Reviewed-by: Jinjie Ruan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 73979c96a3b8f4e461304b529795d469720b8a5e Author: Felix Fietkau Date: Tue Aug 4 08:26:08 2026 +0000 wifi: mac80211: skip default WMM setup for AP_VLAN links [ Upstream commit 4d8cfff012aaa971d50b01823b1015c1073c3ff6 ] AP_VLAN interfaces are never passed to the driver, so setting default WMM parameters on their links trips the check-sdata-in-driver warning in drv_conf_tx(), as well as in the BSS_CHANGED_QOS link info notification. Skip it, matching the existing AP_VLAN handling in this function. Fixes: 2259d14499d1 ("wifi: mac80211: set default WMM parameters on all links") Signed-off-by: Felix Fietkau Link: https://patch.msgid.link/20260804082608.2011433-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 48b5a520b80a746d40b95be0eb4b53a62e7b34a8 Author: Leon Romanovsky Date: Thu Aug 6 11:48:56 2026 +0300 RDMA/erdma: restrict the driver to little-endian systems [ Upstream commit a12d9145145b21c50531afb6e3f711b1f34e1465 ] The eRDMA device interface requires explicit byte ordering, but several DMA-visible values that should be little-endian remain native-endian. Command request payloads are copied verbatim, data-path SQE headers are written without cpu_to_le64(), and kernel doorbell records are assigned plain u64 values. The command completion path also reads a little-endian SQE header without conversion. These paths are byte-swapped on big-endian kernels and can break command processing during probe. Since complete big-endian support requires converting every device-visible structure, depend on !CPU_BIG_ENDIAN. Fixes: ca7fd6cff3b8 ("RDMA/erdma: Add driver to kernel build environment") Link: https://patch.msgid.link/20260806-missing-endianness-conversion-for-64-v1-1-896327c1aff1@nvidia.com Acked-by: Cheng Xu Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit b2709aad7599f6fd957939b60f4a8323c8f08072 Author: Petr Pavlu Date: Thu Aug 6 11:10:16 2026 +0200 module/dups: Fix use-after-free in kmod_dup_req lifetime handling [ Upstream commit 5eecb11b543f9f417bcf0dea239ff99c6af65dbd ] The kmod dups code uses RCU to ensure that a kmod_dup_req instance is freed only after it is no longer referenced. When releasing an instance, the kmod_dup_request_delete() function removes the kmod_dup_req from the dup_kmod_reqs list, waits via synchronize_rcu() and finally frees it. However, this doesn't work correctly because parallel users referencing the instance in kmod_dup_request_exists_wait() don't enter an RCU read-side critical section. This can result in a use-after-free. The kmod_dup_request_exists_wait() function may need to hold a valid reference to a kmod_dup_req instance across a blocking wait until the corresponding modprobe command completes. This makes it unsuitable for RCU. Fix the issue by changing the lifecycle management of kmod_dup_req to use reference counting. Fixes: 8660484ed1cf ("module: add debugging auto-load duplicate module support") Reviewed-by: Aaron Tomlin Signed-off-by: Petr Pavlu Signed-off-by: Sasha Levin commit ef7c354f7377fa452d7cfcf70839d9fe791a5598 Author: Petr Pavlu Date: Thu Aug 6 11:10:15 2026 +0200 module/dups: Inform duplicate requests about the result directly [ Upstream commit d258ed8a86bb46bbbbc84fb914478259a1e694a4 ] When kmod_dup_request_announce() announces the completion of a request_module() call to duplicate waiters, it queues a work item to invoke kmod_dup_request_complete(), and only that function calls complete_all(). This adds an arbitrary delay that is unnecessary and provides little benefit. Call complete_all() directly from kmod_dup_request_announce() instead. Signed-off-by: Petr Pavlu Stable-dep-of: 5eecb11b543f ("module/dups: Fix use-after-free in kmod_dup_req lifetime handling") Signed-off-by: Sasha Levin commit 11fa3f7ffd4f7122ceee4c154a057b0e3c8e9b82 Author: Naveen Kumar Chaudhary Date: Thu Jun 4 23:15:02 2026 +0530 module: use strscpy() to copy module names in stats and dup tracking [ Upstream commit 93c29ebd1622fb0670701e1c1b3a978a5cac08b7 ] Both try_add_failed_module() and kmod_dup_request_exists_wait() use memcpy() with strlen() to copy module names into fixed-size char[MODULE_NAME_LEN] buffers. Neither performs a bounds check on the copy. Current callers always pass names originating from mod->name (itself char[MODULE_NAME_LEN]), so this is not exploitable today. However both functions accept a plain const char * with no documented length contract, making them latent buffer overflows if a future caller passes a longer string. Replace memcpy() with strscpy() in both sites, which bounds the copy to MODULE_NAME_LEN and always NUL-terminates. Signed-off-by: Naveen Kumar Chaudhary Reviewed-by: Petr Pavlu Signed-off-by: Petr Pavlu Stable-dep-of: 5eecb11b543f ("module/dups: Fix use-after-free in kmod_dup_req lifetime handling") Signed-off-by: Sasha Levin commit ba7e83ce0b340137115753313c0a0f984ff54be6 Author: Marco Crivellari Date: Tue Nov 11 10:50:49 2025 +0100 module: replace use of system_wq with system_dfl_wq [ Upstream commit 581ac2d4a58b81669cc6abf645a558bce5cf14ab ] Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") Switch to using system_dfl_wq, the new unbound workqueue, because the users do not benefit from a per-cpu workqueue. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Reviewed-by: Petr Pavlu Signed-off-by: Sami Tolvanen Stable-dep-of: 5eecb11b543f ("module/dups: Fix use-after-free in kmod_dup_req lifetime handling") Signed-off-by: Sasha Levin commit de603f01d9ccf823e575b013ffd86ebedca9a8c5 Author: Shuangpeng Bai Date: Sat Aug 1 17:36:32 2026 -0400 RDMA/siw: Fix use-after-free in siw_accept() [ Upstream commit a9394971825933074032794a5feee5211509c774 ] siw_accept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it. The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association. Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint. Fixes: 6c52fdc244b5 ("rdma/siw: connection management") Signed-off-by: Shuangpeng Bai Link: https://patch.msgid.link/20260801213632.1086548-1-shuangpeng.kernel@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6c506fee5a5f2c8719c65bcfc5e5d0862b0a1946 Author: Yehyeong Lee Date: Fri Jul 31 13:12:12 2026 +0900 IB/isert: post the full-feature receive buffers after session registration [ Upstream commit 5247dde9daac7e107853b6fea043f7f47be033f7 ] isert_put_login_tx() posts the full-feature receive buffers before __transport_register_session() runs, so an initiator that does not wait for the final Login Response can still have a SCSI command executed against an se_session whose se_tpg is NULL - the same oops as the previous patch, at target_submit+0xbe. Post them from isert_get_rx_pdu(), which the previous patch already uses to send that response, and post them before that send: the receive queue is filled at the moment the initiator is told it may use it. Allocating there keeps the existing property that a memory allocation failure cannot happen once the final Login Response is on the wire. The receive queue is already empty between the final Login Request and isert_post_recvm(); this moves the second point later, from a median of 92 us to 172 us over 1200 logins. Only an initiator that sends before it has been told to can reach that window, and on IB and RoCE its send is retried there until the buffers appear - isert_rdma_accept() asks for rnr_retry_count = 7. iWARP has no RNR flow control, so there the same send terminates the connection instead. Measured over rxe, 400 login cycles per run, with an initiator that does not wait: an instrumented build counted no entries to isert_recv_done() before the buffers are posted in 10 runs, where that initiator oopsed 8 of 10 unpatched runs and 5 of 10 with only the previous patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260731041212.1733364-2-yhlee@isslab.korea.ac.kr Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a6c19af05c170f267eca1d01c3c72c84ba7860ae Author: Yehyeong Lee Date: Fri Jul 31 13:12:11 2026 +0900 IB/isert: delay the final Login Response until the session is registered [ Upstream commit 464f5afa92d071a226f88424803b0fcf88093ede ] isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260731041212.1733364-1-yhlee@isslab.korea.ac.kr Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit aaa66e60c0e21d19993a95bc3718dc29eb2d3192 Author: Karl Mehltretter Date: Thu Aug 6 07:02:39 2026 +0200 cpufreq: imx6q: fix out-of-bounds write when probed more than once [ Upstream commit 8c3afcf27fa4582c1ab912503dc8a4ebb8dc0f82 ] imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: imx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local. Fixes: b4573d1d657a ("cpufreq: imx6q: correct VDDSOC/PU voltage scaling when cpufreq is changed") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit e2d2612e63e294ebcdec7c6f08a1a052b7dfdc59 Author: Karl Mehltretter Date: Thu Aug 6 07:09:02 2026 +0200 cpufreq: imx6q: fix devres accumulation across driver rebind [ Upstream commit 22c23c72c3b21fa3ec3db5070dfc0582794e0ef9 ] imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system. Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver(). That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release. Tested by rebinding the driver on qemu's mcimx6ul-evk. Fixes: b4573d1d657a ("cpufreq: imx6q: correct VDDSOC/PU voltage scaling when cpufreq is changed") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit db0a49f0a37d4f6e9b5fc6443cee06c57bdc7847 Author: Priya Bala Govindasamy Date: Mon Jul 20 18:00:58 2026 +0000 rust: cpufreq: Fix temporary write in Registration::bios_limit_callback [ Upstream commit 19c76bdd3fc02475c73c8576f6f4a55ff07886f1 ] In `Registration::bios_limit_callback`, the expression `&mut (unsafe { *limit })` creates a reference to a temporary copy of the value pointed to by `limit` on the stack. Therefore, writes made by `T::bios_limit` go to this temporary instead of the memory location pointed to by `limit`. Additionally, `limit` may be uninitialized, such as when `Registration::bios_limit_callback` is invoked by `show_bios_limit` in drivers/cpufreq/cpufreq.c. Therefore creating a reference to `limit` is unsound. Fix this by changing the signature of `T::bios_limit` to return the limit value. `Registration::bios_limit_callback` can then update `limit` directly. Fixes: c6af9a1191d042839e56abff69e8b0302d117988 ("rust: cpufreq: Extend abstractions for driver registration") Reported-by: Dylan Zueck Reported-by: Yuan Tan Assisted-by: ChatGPT:gpt-5.4 Signed-off-by: Priya Bala Govindasamy [ Viresh: Fix rustfmtcheck warning ] Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 2973978781908aa4c677d6ce9dddec51d744102f Author: Priya Bala Govindasamy Date: Mon Jul 20 20:50:35 2026 +0000 rust: cpufreq: Add CPUFREQ_TABLE_END as last table entry in TableBuilder::to_table [ Upstream commit b5e4771f20a37fdf19eac0824bf062dffb4e291f ] The `TableBuilder::to_table` function adds `Hertz(c_ulong::MAX).as_khz()` as the last frequency entry in the frequency table. But the C API expects the last entry to have frequency set to `CPUFREQ_TABLE_END` which is `~1u` as per include/linux/cpufreq.h. Fix this by setting the last frequency entry to `CPUFREQ_TABLE_END` instead of `Hertz(c_ulong::MAX).as_khz()`. Fixes: 2207856ff0bc8d953d6e89bda70b8978c2de8bab ("rust: cpufreq: Add initial abstractions for cpufreq framework") Reported-by: Dylan Zueck Reported-by: Yuan Tan Assisted-by: ChatGPT:gpt-5.6-terra Signed-off-by: Priya Bala Govindasamy Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit b43a2518c3ecabc83c338c740f346ce78d0499a8 Author: Jernej Skrabec Date: Mon Aug 3 18:10:50 2026 +0200 drm/sun4i: hdmi-phy: Fix H6 8-bit MPLL config at 594 MHz [ Upstream commit 0ba6deddaae74f0539c0303bfb5f860adbe1a68b ] The 8-bit entry of the last MPLL row (594 MHz) doesn't lock reliably on H6. 4K@60 RGB/YUV444, which is the mode that reaches this entry, doesn't come up. Align the value with the vendor driver. Other entries are left alone, they are used by lower pixel clocks which work fine. Tested with 4K@60 on a LG TV. Fixes: 0fb4b858b102 ("drm/sun4i: Add support for H6 HDMI PHY") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/aec9060209473b8176eb43bc7c63c20b21306adf.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 46510c3e496b6ad514f4fc93687b611de173a7bd Author: Jernej Skrabec Date: Mon Aug 3 18:10:48 2026 +0200 drm/sun4i: dw-hdmi: Drop TCON TOP port reference [ Upstream commit d2a242e5688a17b79c89cd966cd31820c5096d80 ] When the HDMI controller is fed by TCON TOP, the port node used to enumerate the possible CRTCs is never released. Fixes: 57e23de02f48 ("drm/sun4i: DW HDMI: Expand algorithm for possible crtcs") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/43ffcc17f7c3f94c1d7bd1ee89134c766e84df35.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 17a588752ddf87d0681a9730144f7ce7eb48d917 Author: Jernej Skrabec Date: Mon Aug 3 18:10:47 2026 +0200 drm/sun4i: tcon: Drop remote endpoint reference [ Upstream commit 3f77e4072630e2301efdbe521e7fca10311043ec ] sun4i_tcon_of_get_id_from_port() never drops the reference taken by of_graph_get_remote_endpoint(). The function is not only called during bind, but also on every mode set through sun8i_r40_tcon_tv_set_mux(), so the leak accumulates. Fixes: e8d5bbf7f4c4 ("drm/sun4i: tcon: get TCON ID and matching engine with remote endpoint ID") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/3f5ec952ad80cb51efebf2fe230df50259041a23.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 65bc02fec98e4e1d7d59d86cf2ddf8fd73dacb89 Author: Jernej Skrabec Date: Mon Aug 3 18:10:46 2026 +0200 drm/sun4i: crtc: Propagate layer initialization error [ Upstream commit 7061ff05ed4a3cf16e83f7e3ad09cbd212508a32 ] sun4i_crtc_init() returns plain NULL when layer initialization fails, while all its other error paths return an error pointer. The only caller, sun4i_tcon_bind(), checks the result with IS_ERR() and happily continues with tcon->crtc set to NULL. sun4i_rgb_init() and sun4i_lvds_init() then dereference it in drm_crtc_mask(), which oopses. Return the error pointer instead. Fixes: dcd215801b02 ("drm/sun4i: Drop primary layer pointer from sun4i_drv") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/b26a0d427d9dfae9c82e3ca90a67d24d8ece5a28.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 50806c951a68cd70f4fbbb149225af568c3cb0f6 Author: Jernej Skrabec Date: Mon Aug 3 18:10:45 2026 +0200 drm/sun4i: hdmi: Don't leak sync polarity bits into packet control [ Upstream commit f5c3b1b0d228624786d22973a20c908c84e1a576 ] sun4i_hdmi_enable() keeps using the same variable after it programmed the video timing polarity register with it. The leftover TX_CLK, HSYNC and VSYNC bits are then ORed into the packet control register, where each nibble selects the packet type sent in one slot. As a result, slot 0 selects packet type 3 instead of the AVI infoframe whenever the mode has positive HSYNC polarity, and the TX_CLK bits set nibbles which the driver never programs. Assign the packet types instead of ORing them into the stale value. Fixes: 9ca6bc246035 ("drm/sun4i: hdmi: Move mode_set into enable") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/51ba0918ce016a4b45313d5df1b6ce31b8c8731e.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 1ca06d47ac40bdcb63e4e528499bf531c6c3231b Author: Jernej Skrabec Date: Mon Aug 3 18:10:44 2026 +0200 drm/sun4i: tcon: Drop TCON TOP device reference [ Upstream commit 8208832a38ff3d2560eb8a77a9d7a2f17d8ebcdc ] of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds. Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/871a3108086c15a483eef23301984c8d2254dfa7.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 425a414f9b5de01162df860175686a34ee599c73 Author: Jernej Skrabec Date: Mon Aug 3 18:10:43 2026 +0200 drm/sun4i: tcon: Set output mux for DSI and LVDS [ Upstream commit 9c90199b39637ad94253c4fd8e7b1333ca1d3e0d ] DSI and LVDS skip output mux setup, so TCON TOP cannot route the selected mixer. Configure them like other channel 0 outputs. In practice this matters for D1, where channel 0 TCONs are fed through TCON TOP. The remaining set_mux implementations only handle TMDS and return an error for other encoder types, as before. Fixes: b9b52d2f4aaf ("drm/sun4i: Add support for D1 TCONs") Signed-off-by: Jernej Skrabec Acked-by: Chen-Yu Tsai Link: https://patch.msgid.link/7e9dad9eed2e91a79c4e1202caa8fed7c2427531.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 6ec54d801440e5913677fa38293b7bc3b99e4d5d Author: Jernej Skrabec Date: Mon Aug 3 18:10:40 2026 +0200 drm/sun4i: vi scaler: Fix coefficient selection [ Upstream commit 5c31990b21f0b535732deb2b658b78b07464f56c ] Currently, vertical coefficients are selected based on horizontal scaling, which is wrong. Additionally, chroma coefficients should be selected based on format subsampling. Fix all that. Fixes: b862a648de3b ("drm/sun4i: Add support for HW scaling to DE2") Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/263a4a41442a3c8b072b170256b72658f1b90802.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 46a5fe1a43574e0b391d6c71c7e31aec32dd79b5 Author: Alexey Charkov Date: Wed Aug 5 17:45:09 2026 +0400 clk: rockchip: rk3576: fix source muxes for SPI0..SPI4 [ Upstream commit 586ff159ec02533c17dd928641529cb0b52e9c62 ] The TRM defines available source muxes for SPI0..SPI4 as - b00: clk_gpll_div6_src - b01: clk_gpll_div8_src - b10: clk_cpll_div10_src - b11: clk_xin_osc0_func Which doesn't match what the current clock driver implements, making it impossible to derive some SPI clock rates such as 37.125 MHz (which requires clk_gpll_div8_src as the source mux). Add a correct mux definition per TRM and point SPI0..SPI4 clocks at it. Fixes: cc40f5baa91b ("clk: rockchip: Add clock controller for the RK3576") Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260805-rk3576-spi-clk-v1-1-2f040d0d163b@flipper.net Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit aee687a2fb36974dc37e4e0f5b03802067c6c4ec Author: Cen Zhang Date: Wed Jun 24 17:53:09 2026 +0800 ocfs2: synchronize heartbeat callbacks with o2net teardown [ Upstream commit 3e326f3bf16506873777444608e8b715aab74a7a ] Patch series "ocfs2: harden heartbeat teardown races". This series fixes two OCFS2 heartbeat/o2net teardown races found by KASAN. This patch (of 2): Heartbeat callbacks stay registered while configfs local-node teardown enters o2net_stop_listening(). A node-down event can still run through o2net_disconnect_node() and o2net_set_nn_state() while teardown is destroying o2net_wq, so the later queue/flush operations can hit a dead workqueue. KASAN has caught this as a slab-use-after-free in __queue_work() with the call chain: KASAN slab-use-after-free in __queue_work+0x56/0xa90 Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __queue_work+0x56/0xa90 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __queue_delayed_work+0x58/0x1e0 queue_delayed_work_on+0xb4/0xc0 o2net_set_nn_state+0x467/0x840 o2net_disconnect_node+0x7b/0xe0 o2net_hb_node_down_cb+0x54/0x60 o2hb_run_event_list+0x236/0x2d0 o2hb_check_slot+0xad4/0xbc0 lock_release+0xc8/0x290 o2hb_check_slot+0x9ea/0xbc0 trace_hardirqs_on+0x18/0x130 o2hb_do_disk_heartbeat+0x646/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) __lock_acquire+0x466/0x2260 lockdep_hardirqs_on_prepare+0xea/0x1a0 ktime_get_with_offset+0xe9/0x230 o2hb_thread+0x14e/0x770 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 __switch_to+0x2e9/0x730 ret_from_fork_asm+0x1a/0x30 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x292/0x760 __alloc_workqueue+0x736/0xc60 alloc_workqueue_noprof+0xb1/0x110 o2net_start_listening+0xe5/0x430 o2nm_node_local_store+0x184/0x310 configfs_write_iter+0x18a/0x210 vfs_write+0x469/0x810 ksys_write+0xd2/0x170 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 rcu_core+0x4f4/0x1320 handle_softirqs+0x156/0x660 queue_delayed_work_on o2net_set_nn_state o2net_disconnect_node o2net_hb_node_down_cb o2hb_run_event_list Keep heartbeat callbacks registered so quorum state still tracks node state, but stop them from driving o2net reconnect/disconnect work once local teardown starts. Mark the transport offline before destroying o2net_wq, wait for any in-flight heartbeat callback to finish, and delay bring-up replay until the new local node is published through o2nm_this_node(). The replay also has to stay serialized with heartbeat callback delivery. Otherwise a live-node snapshot can be copied, a real hb_down callback can install -ENOTCONN for a peer, and the stale replay can call o2net_hb_node_up() for that same peer and queue reconnect work even though heartbeat is already down. The buggy scenario involves two paths, with each column showing the order within that path: local-node teardown: heartbeat node-down callback: 1. configfs local-off enters 1. o2hb_run_event_list() invokes o2net_stop_listening(). o2net_hb_node_down_cb(). 2. teardown heads for 2. the callback reaches destroy_workqueue(o2net_wq). o2net_disconnect_node() and o2net_set_nn_state(). 3. teardown destroys and NULLs 3. the callback flushes or queues o2net_wq. work through o2net_wq. Link: https://lore.kernel.org/20260624095310.763763-1-zzzccc427@gmail.com Link: https://lore.kernel.org/20260624095310.763763-2-zzzccc427@gmail.com Fixes: 98211489d414 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Cen Zhang Assisted-by: Codex:gpt-5.5 Reviewed-by: Joseph Qi Cc: Changwei Ge Cc: Heming Zhao Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit ba32c7d6129db9964ee85f91ba1837ffd8a0f6bd Author: Arnaldo Carvalho de Melo Date: Sun Aug 2 11:27:12 2026 -0300 perf libbfd: Fix memory leaks and NULL fclose in BPF disassembly [ Upstream commit fe3ab00d55aa56b4d55cbc1150448f0aadd6732c ] symbol__disassemble_bpf_libbfd() has four resource management bugs: 1. free(prog_linfo) leaks internal arrays. bpf_prog_linfo contains raw_linfo, raw_jited_linfo, nr_jited_linfo_per_func, and jited_linfo_func_idx pointers that are only freed by the proper destructor bpf_prog_linfo__free(). 2. open_memstream(&buf, &buf_size) allocates a dynamic buffer that the caller must free after fclose(). The function calls fclose(s) but never free(buf), leaking the stream buffer on every call. 3. args->line = strdup(srcline) is immediately consumed by disasm_line__new(args) which internally calls strdup(args->line) again via annotation_line__init(). The first strdup result is then overwritten by args->line = buf + prev_buf_size without being freed. 4. If open_memstream() fails, the error path jumps to 'out:' which calls fclose(s) with s == NULL — undefined behavior. Fix by using bpf_prog_linfo__free(), initializing buf to NULL, adding free(buf) after fclose(s), guarding fclose() against NULL, and removing the redundant strdup since annotation_line__init() makes its own copy. Fixes: 6987561c9e86eace ("perf annotate: Enable annotation of BPF programs") Reported-by: sashiko-bot Cc: Song Liu Reviewed-by: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 59cc63d244d934f193a576722eb30430975e5c17 Author: Arnaldo Carvalho de Melo Date: Sun Aug 2 11:27:11 2026 -0300 perf bpf: Add PROG_TAGS to required arrays in __bpf_event__print_bpf_prog_info() [ Upstream commit 38ba525335c4399b15c9be0f81de304e94ccb462 ] synthesize_bpf_prog_name() unconditionally dereferences prog_tags[sub_id] (line: u8 (*prog_tags)[BPF_TAG_SIZE] = (void *)(uintptr_t)(info->prog_tags)) but __bpf_event__print_bpf_prog_info() only requires JITED_KSYMS and JITED_FUNC_LENS in its required_arrays bitmask. If a crafted perf.data has the PROG_TAGS bit cleared (or the array was invalidated by bpil_offs_to_addr() bounds checking), info->prog_tags contains either zero or a raw file offset. Dereferencing it causes a NULL pointer dereference or an arbitrary memory read. Add PERF_BPIL_PROG_TAGS to required_arrays so the function returns early when prog_tags was not present or failed validation. Fixes: f8dfeae009effc0b ("perf bpf: Show more BPF program info in print_bpf_prog_info()") Reported-by: sashiko-bot Cc: Song Liu Reviewed-by: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit c473f3aa721e830fb92b293855834f4e70880045 Author: Arnaldo Carvalho de Melo Date: Sun Aug 2 11:27:09 2026 -0300 perf libbfd: Validate BPF prog info arrays before pointer cast [ Upstream commit 01765b456f850aed7475b37111f1c50bf76aaf51 ] symbol__disassemble_bpf_libbfd() casts info_linear->info.jited_prog_insns and info_linear->info.jited_ksyms to pointers without checking whether bpil_offs_to_addr() actually converted the file offsets. A crafted perf.data with PERF_BPIL_* bits unset but non-zero counts causes raw file offsets to be dereferenced as pointers. Add bitmask checks for PERF_BPIL_JITED_INSNS and PERF_BPIL_JITED_KSYMS before the casts, matching the validation added to bpf-event.c call sites. Fixes: 6987561c9e86 ("perf annotate: Enable annotation of BPF programs") Reported-by: sashiko-bot Cc: Song Liu Reviewed-by: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit c71f9a56520b419e55d173052629f2324deb5549 Author: Xie Yuanbin Date: Tue Jul 28 03:16:42 2026 +0100 ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults [ Upstream commit 1039bffd6ae9c75b42b7d148d6c1106134107b66 ] When CONFIG_DEBUG_USER=y, and cmdline "user_debug=31" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the "oops" state, acquiring a lock may risk a deadlock. Co-developed-by: Qi Xi Fixes: 6d021b724481 ("ARM: dump pgd, pmd and pte states on unhandled data abort faults") Link: https://lore.kernel.org/20260716014022.2823-1-xieyuanbin1@huawei.com Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Linus Walleij Signed-off-by: Qi Xi Signed-off-by: Xie Yuanbin Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 314f1a6762b5d51b37784ed7dc701d4c3d893703 Author: Linus Walleij Date: Sat Jul 4 21:15:55 2026 +0100 ARM: 9481/2: breakpoint: CFI breakpoints only on demand [ Upstream commit 8ed9bff906cf8036531d1559f10e82733a52b41f ] This removes the stub hw_breakpoint_cfi_handler() from ARM, making it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless CFI is actively used in the kernel. When not instrumenting with CFI, or when a breakpoint is issued in userspace, we fall through to return 1 from hw_breakpoint_pending() "unhandled fault" so userspace can make use of this breakpoint. Tested with LKDTM and this command line: echo CFI_FORWARD_PROTO > /sys/kernel/debug/provoke-crash/DIRECT still works as expected. Closes: https://lore.kernel.org/lkml/kJqktbpLphg_Pk5I5SPptgTLjl3E3eq5mN5UzCslyFj7Q1Irp-wDid4mj5eQVd2iZtRGXgeZd8goq195EkXdjyt864YMc8mVb2B9NGH91NQ=@protonmail.com/ Fixes: c3f89986fde7 ("ARM: 9391/2: hw_breakpoint: Handle CFI breakpoints") Reported-by: slipher Suggested-by: Mark Rutland Signed-off-by: Linus Walleij Signed-off-by: Russell King Signed-off-by: Sasha Levin commit dc2272c00d7c00ee2a69b57f7ca9caaefcbdb8cd Author: Yehyeong Lee Date: Wed Jul 29 18:32:03 2026 +0900 RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ [ Upstream commit 961ac0f0c5e414abdd6b33fae84b311d9fde0bd0 ] srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it: BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8) Without KASAN the returned bytes are whatever is next in the slab. One run returned ".strtab". rsp->data[3] in srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read. Fixes: bb12588a38e6 ("IB/srp: Implement SRP_CRED_REQ and SRP_AER_REQ") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260729093203.1503201-1-yhlee@isslab.korea.ac.kr Reviewed-by: Bart Van Assche Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ec987c0654651036dad6a42f7fa2a6d7c16a3687 Author: Cheng Xu Date: Thu Jul 30 20:43:54 2026 +0800 RDMA/erdma: Hold QP references for AE and CM processing [ Upstream commit a52eeff32024f190b3bdc99088c7becccd4fa60b ] AE QP fatal events and iWARP CM paths load QPs from dev->qp_xa and then use or reference them outside the xarray lock. erdma_destroy_qp() can drop the destroy-path reference and free QP resources while such a lookup is in flight. Add erdma_qp_get_by_qpn() to acquire a kref under the xarray lock with kref_get_unless_zero(). Remove the QP from the xarray before dropping the destroy-path reference so no new lookup can acquire it while destruction waits for existing users. Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation") Signed-off-by: Cheng Xu Link: https://patch.msgid.link/20260730124357.12976-2-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 1fc9c1933959d2776a1ce7bf424251b8b5b586cd Author: Cheng Xu Date: Thu Jul 30 20:43:53 2026 +0800 RDMA/erdma: Hold CQ references when processing EQ events [ Upstream commit 98df2aee1459ee1c62c70cbe9b370d2a532aea36 ] EQ handlers look up CQs from dev->cq_xa and invoke CQ completion or error callbacks outside the xarray lock. erdma_destroy_cq() can erase the CQ from the xarray and free its queue buffer and doorbell record while a previously scheduled EQ handler is still using the CQ. Add a CQ refcount and take a reference under the xarray lock with refcount_inc_not_zero(). Remove the CQ from the xarray before dropping the destroy-path reference, then wait for in-flight EQ users before releasing CQ resources. Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation") Signed-off-by: Cheng Xu Link: https://patch.msgid.link/20260730124357.12976-1-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 56ea0a1f9f93d738114d5ba1a8c42966e0053cd0 Author: Yuntao Wang Date: Wed Jul 29 15:17:37 2026 +0800 kbuild: fix modules.builtin(.modinfo) targets in the top-level Makefile [ Upstream commit 69ef27076d19297c0bf3bd22171fab8d87464a09 ] Commit 7a342e6c7735 ("kbuild: move modules.builtin(.modinfo) rules to Makefile.vmlinux_o") moved the modules.builtin(.modinfo) rules from link-vmlinux.sh to Makefile.vmlinux_o, and added the corresponding targets to the top-level Makefile. Commit 39cfd5b12160 ("kbuild: extract modules.builtin.modinfo from vmlinux.unstripped") later moved these rules from Makefile.vmlinux_o to Makefile.vmlinux, but left the corresponding targets in the top-level Makefile unchanged. These modules.builtin(.modinfo) targets in the top-level Makefile should be moved alongside the vmlinux target, since they are now generated by Makefile.vmlinux. However, simply removing these trivial targets might be a better choice, as it makes the Makefile cleaner and avoids the need to keep them in sync across multiple files, reducing the chance of future mistakes. Fixes: 39cfd5b12160 ("kbuild: extract modules.builtin.modinfo from vmlinux.unstripped") Signed-off-by: Yuntao Wang Reviewed-by: Nathan Chancellor Link: https://patch.msgid.link/20260729071737.818007-1-yuntao.wang@linux.dev Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit 933076eb1d3d68da5142fd850bea04ca954c9e43 Author: Robertus Diawan Chris Date: Wed Jun 24 11:47:42 2026 +0700 modpost: prevent leak when early return no suffix .o in read_symbols() [ Upstream commit 9a5b76027ed91680e10f90111d9cba300f96d1ab ] The allocation for elf info symsearch and hdr from parse_elf() haven't been released when return because of modname didn't have suffix ".o". And it seems like the suffix ".o" check did not depends on parse_elf() to succeed first. So, move the suffix ".o" check before checking parse_elf() result to prevent resource leak when the modname didn't have suffix ".o" and return early. This is reported by Coverity Scan as "Resource leak". Fixes: 8c9ce89c5b63 ("modpost: simplify mod->name allocation") Signed-off-by: Robertus Diawan Chris Reviewed-by: Nathan Chancellor Link: https://patch.msgid.link/20260624044742.144852-1-robertusdchris@gmail.com Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit 0fde935ae0ea966e8766c6836e7ce466b648f2fc Author: Sergei Litvin Date: Tue Jul 14 10:33:31 2026 +0200 scripts/tags.sh: Prevent binary files appearing in cscope.files [ Upstream commit a9b93c34625a27bed5dc0f80ee2a359ceb955172 ] When executing the command `make COMPILED_SOURCE=1 cscope`, the resulting `cscope.files` file contains filenames with the extensions *.rlib, *.rmeta, and *.so. To fix this, modify the regular expression in the `all_compiled_sources()` function so that only files with the extensions *.h, *.c, *.S, and *.rs are accepted. The issue has been introduced by commit 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely") which implemented the parsing of compiled sources from *.cmd files instead of using the "find" command. Fixes: 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely") Signed-off-by: Sergei Litvin Acked-by: Miguel Ojeda Tested-by: Nicolas Schier Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260714083331.69482-1-litvindev@gmail.com [nsc: cleaned-up commit message line breaks and removed cc trailers] Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit 804378ff0d62c89b5b88532d6bc48cc5233ff3a7 Author: Rafael J. Wysocki Date: Mon Aug 3 20:11:10 2026 +0200 intel_idle: Avoid using deep idle states during initialization [ Upstream commit 9eadbed788df453289b5927327bd22edb542f472 ] Commit c0f691388992 ("intel_idle: Use subsys_initcall_sync() for initialization") effectively made intel_idle initialize earlier which turns out to interfere with USB EHCI probing on some platforms [1]. Investigation led to the conclusion that this was related to allowing package idle states to be used earlier than before. Work around that issue by making intel_idle set a CPU latency QoS request to prevent package idle states from being used on all platforms supported by it for the duration of the device_initcall() initialization phase. Fixes: c0f691388992 ("intel_idle: Use subsys_initcall_sync() for initialization") Reported-by: Julian Silver Tested-by: Julian Silver Closes: https://lore.kernel.org/linux-acpi/3353bdf3-4f33-44b1-809b-b0378bee5816@gmail.com/ Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5120454.31r3eYUQgx@rafael.j.wysocki Signed-off-by: Sasha Levin commit 56450feb6f4854a0a422b981b6d53f88fcc045eb Author: Artem Bityutskiy Date: Tue Dec 16 10:04:01 2025 +0200 intel_idle: Add cmdline option to adjust C-states table [ Upstream commit 111f77a233484cf39a6317f4d0306387e9ffda7b ] Add a new module parameter that allows adjusting the C-states table used by the driver. Currently, the C-states table is hardcoded in the driver based on the CPU model. The goal is to have good enough defaults for most users. However, C-state characteristics, such as exit latency and residency, can vary between different variants of the same CPU model and BIOS settings. Moreover, different platform usage models and user preferences may benefit from different C-state target_residency values. Provide a way for users to adjust the C-states table via a module parameter "table". The general format is: "state1:latency1:target_residency1,state2:latency2:target_residency2,..." In other words, represent each C-state by its name, exit latency (in microseconds), and target residency (in microseconds), separated by colons. Separate multiple C-states by commas. For example, suppose a CPU has 3 C-states with the following characteristics: C1: exit_latency=1, target_residency=2 C1E: exit_latency=10, target_residency=10 C6: exit_latency=100, target_residency=500 Users can specify a custom C-states table as follows: 1. intel_idle.table="C1:2:2,C1E:5:20,C6:150:600" Result: C1: exit_latency=2, target_residency=2 C1E: exit_latency=5, target_residency=20 C6: exit_latency=150, target_residency=600 2. intel_idle.table="C6::400" Result: C1: exit_latency=1, target_residency=2 (unchanged) C1E: exit_latency=10, target_residency=10 (unchanged) C6: exit_latency=100, target_residency=400 (only target_residency changed) Signed-off-by: Artem Bityutskiy Link: https://patch.msgid.link/20251216080402.156988-3-dedekind1@gmail.com Signed-off-by: Rafael J. Wysocki Stable-dep-of: 9eadbed788df ("intel_idle: Avoid using deep idle states during initialization") Signed-off-by: Sasha Levin commit 33a5d2f00cac383e660e18bf32fc02eada2c9231 Author: Artem Bityutskiy Date: Tue Dec 16 10:04:00 2025 +0200 intel_idle: Initialize sysfs after cpuidle driver initialization [ Upstream commit ff24f314447a25164bac85cb310c382e289afdbe ] Reorder initialization calls to initialize the internal driver data before sysfs: Was: intel_idle_sysfs_init(); intel_idle_cpuidle_driver_init(); Now: intel_idle_cpuidle_driver_init(); intel_idle_sysfs_init(); Follow the general principle that drivers should initialize internal state before registering external interfaces like sysfs, avoiding potential usage before full initialization. Signed-off-by: Artem Bityutskiy Link: https://patch.msgid.link/20251216080402.156988-2-dedekind1@gmail.com Signed-off-by: Rafael J. Wysocki Stable-dep-of: 9eadbed788df ("intel_idle: Avoid using deep idle states during initialization") Signed-off-by: Sasha Levin commit 6ee7b00888498cf387dd30729e18a05328b94709 Author: Daniel Borkmann Date: Tue Aug 4 22:19:16 2026 +0200 bpf: Check load-acquire src ptr type before the load [ Upstream commit b87803391baa7e0bef60549d8841f12e549ad057 ] check_atomic_load() calls check_load_mem() before atomic_ptr_type_ok(). For a load-acquire that fetches into its own source register (dst_reg == src_reg), check_load_mem() overwrites src_reg's type with the type of the loaded value, so the subsequent atomic_ptr_type_ok() no longer sees the source pointer and fails to reject the disallowed types (ctx, pkt, flow_keys, sock). Since bpf_convert_ctx_accesses() does not rewrite atomic loads, the raw access to the underlying kernel object is left in place. The destination type is taken from the ctx access itself, so a load-acquire of the sk field of struct __sk_buff for example leaves the register typed as PTR_TO_SOCK_COMMON_OR_NULL, which type_is_sk_pointer() does not match either, while it actually holds unconverted struct sk_buff bytes. Once the NULL check has passed this is a type confusion, not just a leak of kernel data. Validate src_reg with check_reg_arg() and check the source pointer type with atomic_ptr_type_ok() before the load again, mirroring check_atomic_rmw(). Out-of-range register numbers are already rejected earlier by check_and_resolve_insns() (commit 503d21ef8eac ("bpf: Do register range validation early")), and the only exemption there, is_stack_arg_ldx(), requires BPF_LDX | BPF_MEM | BPF_DW and thus never matches a BPF_ATOMIC insn. atomic_ptr_type_ok() can therefore not dereference register state out of bounds, that is, the out-of-bounds read addressed by the Fixes commit below does not reappear (as proven also via selftest). Fixes: c03bb2fa327e ("bpf: Fix out-of-bounds read in check_atomic_load/store()") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260804201917.253491-1-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit cb0671ffce488dc2f54f9df7e31f704002c22250 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:20 2026 +0200 arm64: dts: qcom: sar2130p: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit 9d883d21fc12c873eee2f864f706c38a289bef59 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHY on this board, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 6339e41fa39b ("arm64: dts: qcom: sar2130p: add QAR2130P board file") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-22-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit af38023bc47dc252705603fd22f9442d31890232 Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:12 2026 +0200 arm64: dts: qcom: sm7225-fairphone-fp4: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit a3b3a060b696d964c769a7d9dc5835c79e4fe964 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHY on this board, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 4cbea668767d ("arm64: dts: qcom: sm7225: Add device tree for Fairphone 4") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Reviewed-by: Luca Weiss Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-14-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f068388689bea5d5f5133bd53e5fea9570741cad Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:09 2026 +0200 arm64: dts: qcom: qcs8550-aim300: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit c0ea3b6339881c2a5fff0830557b1279d9681036 ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHY on this board, feeding 1.2V to vdda-phy and 0.88V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 0b12da4e28d8 ("arm64: dts: qcom: add base AIM300 dtsi") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-11-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e70a165b79419ef13dc61d272ef18866a8cc805f Author: Manivannan Sadhasivam Date: Mon Aug 3 08:34:00 2026 +0200 arm64: dts: qcom: sc8280xp-blackrock: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies [ Upstream commit ff7155df9a9543af1eb9722563e6dcda33c1a97d ] The QMP PHY expects the vdda-phy supply to be around 0.88V and the vdda-pll supply to be 1.2V. But these two supplies are swapped for the USB QMP PHYs on this board, feeding 1.2V to vdda-phy and 0.9V to vdda-pll. Fix it by swapping the two supplies back. Fixes: 16a7fed11714 ("arm64: dts: qcom: sc8280xp-blackrock: dt definition for WDK2023") Reported-by: Konrad Dybcio Assisted-by: Claude:opus-4-8 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260803-phy-supply-fix-v1-2-5880630cde3e@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2fa866714f227109a9359dc298c08090fe7133ba Author: Sayali Patil Date: Wed Jul 8 12:29:07 2026 +0530 selftests/mm: fix ternary operator precedence in ksm_tests [ Upstream commit 4e1fbffb3333626682a011db7c4b4e9e40ba96d4 ] The KSM selftest uses conditional expressions to skip accesses to merge_across_nodes on systems without NUMA support. However, the ternary operator is combined with logical OR without parentheses: a || numa_available() ? 0 : b || c Due to operator precedence rules, this is parsed as: (a || numa_available()) ? 0 : (b || c) instead of the intended: a || (numa_available() ? 0 : b) || c Add parentheses around the conditional expressions to ensure the correct evaluation order. Link: https://lore.kernel.org/ce859430287ed2642848c933a90eb9a69da361f0.1783446924.git.sayalip@linux.ibm.com Fixes: 9aa1af954db0 ("selftests: vm: check numa_available() before operating "merge_across_nodes" in ksm_tests") Signed-off-by: Sayali Patil Acked-by: David Hildenbrand (Arm) Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 5cd78a904275a03b0c0608af8eb227c73c5532c8 Author: Sayali Patil Date: Wed Jul 8 12:29:06 2026 +0530 selftests/mm: fix ksm NUMA merge test for systems with memoryless NUMA nodes [ Upstream commit 15828a150c5806869b7feb9e38ad2c0284fbf18a ] The KSM NUMA merge test allocates identical pages on different NUMA nodes and verifies KSM behavior with merge_across_nodes enabled and disabled. On systems with memoryless NUMA nodes, for example: #numactl -H available: 2 nodes (0,4) ..... node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 node 0 size: 14825 MB node 0 free: 1382 MB node 4 cpus: node 4 size: 0 MB node 4 free: 0 MB the test may attempt to allocate memory on a node without memory, causing numa_alloc_onnode() to fail and resulting in a spurious test failure. The test currently checks numa_num_configured_nodes() to determine whether sufficient NUMA nodes are available. However, configured nodes do not necessarily have memory. Reuse the existing get_first_mem_node() and get_next_mem_node() helpers to locate NUMA nodes that actually contain memory, and skip the test when fewer than two such nodes are available. Before patch: --------------------------- running ./ksm_tests -N -m 1 --------------------------- mbind: Invalid argument ok 1 KSM NUMA merging Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 [PASS] ok 1 ksm_tests -N -m 1 --------------------------- running ./ksm_tests -N -m 0 --------------------------- mbind: Invalid argument not ok 1 KSM NUMA merging Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0 [FAIL] not ok 2 ksm_tests -N -m 0 # exit=1 After patch: --------------------------- running ./ksm_tests -N -m 1 --------------------------- At least 2 NUMA nodes with memory must be available ok 1 SKIP KSM NUMA merging Totals: pass:0 fail:0 xfail:0 xpass:0 skip:1 error:0 [PASS] ok 1 ksm_tests -N -m 1 --------------------------- running ./ksm_tests -N -m 0 --------------------------- At least 2 NUMA nodes with memory must be available ok 1 SKIP KSM NUMA merging Totals: pass:0 fail:0 xfail:0 xpass:0 skip:1 error:0 [PASS] ok 2 ksm_tests -N -m 0 Link: https://lore.kernel.org/78a3b0e3fb94004c0710872c5bab6f7381b7d63c.1783446924.git.sayalip@linux.ibm.com Fixes: e3820ab252dd ("selftest/vm: fix ksm selftest to run with different NUMA topologies") Co-developed-by: David Hildenbrand (Arm) Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Sayali Patil Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 335b75cfed44b69d835eb0ec25a921105a8d0a9e Author: Mike Rapoport (Microsoft) Date: Mon May 11 19:27:59 2026 +0300 selftests/mm: ksm_tests: use kselftest framework [ Upstream commit 4cc68d5f52de9614e2db70f43c52f012d1ebb5ad ] Convert ksm_tests to use kselftest framework for reporting and tracking successful and failing runs. Link: https://lore.kernel.org/20260511162840.375890-16-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Reviewed-by: Donet Tom Reviewed-by: Mark Brown Tested-by: Sarthak Sharma Tested-by: Luiz Capitulino Cc: Baolin Wang Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Jason Gunthorpe Cc: John Hubbard Cc: Lance Yang Cc: Leon Romanovsky Cc: Liam Howlett Cc: Li Wang Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Nico Pache Cc: Peter Xu Cc: Ryan Roberts Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton Stable-dep-of: 15828a150c58 ("selftests/mm: fix ksm NUMA merge test for systems with memoryless NUMA nodes") Signed-off-by: Sasha Levin commit 86ead176301109b78e1d14c0e9d0d9ff9723c769 Author: Pu Lehui Date: Mon Aug 3 01:39:34 2026 +0000 bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed [ Upstream commit 6655c409707ec8ce9ce0850ffe4fe02331fd4d9c ] A potential invalid storage access issue can occur after replacing a cgroup bpf prog. This occurs in the following scenario: 1. prog1 with storage is attached to a cgroup in multi-attach mode. 2. prog1 is replaced with prog2 using BPF_F_REPLACE in multi-attach mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or update_effective_progs). 3. A new prog3 is attached to the cgroup in multi-attach mode. The reason is that __cgroup_bpf_attach overwrites pl->storage with the new storage prior to attachment completion. When attachment fails midway, the cleanup path calls bpf_cgroup_storages_free(new_storage) to free the newly allocated storage, but fails to restore pl->storage back to old_storage. Consequently, the still-active prog1 holds invalid or dangling storage pointers, leading to an invalid memory access when prog1 executes and calls bpf_get_local_storage. Additionally, original pl->flags and cgrp->bpf.flags[atype] are left unrestored. Fix this by saving old_pl_flags, old_storage, and old_flags prior to the update, and properly restoring all of them in the cleanup path on error. Fixes: 7d9c3427894f ("bpf: Make cgroup storages shared between programs on the same cgroup") Reported-by: Sashiko Signed-off-by: Pu Lehui Signed-off-by: Andrii Nakryiko Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/20260803013934.4036646-1-pulehui@huaweicloud.com Signed-off-by: Sasha Levin commit 6fd220604f06c746760183df74b07384c3fdd660 Author: Mukesh Ojha Date: Mon Aug 3 17:13:31 2026 +0530 remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() [ Upstream commit bb840ea69347aff7bde5a208e7b5b180669a7656 ] table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression "table_sz - offset - sizeof(*hdr)", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic. Signed-off-by: Mukesh Ojha Fixes: fd2c15ec1dd3 ("remoteproc: resource table overhaul") Link: https://lore.kernel.org/r/20260803114331.3277263-6-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5a5ed571032e9c275a8075523f343818249ad019 Author: Mukesh Ojha Date: Wed May 6 10:31:04 2026 +0530 remoteproc: use rsc_table_for_each_entry() in rproc_handle_resources() [ Upstream commit 49abb5d6e1ac8169cdfc0c3aa4408e0d90ee5696 ] Replace the open-coded resource table iteration loop in rproc_handle_resources() with the rsc_table_for_each_entry() helper. The remoteproc-specific dispatch logic (vendor resource handling via rproc_handle_rsc(), RSC_LAST bounds check, handler table lookup) is moved into a local callback rproc_handle_rsc_entry(), keeping the iteration mechanics in one canonical place. The callback receives the payload offset within the table so that handlers which write back into the resource table (e.g. rproc_handle_carveout() recording a dynamically allocated address via rsc_offset) continue to work correctly. No functional change. Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260506050107.1985033-3-mukesh.ojha@oss.qualcomm.com Stable-dep-of: bb840ea69347 ("remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()") Signed-off-by: Sasha Levin commit a356d08d7151acc4d5f7ee78a6139b6813a59bd4 Author: Mukesh Ojha Date: Wed May 6 10:31:03 2026 +0530 remoteproc: Move resource table data structure to its own header [ Upstream commit 0590420c2f90de497d342c9a41a618f46f4d09ab ] The resource table data structure has traditionally been associated with the remoteproc framework, where the resource table is included as a section within the remote processor firmware binary. However, it is also possible to obtain the resource table through other means—such as from a reserved memory region populated by the boot firmware, statically maintained driver data, or via a secure SMC call—when it is not embedded in the firmware. There are multiple Qualcomm remote processors (e.g., Venus, Iris, GPU, etc.) in the upstream kernel that do not use the remoteproc framework to manage their lifecycle for various reasons. When Linux is running at EL2, similar to the Qualcomm PAS driver (qcom_q6v5_pas.c), client drivers for subsystems like video and GPU may also want to use the resource table SMC call to retrieve and map resources before they are used by the remote processor. In such cases, the resource table data structure is no longer tightly coupled with the remoteproc headers. Client drivers that do not use the remoteproc framework should still be able to parse the resource table obtained through alternative means. Therefore, there is a need to decouple the resource table definitions from the remoteproc headers. Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260506050107.1985033-2-mukesh.ojha@oss.qualcomm.com Stable-dep-of: bb840ea69347 ("remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()") Signed-off-by: Sasha Levin commit 90361f45ffe855fd3412375e1bc15cc89e9e0c70 Author: Imran Shaik Date: Sat Jul 18 18:26:19 2026 +0530 arm64: dts: qcom: agatti: Add missing CX power domain to DISPCC [ Upstream commit 26d7b23caa4b1d8208e28c5981a85cf83e658e7c ] Add the missing power-domains property to associate DISPCC with CX rail. This is to ensure the genpd performance state votes on the GDSC to get propagated to the CX rail and to avoid the rail under-voltage conditions. Fixes: a2b32096709d ("arm64: dts: qcom: qcm2290: Add display nodes") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Imran Shaik Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-12-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9063b30faae8ccaacf003735560df3956dbb592f Author: Andreas Kemnade Date: Thu Jul 2 17:27:11 2026 +0200 drm/omap: dsi: Do not copy isr table [ Upstream commit 97c03b32b28a9f7f13f768f2b06e1eaafe850e66 ] To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table. Fixes: 4ae2ddddf44cd ("OMAP: DSS2: DSI: Add ISR support") Signed-off-by: Andreas Kemnade Link: https://patch.msgid.link/20260702-dsi-uaf-v2-1-dbb4aa0f0b8e@kemnade.info Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit d1cfbccccad7d56943bb71415f4237600e25c402 Author: Inochi Amaoto Date: Mon May 11 14:38:17 2026 +0800 riscv: dts: sophgo: cv180x: Allow the DMA multiplexer to set channel number for DMA controller [ Upstream commit 5011466bade64483bb52bc4a926719d6794e6dab ] Change the DMA controller compatible to the sophgo,cv1800b-axi-dma, which supports setting DMA channel number in DMA phandle args. This dts change does not break backward compatibility as a fallback compatiable string is added. Fixes: 514951a81a5e ("riscv: dts: sophgo: cv18xx: add DMA controller") Reported-by: Anton D. Stavinskii Closes: https://github.com/sophgo/linux/issues/9 Tested-by: Anton D. Stavinskii Link: https://patch.msgid.link/20260511063818.463877-3-inochiama@gmail.com Signed-off-by: Inochi Amaoto Signed-off-by: Chen Wang Signed-off-by: Sasha Levin commit 571ea4263d69df1b48578e4314a828ecd0604755 Author: Yichong Chen Date: Wed Jul 15 10:09:57 2026 +0800 fat: release buffer head after rebuilding parent [ Upstream commit 83e98dbf19ab64e8528e101e20f8d50e1aaa68a8 ] fat_scan_logstart() leaves the matching directory entry's buffer head in sinfo.bh for the caller to release, just like fat_scan(). fat_rebuild_parent() uses the directory entry to rebuild the parent inode for the nostale_ro NFS export path, but does not release sinfo.bh after a successful scan. Release it once fat_build_inode() has consumed the directory entry data. Link: https://lore.kernel.org/20260715020957.1096309-1-chenyichong@uniontech.com Fixes: f1e6fb0ab451 ("fat (exportfs): rebuild directory-inode if fat_dget()") Signed-off-by: Yichong Chen Acked-by: OGAWA Hirofumi Cc: Christian Brauner Cc: Amit Sahrawat Cc: chenyichong Cc: Namjae Jeon Cc: Ravishankar N Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 44a37264b26911e13d0a4f5630751c4157ed0354 Author: Guangshuo Li Date: Wed Jul 8 15:06:28 2026 +0800 rapidio: clear mport->net when rio_add_net() fails [ Upstream commit b74030fbf187b43c1f85b66a7082e9946511cb5d ] rio_alloc_net() stores the newly allocated rio_net in mport->net before rio_scan_alloc_net() registers the device. If rio_add_net() fails, rio_scan_alloc_net() drops the device reference with put_device(), which releases the rio_net through the device release callback. However, mport->net is left pointing at the freed object. A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rio_net again. Clear mport->net in the rio_add_net() failure path, matching the cleanup done for the destID table allocation failure path. Link: https://lore.kernel.org/20260708070628.721010-1-lgs201920130244@gmail.com Fixes: e842f9a1edf3 ("rapidio: add check for rio_add_net() in rio_scan_alloc_net()") Signed-off-by: Guangshuo Li Cc: Alexandre Bounine Cc: Matt Porter Cc: Yang yingliang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 9df662fcac6fe15a77af2861409078ebe169cf69 Author: Calvin Owens Date: Mon Jul 6 10:19:07 2026 -0700 pps-gpio: remove dead capture_clear code [ Upstream commit b899e0279f90c3ce4099d68b989dd27861cc5c4f ] The capture_clear field is never set, and all code conditional on it being set has been unreachable since the platform data logic was removed from pps-gpio in ee89646619ba ("pps: clients: gpio: Get rid of legacy platform data"). I think the only logical thing to do here is to remove it all, since no in-tree code ever actually used it in the first place, and it has been completely dead code for over five years (since v5.13). Sashiko asked some questions about the gpiod_get_value() call which caused me to look deeper and figure this out, but it did not actually notice capture_clear is never set. Link: https://lore.kernel.org/f70196bafcf75d9782dd36ed784e42345b6e8a1b.1783355507.git.calvin@wbinvd.org Fixes: ee89646619ba ("pps: clients: gpio: Get rid of legacy platform data") Signed-off-by: Calvin Owens Closes: https://sashiko.dev/#/patchset/cover.1779733602.git.calvin%40wbinvd.org?part=1 Acked-by: Rodolfo Giometti Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 599d4c92aa0b40687b3a2e9604265472f4296c69 Author: Michael Byczkowski Date: Mon Jun 1 17:44:09 2026 -0700 pps: pps-gpio: split IRQ handler into hardirq timestamper + threaded handler [ Upstream commit 93781560b2fdd26fa8499d64db8a95a07e1dc902 ] Split the pps-gpio interrupt handler into a primary (hardirq) handler that captures the PPS timestamp at interrupt entry, and a threaded handler that processes the event. This produces the same two-part handler structure on both PREEMPT_RT and non-RT kernels. On non-RT kernels the threaded portion runs immediately after the primary, with no behavioral change compared to the previous single-handler implementation. On PREEMPT_RT, where interrupt handlers are force-threaded by default, the previous single-handler implementation captured the timestamp inside the threaded portion, after IRQ-thread scheduling delay. With the split, the timestamp is captured in true hardirq context as it is on non-RT kernels, eliminating a significant source of PPS jitter on RT systems. Link: https://lore.kernel.org/2e32729029fbf6977ecf04665eb00f2efd3e2c17.1780359378.git.calvin@wbinvd.org Signed-off-by: Michael Byczkowski Signed-off-by: Calvin Owens Reviewed-by: Sebastian Andrzej Siewior Tested-by: Michael Byczkowski Tested-by: Calvin Owens Acked-by: Rodolfo Giometti Signed-off-by: Andrew Morton Stable-dep-of: b899e0279f90 ("pps-gpio: remove dead capture_clear code") Signed-off-by: Sasha Levin commit e31ff723811eedd09ffe8775c918820e89bb75ea Author: Calvin Owens Date: Fri Jun 12 11:52:09 2026 -0700 pps: don't try to wait for negative timeouts in PPS_FETCH [ Upstream commit 45217e98987a87ff2372386dbf82fd5325db28ea ] If userspace passes a negative timeout to PPS_FETCH, it triggers a kernel splat from schedule_timeout(): schedule_timeout: wrong timeout value fffffffffff0bfb4 CPU: 17 UID: 0 PID: 4720 Comm: a.out Not tainted 7.1.0-rc5-x86-kvm-00150-g331d97e36b37 #1 PREEMPT_RT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-20240910_120124-localhost 04/01/2014 Call Trace: dump_stack_lvl+0x4b/0x70 schedule_timeout+0xb7/0xe0 pps_cdev_pps_fetch.isra.0+0x93/0x150 pps_cdev_ioctl+0x70/0x310 __x64_sys_ioctl+0x7b/0xc0 do_syscall_64+0xb6/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Here is a trivial reproducer that works with the PPS_CLIENT_KTIMER test device enabled in the kernel: #include #include #include #include #include #include int main() { struct pps_fdata fdata; int fd; fd = open("/dev/pps0", O_RDWR); if (fd == -1) err(1, "Failed to open /dev/pps0"); fdata.timeout.sec = -1; fdata.timeout.nsec = 0; if (ioctl(fd, PPS_FETCH, &fdata)) err(2, "PPS_FETCH failed"); close(fd); return 0; } Sashiko imagines this to be some sort of security problem, which is obviously really silly. But I think it is still worth fixing, so buggy userspace code can't trigger the splat. Silence the splat by using timespec64_to_jiffies(), which hard limits the timeout to LONG_MAX jiffies. To be safe, explicitly preserve the -ETIMEDOUT return value userspace sees today if it passes a negative timeout. If you really squint, this is still a slight behavior change in that there are "denormalized" combinations of tv_sec and tv_nsec which used to work but will now return -ETIMEDOUT. I can't imagine anybody will care about that... Link: https://lore.kernel.org/c5c97c3b3c9d66010382094fd538e59a38f4aacf.1781289959.git.calvin@wbinvd.org Fixes: eae9d2ba0cfc ("LinuxPPS: core support") Signed-off-by: Calvin Owens Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/cover.1779733602.git.calvin%40wbinvd.org?part=3 Acked-by: Rodolfo Giometti Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f637a83115b32b0b5894a33ff520dc3c0c50756e Author: Bradley Morgan Date: Sun Jun 21 12:11:33 2026 +0000 lib/string: fix memchr_inv() for large ranges [ Upstream commit c04cffb8c51618538f0c05c478a931eb6e1a806b ] memchr_inv() takes a size_t length but counts 8 byte words in an unsigned int. At 32GiB that count wraps, so the scan can quietly miss most of the range. Use size_t for the word count. Link: https://lore.kernel.org/20260621121133.16460-1-include@grrlz.net Fixes: 798248206b59 ("lib/string.c: introduce memchr_inv()") Signed-off-by: Bradley Morgan Cc: Akinbou Mita Cc: Andy Shevchenko Cc: Christoph Lameer Cc: Joern Engel Cc: Kees Cook Cc: Pekka Enberg Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8abb2b7c60d2b2c0f40606048c873096c03874d2 Author: Cen Zhang Date: Tue Jun 16 15:49:31 2026 +0800 ocfs2/cluster: keep heartbeat local node stable [ Upstream commit 688bc88e2046dd6ce81ce18079b5254cb8dadc0e ] o2nm_node_local_store() handles local=0 by stopping o2net and setting cl_local_node to O2NM_INVALID_NODE_NUM, but it leaves cl_has_local set. That stale state makes o2nm_this_node() return 255, blocks a later local=1 attempt with -EBUSY, and can feed 255 to heartbeat users that call o2nm_this_node() dynamically. Clearing cl_has_local is required when the local node is reset. But heartbeat threads can still be running at that point. They pin the local node config item at startup, yet o2hb_do_disk_heartbeat() and thread teardown re-read o2nm_this_node() for the local slot and for o2nm_undepend_this_node(). Once local=0 has cleared the live local-node state, those dynamic reads return O2NM_MAX_NODES, which is also the invalid node number 255. Store the local node number in the heartbeat region when the region starts. Use that stable node for heartbeat slot writes/checks, negotiation messages, and the final configfs undepend. Stop the heartbeat loop when the current local node no longer matches the stored node, and clear cl_has_local together with cl_local_node in the local=0 path so nodemanager state matches node removal. Validation reproduced this kernel report: KASAN slab-out-of-bounds in o2hb_do_disk_heartbeat+0x372/0xb30 RIP: 0010:memset+0xf/0x20 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xd0/0x630 o2hb_do_disk_heartbeat+0x372/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x188/0x2f0 kasan_report+0xe4/0x120 o2hb_do_disk_heartbeat+0x5/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) o2hb_thread+0x14e/0x770 kthread_affine_node+0x139/0x180 lockdep_hardirqs_on_prepare+0xda/0x190 trace_hardirqs_on+0x18/0x130 kthread+0x19d/0x1e0 ret_from_fork+0x37a/0x4d0 __switch_to+0x2d5/0x6f0 ret_from_fork_asm+0x1a/0x30 Link: https://lore.kernel.org/20260616074931.3774929-1-zzzccc427@gmail.com Fixes: a7f6a5fb4bde ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Suggested-by: Joseph Qi Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit b55e7e61c5c195734f9f95f9e8ef94919dd6f3f8 Author: Caleb Sander Mateos Date: Wed Jul 29 11:10:40 2026 -0600 ublk: check for ublk_unmap_io() returning 0 [ Upstream commit 24fd3706178f1ae5501fd1ff9036e170ed0665ba ] If the userspace ublk server passes an unmapped address as the data buffer for a completed ublk read, ublk_unmap_io() will return 0 indicating no bytes could be copied. Currently, this will result in calling blk_update_request() with nr_bytes=0, which doesn't seem supported. Fail the I/O with BLK_STS_IOERR in this case instead. Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Signed-off-by: Caleb Sander Mateos Link: https://patch.msgid.link/20260729171041.45061-3-csander@purestorage.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0121c84adb6a4cd6f7560b5895bd88f9899bbc1f Author: Caleb Sander Mateos Date: Wed Jul 29 11:10:39 2026 -0600 ublk: check import_ubuf() return value [ Upstream commit 3831568792af75b6523fa93bb91560e29189cf55 ] import_ubuf() can fail if the address range (provided by the userspace ublk server) is outside the allowed user address space. Return that 0 bytes were copied if import_ubuf() fails rather than passing an uninitialized struct iov_iter to ublk_copy_user_pages(). Fixes: 981f95a571e3 ("ublk: cleanup ublk_copy_user_pages") Reported-by: Ming Lei Signed-off-by: Caleb Sander Mateos Link: https://patch.msgid.link/20260729171041.45061-2-csander@purestorage.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b4e971c80e64fce6022a8431b49011805e7ff275 Author: Tao Cui Date: Mon Jul 20 17:37:26 2026 +0800 block/kyber-iosched: flush per-cpu latency buckets over possible CPUs [ Upstream commit 482fc257de95ab181688e9d1dfcc6b6a58857b1e ] kyber_timer_fn() sums the per-cpu latency histograms with for_each_online_cpu(). A CPU that goes offline mid-interval leaves its bucket un-flushed; the samples are lost from the current decision and re-appear (stale) when the CPU is onlined again. Fixes: 6e25cb01ea20 ("kyber: implement improved heuristics") Signed-off-by: Tao Cui Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260720093726.28965-5-cui.tao@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7c25949cee2f06203f40fe8d1816aaa0c969f16f Author: Tao Cui Date: Mon Jul 20 17:37:25 2026 +0800 block/blk-iocost: collect per-cpu latency stats over possible CPUs [ Upstream commit 4e050c5b92c1600415b2cd452583e543036f3d73 ] ioc_lat_stat() walks ioc->pcpu_stat with for_each_online_cpu() to compute missed-ppm and rq_wait deltas. An offlined CPU is skipped, so its delta is dropped from the period and its last_* watermark is not advanced; on re-online the next collection sees a delta spanning the whole offline interval, corrupting the latency/vrate picture. Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Signed-off-by: Tao Cui Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260720093726.28965-4-cui.tao@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 55bda3de92f8c0070b07f0bff83938b2b72e3984 Author: Tao Cui Date: Mon Jul 20 17:37:23 2026 +0800 block/blk-stat: drain per-cpu callback stats over possible CPUs [ Upstream commit 9d617828cfc4d9a4d385daa2cd61f9db0592c53f ] blk_stat_timer_fn() sums and resets a callback's per-cpu buckets using for_each_online_cpu(). A CPU that goes offline with pending samples is skipped, so its samples are neither accumulated into the window nor cleared; they sit in the bucket until the CPU comes back online, at which point the stale values are flushed into whatever window is then running. This silently corrupts the latency picture that consumers (notably writeback throttling via wbt, and blk-mq latency tracking) base decisions on around CPU hotplug: under-counting while the CPU is offline, then a burst of stale data on re-online. Fixes: 34dbad5d26e2 ("blk-stat: convert to callback-based statistics reporting") Signed-off-by: Tao Cui Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260720093726.28965-2-cui.tao@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3d8c3da95c75a4d312e272fc7b4076dd3ba9115c Author: Zheng Qixing Date: Sun Aug 2 19:25:19 2026 +0800 blk-cgroup: skip dying blkg in blkcg_activate_policy() [ Upstream commit 5e9220389920f33b6a804d50c548cd0cd1b04634 ] When switching IO schedulers on a block device, blkcg_activate_policy() can race with concurrent blkcg deletion, leading to a use-after-free in rcu_accelerate_cbs. T1: T2: blkg_destroy kill(&blkg->refcnt) // blkg->refcnt=1->0 blkg_release // call_rcu(__blkg_release) ... blkg_free_workfn ->pd_free_fn(pd) elv_iosched_store elevator_switch ... iterate blkg list blkg_get(blkg) // blkg->refcnt=0->1 list_del_init(&blkg->q_node) blkg_put(pinned_blkg) // blkg->refcnt=1->0 blkg_release // call_rcu again rcu_accelerate_cbs // uaf Fix this by checking hlist_unhashed(&blkg->blkcg_node) before getting a reference to the blkg. This is the same check used in blkg_destroy() to detect if a blkg has already been destroyed. If the blkg is already unhashed, skip processing it since it's being destroyed. Fixes: f1c006f1c685 ("blk-cgroup: synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()") Signed-off-by: Zheng Qixing Reviewed-by: Tang Yizhou Signed-off-by: Yu Kuai Reviewed-by: Tao Cui Reviewed-by: Nilay Shroff Link: https://patch.msgid.link/20260802112525.3933753-4-yukuai@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ac34e655dffa74349d885a43d098115336f53842 Author: Zheng Qixing Date: Sun Aug 2 19:25:18 2026 +0800 blk-cgroup: fix race between policy activation and blkg destruction [ Upstream commit 5313d4d41739b0cb63000747c97bb1217ac45f3e ] When switching an IO scheduler on a block device, blkcg_activate_policy() allocates blkg_policy_data (pd) for all blkgs attached to the queue. However, blkcg_activate_policy() may race with concurrent blkcg deletion, leading to use-after-free and memory leak issues. The use-after-free occurs in the following race: T1 (blkcg_activate_policy): - Successfully allocates pd for blkg1 (loop0->queue, blkcgA) - Fails to allocate pd for blkg2 (loop0->queue, blkcgB) - Enters the enomem rollback path to release blkg1 resources T2 (blkcg deletion): - blkcgA is deleted concurrently - blkg1 is freed via blkg_free_workfn() - blkg1->pd is freed T1 (continued): - Rollback path accesses blkg1->pd->online after pd is freed - Triggers use-after-free In addition, blkg_free_workfn() frees pd before removing the blkg from q->blkg_list. This allows blkcg_activate_policy() to allocate a new pd for a blkg that is being destroyed, leaving the newly allocated pd unreachable when the blkg is finally freed. Fix these races by extending blkcg_mutex coverage to serialize blkcg_activate_policy() rollback and blkg destruction, ensuring pd lifecycle is synchronized with blkg list visibility. Fixes: f1c006f1c685 ("blk-cgroup: synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()") Signed-off-by: Zheng Qixing Reviewed-by: Tang Yizhou Signed-off-by: Yu Kuai Reviewed-by: Tao Cui Reviewed-by: Nilay Shroff Link: https://patch.msgid.link/20260802112525.3933753-3-yukuai@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c4487e4d5309de587479ecc2f5173b49586f46f4 Author: Breno Leitao Date: Wed Jul 29 02:29:47 2026 -0700 phonet: pep: do not write beyond optlen in getsockopt [ Upstream commit 77e5eb0e192aec6710c03ca8144582fd2af36ca4 ] pep_getsockopt() clamps the reported length to the caller's buffer with min_t(), but then stores the value with put_user(val, (int __user *) optval), which always writes sizeof(int) bytes. A getsockopt() call with an optlen smaller than sizeof(int) thus reports the clamped length yet writes a full int, one to three bytes past the user buffer. Write the value with copy_to_user() bounded by len, so at most optlen bytes are copied, matching the length reported back to userspace. Fixes: 02a47617cdce ("Phonet: implement GPRS virtual interface over PEP socket") Acked-by: Rémi Denis-Courmont Reviewed-by: Joe Damato Acked-by: Stanislav Fomichev Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260729-getsockopt_phase4-v4-4-c44576757c17@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f16c2c3932ce7ebc2da37d249e5119070077578a Author: Zxyan Zhu Date: Wed Jul 29 15:42:36 2026 +0800 net: stmmac: Skip PHY attach if custom PCS is in use [ Upstream commit af4d934164457f0578bf90e92ae0fcc5348260cb ] When a platform provides a custom PCS via the pcs_init callback, the MAC's phylink_pcs is already configured. In this case, no traditional PHY device is needed. Without this, stmmac_init_phy() falls through to the no-phy-node path and errors out with "no phy found" when the DT has no phy-handle for such interfaces. Skip the PHY attach when priv->hw->phylink_pcs is set and phy_addr is invalid. Fixes: f0ef433fc264 ("net: stmmac: introduce pcs_init/pcs_exit stmmac operations") Signed-off-by: Zxyan Zhu Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260729074237.2624940-2-zxyan0222@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c65d67b08bab47a6bc908bc0ca5aa725b55b26ef Author: Sang-Heon Jeon Date: Tue Jul 28 03:47:39 2026 +0900 iio: light: tsl2583: return zero in write_raw() on success [ Upstream commit 42e8791841e0677418a3ccc97fa5c22a1455f417 ] tsl2583_write_raw() returns the value of pm_runtime_put_autosuspend(), which is 1 if the device is already runtime suspended. In that case write() on the sysfs attribute returns 1 instead of the number of bytes written. Make tsl2583_write_raw() always return zero on success. Fixes: 371894f5d1a0 ("iio: tsl2583: add runtime power management support") Signed-off-by: Sang-Heon Jeon Reviewed-by: Brian Masney Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7a6a9bc87c6ee1d658560ea9d097c60bb551eb13 Author: Sang-Heon Jeon Date: Tue Jul 28 03:47:38 2026 +0900 iio: light: isl29028: return zero in write_raw() on success [ Upstream commit 55b75622829779223b9e32aa9600a8651d3e2df4 ] isl29028_write_raw() returns the value of pm_runtime_put_autosuspend(), which is 1 if the device is already runtime suspended. In that case write() on the sysfs attribute returns 1 instead of the number of bytes written. Make isl29028_write_raw() always return zero on success. Fixes: 2db5054ac28d ("staging: iio: isl29028: add runtime power management support") Signed-off-by: Sang-Heon Jeon Reviewed-by: Brian Masney Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 1e628f7ce4bc2620b871eadce288c9754c728fa2 Author: Yuanshen Cao Date: Fri Jul 24 23:46:01 2026 +0000 iio: light: tsl2772: fix ALS calibscale readback [ Upstream commit ac75550ab5b5d73649bffea245c2075fd9249bd0 ] The read_raw() implementation uses IIO_LIGHT to distinguish between the ambient light and proximity channels when handling IIO_CHAN_INFO_CALIBSCALE. However, the ALS channel is registered as IIO_INTENSITY, while write_raw() correctly writes to IIO_INTENSITY. As a result, reading in_intensity0_calibscale incorrectly returns the proximity gain instead of the ALS gain. This causes the following user-visible behavior: - Writing in_intensity0_calibscale appears to have no effect because the readback reports the proximity gain. - Writing in_proximity0_calibscale causes both in_proximity0_calibscale and in_intensity0_calibscale to report the same value. Fix this by checking for IIO_INTENSITY in read_raw(), matching the channel definition and the existing write_raw() implementation. Fixes: 3c97c08b5735 ("staging: iio: add TAOS tsl2x7x driver") Signed-off-by: Yuanshen Cao Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 6c98ec4447d2c291112b09c70e055dac6c4608d1 Author: Arnaldo Carvalho de Melo Date: Mon Jul 27 13:17:05 2026 -0300 perf arm-spe: Reject zero nr_cpu in metadata to prevent division by zero [ Upstream commit d67241d43b709af4d13051bb8494892b654aba41 ] arm_spe__alloc_metadata() reads nr_cpu from the auxtrace_info priv array without validation. When a crafted perf.data provides nr_cpu=0, the per_cpu_sz calculation divides by zero: per_cpu_sz = (metadata_size - (hdr_sz * sizeof(u64))) / (*nr_cpu); Reject nr_cpu <= 0 early, before the division. The caller already treats NULL return with metadata_ver != 1 as a parse failure. Fixes: 7842a4b6ff698 ("perf arm-spe: Support metadata version 2") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: James Clark Reviewed-by: Adrian Hunter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 9a857be21e2f36da5f6d622e163b3d6f04b6bf90 Author: Arnaldo Carvalho de Melo Date: Mon Jul 27 13:17:04 2026 -0300 perf intel-bts: Fix off-by-one in auxtrace_info minimum size check [ Upstream commit b9fb8225951ce27e62a2235a71f3ab01137aaec3 ] Same pattern as the Intel PT fix: min_sz is set to sizeof(u64) * INTEL_BTS_SNAPSHOT_MODE, but the code accesses auxtrace_info->priv[INTEL_BTS_SNAPSHOT_MODE], which requires at least INTEL_BTS_SNAPSHOT_MODE + 1 elements. Use (INTEL_BTS_SNAPSHOT_MODE + 1) to ensure the highest accessed index is within bounds. Fixes: d0170af7004dce9c ("perf tools: Add Intel BTS support") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: James Clark Reviewed-by: Adrian Hunter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b3a42fd1a0cd15c19c00dda58900b4d4d936f2d2 Author: Arnaldo Carvalho de Melo Date: Mon Jul 27 13:17:03 2026 -0300 perf intel-pt: Fix off-by-one in auxtrace_info minimum size check [ Upstream commit c4362d5e1a5ed4ce2098798f655a636c4340fa20 ] min_sz is set to sizeof(u64) * INTEL_PT_PER_CPU_MMAPS, but the code accesses auxtrace_info->priv[INTEL_PT_PER_CPU_MMAPS], which requires at least INTEL_PT_PER_CPU_MMAPS + 1 elements. A file with exactly min_sz bytes of priv data passes the size check but the access reads one u64 past the validated region. Use (INTEL_PT_PER_CPU_MMAPS + 1) to ensure the highest accessed index is within bounds. Fixes: 90e457f7be087005 ("perf tools: Add Intel PT support") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: James Clark Reviewed-by: Adrian Hunter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 59910f142da84999620b281f45451cde27ec2f1c Author: Arnaldo Carvalho de Melo Date: Mon Jul 27 13:17:02 2026 -0300 perf auxtrace: Fix queue grow overflow and old array leak [ Upstream commit 96fcc9ea5f18c083a1fa73da23afef7e953f7dca ] auxtrace_queues__grow() has two bugs: 1. When idx is UINT_MAX, the caller passes new_nr_queues = idx + 1 = 0. The function skips growing (since any nr_queues >= 0), returns success, and the caller accesses queue_array[UINT_MAX] — an OOB heap write. Fix by rejecting new_nr_queues == 0 up front. 2. The function allocates a new queue_array via calloc and copies elements from the old array, but never frees the old array. Fix by saving the old pointer and freeing it after the copy. Fixes: e502789302a6ece9 ("perf auxtrace: Add helpers for queuing AUX area tracing data") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: James Clark Reviewed-by: Adrian Hunter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 003de0cf0810cc0b4c3f2af98c54bd6fb249ee97 Author: Arnaldo Carvalho de Melo Date: Mon Jul 27 13:17:01 2026 -0300 perf thread-stack: Fix heap buffer overflow on branch stack wrap copy [ Upstream commit ab9c84d1cd59e6b3b73de34982a35a76e3a9b032 ] thread_stack__br_sample() copies the wrap-around portion of the branch stack ring buffer with: nr = min(ts->br_stack_pos, sz); memcpy(be, &src->entries[0], bsz * ts->br_stack_pos); 'nr' is correctly bounded to min(br_stack_pos, sz) but the memcpy uses the unbounded ts->br_stack_pos directly. When br_stack_pos exceeds the remaining destination space 'sz', this writes past the destination buffer. Use 'nr' (the bounded value) in the memcpy size, matching the pattern of the first memcpy in the same function. Fixes: 86d67180b920 ("perf thread-stack: Add branch stack support") Reported-by: sashiko-bot Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: James Clark Reviewed-by: Adrian Hunter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 5db6e27ad43d2d3d0fe77a29f1aab6323772db0f Author: Jiancheng Huang Date: Fri Jul 24 20:19:17 2026 +0800 HID: lg4ff: validate report length before fixed offsets [ Upstream commit be00988cce4ed44db1e61231d0ab71a64bab44cd ] lg4ff_raw_event() rewrites fixed report offsets when combined pedals are enabled. It currently assumes that each product report contains every source and destination byte used by the rewrite. Return without rewriting a short report before each product-specific access. Apply the same bound to the computed offset path. Fixes: c832f86effbc ("HID: hid-logitech: Add combined pedal support Logitech wheels") Signed-off-by: Jiancheng Huang Assisted-by: Codex:gpt-5.6-luna Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit bef8426d7138c1995fa38963ecef1655f1245074 Author: Chao Huang Date: Wed Jul 22 17:36:54 2026 +0800 HID: i2c-hid: goodix: Disable VDD on VDDIO enable failure [ Upstream commit 8e2c560faea0220664169f7be4b498915ea1469f ] If enabling VDDIO fails after VDD has been enabled, the power-up path returns without disabling VDD. This leaves the regulator enabled and its enable count unbalanced. Disable VDD before returning the VDDIO error. Fixes: eb16f59e8e58 ("HID: i2c-hid: goodix: Add mainboard-vddio-supply") Signed-off-by: Chao Huang Reviewed-by: Douglas Anderson Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit f694ea0ead544080949e409a7c6885ee1fc77a98 Author: Vicki Pfau Date: Wed Jul 29 21:12:33 2026 -0700 HID: steam: Reject short reads [ Upstream commit 33ff7b49c38b39b1f3d27db508ac0720fb25c08a ] Steam Controller FEATURE reports encode the size of the message in the message itself. Previously we were trusting that the size reported matched the size we actually read, leading to a potential issue with short reads. Instead, we should actually verify the length of the read. Fixes: c164d6abf384 ("HID: add driver for Valve Steam Controller") Reported-by: syzbot+75f3f9bff8c510602d36@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=75f3f9bff8c510602d36 Signed-off-by: Vicki Pfau Link: https://syzkaller.appspot.com/bug?extid=75f3f9bff8c510602d36 Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 78c39dd5cc4ae358edb6688409fb9197474f170a Author: Vicki Pfau Date: Wed Jul 29 21:12:31 2026 -0700 HID: steam: Improve logging and other cleanup [ Upstream commit de435b770cd9492b803346b84df69fe345b845f2 ] Adds more logging as appropriate, reindents an enum to match surrounding style, as well as cleaning up some places where we can use guard() instead of doing locking and unlocking manually. Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina Stable-dep-of: 33ff7b49c38b ("HID: steam: Reject short reads") Signed-off-by: Sasha Levin commit a0fbd9437d7dc56c0d8b41cc68cd31d69d88d07b Author: Vicki Pfau Date: Wed Jul 29 21:12:27 2026 -0700 HID: steam: Add support for sensor events on the Steam Controller (2015) [ Upstream commit 2eb7cf02b52156ebd19c7c14a7f5228c6adfcf97 ] Sensor support was added for the Steam Deck previously, but Steam Controller sensor events were never added. This adds that missing support, bringing Steam Controller support much closer to feature parity with things like SDL and Steam itself. Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina Stable-dep-of: 33ff7b49c38b ("HID: steam: Reject short reads") Signed-off-by: Sasha Levin commit 041e63bd2f73cc9514cee2dd24b873c2fb0da8f5 Author: Vicki Pfau Date: Wed Jul 29 21:12:26 2026 -0700 HID: steam: Rename some constants that got renamed upstream [ Upstream commit 6afec3c8fff2af0050ca802c9b731303ce0e2b8e ] SETTING_MOUSE_POINTER_ENABLED was renamed to SETTING_LIZARD_MODE upstream. SETTING_GYRO_MODE was renamed to SETTING_IMU_MODE in an older commit, but the associated enum was overlooked. Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina Stable-dep-of: 33ff7b49c38b ("HID: steam: Reject short reads") Signed-off-by: Sasha Levin commit d73725bf8612089ae5e96d5b8f929d6fd6cd2653 Author: Vicki Pfau Date: Wed Jul 29 21:12:25 2026 -0700 HID: steam: Refactor and clean up report parsing [ Upstream commit 3d3c6ab5b07e16ed73070076e4b7f5130da2404f ] This switches from a parsing style where each button or axis is parsed individually out of a report using !!(byte & BIT(x)) style. This commit switches it to a mostly unified approach of defining a list of individual mappings in an array and passing it to a function that handles all of the extraction. Theoretically this is more lines, but in practice it results in (subjectively) cleaner code. Some exceptions still need to be made for things like handling the lizard mode toggle key, but in general there's a lot less manual code. Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina Stable-dep-of: 33ff7b49c38b ("HID: steam: Reject short reads") Signed-off-by: Sasha Levin commit 17e532415518a72919a6794183d78bc063452015 Author: Ai Chao Date: Thu Jul 16 19:29:32 2026 +0800 HID: i2c-hid: Fix "(null)" output when reading report descriptor fails [ Upstream commit 8da0f0951deec9f0728ed2d9c54ded1c344b7542 ] When i2c-hid fails to read the HID report descriptor during device initialization, the error message prints as: hid (null): reading report descriptor failed The HID device name is set in hid_add_device() after calling hdev->ll_driver->parse(), so when i2c_hid_parse() fails and calls hid_err(), the device name has not been set yet, resulting in "(null)" output. Use dev_err(&client->dev, ...) instead of hid_err(hid, ...) because the I2C client device is fully initialized with a proper name, providing meaningful error messages for debugging. Before: hid (null): reading report descriptor failed After: i2c_hid i2c-TPD0001:00: reading report descriptor failed Fixes: 4a200c3b9a40 ("HID: i2c-hid: introduce HID over i2c specification implementation") Signed-off-by: Ai Chao Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 01eeb601a1626e683fb7b77c63f442b06fb87093 Author: Yousef Alhouseen Date: Sun Jun 28 02:58:46 2026 +0200 HID: synchronize input before cleaning up a failed probe [ Upstream commit 207853d46f7ef2e28042344a1468da8754c3ddbf ] hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress. Fixes: c849a6143bec ("HID: Separate struct hid_device's driver_lock into two locks.") Reported-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9eebf5f6544c5e873858 Signed-off-by: Yousef Alhouseen Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit e5b6af32ecdd8f8a9cb4728fefd1b8aaf6bf0fc9 Author: 谢致邦 (XIE Zhibang) Date: Tue Jun 30 05:04:21 2026 +0000 HID: i2c-hid: Refactor _DSM helper and add i2c-hid-acpi-prp0001 driver [ Upstream commit fd7c67d05fb695b1deb07f9e213dd7e80e3a8427 ] Move the _DSM call that gets the HID descriptor address from i2c-hid-acpi.c into i2c-hid-acpi.h as a static inline so both the ACPI and the new PRP0001 driver can use it. While refactoring, move the blacklist check and the _DSM call to the top of probe() to avoid a pointless alloc when the device is blacklisted or does not implement the _DSM. Some devices, for example the Lenovo KaiTian N60d and Inspur CP300L3, are declared with _HID "PRP0001" and _DSD compatible "hid-over-i2c" but lack "hid-descr-addr" from the _DSD and provide the HID descriptor address only through an ACPI _DSM. The OF driver fails to probe them because it requires hid-descr-addr. Add a new driver that handles these devices by calling the shared _DSM helper. Link: https://lore.kernel.org/tencent_F6FC553D1BB737FC00062AD0FEF43C580F0A@qq.com Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules") Signed-off-by: 谢致邦 (XIE Zhibang) Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit d7f2ec073a05acec5c32e61e313e05a78c7a7357 Author: Niklas Cassel Date: Thu Jul 30 14:20:47 2026 +0200 misc: pci_endpoint_test: Check SUCCESS bit for doorbell status [ Upstream commit 37ddcce6904c20c6a7debe4751f6a82f218c3bae ] The pci-epf driver sets STATUS_DOORBELL_ENABLE_SUCCESS as the final step of pci_epf_test_enable_doorbell(), and STATUS_DOORBELL_DISABLE_SUCCESS as the final step of pci_epf_test_disable_doorbell(). A missing SUCCESS bit therefore unambiguously means that the operation did not complete, whereas the FAIL bit is only set on an explicit failure path. The host side test in pci_endpoint_test_doorbell() currently keys off the FAIL bit. That covers explicit failures but misses two cases. The first case is when the wait for the completion IRQ times out. No IRQ arrives, the Endpoint never updates STATUS, and neither SUCCESS nor FAIL is set. The enable path already handles this correctly because it also fails when the wait times out without an IRQ. The disable path does not have that extra guard and would wrongly treat the timeout as success. The second is a buggy EPC that raises two IRQs in response to a single DOORBELL_ENABLE command. The second wait_for_completion_timeout() returns immediately with 'left' non zero, but the endpoint has not yet written STATUS, so SUCCESS is clear and FAIL is also clear. The current FAIL only check treats this as success. So check the SUCCESS bit instead. That matches the Endpoint's contract because SUCCESS is the last write on the success path, and it correctly reports failure for both timeouts and the spurious IRQ case without relying on the FAIL bit being set. Fixes: eefb83790a0d ("misc: pci_endpoint_test: Add doorbell test case") Signed-off-by: Niklas Cassel [mani: commit log] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260730122045.1382749-5-cassel@kernel.org Signed-off-by: Sasha Levin commit 5c58ea19a909ef6bed4f0f824e9cd7e30d7e4775 Author: Shukai Ni Date: Tue Jul 28 16:33:50 2026 +0200 dm-integrity: replace forgeable discard filler with a keyed sector marker [ Upstream commit 68c5c42567bc462139128968ebbfadd0aefff519 ] The discard-block check in dm_integrity_rw_tag() treats a stored tag of all 0xf6 bytes (DISCARD_FILLER) as proof a block was discarded and skips HMAC verification. allow_discards is only accepted in dm-integrity's standalone mode. An attacker with raw write access to the backing device, but without the integrity key, can stamp any block with an all-0xf6 tag and have it served as authentic. Add a new "allow_discards_keyed" target argument that marks discarded blocks with a keyed checksum of (salt || sector) instead, computed by integrity_discard_checksum(). Fixes: 84597a44a9d8 ("dm integrity: add optional discard support") Co-developed-by: Jo Van Bulck Signed-off-by: Jo Van Bulck Signed-off-by: Shukai Ni Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 4f6bd79bb7e55095f09bec9b4eb6c09df1306116 Author: Karl Mehltretter Date: Fri Jul 31 20:18:43 2026 +0200 tty: clear cdev pointer after cdev_add() failure [ Upstream commit 6645856f0df3aeecd45519cb611415b4b89c2223 ] tty_cdev_add() drops the cdev reference when cdev_add() fails, but leaves driver->cdevs[index] pointing to freed memory. tty_unregister_device() later passes that stale pointer to cdev_del(), causing a use-after-free. Clear the slot after dropping the reference. Fixes: c1a752ba2d6b ("tty: don't leak cdev in tty_cdev_add()") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260731181844.11330-5-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5b77848423f4a5a362dcc3caedcdc1a75d0758c3 Author: Karl Mehltretter Date: Fri Jul 24 23:33:48 2026 +0200 serial: amba-pl011: keep console clock enabled for atomic writes [ Upstream commit c0e8cfef754645856374e82c8effd54b7d82002b ] pl011_console_write_atomic() runs from nbcon atomic context, where sleeping is not allowed. It calls clk_enable(), which takes the common-clk enable_lock. Under PREEMPT_RT that is a sleeping lock: clk_enable_lock() first tries spin_trylock_irqsave(), but on contention falls back to spin_lock_irqsave(). Therefore, an atomic-context printk on an RT kernel with a clk-backed pl011 can trip: BUG: sleeping function called from invalid context at spinlock_rt.c:48 __might_resched from rt_spin_lock rt_spin_lock from clk_enable_lock clk_enable_lock from clk_enable clk_enable from pl011_console_write_atomic ... from vprintk_emit This was found and reproduced on PREEMPT_RT. Arm32 and arm64 DT SoCs are affected; arm64 SBSA/ACPI has no clk, so clk_enable(NULL) short-circuits before the lock. In addition, write_atomic() may be invoked from NMI context and is documented to avoid locking. Removing clk_enable() from the callback also avoids a potentially unsafe NMI acquisition of the common-clock enable_lock. An nbcon atomic-capable console must be printable from any context, so the clock cannot be gated between writes. Enable the clock while the console is available for output: use clk_prepare_enable() in pl011_console_setup(), release it via clk_disable_unprepare() in the console .exit() callback, and drop the per-write clk_enable()/clk_disable() pairs from write_atomic() and write_thread(). When printk suspends consoles, drop the reference after uart_suspend_port() stops console access and restore it before uart_resume_port() -- but only if suspend actually marked the port suspended (a wake-capable tty stays running and must keep its clock), and keep it when console_suspend_enabled is false so no_console_suspend works. The active power cost of keeping the clock enabled is platform-dependent: none where the UART clock is a fixed always-on oscillator, real where it is a gateable clock branch, which then cannot be gated (nor possibly can its parent clocks) while the console is available for output. When serial core actually suspends the port, the reference is released so the clock provider can gate the clock tree. Fixes: 2eb2608618ce ("serial: amba-pl011: Implement nbcon console") Suggested-by: John Ogness Link: https://lore.kernel.org/all/8733xeaxix.fsf@jogness.linutronix.de/ Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260724213348.77418-3-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5ac19e4e26e99248f17bfb9838a761e4598eec67 Author: Karl Mehltretter Date: Fri Jul 24 23:33:47 2026 +0200 serial: amba-pl011: unprepare console clock on unregister [ Upstream commit 7f93da9d78d433c37836d85de475c5d884ad58ed ] pl011_console_setup() calls clk_prepare() on the UART clock, but the console provides no matching teardown, so the clock is never unprepared when the console is unregistered -- via the sysfs "console" attribute or a driver unbind. Each re-registration prepares the clock again, leaking one prepare reference per cycle. Even where preparing the clock has no hardware effect, the stale reference leaves the clock framework's prepare count unbalanced. For providers with prepare/unprepare operations or runtime-PM integration, it may also retain resources after the console is unregistered. Add a console .exit() callback that clk_unprepare()s the clock, balancing the clk_prepare() in pl011_console_setup(). Fixes: 4b4851c65d92 ("clk: amba-pl011: convert to clk_prepare()/clk_unprepare()") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260724213348.77418-2-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ea7fd4e8e8b8744ee802cee288fb50b3800ae5cc Author: Thomas Bogendoerfer Date: Fri Jul 17 13:27:31 2026 +0200 MIPS: ptrace: Fix syscall skipping via PTRACE_SYSCALL [ Upstream commit 5475c03fa25f31cfd5f8c7e552f8d10347bbaad9 ] If tracer wanted to skip a syscall return value was always overwritten with -ENOSYS. Fix this by checking against original syscall number and only return -ENOSYS, if it is negative. Fixes: b6318a903d06 ("MIPS/ptrace: Pick up ptrace/seccomp changed syscalls") Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 6bdbc2b4df1f501efcdee0ebd18394369e362cae Author: Christophe Leroy (CS GROUP) Date: Thu Jul 30 12:09:40 2026 +0200 soc: fsl: qe: implement get_direction() [ Upstream commit e460ef309f44b39480209970f1dd462f051d6f30 ] The lack of get_direction() callback in this driver causes GPIOLIB to emit a warning. Implement it. Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()") Reviewed-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/30b3f278a10b46252783458c81dc438df176f86c.1785405882.git.chleroy@kernel.org Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit 0f3d1d7ab5d2f707a351cf57614fa9007f8afb42 Author: Christophe Leroy (CS GROUP) Date: Thu Jul 30 14:29:36 2026 +0200 soc: fsl: qe: properly scan GPIO nodes at startup [ Upstream commit e2414b289c2b68afab361def612ca3791cd70d12 ] Before commit 156460811def ("soc: fsl: qe: Change GPIO driver to a proper platform driver") qe_add_gpiochips() was walking the device tree to find all nodes with compatible "fsl,mpc8323-qe-pario-bank". After that commit the discovery is handled by the platform core, therefore it is necessary to call of_platform_default_populate() on the par_io node. Fixes: 156460811def ("soc: fsl: qe: Change GPIO driver to a proper platform driver") Reviewed-by: Herve Codina Link: https://lore.kernel.org/r/a1db12ef75bf881dd5fba893a37db0c8517eca1b.1785414349.git.chleroy@kernel.org Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit 90d953002cf0b233dd053a0e7cb67ab79cebd0e3 Author: Saket Kumar Bhaskar Date: Mon Aug 3 10:58:43 2026 +0530 powerpc/irq: Fix missing r2 clobber in PCREL inline assembly [ Upstream commit 00be69070d91d2be978e752bb117a0a4db0e1281 ] In CONFIG_PPC_KERNEL_PCREL mode, r2 is no longer reserved for the TOC pointer and is available as a caller-saved register [0]. Both call_do_irq() and call_do_softirq() use inline assembly to call functions with stack switching, but fail to list r2 in their clobber lists. This causes the compiler to assume r2 is preserved across these calls, leading to register corruption when the called functions (__do_irq and __do_softirq) clobber r2. As a result of this kernel crash during interrupt handling is seen and the kernel fails to boot: BUG: Unable to handle kernel data access on write at 0xc000000404697638 Faulting instruction address: 0xc0000000000181ec Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000181ec] __do_IRQ+0x6c/0xc0 With older GCC, the compiler would conservatively allocate callee-saved registers (like r31) for values spanning function calls, accidentally avoiding the bug: <__do_IRQ>: 00 00 00 60 nop a6 02 08 7c mflr r0 f8 ff e1 fb std r31,-8(r1) f0 ff c1 fb std r30,-16(r1) 2d 03 10 06 pla r31,53297316 ... 3d e8 ff 4b bl c0000000000165ac <__do_irq> 00 00 21 e8 ld r1,0(r1) 28 00 4d e9 ld r10,40(r13) 40 00 21 38 addi r1,r1,64 2a f9 aa 7f stdx r29,r10,r31 With newer GCC 14, the compiler uses r2 for such values, exposing the missing clobber specification: <__do_IRQ>: 00 00 00 60 nop a6 02 08 7c mflr r0 f0 ff c1 fb std r30,-16(r1) f8 ff e1 fb std r31,-8(r1) 29 02 10 06 pla r2,36252592 # c0000000022aadc0 <__irq_regs> ... 85 dc ff 4b bl c000000000015ee0 <__do_irq> 00 00 21 e8 ld r1,0(r1) 28 00 2d e9 ld r9,40(r13) 30 00 21 38 addi r1,r1,48 2a 11 c9 7f stdx r30,r9,r2 Fix this by adding r2 to the clobber list for both call_do_irq() and call_do_softirq() when CONFIG_PPC_KERNEL_PCREL is enabled. [0]: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg313226.html Fixes: 7e3a68be42e1 ("powerpc/64: vmlinux support building with PCREL addresing") Signed-off-by: Saket Kumar Bhaskar Reviewed-by: Christophe Leroy (CS GROUP) Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/10fc2cda485cd22e209a31d786bed1984bdf3982.1785732393.git.skb99@linux.ibm.com Signed-off-by: Sasha Levin commit 5fa92c6466fa20c478ac0d2b38548afb3c5c35ed Author: Gou Hao Date: Mon Jul 27 18:42:15 2026 +0800 powerpc/smp: add NULL guard for cause_ipi in smp_muxed_ipi_message_pass [ Upstream commit 5aabc192702defb8950e7c81b05c3f4ca8ee43ec ] smp_muxed_ipi_message_pass() calls smp_ops->cause_ipi() without checking whether it has been set. On platforms using muxed IPI (e.g. powernv/pseries), smp_ops->cause_ipi is initialized to NULL in the static smp_ops and only assigned during the platform smp_probe() handler. If the IPI subsystem fails to initialize -- for example when xive_init_ipis() fails and xive_smp_probe() returns an error -- the probe handler returns early and cause_ipi is never set. Any subsequent IPI send (e.g. arch_smp_send_reschedule()) would dereference the NULL pointer. Add a NULL check to avoid the crash in that situation. Fixes: 23d72bfd8f9f ("powerpc: Consolidate ipi message mux and demux") Signed-off-by: Gou Hao Reviewed-by: jiazhenyuan Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727104215.184786-6-gouhao@uniontech.com Signed-off-by: Sasha Levin commit b59a47e20040ab77825746ca20a3821ff983679e Author: Troy Mitchell Date: Wed Jul 29 02:26:42 2026 -0700 pinctrl: spacemit: validate pins in pinconf callbacks [ Upstream commit 41c59b22370d2e1785e0e80f8ad7bd9946a1ca82 ] Pin 0 is a valid pin ID, but spacemit_pinconf_get() rejects it by testing the numeric ID rather than the result of the descriptor lookup. It also fails to reject nonzero IDs absent from the SoC pin table before computing their register addresses. Check the descriptor and use its pin ID for the register lookup. spacemit_pinconf_group_set() validates only the first group member when generating the configuration. If a later member is invalid, spacemit_pin_set_config() returns -EINVAL, but the callback ignores it and reports success after partially updating the group. Validate every group member before writing any registers so malformed groups fail without being partially applied. Fixes: a83c29e1d145 ("pinctrl: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Troy Mitchell Reviewed-by: Yixun Lan Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 41eba3b3ef86f7427821c268f8fd8035d9e1531b Author: Yulin Lu Date: Tue Jul 28 15:29:06 2026 +0800 pinctrl: eswin: Fix Handling of PIN_CONFIG_PERSIST_STATE [ Upstream commit f9af1329b98a478f4bba605ec6db429ef0e38d54 ] The EIC7700 pinctrl driver does not handle PIN_CONFIG_PERSIST_STATE specifically, and returns -EOPNOTSUPP from the default case. Since all pins on the EIC7700 SoC are persistent over suspend, the correct behaviour is to accept this parameter and return success. Add an explicit case for PIN_CONFIG_PERSIST_STATE that returns 0 to prevent errors when this parameter is set. Signed-off-by: Yulin Lu Fixes: 5b797bcc00ef ("pinctrl: eswin: Add EIC7700 pinctrl driver") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2d98a3b89394f283f054a4a54587c14ee89acaf9 Author: Laxman Acharya Padhya Date: Sat Aug 1 22:41:51 2026 +0545 firmware: coreboot: Validate table bounds [ Upstream commit a58a57a1076f8c5dae0327e3710899478c3be901 ] The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table. Fixes: d384d6f43d1e ("firmware: google memconsole: Add coreboot support") Signed-off-by: Laxman Acharya Padhya Link: https://lore.kernel.org/r/20260801165651.42172-1-acharyalaxman8848@gmail.com Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit d0a19a59580a2265cd04893602e6e26ef65c5c18 Author: Titouan Ameline de Cadeville Date: Sun Apr 26 23:47:39 2026 +0200 firmware: google: Add bounds checks in coreboot_table_populate() [ Upstream commit 7b1a1af4556a4f95ef273e91435fe804cbfcd223 ] coreboot_table_populate() iterates over firmware-provided table entries with no validation that the entries stay within the mapped memory region. A corrupt table with a large `entry->size` advances `ptr_entry` past the mapped region, causing an out-of-bounds read on the next iteration. Add a check before dereferencing `ptr_entry` to ensure the entry header is readable, and a second check after reading `entry->size` to ensure the full entry stays within the mapped region. Pass `len` from coreboot_table_probe() into coreboot_table_populate() to make the mapped region size available for validation. Signed-off-by: Titouan Ameline de Cadeville Reviewed-by: Julius Werner Link: https://lore.kernel.org/r/20260426214739.117131-1-titouan.ameline@gmail.com Signed-off-by: Tzung-Bi Shih Stable-dep-of: a58a57a1076f ("firmware: coreboot: Validate table bounds") Signed-off-by: Sasha Levin commit 7a22cbc6c6bdd3c3811b4ce13875685c520f94de Author: Zhao Li Date: Fri Jul 31 15:11:03 2026 +0800 wifi: cfg80211: stop PMSR before P2P and NAN teardown [ Upstream commit 6c5fc504d0d6934132637aa3db4b9b58148eaa78 ] PMSR request teardown must abort active measurements while the wireless_dev is still present in the driver. cfg80211_leave_locked() and cfg80211_stop_pd() already do this before invoking the driver's stop callback, but cfg80211_stop_p2p_device() and cfg80211_stop_nan() do not. Those helpers are also called directly by nl80211, rfkill shutdown, and wireless_dev unregister paths. If one of these paths stops a P2P device or NAN interface with a pending request, it removes the mac80211 subinterface from the driver first. Subsequent request cleanup cannot reach the lower driver's abort callback, but cfg80211 frees the request regardless. Driver state can then retain a stale request and use it when it later reports a result. Call cfg80211_pmsr_wdev_down() before stopping the P2P device or NAN interface. This keeps lower-driver request state and cfg80211 request ownership in sync for all of the helpers' callers. Fixes: 9bb7e0f24e7e ("cfg80211: add peer measurement with FTM initiator API") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260731071103.73563-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0a0c03e4b7c63bdd2db457349431a20d62721c60 Author: Miri Korenblit Date: Wed Mar 18 14:39:15 2026 +0200 wifi: cfg80211: Add an API to configure local NAN schedule [ Upstream commit 6e78b70c9a3d2a627229801f93e3f62869922587 ] Add an nl80211 API to allow user space to configure the local NAN schedule. The local schedule consists of a list of channel definitions and a schedule map, in which each element covers a time slot and indicates on what channel the device should be in that time slot. Channels can be added to schedule even without being scheduled, for reservation purposes. A schedule can be configured either immedietally or be deferred, in case there are already connected peers. When the deferred flag is set, the command is a request from the device to perform an announced schedule update: send the updated NAN Availability - as set in this command - to the peers, and do the actual switch to the new schedule on the right time (i.e. at the end of the slot after the slot in which the update was sent to the peers). In addition, a notification will be sent to indicate a deferred update completion. Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260219114327.ecca178a2de0.Ic977ab08b4ed5cf9b849e55d3a59b01ad3fbd08e@changeid Link: https://patch.msgid.link/20260318123926.206536-2-miriam.rachel.korenblit@intel.com Signed-off-by: Johannes Berg Stable-dep-of: 6c5fc504d0d6 ("wifi: cfg80211: stop PMSR before P2P and NAN teardown") Signed-off-by: Sasha Levin commit 84263694c8d1fd6a76002fdb78f5b1862b21f5df Author: Johannes Berg Date: Tue Mar 3 22:17:09 2026 +0100 wifi: nl80211: split out UHR operation information [ Upstream commit e4b993f2bca78357b430170574f8de7bc7874088 ] The beacon doesn't contain the full UHR operation, a number of fields (such as NPCA) are only partially there. Add a new attribute to contain the full information, so it's available to the driver/mac80211. Link: https://patch.msgid.link/20260303221710.866bacf82639.Iafdf37fb0f4304bdcdb824977d61e17b38c47685@changeid Signed-off-by: Johannes Berg Stable-dep-of: 6c5fc504d0d6 ("wifi: cfg80211: stop PMSR before P2P and NAN teardown") Signed-off-by: Sasha Levin commit e182bf30a38c3d82edfa4170ffff7ad784d0c0c1 Author: Miri Korenblit Date: Thu Feb 19 11:47:11 2026 +0200 wifi: nl80211: refactor nl80211_parse_chandef [ Upstream commit 49a1e65c6d706703a8fcd54a5c5ca1f11f7e319b ] In order to be able to use this function also for nested attributes, change this function to receive a pointer to extack and to the attributes array, instead of receiving the info and extracting them out of it. While at it, use NL_SET_ERR_MSG_ATTR with the frequency of the chandef. Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260219114327.2b994566a63b.I6c2b6f4c7e2e09f4c47285ca4ac8a37b20700e19@changeid Signed-off-by: Johannes Berg Stable-dep-of: 6c5fc504d0d6 ("wifi: cfg80211: stop PMSR before P2P and NAN teardown") Signed-off-by: Sasha Levin commit 6481459f78be3a700d3b66c80fcbda757e257002 Author: Hari Chandrakanthan Date: Mon Feb 16 08:50:26 2026 +0530 wifi: cfg80211: add support to handle incumbent signal detected event from mac80211/driver [ Upstream commit 6a584e336cefb230e2d981a464f4d85562eb750c ] When any incumbent signal is detected by an AP/mesh interface operating in 6 GHz band, FCC mandates the AP/mesh to vacate the channels affected by it [1]. Add a new API cfg80211_incumbent_signal_notify() that can be used by mac80211 or drivers to notify the higher layers about the signal interference event with the interference bitmap in which each bit denotes the affected 20 MHz in the operating channel. Add support for the new nl80211 event and nl80211 attribute as well to notify userspace on the details about the interference event. Userspace is expected to process it and take further action - vacate the channel, or reduce the bandwidth. [1] - https://apps.fcc.gov/kdb/GetAttachment.html?id=nXQiRC%2B4mfiA54Zha%2BrW4Q%3D%3D&desc=987594%20D02%20U-NII%206%20GHz%20EMC%20Measurement%20v03&tracking_number=277034 Signed-off-by: Hari Chandrakanthan Signed-off-by: Amith A Link: https://patch.msgid.link/20260216032027.2310956-2-amith.a@oss.qualcomm.com Signed-off-by: Johannes Berg Stable-dep-of: 6c5fc504d0d6 ("wifi: cfg80211: stop PMSR before P2P and NAN teardown") Signed-off-by: Sasha Levin commit 335c515932a59a694f5602af891292184cf2b215 Author: Johannes Berg Date: Fri Jan 30 16:21:06 2026 +0100 wifi: cfg80211: add initial UHR support [ Upstream commit 072e6f7f416f5d17be71000b31fb108651ad360d ] Add initial support for making UHR connections (or suppressing that), adding UHR capable stations on the AP side, encoding and decoding UHR MCSes (except rate calculation for the new MCSes 17, 19, 20 and 23) as well as regulatory support. Link: https://patch.msgid.link/20260130164259.54cc12fbb307.I26126bebd83c7ab17e99827489f946ceabb3521f@changeid Signed-off-by: Johannes Berg Stable-dep-of: 6c5fc504d0d6 ("wifi: cfg80211: stop PMSR before P2P and NAN teardown") Signed-off-by: Sasha Levin commit be90aa8bf17751da1229f14fcd5c4204d3069bd7 Author: Johannes Berg Date: Fri Jan 30 16:21:05 2026 +0100 wifi: ieee80211: add some initial UHR definitions [ Upstream commit a7cb50156e8206562b001b3bb625045a0ee0f651 ] This is based on Draft P802.11bn_D1.2, but that's still very incomplete, so don't handle a number of things and make some local decisions such as using 40 bits for MAC capabilities and 8 bits for PHY capabilities. Link: https://patch.msgid.link/20260130164259.b28c9456ff94.I5b11fb0345a933bf497fd802aecc72932d58dd68@changeid Signed-off-by: Johannes Berg Stable-dep-of: 6c5fc504d0d6 ("wifi: cfg80211: stop PMSR before P2P and NAN teardown") Signed-off-by: Sasha Levin commit 66722acd740be41aba5f6695853600e52a6fd154 Author: Sai Pratyusha Magam Date: Wed Jan 14 16:48:55 2026 +0530 wifi: nl80211: Add support for EPP peer indication [ Upstream commit 6ee3a22c61cdf57d71592ec9f3b9439cd5d0c75f ] Introduce a new netlink attribute NL80211_ATTR_EPP_PEER to be used with NL80211_CMD_NEW_STA and NL80211_CMD_ADD_LINK_STA for the userspace to indicate that a non-AP STA is an Enhanced Privacy Protection (EPP) peer. Co-developed-by: Rohan Dutta Signed-off-by: Rohan Dutta Signed-off-by: Sai Pratyusha Magam Signed-off-by: Kavita Kavita Link: https://patch.msgid.link/20260114111900.2196941-5-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg Stable-dep-of: 6c5fc504d0d6 ("wifi: cfg80211: stop PMSR before P2P and NAN teardown") Signed-off-by: Sasha Levin commit 93b4c9130461ca88b1981e2bac241fe540c049c6 Author: Lachlan Hodges Date: Fri Jan 9 19:14:39 2026 +1100 wifi: cfg80211: include S1G_NO_PRIMARY flag when sending channel [ Upstream commit e1cbdf78f60c35a1a320ca401852fd6a73624a4a ] When sending a channel ensure we include the IEEE80211_CHAN_S1G_NO_PRIMARY flag. Signed-off-by: Lachlan Hodges Link: https://patch.msgid.link/20260109081439.3168-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg Stable-dep-of: 6c5fc504d0d6 ("wifi: cfg80211: stop PMSR before P2P and NAN teardown") Signed-off-by: Sasha Levin commit e7bc5ab93acd1c3f54feeb9fa19ead3530168090 Author: Johannes Berg Date: Sun Aug 2 11:12:17 2026 +0300 wifi: mac80211: disconnect on CSA to channel 0 [ Upstream commit cf57f0a674cc3e3cda1a789359cc1238b61b9d7d ] The refactor for the CSA parsing erroneously equates channel zero and no information present, leading it to ignore a CSA on an AP that advertises a switch to that (invalid) channel. This leads to not disconnecting, which we should. For Intel devices, this can lead to a firmware crash. Fix this by using an int type for the channel number as well as the opclass, and using a (negative) value that cannot be encoded in the element to indicate it's not present. Fixes: 21c3f8f95554 ("wifi: mac80211: refactor STA CSA parsing flows") Signed-off-by: Johannes Berg Reviewed-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260802111213.3bc833515e40.I255c37c31ca8b0b34e351cf254e16b6071dd8fb3@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7c3d762bc15c5820494a629912788fdf1fc79b79 Author: Zhao Li Date: Thu Jul 23 09:10:01 2026 +0800 wifi: mac80211: skip unused probe response countdown offsets [ Upstream commit fd2bf5e718108c00732eb07fd94a5d8830f62a9f ] mac80211 copies cfg80211's variable-length countdown offset list into a zero-initialized fixed-size array, leaving unused entries at zero. The beacon branch already skips those zero entries, but the AP probe-response branch writes through them unconditionally. When a probe-response template has no countdown offset, the write through an unused zero entry overwrites resp->data[0], corrupting the first byte of the template. cfg80211 already bounds explicitly supplied non-zero offsets in nl80211_parse_counter_offsets(), so this is a zero-sentinel bug, not an out-of-bounds write. Skip zero probe-response offsets, matching the beacon path. Fixes: af296bdb8da4 ("mac80211: move csa counters from sdata to beacon/presp") Link: https://lore.kernel.org/all/20260708195911.84365-6-enderaoelyther@gmail.com/ Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260723011001.76851-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 979ad5269bdf0262aca0fa1b285b1352af88a7c9 Author: Slawomir Stepien Date: Thu Jul 30 08:52:31 2026 +0200 wifi: zd1211rw: reject secondary interfaces to prevent conflicts [ Upstream commit 0e4532ec658606f76f62eb277e7a933919d36cbb ] The zd1211rw driver is designed for single-function Wi-Fi dongles and hardcodes its USB endpoints. When a malformed USB device exposes multiple interfaces that match the driver's device ID, the driver blindly binds to all of them. During probe(), the driver calls usb_reset_device(), which iterates over all interfaces and invokes the pre_reset() callback for each bound interface. Since multiple interfaces are bound to zd1211rw, pre_reset() is called sequentially for each instance, acquiring their respective &mac->chip.mutex. Because all instances initialize their mutexes with the same lock class, lockdep detects a task acquiring a lock of the same class it already holds and flags it as a possible recursive deadlock: WARNING: possible recursive locking detected kworker/0:1/11 is trying to acquire lock: ffff88810371dde0 (&chip->mutex){+.+.}-{4:4}, at: zd_chip_disable_rxtx+0x20/0x50 drivers/net/wireless/zydas/zd1211rw/zd_chip.c:1465 but task is already holding lock: ffff8881138ddde0 (&chip->mutex){+.+.}-{4:4}, at: pre_reset+0x28c/0x380 drivers/net/wireless/zydas/zd1211rw/zd_usb.c:1505 Fix this by explicitly rejecting secondary interfaces (bInterfaceNumber != 0) during probe(). This ensures that only a single instance of the driver binds to the device, eliminating the recursive locking scenario. Fixes: e85d0918b54f ("[PATCH] ZyDAS ZD1211 USB-WLAN driver") Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+0ec3d1a6cf1fbe79c153@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0ec3d1a6cf1fbe79c153 Link: https://syzkaller.appspot.com/ai_job?id=00724ef7-fd77-4cde-9779-895b8f63c2f6 Signed-off-by: Slawomir Stepien Link: https://patch.msgid.link/20260730065231.1644030-1-sst@poczta.fm Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 26e6123a93dcaedf9f041787f318d88b3e7f0f51 Author: Zhao Li Date: Thu Jul 30 01:36:07 2026 +0800 wifi: mac80211: send TWT teardown to peer after setup TX failure [ Upstream commit a28fcce6ee74be8a4526e6cfa16dc7786d62a784 ] When an AP's TWT Setup response is not acknowledged, ieee80211_s1g_tx_twt_setup_fail() asks the driver to tear down the local agreement and sends a TWT teardown action as the peer notification. It uses the response SA as the destination, but ieee80211_s1g_send_twt_setup() built that response with SA set to the AP's address. The teardown is therefore queued with DA, SA and BSSID all set to the AP address and never reaches the station. The in-tree driver callbacks update local hardware state and emit no action frame. The station receives no notification that mac80211 asked the driver to remove the agreement and can keep following the TWT schedule, leaving the peers' power-save state desynchronized. Address the teardown to the response DA, the station to which the failed response was sent. This also matches the station lookup the transmit status path already performs on the same frame. Fixes: f5a4c24e689f ("mac80211: introduce individual TWT support in AP mode") Assisted-by: Codex:gpt-5.6-sol Assisted-by: Kimi:K3 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260729173607.13340-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 97dd2f6560ce35ae4e945e73a844cb670d27642d Author: Davidlohr Bueso Date: Wed Jul 15 12:14:52 2026 -0700 perf/cxlpmu: Fix 64-bit write to 32-bit HDM filter register [ Upstream commit ea434e8fd3a539e9c53285b10d3c7e539e228591 ] The HDM decoder filter configuration register is 32 bits wide, but the driver programs it with a 64-bit writeq(). The filter value never exceeds 32 bits, so the upper half of the write is always zero and lands in the adjacent Filter ID 1 (Channel/Rank/Bank) configuration register at offset+4. Fixes: 5d7107c72796 ("perf: CXL Performance Monitoring Unit driver") Signed-off-by: Davidlohr Bueso Reviewed-by: Richard Cheng Reviewed-by: Dave Jiang Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 9ba040f4fec87f57a99eb46f9e405521efb46c20 Author: Pranjal Shrivastava Date: Tue Jul 28 21:11:23 2026 +0000 iommu/arm-smmu-v3: Convert to use atomic poll timeout [ Upstream commit eced8058c82a3a81ae480a6546e2da32100dddfa ] The arm_smmu_write_reg_sync() helper is currently implemented using readl_relaxed_poll_timeout() (that relies on usleep_range() internally) which becomes a critical issue when used in the gerror irq handler. If the SMMU hits a gerror and enters Service Failure Mode (GERROR_SFM_ERR), the gerror handler calls arm_smmu_device_disable() in hard-irq context. This becomes a problem as arm_smmu_device_disable() inevitably calls arm_smmu_write_reg_sync() which might attempt to sleep inside a hard-irq context. Fix this by converting the arm_smmu_write_reg_sync to use the readl_relaxed_poll_timeout_atomic() polling helper. (Discovered while running Sashiko locally on another patch series). Reported-by: Sashiko Fixes: 48ec83bcbcf5 ("iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices") Signed-off-by: Pranjal Shrivastava Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2a08fd5a082e1462866c1b579ff623170ab449d2 Author: Mark Brown Date: Fri Jul 31 21:50:52 2026 +0100 kselftest/arm64: Don't write to P0 in irritator on SME only systems [ Upstream commit 2b989c411ab98fa76b7bb3b87ba7a2a4c3b5e946 ] Commit 3e360ef0c0a1f ("kselftest/arm64: Corrupt P0 in the irritator when testing SSVE") added corruption of P0 to the sve-test case in order to ensure that the predicate registers were covered as part of the corruption. On SME only systems this results in an illegal instruction since signal handlers are run out of streaming mode and the predicate registers do not exist out of streaming mode without SVE. Switch to entering and exiting streaming mode in the irritator, this will reset all relevant registers to 0 if they somehow weren't already by the signal entry. Fixes: 3e360ef0c0a1f ("kselftest/arm64: Corrupt P0 in the irritator when testing SSVE") Reported-by: Mark Rutland Signed-off-by: Mark Brown Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ee46a1714d3a9bc44f3cdb0756bcee1ee61a7643 Author: Karl Mehltretter Date: Wed Jul 29 02:42:55 2026 +0200 kselftest/arm64: fp-ptrace: Fix checks for inactive SVE and SSVE regsets [ Upstream commit bd290e7fc245f9f85607f305fe8213c6c47a416c ] The checks on the header size reported for the inactive regset of the NT_ARM_SVE/NT_ARM_SSVE pair compare it against sizeof(sve), but sve is a struct user_sve_header *, so this is 8 rather than the intended 16. The kernel carried the identical typo when filling in the header, so kernel and test agreed on the wrong value and the test passed. Compare against sizeof(*sve), stop after the header checks for an inactive regset since it has no payload to compare, and prefill the buffer with a sentinel to verify that reading an inactive regset leaves everything after the header untouched. This also covers the getter's return value, which determines how many bytes ptrace copies back to userspace. Fixes: 864f3ddcd715 ("kselftest/arm64: fp-ptrace: Adjust to new inactive mode behaviour") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 695e976e25a1139b2a5912404d7a7889cf032b7d Author: Karl Mehltretter Date: Wed Jul 29 02:42:54 2026 +0200 arm64/fpsimd: ptrace: Fix inactive SVE and SSVE regsets [ Upstream commit c3f83d021162571bcd87b062ec9e587828d2b7f3 ] sve_init_header_from_task() takes header as a pointer, so for the inactive mode header->size = sizeof(header); stores 8 rather than sizeof(struct user_sve_header), which is 16. Userspace sees an impossible size smaller than the header it describes. The inactive-mode check in sve_get_common() compares header.size against sizeof(header) as well, but there header is a struct, so the check can never fire. Reads of NT_ARM_SVE and NT_ARM_SSVE for the inactive mode therefore still return the other mode's FPSIMD data, exactly the situation the check was added to prevent. Fix the size, and make the check return the remaining membuf space instead of 0, which regset_get() would interpret as the entire (zero-filled) buffer having been populated. Fixes: b93e685ecff7 ("arm64/fpsimd: ptrace: Do not present register data for inactive mode") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit a2ff70c44fe8eb192dd5cd98cdff8526a8918045 Author: Vladimir Murzin Date: Fri Jul 31 13:26:46 2026 +0100 arm64: smp: Fix IPI teardown for GICv5 flow [ Upstream commit 4c9c81a0860415284e9d260f998fbd755d3a7469 ] Sashiko reported that during CPU offlining, __cpu_disable() is executed by the stopper thread via take_cpu_down() with local interrupts disabled. __cpu_disable() calls ipi_teardown(), which invokes ipi_lpi_disable(). For the GICv5 flow, this eventually calls the sleepable disable_irq(). This can be reproduced easily with CONFIG_DEBUG_ATOMIC_SLEEP=y by offlining a CPU: BUG: sleeping function called from invalid context at kernel/irq/manage.c:702 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 20, name: migration/1 preempt_count: 1, expected: 0 no locks held by migration/1/20. irq event stamp: 186 hardirqs last enabled at (185): [] _raw_spin_unlock_irq+0x38/0x68 hardirqs last disabled at (186): [] multi_cpu_stop+0xc8/0x190 softirqs last enabled at (80): [] handle_softirqs+0x410/0x468 softirqs last disabled at (75): [] __do_softirq+0x1c/0x28 Fix this by using disable_irq_nosync() instead, which is safe in this atomic context. Fixes: ba1004f861d1 ("arm64: smp: Support non-SGIs for IPIs") Signed-off-by: Vladimir Murzin Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 80818e72aec4d82875b922d4cb8fac460d577e2b Author: Jose Ignacio Tornos Martinez Date: Thu Jul 2 12:43:37 2026 +0200 wifi: mt76: mt7996: remove beacon_int_min_gcd from ADHOC interface combinations [ Upstream commit 4df22710a77d2365e56d720bc4106e54c1dfa2ff ] The driver fails to register with error -22 (EINVAL) due to a cfg80211 validation failure in wiphy_verify_iface_combinations(). Commit 5ef0e8e2653b ("wifi: mt76: mt7996: fix iface combination for different chipsets") added beacon_int_min_gcd to if_comb_global and if_comb_global_7992, but these combinations include ADHOC (IBSS) interface type. This violates a cfg80211 rule from commit 56271da29c52 ("cfg80211: disallow beacon_int_min_gcd with IBSS") that explicitly forbids combining ADHOC with beacon_int_min_gcd. The restriction exists because beacon_int_min_gcd requires static, predictable beacon intervals to coordinate multiple beaconing interfaces, but ADHOC interfaces have dynamic beacon intervals that change when joining different networks, making the GCD constraint unenforceable. Remove beacon_int_min_gcd from the interface combinations that include ADHOC because they are not necessary for ADHOC operation. The if_comb combination (AP/MESH/STA only, without ADHOC) correctly retains beacon_int_min_gcd for multi-AP coordination. Fixes: 5ef0e8e2653b ("wifi: mt76: mt7996: fix iface combination for different chipsets") Signed-off-by: Jose Ignacio Tornos Martinez Tested-by: Alex Gavin Link: https://patch.msgid.link/20260702104337.679536-1-jtornosm@redhat.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7039825a7479df637c4f5d546cb0e1cec18cd8e1 Author: Linghui Wu Date: Mon Jul 27 12:56:29 2026 +0530 wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump [ Upstream commit 4f25071afe9218aaae1c63fbf75e229aa6405319 ] On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1 Fixes: 3f14b73c3843 ("ath10k: Enable MSA region dump support for WCN3990") Signed-off-by: Linghui Wu Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260727072629.2297208-1-linghui.wu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 637bb99cc766a858d744905e46638459ca128b6c Author: Felix Fietkau Date: Sat Aug 1 14:53:34 2026 +0000 wifi: mt76: mt7996: fix out-of-bounds link array access in mt7996_tx() [ Upstream commit 4330a0ef9f75a54fde3548432a9a698f06bab635 ] When mac80211 leaves the link unspecified, mt7996_tx() substitutes the primary link id of the station or vif. That value is IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added, and it is then used unchecked to index vif->link_conf[], mvif->mt76.link[] and sta->link[], all of which hold IEEE80211_MLD_MAX_NUM_LINKS (15) entries. Clamp the primary link id to the default link before using it, and use the clamped value for the link_sta fallback as well. Fixes: 1609b014aa29 ("wifi: mt76: mt7996: Overwrite unspecified link_id in mt7996_tx()") Link: https://patch.msgid.link/20260801145334.1166751-10-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 13f6a9c786022d5213e84d494cc8717c378f5395 Author: Felix Fietkau Date: Sat Aug 1 14:53:33 2026 +0000 wifi: mt76: reject out-of-range link ids in mt76_vif_link() [ Upstream commit 9ba744a28c26eaa5cae930688a22e01888395308 ] mt76_vif_link() indexes mvif->link[] without validating link_id, but callers pass mvif->deflink_id / msta->deflink_id, which hold IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added. Since IEEE80211_MLD_MAX_NUM_LINKS is 15, that reads one element past the end of the array, aliasing mt76_vif_data.offchannel_link. Reachable via mt7996_set_tsf()/mt7996_offset_tsf() and mt7996_net_fill_forward_path(). Bounds check link_id and return NULL, matching mt7996_sta_link() and mt7996_sta_link_protected(). Fixes: a9384b36a42a ("wifi: mt76: mt7996: rework set/get_tsf callabcks to support MLO") Link: https://patch.msgid.link/20260801145334.1166751-9-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 81ccb9faf3c43a82be55716eb5c3dde38fbef7fc Author: shengwei.lu Date: Thu Jul 23 11:11:08 2026 +0800 wifi: mt76: mt7925: Fix EHT Beamformee SS subfields to meet 802.11be minimum [ Upstream commit 404c4e564f6b1eeffd10bf2b2d3b86620f5794c3 ] Per IEEE 802.11be, the Beamformee SS <= 80/160/320 MHz 3-bit subfields in the EHT PHY Capabilities are encoded as (Nss - 1) and are required to be >= 3 (i.e. at least 4 SS receive capability) whenever SU Beamformee is advertised. MT7925 is a 2x2 STA (sts = 2), so directly filling (sts - 1) = 1 violates the spec minimum. Clamp the encoded value to 3 when sts <= 3, otherwise use (sts - 1). This is applied consistently to the BEAMFORMEE_SS <= 80 MHz (split across phy_cap_info[0]/[1]), <= 160 MHz and <= 320 MHz (6 GHz only) subfields. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: shengwei.lu Link: https://patch.msgid.link/20260723031108.2017653-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0ead464cb43ef47f5c2bfbf94c8e024e91e900a2 Author: Javier Tia Date: Sat Apr 25 14:49:55 2026 -0500 wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band [ Upstream commit 77833c57a33450c0409e4b90d7721d255ea23a9e ] mt7925_init_eht_caps() only populates EHT MCS/NSS maps for BW <= 80 and BW = 160, but never sets BW = 320. This means iw phy shows no 320MHz MCS map entries even though the hardware supports 320MHz operation in the 6GHz band. Add the missing 320MHz capability bits for 6GHz: - PHY_CAP0: IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ - PHY_CAP1: beamformee SS for 320MHz - PHY_CAP2: sounding dimensions for 320MHz - PHY_CAP6: MCS15 support for 320MHz width - MCS/NSS: populate bw._320 maps for 6GHz band Introduce is_320mhz_supported() to gate 320MHz on MT7927 only, since MT7925 does not support 320MHz operation. Tested-by: Marcin FM Tested-by: Cristian-Florin Radoi Tested-by: George Salukvadze Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo Tested-by: Ariel Rosenfeld Tested-by: Chapuis Dario Tested-by: Thibaut François Tested-by: 张旭涵 Reviewed-by: Sean Wang Signed-off-by: Javier Tia Link: https://patch.msgid.link/20260425195011.790265-6-sean.wang@kernel.org Signed-off-by: Felix Fietkau Stable-dep-of: 404c4e564f6b ("wifi: mt76: mt7925: Fix EHT Beamformee SS subfields to meet 802.11be minimum") Signed-off-by: Sasha Levin commit c59c8b962c4d87c4e6efcaa331d71f9e13348f14 Author: Peter Chiu Date: Mon Jul 27 15:04:30 2026 +0000 wifi: mt76: fix queue assignment for disassoc packets [ Upstream commit 3999d15cfcc72a946ec419c4059b0e0cd7860053 ] Like deauth, a disassoc frame sent to a client in powersave mode can get stuck in a tx queue along with other buffered frames, filling up hardware queues with frames that are only released after the WTBL slot is reused for another client. Move disassoc packets to the ALTX queue, matching the existing deauth handling. Fixes: dedf2ec30fe4 ("wifi: mt76: fix queue assignment for deauth packets") Signed-off-by: Peter Chiu Link: https://patch.msgid.link/20260727150434.1778520-11-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 292bc52d8420a1fcfd70710d26a6e6310bd87769 Author: Felix Fietkau Date: Mon Jul 27 15:04:28 2026 +0000 wifi: mt76: mt7915: report RX chain signal for all RX paths [ Upstream commit b53c44fe65792608f58028c7b0953e610ad652ee ] status->chains was set from the antenna mask, which is derived from the number of spatial streams, while the chain_signal array is filled from all RCPI fields. On boards where the number of RX paths exceeds the stream count, e.g. the 3T3R mt7916/mt7981 variant with 2 streams on the 5 GHz band, the RSSI of the extra chains was never reported. Use the band local RX path chainmask instead. Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Link: https://patch.msgid.link/20260727150434.1778520-9-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 4dee6aca79295de8499f3a22443f391767d1a2da Author: Felix Fietkau Date: Mon Jul 27 15:04:27 2026 +0000 wifi: mt76: mt7915: fix chainmask handling for non-dbdc phys on band 1 [ Upstream commit ea891799eccc9e43ebba0dc157d4b197ad6c1a0e ] On single-adie mt7986 the only phy is bound to band 1, but its chainmask is stored unshifted, because dev->chainshift is still zero while the eeprom is parsed for the main phy. mt7915_set_antenna() on the other hand shifts by chainshift * band_idx, so the representation of the chainmask changed as soon as the antenna configuration was touched. Until then, mt7915_mcu_set_chan_info() passed rx_path = 0 to the firmware, since shifting the unshifted mask down clears all bits. Keep the unshifted form for that case and add helpers for the band local chainmask, so that only the band 1 phy of a dbdc device uses the shifted form. Fixes: 3eb50cc90534 ("wifi: mt76: mt7915: rely on band_idx of mt76_phy") Link: https://patch.msgid.link/20260727150434.1778520-8-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 76144da3c6184c7850631ad79d0600ac8bf7649a Author: Felix Fietkau Date: Mon Jul 27 15:04:25 2026 +0000 wifi: mt76: mt7996: do not attach hif2 WED when the main WED attach failed [ Upstream commit 7c1924332e986019c6bcddf55c843361cccac73f ] If the WED attach for the primary PCIe function fails, the probe path still attached wed_hif2 for the secondary function, leaving the device in an inconsistent half-WED configuration that crashes later. The hif2 call also re-enabled hwrro_mode, which the failed primary attach had just turned off. Skip the hif2 WED setup when the primary WED device is not active. Fixes: 83eafc9251d6 ("wifi: mt76: mt7996: add wed tx support") Link: https://patch.msgid.link/20260727150434.1778520-6-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d4326105ee28dcce176b33a73033729a438edf91 Author: StanleyYP Wang Date: Mon Jul 27 15:04:24 2026 +0000 wifi: mt76: mt7996: fix reg addr remap when addr is 0 [ Upstream commit eb906eeff2d1e84b628dc210dada325269c71383 ] When addr is less than the hardcoded threshold in __mt7996_reg_addr, it indicates that remapping is unnecessary. Currently, the flow remaps address 0x0 to MT_HIF_REMAP_BASE_L2, which is incorrect. To address this, modify __mt7996_reg_addr to return INVALID_REG_ADDR if the address is not below the hardcoded value or is not present in the mt7996_reg_map array. Additionally, update the remap condition to check if addr is equal to INVALID_REG_ADDR. Fixes: 3687854d3e7e ("wifi: mt76: mt7996: add locking for accessing mapped registers") Signed-off-by: StanleyYP Wang Link: https://patch.msgid.link/20260727150434.1778520-5-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ed5cc46a3c8f4fe7f549c661914d8d835169acc0 Author: Felix Fietkau Date: Mon Jul 27 15:04:23 2026 +0000 wifi: mt76: mt7915: release hif2 reference on probe IRQ failure [ Upstream commit 8370aebd26a9dfa2e0de665e3ab504c0e97ee730 ] The hif2 reference obtained by mt7915_pci_init_hif2() is only released on error paths that key off dev->hif2, which is not assigned until after the IRQ setup. If pci_alloc_irq_vectors() or the primary devm_request_irq() fails, the reference leaks. Drop it explicitly on those paths via mt7915_put_hif2(). Fixes: f68d67623dec ("mt76: mt7915: add Wireless Ethernet Dispatch support") Link: https://patch.msgid.link/20260727150434.1778520-4-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a7fd3bae8e11a7c00df6a5021d9ef248ae9f9bf5 Author: Felix Fietkau Date: Mon Jul 27 15:04:22 2026 +0000 wifi: mt76: mt7915: fix ext PHY use-after-free on register error path [ Upstream commit 15b960014f24dce5388d4a2e7274e6490cb3c421 ] After mt7915_register_ext_phy() succeeded, a failure of the main PHY mt7915_init_debugfs() or mt7915_coredump_register() unwound through free_phy2, which called ieee80211_free_hw() on the ext PHY hw while it was still registered with mac80211, since mt76_unregister_device() only unregisters the main hw. Unregister the ext PHY (thermal + phy + hw) first and skip the redundant free. Fixes: 7b8e1ae886e4 ("mt76: mt7915: rework hardware/phy initialization") Link: https://patch.msgid.link/20260727150434.1778520-3-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 249cbaa1873550689fab136b74982cbba74c4169 Author: Felix Fietkau Date: Mon Jul 27 15:04:21 2026 +0000 wifi: mt76: mt7915: fix double hif2 init on the non-WED path [ Upstream commit 3ae8ad277e2819a281b0e36b55633c8515c16ce7 ] mt7915_pci_init_hif2() was called unconditionally and again inside the WED-inactive branch. The helper increments the global hif_idx, writes the PCIe RECOG_ID register and takes a get_device() reference via mt7915_pci_get_hif2(), while removal only drops one reference. On non-WED dual-hif hardware this double-incremented hif_idx, wrote RECOG_ID twice and leaked a device reference. Only the call inside the WED-inactive branch is correct; drop the unconditional one. hif2 is already initialised to NULL. Fixes: cacdd67812c6 ("mt76: mt7915: add mt7915_mmio_probe() as a common probing function") Link: https://patch.msgid.link/20260727150434.1778520-2-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 51c6d1f665401c5d1643cc915d96ec53224b54b4 Author: Felix Fietkau Date: Mon Jul 27 15:04:20 2026 +0000 wifi: mt76: mt7996: fix MIB TX aggregation counter registers for mt7990 [ Upstream commit d0b750072a29c8ff0504c3bc28c411c402f26716 ] The MIB_TSCR0-7 counters read by mt7996_mac_update_stats() are hardcoded at the mt7996/mt7992 offsets 0x6b0-0x6d0, but mt7990 moved them to 0x750-0x770, so TX AMPDU statistics were read from unrelated registers on that chip. Move the offsets into the per-chip register tables. Fixes: f6c87411d15f ("wifi: mt76: mt7996: rework register mapping for mt7990") Link: https://patch.msgid.link/20260727150434.1778520-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2b10eb3636d0c4cb6b763e045ec1294dbd70f5ad Author: Felix Fietkau Date: Fri Jul 24 12:48:09 2026 +0000 wifi: mt76: mt7996: free vif links after clearing wcid entries on full reset [ Upstream commit 7e4208e9f6a876c2b7d28fdb6b86dff3b05db2f7 ] mt7996_mac_reset_vif_iter() queues non-default vif links for kfree_rcu while dev->wcid[] still holds pointers to the wcid embedded in each freed link; mt76_reset_device() then dereferences those entries and runs mt76_wcid_cleanup() on them. If a grace period elapses in between, the cleanup operates on freed memory. Run mt76_reset_device() first, so the wcid entries are cleaned up and cleared while the links are still valid. Fixes: ace5d3b6b49e ("wifi: mt76: mt7996: improve hardware restart reliability") Link: https://patch.msgid.link/20260724124813.3961474-25-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f3d8cf8c09e3b7379c606e4fb0fbf15d387ed3de Author: Felix Fietkau Date: Fri Jul 24 12:48:03 2026 +0000 wifi: mt76: mt7996: wake MCU waiters before aborting scan in L1 SER [ Upstream commit 6f8d8c458010b597bf4114e6fb3162bff7050041 ] The L1 reset path calls mt76_abort_scan() between setting MT76_MCU_RESET and waking mcu.wait. A scan work blocked on an in-flight MCU command does not re-evaluate its wait condition until woken, so the cancel_delayed_work_sync() inside the abort sleeps out the full MCU timeout before recovery can proceed, adding several seconds of SER latency. mt7996_mac_full_reset() and the mt7915 counterpart already order the wake-up first. Wake mcu.wait immediately after setting MT76_MCU_RESET so in-flight commands bail out before the abort synchronises against them. Fixes: b36d55610215 ("wifi: mt76: abort scan/roc on hw restart") Link: https://patch.msgid.link/20260724124813.3961474-19-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2cc7d32b42dab0d7a8fb34f451758a08ec869700 Author: Felix Fietkau Date: Fri Jul 24 12:48:02 2026 +0000 wifi: mt76: mt7996: skip key upload when adding an offchannel link [ Upstream commit ccb4bda277999959bc852480d8684b13b926e657 ] No hw keys are ever uploaded for scanning/roc links and the link remove path already skips the key iteration for them. The add path still runs it, and since mt7996_set_hw_key() resolves the target through mvif->link[link_id] rather than the offchannel link, starting a scan on another band re-uploads the group keys of the link sharing the same link_id, re-sending its BSS cipher info and, for BIGTK with beacon protection on an AP link, toggling its beacons off and on. Skip the key iteration for offchannel links, mirroring the remove path. Fixes: 69d54ce7491d ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Link: https://patch.msgid.link/20260724124813.3961474-18-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6bce0f1280c94af8314f895f404629da09f0788c Author: Felix Fietkau Date: Fri Jul 24 12:48:01 2026 +0000 wifi: mt76: mt7915: unlink TWT flow if the MCU rejects the agreement [ Upstream commit 16a04441eab0dcd4d7126a6f66b370adbf28f96d ] The flow is added to dev->twt_list before sending the agreement to the firmware, but the error path leaves it linked while flowid_mask is never set. The flow slot can then be reused and memset while still on the list, corrupting twt_list, and station removal leaves a dangling entry behind that mt7915_mac_twt_sched_list_add() later walks. Fixes: 3782b69d03e7 ("mt76: mt7915: introduce mt7915_mac_add_twt_setup routine") Link: https://patch.msgid.link/20260724124813.3961474-17-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 40f3bfbbb222b92278f3797614b70f68d46824ac Author: Yonghong Song Date: Tue Jul 28 22:02:04 2026 -0700 bpf, x86: Fix trampoline stack size for 128-bit arguments [ Upstream commit 814cba835ef648e0c5eb79505c96c0493b29eea6 ] btf_distill_func_proto() accepts a function argument up to 16 bytes, so a 128-bit scalar such as __int128 reaches the x86 trampoline with arg_size == 16. But the current implementation assumes an __int128 argument only needs one register, so the register save area is under-allocated and save_args() overwrites adjacent stack slots. Compute the register count from arg_size for all arguments to fix it. Fixes: a9c5ad31fbdc ("bpf: x86: Support in-register struct arguments in trampoline programs") Signed-off-by: Yonghong Song Acked-by: Leon Hwang Link: https://lore.kernel.org/bpf/20260729050204.2586457-1-yonghong.song@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit f6202ed975070c580227771193e862b1b949ea24 Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:14 2026 -0300 perf machine: Check snprintf truncation for guest kallsyms path [ Upstream commit d04ef71492fad7230d474efe33d05f4c0563d409 ] machines__create_guest_kernel_maps() builds the guest kallsyms path with snprintf() without checking the return value. A truncated path could pass the access() check if a prefix directory happens to contain a file named "kallsyms", leading to the wrong file being used for symbol resolution. Check for truncation and skip the directory. Fixes: a1645ce12adb ("perf: 'perf kvm' tool for monitoring guest performance from host") Reported-by: sashiko-bot Cc: Zhang, Yanmin Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit eaa350a2ec347b80f2045d1e722d514ced315786 Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:13 2026 -0300 perf machine: Free scandir entries in guest kernel map creation [ Upstream commit f53bf58dcd11e1cb088d3b91a035fef77062094b ] machines__create_guest_kernel_maps() calls scandir() which allocates both the namelist array and each individual dirent entry. The code frees the namelist array but not the individual entries, leaking memory proportional to the number of directories under guestmount. Free each namelist[i] after it is no longer needed. Fixes: a1645ce12adb ("perf: 'perf kvm' tool for monitoring guest performance from host") Reported-by: sashiko-bot Cc: Zhang, Yanmin Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 9054ad50ffe27f39d0ff2c066bbf96e107601b88 Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:12 2026 -0300 perf machine: Reset errno before strtol in guest kernel map creation [ Upstream commit 29ec46e43f6ca7d6a6651db724d4ffd820f46e8b ] machines__create_guest_kernel_maps() checks errno == ERANGE after strtol() to detect overflow, but does not clear errno first. A stale ERANGE from an earlier library call (e.g. scandir internals) causes valid numeric directory names to be incorrectly skipped. Set errno = 0 before strtol() so only the current conversion can trigger the ERANGE check. Fixes: a1645ce12adb ("perf: 'perf kvm' tool for monitoring guest performance from host") Reported-by: sashiko-bot Cc: Zhang, Yanmin Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit c0b06d47ac32990f43bcc72933985bd68bf5b8b8 Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:11 2026 -0300 perf machine: Don't abort guest map creation on first inaccessible dir [ Upstream commit b687e1a418fb819ef83c362d84c216a6a841e3b0 ] machines__create_guest_kernel_maps() jumps to the failure label when one guest directory's kallsyms file fails access(), skipping all remaining valid guest directories. An inaccessible directory is not fatal — other guests may still be reachable. Replace 'goto failure' with 'continue' so the loop processes all directories, and remove the now-unreferenced failure label. Fixes: a1645ce12adb ("perf: 'perf kvm' tool for monitoring guest performance from host") Reported-by: sashiko-bot Cc: Zhang, Yanmin Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b3b3175103acf5ea059721dd1cceee07e2cab777 Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:10 2026 -0300 perf machine: Check snprintf truncation in machines__findnew() [ Upstream commit cc6abe0012bf8c04af8275266f8ed7c55ba4a5fb ] The guestmount path is built with snprintf() into a PATH_MAX buffer without checking the return value. If symbol_conf.guestmount is long enough to cause truncation, the truncated path could match a different directory, causing the wrong guest to be associated with the pid. Check for truncation and bail out early. Fixes: a1645ce12adb ("perf: 'perf kvm' tool for monitoring guest performance from host") Reported-by: sashiko-bot Cc: Zhang, Yanmin Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 15159fc5441bcb9462e08a66b9436fe01465c651 Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:09 2026 -0300 perf machine: Guard against NULL strlist in machines__findnew() [ Upstream commit e27b96d0a34e1dc87affecf221a99fee8f6c5afc ] The static 'seen' strlist caches guestmount paths that have already been reported as inaccessible, to avoid repeating the error message. If strlist__new() fails (OOM), 'seen' stays NULL and the next call dereferences it via strlist__has_entry() and strlist__add(). Guard both calls so that on allocation failure the error message is still printed (just not deduplicated) instead of crashing. Fixes: c80c3c269011 ("perf kvm: Limit repetitive guestmount message to once per directory") Reported-by: sashiko-bot Cc: David Ahern Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit e3a2ed4c0e8e0d56dd10e8c4d1076f22f7abd75c Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:08 2026 -0300 perf machine: Fix NULL parent dereference in fork event processing [ Upstream commit 73ac546bd6ba8ed4dc8d7a90fcb9bb8236de1568 ] machine__process_fork_event() calls machine__findnew_thread() for the parent thread, which can return NULL on allocation failure. The code then dereferences parent via thread__pid(parent) without a NULL check when validating whether the parent PID matches. The later NULL check at thread__fork() does not prevent this earlier dereference. Add a NULL guard before accessing the parent thread. Fixes: 5cb73340d92a ("perf tools: Make fork event processing more resilient") Reported-by: sashiko-bot Cc: Adrian Hunter Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 28bb9ea64c0c5de36eb0f6a6d79dbfc339796ebb Author: Arnaldo Carvalho de Melo Date: Sun Jul 26 20:40:07 2026 -0300 perf machine: Fix fd leak on bounds check in maps__set_modules_path_dir() [ Upstream commit 23010160bb9fd6e7ce940e232cd660b37ab9b20b ] The bounds check for root_len >= path_size returns -1 directly without closing the directory fd opened by io_dir__init() a few lines above. Jump to the out label instead, which calls close(iod.dirfd). Fixes: e7af1946818b ("perf machine: Reuse module path buffer") Reported-by: sashiko-bot Cc: Ian Rogers Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 0b950aa7ec95e120b2bde745ca9a7ed3ce49d528 Author: Joy Zou Date: Fri Jul 31 18:21:43 2026 +0800 regulator: core: use system_freezable_wq for init complete work [ Upstream commit 03eab318cedd6ae34ecd34533cd986edf5237164 ] schedule_delayed_work() uses system_wq, which is non-freezable, allowing regulator_init_complete_work to run concurrently with system suspend. This work fires ~30s after boot to disable unused regulators via I2C. When it races with PM suspend, the I2C adapter may already be suspended, triggering a -ESHUTDOWN warning in __i2c_transfer(): WARNING: ... at __i2c_transfer+0x36c/0x3c8 Call trace: __i2c_transfer i2c_transfer regmap_i2c_write _regmap_update_bits regulator_disable_regmap _regulator_do_disable regulator_late_cleanup regulator_init_complete_work_function process_one_work Switch to system_freezable_wq so the work is frozen before any device is suspended, eliminating the race. Fixes: 55576cf18537 ("regulator: Defer init completion for a while after late_initcall") Signed-off-by: Joy Zou Reviewed-by: Frank Li Link: https://patch.msgid.link/20260731-b4-regulator-pf01-v2-1-a406c8737fdb@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2e2d63f68211e9334b7158d38c8f6dfb7943c787 Author: Andrey Golovko Date: Mon Jul 27 12:33:09 2026 +0300 ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach [ Upstream commit b627da43035744ca4d691fbf56eef60268319873 ] When the peripheral re-attaches after the SoundWire controller was power-gated during system suspend (s2idle reaching S0i3 on AMD ACP), the amplifier has lost all of its register and DSP state. tas_update_status() handles that by re-running tas_io_init(), which writes the device's TAS2783_SW_RESET register - a vendor register write that clears the device's register file and DSP state, not a SoundWire reset, so no re-enumeration is involved - and re-downloads the firmware. Before doing any of that, it syncs back a register cache that still holds the pre-suspend values. That sync is useless, since the reset immediately wipes whatever it wrote, and it leaves the cache claiming that the amplifier is already powered up and unmuted. Subsequent read-modify-write updates - DAPM amplifier power-up, SDCA PDE transitions at stream start - then see "no change" and skip the hardware write. Playback runs without a single error while the speakers stay silent. Unbinding and rebinding the driver restores audio, since probe starts from a fresh cache. Drop the cache instead of syncing it when an uninitialized device attaches, so that later accesses see the real hardware state. Reordering the sync after tas_io_init() and marking the cache dirty is not a workable alternative here: tas_regmap has no .writeable_reg, so the cache accepts every register up to .max_register, including ones for which tas2783_sdca_mbq_size() returns 0. regmap_sdw_mbq_size() rejects those with -EINVAL, so the replay fails on the first such register and takes initialization down with it. Cached user settings fall back to hardware defaults across such a power loss, which seems clearly preferable to a silent amplifier - the device is being reset and its firmware reloaded at this point anyway. Tested on an ASUS ProArt PX13 HN7306EAC (AMD Strix Halo, ACP7.0, two TAS2783 amplifiers plus RT721 on SoundWire link 1): the speakers work after an s2idle resume with ~51 s of S0i3 residency, where previously they stayed silent despite a complete firmware re-download. Fixes: 4cc9bd8d7b32 ("ASoc: tas2783A: Add soundwire based codec driver") Reported-by: Antoine Monnet Closes: https://lore.kernel.org/all/c66ae00a-e878-4af0-a05a-272e9574eaa5@montane.tech/ Signed-off-by: Andrey Golovko Link: https://patch.msgid.link/3e2751d1fb027bed0f09c88e5e56da8f@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5589af278c504a7c2d1a9bc71d03bd0528ae20dd Author: Pengpeng Hou Date: Sat Jul 4 11:57:46 2026 +0800 ASoC: codecs: tas2783-sdw: Propagate regcache_sync() errors [ Upstream commit 0d6b2d6f93a6715827a9b3c027cd8448d76e0e47 ] regcache_sync() can fail while replaying cached register state after SoundWire resume or attach handling. tas2783 currently ignores that failure. Propagate the error and restore cache-only/dirty state on failure. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704035746.82560-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Stable-dep-of: b627da430357 ("ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach") Signed-off-by: Sasha Levin commit 551f3e27486bc4c9680ecf408638a46eba8a1d23 Author: Charles Keepax Date: Tue May 12 11:30:22 2026 +0100 ASoC: tas2783: Use new SoundWire enumeration helper [ Upstream commit ac6d4f298160bebf6979e63c2758414af5266f28 ] Update the driver to use the new core helper that waits for the device to enumerate on SoundWire and be initialised by the SoundWire core. Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260512103022.1154645-19-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Stable-dep-of: b627da430357 ("ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach") Signed-off-by: Sasha Levin commit 0b5c09512f21b615a6ffa7129bf33ae37368eed1 Author: Charles Keepax Date: Tue May 12 11:30:05 2026 +0100 soundwire: Add a helper function to wait for device initialisation [ Upstream commit 3492e8b494c18028044d4a2e03db5c7331fbd789 ] Add a new helper function to wait for the device to enumerate and be initialised by the SoundWire core. Most of the SoundWire drivers have very similar boiler plate code in their runtime resume, and that boiler plate tends to access various internals of the SoundWire structs which is a mild layering violation. Adding a new core helper function greatly eases both of these issues. Acked-by: Vinod Koul Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260512103022.1154645-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Stable-dep-of: b627da430357 ("ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach") Signed-off-by: Sasha Levin commit f5bb3471c9f46c6cabc06a152c13fc518330913e Author: Jeff Johnson Date: Mon Jul 27 16:39:41 2026 -0700 wifi: ath11k: fix leak in ath11k_service_ready_ext_event() [ Upstream commit 0293be2212d319d59589082461abf2a9b626cd1c ] Currently, during ath11k_service_ready_ext_event() processing, svc_rdy_ext.mac_phy_caps can be allocated during TLV parsing. This is a temporary allocation that is freed on the success path, but not on the error path. If parsing succeeds far enough to allocate mac_phy_caps and then fails on a later TLV, the allocation leaks. So free the allocation on the error path. Compile tested only. Fixes: 5b90fc760db5 ("ath11k: fix wmi service ready ext tlv parsing") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260727-ath11k_service_ready_ext_event-memleak-v1-1-e8373d27bdd1@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 83bc4eab83ae5ab88d410148a2e73e09e6f21c04 Author: Konrad Dybcio Date: Tue Jul 28 15:20:47 2026 +0200 drm/msm/dsi: Drop dev_pm_opp_set_rate(0) [ Upstream commit 06b7ba206561619bb34116f49e0ef26b867ce3aa ] dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Drop the explicit call to it. Every call site of ops->link_clk_disable() is followed by pm_runtime_put(), so the power vote will be rescinded if deemed safe. Fixes: 32d3e0feccfe ("drm/msm: dsi: Use OPP API to set clk/perf state") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/742783/ Link: https://lore.kernel.org/r/20260728-topic-dpu_power-v1-3-e7783b859a70@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit e0d1d1253ea2a1a005e50251a269f8c5ed374e6e Author: Konrad Dybcio Date: Tue Jul 28 15:20:46 2026 +0200 drm/msm/dp: Drop dev_pm_opp_set_rate(0) [ Upstream commit cebfa9909e27ec7b7cbaec25ee5516cf886baa39 ] dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Drop the explicit calls to it. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/742781/ Link: https://lore.kernel.org/r/20260728-topic-dpu_power-v1-2-e7783b859a70@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit be73b1984086f05962b022e6c7c5e856f685eeaa Author: Konrad Dybcio Date: Tue Jul 28 15:20:45 2026 +0200 drm/msm/dpu: Drop sneaky dev_pm_opp_set_rate(0) [ Upstream commit 811c38907eab0f66c22c5e5708e6f8eab14d76fa ] dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Prevent that from happening when _dpu_core_perf_get_core_clk_rate() returns 0. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/742779/ Link: https://lore.kernel.org/r/20260728-topic-dpu_power-v1-1-e7783b859a70@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 81d21396fea2dd752b0b7a5e5602b56d30e60e04 Author: Leo Yan Date: Thu Jul 2 18:05:21 2026 +0100 perf: arm_spe: Make wakeup range check overflow safe [ Upstream commit fcc5eaea2d234162dfb8258372dd897bc2a1b862 ] The current code checks whether the wakeup point is in the current writable range by comparing it with handle->head + handle->size. The perf AUX head is a monotonically increasing index, so that addition can overflow when head is close to ULONG_MAX. In that case, a wakeup point which is still inside the free space range can be missed. Use unsigned subtraction to compare the distance from head to wakeup against the handle->size. This can dismiss the issue when addition overflow. This is unlikely to happen in practice, but the change makes the watermark check logically correct. Fixes: d5d9696b0380 ("drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension") Signed-off-by: Leo Yan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ad1d83816b8457e36f30ade80e5a6e09422024fa Author: Dmitry Baryshkov Date: Wed Jul 22 09:36:30 2026 +0300 drm/msm/dp: do not reject wide-bus modes while a YUV420 mode is active [ Upstream commit bd926e62d355879133452bc3889447f8e89757f2 ] msm_dp_bridge_mode_valid() halves the candidate mode's pixel clock when the sink either uses YUV 420 output or drives the wide bus, so that modes relying on those to stay under DP_MAX_PIXEL_CLK_KHZ are accepted. The wide bus part is queried through msm_dp_wide_bus_available(), which returns false whenever the currently committed mode uses YUV 420 output: it inspects the stored msm_dp_mode.out_fmt_is_yuv_420 of the active mode, not the mode being validated. Consequently, while a YUV 420 mode is active, an RGB mode that needs the wide bus to fit under DP_MAX_PIXEL_CLK_KHZ has its pixel clock left un-halved and is wrongly rejected as MODE_CLOCK_HIGH. The candidate mode's YUV 420 status is already evaluated as is_yuv_420, and the wide bus is disabled precisely for YUV 420 output, so halving the pixel clock for either case is equivalent to halving it when the candidate is YUV 420 or the controller supports the wide bus. Test wide_bus_supported directly, so the decision no longer depends on the format of the active mode. Fixes: df9cf852ca30 ("drm/msm/dp: account for widebus and yuv420 during mode validation") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/741740/ Link: https://lore.kernel.org/r/20260722-drm-msm-display-interface-v1-15-368c10fe62fd@oss.qualcomm.com Signed-off-by: Sasha Levin commit 6572b5a74ab1c71c542429cacbd11c222d192197 Author: Dmitry Baryshkov Date: Wed Jul 22 09:36:16 2026 +0300 drm/msm/dp: reject YUV420-only modes without VSC SDP support [ Upstream commit 684f95fb4e9ad10aac39fbb1fa7592a59d7f54ea ] DP conveys YUV 420 colorimetry through a VSC SDP. A sink that advertises a mode as YUV-420-only therefore cannot be driven at all unless the panel supports VSC SDP, yet msm_dp_bridge_mode_valid() only used the VSC SDP capability to decide whether to halve the pixel clock, otherwise letting such modes through to be validated (and possibly accepted) at the full RGB clock the sink cannot display. Reject 420-only modes with MODE_NO_420 when the panel does not support VSC SDP. With those modes filtered out, being a 420-only mode implies VSC SDP support, so the YUV-420 test reduces to drm_mode_is_420_only(): drop msm_dp_is_yuv_420_enabled() and call the DRM helper directly at its two callers (the DPU encoder already has the connector from the atomic state). Fixes: df9cf852ca30 ("drm/msm/dp: account for widebus and yuv420 during mode validation") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/741713/ Link: https://lore.kernel.org/r/20260722-drm-msm-display-interface-v1-1-368c10fe62fd@oss.qualcomm.com Signed-off-by: Sasha Levin commit 08827aa40f0ee9d37dcff8d6acb340b970051486 Author: Dmitry Baryshkov Date: Thu Jul 23 12:52:12 2026 +0300 drm/msm: don't tear down KMS twice when KMS init fails [ Upstream commit 93c125e4ea98fb25f927ba5a334d85845127d667 ] When priv->kms_init() (mdp4_kms_init() / mdp5_kms_init()) fails partway through, both display drivers already tear their KMS state down via mdp4_destroy() / mdp5_kms_destroy() before returning the error. The common error path in msm_drm_init() then runs msm_drm_uninit() -> msm_drm_kms_uninit(), which tries to destroy the very same KMS a second time, which causes a use-after-free crash. Bring MDP4/MDP5 in line with the DPU driver whose dpu_kms_init() doesn't perform error cleanup on the failure. Let the common path own the cleanup, instead of freeing the KMS from their error paths. The crash trace for the reference: __lock_acquire from lock_acquire (kernel/locking/lockdep.c:5906 kernel/locking/lockdep.c:5863) lock_acquire from touch_wq_lockdep_map (kernel/workqueue.c:4094 (discriminator 1)) touch_wq_lockdep_map from __flush_workqueue (kernel/workqueue.c:4136) __flush_workqueue from msm_drm_kms_uninit (drivers/gpu/drm/msm/msm_kms.c:243 (discriminator 33)) msm_drm_kms_uninit from msm_drm_uninit (drivers/gpu/drm/msm/msm_drv.c:93) msm_drm_uninit from msm_drm_init (drivers/gpu/drm/msm/msm_drv.c:184) msm_drm_init from try_to_bring_up_aggregate_device (drivers/base/component.c:249 drivers/base/component.c:227) try_to_bring_up_aggregate_device from __component_add (drivers/base/component.c:269 drivers/base/component.c:748) __component_add from dsi_host_attach (drivers/gpu/drm/msm/dsi/dsi_host.c:1739) dsi_host_attach from mipi_dsi_attach (drivers/gpu/drm/drm_mipi_dsi.c:383) mipi_dsi_attach from sharp_nt_panel_probe (drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c:247) Fixes: 506efcba3129 ("drm/msm: carve out KMS code from msm_drv.c") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/742068/ Link: https://lore.kernel.org/r/20260723-msm-fix-crash-v1-1-78fb4721c2d9@oss.qualcomm.com Signed-off-by: Sasha Levin commit 64976f3b34b07eb866ead4052cefe7e9ff45fd2f Author: Can Peng Date: Wed Jul 29 10:36:05 2026 +0800 ACPI: processor: Unregister cpufreq notifier on init failure [ Upstream commit 06f32dd67e6b23a05bef0d8183c5335af91c0c3b ] acpi_processor_driver_init() registers the cpufreq policy notifier before registering the ACPI processor driver and setting up CPU hotplug state. If driver_register() or cpuhp_setup_state() fails, the error path only unregisters the ACPI processor driver and the idle driver. The cpufreq notifier remains registered even though initialization failed. Mirror the module exit path on the init failure path and unregister the cpufreq notifier when it has been registered. Fixes: c0e0421a60bf ("ACPI: processor: Reorder acpi_processor_driver_init()") Signed-off-by: Can Peng Link: https://patch.msgid.link/20260729023605.197367-1-pengcan@kylinos.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6cffb59ee50ea4fc0959d83a7b1d7e198d406d2c Author: Huisong Li Date: Tue Dec 23 18:09:09 2025 +0800 ACPI: processor: idle: Optimize ACPI idle driver registration [ Upstream commit 13ebeef6a1b9c4e5c9789f835cc4ec34873f0bb1 ] Currently, the ACPI idle driver is registered from within a CPU hotplug callback. Although this didn't cause any functional issues, this is questionable and confusing. And it is better to register the cpuidle driver when all of the CPUs have been brought up. So add a new function to initialize acpi_idle_driver based on the power management information of an available CPU and register cpuidle driver in acpi_processor_driver_init(). This commit has four changes under the commit 7a8c994cbb2d (ACPI: processor: idle: Optimize ACPI idle driver registration): 1) move acpi_processor_register_idle_driver() ahead of the driver_register(). 2) add acpi_processor_cstate_first_run_checks() before calling acpi_processor_get_power_info(). 3) squash the commit 9d68320b2bca (ACPI: processor: idle: Fix function defined but not used warning) into this change. 4) use for_each_possible_cpu(cpu) to scan all possible cpus. Signed-off-by: Huisong Li Tested-by: Borislav Petkov (AMD) [ rjw: New comment edits, changelog tweak ] Link: https://patch.msgid.link/20251223100914.2407069-2-lihuisong@huawei.com Signed-off-by: Rafael J. Wysocki Stable-dep-of: 06f32dd67e6b ("ACPI: processor: Unregister cpufreq notifier on init failure") Signed-off-by: Sasha Levin commit efc57983a1d4689212deb7d2f815df9a8f278052 Author: Felix Fietkau Date: Fri Jul 24 12:47:58 2026 +0000 wifi: mt76: only consume the WO drop bit on WED v2 devices [ Upstream commit 1df54335590bb025c3bd706a9ba9c6e73a1d3000 ] The RX path is handled by the WO MCU only on WED v2 hardware. On WED v3 the same buf1 bit does not carry drop information, so evaluating it there causes spurious RX drops. Fixes: e4d2b8bcac11 ("wifi: mt76: drop the incorrect scatter and gather frame") Link: https://patch.msgid.link/20260724124813.3961474-14-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 19f108fee1470878e9892b4b00c7a53ccf2a4a54 Author: StanleyYP Wang Date: Fri Jul 24 12:47:57 2026 +0000 wifi: mt76: mt7996: add missing rdd_idx check when enabling background radar [ Upstream commit dbca5c4d29826cecd3185fb1ae2746205ab55127 ] Add the missing rdd idx check (< 0) in mt7996_mcu_rdd_background_enable(). mt7996_get_rdd_idx() returns -1 for phys without 5 GHz support, and the negative index was passed to the RDD MCU command unchecked. Fixes: 1529e335f93d ("wifi: mt76: mt7996: rework radar HWRDD idx") Signed-off-by: StanleyYP Wang Link: https://patch.msgid.link/20260724124813.3961474-13-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b93d0f07ed040013fd0a44b837adec52f13fcee1 Author: Felix Fietkau Date: Fri Jul 24 12:47:56 2026 +0000 wifi: mt76: mt7915: use little-endian for bss_info_ra wire fields [ Upstream commit 04280d0a56be4264720e7b205daaa332c715e5ec ] train_up_high_thres, train_up_rule_rssi and low_traffic_thres were declared as host-native short in a firmware-facing TLV and assigned host-order constants, so on a big-endian host the firmware received byte-swapped rate-adaptation thresholds. Declare them __le16 and convert with cpu_to_le16(). Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Link: https://patch.msgid.link/20260724124813.3961474-12-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 92dc45686b9f142da9c69a7e02572d199ae3f7aa Author: Felix Fietkau Date: Fri Jul 24 12:47:53 2026 +0000 wifi: mt76: mt7996: don't leak MLD group index on remap alloc failure [ Upstream commit 151a6cf0d12f5d333b93b634dbe5834ea0b77ce7 ] mt7996_change_vif_links() sets the mld_idx_mask group bit before allocating the remap index. If the remap allocation fails it jumped to the exit without clearing that bit, permanently consuming one of the 16 MLD group slots. Release the group bit on the error path. Fixes: 4fb3b4e7d1ca ("wifi: mt76: mt7996: fix MLD group index assignment") Link: https://patch.msgid.link/20260724124813.3961474-9-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 45d8896e4cffffb2c6554ccbec6efe7a0d53166f Author: Felix Fietkau Date: Fri Jul 24 12:47:52 2026 +0000 wifi: mt76: mt7996: reserve space for the CSA-abort countdown TLV [ Upstream commit 50c66bab321140c49aa2ed779a3ec9d2f085b458 ] When a CSA countdown is active, mt7996_mcu_beacon_cntdwn() emits two bss_bcn_cntdwn_tlv entries (the CSA countdown and the CCA-abort BCC), but MT7996_BEACON_UPDATE_SIZE only reserved one. With MBSSID enabled and a near-maximum beacon template the extra 8 bytes could push the offload command past MT7996_MAX_BSS_OFFLOAD_SIZE and trigger skb_over_panic(). Reserve room for both countdown TLVs. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Link: https://patch.msgid.link/20260724124813.3961474-8-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 906ad486ba5c4933d82e1ebe0685656390a48450 Author: Felix Fietkau Date: Fri Jul 24 12:47:49 2026 +0000 wifi: mt76: mt7996: hold dev->mt76.mutex while disabling tx worker in SER [ Upstream commit 6190db312b8230813f529f014b26247c6d9800d0 ] mt7996_mac_reset_work() parked the tx worker and disabled the RX/TX NAPIs before taking dev->mt76.mutex. mt76_worker_disable()/_enable() are plain kthread park/unpark, not refcounted, and __mt76_set_channel() toggles the same worker and the MT76_RESET bit under the mutex. An L1 SER racing a channel switch could therefore have the worker unparked and MT76_RESET cleared while the reset path resets the DMA rings, corrupting descriptors or tokens. Take the mutex before disabling the worker, as mt7915 does. Fixes: 27015b6fbcca ("wifi: mt76: mt7996: enable full system reset support") Link: https://patch.msgid.link/20260724124813.3961474-5-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 507eddb8175a67df5086354b92d6a4fd7f6f1f96 Author: Felix Fietkau Date: Fri Jul 24 12:47:48 2026 +0000 wifi: mt76: mt7915: unwind state on add_interface failure [ Upstream commit 2fb6480c52f611338e1b0abe5e6219be1fc9ab75 ] When mt76_wcid_alloc() fails, mt7915_add_interface() returned without clearing the vif_mask/omac_mask bits it had already set, without removing the firmware dev info added earlier, and without clearing a monitor_vif pointer to the vif mac80211 is about to free. mac80211 does not call remove_interface() for a failed add, so the indices and firmware dev entry leaked permanently and testmode could dereference the stale monitor_vif. Add a proper error unwind. Fixes: b619e01380ee ("mt76: fix MBSS index condition in DBDC mode") Link: https://patch.msgid.link/20260724124813.3961474-4-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d0bb2189ade617e624f3c8f444ebb05f59bb2524 Author: Felix Fietkau Date: Fri Jul 24 12:47:46 2026 +0000 wifi: mt76: mt7996: bound TLV walk in mt7996_mcu_get_chip_config [ Upstream commit 44af52467e72094351a362bf69effd52f1d9c186 ] The response TLV loop advanced by tlv->len without a minimum, so a theoretical firmware response containing a zero-length TLV could spin forever, hanging the CPU during device probe. The u32 payload was also read without bounds checking. Reject a short fixed field, stop on a TLV whose length underruns the header or overruns the skb. Fixes: 5d33053be609 ("wifi: mt76: mt7996: add variants support") Link: https://patch.msgid.link/20260724124813.3961474-2-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 1c7ad1236bc6f7eb11e87f3d311e1c9d438ae3d1 Author: Rex Lu Date: Wed Jul 22 08:25:54 2026 +0000 wifi: mt76: check txfree done event on the WED hw path [ Upstream commit 3310e71a74b176d3613dfb42b6bc630d99e90cbb ] Check the txfree done event DW1 bit 15 when WED is enabled, to avoid the driver reading a txfree done event before WED has finished reading it. No need to check this flag on WED v2, otherwise SER will occur. The bit position was previously defined as MT_DMA_CTL_BURST, which is unused; rename it to match its function on the txfree ring. Fixes: 83eafc9251d6 ("wifi: mt76: mt7996: add wed tx support") Signed-off-by: Rex Lu Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260722082610.2699628-2-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 31faa92cd50742b70c234e20dcad03d9d0c458e4 Author: Felix Fietkau Date: Wed Jul 22 08:26:10 2026 +0000 wifi: mt76: mt7915: poll the correct SLP CTRL register for the second adie [ Upstream commit dd59a6126a8f1bd52bf6bd057bf0c8307f76a74b ] The clock enable path for the second adie sets MT_ADIE_SLP_CTRL_CK0(1) but polled the busy bit of MT_ADIE_SLP_CTRL_CK0(0), so dual-adie bring-up could proceed before the adie1 clock was stable. Fixes: 99ad32a4ca3a ("mt76: mt7915: add support for MT7986") Link: https://patch.msgid.link/20260722082610.2699628-18-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7ac05ed3a50e511c93f8506e555709a208dfce0a Author: Felix Fietkau Date: Wed Jul 22 08:26:09 2026 +0000 wifi: mt76: fix RXDMAD_C buffer recycling race [ Upstream commit e1f97c10a4ec2b9db69a134b757304399ca903ce ] The RXDMAD_C buffers come from the RRO data queues' page pools, which are bound to a different NAPI, so the direct page-pool recycle used here could race the owning NAPI; take the non-direct path as is already done for WED RX queues. Fixes: e50d4d710efd ("wifi: mt76: Add mt76_dma_get_rxdmad_c_buf utility routione") Link: https://patch.msgid.link/20260722082610.2699628-17-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 576683faa9381cbba784eecd608f7ade10d3d356 Author: Felix Fietkau Date: Wed Jul 22 08:26:08 2026 +0000 wifi: mt76: fix uninitialised RXDMAD_C descriptor info [ Upstream commit d3ecac68f73b11828e72eaf7952a9beb5caea12b ] Unlike other WED-RRO queues, RXDMAD_C frames continue into the skb build path, but mt76_dma_get_buf() skips the desc->info read for RRO queues, so the uninitialised on-stack info was stored into skb->cb and passed to rx_skb(); initialise it to zero. Fixes: e50d4d710efd ("wifi: mt76: Add mt76_dma_get_rxdmad_c_buf utility routione") Link: https://patch.msgid.link/20260722082610.2699628-16-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 423be355be5ae47f03a134a419cfad80b2661d60 Author: Felix Fietkau Date: Wed Jul 22 08:26:06 2026 +0000 wifi: mt76: fix stranded frames in mt76_txq_schedule_pending [ Upstream commit 422dd2db28ae27c35a586acd9ad482f30000c090 ] A wcid is added to phy->tx_list whenever either tx_pending or tx_offchannel becomes non-empty, but the requeue check after a partial schedule required BOTH queues to be non-empty. When mt76_txq_schedule_pending_wcid() returns -1 (queue stopped or MT76_RESET) it leaves frames in tx_pending while tx_offchannel is empty, so the wcid is dropped from every scheduling list and its frames stall until the next mt76_tx() for that wcid or wcid cleanup. This strands EAPOL/mgmt/nullfunc frames under momentary queue-full or across scan/channel-switch, causing association and 4-way-handshake timeouts. Requeue when either queue still holds frames, matching the enqueue condition. Fixes: 0b3be9d1d34e ("wifi: mt76: add separate tx scheduling queue for off-channel tx") Link: https://patch.msgid.link/20260722082610.2699628-14-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 471586e88861df649abd818f3d5d4bdd1ef2f625 Author: Felix Fietkau Date: Wed Jul 22 08:26:03 2026 +0000 wifi: mt76: mt7915: write RX header translation bit to the correct register [ Upstream commit 236145737480c4c0c515e09061d0d5f77cf52d3f ] MT_MDP_DCR0_RX_HDR_TRANS_EN is a field of MT_MDP_DCR0, but monitor-mode handling applied it to the per-band MT_DMA_DCR0 register instead. As a result RX header translation was never disabled in the MDP when entering monitor mode, and an undocumented bit of MT_DMA_DCR0 was toggled. Target MT_MDP_DCR0, matching the mt7996 driver. Fixes: b2491018587a ("wifi: mt76: mt7915: fix monitor mode issues") Link: https://patch.msgid.link/20260722082610.2699628-11-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 522101cbbb3bc2f0af1229f9d5f68a1b043365da Author: Felix Fietkau Date: Wed Jul 22 08:26:02 2026 +0000 wifi: mt76: mt7996: don't report a zero TX bitrate [ Upstream commit d4d92ccded678c92c390003926097ddbb6516bc7 ] mt7996_sta_statistics() set NL80211_STA_INFO_TX_BITRATE unconditionally after the block that already sets it, so a station with no rate info yet was reported to userspace with a valid-but-zero TX rate. Drop the redundant unconditional assignments; the in-block ones are sufficient. Fixes: b34f346b917e ("wifi: mt76: mt7996: drop return in mt7996_sta_statistics") Link: https://patch.msgid.link/20260722082610.2699628-10-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6ce78d04c7ea4b66838941b5a4232dd1ee0e2cc7 Author: Felix Fietkau Date: Wed Jul 22 08:26:01 2026 +0000 wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss [ Upstream commit 4a2f4be532e3ea4e2b536e411793a05aaa51af25 ] If a peer's VHT/HE MCS map has no supported spatial stream (all fields 0x3), the loop exits with nss == 0 and the function returned (u8)-1 (255), which was then written into the firmware sta_rec_bf beamforming fields. Clamp the result to 0. Fixes: 89029a85482c ("mt76: mt7915: add Tx beamformer support") Link: https://patch.msgid.link/20260722082610.2699628-9-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b4a41a47a67c788e6b0625fa517ec8872e99bb6c Author: Felix Fietkau Date: Wed Jul 22 08:26:00 2026 +0000 wifi: mt76: mt7915: clear wcid mask under mutex after RCU pointer clear [ Upstream commit 6486e11a6e2f679597af2d5bb48c3b07a2b2a7ba ] mt7915_remove_interface() cleared the wcid mask bit with no lock held and before clearing the RCU wcid pointer. The mask is a non-atomic RMW shared with the allocators, which all run under dev->mt76.mutex; on DBDC the two wiphys share one mt76_dev, so this raced add_interface/sta_add on the other band and could leak or double-hand-out a wcid. Clearing the bit before the RCU pointer also let a concurrent allocation reuse the index and publish its wcid, which the subsequent NULL assignment then wiped. Move the clear into the existing mutex section, after the RCU pointer is cleared. Fixes: f3049b88b2b3 ("wifi: mt76: mt7915: allocate vif wcid in the same range as stations") Link: https://patch.msgid.link/20260722082610.2699628-8-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit bf59177bab17b2a1bc5bc9ec6f2231f101faf75a Author: Felix Fietkau Date: Wed Jul 22 08:25:59 2026 +0000 wifi: mt76: mt7996: set MT76_MCU_RESET before waking MCU waiters on full reset [ Upstream commit 6469ae71e7e5d0132c934972f628f346ad0379cd ] mt7996_mac_full_reset() called wake_up(&dev->mt76.mcu.wait) without first setting MT76_MCU_RESET. The MCU response wait condition only checks the response queue and that bit, so the wake-up released nobody: a thread blocked in an MCU command against the dead firmware (typically holding dev->mt76.mutex) stayed asleep until its multi-second timeout, stalling recovery. Set the bit before the wake-up, as mt7915 does. Fixes: 27015b6fbcca ("wifi: mt76: mt7996: enable full system reset support") Link: https://patch.msgid.link/20260722082610.2699628-7-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0f53ece876e1f3bbb3e18f48afc4af1ee967b16c Author: Felix Fietkau Date: Wed Jul 22 08:25:58 2026 +0000 wifi: mt76: mt7996: validate RX band_idx before dereferencing phys[] [ Upstream commit 2243778a5fae8329ab5f18e7adcd7e03b911a1b7 ] band_idx comes from a 2-bit descriptor field (0-3) and was used directly to index dev->mt76.phys[] (size __MT_MAX_BAND == 3) and dereference the result. A corrupt or reserved descriptor value could index out of bounds or hit a NULL phy on parts with fewer bands. Reject invalid band indices, mirroring mt7996_rx_get_wcid(). Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Link: https://patch.msgid.link/20260722082610.2699628-6-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 310edc8f3f56ba67cb256e4c5a108adca608633d Author: Michael-CY Lee Date: Wed Jul 22 08:25:57 2026 +0000 wifi: mt76: assign link_id when sending probe request during scan [ Upstream commit f137fabc1313427e08af06a414d929ebd9fd37d6 ] The link_id in info->control.flags is required by mt7996 to select the correct mt76_wcid for transmission. Not assigning the link_id in info->control.flags is equivalent to assigning the link_id to 0, causing mt7996 to select link_id 0 for transmission, so probe requests sent on behalf of an MLD vif scanning via a different link were transmitted with the wrong per-link wcid. Fixes: 31083e38548f ("wifi: mt76: add code for emulating hardware scanning") Signed-off-by: Michael-CY Lee Link: https://patch.msgid.link/20260722082610.2699628-5-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fc7fae55255ccbde009232e84b102d2782a69ecf Author: Michael-CY Lee Date: Wed Jul 22 08:25:56 2026 +0000 wifi: mt76: fix non-AQL packet accounting for MLO stations [ Upstream commit 8ae659743ba936b22ecb4620815887728e2820d6 ] __mt76_tx_queue_skb() overrides the wcid passed by the driver with sta->drv_priv, so the wcid might incorrectly be changed after TX, causing wcid->non_aql_packets to be counted on the wrong wcid. For example, on the AP side, if a station's setup link is the 5G link and the station uses 2G to transmit a frame, the value of non_aql_packets is increased on the 5G wcid but decreased on the 2G wcid. Once the inflated counter exceeds MT_MAX_NON_AQL_PKT, the TX scheduler permanently refuses to service the station. Drop the reassignment and account on the wcid used for transmission. This also records the actual wcid in the queue entry. Fixes: e1378e5228aa ("mt76: rely on AQL for burst size limits on tx queueing") Signed-off-by: Michael-CY Lee Link: https://patch.msgid.link/20260722082610.2699628-4-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5183b9f092fc0041618f38f895bd0ad860c26ca9 Author: Peter Chiu Date: Wed Jul 22 08:25:55 2026 +0000 wifi: mt76: mt7996: fix MLD ID in MAC TXD and HIF TXP [ Upstream commit ce35ecffc96e6d097d27b6fe30677a2cfe2e0461 ] Problem: MCU command timeout while the firmware state is normal, and the firmware keeps showing the error log "ERROR!! NO PAUSE...". Root cause: If the MLD_ID field in the TXD is neither the primary link id nor the secondary link id, it may lead to a firmware busy loop when the third link is in power saving mode. Remap frames directed to a third link to the primary link wcid. Since TX status events and txfree completions carry the wcid the firmware saw, use the remapped wcid for packet id tracking and non-AQL packet accounting as well, while the frame keeps its original link context for addressing, band and OMAC selection. Fixes: 85cd5534a3f2 ("wifi: mt76: mt7996: use correct link_id when filling TXD and TXP") Signed-off-by: Peter Chiu Link: https://patch.msgid.link/20260722082610.2699628-3-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 990ec9215ebe11a43ffbe544fe31eb3872104f09 Author: Felix Fietkau Date: Tue Mar 24 15:49:03 2026 +0000 wifi: mt76: mt7996: fix out-of-bounds array access during hardware restart [ Upstream commit 7ec087fef32a88410488b764b0f5eef68e51175f ] During hardware restart, link_id can be IEEE80211_LINK_UNSPECIFIED, causing an out-of-bounds array access on msta->link[]. Add mt7996_sta_link() and mt7996_sta_link_protected() helper functions for accessing sta links with proper RCU handling and bounds checking. Use them for any sta link RCU access. Reported-by: Chad Monroe Link: https://patch.msgid.link/20260324154904.2555603-1-nbd@nbd.name Signed-off-by: Felix Fietkau Stable-dep-of: ce35ecffc96e ("wifi: mt76: mt7996: fix MLD ID in MAC TXD and HIF TXP") Signed-off-by: Sasha Levin commit 25b765aa9a61fb08e832bbb34a1ca6e404299310 Author: StanleyYP Wang Date: Mon Dec 15 14:37:24 2025 +0800 wifi: mt76: mt7996: set specific BSSINFO and STAREC commands after channel switch [ Upstream commit 7247037a016ed4bc8a50507d74d0bae98409ae3f ] After channel switch, some tags of BSSINFO (rfch) and STAREC (bfer, rate_ctrl) commands should also be updated. Otherwise, a BSS might not be able to transmit with its peer using correct bandwidth. Co-developed-by: Shayne Chen Signed-off-by: Shayne Chen Signed-off-by: StanleyYP Wang Link: https://patch.msgid.link/20251215063728.3013365-3-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Stable-dep-of: ce35ecffc96e ("wifi: mt76: mt7996: fix MLD ID in MAC TXD and HIF TXP") Signed-off-by: Sasha Levin commit 5c350e3b6065f9bea61f6e3835bc7c28f4505a42 Author: Shayne Chen Date: Thu Nov 6 14:41:55 2025 +0800 wifi: mt76: mt7996: support fixed rate for link station [ Upstream commit feb06d4556203cd27cf3fa31147d43f28f329653 ] Introduce mt7996_link_sta_add_debugfs() to extend fixed rate support for MLO link station. Co-developed-by: Howard Hsu Signed-off-by: Howard Hsu Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20251106064203.1000505-4-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Stable-dep-of: ce35ecffc96e ("wifi: mt76: mt7996: fix MLD ID in MAC TXD and HIF TXP") Signed-off-by: Sasha Levin commit 62aea1d45b524cde9e02d1e7f65d2c4fd60871b8 Author: Rex Lu Date: Wed Jul 22 08:25:53 2026 +0000 wifi: mt76: fix RX data queuing of RRO 3.0 [ Upstream commit 86897f106669c07eea4c34b54c3268d448d41426 ] For RRO 3.0, RX data released from a RRO data queue should be put to the indicator queue. The frames are processed and completed in the context of the indicator queue NAPI, which only polls skbs queued on the MT_RXQ_RRO_IND list; frames queued under the data queue id are left sitting on that list until the data queue NAPI happens to run, stalling and reordering RX data. Fixes: b1e58e137b61 ("wifi: mt76: mt7996: Introduce RRO MSDU callbacks") Signed-off-by: Rex Lu Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260722082610.2699628-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 97a77dc0abd909c29eae1e5da0a0d9f059eefc89 Author: Shayne Chen Date: Fri Mar 13 14:21:50 2026 +0800 wifi: mt76: mt7996: fix capability of EHT-MCS 15 in MRU [ Upstream commit 29e889c4ada83c69d10a3937f5ae2934306e2e3d ] According to the definition in IEEE Std 802.11be-2024, Table 9-417r: - If 80 MHz is not supported, bit 1-3 are set to 0. - If 160 MHz is not supported, bit 2-3 are set to 0. - If 320 MHz is not supported, bit 3 is set to 0. Fixes: 348533eb968d ("wifi: mt76: mt7996: add EHT capability init") Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260313062150.3165433-2-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 674e0ad0ae15fcc017a561c0eec9fbd17a6430f1 Author: Chad Monroe Date: Tue Jul 21 18:53:32 2026 +0000 wifi: mt76: mt7996: fix EAPOL source BSS for non-MLD stations [ Upstream commit 6bb5066cfcd4296ac5e0b6872f43f96a43bfe566 ] A non-MLD station's EAPOL and data frames are tagged with link_id == IEEE80211_LINK_UNSPECIFIED, which now skips the per-link lookup in mt7996_mac_write_txwi() and leaves omac_idx/band_idx/wmm_idx at slot 0. When the radio also runs AP VAPs the station's omac is non-zero (get_omac_idx() prefers HW BSSID slots 1-3), so its EAPOL frames egress from the wrong BSS and the 4-way handshake times out even though association succeeds. In mt7996_tx_prepare_skb(), resolve the link from the peer wcid when link_id is UNSPECIFIED and the wcid is not the global entry, restoring the pre-MLO behaviour for station traffic. Fixes: 729c83a3330c ("wifi: mt76: mt7996: fix reading zeroed info->control.flags after mt76_tx_status_skb_add()") Signed-off-by: Chad Monroe Link: https://patch.msgid.link/20260721185333.2419297-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ddf6a17d8e3d0dbb841c13c10d7c1340a138a80d Author: Eason Lai Date: Fri Jul 3 08:59:45 2026 +0800 wifi: mt76: mt792x: Fix memory leak in SDIO TX path [ Upstream commit 808f2767d4217a5b96f674288573b9b89d432eed ] When tx_prepare_skb() returns an error in the SDIO TX path, the skb is not freed, leading to a memory leak. This can occur when zero-length frames (such as WNM NULL frames) are dropped to prevent potential hardware TX hangs. Fix this by properly releasing the skb with ieee80211_tx_status_ext() when tx_prepare_skb() fails. Fixes: b747fa343817 ("mt76: mt7915: drop zero-length packet to avoid Tx hang") Signed-off-by: Eason Lai Link: https://patch.msgid.link/20260703005945.2244533-1-eason.lai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 52c7bcf067861e8b89842e31ac290ab25d5fc93f Author: Jared.Huang Date: Wed Jun 17 15:13:20 2026 +0800 wifi: mt76: mt7925: fix msg len mismatch between driver and firmware [ Upstream commit 9ddb7487aa7cccb6e1880b4151ab5895109eb8d6 ] The mt7925_tx_power_limit_tlv struct begins with a 4-byte rsv[] field that acts as a UNI command header prefix. The firmware dispatcher did not use the 4-byte rsv[] and will only check the payloads after the 4-byte rsv[] As a result, the total message length minus the 4-byte prefix. Fix this by setting len to msg_len - 4. Fixes: ccb186326bb6 ("wifi: mt76: mt7925: fix incorrect length field in txpower command") Signed-off-by: Jared.Huang Link: https://patch.msgid.link/20260617071320.1808499-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 383bb0511dfe6500c498d85a329d0abfeb892d46 Author: Jared.Huang Date: Wed Jun 17 15:13:05 2026 +0800 wifi: mt76: mt7925: update clc before setting sar power table [ Upstream commit 8a27c5c764040fbc990cc416a927b1d7eadf559f ] Fix the power table update sequence to ensure CLC is loaded before setting SAR power table. The firmware requires CLC baseline to be established first to properly calculate the final power limit as min(clc_limit, rate_limit,sar_limit). Fixes: 9557b6fe0c8b ("wifi: mt76: mt7925: refine the txpower initialization flow") Signed-off-by: Jared.Huang Link: https://patch.msgid.link/20260617071305.1808394-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 670b3dc4e3713542a9f002d38fb9d1740b9e342b Author: Eason Lai Date: Wed May 6 15:04:58 2026 +0800 wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash [ Upstream commit 915672c5ae32deeb72f4572856d123f314791136 ] When an AER error occurs and the bus is hung, the register reads return 0xFFFFFFFF, causing the DMA queue state to be corrupted and resulting in an invalid memory access when accessing q->desc[] or q->entry[]. Unable to handle kernel paging request at virtual address ffffffc01099eac0 pc : mt76_dma_add_buf+0x124/0x188 [mt76] lr : mt76_dma_rx_fill+0x11c/0x1d8 [mt76] sp : ffffffc016d9bbf0 x29: ffffffc016d9bc10 x28: 0000000000000000 x27: 0000000000000000 x26: ffffffb7855e50b8 x25: ffffffb80d04f000 x24: 0000000000000000 x23: 0000000000000ec0 x22: ffffffb796803648 x21: ffffffb796801f80 x20: ffffffb7968035f8 x19: 0000000000000ec0 x18: 0000000000000000 x17: 000000004ec00000 x16: 000000000ec00000 x15: ffffffc01099eac0 x14: 000000004ec00000 x13: 00000000ffc5a000 x12: ffffffc016d9bc32 x11: 00000000ffffffff x10: 0000000000000002 x9 : 0000000000000000 x8 : 000000000000b4ac x7 : 0000000000000a20 x6 : ffffffb6c1806400 x5 : 0000000000000000 x4 : ffffffb80d04f000 x3 : 0000000000000000 x2 : 0000000000000001 x1 : 000000000ec04000 x0 : ffffffb7968035f8 Call trace: mt76_dma_add_buf+0x124/0x188 [mt76 (HASH:1029 4)] mt76_dma_rx_reset+0xe8/0xfc [mt76 (HASH:1029 4)] mt7921_wpdma_reset+0x188/0x1b0 [mt7921e (HASH:ee48 5)] mt7921e_mac_reset+0x128/0x418 [mt7921e (HASH:ee48 5)] mt7921_mac_reset_work+0xac/0x1a8 [mt7921_common (HASH:f721 6)] process_one_work+0x188/0x514 worker_thread+0x12c/0x300 kthread+0x140/0x1fc ret_from_fork+0x10/0x30 Fix the invalid memory access by validating the DMA index read from the hardware before it is used as a queue index. An out-of-range value, such as the 0xFFFFFFFF returned while the bus is hung, is now clamped so it can no longer corrupt q->head or q->tail. In addition, check the bus_hung flag in mt7921_mac_reset_work() before attempting the reset sequence, reject MCU messages while the bus is hung, and install no-op bus operations when an unrecoverable AER error is detected, preventing further invalid hardware accesses. Due to hardware limitations - such as the lack of a connected hardware reset pin or the absence of host re-probe functionality - affected Wi-Fi devices may not fully recover to a normal operational state after certain errors, even with AER enabled. Fixes: 17f1de56df05 ("mt76: add common code shared between multiple chipsets") Co-developed-by: Sean Wang Signed-off-by: Sean Wang Co-developed-by: Jeff Hsu Signed-off-by: Jeff Hsu Signed-off-by: Eason Lai Co-developed-by: Michael Lo Link: https://patch.msgid.link/20260506070458.3096180-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0015b56dff60f40f3b3c587c73b4fef0abf624b1 Author: Lorenzo Bianconi Date: Thu Jan 22 11:39:47 2026 +0100 wifi: mt76: always enable RRO queues for non-MT7992 chipset [ Upstream commit f801fec3f0850ac00073bc322c0e4ea446d938ae ] MT7990 NPU binary requires to initialize NPU desc_base after configuring ring_size. This is a preliminary patch to enable NPU offload for MT7996 (Eagle) chipset. Tested-by: Kang Yang Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260122-mt76-npu-eagle-offload-v2-3-2374614c0de6@kernel.org Signed-off-by: Felix Fietkau Stable-dep-of: 915672c5ae32 ("wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash") Signed-off-by: Sasha Levin commit 6e9207ac476ca50be95a552d1fc24dfa94a94266 Author: Lorenzo Bianconi Date: Fri Oct 17 10:50:32 2025 +0200 wifi: mt76: Introduce the NPU generic layer [ Upstream commit 7fb554b1b623c7da845521604bd05fa9570d07bc ] Add the NPU generic layer in mt76 module. NPU will be used to enable traffic forward offloading between the MT76 NIC and the Airoha ethernet one available on the Airoha EN7581 SoC using Netfilter Flowtable APIs. Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251017-mt76-npu-devel-v2-4-ddaa90901723@kernel.org Signed-off-by: Felix Fietkau Stable-dep-of: 915672c5ae32 ("wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash") Signed-off-by: Sasha Levin commit c0dbce50c89619035988618d8e3cf96aca2f52d1 Author: Lorenzo Bianconi Date: Fri Oct 17 10:50:29 2025 +0200 wifi: mt76: Move Q_READ/Q_WRITE definitions in dma.h [ Upstream commit e627439aecf358944261cf2ffb4449c61a7e5e9f ] This is a preliminary patch to enable traffic forward offloading between the MT76 NIC and the Airoha ethernet one via the Airoha NPU module available on the Airoha EN7581 SoC. Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251017-mt76-npu-devel-v2-1-ddaa90901723@kernel.org Signed-off-by: Felix Fietkau Stable-dep-of: 915672c5ae32 ("wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash") Signed-off-by: Sasha Levin commit 50c896af50e02d93a3138be547bd87d9c1423c07 Author: Zhi-Jun You Date: Wed Jul 15 23:21:13 2026 +0800 wifi: mt76: mt7915: fix net_fill_forward_path for non-DBDC mt7986 [ Upstream commit bade0d238b60c29dafcc7da17501fa489495d6ae ] Current implementation assumes that the hardware supports DBDC or single band and binds to band0. This causes net_fill_forward_path to select the wrong queue for non-DBDC mt7986 because it binds to band1 and getting the following in dmesg: ieee80211 phy2: WA: --> drop by reaseon:1, msdu id = 0xc002 but failed! mtk_wed1: error status=00000002 ieee80211 phy2: WA: txblk 10324e00 len = 128 DW0 : 10 00 00 00 DW1 : 00 00 00 00 DW2 : 00 00 00 00 DW3 : 72 0f 94 68 DW4 : 00 00 00 00 DW5 : ff 03 00 00 DW6 : 00 00 3c 40 DW7 : 00 17 dd 14 DW8 : 79 6f 00 00 DW9 : 02 c0 00 00 DW10 : 58 c5 34 10 DW11 : 00 00 00 00 DW12 : 00 06 3e 00 DW13 : 00 00 00 80 DW14 : 10 8c 00 00 DW15 : 00 00 00 00 DW16 : 00 00 00 00 DW17 : 00 00 00 00 DW18 : 00 00 00 00 DW19 : 00 00 00 00 DW20 : 00 00 00 00 DW21 : 00 00 00 00 DW22 : 00 00 00 00 DW23 : 00 00 00 00 DW24 : 00 00 00 00 DW25 : 00 00 00 00 DW26 : 00 00 00 00 DW27 : 00 00 00 00 DW28 : 00 00 00 00 DW29 : 00 00 00 00 DW30 : 00 00 00 00 DW31 : 00 00 00 00 Fix it by using phy->mt76->band_idx for queue which works for both non-DBDC and DBDC devices. Fixes: f68d67623dec ("mt76: mt7915: add Wireless Ethernet Dispatch support") Suggested-by: Benjamin Larsson Signed-off-by: Zhi-Jun You Link: https://patch.msgid.link/20260715152113.553-2-hujy652@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 17d6b89e09eac2d90272fceeba3644e92212e02f Author: Devin Wittmayer Date: Fri Jun 12 17:25:43 2026 -0700 wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length [ Upstream commit 81497634d9f872fd3e8b03aada55574afff6f174 ] The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set. Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf ("mt76x2: remove some harmless WARN_ONs in tx status and rx path") did for the neighboring rx and tx status paths. Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel. Fixes: 7bc04215a66b ("mt76: add driver code for MT76x2e") Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260613002544.27750-2-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0340bd33b4e21d08e07f34e9ac53c161ae1676c1 Author: Dmitry Gomzyakov Date: Sun May 10 15:29:10 2026 +0500 wifi: mt76: connac: add MT7991A (0x7991) to is_mt7996() [ Upstream commit 574bd79955d166c00c2b1531fed591ee70b6ba04 ] The MT7991A chipset uses PCI device ID 0x7991 (MT7996_DEVICE_ID_2), but is_mt7996() only checks for 0x7990. This causes MT7991A devices to use incorrect chip-specific settings, such as: - MSDU_CNT_V2 instead of MSDU_CNT in TX descriptors - Wrong WTBL BMC size (32 instead of 64) - Incorrect prefetch depth for MCU queues Fixes: 7014fe535860 ("wifi: mt76: mt7996: add macros for pci device ids") Signed-off-by: Dmitry Gomzyakov Link: https://patch.msgid.link/20260510102911.1883849-2-kyoto1337@protonmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 1991d605a45f69068e748c6ffcba5eea7a9857aa Author: Yichong Chen Date: Fri Jul 31 10:18:27 2026 +0800 fanotify: report full event length for FIONREAD [ Upstream commit 68615158c12de36220446dfea5cfdf9ba6c19690 ] fanotify_ioctl(FIONREAD) reports the number of bytes available to read from the event queue. It currently accounts only FAN_EVENT_METADATA_LEN for each queued event. That underestimates events that carry additional information records, such as FAN_REPORT_DFID_NAME events. A userspace program that uses FIONREAD to size its read buffer can receive a length that is smaller than the next event. Reading with that buffer then fails with -EINVAL, while a larger buffer succeeds and reports a larger metadata.event_len. Use fanotify_event_len() when summing queued events so FIONREAD includes all info records. Fixes: 5e469c830fdb ("fanotify: copy event fid info to user") Signed-off-by: Yichong Chen Link: https://patch.msgid.link/20260731021827.602479-1-chenyichong@uniontech.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 6248eb1833ff0adfdbbadd5f846c2f22e02a01b0 Author: Muhammad Usama Anjum Date: Thu Jul 30 12:12:50 2026 +0100 misc: sgi-gru: remove interrupt-context page-table walks [ Upstream commit 928a8e9f523df845fc496bcb9811013b67aabec5 ] The GRU TLB miss handler walks a process's page tables without holding page-table locks or a reference to the mapped page. It also uses a kernel page-table accessor on user page tables and supports only PMD-level large mappings on x86-64. Remove the direct walker. Send interrupt faults directly to user polling mode so the existing call-OS fallback retries them in process context. Remove the mmap-lock failure statistic that can no longer be incremented. Fixes: 142586409c8b ("GRU Driver: page faults & exceptions") Signed-off-by: Muhammad Usama Anjum Link: https://patch.msgid.link/20260730111316.3672672-2-usama.anjum@arm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e6e4cbc9e8fdd53579c6a31aa3a3bb9398710f2c Author: Abdun Nihaal Date: Wed Jul 22 15:42:13 2026 +0530 misc: vmc_vmci: Fix potential memory leak in vmci_event_subscribe() [ Upstream commit 210854a96ef18b09b45a2a59ff14ca06dfe5ad4d ] The memory allocated for struct vmci_subscription (sub) is not freed in the error path when have_new_id is false. Fix that by adding a kfree() call, and moving the read of sub->id to a point before freeing. Fixes: 1d990201f9bb ("VMCI: event handling implementation.") Signed-off-by: Abdun Nihaal Acked-by: Vishnu Dasa Link: https://patch.msgid.link/20260722101215.76680-1-nihaal@cse.iitm.ac.in Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2a1c16c4700cd4f21d5ca0fa530059704b63454b Author: Jinjie Ruan Date: Wed Jul 29 09:29:46 2026 +0800 powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr() [ Upstream commit 4cc4b586007fbbf8edba4f1d0849e9a06b0cf6c3 ] In get_crash_memory_ranges(), if crash_exclude_mem_range() failed after realloc_mem_ranges() has successfully allocated the cmem memory, it just returns an error but leaves cmem pointing to the allocated memory, nor is it freed in the caller update_crash_elfcorehdr(), which cause a memory leak, goto out to free the cmem. Fixes: 849599b702ef ("powerpc/crash: add crash memory hotplug support") Reviewed-by: Sourabh Jain Signed-off-by: Jinjie Ruan Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260729012948.2797865-2-ruanjinjie@huawei.com Signed-off-by: Sasha Levin commit 7969b571ae940da0d429724a1a8ce141feda6583 Author: Rosen Penev Date: Sat May 16 23:37:54 2026 -0700 powerpc/44x: Set GPIO chip parent [ Upstream commit b9254d222d0b38cc6f7b73119fad6316f65278be ] The PPC4xx GPIO driver stopped assigning an explicit parent to the gpio_chip when it moved away from of_mm_gpiochip_add_data(). Restore that association from the platform device so OF GPIO lookup can match phandles to the registered gpiochip. Tested on: Cisco MX60W. No more probe deferral. Assisted-by: Codex:GPT-5.5 Fixes: 1044dbaf2a77 ("powerpc/44x: Change GPIO driver to a proper platform driver") Signed-off-by: Rosen Penev Reviewed-by: Christophe Leroy (CS GROUP) Reviewed-by: Linus Walleij Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260517063754.21819-1-rosenp@gmail.com Signed-off-by: Sasha Levin commit 687d42d9eea41a0eeecf638849658fafdb27f62b Author: Christophe Leroy (CS GROUP) Date: Wed Jul 29 11:56:48 2026 +0200 powerpc: implement get_direction() in cpm2 [ Upstream commit ca16219e9babc874349a6ac307d56523871a9137 ] The lack of get_direction() callback in this driver causes GPIOLIB to emit a warning. Implement it. Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()") Signed-off-by: Christophe Leroy (CS GROUP) Reviewed-by: Bartosz Golaszewski Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/c6eb70aa0e1ba6e15f947c827006aa79edace05c.1785318836.git.chleroy@kernel.org Signed-off-by: Sasha Levin commit e7c69c6695d84220847cca62a45e879e71e79e9d Author: Naveen Kumar Chaudhary Date: Thu Jun 11 23:08:17 2026 +0530 locking/lockdep: Fix NULL pointer dereference in __lock_set_class() [ Upstream commit 7577e00b9ab506202b9f1a33de3cc8cc6413a4db ] register_lock_class() can return NULL when the lock class pool is exhausted, graph_lock() fails, or key validation fails. However, __lock_set_class() uses the return value directly in pointer arithmetic without a NULL check: class = register_lock_class(lock, subclass, 0); hlock->class_idx = class - lock_classes; If class is NULL, this computes a wild offset that corrupts hlock->class_idx. The subsequent reacquire_held_locks() call will invoke hlock_class() with this corrupted index, leading to a NULL or out-of-bounds pointer dereference. Add the missing NULL check, consistent with how __lock_acquire() already handles this case at the same call site. Fixes: 64aa348edc61 ("lockdep: lock_set_subclass - reset a held lock's subclass") Signed-off-by: Naveen Kumar Chaudhary Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Waiman Long Reviewed-by: Dmitry Ilvokhin Link: https://patch.msgid.link/h2kfw43n4527x6mgi2lwpz2rieqnfzgictpv4wr5nyfjkc47co@2r5vz4uz44db Signed-off-by: Sasha Levin commit 37f11973c3eb72a5eb061082cad529bb6939c24f Author: Martin Wilck Date: Thu Jul 23 13:27:41 2026 +0200 md/raid1: create serial pool adding rdev to array with serialize_policy=1 [ Upstream commit 140234b2380ffb8ffb0cfc46fee0e822f43adef7 ] The following bug has been observed with kernel 7.1.3 after adding a new rdev to an existing RAID1 array with serialize_policy enabled: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 19639 Comm: ext4lazyinit Not tainted 7.1.3-1-default RIP: _raw_spin_lock_irqsave+0x27/0x50 CR2: 0000000000004960 Call Trace: wait_for_serialization+0xb9/0x260 [raid1] raid1_make_request+0x762/0xaff [raid1] md_handle_request+0x1c9/0x2e0 [md_mod] The raid1.c code calls wait_for_serialization() if the MD_SERIALIZE_POLICY is set, and wait_for_serialization assumes that rdev->serial is initialized. Normally this will be the case for arrays that have the serialize_policy sysfs attribute set to 1. But when a new rdev is added to an existing array in bind_rdev_to_array(), the condition at mddev_create_serial_pool() causes creation of rdev->serial to be skipped. Fix it. Fixes: 69b00b5bb235 ("md: introduce a new struct for IO serialization") Signed-off-by: Martin Wilck Reviewed-by: Mykola Marzhan Link: https://patch.msgid.link/20260723112741.1206836-1-mwilck@suse.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 71da948d249a59fe0a09454ecdd56a3fb06d283e Author: Yu Peng Date: Wed Jul 8 16:02:32 2026 +0800 fs: annotate inode timestamp accessors [ Upstream commit c610d2d0787961cdd6fc1de69d9be1ff3687e1a6 ] syzbot reported a KCSAN race between fill_mg_cmtime() and inode_set_ctime_to_ts() on inode->i_ctime_{sec,nsec}. stat/getattr can sample inode timestamps while update paths store new values concurrently, so KCSAN can report benign races on these fields. Annotate the timestamp accessors with READ_ONCE()/WRITE_ONCE(), and use the ctime accessor for the remaining ctime loads. This avoids the KCSAN reports without changing timestamp semantics. Fixes: 4e40eff0b573 ("fs: add infrastructure for multigrain timestamps") Reported-by: syzbot+8b3bd9f8a06658479d4a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8b3bd9f8a06658479d4a Signed-off-by: Yu Peng Link: https://patch.msgid.link/20260708080232.2564807-1-pengyu@kylinos.cn Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 039e490e3ac47e70a1e2a56bb6a31a6593eb057f Author: Can Peng Date: Wed Jul 15 09:29:49 2026 +0800 i3c: master: adi: add OF module alias for autoloading [ Upstream commit a733069a1943f30922b90bde5eef3cb25b010f8b ] The Analog Devices I3C master driver can be built as a module and uses adi_i3c_master_of_match as its OF match table, but the table is not exported for module alias generation. Add the MODULE_DEVICE_TABLE(of, ...) entry so modpost can generate OF module aliases for OF based module autoloading. Fixes: a79ac2cdc91d ("i3c: master: Add driver for Analog Devices I3C Controller IP") Signed-off-by: Can Peng Reviewed-by: Frank Li Link: https://patch.msgid.link/20260715012949.180245-1-pengcan@kylinos.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 9eaac0cb4ca94e2e32c53c156ae5b813ba7ef90c Author: Jakub Kicinski Date: Tue Jun 30 10:29:04 2026 -0700 i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices [ Upstream commit 038cf48b3170af26a70bf2dee4f8c3ac910f5176 ] On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned. Fixes: 1dd728f5d4d4 ("i3c: master: Add driver for Synopsys DesignWare IP") Signed-off-by: Jakub Kicinski Reviewed-by: Frank Li Link: https://patch.msgid.link/20260630172904.2662160-1-kuba@kernel.org Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 35e0103177826430b5df888b1506239d41e76ab5 Author: Aneesh Kumar K.V (Arm) Date: Fri Jul 17 23:34:23 2026 +0530 swiotlb: Preserve allocation virtual address for dynamic pools [ Upstream commit 57d29044d0f29a76c6ec0c112c8c7371d5608dc7 ] swiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the atomic pool is backed by remapped virtual addresses, which are not the same as the direct-map addresses returned by phys_to_virt(). swiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address from the physical start address. For atomic-pool backed allocations this stores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes that address to dma_free_from_pool(), which will fail to recognize the chunk Pass the virtual address returned by the allocation path into swiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This keeps the pool free path using the same virtual address as the allocator. Fixes: 79636caad361 ("swiotlb: if swiotlb is full, fall back to a transient memory pool") Reviewed-by: Jason Gunthorpe Tested-by: Michael Kelley Tested-by: Mostafa Saleh Reviewed-by: Petr Tesarik Signed-off-by: Aneesh Kumar K.V (Arm) Reviewed-by: Mostafa Saleh Link: https://lore.kernel.org/r/20260717180442.110954-6-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski Signed-off-by: Sasha Levin commit fb0b39287ba894dbdfac2901c51788b63f5c2291 Author: Aneesh Kumar K.V (Arm) Date: Fri Jul 17 23:34:21 2026 +0530 iommu/dma: Check atomic pool allocation result directly [ Upstream commit af95a0ebc0a0db0762be75f51eadf770bad01aaa ] The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping. Fixes: 9420139f516d ("dma-pool: fix coherent pool allocations for IOMMU mappings") Reviewed-by: Jason Gunthorpe Tested-by: Michael Kelley Tested-by: Mostafa Saleh Reviewed-by: Petr Tesarik Signed-off-by: Aneesh Kumar K.V (Arm) Link: https://lore.kernel.org/r/20260717180442.110954-4-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski Signed-off-by: Sasha Levin commit 28fdea874f68cac6c36651b1fc7272fd2199c48d Author: Chen Cheng Date: Sat Jul 18 16:42:18 2026 +0800 md: scope memalloc_noio to allocation critical sections [ Upstream commit bace2010dd7ac07bc980575afb135c406730a7fe ] Storing a memalloc_noio_save() token in mddev->noio_flags lets one task save the token and another task restore it. With concurrent suspend sysfs writes, task A can enter PF_MEMALLOC_NOIO, return to userspace still in that scope, and later task B can restore A's saved token. Avoid tying the token lifetime to mddev. Keep mddev_suspend() and mddev_resume() only responsible for array suspension, and enter PF_MEMALLOC_NOIO only in the MD paths that allocate memory after the array has been suspended. Restore the token before resuming the array. A reproducer repeatedly writes suspend_lo and suspend_hi from concurrent workers and checks each worker's /proc/self/stat flags before and after the sysfs write. Link: https://github.com/chencheng-fnnas/reproducer/blob/main/repro-md-noio-token-leak.sh Fixes: 78f57ef9d50a ("md: use memalloc scope APIs in mddev_suspend()/mddev_resume()") Signed-off-by: Chen Cheng Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260718084218.417895-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit c510626bbacb1dc58b0d03b42390bbf382c4f1bd Author: Abd-Alrhman Masalkhi Date: Tue Apr 28 15:05:24 2026 +0200 md: skip redundant raid_disks update when value is unchanged [ Upstream commit abaf4783822851678632e5cea98aa5aead99852f ] Calling update_raid_disks() with the same value as the current one can trigger unnecessary work. For example, RAID1 will reallocate resources such as the mempool for r1bio. Signed-off-by: Abd-Alrhman Masalkhi Link: https://patch.msgid.link/20260428130524.448063-1-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Stable-dep-of: bace2010dd7a ("md: scope memalloc_noio to allocation critical sections") Signed-off-by: Sasha Levin commit 9f16747fc3b23c35c2c98a1156cae579d5944d92 Author: Chen Cheng Date: Wed Mar 4 19:14:17 2026 +0800 md: remove unused mddev argument from export_rdev [ Upstream commit 6f507eb2bb5491327fe634dc23558d4ca5d710b8 ] The mddev argument in export_rdev() is never used. Remove it to simplify callers. Signed-off-by: Chen Cheng Reviewed-by: Paul Menzel Link: https://lore.kernel.org/linux-raid/20260304111417.20777-1-chencheng@fnnas.com/ Signed-off-by: Yu Kuai Stable-dep-of: bace2010dd7a ("md: scope memalloc_noio to allocation critical sections") Signed-off-by: Sasha Levin commit 6763fb409a0b4106676a52cf934440d9484b32c8 Author: Chen Cheng Date: Sat Jul 18 11:42:36 2026 +0800 md/bitmap: resume array on backlog_store() error path [ Upstream commit 2911cd0a0f4366a7e06832bc5f0a7fdcc138e4dc ] backlog_store() suspends the array before checking whether a write-mostly device exists. If no such device exists, the error path only unlocks reconfig_mutex and leaves the array suspended, blocking subsequent I/O. Use mddev_unlock_and_resume() to release both states. Fixes: 58226942ad3d ("md: use new apis to suspend array before mddev_create/destroy_serial_pool") Signed-off-by: Chen Cheng Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260718034236.4119093-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 85ece0386c4fe4930bb440e8788b6c95c5c51cc4 Author: Vladimir Zapolskiy Date: Mon Jun 29 19:21:27 2026 +0300 clk: qcom: Return expected ENOMEM error on dynamic allocation failure [ Upstream commit 22d9257f08913b6eec3e8ece4d13d9c41f14428b ] If a dynamic memory allocation fails, the returned error code in clock controller driver probe functions on a few legacy platforms should be set to -ENOMEM instead of -EINVAL. Fixes: ee15faffef11 ("clk: qcom: common: Add API to register board clocks backwards compatibly") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260629162127.3910603-1-vz@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 64abdd6961290b882580306b16735a27eb65cbb6 Author: Imran Shaik Date: Sat Jul 18 18:26:18 2026 +0530 clk: qcom: gpucc-qcm2290: Park RCG's clk source at XO during disable [ Upstream commit ab46b5fb668b8b9b848a8f036fc4c06ce86b7e3b ] The RCG's clk src has to be parked at XO while disabling as per hardware team's recommendation, hence use clk_rcg2_shared_ops to achieve the same. Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Imran Shaik Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-11-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit af7a6d6ec36a16a583ba2e4e9984c3cf1fe34655 Author: Stanislav Kinsburskii Date: Wed Jul 1 15:02:20 2026 -0700 lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone [ Upstream commit 6a8024511ddf4877435c34fb3d6028aa8e590649 ] dmirror_fault() is called from the dmirror_read() and dmirror_write() retry loops after dmirror_do_read() or dmirror_do_write() finds a missing device page table entry. If the mirrored mm has already exited, mmget_not_zero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress. Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable. Link: https://lore.kernel.org/178294308408.327222.3319445682023999403.stgit@skinsburskii Fixes: b2ef9f5a5cb37 ("mm/hmm/test: add selftest driver for HMM") Signed-off-by: Stanislav Kinsburskii Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Ralph Campbell Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 85cf991c881e7198be32be05a9daa2625390c8b3 Author: Pu Lehui Date: Tue Jul 28 02:54:57 2026 +0000 bpf: Fix potential UAF when reading bpf link info [ Upstream commit 863f3ddd0b8ac65abfb50d3be0869268ac0e277b ] In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is accessed without holding any locks. If the prog is concurrently replaced via bpf_link_update, the old prog can be freed, leading to a potential UAF issue. Fix this by accessing link->prog under RCU protection to safely fetch the pointer and guarantee its lifetime while reading its fields. Fixes: 0c991ebc8c69 ("bpf: Implement bpf_prog replacement for an active bpf_cgroup_link") Reported-by: Sashiko Signed-off-by: Pu Lehui Signed-off-by: Andrii Nakryiko Reviewed-by: Emil Tsalapatis Reviewed-by: Amery Hung Acked-by: Leon Hwang Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweicloud.com [0] Link: https://lore.kernel.org/bpf/20260728025457.2814876-1-pulehui@huaweicloud.com Signed-off-by: Sasha Levin commit bda86e9f31b9a296b6e64a51c91dc776fc9f613e Author: Pu Lehui Date: Tue Jul 28 02:32:59 2026 +0000 bpf: Fix potential UAF in bpf_netns_link_update_prog [ Upstream commit 5c5997836381010fc5907b36bc17d3b19407e933 ] In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping. Fixes: 7f045a49fee0 ("bpf: Add link-based BPF program attachment to network namespace") Reported-by: Sashiko Signed-off-by: Pu Lehui Signed-off-by: Andrii Nakryiko Reviewed-by: Amery Hung Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweicloud.com [0] Link: https://lore.kernel.org/bpf/20260728023259.2813482-1-pulehui@huaweicloud.com Signed-off-by: Sasha Levin commit d5266b4c5c77152e386a3a2d9d5244b3b6cbd57a Author: Hongyan Xu Date: Wed Jul 29 18:46:59 2026 +0800 power: supply: sc2731_charger: cancel work on remove [ Upstream commit dfc859bb8d332c525872f1a44028137724fa1998 ] The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released. Set the platform drvdata used by remove, then cancel the work after unregistering the notifier. This issue was found by a static analysis tool. Fixes: 8ac1091ed18b ("power: supply: sc2731_charger: Add one work to charge/discharge") Reviewed-by: Baolin Wang Signed-off-by: Hongyan Xu Link: https://patch.msgid.link/5d48b827687168cb1b1bfe85f17945566b42829d.1785321763.git.getshell@seu.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit f312c5d17f2a7ad50df5b52935d76abbe7b89feb Author: Hongyan Xu Date: Tue Jul 28 20:33:39 2026 +0800 power: supply: isp1704_charger: cancel work on remove [ Upstream commit 60c5b8a9ef4dbc5d69bbc1a960fe55826cb3b643 ] The USB notifier and initial VBUS detection can schedule isp->work. The remove path unregisters the notifier and power supply, but does not wait for queued or running work before tearing down the power supply state. Cancel the work after unregistering the notifier. Do this before unregistering the power supply. This issue was found by a static analysis tool. Signed-off-by: Hongyan Xu Link: https://patch.msgid.link/20260728123423.781-5-getshell@seu.edu.cn Fixes: ec46475f3e31 ("power_supply: Add isp1704 charger detection driver") Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 1a35eda51a50125d8e58b4f99f82034c58000630 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:56:02 2026 +0200 arm64: dts: qcom: qcs6490-rb3gen2: Fix the PCIe iommu-map entries [ Upstream commit 485dc5e557a8fef1374669f4ebe027c947187325 ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 267643b3e3a4 ("arm64: dts: qcom: qcs6490-rb3gen2: Add PCIe nodes") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-21-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e1c65abeb6aafa6daae8d183912f853a6e6a268f Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:55 2026 +0200 arm64: dts: qcom: lemans: Fix the PCIe iommu-map entries [ Upstream commit 19b4c47fc9733a953e9586bc0906a3be378b4cd5 ] The IOMMU provider pcie_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 489f14be0e0a ("arm64: dts: qcom: sa8775p: Add pcie0 and pcie1 nodes") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-14-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 03a85ccf857ac0e532da988c908245503c3e7b9b Author: Shawn Guo Date: Tue Mar 31 17:01:47 2026 +0800 arm64: dts: qcom: lemans: Move PCIe devices into soc node [ Upstream commit 8222873cd4698627c08bffb2e40ba6f5a008fe32 ] These PCIe devices with MMIO address should be inside soc node rather than outside. Fixes: 489f14be0e0a ("arm64: dts: qcom: sa8775p: Add pcie0 and pcie1 nodes") Signed-off-by: Shawn Guo Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260331090147.18522-1-shengchao.guo@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 19b4c47fc973 ("arm64: dts: qcom: lemans: Fix the PCIe iommu-map entries") Signed-off-by: Sasha Levin commit 76e14b0e865677bcb511039a59a491be8a275373 Author: Odelu Kukatla Date: Wed Oct 1 13:03:44 2025 +0530 arm64: dts: qcom: sa8775p: Add reg and clocks for QoS configuration [ Upstream commit e7fc2fee4212714485d0efb12cdd9fbb51dde078 ] Add register addresses and clocks which need to be enabled for configuring QoS on sa8775p SoC. Signed-off-by: Odelu Kukatla Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251001073344.6599-4-odelu.kukatla@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 19b4c47fc973 ("arm64: dts: qcom: lemans: Fix the PCIe iommu-map entries") Signed-off-by: Sasha Levin commit 8d7411cc0bd953967bd792b57920c024b4584df9 Author: Abhinaba Rakshit Date: Wed Dec 24 15:50:24 2025 +0530 arm64: dts: qcom: lemans: add QCrypto node [ Upstream commit 173c43d0e4a435a95568d6b912d0d45c37d6d75f ] Add Qualcomm Crypto Engine device node for LeMans platform. QCE and Crypto DMA nodes patch was applied as part of the commit 7ff3da43ef44 ("arm64: dts: qcom: sa8775p: add QCrypto nodes"), however was partially reverted by commit 92979f12a201 ("arm64: dts: qcom: sa8775p: Partially revert "arm64: dts: qcom: sa8775p: add QCrypto nodes"") due to compatible-string being miss-matched against schema. Reviewed-by: Dmitry Baryshkov Signed-off-by: Abhinaba Rakshit Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251224-enable-qualcomm-crypto-engine-for-lemans-v2-1-a707e3d38765@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 19b4c47fc973 ("arm64: dts: qcom: lemans: Fix the PCIe iommu-map entries") Signed-off-by: Sasha Levin commit 610d253bef4589dca40f71c5f72a10e3c5f9d1df Author: Dmitry Baryshkov Date: Sun Sep 21 10:09:19 2025 +0300 arm64: dts: qcom: lemans: add refgen regulator and use it for DSI [ Upstream commit 7522c9ffaa97041a1a5dfdcb460d2a2b89f860b1 ] Add the refgen regulator block and use it for the DSI controllers. Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250921-refgen-v1-3-9d93e64133ea@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 19b4c47fc973 ("arm64: dts: qcom: lemans: Fix the PCIe iommu-map entries") Signed-off-by: Sasha Levin commit ca29c5c0cc615a481775b6819021cae24db05dc7 Author: Dmitry Baryshkov Date: Sun Sep 21 10:09:18 2025 +0300 arm64: dts: qcom: lemans: move USB PHYs to a proper place [ Upstream commit 883e20433fe586a6d3e1332d25f5e675921fefd9 ] Sort the lemans.dtsi, moving USB1 and USB2 PHYs to a proper place, making the DT file sorted by the address. Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250921-refgen-v1-2-9d93e64133ea@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 19b4c47fc973 ("arm64: dts: qcom: lemans: Fix the PCIe iommu-map entries") Signed-off-by: Sasha Levin commit 349752c7ab6be4cc86034d98976d305cd8d986cd Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:54 2026 +0200 arm64: dts: qcom: talos: Fix the PCIe iommu-map entries [ Upstream commit f7e687d6050f27a03847abadc12d6821576d06ee ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 718cc7542a00 ("arm64: dts: qcom: qcs615: enable pcie") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-13-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit fc2980ea692027f529afb7b127157d45650d6c6e Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:53 2026 +0200 arm64: dts: qcom: sm8750: Fix the PCIe iommu-map entries [ Upstream commit 366a540432a38c1c1533a319bc07b333f53752b6 ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 19f1395333f8 ("arm64: dts: qcom: sm8750: Add PCIe PHY and controller node") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-12-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f418e83ac1abec16df99e36185c44b7a08c2aaf7 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:52 2026 +0200 arm64: dts: qcom: sm8650: Fix the PCIe iommu-map entries [ Upstream commit 8ccba7b44609d58db088447a771f6f30cfa8739e ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Neil Armstrong Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-11-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e8a7928da474e5e944f4747b096cc8515b3ffb73 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:51 2026 +0200 arm64: dts: qcom: sm8550: Fix the PCIe iommu-map entries [ Upstream commit 16d98ee918d63018eaa6cc260791b71319aa4faa ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 7d1158c984d3 ("arm64: dts: qcom: sm8550: Add PCIe PHYs and controllers nodes") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Neil Armstrong Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-10-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit dbcbbb2033736a203230f80fe317be3a8badd79b Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:50 2026 +0200 arm64: dts: qcom: sm8450: Fix the PCIe iommu-map entries [ Upstream commit 9b10e56647fa8f7ab62c7e45ebf4b168f7befa7f ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 7b09b1b47335 ("arm64: dts: qcom: sm8450: add PCIe0 RC device") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-9-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 793dbaa91c3bfbd099b132cc4b8bb6e7856aa3e3 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:49 2026 +0200 arm64: dts: qcom: sm8350: Fix the PCIe iommu-map entries [ Upstream commit 80337ea3a154230621c0b4e3c831f5d81712ba18 ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 6daee40678a0 ("arm64: dts: qcom: sm8350: add PCIe devices") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-8-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c8fd2cabd0b7c1cf68ca1d78cd23e71e245ae032 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:48 2026 +0200 arm64: dts: qcom: sm8250: Fix the PCIe iommu-map entries [ Upstream commit c41749e9554d4e03e7074f5d1e46140bc4ac77bd ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: e53bdfc00977 ("arm64: dts: qcom: sm8250: Add PCIe support") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-7-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 152e82a60d70e6da88d784b305bae6f9171aca9f Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:47 2026 +0200 arm64: dts: qcom: sm8150: Fix the PCIe iommu-map entries [ Upstream commit d2e56fb42e3d10d7e711063cdc00523ddb31d544 ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: a1c86c680533 ("arm64: dts: qcom: sm8150: Add PCIe nodes") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-6-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a98b8bb0ca25f05b15267da97dc665dd9e13309b Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:46 2026 +0200 arm64: dts: qcom: sdm845: Fix the PCIe iommu-map entries [ Upstream commit deaea7e982bc353c8d3c406774970f16ed901adb ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 5c538e09cb19 ("arm64: dts: qcom: sdm845: Add first PCIe controller and PHY") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-5-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8dfc4641001fb96db7ec5c8beb9db50379c5c543 Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:45 2026 +0200 arm64: dts: qcom: sc8180x: Fix the PCIe iommu-map entries [ Upstream commit a4548204821a56c23cd711cfad2a637ca055ff47 ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: d20b6c84f56a ("arm64: dts: qcom: sc8180x: Add PCIe instances") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-4-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 54176af35d989264e4dce0bee10dd3e4dafb4efb Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:44 2026 +0200 arm64: dts: qcom: sar2130p: Fix the PCIe iommu-map entries [ Upstream commit f605087abc70ecac53757a7ae0d2d8068342ec4b ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: be9115bfe5bf ("arm64: dts: qcom: sar2130p: add support for SAR2130P") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-3-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d2b404826bf93c6102ceb5d3186ef41675f0f6ad Author: Manivannan Sadhasivam Date: Thu Jul 30 13:55:43 2026 +0200 arm64: dts: qcom: kodiak: Fix the PCIe iommu-map entries [ Upstream commit 52dac5bda29a3acd896fab2567605683d34970db ] The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: f8328b7549e1 ("arm64: dts: qcom: sc7280: Describe the first PCIe controller and PHY") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-2-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f063039d2e4395818c2f387b8025ba4561e85b0b Author: Dawid Wróbel Date: Thu Jul 30 15:44:07 2026 +0200 arm64: dts: qcom: sm8250-xiaomi-elish: correct the board ID [ Upstream commit 299731d4fbeaaa141ce2e8226ca00cb30d6ab647 ] elish declares the same qcom,msm-id and qcom,board-id pair as sm8250-sony-xperia-edo.dtsi, so a bootloader choosing between appended device trees cannot tell the two boards apart. 0x10008 is Sony's value. The downstream device tree for this board, elish-sm8250-overlay.dts, uses qcom,board-id = <47 0>, i.e. platform type 0x2f. Fixes: a41b617530bf ("arm64: dts: qcom: sm8250: Add device tree for Xiaomi Mi Pad 5 Pro") Signed-off-by: Dawid Wróbel Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260730-elish-board-id-v1-1-92f99e9722ec@dawidwrobel.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d29c5a88d5703afb6286038e86e1b88daa4962a9 Author: Keith Busch Date: Mon Jul 20 13:10:54 2026 -0700 block: fix dio leak on metadata mapping error [ Upstream commit 702a2a9f3dfe066a7481698c858371112f3cb697 ] A failed integrity mapping holds a dio reference, so we need to go through the full bio ending in case there were previously submitted bio's in the sequence. Fixes: 2729a60bbfb92 ("block: don't silently ignore metadata for sync read/write") Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Link: https://patch.msgid.link/20260720201057.1862857-3-kbusch@meta.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 642828f274eb7d02abe279b5b67ff5796b3a9c51 Author: Christoph Hellwig Date: Thu May 28 10:46:13 2026 +0200 block: add a bio_endio_status helper [ Upstream commit a7d8eaee7fafe2e2c58aef9579bdef778c144029 ] Add a helper that sets bi_status and call bio_endio() as that is a very common pattern and convert the core block code over to it. Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Md Haris Iqbal Reviewed-by: Damien Le Moal Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260528084632.2505277-1-hch@lst.de Signed-off-by: Jens Axboe Stable-dep-of: 702a2a9f3dfe ("block: fix dio leak on metadata mapping error") Signed-off-by: Sasha Levin commit 8b1817b36ca5cec4d87495a4cdf4f81241892ae5 Author: Christoph Hellwig Date: Mon May 18 08:33:30 2026 +0200 block: don't set BIO_QUIET for BLK_STS_AGAIN [ Upstream commit a148d0a5af1ab60253994047403f9eb41ef709a4 ] Commit abb30460bda2 ("block: mark bio_wouldblock_error() bio with BIO_QUIET") added this to suppress buffer_head warnings, but neither when this commit was added nor now any buffer_head using code actually ever sets REQ_NOWAIT which can lead to BLK_STS_AGAIN. Remove the special handling for now. If we ever plan to use REQ_NOWAIT for buffer_head based I/O we're better off handling BLK_STS_AGAIN in the completion handler as it actually needs to retry the I/O as well. Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260518063336.507369-3-hch@lst.de Signed-off-by: Jens Axboe Stable-dep-of: 702a2a9f3dfe ("block: fix dio leak on metadata mapping error") Signed-off-by: Sasha Levin commit 2b239a920a99234449f95293289e63651b6132f4 Author: Christoph Hellwig Date: Fri Jan 9 07:07:46 2026 +0100 blk-crypto: use on-stack skcipher requests for fallback en/decryption [ Upstream commit 2f655dcb2d925b55deb8c1ec8f42b522c6bc5698 ] Allocating a skcipher request dynamically can deadlock or cause unexpected I/O failures when called from writeback context. Avoid the allocation entirely by using on-stack skciphers, similar to what the non-blk-crypto fscrypt path already does. This drops the incomplete support for asynchronous algorithms, which previously could be used, but only synchronously. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Biggers Signed-off-by: Jens Axboe Stable-dep-of: 702a2a9f3dfe ("block: fix dio leak on metadata mapping error") Signed-off-by: Sasha Levin commit 196a8f954ae6d16b2f70abb71b321a8f7f681c3a Author: Christoph Hellwig Date: Fri Jan 9 07:07:45 2026 +0100 blk-crypto: optimize bio splitting in blk_crypto_fallback_encrypt_bio [ Upstream commit b37fbce460ad60b0c4449c1c7566cf24f3016713 ] The current code in blk_crypto_fallback_encrypt_bio is inefficient and prone to deadlocks under memory pressure: It first walks the passed in plaintext bio to see how much of it can fit into a single encrypted bio using up to BIO_MAX_VEC PAGE_SIZE segments, and then allocates a plaintext clone that fits the size, only to allocate another bio for the ciphertext later. While the plaintext clone uses a bioset to avoid deadlocks when allocations could fail, the ciphertex one uses bio_kmalloc which is a no-go in the file system I/O path. Switch blk_crypto_fallback_encrypt_bio to walk the source plaintext bio while consuming bi_iter without cloning it, and instead allocate a ciphertext bio at the beginning and whenever we fille up the previous one. The existing bio_set for the plaintext clones is reused for the ciphertext bios to remove the deadlock risk. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Biggers Signed-off-by: Jens Axboe Stable-dep-of: 702a2a9f3dfe ("block: fix dio leak on metadata mapping error") Signed-off-by: Sasha Levin commit 30439432f3f2e67b0d098f1215f1701ca5d3a0d8 Author: Christoph Hellwig Date: Fri Jan 9 07:07:44 2026 +0100 blk-crypto: submit the encrypted bio in blk_crypto_fallback_bio_prep [ Upstream commit aefc2a1fa2edc2a486aaf857e48b3fd13062b0eb ] Restructure blk_crypto_fallback_bio_prep so that it always submits the encrypted bio instead of passing it back to the caller, which allows to simplify the calling conventions for blk_crypto_fallback_bio_prep and blk_crypto_bio_prep so that they never have to return a bio, and can use a true return value to indicate that the caller should submit the bio, and false that the blk-crypto code consumed it. The submission is handled by the on-stack bio list in the current task_struct by the block layer and does not cause additional stack usage or major overhead. It also prepares for the following optimization and fixes for the blk-crypto fallback write path. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Biggers Signed-off-by: Jens Axboe Stable-dep-of: 702a2a9f3dfe ("block: fix dio leak on metadata mapping error") Signed-off-by: Sasha Levin commit f57adb5beca6be725cf60c45860382d0c11de8dd Author: Mukesh Ojha Date: Fri Jul 24 15:19:39 2026 +0530 firmware: qcom: scm: Fix tzmem state on probe retry [ Upstream commit 9941fe8a04f3d258e07eb5899db3027252a4190f ] qcom_tzmem_enable() returns -EBUSY if called a second time, but this causes probe retries to fail permanently if a later step in qcom_scm_probe() defers after qcom_tzmem_enable() has already succeeded. Use DO_ONCE() to ensure qcom_tzmem_init() runs exactly once across all calls in a thread-safe manner. qcom_tzmem_dev is set on every call since probe retries use the same device pointer. The result of the first initialisation is cached and returned to every subsequent caller. Fixes: 40289e35ca52 ("firmware: qcom: scm: enable the TZ mem allocator") Reviewed-by: Bartosz Golaszewski Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260724094939.613844-4-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1da025b5ceb451c0f6629a3a0c8565661deb4166 Author: Mukesh Ojha Date: Fri Jul 24 15:19:38 2026 +0530 firmware: qcom: scm: Fix reserved memory cleanup on probe failure [ Upstream commit b697b20cea4374d27e2134da4bb7b0ea39f36c8b ] of_reserved_mem_device_init() adds an entry to a global list with no devres counterpart. If qcom_scm_probe() fails after the call the assignment is never cleaned up. A probe retry would add a duplicate entry, leaking the original one permanently. Add an err_rmem label that calls of_reserved_mem_device_release() and route all error paths after of_reserved_mem_device_init() through it. of_reserved_mem_device_release() is safe to call unconditionally as it simply walks an empty list when nothing was assigned. Fixes: a33b2579c8d3 ("firmware: qcom: scm: add support for SHM bridge memory carveout") Reviewed-by: Bartosz Golaszewski Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260724094939.613844-3-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1d753df5899ec356272d08bc4718e82844e4bdf0 Author: Mukesh Ojha Date: Fri Jul 24 15:19:37 2026 +0530 firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published [ Upstream commit 966d23c7e68ea32679275a7e3d2383181002c868 ] In qcom_scm_probe(), devm_request_threaded_irq() is called before smp_store_release(&__scm, scm). Two paths can dereference __scm before it is published, both causing a NULL pointer dereference. The IRQ handler receives scm via its data argument but passes only wq_ctx to qcom_scm_waitq_wakeup() and qcom_scm_get_completion(), which then dereference __scm directly. Thread scm through both functions so the IRQ handler path never touches __scm. Non-atomic SMC calls made during probe (e.g. from qcom_tzmem_init via qcom_scm_shm_bridge_enable) can return WAITQ_SLEEP, causing qcom_scm_wait_for_wq_completion() to run before __scm is published and dereference it. Add platform_set_drvdata(pdev, scm) early in probe and change qcom_scm_wait_for_wq_completion() to take the device pointer and use dev_get_drvdata() to reach scm, removing any dependency on __scm. Fixes: 6bf325992236 ("firmware: qcom: scm: Add wait-queue handling logic") Reviewed-by: Bartosz Golaszewski Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260724094939.613844-2-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d72c76684a4a9f8d103e391b86f89fe155da5283 Author: Yuvaraj Ranganathan Date: Fri May 22 12:09:00 2026 +0530 firmware: qcom: scm: instrument SMC call path with tracepoints [ Upstream commit 41329e72363c02facfeae063ef304aa7ced68c3b ] Wire the five tracepoints defined in qcom_scm_trace.h into the SMC execution path by including the header with CREATE_TRACE_POINTS. Reviewed-by: Konrad Dybcio Signed-off-by: Yuvaraj Ranganathan Link: https://lore.kernel.org/r/20260522-scm-tracepoints-v2-2-e27cdbe0c585@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 966d23c7e68e ("firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published") Signed-off-by: Sasha Levin commit 347efe779f55f411ee41240d831508a8c4892d56 Author: Yuvaraj Ranganathan Date: Fri May 22 12:08:59 2026 +0530 firmware: qcom: scm: add trace events for the SMC call interface [ Upstream commit f6bb2daa4584229af155c2488b83151999315293 ] The SCM SMC call path is opaque at runtime. Stalls caused by firmware congestion, QCOM_SCM_WAITQ_SLEEP/RESUME cycles, and EBUSY retry loops are invisible without recompiling the kernel with temporary printk statements or attaching a hardware debugger. Add five TRACE_EVENTs covering the complete lifecycle of an SCM call: scm_smc_request Emit before each arm_smccc_smc_quirk() invocation. Records the SMC function ID, decoded service and command identifiers, argument count, and up to six register arguments in hex and decimal. Because the caller loops on QCOM_SCM_INTERRUPTED, this event fires once per physical SMC instruction including inte scm_smc_done Emit after the outer __scm_smc_do() returns, pairing each request with its final outcome. Records the SMC function ID, the kernel error code returned to the caller, and the four firmware result registers a0-a3. scm_waitq_sleep Emit when the firmware returns QCOM_SCM_WAITQ_SLEEP. Records the wait-queue context and the SMC call context handles required to issue the matching WAITQ_RESUME. scm_waitq_resume Emit just before constructing and sending the WAITQ_RESUME follow-up call. Records the SMC call context handle being resumed. scm_waitq_get_wq_ctx Emit after a successful WAITQ_GET_WQ_CTX fast-call. Records the returned wait-queue context, flags, and more_pending indicator. These events let ftrace and perf reconstruct the full sequence of firmware interactions, measure per-call and end-to-end latency, and attribute waitqueue stalls to specific service/command pairs without modifying driver source. Reviewed-by: Konrad Dybcio Signed-off-by: Yuvaraj Ranganathan Link: https://lore.kernel.org/r/20260522-scm-tracepoints-v2-1-e27cdbe0c585@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 966d23c7e68e ("firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published") Signed-off-by: Sasha Levin commit 889ca992d9c4e7a3ae7d6ece8794505cbe49b732 Author: Unnathi Chalicheemala Date: Wed Dec 17 20:04:20 2025 +0530 firmware: qcom_scm: Support multiple waitq contexts [ Upstream commit ccd207ec848e768da41465352a0f52081eec6bb1 ] Currently, only a single waitqueue context exists in the driver. Multi-waitqueue mechanism is added in firmware to support the case, when multiple VMs make SMC calls or single VM making multiple calls on same CPU. Enhance the driver to support multiple waitqueue when support is present in the firmware. When VMs make a SMC call, firmware allocates a waitqueue context, assuming the SMC call to be a blocking call. The SMC calls that cannot acquire resources, while execution in firmware, are returned to sleep in the calling VM. When the resource becomes available in the firmware, the VM gets notified to wake the sleeping thread and resume SMC call. The current qcom_scm driver supports single waitqueue as the old firmwares support only single waitqueue with waitqueue id zero. Multi-waitqueue mechanism is added in firmware starting SM8650 to support the case when multiple VMs make SMC calls or single VM making multiple calls on same CPU. To enable this support in qcom_scm driver, add support for handling multiple waitqueues. For instance, SM8650 firmware can allocate two such waitq contexts, so the driver needs to implement two waitqueue contexts. For a generalized approach, the number of supported waitqueues can be queried from the firmware using a SMC call. Introduce qcom_scm_query_waitq_count to get the number of waitqueue contexts supported by the firmware and allocate “N” unique waitqueue contexts with a dynamic sized array where each unique wq_ctx is associated with a struct completion variable for easy lookup. Older targets which support only a single waitqueue, may return an error for qcom_scm_query_waitq_count, set the wq_cnt to one for such failures. Reviewed-by: Bartosz Golaszewski Signed-off-by: Unnathi Chalicheemala Signed-off-by: Shivendra Pratap Reviewed-by: Mukesh Ojha Link: https://lore.kernel.org/r/20251217-multi_waitq_scm-v11-2-f21e50e792b8@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 966d23c7e68e ("firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published") Signed-off-by: Sasha Levin commit 3d028e241c2aa6d1f119c9eb0cefd7b79475487e Author: Unnathi Chalicheemala Date: Wed Dec 17 20:04:19 2025 +0530 firmware: qcom_scm: Add API to get waitqueue IRQ info [ Upstream commit da9e6b1a96b1eef47542ec46b67e3f4f883fed3b ] Bootloader and firmware for SM8650 and older chipsets expect node name as "qcom_scm", in order to patch the wait queue IRQ information. However, DeviceTree uses node name "scm" and this mismatch prevents firmware from correctly identifying waitqueue IRQ information. Waitqueue IRQ is used for signaling between secure and non-secure worlds. To resolve this, introduce qcom_scm_get_waitq_irq() that'll get the hardware IRQ number to be used from firmware instead of relying on data provided by devicetree, thereby bypassing the DeviceTree node name mismatch. This hardware IRQ number is converted to a Linux IRQ number using newly qcom_scm_fill_irq_fwspec_params(). This Linux IRQ number is then supplied to the threaded_irq call. Reviewed-by: Bartosz Golaszewski Signed-off-by: Unnathi Chalicheemala Signed-off-by: Shivendra Pratap Reviewed-by: Mukesh Ojha Link: https://lore.kernel.org/r/20251217-multi_waitq_scm-v11-1-f21e50e792b8@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 966d23c7e68e ("firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published") Signed-off-by: Sasha Levin commit 81af527ead79c1aeb6cce85e95d3e1b8b7ee6108 Author: Konrad Dybcio Date: Wed Jul 1 17:43:16 2026 +0200 arm64: dts: qcom: sc8280xp-crd: Fix the pin index for misc_3p3_reg_en [ Upstream commit 0e05c183f3b97427f00d619132ba5984494f6886 ] The correct pin is GPIO1. Fix it. Fixes: ccd3517faf18 ("arm64: dts: qcom: sc8280xp: Add reference device") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260701-topic-8280crd_fixups-v1-2-3fe92ee9636b@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5793229726e259010700c36f264d1815e25b57af Author: Dmitry Baryshkov Date: Wed Jul 22 15:46:08 2026 +0300 clk: qcom: gcc-qcm2290: don't park QUP RCGs upon registration [ Upstream commit 9c4cee964e0ccc155e4ab8fa6cec88fffc262c63 ] The gcc_qupv3_wrap0_s[0-5]_clk_src RCGs feed the QUP serial engines (UART/I2C/SPI). Since shared RCGs are parked to XO at registration time, binding the gcc-qcm2290 driver reprograms these clocks away from the rate configured by the bootloader. For the UART used as the boot console this drops early console output until the serial driver later reconfigures the clock. Switch the QUP wrap0 clock sources over to clk_rcg2_shared_no_init_park_ops so their frequency is left unchanged at registration time, keeping the bootloader-configured console working across the gcc driver probe. Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260722-agatti-no-park-v1-1-31ae3a4774e5@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 939c917d037a5bb2e679138c8d6d2c62a08e3e17 Author: Krishna Kurapati Date: Thu Jul 23 13:47:04 2026 +0530 arm64: dts: qcom: qcs404: Fix DTBS Check errors in usb controller nodes [ Upstream commit 9812d0a3077489f67afaca84dcc7e01a440ee106 ] The following errors pop up when DTBS check is done for qcs404 based platforms: arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb: usb@79b8800 (qcom,qcs404- dwc3): interrupt-names:1: 'qusb2_phy' was expected from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb: usb@79b8800 (qcom,qcs404- dwc3): interrupt-names:2: 'hs_phy_irq' was expected from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb: usb@7678800 (qcom,qcs404- dwc3): interrupt-names:2: 'hs_phy_irq' was expected from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb: usb@7678800 (qcom,qcs404- dwc3): interrupt-names:1: 'qusb2_phy' was expected from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml Modify ordering of hs_phy and qusb2_phy interrupts to fix the errors. Fixes: 927173bf8a0e ("arm64: dts: qcom: Add missing interrupts for qcs404/ipq5332") Signed-off-by: Krishna Kurapati Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260723-qcs404_dtbs_fix-v1-1-c9ca0dd69f23@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4ea052255a4a6a801bb69902d9f193e5c6946d16 Author: Konrad Dybcio Date: Fri Jul 17 13:00:00 2026 +0200 arm64: dts: qcom: sdm632-motorola-ocean: Fix LED default trigger property [ Upstream commit c82ea31fb783d9ce4080eca1a7bb855f4648fc28 ] The correct property name is "linux,default-trigger", not "default-trigger". Fix it to avoid DT checker warnings and let the OSes consume the intended information. Fixes: 3176c4d6b9be ("arm64: dts: qcom: sdm632: Add device tree for Motorola G7 Power") Reviewed-by: Krzysztof Kozlowski Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260717-topic-june26_dts_fixes-v2-3-797cd46e5d9f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d098dd6ec09b845c6f50c68f01bc5050f9612a4b Author: Konrad Dybcio Date: Fri Jul 17 12:59:59 2026 +0200 arm64: dts: qcom: msm8976-longcheer-l9360: Fix accidental node override [ Upstream commit bd0bb7d97773026c9f5d5f8ff1dcf987f8051045 ] The active and sleep pinctrl states for the touchscreen interrupt pin shared the same node name, creating a single node, accidentally overridden immediately after the definition. Alter the names to make them distinct and to silence DT checker warnings. Fixes: 79b896e7da7e ("arm64: dts: qcom: msm8976-longcheer-l9360: Add initial device tree") Reviewed-by: Krzysztof Kozlowski Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260717-topic-june26_dts_fixes-v2-2-797cd46e5d9f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9346a923370750b15cf1ed5f9492dae2c2765c71 Author: Konrad Dybcio Date: Fri Jul 17 12:59:58 2026 +0200 arm64: dts: qcom: msm8998: Don't pull-up I2C pins by default in sleep [ Upstream commit 58ce9a2b9099bb26aed55d4e350c32af94930532 ] When the I2C controller is disabled, no communication is expected to take place. Without traffic on the bus, the pull-up is unnecessary. Both the vendor kernel for this platform and DTs of other SoCs in upstream concur this logic. Change the default and clean up now-NOP overrides. Fixes: 0fee55fc0de7 ("arm64: dts: qcom: msm8998: Add I2C pinctrl and fix BLSP2_I2C naming") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260717-topic-june26_dts_fixes-v2-1-797cd46e5d9f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 179713adff1bd44dd0f93556fbce2d16f65ff717 Author: Itai Handler Date: Thu Jul 23 10:41:38 2026 +0300 rcu: Mark accesses to ->rcu_urgent_qs and ->rcu_need_heavy_qs [ Upstream commit 27d73e81195b395270117ff77c47be2ed9b09b12 ] rcu_all_qs() and rcu_note_context_switch() read/clear the per-CPU ->rcu_urgent_qs and ->rcu_need_heavy_qs flags with plain raw_cpu_read() and this_cpu_write(), while the RCU core clears them with WRITE_ONCE() in rcu_disable_urgency_upon_qs(). KCSAN flags the resulting same-CPU race: BUG: KCSAN: data-race in rcu_all_qs / rcu_disable_urgency_upon_qs It is benign -- the flags are advisory and rcu_all_qs() re-reads ->rcu_urgent_qs with smp_load_acquire() before acting on it -- but these are the last unmarked accesses to the two flags; every other access already uses READ_ONCE()/WRITE_ONCE()/smp_*. Mark them to match. No functional change. Reproduced on a PREEMPT_NONE, CONFIG_KCSAN_INTERRUPT_WATCHER=y kernel with a pthreads program whose threads (two per CPU) loop reading a large file: for (;;) { int fd = open("/proc/kallsyms", O_RDONLY); while (read(fd, buf, sizeof(buf)) > 0) ; close(fd); } The read()s drive cond_resched() -> rcu_all_qs() while the busy CPUs keep the grace period urgent, so the RCU core clears the flags concurrently. Fixes: 2dba13f0b6c2 ("rcu: Switch urgent quiescent-state requests to rcu_data structure") Signed-off-by: Itai Handler Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit badab2078d459922a85cbfbe17542933326757ad Author: Abd-Alrhman Masalkhi Date: Fri Jul 10 10:15:17 2026 +0000 md/raid10: consistently fail atomic writes that require splitting [ Upstream commit 3409bf2f9678d769a4c33bd232a3571c51fac481 ] RAID10 currently handles one badblock path explicitly by failing atomic writes with EIO. However, another badblock path can also reduce the writable range and force the bio through bio_submit_split_bioset(), which implicitly completes the bio with EINVAL. Fix this by handling atomic writes in the common split check. If RAID10 determines that an atomic write would require splitting, complete the bio with EIO. Fixes: a1d9b4fd42d9 ("md/raid10: Atomic write support") Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Yu Kuai Reviewed-by: John Garry Link: https://patch.msgid.link/20260710101521.1714-4-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 75185e2b214e842b7e0af29e5d1fef155662b8b1 Author: Jeff Johnson Date: Tue Jul 28 18:05:29 2026 -0700 wifi: ath11k: fix stride mismatch in mac_phy_caps_parse() [ Upstream commit 7a246c72132eb943b5844ba79dad597b47429dba ] Currently, in ath11k_wmi_tlv_mac_phy_caps_parse(), kcalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct wmi_mac_phy_capabilities)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath11k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Compile tested only. Fixes: 5b90fc760db5 ("ath11k: fix wmi service ready ext tlv parsing") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260728-mac_phy_caps_parse-stride-mismatch-v1-2-27a9c1a3fbd0@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit b9a5d12cbdeb860306f8d47c92caee0ea6ee0e0a Author: Jeff Johnson Date: Tue Jul 28 18:05:28 2026 -0700 wifi: ath12k: fix stride mismatch in mac_phy_caps_parse() [ Upstream commit 4c6eb712a91fa079be6f9f1419c96e0ad2227081 ] Currently, in ath12k_wmi_mac_phy_caps_parse(), kzalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct ath12k_wmi_mac_phy_caps_params)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath12k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260728-mac_phy_caps_parse-stride-mismatch-v1-1-27a9c1a3fbd0@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit ec6edba35aa7b6a21c6066824f4fecb95be16162 Author: Fushuai Wang Date: Fri Jul 24 17:31:51 2026 +0800 Revert "serial: 8250: Clear CON_PRINTBUFFER on port re-registration" [ Upstream commit 57c0741b8c15b93ba4aa92c6618cde6f3f4115b2 ] This reverts commit d338ab1d90603f875c4f7ed223406535378173a5. uart_console() only indicates that the port is selected as the console. It does not mean that the console has already been registered or has printed the buffered messages. On platforms where an initial 8250 port is replaced when the real UART device is registered, clearing CON_PRINTBUFFER causes the console to start at the end of the printk ring buffer. Without earlycon, all messages logged before UART registration are therefore lost. Fixes: d338ab1d9060 ("serial: 8250: Clear CON_PRINTBUFFER on port re-registration") Reported-by: Mark Brown Reported-by: Anirudh Srinivasan Link: https://lore.kernel.org/all/20260522101042.21976-1-fushuai.wang@linux.dev/ Signed-off-by: Fushuai Wang Reviewed-by: John Ogness Link: https://patch.msgid.link/20260724093151.53216-1-fushuai.wang@linux.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d44a02724576c024330852ff3987f43b6232e5ea Author: Cheng-Han Wu Date: Sun Jun 7 17:57:32 2026 +0800 selftests/zram: fix kernel_gte() for POSIX sh [ Upstream commit 649ba27dfac784427a01f9c95c09ecbcb88900d8 ] Commit fc4eb486a59d ("selftests/zram: Skip max_comp_streams interface on newer kernel") added kernel_gte() to zram_lib.sh. The function uses the bash-specific [[ ... ]] conditional, but zram selftests source this file while running under /bin/sh. On systems where /bin/sh is dash, such as Debian, the following test fails: dash -c ' kernel_major=6; kernel_minor=1; major=6; minor=0 if [ $kernel_major -gt $major ]; then echo ok elif [[ $kernel_major -eq $major && $kernel_minor -ge $minor ]]; then echo ok fi' with: dash: 5: [[: not found Use separate POSIX test expressions joined by && instead. Fixes: fc4eb486a59d ("selftests/zram: Skip max_comp_streams interface on newer kernel") Signed-off-by: Cheng-Han Wu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit e5ac7ab78467b064f1da8b0f3042a63595fafcfd Author: Abd-Alrhman Masalkhi Date: Wed Jul 8 11:20:03 2026 +0000 md: recheck spare changes before starting sync [ Upstream commit c7d34d17ea43ebc86b45d439ebb435e11ca44bca ] remove_spares() and remove_and_add_spares() modify the array's rdev configuration. These operations are only safe after the array has been suspended. md_start_sync() checks whether spare configuration changes are needed before taking reconfig_mutex. However, the rdev state can change before the mutex is acquired, so the initial check can become stale. In that case, md_choose_sync_action() may remove or replace rdevs while normal I/O is still accessing them. The race can occur as follows: raid10d Worker Normal IO ____________ _______________________ ______________________ raid10_write_request() wait_blocked_dev() set Blocked set Faulty Skip Faulty rdev rrdev->nr_pending++ .repl_bio = bio removeable_rdev = false . array not suspended . lock mddev goto err_handle lock mddev (wait) . update sb . clear Blocked . . unlock mddev . lock mddev (acquires) remove_spares() removeable_rdev = true raid10_remove_disk() rdev = replacement replacement = NULL rdev_dec_pending(NULL) unlock mddev (NULL)->nr_pending-- In this case, rdev_dec_pending() is called with a NULL pointer, resulting in a NULL pointer dereference when attempting to decrement nr_pending. Fix this by suspending the array when spare configuration changes are needed, including for non-read-write arrays, and checking again after taking reconfig_mutex. If the array was not already suspended and a change is now needed, release the mutex, suspend the array, and reacquire the mutex before continuing. Fixes: bc08041b32ab ("md: suspend array in md_start_sync() if array need reconfiguration") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260628142420.1051027-1-abd.masalkhi@gmail.com?part=3 Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260708112003.474537-1-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 47b61029f146fc7eb04877451712fae19c90e3ad Author: Thomas Weißschuh Date: Mon Jul 27 17:02:48 2026 +0200 tools/nolibc/powerpc: mark ctr and xer as clobbered by system call [ Upstream commit b9fc5a1742b0c8fb7edf066cc17fa0b18b7be623 ] The system call can clobber the ctr and xer registers. Make sure the compiler takes this into account. The missing clobbers only seem to be an issue with newer compilers. Fixes: 0cb0675ec37e ("tools/nolibc: add support for powerpc") Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20260727-nolibc-powerpc-clobber-v1-1-e0911cc99ce1@linutronix.de Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit a2fbef8a6318becb8bb925481c6b0bf3d5aa03a0 Author: Yichong Chen Date: Thu Jul 30 15:06:48 2026 +0800 fanotify: stop permission watchdog when timeout is zero [ Upstream commit 17463fe751309330b74618560f181426f643aa3d ] The fanotify permission watchdog can be disabled by writing zero to fs/fanotify/watchdog_timeout. fanotify_perm_watchdog_group_add() already checks for a zero timeout before scheduling the watchdog. However, once the watchdog work has been scheduled, perm_group_watchdog() unconditionally schedules itself again with the current timeout. If the sysctl is changed to zero while the work is active, secs_to_jiffies(0) causes the work to be rescheduled immediately, resulting in a kworker busy loop. Read the timeout once in perm_group_watchdog_schedule() and do not schedule the work when it is zero. This lets a running watchdog stop after the next execution when the sysctl is set to zero. Fixes: b8cf8fda522d ("fanotify: add watchdog for permission events") Signed-off-by: Yichong Chen Link: https://patch.msgid.link/20260730070648.549458-1-chenyichong@uniontech.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 9d65cb2142533f2058da8375e9ab2c03a79d2bf9 Author: Chen Cheng Date: Sat Jun 27 18:25:19 2026 +0800 md/raid5: protect lockless recovery_offset accesses during reshape [ Upstream commit a47431dfb3538a1485f65b68a0605a05307b5b2d ] During reshape: - reshape_request() advances rdev->recovery_offset for non-In_sync devices locklessly. - analyse_stripe() reads rdev->recovery_offset locklessly to decide: a. use a replacement device to read ? b. a device can already be treated as in-sync for the current stripe ? one possible scenario is: CPU1 CPU2 reshape_request() -> mddev->curr_resync_completed = sector_nr -> if (!mddev->reshape_backwards) -> rdev->recovery_offset = sector_nr analyse_stripe(sh) -> rdev = conf->disks[i].replacement -> if (rdev->recovery_offset >= sh->sector + stripe_sectors) set_bit(R5_ReadRepl) -> or -> if (sh->sector + stripe_sectors <= rdev->recovery_offset) set_bit(R5_Insync) And it could be: - reading from a replacement before it is recovered far enough; or - treating a not-yet-recovered device as in-sync for the current stripe. Fixes: db0505d32066 ("md: be cautious about using ->curr_resync_completed for ->recovery_offset") The race report: ================================================================== BUG: KCSAN: data-race in ops_run_io / reshape_request write to 0xffff8bdee168b270 of 8 bytes by task 1704 on cpu 10: reshape_request+0x1292/0x17b0 raid5_sync_request+0x815/0xa00 md_do_sync.cold+0xf8d/0x1516 [......] read to 0xffff8bdee168b270 of 8 bytes by task 1696 on cpu 9: ops_run_io+0xc25/0x1960 handle_stripe+0x2273/0x4570 handle_active_stripes.isra.0+0x6e0/0xa50 raid5d+0x7d5/0xb90 [......] value changed: 0x0000000000091a00 -> 0x0000000000091b00 ================================================================== Signed-off-by: Chen Cheng Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260627102519.136940-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 455b56209f9615c3902dcc398dd867abb5ade3ab Author: Sajal Gupta Date: Mon Jun 22 19:36:03 2026 +0530 md/raid5-ppl: fix use-after-free in ppl_do_flush() [ Upstream commit 371f7a1b392edc8b7cf449cc7713179b588f2d0e ] The loop in ppl_do_flush() continues iterating after calling ppl_io_unit_finished(), touching io->pending_flushes and leading to a use-after-free. Add a break statement to stop the loop once io is freed. Fixes: 1532d9e87e8b ("raid5-ppl: PPL support for disks with write-back cache enabled") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/ajJF2wKYWRk4GGCK@stanley.mountain/ Signed-off-by: Sajal Gupta Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260622142146.56637-1-sajal2005gupta@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit dcd3d87cfc148a3ef8b205c45a5dfe8a48ac36d7 Author: Chen Cheng Date: Mon Jun 22 20:46:49 2026 +0800 md/raid5: protect bitmap batch counters aka seq_flush/seq_write consistency [ Upstream commit f565925810cb8bc799421485770e15d922ef766a ] kcsan detect race : - raid5d() closes the current bitmap batch by updating conf->seq_flush under conf->device_lock. - __add_stripe_bio() read conf->seq_flush without that lock when assigning sh->bm_seq. so, protect seq_flush/seq_write consistency for multiple CPUs by READ_ONCE()/WRITE_ONCE() under the path without held device_lock. re-explain the stripe batch sequence number update flow: 1. sh->bm_seq declare which batch number the stripe belongs to when perform bitmap-related write. ==> bm_seq = seq_flush+1 2. stripe be handled, * if sh->bm_seq - conf->seq_write > 0, means the batch stripes **newer than** the last written batch, it cannot proceed yet, queued on bitmap_list. * otherwise , has already proceed. 3. raid5d() `++seq_flush` to closes the current batch, means * no more stripes join that old batch * just-closed batch ready to write-out to disk 4. raid5d() calls bitmap hooks unplug() or writeout, then, `++seq_write` to the same as bm_seq. - seq_flush - for producer, to close batches. - seq_write - for consumer, the checkpoint number. the report: ==================================== BUG: KCSAN: data-race in __add_stripe_bio / raid5d write to 0xffff88ba5625d470 of 4 bytes by task 82401 on cpu 0: raid5d+0x1d9/0xba0 [.....] read to 0xffff88ba5625d470 of 4 bytes by task 82421 on cpu 8: __add_stripe_bio+0x332/0x400 raid5_make_request+0x6ac/0x2930 md_handle_request+0x4a2/0xa40 md_submit_bio+0x109/0x1a0 __submit_bio+0x2ec/0x390 [.....] Fixes: 7c13edc87510 ("md: incorporate new plugging into raid5.") v1 -> v2: - remove WRITE_ONCE(conf->seq_write) in held device_lock path. - remove READ_ONCE(conf->seq_flush) in held device_lock path. Signed-off-by: Chen Cheng Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260622124649.1780233-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 4fb17a7c437f145353e93e6a9791f6db70e1cc63 Author: Yuho Choi Date: Tue Jul 7 14:51:00 2026 -0400 bus: mhi: host: Fix controller cleanup on EDL sysfs failure [ Upstream commit 0d5b9e66591d4e2a4376ac82c8cda889a29ba3ee ] mhi_register_controller() adds the controller device before creating the optional trigger_edl sysfs file. If sysfs_create_file() fails, the error path only drops the device reference and leaves the device registered. Hence, call device_del() in the error path before put_device(). Fixes: 17553ba8e19d ("bus: mhi: host: Add sysfs entry to force device to enter EDL") Signed-off-by: Yuho Choi Signed-off-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin commit 21ce330f921a5c959997c8715efe2ce69b865f4e Author: Manivannan Sadhasivam Date: Tue Jun 23 16:51:34 2026 +0200 bus: mhi: host: Flush the posted write after writing to MHI_SOC_RESET_REQ_OFFSET [ Upstream commit 24f4423cbc89548def2b05ae86de6175086dbf94 ] mhi_soc_reset() tries to reset the device by writing to the MHI_SOC_RESET_REQ_OFFSET register. But it doesn't do a read-back to ensure that the write gets flushed to the device before returning to the caller. This may lead to the delay (if implemented) on the caller to be insufficient, if the posted write doesn't reach the device before the delay. So add a read-back after writing to the MHI_SOC_RESET_REQ_OFFSET register. Fixes: b5a8d233a588 ("bus: mhi: core: Add device hardware reset support") Reported-by: Alex Williamson Closes: https://lore.kernel.org/linux-pci/20260622160822.09350246@shazbot.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Reviewed-by: Jeff Hugo Link: https://patch.msgid.link/20260623145134.43976-1-manivannan.sadhasivam@oss.qualcomm.com Signed-off-by: Sasha Levin commit a89818977338ba71194b1ab1d071f0c0848b1e13 Author: Abdun Nihaal Date: Thu Jul 23 17:31:15 2026 +0530 wifi: rtlwifi: pci: fix error path in rtl_pci_probe() [ Upstream commit 3c2999d13eeb222ae56631aeb7ca248090f2b210 ] In the last error path in rtl_pci_probe(), the cleanup functions are skipped due to a wrong goto label. Moreover, the successful call to rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to be reverted. Fix this issue by updating the labels and adding the relevant cleanup functions to the last error path. Fixes: 0c8173385e54 ("rtl8192ce: Add new driver") Signed-off-by: Abdun Nihaal Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260723120118.145383-1-nihaal@cse.iitm.ac.in Signed-off-by: Sasha Levin commit e2cbe14361d7cb0b5abd66d87f3afa0e16efde9f Author: Hongyan Xu Date: Wed Jul 29 18:32:17 2026 +0800 platform/chrome: cros_ec_debugfs: Unregister panic notifier [ Upstream commit e5954d3031fb55dd31aa59bae477d63c68e941c0 ] cros_ec_debugfs_probe() registers notifier_panic with the EC panic notifier chain. The remove path tears down debugfs and the console log, but leaves the notifier registered. A later panic notification can call back into the removed instance and queue work that accesses released data. Unregister the panic notifier before tearing down the debugfs and console log state. This issue was found by a static analysis tool. Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic") Signed-off-by: Hongyan Xu Link: https://lore.kernel.org/r/f3ab74ef8034be63bb45a325f3d54656d658817f.1785320940.git.getshell@seu.edu.cn Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit b95664e3f82da724cb6af06462b8c0d025721206 Author: Hongyan Xu Date: Wed Jul 29 18:32:16 2026 +0800 platform/chrome: cros_ec_debugfs: Clean up console log on probe failure [ Upstream commit 5d187600c4603b8f7812b12ce359a11ad7a7fd3a ] Add a dedicated error label for failures after successful console log setup. Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic") Signed-off-by: Hongyan Xu Link: https://lore.kernel.org/r/c00974953a1b952f51f0f021d7f9fad134159909.1785320940.git.getshell@seu.edu.cn Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit e7768f3dae9f2c6e5b80e9c02429550ea39f2be6 Author: Hungyu Lin Date: Thu Jun 4 05:04:51 2026 +0000 media: qcom: iris: handle runtime PM resume failure in core deinit [ Upstream commit 75d79879ec3cbfd288144b0ae4c3e3fa7700c5fc ] Check the return value of pm_runtime_resume_and_get() in iris_core_deinit(). If runtime PM resume fails, skip hardware power-off operations but still perform software teardown and state transition. Also skip the corresponding pm_runtime_put_sync() call to avoid unbalanced runtime PM references. Fixes: bb8a95aa038e ("media: iris: implement power management") Signed-off-by: Hungyu Lin Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit c1a48452cc16e5bcce5f3729f161ffa9232d922c Author: Dikshita Agarwal Date: Sun May 31 11:20:37 2026 +0530 media: qcom: iris: Fix bitmask test in iris_allow_cmd() [ Upstream commit 0ac05c4d9f1fa25d0692fb154de36bd3baf2e7ce ] iris_allow_cmd() incorrectly checks a sub‑state flag using a logical equality comparison. Since sub_state is a bitmask, this allows STOP to pass when IRIS_INST_SUB_DRAIN is set alongside other bits, violating the intended drain semantics. Fix this by using a proper bitmask test. Fixes: d09100763bed ("media: iris: add support for drain sequence") Reviewed-by: Bryan O'Donoghue Signed-off-by: Dikshita Agarwal Signed-off-by: Vishnu Reddy Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit 794f6d4c4ddef87f2aa93b50427f96203cf0c763 Author: Anna Maniscalco Date: Thu Jul 23 21:23:22 2026 +0200 drm/msm: remove objects from evit list after pinning them [ Upstream commit 83723f32cb3de23d45c1ac09241b5e0cfb32cc9b ] Once objects are pinned they should not be kept in the evict list as that will cause drm_gpuvm_validate to keep ieterating a growing list of objects needlessly. Once an object is pinned remove it from the list. Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Signed-off-by: Anna Maniscalco Patchwork: https://patchwork.freedesktop.org/patch/742166/ Message-ID: <20260723-evict_list_fix-v2-1-bd0725e56253@gmail.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit b3624eecb65a2fcb6ec0dd50bebb24ce0428a17a Author: Ali Tariq Date: Sat Jul 18 20:33:51 2026 +0500 PCI: starfive: Fix unchecked pm_runtime_get_sync() in probe [ Upstream commit aaae917990623a6ca6b638557056606a1ae4a8d6 ] pm_runtime_get_sync() is called in starfive_pcie_probe() without checking its return value. If runtime resume fails, the driver proceeds to configure PCIe hardware through regmap_update_bits(), enable clocks and resets, and power on the PHY, even though the device may not actually be powered. pm_runtime_get_sync() also increments the usage counter even when resume fails, which would leave the counter unbalanced if this error path were later handled without additional cleanup. Switch to pm_runtime_resume_and_get(), which balances the usage counter internally on failure, and bail out of probe before any hardware is touched if resume does not succeed. Tested on StarFive VisionFive 2 v1.2A board. Fixes: 6168efbebace ("PCI: starfive: Enable controller runtime PM before probing host bridge") Signed-off-by: Ali Tariq Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260718153352.661930-1-alitariq45892@gmail.com Signed-off-by: Sasha Levin commit 257a0a59598f56f240a29a3f24e82dd595a119d2 Author: Ali Tariq Date: Sat Jul 18 18:38:25 2026 +0500 PCI: starfive: Fix Runtime PM handling and teardown ordering [ Upstream commit fb9f7973473fc30d62e0f5f90d59df8ef5223777 ] The starfive_pcie_remove() path incorrectly disabled runtime PM before executing plda_pcie_host_deinit(), which can cause unmanaged hardware register access in plda_pcie_host_deinit() while power domains or clocks are disabled. Fix this by restructuring starfive_pcie_remove() to deinitialize the host controller first while runtime PM is active, followed by a synchronous pm_runtime_put_sync() and pm_runtime_disable(). This bug was found in automated AI review by sashiko-bot. Fixes: 39b91eb40c6a ("PCI: starfive: Add JH7110 PCIe controller") Closes: https://lore.kernel.org/linux-pci/20260712180440.423421F000E9@smtp.kernel.org/ Signed-off-by: Ali Tariq Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260718133825.445041-1-alitariq45892@gmail.com Signed-off-by: Sasha Levin commit aa8226f873c91d9c3c016142cdfd8c39c2830cf5 Author: Jeff Johnson Date: Sun Jul 26 16:02:07 2026 -0700 wifi: ath12k: validate TLV length in process_tpc_stats() [ Upstream commit 8e415b8068480d51a057197ded974e2637e8c42b ] The outer skb->len guard only confirms the SKB is large enough to hold the full fixed_param struct, but the TLV's own WMI_TLV_LEN field is never checked. Firmware advertising a TLV length shorter than sizeof(*fixed_param) causes reads of pdev_id and event_count beyond the declared TLV payload. Add a check that the TLV length is at least sizeof(*fixed_param) before casting and dereferencing the pointer. Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260726-ath12k_wmi_process_tpc_stats-len-check-v1-1-c4ba2f84d9c6@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 0364926fb4bfb5b798e5fe2785b3023b4f767327 Author: Jeff Johnson Date: Fri Jul 24 08:56:14 2026 -0700 wifi: ath11k: fix overreads in ath11k_wmi_process_csa_switch_count_event() [ Upstream commit 208d7fdb85976a737a715b81d54efaff6703880c ] There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so the parse infrastructure does not enforce a minimum length for the event struct. Additionally, the num_vdevs field is taken directly from firmware and used as a loop bound over the vdev_ids array without checking that it fits within the TLV payload. Either condition can cause an out-of-bounds read. Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so the parse infrastructure enforces a minimum length for the fixed-size event struct. Add a helper ath11k_wmi_tlv_data_len() to recover the payload length of a parsed TLV from the header preceding its data pointer. Use it in ath11k_wmi_process_csa_switch_count_event() to bound num_vdevs before the loop. Compile tested only. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260724-ath12k_wmi_process_csa_switch_count_event-cleanup-v2-2-02a45d7246c0@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 3b544072185c3d19ddec621ec9f6897ea2d10ee3 Author: Fan Wu Date: Sun Jul 19 01:00:14 2026 +0000 spi: davinci: switch to managed controller allocation [ Upstream commit ea408a05dc8f18b4a184b88d6e19d2fd1acc1527 ] The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_threaded_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded davinci_spi devdata, which is the IRQ handler's dev_id. The devm_request_threaded_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach davinci_spi_irq() and dereference already-freed memory. Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. The clock is acquired with devm_clk_get_enabled(), which is registered after the IRQ and thus released before it by the devres LIFO order. Drain the interrupt explicitly with devm_free_irq() before disabling the controller so that a late interrupt cannot access the registers of a clock-gated controller. This issue was found by an in-house static analysis tool. Fixes: 5b3bb5963ff2 ("spi: davinci: Use devm_*() functions") Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260719010014.3163356-2-fanwu01@zju.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bd764baf82bb46e958a0bd0b481630dd71313055 Author: Guixin Liu Date: Wed Jul 29 18:58:46 2026 +0800 nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request [ Upstream commit f49d0c3a8d56a7cda1628ae17341a4a42063563c ] __nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the rsp_iu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmd_iu unmapped and still marked the op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call .exit_request() when .init_request() fails, the cmd_iu mapping is leaked for every op whose rsp_iu mapping fails. Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and returns the error without marking the op idle, so it stays in the FCPOP_STATE_UNINIT state set by the initial memset(). Fixes: e399441de911 ("nvme-fabrics: Add host support for FC transport") Reviewed-by: Christoph Hellwig Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit c345d9d0b3eefc990bb90cf565325785aab06aab Author: Yehyeong Lee Date: Mon Jul 27 01:39:31 2026 +0900 IB/isert: reject login PDUs declaring more data than was received [ Upstream commit 2488b5b4827e5415768afc8daf097e8eb83c98df ] isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), payload_length = ntoh24(login_req->dlength); tmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Suggested-by: Leon Romanovsky Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260726163931.971063-3-yhlee@isslab.korea.ac.kr Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit cf36fa5357a2fb25776a568d13a3653da7d99bcb Author: Yehyeong Lee Date: Mon Jul 27 01:39:30 2026 +0900 IB/isert: reject PDUs declaring more data than was received [ Upstream commit 957f92ea4022fb6af4618271615a2a21a7b5bef9 ] isert_recv_done() hands each received PDU to the opcode handlers without ever looking at wc->byte_len, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) - out of the fixed-size descriptor: isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len); Because the declared length is never checked against wc->byte_len, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer. Nothing upstream of isert closes this door: - __iscsit_check_dataout_hdr() bounds the inbound payload against conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check. - iscsi_set_connection_parameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsi_check_acceptor_state(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling. - isert never clamps the negotiated value to its own fixed receive descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated. The imm_data_len == data_len path is more than an over-read: it aliases the receive descriptor via sg_set_buf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated. Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN: BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 isert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout() (ib_isert.c:1160), inlined through isert_rx_opcode(). Validate wc->byte_len against the framing in isert_recv_done() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISER_HEADERS_LEN (commit 29e7b925ae6d ("IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all. isert reads the data segment from a fixed offset: isert_get_data() returns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum against wc->byte_len bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything further, and cannot cause a false reject: a PDU carrying an AHS is longer, not shorter. This is a memory-safety fix that verifies the bytes that were actually received; it does not touch RFC 7145 length negotiation and is not the MaxXmitDataSegmentLength negotiation redesign raised in the 2017 "[Query] iSER-Target: QP errors observed on increasing MaxXmitDataSegmentLength" discussion. That redesign is explicitly out of scope here. The patched kernel rejects the malformed DataOut PDU and both immediate-data variants with "PDU declares ... bytes were received" and continues to pass normal traffic with no regression. Reproduced with soft-RoCE (rdma_rxe) and a raw rdma_cm/ibv initiator; no kernel-side test hooks were needed. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260726163931.971063-2-yhlee@isslab.korea.ac.kr Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 429b75000c6a94c1d37af6674636cad46998529d Author: Cong Nguyen Date: Mon Jul 27 18:22:39 2026 +0700 media: staging/ipu7: fix async notifier leak on init error [ Upstream commit 11ccf31a657f9f95260a22848b7d324d3c6cf113 ] isys_notifier_init() initialises a v4l2 async notifier and then, for each CSI-2 port, adds a remote sensor subdev to the notifier's waiting_list via v4l2_async_nf_add_fwnode_remote(), which allocates a sensor_async_sd descriptor and takes a fwnode reference. If parsing or adding a later port fails, the code jumps to the "err_parse" label, which only drops the current endpoint fwnode reference and returns, without calling v4l2_async_nf_cleanup(). Any descriptors already added to the notifier for earlier ports are therefore leaked, and the caller's error path does not clean up the notifier either. Call v4l2_async_nf_cleanup() on the error path, matching the cleanup already performed when v4l2_async_nf_register() fails. This is safe as the notifier is always initialised before the loop is entered. Fixes: a516d36bdc3d ("media: staging/ipu7: add IPU7 input system device driver") Signed-off-by: Cong Nguyen Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit a2e37d1ab773be3cd26b1c19593ca2dbcece9c57 Author: Leon Romanovsky Date: Sun Jul 26 15:21:44 2026 +0300 RDMA/cxgb4: free STAG index when TPT entry write fails [ Upstream commit fdfb5cea4bf070cdb31d997efd87bb684df041fd ] write_tpt_entry() allocates a new STAG index with c4iw_get_resource() and bumps stats.stag.cur before programming the entry. When write_adapter_mem() fails, it returns the error without releasing the index or reversing the statistic. No MR is inserted into rhp->mrs, so deregistration never reclaims it, leaking the index until device teardown. Record whether this call allocated the index and, on a failed write, return it to tpt_table and decrement stats.stag.cur. Key the rollback on both the write error and that flag, not the error alone: a non-reset update carries a caller-owned STAG that this call did not allocate and must not free. Fixes: ec3eead21718 ("RDMA/cxgb4: Remove kfifo usage") Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit b1fe9a1bd00122e8631fd5aeacf44567d69b31a4 Author: Leon Romanovsky Date: Sun Jul 26 12:22:11 2026 +0300 RDMA/mlx5: Send cong param changes to the resolved port mdev [ Upstream commit 033a79e308e4fe832b0924347eda8c4364055174 ] mlx5_ib_set_cc_params() resolves the port-specific mlx5_core_dev via mlx5_ib_get_native_port_mdev() but issued MLX5_CMD_OP_MODIFY_CONG_PARAMS through dev->mdev. On an affiliated secondary RoCE port those pointers refer to different devices, so a write to the secondary port's cc_params debugfs file either altered the master port or failed with a master-side command error, while the read path already used the resolved mdev and returned the unchanged secondary value. Issue the command to the resolved mdev, the same device whose capabilities were checked when its debugfs directory was created. It is already referenced by the get/put pair, so its lifetime is safe. Fixes: 31578defe4eb ("RDMA/mlx5: Update mlx5_ib to use new cmd interface") Link: https://patch.msgid.link/20260726-mlx5-ib-set-cc-params-applies-conges-v1-1-a253edafe1f3@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4599311e78e88c893ad551aca622de2bfdf1c31f Author: Leon Romanovsky Date: Sun Jul 26 12:13:55 2026 +0300 RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs [ Upstream commit 03826bc1fa6c90405bf05831f2b501a8368dcd27 ] get_param() reads a congestion parameter as a u32 but formats it with the signed "%d" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as "-2147483648\n" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with "%u" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored. Fixes: 4a2da0b8c0782 ("IB/mlx5: Add debug control parameters for congestion control") Link: https://patch.msgid.link/20260726-get-param-leaks-kernel-stack-memory-v1-1-d61a4d39662d@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 75424c5a6620ba91115c2455534cc62e64af2244 Author: David Strahan Date: Wed Jul 22 17:03:58 2026 -0500 scsi: smartpqi: Fix AIO retry marker cleared by SCSI core between dispatches. [ Upstream commit 225548863f0a2350c6f34231ca56710c3dd1a5d5 ] On recent Linux kernels the driver can enter a retry loop on the AIO fast path when a request is retried, looping until timeout. A diagnostic path that takes a physical drive offline on AIO-bypass failure is also never entered on affected kernels. Register a per-command initialization callback with the SCSI core. Its presence causes the core to skip the per-dispatch clear, so the retry marker now survives across the requeue and the AIO-to-RAID fallback proceeds as intended. The driver takes over the marker's lifetime: it is zeroed at tag allocation, preserved across the retry requeue so the error path can act on it, and cleared on terminal completion so the tag starts clean on its next use. Fixes: dce5c4afd035 ("scsi: core: Clear driver private data when retrying request") Co-developed-by: Mike McGowen Signed-off-by: Mike McGowen Acked-by: Don Brace Signed-off-by: David Strahan Link: https://lore.kernel.org/linux-scsi/20260722220401.6357-1-david.strahan@microchip.com/ Link: https://patch.msgid.link/20260722220401.6357-2-david.strahan@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3904fb0ee741ebbbc27ec8f50a9bb6cd31e8af05 Author: Ryusuke Konishi Date: Mon Jul 20 23:16:52 2026 +0900 nilfs2: fix BUG in nilfs_copy_dirty_pages() on dirty state mismatch [ Upstream commit 66f4ad3ce158902e5f98afea93189972ed8750c2 ] Syzbot reported a kernel BUG triggered within nilfs_copy_dirty_pages(), which copies dirty DAT file folios/pages to its shadow page cache. The BUG occurs when a retrieved dirty folio/page unexpectedly loses its 'dirty' status. This issue arises because, since the commit referenced below, the 'dirty' flag of a folio/page can be cleared asynchronously after the filesystem detects metadata corruption and transitions to read-only mode. Resolve the issue by returning an -EROFS error if the filesystem has transitioned to read-only mode. Also change the behavior to issue a kernel warning only once instead of triggering a kernel BUG when this unexpected 'dirty' state is detected while the filesystem is not in read-only mode. Reported-by: syzbot+8baf9a79a3ffc6271cb6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8baf9a79a3ffc6271cb6 Fixes: 8c26c4e2694a ("nilfs2: fix issue with flush kernel thread after remount in RO mode because of driver's internal error or metadata corruption") Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 842397fdfd2e61d6470166c796f3125b6c27a162 Author: David Lee Date: Sat Jul 18 01:56:21 2026 +0900 nilfs2: prevent out-of-bounds read in super root block parsing [ Upstream commit 7cb2f76a6a2ba2130b577cb8ac13e1e46c4fc689 ] super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title] Fixes: 8a9d2191e9f4 ("nilfs2: operations for the_nilfs core object") Signed-off-by: David Lee Assisted-by: Codex:gpt-5.5 Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 1fc6df85b4954b6fda9c351843aaca3c06f66d8d Author: Joshua Crofts Date: Fri Jul 17 10:58:54 2026 +0000 nilfs2: fix infinite loop in nilfs_clean_segments() [ Upstream commit ce5a5ad1a8330a2fcfdd9ec2ab341be739e89a18 ] syzbot reported a hung task in nilfs_transaction_begin(). This occurs because the cleaner ioctl falls into an infinite loop if nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device is remounted as read-only after an I/O error). Currently in nilfs_clean_segments(), if err is non-zero, it logs the error and sleeps but doesn't abort when it encounters a terminal error like -EROFS. This causes the thread to loop forever. Fix this by breaking out of the loop if nilfs_segctor_construct() returns -EROFS. This matches the behaviour in nilfs_segctor_write_out(), which also handles -EROFS. Reported-by: syzbot+cae54346a70bbceeff2c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cae54346a70bbceeff2c Fixes: 9ff05123e3bf ("nilfs2: segment constructor") Assisted-by: gemini:gemini-3.1-pro Signed-off-by: Joshua Crofts Acked-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 49a7d62d64f7923b0b66bdff3b09cce6754fbf4a Author: Alexey Charkov Date: Thu Jul 23 14:21:58 2026 +0400 clk: rockchip: Fix the fractional part denominator on RK3588/RK3576 PLLs [ Upstream commit 52aef653c3d0c24013dfa9eccf692594eacdbe17 ] According to the TRM, the fractional PLL coefficient should be divided by 65536 rather than 65535 to obtain the output rate. Fix the denominator and add a comment with the TRM provided clock formulae for future reference. See RK3576 TRM Part 1 V1.2 section 2.13.1.4 Setting Guide on P, M, S and K or equivalently RK3588 TRM part 1 V1.0 section 2.17.1.4 Setting Guide on P, M, S and K. Fractional PLL rates don't seem to be used by any current mainline consumers, so this is purely a correctness fix. It will also be important to properly support DisplayPort output going forward, as the video output controller derives its pixel clock from system PLLs with no dedicated PHY PLL option for DP unlike HDMI, and some display modes are only achievable with fractional PLL rates. Fixes: 8f6594494b1c ("clk: rockchip: add pll type for RK3588") Signed-off-by: Alexey Charkov Reviewed-by: Quentin Schulz Link: https://patch.msgid.link/20260723-rk3588-fracpll-v2-1-3adfb9dda235@flipper.net Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 666071b3128ac80c8b541cc9a90b61bb177f9246 Author: Akari Tsuyukusa Date: Mon Jun 29 22:20:43 2026 +0900 clk: mediatek: mt8135: Fix inverted gate control for devapc_ck [ Upstream commit fd0e3e4edea6a3e4da91be608ca2fb9b348f9e32 ] The devapc_ck (CLK_INFRA_DEVAPC) on MT8135 is currently using "mtk_clk_gate_ops_setclr". However, checking the downstream kernel reveals that this clock is configured with set:enable and clr:disable making "mtk_clk_gate_ops_setclr_inv" the appropriate choice. But, it is strange that some downstream kernels are not like that. Amazon: INV ChromiumOS (early): not INV ChromiumOS 3.16 to 3.18-revew-v2: INV ChromiumOS 3.18-review-v3 and later (sent to kernel.org): not INV Link: https://github.com/amazon-oss/android_kernel_amazon_mt8135/blob/e2b2163a8ec4a7c8d961c89003a15b4ba0f0e371/arch/arm/mach-mt8135/mt_clkmgr.c#L1022-L1028 Link: https://github.com/mtk09422/chromiumos-third_party-kernel-mediatek/blob/4b624ee66e65d5dcd43fca36b313086efae8922a/arch/arm/boot/dts/mt8135-clocks.dtsi#L944-L948 Link: https://github.com/mtk09422/chromiumos-third_party-kernel-mediatek/blob/decd80c01d0dbe9f3afa8ff72273b5618b418180/drivers/clk/mediatek/clk-mt8135.c#L881-L882 Link: https://github.com/mtk09422/chromiumos-third_party-kernel-mediatek/blob/9b6f06cb7637100aa1a42e1fc351b36b384a1c54/drivers/clk/mediatek/clk-mt8135.c#L450 Fixes: a8aede794843 ("clk: mediatek: Add basic clocks for Mediatek MT8135.") Signed-off-by: Akari Tsuyukusa Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 1158a9adc7dceda7154486605f599529e54d4ba7 Author: longlong yan Date: Tue Jul 14 14:51:32 2026 +0800 clk/x86: pmc_atom: add kasprintf return value check [ Upstream commit 18e9d14cbac33db1c1fb933c26a736eef53dd538 ] The kasprintf() function returns NULL on memory allocation failure, but the code in plt_clk_register() was not checking this return value. If kasprintf fails, init.name would be NULL and could cause NULL pointer dereference when clkdev_hw_create() uses it. Add proper error checking for the kasprintf() return value and return ERR_PTR(-ENOMEM) on failure. Fixes: 1141d9d08184 ("clk: x86: Add Atom PMC platform clocks") Signed-off-by: longlong yan Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit b8b81c6c89f0c47d65219afb0be75f0ac3802f36 Author: Myeonghun Pak Date: Sat Jul 11 23:17:42 2026 +0900 clk: palmas: Manage external-control prepare with devm [ Upstream commit ccda84fcbf3a972973f772384935928f41817b3a ] palmas_clks_init_configure() prepares the clock when an external control pin is configured. The current driver only drops that prepare reference when external control configuration fails. If provider registration fails after that point, or if the driver is later removed, the prepare reference remains held. Register a device-managed action after clk_prepare() succeeds. This balances the prepare reference on subsequent probe failure and driver removal. Fixes: 942d1d674931 ("clk: Add driver for Palmas clk32kg and clk32kgaudio clocks") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit d35e45e5bad4fabcf122126402b6c6dcb4379672 Author: Louis-Alexis Eyraud Date: Thu Jul 9 14:23:00 2026 +0200 clk: mediatek: pllfh: Fix IO remapping leak in register_pllfhs error path [ Upstream commit 540d91480bcb1b28a62d7023aa70947ea44c55b9 ] When mtk_clk_register_pllfhs function fails to register a PLL, it unregisters all PLLs and cleans up itself in its error path before returning, so the function callers don't need to do it. But contrary to mtk_clk_unregister_pllfhs function, that does almost the same sequence, it does not free the IO memory mapped on fhctl node, leading to a leak. Fix this leak by factorizing the cleanup sequence in a new private function and use it both mtk_clk_register_pllfhs and mtk_clk_unregister_pllfhs functions. Also, change the loop index start value to avoid the -1 operation on index at each loop. Fixes: d7964de8a8ea ("clk: mediatek: Add new clock driver to handle FHCTL hardware") Signed-off-by: Louis-Alexis Eyraud Reviewed-by: Brian Masney Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit ac6f7740655d8ef10d9cf6158843998e861b24f3 Author: Nicolas Frattaroli Date: Mon Dec 15 11:24:01 2025 +0100 clk: mediatek: Refactor pllfh registration to pass device [ Upstream commit 483f364bb0014495da19c1ccb1a6e2423fc37d95 ] After refactoring all of PLL to pass the device, it's now fairly easy to refactor pllfh and its users, as pllfh registration wraps PLL registration. Do this refactor and move all of the pllfh users to pass the device as well. Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Frattaroli Signed-off-by: Stephen Boyd Stable-dep-of: 540d91480bcb ("clk: mediatek: pllfh: Fix IO remapping leak in register_pllfhs error path") Signed-off-by: Sasha Levin commit c945468a6df7233dc261f0de49d0f2b086d0698b Author: Nicolas Frattaroli Date: Mon Dec 15 11:24:00 2025 +0100 clk: mediatek: Pass device to clk_hw_register for PLLs [ Upstream commit ecffd05839b32f17bde1f3701b68ab182a837b07 ] Passing the struct device pointer to clk_hw_register allows for runtime power management to work for the registered clock controllers. However, the mediatek PLL clocks do not do this. Change this by adding a struct device pointer argument to mtk_clk_register_pll, and fix up the only other user of it. Also add a new member to the struct mtk_clk_pll for the struct device pointer, which is set by mtk_clk_register_pll and is used by mtk_clk_register_pll_ops. If mtk_clk_register_pll is called with a NULL struct device pointer, then everything still works as expected; the clock core will simply treat them as previously, i.e. without runtime power management. Reviewed-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Frattaroli Signed-off-by: Stephen Boyd Stable-dep-of: 540d91480bcb ("clk: mediatek: pllfh: Fix IO remapping leak in register_pllfhs error path") Signed-off-by: Sasha Levin commit b7cd043b8412e8a134abc0b6057a7e0f07cad810 Author: Nicolas Frattaroli Date: Mon Dec 15 11:23:59 2025 +0100 clk: mediatek: Refactor pll registration to pass device [ Upstream commit c9ced38af56fe6411118c6bc6522eab80849326d ] As it stands, mtk_clk_register_plls takes a struct device_node pointer as its first argument. This is a tragic happenstance, as it's trivial to get the device_node from a struct device, but the opposite not so much. The struct device is a much more useful thing to have passed down. Refactor mtk_clk_register_plls to take a struct device pointer instead of a struct device_node pointer, and fix up all users of this function. Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Chen-Yu Tsai Signed-off-by: Nicolas Frattaroli Signed-off-by: Stephen Boyd Stable-dep-of: 540d91480bcb ("clk: mediatek: pllfh: Fix IO remapping leak in register_pllfhs error path") Signed-off-by: Sasha Levin commit 03e070e517204c831e1492843b8f78d792a9c5ef Author: Guangshuo Li Date: Wed Jul 8 19:20:58 2026 +0800 clk: tegra: tegra124-emc: put EMC node on register failure [ Upstream commit f726279f5eab813f9a8b6f38ddf2a4b062d038ff ] tegra124_clk_register_emc() stores a device node reference returned by of_parse_phandle() in tegra->emc_node. If clk_register() fails, the function returns an error before that reference can be consumed and released by the normal runtime path. The tegra_clk_emc object is freed on this failure path, but freeing the object does not drop the OF node reference stored in it. Drop the EMC node reference before freeing the tegra_clk_emc object. of_node_put() is safe for a NULL node, so this also covers the case where the phandle is absent. Fixes: 2db04f16b589 ("clk: tegra: Add EMC clock driver") Signed-off-by: Guangshuo Li Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 75653b0408d525d2ffaff00e6eee9ecc8ef70b59 Author: Ondrej Jirman Date: Sat Jul 25 13:19:07 2026 +0200 arm64: dts: allwinner: sun50i-a64-pinephone: Fix mpu6050 mount matrix [ Upstream commit dfc735fd93e4814e65894916ec5f807f25a391d1 ] The current mount matrix for mpu6050 is wrong. The mount matrix is a simple transform from the sensor coordinate space to the device coordinate space described in DT, where, looking at the screen, X points to the right, Y to the top, and Z towards the user. The mpu6050 is mounted like this (looking at the screen from the front; the sensor is on the near side of the PCB, so its Z axis points towards the user; o marks the pin 1 corner): +Xs ^ | +------+ +Ys <--| | | o | +------+ so this gives: Xd = -Ys [0, -1, 0] Yd = Xs [1, 0, 0] Zd = Zs [0, 0, 1] Fixes: 2496b2aaacf1 ("arm64: dts: allwinner: pinephone: Add mount matrix to accelerometer") Signed-off-by: Ondrej Jirman Link: https://patch.msgid.link/20260725111909.2244868-1-megi@xff.cz Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 730e71d747051f6cc121871bfdb7a7d70a4ef611 Author: Zhao Li Date: Tue Jul 28 19:13:26 2026 +0800 wifi: mac80211: fix per-STA profile length in cross-link CSA parsing [ Upstream commit 4a0bd262df757b25fc4e2a53c947317c119ced4e ] ieee80211_mgd_check_cross_link_csa() starts parsing elements after the fixed per-STA profile header and the STA Info field, but subtracts only the STA Info length from the profile length. As a result, ieee802_11_parse_elems() is given sizeof(*prof) == 3 bytes beyond the current profile's element area, and data following the profile may be interpreted as belonging to it. Subtract the fixed profile header as well. The preceding ieee80211_mle_basic_sta_prof_size_ok() check guarantees that the corrected calculation cannot underflow, and ieee80211_rx_uhr_link_reconfig_req() uses the same calculation. The call site currently states that cross-link CSA parsing has no effect because the broader parsing is still incorrect. This patch does not address that broader problem; it only makes the per-STA profile parser stop at the end of that profile. No production allocation over-read or user-visible failure has been demonstrated. Fixes: 7ef8f6821d16 ("wifi: mac80211: mlme: handle cross-link CSA") Assisted-by: Codex:gpt-5.6-sol Assisted-by: Kimi:K3 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260728111326.63087-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit da7805f0211af19968584e621074f253ac07dba7 Author: Yonatan Nachum Date: Mon Jul 27 09:02:55 2026 +0000 RDMA/efa: Fix PBL chunk length computation [ Upstream commit 229b42d7450c1cf96f45ec39ebb69211b06bc036 ] On register MR, when creating the PBL, if it's an indirect PBL we create a chunk list to hold the PBL pages pointers. Each chunk is 4KB in size and can hold 510 addresses (EFA_PTRS_PER_CHUNK) and has a 12-byte control buffer at the end of it holding the next chunk's pointer and its length. If the PBL number of pages is a multiple of EFA_PTRS_PER_CHUNK, the calculated last chunk length is wrongly computed as 0, even though that chunk is fully populated with 510 real page pointers. This wrong length is used both to DMA map the chunk and is propagated to the device, causing the device to see the chunk as empty and reject the memory registration. Fix the calculation so it will be performed only if the number of pages isn't a multiple of EFA_PTRS_PER_CHUNK, if it is, its already handled in the above loop correctly. Also prevent out-of-bounds reach in the chunks array in such scenario. Fixes: 40909f664d27 ("RDMA/efa: Add EFA verbs implementation") Reviewed-by: Firas Jahjah Reviewed-by: Michael Margolin Signed-off-by: Yonatan Nachum Link: https://patch.msgid.link/20260727090255.1175120-1-ynachum@amazon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 5f1933163327c9f1c8f2a341c6cb551aaf231ff9 Author: Peiyang He Date: Mon Jul 27 13:06:59 2026 +0800 RDMA/rxe: Fix UAF in ODP init error-handling path [ Upstream commit 51f2c8d2c99fc1f452f7113c08a35edcc4bf8732 ] rxe_odp_mr_init_user() stores &umem_odp->umem in mr->umem before calling rxe_odp_init_pages(). If rxe_odp_init_pages() fails, rxe_odp_mr_init_user() releases umem_odp and returns an error. rxe_reg_user_mr() then unwinds the error through rxe_cleanup(), rxe_mr_cleanup(), ib_umem_release(mr->umem). There is an IS_ERR_OR_NULL(umem) check at the start of ib_umem_release(). But since mr->umem is NOT reset to NULL in the error handling path of rxe_odp_mr_init_user(), the check passes and it reads already-freed fields like umem->is_dmabuf, causing UAF. Fix the UAF by clearing mr->umem after releasing the failed ODP umem so the MR cleanup path does not release it again. Fixes: d03fb5c6599e ("RDMA/rxe: Allow registering MRs for On-Demand Paging") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Peiyang He Link: https://patch.msgid.link/70CB6DBCB19624C7+20260727050659.1543627-1-peiyang_he@smail.nju.edu.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 1d2271d7df5230e4ce36bdafd17524bd004f3b3f Author: Nicolin Chen Date: Tue Jul 14 13:55:06 2026 -0700 iommu/tegra241-cmdqv: Fix VINTF0 leak on the init-failure path [ Upstream commit f40f3144477314b489e4bc209c06cb51679fe82b ] tegra241_cmdqv_init_structures() allocates VINTF0 with kzalloc_obj(), inits it, and preallocates its logical VCMDQs. Two of its error paths leak. When tegra241_cmdqv_init_vintf() fails it returns before VINTF0 reaches the cmdqv->vintfs[] array, so the devres unwind on probe failure cannot reach it; free it directly there. A later VCMDQ preallocation failure instead leaves VINTF0 published, and so this time the unwind does reach tegra241_cmdqv_remove_vintf(), which then frees it from vintf->hyp_own. But tegra241_vintf_hw_init() sets that flag only afterward, from a HW read-back, so the still-uninited VINTF0 reads as guest-owned and leaks, with mutex_destroy() and ida_destroy() run on fields it never set up. Decide ownership from vintf->idx instead, the index assigned when its id is allocated: idx 0 is the kernel-owned VINTF0, while idx >= 1 marks a guest VINTF. So the in-kernel free decision in tegra241_cmdqv_remove_vintf() and tegra241_vintf_free_lvcmdq() now keys on idx too, and hyp_own stays a pure HW-readback state. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 9b37afb2d34d99ec4f8db28134181b5a8ec9a4a5 Author: Nicolin Chen Date: Tue Jul 14 13:55:05 2026 -0700 iommu/tegra241-cmdqv: Require exactly one Stream ID for a vSID [ Upstream commit fb292bfc9be936dade7eef7ec5762de1201983d8 ] tegra241_vintf_init_vsid() maps a guest vSID to a single physical Stream ID taken from master->streams[0], and only warns when the device does not have exactly one stream. A device with several streams gets only its first one mapped, so a guest vSID invalidation cannot reach the others' ATC and IOTLB entries; a device with none makes master->streams a ZERO_SIZE_PTR, read out of bounds. Reject the mapping with -EOPNOTSUPP if master->num_streams is not one. Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 735698e81f798b4c02dcb6291ffbdd1b962c8c66 Author: Nicolin Chen Date: Tue Jul 14 13:55:03 2026 -0700 iommu/tegra241-cmdqv: Free the error IRQ before tearing down VINTFs [ Upstream commit 61f0d437988e5730b04442f6a7d30a9907339f2a ] tegra241_cmdqv_remove() tears each VINTF down first, then calls free_irq(). Tearing a VINTF down frees vintf0 and clears cmdqv->vintfs[0]. An error in that window makes tegra241_cmdqv_isr() read the stale slot and hand it to tegra241_vintf0_handle_error(), which dereferences a NULL or freed pointer. Free the IRQ before tearing the VINTFs down. free_irq() waits for in-flight handlers to finish and blocks new ones, so no ISR can observe a VINTF as it is torn down. Note: a user-owned VINTF (viommu) could outlive this teardown, which unmaps cmdqv->base and frees cmdqv->vintfs, so a later viommu close then touches freed memory. This is neither introduced nor fixed here: a physical IOMMU is not a pluggable device, so iommufd by design holds no reference on the one behind a viommu, and this teardown is not expected while that viommu is still alive. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2f627118b668659c6b195ac48beedb1bf8f53368 Author: Nicolin Chen Date: Tue Jul 14 13:55:01 2026 -0700 iommu/tegra241-cmdqv: Don't run the error ISR before probe sets up vintfs [ Upstream commit 5acd67ceb38debe2fbf70ea35e2dec9f7ab01bbd ] __tegra241_cmdqv_probe() requests the error IRQ before it has allocated the cmdqv->vintfs array and set cmdqv->num_vintfs. A CMDQV left enabled with a latched error across a kexec fires the IRQ as soon as it is requested, and tegra241_cmdqv_isr() then walks the uninitialized cmdqv->vintfs array. Request the IRQ only after cmdqv->vintfs is allocated and zeroed, so that a latched interrupt firing early runs the ISR against a valid array of NULL slots that it safely skips. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit bcb82407633c3008362ad927699d985ee4981557 Author: Nicolin Chen Date: Tue Jul 14 13:54:59 2026 -0700 iommu/tegra241-cmdqv: Synchronize the error ISR against VINTF (de)init [ Upstream commit a491be376abd1c80a314cdd658632c85cd660b73 ] A user VINTF is torn down by tegra241_cmdqv_deinit_vintf(), which runs from the destroy callback and from the init-failure unwind in the alloc handler. It clears the cmdqv->vintfs[] slot and lets the iommufd core free it, but nothing serializes that against the error interrupt: tegra241_cmdqv_isr() reads cmdqv->vintfs[idx] and dereferences the vintf. A concurrent error can make the ISR read a slot mid-clear (a NULL deref) or use a vintf which is about to be freed (a use-after-free). deinit_vintf() also returns idx to the IDA before clearing the slot, so a concurrent create that reuses idx can publish its new vintf into the slot, only for this teardown to erase it again with the stale NULL store. On the other end, tegra241_cmdqv_init_vintf() publishes a new vintf with a plain store to the cmdqv->vintfs[] slot, and the ISR dereferences fields of a published vintf such as vintf->base. A plain store gives no ordering on a weakly-ordered CPU, and a stale VINTF_ERR_MAP bit on a reused idx can make the ISR pick a vintf the moment it is published, before its fields are set or tegra241_vintf_hw_init() runs. The cmdqv->vintfs[0] slot stays NULL until tegra241_cmdqv_init_structures() first creates VINTF0, so the slot 0 read needs the same NULL check. Publish every slot with an smp_store_release(), and read each slot in the ISR with an smp_load_acquire() under a NULL check, so the ISR always sees a fully built vintf or NULL. Also make deinit_vintf() clear the slot, and synchronize_irq() prior to returning idx to the IDA, so no vintf is freed under a running handler and no reused idx is clobbered. Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 792f720fc23fe5bd6508d40ed73ae739debd6dcb Author: Nicolin Chen Date: Tue Jul 14 13:54:58 2026 -0700 iommu/tegra241-cmdqv: Publish an LVCMDQ only after it is fully initialized [ Upstream commit cbc41aacd49e695338940196e7084770365e1b68 ] tegra241_vintf_init_lvcmdq() stores the freshly allocated vcmdq pointer to the vintf->lvcmdqs[] array, before tegra241_vcmdq_alloc_smmu_cmdq() builds the vcmdq->cmdq. The error ISR dereferences that cmdq, so a latched LVCMDQ error (e.g. one inherited across a kexec) firing in this window would make tegra241_vintf0_handle_error() pass the still-zeroed arm_smmu_cmdq down to __arm_smmu_cmdq_skip_err(), dereferencing NULL queue register pointers. Drop the store from tegra241_vintf_init_lvcmdq() and publish the vcmdq at the end of the allocation instead, with an smp_store_release() that pairs with an smp_load_acquire() in the ISR, which can see a fully built LVCMDQ or NULL. The user-owned LVCMDQ allocation moves accordingly, publishing the vcmdq once tegra241_vcmdq_hw_init_user() succeeds, using a plain store since a user VINTF's lvcmdqs[] has no lockless reader -- the error ISR only walks the VINTF0 array. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-fable-5 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit aad605a450611e2a7b7cf9dd5724004d39192bfb Author: Weiming Shi Date: Tue Jun 23 03:14:35 2026 -0700 fs/ntfs3: reject restart table growth beyond U16_MAX entries [ Upstream commit 111f8d74a19d85942ecbb3aba78f6f3c88e59391 ] During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): rt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 7a7d30b1cb8904c20e30d16caee8b85827f01eae Author: Ivy Lopez Date: Fri Jul 17 16:01:35 2026 -0600 staging: rtl8723bs: use kfree_sensitive() for key material [ Upstream commit d205dfa8cb825f1954ca1cfa474fc50bf06ee4aa ] The set_stakey_parm struct contains a 16-byte encryption key. Use kfree_sensitive() instead of kfree() to ensure the key material is zeroed before the memory is freed, preventing potential information leaks. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Signed-off-by: Ivy Lopez Link: https://patch.msgid.link/20260717220135.17836-1-skunkolee@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6b2e70e9d52c0cf2d9afe342ba325598ff1946c5 Author: Mukesh Ojha Date: Mon Jan 5 18:52:52 2026 +0530 firmware: qcom_scm: Introduce PAS context allocator helper function [ Upstream commit ccb7bde5f7cc794dee0cd66fd451cb0e0715712d ] When the Peripheral Authentication Service (PAS) method runs on a SoC where Linux operates at EL2 (i.e., without the Gunyah hypervisor), the reset sequences are handled by TrustZone. In such cases, Linux must perform additional steps before invoking PAS SMC calls, such as creating a SHM bridge. Therefore, PAS SMC calls require awareness and handling of these additional steps when Linux runs at EL2. To support this, there is a need for a data structure that can be initialized prior to invoking any SMC or MDT functions. This structure allows those functions to determine whether they are operating in the presence or absence of the Gunyah hypervisor and behave accordingly. Currently, remoteproc and non-remoteproc subsystems use different variants of the MDT loader helper API, primarily due to differences in metadata context handling. Remoteproc subsystems retain the metadata context until authentication and reset are completed, while non-remoteproc subsystems (e.g., video, graphics, IPA, etc.) do not retain the metadata context and can free it within the qcom_scm_pas_init() call by passing a NULL context parameter and due to these differences, it is not possible to extend metadata context handling to support remoteproc and non remoteproc subsystem use PAS operations, when Linux operates at EL2. Add PAS context data structure allocator helper function. Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-4-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 0ea50486978f ("remoteproc: qcom: q6v5: Request shutdown if crash is triggered host-side") Signed-off-by: Sasha Levin commit f15cde11298402f803d5dda9cb9f95eea3d2ca40 Author: Bjorn Andersson Date: Thu Jul 23 03:52:28 2026 +0000 remoteproc: Prevent crash handling to race with rproc_del() [ Upstream commit 74ee3b2f5767447c57959994341e5b95f1079977 ] There's no synchronization between rproc_crash_handler_work() and rproc_del(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues. To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds. In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a "deleting" flag is introduced. This is similar to the RPROC_DELETE state that was introduced to ensure that "start" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the "state" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case. Assisted-by: OpenCode:GPT-5.5 Fixes: 8afd519c3470 ("remoteproc: add rproc_report_crash function to notify rproc crashes") Signed-off-by: Bjorn Andersson Reviewed-by: Pradnya Dahiwale Link: https://lore.kernel.org/r/20260723-rproc-rmmod-not-crashing-v1-2-546dfd5de0e6@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit df92f0e142edba93f7d228c32af5850661c0ba13 Author: Jingyi Wang Date: Tue Jun 23 02:05:34 2026 -0700 remoteproc: core: Attach rproc asynchronously in rproc_add() path via schedule_work() [ Upstream commit 026a3fada43261e403c6c4d9bda9501547e3f108 ] Unlike the remoteproc firmware load path where rproc_add() call rproc_auto_boot_callback() asynchronously and ignores the return value of rproc_boot(), the attach path calls rproc_boot() synchronously and propagates its return value back to rproc_add(). This means a failure during rproc_attach() causes rproc_add() to fail and triggers resource release, removing the remoteproc from sysfs and making it unavailable for recovery or further boot attempts. Align the remoteproc attach path with the firmware load path by introducing attach_work and scheduling rproc_boot() asynchronously via schedule_work(). This keeps the remoteproc registered and available in sysfs even if the initial attach attempt fails, and avoids blocking rproc_add() on the attach result. Signed-off-by: Jingyi Wang Link: https://lore.kernel.org/r/20260623-rproc-attach-issue-v3-1-8e24310707ce@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 74ee3b2f5767 ("remoteproc: Prevent crash handling to race with rproc_del()") Signed-off-by: Sasha Levin commit d6bf603246c90a2dd8fedd7ff92d32980a3debcb Author: Bjorn Andersson Date: Thu Jul 23 03:52:27 2026 +0000 remoteproc: Allow shutdown of crashed processors [ Upstream commit 2482ca875ef5993df8daee563033d70e2523a25f ] rproc_shutdown() rejects a remoteproc in RPROC_CRASHED state, and rproc_del() ignores that error. The result of these two decisions is that a user cannot stop a remoteproc that with recovery disabled that has entered a crash state, and removal of an associated remoteproc driver will release resources without first stopping the remoteproc. Allow rproc_shutdown() to stop crashed processors. Propagate the crash state to subdevice teardown, to allow subdevices to dismantle things appropriately. Assisted-by: OpenCode:GPT-5.5 Fixes: 5e6a0e05270e ("remoteproc: core: Move state checking to remoteproc_core") Signed-off-by: Bjorn Andersson Reviewed-by: Mukesh Ojha Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260723-rproc-rmmod-not-crashing-v1-1-546dfd5de0e6@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a098f5894fcb4c8ca38b0d6839bd8b642175961d Author: Peng Fan Date: Thu Oct 16 19:47:58 2025 +0800 remoteproc: core: Drop redundant initialization of 'ret' in rproc_shutdown() [ Upstream commit 4531b6bad5af669511c348ad5225d9f697af221b ] The variable ret is immediately assigned the return value of mutex_lock_interruptible(), making its prior initialization to zero unnecessary. Remove the redundant assignment No functional changes. Signed-off-by: Peng Fan Acked-by: Andrew Davis Link: https://lore.kernel.org/r/20251016-rproc-cleanup-v3-v3-1-774083716e8a@nxp.com Signed-off-by: Mathieu Poirier Stable-dep-of: 2482ca875ef5 ("remoteproc: Allow shutdown of crashed processors") Signed-off-by: Sasha Levin commit 8b93b783db3296cc4987524ea632c278b30503d0 Author: K Prateek Nayak Date: Mon Jul 27 07:20:48 2026 +0000 cpufreq/amd-pstate: Set min_limit_freq based on bios_min_perf [ Upstream commit 5c3ecf36d2918facff40548ee6ae28eef0865266 ] amd_pstate_update_min_max_limit() sets the min_limit_perf to the nominal_perf to avoid frequency throttling when the system is idling. This was found to be an ideal default but is suboptimal for users who have profiled their workload at different operating frequencies and have configured the optimal idling frequency via bios_min_perf. Use the bios_min_perf (if configured) as the min_limit_perf when running with performance governor. In absence of bios_min_perf, continue using nominal_perf as the default min_limit_perf to avoid throttling. Fixes: 608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: K Prateek Nayak Link: https://lore.kernel.org/r/20260727072056.1248-2-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit 9b95f10e1688c157bcc68f5c157a383363e64eda Author: Juan Martinez Date: Fri Jan 16 15:45:39 2026 -0600 cpufreq/amd-pstate: Add comment explaining nominal_perf usage for performance policy [ Upstream commit 94dbce6c13cd7634f9bdb402248991c95a8c3d57 ] Add comment explaining why nominal_perf is used for MinPerf when the CPU frequency policy is set to CPUFREQ_POLICY_PERFORMANCE, rather than using highest_perf or lowest_nonlinear_perf. Signed-off-by: Juan Martinez Signed-off-by: Viresh Kumar Stable-dep-of: 5c3ecf36d291 ("cpufreq/amd-pstate: Set min_limit_freq based on bios_min_perf") Signed-off-by: Sasha Levin commit 172f24df0dab4653a061ea45369be0db8883c459 Author: Babanpreet Singh Date: Tue Jul 14 04:10:10 2026 +0000 w1: ds2482: Fix signedness bug in ds2482_w1_triplet() [ Upstream commit 4d3721b204f961e905714954ff95633337b768e3 ] ds2482_wait_1wire_idle() returns the status register value (0..255) on success, or a negative value on I2C failure: -1 when selecting the status register fails, or a negative errno from i2c_smbus_read_byte(). ds2482_w1_triplet() feeds that result into "return (status >> 5);" without checking for errors, and the function returns u8. For a negative status the arithmetic shift keeps the sign and the u8 truncation fabricates a triplet result whose meaning depends on the errno value: -1 and -EIO happen to become 0xff, whose set low bits make w1_search() abort, but -ETIMEDOUT (-110 >> 5 = -4) becomes 0xfc - "devices responded on both branches, wrote 1" - and -EOPNOTSUPP (-95 >> 5 = -3) becomes 0xfd - "only the zero branch responded". w1_search() then continues the ROM search with a fabricated direction bit instead of aborting, and the corrupted id is either rejected by the ROM CRC (existing device missed) or registers a phantom slave. The function already defines an in-band error value: status is initialized to (3 << 5), which decodes to 3 (both branch bits set, "no device responded") and makes w1_search() terminate the search when sending the triplet command fails. Decode a negative status to the same value. Found by smatch: drivers/w1/masters/ds2482.c:314 ds2482_w1_triplet() warn: signedness bug returning '(-67108864)' Fixes: baf12ae29ab4 ("[PATCH] W1: Add the DS2482 I2C-to-w1 bridge driver.") Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Babanpreet Singh Link: https://patch.msgid.link/20260714041011.7-1-bbnpreetsingh@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit ef5cc4a8c088d05549f71950a72b5deff5000fd7 Author: Fan Wu Date: Sun Jul 19 01:00:13 2026 +0000 spi: oc-tiny: switch to managed controller allocation [ Upstream commit d710f43ce30975d197f73c543bfe47b958d8ba17 ] The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded driver-private devdata, which is the IRQ handler's dev_id. The devm_request_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach tiny_spi_irq() and dereference already-freed memory (e.g. hw->base). Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. This issue was found by an in-house static analysis tool. Fixes: ce792580ea2c ("spi: add OpenCores tiny SPI driver") Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260719010014.3163356-1-fanwu01@zju.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 67e2ffe98d710ed541b360c1f7a8856a3903b114 Author: Myeonghun Pak Date: Wed Jun 24 15:23:55 2026 +0900 clk: mediatek: mt6735: Unregister PLLs on probe failure [ Upstream commit 935ad6242c47b37380d0cb7ec366516fe11855b4 ] mtk_clk_register_plls() registers the apmixedsys PLL clocks manually, while clk_mt6735_apmixed_remove() unregisters them on driver removal. If devm_of_clk_add_hw_provider() fails after the PLL registration succeeds, probe returns the error directly and the remove callback is not run. This leaves the registered PLL clocks behind on the probe failure path. Unregister the PLLs in that failure branch before returning the error. Fixes: 43c04ed79189 ("clk: mediatek: Add drivers for MediaTek MT6735 main clock and reset drivers") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 106e1a3b2b3454fbda63a59e9290cb9a253f81aa Author: Yichong Chen Date: Tue Jul 21 17:11:52 2026 +0800 isofs: release zisofs block pointer buffer head [ Upstream commit 2f7dd9b86fe4076059e6a4a2a2c5d565afd76b9e ] zisofs_fill_pages() reads the compressed block pointer table. The error paths release the current buffer_head, the loop also releases the old buffer_head when it advances. However, the success path leaves the last buffer_head referenced. Release it before returning success. Fixes: 59bc055211b8 ("zisofs: Implement reading of compressed files when PAGE_CACHE_SIZE > compress block size") Signed-off-by: Yichong Chen Link: https://patch.msgid.link/20260721091152.1450622-1-chenyichong@uniontech.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit c39eb307b49764589fa4dad16469be4b543d013e Author: Sumeet Pawnikar Date: Thu Jul 23 22:53:20 2026 +0530 powercap: intel_rapl_tpmi: Handle PMU registration failure during probe [ Upstream commit 9229916d59918ec9d3639e7263e1e97be638e361 ] intel_rapl_tpmi_probe() invokes rapl_package_add_pmu() but ignores its return value, so a PMU registration failure would leave the driver reporting probe success despite the PMU being absent, with no log trace. Since PMU registration is an optional auxiliary feature for perf energy counters, its failure should not break the primary powercap functionality. Check the return value and log a warning to ensure graceful degradation. Fixes: 963a9ad3c589 ("powercap: intel_rapl_tpmi: Enable PMU support") Signed-off-by: Sumeet Pawnikar [ rjw: Changed the log level of the new message to "info" ] Link: https://patch.msgid.link/20260723172321.5960-1-sumeet4linux@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit bf32f103a325a229bbc5a97ca48935e9954e90c0 Author: Rakesh Kota Date: Fri Jul 24 16:30:24 2026 +0530 thermal/drivers/qcom-spmi-adc-tm5: Drop IIO_VAL_INT check in adc_tm5_get_temp [ Upstream commit 0c569e22020f53ddfac0099b0aa193907bfbcd6f ] Commit bb21ee31f575 ("iio: Fix iio_multiply_value use in iio_read_channel_processed_scale") fixed the iio_read_channel_processed_scale to return 0 on success instead of IIO_VAL_INT (1). The existing check in adc_tm5_get_temp() treated a successful return as an error because it expected IIO_VAL_INT. Drop the redundant `ret != IIO_VAL_INT` condition and rely solely on the negative error check. Fixes: bb21ee31f575 ("iio: Fix iio_multiply_value use in iio_read_channel_processed_scale") Signed-off-by: Rakesh Kota Signed-off-by: Daniel Lezcano Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260724-adc-tm5-drop-iio-val-int-check-v1-1-0b85a0895dd7@oss.qualcomm.com Signed-off-by: Sasha Levin commit 686a92cc9f19b84c268a3d6f0188ff3dba28362d Author: Christian Marangi Date: Thu Jul 2 11:48:30 2026 +0200 thermal/drivers/airoha: Fix copy paste error for sen internal [ Upstream commit 6791265d609549be55bb35b747c9648d0b570c12 ] In airoha_thermal_setup_monitor there is a copy paste error on configuring the internval for temp monitor. Fix the error and use the correct mask for the sen interval for the EN7581_TEMPMONCTL2 register. Fixes: 42de37f40e1b ("thermal/drivers: Add support for Airoha EN7581 thermal sensor") Signed-off-by: Christian Marangi Signed-off-by: Daniel Lezcano Reviewed-by: Wayen Yan Link: https://patch.msgid.link/20260702094846.17325-3-ansuelsmth@gmail.com Signed-off-by: Sasha Levin commit a06b2e6b8f508fca9214a3c60c9a42df6166e95c Author: Christian Marangi Date: Thu Jul 2 11:48:29 2026 +0200 thermal/drivers/airoha: Fix copy paste error on clamp_t low temp [ Upstream commit 251621813fb4275e24431f9a0690aec9b15823e7 ] In airoha_thermal_set_trips, there is a copy paste error on clamping the value for the low trip temp point. Fix it to the correct value and actually clamp for the low variable. Fixes: 42de37f40e1b ("thermal/drivers: Add support for Airoha EN7581 thermal sensor") Signed-off-by: Christian Marangi Signed-off-by: Daniel Lezcano Reviewed-by: Wayen Yan Link: https://patch.msgid.link/20260702094846.17325-2-ansuelsmth@gmail.com Signed-off-by: Sasha Levin commit 5b6cfc6d7ff0959dd9766fdc24286a253b59ca77 Author: Maher Sanalla Date: Thu Jul 23 18:23:49 2026 +0300 RDMA/mlx5: Fix integer overflow of user QP buffer size [ Upstream commit dec47e4b0fe34afdf38caa72b4408ba95502e5de ] set_user_buf_size() computes the QP buffer size by left-shifting the user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers. A sufficiently large rq.wqe_cnt causes signed integer overflow, which is undefined behavior, and yields a small or negative buf_size, causing ib_umem_get() to map a buffer smaller than the hardware will actually write into. Replace the shifts and addition with check_shl_overflow() and check_add_overflow(), rejecting invalid user inputs. Moreover, guard the identical shift computing qp->sq.offset in _create_user_qp() before set_user_buf_size() is reached. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Maher Sanalla Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260723-fix-qp-buf-size-overflow-v1-1-ccb05ee43a7b@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9c9c64abed53056e0bc0d792473b5a51c76f9c8f Author: Can Peng Date: Tue Jul 14 21:14:42 2026 +0800 crypto: keembay - publish OF module alias for OCS AES/SM4 [ Upstream commit 0a94091e29f914e4f233a208599ca4055882c01b ] The Keem Bay OCS AES/SM4 driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Although the match table lives in keembay-ocs-aes-core.o, that object is part of the composite keembay-ocs-aes module. Add the missing MODULE_DEVICE_TABLE(of, ...) entry so modpost can generate OF module alias information for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Fixes: 885743324513 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4") Signed-off-by: Can Peng Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7efb51a5893b22003a679d088b7794be2ccd6c32 Author: Linmao Li Date: Tue Jul 14 11:30:15 2026 +0800 crypto: keembay - Initialize completion before requesting IRQ [ Upstream commit fce20289dd622cc7ab78d72c8a979a9f8b7cb10e ] kmb_ocs_aes_probe() requests the device IRQ before initializing irq_completion. Once the handler is registered it can run immediately, and ocs_aes_irq_handler() unconditionally calls complete(). An interrupt in this window would therefore use an uninitialized completion. Initialize the completion before requesting the IRQ, as the sibling OCS HCU and ECC drivers already do. Fixes: 885743324513 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4") Signed-off-by: Linmao Li Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit cc92af8cc0e4dacd4375d34475141b0f1a70c09e Author: Li Qiang Date: Fri Jul 17 23:39:13 2026 +0800 scsi: ufs: debugfs: Reserve space for a string terminator [ Upstream commit abd26e6b53c4169122d61fdd4cabe09bdd916aac ] ufs_saved_err_write() copies user input into a zero-initialized stack buffer and passes it to kstrtoint(). A write that fills the entire buffer overwrites its only terminator. Reject an input whose length leaves no room for the trailing NUL. Fixes: 7340faae9474 ("scsi: ufs: core: Add debugfs attributes for triggering the UFS EH") Signed-off-by: Li Qiang Reviewed-by: Bart Van Assche Reviewed-by: Peter Wang Link: https://patch.msgid.link/20260717153914.26321-7-liqiang01@kylinos.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 15d4fc8f5f108ece1ae7261bcfefd5725748119e Author: Babanpreet Singh Date: Sun Jul 26 07:22:05 2026 +0000 power: supply: sbs-battery: Use a per-device serial number buffer [ Upstream commit 6027892925b8d19d2245c2d077e2ae35b49cc2b1 ] sbs_get_battery_serial_number() formats the battery serial number into sbs_serial[], a single file-scope buffer shared by every sbs-battery instance, and points val->strval at it. Nothing restricts this driver to one instance. It binds per I2C client, and sbs-manager registers one muxed I2C channel per supported battery specifically so that the smart battery driver can be bound to each of them, so several sbs-battery instances on one system is a supported configuration. The power supply core reads strval after the driver's get_property() callback has returned: power_supply_show_property() fills a local union power_supply_propval, then formats it with sysfs_emit(). Two concurrent POWER_SUPPLY_PROP_SERIAL_NUMBER reads on different batteries therefore race for the shared buffer - battery B's sprintf() can land between battery A filling the buffer and the core reading it, and battery A then reports battery B's serial number. Move the buffer into struct sbs_info so that each battery formats into its own storage. It is deliberately not added to the chip->strings[] array: those entries hold the cached constant strings that sbs_invalidate_cached_props() clears on presence changes, whereas the serial number is re-read from its word register on every access. Fixes: d3ab61ecbab2 ("bq20z75: Add support for more power supply properties") Assisted-by: Claude:claude-opus-5 Signed-off-by: Babanpreet Singh Link: https://patch.msgid.link/20260726072206.7-2-bbnpreetsingh@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit e505092cb200d430d5b8d8d3e926d45f29474ba3 Author: Kohei Enju Date: Wed Jul 15 21:28:50 2026 +0900 arm64: RSI: fix field-spanning write warning in attestation token init [ Upstream commit 221049874b6a78c7d87bc826581b0695cd338e2b ] The challenge is passed in registers a1 through a8. However, copying to ®s.a1 makes FORTIFY treat the destination as the single a1 field, resulting in a field-spanning write warning. [1] Overlay the SMCCC register structure with an RSI-specific argument layout and copy the challenge into an explicit 64-byte array. This keeps the existing a1-a8 argument encoding while giving the copy a correctly sized destination object. [1] memcpy: detected field-spanning write (size 64) of single field "®s.a1" at ./arch/arm64/include/asm/rsi_cmds.h:119 (size 8) WARNING: ./arch/arm64/include/asm/rsi_cmds.h:119 at rsi_attestation_token_init+0xdc/0xf8 [arm_cca_guest], CPU#0: cat/3314 Fixes: b880a80011f5 ("arm64: rsi: Add RSI definitions") Signed-off-by: Kohei Enju Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 386600507b23fc2ebd32f5e04129314e4619692a Author: James Clark Date: Wed Jul 15 15:53:48 2026 +0100 tools/build: Allow versioning of all LLVM tools defined in Makefile.include [ Upstream commit d5a1d1270c898057afc5b51fb6d0f2defa89d56d ] The version of LLVM tools can be given on the build command with LLVM=-15, but this isn't applied to all tools. For example $(CC) gets versioned, but $(CLANG) doesn't. This causes a Perf build with LTO=1 to fail with an error about mixed clang versions: ld.lld: error: libperf/core.o: Unknown attribute kind (86) (Producer: 'LLVM18.1.8' Reader: 'LLVM 15.0.7') This file has two "ifneq ($(LLVM),)" blocks adjacent to each other, so merge these blocks making it obvious that all tools should be versioned consistently and there is nothing special about each block. This also reveals that ?= and "allow-override" are used inconsistently between the blocks. "allow-override" is technically only required for builtin variables, but isn't only used on them, and doesn't do any harm if used on a non-builtin. Make them all "allow-override" for consistency. The only functional difference this will cause is if there is a file level definition of one of the variables followed by an "#include of Makefile.include" which will now overwrite. But this isn't done and in a later commit some of the duplicate definitions will be removed for good measure. There are also some other LLVM tools that are not defined here and will be moved in a later commit. Signed-off-by: James Clark Reviewed-by: Ian Rogers Acked-by: Kumar Kartikeya Dwivedi Fixes: e9c281928c24 ("kbuild: Make $(LLVM) more flexible") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 7f6d898179ca4771ee602bdad4246c3952af83eb Author: Justin Yeh Date: Thu Jul 23 11:58:13 2026 +0800 pinctrl: mediatek: free EINT resources on unbind [ Upstream commit 88292b7103d260e3e606eb3bb2794060a5fde48e ] mtk_eint_do_init() creates an IRQ domain, populates it with a mapping for every EINT line and installs a chained handler on the parent interrupt, but none of these are ever released. This was harmless while the drivers were built-in, but now that they can be built as modules and unbound/rmmod'd it leaves behind a dangling IRQ domain, interrupt mappings whose chip data points at freed memory, and a chained handler that keeps firing into that freed data. The plain allocations in mtk_eint_do_init() already use the device-managed devm_*() helpers, so tear the remaining resources down the same way: register a devm action that detaches the chained handler, waits for any in-flight handler to finish, disposes of the per-line mappings and removes the IRQ domain. This mirrors the device-managed lifecycle adopted for the GPIO chip and keeps the whole EINT setup self-cleaning on unbind. Fixes: e46df235b4e6 ("pinctrl: mediatek: refactor EINT related code for all MediaTek pinctrl can fit") Signed-off-by: Justin Yeh Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f54b96e8aadbfc7f2a1b26df349ef9b062c47d2e Author: Alison Schofield Date: Fri Jul 24 15:28:01 2026 -0700 cxl/region: Fix use-after-free in find_pos_and_ways() error path [ Upstream commit 15da704b732332cc1e8f121f624e5e6c05124c5d ] The error path releases its reference to a switch decoder before logging an error that includes the decoder name. If the released reference is the last one, the decoder can be freed before the error message accesses its name. Drop the reference after the error is reported. Fixes: d90acdf49e18 ("cxl/region: Add a dev_err() on missing target list entries") Reviewed-by: Li Ming Reviewed-by: Jonathan Cameron Signed-off-by: Alison Schofield Link: https://patch.msgid.link/10deb519b543ef693ce23148b509a03fe1c07d0c.1784931354.git.alison.schofield@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit b804df9aa2942388de1ed57b1577af739bec107d Author: Feng Yang Date: Thu Jul 23 16:51:00 2026 +0800 selftests/bpf: Fix memory leak on subtest_states reallocation [ Upstream commit 06efb01c6530e9cfc247178cb96aa8adb3beaf61 ] Fix memory leak in subtest_states reallocation, and revert subtest_num if allocation fails. Fixes: 0925225956bb ("bpf/selftests: Add granular subtest output for prog_test") Signed-off-by: Feng Yang Link: https://lore.kernel.org/bpf/20260723085100.482147-6-yangfeng59949@163.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit b7983cd5ba2c7bdcc112a5bc6148d35fe49f6b0c Author: Feng Yang Date: Thu Jul 23 16:50:57 2026 +0800 selftests/bpf: Fix incorrect error checking for pthread_create [ Upstream commit b04b8d4e198aefc863e7b702ececb957845b0c25 ] pthread_create returns 0 on success and a positive error code on failure; it never returns a negative value. The current conditional branch can never be taken. Failures during thread creation are silently ignored, which will lead to invalid memory access when waiting on threads or dereferencing thread handles later. Fixes: 91b2c0afd00c ("selftests/bpf: Add parallelism to test_progs") Signed-off-by: Feng Yang Link: https://lore.kernel.org/bpf/20260723085100.482147-3-yangfeng59949@163.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit c78a9289084a7f542917301badd9acce5188b370 Author: Karl Mehltretter Date: Mon Jul 13 21:25:06 2026 +0200 ARM: lpc32xx: only run SoC init on LPC32xx hardware [ Upstream commit 717ea4000867e6dffee5e1ed92150a9704ae9f68 ] lpc32xx_check_uid() and lpc32xx_pm_init() are arch_initcalls that poke LPC32xx-only registers. Since the multiplatform conversion they also run on other ARCH_MULTI_V5 boards where access faults e.g. on versatile: Unable to handle kernel paging request at virtual address f4004130 PC is at lpc32xx_check_uid+0x2c/0x9c Drop the arch_initcall() registrations and call both functions directly from lpc3250_machine_init(), the machine's .init_machine hook. The calls are placed in link order (common.c, pm.c, phy3250.c) to keep their previous relative ordering. Fixes: 75bf1bd7d2f9 ("ARM: lpc32xx: allow multiplatform build") Suggested-by: Arnd Bergmann Signed-off-by: Karl Mehltretter Reviewed-by: Vladimir Zapolskiy Reviewed-by: Arnd Bergmann Signed-off-by: Vladimir Zapolskiy Signed-off-by: Sasha Levin commit 85a33c910edc3651f68b17ae3c597c012545958f Author: Mykyta Yatsenko Date: Fri Jul 24 08:52:06 2026 -0700 bpf: Fix CFI mismatch in task work callback [ Upstream commit 2805abd089576799b15092949420e3f8ba97fabd ] BPF subprograms use the bpf_callback_t ABI, but task work invokes the callback through a three-argument function pointer. This trips kCFI. Store and invoke the callback as bpf_callback_t. Fixes: 38aa7003e369 ("bpf: task work scheduling kfuncs") Signed-off-by: Mykyta Yatsenko Link: https://lore.kernel.org/bpf/20260724-task_work_cfi-v1-1-2616691781ed@meta.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 4f7e0be664af78c3a6425a6109c43446e480a967 Author: Fabio Estevam Date: Tue Jul 21 10:54:50 2026 -0300 arm64: dts: rockchip: Fix rk3566-bigtreetech-cb2 touchscreen property [ Upstream commit 7707e4555cf1d52689621e3206df8ad2debaa0dd ] The TSC2007 driver uses the ti,max-rt property to specify the maximum touch resistance, but the rk3566-bigtreetech-cb2 device tree uses the undocumented ti,rt-thr property instead. As a result, the configured value is ignored and the driver falls back to its default maximum resistance value of 4095. Replace ti,rt-thr with ti,max-rt to preserve the intended resistance threshold of 3000. Fixes: bfbc663d2733 ("arm64: dts: rockchip: Add BigTreeTech CB2 and Pi2") Signed-off-by: Fabio Estevam Link: https://patch.msgid.link/20260721135450.45286-1-festevam@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 9ca64fd7a2fdefd5f4dbe0b964bdcc334aba1713 Author: Fabio Estevam Date: Tue Jul 21 10:34:45 2026 -0300 arm64: dts: rockchip: Fix Gru WLAN sideband interrupt [ Upstream commit a761818d9ee11183df0aefd16bf9fe46cc1c4c6d ] The Marvell WLAN host wake interrupt is wired to GPIO0 8 and is not one of the PCI INTx interrupts. The PCI device schema therefore interprets the two-cell GPIO interrupt specifier as an invalid PCI interrupt and reports dtbs_check warnings: pcie@0,0: wifi@0,0:interrupts:0:0: 8 is not one of [1, 2, 3, 4] pcie@0,0: wifi@0,0:interrupts:0: [8, 8] is too long Describe the sideband interrupt with interrupts-extended, which explicitly carries the interrupt controller and removes the ambiguity. Fixes: 48f4d9796d99 ("arm64: dts: rockchip: add Gru/Kevin DTS") Signed-off-by: Fabio Estevam Link: https://patch.msgid.link/20260721133445.44283-1-festevam@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 053220e061c7d9c0575b14d49ebe249f21b5b5e3 Author: Damon Ding Date: Fri Jun 5 10:23:04 2026 +0800 arm64: dts: rockchip: Add missing hclk for RK3588 eDP1 [ Upstream commit 09820811c549ee2c408defe36b210b13c7a85fcf ] Add the required HCLK_VO1 bus clock to RK3588 eDP1 node with corresponding clock-name "hclk". This clock is necessary for the eDP controller to access video output GRF and work properly. Previously the clock was enabled implicitly via GRF phandle reference. Add it explicitly now to align with updated binding. Fixes: a481bb0b1ad9 ("arm64: dts: rockchip: Add eDP1 dt node for rk3588") Signed-off-by: Damon Ding Link: https://patch.msgid.link/20260605022305.3058853-3-damon.ding@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit f5b4bc09c42f2e88d67aea4433aee5f1a0e69fb9 Author: Damon Ding Date: Fri Jun 5 10:23:03 2026 +0800 arm64: dts: rockchip: Add missing hclk for RK3588 eDP0 [ Upstream commit ede2ee37f0a445cacbf24760f53befa10f64994a ] Add the required HCLK_VO1 bus clock to RK3588 eDP0 node with corresponding clock-name "hclk". This clock is necessary for the eDP controller to access video output GRF and work properly. Previously the clock was enabled implicitly via GRF phandle reference. Add it explicitly now to align with updated binding. Fixes: dc79d3d5e7c7 ("arm64: dts: rockchip: Add eDP0 node for RK3588") Signed-off-by: Damon Ding Link: https://patch.msgid.link/20260605022305.3058853-2-damon.ding@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit d65261e0902b476a2a00af514ef574cec699cf17 Author: Osama Abdelkader Date: Thu Jul 16 16:03:36 2026 +0200 drm/panthor: return PTR_ERR() from devm_drm_dev_alloc() [ Upstream commit abc1e559f8e5996eee506dfdc8e3781c2a1e04f9 ] devm_drm_dev_alloc() returns an ERR_PTR() on failure, but panthor_probe() always converts that failure to -ENOMEM. Preserve the actual error code returned by the DRM core instead. Fixes: 4bdca1150792 ("drm/panthor: Add the driver frontend block") Signed-off-by: Osama Abdelkader Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patch.msgid.link/20260716140337.10679-1-osama.abdelkader@gmail.com Signed-off-by: Sasha Levin commit 64bb6000bfbdf241a6dd578199acd90321a4243e Author: Weiming Wu Date: Wed Jun 10 19:57:25 2026 +0800 fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init [ Upstream commit 2064bc663f89e61b8681c1fb9d1ce445de72063d ] ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360) Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Wu Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit e70d48fcf8382581162608a4a322919bfd22aef3 Author: Florian Westphal Date: Mon Jul 6 14:30:55 2026 +0200 netfilter: nf_nat_sip: rewind offset when NAT shrinks the packet [ Upstream commit 16aecbe3036f6097c26b51b12e4c1cf207769690 ] sashiko says: If map_addr() changes the packet length, such as when the public NAT IP string is shorter or longer than the internal IP, coff will still point to the offset relative to the pre-mangled packet. If the packet shrinks, coff could overshoot the correct position, potentially causing the next ct_sip_parse_header_uri() call to silently skip bytes and miss subsequent Contact headers. Could this lead to a failure to NAT those subsequent headers and leak internal network details? Fixes: c978cd3a9371 ("[NETFILTER]: nf_nat_sip: translate all Contact headers") Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 2e199e3ede9c12b999d6fb33f7fab558364ad57a Author: Can Peng Date: Wed Jul 15 10:41:30 2026 +0800 drm/tve200: add OF module alias for autoloading [ Upstream commit b6c3585f2058e0fbfa8cb403458f5cc6cf5c5e06 ] The TVE200 DRM driver can be built as a module and uses tve200_of_match as its OF match table, but the table is not exported for module alias generation. Add the MODULE_DEVICE_TABLE(of, ...) entry so modpost can generate OF module aliases for OF based module autoloading. Fixes: 179c02fe90a4 ("drm/tve200: Add new driver for TVE200") Signed-off-by: Can Peng Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260715024130.186416-1-pengcan@kylinos.cn Signed-off-by: Sasha Levin commit d9e01c333cebca1749bbf555f7a835fb1c1a323d Author: Ian Rogers Date: Wed Jul 22 22:06:40 2026 -0700 perf cap: Remove used_root parameter and simplify capability checks [ Upstream commit 87ec3437f37b9fe44c524ba967cb12e78de06f15 ] Refactor perf_cap__capable() to completely remove the used_root out-parameter as requested by the maintainer. Relying on an explicit used_root boolean poisoned sequential capability checks (e.g. failing CAP_SYS_ADMIN checks poisoning the flag for subsequent CAP_PERFMON evaluations for unprivileged users) and created redundant complexity across check_ftrace_capable(), symbol__read_kptr_restrict(), and perf_event_paranoid_check(). Streamline the capability API to perform a pure true/false boolean evaluation. The function checks the Effective set using SYS_capget; if the syscall is missing or fails on legacy kernels, it cleanly falls back to checking EUID == 0. This perfectly preserves modern capability-aware host sessions, guarantees transparent fallback for older kernels, and correctly rejects privileged operations for containerized root processes that have explicitly dropped their capability bounding and permitted sets. Fixes: e25ebda78e23 ("perf cap: Tidy up and improve capability testing") Suggested-by: Namhyung Kim Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit a73a88bc4f4526dd330631f231f13adcd6287bec Author: Cosmo Chou Date: Wed Jul 15 16:07:47 2026 +0800 leds: pca9532: Fix phantom device registration on missing hardware [ Upstream commit 8d6b6c05b8e33d11e3fb3203309385e1a9cceecd ] The initial PWM and PSC register writes in pca9532_configure() do not check the return values of i2c_smbus_write_byte_data(). If the I2C device is physically absent from the bus, the write fails with -ENXIO. However, the driver ignores this error and allows probe() to complete successfully. This results in the registration of phantom LED class devices and gpiochips backed by non-existent hardware. Subsequent GPIO reads from these phantom chips return bogus values (due to -ENXIO being truncated to an unsigned char in pca9532_gpio_get_value()), silently corrupting hardware state tracking in userspace. Propagate the I2C write failures back to probe() so the driver core can gracefully abort binding and release devres-managed resources. Fixes: e14fa82439d3 ("leds: Add pca9532 led driver") Signed-off-by: Cosmo Chou Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260715080747.1638097-1-chou.cosmo@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f1e8c4d48583d24edefc56fdc9f25d1c0b64a2b4 Author: Malaya Kumar Rout Date: Sat Jul 11 20:22:45 2026 +0530 PM: hibernate: Fix memory leak in snapshot_write_next() error path [ Upstream commit 21d5c4cee31c5ce78f6decc7fafc7e7759af391f ] When memory_bm_create() succeeds for copy_bm but fails for zero_bm, the function returns without freeing the resources allocated for copy_bm. This results in a memory leak that includes radix tree nodes, zone structures, and page lists. Fix this by calling memory_bm_free() to release copy_bm's resources before returning the error code when zero_bm allocation fails. Fixes: 005e8dddd497 ("PM: hibernate: don't store zero pages in the image file") Signed-off-by: Malaya Kumar Rout Acked-by: Brian Geffon Link: https://patch.msgid.link/20260711145246.8625-1-malayarout91@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ce7d205c264665517c25e8a3231cf2d0c2443e3c Author: Leon Romanovsky Date: Thu Jul 23 07:35:23 2026 -0400 RDMA/erdma: complete object teardown when the destroy command fails [ Upstream commit 652befcba956ef357f480525ccbe25c59bc81d4d ] erdma_destroy_qp(), erdma_destroy_cq(), erdma_dereg_mr(), and erdma_destroy_ah() returned early when erdma_post_cmd_wait() failed, leaking the queue buffers, MTTs, doorbells and the STAG, QPN, CQN and AHN identifiers. A command timeout clears ERDMA_CMDQ_STATE_OK_BIT and permanently disables the command queue, so no retry can succeed; the RDMA core keeps the object after a failed destructor and forced uverbs cleanup then nulls the pointers, making the resources unreachable. Warn on failure but release every software-owned resource and return success, since during terminal destruction the hardware command result is only diagnostic. Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation") Link: https://patch.msgid.link/20260722-b4-qp-and-cq-memory-are-leaked-if-the-d-v1-1-97e223dc1c96@nvidia.com Signed-off-by: Leon Romanovsky Acked-by: Cheng Xu Signed-off-by: Sasha Levin commit 02deb637e965950148752a304dd1471212dd6470 Author: Sanghyun Park Date: Wed Jul 22 16:28:38 2026 +0900 xfrm: Fix skb double-free in xfrm_dev_direct_output() [ Upstream commit 2aed51fc58d9ce450e2c116efb956160fd06fa02 ] A return value other than 1 from local_out() means that the skb has been consumed or its ownership was transferred. xfrm_dev_direct_output() nevertheless frees the skb on this path, causing a double-free when netfilter drops the packet and invalidating any other owner. Return the local_out() result directly, matching the ownership handling in xfrm_output_resume(). Fixes: 5eddd76ec2fd ("xfrm: fix tunnel mode TX datapath in packet offload mode") Signed-off-by: Sanghyun Park Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 78da16d23496f33c91bcd39d35229f7d8f94b615 Author: Leo Yan Date: Mon Jul 20 11:01:21 2026 +0100 perf cs-etm: Avoid truncating AUX buffer sizes to int [ Upstream commit ec99be8a31db999a4f866be74ea7db61dbb19f24 ] cs_etm__get_trace() returns an int, but it used to return etmq->buf_len on success. That value comes from auxtrace_buffer::size, which is a size_t. For a large AUX trace block, returning the byte count through an int can overflow and make a valid buffer look like a negative error. The callers do not need the actual byte count from cs_etm__get_trace(). The buffer length is already stored in the etmq->buf_len. The callers only need to distinguish three states: < 0: error = 0: no more AUX buffers > 0: data is available Make cs_etm__get_trace() return 0 for all non-error cases and use etmq->buf_len to indicate whether a new buffer was found. Then make cs_etm__get_data_block() return 1 whenever data is available, instead of returning the buffer length. Also refactor cs_etm__get_data_block() to make its return value semantics clearer. Reported-by: Suyash Mahar Fixes: 8224531cf5a1 ("perf cs-etm: Modularize auxtrace_buffer fetch function") Signed-off-by: Leo Yan Reviewed-by: James Clark Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit f78fba8549204b86ce9779235e07ce64af38e737 Author: Leo Yan Date: Thu Jul 2 20:51:41 2026 +0100 perf cs-etm: Flush thread stacks after decoder reset [ Upstream commit ea5075e3776846d4941dddf1549426ebd3feb81f ] Perf resets the CoreSight decoder when moving to a new AUX trace buffer, this causes trace discontinunity globally. For callchain synthesis, keeping thread-stack state after decoder reset can leave stale call/return history attached to threads that are decoded later, producing incorrect synthesized callchains. Flush all host thread stacks after a decoder reset. When virtualization is present, flush the guest thread stacks as well. Reviewed-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Namhyung Kim Stable-dep-of: ec99be8a31db ("perf cs-etm: Avoid truncating AUX buffer sizes to int") Signed-off-by: Sasha Levin commit 25be36738f5fcc23d807e757a91a0c53cda25e0f Author: Junhui Liu Date: Sun Jul 12 12:00:02 2026 +0800 riscv: dts: spacemit: k1: Split gmac_clk_ref into independent pinctrl groups [ Upstream commit 8270311d70fdf36bc8aab1e52b554e654a8839ff ] The gmac_clk_ref signal is optional for the GMAC controller and is not strictly required for all hardware designs. The pins for gmac0_clk_ref (GPIO 45) and gmac1_clk_ref (GPIO 46) may also be used as GPIOs for other functions even when the Ethernet controller is active. Split the refclk pins into independent pinctrl groups so boards can request them only when the reference clock path is actually needed. Among the already mainlined boards, BPI-F3, Jupiter and MusePi Pro have optional hardware paths for the GMAC refclk pins. BPI-F3 and Jupiter route both GMAC refclk pins to the PHYs through NC/0R option resistors, while MusePi Pro only does so for GMAC0. Keep referencing the new clk-ref pinctrl groups on these boards so the optional hardware paths remain usable if the option resistors are populated. OrangePi R2S has no publicly available schematic, so also keep the clk-ref groups there to preserve the previous pinmux behavior. Fixes: 60775f28cfb7 ("riscv: dts: spacemit: Add Ethernet support for K1") Signed-off-by: Junhui Liu Reviewed-by: Yixun Lan Link: https://patch.msgid.link/20260712-bpi-cm6-v3-2-8d1e2045179d@pigmoral.tech Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit fe9d15fb66d5e00d1e42dd12a10cb90d26097e4b Author: Michael Opdenacker Date: Wed Nov 12 04:44:42 2025 +0000 riscv: dts: spacemit: Add OrangePi R2S board device tree [ Upstream commit 63e572b11464a233f45ad469ba64b8b9e68a9cd1 ] Add initial device tree support for the OrangePi RV2 board [1], which is marketed as using the Ky X1 SoC but is identical in die and package to the SpacemiT K1 SoC [2]. Enable UART0, to boot into a serial console Two Gigabit Ethernet ports with RGMII interface standard support are enabled, each port is connected to an external Motorcomm YT8531C PHY chip which uses the GPIO for reset control. Enable PDMA. Enable 8 GB eMMC chip for storage. Link: http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-R2S.html [1] Link: https://www.spacemit.com/en/key-stone-k1 [2] Signed-off-by: Michael Opdenacker Reviewed-by: Yixun Lan Link: https://lore.kernel.org/r/20251112044426.2351999-3-michael.opdenacker@rootcommit.com Signed-off-by: Yixun Lan Stable-dep-of: 8270311d70fd ("riscv: dts: spacemit: k1: Split gmac_clk_ref into independent pinctrl groups") Signed-off-by: Sasha Levin commit 9933e5f1f61ec3558c223128db84192edbf9e436 Author: Troy Mitchell Date: Thu Oct 23 15:28:30 2025 +0800 riscv: dts: spacemit: add MusePi Pro board device tree [ Upstream commit 0ee59934662dfb89b43a8392e64ac4880c2fca88 ] Add initial device tree support for the MusePi Pro board [1]. The board is using the SpacemiT K1/M1 SoC. This device tree is adapted from the SpacemiT vendor tree [2] and enables basic board functionality, including UART console, LED, eMMC, Ethernet, and PDMA. Link: https://developer.spacemit.com/documentation?token=YJtdwnvvViPVcmkoPDpcvwfVnrh&type=pdf [1] Link: https://gitee.com/bianbu-linux/linux-6.6/blob/k1-bl-v2.2.y/arch/riscv/boot/dts/spacemit/k1-x_MUSE-Pi-Pro.dts [2] Signed-off-by: Troy Mitchell Link: https://lore.kernel.org/r/20251023-k1-musepi-pro-dts-v4-2-01836303e10f@linux.spacemit.com Signed-off-by: Yixun Lan Stable-dep-of: 8270311d70fd ("riscv: dts: spacemit: k1: Split gmac_clk_ref into independent pinctrl groups") Signed-off-by: Sasha Levin commit a76b20b1f03099204db29b90e1024fe1c2b2cdd7 Author: Sudeep Holla Date: Wed Jul 22 18:35:21 2026 +0100 firmware: arm_scmi: Unrequest devices if driver registration fails [ Upstream commit 9f7cd6a62aa754ed6b48cbd5d50de40add1bcc86 ] scmi_driver_register() requests protocol devices before registering the driver. If driver_register() fails, those requests remain in the global IDR and retain pointers to the module's ID table. Once the failed module load releases that storage, later request matching or SCMI device creation can dereference the stale pointers. Unrequest the complete protocol table before returning the registration failure. At this point table registration succeeded, so every entry is owned by the current registration attempt. Fixes: d3cd7c525fd2 ("firmware: arm_scmi: Refactor protocol device creation") Reported-by: Sashiko Link: https://patch.msgid.link/20260722173521.2184378-2-sudeep.holla@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 456856a34906475fcf4b23879237103770dc7ef2 Author: Sudeep Holla Date: Wed Jul 22 18:35:20 2026 +0100 firmware: arm_scmi: Roll back partial protocol table registration [ Upstream commit 2224b622260ba590ab56ea1585d6bf7610be25b2 ] scmi_protocol_table_register() can leave earlier requests registered when a later entry in the same ID table fails. Each request retains a pointer to the driver's ID table, so a failed module load can leave a dangling pointer after the module storage is released. Unrequest only the successfully registered prefix, in reverse order, before returning the failure. Leave the failed entry and the remaining entries untouched because matching requests can be owned by another driver. Fixes: 2858f6e5f064 ("firmware: arm_scmi: Add multiple protocols registration support") Reported-by: Sashiko Link: https://patch.msgid.link/20260722173521.2184378-1-sudeep.holla@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 406d5ead1bcb04368fc6611081231a4912c823f3 Author: Marco Scardovi Date: Tue Jun 9 09:29:04 2026 +0200 cpufreq/amd-pstate: Toggle auto_sel in active mode on shared memory systems [ Upstream commit 9dfd13f80c856eab79130403a13fa3b83199346b ] On shared memory systems, the EPP configuration path (handled via cppc_set_epp_perf()) is responsible for toggling on the CPPC autonomous selection register (auto_sel). Currently, shmem_init_perf() returns early without doing any of the auto_sel configuration steps if cppc_state is AMD_PSTATE_ACTIVE. This skips enabling auto_sel, leaving the CPU in non-autonomous mode. Remove the early return check in shmem_init_perf() when cppc_state is AMD_PSTATE_ACTIVE. Toggling auto_sel is necessary for the active mode on shared memory systems to function based on the ACPI spec for CPPC v2 and below. Fixes: 2dd6d0ebf740 ("cpufreq: amd-pstate: Add guided autonomous mode") Assisted-by: Antigravity:gemini-3.5-flash Reviewed-by: K Prateek Nayak Tested-by: K Prateek Nayak Signed-off-by: Marco Scardovi Reviewed-by: K Prateek Nayak Link: https://lore.kernel.org/r/20260609073042.81275-3-scardracs@disroot.org Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit 821b41f6e3e4fcbc579de26620ec687ce4994f24 Author: Marco Scardovi Date: Tue Jun 9 09:29:03 2026 +0200 cpufreq/amd-pstate: Fix EPP return type and handle errors during initialization [ Upstream commit 57476909c3000a04e84a1d6018d63ba1b2aa20ab ] Currently, the EPP getter helper functions (msr_get_epp, shmem_get_epp, and the static call wrapper amd_pstate_get_epp) return u8 or s16. This makes it difficult to correctly propagate negative error values returned by the underlying MSR read or CPPC helpers (such as rdmsrq_on_cpu or cppc_get_epp_perf). Modify the return type of these functions to int, allowing them to return negative error codes properly. Additionally, in amd_pstate_epp_cpu_init(), fetch the firmware-programmed default EPP value and validate it before assigning it to the EPP variables. If amd_pstate_get_epp() returns an error code, propagate the error and abort the CPU initialization to prevent subsequent configuration failures. Fixes: 555bbe67a622 ("cpufreq/amd-pstate: Convert all perf values to u8") Assisted-by: Antigravity:gemini-3.5-flash Reviewed-by: K Prateek Nayak Tested-by: K Prateek Nayak Signed-off-by: Marco Scardovi Reviewed-by: K Prateek Nayak Link: https://lore.kernel.org/r/20260609073042.81275-2-scardracs@disroot.org Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit 95ad5fd298bcd4b3133b99c6c86561fa84b89efb Author: Mario Limonciello (AMD) Date: Sun Mar 29 15:38:09 2026 -0500 cpufreq/amd-pstate: Add support for platform profile class [ Upstream commit 798c47593ccae7dd36c033e557f3f364a2056b9e ] The platform profile core allows multiple drivers and devices to register platform profile support. When the legacy platform profile interface is used all drivers will adjust the platform profile as well. Add support for registering every CPU with the platform profile handler when dynamic EPP is enabled. The end result will be that changing the platform profile will modify EPP accordingly. Reviewed-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello (AMD) Stable-dep-of: 57476909c300 ("cpufreq/amd-pstate: Fix EPP return type and handle errors during initialization") Signed-off-by: Sasha Levin commit 471d6659925aa0dcb4ab2520fa5ee3f49dfeab22 Author: Mario Limonciello (AMD) Date: Sun Mar 29 15:38:07 2026 -0500 cpufreq/amd-pstate: Add dynamic energy performance preference [ Upstream commit e30ca6dd5345c5b8ba05f346a8e81105352fe571 ] Dynamic energy performance preference changes the EPP profile based on whether the machine is running on AC or DC power. A notification chain from the power supply core is used to adjust EPP values on plug in or plug out events. When enabled, the driver exposes a sysfs toggle for dynamic EPP, blocks manual writes to energy_performance_preference while it "owns" the EPP updates. For non-server systems: * the default EPP for AC mode is `performance`. * the default EPP for DC mode is `balance_performance`. For server systems dynamic EPP is mostly a no-op. Reviewed-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello (AMD) Stable-dep-of: 57476909c300 ("cpufreq/amd-pstate: Fix EPP return type and handle errors during initialization") Signed-off-by: Sasha Levin commit 0b99dd4201c255f9c910de22ddb79219ae9747c2 Author: Gautham R. Shenoy Date: Thu Mar 26 17:17:47 2026 +0530 amd-pstate: Make certain freq_attrs conditionally visible [ Upstream commit e67a5b6541831bbf1c40b6042a867a4594ec6b55 ] Certain amd_pstate freq_attrs such as amd_pstate_hw_prefcore and amd_pstate_prefcore_ranking are enabled even when preferred core is not supported on the platform. Similarly there are common freq_attrs between the amd-pstate and the amd-pstate-epp drivers (eg: amd_pstate_max_freq, amd_pstate_lowest_nonlinear_freq, etc.) but are duplicated in two different freq_attr structs. Unify all the attributes in a single place and associate each of them with a visibility function that determines whether the attribute should be visible based on the underlying platform support and the current amd_pstate mode. Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello (AMD) Stable-dep-of: 57476909c300 ("cpufreq/amd-pstate: Fix EPP return type and handle errors during initialization") Signed-off-by: Sasha Levin commit ea49944836140500c81a8c4eccb9d30b2faece67 Author: Mario Limonciello (AMD) Date: Thu Oct 9 11:17:51 2025 -0500 cpufreq/amd-pstate: Use sysfs_match_string() for epp [ Upstream commit 7e17f48667b6707593fc215cbe025157920934f1 ] Rather than scanning the buffer and manually matching the string use the sysfs macros. Reviewed-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello (AMD) Stable-dep-of: 57476909c300 ("cpufreq/amd-pstate: Fix EPP return type and handle errors during initialization") Signed-off-by: Sasha Levin commit baf5a7fd3f3e2f4297b42b249f4f4f63214f44c0 Author: Qianheng Peng Date: Thu Jul 16 16:51:39 2026 +0800 cpufreq: amd-pstate-ut: Skip tests when amd-pstate driver is not active [ Upstream commit 8d31bb1451643f328db0cea0e21e63ef54b4faf2 ] The crash issue may occur when modprobe amd_pstate_ut on intel platform. amd_pstate_ut: 1 amd_pstate_ut_acpi_cpc_valid success! amd_pstate_ut: 2 amd_pstate_ut_check_enabled success! BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 20300 Comm: modprobe Kdump: loaded Tainted: G O 6.6.0-0010.rc1.ctl4.x86_64 #1 Hardware name: FiberHome R2200 V5/Xeon Boards, BIOS 3.1a 02/24/2020 RIP: 0010:amd_pstate_ut_check_perf+0x141/0x280 [amd_pstate_ut] Call Trace: amd_pstate_ut_init+0x1b/0xff0 [amd_pstate_ut] ? __pfx_amd_pstate_ut_init+0x10/0x10 [amd_pstate_ut] do_one_initcall+0x42/0x2e0 ? kmalloc_trace+0x26/0x90 do_init_module+0x60/0x240 __se_sys_init_module+0x185/0x1c0 do_syscall_64+0x62/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Add state detection to amd pstate driver to prevent amd_pstate_ut driver from testing on non-AMD platforms. Fixes: 14eb1c96e3a3 ("cpufreq: amd-pstate: Add test module for amd-pstate driver") Suggested-by: Li Xiong Suggested-by: Xibo Wang Signed-off-by: Qianheng Peng Reviewed-by: Zhongqiu Han Link: https://lore.kernel.org/r/1784191899-28957-1-git-send-email-pengqh1@chinatelecom.cn (ML: adjust title) Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit 937f09ce104c139b2afd8f154c04ce479e69b867 Author: Andre Przywara Date: Mon Jul 20 23:51:28 2026 +0200 ARM: dts: allwinner: a10: Fix PMU interrupt [ Upstream commit eb7051f756460d7b951e94d9656e31ebb631ba28 ] The Performance Monitoring Unit of the Cortex-A8 cores in the Allwinner A10 SoC is connected to interrupt line 66, not 3. This is shown in the manual (where interrupt 3 is assigned to UART2, also in our .dtsi), but has also been confirmed by triggering an PMU overflow interrupt and inspecting the IRQ controller status registers (from U-Boot). Please note that "perf stat" does not use interrupts, this might explain why this evaded the initial testing. Fixes: 7e345d25c796 ("ARM: dts: sun4i-a10: Add PMU node") Signed-off-by: Andre Przywara Link: https://patch.msgid.link/20260720215128.5761-1-andre.przywara@arm.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 3933884bc3102898b458c53fbd1ac52eb9cdb8a4 Author: Xiang Mei Date: Thu Jul 9 11:41:01 2026 -0700 ext4: check dir entry fits before reading the hash trailer in ext4_search_dir() [ Upstream commit c7e6b863d298f56522d0d08554bbea7f142e6588 ] For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4_DIRENT_HASHES()), at an offset derived from de->name_len. On the sb_no_casefold_compat_fallback() path ext4_match() reads that trailer, but ext4_search_dir()'s by-hand pre-check only tests de->name + de->name_len <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4_DIRENT_HASHES(de) lands past the block end, so ext4_match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object: BUG: KASAN: use-after-free in ext4_match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4_match (fs/ext4/namei.c:1435) ext4_search_dir (fs/ext4/namei.c:1470) __ext4_find_entry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4_lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filename_lookup (fs/namei.c:2842) vfs_statx (fs/stat.c:353) __do_sys_newfstatat (fs/stat.c:538) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4_match(). This is the same bound ext4_check_dir_entry() already enforces via ext4_dir_rec_len(), so no well-formed entry is rejected. The other caller, ext4_find_dest_de(), runs ext4_check_dir_entry() first and is unaffected. Fixes: 471fbbea7ff7 ("ext4: handle casefolding with encryption") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Reviewed-by: Andreas Dilger Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260709184101.441348-1-xmei5@asu.edu Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 1399f102d8a1855c1a38506057306ec79d0787d9 Author: Guanghui Yang <3497809730@qq.com> Date: Thu Jul 9 14:41:51 2026 +0000 ext4: fix buffer_head leak in ext4_init_orphan_info [ Upstream commit 05704335803b69c1bfa8637b7ada942bf2ee8a41 ] ext4_init_orphan_info() reads orphan file blocks with ext4_bread() and stores the returned buffer_head in oi->of_binfo[i].ob_bh. If ext4_bread() succeeds but the orphan block magic or checksum validation fails, the function jumps to out_free. However, the old out_free loop starts releasing buffers from i - 1, so the current buffer_head at index i is skipped. This leaks the buffer_head reference obtained by ext4_bread() on the bad magic and bad checksum error paths. Fix this by tracking the number of successfully read buffer_heads and releasing exactly those buffer_heads on the error path. Fixes: 02f310fcf47f ("ext4: Speedup ext4 orphan inode handling") Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: Jan Kara Link: https://patch.msgid.link/tencent_B38798612A159E21450ECF959016371B0807@qq.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 0afbfe019c881483337d9f8304e678af05ebe7cc Author: Selvin Xavier Date: Tue Jul 21 04:54:40 2026 -0700 RDMA/bnxt_re: Clear VM_MAYWRITE on DBR/toggle page mmap [ Upstream commit 9b66c9af7172ffcf727214fa0ebe9a5e1ed6eb16 ] bnxt_re_mmap() rejects VM_WRITE for the DBR_PAGE and TOGGLE_PAGE mmap flags, but a read-only mapping can still retain VM_MAYWRITE. nd later be upgraded with mprotect(PROT_WRITE). This can bypass the write check that only runs at mmap time. Clear VM_MAYWRITE before vm_insert_page() in the shared DBR/toggle-page branch, matching the existing policy that userspace writes are not expected for these pages. Fixes: ea222485788208 ("RDMA/bnxt_re: Update alloc_page uapi for pacing") Suggested-by: Yousef Alhouseen Signed-off-by: Selvin Xavier Link: https://patch.msgid.link/20260721115440.24021-5-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 72a5e45f606ec454ef556a68ffd92e06b0677f44 Author: Jeff Johnson Date: Thu Jul 16 13:01:31 2026 -0700 wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx() [ Upstream commit 9ef9dd30058cc9223c72f711dca1a28a5947d0c5 ] Currently, in ath11k_wmi_tlv_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Add an upfront length check before dereferencing skb->data as a wmi_cmd_hdr. The check is placed before the trace_ath11k_wmi_event() call to preserve the existing trace semantics (tracing the full raw WMI event including the header), unlike the analogous ath12k fix which could use skb_pull_data() directly. Compile tested only. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260716-ath11k_wmi_tlv_op_rx-overread-v1-1-0b972b3f1368@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 95d1bd1db9e9d8eccffc880166e01c4775115716 Author: Jeff Johnson Date: Thu Jul 16 13:01:11 2026 -0700 wifi: ath12k: Avoid buffer overread in ath12k_wmi_op_rx() [ Upstream commit 7698656a2f7b045af5a6859766238cefea1b1945 ] Currently, in ath12k_wmi_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Update the logic to verify the buffer contains at least enough data to hold a wmi_cmd_hdr before reading from the buffer. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260716-ath12k_wmi_op_rx-overread-v1-1-327a4b1c2372@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit ccca0f7d9e906de2e777a7b2e54a77f8818c3b6b Author: Jeff Johnson Date: Mon Jul 13 09:15:50 2026 -0700 wifi: ath11k: Correctly copy the hint BSSID in WMI scan request [ Upstream commit 6fe2dddf59bbb2a96be0fcf23a205807b25ac173 ] Currently, in ath11k_wmi_send_scan_start_cmd(), the logic to populate the hint_bssid copies the BSSID in the wrong direction, from the firmware message to the argument buffer. Swap the parameters so that the BSSID is correctly populated in the firmware message from the argument buffer. This issue was reported on ath12k, but exists in ath11k as well. Compile tested only. Reported-by: Baochen Qiang Closes: https://lore.kernel.org/linux-wireless/afbff608-a005-43c4-af76-968a58bf0cc3@oss.qualcomm.com/ Fixes: 74601ecfef6e ("ath11k: Add support for 6g scan hint") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260713-ath12k_wmi_send_scan_start_cmd-bad-hint_bssid-v1-2-4ffc4a472992@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 8f86a58ab9412a772ad2b3c0e92e0bf8d499c16e Author: Jeff Johnson Date: Mon Jul 13 09:15:49 2026 -0700 wifi: ath12k: Correctly copy the hint BSSID in WMI scan request [ Upstream commit 7b0bd40e97a00991122122d5888ae455fb2bfc7a ] Currently, in ath12k_wmi_send_scan_start_cmd(), the logic to populate the hint_bssid copies the BSSID in the wrong direction, from the firmware message to the argument buffer. Swap the parameters so that the BSSID is correctly populated in the firmware message from the argument buffer. Compile tested only. Reported-by: Baochen Qiang Closes: https://lore.kernel.org/linux-wireless/afbff608-a005-43c4-af76-968a58bf0cc3@oss.qualcomm.com/ Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260713-ath12k_wmi_send_scan_start_cmd-bad-hint_bssid-v1-1-4ffc4a472992@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 0c9eac0d1fb47de4360fbd857c49e808a9b69445 Author: Aaradhana Sahu Date: Tue Jun 30 11:50:48 2026 +0530 wifi: ath12k: allocate HOST_DDR and BDF regions after Q6 RO region [ Upstream commit 42399be44b13eafb45c56b1c7d7c92107e50c289 ] Currently, the Q6 region contains a read-only firmware region along with the BDF_MEM_REGION_TYPE and HOST_DDR_REGION_TYPE memory areas. The firmware expects these writable memory regions to be assigned after the Q6 read-only section. However, the ath12k driver currently allocates the HOST_DDR_REGION_TYPE starting from the base of the Q6 region, which includes the read-only firmware area. As a result, the allocated memory regions overlap with the read-only section, causing the firmware to assert during QMI memory allocation. The Q6 memory region layout is as follows: Q6 Reserved Memory +--------------------------------------+ | | | Read-only Firmware Region | | (Q6 RO Region) | | | +--------------------------------------+ <--- bdf_addr_offset | Writable Memory Region | | (BDF + HOST_DDR allocations) | | | +--------------------------------------+ Fix this by allocating the required memory regions only after the end of the read-only region in the Q6 address space. The bdf_addr_offset parameter indicates where the writable region starts. Both HOST_DDR and BDF regions are allocated sequentially after this offset, with each region placed immediately after the previous one to avoid gaps and overlaps. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Fixes: 6757079c5890 ("wifi: ath12k: add support for fixed QMI firmware memory") Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Signed-off-by: Aaradhana Sahu Link: https://patch.msgid.link/20260630062048.1615178-4-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit e69fd62e8117ed130d7cf11432e58c0e7c97f9d2 Author: Aaradhana Sahu Date: Tue Jun 30 11:50:47 2026 +0530 wifi: ath12k: refactor QMI memory assignment [ Upstream commit ecb517f97e629d3b8c360cbb5db3fed4d599ea2e ] ath12k_qmi_assign_target_mem_chunk() uses a large switch-case to handle both memory region identification and allocation for each memory request type, leading to redundant allocation logic. Refactor this by introducing ath12k_qmi_get_mem_reg_name() to map memory request types to their corresponding reserved memory region names. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Signed-off-by: Aaradhana Sahu Link: https://patch.msgid.link/20260630062048.1615178-3-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Stable-dep-of: 42399be44b13 ("wifi: ath12k: allocate HOST_DDR and BDF regions after Q6 RO region") Signed-off-by: Sasha Levin commit 42bc932e05093a0cf5e98b70b542e24451f54aad Author: Aaradhana Sahu Date: Tue Jun 30 11:50:46 2026 +0530 wifi: ath12k: switch to name-based reserved memory lookup [ Upstream commit 3fe59edd1901c040e5b8e9d2428bf9ec6b4ce630 ] The driver currently retrieves reserved memory regions using index-based lookup, which depends on the ordering of reserved-memory nodes in the device tree. Since different platforms define these regions in varying orders and combinations, this approach is not compatible and can result in incorrect memory region access. Switch to looking up memory regions by name instead of index so it does not depend on node order. Use names already defined in qcom,ipq5332-wifi.yaml, so there are no backward compatibility issues. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Signed-off-by: Aaradhana Sahu Link: https://patch.msgid.link/20260630062048.1615178-2-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Stable-dep-of: 42399be44b13 ("wifi: ath12k: allocate HOST_DDR and BDF regions after Q6 RO region") Signed-off-by: Sasha Levin commit abda58f4529d7eebb6ef82e2d266dabc17507faa Author: Jeff Johnson Date: Sat Jul 11 11:04:43 2026 -0700 wifi: ath6kl: avoid buffer overreads in WMI event handlers [ Upstream commit f57314aade9d74d30f3360ec5ef85a83654748be ] The following WMI event handlers currently read from the event buffer without first verifying that the message was large enough to hold the expected event: ath6kl_wmi_scan_complete_rx() ath6kl_wmi_addba_req_event_rx() ath6kl_wmi_delba_req_event_rx() Add length checks to prevent overread. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260711-ath6kl_wmi_scan_complete_rx-v2-1-22dc0f7f45e7@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 64d445d40e5ea4c4d4d88880db753b370cb69161 Author: Yao Kai Date: Mon Jul 6 12:13:13 2026 +0800 ext4: validate readdir offset before accessing dirent [ Upstream commit bc4b7b0414c33b2c8898eb04386df0d21a13dad8 ] A corrupted directory can trigger the following KASAN report when ext4_readdir() resumes from an invalid position: BUG: KASAN: use-after-free in __ext4_check_dir_entry+0x5ef/0x820 Read of size 2 at addr ffff88810a646000 by task repro_linear/509 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 kasan_report+0xce/0x100 __ext4_check_dir_entry+0x5ef/0x820 ext4_readdir+0xcde/0x2b70 iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x12b/0x220 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f KASAN reports use-after-free because the out-of-bounds access lands in an adjacent freed page. The directory buffer itself is still referenced. ext4_dir_llseek() invalidates the directory cookie so that ext4_readdir() rescans directory entries from the start of the block. The rescan checks only the lower bound of rec_len before advancing. A corrupted rec_len can therefore place the offset where the block has insufficient space for a complete directory entry. The rescan itself may dereference that truncated entry, or the main loop may pass it to __ext4_check_dir_entry(). The latter reads de->rec_len before validating the range. For example: block offset 0 4092 4096 |---- de1.rec_len = 4092 -----|----| de2.inode | de2.rec_len ^ OOB, reported as UAF de2 starts at offset 4092 in this 4 KiB block. Its four-byte inode fits in the block, but its rec_len starts at offset 4096 and crosses the boundary. The minimum safe length is inode-dependent. Encrypted and casefolded directory entries need eight additional hash bytes, while a valid metadata checksum tail is only 12 bytes. Cache the metadata checksum feature state and derive the minimum directory entry length from the on-disk format. Use it to bound both the rescan and the offset passed to the main loop. Report an offset in a truncated block tail and skip the remainder of the block, while continuing to accept an offset exactly at the block boundary. Reported-by: syzbot+5322c5c260eb44d209ed@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5322c5c260eb44d209ed Fixes: ac27a0ec112a ("[PATCH] ext4: initial copy of files from ext3") Signed-off-by: Yao Kai Reviewed-by: Zhihao Cheng Reviewed-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20260706041313.708346-1-yaokai34@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit bd8d74bd46d09905164255b8635fa58b45f41068 Author: Aditya Prakash Srivastava Date: Fri Jul 3 04:54:12 2026 +0000 ext4: use fsdata to track inline data write state and fix race [ Upstream commit 7edbb323bab2b2a609016014caafdb651c898249 ] Instead of checking the live inode state (ext4_has_inline_data(inode) and ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in the write_end handlers, use the fsdata parameter of the address space operations to explicitly pass down the state in which write_begin prepared the write. A concurrent thread (such as ext4_page_mkwrite()) can convert the inline data to an extent between write_begin and write_end. If this happens, the write_end handlers would previously miss the inline write_end path and fall through to extent-based write_end logic. However, since block buffers were never allocated in write_begin, this resulted in NULL pointer dereferences or data loss because folio_buffers(folio) was NULL. Define EXT4_WRITE_DATA_INLINE (4) as a bit flag (Bit 2), treating fsdata as bitwise flags rather than mutually exclusive enums to keep states of the write path independent. Communicate this state via fsdata: 1) ext4_write_begin() and ext4_da_write_begin() set the EXT4_WRITE_DATA_INLINE bit in *fsdata via bitwise OR when an inline write is successfully prepared. 2) On entry, ext4_write_begin() clears the EXT4_WRITE_DATA_INLINE bit to safely handle VFS retries (where generic_perform_write() bypasses the fsdata initialization on its retry jump). 3) The write_end handlers perform a bitwise AND to check if the EXT4_WRITE_DATA_INLINE bit is set and invoke the inline write_end helper accordingly. Furthermore, during a buffered write, ext4_write_inline_data_end() acquires the xattr lock after preparing the write. If a concurrent page fault (ext4_page_mkwrite()) converts the inline data to an extent after the write_end handlers check the state but before ext4_write_inline_data_end() acquires the xattr write lock, the subsequent check will trigger a kernel panic via BUG_ON(!ext4_has_inline_data(inode)). To keep git history working and bisectability clean, replace the BUG_ON check in ext4_write_inline_data_end() with a graceful error- handling retry path in this same commit. If the inline data is cleared after locking the xattr, we safely release all resources (releasing iloc.bh, unlocking/putting the folio, stopping the active journal transaction handle) and return 0 (VFS retry) to let the generic write path retry the operation safely. Reported-by: syzbot+0c89d865531d053abb2d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0c89d865531d053abb2d Fixes: 3fdcfb668fd7 ("ext4: add journalled write support for inline data") Suggested-by: Jan Kara Signed-off-by: Aditya Prakash Srivastava Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260703045414.1768-1-aditya.ansh182@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 4e4e3eec506247c8f8bd8aaa1eb25e67016681a5 Author: Baokun Li Date: Mon Jun 29 19:38:23 2026 +0800 ext4: drain in-flight DIO before buffered write fallback [ Upstream commit 15cdefd0c0522f9d5e12d947fa04f4c11649b699 ] generic/746 started failing intermittently on ext3 (no-extent inodes). The test triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO. Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied, post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback) ----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared() iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async) dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0, 8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range() iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages() invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO) This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race. Fixes: 378f32bab371 ("ext4: introduce direct I/O write using iomap infrastructure") Suggested-by: Zhang Yi Link: https://patch.msgid.link/d1adcf7c-c276-458d-9cac-68a4410f7626@gmail.com Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Signed-off-by: Baokun Li Link: https://patch.msgid.link/20260629113827.4074335-3-libaokun@linux.alibaba.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit aa0042630b1f7cab735b0a168539281198822586 Author: Gerald Yang Date: Fri Jun 26 00:01:23 2026 +0800 ext4: clear stale xarray tags on folios skipped during writeback [ Upstream commit ec524aae479b4b2078c47492b90ec21200bce434 ] In data=journal mode, the writeback thread can hit the WARN_ON_ONCE(sb_rdonly(sb)) in ext4_journal_check_start() while the superblock is being remounted read-only during reboot: Workqueue: writeback wb_workfn (flush-253:0) RIP: 0010:ext4_journal_check_start+0x8b/0xd0 Call Trace: __ext4_journal_start_sb+0x3c/0x1e0 mpage_prepare_extent_to_map+0x4af/0x580 ext4_do_writepages+0x3c0/0x1080 ext4_writepages+0xc8/0x1a0 do_writepages+0xc4/0x180 __writeback_single_inode+0x45/0x2f0 writeback_sb_inodes+0x26b/0x5d0 __writeback_inodes_wb+0x54/0x100 wb_writeback+0x1ac/0x320 wb_workfn+0x394/0x470 And followed by the warning: EXT4-fs warning (device vda1): ext4_evict_inode:195: inode #6263: comm (sd-umount): data will be lost This issue is not reproduced every time, but frequently. The reproduction step is to create a VM with 8 CPUs, 16G memory and setup data=journal: sudo tune2fs -o journal_data /dev/vda1 Run fio: rm -f fiotest fio --name=fiotest --rw=randwrite --bs=4k --runtime=6 --ioengine=libaio --iodepth=256 --numjobs=8 --filename=fiotest --filesize=30G --group_reporting Reboot the VM, and check the console output from: virsh console testvm But there is no dirty inode, folio_clear_dirty_for_io clears PG_dirty but leaves tags PAGECACHE_TAG_DIRTY and PAGECACHE_TAG_TOWRITE set which are only cleared by __folio_start_writeback. In data=journal mode, jbd2 checkpoints the journalled data to its final location and clears its own dirty flag without touching folio PG_dirty or xarray dirty flags. The commit f4a2b42e7891 ("ext4: fix stale xarray tags after writeback") fixes when PG_dirty is still set but there is no dirty page. Another case is PG_dirty is cleared, but PAGECACHE_TAG_DIRTY and PAGECACHE_TAG_TOWRITE is still set. In this case, writeback thread checks clean folio and skips it in mpage_prepare_extent_to_map: if (!folio_test_dirty(folio) || ... folio_unlcok(folio); continue And never reaches ext4_bio_write_folio where the commit f4a2b42e7891 clears the stale xarray tags. Print debug logs after the filesystem is remounted read-only: writepages RDONLY nrpages=2048 dirtytag=1 wbtag=0 towrite=1 sync=0 And all folios are actually clean: folio idx=3 dirty=0 wb=0 checked=0 dirtybuf=0 jbddirty=0 mapped=1 ... We need to clear the xarray stale tags for such clean folios by cycling them through writeback in the skip path, the same way f4a2b42e7891 does in ext4_bio_write_folio. Fixes: dff4ac75eeee ("ext4: move keep_towrite handling to ext4_bio_write_page()") Signed-off-by: Gerald Yang Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260625160127.162272-1-gerald.yang@canonical.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit d7b025d3fdf3cf8b726ce1d13f434f57477972bb Author: Pengpeng Hou Date: Tue Jun 23 09:51:40 2026 +0800 thermal: intel: int3400: clean up ODVP on probe failures [ Upstream commit d83dc9ce57a746a6dca28439bcc0575d26fa6986 ] evaluate_odvp() creates per-ODVP sysfs files before the thermal zone and later probe resources are registered. The current unwind path only calls cleanup_odvp() from the late sysfs failure path, so failures after evaluate_odvp() but before that label, including thermal_tripless_zone_device_register() failures, leave the ODVP files and storage behind. Move the ODVP cleanup to the common ART/TRT unwind path so every failure after evaluate_odvp() releases the ODVP state. Also clear the cached ODVP pointers in cleanup_odvp(), because evaluate_odvp() can already call it for partial setup failures while probe continues. Fixes: 006f006f1e5c ("thermal/int340x_thermal: Export OEM vendor variables") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260623015140.19300-1-pengpeng@iscas.ac.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 466358635a2e4f7bed269a6d6bbe5f2e77f2d0e5 Author: Nicolin Chen Date: Mon Jun 15 12:45:33 2026 -0700 iommu/arm-smmu-v3: Declare eats_s1chk and eats_trans as host-endian u64 [ Upstream commit 4455286274474e95f223c68c215d32c864404889 ] arm_smmu_get_ste_update_safe() declares the eats_s1chk and eats_trans locals as __le64, but initializes them from FIELD_PREP(), which returns a host-endian value, and passes them through cpu_to_le64() at the use sites. Sparse reports the following warnings: >> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:1122:38: sparse: sparse: cast from restricted __le64 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:1124:33: sparse: sparse: cast from restricted __le64 Declare both locals as u64 so the type matches FIELD_PREP() and the existing cpu_to_le64() at the use sites performs the host-to-little-endian conversion. No functional change. Fixes: 7cad80048595 ("iommu/arm-smmu-v3: Mark EATS_TRANS safe when computing the update sequence") Reported-by: kernel test robot Closes: https://lore.kernel.org/all/202606151017.QU0evpH9-lkp@intel.com/ Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Reviewed-by: Jason Gunthorpe Reviewed-by: Pranjal Shrivastava Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 267fb3771ddf6a7c78e0bfa18c481ef0cf6f4574 Author: Mukesh Ojha Date: Fri Jul 17 20:16:03 2026 +0530 iommu/qcom: Fix inverted fault report check in qcom_iommu_fault() [ Upstream commit 1f33b8208a1978b0c0d6ad60a47fe4bb7a235e58 ] report_iommu_fault() returns 0 when a fault handler successfully handles the fault, and -ENOSYS when no handler is installed. The condition '!report_iommu_fault()' evaluates to true (printing "Unhandled context fault") precisely when the fault *was* handled, and stays silent when no handler is present — the opposite of what is intended. Remove the '!' so the driver logs unhandled faults correctly. Fixes: 049541e178d5 ("iommu: qcom: wire up fault handler") Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 0812b282703a7b76506202a63c89dfcfe1b3ca30 Author: Haoxiang Li Date: Tue Jun 23 15:12:45 2026 +0800 iommu/qcom: Remove sysfs device on probe failure path [ Upstream commit c579f18e79599c16168925cb149e1db3f29eea5f ] In qcom_iommu_device_probe(), if iommu_device_register() fails, the sysfs device created by iommu_device_sysfs_add() is not released. Add a goto label to do the cleanup. Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu") Signed-off-by: Haoxiang Li Reviewed-by: Konrad Dybcio Reviewed-by: Mukesh Ojha Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 8aabe0fba01486b5d893e708b05a8fa7f1b7efbb Author: Li RongQing Date: Mon Jun 1 08:12:40 2026 -0400 iommu/amd: Fix undefined behavior in devid_write debugfs function [ Upstream commit 843e149989665f8309ad2efe6048dc76591e1f94 ] When for_each_pci_segment() loop completes without finding a matching segment, the pci_seg pointer is not NULL but points to an invalid memory location (the list head). Accessing pci_seg->id after the loop causes undefined behavior. Fix this by handling the successful case inside the loop and returning -EINVAL after the loop if no matching segment is found. Fixes: 2e98940f123d9 ("iommu/amd: Add support for device id user input") Signed-off-by: Li RongQing Reviewed-by: Ankit Soni Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit c3d4ef1c0ca6917aad6f1093b49f3932944a8c19 Author: Sudeep Holla Date: Wed Jul 22 10:52:50 2026 +0100 firmware: arm_scmi: Fix requested device removal race [ Upstream commit 2c4097e6c4aed276c5e9ec2ab331ab397ea780bf ] scmi_protocol_device_unrequest() drops scmi_requested_devices_mtx while notifying listeners but continues to retain the per-protocol list head. When two SCMI drivers for the same protocol unregister concurrently, one thread can remove the final request and free the list head while the other is running its notifier. The latter then dereferences the freed list head after reacquiring the mutex and can free it a second time. Complete the list and IDR updates, including freeing an empty list head, before dropping the mutex. Keep the blocking notifier outside the critical section and retain only the detached request across the callback. Fixes: d3cd7c525fd2 ("firmware: arm_scmi: Refactor protocol device creation") Reported-by: Sashiko Link: https://patch.msgid.link/20260722095250.2011630-1-sudeep.holla@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 66d65f36d39759e9f62dc746dc71d862f20f827f Author: Patrisious Haddad Date: Mon Jul 13 18:38:07 2026 +0300 RDMA/core: Fix potential use after free in ib_dealloc_pd_user() [ Upstream commit 8b90e701342275f414e36e7421c502237df241ad ] When accessing a PD via the netlink path the only synchronization mechanism for the said PD is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_dealloc_pd_user(), which is too late, since by that point vendor-specific resources associated with the PD might already be freed. This can leave a short window where the PD remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_dealloc_pd_user(), ensuring that the PD is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a PD that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. Fixes: 91a7c58fce06 ("RDMA: Restore ability to fail on PD deallocate") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-8-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8b22722f45a29a7c0900b1d4d0bc5da5492ece10 Author: Patrisious Haddad Date: Mon Jul 13 18:38:06 2026 +0300 RDMA/core: Fix potential use after free in uverbs_free_dmah() [ Upstream commit 2696626a0be5877f445fb647c25ef43930c777e6 ] When accessing a dmah via the netlink path the only synchronization mechanism for the said dmah is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of uverbs_free_dmah(), which is too late, since by that point vendor-specific resources associated with the dmah might already be freed. This can leave a short window where the dmah remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of uverbs_free_dmah(), ensuring that the dmah is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a dmah that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. Fixes: d83edab562a4 ("RDMA/core: Introduce a DMAH object and its alloc/free APIs") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-7-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9abea37942534eeb049335476178696b654b000c Author: Patrisious Haddad Date: Mon Jul 13 18:38:05 2026 +0300 RDMA/core: Fix potential use after free in ib_free_cq() [ Upstream commit 29dc2f8e1c97372c2871a70088707933515fbd5b ] When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction. Fixes: 43d781b9fa56 ("RDMA: Allow fail of destroy CQ") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-6-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8c013e3a8d8273da4d47bf1c27f016a3551996f5 Author: Patrisious Haddad Date: Mon Jul 13 18:38:04 2026 +0300 RDMA/core: Fix potential use after free in counter_release() [ Upstream commit 235ef2d0e750885c29340b0fc40620a7a4f52e12 ] When accessing a counter via the netlink path the only synchronization mechanism for the said counter is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of counter_release(), which is too late, since by that point vendor-specific resources associated with the counter might already be freed. This can leave a short window where the counter remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources, ensuring that the counter is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a counter that is in the process of destruction. Fixes: 99fa331dc862 ("RDMA/counter: Add "auto" configuration mode support") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-5-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit bedd7dee72588c838f5b67197ea8b387e7beb918 Author: Patrisious Haddad Date: Mon Jul 13 18:38:03 2026 +0300 RDMA/core: Fix potential use after free in ib_destroy_srq_user() [ Upstream commit 88244ecc71cc0b3ed200f5ef7ddea6686adfd730 ] When accessing a SRQ via the netlink path the only synchronization mechanism for the said SRQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_srq_user(), which is too late, since by that point vendor-specific resources associated with the SRQ might already be freed. This can leave a short window where the SRQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_srq_user(), ensuring that the SRQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a SRQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. Fixes: 48f8a70e899f ("RDMA/restrack: Add support to get resource tracking for SRQ") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-4-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 197c262dbf94c0f7ab7ac54b66f892ce9f343232 Author: Patrisious Haddad Date: Mon Jul 13 18:38:02 2026 +0300 RDMA/core: Fix potential use after free in ib_destroy_cq_user() [ Upstream commit 3481bec4dfc4aee24ffea5a547ee95b70b67d9d5 ] When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_cq_user(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_cq_user(), ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. Fixes: 08f294a1524b ("RDMA/core: Add resource tracking for create and destroy CQs") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-3-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 038cf231b7099ba6202dcc0c1ea01525122df09f Author: Patrisious Haddad Date: Mon Jul 13 18:38:01 2026 +0300 RDMA/core: Fix use after free in ib_query_qp() [ Upstream commit 709ba0e5311bd034eb4d9c1c00cc4e1109d6dc3e ] When querying a QP via the netlink flow the only synchronization mechanism for the said QP is rdma_restrack_get(), meanwhile during the QP destroy path rdma_restrack_del() is called at the end of the ib_destroy_qp_user() function which is too late, since by then the vendor specific resources for said QP would already be destroyed, and till the rdma_restrack_del() is called this QP can still be accessed, which could cause the use after free below. Fix this by moving the rdma_restrack_begin_del() to the start of the ib_destroy_qp_user(), which in turn waits for all usages of the QP to be done then removes it from the database to prevent access to it while it is being destroyed. RIP: 0010:ib_query_qp+0x15/0x50 [ib_core] Code: 48 83 05 5d 8e b9 ff 01 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 c7 46 40 00 00 00 00 48 c7 46 78 00 00 00 00 <48> 8b 07 48 8b 80 88 01 00 00 48 85 c0 74 1a 48 83 05 54 91 b9 ff RSP: 0018:ff11000108a8f2f0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ff11000108a8f370 RCX: ff11000108a8f370 RDX: 0000000000000000 RSI: ff11000108a8f3d8 RDI: 0000000000000000 RBP: ff1100010de5a000 R08: 0000000000000e80 R09: 0000000000000004 R10: ff110001057a604c R11: 0000000000000000 R12: ff11000108a8f370 R13: ff110001090e8000 R14: 0000000000000000 R15: ff110001057a602c FS: 00007f2ffd8db6c0(0000) GS:ff110008dc90b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010b9a7004 CR4: 0000000000373eb0 Call Trace: mlx5_ib_gsi_query_qp+0x21/0x50 [mlx5_ib] mlx5_ib_query_qp+0x689/0x9d0 [mlx5_ib] ib_query_qp+0x35/0x50 [ib_core] fill_res_qp_entry_query.isra.0+0x47/0x280 [ib_core] ? __wake_up+0x40/0x50 ? netlink_broadcast_filtered+0x15a/0x550 ? kobject_uevent_env+0x562/0x710 ? ep_poll_callback+0x242/0x270 ? __nla_put+0xc/0x20 ? nla_put+0x28/0x40 ? nla_put_string+0x2e/0x40 [ib_core] fill_res_qp_entry+0x138/0x190 [ib_core] res_get_common_dumpit+0x4a5/0x800 [ib_core] ? fill_res_qp_entry_query.isra.0+0x280/0x280 [ib_core] nldev_res_get_qp_dumpit+0x1e/0x30 [ib_core] netlink_dump+0x16f/0x450 __netlink_dump_start+0x1ce/0x2e0 rdma_nl_rcv_msg+0x1d3/0x330 [ib_core] ? nldev_res_get_qp_raw_dumpit+0x30/0x30 [ib_core] rdma_nl_rcv_skb.constprop.0.isra.0+0x108/0x180 [ib_core] rdma_nl_rcv+0x12/0x20 [ib_core] netlink_unicast+0x255/0x380 ? __alloc_skb+0xfa/0x1e0 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x230 ? copy_msghdr_from_user+0xea/0x170 ___sys_sendmsg+0x7c/0xb0 ? __futex_wait+0x95/0xf0 ? __futex_wake_mark+0x40/0x40 ? futex_wait+0x67/0x100 ? futex_wake+0xac/0x1b0 __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xb90 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Fixes: 514aee660df4 ("RDMA: Globally allocate and release QP memory") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-2-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c538cd121be772a39ce204257da3a81a02876792 Author: Patrisious Haddad Date: Mon Jul 13 18:38:00 2026 +0300 RDMA/core: Add rdma_restrack_begin/abort/commit_del() operations [ Upstream commit 8d186210677c0322db886973bcec9aa4d21b51cd ] Add rdma_restrack_abort_del(), rdma_restrack_begin_del() and rdma_restrack_commit_del() functions to allow deleting a resource from the xarray to effectively prevent future access to it and wait for all current users to finish while preserving its index in the xarray to allow to re-insert it if needed with guaranteed success. This is a preparatory change for subsequent patches in the series which will use these functions to fix the cleanup flow. Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-1-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky Stable-dep-of: 709ba0e5311b ("RDMA/core: Fix use after free in ib_query_qp()") Signed-off-by: Sasha Levin commit a07cba1296aaa81bf9b914486ca957aaff196247 Author: Jason Gunthorpe Date: Wed Jun 3 22:27:43 2026 -0300 RDMA/nldev: Fix locking when accessing mr->pd [ Upstream commit 50d5c02ab8e62325548bd3a6e6b758a9dcd6e7c3 ] Sashiko points out that, due to rereg_mr, the PD is actually variable and all the touches in nldev are racy. Use mr->device instead of mr->pd->device. Getting the PD restrack ID is more tricky. To avoid disturbing all the happy paths, add an rdma_restrack_sync() operation which is sort of like flush_workqueue() or synchronize_irq(): after it returns, all the old nldev touches to the mr are gone and everything sees the new PD. This makes it safe to reach into the PD pointer. Fixes: da5c85078215 ("RDMA/nldev: add driver-specific resource tracking") Link: https://patch.msgid.link/r/4-v1-29ebd2c229b5+fd5-ib_mr_pd_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Stable-dep-of: 709ba0e5311b ("RDMA/core: Fix use after free in ib_query_qp()") Signed-off-by: Sasha Levin commit b7091e0e2ebab7368453285483ac09a9ba746d99 Author: Kalesh AP Date: Thu Nov 13 16:24:57 2025 +0530 RDMA/restrack: Fix typos in the comments [ Upstream commit d43358cda7c4696e08880aaa58a7df82e471fa7c ] Fix couple of occurrences of the misspelled word "reource" in the comments with the correct spelling "resource". Signed-off-by: Kalesh AP Link: https://patch.msgid.link/20251113105457.879903-1-kalesh-anakkur.purayil@broadcom.com Signed-off-by: Leon Romanovsky Stable-dep-of: 709ba0e5311b ("RDMA/core: Fix use after free in ib_query_qp()") Signed-off-by: Sasha Levin commit 4aaa2ab816c710be7385b31d08373edcdcd71656 Author: Leon Romanovsky Date: Tue Jul 21 18:00:01 2026 +0300 RDMA/mana_ib: drain QP references after partial table insertion [ Upstream commit 97f7c2262c28ebcae64fc957ee978646684a5ed9 ] mana_table_store_ud_qp() publishes a QP at its send-queue id before inserting the receive-queue id, dropping the XArray lock between the two xa_insert_irq() calls. A concurrent completion handler can look up the QP and take a transient reference. When the second insertion fails, the rollback erased only the send-queue entry and returned, leaving both the initial table reference and the transient reference outstanding while RDMA core frees the QP, causing a use-after-free. Drain the reference as normal destruction does: drop the initial reference and wait for qp->free, releasing the QP only after every concurrent lookup returns its reference. Fixes: 8001e9257eca ("RDMA/mana_ib: extend mana QP table") Link: https://patch.msgid.link/20260721-if-mana-table-store-qp-qids-partiall-v1-1-8fb3d2d2b559@nvidia.com Reviewed-by: Konstantin Taranov Reviewed-by: Long Li Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a60c36d8d17f1b86705523d5eb6d290df28831e5 Author: Myeonghun Pak Date: Tue Jul 21 17:25:45 2026 +0900 RDMA/erdma: Fix CEQ tasklet use-after-free on removal [ Upstream commit 0ca79979384f031d710c4b3bae065dcb5d95aca3 ] Each CEQ interrupt handler only schedules eqc->tasklet. The tasklet calls erdma_ceq_completion_handler(), which reads the DMA-coherent EQ ring through get_next_valid_eqe() and updates eq->dbrec through notify_eq(). erdma_ceqs_uninit() frees each CEQ IRQ and then destroys its EQ. free_irq() prevents another hard IRQ and waits for an in-flight handler, but it does not drain a tasklet that the handler already scheduled. The tasklet can therefore access eq->qbuf or eq->dbrec after erdma_eq_destroy() frees them. Clearing ceq_cb->ready does not synchronize with a tasklet that already passed the check at the start of erdma_ceq_completion_handler(). Kill the tasklet after free_irq(), when no handler can schedule it again, and before erdma_ceq_uninit_one() releases the EQ buffers. Fixes: f2a0a630b953 ("RDMA/erdma: Add event queue implementation") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260721082545.47395-1-mhun512@gmail.com Acked-by: Cheng Xu Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 53446b921cdd6c5c9c1938da50601194bb1b86c8 Author: Takuma Fujiwara Date: Tue Jul 21 10:57:43 2026 -0500 PCI: j721e: Fix incorrect max_lanes for J7200 [ Upstream commit 7147a7bfce47acd48c3738130bf0bd692bfd80de ] The PCIe Controller in the J7200 SoC supports a 4-lane configuration. However, j7200_pcie_rc_data and j7200_pcie_ep_data incorrectly set .max_lanes = 2, limiting operation to fewer lanes than the hardware supports. Set .max_lanes = 4 for both j7200_pcie_rc_data and j7200_pcie_ep_data to match the hardware capability. See J7200 Technical Reference Manual (SPRUIU1D), section 12.2.3.1.1 for further details: https://www.ti.com/lit/pdf/spruiu1d Fixes: 3ac7f14084f5 ("PCI: j721e: Add per platform maximum lane settings") Signed-off-by: Takuma Fujiwara Signed-off-by: Manivannan Sadhasivam Reviewed-by: Siddharth Vadapalli Link: https://patch.msgid.link/20260721155743.3347659-1-t-fujiwara1@ti.com Signed-off-by: Sasha Levin commit 8c24bda66dd1cee8423fdb9d75158143b417180d Author: Leon Romanovsky Date: Tue Jul 21 12:10:56 2026 +0300 RDMA/srpt: Pass the mapped task attribute to target_init_cmd() [ Upstream commit ef63cc441703412628a517dda354f3e51fe2dc92 ] srpt_handle_cmd() maps the initiator-supplied srp_cmd->task_attr into cmd->sam_task_attr, but then hands a hardcoded TCM_SIMPLE_TAG to target_init_cmd(). Pass the already mapped cmd->sam_task_attr instead, so target core sees the attribute the initiator requested. Fixes: 9474b043132f ("ib_srpt: Convert I/O path to target_submit_cmd + drop legacy ioctx->kref") Link: https://patch.msgid.link/20260721-b4-scsi-ordering-violation-due-to-hardc-v1-1-07205aab71bb@nvidia.com Reviewed-by: Bart Van Assche Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e42cede6f90177f4f92f80d3de18f628e61d2087 Author: Kumar Kartikeya Dwivedi Date: Sun Jul 19 17:36:30 2026 +0200 bpf: Mark bpf_refcount field as unique [ Upstream commit 61e655391cb19c31f94ecd4354f624c81ce4cf75 ] BPF_REFCOUNT is not marked as a unique field, while it should be. Fix this oversight. Fixes: d54730b50bae ("bpf: Introduce opaque bpf_refcount struct and add btf_record plumbing") Signed-off-by: Kumar Kartikeya Dwivedi Link: https://patch.msgid.link/20260719153634.2908692-4-memxor@gmail.com Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 28d5f20ed022ade0fb0bfbf50b78fec782083175 Author: Kumar Kartikeya Dwivedi Date: Sun Jul 19 17:36:29 2026 +0200 bpf: Preserve unique-field state across nested structs [ Upstream commit f08619f060468076e4acbdc10e0713af20d60e65 ] btf_find_struct_field() initializes a fresh seen mask for every recursive descent. Unique special fields in different levels of the same aggregate therefore do not see one another. The duplicate fields can reach btf_parse_fields(), where they trigger an invariant WARN_ON_ONCE(). A crafted user BTF can consequently trigger the warning before map creation checks capabilities. Initialize the seen mask once in btf_find_field() and pass the same pointer through struct, datasec, and nested-struct walks. This gives the entire field traversal one shared uniqueness state. Fixes: 64e8ee814819 ("bpf: look into the types of the fields of a struct type recursively.") Signed-off-by: Kumar Kartikeya Dwivedi Link: https://patch.msgid.link/20260719153634.2908692-3-memxor@gmail.com Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit dfdce1f20a7e5e826165c556fd3367c65387e966 Author: Kumar Kartikeya Dwivedi Date: Sun Jul 19 17:36:28 2026 +0200 bpf: Fix offset warn check for bpf_res_spin_lock [ Upstream commit 04e19012efaec2bfd8c3b37fd8a6c3f1fe731ffc ] Sashiko pointed out correctly that the case statement for BPF_RES_SPIN_LOCK incorrectly checks offset for BPF_SPIN_LOCK. Fix it by checking res_spin_lock_off instead. Fixes: 0de2046137f9 ("bpf: Implement verifier support for rqspinlock") Signed-off-by: Kumar Kartikeya Dwivedi Link: https://patch.msgid.link/20260719153634.2908692-2-memxor@gmail.com Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 2d2616b4f3728bc422e2fabcd16c7fa892b0febb Author: Kohei Enju Date: Fri Jun 12 20:09:21 2026 +0900 virt: arm-cca-guest: use migrate_disable() for attestation token requests [ Upstream commit 24f55f511b9e1c19dc48d11bfe0dc60c86bdb376 ] The RSI attestation token init and continue calls must be issued from the same CPU. arm_cca_report_new() currently snapshots the CPU number and uses smp_call_function_single() to issue those calls on that CPU. With CONFIG_DEBUG_PREEMPT=y, the smp_processor_id() call used for the snapshot triggers a debug splat [0] because it runs in preemptible context. The snapshot does not pin the task to that CPU; it is only used to choose the target CPU for smp_call_function_single(), which can fail if that CPU is no longer available. Use migrate_disable() and issue the token init and continue operations directly, without the smp_call_function_single() callbacks. This keeps the token request sequence on the same CPU while preserving a sleepable context for the GFP_KERNEL allocations needed after the init call. [0] BUG: using smp_processor_id() in preemptible [00000000] code: cca-workload-at/264 caller is debug_smp_processor_id+0x20/0x30 CPU: 0 UID: 0 PID: 264 Comm: cca-workload-at Not tainted 7.1.0-rc1-00044-g55542ab273f2 #80 PREEMPT(lazy) Hardware name: linux,dummy-virt (DT) Call trace: [...] check_preemption_disabled+0xd8/0xf8 debug_smp_processor_id+0x20/0x30 arm_cca_report_new+0x48/0x278 tsm_report_read+0x154/0x1f8 tsm_report_outblob_read+0x20/0x38 configfs_bin_read_iter+0x118/0x208 vfs_read+0x220/0x318 [...] Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms") Signed-off-by: Kohei Enju Reviewed-by: Suzuki K Poulose Tested-by: Suzuki K Poulose Reviewed-by: Gavin Shan Reviewed-by: Steven Price Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 662f242863fd8cab251a1cc7d1ec795b861c2e5d Author: Rafael J. Wysocki Date: Tue Jul 21 15:16:31 2026 +0200 ACPI: battery: Adjust charging status validation check [ Upstream commit 77ce4be0d8d53c528d1663ab62a14d93d5853f11 ] Commit bb1256e0ddc7 ("ACPI: battery: fix incorrect charging status when current is zero") added a charge rate check to validate the "charging" status of the battery, but that check is reported to cause some systems to misbehave [1]. Namely, it causes the "not charging" status to be reported on them while the battery is in fact charging (and they were correctly reporting the "charging" status in that case previously). To address that, check if the battery is full in addition to checking the charge rate when the "charging" status is reported by the platform firmware and only change it to "not charging" if the battery is full and its charge rate is zero or it is unknown. Fixes: bb1256e0ddc7 ("ACPI: battery: fix incorrect charging status when current is zero") Reported-by: golne tree Tested-by: golne tree Closes: https://lore.kernel.org/linux-acpi/AM9P193MB158895CFE0DDFA62FCD1DA5ED0F22@AM9P193MB1588.EURP193.PROD.OUTLOOK.COM/ [1] Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/6286911.lOV4Wx5bFT@rafael.j.wysocki Signed-off-by: Sasha Levin commit 26d9496c826586338d1b8c27edfec4a19a89f462 Author: Feng Jiang Date: Mon Jul 20 06:42:57 2026 +0000 bpf, riscv: Fix extable handling for arena load_acquire [ Upstream commit 5eb8921371c6fd117d4a328b6053dfda38707df8 ] emit_atomic_ld_st() returns 1 to have build_body() skip the zext after a sub-word load_acquire. The caller does "ret = ret ?: add_exception_handler(...)", which skips add_exception_handler() on any non-zero ret, so the extable entry is missing and a faulting PROBE_ATOMIC load_acquire oopses. REG_DONT_CLEAR_MARKER leaves rd stale on fault, and the verifier still thinks the load overwrote it, so a program can leak it through a map. Check ret >= 0 before calling add_exception_handler(), and pass rd for LOAD_ACQ so the fault zeroes rd like a PROBE_MEM load. Return ret unchanged for the zext skip. Fixes: fb7cefabae81 ("riscv, bpf: Add support arena atomics for RV64") Suggested-by: Pu Lehui Signed-off-by: Feng Jiang Reviewed-by: Pu Lehui Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20260720-bpf-riscv-fix-extable-v4-1-165c0b3b07d5@kylinos.cn Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 34b1bb33a025787e05f966e74de18cd36276f801 Author: Pu Lehui Date: Wed Jul 8 06:44:33 2026 +0000 riscv, bpf: Fix kernel stack corruption in tailcall with CFI [ Upstream commit 52fb1756ea1d2759dfef2d86245be00b05dac3a2 ] When CONFIG_CFI_CLANG is enabled, prog->bpf_func already skips the kcfi instruction during setup. Including it again in the tailcall jump offset causes it to jump over an extra 4 bytes, skipping the stack pointer adjustment, which will result in kernel stack corruption. Fixes: 30a59cc79754 ("riscv, bpf: Fix possible infinite tailcall when CONFIG_CFI_CLANG is enabled") Reported-by: Sashiko Signed-off-by: Pu Lehui Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20260708064436.2971933-5-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 5cadc66b534fe8140441916200a20c7efb06a388 Author: Pu Lehui Date: Wed Jul 8 06:44:31 2026 +0000 riscv, bpf: Fix memory leak in bpf_jit_free [ Upstream commit 369e4635d04801f394d5bd42556f21029e95ff93 ] When bpf_int_jit_compile() is called for subprograms, it returns early during the first pass (!prog->is_func || extra_pass is false), keeping ctx->offset alive for the subsequent extra pass. If JIT compilation fails for a later subprogram, the BPF core aborts and calls bpf_jit_free() to clean up the first subprogram. However, bpf_jit_free() fails to free jit_data->ctx.offset, which causes a memory leak of the JIT context offsets array. Fix this by adding the missing kfree(jit_data->ctx.offset) in bpf_jit_free(). Fixes: 48a8f78c50bd ("bpf, riscv: use prog pack allocator in the BPF JIT") Reported-by: Sashiko Signed-off-by: Pu Lehui Reviewed-by: Björn Töpel Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20260708064436.2971933-3-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit e991c317d4a005f3eb5eb0fd28b7e4a9a488dc0b Author: Ricardo B. Marlière Date: Mon Jul 20 08:13:09 2026 -0300 libbpf: Search /lib64 and /lib in resolve_full_path() [ Upstream commit 7b5ae0481efdac040cea72b4fabd1398109f975b ] attach_probe/uprobe-lib and uprobe_autoattach selftests fail with "failed to resolve full path for libc.so.6" on older non-usrmerged distros, where libc.so.6 lives under a top-level /lib64 or /lib rather than /usr/lib64 or /usr/lib. Add /lib64:/lib to the search paths, alongside the existing /usr/lib64:/usr/lib and Debian multiarch entries. Fixes: 1ce3a60e3c28 ("libbpf: auto-resolve programs/libraries when necessary for uprobes") Signed-off-by: Ricardo B. Marlière Acked-by: Ihor Solodrai Link: https://lore.kernel.org/bpf/20260720-selftests-bpf_fixes-v2-3-b450eda93dfe@suse.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 1534c4bff3aaca19c4c9a82f93e9b81f7c983de3 Author: Kumar Kartikeya Dwivedi Date: Sun Jul 19 14:54:18 2026 +0200 bpf: Zero queue and stack outputs on lock failure [ Upstream commit 7ac6e1ae41a09f1dd4baeeff1d028ae49ee01232 ] Queue and stack pop/peek helpers accept an uninitialized output buffer because the verifier expects the helper to initialize it. The empty-map error path clears the buffer, but a failed lock acquisition returns -EBUSY without writing it. Clear the output before returning -EBUSY so BPF programs cannot observe uninitialized stack contents after a failed helper call. Fixes: a34a9f1a19af ("bpf: Avoid deadlock when using queue and stack maps from NMI") Signed-off-by: Kumar Kartikeya Dwivedi Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/20260719125419.1782196-1-memxor@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 5af710a4f3e3943316f40e86d0d3a5639633ac1f Author: Yousef Alhouseen Date: Wed Jul 1 18:42:04 2026 +0200 platform/x86: acer-wmi: reject missing gaming WMI results [ Upstream commit caf8342512c3056005f475d350eeca089c3c6623 ] WMI_gaming_execute_u32_u64() returns success when firmware supplies no output object, leaving the caller output untouched. Gaming getters then inspect an uninitialized result value. When the caller requests an output value, return -ENOMSG if firmware supplies no object. Preserve a NULL output pointer as the supported way for callers to ignore the result. Fixes: 2d76708c2221 ("platform/x86: acer-wmi: use WMI calls for platform profile handling") Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260701164208.8998-1-alhouseenyousef@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 7ace189b9ea79cf78df9c32b940ce12735f9459a Author: Yun Zhou Date: Tue Jun 23 14:19:02 2026 +0800 ext4: skip extra isize expansion during mount to prevent deadlock [ Upstream commit 7461c60b9c6a839b13ad4c3490681a0cf5aa0637 ] ext4_try_to_expand_extra_isize() is called from __ext4_mark_inode_dirty() while holding an active jbd2 handle. During mount (!SB_ACTIVE), the expand path may move xattrs to external blocks and release ea_inodes via iput(). When !SB_ACTIVE, iput() calls write_inode_now() which acquires s_writepages_rwsem, creating a circular lock dependency: s_writepages_rwsem --> jbd2_handle --> xattr_sem --> s_writepages_rwsem This can be triggered via: ext4_process_orphan() -> ext4_truncate() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() or: ext4_evict_inode() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() Skip expansion when !SB_ACTIVE. This is a minor loss of functionality (extra isize won't grow for these inodes during mount), which e2fsck can resolve later if needed. Reported-by: syzbot+5d19358d7eb30ffb0cc5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5d19358d7eb30ffb0cc5 Fixes: c8585c6fcaf2 ("ext4: fix races between changing inode journal mode and ext4_writepages") Signed-off-by: Yun Zhou Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260623061903.2148767-1-yun.zhou@windriver.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 6702c7da86d8cdb88d0fc57166286e115ffeb8c0 Author: Xiang Mei Date: Mon Jun 15 12:05:19 2026 -0700 ext4: fix out-of-bounds read in ext4_read_inline_dir() [ Upstream commit 9333cc809f0a89e001b814155a6cb8903a6274df ] ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: dir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic "." and ".." land at their block-dir offsets. A dirent is formed at "dir_buf + pos - extra_offset", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer. Fixes: c4d8b0235aa9 ("ext4: fix readdir error in case inline_data+^dir_index.") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260615190519.946736-1-xmei5@asu.edu Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit e4223231b6860141813637a6413c2371ae4d6fa8 Author: Yun Zhou Date: Fri Jun 12 08:53:30 2026 +0800 ext4: fix circular lock dependency in ext4_ext_migrate [ Upstream commit a897682793eba5de51ee6f3152760374afa629cf ] Move iput(tmp_inode) after ext4_writepages_up_write() to avoid a circular lock dependency between s_writepages_rwsem and sb_internal (freeze protection). The deadlock scenario: CPU0 (EXT4_IOC_MIGRATE) CPU1 (orphan cleanup during mount) ---- ---- ext4_ext_migrate() ext4_writepages_down_write() s_writepages_rwsem (write) ext4_evict_inode() sb_start_intwrite() [sb_internal] ... ext4_writepages() s_writepages_rwsem (read) [BLOCKED] iput(tmp_inode) ext4_evict_inode() sb_start_intwrite() [BLOCKED] The tmp_inode is a temporary inode with nlink=0 created solely for building the extent tree. Its eviction does not require s_writepages_rwsem protection, so deferring iput() until after releasing the rwsem is safe. Reported-by: syzbot+212e8f62790f8e0bc63b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=212e8f62790f8e0bc63b Fixes: cb85f4d23f79 ("ext4: fix race between writepages and enabling EXT4_EXTENTS_FL") Signed-off-by: Yun Zhou Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260612005330.1930804-1-yun.zhou@windriver.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 3eee4c21931dc048ce63b86809f04e4e6f0dcad5 Author: Chen Pei Date: Wed Jul 15 21:50:48 2026 +0800 ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root [ Upstream commit 8a742141f7ab84975aa758b775567ef4740ef0cf ] acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed. Fixes: db89b4f0dbab ("ACPI: catch calls of acpi_driver_data on pointer of wrong type") Reported-by: Sashiko AI review Link: https://sashiko.dev/#/patchset/20260526025118.38935-1-cp0613@linux.alibaba.com Link: https://sashiko.dev/#/patchset/20260707121258.11640-1-cp0613@linux.alibaba.com Signed-off-by: Chen Pei Link: https://patch.msgid.link/20260715135048.3278-1-cp0613@linux.alibaba.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4d8ecaa332c163f2b44aa5027bf061950b71b5f3 Author: Pengpeng Hou Date: Wed Jul 15 16:32:53 2026 +0800 ACPI: processor: validate MADT IOAPIC entry bounds [ Upstream commit 2c50ffdc73f3a70d745d249f509fc290754121e6 ] The IOAPIC hotplug lookup parses both MADT and _MAT records directly. The MADT walk previously used a subtable's declared length to advance the cursor after only locating a generic header. The _MAT path likewise passed a generic header to the IOAPIC helper. Validate that a current record has a complete generic header, that its declared length is contained in the available record range, and that a typed IOAPIC record contains the full fixed IOAPIC body before reading its fields. Use the same relation for both MADT and _MAT provider paths. Fixes: ecf5636dcd59 ("ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260715083253.22831-1-pengpeng@iscas.ac.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 87735eb21d7e512f298c080dc7644442ab2d3a4c Author: Zhu Ling Date: Wed Jul 15 09:25:19 2026 +0800 ACPI: EC: Avoid _REG disconnect on GPIO IRQ defer [ Upstream commit e71bdbce27dcaa7f467a3a198cbe723924f05569 ] EC event delivery uses either a GPE or, on ACPI reduced hardware platforms, a GpioInt resource. The GPE path does not have a provider lookup that can defer, but acpi_dev_gpio_irq_get() can return -EPROBE_DEFER for the GpioInt path. ec_install_handlers() currently installs the EC address space handler and executes _REG before looking up the GPIO IRQ. If the GPIO lookup then defers, acpi_ec_setup() tears the handlers down again. Removing the EC address space handler causes ACPICA to execute _REG for disconnect, so firmware may observe an EC OpRegion connected -> disconnected transition during one failed probe attempt. This is observable when the namespace EC reuses a boot EC that has already installed the EC address space handler. A deferred namespace EC probe can disconnect the already usable boot EC OpRegion until a later reprobe connects it again. AML that gates EC field accesses on _REG state can then return fallback values to other drivers during that window. Prepare the GPIOInt IRQ before publishing EC OpRegion availability to AML. This leaves the GPE path unchanged, keeps non-deferred GPIO lookup errors non-fatal as before, and still lets the existing acpi_ec_setup() error path clean up real handler installation failures. Fixes: f6484cadbcaf ("ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()") Signed-off-by: Zhu Ling [ rjw: Added an empty code line after a conditional ] Link: https://patch.msgid.link/20260715012556.12043-1-zhuling2709@phytium.com.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 0bfa897e3e1a61d172f95675b353168bc9290312 Author: Pengpeng Hou Date: Mon Jul 20 19:49:18 2026 +0800 RDMA/nldev: validate dynamic counter attribute length [ Upstream commit 74f49255492a62658f36bf2578d7916f1c6ffad1 ] RDMA_NLDEV_ATTR_STAT_HWCOUNTERS is a nested attribute whose children are consumed directly with nla_get_u32(). The top-level policy validates only the container, so it does not establish the fixed shape of each child. Require every child payload to be exactly one u32 before reading it. Fixes: 3c3c1f141639 ("RDMA/nldev: Allow optional-counter status configuration through RDMA netlink") Reviewed-by: Zhu Yanjun Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260720114918.70323-1-pengpeng@iscas.ac.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6eb1f1414bf70185dad2525ecac5411db551faa2 Author: Kemeng Shi Date: Tue Jul 21 14:32:40 2026 +0800 irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc() [ Upstream commit 325ff3e78c64cd619d52b99f7c8b09a3f31e1495 ] When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ] Fixes: 7d75bbb4bc1ad ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Kemeng Shi Signed-off-by: Thomas Gleixner Acked-by: Marc Zyngier Link: https://patch.msgid.link/20260721063241.52549-2-shikemeng@huaweicloud.com Signed-off-by: Sasha Levin commit 93290f29be8f985eb0cd705467c4c50355c3f2a0 Author: Viktor Malik Date: Wed Jul 15 13:22:02 2026 +0200 selftests/bpf: Silence array bounds warning in global_map_resize [ Upstream commit dcd164ec67f89e0db5ee025ee9e91280052eb737 ] When compiling BPF selftests with -O2, GCC reports an array bounds violation warning in global_map_resize test: In function ‘global_map_resize_bss_subtest’, inlined from ‘test_global_map_resize’ at /bpf-next/tools/testing/selftests/bpf/prog_tests/global_map_resize.c:228:3: /bpf-next/tools/testing/selftests/bpf/prog_tests/global_map_resize.c:64:33: error: array subscript 1 is above array bounds of ‘int[1]’ [-Werror=array-bounds=] 64 | skel->bss->array[i] = 1; | ~~~~~~~~~~~~~~~~^~~ In file included from /bpf-next/tools/testing/selftests/bpf/prog_tests/global_map_resize.c:6: ./test_global_map_resize.skel.h: In function ‘test_global_map_resize’: ./test_global_map_resize.skel.h:44:21: note: while referencing ‘array’ 44 | int array[1]; | ^~~~~ This is a false positive because `array` (a BPF map) has been resized from within the BPF program. GCC doesn't know that so let us silence the warning by accessing the array via a plain pointer. Fixes: 08b089567573 ("libbpf: Selftests for resizing datasec maps") Signed-off-by: Viktor Malik Link: https://lore.kernel.org/bpf/57765bc465a27923c3c093eba222cc24d08d8c40.1784112948.git.vmalik@redhat.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 03cf3a1d950f4511be8374cca3b8a0294bbf1b20 Author: Viktor Malik Date: Wed Jul 15 13:22:01 2026 +0200 selftests/bpf: Check malloc result with ASSERT_NEQ in test_sha256 [ Upstream commit eb5cd154f174f42079a45f4bd7ee8bc20f2ba6f3 ] Replace ASSERT_OK_PTR by ASSERT_NEQ(res, NULL, ...) when checking the result of malloc. It is more accurate since malloc returns NULL, not an error code, on failure and it also prevents the following false GCC warning when compiling BPF selftests with -O2: In file included from /bpf-next/tools/testing/selftests/bpf/prog_tests/sha256.c:4: /bpf-next/tools/testing/selftests/bpf/prog_tests/sha256.c: In function ‘test_sha256’: ./test_progs.h:393:22: error: ‘data’ may be used uninitialized [-Werror=maybe-uninitialized] 393 | int ___err = libbpf_get_error(___res); \ | ^~~~~~~~~~~~~~~~~~~~~~~~ /bpf-next/tools/testing/selftests/bpf/prog_tests/sha256.c:28:14: note: in expansion of macro ‘ASSERT_OK_PTR’ 28 | if (!ASSERT_OK_PTR(data, "malloc")) | ^~~~~~~~~~~~~ In file included from /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/bpf.h:32, from ./test_progs.h:37: /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/libbpf_legacy.h:113:17: note: by argument 1 of type ‘const void *’ to ‘libbpf_get_error’ declared here 113 | LIBBPF_API long libbpf_get_error(const void *ptr); | ^~~~~~~~~~~~~~~~ Fixes: f09f57c74677 ("selftests/bpf: Add test for libbpf_sha256()") Signed-off-by: Viktor Malik Link: https://lore.kernel.org/bpf/f9dec09cca0c2aa5eeb4fdcd400a13aa19e2c073.1784112948.git.vmalik@redhat.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 86ce84cf93d2c187abda8871b31c6e2a92c79596 Author: Pawan Gupta Date: Wed Jul 8 11:40:14 2026 -0700 x86/bugs: Don't use cpu-type matching in cpu_vuln_blacklist [ Upstream commit a4c714fe9746bf5a434bb798b26ebba278b798c1 ] Thomas Gleixner pointed out that cpu-type is a per-CPU property while hybrid is a system property; conflating the two in the CPU matching infrastructure is wrong. Currently, on a hybrid system x86_match_cpu() matches any cpu-type. This works if the intent is to find the possibility of a cpu-type in a system. But fails if matching for the cpu-type of a given CPU. Borislav posted a cleanup here: https://lore.kernel.org/all/20260703193222.GFakgORjvxwnZTPRnI@fat_crate.local To make way for the cleanup stop matching cpu-type in cpu_vuln_blacklist. RFDS is the only user, so drop the VULNBL_INTEL_TYPE entries and fold their RFDS bit into the base Alder Lake (0x97) and Raptor Lake (0xB7) blacklist entries. For now open-code cpu-type check in vulnerable_to_rfds(). In the future, if more vulnerabilities need cpu-type matching a helper can be added. No functional change intended. Fixes: 722fa0dba74f ("x86/rfds: Exclude P-only parts from the RFDS affected list") Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov (AMD) Link: https://patch.msgid.link/20260708-cpu-type-vuln-v1-1-85c1d3c704db@linux.intel.com Signed-off-by: Sasha Levin commit 1654875005c7b6d5c98c81025aa801e6368694b9 Author: Frank Li Date: Thu Jul 9 16:29:46 2026 -0400 arm64: dts: imx8-ss-audio: Fix LPCG clock indices for ASRC0 [ Upstream commit 8563591f76ca02c1a6fd70ce986df1d0dde8d249 ] The LPCG clock indices for ASRC0 and AUD_PLL_DIV0 are swapped. The ASRC0 LPCG provides only IMX_LPCG_CLK_4, so update the ASRC0 clock consumer to use IMX_LPCG_CLK_4 instead of the non-existent IMX_LPCG_CLK_0. Likewise, the AUD_PLL_DIV0 LPCG provides only IMX_LPCG_CLK_0, so update its clock consumer to use IMX_LPCG_CLK_0 instead of the non-existent IMX_LPCG_CLK_4. Fixes: 5125617c7a4d3 ("arm64: dts: imx8qxp: add asrc[0,1], esai0, spdif0 and sai[4,5]") Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 18b1deba715462a1e7cb466848d1a417391d4917 Author: Marco Elver Date: Mon Jul 20 18:08:22 2026 +0200 kcsan: avoid unintended access checking in NMIs [ Upstream commit a8488ecbd7ba44d65b912dfe88a73f438eba2447 ] If a watcher deliberately disables interrupts (either by user choice, or because we're dealing with a scoped reordered access) to avoid detecting any data races in interrupts, NMIs are still able to fire. When we set up a watchpoint on a scoped reordered access, we disabled interrupts because the same CPU cannot observe reordering of its own accesses. To ensure we observe no false positives from NMIs, disable access checking for interrupt contexts as well. Fixes: 69562e4983d9 ("kcsan: Add core support for a subset of weak memory modeling") Signed-off-by: Marco Elver Signed-off-by: Sasha Levin commit af073bd245180393bcb15d33d3990a6bdc32593a Author: TanZheng Date: Wed Jul 15 18:15:50 2026 +0800 RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters [ Upstream commit b38f98e176050850f41bb6415f3a71400056623e ] When srpt_alloc_rw_ctxs() fails partway through a multi-buffer indirect descriptor, the unwind path destroys RDMA contexts but leaves stale n_rw_ctx and n_rdma values (and a dangling rw_ctxs pointer). Later sq_wr_avail accounting in srpt_queue_response() or srpt_write_pending() can then subtract the wrong number of send queue credits. Reset the counters and clear rw_ctxs after freeing the heap allocation before returning an error. Fixes: b99f8e4d7bcd ("IB/srpt: convert to the generic RDMA READ/WRITE API") Signed-off-by: TanZheng Link: https://patch.msgid.link/20260715101550.45345-1-kensanya@163.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 13cb7160e5b791f5e3ecf9311cf32849fe7e9b62 Author: Ibrahim Hashimov Date: Sun Jul 12 14:21:49 2026 +0200 RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[] [ Upstream commit 126c757e4cd46f866ddc283143b58eb4d9bf52cd ] For a user QP, qp->sq.queue is a ring the application writes directly, so rxe_post_send() takes the is_user branch and only schedules send_task without validating the WQE. rxe_requester() consumes it in place via req_next_wqe() and calls copy_data(), which indexes &wqe->dma.sge[cur_sge] with the attacker-controlled num_sge/cur_sge. Only the kernel path bounds num_sge (validate_send_wr()); the user WQE is never checked, so a local unprivileged user can post a WQE with an out-of-range cur_sge or oversized num_sge and force an out-of-bounds read of the per-WQE sge array in copy_data() (vmalloc OOB read, local DoS). Bound num_sge to qp->sq.max_sge in rxe_requester() before use, the way get_srq_wqe() already guards SRQ entries, and bound cur_sge only when the WQE carries payload (dma.resid): copy_data() returns early on a zero-length copy before touching dma->sge[], so a zero-payload WQE -- the only kind a max_sge == 0 QP can post -- stays valid. Reproduced under KASAN; the vmalloc-out-of-bounds in copy_data() is gone. Fixes: 8700e3e7c485 ("Soft RoCE driver") Reviewed-by: Zhu Yanjun Signed-off-by: Ibrahim Hashimov Link: https://patch.msgid.link/20260712122149.78142-1-security@auditcode.ai Assisted-by: AuditCode-AI:2026.07 Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 3416db552eb378e54cb2f2ce0db5f0df88654bda Author: Danila Chernetsov Date: Wed Jul 8 16:22:52 2026 +0000 RDMA/hfi1: Propagate sdma_txinit_ahg() errors [ Upstream commit 091c6162c022cbdfb64219708a71728cfd1d4600 ] set_txreq_header_ahg() ignores the return value of sdma_txinit_ahg(). If sdma_txinit_ahg() fails, it returns before initializing tx->txreq. However, set_txreq_header_ahg() ignores the error and returns the AHG change count, causing the caller to continue processing the request as though initialization had succeeded. Propagate sdma_txinit_ahg() failures to the caller and abort request processing when initialization fails. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e3304b7cc4f1 ("IB/hfi1: Optimize cachelines for user SDMA request structure") Signed-off-by: Danila Chernetsov Link: https://patch.msgid.link/20260708162252.936634-1-listdansp@mail.ru Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e166856d4ef2d85ab0f5f678c3f191246b5fa7b2 Author: Jun Yan Date: Wed Jun 24 21:56:44 2026 +0800 arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for PCIe [ Upstream commit 7f1d0cc86cb70fa550163b6f70fd1d484c03218e ] The PCIe PHY node references mipi_pcie_analog_dphy via its phys property. Enable this analog PHY node to make PCIe functionally viable. Fixes: 9715b01da6cf ("arm64: dts: meson-axg-s400: enable PCIe M.2 Key E slots") Signed-off-by: Jun Yan Reviewed-by: Martin Blumenstingl Link: https://patch.msgid.link/20260624135650.727077-5-jerrysteve1101@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 0da7e87b3044d148f8b9b5b1e3a50f178171cbae Author: Jun Yan Date: Wed Jun 24 21:56:42 2026 +0800 arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins [ Upstream commit 45eb76f9ab6854f79690d56d04df227429a536b8 ] The nand_all_pins pinctrl node was missing the nand_rb0 (ready/busy) pin description, which is required for NAND controller operation. Add it to the pinmux list. Fixes: be18d53c32b2 ("arm64: dts: amlogic: meson-axg: pinctrl node for NAND") Signed-off-by: Jun Yan Reviewed-by: Martin Blumenstingl Link: https://patch.msgid.link/20260624135650.727077-3-jerrysteve1101@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 624ddc40f2185e28367f00791f9e1078d45ade47 Author: Can Peng Date: Sat Jul 18 17:00:54 2026 +0800 phy: starfive: Fix runtime PM cleanup in JH7110 DPHY RX probe [ Upstream commit 97bed336f6a25c9d1115ca95e3aa00e05c3bc271 ] stf_dphy_probe() enables runtime PM before registering the PHY provider. If devm_of_phy_provider_register() fails, probe returns with runtime PM still enabled. The driver also has no remove callback, so runtime PM is left enabled on driver unbind after a successful probe. Use devm_pm_runtime_enable() so runtime PM is disabled automatically on later probe failures and on driver unbind. Fixes: f8aa660841bc ("phy: starfive: Add mipi dphy rx support") Signed-off-by: Can Peng Reviewed-by: Changhuang Liang Link: https://patch.msgid.link/20260718090054.444513-3-pengcan@kylinos.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 41cacaa222b0d8502e17c746187f55bcfbb622e0 Author: Can Peng Date: Sat Jul 18 17:00:53 2026 +0800 phy: starfive: Fix runtime PM cleanup in JH7110 DPHY TX probe [ Upstream commit f40b0241f3a382e99c14de2f28f14a44973407c1 ] stf_dphy_probe() enables runtime PM before getting the clock and reset controls, creating the PHY and registering the PHY provider. If any of those steps fails, probe returns with runtime PM still enabled. The driver also has no remove callback, so runtime PM is left enabled on driver unbind after a successful probe. Use devm_pm_runtime_enable() so runtime PM is disabled automatically on later probe failures and on driver unbind. Fixes: d3ab79553308 ("phy: starfive: Add mipi dphy tx support") Signed-off-by: Can Peng Reviewed-by: Changhuang Liang Link: https://patch.msgid.link/20260718090054.444513-2-pengcan@kylinos.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8fec16898f184e5f8f8fdd09ff1ced2bd7ffc13d Author: Linmao Li Date: Fri Jul 17 09:24:33 2026 +0800 ASoC: meson: Keep link pointers valid on realloc failure [ Upstream commit 2aaa41cf974f83a6fb105422bac4e2f107150774 ] meson_card_reallocate_links() grows the DAI link and private data arrays with two consecutive krealloc() calls and updates the owner pointers only after both calls have succeeded. A successful krealloc() may move the data: it frees the old block and returns a new one. When that happens for the link array and the second krealloc() then fails, card->dai_link still points to the block that krealloc() already freed, and the error path frees the new block too. The probe error path then calls meson_card_clean_references(), which dereferences card->dai_link and kfree()s it again, resulting in a use-after-free and a double free. Commit card->dai_link and card->num_links right after the first krealloc() succeeds, so the pointer always refers to a valid allocation that meson_card_clean_references() can walk and free. krealloc() with __GFP_ZERO zero-initializes the added entries, so walking them on the error path is safe. With both failure paths reduced to a plain return, drop the goto labels and the error message. Fixes: 7864a79f37b5 ("ASoC: meson: add axg sound card support") Signed-off-by: Linmao Li Reviewed-by: Jerome Brunet Link: https://patch.msgid.link/20260717012433.1432285-1-lilinmao@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 20b92646ee0306ba86d34b261cf30a07e7ee7e9e Author: Koichiro Den Date: Sat Jul 18 03:06:36 2026 +0900 dmaengine: dw-edma: Clear stale requests on termination [ Upstream commit c0d9c6275adcca7c0ca5f4270bf88026f9864bd1 ] terminate_all() can finish immediately when the channel is unconfigured, paused, idle, or already stopped in hardware. A pending PAUSE request can survive these paths and block issue_pending() even after termination. Clear the request whenever termination leaves the channel idle. A running channel keeps its STOP request until the interrupt handler consumes it. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-7-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit fe0ffa0190e862ed71e8c1a476090f648c9cb7d9 Author: Koichiro Den Date: Sat Jul 18 03:06:35 2026 +0900 dmaengine: dw-edma: Serialize channel state checks [ Upstream commit f7d1619f3e10c619b62c6cd6d95371b5c526c85a ] pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent. For example, pause() can observe EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-6-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 0c3294066c36d5980fd9c8192dcb53bb9ccd1f7b Author: Koichiro Den Date: Sat Jul 18 03:06:33 2026 +0900 dmaengine: dw-edma: Serialize abort state updates [ Upstream commit dd80e259f65d932634e26d366570d71669ef6654 ] dw_edma_abort_interrupt() drops vc.lock before changing request and status. issue_pending() can acquire the lock in that small window, observe the old busy state, and skip starting queued descriptors. Then the abort handler overwrites the channel status as idle, leaving the new descriptors stranded for good. Keep descriptor completion and the state transition in the same critical section. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-4-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit be87d86537de7ea6fd025f41033d2faff880973f Author: Koichiro Den Date: Sat Jul 18 03:06:32 2026 +0900 dmaengine: dw-edma: Terminate all descriptors without callbacks [ Upstream commit 99109a51efd28c9a661fbfb9469b023c517b31d1 ] The DMA Engine client documentation says in the "Terminate APIs" section of Documentation/driver-api/dmaengine/client.rst: "No callback functions will be called for any incomplete transfers." dw-edma instead calls vchan_cookie_complete() when a deferred STOP reaches the interrupt handler. This schedules a callback for the active descriptor and leaves other issued or submitted descriptors queued. A late callback after dmaengine_terminate_sync() can dereference client state that has already been freed, while leftover descriptors may later restart into reused buffers or leak. Move all issued and submitted descriptors to the terminated list whenever termination completes. For a pending STOP, do this from both the DONE and ABORT paths. Complete their cookies in order without scheduling callbacks. A STOP can remain pending until the running transfer raises an interrupt. Make device_synchronize() wait for such a pending STOP to complete before releasing terminated descriptors. Reuse it from free_chan_resources(), then release the remaining virt-dma resources. Sleep instead of busy-polling while waiting, and warn if the existing timeout expires. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-3-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a968dffa5ab3c74d2ebb3a6233bf8b843f0bfc20 Author: Yiyang Chen Date: Fri Jul 17 12:53:47 2026 +0000 bpf: Reject arena frees below the arena base [ Upstream commit b5a71cb2db6d84ac0042549dcec266b18429d41e ] bpf_arena_free_pages() accepts scalar arena addresses. The runtime masks the address to the low 32 bits and reconstructs a full user address from the arena base before returning the range to the arena free tree. When the scalar value is below the low 32 bits of the arena base, full_uaddr falls below user_vm_start. The existing upper-end clipping then turns this into an out-of-range free-tree offset. A later allocation can reuse that offset and return an address below the arena mapping. Reject such frees before computing the clipped range. Fixes: 317460317a02a ("bpf: Introduce bpf_arena.") Signed-off-by: Yiyang Chen Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/20260717-c10-031-public-bpf-next-v2-b4-v2-1-54b555443a7c@mails.tsinghua.edu.cn Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 122ad34f72583d7a8127ae23bded404e4839523b Author: Puranam V G Tejaswi Date: Sat Jul 18 02:11:26 2026 +0530 drm/msm/a6xx: Fix RBBM_CLOCK_CNTL3_TP0 value in a730_hwcg [ Upstream commit 01bcc0398f43099acb407a6067481e635c3e1b84 ] The RBBM_CLOCK_CNTL3_TP0 entry in a730_hwcg has bits[19:16] set to 2 (clock gating enabled for that TP0 stage). As per the latest recommendation, clear this nibble to disable clock gating for this particular stage. Fixes: 9588d2f860a4 ("drm/msm/a6xx: Add A730 support") Signed-off-by: Puranam V G Tejaswi Reviewed-by: Konrad Dybcio Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/740955/ Message-ID: <20260718-eliza-gpu-v2-1-64379dbebd7a@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 333246218efd55c75196414c642c94536f7eb0a3 Author: Yuho Choi Date: Mon Jun 15 14:07:46 2026 -0400 driver core: soc: Unregister bus on early device registration failure [ Upstream commit 45dfa004893dfeae182ec27eddbd153c6d4ddbf9 ] soc_bus_register() registers the SoC bus before registering a deferred early SoC device. If soc_device_register() fails in that path, the function returns the error directly and leaves the bus registered. Store the returned SoC device pointer explicitly so the success and error cases are handled separately. On failure, clear soc_bus_registered and unregister the bus before returning the error. Fixes: 6e12db376b60 ("base: soc: Allow early registration of a single SoC device") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260615180746.713540-1-dbgh9129@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit df5466412b362db7adfa78e3e092fe07ac6769a4 Author: Alban Bedel Date: Thu Jun 11 18:40:05 2026 +0200 software node: Fix software_node_get_reference_args() with index -1 [ Upstream commit ba3dedcf3bd47017307595a7e54924198f018246 ] The bounds check for the index passed to software_node_get_reference_args() was failing when passed UINT_MAX, this in turn would lead to an out of bound access in the property array. Fix the bound check to also cover the UINT_MAX case. Fixes: 31e4e12e0e960 ("software node: Correct a OOB check in software_node_get_reference_args()") Reported-by: Sashiko Closes: https://lore.kernel.org/linux-devicetree/20260611103904.7CB131F00893@smtp.kernel.org/ Signed-off-by: Alban Bedel Link: https://patch.msgid.link/20260611164005.2930205-1-alban.bedel@lht.dlh.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 13a234359ca8d3df879262f5b666b87d8481a73d Author: Ian Rogers Date: Thu Jul 16 00:23:43 2026 -0700 perf ui hists: Fix uninitialized stack memory free on pstack allocation failure [ Upstream commit d5fdde1c426922efabe86a515f0782b3eba40577 ] Fixes heap corruption by initializing the options and actions arrays before the pstack allocation check, preventing an uninitialized stack pointer from being passed to free_popup_options() if the allocation fails. Reported-by: sashiko-bot Closes: https://lore.kernel.org/linux-perf-users/20260709035230.6DBEE1F000E9@smtp.kernel.org/ Fixes: f2b487db45f2 ("perf hists browser: Fix possible memory leak") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Ian Rogers Link: https://lore.kernel.org/linux-perf-users/20260709035230.6DBEE1F000E9@smtp.kernel.org/ Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 398aca2f90122d5abbabff1079deaeb885fe9e40 Author: zhouminqiang Date: Thu Jul 16 21:14:32 2026 +0800 mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() [ Upstream commit b759d5bb6265419344ee9729fd0dc07ad85719d8 ] mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior. Commit 5daa7b21496a ("mtd: prepare partition add and del functions for ioctl requests") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e ("mtd: add a flags for partitions which should just leave smth. after them") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value. With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers: WARN_ON((!mtd->erasesize || !master->_erase) && !(mtd->flags & MTD_NO_ERASE)) in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the "out of reach" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error. Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK. Fixes: 1a31368bf92e ("mtd: add a flags for partitions which should just leave smth. after them") Signed-off-by: zhouminqiang Reviewed-by: Zhihao Cheng Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 5c349c533e72af2313c3be0f80a24d7407fa4777 Author: Ruoyu Wang Date: Wed Jul 8 22:33:55 2026 +0800 mtd: mtdswap: Avoid freeing registered blktrans device twice [ Upstream commit 779aa4c66a96bf43d2d62982ea1a9096a9128d87 ] In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice. add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev. The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: e8e3edb95ce6 ("mtd: create per-device and module-scope debugfs entries") Signed-off-by: Ruoyu Wang Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit b63058bd5e1be9ccbb366c96d3d36dade59748cb Author: Guangshuo Li Date: Sun Jul 5 11:31:07 2026 +0800 mtd: intel-dg: Fix runtime PM error path in probe [ Upstream commit df6f582df3377af316a60ca8ee0d590b2d03924d ] intel_dg_mtd_probe() allocates region names before enabling runtime PM and before calling pm_runtime_resume_and_get(). If kasprintf() fails while building a region name, the error path jumps to err, which calls pm_runtime_put(). At that point there has not been a successful pm_runtime_resume_and_get() call to balance, so the runtime PM usage count can underflow. Jump to err_norpm from the kasprintf() failure path, as the runtime PM reference has not been acquired yet. Fixes: 779c59274d03 ("mtd: intel-dg: Fix accessing regions before setting nregions") Signed-off-by: Guangshuo Li Reviewed-by: Raag Jadav Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 31f3f496da280d14a98123b7d4906937128dd663 Author: Alexander Usyskin Date: Thu Oct 23 15:21:03 2025 +0300 mtd: intel-dg: wake card on operations [ Upstream commit 3e9c49d4c3063dcf7ddcdea4c5e3aa21eae359d0 ] The Intel DG cards do not have separate power control for persistent memory. The memory is available when the whole card is awake. Enable runtime PM in mtd driver to notify parent graphics driver that whole card should be kept awake while nvm operations are performed through this driver. Signed-off-by: Alexander Usyskin Signed-off-by: Miquel Raynal Stable-dep-of: df6f582df337 ("mtd: intel-dg: Fix runtime PM error path in probe") Signed-off-by: Sasha Levin commit 533d0c5feef85ee6404b9f41d5564fac6971a008 Author: Xiang Mei Date: Sat Jul 4 18:40:10 2026 -0700 vfio/pci: clear vdev->msi_perm after freeing it on init failure [ Upstream commit dc77acfeb979dded39b247b60fef0399536bfa77 ] vfio_msi_cap_len() lazily allocates the per-device MSI permission table: vdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); if (!vdev->msi_perm) return -ENOMEM; ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); if (ret) { kfree(vdev->msi_perm); return ret; /* vdev->msi_perm left dangling */ } When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at "if (vdev->msi_perm) return len;" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception Fixes: 30ea32ab1951 ("vfio/pci: Fix potential memory leak in vfio_msi_cap_len") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Link: https://lore.kernel.org/r/20260705014010.1297885-1-xmei5@asu.edu Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 21d576fc7e2989a6eb33fba245ac353f0ccedb35 Author: Myeonghun Pak Date: Tue Jun 23 17:55:55 2026 +0900 char: xilinx_hwicap: unregister class on init errors [ Upstream commit e7e12b4cc0f0c3a2782aea084d4215e23f5512b3 ] hwicap_module_init() registers icap_class before reserving the character-device region and registering the platform driver. If either of those later steps fails, the init path must undo the successful class registration before returning an error. Route the chrdev registration failure through a class unwind label, and let the platform-driver registration failure fall through the existing chrdev unwind before unregistering the class. The normal module exit path is unchanged. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: ef141a0bb0dc ("[POWERPC] Xilinx: hwicap driver") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260623085604.89284-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1a3258e105f711538201bdd2ac2a05b11554eabc Author: Pei Xiao Date: Wed Jul 1 10:01:09 2026 +0800 ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup on remove [ Upstream commit b6b5d64cb161a28347d64dc3168a636c4abb68d5 ] Three issues arise when the device is removed while a tty session is still active: 1. UAF of struct ipoctal: the remove callback frees ipoctal via kfree() while tty ops may still access it. Fix by introducing kref-based lifetime management — kref is taken in install() when a tty is opened and released in cleanup() when the tty is finally destroyed; remove() uses kref_put() instead of kfree(). 2. NULL dereference in ipoctal_write_tty(): __ipoctal_remove() frees xmit_buf via tty_port_free_xmit_buf() while a userspace process may still hold the tty fd and call write(). Fix by checking for NULL xmit_buf in ipoctal_write_tty(). 3. UAF in ipoctal_cleanup(): ipack_put_carrier(ipoctal->dev) dereferences ipoctal->dev after the ipack_device has been freed by ipack_device_del(). Fix by caching ipoctal->carrier_owner during probe() and calling module_put() on the cached pointer directly in cleanup(), avoiding any access to ipoctal->dev. Also introduce a "removed" flag in struct ipoctal, set at the start of __ipoctal_remove(), and checked in every tty op that accesses hardware resources (port_activate, write_tty, set_termios, hangup, shutdown). This prevents page faults when devm_ioremap() regions are unmapped after remove() returns. Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/lkml/178144969601.60470.1257088106279546587@gmail.com/ Fixes: 05e5027efc9c ("Staging: ipack: move out of staging") Signed-off-by: Pei Xiao Link: https://patch.msgid.link/e3b0a90b07f079c5bcd5ca90d1dd3b79bb29adb5.1782870760.git.xiaopei01@kylinos.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 29df4ee11433cff365ff2e36dcbd3b9e085fd69b Author: Linmao Li Date: Thu Jul 16 09:39:23 2026 +0800 ppdev: prevent overflow when setting port timeout [ Upstream commit 3c0cf801ea2fa40daa5e7d1e6d32adca5ff75ad9 ] PPSETTIME64 supplies the timeval fields as s64 values, but pp_set_timeout() narrows tv_usec to int and calculates tv_sec * HZ in a signed long. Large positive values can therefore be truncated or overflow and install an unintended timeout. Keep both fields as s64, reject a non-canonical microsecond value, and use timespec64_to_jiffies() to cap excessively large timeouts at MAX_JIFFY_OFFSET. This is a behavior change because both PPSETTIME ioctls could previously accept values with tv_usec >= USEC_PER_SEC. The validation follows the precedent set by sock_set_timeout(). Fixes: 3b9ab374a1e6 ("ppdev: convert to y2038 safe") Signed-off-by: Linmao Li Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20260716013923.19494-1-lilinmao@kylinos.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e4a7ace58941ea7178c99e12d349169684890e7d Author: Breno Leitao Date: Thu Jun 11 04:55:13 2026 -0700 cacheinfo: don't propagate DT/ACPI error when arch supplies info (arm64) [ Upstream commit 274259391c14166fcabae74f9fc0104223ff27a1 ] cache_setup_properties() sets use_arch_info = true when DT/ACPI provide no cache nodes and the arch can derive the topology from CPU registers (e.g. arm64 reading CLIDR_EL1), but still returns the original -ENOENT. cache_shared_cpu_map_setup() bails on that error before the new flag can take effect, so the first CPU brought online always trips a misleading warning: cacheinfo: Unable to detect cache hierarchy for CPU 0 Subsequent CPUs skip cache_setup_properties() entirely because use_arch_info is now true, which is why only CPU0 hits it. This is reproducible on arm64 with the QEMU 'virt' machine, whose default DT has no cache nodes. Clear ret after setting use_arch_info so the caller proceeds and populates the shared cpu map via the arch-supplied leaves. Fixes: ef9f643a9f8b ("cacheinfo: Add use_arch[|_cache]_info field/function") Reviewed-by: Pierre Gondois Signed-off-by: Breno Leitao Reviewed-by: Sudeep Holla Link: https://patch.msgid.link/20260611-cacheinfo-v2-1-6069ef066cf3@debian.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 98bb638f583db8e0fb9f98bb67a51fe648d0b5d8 Author: Pengpeng Hou Date: Tue Jun 23 09:52:48 2026 +0800 misc: lan966x_pci: depopulate children on populate failure [ Upstream commit f6e2ed54db95286d9512b1cff38264e2f6299814 ] lan966x_pci_probe() applies a device-tree overlay and then populates platform children from the overlaid node. If of_platform_default_populate() creates some children and then fails, the current error path only unloads the overlay. Depopulate the children before unloading the overlay on that failure path, matching the remove path order. Fixes: 185686beb464 ("misc: Add support for LAN966x PCI device") Reviewed-by: Herve Codina Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260623015248.22721-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c7ff7a70f405a3c6fde39ed00a36d9f4fecaf3ab Author: Pengpeng Hou Date: Tue Jun 23 09:56:43 2026 +0800 misc: ad525x_dpot: use driver core groups for sysfs files [ Upstream commit e3a8557e88eb26278eda60bf64f2ef33ce7de8bf ] ad_dpot_probe() creates per-RDAC sysfs files manually and then optionally creates the command sysfs group. This leaves probe responsible for rolling back partial sysfs state and makes remove responsible for matching every file that probe created. Move the device attributes into driver core dev_groups for the I2C and SPI drivers and use an is_visible() callback to expose only the attributes supported by the probed device. With this shape, the driver core creates the sysfs files only after probe succeeds and removes them before the remove callback frees the driver data. Fixes: 4eb174bee6f8 ("ad525x_dpot: new driver for AD525x digital potentiometers") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260623015643.36508-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c8b85cad0fa49fd3b5a913efd8478c434ee926ed Author: Gleb Markov Date: Mon Jun 29 16:09:18 2026 +0300 misc: rtsx: add missing write register handling [ Upstream commit 655faba1ccf195e22a7a83146ef6015e3271233c ] If an error occurs at the stage of working with registers in conjunction with MCU_Block, it will not be processed. The occurrence of errors at this stage may signal an impact on writes to the device's PCI registers and is a more global problem than a driver-level security problem, but adding a handler would be a good practice. Add a missing error handling. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: c0e5f4e73a71 ("misc: rtsx: Add support for RTS5261") Signed-off-by: Gleb Markov Link: https://patch.msgid.link/20260629130920.1260-1-markov.gi@npc-ksb.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a45d6dd3c11e921882a2e74c7c8710b975f2eaa7 Author: Gui-Dong Han Date: Wed Jun 3 10:11:27 2026 +0800 misc: bcm-vk: Use acquire/release for msgq_inited [ Upstream commit 61b101c6a150057b6d512421ed108aed16e822ea ] bcm_vk_sync_msgq() fills the message queue information and then sets msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the message queues and their cached queue information. atomic_set()/atomic_read() do not order those accesses. A reader can see msgq_inited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate. Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the gate and does not publish queue state to readers. Fixes: 111d746bb476 ("misc: bcm-vk: add VK messaging support") Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260603021127.3285057-1-hanguidong02@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5310334762c3f08f51dc2414344dd47492c07d1d Author: Pavel Zhigulin Date: Mon Jun 1 01:07:58 2026 +0200 speakup: keyhelp: guard letter_offsets possible out-of-range indexing [ Upstream commit 6a19ad4d68c95185308cd9e5d169b10a2cf236c8 ] help_init() builds letter_offsets[] by using the first byte of each function name as an index via `(start & 31) - 1`. If function_names are overridden from sysfs (root) with a name starting outside [a–z], the index underflows or exceeds the array, leading to OOB write. Function names can be overridden with the following commands as root: modprobe speakup_soft echo "0 _bad" > /sys/accessibility/speakup/i18n/function_names # then press Insert+2 on /dev/tty This fix checks the first letter in help_init(), and if it is not in the [a–z] range the function returns an error to the caller. Eventually this error is propagated to drivers/accessibility/speakup/main.c:2217, which causes a bleep sound. Fixes: c6e3fd22cd53 ("Staging: add speakup to the staging directory") Signed-off-by: Pavel Zhigulin Signed-off-by: Samuel Thibault Link: https://patch.msgid.link/20260531230804.254962-10-samuel.thibault@ens-lyon.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8688fe2941d54907e3f71dbb96b0b7a021ee12b8 Author: Christophe JAILLET Date: Mon Jun 1 01:07:53 2026 +0200 accessibility: speakup: Fix incorrect string length computation in report_char_chartab_status() [ Upstream commit bce0e640623372520d9d90c42f33ddbfb576ce69 ] snprintf() returns the "number of characters which *would* be generated for the given input", not the size *really* generated. In order to avoid too large values for 'len' (and potential negative values for "sizeof(buf) - (len - 1)") use scnprintf() instead of snprintf(). Fixes: c6e3fd22cd53 ("Staging: add speakup to the staging directory") Signed-off-by: Christophe JAILLET Signed-off-by: Samuel Thibault Reviewed-by: Samuel Thibault Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20260531230804.254962-5-samuel.thibault@ens-lyon.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 16695e9059d80ea6661e8399064b0c01f641dd8c Author: Yuho Choi Date: Tue Jun 30 15:27:14 2026 -0400 uio: Fix stale info pointer in failed registration path [ Upstream commit 67b6fc084b034a91c3ec7907a3fed89a2450f30b ] After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same "device gone" state as normal uio_unregister_device(). Fixes: a93e7b331568 ("uio: Prevent device destruction while fds are open") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260630192714.1867170-1-dbgh9129@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1e805a7f4fe01d73d33d02de38cd3dc7304474f0 Author: Gui-Dong Han Date: Fri May 22 15:34:47 2026 +0800 gpib: Move stuck SRQ update under lock [ Upstream commit 7ddb521ab097413fbdff483b53b4a8c73a0e2b40 ] Move the stuck SRQ state update into autopoll_all_devices() and keep it under big_gpib_mutex. Except for initialization, keep the stuck_srq users under this mutex. autopoll_all_devices() is only called by autospoll_thread(), so there is no need to return to autospoll_thread() and set this state after dropping big_gpib_mutex. Without the mutex, a newly opened device can clear stuck_srq and have that clear overwritten by the previous autospoll result: autospoll: serial_poll_all() returns 0 and unlocks big_gpib_mutex open_dev_ioctl: open new device and clear stuck_srq with big_gpib_mutex held autospoll: set stuck_srq That leaves the board marked stuck again after the new device is opened. autospoll_wait_should_wake_up() then refuses to poll while stuck_srq is set, so later SRQ handling can be mistakenly suppressed. Without the mutex, atomic_set() and set_bit() only make individual updates atomic. They do not order the two updates or make stuck_srq and status visible as a consistent pair. Taking big_gpib_mutex serializes the state transition with the other runtime users. Keep the existing wakeup behavior unchanged and only move the stuck SRQ state update under the mutex. Fixes: 9dde4559e939 ("staging: gpib: Add GPIB common core driver") Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260522073447.4117690-1-hanguidong02@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6c9f6a3b9fdd31a0836b681053155b5997c0156e Author: Cong Nguyen Date: Wed Jul 15 18:17:10 2026 +0700 staging: rtl8723bs: fix xmit_frame/xmit_buf leaks on mgnt-frame error paths [ Upstream commit 41b8209376dffbd7b0b85c8bc4697d9166ac62ef ] issue_beacon(), issue_probersp() and issue_asocrsp() obtain a management xmit_frame together with its xmit_buf from the driver's fixed-size management-TX pools via alloc_mgtxmitframe(). On the normal path the frame is handed to dump_mgntframe(), which transfers ownership and eventually returns both objects to their pools (the frame and, for beacons, the buf in rtl8723bs_mgnt_xmit(); other bufs via the pending-xmitbuf/TX-completion path). Several error/edge paths return early after a successful alloc_mgtxmitframe() but before dump_mgntframe(), so ownership is never transferred and neither object is freed: - issue_beacon(): beacon larger than 512 bytes - issue_probersp(): cur_network->ie_length > MAX_IE_SZ - issue_probersp(): kzalloc() of the SSID scratch buffer fails - issue_asocrsp(): pkt_type is neither ASSOCRSP nor REASSOCRSP Because alloc_mgtxmitframe() removes the frame and buf from their free lists (list_del_init) without placing them on any pending list, an orphaned pair is on no list and referenced by nobody, so it is only reclaimed at driver teardown. Repeated hits progressively exhaust the management-TX pools until alloc_mgtxmitframe() returns NULL and the interface can no longer send beacons or probe/assoc responses. Free the frame and buffer on these paths, matching the existing correct error handling in issue_assocreq(). Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Signed-off-by: Cong Nguyen Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20260715111710.295052-1-congnt264@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 28ebc34373f04e2dc488d85e0edf5bb43eca0c18 Author: Mohammed Rizwan Kaniyate Date: Sat Apr 25 16:53:27 2026 +0530 staging: rtl8723bs: remove multiple blank lines in core/ [ Upstream commit 7dbc9fd714387388ebe049a619513e60b5c442e8 ] Remove multiple consecutive blank lines. Issue reported by checkpatch.pl Signed-off-by: Mohammed Rizwan Kaniyate Reviewed-by: Luka Gejak Link: https://patch.msgid.link/20260425112327.215355-1-mrizwank004@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 41b8209376df ("staging: rtl8723bs: fix xmit_frame/xmit_buf leaks on mgnt-frame error paths") Signed-off-by: Sasha Levin commit 368f19a5ed15f396db4ec2182c1311a7fa4f993b Author: Minu Jin Date: Wed Feb 4 22:13:45 2026 +0900 staging: rtl8723bs: replace rtw_zmalloc() with kzalloc() [ Upstream commit 980cd426a25747daf8ed25e2a1904b2d26ffbb3d ] Replace the wrapper function rtw_zmalloc() with standard kzalloc(). Use kzalloc() for rtw_malloc() calls that were followed by manual zero initialization. About GFP Flags: - GFP_ATOMIC is used for allocations in atomic contexts such as spinlock-protected sections, tasklets, and timer handlers. - GFP_KERNEL is used for process contexts where sleeping is allowed. Additionally, use array_size() and size_add() to prevent potential integer overflows during allocation size calculation. Signed-off-by: Minu Jin Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260204131347.3515949-4-s9430939@naver.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 41b8209376df ("staging: rtl8723bs: fix xmit_frame/xmit_buf leaks on mgnt-frame error paths") Signed-off-by: Sasha Levin commit aa89cd88ae034651e1357278813908dfeba8decf Author: Nayana Mariyappa Date: Fri Jan 16 12:05:11 2026 +0000 staging: rtl8723bs: expand multiple assignment into separate statements [ Upstream commit 5080a15d755be4ff72bc92df97475cf69ccf5e58 ] Split multiple assignments in a single line into separate statements in osdep_service.c to follow kernel coding style. No functional change. Signed-off-by: Nayana Mariyappa Link: https://patch.msgid.link/20260116120511.48272-5-nayana.mariyappa@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 41b8209376df ("staging: rtl8723bs: fix xmit_frame/xmit_buf leaks on mgnt-frame error paths") Signed-off-by: Sasha Levin commit 87ccaea185696b5488502223cd8b3da3cf676f02 Author: Khushal Chitturi Date: Fri Jan 16 11:00:49 2026 +0530 staging: rtl8723bs: fix operator and type cast spacing [ Upstream commit 53e0181ee7225e3a1958c51b2f00f648878e91e1 ] Fix spacing around operators and type casts in rtw_xmit.c to comply with the kernel coding style. Signed-off-by: Khushal Chitturi Link: https://patch.msgid.link/20260116053052.4198-2-khushalchitturi@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 41b8209376df ("staging: rtl8723bs: fix xmit_frame/xmit_buf leaks on mgnt-frame error paths") Signed-off-by: Sasha Levin commit d8664fa56c46bdecace9ed8b04d705a2648eebbb Author: Navaneeth K Date: Tue Nov 25 11:20:56 2025 +0000 staging: rtl8723bs: use standard offsetof in cfg80211 operations [ Upstream commit 6ddb173fcf34f4b9351a20f29e31aa2bc3f90574 ] Replace usage of the custom FIELD_OFFSET macro with the standard offsetof() macro in ioctl_cfg80211.c. This improves code readability and uses the kernel's standard mechanism. Also include in basic_types.h to ensure offsetof() is available for this and future conversions. Signed-off-by: Navaneeth K Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20251125112059.16913-3-knavaneeth786@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 41b8209376df ("staging: rtl8723bs: fix xmit_frame/xmit_buf leaks on mgnt-frame error paths") Signed-off-by: Sasha Levin commit 11b3765fcb71dc7b43d68707e2a26daa39587de5 Author: Sameeksha Sankpal Date: Mon Oct 6 09:50:05 2025 +0530 staging: rtl8723bs: Fix operator spacing in rtw_security.c [ Upstream commit 7550f96a57c8f8b649113aaa2cc4f87a755c866e ] This file has multiple style issues where spaces were missing around operators. Cleaned up the entire file by adding the required spacing around the arithmetic, logical, and comparison operators to improve readibility and adhere to the Linux kernel coding style guidelines. Signed-off-by: Sameeksha Sankpal Link: https://lore.kernel.org/r/20251006042005.9778-1-sameekshasankpal@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 41b8209376df ("staging: rtl8723bs: fix xmit_frame/xmit_buf leaks on mgnt-frame error paths") Signed-off-by: Sasha Levin commit 8da8fd3df9fc14cf79ca3a3978d27ba067985111 Author: David Lee Date: Fri Jul 17 10:47:21 2026 +0000 UDF symlink pathComponent header OOB read [ Upstream commit d23eb7380d1594cda31a5dc8487dd2a5c8def8c7 ] udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: David Lee Assisted-by: Codex:gpt-5.5 Link: https://patch.msgid.link/20260717104722.41446-1-david.lee@trailofbits.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit f42e35e9a7e694ecfb4b093050a2e97037289d76 Author: Karl Mehltretter Date: Fri Jul 17 09:16:16 2026 +0200 tty: hvc: restrict HVC_DCC to ARMv6+ and ARM64 [ Upstream commit 782f4dbd1794b4f30dc116a7ca42c5962c409be8 ] hvc_dcc drives the JTAG DCC via the ARMv6/v7 CP14 debug registers (mrc/mcr p14, 0, rX, c0, c1/c5, 0 in asm/dcc.h). That encoding is undefined on older ARM cores, and also on ARMv7-M, but HVC_DCC only depends on ARM, so it can be enabled on e.g. ARM926 (ARCH_MULTI_V5), where hvc_dcc_console_init() runs __dcc_putchar() at boot and takes an undefined-instruction trap before the console is up: Internal error: Oops - undefined instruction: 0 [#1] ARM PC is at hvc_dcc_check+0x50/0x8c hvc_dcc_check from hvc_dcc_console_init+0x18/0x48 hvc_dcc_console_init from console_init+0x58/0x170 Kernel panic - not syncing: Fatal exception Restrict HVC_DCC to the CPUs where that encoding is valid: the CPU_V6 || CPU_V6K || CPU_V7 set that arch/arm/include/debug/icedcc.S guards it with, plus ARM64. Fixes: 16c63f8ea49c ("drivers: char: hvc: add arm JTAG DCC console support") Signed-off-by: Karl Mehltretter Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20260717071616.91423-1-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2ed25c9d4400cf90d9201657963a231c27a5ea57 Author: Xu Yang Date: Mon Jul 13 14:08:45 2026 +0800 usb: gadget: f_uac1_legacy: remove broken string configfs attributes [ Upstream commit 590d74ec8f488e06b9f1c0f8f0941f45531f3a55 ] The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for the fn_play, fn_cap, and fn_cntl string options. The store function contains an inverted null check on the kstrndup() return value. This means every write attempt returns -ENOMEM on success and dereferences a NULL pointer on allocation failure. The attributes have been broken and unused for many years. Remove the UAC1_STR_ATTRIBUTE macro and the three attributes it generated. The internal defaults (FILE_PCM_PLAYBACK, FILE_PCM_CAPTURE, FILE_CONTROL) set in f_audio_alloc_inst() are unaffected. Fixes: 0854611a19ae ("usb: gadget: f_uac1: add configfs support") Link: https://lore.kernel.org/linux-usb/20260625113154.1954813-1-xu.yang_2@oss.nxp.com/ Suggested-by: Greg Kroah-Hartman Assisted-by: Claude:claude-sonnet-4.6 Signed-off-by: Xu Yang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260713060845.3759673-1-xu.yang_2@oss.nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 772f29206544f77e64ec4e7ff32a6313d0bf4cb5 Author: Rafael J. Wysocki Date: Thu Jul 9 14:30:35 2026 +0200 ACPI: processor: idle: Expand _LPI package sanity checks [ Upstream commit d5c13047a132162d2649be876906ead691d12948 ] The _LPI package sanity checks in acpi_processor_evaluate_lpi() miss a couple of things, so expand them by adding a buffer size check before retrieving a struct acpi_power_register from it (and skip the given state if the buffer is not large enough to hold a register structure) and making the function avoid copying the state description from the ACPI table if there are too few elements in the package supposed to hold it. While at it, relocate and rephrase a comment about skipping _LPI state package elements [7-8]. Fixes: a36a7fecfe60 ("ACPI / processor_idle: Add support for Low Power Idle(LPI) states") Signed-off-by: Rafael J. Wysocki Reviewed-by: Sudeep Holla Acked-by: Huisong Li Link: https://patch.msgid.link/5084143.GXAFRqVoOG@rafael.j.wysocki Signed-off-by: Sasha Levin commit 19ae79f185bc5e247b6b9391bc0f23cfd90d2d97 Author: Thorsten Blum Date: Fri Jul 10 09:42:17 2026 +0200 crypto: sl3516 - drop invalid sg_dma_len checks before DMA mapping [ Upstream commit 3ae59a2eba64b3648f069aa52eeaaeefdfe4bb2f ] sg_dma_len() is only valid after mapping the scatterlist with dma_map_sg(). However, sl3516_ce_need_fallback() checks it before the source and destination scatterlists are mapped. Thus, a stale DMA length that is not a multiple of 16 could incorrectly force a software fallback when CONFIG_NEED_SG_DMA_LENGTH=y. Remove the invalid checks; the existing scatterlist length checks are sufficient. Fixes: 46c5338db7bd ("crypto: sl3516 - Add sl3516 crypto engine") Signed-off-by: Thorsten Blum Acked-by: Linus Walleij Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d43e1bbfd43458b9242806eec77ea3b032134baf Author: Ruoyu Wang Date: Thu Jul 9 14:23:09 2026 +0800 drm/msm: Only fini scheduler after successful init [ Upstream commit e2332abed2a4d3caa59052095dc16e4ce44791ea ] msm_ringbuffer_new() destroys a partially initialized ring through msm_ringbuffer_destroy() when an allocation or scheduler setup step fails. If drm_sched_init() fails before it finishes initializing the scheduler, the failure path still calls drm_sched_fini(). That teardown path assumes the scheduler work items, lists, and workqueue state were initialized. Track successful scheduler initialization and call drm_sched_fini() only after drm_sched_init() returned 0. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler") Signed-off-by: Ruoyu Wang Patchwork: https://patchwork.freedesktop.org/patch/738905/ Message-ID: <20260709062309.4168362-1-ruoyuw560@gmail.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 6c472fde2c8096e16bb46b0605adda2488f300c0 Author: Jie Zhang Date: Fri Jun 5 01:38:22 2026 +0530 drm/msm: Fix task_struct reference leak in recover_worker [ Upstream commit 40b793714ad8f393ab3d469f9d00b20ebda46257 ] get_pid_task() increments the task reference count, but the corresponding put_task_struct() was missing in the else branch, leaking a reference on every GPU hang recovery. Fixes: 25654a1756a4 ("drm/msm: Update global fault counter when faulty process has already ended") Signed-off-by: Jie Zhang Signed-off-by: Akhil P Oommen Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/730662/ Message-ID: <20260605-assorted-fixes-june-v1-6-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 133c9aa5b896cba28a19a30452f17d9e56cfa627 Author: Jie Zhang Date: Fri Jun 5 01:38:20 2026 +0530 drm/msm/a6xx: Fix A621 GPUCC register list for state capture [ Upstream commit d052d0358fb89b59718b9c24871d72006d4b89b0 ] A621 uses an incorrect GPUCC register list during state capture. The existing list matches A623/A663. Rename it accordingly and add a dedicated A621 GPUCC register list. Fixes: 11cdb81b3c1b ("drm/msm/a6xx: Fix gpucc register block for A621") Signed-off-by: Jie Zhang Signed-off-by: Akhil P Oommen Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/730659/ Message-ID: <20260605-assorted-fixes-june-v1-4-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 15d9b29c7da186c8e1ed24c7ceeaf95f5f969085 Author: Akhil P Oommen Date: Tue Nov 18 14:20:37 2025 +0530 drm/msm/a6xx: Rebase GMU register offsets [ Upstream commit 188db3d7fe66ca0f865a4f5608d00b961cc8b2d9 ] GMU registers are always at a fixed offset from the GPU base address, a consistency maintained at least within a given architecture generation. In A8x family, the base address of the GMU has changed, but the offsets of the gmu registers remain largely the same. To enable reuse of the gmu code for A8x chipsets, update the gmu register offsets to be relative to the GPU's base address instead of GMU's. Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/689010/ Message-ID: <20251118-kaana-gpu-support-v4-10-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark Stable-dep-of: d052d0358fb8 ("drm/msm/a6xx: Fix A621 GPUCC register list for state capture") Signed-off-by: Sasha Levin commit 8bc35465c51be3626fed3f4c2d308658e15eb62e Author: Jie Zhang Date: Fri Jun 5 01:38:19 2026 +0530 drm/msm/a6xx: Fix A663 GPUCC register list for state capture [ Upstream commit fc7ccbc6174b79ffab5be5dca5b6e253df22f030 ] The GPUCC register list for A663 is incorrect, which can cause out-of-bounds register access during GPU state capture. Update it to use the correct register ranges. Fixes: 5773cce8615c ("drm/msm/a6xx: Add support for A663") Signed-off-by: Jie Zhang Signed-off-by: Akhil P Oommen Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/730656/ Message-ID: <20260605-assorted-fixes-june-v1-3-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit e36284257eeca13768687bf8e52f66f8ea0e8794 Author: Jie Zhang Date: Fri Jun 5 01:38:18 2026 +0530 drm/msm: Recover HW before retire hung submit [ Upstream commit b303e1d52811de7d1bcf793560754d4df68d4a1c ] During recovery, it is not safe to retire the hung submit before we recover the GPU. Retiring the submit triggers BO free and that can result in GPU pagefaults since the GPU may be actively accessing those BOs. To fix this, retire the submits after gpu recovery is complete in recover_worker(). Fixes: 1a370be9ac51 ("drm/msm: restart queued submits after hang") Signed-off-by: Jie Zhang Signed-off-by: Akhil P Oommen Acked-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/730655/ Message-ID: <20260605-assorted-fixes-june-v1-2-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 8298883bb3edbcfa201e51b7e7b7af52056ec5b1 Author: Shivam Rawat Date: Fri Jun 5 01:38:17 2026 +0530 drm/msm/a6xx: Fix stale rpmh votes after suspend [ Upstream commit d9108bfdb746edacdb05bd27959a4ae63c6c7f3f ] There are stale RPMH votes (BCM votes) observed after GMU suspend. This is because the rpmh stop sequences are skipped during gmu suspend. Fix this and also move GMU to reset state to avoid any further activity. Fixes: f248d5d5159a ("drm/msm/a6xx: Fix PDC sleep sequence") Signed-off-by: Shivam Rawat Signed-off-by: Akhil P Oommen Tested-by: Neil Armstrong # on SM8650-HDK Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/730652/ Message-ID: <20260605-assorted-fixes-june-v1-1-2caa04f7287c@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 9ad7a6ccc7b839247663d57d3dbb4481dec492de Author: Mikko Perttunen Date: Tue Jun 9 17:09:20 2026 +0900 gpu: host1x: Avoid stack over-read in debug output helpers [ Upstream commit bc17ac285fb708f22a8fa2c0ed32eceb1d37e6d6 ] host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written. Fixes: 6236451d83a7 ("gpu: host1x: Add debug support") Signed-off-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-4-7c1131c0b3ad@nvidia.com Signed-off-by: Sasha Levin commit 9211efca5c6573a9c804da5d0db4da60bcb6f39c Author: Mikko Perttunen Date: Tue Jun 9 17:09:19 2026 +0900 gpu: host1x: Fix offset calculation in trace_write_gather [ Upstream commit eb896850964d3dfce291b4fdff9c2d42d85e564b ] When a gather longer than 2*TRACE_MAX_LENGTH (256) words is traced through host1x_cdma_push_gather, the reported BO offset drifts from the third iteration onward. Fix the calculation by properly calculating the value on each loop rather than accumulating. In reality, gathers tend to be pretty short so this is unlikely to ever have been observed. Fixes: b40d02bf96e0 ("gpu: host1x: Use struct host1x_bo pointers in traces") Signed-off-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-3-7c1131c0b3ad@nvidia.com Signed-off-by: Sasha Levin commit 6b7d5abf3e374ca3af31ceb6b9b2efc7a48afde3 Author: Avraham Stern Date: Wed Jul 15 22:04:31 2026 +0300 wifi: iwlwifi: mei: pass correct argument to function [ Upstream commit 905f57aefde4f4092a411c8a55856182fb1c7598 ] The first argument to iwl_mei_write_cyclic_buf() should be the cldev but the q_head pointer is passed instead. Fix it. Fixes: 652291601459 ("iwlwifi: mei: don't rely on the size from the shared area") Signed-off-by: Avraham Stern Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715220243.24cea60c6428.I42301010c31487b1458faa967b22c8320b0cfd23@changeid Signed-off-by: Sasha Levin commit f26f72c2448829701d7c3e840fac9d168a98a955 Author: Emmanuel Grumbach Date: Wed Jul 15 22:04:29 2026 +0300 wifi: iwlwifi: guard against division by zero in iwl_dbg_tlv_alloc_fragments [ Upstream commit 9318bc0c41b24705690cf80d1596cf6b711e7027 ] Make sure we don't end-up with a num_frags = 0 situation. For that, check that the required size is not 0 and put a checker on num_frags as well. Fixes: 14124b25780d ("iwlwifi: dbg_ini: implement monitor allocation flow") Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715220243.60121deecf2c.Iebc891c95a7bd1b2a093b0bb88532db446a758ee@changeid Signed-off-by: Sasha Levin commit 242125bbf19a2974d22f3d5025c9c14c0a4aea58 Author: Avraham Stern Date: Wed Jul 15 22:04:27 2026 +0300 wifi: iwlwifi: mei: check SAP message length before reading it [ Upstream commit 7d8cc301bcba233f31b589a45f4c1c97f2bb90d6 ] Verify the SAP message size is not larger than the local buffer before reading the message to avoid buffer overflow. Fixes: bcd68b3dbe78 ("wifi: iwlwifi: mei: fix tx DHCP packet for devices with new Tx API") Signed-off-by: Avraham Stern Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715220243.f0026ce26218.I00a856d3aacae1caac605c708f7362689b734234@changeid Signed-off-by: Sasha Levin commit c9d8641aea01c3b2516483e128e1f557cfbcf44a Author: Emmanuel Grumbach Date: Wed Jul 15 22:04:22 2026 +0300 wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiser [ Upstream commit f6a6c01cbc046f68e6916a7e047a1bc881c8c9ab ] iwl_mvm_frob_txf_key_iter() tracks the last matched byte position in loop variable 'i'. When a full key match is found (match == keylen), 'i' points at the last byte of the matched key. The memset start offset should therefore be i + 1 - keylen, not i - keylen; the current code zeroes one byte before the match and leaves the final key byte un-sanitised. Fixes: 12d60c1efc29 ("iwlwifi: mvm: scrub key material in firmware dumps") Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715220243.355998ec4fbe.I40f3427657b897e911bdf4ebf8e494745508d126@changeid Signed-off-by: Sasha Levin commit 8d8a526f3ec659194f846a2cb33844d9f6cb9995 Author: Emmanuel Grumbach Date: Wed Jul 15 22:04:20 2026 +0300 wifi: iwlwifi: fix counter type in iwl_fwrt_dump_error_logs [ Upstream commit 71e67b4b59337b2f9f4fef976a27de2dad7aabf2 ] The loop counter 'count' was declared as u8 while num_pc is u32. If firmware advertises more than 255 PC entries the counter wraps back to zero and the loop never terminates potentially causing an infinite loop or reading past the allocated pc_data array. Change the declaration to u32 to match num_pc. Fixes: 2b69d242e29b ("wifi: iwlwifi: fw: print PC register value instead of address") Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715220243.a61c65f34e87.Ie5f1a7ca43e0cc5a0ddc8305b0448ddffc09cd18@changeid Signed-off-by: Sasha Levin commit f20b182ff2d44d30f47ccc74b457aea4f19f30ad Author: Praveen Talari Date: Thu Jul 16 13:55:45 2026 +0530 spi: geni-qcom: Fix sticky ret causing wrong return value on invalid proto [ Upstream commit 2c1c13da3a3a639d2ac7221e1a5e57945cbc7235 ] spi_geni_init() reuses 'ret' after it has already been set by the runtime PM acquire check earlier in the function. When an invalid protocol is later detected, the function returns this stale 'ret' value instead of a proper error code, so it can end up returning 0 (or some other non-error value) even though the protocol check failed. Fix this by returning -EINVAL directly on both invalid-proto paths. Fixes: d8e9ea989acb ("spi: qcom-geni: Fix missing error check on pm_runtime_get_sync()") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202607122241.qzP3QAXF-lkp@intel.com/ Signed-off-by: Praveen Talari Reviewed-by: Konrad Dybcio Acked-by: Mukesh Kumar Savaliya Link: https://patch.msgid.link/20260716-fix_return_error_code-v1-1-3295003aacd5@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit badb810da2b096283ed746b068e3c63d85f91167 Author: Geert Uytterhoeven Date: Thu Jul 9 12:47:44 2026 +0200 soc: renesas: r8a78000: Drop duplicate "default ARCH_RENESAS" [ Upstream commit 07231087d5e24c4d9c578c824b96f8af913f7324 ] The Kconfig entry for ARCH_R8A78000 contains both "default y if ARCH_RENESAS" and "default ARCH_RENESAS", which are sort-of duplicates. Drop the latter, to restore consistency with the other ARM64 entries. Fixes: 5284d0b09d1bdc69 ("soc: renesas: Identify R-Car X5H") Reported-by: Marek Vasut Closes: https://lore.kernel.org/a069d50d-030d-4189-ae9d-37f989829da4@mailbox.org Signed-off-by: Geert Uytterhoeven Reviewed-by: Marek Vasut Reviewed-by: Kuninori Morimoto Reviewed-by: Duy Nguyen Link: https://patch.msgid.link/64de6e95719a6dec7412cf7e917a42749e738b99.1783593775.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit d9f25cc138c74d40a0a18de98564c07534db4a9f Author: Abel Vesa Date: Wed Jul 15 16:29:15 2026 +0300 clk: qcom: gcc-glymur: Enable runtime PM [ Upstream commit 8d4f342369d0d77f32a0211692442d3b6d455872 ] Enable runtime PM for the controller so the common GCC probe path resumes the attached domain while registering clocks, resets and GDSCs. This lets GDSC consumers propagate their votes through the GCC provider to the CX parent domain. Fixes: efe504300a17 ("clk: qcom: gcc: Add support for Global Clock Controller") Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20260715-glymur-fix-gcc-cx-scaling-v3-2-72eb5adad156@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 563a1fcf551cd5b364dd1ca6d6e807e5905202cd Author: Ian Rogers Date: Mon Jul 6 20:40:17 2026 -0700 perf jevents: Add more components to the metric sorting order [ Upstream commit 557f8b3ca8c8e58d5bc3084734bc7a470b043922 ] Nazar Kazakov reported non-deterministic builds due to the metrics being reordered in the jevents.py output. The metrics were largely only being sorted by name, add in the expressions and descriptions. Reported-by: Nazar Kazakov Closes: https://lore.kernel.org/linux-perf-users/20260706175624.692736-1-nazar.kazakov@codethink.co.uk/ Fixes: 40769665b63d ("perf jevents: Parse metrics during conversion") Tested-by: Nazar Kazakov Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 0b5f752d635c5aed251f067bf3e85537a6d6a7c7 Author: Dmitry Baryshkov Date: Thu Jun 4 19:22:24 2026 +0300 arm64: dts: qcom: sm8250: correct frequencies in the Iris OPP table [ Upstream commit 68ea007df9293fcb29d38219d73094bbf4b59673 ] The OPP table for the Iris core is wrong, it copies the VDD table from the downstream kernel, but that table is written for the video_cc_mvs0_clk_src, while the upstream uses video_cc_mvs0_clk for OPP rate setting (which is clk_src divided by 3). Specify correct frequencies in the OPP table. Fixes: fa245b3f06cd ("arm64: dts: qcom: sm8250: Add venus DT node") Reported-by: Konrad Dybcio Reviewed-by: Konrad Dybcio Reviewed-by: Dikshita Agarwal Signed-off-by: Dmitry Baryshkov Reviewed-by: Vishnu Reddy Link: https://lore.kernel.org/r/20260604-iris-venus-fix-sm8250-v7-2-7bd2f0e5bae8@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c795f18678de62cb0c82f8d17e0b4e4ac952f0d4 Author: Dmitry Baryshkov Date: Thu Jun 4 19:22:23 2026 +0300 arm64: dts: qcom: sm8250: sort out Iris power domains [ Upstream commit d5c8efda722eb1f67cfe299b71f13dab93746934 ] On SM8250 Iris core requires two power rails to function, MX (for PLLs) and MMCX (for everything else). The commit fa245b3f06cd ("arm64: dts: qcom: sm8250: Add venus DT node") added only MX power rail, but omitted MMCX voltage levels. Add MMCX domain to the Iris device node. Fixes: fa245b3f06cd ("arm64: dts: qcom: sm8250: Add venus DT node") Reported-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Dikshita Agarwal Link: https://lore.kernel.org/r/20260604-iris-venus-fix-sm8250-v7-1-7bd2f0e5bae8@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4e59a0b78e04884669ac22019a98f2112f834531 Author: George Moussalem Date: Mon Jun 8 09:09:18 2026 +0400 arm64: qcom: ipq5018: Add GEPHY RX and TX clocks [ Upstream commit 742dc058588bf1233647dcd95738c0afc621435d ] Add RX and TX clocks for the IPQ5018 GEPHY to enable the datapath. Fixes: f5f2b835e316 ("arm64: dts: qcom: ipq5018: Add GE PHY to internal mdio bus") Reviewed-by: Dmitry Baryshkov Signed-off-by: George Moussalem Link: https://lore.kernel.org/r/20260608-ipq5018-gephy-clocks-v4-3-fb2ccd56894b@outlook.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c9fed0c7056c59294da36e05617ee8f6f629bf74 Author: George Moussalem Date: Thu May 21 11:55:58 2026 +0400 arm64: dts: qcom: ipq5018: Correct CMN PLL reference clock rate [ Upstream commit 5e92312a1d7542be9a0e588467bfbb2ca123eaac ] The correct CMN PLL reference clock rate for IPQ5018 is 4.8 GHz. The CMN PLL driver did not account for the ref clock divider which is 2 for IPQ5018. Therefore, the computed rate was twice the actual output. With the driver now accounting for the CMN PLL reference clock divider (commit: 88c543fff756), set the correct reference clock rate. Fixes: c006b249c544 ("arm64: dts: ipq5018: Add CMN PLL node") Signed-off-by: George Moussalem Acked-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260521-ipq5018-cmn-pll-rate-fix-v2-1-04b28a92e0f2@outlook.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5d0fc8094678fbc0269ed75f442a37cf6e520f70 Author: Pengyu Luo Date: Mon Jun 29 14:59:03 2026 +0800 arm64: dts: qcom: sc8280xp-x13s: Fix the drive-strength of mclk pin [ Upstream commit 09531bb8e0de5081fdbe215877dd7f2ec8b2f0e1 ] The value can be retrieve via windbg on Windows. lkd> !dd f111000 L8 ctl_reg => 0x284 in drivers/pinctrl/qcom/pinctrl-msm.c function msm_gpio_dbg_show_one() ... drive = (ctl_reg >> g->drv_bit) & 7; // (0x284 >> 6) & 7 == 2 ... seq_printf(s, " %dmA", msm_regval_to_drive(drive)); // (drive + 1) * 2 == 6; ... So the value is 6, not 16, it matches Windows now. Fixes: 21927e94caa5 ("arm64: dts: qcom: sc8280xp-x13s: Enable RGB sensor") Signed-off-by: Pengyu Luo Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260629065905.15651-2-mitltlatltl@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 188344787dacb036cd42bd124b18efdfe94fce2a Author: Konrad Dybcio Date: Thu Jun 25 10:42:43 2026 +0200 arm64: dts: qcom: msm8996-xiaomi-gemini: Fix up ti,drv2604 enable GPIO [ Upstream commit 569413a98a1761782a0770aa85d20a2c78893279 ] Update the 'enable-gpio' property name to 'enable-gpios' to conform to the bindings for the TI DRV2604 haptics module. While at it, use the GPIO_ACTIVE_HIGH define instead of the raw literal. Fixes: 4ac46b3682c5 ("arm64: dts: qcom: msm8996: xiaomi-gemini: Add support for Xiaomi Mi 5") Signed-off-by: Konrad Dybcio Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260625-topic-ti_drv2604_dtwarn-v1-1-76e91fcafbe8@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 591b6fac9df3f43522e8ff6eed8662f8b6f1a124 Author: Denis V. Lunev Date: Wed Jul 15 20:34:52 2026 +0200 x86/mm/pat: Take cpa_lock around large-page collapse [ Upstream commit 1aac65f3e651334259ecb2a5f5ddb81c01f02599 ] Loading and unloading modules concurrently on several CPUs on a KASAN build, with a short delay injected at the CPA page-table lookup to widen the window, faults within minutes: BUG: KASAN: use-after-free in __change_page_attr+0x7cc/0x7e0 Write of size 8 at addr ffff888181139718 by task modprobe ... The buggy address belongs to the physical page: pfn:0x181139 ... page_type: f2(table) cpa_collapse_large_pages() rebuilds a leaf PMD from its 4K PTEs and frees the old PTE-table pages, while __change_page_attr() fetches a PTE pointer from a lockless lookup_address_in_pgd_attr() and writes it with set_pte_atomic() only later. When module text is served from a shared large ROX mapping the two run on the same PMD: CPU A (module load) CPU B (module finalize) ------------------- ----------------------- execmem_make_temp_rw set_memory_nx __change_page_attr split 2M -> 4K table P kpte = &P[i] (lockless) execmem_restore_rox set_memory_rox (CPA_COLLAPSE) cpa_collapse_large_pages rebuild leaf PMD flush_tlb_all pagetable_free(P) set_pte_atomic(kpte, ...) -> writes into freed P P is a page-table page (page_type: table), reused at once, so the write corrupts whatever got the page next: a bad-pte or bad-page splat, or a fatal fault once P has been turned into read-only text. The flush_tlb_all() before the free does not close this: its IPI only serializes against page-table walkers that run with interrupts off (e.g. GUP-fast); the walk in __change_page_attr() runs with interrupts on, so nothing stops it from holding a stale pointer into P. Serialize the collapse - the PMD rebuild, TLB flush and PTE-table free - under cpa_lock, the same lock __change_page_attr() now takes unconditionally since commit ("x86/mm/pat: stop gating cpa_lock on debug_pagealloc_enabled()"), so a concurrent walker can no longer hold a pointer into a table the collapse is about to free. Fixes: 41d88484c71c ("x86/mm/pat: restore large ROX pages after fragmentation") Signed-off-by: Denis V. Lunev Signed-off-by: Dave Hansen Acked-by: Kiryl Shutsemau (Meta) Link: https://patch.msgid.link/20260715183453.2381141-1-den@openvz.org Signed-off-by: Sasha Levin commit 57c567e0e8aa76f6e3e8f39d7f40c20bc37e76af Author: Maoyi Xie Date: Wed Jul 1 14:44:40 2026 +0800 drm/bridge: tc358767: clamp the reported AUX read size to the request [ Upstream commit ec6444a00c49e6c2b5e9a507272a28126677f9ee ] tc_aux_transfer() clamps an AUX read to the payload limit: size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: if (size) size = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 ("drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer"). Fixes: 12dfe7c4d9c5 ("drm/bridge: tc358767: Use reported AUX transfer size") Co-developed-by: Kaixuan Li Signed-off-by: Kaixuan Li Signed-off-by: Maoyi Xie Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260701064440.1541418-1-maoyixie.tju@gmail.com Signed-off-by: Sasha Levin commit b6b68da41b2706e8998dfc60a08cafc637e830d3 Author: Hongling Zeng Date: Fri Jul 10 16:01:40 2026 +0800 perf: evsel: Fix error handling in tp_format lookup [ Upstream commit 4968708beaad53940b67e4952e34a97d8768091d ] In evsel__tp_format(), when trace_event__tp_format*() returns an error, IS_ERR() checks the local variable 'tp_format', but PTR_ERR() incorrectly uses 'evsel->tp_format' which hasn't been assigned yet. Fix this by using PTR_ERR(tp_format) to extract the error code from the correct variable. Fixes: 6c8310e8380d ("perf evsel: Allow evsel__newtp without libtraceevent") Signed-off-by: Hongling Zeng Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 4bc18263ef7ac31a068cd2a62e556808fcd495f9 Author: Uday Khare Date: Thu Jun 18 18:50:54 2026 +0530 remoteproc: qcom: Fix glink->node reference leak in qcom_add_glink_subdev [ Upstream commit 44f4911ab8e6f4d69afad5f2571bbd2da421c918 ] In qcom_add_glink_subdev(), the device node reference acquired via of_get_child_by_name() is stored in glink->node. If the subsequent kstrdup_const() allocation for glink->ssr_name fails, the function returns early without calling of_node_put() on glink->node, leaking the reference count. Fix this by adding of_node_put(glink->node) on the error path before returning. Fixes: cd9fc8f1b35b ("remoteproc: qcom: Pass ssr_name to glink subdevice") Signed-off-by: Uday Khare Link: https://lore.kernel.org/r/20260618132054.11010-1-udaykhare77@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b44f085fb484d2a6f2e6f5fc7f42b037dc5fa329 Author: Zhongqiu Han Date: Fri Jul 3 17:24:33 2026 +0800 cpufreq: schedutil: Fix self-contradictory comment in sugov_iowait_apply() [ Upstream commit db6a017c91b774c15b1b890db45981eacfff540e ] The kerneldoc of sugov_iowait_apply() says the IO boost value is increased in sugov_iowait_apply() and, in the same sentence, that it is decreased by the same function. That is self-contradictory, and the first part is wrong: sugov_iowait_apply() only decreases the boost. The boost is actually increased in sugov_iowait_boost(). Fix the comment to name sugov_iowait_boost() as the place where the boost is increased, so it matches the code. No functional change. Fixes: fd7d5287fd65 ("cpufreq: schedutil: Cleanup and document iowait boost") Signed-off-by: Zhongqiu Han Reviewed-by: Christian Loehle Link: https://patch.msgid.link/20260703092433.4080165-1-zhongqiu.han@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c23a708a71afc3be030cc7659bfcf0fb1fbd3ea7 Author: Rafael J. Wysocki Date: Wed Jun 24 19:33:08 2026 +0200 cpufreq: intel_pstate: Fix setting minimum P-state at init time [ Upstream commit db53c573d31d07d5d782c5312d37cb33be788eba ] If HWP is enabled, writes to MSR_IA32_PERF_CTL have no effect, so intel_pstate_get_cpu_pstates() should not attempt to call intel_pstate_set_min_pstate() to set the minimum P-state for the given CPU in that case. Accordingly, remove the intel_pstate_set_min_pstate() call from intel_pstate_get_cpu_pstates() and make both intel_pstate_cpu_init() and intel_cpufreq_cpu_init() call that function in their non-HWP code paths. The HWP code path in intel_pstate_cpu_init() does not need to update the current P-state of the CPU directly at all because it is taken care of the processor automatically, but the HWP code path of intel_cpufreq_cpu_init() should update it in principle to initialize the DESIRED_PERF field in MSR_HWP_REQUEST. For this purpose, make it call intel_cpufreq_hwp_update() and pass the minimum P-state limit to it as the current target value along with the current minimum and maximum limits. Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5090465.GXAFRqVoOG@rafael.j.wysocki Signed-off-by: Sasha Levin commit ce51fcf0d2385d125e1867edb07ce353ddbbd421 Author: Gleb Markov Date: Mon Jun 29 16:09:06 2026 +0300 drm/amd/display: Remove unused-but-set variable hubp from [ Upstream commit b736792e5bd4a62f24e8d1e310bf4a75bfbeaaaa ] The final check of hubp for NULL covers all remaining lines of code, since the value of hubp does not change until the end of the method. This check is redundant because hubp1 is already dereferenced within the macro. If it were NULL, the program would have already failed to proceed. Remove the left part of the expression with the logical "&&". Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: be1fb44389ca ("drm/amd/display: Check null pointers before used"). Signed-off-by: Gleb Markov Reviewed-by: George Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8ee385305e8902fa6fbfd66b5a112238292567b6 Author: Geoffrey McRae Date: Mon Jun 29 02:04:13 2026 +1000 drm/amd/display: Fix DM I2C teardown race [ Upstream commit e4ae30a12aa95942814957d8bc1ce7366a7107d7 ] DM I2C adapters can remain visible to userspace while DM teardown is already in progress. A concurrent i2c-dev transfer may then enter amdgpu_dm_i2c_xfer() after the backing DM state has been torn down, leading to a NULL pointer dereference. Create a devres group around the DM I2C adapter lifetime and release it at the start of dm_hw_fini(), before HPD, IRQ, and DM state are torn down. This removes the I2C adapters first and waits for in-flight users to drain before the structures used by amdgpu_dm_i2c_xfer() disappear. This fixes a teardown ordering race seen during device removal: BUG: kernel NULL pointer dereference RIP: amdgpu_dm_i2c_xfer+0x122/0x1c0 [amdgpu] Call Trace: __i2c_transfer i2c_transfer i2cdev_ioctl_rdwr Fixes: 5b3eca05cfb0 ("drm/amd/display: Use devm_i2c_add_adapter to simplify i2c cleanup logic") Signed-off-by: Geoffrey McRae Acked-by: Alex Deucher Reviewed-by: Leo Li Cc: Alex Deucher Cc: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5323ed5a7bb2568191ec676b2035b0396105aa05 Author: Ruoyu Wang Date: Wed Jul 8 22:33:43 2026 +0800 media: ipu6: Do not free aux device pdata after init [ Upstream commit 9be07216af4cfc4813e1a46ce26407d31ea845de ] ipu6_bus_initialize_device() stores the isys/psys pdata pointer in struct ipu6_bus_device and initializes the auxiliary device. After that point, error unwinding must drop the auxiliary device reference and let ipu6_bus_release() free both the bus device and adev->pdata. The isys and psys init paths already call put_device() when MMU initialization fails, and ipu6_bus_add_device() calls auxiliary_device_uninit() on auxiliary_device_add() failure. Both paths therefore run the bus release callback. The extra kfree(pdata) in the callers can release the same object a second time. Remove the manual pdata frees after the auxiliary device has been initialized. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: cb3117b074ae ("media: intel/ipu6: add IPU auxiliary devices") Signed-off-by: Ruoyu Wang Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 2c29cd408ef86e695acb2a5d4e00fa2f5695368d Author: Eugen Hristev Date: Tue Jun 9 20:05:23 2026 +0300 media: bcm2835-unicam: Fix asc leaked in error/remove path [ Upstream commit 253c9659e25131b0169f718e7d094ac1aa0d9279 ] v4l2_async_nf_add_fwnode_remote() allocates the asc, which is freed when v4l2_async_nf_cleanup() is called. Call v4l2_async_nf_cleanup() properly in the driver paths. Discovered with kmemleak after rmmod: unreferenced object 0xffff000084526b80 (size 64): comm "modprobe", pid 185, jiffies 4295013512 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 e8 0d ff bf 00 00 ff ff ................ 40 83 bc 84 00 00 ff ff 60 83 bc 84 00 00 ff ff @.......`....... backtrace (crc ac584083): [<00000000ffb081a7>] kmemleak_alloc+0x38/0x44 [<00000000d2fd9301>] __kmalloc+0x1b0/0x250 [<000000004dd5354d>] __v4l2_async_nf_add_fwnode+0x28/0x9c [<0000000067587657>] __v4l2_async_nf_add_fwnode_remote+0x3c/0x64 Fixes: 392cd78d495f ("media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface") Signed-off-by: Eugen Hristev Reviewed-by: Laurent Pinchart Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 96baeead354ab04bd07ef7ca174aaa6c703bcfce Author: Biren Pandya Date: Sun Jul 5 01:46:28 2026 +0530 media: i2c: rdacm21: Fix missing media_entity_cleanup() [ Upstream commit 04c053379c3a33460b581953c4f5b36de39439ac ] The driver misses calling media_entity_cleanup() on the probe error path and during remove, leaking resources if probe fails after entity initialization or when the driver is unloaded. Fix this by adding media_entity_cleanup() to the rdacm21_probe() error handling path and to rdacm21_remove(). Fixes: a59f853b3b4b ("media: i2c: Add driver for RDACM21 camera module") Signed-off-by: Biren Pandya Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 9acc996cb2e8477ae81bd7c067fec15202d6bc89 Author: Qingshuang Fu Date: Wed Jul 8 18:08:46 2026 +0800 irqchip/renesas-irqc: Fix generic interrupt chip leak on remove [ Upstream commit 616dd89d81ad9a3cf1cfff4088a4c43e4e00d6ba ] The driver allocates domain generic chips probe. However, on driver removal, the generic chips are not automatically freed when the interrupt domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC. This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. Fix the resource leak by setting IRQ_DOMAIN_FLAG_DESTROY_GC on the interrupt domain; this lets the interrupt domain core automatically release all generic chips when irq_domain_remove() is invoked, removing the need for manual cleanup calls in error paths and remove callback. Fixes: 99c221df33fbfa1b ("irqchip/renesas-irqc: Move over to nested generic chip") Signed-off-by: Qingshuang Fu Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260708100846.506314-1-fffsqian@163.com Signed-off-by: Sasha Levin commit f6f6bdf1708acbcebdcbf96e47e8b87fe72a2d86 Author: Yuho Choi Date: Tue Jun 30 15:52:34 2026 -0400 PCI: xgene: Drop unnecessary OF node reference [ Upstream commit 4869db344e76c9adfb1d9654df442db5371fac71 ] xgene_pcie_probe() stores dev->of_node in port->node with of_node_get(), but the cached node is only used during probe by xgene_pcie_parse_map_dma_ranges(). The driver never releases the extra reference, so the node reference is leaked. There is no need for private OF node ownership here. Use the device's existing of_node directly in xgene_pcie_parse_map_dma_ranges() and remove the cached port->node pointer. Fixes: 5f6b6ccdbe1c ("PCI: xgene: Add APM X-Gene PCIe driver") Signed-off-by: Yuho Choi Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260630195234.1871951-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin commit 9c001b7dd4d6c4066d65ea159f0c3cfa0660c11a Author: Dan Carpenter Date: Tue Jul 14 18:46:22 2026 +0300 cpufreq: spear: Fix an IS_ERR() vs NULL bug in spear1340_set_cpu_rate() [ Upstream commit 6a9e0e0f7592313ace66303cf5eca68e04c10f30 ] The clk_get_parent() function doesn't return error pointers, it returns NULL on error. Update the error checking to match. Fixes: 420993221175 ("cpufreq: SPEAr: Add CPUFreq driver") Signed-off-by: Dan Carpenter Reviewed-by: Zhongqiu Han Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 6a37acecc7c29136235cbc446a1b89e81414344b Author: John Groves Date: Mon Jun 15 16:07:30 2026 +0000 dax: read holder_ops once in dax_holder_notify_failure() [ Upstream commit 7ae9d15bdcde0f2955ae13b6a95587f9e23b2359 ] dax_holder_notify_failure() reads dax_dev->holder_ops twice without READ_ONCE() -- once for the NULL check and once for the indirect notify_failure() call. A concurrent fs_put_dax() can clear holder_ops between the two reads, so the check can observe a non-NULL pointer while the call dereferences NULL. (kill_dax() also clears holder_ops, but only after synchronize_srcu(), so it cannot race a reader that is inside dax_read_lock(); fs_put_dax() does no such synchronization.) Fetch holder_ops once into a local with READ_ONCE() so the NULL check and the indirect call observe the same value. Fixes: 8012b86608552 ("dax: introduce holder for dax_device") Suggested-by: Richard Cheng Reviewed-by: Richard Cheng Signed-off-by: John Groves Link: https://patch.msgid.link/0100019ecc09bb56-5ecc9c6b-35ba-44f8-b112-921b01b34478-000000@email.amazonses.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit 91be086330c3fbaee29ec8ceffa5e98c09225e64 Author: Bryam Vargas Date: Wed Jun 24 01:03:46 2026 -0500 libnvdimm/labels: Bound the on-media label size before the shift [ Upstream commit 18f9124248ed7a9da1c31973b629dceef76a9b0c ] For a v1.2+ index, __nd_label_validate() computes the label size as 1 << (7 + nsindex[i]->labelsize), where labelsize is a u8 read from the label storage medium. A value of 25 or more makes the shift count reach or exceed the width of int -- undefined behavior -- and 24 already shifts into the sign bit. Only 0 (128-byte) and 1 (256-byte) are valid. Reject a labelsize above 1 before the shift. The result was rejected by the following size comparison anyway, so this only removes the undefined shift on a crafted or corrupted medium; conforming labels are unaffected. Fixes: 564e871aa66f ("libnvdimm, label: add v1.2 nvdimm label definitions") Signed-off-by: Bryam Vargas Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260624-b4-disp-d8279485-v3-2-cdb6cab28b41@proton.me Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit 25b472c156364dfe40f34f48af7e3f7459838b4f Author: Liang Luo Date: Tue Jul 14 11:20:51 2026 +0800 tools/sched_ext: scx_qmap: Fix stale API name in comment [ Upstream commit 35f9cbbacb671e587c84e992e7b0098c39e895a4 ] The comment above dispatch_highpri() still references scx_bpf_dispatch[_vtime]_from_dsq(), which was renamed to scx_bpf_dsq_move[_vtime]() in v6.13 to unload the overloaded "dispatch" verb. The code below already uses the new names; only the comment was left behind during the rename. Fixes: 5cbb302880f5 ("sched_ext: Rename scx_bpf_dispatch[_vtime]_from_dsq*() -> scx_bpf_dsq_move[_vtime]*()") Signed-off-by: Liang Luo Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 85e5eeb651a1396afdc082c91221f5dda925a561 Author: Dan Carpenter Date: Fri Jul 10 22:34:44 2026 +0300 regulator: adp5055: Fix error code in adp5055_of_parse_cb() [ Upstream commit 153bc959ce0f91b4446fb6fb805b8c1d2ca20c75 ] This code accidentally returned the wrong variable instead of a negative error code. Return -EINVAL. Fixes: 147b2a96f24e ("regulator: adp5055: Add driver for adp5055") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/alFJVBbiFNxhqa_1@stanley.mountain Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b8abbd5c2928fd839dab702244cc57b228ab43aa Author: Richard Cheng Date: Fri Jun 26 18:41:02 2026 +0800 cxl/features: Clamp Get Feature output size to the remaining buffer [ Upstream commit 2aeb21fe557ef154f0cdf4f9745ebd8d5b31ca83 ] cxl_get_feature() reads a feature in a loop but passes a fixed size_out as the output capacity every iteration. On the last partial iteration the buffer has less room left, so a device that returns more than asked can overflow feat_out. Use the per-iter size data_to_rd_size, which already tracks the remaining room, as the output capacity. Fixes: 5e5ac21f629d ("cxl/mbox: Add GET_FEATURE mailbox command") Signed-off-by: Richard Cheng Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260626104102.53892-4-icheng@nvidia.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 1281dc84c81577b51e2b61c24617c9f44b2cdb99 Author: Richard Cheng Date: Fri Jun 26 18:41:01 2026 +0800 cxl/features: Reject Set Features output buffer smaller than the header [ Upstream commit cde18d6c1d913a67ab0afd3d9475ece4be79da50 ] cxlctl_set_feature() sizes its output buffer from the user's fwctl_rpc.out_len but never checks it is large enough to hold even the fwctl_rpc_cxl_out header. With out_len == 0 , kvzalloc() returns ZERO_SIZE_PTR, which passes the !rpc_out check, the subsequent rpc_out->size = 0 then writes through the poison pointer. Reject requests whose output buffer can't hold the response header, before allocating. The Set Feature reply carries no payload, so the header is all that is required. Fixes: eb5dfcb9e36d ("cxl: Add support to handle user feature commands for set feature") Signed-off-by: Richard Cheng Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260626104102.53892-3-icheng@nvidia.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 3f02031a0a53de0d3ef066c92d0486b2b11be40c Author: Richard Cheng Date: Fri Jun 26 18:41:00 2026 +0800 cxl/features: Reject Get Feature count larger than the output buffer [ Upstream commit 4bf6bac375076ced2fa4b3fef8739bd985f93456 ] cxlctl_get_feature() sizes its output buffer from the user's fwctl_rpc.out_len, but the device is told to write cxl_mbox_get_feat_in.count bytes into rpc_out->payload, which is a separate user-controlled value. Nothing bounds count against out_len, so a small out_len with a large count overflows the kvzalloc()'d buffer. A heap OOB write reachable from FWCTL_RPC. Reject requests where count exceeds the available payload room, before allocating. Fixes: 5908f3ed6dc2 ("cxl: Add support to handle user feature commands for get feature") Reviewed-by: Kai-Heng Feng Reviewed-by: Koba Ko Reviewed-by: Dave Jiang Signed-off-by: Richard Cheng Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260626104102.53892-2-icheng@nvidia.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit c656427440ea627166394d00c4b72147d5d79c60 Author: Sudeep Holla Date: Tue Jul 14 13:56:35 2026 +0100 firmware: arm_scmi: Fix transport device teardown lookup [ Upstream commit a14dd8fe0a95db638c550ed984cfe2a7428c783d ] SCMI transport devices are deliberately excluded from normal SCMI bus matching so protocol drivers cannot bind to the internal transport children. However, scmi_device_destroy() uses the same protocol/name lookup to find devices that must be unregistered during channel teardown. Split the match helper so driver matching still skips transport devices, while explicit child lookup can find them for teardown. Use a shared transport-device name prefix macro for both matching and name generation. Since transport-device names are derived from direction and protocol ID, reject duplicate protocol channel setup before creating or finding a transport device. This prevents malformed firmware with duplicate protocol child nodes from reusing an existing transport device and then destroying it when the duplicate IDR insertion fails. Fixes: 9593804c44c2 ("firmware: arm_scmi: Exclude transport devices from bus matching") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-16-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 3b0b02134ab90202af80b102fa37196b9689e86f Author: Sudeep Holla Date: Tue Jul 14 13:56:33 2026 +0100 firmware: arm_scmi: Unwind P2A receiver mailbox setup failure [ Upstream commit f3e3773c4e5e96549d7540d8ddeb4fcd534f6f1d ] mailbox_chan_setup() can request an additional P2A receiver channel after successfully acquiring the primary P2A channel. If that later request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts. Fixes: fa8b28ba22d9 ("firmware: arm_scmi: Add support for platform to agent channel completion") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-14-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 717b8e972a667fc1bebe63cbcf0d58e692cbb491 Author: Sudeep Holla Date: Tue Jul 14 13:56:32 2026 +0100 firmware: arm_scmi: Unwind TX receiver mailbox setup failure [ Upstream commit 6f7c06744d53dc8e047725d411d7f915d9ec35ae ] mailbox_chan_setup() can request an additional unidirectional TX receiver channel after successfully acquiring the primary channel. If that second request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts. Fixes: 9f68ff79ec2c ("firmware: arm_scmi: Add support for unidirectional mailbox channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-13-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit a54dc23e8bd2246c28eafffa60b4634f0d1a11cc Author: Sudeep Holla Date: Tue Jul 14 13:56:29 2026 +0100 firmware: arm_scmi: Drop handle on protocol bind failures [ Upstream commit e3a5c30d233ca5d3e799a80da806554c703bda13 ] The SCMI bus notifier acquires an SCMI handle when the driver core emits BUS_NOTIFY_BIND_DRIVER, before invoking the protocol driver probe callback. The protocol probe path only checks whether sdev->handle is set. If device_link_add() fails after the handle has been acquired, the protocol device can still bind with a valid handle but without the dependency link to the SCMI parent. A concurrent parent unbind can then miss the child and tear down the SCMI instance while the child still holds a handle into it. If the protocol driver probe later fails, for example with -EPROBE_DEFER, the driver core emits BUS_NOTIFY_DRIVER_NOT_BOUND rather than BUS_NOTIFY_UNBOUND_DRIVER. The SCMI notifier only released the handle on BUS_NOTIFY_UNBOUND_DRIVER, so each failed protocol-device bind leaked the SCMI instance users refcount and left sdev->handle set after the failed probe. Make the link helper report failure and drop the acquired handle if the link cannot be created. Also handle BUS_NOTIFY_DRIVER_NOT_BOUND in the same cleanup path used for unbind so failed probes balance the earlier BUS_NOTIFY_BIND_DRIVER acquisition. Fixes: 971fc0665f13 ("firmware: arm_scmi: Move handle get/set helpers") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-10-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 8197bc6acc517cae8dfc13bad0d0aa1f30ad5787 Author: Sudeep Holla Date: Tue Jul 14 13:56:28 2026 +0100 firmware: arm_scmi: Protect device request lookup with RCU [ Upstream commit e6a0e7a49d83e4fa4e1db68d74f99282eb97aa49 ] The SCMI device request notifier looks up protocol OF nodes from the active_protocols IDR. The IDR lookup can run concurrently with protocol activation while probe is still registering protocols and creating their SCMI devices. Wrap the lookup in an RCU read-side critical section as required by the IDR API for lockless readers. Fixes: 53b8c25df708 ("firmware: arm_scmi: Add common notifier helpers") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-9-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 71c1f8ced3cc0930449953b308c1f3075d5ea66e Author: Sudeep Holla Date: Tue Jul 14 13:56:27 2026 +0100 firmware: arm_scmi: Use channel ID for transport teardown [ Upstream commit a71a3d4d8a6e9e399fd988c0e6da47a6ee21c99e ] SCMI protocols can share the BASE transport channel when firmware does not describe a dedicated channel for the protocol. In that case multiple IDR entries can point at the same scmi_chan_info, whose owning transport device was created with cinfo->id. scmi_chan_destroy() used the IDR iterator key when destroying the transport device. If an alias entry is visited before the owning channel entry, the lookup can miss the device because the iterator key does not match the protocol ID used when the transport device was created. The code then clears cinfo->dev, so the later owning entry skips teardown and leaks the transport device. Destroy the transport device using cinfo->id, which is the protocol ID that owns the channel and was used when creating the transport device. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-8-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit e66756313d1b4eadd13f39a0aee9fc8773d4d375 Author: Sudeep Holla Date: Tue Jul 14 13:56:26 2026 +0100 firmware: arm_scmi: Reject out of range DT protocol IDs [ Upstream commit 59407ccb52130f2c81f4b3cbe4f14114afceb54f ] SCMI protocol IDs carried in message headers are limited by MSG_PROTOCOL_ID_MASK. The DT parsing paths noticed protocol IDs outside that range, but only logged an error and then kept processing the invalid value. That lets a malformed 32-bit DT reg value reach helpers which take a u8 protocol ID, where it can be truncated and/or treated as a different protocol. For channel setup, two different out-of-range values can also be used as distinct IDR keys while aliasing the generated SCMI protocol identity. Skip DT protocol nodes whose reg value does not fit the SCMI protocol ID field before setting up channels or creating protocol devices. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-7-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 54e5a4f7d83db4552d963d0785be32d9df680dcd Author: Sudeep Holla Date: Tue Jul 14 13:56:25 2026 +0100 firmware: arm_scmi: Avoid IDR updates while cleaning channels [ Upstream commit c38b1e19485aaa820e52cfe162525a8af67563da ] scmi_cleanup_channels() walks the TX/RX channel IDRs with idr_for_each() to free transport resources and destroy the dedicated transport devices before calling idr_destroy(). The destroy callback removed each entry from the same IDR being walked. That is not needed for this cleanup path, and it is unsafe because idr_for_each() has not advanced its radix-tree iterator while the callback is running. Removing the current entry from the callback can invalidate the iterator state. The callback also cannot be protected by rcu_read_lock(), because scmi_device_destroy() may sleep. Leave IDR teardown to the following idr_destroy() call and keep the callback limited to device destruction. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-6-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit d7c60c0fe2bd452b56fe07947842d64da61b7290 Author: Sudeep Holla Date: Tue Jul 14 13:56:24 2026 +0100 firmware: arm_scmi: Free transport channel on IDR failure [ Upstream commit d72e7e5f24687c0490aabf317653caffe0447aeb ] If transport channel setup succeeds but the following IDR insertion fails, the error path destroys the transport device and frees the channel info without invoking the transport cleanup callback. Call chan_free() before destroying the device so transport specific resources such as IRQs, mailbox channels and mapped shared memory are released consistently with the normal teardown path. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-5-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit d33b2b68bce6d5e28ee77f0952d7f3dc82bbe610 Author: Sudeep Holla Date: Tue Jul 14 13:56:23 2026 +0100 firmware: arm_scmi: Clean up channels on setup failure [ Upstream commit 687d67be3d87894ef12e8a164434612e0b53cfae ] scmi_channels_setup() can fail after the common BASE channel or earlier protocol channels have already been registered in the TX/RX IDRs. Route this failure through the existing channel cleanup label so the transport channels, transport devices and IDR state created before the failure are released before the probe error path frees the SCMI instance ID. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-4-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 2aac23bc0a79af41104d99823bb250fae92ba144 Author: Sudeep Holla Date: Tue Jul 14 13:56:22 2026 +0100 firmware: arm_scmi: Quiesce notifications before teardown [ Upstream commit 8e49055d0d495c9c07575ad8e111d9eaf0efb13f ] scmi_notification_exit() clears and releases the notification instance, but transport callbacks can still deliver incoming notifications until the TX/RX channels are freed. During remove, an RX interrupt in that window can enter scmi_notify() while notification state is being torn down and then dereference freed memory. The same ordering exists on the probe error path after notification initialization. The notification late-init worker has a separate lifetime issue: protocol event registration queues ni->init_work on the system workqueue, so destroying ni->notify_wq does not drain that work. If the devres group is released while init_work is still pending or running, the late-init worker can dereference the freed notification instance. Quiesce the notification core before TX/RX channels are torn down, then clean up the channels before releasing the notification core resources. Use disable_work_sync() so future late-init queueing is rejected and any already queued or running late-init work has completed before channel teardown starts. Fixes: 1e7cbfaa66d3 ("firmware: arm_scmi: Free mailbox channels if probe fails") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-3-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit f5e528f631425416f9b39e9d8b385c9f1ceb40d6 Author: Sudeep Holla Date: Tue Jul 14 13:56:21 2026 +0100 firmware: arm_scmi: Unregister device notifier before IDR teardown [ Upstream commit 66a0bbf30cc14140fe13f63cd594a7c1ee352b75 ] The requested-devices notifier looks up protocol fwnodes from the active_protocols IDR. During remove, unregister the notifier before releasing and destroying active_protocols so no notifier callback can race with the IDR teardown. Keep the bus notifier registered until after the protocol state is torn down, matching the existing remove ordering for SCMI bus users. Fixes: 53b8c25df708 ("firmware: arm_scmi: Add common notifier helpers") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-2-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 1bea027f7ef6fb889628b16c568a5f7c07a51b30 Author: Sudeep Holla Date: Tue Jul 14 13:56:20 2026 +0100 firmware: arm_scmi: Publish channel state before callbacks [ Upstream commit 0314900dcdde044af0208fed212035dbfaa55843 ] Transport setup can enable callbacks before the setup routine returns. mailbox_chan_setup() registers the mailbox client with mbox_request_channel(), and the mailbox controller startup path can enable interrupt delivery before SCMI mailbox channel state has been published. Similarly, smc_chan_setup() requests the optional A2P completion IRQ before the SMC transport has made its cinfo pointer visible. If a pending or spurious callback fires in those windows, the transport RX callback can dereference a NULL transport cinfo pointer. Publishing only the transport-private pointer is not sufficient either: an early callback can enter the SCMI core before scmi_chan_setup() has assigned cinfo->handle. The core derives scmi_info from cinfo->handle in the RX path, so a NULL handle can still fault even when the transport-private cinfo is valid. Assign cinfo->handle before invoking the transport setup callback. Publish the mailbox and SMC transport-private channel state before requesting the mailbox channels or IRQ, and clear the early-published pointers again on setup failure. Also unwind mailbox setup devres resources on failure so an optional RX setup error that is ignored by the core does not leave stale transport state behind. Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-1-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit b967c097d1b6a80c8bba5e456d0a2de0dcb09503 Author: David Stevens Date: Fri Apr 24 12:14:54 2026 -0700 x86/entry/fred: Encode frame pointer on entry [ Upstream commit dab01c597f6bd40e0efe7da967b8374ca1971b79 ] Add missing ENCODE_FRAME_POINTER macro invocation into FRED_ENTER macro, to prevent the unwinder from encountering a NULL stack frame pointer when CONFIG_UNWINDER_FRAME_POINTER is enabled Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") Signed-off-by: David Stevens Signed-off-by: Dave Hansen Acked-by: H. Peter Anvin (Intel) Link: https://patch.msgid.link/20260424191456.2679717-12-stevensd@google.com Signed-off-by: Sasha Levin commit 2bb2a778a487305bd378db5fd5014fbdce4ada2c Author: Baochen Qiang Date: Wed Jul 1 09:49:13 2026 +0800 wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate [ Upstream commit 12b09e478aa7459b7893a695ef77682202f2da83 ] ath11k can receive HT/VHT/HE frames whose reported MCS is above the maximum that can be expressed in the corresponding mac80211 rate space (e.g. an HE frame reported with MCS 12, while HE tops out at MCS 11). The frame itself is valid and decodes correctly, but for such a frame ath11k_dp_rx_h_rate() leaves rx_status->rate_idx set to the out-of-range value and never assigns rx_status->encoding, so it stays RX_ENC_LEGACY from the ath11k_dp_rx_h_ppdu() initialization. Once that frame reaches mac80211 it trips the rate sanity check and the frame is dropped with a splat: ath11k_pci 0000:03:00.0: Received with invalid mcs in HE mode 12 WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:5433 ieee80211_rx_list+0xb0a/0xe90 [mac80211] Dropping the frame would discard otherwise valid data, so instead cap the reported MCS to the maximum the rate space can express and deliver the frame. Set rx_status->encoding before the range check and assign rate_idx from the capped value, so a frame with an out-of-range MCS no longer leaves partial or bogus rate metadata behind. Also downgrade the logging level since they are not treated as invalid frames now. The only loss is that such a frame is reported as the capped MCS in the rx rate statistics. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260701-ath11k-invalid-he-mcs-v1-1-7d963080c079@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit e31985c67ba00a59d9b1340af473c1dbe6c87856 Author: Kyle Zeng Date: Wed Jul 8 18:02:03 2026 -0700 hfsplus: validate thread record before delete key rebuild [ Upstream commit e2ea5cac61acfc11dad22f1d2d4bc71d56c52a20 ] hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: Codex:gpt-5.6 Signed-off-by: Kyle Zeng Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260709010203.49664-1-kylebot@openai.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 5b894d01117b2f8df262e078d6f92df3157b5d69 Author: Alison Schofield Date: Mon Jul 13 19:04:35 2026 -0700 cxl/port: Restart port enumeration when a sibling adds the dport first [ Upstream commit a623128bc2a1c257cbad97d0582f355fbe7be927 ] Endpoint probes can race while enumerating a shared switch. If a sibling probe adds the dport first, the losing probe finds the dport already present, gets -EBUSY, and fails to enumerate the endpoint. Treat this race the same as the existing port-created case by restarting the port walk, allowing it to find the existing dport and continue enumeration. This race was discovered while testing a cxl_test mixed-granularity topology, where twelve endpoints behind shared switches are probed in parallel during module load. Fixes: 4f06d81e7c6a ("cxl: Defer dport allocation for switch ports") Signed-off-by: Alison Schofield Tested-by: Li Ming Reviewed-by: Li Ming Link: https://patch.msgid.link/20260714020438.1822669-1-alison.schofield@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 7a14b995931f18450050414290b0f91afae8d6df Author: Dave Jiang Date: Mon Jul 6 15:43:22 2026 -0700 cxl/pci: Honor -EPROBE_DEFER from component register setup [ Upstream commit 430c502c80e542e77bcf97db13ec0e8cdf9addb0 ] cxl_pci_setup_regs() for CXL_REGLOC_RBI_COMPONENT can return -EPROBE_DEFER on a Restricted CXL Host (RCD) when the upstream port has not yet been enumerated and the Component Registers must be extracted from the RCRB. cxl_pci_probe() treats every non-zero return from that call as the benign "component registers not found" case, logs a warning, and continues. The rc is then immediately overwritten by the subsequent cxl_pci_type3_init_mailbox() call, so the deferral is silently swallowed. Return -EPROBE_DEFER instead of continuing so the probe is retried once the upstream port is available. Fixes: 733b57f262b0 ("cxl/pci: Early setup RCH dport component registers from RCRB") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-cxl/ajzhsubot_PSYtHQ@MWDK4CY14F/T/#m063bbf76b1c9c293ade52ab311018ae6bba11a44 Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Alison Schofield Link: https://lore.kernel.org/linux-cxl/ajzhsubot_PSYtHQ@MWDK4CY14F/T/#m063bbf76b1c9c293ade52ab311018ae6bba11a44 Link: https://patch.msgid.link/20260706224322.714934-1-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 6ad491cef1a812cf7b53aa769cd8869516c47362 Author: Dave Jiang Date: Thu Jul 9 08:57:14 2026 -0700 cxl/mbox: Break poison list loop on an empty payload [ Upstream commit 8b301c4afbce4bc3f94528441d8d5ce1366504ad ] A device that returns count == 0 with CXL_POISON_FLAG_MORE set on every iteration never advances nr_records, so the max_errors guard never trips and the do/while loops forever while holding poison.mutex. That hangs the sysfs-triggered scan thread and blocks all subsequent poison operations on the device. The existing "Protect against an uncleared _FLAG_MORE" guard was intended to bound a misbehaving device but does not cover the count == 0 case. Stop the loop on an empty payload so a malfunctioning or malicious device cannot wedge the poison scan. Link: https://sashiko.dev/#/patchset/20260702090849.47501-1-icheng@nvidia.com?part=3 Fixes: ed83f7ca398b ("cxl/mbox: Add GET_POISON_LIST mailbox command") Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260709155714.1893280-1-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 485bf440904914df22414eaab7f1c336d624c480 Author: Guzebing Date: Mon Jul 13 19:27:44 2026 +0800 cxl/memdev: Fix firmware upload exact-fit handling [ Upstream commit af5035e1b3e400067bb003975936e5407377e7a3 ] cxl_fw_prepare() classifies a firmware image as a one-shot transfer only when its Transfer FW input payload is smaller than the mailbox payload size. An image that exactly fills the payload is therefore treated as a multi-part transfer. The firmware loader invokes cxl_fw_write() only once for that image. Since both offset == 0 and remaining == 0, the multi-part action selection sends INITIATE, never sends END, and then attempts to activate the target slot. Include equality in the one-shot classification so exact-fit images use the FULL action. Fixes: 9521875bbe00 ("cxl: add a firmware update mechanism using the sysfs firmware loader") Signed-off-by: Guzebing Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260713112744.2543829-1-guzebing1612@gmail.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit a97eef0d6e2fee6bc9c62e56f7b022f47dfb02c5 Author: Jason Gunthorpe Date: Mon Jul 13 14:09:46 2026 -0300 iommufd: Simplify iommufd_device_remove_vdev() [ Upstream commit 8062148046e1a6417d44e2ed86c04e66c2f4f2a1 ] Peiyang reports that this function indirectly includes a fault injection point through iommufd_get_object() that was intended to cover the uAPI use of object IDs, not in places like this that cannot fail. On deeper inspection this can be written using a dedicated helper to obtain a users refcount relying entirely on the xa locking instead of going through the whole get/put scheme. The new helper doesn't need the fault injection point. Fixes: 850f14f5b919 ("iommufd: Destroy vdevice on idevice destroy") Link: https://patch.msgid.link/r/0-v1-719003d53a5b+38b-iommufd_fault_inj_vdev_jgg@nvidia.com Reported-by: Peiyang He Closes: https://lore.kernel.org/r/870BB9ADBBEDDD1A+37c5bfab-ad32-4fc5-a302-57c81a8432b5@smail.nju.edu.cn Reviewed-by: Nicolin Chen Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ecad679e2b92c419cc22cc8f257cd457d5192647 Author: Vishnu Santhosh Date: Thu Jun 4 14:12:53 2026 +0530 rpmsg: glink: fix deadlock in endpoint destroy during driver detach [ Upstream commit 5a5a48e788e02fd8a8eb7188ce440572d6c12418 ] During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock. Co-developed-by: Deepak Kumar Singh Signed-off-by: Deepak Kumar Singh Signed-off-by: Vishnu Santhosh Tested-by: Bjorn Andersson Fixes: a53e356df548 ("rpmsg: glink: fix rpmsg device leak") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260604-rpmsg-glink-fix-deadlock-destroy-ept-v1-1-b8a54ad1e4fd@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit dd2b56f44be4910278bd97eb3f2fbc0cac30c5ee Author: Srinivas Kandagatla Date: Fri Aug 22 11:00:43 2025 +0100 rpmsg: glink: remove duplicate code for rpmsg device remove [ Upstream commit 112766cdf2e5ea0a0f72b0304d57a6f74c066670 ] rpmsg device remove code is duplicated in at-least 2-3 places, add a helper function to remove this duplicated code. Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250822100043.2604794-3-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 5a5a48e788e0 ("rpmsg: glink: fix deadlock in endpoint destroy during driver detach") Signed-off-by: Sasha Levin commit c7f41c7f7d68f3d1163639beb8e2ef1dabba18ed Author: Dmitry Ilvokhin Date: Wed Jul 8 13:38:34 2026 +0000 perf record: Fix multiple PERF_RECORD_COMPRESSED2 records per push [ Upstream commit ad40a000ea598f316ddc0e81e5acc77cc3b1fae0 ] With Zstd compression enabled ('perf record -z'), a single mmap push whose compressed output exceeds the maximum record size makes zstd_compress_stream_to_records() emit several PERF_RECORD_COMPRESSED2 records back to back. record__pushfn() however rewrote only the first record's header to describe the whole blob as one record: event->data_size = compressed - sizeof(struct perf_record_compressed2); event->header.size = PERF_ALIGN(compressed, sizeof(u64)); padding = event->header.size - compressed; ... record__write(rec, map, &pad, padding); perf_event_header::size is a __u16, so once the compressed blob no longer fits in it the header.size assignment truncates and 'padding' (size_t) underflows. write() is then handed that bogus length and fails with EFAULT, aborting the recording: failed to write perf data, error: Bad address The bytes that did reach the file are mis-framed, so reading it back cannot be decompressed. This is easy to hit with a high event rate and a large buffer, e.g.: perf record -z -F max -m 32M --per-thread -- perf test -w thloop 5 1 The single-record fixup is wrong by construction: because header.size is 16 bits a compressed record cannot exceed 64KB, so the compressor must split a push into a chain of records, and the session reader already consumes them as such. Frame each record where it is produced instead: make process_comp_header() set the per-record data_size, 8-byte-align header.size and zero the trailing padding, and let record__pushfn() write the resulting blob, as the AIO path already does. Reduce max_record_size by sizeof(u64) so the per-record alignment padding cannot push header.size past its u16 field. process_comp_header() returns -1 when that padding would not fit the space left in 'dst', so the compressor stops instead of overrunning the output buffer. There is no on-disk format change; a perf.data written by the fixed tool is still read by existing perf. Fixes: 208c0e168344 ("perf record: Add 8-byte aligned event type PERF_RECORD_COMPRESSED2") Reported-by: Farid Zakaria Signed-off-by: Dmitry Ilvokhin Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit f476567a3a96538cf63bd7ff83e54a5bdf72713c Author: Dmitry Ilvokhin Date: Wed Jul 8 13:38:33 2026 +0000 perf record: Return the written size from process_comp_header() [ Upstream commit 757155c142f2bc9793e888ab101a5eea2d53f8f8 ] process_comp_header() is called from zstd_compress_stream_to_records() twice per record: once with data_size == 0 to write the record header, and once with the payload size to finalize it. It returns the increment it was passed, and the loop separately decides whether a record still fits by comparing the remaining 'dst_size' against the header size. With the fit check split from the code that writes the record, process_comp_header() cannot reject a record on its own, so any bytes it writes into 'dst' have to be bounds-checked by the caller instead of where they are produced. Pass the space left in 'dst' to process_comp_header(), let it return the number of bytes written or -1 when the header does not fit, and account the compressed payload in the loop. No functional change intended. Signed-off-by: Dmitry Ilvokhin Signed-off-by: Namhyung Kim Stable-dep-of: ad40a000ea59 ("perf record: Fix multiple PERF_RECORD_COMPRESSED2 records per push") Signed-off-by: Sasha Levin commit 8b771b43710f79c6a65689b9eb5d55348f23540a Author: Arnaldo Carvalho de Melo Date: Mon May 4 18:26:07 2026 -0300 perf zstd: Fix compression error path in zstd_compress_stream_to_records() [ Upstream commit a18908b5056b8fdb2c44505f0c57ff05865740a3 ] The error fallback does memcpy(dst, src, src_size) intending to store uncompressed data when compression fails, but this has three bugs: 1. dst has been advanced past the record header (and potentially past earlier compressed records), so the copy writes to the wrong offset in the output buffer. 2. src still points to the start of the input, not to the remaining uncompressed data at src + input.pos. On a second or later iteration, previously compressed data would be duplicated. 3. No check that dst_size >= src_size — if the remaining output space is smaller, this is an out-of-bounds write. Replace with return -1 after resetting the ZSTD compression context via ZSTD_initCStream(). The -1 propagates through zstd_compress() -> record__pushfn() -> perf_mmap__push() to the recording loop, which breaks out and terminates recording. Add an out_child_no_flush label in __cmd_record() so the mmap-read failure path skips the final record__mmap_read_all() flush — retrying the same read that just failed would just fail again, and the flush is only useful when the mmap data is intact but the control path (auxtrace, switch_output) had an error. Consolidate all error paths through a single 'reset' label to ensure the compression context is always reset on failure — including the output-buffer-full path, where a bare return without resetting would leave stale stream state that corrupts output if the caller retries. Also guard against process_header() writing the event header before the buffer-full check: add a sizeof(perf_event_header) pre-check so the callback never writes past the output buffer. Guard against ZSTD making no progress: if output.pos is zero after ZSTD_compressStream(), calling process_header(record, 0) would re-trigger header initialization, double-subtracting the header size from dst_size and underflowing the unsigned counter. Also fix two pre-existing issues in the same function: - Add a dst_size guard before subtracting the record header size: if the output buffer is nearly full, the unsigned dst_size -= size underflows to a huge value, causing ZSTD_compressStream to write past the buffer boundary. - Check the ZSTD_initCStream() return value and log an error if the context reset itself fails. Reported-by: sashiko-bot@kernel.org # Running on a local machine Reviewed-by: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6-1m Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: ad40a000ea59 ("perf record: Fix multiple PERF_RECORD_COMPRESSED2 records per push") Signed-off-by: Sasha Levin commit ae69f936e8ffed553d899ba4c02f8a7461a89e54 Author: Reinette Chatre Date: Mon Jul 13 10:39:40 2026 -0700 fs/resctrl: Prevent use-after-free in rdtgroup_kn_put() [ Upstream commit f5bcf539484d2d604c2f2330e09487ea090b21c7 ] A struct rdtgroup is reference counted via rdtgroup::waitcount. Callers that need the structure to remain valid across a sleep (while waiting on acquiring rdtgroup_mutex) take a reference with rdtgroup_kn_get() and release it with rdtgroup_kn_put(). The release path is intended to serve as the fallback freer: if the count drops to zero and the group has already been marked RDT_DELETED, rdtgroup_kn_put() frees the structure. The bulk teardown paths free_all_child_rdtgrp() and rmdir_all_sub() resulting from a resctrl directory remove or resctrl fs unmount act as the primary freer: they hold rdtgroup_mutex and free each rdtgroup whose waitcount is zero, otherwise they set RDT_DELETED and leave the freeing to the last waiter. These two freers race. rdtgroup_kn_put() commits waitcount == 0 with atomic_dec_and_test() outside rdtgroup_mutex, then reads rdtgroup::flags. Between those two operations a concurrent caller of free_all_child_rdtgrp() or rmdir_all_sub() (which holds the mutex) can observe waitcount == 0 via atomic_read(), call rdtgroup_remove(), and kfree() the structure. The subsequent read of rdtgroup::flags in rdtgroup_kn_put() is then a use-after-free, and the structure may even be freed twice if the freed memory happens to satisfy the RDT_DELETED flag check. Replace the bare atomic_dec_and_test() with atomic_dec_and_mutex_lock() so that the decrement-to-zero takes rdtgroup_mutex before the count becomes globally visible. The inspection of rdtgroup::flags then runs under the same mutex held by the bulk freers, making the two paths mutually exclusive. The common case where the count does not reach zero remains lock-free. Defer kernfs_unbreak_active_protection() until after the mutex is dropped since kernfs active protections functionally wrap rdtgroup_mutex. Remove resource group, which in turn drops its kernfs reference, after kernfs protection is restored. [ bp: Split the commit messsages into smaller, easier-parseable paragraphs. ] Fixes: b8511ccc75c0 ("x86/resctrl: Fix use-after-free when deleting resource groups") Closes: https://sashiko.dev/#/patchset/20260515193944.15114-1-tony.luck%40intel.com?part=1 Reported-by: Sashiko Assisted-by: GitHub_Copilot:gemini-3.1-pro Signed-off-by: Reinette Chatre Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ben Horgan Reviewed-by: Tony Luck Link: https://patch.msgid.link/8d028bbea582dc382a4cc166b235f75bd5901aea.1783963505.git.reinette.chatre@intel.com Signed-off-by: Sasha Levin commit 65e55f34fb2d61cb4f8a5dfcb93848af2aea0f32 Author: Hans Verkuil Date: Mon Jun 29 08:47:05 2026 +0200 media: v4l2-async: Unregister sub-device if asc_list is empty [ Upstream commit 4e72f13d58c4245c177a9d5f54579345554f354d ] When my em28xx USB device that uses the i2c tvp5150 driver is disconnected, it crashes. The cause is that the tvp5150 i2c module uses v4l2_async, but the em28xx driver does not since it predates v4l2_async. In that corner case sd->asc_list is empty, so v4l2_async_unregister_subdev() never calls v4l2_device_unregister_subdev(). Modify the code so that, if sd->asc_list is empty, v4l2_device_unregister_subdev() is still called. Fixes: 28a1295795d8 ("media: v4l: async: Allow multiple connections between entities") Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Tested-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f0b084c9996060fd2cf784d13cd7c201065bfabe Author: Samuel Moelius Date: Sun Jun 28 15:23:32 2026 +0000 iommufd/selftest: Avoid selftest dirty bitmap size wrap [ Upstream commit 4132ba2ae2cf14c289e3fabc1c95ac244d643356 ] IOMMU_TEST_OP_DIRTY sizes its temporary dirty bitmap from length / page_size. Very large selftest ranges can make the DIV_ROUND_UP() additions wrap before allocation, producing a zero-length allocation while the later test_bit() loop still walks the original number of bits. The selftest helper does not need to support unbounded dirty bitmap sizes. Reject requests that would allocate more than SZ_16M for the temporary buffer. Fixes: 79ea4a496ab5 ("iommufd/selftest: Fix buffer read overrrun in the dirty test") Link: https://patch.msgid.link/r/20260628152331.82122.408afd7b466c.iommufd-test-dirty-bitmap-size-wrap@trailofbits.com Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit cd616aa0449a772a6956abf03358f0ff31720580 Author: Xiang Mei Date: Sun Jul 12 16:41:50 2026 -0700 isofs: fix out-of-bounds page array access on empty zisofs block [ Upstream commit 68d4d3e78150c7ed7d1195af63ad1e6ace30c661 ] zisofs_uncompress_block()'s empty-block fast path returns pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the decompression path which returns bytes produced relative to poffset. zisofs_fill_pages() uses that return to advance its page cursor, so when the zisofs block size is below PAGE_SIZE and a sub-page block leaves poffset partway into a page, a following empty block over-counts and advances pages[] one element past its end, after which "if (poffset && *pages)" reads pages[1] out of bounds. rock.c only rejects a block-size shift > 17, so a crafted "ZF" Rock Ridge record can set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a compressed file on such a mounted ISO9660 image. Return the byte count relative to poffset and zero only [poffset, PAGE_SIZE) of the first page, matching the decompression path. The page-aligned case (poffset == 0) is unaffected. BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290) Read of size 8 at addr ffff88800f5eac48 by task exploit/142 zisofs_read_folio (fs/isofs/compress.c:290) read_pages (mm/readahead.c:184) ... filemap_read (mm/filemap.c:2814) vfs_read (fs/read_write.c:574) __x64_sys_pread64 (fs/read_write.c:769) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address is located 0 bytes to the right of the allocated 8-byte region in the kmalloc-8 cache Fixes: 59bc055211b8 ("zisofs: Implement reading of compressed files when PAGE_CACHE_SIZE > compress block size") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260712234150.3213467-1-xmei5@asu.edu Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 81ff877e458e007a549f879842b05bf6a6f2fec7 Author: James Calligeros Date: Sat Jul 11 11:11:19 2026 +1000 ASoC: apple: mca: increase SERDES reset delay [ Upstream commit cccd721e5aab03e92234faee72b363c9ba60611c ] The SERDES clusters in this peripheral take a long time to warm up. We tried polling the reset bit until cleared, however this is not a reliable signal of readiness to be configured. Only waiting ~25 us to give the cluster a chance to settle makes it work reliably. Increase the 2 us delay to 25 us and hope we never have to do this again. Fixes: d8b3e396088d ("ASoC: apple: mca: Fix SERDES reset sequence") Signed-off-by: James Calligeros Link: https://patch.msgid.link/20260711-apple-audio-redux-v4-1-2994d87c2f24@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1b769e5d5c33c3008c42ab7985a7f46127555d9b Author: Leon Romanovsky Date: Mon Jul 13 07:41:25 2026 -0400 RDMA/hfi1: Initialize debugfs after probe completes [ Upstream commit bb18740b302f6f222ce3d5a7e5c45a52a90df805 ] Commit ed6f653fe430 ("staging/rdma/hfi1: Fix debugfs access race") moved debugfs creation after device initialization and IB registration so users cannot access the files before the driver is ready. However, init_one() still creates them before character device creation and SDMA startup finish. Move hfi1_dbg_ibdev_init() to the end of the successful probe path, matching hfi1_dbg_ibdev_exit() as the first action in remove_one(). Fixes: ed6f653fe430 ("staging/rdma/hfi1: Fix debugfs access race") Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-12-b9e9641268a5@nvidia.com Reviewed-by: Kalesh AP Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a913960dd85dc4244ae06d7b3eb5afba1d763ef4 Author: Leon Romanovsky Date: Mon Jul 13 07:41:25 2026 -0400 RDMA/hfi1: Stop flushing the global IB workqueue [ Upstream commit d43b1c17f9e1b9d34a0d742f569c00d84147ebc0 ] hfi1 does not queue work on ib_wq. QSFP and link work run on the per-port link_wq, while the remaining device work uses hfi1_wq or dedicated queues. The probe failure path destroys both per-port workqueues, and normal device removal flushes them in shutdown_device() before destroying them. Remove the flushes of the core-owned global workqueue. Waiting for unrelated core or other device work is not part of hfi1 teardown. Fixes: 71d47008ca1b ("IB/hfi1: Create workqueue for link events") Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-10-b9e9641268a5@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e32f985ea38aa9fe6f1cb35ab8e06084a6d5a186 Author: Leon Romanovsky Date: Mon Jul 13 07:41:24 2026 -0400 RDMA/hfi1: Create workqueues before device initialization [ Upstream commit 0d5618c1b2fc9dd4fc086f0226acd8a077ab6c1b ] create_workqueues() only needs fields set up by hfi1_alloc_devdata(). Call it before hfi1_init_dd() so a workqueue allocation failure happens before chip resources are initialized. To keep the reordered error paths safe, make init_one() own hfi1_devdata. hfi1_init_dd() unwinds its partial setup but leaves the allocation for the caller to free. If device initialization fails, destroy the workqueues before freeing the device data. Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-6-b9e9641268a5@nvidia.com Signed-off-by: Leon Romanovsky Stable-dep-of: 9f674ba674a0 ("RDMA/hfi1: Allocate device data after PCI initialization") Signed-off-by: Sasha Levin commit 460aaad5044d54b3741e94c95f6ede08719228b0 Author: Leon Romanovsky Date: Mon Jul 13 07:41:24 2026 -0400 RDMA/hfi1: Remove redundant PCI device ID validation [ Upstream commit af9117d02f50514c998714b23820de71d0aa5d24 ] The PCI core calls init_one() only after pci_match_device() has selected an ID. For normal probing, hfi1_pci_tbl already restricts matches to the two supported Intel device IDs. Dynamic IDs and driver_override are explicit requests to attempt binding, so the probe should not second-guess the PCI core's decision. Remove the redundant check. Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-3-b9e9641268a5@nvidia.com Signed-off-by: Leon Romanovsky Stable-dep-of: 9f674ba674a0 ("RDMA/hfi1: Allocate device data after PCI initialization") Signed-off-by: Sasha Levin commit 149a14ec70887ad14e820a7ca15738ded3d2d493 Author: Leon Romanovsky Date: Mon Jul 13 07:41:24 2026 -0400 RDMA/hfi1: Free RX data on late probe failure [ Upstream commit 8e17e101e04a3dc062e2719da57ff78c1c060632 ] hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning. If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears down the device data without calling hfi1_free_rx(). This leaks netdev_rx and its dummy netdev. Free the RX support after IB unregistration and before postinit_cleanup(), as done on normal device removal. Fixes: 4730f4a6c6b2 ("IB/hfi1: Activate the dummy netdev") Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-7-b9e9641268a5@nvidia.com Reviewed-by: Kalesh AP Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit fd4d3ad5f244a867166d1e2da7ece3d82878ec81 Author: Leon Romanovsky Date: Mon Jul 13 07:41:23 2026 -0400 RDMA/hfi1: Preserve unit 0 on allocation failure [ Upstream commit 2e3809ad8911f5d5581b3f046bd628417bface76 ] hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device. Fixes: 03b92789e5cf ("hfi1: Convert hfi1_unit_table to XArray") Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-2-b9e9641268a5@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 186df50ce26fb014665973bf30a46abbb4d5ae47 Author: Sean Rhodes Date: Mon Jul 6 16:40:43 2026 +0100 misc: rtsx_usb: avoid USB I/O in runtime autosuspend [ Upstream commit 483c948324a3823871c004560a92545759d3253c ] The runtime autosuspend callback currently queries card status and clears OCP by issuing USB register accesses. This can run from the USB runtime-PM path itself, which is the wrong place to start more device I/O. Keep a cached copy of the card-status bits from normal status reads instead. During runtime autosuspend, use that cached value only to preserve the existing Memory Stick autosuspend deferral. Do not treat raw SD_CD as an autosuspend blocker, because tray-based SD readers can assert SD_CD with an empty tray. A real SD card is protected by the SD/MMC child runtime-PM usage once powered. Also stop clearing OCP from the runtime autosuspend callback, so the callback does not issue USB commands. Fixes: bb400d2120bd ("mfd: rtsx_usb: Defer autosuspend while card exists") Signed-off-by: Sean Rhodes Acked-by: Greg Kroah-Hartman Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 1c1c2df09daacdd690421a706e3f80e2312fc7ce Author: Pengpeng Hou Date: Tue Jun 23 21:59:37 2026 +0800 pmdomain: bcm: bcm2835: handle genpd provider registration errors [ Upstream commit a1d9d3b958d69a13783613304f524f489fecdd1f ] bcm2835_power_probe() initializes all power domains and then registers the onecell genpd provider, but ignores of_genpd_add_provider_onecell() failures. Probe can therefore return success even though no provider was published. Check the provider registration return value and jump to the existing cleanup path on failure. Fixes: 670c672608a1 ("soc: bcm: bcm2835-pm: Add support for power domains under a new binding.") Signed-off-by: Pengpeng Hou Reviewed-by: Stefan Wahren Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 36cbb7249819a0427c8deb6280dfca48b826a4f3 Author: Evgenii Burenchev Date: Wed Jul 8 17:11:44 2026 +0300 ALSA: hpi: Check transport errors during HPI6000 adapter initialization [ Upstream commit cc15c329663e3ef1aeed0b68e49a5d5ce4ae0d5c ] create_adapter_obj() retrieves adapter information by calling hpi6000_message_response_sequence(). This function reports transport-level errors through its return value and DSP-reported errors via hr0.error. The current code only checks hr0.error, causing transport-level errors to be ignored. As a result, adapter initialization may continue with an invalid response. Check the return value of hpi6000_message_response_sequence() before examining hr0.error. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 719f82d3987a ("ALSA: Add support of AudioScience ASI boards") Signed-off-by: Evgenii Burenchev Link: https://patch.msgid.link/20260708141147.18253-1-evg28bur@yandex.ru Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0f679e0523ddfff3fb554336ceb874b0e51e9cd3 Author: Xiang Mei Date: Sat Jul 4 14:03:32 2026 -0700 xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full [ Upstream commit 5d9e3bf34fec9a5d237e4b7cef4a707bc2e091bc ] The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use "sp->len >= XFRM_MAX_DEPTH", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]' Fixes: 9473e1f631de ("[XFRM] MIPv6: Fix to input RO state correctly.") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit b0f7343a002f9c8b8378011f60482c76f3216dfd Author: Guangshuo Li Date: Sat Jul 4 19:25:09 2026 +0800 crash_dump: release keyring reference at the correct time [ Upstream commit ada2e5a44e99113e08ad9b7b71396c6c572204da ] restore_dm_crypt_keys_to_thread_keyring() gets a reference to the user keyring before restoring the saved dm-crypt keys. The same keyring reference is then passed to add_key_to_keyring() for each saved key, but add_key_to_keyring() drops that reference on every call. This is only balanced when exactly one key is restored. With multiple keys, the keyring reference is dropped too many times and may trigger a refcount underflow or use-after-free. When more than five keys are restored, a refcount underflow/use-after-free warning can be triggered. The early error paths after lookup_user_key() also return without dropping the keyring reference. Keep ownership of the keyring reference in restore_dm_crypt_keys_to_thread_keyring(), drop it once on all exit paths, and make add_key_to_keyring() only use the reference without consuming it. Fixes: 62f17d9df692 ("crash_dump: retrieve dm crypt keys in kdump kernel") Signed-off-by: Guangshuo Li Reviewed-and-tested-by: Coiby Xu Acked-by: Baoquan He Reviewed-by: Bradley Morgan Link: https://patch.msgid.link/20260704112509.3717884-1-lgs201920130244@gmail.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit c115b908e35084c104feb791ceacb9c72378d92f Author: Yuho Choi Date: Thu Jul 2 19:39:21 2026 -0400 hwrng: ks-sa - Fix runtime PM cleanup on registration failure [ Upstream commit 1c17b601fafb09c9ec074fd097737d20eafe7d63 ] ks_sa_rng_probe() enables runtime PM and resumes the device before registering the hwrng. If devm_hwrng_register() fails, probe returns without dropping the runtime PM usage count or disabling runtime PM. Unwind the runtime PM state on the registration failure path, matching the cleanup done by remove(). Fixes: eb428ee0e3ca ("hwrng: ks-sa - add hw_random driver") Signed-off-by: Yuho Choi Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4a52a2fb96d1006598fd130320401cfff8a91420 Author: Atish Patra Date: Tue Jun 2 15:36:35 2026 -0700 crypto: ccp - Fix memory leak in SEV INIT_EX path [ Upstream commit c8e53ada20d352b0f1bdc3e58405a9edab897a2e ] allocated pages in _init_ext_path are never freed and sev_init_ex_buffer is left pointing at the leaked memory in case of any failures during the function.. Fix by adding an error path that frees the pages and clears sev_init_ex_buffer. Make sure we only free the memory if the failure happens before the conversion. Otherwise, we may end up trying to free up converted pages in case of reclaim failure. rmp_mark_pages_firmware failures should be rare enough to avoid more code complexity to track down which pages were reclaimed/leaked vs which are not. Fixes: 7364a6fbca45 ("crypto: ccp: Handle non-volatile INIT_EX data when SNP is enabled") Reported-by: Sashiko Reviewed-by: Tom Lendacky Signed-off-by: Atish Patra Acked-by: Herbert Xu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 634e56b4f9913f6ae6fe7692032200060d3339f0 Author: Dmitry Baryshkov Date: Sun Jul 12 14:56:55 2026 +0300 Revert "drm/msm: dsi: fix PLL init in bonded mode" [ Upstream commit 44784327815b2a1ad8bb56b9236770cb538c7c27 ] Commit 93c97bc8d85d ("drm/msm: dsi: fix PLL init in bonded mode") fixed one of the issues with the DSI bonded mode, but broke non-bonded usecase for DSI as reported by Mohit Dsor. Clock divider is being programmed incorrectly, resultin in the wrong display mode being selected. Revert the offending commit, letting Neil to work on a better fix. Fixes: 93c97bc8d85d ("drm/msm: dsi: fix PLL init in bonded mode") Reported-by: Mohit Dsor Closes: https://lore.kernel.org/r/ae07cef84AmXK43H@hu-mdsor-hyd.qualcomm.com Cc: Neil Armstrong Cc: Thorsten Leemhuis Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/739459/ Link: https://lore.kernel.org/r/20260712-msm-revert-dsi-pll-fix-v1-1-40122689ea25@oss.qualcomm.com Signed-off-by: Sasha Levin commit 287f458ca2251c083417b358842292d520dcf057 Author: Jens Glathe Date: Mon Jun 8 06:54:39 2026 +0200 drm/msm/dp: add missing drm_edid_connector_update() before add_modes on cached EDID [ Upstream commit b7088d58dccfba87fe8dd2ab7c493ee1d9d09277 ] After the refactor to struct drm_edid, the fast path in msm_dp_panel_get_modes() that already held a cached EDID called drm_edid_connector_add_modes() directly without first calling drm_edid_connector_update(). The new API requires the update step to associate the EDID with the connector. Add the missing call. This restores correct behaviour for the cached-EDID path. Fixes: 5bea90ad9743 ("drm/msm/dp: switch to struct drm_edid") Reviewed-by: Dmitry Baryshkov Signed-off-by: Jens Glathe Patchwork: https://patchwork.freedesktop.org/patch/731125/ Link: https://lore.kernel.org/r/20260608-drm_plug_flaky_edid-v3-1-1ca632938e7f@oldschoolsolutions.biz Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 399713f1f0eac641351c8ceaec0ab8244ddcf78c Author: Allison Henderson Date: Sat Jul 11 09:54:19 2026 -0700 RDMA/rxe: Avoid reprocessing the current packet after the QP enters the error state [ Upstream commit 15ae32c4a3551c4c9da457370bdfdd65d171e512 ] When do_complete() finds the QP in the error state it returns RESPST_CHK_RESOURCE. Before commit 49dc9c1f0c7e ("RDMA/rxe: Cleanup reset state handling in rxe_resp.c") this was the flush loop: check_resource() had an error-state branch that fetched each remaining recv WQE and completed it with IB_WC_WR_FLUSH_ERR, without touching the current packet. That commit removed the error-state branch from check_resource() (draining is now done at rxe_receiver() entry) but kept the do_complete() error-state return. As a result, when a QP moves to the error state while a packet is being completed - e.g. an rdma_cm disconnect racing with receive processing - the responder state machine loops back into the request processing chain with the already-completed packet still in hand: check_resource() fetches a fresh recv WQE, execute()/send_data_in() copies the same packet payload again, do_complete() posts another IB_WC_SUCCESS CQE (qp->resp.status is still 0), and control returns to the error-state check. The loop re-executes the same packet once per posted recv WQE (observed: ~1000 duplicate IB_WC_SUCCESS completions of one SEND, one per ~8us, matching the RQ occupancy) until the RQ is exhausted, after which qp->resp.wqe is NULL and send_data_in() dereferences it: BUG: kernel NULL pointer dereference, address: 0000000000000014 Workqueue: rxe_wq do_work RIP: copy_data+0x29/0x1f0 Call Trace: send_data_in+0x25/0x50 rxe_receiver+0xf36/0x1dd0 The duplicate completions are indistinguishable from real receives to the ULP. During an rds stress test, the message was accepted as new and delivered the same datagram to user space hundreds of times, corrupting the stream; any ULP that relies on RC exactly-once delivery is affected. A live packet reaching the error-state check in do_complete() has been executed and completed exactly once and must be consumed, not re-processed. Return RESPST_CLEANUP for it (dequeue and free); keep returning RESPST_CHK_RESOURCE for the pkt == NULL case. Fixes: 49dc9c1f0c7e ("RDMA/rxe: Cleanup reset state handling in rxe_resp.c") Assisted-by: Claude-Code:claude-fable-5 Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260711165419.13486-1-achender@kernel.org Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8dc5ffcb8efcc01e44dd1ebc490eaae72de3fadf Author: Leon Romanovsky Date: Sun Jul 12 04:37:36 2026 -0400 RDMA/ipoib: Drain RCU callbacks during module teardown [ Upstream commit 31b7c700670830a0e8a4cdcd451c88a13cc5dc48 ] IPoIB reclamation completions can be signaled from inside an RCU callback. Teardown can wake before the callback returns and unload ib_ipoib while its code is still executing. Client registration failure can also remove already-added devices and queue callbacks. Wait after client and workqueue teardown. Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup in xmit path") Reported-by: Sebastian Andrzej Siewior Closes: https://lore.kernel.org/linux-rdma/20260708092316.Qb39F_B0@linutronix.de/ Link: https://patch.msgid.link/20260709-unload-rcu-v1-3-fccd27211e5a@nvidia.com Acked-by: Sebastian Andrzej Siewior Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 7babc25d8dd5b7642920fbc0737cfd1469e7025b Author: Leon Romanovsky Date: Sun Jul 12 04:37:36 2026 -0400 RDMA/mlx5: Drain RCU callbacks during module teardown [ Upstream commit e37cdd75f8d61c1123d324ae5667ac3da562290e ] devx_free_subscription() can remain queued after the last DevX event file drops its module reference or an auxiliary driver detaches its devices. mlx5_ib can then unload before the callback runs. Registration error unwind has the same risk because driver registration can attach existing devices before failing. Wait after all drivers have stopped. Fixes: 6898d1c661d7 ("RDMA/mlx5: Use RCU and direct refcounts to keep memory alive") Reported-by: Sebastian Andrzej Siewior Closes: https://lore.kernel.org/linux-rdma/20260708092316.Qb39F_B0@linutronix.de/ Link: https://patch.msgid.link/20260709-unload-rcu-v1-2-fccd27211e5a@nvidia.com Acked-by: Sebastian Andrzej Siewior Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9d998297fdaf47492f6679287f6552879d1a7e3a Author: Leon Romanovsky Date: Sun Jul 12 04:37:35 2026 -0400 RDMA/core: Wait for RCU callbacks before unloading ib_core [ Upstream commit 7d75592114d1664623c8cf191a12b38052c04483 ] put_gid_ndev() is queued with call_rcu() and implemented in ib_core. Stopping the workqueues does not drain callbacks already queued, so RCU could invoke it after the module code has been unloaded. synchronize_rcu() does not wait for callbacks. Wait for them after all producers have stopped. Fixes: 943bd984b108 ("RDMA/core: Allow detaching gid attribute netdevice for RoCE") Reported-by: Sebastian Andrzej Siewior Closes: https://lore.kernel.org/linux-rdma/20260708092316.Qb39F_B0@linutronix.de/ Link: https://patch.msgid.link/20260709-unload-rcu-v1-1-fccd27211e5a@nvidia.com Acked-by: Sebastian Andrzej Siewior Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 0e5c6bf4a04c8544de4f8725c5e03cbca1bba69f Author: Mert Seftali Date: Fri Jul 10 10:36:23 2026 +0200 iio: accel: dmard09: Implement IIO_CHAN_INFO_SCALE [ Upstream commit aa58ecc73466d0cb8c418de98e2225490bf600e3 ] Reading the in_accel_scale attribute on the DMARD09 has always returned -EINVAL: the channels advertise scale via info_mask_shared_by_type so the IIO core exposes the attribute, but dmard09_read_raw() only handles IIO_CHAN_INFO_RAW, so a SCALE read falls through to 'default: return -EINVAL': $ cat .../iio:deviceX/in_accel_scale cat: in_accel_scale: Invalid argument leaving userspace with raw counts it cannot convert to m/s^2. The driver was written from a vendor source [1] without a datasheet, and the scale was declared but never implemented. The vendor source carries the sensitivity: its conversion is acc = raw * GRAVITY_EARTH_1000 / sensitivity (then / 1000 -> m/s^2) with sensitivity = 32 and GRAVITY_EARTH_1000 = 9807 ("about (9.80665)*1000"), i.e. 32 counts correspond to 1 g. That sensitivity applies to the value this driver already reports as raw: the vendor reduces each 16-bit sample to a signed 9-bit value, and the preparation in dmard09_read_raw() yields the same value. It is self-consistent: 256 counts / 32 = 8 g full scale, matching the +/-8g range. Implement the scale derived from that sensitivity using standard gravity: scale = 9.80665 / 32 = 0.3064578125 m/s^2 per LSB Link: https://github.com/minstrelsy/mediatek/blob/1f49d8c87b839651bc89afc870277e8e0f2e2d55/custom/common/kernel/accelerometer/dmard09/dmard09.c [1] Fixes: a4fa6509dda4 ("iio: accel: add support for the Domintech DMARD09 3-axis accelerometer") Signed-off-by: Mert Seftali Reviewed-by: Joshua Crofts Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit dbe8894db922c458485b8de8f4f022425643a67f Author: Chih-Kang Chang Date: Tue Jul 7 17:10:53 2026 +0800 wifi: rtw89: 8852a: fix RSSI report when average beacon RSSI is not ready [ Upstream commit 9bf6bd6ed5accb57544d04ded911a2ef1642d48f ] 8852A uses the average beacon RSSI to smooth the RSSI. However, before the average beacon RSSI is available, the RSSI should use the PPDU status RSSI of the received packet to avoid reporting the RSSI as -110 dBm. Fixes: f0f3bf4b370c ("wifi: rtw89: 8852a: report average RSSI to avoid unnecessary scanning") Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260707091056.42771-13-pkshih@realtek.com Signed-off-by: Sasha Levin commit 6e4b73b6b743d7bc9fd9fb784dbd092f6e26a3bb Author: Kuan-Chung Chen Date: Wed Apr 29 21:26:20 2026 +0800 wifi: rtw89: phy: support per PHY RX statistics [ Upstream commit 09d369c66373de8708e442a30460ced17f254915 ] Previously, RX statistics such as beacon RSSI and packet counters were shared across all PHYs. To support MLO, extend the statistics to be maintained per PHY. Update the debugfs output for phy_info and beacon_info to include a "[PHY X]" label for better clarity. The output of phy_info: TP TX: 0 [0] Mbps (lv: 0), RX: 0 [0] Mbps (lv: 0) Avg packet length: TX=0, RX=120 TF: 0 [PHY 0] Beacon: 19 (-45 dBm) RX count: Legacy: [0, 0, 0, 0] ... EHT 2SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] The output of beacon_info: [PHY 0] Beacon: 20 raw rssi: 131 hw rate: 4 length: 437 [Beacon info] interval: 100 dtim: 1 Signed-off-by: Kuan-Chung Chen Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260429132625.1659182-3-pkshih@realtek.com Stable-dep-of: 9bf6bd6ed5ac ("wifi: rtw89: 8852a: fix RSSI report when average beacon RSSI is not ready") Signed-off-by: Sasha Levin commit 0bae3ec6a16a9ac0f4f44e27ddac88726c6754d2 Author: Kuan-Chung Chen Date: Wed Apr 29 21:26:19 2026 +0800 wifi: rtw89: mlo: rearrange MLSR link decision flow [ Upstream commit 7284f5be5d298c901be1fc9fda6a2476f5ffdbaf ] The original MLSR link decision refers to RSSI, but it should be based on the premise of an existing link. Otherwise, make a link decision to select a new link from any available band. Signed-off-by: Kuan-Chung Chen Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260429132625.1659182-2-pkshih@realtek.com Stable-dep-of: 9bf6bd6ed5ac ("wifi: rtw89: 8852a: fix RSSI report when average beacon RSSI is not ready") Signed-off-by: Sasha Levin commit e0abd0b1e2f561a11553f2f79d661e0ca27ae454 Author: Ping-Ke Shih Date: Tue Nov 11 10:24:47 2025 +0800 wifi: rtw89: debug: add parser to diagnose along DIAG_MAC fw element [ Upstream commit 7bf433c6767ffe2ad5b7ac8680c6e93e7d0be3e4 ] The rules to diagnose MAC have a common header, and a cmd field is used to know the exact command and its format. The rules with the same tuple of fields {sheet, seq} can be seen as a set of compound rules, which treat it as positive rule if just one of the rules is positive. Take EQUALV rules as example, if value of {addr, mask} is equal to predefined value as field val, a rule is positive. Fields addr_name_offset and msg_offset are offsets related to textual messages for human readable. Format of common rule header (8 bytes) +-------+-----+--------+-----------+-----+---------+ | sheet | cmd | seq[2] | io / band | len | rsvd[2] | +-------+-----+--------+-----------+-----+---------+ Format of rule command is EQUALV (equal value) (24 bytes): +------+------------------+------+-----+------------+---------+ | addr | addr_name_offset | mask | val | msg_offset | rsvd[4] | +------+------------------+------+-----+------------+---------+ Format of message: +-----+----------+ | len | string[] | +-----+----------+ An example of output: Plain(Ignore)/Rules/Positive: 115(4)/86/81 Where, Plain is total rules written in firmware element. Ignore is the ignored rules, such as USB IO, but current is PCIE. Rules is number of set of compound rules. Positive is number of positive Rules. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251111022452.28093-4-pkshih@realtek.com Stable-dep-of: 9bf6bd6ed5ac ("wifi: rtw89: 8852a: fix RSSI report when average beacon RSSI is not ready") Signed-off-by: Sasha Levin commit 84cb2ae9c01238f8d9089372b9be048f25235fec Author: Ping-Ke Shih Date: Tue Nov 11 10:24:46 2025 +0800 wifi: rtw89: fw: parse firmware element of DIAG_MAC [ Upstream commit de19cc7def5a9c646264a1e7a2a183a3baad112f ] The firmware element ID 28 is a set of rules to diagnose if MAC get abnormal. The latter patch will use these rules via debugfs to know the status. The element contains rules with their textual messages shown as below: +------------------------------------+ | | | +-----------+ | | | rule_size |-------|----------+ +----------------+-----------+-------+ -- | | rule[0] | \ | | rule[1] | | <---+ | : | / +------------------------------------+ -- | msg[0] msg[1] | each msg has variable length | msg[2] msg[3] ... | (with address align 2) | ... | +------------------------------------+ Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251111022452.28093-3-pkshih@realtek.com Stable-dep-of: 9bf6bd6ed5ac ("wifi: rtw89: 8852a: fix RSSI report when average beacon RSSI is not ready") Signed-off-by: Sasha Levin commit f345b7d23c6f0e3c6e9c20e5346d3fb632921524 Author: Ping-Ke Shih Date: Tue Nov 11 10:24:45 2025 +0800 wifi: rtw89: pci: add to read PCI configuration space from common code [ Upstream commit dae8d7d63b740d8f5972b8438b139a6488e0f9fa ] Normally only access PCI device in pci.c. However for debug purpose, a set of registers predefined in firmware element including PCI configuration space should be read for diagnosis. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251111022452.28093-2-pkshih@realtek.com Stable-dep-of: 9bf6bd6ed5ac ("wifi: rtw89: 8852a: fix RSSI report when average beacon RSSI is not ready") Signed-off-by: Sasha Levin commit 0cfc9348a045da64955af2dd6902e66dfc7d6469 Author: Nicholas Dudar Date: Thu Jul 9 14:27:59 2026 -0400 bpf: Require a BPF cpumask for bpf_cpumask_populate() [ Upstream commit 8740156ad33be5071b588b594c55f279457f667c ] bpf_cpumask_populate() writes to its destination with bitmap_copy(), but the destination is typed as struct cpumask *. That allows the verifier to accept borrowed cpumask pointers returned by read-only kfuncs, such as scx_bpf_get_online_cpumask(), as a writable destination. Make the destination a struct bpf_cpumask * so populate follows the same ownership rule as the other mutating cpumask kfuncs. Query kfuncs continue to accept const struct cpumask * inputs. Fixes: 950ad93df2fc ("bpf: add kfunc for populating cpumask bits") Signed-off-by: Nicholas Dudar Acked-by: Tejun Heo Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/20260709182800.2037938-2-main.kalliope@gmail.com Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit abe7ac019ad99bdbd71301ff4517026dac560b42 Author: Tejun Heo Date: Mon Oct 6 15:51:44 2025 -1000 tools/sched_ext: Strip compatibility macros for cgroup and dispatch APIs [ Upstream commit 111a79800aeda615797f20b3a00ef116edce9e03 ] Enough time has passed since the introduction of scx_bpf_task_cgroup() and the scx_bpf_dispatch* -> scx_bpf_dsq* kfunc renaming. Strip the compatibility macros. Acked-by: Changwoo Min Acked-by: Andrea Righi Reviewed-by: Emil Tsalapatis Signed-off-by: Tejun Heo Stable-dep-of: 8740156ad33b ("bpf: Require a BPF cpumask for bpf_cpumask_populate()") Signed-off-by: Sasha Levin commit 9257ece49ae727495d90cd9f10e0c2082ada238c Author: Brian Masney Date: Wed Jul 8 18:30:06 2026 -0400 clk: qcom: camcc-sc8280xp: unregister CAMCC_GDSC_CLK [ Upstream commit 499b4cb6710f9a351d8b57a2132f9b4389d8464a ] With the introduction of sync_state support in the clk and pmdomain subsystems, the following warning happens when the unused clocks are shutdown in camcc-sc8280xp: [ 15.408367] titan_top_gdsc status stuck at 'on' [ 15.408429] WARNING: drivers/clk/qcom/gdsc.c:178 at gdsc_toggle_logic+0x14c/0x160, CPU#2: kworker/u32:1/14 [ 15.408462] Modules linked in: bnep vfat fat ath11k_pci(+) ath11k mac80211 cfg80211 mhi libarc4 snd_soc_wcd938x snd_soc_wcd938x_sdw snd_soc_wcd_classh hci_uart snd_soc_wcd_common snd_soc_sc8280xp soundwire_qcom snd_soc_wcd_mbhc snd_soc_qcom_sdw slimbus snd_soc_qcom_common regmap_sdw btqca btrtl qcom_camss soundwire_bus btbcm btintel snd_soc_sdca snd_soc_lpass_wsa_macro bluetooth snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_rx_macro snd_soc_hdmi_codec snd_soc_lpass_macro_common videobuf2_dma_sg ov5675 v4l2_fwnode videobuf2_memops qcom_spmi_adc5 snd_soc_core qcom_spmi_adc_tm5 videobuf2_v4l2 snd_seq snd_seq_device videobuf2_common v4l2_async qcom_vadc_common qcom_spmi_temp_alarm pm8941_pwrkey industrialio videodev snd_compress rfkill ac97_bus snd_pcm_dmaengine qcom_tsens mc qcom_edac snd_pcm pci_pwrctrl_pwrseq qcom_cpufreq_hw snd_timer snd qcomtee soundcore tee leds_gpio joydev binfmt_misc zram lz4hc_compress governor_simpleondemand panel_edp msm xhci_plat_hcd nvme nvme_core dwc3 qcom_pm8008_regulator [ 15.408688] ucsi_glink nvme_keyring nvme_auth pmic_glink_altmode udc_core typec_ucsi aux_hpd_bridge qcom_battmgr ulpi ubwc_config socinfo ocmem drm_gpuvm qcom_q6v5_pas drm_exec qcom_pil_info leds_qcom_lpg gpu_sched led_class_multicolor rtc_pm8xxx qcom_pbs qcom_common drm_display_helper qcom_pon qcom_glink_smem qcom_glink ghash_ce pwrseq_qcom_wcn gpio_sbu_mux qcom_stats phy_qcom_qmp_combo qcom_q6v5 gf128mul cec dispcc_sc8280xp phy_qcom_edp camcc_sc8280xp i2c_qcom_cci qcom_sysmon drm_dp_aux_bus mdt_loader aux_bridge qcom_pm8008 i2c_hid_of_elan dwc3_qcom_legacy llcc_qcom icc_bwmon gpi typec qcom_refgen_regulator phy_qcom_qmp_usb nvmem_qfprom qcom_ipcc phy_qcom_snps_femto_v2 gpucc_sc8280xp pinctrl_sc8280xp_lpass_lpi qcom_hwspinlock pinctrl_lpass_lpi lpasscc_sc8280xp qrtr qcom_aoss pmic_glink pdr_interface phy_qcom_qmp_pcie qcom_smd qcom_pdr_msg icc_osm_l3 qcom_wdt qmi_helpers qcom_rng smp2p rpmsg_core gpio_keys pwm_bl smem hid_multitouch fuse i2c_dev [ 15.408928] CPU: 2 UID: 0 PID: 14 Comm: kworker/u32:1 Not tainted 7.1.0+ #2 PREEMPT(lazy) [ 15.408937] Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET88W (1.60 ) 03/14/2024 [ 15.408942] Workqueue: pm pm_runtime_work [ 15.408959] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 15.408967] pc : gdsc_toggle_logic+0x14c/0x160 [ 15.408978] lr : gdsc_toggle_logic+0x14c/0x160 [ 15.408987] sp : ffff8000800f3b40 [ 15.408991] x29: ffff8000800f3b40 x28: 0000000000000000 x27: 0000000000000000 [ 15.409003] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 15.409014] x23: 0000000000000000 x22: 0000000000000001 x21: ffffa33f298fca88 [ 15.409024] x20: 0000000000000000 x19: ffffa33f298fc5b0 x18: 00cd15db75dacefd [ 15.409035] x17: 000000040044ffff x16: ffffa33f3b1a3d88 x15: 726f776b80000002 [ 15.409045] x14: ffffffffffffffff x13: 0000000000000028 x12: 0101010101010101 [ 15.409056] x11: 7f7f7f7f7f7f7f7f x10: fefeff3039313274 x9 : ffffa33f3a5edafc [ 15.409067] x8 : ffff8000800f3780 x7 : 0000000000000001 x6 : 0000000000000001 [ 15.409078] x5 : ffff000bf3ca1288 x4 : 0000000000000000 x3 : ffff5cccb6a3f000 [ 15.409088] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000080ae0000 [ 15.409098] Call trace: [ 15.409103] gdsc_toggle_logic+0x14c/0x160 (P) [ 15.409115] gdsc_disable+0x4c/0x190 [ 15.409126] _genpd_power_off+0xa0/0x1a8 [ 15.409137] genpd_power_off.part.0+0x180/0x2a0 [ 15.409149] genpd_runtime_suspend+0x218/0x310 [ 15.409155] __rpm_callback+0x50/0x1f8 [ 15.409166] rpm_callback+0x7c/0x90 [ 15.409175] rpm_suspend+0xe8/0x690 [ 15.409185] pm_runtime_work+0xd0/0xe0 [ 15.409195] process_one_work+0x18c/0x518 [ 15.409208] worker_thread+0x190/0x320 [ 15.409218] kthread+0x110/0x130 [ 15.409227] ret_from_fork+0x10/0x20 This clock is force enabled to be on in the probe, and registered with the Common Clk Framework, resulting in them being toggled off after unused clocks are shutdown. This clock is required for the GDSC transitions. Similar to the fix in commit b60521eff227 ("clk: qcom: gcc-x1e80100: Unregister GCC_GPU_CFG_AHB_CLK/GCC_DISP_XO_CLK"), let's just unregister this clock. Link: https://lore.kernel.org/linux-clk/20260626-camcc-sc8280xp-titan-top-v1-1-2ca246886493@redhat.com/ Fixes: ff93872a9c616 ("clk: qcom: camcc-sc8280xp: Add sc8280xp CAMCC") Suggested-by: Jagadeesh Kona Signed-off-by: Brian Masney Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20260708-camcc-sc8280xp-remove-gdsc-v1-1-dfaab98a3bf5@redhat.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 086ac3881a8c2914ff53ab697592d017f87218d7 Author: Pengpeng Hou Date: Tue Jun 23 09:54:15 2026 +0800 bus: qcom-ebi2: use managed resources for clocks and children [ Upstream commit d19a46f7ed8eb54fea61e0eaf7db53ff7babb03c ] qcom_ebi2_probe() enables the EBI2 clocks manually and populates child devices manually. Several later failure paths can then return without disabling the clocks or without relying on the driver core to undo child population. Use devm_clk_get_enabled() for both clocks and devm_of_platform_populate() for children. This lets the driver core unwind the resources automatically and removes the hand-written error labels. Fixes: 335a12754808 ("bus: qcom: add EBI2 driver") Signed-off-by: Pengpeng Hou Reviewed-by: Konrad Dybcio Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20260623015415.26975-1-pengpeng@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 03991f9a561ce517ed11df1d639519505cd71bbd Author: Pengpeng Hou Date: Tue Jun 23 09:55:01 2026 +0800 soc: qcom: rpmh-rsc: manage PM notifiers with devres [ Upstream commit 75e918aa876440d8ad559a11d6ab87bddb1ed79a ] rpmh_rsc_probe() registers CPU PM or genpd notifiers before populating child devices. If child population fails, the CPU PM notifier path is not unwound and the genpd path needs open-coded cleanup. Use devm_pm_runtime_enable() for the genpd path and devm_add_action_or_reset() for both notifier registrations. This makes probe failure and driver detach use the same cleanup model while keeping devm_of_platform_populate() responsible for child devices. Fixes: 25092e6100ac ("soc: qcom: rpmh-rsc: Attach RSC to cluster PM domain") Signed-off-by: Pengpeng Hou Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260623015501.31129-1-pengpeng@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit dae798b9503881cb8f6612535c4c09fdfb143e08 Author: Yu Peng Date: Tue Jun 2 16:11:04 2026 +0800 perf metricgroup: Fix metric expression copy leaks [ Upstream commit ef3af1df4f3372bd8ad47619452a283048b3bc8d ] metricgroup__copy_metric_events() allocates a new metric expression and duplicates metric_name before linking the expression into the destination metric event. Free new_expr when strdup() fails, and free the duplicated metric_name on the later error paths. Fixes: b85a4d61d302 ("perf metric: Allow modifiers on metrics") Signed-off-by: Yu Peng Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 846ce4d3fda94a0718b145b6c23ad153bc5b71b8 Author: Laxman Acharya Padhya Date: Sat Jul 4 12:51:48 2026 +0545 drm/panel: samsung-s6d16d0: Power off on prepare failure [ Upstream commit a9f950adfe2147318d75e7a6eab5e814851802ac ] If enabling tearing mode or exiting sleep mode fails after the regulator is enabled, s6d16d0_prepare() returns without asserting reset or disabling the supply. Since the DRM panel core leaves the panel unprepared, a later unprepare call skips the driver callback and the supply remains enabled. Assert reset and disable the supply before returning the DSI command error. Fixes: ac1d6d74884e ("drm/panel: Add driver for Samsung S6D16D0 panel") Assisted-by: Codex:gpt-5 Signed-off-by: Laxman Acharya Padhya Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260704070648.35249-1-acharyalaxman8848@gmail.com Signed-off-by: Sasha Levin commit 39b000d393dea0763921bcec6ce845d5caf07075 Author: Pengpeng Hou Date: Thu Jul 9 20:32:39 2026 +0800 usb: typec: ucsi: gaokun: unwind notifier on UCSI register failure [ Upstream commit 2c5659a7064e7c4c0c51eb9356bcf6726a85773b ] gaokun_ucsi_register_worker() registers the EC notifier before calling ucsi_register(). If ucsi_register() fails, the worker currently only logs the error and leaves the notifier registered. Later EC events can then call into an unpublished UCSI instance. The remove path also unconditionally unregisters both the EC notifier and the UCSI device even if the delayed worker failed before both publication steps completed. Unregister the notifier immediately when ucsi_register() fails, and track only the fully published state. The remove path then tears down the pair only if both publication steps completed. Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver") Reviewed-by: Heikki Krogerus Reviewed-by: Pengyu Luo Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260709123239.62930-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7f2d926a464bba96c41e11b71eee6477fb381410 Author: Pengyu Luo Date: Sun Jun 7 18:18:44 2026 +0800 usb: ucsi: huawei_gaokun: support mode switching [ Upstream commit 1c2b66a7d7257d2652aa41f9a860ecb96dde27dd ] The USB PHY (QMP Combo PHY) is always initialized in USB3+DP mode. In the past, there was no MUX, and it was unnecessary to set it, since MSM only supported 2-lane DP. But now, MST and 4-lane DP support has been added to MSM, and a MUX has been added to the PHY. To support 4-lane DP and mode switching for gaokun, get the MUX and set it. Signed-off-by: Pengyu Luo Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260607101844.820064-1-mitltlatltl@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 2c5659a7064e ("usb: typec: ucsi: gaokun: unwind notifier on UCSI register failure") Signed-off-by: Sasha Levin commit 6b0d4519bcf0925a4d8d01e59739499612ecf0f4 Author: Biju Das Date: Thu Jul 2 08:38:29 2026 +0100 usb: renesas_usbhs: Fix power-off ordering on unbind [ Upstream commit 589b9e6f96be6bd8dd0d45fda8e948c31dc2fe94 ] Move the usbhsc_power_ctrl() call to before hardware_exit() and reset_control_assert() in usbhs_remove(), so the PHY is powered off while priv->phy is still valid, rather than after hardware_exit() has already cleared it. Fixes: eb9ac779830b ("usb: renesas_usbhs: Fix synchronous external abort on unbind") Signed-off-by: Biju Das Link: https://patch.msgid.link/20260702073832.175047-1-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f0cfba808e632c2e824f2743924090bb8e770faa Author: Fei Shao Date: Fri Jun 26 16:21:51 2026 +0800 usb: mtu3: allow system suspend during active gadget connection [ Upstream commit e69027c25361b6044c7928715667586cc5469063 ] When operating in gadget mode connected to a USB host, system suspend fails with -EBUSY because active peripheral connections block suspend entry. Fix this by restricting the -EBUSY check to runtime autosuspend (PMSG_IS_AUTO). For system suspend (!PMSG_IS_AUTO), perform soft disconnect to disconnect from the bus and allow MAC sleep. Fixes: 427c66422e14 ("usb: mtu3: support suspend/resume for device mode") Signed-off-by: Fei Shao Link: https://patch.msgid.link/20260626082218.2750459-2-fshao@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7fea5a310e3b2db24f7aafe64897e4e659ffbb7d Author: Linmao Li Date: Mon Jul 6 09:25:11 2026 +0800 platform/surface: acpi-notify: Check ACPI companion before use [ Upstream commit 2b3a5dabe89e330413af403246b648c1890f368f ] Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 ("ACPI: driver: Check ACPI_COMPANION() against NULL during probe") does for the core ACPI platform drivers. Fixes: a9e10e587304 ("ACPI: scan: Extend acpi_walk_dep_device_list()") Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260706012512.524359-2-lilinmao@kylinos.cn Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 71ba8b6e28f7a83b724036f5de07e03bb5473286 Author: Linmao Li Date: Mon Jul 6 09:20:56 2026 +0800 platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL [ Upstream commit c38cce70adef874c2a7b5132c14d6c221401deff ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing. Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260706012056.524096-1-lilinmao@kylinos.cn Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 7e795801295c84a6bbc10a3e7a4c99c50bfe45ac Author: Gary Guo Date: Tue Jul 7 13:26:46 2026 +0100 usb: fix UAF when probe runs concurrent to dyn ID removal [ Upstream commit ef8154d8b52d60338c1fd8d793cd8e891c604c14 ] Dynamic IDs are only guaranteed to be valid when usb_dynids_lock is held, as remove_id_store can free the node. Thus, make a copy in usb_probe_interface. Clarify the documentation that the id parameter is only valid during the probe. USB serial has the same pattern, but it does not need fixing as the IDs cannot be removed via sysfs. Fixes: 0c7a2b72746a ("USB: add remove_id sysfs attr for usb drivers") Signed-off-by: Gary Guo Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-7-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ff6e88e29965bd06f640e59acdcf0bbf04a7f55c Author: Ruoyu Wang Date: Wed Jun 10 20:10:22 2026 +0800 usb: gadget: aspeed_udc: check endpoint DMA allocation [ Upstream commit 97cee53a94be3bd4fd8fbed6071bd2f32dad1ab1 ] ast_udc_probe() allocates a coherent DMA buffer used as the backing store for endpoint buffers. ast_udc_init_ep() derives per-endpoint buffer pointers from udc->ep0_buf, so a failed allocation is dereferenced during probe. Check the allocation before endpoint setup. The existing probe error path called ast_udc_remove(), which unregisters the gadget unconditionally and is not safe before usb_add_gadget_udc() succeeds. Add a local cleanup helper for probe failures so pre-registration failures only unwind the resources that were actually initialized. This was found by a local static analysis checker for unchecked allocator returns while scanning Linux 6.16. The change was checked by applying it to current mainline and by running checkpatch. I do not have access to Aspeed UDC hardware, so no runtime testing was performed. Fixes: 055276c13205 ("usb: gadget: add Aspeed ast2600 udc driver") Signed-off-by: Ruoyu Wang Reviewed-by: Andrew Jeffery Link: https://patch.msgid.link/20260610121022.3-1-ruoyuw560@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit aed958c4f784a29cf42abb3e54af51a16bddde46 Author: Maoyi Xie Date: Thu Jun 18 14:19:48 2026 +0800 usb: ljca: bound bank_num in ljca_enumerate_gpio() [ Upstream commit dd9483726d0f16c1a56879c3edb65128259a4e2b ] ljca_enumerate_gpio() reads desc->bank_num from the device and loops valid_pin[i] = get_unaligned_le32(...) for i < bank_num. valid_pin[] holds only LJCA_MAX_GPIO_NUM / 32 = 2 entries. Two checks run before the loop. The reply length must match struct_size(desc, bank_desc, bank_num). The product pins_per_bank * bank_num must not exceed LJCA_MAX_GPIO_NUM. Neither one bounds bank_num against the size of valid_pin[]. The reply is capped at LJCA_MAX_PAYLOAD_SIZE (60) bytes, so the struct_size check limits bank_num to 9. A device that reports bank_num 9 with pins_per_bank 7 still passes both checks. gpio_num is 63 and the reply is 56 bytes. The loop then writes nine u32 into the two entry array and overruns valid_pin[] on the stack. A broken or malicious LJCA device can therefore overflow the stack. Reject a bank_num that does not fit valid_pin[]. Fixes: acd6199f195d ("usb: Add support for Intel LJCA device") Signed-off-by: Maoyi Xie Acked-by: Sakari Ailus Link: https://patch.msgid.link/178176358875.3352358.6059116660356914900@maoyixie.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit afbf39c0f2297c6abef6d670a82a2079b0836191 Author: Michael Bommarito Date: Wed Jun 17 20:50:43 2026 -0400 usb: gadget: configfs: fix out-of-bounds read of qw_sign [ Upstream commit f63edb54d8f738f9c21e2068c777ae1c097df6b7 ] os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions. Fixes: 76180d716f91 ("usb: gadget: configfs: make qw_sign attribute symmetric") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260618005043.1581707-1-michael.bommarito@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5fd8baacc7dc477df9cac61b45491840247a9b1e Author: Nuno Sá Date: Fri Jun 12 15:57:57 2026 +0100 usb: gadget: f_fs: Fix fence cleanup in ffs_dmabuf_transfer() error paths [ Upstream commit 621707dc67c9846fd876d7579ec951d92aa033f1 ] The error paths for endpoint-disabled (ESHUTDOWN) and request-allocation failure (ENOMEM) in ffs_dmabuf_transfer() jump to err_fence_put which calls dma_fence_put() on the fence. However, at that point the fence has only been kmalloc'd — dma_fence_init() has not been called yet, so the refcount and the fence ops are uninitialized. Calling dma_fence_put() on such an object leads to undefined behavior. Use kfree() instead, since the fence is just a plain allocation at this stage, and rename the label to err_fence_free to reflect the actual cleanup action. Fixes: 7b07a2a7ca02 ("usb: gadget: functionfs: Add DMABUF import interface") Signed-off-by: Nuno Sá Reviewed-by: Paul Cercueil Link: https://patch.msgid.link/20260612-fix-f_fs-fence-cleanup-v1-1-79f489b0efe9@analog.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c02d030747c46da33faf406dd772ef91100efa27 Author: Guangshuo Li Date: Wed Jul 8 21:17:26 2026 +0800 serial: qcom-geni: do not advance stale DMA completions [ Upstream commit 7ea38c49e7178960926657863299face6dc0e1b0 ] The qcom GENI serial DMA TX completion path advances the transmit fifo by the number of bytes recorded in port->tx_remaining. If uart_flush_buffer() runs after the hardware has completed a DMA transfer but before the DMA completion interrupt has been handled, the serial core resets the transmit fifo while port->tx_remaining still describes the old DMA transfer. A previous fix avoided advancing an empty fifo by checking that the fifo length is at least tx_remaining. That still does not distinguish the old DMA payload from new bytes written after the flush. If userspace writes new data before the stale DMA completion interrupt is handled, the fifo can again contain at least tx_remaining bytes and the stale completion can advance and discard those new bytes. Mark an in-flight DMA transfer stale when the transmit fifo is flushed. The later completion still unprepares the original DMA mapping using the saved length, but it no longer advances the transmit fifo. Fixes: 2aaa43c70778 ("tty: serial: qcom-geni-serial: add support for serial engine DMA") Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260708131726.768692-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 783961be18f5cb82a0ab294fa95b51e8bcb4f56d Author: Yuho Choi Date: Tue Jun 30 17:40:43 2026 -0400 serial: ma35d1: Fix OF node reference leaks in console init [ Upstream commit 8dfea56f350b3dc826f35711802ad6ae8fae0748 ] ma35d1serial_console_init_port() stores matching UART device nodes in ma35d1serial_uart_nodes[] with an extra of_node_get() so that console setup can later read the "reg" property. However, the stored references are never released after console setup has finished using them. Drop the stored node reference after ma35d1serial_console_setup() reads the "reg" property, and clear the array slot to avoid leaving a stale pointer behind. Also release the iterator reference before breaking out of for_each_matching_node(), since the normal iterator advance will not run in that path. Fixes: 930cbf92db01 ("tty: serial: Add Nuvoton ma35d1 serial driver support") Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260630214043.1887351-1-dbgh9129@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4e2a433822524a18f2c82e08685aade411097ad6 Author: Fushuai Wang Date: Fri May 22 18:10:42 2026 +0800 serial: 8250: Clear CON_PRINTBUFFER on port re-registration [ Upstream commit d338ab1d90603f875c4f7ed223406535378173a5 ] When two PnP devices map to the same physical port, the serial8250 driver removes and re-registers the console structure for the same port. During re-registration, the console structure still has CON_PRINTBUFFER set from the initial registration, which causes console_init_seq() to set console->seq to syslog_seq. This results in re-printing the entire system log buffer, which may lead to RCU stall on slow serial consoles. Clear CON_PRINTBUFFER when re-registering a port to prevent duplicate log printing. Fixes: 835d844d1a28 ("8250_pnp: do pnp probe before legacy probe") Suggested-by: Greg Kroah-Hartman Signed-off-by: Fushuai Wang Link: https://patch.msgid.link/20260522101042.21976-1-fushuai.wang@linux.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 45c64f2c09b2d43e8da8b3ec6b5ca8e8844fc455 Author: John Ogness Date: Mon May 11 17:33:02 2026 +0206 serial: 8250: Add support for console flow control [ Upstream commit 5e6dfb87b191f34b1bb7cfb4d668665e5b70687b ] The kernel documentation specifies that the console option 'r' can be used to enable hardware flow control for console writes. The 8250 driver does include code for hardware flow control on the console if cons_flow is set, but there is no code path that actually sets this. However, that is not the only issue. The problems are: 1. Specifying the console option 'r' does not lead to cons_flow being set. 2. Even if cons_flow would be set, serial8250_register_8250_port() clears it. 3. When the console option 'r' is specified, uart_set_options() attempts to initialize the port for CRTSCTS. However, afterwards it does not set the UPSTAT_CTS_ENABLE status bit and therefore on boot, uart_cts_enabled() is always false. This policy bit is important for console drivers as a criteria if they may poll CTS. 4. Even though uart_set_options() attempts to initialize the port for CRTSCTS, the 8250 set_termios() callback does not enable the RTS signal (TIOCM_RTS) and thus the hardware is not properly initialized for CTS polling. 5. Even if modem control was properly setup for CTS polling (TIOCM_RTS), uart_configure_port() clears TIOCM_RTS, thus breaking CTS polling. 6. wait_for_xmitr() and serial8250_console_write() use cons_flow to decide if CTS polling should occur. However, the condition should also include a check that it is not in RS485 mode and CRTSCTS is actually enabled in the hardware. Address all these issues as conservatively as possible by gating them behind checks focussed on the user specifying console hardware flow control support and the hardware being configured for CTS polling at the time of the write to the UART. Since checking the UPSTAT_CTS_ENABLE status bit is a part of the new condition gate, these changes also support runtime termios updates to disable/enable CRTSCTS. Signed-off-by: John Ogness Link: https://patch.msgid.link/20260511152706.151498-4-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman Stable-dep-of: d338ab1d9060 ("serial: 8250: Clear CON_PRINTBUFFER on port re-registration") Signed-off-by: Sasha Levin commit 71d8fcbb767b8a683f0710c799066be98369b0d1 Author: John Ogness Date: Mon May 11 17:33:00 2026 +0206 serial: 8250: Set cons_flow on port registration [ Upstream commit f69ec492244d54068f08c20f90979274d8ac3655 ] Since console flow control policy is no longer part of uart_port.flags, explicitly set the policy for the port. Signed-off-by: John Ogness Link: https://patch.msgid.link/20260511152706.151498-2-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman Stable-dep-of: d338ab1d9060 ("serial: 8250: Clear CON_PRINTBUFFER on port re-registration") Signed-off-by: Sasha Levin commit 7416aefeeb82206d7958d0573aaa3ec7838f577a Author: John Ogness Date: Wed May 6 14:21:57 2026 +0206 serial: Replace driver usage of UPF_CONS_FLOW [ Upstream commit bf558715d91cfa28f283de7105a879a92da31fb7 ] Rather than using the UPF_CONS_FLOW bit of uart_port.flags to track the user configuration of console flow control, use the newly added uart_port.cons_flow (via its getter/setter functions). A coccinelle script was used to perform the search/replace. Note1: The sh-sci driver is blindly copying platform data configuration flags to uart_port.flags. Thus UPF_CONS_FLOW could get set for uart_port.flags. A follow-up commit will address this. Note2: The samsung_tty driver is using UPF_CONS_FLOW as a platform data configuration flag. However, the driver explicitly checks for this configuration flag and thus setting UPF_CONS_FLOW in uart_port.flags is avoided. Signed-off-by: John Ogness Link: https://patch.msgid.link/20260506121606.5805-3-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman Stable-dep-of: d338ab1d9060 ("serial: 8250: Clear CON_PRINTBUFFER on port re-registration") Signed-off-by: Sasha Levin commit b897b1f791f34658a5ce4b17c4a15c7cea1d4ee3 Author: John Ogness Date: Wed May 6 14:21:56 2026 +0206 serial: core: Add dedicated uart_port field for console flow [ Upstream commit 9c7eb1c9c3e3bfecb556fc8fa1b68939385444de ] Currently the UPF_CONS_FLOW bit in the uart_port.flags field is used by serial console drivers to identify if a user has configured flow control on the console. Usually this policy is setup during early boot, but can be changed at runtime. The bits in uart_port.flags are either hardware and driver properties that are initialized before usage or are properties that can be changed via the tty layer. The UPF_CONS_FLOW bit is an exception because it is a console-only policy that can change at runtime and its setting and usage have nothing to do with the tty layer. This actually causes a problem for its usage because uart_port.flags is synchronized by a related tty_port.mutex, but a console has no relation to a tty (other than sharing the port). This is probably why console flow control is not properly available for most serial drivers. And it is hindering being able to provide a proper implementation. Commit d01f4d181c92 ("serial: core: Privatize tty->hw_stopped") addressed a similar issue to deal with software assisted CTS flow state tracking. Add a new uart_port boolean field "cons_flow" to store the user configuration for console flow control. Add getter/setter wrappers to allow for adding more policies later and/or locking constraint validation. Mark UPF_CONS_FLOW as deprecated. Signed-off-by: John Ogness Link: https://patch.msgid.link/20260506121606.5805-2-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman Stable-dep-of: d338ab1d9060 ("serial: 8250: Clear CON_PRINTBUFFER on port re-registration") Signed-off-by: Sasha Levin commit ed07324ed48718391b184fe4720c7300e5621320 Author: Praveen Talari Date: Fri Jul 10 15:42:44 2026 +0530 spi: qcom-geni: Fix missing error check on pm_runtime_get_sync() [ Upstream commit d8e9ea989acb54508477e4a8c9d9eaf8217e0081 ] spi_geni_init() calls pm_runtime_get_sync() to power up the device before accessing hardware registers, but never checks the return value. If the runtime resume fails, the function silently proceeds to read and write hardware registers on a device that may not be powered up, leading to register access faults. Fix this by replacing pm_runtime_get_sync() with the PM_RUNTIME_ACQUIRE_IF_ENABLED() macro and checking the result via PM_RUNTIME_ACQUIRE_ERR(), propagating any error back to the caller immediately before any hardware access occurs. Since the macro handles its own cleanup on failure, the out_pm label and the corresponding pm_runtime_put() call are no longer needed. Replace all goto out_pm paths with direct return ret statements and remove the label entirely. Fixes: 561de45f72bd ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP") Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Konrad Dybcio Signed-off-by: Praveen Talari Link: https://patch.msgid.link/20260710-fix_sticky_-einval_after_pm_runtime_api_failure-v4-2-be81d6c15043@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4c59f0e5ee0dfb2731ca210413c79e31fd4d9736 Author: Tengda Wu Date: Wed Jul 1 03:53:35 2026 +0000 perf capstone: Fix kernel map reference count leak [ Upstream commit d3c9fca531e2465f3a8f585965f3d10e1a6595ff ] In print_capstone_detail(), maps__find() is used to locate the kernel map. This function increments the reference count of the found map object. However, the current implementation fails to call map__put() after the map is no longer needed, leading to a reference count leak. Fix this by adding a map__put(map) call to properly release the reference after use. Fixes: 92dfc59463d5 ("perf annotate: Add symbol name when using capstone") Signed-off-by: Tengda Wu Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 45181de1077c035397e0d536b41842fe1367b73d Author: Liang Luo Date: Thu Jul 9 18:03:40 2026 +0800 selftests/sched_ext: Fix bpf_link leak on early return in prog_run [ Upstream commit e655c1f1bd14804f398df7da029c4a7e3f9ccd7f ] In prog_run's run(), the bpf_link is attached early but only destroyed on the success path. The three SCX_EQ assertions between attach and destroy expand to a direct 'return SCX_TEST_FAIL', so if any of them triggers, bpf_link__destroy() is never reached and the BPF scheduler stays loaded. All subsequent tests then fail to attach because SCX is not in the DISABLED state. Convert those assertions to explicit checks that jump to a unified 'out' label which always runs the cleanup, matching the pattern used in cyclic_kick_wait.c. Fixes: a5db7817af78 ("sched_ext: Add selftests") Signed-off-by: Liang Luo Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 892bb4715265f51a1811763a0572851b3d518725 Author: Wolfram Sang Date: Tue May 12 10:48:23 2026 +0200 hwspinlock: propagate errno when registering single lock [ Upstream commit e088ffa9a00eaaaf90da74763e774ca160969c26 ] hwspin_lock_register_single() always returns 0 despite checking the result from radix_tree_insert(). Propagate the errno to make sanity checks in callers of this function actually meaningful. Fixes: 300bab9770e2 ("hwspinlock/core: register a bank of hwspinlocks in a single API call") Link: https://sashiko.dev/#/patchset/20260319105947.6237-1-wsa%2Brenesas%40sang-engineering.com # review of patch 14 Signed-off-by: Wolfram Sang Link: https://lore.kernel.org/r/20260512084856.30497-2-wsa+renesas@sang-engineering.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7420aac8b1f7e5a75a9d659be3f151dd89de6911 Author: Felix Gu Date: Fri Jan 16 20:11:03 2026 +0800 remoteproc: qcom_q6v5_adsp: Fix reference leak for device node [ Upstream commit 8c952807c2cebd5e9e9b37146c9383229794c129 ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In adsp_map_carveout, it does not release the reference. Fixes: f22eedff28af ("remoteproc: qcom: Add support for memory sandbox") Signed-off-by: Felix Gu Link: https://lore.kernel.org/r/tencent_EDC2253D3B1C22217E1259E07765D269100A@qq.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9a85e2d35e54248aca39bad4f4152ed34de1995f Author: Armin Wolf Date: Wed Jul 8 21:55:49 2026 +0200 platform/x86: lg-laptop: Fix LED resource handling [ Upstream commit 3e91964aa74ab261aa15d9d96318eded2fd9d22a ] The event notification callback might access kbd_backlight even when it was not successfully registered with the LED subsystem. The same happens inside acpi_remove(), where the LED devices are unregistered unconditionally. Fix this by tracking the availability of the kbd_backlight LED device and use devm_led_classdev_register() to let devres take care of unregistering the LED devices during removal. For this the parent device of the LED devices is changed to the native platform device. Fixes: ae26278829a8 ("platform/x86: lg-laptop: Use correct event for keyboard backlight FN-key") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260708195553.7762-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit c5c3e0036a7ae0e25a887da4a3d621c51df2fa78 Author: Rafael J. Wysocki Date: Thu Mar 12 12:14:47 2026 +0100 platform/x86: lg-laptop: Convert ACPI driver to a platform one [ Upstream commit 2d9cb20610f75ca48c1cac064aede90196787507 ] In all cases in which a struct acpi_driver is used for binding a driver to an ACPI device object, a corresponding platform device is created by the ACPI core and that device is regarded as a proper representation of underlying hardware. Accordingly, a struct platform_driver should be used by driver code to bind to that device. There are multiple reasons why drivers should not bind directly to ACPI device objects [1]. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the LG Gram ACPI features and hotkeys driver from an ACPI driver to a platform one. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1] Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/1868365.VLH7GnMWUR@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Stable-dep-of: 3e91964aa74a ("platform/x86: lg-laptop: Fix LED resource handling") Signed-off-by: Sasha Levin commit f7f83b0826738f4109ef439d2e889c188dbfea80 Author: Rafael J. Wysocki Date: Thu Mar 12 12:14:03 2026 +0100 platform/x86: lg-laptop: Drop debug-only ACPI notify handler [ Upstream commit c12fe0b2c12195e0d1c56e0f670a6bd792b0567e ] To facilitate subsequent conversion of the driver to using struct platform_driver instead of struct acpi_driver, drop the debug-only notify handler method from the driver. No intentional functional impact beyond debug. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3346280.5fSG56mABF@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Stable-dep-of: 3e91964aa74a ("platform/x86: lg-laptop: Fix LED resource handling") Signed-off-by: Sasha Levin commit 6ff6af62f042bb34ac9d2b650c6c043082c5bbda Author: Armin Wolf Date: Fri Jun 12 19:34:49 2026 +0200 platform/x86: dell-wmi-base: Fix resource leak on module load failure [ Upstream commit 072841e02cf9c00a7e8a9c567a14239e02ca47ad ] We need to properly clean up the SMBIOS request and the privacy driver when the module load fails. Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260612173451.467629-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 9f860050c3d17ff8499d3998f7534d306c3da50a Author: Armin Wolf Date: Fri Jun 12 19:34:48 2026 +0200 platform/x86: dell-privacy: Fix race condition [ Upstream commit ca9338dbc64759b30741b12017c050b33c94dfa2 ] Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment. Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260612173451.467629-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit c9729ced165d6c5b57d99141b6632bb8711efec9 Author: Lorenzo Pieralisi Date: Thu Jul 9 10:40:14 2026 +0200 ACPI: RISC-V: Fix riscv_acpi_add_prt_dep() loop handling [ Upstream commit 3a56321d0aceee2a0bd80d23366401c131ff8350 ] The loop in riscv_acpi_add_prt_dep() includes error conditions that are handled in a dubious - if not outright wrong - way, by continuining the loop (which skips and misses the entry pointer update to point to the next entry). Rewrite the loop as a for loop (that handles the continuation correctly) and wrap the condition and update statements using helper functions to make it cleaner. Fixes: 1b173cc4bfcd ("ACPI: RISC-V: Implement function to add implicit dependencies") Signed-off-by: Lorenzo Pieralisi Tested-by: Sunil V L Reviewed-by: Sunil V L Link: https://patch.msgid.link/20260709-gic-v5-acpi-iwb-probe-deferral-v4-4-48dae790f871@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4cdcf4e19ed3127afd787f026d4ec56ae4d2a4ed Author: Lorenzo Pieralisi Date: Thu Jul 9 10:40:13 2026 +0200 ACPI: RISC-V: Check acpi_get_handle() status in riscv_acpi_add_prt_dep() [ Upstream commit 20435bda13f1219891ed0ce41207e320a916ff9c ] In riscv_acpi_add_prt_dep(), the acpi_get_handle() call can fail which would leave link_handle uninitialized. Fix it by checking the acpi_get_handle() return status and skip the entry if it fails. Fixes: 1b173cc4bfcd ("ACPI: RISC-V: Implement function to add implicit dependencies") Signed-off-by: Lorenzo Pieralisi Tested-by: Sunil V L Reviewed-by: Sunil V L Link: https://patch.msgid.link/20260709-gic-v5-acpi-iwb-probe-deferral-v4-3-48dae790f871@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 7857f19b5219c5d873e40f951e3592627ec45715 Author: Lorenzo Pieralisi Date: Thu Jul 9 10:40:12 2026 +0200 ACPI: RISC-V: Fix riscv_acpi_irq_get_dep() loop termination [ Upstream commit 64ae310bffa477cd11029c818bec489f4b8a845e ] In riscv_acpi_add_irq_dep() the main loop condition would currently stop the loop if an interrupt descriptor contains an interrupt for which the respective GSI handle is NULL, which is not correct because subsequent interrupts in the interrupt descriptor might still have a GSI dependency that must not be skipped. Rework riscv_acpi_add_irq_dep() and the riscv_acpi_irq_get_dep() call chain to fix it - by not forcing the loop to stop in order to guarantee dependency detection for all the interrupt entries in the CRS descriptor. Fixes: 1b173cc4bfcd ("ACPI: RISC-V: Implement function to add implicit dependencies") Signed-off-by: Lorenzo Pieralisi Tested-by: Sunil V L Reviewed-by: Sunil V L Link: https://patch.msgid.link/20260709-gic-v5-acpi-iwb-probe-deferral-v4-2-48dae790f871@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit fbf9bb81b21537ede387a31cc586f1d2ce66a74e Author: John Ogness Date: Fri Jul 3 16:20:31 2026 +0206 printk: Fix possible console use-after-free [ Upstream commit 36630cafbeede0b64c370edb2f7b4094327ee1e0 ] When emitting a record via legacy printing, it is possible that a handover to another legacy printing context occurs. When a context has performed a handover, the console SRCU read lock is released and the pointer to the console struct might now be invalid. Therefore, after calling nbcon_legacy_emit_next_record() or console_emit_next_record(), it is necessary to check if a handover occurred _before_ further @con usage. Sashiko pointed out that console_flush_one_record() was not doing this. In console_flush_one_record(), after emitting a record, move the further usage of @con after the handover check. Fixes: c158834b223f ("printk: nbcon: Use nbcon consoles in console_flush_all()") Reported-by: Sashiko Closes: https://lore.kernel.org/lkml/20260630170903.099D61F000E9@smtp.kernel.org Signed-off-by: John Ogness Reviewed-by: Petr Mladek Link: https://patch.msgid.link/20260703141521.202813-1-john.ogness@linutronix.de Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit b84065e9a8307fc63ac212e3de5d5cde8c447123 Author: Andrew Murray Date: Mon Oct 20 16:38:05 2025 +0100 printk: Introduce console_flush_one_record [ Upstream commit 741ea7aa95dd9ac77f861e7d0961d8d231ac8448 ] console_flush_all prints all remaining records to all usable consoles whilst its caller holds console_lock. This can result in large waiting times for those waiting for console_lock especially where there is a large volume of records or where the console is slow (e.g. serial). Let's extract the parts of this function which print a single record into a new function named console_flush_one_record. This can later be used for functions that will release and reacquire console_lock between records. This commit should not change existing functionality. Reviewed-by: Petr Mladek Signed-off-by: Andrew Murray Reviewed-by: John Ogness Link: https://patch.msgid.link/20251020-printk_legacy_thread_console_lock-v3-1-00f1f0ac055a@thegoodpenguin.co.uk Signed-off-by: Petr Mladek Stable-dep-of: 36630cafbeed ("printk: Fix possible console use-after-free") Signed-off-by: Sasha Levin commit d095438ac3320fb6fac1b444eadfbdd0c85e3cb1 Author: Manuel Fombuena Date: Thu Jul 2 23:35:58 2026 +0100 leds: st1202: Validate LED reg property against channel count [ Upstream commit cf197514bdfd3877f42b5dce1efd40b7b686547e ] The reg property from the device tree is used directly as an array index into chip->leds[] without bounds checking. A value >= ST1202_MAX_LEDS would cause an out-of-bounds write during probe. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB849718B43321DB7E5A05D17BC5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 4efb94335d70f188b7635f1b07a091193f1430f8 Author: Manuel Fombuena Date: Thu Jul 2 23:34:37 2026 +0100 leds: st1202: Disable channel when brightness is set to zero [ Upstream commit 0767335233a8cbab00bbe260a4e4bd380c7677fd ] When brightness_set() is called with LED_OFF, only the ILED register is zeroed; the channel enable bit is left set from probe time. A hardware channel enabled with ILED=0 still draws a small residual current, causing a dim glow even when the LED is supposed to be off. Fix this by splitting st1202_channel_set() into a lockless inner function __st1202_channel_set() and a locking wrapper, then calling the inner function from brightness_set() while it already holds the mutex. The channel is now disabled when value is zero and re-enabled when non-zero, in the same lock region as the ILED write. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB8497F11B30FE7D74CAA25135C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 9666b92fe2383d645cb2f81697a1b92b4da60bb0 Author: Manuel Fombuena Date: Thu Jul 2 23:33:16 2026 +0100 leds: st1202: Fix brightness having no effect while pattern mode is active [ Upstream commit 7cbe470366bdd43c7e8114fb2c4d74fa69093121 ] Once a hardware pattern is running (PATS=1), writing to the brightness sysfs attribute only updates the ILED register. The visible output is ILED x Pattern_PWM / 4095, so the change has little effect and the LED never returns to steady static operation as the user expects. The LED1202 has a single global sequencer shared across all channels. Stopping it in brightness_set() to force static mode would halt running patterns on all other active LEDs. Instead, set all 8 PWM slots for the channel to ST1202_PATTERN_PWM_FULL before writing ILED. With every step at full duty cycle, the output is ILED x FULL / 4095 = ILED regardless of the sequencer state, without disturbing other channels. This also enables basic LED operation without the pattern trigger: with the trigger set to none, the brightness sysfs attribute fully controls the LED as a simple on/off device. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB8497570FD162D0D42A9864E3C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 2176b43f70da0c8693def37beff6ebad82b247e1 Author: Manuel Fombuena Date: Thu Jul 2 23:30:50 2026 +0100 leds: st1202: Set all pattern PWM slots to full after clearing pattern [ Upstream commit d2ca0e2b6d6430f9c60bb2e0ee0b2b3dc4e5d86a ] pattern_clear() sets all PWM registers for the channel to LED_OFF (0). In static mode (PATS=0), the LED output is ILED x Pattern0_PWM / 4095; with Pattern0 at zero the LED remains dark regardless of the ILED value. The LED1202 has a single global sequencer shared across all channels. If another channel starts the sequencer after this one has been cleared, the cleared channel runs through all 8 steps at zero duty cycle and stays dark regardless of ILED. Set all 8 PWM slots to ST1202_PATTERN_PWM_FULL so that ILED alone controls the channel brightness in both static and sequencer modes. Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB849732C162CFE9E2C525AC16C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Stable-dep-of: 7cbe470366bd ("leds: st1202: Fix brightness having no effect while pattern mode is active") Signed-off-by: Sasha Levin commit 48a05db6110278334f2ea482440ed600e0b9fc73 Author: Manuel Fombuena Date: Thu Jul 2 23:31:55 2026 +0100 leds: st1202: Fix spurious pattern sequence start in setup [ Upstream commit dcc31246aaf0d330a3ba9a725f56c33e6d634caa ] st1202_setup() writes PATS and PATSR to the Configuration register as its final step, which starts the hardware pattern sequencer during device probe before any patterns have been programmed. This causes the device to run a sequence with whatever values happen to be in the pattern registers at the time. Remove the write. The device reset at the start of setup restores all registers to their power-on defaults, leaving PATS and PATSR cleared. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB849724B0FF00255F4760FAE0C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 45dee22d52fd983f956c8b8ef4f050383713b8c9 Author: Manuel Fombuena Date: Thu Jul 2 23:29:39 2026 +0100 leds: st1202: Fix pattern duration prescaler and pattern_clear skip marker [ Upstream commit d32f8bdc2b417a3013e1316a54a0b314f973bbc1 ] The PATy_DUR register encodes duration as N × 22.2 ms, with register value 0 reserved as a pattern skip indicator (§7.10). The driver incorrectly subtracted 1 from the register value: value / ST1202_MILLIS_PATTERN_DUR_MIN - 1 This caused two problems: - All programmed durations were off by one step (~22 ms too short). - Writing the minimum duration (22 ms) produced register value 0, silently skipping the pattern step instead of setting a 22 ms duration. The maximum duration constant was also wrong at 5660 ms. The 8-bit register saturates at 255, giving a maximum of 5610 ms (22 ms × 255). Values above 5653 ms were already producing a uint8_t overflow and writing 0 to the hardware. Fix the formula by removing the erroneous subtraction, and derive the maximum from the register width so the relationship is explicit. Update the documentation to reflect the correct maximum. This exposes a secondary issue: pattern_clear() was calling st1202_duration_pattern_write() with ST1202_MILLIS_PATTERN_DUR_MIN to reset unused slots, accidentally relying on the broken formula to produce register value 0. With the corrected formula, the same call writes 0x01 (22 ms), leaving unused slots as valid 22 ms zero-PWM steps and making the LED appear off for 7 × 22 ms out of every cycle. Write 0 directly to the duration registers in pattern_clear() so unused slots are always explicitly marked as skip, independently of the conversion formula. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB84971D3AF982F4F707A378F0C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit b8136daec6308929e05a0c46157f9214187736f0 Author: Manuel Fombuena Date: Thu Jul 2 23:27:22 2026 +0100 leds: st1202: Stop pattern sequence before reprogramming [ Upstream commit 9c019a8cb95d820e0bd03e75cfbad2c5b13941b7 ] The LED1202 datasheet (section 4.8) states that modifications to the Pattern Sequence Repetition register (PAT_REP) and pattern duration registers are only applied after the sequence has completed or been stopped. When the device is running in infinite loop mode (PAT_REP = 0xFF) the sequence never completes on its own, so these writes are silently ignored by the hardware. Neither pattern_clear() nor pattern_set() stop the running sequence before modifying pattern registers, causing any subsequent pattern reprogramming to have no effect when the previous pattern was set to infinite repeat. Fix this by clearing PATS in the Configuration register before touching any pattern registers in both functions, ensuring the hardware accepts the new values immediately. Note that the LED1202 has a single global pattern sequencer shared by all channels: PATS, PATSR, the duration registers, and PAT_REP are chip-wide. Stopping the sequencer in pattern_clear() therefore halts any pattern running on other channels. This is an inherent hardware constraint; pattern_set() restarts the sequencer when a new pattern is programmed. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Manuel Fombuena Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/GV1PR08MB84978D0F499774773C7DA1FCC5F52@GV1PR08MB8497.eurprd08.prod.outlook.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e774c612b7f8ecaabe215b00dff8189947fffa5c Author: Cosmo Chou Date: Fri Jul 3 09:42:01 2026 +0800 leds: pca9532: Fix inverted GPIO output polarity [ Upstream commit 65a38a28a0b04af19a5e1fbf3869051412eeac96 ] The pca9532_gpio_set_value() function incorrectly mapped the requested value to PCA9532_ON and PCA9532_OFF, inverting the GPIO output polarity. A requested logical high (val=1) incorrectly enabled the LED output driver, which on this open-drain device pulls the pin low, while a requested logical low (val=0) released the pin. Correct the mapping so that val=1 yields PCA9532_OFF (pin released / high-impedance) and val=0 yields PCA9532_ON (pin driven low). pca9532_gpio_direction_input() is also updated to pass val=1 to pca9532_gpio_set_value() to align with the corrected polarity mapping, ensuring the pin remains not driven when configured as an input. Fixes: 3c1ab50d0a31 ("drivers/leds/leds-pca9532.c: add gpio capability") Signed-off-by: Cosmo Chou Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260703014201.69829-1-chou.cosmo@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit fb43400a3a0f39914f88c162effe52185e7488cc Author: Wei Wang Date: Thu Jul 2 22:40:19 2026 +0800 iommu/amd: Fix false positive in SB IOAPIC IVRS validation [ Upstream commit 04fee302fac762a242ff1ad6810cff90c2a350ba ] The check_ioapic_information() function is designed to prevent boot hangs by ensuring the Southbridge (SB) IOAPIC is properly mapped in the IVRS table before enabling Interrupt Remapping. Currently, this check passes if *any* enumerated IOAPIC matches the expected SB IOAPIC device ID. If a buggy BIOS incorrectly assigns the SB IOAPIC's device ID to a secondary IOAPIC in the IVRS, while scrambling the true SB IOAPIC's mapping, the check hits a false positive and succeeds. This erroneously enables Interrupt Remapping. Consequently, the IOMMU blocks unmapped interrupts from the actual SB IOAPIC, dropping the system timer and leading to a silent kernel boot hang. Tighten the validation to verify the device ID specifically against the SB IOAPIC by matching their APIC IDs first. This prevents the validation check from being bypassed via device ID aliasing. Fixes: c2ff5cf5294b ("iommu/amd: Work around wrong IOAPIC device-id in IVRS table") Signed-off-by: Wei Wang Tested-by: Yongwei Xu Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 21750cb34ca87f256f44ca1b222c9d46f2d073de Author: Fu Hao Date: Tue Apr 7 16:25:40 2026 +0800 iommu/amd: Add support for Hygon family 18h model 4h IOAPIC [ Upstream commit 5beda8cadb1f072140e58b1edb7604444a42d955 ] The SB IOAPIC is on the device 0xb from Hygon family 18h model 4h. Signed-off-by: Fu Hao Tested-by: Tingyin Duan Signed-off-by: Joerg Roedel Stable-dep-of: 04fee302fac7 ("iommu/amd: Fix false positive in SB IOAPIC IVRS validation") Signed-off-by: Sasha Levin commit 1fe56537065003a0c7ce9fba918edd6413d433c2 Author: Wei Wang Date: Thu Jul 2 22:40:18 2026 +0800 iommu/amd: Prevent SB IOAPIC from overriding IVRS validation errors [ Upstream commit 854056480f9217568e3ab5edd81a9347a173ea79 ] The check_ioapic_information() function validates IOAPICs against the IVRS table to safely disable Interrupt Remapping (IR) if the BIOS provides a broken topology. Currently, the validation loop contains a bug: If an unmapped secondary IOAPIC is encountered, 'ret' is set to false. But if the Southbridge (SB) IOAPIC is enumerated after it in the MADT, the loop overwrites 'ret' to true. This bypasses the validation failure and leaves IR enabled. When devices attached to the unmapped secondary IOAPIC fire interrupts, the IOMMU drops them due to the missing Requestor ID, leading to localized device hangs. Fix this by initializing 'ret' to true and only toggling it to false upon encountering a validation error, ensuring failures are never erased. Fixes: c2ff5cf5294b ("iommu/amd: Work around wrong IOAPIC device-id in IVRS table") Signed-off-by: Wei Wang Tested-by: Yongwei Xu Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 3df590e85e1a2075fd896fd04f4111f3960e1fdf Author: Vladimir Zapolskiy Date: Thu Jul 2 01:24:11 2026 +0300 iommu/msm: Return -ENOMEM on memory allocation failure in probe [ Upstream commit b0d50c9016c4c2959dfa61bf9549cf98f9aa19cd ] If dynamic memory allocation in driver's probe function execution fails, it should be reported to the driver's framework with -ENOMEM error code. Fixes: 109bd48ea2e1 ("iommu/msm: Add DT adaptation") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 9fb04596eb957a5f3611eae6f79e64a82a2702ae Author: Daniel Borkmann Date: Thu Jul 9 09:34:22 2026 +0200 bpf: Fix security_bpf_map_create error handling [ Upstream commit 36ffa86c42f91c8a57071e024afc4ffb51a8958f ] Commit 5816bf4273ed ("lsm,selinux: Add LSM blob support for BPF objects") made the LSM hook wrappers for BPF object creation clean up the LSM state internally upon denial, e.g. security_bpf_map_create() internally calls security_bpf_map_free() when the bpf_map_create hook returns an error. map_create() however still routes a denial to its free_map_sec label, which invokes security_bpf_map_free() a second time, so the bpf_map_free hook fires twice for a single denied map. In-tree LSMs are unaffected in practice since the blob kfree() inside security_bpf_map_free() is NULL-safe and idempotent and none of them implement bpf_map_free, but a BPF LSM program attached to that hook observes double invocations. Route the denial to free_map instead. Fixes: 5816bf4273ed ("lsm,selinux: Add LSM blob support for BPF objects") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260709073422.379247-1-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit e7eda48c346794b93f38dab8573266c12acc5971 Author: Akari Tsuyukusa Date: Mon Jun 29 23:59:44 2026 +0900 iommu/mediatek-v1: Fix off-by-one in MT2701_LARB_NR_MAX [ Upstream commit aebaa93f3da1572877579c2e15ebf27be2dcc7fb ] The mt2701_m4u_in_larb[] array contains 4 (for LARB0 to LARB3) elements, meaning mt2701_m4u_to_larb() can legitimately return 3. The current check `if (larbid >= MT2701_LARB_NR_MAX)` incorrectly rejects valid LARB3 with -EINVAL. Fix this off-by-one error by updating MT2701_LARB_NR_MAX to 4. Note that this does not cause immediate issues with the current mt2701.dtsi and mt7623n.dtsi because it only defines 3 LARBs: mediatek,larbs = <&larb0 &larb1 &larb2>; Thus, larbid never reaches 3 in the existing upstream device tree. Fixes: de78657e16f4 ("iommu/mediatek: Fix NULL pointer dereference when printing dev_name") Signed-off-by: Akari Tsuyukusa Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 5587e7871ce994bb079f97fe7e430d99627e5292 Author: Yuho Choi Date: Wed Jun 3 15:51:42 2026 -0400 bus: mhi: ep: Fix device refcount leak in the error path of MHI device creation [ Upstream commit 6f12862600bb70e599a614d706a095ea5f8f9858 ] mhi_ep_create_device() takes one device reference for the UL channel and another for the DL channel after allocating the transfer device. These references are normally released by mhi_ep_destroy_device() before the device itself is removed. If dev_set_name() or device_add() fails, the error path currently drops only one reference. The remaining channel references keep the device from being released and leave the channels associated with a device that was never registered. Route both failures through a common unwind path that drops the DL channel reference, the UL channel reference, and the initial reference from device_initialize(). Fixes: 297c77a0f273 ("bus: mhi: ep: Add support for creating and destroying MHI EP devices") Signed-off-by: Yuho Choi Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260603195142.2189386-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin commit 86d54cf069fc5ae2e111c87933bebf6eb527978e Author: Sanghyun Park Date: Wed Jul 8 16:21:04 2026 +0900 bpf: Fix use-after-free on mm_struct in bpf_find_vma() [ Upstream commit 47b079e2117a2ee52e21f8b72935900c702fc0b5 ] bpf_find_vma() reads task->mm and calls mmap_read_trylock(mm) without holding a reference on the mm. On a foreign task, a concurrent exit_mm() can free the mm_struct between the lockless read and the trylock, resulting in a use-after-free. mm_struct is not SLAB_TYPESAFE_BY_RCU. For the current task, task->mm is stable. For a foreign task, pin the mm under task->alloc_lock and release it with mmput_async(), mirroring commit d8e27d2d22b6 ("bpf: fix mm lifecycle in open-coded task_vma iterator"). Use spin_trylock() instead of get_task_mm() so BPF context does not block on alloc_lock. Reject irqs-disabled contexts and !CONFIG_MMU on the foreign-task path because dropping the mm reference is not safe there. Race: CPU0 (BPF program) CPU1 (exiting task) ============================ ========================== bpf_find_vma(foreign_task): mm = task->mm exit_mm(): task->mm = NULL mmput(mm) -> frees mm_struct mmap_read_trylock(mm) // UAF on mm Fixes: 7c7e3d31e785 ("bpf: Introduce helper bpf_find_vma") Signed-off-by: Sanghyun Park Reviewed-by: Puranjay Mohan Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20260708072106.199637-2-sanghyun.park.cnu@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit ca71ee2f6c28c875655a6c9b960ae87e7351bbac Author: Breno Leitao Date: Tue Jun 16 05:09:34 2026 -0700 efi: fix stale reference to efi_recover_from_page_fault() [ Upstream commit 718ee46ba4d95d28d50d3f6437afbbe2be531175 ] efi_recover_from_page_fault() was renamed to efi_crash_gracefully_on_page_fault(), but the comment above enum efi_rts_ids was not updated. Use the current name. Fixes: c46f52231e79 ("x86/{fault,efi}: Fix and rename efi_recover_from_page_fault()") Signed-off-by: Breno Leitao Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 2892f3f44bf865c8fb6b6c0960edec4cc91806ee Author: Daniel Borkmann Date: Wed Jul 8 23:15:34 2026 +0200 bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux [ Upstream commit 92863e678070f57c17c868e4bfa2441a5c61ad2b ] bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire(). Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals. Fixes: 8580ac9404f6 ("bpf: Process in-kernel BTF") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260708211537.371874-2-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 78cae066f029aff2146f2c56e67d3e03ae7bc864 Author: Tanushree Shah Date: Wed Jul 8 16:56:08 2026 +0530 perf dso: Fix kallsyms DSO detection with fallback logic [ Upstream commit 8c5f60344b07f839267c0c835962e2206143be85 ] The current kallsyms detection in dso__is_kallsyms() uses the dso_binary_type enum which fixes the issue of kallsyms being cached in the build-id cache for out-of-tree modules. However, during build-id injection in perf record/inject, dso_binary_type has not been explicitly set yet,so dso__binary_type() returns DSO_BINARY_TYPE__NOT_FOUND instead of DSO_BINARY_TYPE__KALLSYMS for the kernel DSO. The current check then fails to identify it as kallsyms, causing build-id symlinks to not be created in ~/.debug/.build-id/ and perf archive to fail with "Cannot stat" errors. Steps to reproduce the issue: 1. rm -rf ~/.debug/.build-id 2. perf record sleep 1 3. perf archive Fix by falling back to matching long_name against the known kallsyms strings explicitly when binary_type is not yet set (== DSO_BINARY_TYPE__NOT_FOUND). Use strcmp() for exact matching of fixed names and strict validation for guest kallsyms with embedded PID to prevent path traversal attacks. Fixes: ebf0b332732d ("perf dso: fix dso__is_kallsyms() check") Signed-off-by: Tanushree Shah Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit e69d90bfae1aa78864a76321707ab16393f6832d Author: Sandipan Das Date: Wed Jul 8 00:34:01 2026 +0530 perf vendor events amd: Reintroduce deprecated Zen 5 core events [ Upstream commit eda39f98bbc5ce8b7b0be10193d2de38ed59da6c ] Maintain backward compatibility by reintroducing the events that were previously removed by commit 047979af3bf6 ("perf vendor events amd: Update Zen 5 core events"). Also set the deprecated flag and update the descriptions to point users to the correct alternative. Reported-by: Ian Rogers Closes: https://lore.kernel.org/all/CAP-5=fV_czvd-z4N7K+_SabxuOm9UUHRyBxNuchrtAgJL3OqOw@mail.gmail.com/ Fixes: 047979af3bf6 ("perf vendor events amd: Update Zen 5 core events") Signed-off-by: Sandipan Das Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 71e3023c5dddf78025eca4cd5f4eaf5590eb6dd4 Author: Daniel Borkmann Date: Wed Jul 8 09:53:39 2026 +0200 bpftool: Check EVP_Digest when computing excl_prog_hash [ Upstream commit 576bcaa1f5c208af0f590c9622247da87b49c05f ] bpftool_prog_sign() ignores the return value of EVP_Digest(). If the digest computation fails (context allocation failure, or a digest fetch failure under OpenSSL), EVP_Digest() returns 0 and leaves the output buffer untouched, but the function still reports success. Fixes: 40863f4d6ef2 ("bpftool: Add support for signing BPF programs") Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20260708075343.358712-5-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 11afe1912140f79d5af3091a54b181ef72fce1a5 Author: Aleksandr Nogikh Date: Tue Jun 23 12:30:52 2026 +0000 udf: Mark LVID buffer as uptodate before marking it dirty [ Upstream commit fb0601134c7e51728bd098abc6909315de1e5d86 ] When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 ("udf: Mark LVID buffer as uptodate before marking it dirty"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline] vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline] __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 Fixes: 853a0c25baf9 ("udf: Mark LVID buffer as uptodate before marking it dirty") Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview syzbot Reported-by: syzbot+0306b38d9ed6ef71467d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0306b38d9ed6ef71467d Link: https://syzkaller.appspot.com/ai_job?id=05f8e20f-f080-4c7f-a206-08dbc15cb4a1 Signed-off-by: Aleksandr Nogikh Link: https://patch.msgid.link/6ffb2ca8-e22f-4fd6-9f37-7202ec0878bd@mail.kernel.org Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 6648c470918371766f6d368113dd2a4faebac93f Author: Hongyan Xu Date: Wed Jun 24 22:09:08 2026 +0800 usb: gadget: r8a66597: avoid double free of ep0_req in probe error path [ Upstream commit 41d541e3718db01668a4cd29815ee4b3b55f76d2 ] If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL. Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once. Fixes: 776976a67ae2 ("usb: gadget: r8a66597-udc: cleanup error path") Issue found using a prototype static analysis tool and confirmed by code review. Signed-off-by: Hongyan Xu Signed-off-by: Slavin Liu <220245772@seu.edu.cn> Link: https://patch.msgid.link/20260624140908.1282-1-getshell@seu.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1f44d001620fd3caa30619a9bc73e9d15555408b Author: Bjorn Andersson Date: Thu Jun 11 22:22:02 2026 +0000 usb: typec: ucsi: unregister debugfs entries on teardown [ Upstream commit eed73a65ab609b79d53de88cccc34b36dfe753c4 ] ucsi_register() creates per-instance debugfs entries, but ucsi_unregister() keeps them around until ucsi_destroy(). Drivers like ucsi_glink that unregister/register the same UCSI instance across remoteproc restart then try to create an already existing debugfs directory and log: debugfs: 'pmic_glink.ucsi.0' already exists in 'ucsi' Unregister debugfs entries as part of ucsi_unregister(), and clear ucsi->debugfs after freeing it so repeated unregister paths remain safe. Assisted-by: Codex:GPT-5.5 Signed-off-by: Bjorn Andersson Fixes: df0383ffad64 ("usb: typec: ucsi: Add debugfs for ucsi commands") Tested-by: Konrad Dybcio # X1E80100 CRD Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260611-usci-unregister-debugfs-v1-1-f4a518a94f27@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 35bf61798e7d4abf39667d98f298f793b3dd9bbe Author: Dan Carpenter Date: Fri Jun 26 13:38:22 2026 +0300 thermal/drivers/rcar: Fix error checking in probe() [ Upstream commit dd04ad1cdabcad51e34b74b4e91b9aeb7180d05d ] This code accidentally calls thermal_zone_device_enable() before checking whether thermal_zone_device_register_with_trips() failed. Move the call until later to avoid an error pointer dereference of "priv->zone". The driver works differently depending on if we are using OF thermal or not. We use thermal_add_hwmon_sysfs() if we are using OF thermal and call thermal_zone_device_enable() if not. We can share same error check for if either of these fail. Moving the thermal_zone_device_enable() call is a bit cleaner as well. The original code used a three step process to cleanup: 1. Call thermal_zone_device_unregister() to cleanup. 2. Set priv->zone to an error pointer to preserve the error code. 3. Set priv->zone to NULL to avoid a second call to thermal_zone_device_unregister() in the rcar_thermal_remove() function. Now we can just do a direct goto error_unregister and rcar_thermal_remove() handles the cleanup properly. Fixes: bbcf90c0646a ("thermal: Explicitly enable non-changing thermal zone devices") Reviewed-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Signed-off-by: Dan Carpenter Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/aj5WnseULiwgmlWv@stanley.mountain Signed-off-by: Sasha Levin commit 593fda71983b9c23c84a566b20c53dc402c6b376 Author: Vidhu Sarwal Date: Sat Jul 4 14:00:31 2026 +0530 staging: media: ipu7: fix pm_runtime refcount leak in ipu7_resume() [ Upstream commit b298b80814dd0fc3cb1c8c0e0082fc14fdb5fecf ] ipu7_resume() calls pm_runtime_get_sync() before resuming the device. If the runtime PM resume fails, the usage count remains incremented, but the error path returns without dropping the reference. Use pm_runtime_resume_and_get() instead, which balances the usage count on failure and avoids the leak. Keep returning 0 on error, as resume callbacks should not propagate failures to the PM core, matching the behaviour of the ipu6 driver. Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Signed-off-by: Vidhu Sarwal Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit fb9fab1a4d6351aa8dd89c3af0ecbf96f0a9b840 Author: Vidhu Sarwal Date: Sat Jul 4 14:00:30 2026 +0530 staging: media: ipu7: fix pm_runtime refcount leak in ipu7_init_fw_code_region_by_sys() [ Upstream commit 843644e1c3347670498d247d7cd20dff1569181c ] ipu7_init_fw_code_region_by_sys() calls pm_runtime_get_sync() before accessing the firmware code region. If resuming the device fails, pm_runtime_get_sync() leaves the runtime PM usage count incremented, but the error path returns without dropping the reference. Use pm_runtime_resume_and_get() instead, which balances the usage count automatically on failure and avoids the leak. The ipu6 driver uses pm_runtime_resume_and_get() in the equivalent location. Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Signed-off-by: Vidhu Sarwal Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 947056a91d2324a6cc686a68a7c99bc8ef1d6942 Author: Tanushree Shah Date: Thu Jun 4 12:25:19 2026 +0530 perf data convert json: Fix trace_seq memory leak in process_sample_event() [ Upstream commit dcb87c88952046ef43cb5ba3a5b95eb29c362a16 ] Unlike the in-kernel trace_seq which uses a statically allocated buffer, the userspace traceevent library's trace_seq uses a dynamically allocated one. Therefore, every trace_seq_init() call must be paired with a trace_seq_destroy(), otherwise it produces a memory leak. In process_sample_event(), a trace_seq is initialized for each field when formatting tracepoint raw_data, but the matching trace_seq_destroy() is never called, leaking memory for every field of every sample processed. Add the missing trace_seq_destroy() after using the trace_seq buffer to properly free the allocated memory. Detected with Valgrind on a perf.data file with 2,729 tracepoint samples: Before: definitely lost: 55,537,664 bytes in 13,559 blocks After: definitely lost: 0 bytes in 0 blocks Fixes: 9d895e468429 ("perf data: Add tracepoint fields when converting to JSON") Signed-off-by: Tanushree Shah Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 4b759af64a21422d10b846c671e8e97bfd64de5f Author: Loic Poulain Date: Mon Jun 29 21:22:56 2026 +0200 clk: qcom: gcc-qcs8300: Use retention for USB power domains [ Upstream commit d8638610e0c9ebab2800b7ad6c2c2a3737090da9 ] The USB subsystem does not expect to lose its state on suspend: xhci-hcd xhci-hcd.1.auto: xHC error in resume, USBSTS 0x401, Reinit usb usb1: root hub lost power or was reset To maintain state during suspend, the relevant GDSCs need to stay in retention mode, like they do on other similar SoCs. Change the mode to PWRSTS_RET_ON to fix. Fixes: 95eeb2ffce73 ("clk: qcom: Add support for Global Clock Controller on QCS8300") Signed-off-by: Loic Poulain Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260629-monza-suspend-v1-2-b601d8a2f2f8@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a2e4ebada684034dad8f97f7c715a8f2f299c290 Author: Loic Poulain Date: Mon Jun 29 21:22:55 2026 +0200 clk: qcom: gcc-qcs8300: Use retention for PCIe power domains [ Upstream commit 11b170abe4d324cac0d15a410282d1ec2b6bafa0 ] As the PCIe host controller driver does not yet support dealing with the loss of state during suspend, use retention for relevant GDSCs. Fix the PCIe link not surviving upon resume, and GDSC error: gcc_pcie_0_gdsc status stuck at 'off' Fixes: 95eeb2ffce73 ("clk: qcom: Add support for Global Clock Controller on QCS8300") Signed-off-by: Loic Poulain Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260629-monza-suspend-v1-1-b601d8a2f2f8@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 448f948c9767c32255b491dff55a86eb915055da Author: Konrad Dybcio Date: Tue Jun 16 11:08:52 2026 +0200 arm64: dts: qcom: sc8180x-lenovo-flex-5g: Describe the display power net [ Upstream commit d5f5c089858f7accd1e4574c0c09d811e90eb51f ] Describe and wire up the power supplies for the eDP panel and its backlight. Previously, this was only working because of settings inherited from the bootloader. Fixes: 20dea72a393c ("arm64: dts: qcom: sc8180x: Introduce Lenovo Flex 5G") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260616-topic-8180_disp_power-v2-4-167785993231@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3a624b08d77362effa726e384dab9550bc6f6643 Author: Konrad Dybcio Date: Tue Jun 16 11:08:51 2026 +0200 arm64: dts: qcom: sc8180x-lenovo-flex-5g: Rename regulator nodes [ Upstream commit 0b1c6d2a65fc41aa0d5f6617dd04043384678d61 ] Align with the contemporary way of naming regulator nodes (regulator- prefix) in preparation for adding more of them. Reorder the renamed entries to match the expectations of the DT coding style doc. Reviewed-by: Dmitry Baryshkov Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260616-topic-8180_disp_power-v2-3-167785993231@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: d5f5c089858f ("arm64: dts: qcom: sc8180x-lenovo-flex-5g: Describe the display power net") Signed-off-by: Sasha Levin commit 25026bef5183cd02ddf53daa74f11786c3768456 Author: Konrad Dybcio Date: Tue Jun 16 11:08:50 2026 +0200 arm64: dts: qcom: sc8180x-primus: Describe the display power net [ Upstream commit 80bf2eb87bfbf1b7bc7b12228cbcc710b0a26275 ] Describe and wire up the power supplies for the eDP panel and its backlight. Previously, this was only working because of settings inherited from the bootloader. Fixes: 2ce38cc1e8fe ("arm64: dts: qcom: sc8180x: Introduce Primus") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260616-topic-8180_disp_power-v2-2-167785993231@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 76208cf896aabc024ea32ae4593edc888cfc21d8 Author: Konrad Dybcio Date: Tue Jun 16 11:08:49 2026 +0200 arm64: dts: qcom: sc8180x-primus: Rename regulator nodes [ Upstream commit ae51d9396f9318189e91578878409d8ada152edb ] The nodes would be sorted correctly, if their names started with "regulator-" (which is the style used in the latest submissions). Touch that up. Reviewed-by: Dmitry Baryshkov Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260616-topic-8180_disp_power-v2-1-167785993231@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 80bf2eb87bfb ("arm64: dts: qcom: sc8180x-primus: Describe the display power net") Signed-off-by: Sasha Levin commit badb18b11215befe61f92799e59073a44962488b Author: Jérôme de Bretagne Date: Thu Jun 4 18:18:40 2026 +0200 arm64: dts: qcom: sc8280xp-arcata: Fix top USB-C DP alt mode [ Upstream commit 16065c4ec1e7ca595f4fa363dc2251c6bdf1f6b3 ] The top USB-C port (usb0) didn't switch to DP alt mode, as reusing the same GPIO 101 as on the SC8280XP CRD or Lenovo ThinkPad X13s was not working on the Surface Pro 9 5G. Investigation [1] by Jens on the Windows Dev Kit (WDK2023), the other sc8280xp-based "blackrock" model from Microsoft, found a reference to GPIO 100 in the DSDT in addition to 101. Switching to GPIO 100 fixed the issue on blackrock, as it does on arcata to enable external screen when using the left-side top USB-C port. [1] https://lore.kernel.org/all/20250609-blackrock-usb0-mux-v1-1-7903c3b071e4@oldschoolsolutions.biz/ Cc: Jens Glathe Fixes: f6231a2eefd4 ("arm64: dts: qcom: sc8280xp: Add Microsoft Surface Pro 9 5G") Reviewed-by: Konrad Dybcio Signed-off-by: Jérôme de Bretagne Link: https://lore.kernel.org/r/20260604-surface-sp9-5g-for-next-v3-4-6aa6f6612c10@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f60f495858379dc70e87c6898d761a9db98739ff Author: Herman van Hazendonk Date: Tue Jun 2 16:09:34 2026 +0200 clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister() [ Upstream commit 86b23609d5e17a770d03037e53c6a443e742a6e6 ] gdsc_unregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pm_genpd_remove() on the individual generic_pm_domain structures registered by gdsc_init(): void gdsc_unregister(struct gdsc_desc *desc) { struct device *dev = desc->dev; size_t num = desc->num; gdsc_pm_subdomain_remove(desc, num); of_genpd_del_provider(dev->of_node); } That leaves dangling entries on the global gpd_list. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdsc_init() will end up trying to re-register a name that is still in the list and pm_genpd_init() returns -EEXIST. While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh of_genpd_get_from_provider() call racing with the teardown could attach to a domain that is mid-removal. Iterate the scs[] array and pm_genpd_remove() each registered domain after the subdomain links are torn down. The regulators stay devm- managed (devm_regulator_get_optional() in gdsc_register()), so the release happens automatically when the underlying device is unbound; just the genpd accounting needs to be undone explicitly. Signed-off-by: Herman van Hazendonk Fixes: 45dd0e55317c ("clk: qcom: Add support for GDSCs") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260602140934.796697-4-github.com@herrie.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f8fe8cb89d3a8dbd7f67cb96728aabe4aa6f77c1 Author: Herman van Hazendonk Date: Tue Jun 2 16:09:33 2026 +0200 clk: qcom: gdsc: propagate gdsc_enable() failure for ALWAYS_ON domains [ Upstream commit eea55fc694e132aacbe2cf4be7f345115e3d1801 ] GENPD_FLAG_ALWAYS_ON requires the underlying domain to be on at genpd_init() time -- the framework will refuse to register the domain otherwise. When the cold readback in gdsc_init() finds an ALWAYS_ON GDSC powered down, the driver tries to bring it back up: } else if (sc->flags & ALWAYS_ON) { /* If ALWAYS_ON GDSCs are not ON, turn them ON */ gdsc_enable(&sc->pd); on = true; } but discards the return value: if gdsc_enable() fails (regmap write error, the long-form sequence's status poll times out, or the HW_CTRL hand-off errors) the code still sets on=true and falls through to pm_genpd_init(..., !on) -- which then registers the domain in the ON state and sets GENPD_FLAG_ALWAYS_ON, even though the silicon is actually off. Subsequent consumer probes will see genpd report "on" while accessing dead registers and hang or read garbage. Catch the failure and surface it: returning the error from gdsc_init() makes the provider probe fail with the underlying errno, which propagates to consumers as -EPROBE_DEFER (or fatal if the hardware really is broken) rather than silently lying about the rail state. Signed-off-by: Herman van Hazendonk Fixes: fb55bea1fe43 ("clk: qcom: gdsc: Add support for ALWAYS_ON gdscs") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260602140934.796697-3-github.com@herrie.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e97f24ad63b83bba11ddb0cc2bf4796aee404136 Author: Herman van Hazendonk Date: Tue Jun 2 16:09:32 2026 +0200 clk: qcom: gdsc: propagate gdsc_check_status() errors from gdsc_poll_status [ Upstream commit d69f0c2b8d292b4890c9f0fbe184dfc26c4de86c ] gdsc_check_status() returns negative errno when the underlying regmap_read() fails -- e.g. when a parent regmap dies during system suspend, a CSR is removed by an HW debug tool, or the bus controller goes into protection. gdsc_poll_status() treats the result as a plain boolean ("is the GDSC in the requested state?"), so any negative error return is truncated to "true" and the poll exits with success even though the rail's real state is unknown: do { if (gdsc_check_status(sc, status)) return 0; } while (ktime_us_delta(ktime_get(), start) < STATUS_POLL_TIMEOUT_US); if (gdsc_check_status(sc, status)) return 0; return -ETIMEDOUT; This silently misleads gdsc_toggle_logic() (which writes/un-writes SW_COLLAPSE on the strength of the poll succeeding) and the gdsc_init() sync path (which assumes the readback represents real silicon state). Latch the return value, propagate negative errno immediately, and only treat a strictly-positive value as "reached the target state". Make the same change in the post-timeout final check so a regmap that comes back after the deadline does not silently degrade to -ETIMEDOUT. Signed-off-by: Herman van Hazendonk Fixes: 77b1067a19b4 ("clk: qcom: gdsc: Add support for gdscs with gds hw controller") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260602140934.796697-2-github.com@herrie.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 27b68ba9af9ddc36fdf116e9b9c1584eccd08d81 Author: Brian Norris Date: Tue Apr 28 13:06:59 2026 -0700 arm64: dts: qcom: Add #{address,size}-cells to Chromium-based /firmware [ Upstream commit 2a906f0b4f037b3fe5f790a48f88549a86288fdf ] Chromium/Depthcharge bootloaders may dynamically add a few device nodes to a system's DTB under a /firmware node. A typical DT looks something like the following: / { firmware { ranges; coreboot { compatible = "coreboot"; reg = <...>; ...; }; }; }; Notably, the /firmware node has an empty 'ranges', but does not have address/size-cells. Commit 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses") started requiring #address-cells for a device's parent if we want to use the reg resource in a device node. This leads to errors like the following: [ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22 Add appropriate #{address,size}-cells to work around the problem. Note that Google has also patched the Depthcharge bootloader source to add {address,size}-cells [1], but bootloader updates are typically delivered only via Google OS updates. Not all users install Google software updates, and even if they do, Google may not produce updated binaries for all/older devices. [1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/ https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and #size-cells for firmware node") Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/ Fixes: 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses") Signed-off-by: Brian Norris Reviewed-by: Dmitry Baryshkov Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20260428200712.2660635-8-briannorris@chromium.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 05a95478f9603f270341bc1452ce9841e35e7fa4 Author: David Woodhouse Date: Sun Jun 21 22:53:55 2026 +0100 timekeeping: Account for monotonicity adjustment in ntp_error [ Upstream commit b7befd6d91207cf3f4cecd68fea0c212093906cf ] timekeeping_apply_adjustment() modifies xtime_nsec to ensure monotonicity when mult changes: xtime_nsec -= offset This ensures that the time reported to userspace does not jump when the multiplier is adjusted from one tick to the next. However, the ntp_error accumulator which tracks the difference between intended and actual clock position was not being updated to reflect this additional discrepancy. An earlier attempt at this compensation existed as: ntp_error -= (interval - offset) << ntp_error_shift but was removed in commit c2cda2a5bda9 ("timekeeping/ntp: Don't align NTP frequency adjustments to ticks") because it was a major source of NTP error. That's because (interval - offset) was wrong: the subtraction of "interval" prematurely accounted for the changed xtime_interval of the next tick, which would be correctly accounted in the next accumulation anyway — a double subtraction. What is actually needed is just the "offset" part: ntp_error must be told that xtime_nsec moved by "offset" without a corresponding change in the intended position. For the normal ±1 mult dithering this is negligible (the adjustments cancel over time), but for larger mult changes — such as when an external reference clock sets a new frequency — the one-time uncompensated offset is significant. Fix by adjusting ntp_error by the correct amount: ntp_error += offset << ntp_error_shift This keeps ntp_error consistent with the actual xtime_nsec position after the adjustment, and ensures the discrepancy is correctly smoothed away over time and the clock returns to where it should have been. Fixes: c2cda2a5bda9 ("timekeeping/ntp: Don't align NTP frequency adjustments to ticks") Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Assisted-by: Kiro:claude-opus-4.6-1m Acked-by: John Stultz Link: https://patch.msgid.link/20260621220051.1030462-3-dwmw2@infradead.org Signed-off-by: Sasha Levin commit 0fcf7857ae11079bbbce61d7a905cd3cab62cb7f Author: Thomas Weißschuh Date: Mon May 4 08:32:26 2026 +0200 y2038: uapi: Use 64-bit __kernel_old_timespec::tv_nsec on x32 [ Upstream commit 79ced850e549e8c86b772a79ea417a1425b5c04b ] 'struct __kernel_old_timespec' represents the 'native' time ABI of the kernel. On 32-bit systems it uses 32-bit fields and on 64-bit systems it uses 64-bit fields. However the x86 x32 ABI uses the 64-bit time ABI natively. This is correctly handled for the 'tv_sec' fields, through the typedefs of '__kernel_old_time_t' -> '__kernel_long_t' -> 'long long'. The same treatment was missed for 'tv_nsec'. In practice this might not make much of a difference as the value of 'tv_nsec' will always fit into 32 bits and the missing bits fall into the padding of the structure. When introspecting the structure however, a difference can be observed. Switch to 64-bit tv_nsec on x32. No other architectures or ABIs are affected. While this could be interpreted as violating the POSIX requirement of 'timespec::tv_nsec' being 'long': * __kernel_old_timespec is not actually the POSIX timespec type * the requirement is gone in newer versions of POSIX * this matches glibc Fixes: 94c467ddb273 ("y2038: add __kernel_old_timespec and __kernel_old_time_t") Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260504-timespec-x32-v2-1-0739c9047fc4@linutronix.de Signed-off-by: Sasha Levin commit db667d2970c756cc7b483f45f272440f845a665b Author: Malaya Kumar Rout Date: Sat Jul 4 15:04:28 2026 +0530 time/namespace: Validate nanosecond field in proc_timens_set_offset() [ Upstream commit 06aba58e58492d2b8eae059274caed29025ea96e ] The function validates tv_sec to be within [-KTIME_SEC_MAX, KTIME_SEC_MAX] but never validates that tv_nsec is within the valid range of [0, NSEC_PER_SEC-1] before using it in timespec64_add(). timespec64_add() expects both timespec64 structures to have normalized values with tv_nsec in the range [0, 999999999]. If off->val.tv_nsec contains invalid values (negative or >= NSEC_PER_SEC), it could lead to incorrect calculations or unexpected behavior. Add validation to ensure tv_nsec is within the valid range before performing the addition. Fixes: 04a8682a71be ("fs/proc: Introduce /proc/pid/timens_offsets") Signed-off-by: Malaya Kumar Rout Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260704093429.89350-1-malayarout91@gmail.com Signed-off-by: Sasha Levin commit ecd622375e6d542511e1a035e8f631e3835c96a4 Author: Thomas Weißschuh Date: Mon Mar 30 09:07:56 2026 +0200 timens: Simplify some calls to put_time_ns() [ Upstream commit 3fa3aeb4a5cb19e372680ef8860a0381cd5409e9 ] Use the new __free() based cleanup helpers to simplify some functions. Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260330-timens-cleanup-v1-2-936e91c9dd30@linutronix.de Stable-dep-of: 06aba58e5849 ("time/namespace: Validate nanosecond field in proc_timens_set_offset()") Signed-off-by: Sasha Levin commit 453812e92c760b3995622d98acd358fe4702a088 Author: Thomas Weißschuh Date: Mon Mar 30 09:07:55 2026 +0200 timens: Add a __free() wrapper for put_time_ns() [ Upstream commit c2de5a5be4d60af5f928a2dd2b0f73e17358e346 ] The wrapper will be used to simplify cleanups of 'struct time_namespace'. Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260330-timens-cleanup-v1-1-936e91c9dd30@linutronix.de Stable-dep-of: 06aba58e5849 ("time/namespace: Validate nanosecond field in proc_timens_set_offset()") Signed-off-by: Sasha Levin commit b19176ff94a019fb6d3524a4ece8ea1bf6f2fad1 Author: Thomas Weißschuh Date: Thu Mar 26 12:42:30 2026 +0100 vdso/timens: Move functions to new file [ Upstream commit 5dc9cf835aba73c882348aa4f99be83b6e45ad9b ] As a preparation of the untangling of time namespaces and the vDSO, move the glue functions between those subsystems into a new file. While at it, switch the mutex lock and mmap_read_lock() in the vDSO namespace code to guard(). Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260326-vdso-timens-decoupling-v2-1-c82693a7775f@linutronix.de Stable-dep-of: 06aba58e5849 ("time/namespace: Validate nanosecond field in proc_timens_set_offset()") Signed-off-by: Sasha Levin commit 6e4b5205538360317bbbcbfe14b6639f86f4621b Author: Petr Tesarik Date: Wed Oct 22 12:26:12 2025 +0200 x86/tsx: Make tsx_ctrl_state static [ Upstream commit f018fca8f90bc383fefd97e3b2db03ea612ac789 ] Move all definitions related to tsx_ctrl_state to tsx.c. They are never referenced outside this file. No functional change. Signed-off-by: Petr Tesarik Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Nikolay Borisov Link: https://lore.kernel.org/all/cover.1758906115.git.ptesarik@suse.com Stable-dep-of: 06aba58e5849 ("time/namespace: Validate nanosecond field in proc_timens_set_offset()") Signed-off-by: Sasha Levin commit e165c01653920503632a3e121c3b290d999d52fe Author: Malaya Kumar Rout Date: Sat Jul 4 14:25:33 2026 +0530 timers/migration: Fix memory leak in tmigr_setup_groups() error path [ Upstream commit eddfded4196542deda7cb2da3d7ebef83f7ccfa4 ] When the WARN_ON_ONCE(i >= tmigr_hierarchy_levels) assertion triggers, the function returns -EINVAL without freeing the 'stack' memory allocated via kzalloc_objs() at the beginning of the function. Add kfree(stack) before returning to prevent the memory leak. Fixes: 6c181b5667ee ("timers/migration: Convert "while" loops to use "for"") Signed-off-by: Malaya Kumar Rout Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260704085533.87098-1-malayarout91@gmail.com Signed-off-by: Sasha Levin commit ed7472619e614ab23e17ce41645bda6acf481b9c Author: Yuho Choi Date: Fri Jul 3 12:53:37 2026 -0400 timekeeping: Unwind aux clock sysfs children on failure [ Upstream commit f2eee7e31ccd4bc87d047d8670cc2ec39cf36647 ] tk_aux_sysfs_init() creates one child kobject per auxiliary clock. If a later child or sysfs group creation fails, the current error path only puts the parent kobjects and leaves earlier children and groups behind. Store the child kobjects during init and remove the successfully created groups and kobjects on failure. Fixes: 7b5ab04f035f ("timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths") Signed-off-by: Yuho Choi Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260703165337.168445-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin commit 4222494df71bd715e39efa7bc98756d17c9a7ea1 Author: Yuho Choi Date: Thu Jul 2 17:57:33 2026 -0400 clocksource: Unregister subsystem on device registration failure [ Upstream commit 3dee6537e728bd8137fda6eaf859f26e685943f7 ] init_clocksource_sysfs() registers the clocksource subsystem before registering the clocksource device. If device_register() fails, the function returns the error while leaving the subsystem registered. Unregister the clocksource subsystem on that failure path so the successful subsystem registration is unwound before returning. Fixes: d369a5d8fc70 ("clocksource: convert sysdev_class to a regular subsystem") Signed-off-by: Yuho Choi Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260702215733.84588-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin commit f84b1c25712abf752bfe16a2b7279eaff10076e1 Author: Jiangshan Yi Date: Thu Jul 2 17:39:15 2026 +0800 selftests: timers: leap-a-day: Fix -w option and update usage comment [ Upstream commit b4b66151a71445f3a71574136ddc82968c7b175e ] Commit 98b74e1f3104 ("kselftests: timers: leap-a-day: Change default arguments to help test runs") replaced the -s option with -w and made "wait for the leap second" the non-default behaviour, but it only updated the switch/case handling. Two things were left inconsistent: - The getopt() option string still lists 's' instead of 'w', so passing -w is rejected as an invalid option and the new behaviour cannot be selected at all. - The file header comment still documents the removed -s option and an outdated default for -i. Fix the getopt() string to accept 'w' (matching the existing case 'w': handler) and update the header comment to describe -w, -t and the current -i default. Fixes: 98b74e1f3104 ("kselftests: timers: leap-a-day: Change default arguments to help test runs") Signed-off-by: Jiangshan Yi Signed-off-by: Thomas Gleixner Acked-by: John Stultz Link: https://patch.msgid.link/20260702093915.2652638-1-yijiangshan@kylinos.cn Signed-off-by: Sasha Levin commit d76656e42146694c5d738bc110167bb56f50e6e4 Author: Kemeng Shi Date: Thu Jul 2 11:30:46 2026 +0800 irqchip/gic-v3-its: Fix its node leak in gic_acpi_parse_madt_its() [ Upstream commit 698a8648ca8051d34722b09b8a8088c741120ac3 ] Fix its node leak when its_probe_one() failed in gic_acpi_parse_madt_its(). Fixes: 9585a495ac936 ("irqchip/gic-v3-its: Split allocation from initialisation of its_node") Signed-off-by: Kemeng Shi Signed-off-by: Thomas Gleixner Reviewed-by: Radu Rendec Link: https://patch.msgid.link/20260702033050.1583-3-shikemeng@huaweicloud.com Signed-off-by: Sasha Levin commit 68de28e0a098a4f867cca9f2bdd02a5ca31acf61 Author: Kemeng Shi Date: Thu Jul 2 11:30:45 2026 +0800 irqchip/gic-v3-its: Fix memleak in its_probe_one() [ Upstream commit 1efffab6fe336a5c4fd3c2886f255cd2f998e65f ] Fix collection leak when its_init_domain() failed in its_probe_one(). Fixes: 4c21f3c26ecc2 ("irqchip: GICv3: ITS: DT probing and initialization") Signed-off-by: Kemeng Shi Signed-off-by: Thomas Gleixner Reviewed-by: Radu Rendec Link: https://patch.msgid.link/20260702033050.1583-2-shikemeng@huaweicloud.com Signed-off-by: Sasha Levin commit 8da5dc215ebc968d4a38bcaaaeab123a8e83f85b Author: Wang Yan Date: Fri Jul 3 20:09:51 2026 +0800 selftests/lsm: Fix memory leak in attr_lsm_count [ Upstream commit 0cee720cfd51402cfcb14d96cb326a36c13b823a ] The calloc-allocated buffer in attr_lsm_count() is never released on any exit path, including both the normal return path and the early return when read_sysfs_lsms fails, resulting in a heap memory leak. Add free() for the buffer on all return branches to fix the leak. Fixes: d3d929a8b0cd ("LSM: selftests for Linux Security Module syscalls") Signed-off-by: Wang Yan Reviewed-by: William Roberts Tested-by: William Roberts Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 4d6923a9912da501f4769d2fa40f0da6c3590f62 Author: Feng Yang Date: Tue Jul 7 16:14:34 2026 +0800 selftests/bpf: Fix memory leak in msg_alloc_iov [ Upstream commit 602701718649936eb287bf6c7ecf870ec54c6f71 ] In the msg_alloc_iov function, the iov pointer is only assigned to msg->msg_iov after all memory allocations complete successfully. Therefore, when a calloc failure triggers the unwind_iov cleanup branch, we should use the local variable iov instead of msg->msg_iov. Fixes: 753fb2ee0934 ("bpf: sockmap, add msg_peek tests to test_sockmap") Signed-off-by: Feng Yang Reviewed-by: John Fastabend Link: https://lore.kernel.org/bpf/20260707081434.539327-1-yangfeng59949@163.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 58dc854c302a11bf7a3ceb9ac4fc496ccffd4e4d Author: Malaya Kumar Rout Date: Sat Jul 4 17:59:35 2026 +0530 selftests/bpf: Fix memory leak in msg_alloc_iov error path [ Upstream commit 0bebfaa39deadec21638f6fba553eae12627a26d ] In msg_alloc_iov(), when calloc() fails for an individual iov_base allocation, the error path frees all previously allocated iov_base entries but fails to free the iov array itself that was allocated with calloc() at the beginning of the function. This results in a memory leak of the iov array. Add free(iov) in the unwind_iov error path to ensure proper cleanup of all allocated memory. Fixes: 753fb2ee0934 ("bpf: sockmap, add msg_peek tests to test_sockmap") Signed-off-by: Malaya Kumar Rout Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/20260704122936.102394-1-malayarout91@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 3201c4e882847c2f8522f0793ce69ae4e38bfe26 Author: Evgenii Burenchev Date: Mon Jul 6 16:16:34 2026 +0300 ALSA: via82xx: Remove unreachable branch in snd_via686_pcm_pointer() [ Upstream commit cd3447e1b6425efd1704ed07f1f245c842927eb0 ] The condition if (count && size < count) can never evaluate to true. The VIA DMA count register is masked with 0x00ffffff before use, while the DMA buffer size is limited to 0x00fffffe bytes. As a result, 'count' can never exceed 'size', making the condition permanently false. This branch has therefore been unreachable since the driver was introduced. Remove the unreachable branch without changing runtime behavior. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Evgenii Burenchev Link: https://patch.msgid.link/20260706131638.15311-1-evg28bur@yandex.ru Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 737c928ff5092d7e55128a232c231248fc993777 Author: Dawei Feng Date: Mon May 25 17:18:36 2026 +0800 staging: rtl8723bs: fix mismatched free of HalData in rtw_sdio_if1_init() [ Upstream commit 264676418b726baca7be49171e306b6aa05cceb0 ] padapter->HalData is allocated via vzalloc(), but incorrectly freed using kfree() in the rtw_sdio_if1_init() error path. Using kfree() to release this vmalloc-backed buffer can lead to memory corruption. Use rtw_hal_data_deinit() to pair the free correctly and free HalData with vfree(). The bug was first flagged by an experimental static analysis tool we are developing for kernel memory-management bugs. Manual inspection confirms that the issue is still present in current mainline. An x86_64 allyesconfig build showed no new warnings. As we do not have suitable RTL8723BS SDIO hardware to test with, no runtime testing was able to be performed. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20260525091836.812565-1-dawei.feng@seu.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 89f9f433271fad9351de6a3c713b45b2cfb23e4a Author: Ayush Mukkanwar Date: Mon Jun 15 22:57:34 2026 +0530 staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown [ Upstream commit c0a9a8586a63fda49e61a6b83360feac2a60d898 ] cvm_oct_rx_shutdown calls free_irq and netif_napi_del without disabling the napi instance first. As the free_irq only waits for completion of hard interrupt handlers, the napi poll function could still be active. If cvm_oct_remove proceeds to free the plat structure (which holds the NAPI instances), the active poll function will access freed memory, resulting in a use-after-free crash. Fixes: 3368c784bcf7 ("Staging: Octeon Ethernet: Convert to NAPI.") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260511150931.93382-1-ayushmukkanwar%40gmail.com Signed-off-by: Ayush Mukkanwar Link: https://patch.msgid.link/20260615172734.42038-2-ayushmukkanwar@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ab63b49bad0da0c49a430b51de50d6eb58743eab Author: Ayush Mukkanwar Date: Mon May 11 20:39:31 2026 +0530 staging: octeon: replace pr_warn with dev_warn in fill and rx paths [ Upstream commit 2191a8dfd1f5a3091e9f388899beb137686c6532 ] Add struct platform_device parameter to cvm_oct_fill_hw_memory, cvm_oct_mem_fill_fpa, cvm_oct_rx_refill_pool and cvm_oct_rx_initialize to support device-aware logging. Replace pr_warn with dev_warn using &pdev->dev. To avoid passing these parameters through global state, introduce struct octeon_ethernet_platform to hold per-device state including the rx_refill_work and the oct_rx_group array. This ensures all receive group state and workers are correctly associated with the platform device. Define struct oct_rx_group and struct octeon_ethernet_platform in octeon-ethernet.h so they are shared across compilation units. Signed-off-by: Ayush Mukkanwar Link: https://patch.msgid.link/20260511150931.93382-4-ayushmukkanwar@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: c0a9a8586a63 ("staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown") Signed-off-by: Sasha Levin commit b62bc652590fee0b31170962e669224afbe0e8ae Author: Ayush Mukkanwar Date: Mon May 11 20:39:29 2026 +0530 staging: octeon: ethernet-mem: replace pr_warn with dev_warn in free functions [ Upstream commit be5e8d5f61b31105e0ed7f51cd591653aea5054f ] Add struct platform_device parameter to cvm_oct_free_hw_skbuff, cvm_oct_free_hw_memory and cvm_oct_mem_empty_fpa. Replace pr_warn calls with dev_warn, using &pdev->dev for device-aware logging. Signed-off-by: Ayush Mukkanwar Link: https://patch.msgid.link/20260511150931.93382-2-ayushmukkanwar@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: c0a9a8586a63 ("staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown") Signed-off-by: Sasha Levin commit 269d16a78a5be95de73351e2b8b5fdf4b0983fcc Author: Yuvraj Singh Chauhan Date: Thu Feb 12 22:49:03 2026 +0530 staging: octeon: fix free_irq dev_id mismatch in cvm_oct_rx_shutdown [ Upstream commit 41db5b76eeb4cc11a1097384caba7cfc659f7293 ] In cvm_oct_rx_initialize(), request_irq() is called with &oct_rx_group[i].napi as the dev_id: request_irq(oct_rx_group[i].irq, cvm_oct_do_interrupt, 0, "Ethernet", &oct_rx_group[i].napi); However, cvm_oct_rx_shutdown() passes cvm_oct_device (an array of struct net_device pointers) as the dev_id to free_irq(): free_irq(oct_rx_group[i].irq, cvm_oct_device); Since __free_irq() matches the action to remove by comparing dev_id pointers, the mismatched cookie means the IRQ handler is never found, triggering a WARN and leaving the IRQ line permanently allocated. This prevents proper driver cleanup on module removal. Fix the mismatch by passing &oct_rx_group[i].napi as the dev_id to free_irq(), matching what was used during request_irq(). Signed-off-by: Yuvraj Singh Chauhan Link: https://patch.msgid.link/20260212171903.1417804-1-ysinghcin@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: c0a9a8586a63 ("staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown") Signed-off-by: Sasha Levin commit 2c0c9956596e48654bb4855e2a0742748a0826a7 Author: Ayush Mukkanwar Date: Mon Jun 15 22:57:33 2026 +0530 staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown [ Upstream commit b9af44b0d20b2247c4eb0ea5cfca907d643eea50 ] The TX cleanup tasklet can be scheduled by the watchdog IRQ handler to execute cvm_oct_tx_do_cleanup. There can be a pending tasklet in the queue which might run after the cvm_oct_remove() frees net_device structures, causing a use-after-free in cvm_oct_tx_do_cleanup() as it iterates cvm_oct_device[] which is an array of netdevice pointers. Add tasklet_kill() after free_irq() to ensure the tasklet is no longer scheduled or running before teardown proceeds. Fixes: 4898c560103f ("Staging: Octeon: Free transmit SKBs in a timely manner") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260511150931.93382-1-ayushmukkanwar%40gmail.com Signed-off-by: Ayush Mukkanwar Link: https://patch.msgid.link/20260615172734.42038-1-ayushmukkanwar@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bcd95498f0cfe4351fa0a3b7e139f18f97cf52aa Author: Dan Carpenter Date: Wed Jun 3 10:34:21 2026 +0300 staging: fbtft: Use sysfs_emit_at() to print to sysfs file [ Upstream commit 221192a784c25e28b489a7e75fabf59be4f63d57 ] This scnprintf() uses the wrong limit. It should be "PAGE_SIZE - len" instead of just PAGE_SIZE. We're not going to hit the limit in real life since we are printing at most FBTFT_GAMMA_MAX_VALUES_TOTAL (128) u32 values, however, it's still worth fixing. Use sysfs_emit_at() to fix this since this is a sysfs file. Fixes: c296d5f9957c ("staging: fbtft: core support") Signed-off-by: Dan Carpenter Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/ah_Y_Y2RtqeGxchF@stanley.mountain Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c9191f2e2f35f1209eb2dc24b31129dd47b48c16 Author: Bryam Vargas Date: Tue Jun 16 01:06:12 2026 -0500 greybus: audio: bound the topology section sizes against the fetched size [ Upstream commit 33d8c7b794d2a30637c9d3fcb478f1d3222bef1e ] gb_audio_gb_get_topology() fetches a topology blob of a module-supplied size, and gbaudio_tplg_parse_data() then walks it by adding the module-supplied size_dais, size_controls and size_widgets fields to form the control, widget and route section offsets. Those le32 sizes are never checked against the fetched blob, so a module reporting a small topology size but large section sizes makes the offsets point past the allocation, and parsing reads out of bounds. Reject a topology whose section sizes do not fit within the fetched size before it is parsed. Fixes: 184992e305f1 ("greybus: audio: Add Greybus Audio Device Class Protocol helper routines") Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260616-b4-disp-4352e8b0-v1-1-3e09f62e0ad5@proton.me Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c458311637182b3d21d45009f047d92295578a33 Author: Rong Zhang Date: Wed Jun 3 02:51:42 2026 +0800 staging: sm750fb: Add missing Kconfig dependency [ Upstream commit da8fd33e7d6af4c069668c2d42234b969f706885 ] The sm750 frame buffer driver depends on FB_IOMEM_FOPS, but its Kconfig somehow misses it. Fix it by making FB_SM750 select FB_IOMEM_FOPS, as other frame buffer drivers do. Fixes: dc0ad215e5d8 ("staging/sm750fb: Initialize fb_ops with fbdev macros") Signed-off-by: Rong Zhang Link: https://patch.msgid.link/20260603-sm750-fb-iomem-kconfig-v1-1-7f6a3046cce2@rong.moe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit af65ceb437971180c3b733f5129fd41024374c24 Author: Ahmet Sezgin Duran Date: Thu May 21 20:44:25 2026 +0000 staging: sm750fb: gate dualview dataflow using g_dualview [ Upstream commit d352778979d2eed09e266ed0f3a5e3ccd3983940 ] In sm750fb_setup and sm750fb_set_drv functions, the dualview related code is guarded by `sm750_dev->fb_count > 1` condition. That value is updated only after each framebuffer is registered, while both guards are used before any increment. Current flow: lynxfb_pci_probe() sm750fb_setup() // fb_count is 0 for each fb: sm750fb_framebuffer_alloc() lynxfb_set_fbinfo() sm750fb_set_drv() // fb_count is 0 or 1 register_framebuffer() sm750_dev->fb_count++; // fb_count is incremented Thus even if `dualview=1` parameter is passed down to the driver, fb_count is never > 1 at either check, so dualview dataflows are not selected and crtc->vidmem_size is never halved. Use `g_dualview` global variable instead of fb_count > 1 to correctly enable dualview capabilities. Fixes: a3f92cc94c61 ("staging: sm750fb: replace dual member of sm750_dev with fb_count") Signed-off-by: Ahmet Sezgin Duran Link: https://patch.msgid.link/20260521204425.82627-1-ahmet@sezginduran.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 311a2e65e42aff2285795f768269c8363f0617d1 Author: Alexander A. Klimov Date: Thu May 21 20:23:30 2026 +0200 staging: greybus: audio: correct sscanf() return value check [ Upstream commit f883fa1a0a0212f63acb18c50e5f900301f3bb1e ] manager_sysfs_add_store() passes 6 pointers to sscanf(), but required latter to return 7 which always failed the operation. I corrected it to 6. Fixes: 49b9137a6002 ("staging: greybus: audio: remove redundant slot field") Signed-off-by: Alexander A. Klimov Link: https://patch.msgid.link/20260521182331.22685-1-grandmaster@al2klimov.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e7fccad2c8e6ef6bbafe509c95869d161d0f466b Author: Cen Zhang Date: Tue Jul 7 00:18:22 2026 +0800 wifi: mac80211_hwsim: avoid NULL skb in stop queue drain [ Upstream commit 158438cd6ad69d6dd7d871582c38baf22169fede ] mac80211_hwsim_stop() drops any frames left in data->pending. The loop currently checks skb_queue_empty() and then dequeues separately. That split is racy with TX status handling, which can remove a pending frame under the queue lock. If the last entry is removed after the empty check, skb_dequeue() returns NULL and the stop path passes that NULL skb to ieee80211_free_txskb(). Use skb_dequeue() as the loop condition instead. The dequeue result is the object that stop owns and frees, and a concurrent status completion that empties the queue simply makes the loop terminate. Fixes: bd18de517923 ("mac80211_hwsim: drop pending frames on stop") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Link: https://patch.msgid.link/20260706161822.921039-1-zzzccc427@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2496d9829ab5e5125be610e1c53e64dd8066bd24 Author: Ruoyu Wang Date: Sat Jun 20 16:04:06 2026 +0800 bus: qcom-ebi2: Fix clock leak on probe failure [ Upstream commit 64774dea58969194ea5c27fa639954e551a87024 ] qcom_ebi2_probe() enables the EBI2X and EBI2 clocks before it walks child nodes and populates child devices. If reading a child node's reg property fails, or if of_platform_default_populate() fails, probe returns without disabling either clock. Route those failure paths through the existing clock cleanup labels so a failed probe does not leave the clocks prepared and enabled. Fixes: 335a12754808 ("bus: qcom: add EBI2 driver") Signed-off-by: Ruoyu Wang Link: https://lore.kernel.org/r/20260620080406.1970447-1-ruoyuw560@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e6edd7339153c7e7849a6c7636985bf3989401f1 Author: Krzysztof Kozlowski Date: Fri Jan 2 13:50:31 2026 +0100 bus: qcom-ebi2: Simplify with scoped for each OF child loop [ Upstream commit 9c252f3c8f390fae4ca09de36c9262a35ae88ace ] Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260102125030.65186-3-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 64774dea5896 ("bus: qcom-ebi2: Fix clock leak on probe failure") Signed-off-by: Sasha Levin commit 3cf9e40432c5dac1cb74fb7fc18b2e2ed5f8bb32 Author: Taniya Das Date: Wed Jun 17 16:37:52 2026 +0530 clk: qcom: gcc-glymur: Move EVA clocks to critical clock list [ Upstream commit 7399034fd78615ba826b864fca2e4572f13cf8e3 ] The gcc_eva_ahb_clk and gcc_eva_xo_clk branch clocks should not be registered as standalone GCC branch clocks. Drop these clocks from the GCC clock list and instead add their CBCR registers to the GCC critical clocks list to ensure they remain enabled during early boot. If these clocks are registered as normal branch clocks, they may be gated, which breaks access to the EVA clock controller during clock controller probe, thus leave them as critical clocks similar to other subsystem AHB and XO clocks. Fixes: efe504300a17 ("clk: qcom: gcc: Add support for Global Clock Controller") Signed-off-by: Taniya Das Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260617-evacc_glymur-v2-1-905108dacaaa@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7be3c0bae7c58b99e6e5110c1ae7f1f8c8d3d8fb Author: Konrad Dybcio Date: Mon May 18 11:54:39 2026 +0200 arm64: dts: qcom: hamoa: Fix clocks for HSPHYs [ Upstream commit 115894bc201b0cd1799d239875a1b40924f0ef7b ] The tertiary controller's HSPHY has its own toggle in TCSR, while the primary one is wired directly to the XO clock. Fix that. Fixes: 4af46b7bd66f ("arm64: dts: qcom: x1e80100: Add USB nodes") Signed-off-by: Konrad Dybcio Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260518-topic-hamoa_hsphy_clk-v1-1-d85203756505@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 62b399c4e985669b36f248a3105f6beee84fe50e Author: Luca Weiss Date: Tue May 5 17:08:35 2026 +0200 arm64: dts: qcom: sm7225-fairphone-fp4: Fix address in fb node name [ Upstream commit f6e65005fe55c3d09287851523de06367cbf0bc2 ] 'reg' is 0xa0000000 so the node name is missing a zero. Add it, so that the reg and address in the node name matches. No functional impact. Fixes: 4cbea668767d ("arm64: dts: qcom: sm7225: Add device tree for Fairphone 4") Signed-off-by: Luca Weiss Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260505-sm6350-misc-v1-3-0b9efc22690c@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a81fad1ff10478e389f6392b08469d2d5696f985 Author: Jens Glathe Date: Fri May 1 11:11:29 2026 +0200 arm64: dts: qcom: sc8280xp-blackrock: switch to uefi rtc offset [ Upstream commit f52102fc9ccbbb3c4bc01a29f3194fe07f9602f5 ] On many Qualcomm platforms the PMIC RTC control and time registers are read-only so that the RTC time can not be updated. Instead an offset needs be stored in some machine-specific non-volatile memory, which a driver can take into account. On platforms where the offset is stored in a Qualcomm specific UEFI variable the variables are also accessed in a non-standard way, which means that the OS cannot assume that the variable service is available by the time the RTC driver probes. Use the new 'qcom,uefi-rtc-info' property to indicate that the offset is stored in a UEFI variable so that the OS can determine whether to wait for it to become available. [1]: https://lore.kernel.org/r/20250423075143.11157-4-johan+linaro@kernel.org Fixes: 16a7fed11714 ("arm64: dts: qcom: sc8280xp-blackrock: dt definition for WDK2023") Signed-off-by: Jens Glathe Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260501-blackrock-rtc-v1-1-bddf3e37fa94@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e5965ae3f7c918151b87e5c925b7978afbeaf638 Author: Waiman Long Date: Thu Jul 2 17:47:47 2026 -0400 cgroup/cpuset: Make nr_deadline_tasks an atomic_t [ Upstream commit 95220e1f18f6321008f021abc7d6f581f64bcb82 ] The nr_deadline_tasks variable in the cpuset structure was introduced by commit 6c24849f5515 ("sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets"). It is reported by sashiko [1] that nr_deadline_tasks can currently be modified by inc_dl_tasks_cs() under rq->lock and by cpuset_attach() under cpuset_mutex. So if both updates happen simultaneously, the nr_deadline_tasks variable can be corrupted leading to incorrect operations down the road. Fix that by changing its type to atomic_t so that nr_deadline_tasks are always atomically updated. This fix patch is a low hanging fruit. It can handle some of the races between a concurrent sched_setscheduler() and cpuset_can_attach()/cpuset_attach() calls, but not all of them like the other issue raised by sashiko [2]. This will be handled hopefully in a future follow up patch. [1] https://sashiko.dev/#/patchset/20260626181923.133658-1-longman%40redhat.com [2] https://sashiko.dev/#/patchset/20260630033344.352702-1-longman%40redhat.com Fixes: 6c24849f5515 ("sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets") Reviewed-by: Ridong Chen Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 3a1b23f9ede955e4a8d111ae3ad184904cbce302 Author: Haowen Tu Date: Wed Jun 24 13:38:39 2026 +0800 PM: sleep: Fix off-by-one in wakelocks number limit check [ Upstream commit 6058646587dded0ce0ba91bd5a6afbf14fe42055 ] CONFIG_PM_WAKELOCKS_LIMIT is documented as the maximum number of user-space wakeup sources, but the limit check is performed before the counter is incremented and only rejects new wakeup sources when the current number is greater than the limit. This allows one extra wakeup source to be created. Reject new wakeup sources once the counter has reached the limit. Fixes: b86ff9820fd5 ("PM / Sleep: Add user space interface for manipulating wakeup sources, v3") Signed-off-by: Haowen Tu [ rjw: Subject edits ] Link: https://patch.msgid.link/20260624053839.2150567-1-tuhaowen@uniontech.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 0f297bc93bbfd9d85c46ce92bc5217a076d8d81e Author: Yuho Choi Date: Mon Jun 15 16:05:40 2026 -0400 bus: ti-sysc: Fix /chosen node reference leak [ Upstream commit 6342de0aed216b6df460b492ddb532b3e0ed16f1 ] sysc_init_stdout_path() gets the /chosen node with of_find_node_by_path() to read stdout-path. The function then overwrites the local node pointer with the stdout-path lookup result, or exits on error, without dropping the /chosen reference. Keep the /chosen node in a separate variable and put it after the stdout-path value has been used for the lookup. The successful stdout node lookup remains referenced by the cached stdout_path pointer. Fixes: 3bb37c8e6e6a ("bus: ti-sysc: Handle stdout-path for debug console") Signed-off-by: Yuho Choi Reviewed-by: Andreas Kemnade Link: https://patch.msgid.link/20260615200540.770205-1-dbgh9129@gmail.com Signed-off-by: Kevin Hilman (TI) Signed-off-by: Sasha Levin commit ca795fc1d8a1a4ab0e6bd1d27c9adb78d4ed1a1c Author: Shin'ichiro Kawasaki Date: Mon Jun 29 14:15:28 2026 +0900 nvmet-rdma: fix response resource leak on queue teardown [ Upstream commit 0114dd303b373522dea06053aabae34bdd33a7c4 ] When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm "kworker/2:1H", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 unreferenced object 0xffff88814bd05e80 (size 64): comm "kworker/3:1H", pid 148, jiffies 4295195428 backtrace (crc e35510cb): __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources() that frees up the RDMA read/write context and the request SGLs of such responses. Fixes: 8f000cac6e7a ("nvmet-rdma: add a NVMe over Fabrics RDMA target driver") Signed-off-by: Shin'ichiro Kawasaki Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 0fed8c64266c2b00d3547a73945c63ae0708670f Author: Shin'ichiro Kawasaki Date: Mon Jun 29 14:15:27 2026 +0900 nvmet-rdma: factor out response resource cleanup [ Upstream commit 90096175473f7c86e39c3f74f10343f965f5a05d ] Move the RDMA read/write context teardown and the request SGL freeing out of nvmet_rdma_release_rsp() into a new helper function nvmet_rdma_free_rsp_resources(). This is a refactoring with no functional change, in preparation for the following patch that uses nvmet_rdma_free_rsp_resources(). Signed-off-by: Shin'ichiro Kawasaki Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Stable-dep-of: 0114dd303b37 ("nvmet-rdma: fix response resource leak on queue teardown") Signed-off-by: Sasha Levin commit e5a79244a3c526a76d930f2ef30aff64528b0c6a Author: Gui-Dong Han Date: Thu Jun 18 10:15:43 2026 +0800 nvme-apple: Use acquire/release for queue enabled state [ Upstream commit f61c934aa084b7440fec681be3f4b481eb5a8609 ] apple_nvme_init_queue() initializes queue state and then marks the queue enabled. The interrupt and request paths check enabled before using that queue state. The old wmb() after WRITE_ONCE(enabled, true) does not publish the earlier initialization before enabled becomes visible. Use a release store when enabling the queue and acquire loads when testing it. Although the shutdown-side enabled accesses are not used for publishing queue initialization, use helpers for them as well for consistency. Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Signed-off-by: Gui-Dong Han Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 7117f27eb3bfb0ee1fa44c045d8854fc319d538c Author: Kuldeep Singh Date: Wed Apr 29 15:05:40 2026 +0530 arm64: dts: qcom: sm8750: wire UFS to ice instance [ Upstream commit ac456227d22952b656ad291ebd2d3d3e498e3d95 ] The Inline Crypto Engine (ICE) exists as a standalone DT node, but the UFS node lacks the required qcom,ice phandle reference. Add the qcom,ice property to explicitly associate the UFS controller with its ICE instance. Fixes: d288abc3a70e ("arm64: dts: qcom: sm8750: Add UFS nodes for SM8750 SoC") Signed-off-by: Kuldeep Singh Tested-by: Wenjia Zhang # on sm8750-mtp Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260429-sm8750_ice_dt_fix-v1-1-2540dc337082@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 07974c267f603a76aead348bca97deee95efdcc9 Author: Jacob Moroni Date: Thu Jun 18 20:14:58 2026 +0000 RDMA/irdma: Add refcounting to user ring MRs [ Upstream commit f67d8a08f60c9217df6d40da56422d2049f5e334 ] Prevent userspace from deregistering the MRs that back QP/CQ/SRQ rings by bumping the MR's refcount upon association. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260618201458.875740-5-jmoroni@google.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 2ed1164153e9226b9bf454052bf809159e788cff Author: Jacob Moroni Date: Thu Jun 18 20:14:57 2026 +0000 RDMA/irdma: Add irdma_cq fields to track pbl allocations [ Upstream commit 971e99623ed7a0d75a719021cf4fd64e5f9e44e5 ] These fields will be used in a subsequent commit which adds refcounting to user CQ MRs. Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260618201458.875740-4-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: f67d8a08f60c ("RDMA/irdma: Add refcounting to user ring MRs") Signed-off-by: Sasha Levin commit e11379ca6e90bc318c7cc7027bd2b950ac808803 Author: Jacob Moroni Date: Thu Jun 18 20:14:56 2026 +0000 RDMA/irdma: Add a refcount to track user ring MR associations [ Upstream commit a7d0a6b58256a77566e9088a99e1594bf35821ec ] User QP/CQ/SRQ rings are registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. In order to prevent userspace from deregistering these special MRs while the child object still exists, a refcount will be used. This commit adds the refcount and logic to reject a dereg_mr with active references. Subsequent commits will add logic to bump this refcount when the user QP/CQ/SRQ objects are created. Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260618201458.875740-3-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: f67d8a08f60c ("RDMA/irdma: Add refcounting to user ring MRs") Signed-off-by: Sasha Levin commit 8fb2c3106a91124ced60f6c03d309b4a96f74e86 Author: Jacob Moroni Date: Thu Jun 18 20:14:55 2026 +0000 RDMA/irdma: Deduplicate the irdma_del_memlist logic [ Upstream commit 097f50384e1877b7cf3ace12ff0d1beed19f2088 ] Simplify/dedup the irdma_del_memlist logic in preparation for the QP/CQ/SRQ ring MR refcounting change that will follow in a subsequent commit. Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260618201458.875740-2-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: f67d8a08f60c ("RDMA/irdma: Add refcounting to user ring MRs") Signed-off-by: Sasha Levin commit 5bbb726d27ff6dff750264e51aa665538394d0f8 Author: Myeonghun Pak Date: Wed Jun 24 16:15:49 2026 +0900 crypto: keembay - Fix AEAD unregister count in error path [ Upstream commit e264401ce4776a288524e5b87593d4d864147115 ] register_aes_algs() registers the AEAD algorithms before registering the skcipher algorithms. If skcipher registration fails, the function unwinds the earlier AEAD registration with crypto_engine_unregister_aeads(), but it passes ARRAY_SIZE(algs), which is the skcipher table size. Use ARRAY_SIZE(algs_aead) for the AEAD unwind path so the unregister helper iterates over the same table that was registered. Also clarify the nearby comment: the crypto registration helpers clean up algorithms registered within the same call, while this function must still unwind earlier successful registration steps. Fixes: 885743324513 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e7d8ddd471d2895f1d4098832c21121d4191adaa Author: Pengpeng Hou Date: Tue Jun 23 21:55:28 2026 +0800 crypto: rk3288 - fail ahash requests on HASH idle timeout [ Upstream commit ae150db7826f21e8d19e54fb6243169628809c4d ] rk_hash_run() waits for RK_CRYPTO_HASH_STS to become idle after the final DMA transfer, but ignores the poll result. If the hash engine never becomes idle, the driver still reads the digest registers and finalizes the request with the previous success value. Store the poll result and finalize the request with the timeout error before reading the digest registers. Fixes: 37bc22159c45 ("crypto: rockchip - use read_poll_timeout") Signed-off-by: Pengpeng Hou Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 62219775a07ce0bd8085852f3d1e2d772bf6fdec Author: Pengpeng Hou Date: Tue Jun 23 14:07:27 2026 +0800 hwrng: xilinx-trng - propagate timeout before any data is read [ Upstream commit ba088974419326daf46c5dc03e2cf6ab6ab701f7 ] xtrng_readblock32() polls for 16-byte chunks but returns the number of bytes read even when the first poll times out. Its caller then treats a zero return as a short successful read, and partial reads for full 32-byte blocks can make the tail copy use a fixed block offset rather than the amount already produced. Return the poll error when no data has been read, preserve partial positive returns after some data is available, stop the generator on all collection exits, and append tail bytes at the current output count. Fixes: 8979744aca80 ("crypto: xilinx - Add TRNG driver for Versal") Signed-off-by: Pengpeng Hou Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 91ded4742fcde6ad415c4d8a20e5ea0dcdf4f73e Author: Pengpeng Hou Date: Tue Jun 16 08:46:27 2026 +0800 crypto: sa2ul - stop probe if context pool creation fails [ Upstream commit d03f980a25853f6a380895119a572a3bb1194e8d ] sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool. Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool. Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver") Signed-off-by: Pengpeng Hou Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f4d347fb1309b69ea6f817a17e6b2893c8d754b7 Author: Lothar Rubusch Date: Sat Jun 13 20:20:37 2026 +0000 crypto: atmel-sha204a - fix heap info leak on I2C transfer failure [ Upstream commit 72bbf11ba14bd7d5fbf31a1ec42fff608b657f74 ] The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes. If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated work_data is not usable for producing RNG output and must not remain associated with the hwrng state. Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data. Fix this by freeing the pending work_data. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read. Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator") Signed-off-by: Lothar Rubusch Assisted-by: Gemini:1.5 Pro [google] Reviewed-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e64d6f1aae8c837cb3f0446bf44108226d7370f4 Author: Thorsten Blum Date: Thu Jun 11 23:36:17 2026 +0200 crypto: atmel-ecc - reject hardware ECDH without a public key [ Upstream commit f240f9b588f4e2de89822adebf560a96b5d263ed ] The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm. atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm. Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver") Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9af019e213ada5c3d0d33c515071a1414b6899f3 Author: Giovanni Cabiddu Date: Mon Jun 8 16:04:20 2026 +0100 crypto: qat - clear AES key schedule from stack [ Upstream commit d41a9fcfb7f9ee36e4a4aaf5e7996bca6be1e7a9 ] qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame. Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy. Fixes: 5106dfeaeabe ("crypto: qat - add AES-XTS support for QAT GEN4 devices") Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6b19f343ae8ada4c84209bc6f62d50ea9781c4ae Author: Giovanni Cabiddu Date: Mon Jun 8 15:59:40 2026 +0100 crypto: qat - cancel work on re-enable SR-IOV timeout [ Upstream commit 455b0f3ac9e254edab9f5a873d337abe5e6e3604 ] The QAT reset worker queues SR-IOV reenable work using a work_struct and completion embedded in an on-stack adf_sriov_dev_data. If the completion wait times out, the reset worker can return while device_sriov_wq still holds or executes the stack-backed work item. Cancel the work on the device_sriov_wq on timeout before the stack frame unwinds. Fixes: 4469f9b23468 ("crypto: qat - re-enable sriov after pf reset") Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit cf293c9c7424de0d04b51367d07f40570ce80231 Author: Manos Pitsidianakis Date: Fri Jun 5 14:23:51 2026 +0300 hwrng: core - fix rng list on registration error [ Upstream commit 3a5834db2b1ce25649f330e78efe1ccde78967fd ] hwrng_register(rng) does the following: 1. Checks if rng has name and read methods set 2. Checks if the name already exists 3. Adds rng to global rng_list 4. May try to set rng to current_rng If step 4 fails, it returns an error. However, it does not remove the rng from rng_list, causing a dangling reference which can result in use-after-free if the caller frees rng, since registration failed. Add a list_del_init() cleanup step. Fixes: 2bbb6983887f ("hwrng: use rng source with best quality") Signed-off-by: Manos Pitsidianakis Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 48b8b438d2342847a17524ddc49e3f3a25f4476a Author: Sandipan Das Date: Tue Jun 23 10:58:31 2026 +0530 perf vendor events amd: Update Zen 5 core events [ Upstream commit 047979af3bf6a118066c81099162d518de63abb1 ] Update definitions for the following events. * PMCx00A - Add missing unit masks * PMCx00B - Add missing unit masks and fix descriptions * PMCx00C - Add missing unit masks * PMCx00D - Add missing unit masks * PMCx025 - Add missing unit masks and fix descriptions Fixes: 45c072f2537a ("perf vendor events amd: Add Zen 5 core events") Signed-off-by: Sandipan Das Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 0f456e4eca61af0a2208b9e6f1ca01356c1fdfcf Author: Sandipan Das Date: Wed Jul 1 11:12:00 2026 +0530 perf/x86/amd/uncore: Add group validation [ Upstream commit edda9051e267b7390c7ce24b1b71434414ad156e ] The amd_uncore driver currently does not validate event groups and allows creation of groups with more events than the number of available hardware counters. Because of this, pmu->event_init() succeeds but counter assignment fails later in pmu->add() which returns -EBUSY once all counters are exhausted. Address this by introducing group validation in the pmu->event_init() path. Since the uncore PMUs have no per-event constraints and all counters of a PMU are interchangeable, validation is reduced to just counting the group members that target a PMU and ensuring that they fit within the available set of counters. Fixes: c43ca5091a37 ("perf/x86/amd: Add support for AMD NB and L2I "uncore" counters") Signed-off-by: Sandipan Das Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/750877d66e208603c3047f13eed6399625d43969.1782884387.git.sandipan.das@amd.com Signed-off-by: Sasha Levin commit c6466466185c1345f5940e202020235407ebf5a0 Author: Leo Yan Date: Thu Jul 2 20:51:36 2026 +0100 perf cs-etm: Fix thread leaks on trace queue init failure [ Upstream commit 50cd0d54f1f6dd9b3de7c0ad101bd41d06206ace ] cs_etm__init_traceid_queue() allocates the frontend and decode threads, if a later allocation fails, the error path does not drop thread reference that was already acquired. Release both thread pointers with thread__zput() on the error path, so does not leak thread references or leave stale pointers behind. Fixes: 951ccccdc715 ("perf cs-etm: Only track threads instead of PID and TIDs") Reviewed-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 47b3686dd841aca57edd84fbb3d17d4221830844 Author: Thomas Weißschuh Date: Fri Jul 3 19:30:16 2026 +0200 tools/nolibc: mark arg1 operand in __nolibc_syscall0() as write-only [ Upstream commit a3b2181459a2c74c03ddbad585f884eefc8ff8ff ] __nolibc_syscall0() does not set the arg1 variable before passing it to the asm block. This uninitialized variable read is undefined behavior. Clang can miscompile this. Mark the asm operand as write-only to fix this. Fixes: 8e1930296f92 ("tools/nolibc: Add support for SPARC") Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260703-nolibc-sparc-asm-v1-1-c7fe73e2e777@weissschuh.net Signed-off-by: Sasha Levin commit e3aa0446e37d143fd82f9614ebd69b5a480bbf71 Author: Xuanqiang Luo Date: Fri Jul 3 11:13:45 2026 +0800 fanotify: initialize permission event watchdog state [ Upstream commit a3aa899823dda059ab88a58254f9a605e03ec275 ] fanotify permission events are allocated with kmem_cache_alloc(), but fanotify_alloc_perm_event() does not initialize watchdog_cnt. The watchdog reads watchdog_cnt after the event is moved to access_list. A stale value can make it warn too early or skip the warning. Initialize watchdog_cnt when allocating a permission event. Fixes: b8cf8fda522d ("fanotify: add watchdog for permission events") Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260703031345.9354-1-xuanqiang.luo@linux.dev Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit f2a01deff7d0d5cc3dcbf2358dac113979303c8e Author: Pengpeng Hou Date: Tue Jun 30 15:28:27 2026 +0800 wifi: rtw89: fix HE extended capability length check [ Upstream commit 2aba608a86e9b099c9af2ea70b620552dee2b628 ] rtw89_mac_check_he_obss_narrow_bw_ru_iter() reads extended capability byte 10, but rejects only datalen values below 10. Byte 10 requires at least 11 bytes. Require datalen >= 11 before reading data[10]. Fixes: 8d540f9d2916 ("wifi: rtw89: disable 26-tone RU HE TB PPDU transmissions") Signed-off-by: Pengpeng Hou Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/2026063009025530.2-ccfa108-0024-wifi-rtw89-fix-HE-extended--pengpeng@iscas.ac.cn Signed-off-by: Sasha Levin commit 8f68dd7e4b2f9185cd9ab2c1350ff7b15fb0fb24 Author: Dmitry Morgun Date: Mon Jun 29 09:44:52 2026 +0000 wifi: rtw89: check return values in rtw89_ops_start_ap() [ Upstream commit a8cddb62c573f28eef5f887a8f3156e8ee22776a ] Several functions called in rtw89_ops_start_ap() may fail to allocate skb or fail to send H2C command to firmware, returning -ENOMEM or an error code. Their return values are ignored, so subsequent commands are executed with incorrect state. Check the return values and propagate errors. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a52e4f2ce0f5 ("rtw89: implement ieee80211_ops::start_ap and stop_ap") Signed-off-by: Dmitry Morgun Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260629094452.8709-1-d.morgun@ispras.ru Signed-off-by: Sasha Levin commit 74f26d1fa61b25f76707ff01176c030d69005360 Author: Chih-Kang Chang Date: Fri Nov 14 14:01:27 2025 +0800 wifi: rtw89: update format of addr cam H2C command [ Upstream commit 9dab26b9fa457ee538be650ca0bddf352c059e79 ] The addr cam H2C command is to tell firmware the addr related info. For RTL8922D and RTL8922A after firmware version 0.35.84.0, the addr cam must be updated with update mode to avoid clearing previously set fields. Update it accordingly. Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251114060128.35363-14-pkshih@realtek.com Stable-dep-of: a8cddb62c573 ("wifi: rtw89: check return values in rtw89_ops_start_ap()") Signed-off-by: Sasha Levin commit 19052c700bff0032f0337e686c2071092be4dfb0 Author: Ping-Ke Shih Date: Fri Nov 14 14:01:25 2025 +0800 wifi: rtw89: fill addr cam H2C command by struct [ Upstream commit 239dd70d776cf94f39000740b307c91e4f72d615 ] The addr cam is used to tell firmware the MAC address and BSSID associated to connected stations. Use struct instead of macros with pointer arithmetic to fill the data. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251114060128.35363-12-pkshih@realtek.com Stable-dep-of: a8cddb62c573 ("wifi: rtw89: check return values in rtw89_ops_start_ap()") Signed-off-by: Sasha Levin commit 847a5ba0ac75f609e3f88da905251f7a76179145 Author: Tzung-Bi Shih Date: Thu Jul 2 08:27:45 2026 +0000 platform/chrome: sensorhub: Fix memory overread in ring handler [ Upstream commit d1ceb2b2324717fa30b44d56ef0c52813e239569 ] `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length. Fixes: 145d59baff59 ("platform/chrome: cros_ec_sensorhub: Add FIFO support") Reviewed-by: Tomasz Figa Link: https://lore.kernel.org/r/20260702082745.1014968-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit e4e2d06623d32a98348de3496e40f4e317b2bc0a Author: Hisam Mehboob Date: Fri Jun 19 00:37:25 2026 +0500 selftests/rseq: Replace glibc-specific __GNUC_PREREQ with portable check [ Upstream commit d7b2769f8dba3e5f40d2a8a11988812d51160b17 ] Building the rseq selftests against musl libc fails because musl's does not provide the glibc-specific __GNUC_PREREQ macro: error: missing binary operator before token '(' Replace __GNUC_PREREQ(11, 1) with an equivalent check using __GNUC__ and __GNUC_MINOR__ directly. This pattern is portable across all C library implementations and is already used elsewhere in the tools/ tree (e.g., tools/include/linux/string.h). This also allows removing the #include , which was only needed for __GNUC_PREREQ. Fixes: 886ddfba933f ("selftests/rseq: Introduce thread pointer getters") Signed-off-by: Hisam Mehboob Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260618193724.589113-2-hisamshar@gmail.com Signed-off-by: Sasha Levin commit a776afa89424570bfa637ebf812ca281a5732904 Author: Hanlin Song Date: Fri May 22 11:18:24 2026 +0800 csky: Fix a4/a5 restoration in syscall trace path [ Upstream commit abb81e5ce7d995baa41556b8125fa59e28ba3be8 ] The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2 Fixes: e0bbb53843b5 ("csky: Fixup abiv2 syscall_trace break a4 & a5") Suggested-by: Guo Ren Signed-off-by: Hanlin Song Signed-off-by: Guo Ren (Alibaba DAMO Academy) Signed-off-by: Sasha Levin commit 5ac21c880dcd6415980261825c2b404fe4d073e9 Author: Sanjay Chitroda Date: Mon Jun 22 10:59:57 2026 +0530 iio: orientation: hid-sensor-rotation: Avoid race between callback setup and device exposure [ Upstream commit 0e32649a7cf3cd784862f8dc0c68a5134731bfff ] The driver currently exposes the IIO device to userspace before completing sensor hub callback registration, and similarly removes callbacks while the device can still be accessed during teardown. This creates a timing window where userspace may enable the buffer before callbacks are available. In such cases: - samples can be dropped, - buffered reads may observe stale or no data. Reorder probe and remove paths to ensure callbacks are active before device exposure and are removed after device is no longer accessible. This avoids a race window leading to data loss. Signed-off-by: Sanjay Chitroda Fixes: fc18dddc0625 ("iio: hid-sensors: Added device rotation support") Reviewed-by: Andy Shevchenko Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 69f73ad463b2e4b9d16c9eeff56b1c94f6bece9b Author: Srinivas Kandagatla Date: Wed Jul 1 20:30:05 2026 +0100 soundwire: qcom: Fix port exhaustion check in stream_alloc_ports [ Upstream commit 6ccec91c3535b07310e12d32fe9c67ff8d31d965 ] find_first_zero_bit(mask, n) returns n (not n+1) when all bits are set, so the guard `pn > maxport` is never true on exhaustion. The driver would silently call set_bit(maxport, port_mask) and assign the out-of-range port instead of returning -EBUSY. Fix the comparison to `pn >= maxport`. Fixes: 02efb49aa805 ("soundwire: qcom: add support for SoundWire controller") Reported-by: sashiko-bot Assisted-by: Claude Sonnet 4.6 Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260701193006.4113-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a13974410cee7c49f6ee08c5bda6daf94eaa7250 Author: Vladimir Zapolskiy Date: Tue Jun 30 17:42:14 2026 +0300 dmaengine: hisilicon: Return -ENOMEM on dynamic memory allocation in probe [ Upstream commit cbabdd6ce1b313b5877c7fbb2f5e2f7936564d2f ] Out of memory situation on driver's probe is expected to be reported to the driver's framework with a proper -ENOMEM error code. Fixes: e9f08b65250d ("dmaengine: hisilicon: Add Kunpeng DMA engine support") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Frank Li Link: https://patch.msgid.link/20260630144214.4080302-1-vz@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 32f69e6c95b59f9cfc649ebf352a204d23ba93d7 Author: Golla Nagendra Date: Tue Jun 30 12:18:43 2026 +0530 dmaengine: zynqmp_dma: fix race between runtime PM and device removal [ Upstream commit 516ba2d8b7aac4238f9fcbd58579c43c71b9b695 ] In zynqmp_dma_remove(), runtime PM was disabled only after checking state and doing a manual suspend. This can race with runtime PM in the remove/unbind (rmmod) path. Disable runtime PM first, then suspend only if the device is not already suspended. To prevent any further runtime PM transitions. Fixes: 72dd8b2914b5 ("dmaengine: zynqmp_dma: Add shutdown operation support") Co-developed-by: Prasanna Kumar T S M Signed-off-by: Prasanna Kumar T S M Signed-off-by: Golla Nagendra Reviewed-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260630064844.705173-2-nagendra.golla@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ec927657524be4438447944a58173c7baf7f2384 Author: Suraj Gupta Date: Fri Jun 26 14:56:54 2026 +0530 dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers [ Upstream commit 0b6d055edb55ecadadf54e930c2b4fab76fa9a5a ] Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts. Fixes: c0bba3a99f07 ("dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine") Tested-by: Folker Schwesinger Signed-off-by: Suraj Gupta Co-developed-by: Srinivas Neeli Signed-off-by: Srinivas Neeli Reviewed-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260626092656.1563871-2-suraj.gupta2@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit e429184ed58d67c61f06cc7508aa1b551199ae5b Author: Vladimir Zapolskiy Date: Wed Jul 1 23:07:03 2026 +0300 dmaengine: mediatek: mtk-uart-apdma: Return -ENOMEM on memory allocation failure [ Upstream commit 467265c750edd7ab43803deeafe7d3120a791d32 ] If dynamic memory allocation in driver's probe function execution fails, it should be reported to the driver's framework with -ENOMEM error code. Fixes: 9135408c3ace ("dmaengine: mediatek: Add MediaTek UART APDMA support") Signed-off-by: Vladimir Zapolskiy Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Frank Li Reviewed-by: Matthias Brugger Link: https://patch.msgid.link/20260701200703.117929-1-vz@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit bc3b5e6519b8df22d622a03eab6772784da97db4 Author: Gregory Price Date: Wed Jul 1 18:16:13 2026 -0400 mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug [ Upstream commit 2ebce860bdd7ae5e13002811bc9bbbf33fcfc221 ] We miss a failed allocation check for pgdat->per_cpu_nodestats, which results in a NULL deref when we offset into the per-cpu area. Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing at boot_nodestats so a later online can retry the allocation. hotadd_init_pgdat() returns NULL on failure, which __try_online_node() already maps to -ENOMEM. On failure nothing needs to be unwound: - the node is never marked online - per_cpu_nodestats is left pointing at boot_nodestats - __add_memory_resource() cleans up pending memblock resources - later online attempts retry the per_cpu_nodestats allocation Reported-by: Sashiko Link: https://sashiko.dev/#/patchset/20260627202243.758289-1-gourry%40gourry.net Fixes: 75ef71840539 ("mm, vmstat: add infrastructure for per-node vmstats") Signed-off-by: Gregory Price Acked-by: David Hildenbrand (Arm) Link: https://patch.msgid.link/20260701221613.2818148-1-gourry@gourry.net Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit d3498c7b587b7bed2cab90bef7c22a8d78bef7f8 Author: Gregory Price Date: Wed Feb 11 16:54:47 2026 -0500 mm: name the anonymous MMOP enum as enum mmop [ Upstream commit c5c48345135ff04e039377020df23294d59aa59a ] Give the MMOP enum (MMOP_OFFLINE, MMOP_ONLINE, etc) a proper type name so the compiler can help catch invalid values being assigned to variables of this type. Leave the existing functions returning int alone to allow for value-or-error pattern to remain unchanged without churn. mmop_default_online_type is left as int because it uses the -1 sentinal value to signal it hasn't been initialized yet. Keep the uint8_t buffer in offline_and_remove_memory() as-is for space efficiency, with an explicit cast when we consume the value. Move the enum definition before the CONFIG_MEMORY_HOTPLUG guard so it is unconditionally available for struct memory_block in memory.h. No functional change. Link: https://lore.kernel.org/linux-mm/3424eba7-523b-4351-abd0-3a888a3e5e61@kernel.org/ Link: https://lkml.kernel.org/r/20260211215447.2194189-1-gourry@gourry.net Signed-off-by: Gregory Price Suggested-by: Jonathan Cameron Suggested-by: "David Hildenbrand (arm)" Reviewed-by: Ben Cheatham Acked-by: David Hildenbrand (Arm) Reviewed-by: Dave Jiang Reviewed-by: Davidlohr Bueso Reviewed-by: Jonathan Cameron Cc: Danilo Krummrich Cc: Greg Kroah-Hartman Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Oscar Salvador Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Stable-dep-of: 2ebce860bdd7 ("mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug") Signed-off-by: Sasha Levin commit 420d65038c3443d283cf598cbc337e6c4c8124e3 Author: Israel Batista Date: Wed Oct 29 19:56:30 2025 +0000 mm: change type of state in struct memory_block [ Upstream commit 8bc7ba3d265d6ee698de4b1941b7e8f7d91a0562 ] The state of a memory block should be restricted to values specified in the documentation of the memory hotplug API. However, since the state field in the memory_block struct was defined as an unsigned long, this restriction was not enforced at compile time. With the introduction of the enum memory_block_state, it is now possible to incorporate the desired semantics in the field declaration and enforce these restrictions at compile time. [akpm@linux-foundation.org: fix whitespace, per Randy] Link: https://lkml.kernel.org/r/20251029195617.2210700-3-linux@israelbatista.dev.br Signed-off-by: Israel Batista Acked-by: David Hildenbrand Acked-by: Mike Rapoport (Microsoft) Reviewed-by: Lorenzo Stoakes Cc: Omar Sandoval Cc: Randy Dunlap Signed-off-by: Andrew Morton Stable-dep-of: 2ebce860bdd7 ("mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug") Signed-off-by: Sasha Levin commit fff12ff7b3c471891db8f37e7f045433c0141572 Author: Israel Batista Date: Wed Oct 29 19:56:28 2025 +0000 mm: convert memory block states (MEM_*) macros to enum [ Upstream commit 1a4f70f6851a1916c4f0e52731c7ecfe99bf36e6 ] Patch series "mm: Convert memory block states (MEM_*) macros to enums", v2. The MEM_* constants indicating the state of a memory block are currently defined as macros, meaning their definitions will be omitted from the debuginfo on most kernel builds. This makes it harder for debuggers to correctly map the block state at runtime, which can be quite useful when analysing errors related to memory hot plugging and unplugging with tools such as drgn. Converting the constants to an enum ensures the correct information is emitted by the compiler and available for the debugger, without needing to hard-code them into the debugger and track their changes. This patch series aims to replace the current macros with a newly created enum named memory_block_state, while also taking advantage of the compile time guarantees that we get when using enums. The first patch does the conversion of the macros to an enum, while the 2nd and 3rd patches use this enum to clean up some type declarations and make sure that only valid values are used. This patch (of 3): Converting the MEM_* constants from macros to an enum ensures that their values will be correctly emitted in the debug symbols, making it easier to trace the meaning of each value when debugging with tools such as drgn, without the need to hard-code the values. Since the values are mutually exclusive and they are not exposed directly to userspace, I also dropped the misleading pattern (1< Acked-by: David Hildenbrand Acked-by: Mike Rapoport (Microsoft) Reviewed-by: Lorenzo Stoakes Cc: Omar Sandoval Cc: Randy Dunlap Signed-off-by: Andrew Morton Stable-dep-of: 2ebce860bdd7 ("mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug") Signed-off-by: Sasha Levin commit d5f2f741a900123fbcb7c7c0a002b81306fbe242 Author: Sechang Lim Date: Wed Jul 1 08:07:51 2026 +0000 bpf,lsm: Drop bpf_prog_free from sleepable_lsm_hooks [ Upstream commit 2ce3f548cfc6a1fe4c53479cf8a21931cdfd51d8 ] __bpf_prog_put_rcu() is the call_rcu() callback for non-sleepable programs. security_bpf_prog_free() called from there fires bpf_prog_free in softirq; if a sleepable LSM prog is attached to that hook, might_fault() BUGs: BUG: sleeping function called from invalid context in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 5038 preempt_count: 101, expected: 0 Call Trace: __bpf_prog_enter_sleepable+0x1cd/0x320 kernel/bpf/trampoline.c:1255 bpf_trampoline_6442549705+0x53/0xd7 security_bpf_prog_free+0xde/0x130 security/security.c:5465 __bpf_prog_put_rcu+0xab/0xd0 kernel/bpf/syscall.c:2365 rcu_do_batch kernel/rcu/tree.c:2617 [inline] handle_softirqs+0x236/0x800 kernel/softirq.c:622 The call_rcu/call_rcu_tasks_trace split reflects the freed program's sleepability, not that of any attached observer. security_bpf_prog_free() also frees prog->aux->security, which has to stay after the grace period, so drop bpf_prog_free from sleepable_lsm_hooks rather than move the call. Non-sleepable observers still run there. Fixes: 1b67772e4e3f ("bpf,lsm: Refactor bpf_prog_alloc/bpf_prog_free LSM hooks") Signed-off-by: Sechang Lim Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260701080757.1394144-1-rhkrqnwk98@gmail.com Signed-off-by: Sasha Levin commit 01c5ad41cf4db820358502f03f3276d6f1bfe79f Author: Guillaume Maudoux Date: Tue Jun 30 11:57:23 2026 +0200 selftests/bpf: Mask socket type flags in mptcpify prog [ Upstream commit b4b8b334f6b535a86ab83f18d3d241fe01270bc3 ] The mptcpify BPF prog upgrades eligible TCP sockets to MPTCP, but only when the socket type is exactly SOCK_STREAM. Its update_socket_protocol() hook runs on the raw type from userspace, before the socket core masks it with SOCK_TYPE_MASK, so the type may still carry SOCK_CLOEXEC or SOCK_NONBLOCK in its upper bits and the equality check fails. As a result, a socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0) -- what common libraries do by default -- is silently left as plain TCP. This was hit in practice with curl. Since mptcpify.c is referenced as example code for enabling MPTCP transparently, the same mistake is likely to be copied into real deployments where it fails the same way and is hard to diagnose. Mask the type before comparing, mirroring the socket core. Extend the test to also create the server with SOCK_CLOEXEC set; the same masking is applied to start_server_addr() so a flagged type still listens. Fixes: ddba122428a7 ("selftests/bpf: Add mptcpify test") Signed-off-by: Guillaume Maudoux Signed-off-by: Andrii Nakryiko Reviewed-by: Matthieu Baerts (NGI0) Link: https://lore.kernel.org/bpf/20260630095723.564392-1-layus.on@gmail.com Signed-off-by: Sasha Levin commit d51a838da7a794260b5e90215d9c6e68d8f4fdda Author: Alexis Lothoré (eBPF Foundation) Date: Wed Nov 5 09:22:48 2025 +0100 selftests/bpf: Systematically add SO_REUSEADDR in start_server_addr [ Upstream commit 38e36514fcb01ff1cce84cd77a93906f233a4cb8 ] Some tests have to stop/start a server multiple time with the same listening address. Doing so without SO_REUSADDR leads to failures due to the socket still being in TIME_WAIT right after the first instance stop/before the second instance start. Instead of letting each test manually set SO_REUSEADDR on their servers, it can be done automatically by start_server_addr for all tests (and without any major downside). Enforce SO_REUSEADDR in start_server_addr for all tests. Signed-off-by: Alexis Lothoré (eBPF Foundation) Signed-off-by: Martin KaFai Lau Link: https://patch.msgid.link/20251105-start-server-soreuseaddr-v1-1-1bbd9c1f8d65@bootlin.com Stable-dep-of: b4b8b334f6b5 ("selftests/bpf: Mask socket type flags in mptcpify prog") Signed-off-by: Sasha Levin commit 5e9f69829835521aa2942d1d14bd0990fbc6991e Author: Leon Hwang Date: Wed Jun 24 23:51:14 2026 +0800 bpf: Copy per-CPU map value padding in copy_map_value_long() [ Upstream commit 7cf9cd98cf6f0df3befc167ca6b54c07014d71de ] In kernel, per-CPU map elements are stored with round_up(map->value_size, 8) bytes. On UAPI lookup paths, it copies the rounded size for each CPU into a temporary buffer. However, copy_map_value_long() passes 'map->value_size' to bpf_obj_memcpy(). When the map has special fields, bpf_obj_memcpy() copies around those fields with memcpy(), and does not copy the tail padding between 'map->value_size' and round_up(map->value_size, 8). The temporary UAPI lookup buffers are allocated without __GFP_ZERO. As a result, when the per-CPU map's value size is not equal to round_up(map->value_size, 8), UAPI LOOKUP_ELEM and its variants can return stale heap contents from that padding to user space. The same issue applies to bpf_iter for per-CPU maps. Pass round_up(map->value_size, 8) to bpf_obj_memcpy() from copy_map_value_long(), so per-CPU maps both with and without special fields copy the entire per-CPU slot. Remove the now redundant round_up() from bpf_obj_memcpy()'s long_memcpy path. Fixes: 448325199f57 ("bpf: Add copy_map_value_long to copy to remote percpu memory") Signed-off-by: Leon Hwang Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260624155115.85196-2-leon.hwang@linux.dev Signed-off-by: Sasha Levin commit e5f6d43168b2efdcc8ebbe8073a048b1a46c6410 Author: Yichong Chen Date: Wed Jun 24 10:50:55 2026 +0800 tools/bpf/bpftool: Reset vmlinux BTF after struct_ops commands [ Upstream commit f7f540e19751face50c68bb9ce58460fcb46c293 ] struct_ops frees the global btf_vmlinux object. In batch mode, a later struct_ops command can reuse stale state. Reset the BTF pointer and cached map info state. Fixes: 65c93628599d ("bpftool: Add struct_ops support") Signed-off-by: Yichong Chen Signed-off-by: Andrii Nakryiko Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/9F9017160ABE125F+20260624025055.1574875-3-chenyichong@uniontech.com Signed-off-by: Sasha Levin commit 82a43463ab0913590baf0043dd0da491890c9cfa Author: Yichong Chen Date: Wed Jun 24 10:50:54 2026 +0800 tools/bpf/bpftool: Reset vmlinux BTF after map commands [ Upstream commit 66d7e39e49b0dd57610c9b63afc65b4d5690983b ] get_map_kv_btf() caches the vmlinux BTF object when a map uses btf_vmlinux_value_type_id. map dump released that object when the command completed, but left the global pointer stale. The same cached object can also be returned to print_key_value(), which freed it directly. That leaves btf_vmlinux dangling before the command cleanup path runs. Use free_map_kv_btf() for per-entry cleanup, and reset the cached btf_vmlinux pointer when the map command releases the object. This keeps batch mode from reusing a freed BTF object. Fixes: 4e1ea33292ff ("bpftool: Support dumping a map with btf_vmlinux_value_type_id") Signed-off-by: Yichong Chen Signed-off-by: Andrii Nakryiko Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/bpf/9072F43B3F74DF91+20260624025055.1574875-2-chenyichong@uniontech.com Signed-off-by: Sasha Levin commit 46d27e56dbd6345b9c7b62b67ec57407bf3bf29a Author: Asad Kamal Date: Tue Jun 23 00:00:00 2026 +0000 drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup [ Upstream commit 6fa33f594e46e775a94097f71b486d7b006b6917 ] vddInd, vddciInd and mvddInd from VBIOS-parsed tables index into vddc, vddci and vddmem lookup tables without bounds checks across nine sites. Return -EINVAL when any index is out of range. Fixes: f83a9991648b ("drm/amd/powerplay: add Vega10 powerplay support (v5)") Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8a3db9f593b643904c6cc6d8a3f211c84ca6cf8a Author: Asad Kamal Date: Tue Jun 23 00:00:00 2026 +0000 drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup [ Upstream commit 3a8a05477cda6c8293e2b629495b42981dcaba32 ] vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range. Fixes: c82baa281843 ("drm/amd/powerplay: add Tonga dpm support (v3)") Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 68ce4f8223b78f8616ec7f4a02c38988eae627d2 Author: Uday Khare Date: Thu Jun 18 18:53:27 2026 +0530 regulator: tps6594: Fix device node reference leaks in multiphase loop [ Upstream commit 7fd28093b3effc4f92566466df364622830ec608 ] In tps6594_regulator_probe(), the multi-phase configuration loop calls of_find_node_by_name() to find buck nodes by name, and of_get_parent() twice to navigate to the PMIC parent node. None of the acquired node references (np, intermediate parent, np_pmic_parent) are ever released via of_node_put(), causing a reference leak on every loop iteration. Additionally, of_find_node_by_name() can return NULL, but the result was immediately passed to of_node_full_name() and of_get_parent() without a NULL check, which could lead to a NULL pointer dereference. Fix this by: - Adding a NULL check for np after of_find_node_by_name() - Storing the intermediate parent node in a local variable np_parent - Calling of_node_put() on np, np_parent and np_pmic_parent at the end of each loop iteration Fixes: f17ccc5deb4d ("regulator: tps6594-regulator: Add driver for TI TPS6594 regulators") Signed-off-by: Uday Khare Link: https://patch.msgid.link/20260618132327.11529-1-udaykhare77@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 506a6aca57c78e42cdf608eaf170f875b807b247 Author: Ian Rogers Date: Mon Jun 22 18:27:54 2026 -0700 perf tests: Fix flakiness in branch stack sampling tests [ Upstream commit 344d3aec164dba83a5520f23a0d46e13e904a205 ] The branch stack sampling test (test 130) runs short iteration-based workloads to verify syscall, kernel, and trap branch stack sampling. Specifically, `test_syscall()` and `test_kernel_branches()` run `perf bench syscall basic` with loop counts of 8000 and 1000, and `test_trap_eret_branches()` runs `traploop` with 1000 iterations. Because these loop limits are extremely small, the total benchmark runtimes last only a few milliseconds (or less). Under high load, virtualization, or coarse sampling conditions, PMU cycle sampling fails to capture enough samples inside the brief benchmark loops. This leads to false negatives where the script output lacks the expected syscall, kernel, or trap branch entries (e.g. "ERROR: Branches missing getppid[^ ]*/SYSCALL/"). Fix this by increasing the workload loop counts to 100,000 across all three test sections. Running 100,000 loops still finishes virtually instantaneously (less than 0.1 seconds), but generates enough iterations to guarantee robust branch stack capture. Fixes: b55878c90ab9 ("perf test: Add test for branch stack sampling") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 7980e2a92a76a8ca3367b1449b5d5862adabe420 Author: Ian Rogers Date: Wed Apr 8 17:02:16 2026 -0700 perf test: Fixes for check branch stack sampling [ Upstream commit 86d1095fdb7017a93e9d7be875775f7e5aa5c2f5 ] When filtering branch stack samples on user events they sample in user land but may have come from the kernel. Aarch64 avoids leaking the kernel address for kaslr reasons but other platforms, for now, don't. Be more permissive in allowing kernel addresses in the source of user branch stacks. When filtering branch stack samples on kernel events they sample in kernel land but may have come from user land. Avoid the target being a user address but allow the source to be in user land. Aarch64 may not leak the user land addresses (making them 0) but other platforms do. As the kernel address sampling implies privelege, just allow this. Increase the duration of the system call sampling test to make the likelihood of sampling a system call higher (increased from 1000 to 8000 loops - a number found through experimentation on an Intel Tigerlake laptop), also make the period of the event a prime number. Put unneeded perf record output into a temporary file so that the test output isn't cluttered. More clearly state which test is running and the pass, fail or skipped result of the test. These changes make the test on an Intel tigerlake laptop reliably pass rather than reliably fail. Signed-off-by: Ian Rogers Reviewed-by: James Clark Signed-off-by: Namhyung Kim Stable-dep-of: 344d3aec164d ("perf tests: Fix flakiness in branch stack sampling tests") Signed-off-by: Sasha Levin commit 82c0378d4569bee1389fca541183128310cc1268 Author: Ian Rogers Date: Mon Jun 22 18:27:53 2026 -0700 perf tests: Fix flakiness in BPF counters test on hybrid systems [ Upstream commit b02027776ac5bf737f1b76f3759f405e376097e5 ] The `perf stat --bpf-counters test` fails intermittently on hybrid architectures or systems with dynamic frequency scaling (DVFS). This happens because the test workload (`sqrtloop`) runs for a fixed 1-second duration, and the CPU frequency can scale dynamically between idle and maximum frequency. As the first run runs on a cold CPU and the second run runs on a warmed-up CPU (or vice versa), the number of instructions executed in 1 second differs by up to 2.2x, violating the comparison tolerance. Also, when running as root, BPF tracepoints and scheduling programs trigger frequently. Since standard `perf stat -e instructions` measures both user and kernel space instructions, it counts BPF helper and program execution overheads, whereas the BPF counters themselves do not self- measure. This introduces a large kernel-space instruction count discrepancy between standard and BPF counters. Fix these issues by: 1. Switching the workload to a strictly deterministic, iteration-based workload: `awk 'BEGIN { for (i=0; i<10000000; i++) sum+=i }'`. We pin the workload to a single random allowed CPU using `taskset -c $CPU` via a bash array. 2. Restricting the counted event to user-space only (`instructions:u` or `/u`). 3. Tightening the comparison tolerance from 20% to 15%. These modifications isolate the measurements to user-space instructions of the deterministic loop, which executes a virtually identical number of instructions on both runs (with less than 0.001% variation), eliminating Dynamic Frequency Scaling (DVFS), kernel scheduling noise, and BPF helper self-measurement overheads. Fixes: 2c0cb9f56020 ("perf test: Add a shell test for 'perf stat --bpf-counters' new option") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit da65eac26fb1fce87a0f0fa96681ef84ea297c1f Author: Namhyung Kim Date: Wed Mar 18 23:45:13 2026 -0700 perf test: Fix perf stat --bpf-counters on hybrid machines [ Upstream commit d9db9c8db56c3e378aa5c91637664f77ca5a6f72 ] The test constantly fails on my Intel hybrid machine. The issue was it has two events in the output even if I only gave it one event. $ perf stat -e instructions -- perf test -w sqrtloop Performance counter stats for 'perf test -w sqrtloop': 910,856,421 cpu_atom/instructions/ (28.05%) 14,852,865,997 cpu_core/instructions/ (96.79%) 1.014313341 seconds time elapsed 1.004114000 seconds user 0.008174000 seconds sys Let's modify the awk script to add the values for each line and print the total. The variable 'i' has a number of input lines that have valid output and variable 'c' has the sum of actual counter values. That way it should work on any platforms. Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Stable-dep-of: b02027776ac5 ("perf tests: Fix flakiness in BPF counters test on hybrid systems") Signed-off-by: Sasha Levin commit 0eec12a34b9495c40e5c544304155a45f671980e Author: Ian Rogers Date: Mon Jun 22 18:27:52 2026 -0700 perf tests: Fix flakiness in trace record and replay test [ Upstream commit 509a2b9a6e142697dd5f34cdd802e5b86eababa1 ] The `perf trace record and replay` test fails intermittently on slow or virtualized hosts because the default recording workload (`sleep 1`) occasionally completes without scheduling the target `nanosleep` or `clock_nanosleep` system calls inside the recorded sample window, resulting in the error: `Failed: cannot find *nanosleep syscall`. Generalize the `perf_record_with_retry` helper in `tests/shell/lib/perf_record.sh` to support a custom record command prefix via the `PERF_RECORD_CMD` environment variable (defaulting to "perf record"). Update `trace_record_replay.sh` to use this robust retry loop running with `PERF_RECORD_CMD="perf trace record"` and a base workload of `sleep`. The test will automatically retry with scaled sleep durations (from 0.01s up to 2.0s) until the required `nanosleep` event is successfully captured. Fixes: 15bcfb96d0dd ("perf test: Add trace record and replay test") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 81877759d71612d339ea7f23ac3757d77ca94b75 Author: Ian Rogers Date: Mon Jun 22 18:27:49 2026 -0700 perf tests: Add robust record retry helper and use subsecond workloads [ Upstream commit 74dba58222f0d34cf8bd3eba1a6926e9654d4b6b ] Introduce `perf_record_with_retry` and `perf_record_cleanup` in a shared library `tests/shell/lib/perf_record.sh` to prevent record test failures caused by transient recording or workload delays. Update `record.sh`, `record_lbr.sh`, `pipe_test.sh`, `kvm.sh`, and `stat_all_pfm.sh` to use this robust record retry logic. These tests now start with very short durations (e.g. 0.01 seconds) and scale up if the initial recording failed to capture samples, significantly improving test execution speed on success while remaining resilient to slow systems. Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Stable-dep-of: 509a2b9a6e14 ("perf tests: Fix flakiness in trace record and replay test") Signed-off-by: Sasha Levin commit 2ab5938f8427ccd261bee95d91cc7a6311563cc3 Author: Ian Rogers Date: Sat Nov 22 00:19:29 2025 -0800 perf test kvm: Add some basic perf kvm test coverage [ Upstream commit b58261584d2f6b5241ac1693026242ef2f2148b4 ] Setup qemu with KVM then run kvm stat and some host recording/reporting/build-id tests. Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Stable-dep-of: 509a2b9a6e14 ("perf tests: Fix flakiness in trace record and replay test") Signed-off-by: Sasha Levin commit f597922c6e52124a05117d22c4d68e1e3ed85294 Author: Ian Rogers Date: Mon Jun 22 18:27:50 2026 -0700 perf tests: Skip metrics validation if system-wide recording lacks permission [ Upstream commit 8953bfd8820b6525032023fda3a420098c1823ae ] The metrics value validation test requires system-wide recording (`-a`), which can fail on systems without root permissions or where paranoid levels restrict tracing. Add a check to skip the test if `-a` is not supported. Also fix false negatives during validation by updating parse error string patterns and resolving issues in metric list generation. Fixes: 3ad7092f5145 ("perf test: Add metric value validation test") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 98e165f28d9b449e3586c87c0fcf73b6eda86972 Author: Namhyung Kim Date: Thu Dec 18 17:18:19 2025 -0800 perf test: Do not skip when some metrics tests succeeded [ Upstream commit 1c89bc1b95fa9058f3e7cd37f1142939261417d5 ] I think the return value of SKIP (2) should be used when it skipped the entire test suite rather than a few of them. While the FAIL should be reserved if any of test failed. $ perf test -vv 110 110: perf all metrics test: --- start --- test child forked, pid 2496399 Testing tma_core_bound Testing tma_info_core_ilp Testing tma_info_memory_l2mpki Testing tma_memory_bound Testing tma_bottleneck_irregular_overhead Testing tma_bottleneck_mispredictions Testing tma_info_bad_spec_branch_misprediction_cost Testing tma_info_bad_spec_ipmisp_cond_ntaken Testing tma_info_bad_spec_ipmisp_cond_taken Testing tma_info_bad_spec_ipmisp_indirect Testing tma_info_bad_spec_ipmisp_ret Testing tma_info_bad_spec_ipmispredict Testing tma_info_branches_callret Testing tma_info_branches_cond_nt Testing tma_info_branches_cond_tk Testing tma_info_branches_jump Testing tma_info_branches_other_branches Testing tma_branch_mispredicts Testing tma_clears_resteers Testing tma_machine_clears Testing tma_mispredicts_resteers Testing tma_bottleneck_big_code Testing tma_icache_misses Testing tma_itlb_misses Testing tma_unknown_branches Testing tma_info_bad_spec_spec_clears_ratio Testing tma_other_mispredicts Testing tma_branch_instructions Testing tma_info_frontend_tbpc Testing tma_info_inst_mix_bptkbranch Testing tma_info_inst_mix_ipbranch Testing tma_info_inst_mix_ipcall Testing tma_info_inst_mix_iptb Testing tma_info_system_ipfarbranch Testing tma_info_thread_uptb Testing tma_bottleneck_branching_overhead Testing tma_nop_instructions Testing tma_bottleneck_compute_bound_est Testing tma_divider Testing tma_ports_utilized_3m Testing tma_bottleneck_instruction_fetch_bw Testing tma_frontend_bound Testing tma_assists Testing tma_other_nukes Testing tma_serializing_operation Testing tma_bottleneck_data_cache_memory_bandwidth Testing tma_fb_full Testing tma_mem_bandwidth Testing tma_sq_full Testing tma_bottleneck_data_cache_memory_latency Testing tma_l1_latency_dependency Testing tma_l2_bound Testing tma_l3_hit_latency Testing tma_mem_latency Testing tma_store_latency Testing tma_bottleneck_memory_synchronization Testing tma_contested_accesses Testing tma_data_sharing Testing tma_false_sharing Testing tma_bottleneck_memory_data_tlbs Testing tma_dtlb_load Testing tma_dtlb_store Testing tma_backend_bound Testing tma_bottleneck_other_bottlenecks Testing tma_bottleneck_useful_work Testing tma_retiring Testing tma_info_memory_fb_hpki Testing tma_info_memory_l1mpki Testing tma_info_memory_l1mpki_load Testing tma_info_memory_l2hpki_all Testing tma_info_memory_l2hpki_load Testing tma_info_memory_l2mpki_all Testing tma_info_memory_l2mpki_load Testing tma_l1_bound Testing tma_l3_bound Testing tma_info_memory_l2mpki_rfo Testing tma_fp_scalar Testing tma_fp_vector Testing tma_fp_vector_128b Testing tma_fp_vector_256b Testing tma_fp_vector_512b Testing tma_port_0 Testing tma_x87_use Testing tma_info_botlnk_l0_core_bound_likely Testing tma_info_core_fp_arith_utilization Testing tma_info_pipeline_execute Testing tma_info_system_gflops Testing tma_info_thread_execute_per_issue Testing tma_dsb Testing tma_info_botlnk_l2_dsb_bandwidth Testing tma_info_frontend_dsb_coverage Testing tma_decoder0_alone Testing tma_dsb_switches Testing tma_info_botlnk_l2_dsb_misses Testing tma_info_frontend_dsb_switch_cost Testing tma_info_frontend_ipdsb_miss_ret Testing tma_mite Testing tma_mite_4wide Testing CPUs_utilized Testing backend_cycles_idle [Ignored backend_cycles_idle] failed but as a Default metric this can be expected Performance counter stats for 'perf test -w noploop': cpu-cycles:u stalled-cycles-backend:u 1.014051473 seconds time elapsed 1.005718000 seconds user 0.008013000 seconds sys Testing branch_frequency Testing branch_miss_rate Testing cs_per_second Testing cycles_frequency Testing frontend_cycles_idle [Ignored frontend_cycles_idle] failed but as a Default metric this can be expected Performance counter stats for 'perf test -w noploop': cpu-cycles:u stalled-cycles-frontend:u 1.012813656 seconds time elapsed 1.004603000 seconds user 0.008004000 seconds sys Testing insn_per_cycle Testing migrations_per_second Testing page_faults_per_second Testing stalled_cycles_per_instruction [Ignored stalled_cycles_per_instruction] failed but as a Default metric this can be expected Error: No supported events found. The stalled-cycles-backend:u event is not supported. Testing tma_bad_speculation Testing l1d_miss_rate Testing llc_miss_rate Testing dtlb_miss_rate Testing itlb_miss_rate [Ignored itlb_miss_rate] failed but as a Default metric this can be expected Performance counter stats for 'perf test -w noploop': iTLB-loads:u 3,097 iTLB-load-misses:u 1.012766732 seconds time elapsed 1.004318000 seconds user 0.008002000 seconds sys Testing l1i_miss_rate [Ignored l1i_miss_rate] failed but as a Default metric this can be expected Performance counter stats for 'perf test -w noploop': L1-icache-load-misses:u L1-icache-loads:u 1.013606395 seconds time elapsed 1.001371000 seconds user 0.011968000 seconds sys Testing l1_prefetch_miss_rate [Ignored l1_prefetch_miss_rate] failed but as a Default metric this can be expected Error: No supported events found. The L1-dcache-prefetches:u event is not supported. Testing tma_info_botlnk_l2_ic_misses Testing tma_info_frontend_fetch_upc Testing tma_info_frontend_icache_miss_latency Testing tma_info_frontend_ipunknown_branch Testing tma_info_frontend_lsd_coverage Testing tma_info_memory_tlb_code_stlb_mpki Testing tma_info_pipeline_fetch_dsb Testing tma_info_pipeline_fetch_lsd Testing tma_info_pipeline_fetch_mite Testing tma_info_pipeline_fetch_ms Testing tma_fetch_bandwidth Testing tma_lsd Testing tma_branch_resteers Testing tma_code_l2_hit Testing tma_code_l2_miss Testing tma_code_stlb_hit Testing tma_code_stlb_miss Testing tma_code_stlb_miss_2m Testing tma_code_stlb_miss_4k Testing tma_lcp Testing tma_ms_switches Testing tma_info_core_flopc Testing tma_info_inst_mix_iparith Testing tma_info_inst_mix_iparith_avx128 Testing tma_info_inst_mix_iparith_avx256 Testing tma_info_inst_mix_iparith_avx512 Testing tma_info_inst_mix_iparith_scalar_dp Testing tma_info_inst_mix_iparith_scalar_sp Testing tma_info_inst_mix_ipflop Testing tma_info_inst_mix_ippause Testing tma_fetch_latency Testing tma_fp_arith Testing tma_fp_assists Testing tma_info_system_cpu_utilization Testing tma_info_system_dram_bw_use [Skipped tma_info_system_dram_bw_use] Not supported events Performance counter stats for 'perf test -w noploop': UNC_ARB_TRK_REQUESTS.ALL:u UNC_ARB_COH_TRK_REQUESTS.ALL:u 1,013,554,749 duration_time 1.013527265 seconds time elapsed 1.005417000 seconds user 0.008011000 seconds sys Testing tma_info_frontend_l2mpki_code Testing tma_info_frontend_l2mpki_code_all Testing tma_info_inst_mix_ipload Testing tma_info_inst_mix_ipstore Testing tma_info_memory_latency_load_l2_miss_latency Testing tma_lock_latency Testing tma_info_memory_core_l1d_cache_fill_bw_2t Testing tma_info_memory_core_l2_cache_fill_bw_2t Testing tma_info_memory_core_l3_cache_access_bw_2t Testing tma_info_memory_core_l3_cache_fill_bw_2t Testing tma_info_memory_l1d_cache_fill_bw Testing tma_info_memory_l2_cache_fill_bw Testing tma_info_memory_l3_cache_access_bw Testing tma_info_memory_l3_cache_fill_bw Testing tma_info_memory_l3mpki Testing tma_info_memory_load_miss_real_latency Testing tma_info_memory_mix_bus_lock_pki Testing tma_info_memory_mix_uc_load_pki Testing tma_info_memory_mlp Testing tma_info_memory_tlb_load_stlb_mpki Testing tma_info_memory_tlb_page_walks_utilization Testing tma_info_memory_tlb_store_stlb_mpki Testing tma_info_system_mem_parallel_reads [Skipped tma_info_system_mem_parallel_reads] Not supported events Performance counter stats for 'perf test -w noploop': UNC_ARB_DAT_OCCUPANCY.RD:u UNC_ARB_DAT_OCCUPANCY.RD/cmask=1/ 1.013354884 seconds time elapsed 1.009239000 seconds user 0.004004000 seconds sys Testing tma_info_system_mem_read_latency [Skipped tma_info_system_mem_read_latency] Not supported events Performance counter stats for 'perf test -w noploop': UNC_ARB_DAT_OCCUPANCY.RD:u UNC_ARB_TRK_OCCUPANCY.RD UNC_ARB_TRK_REQUESTS.RD 1.012882143 seconds time elapsed 1.004600000 seconds user 0.008036000 seconds sys Testing tma_info_thread_cpi Testing tma_streaming_stores Testing tma_dram_bound Testing tma_store_bound Testing tma_l2_hit_latency Testing tma_load_stlb_hit Testing tma_load_stlb_miss Testing tma_load_stlb_miss_1g Testing tma_load_stlb_miss_2m Testing tma_load_stlb_miss_4k Testing tma_store_stlb_hit Testing tma_store_stlb_miss Testing tma_store_stlb_miss_1g Testing tma_store_stlb_miss_2m Testing tma_store_stlb_miss_4k Testing tma_info_memory_latency_data_l2_mlp Testing tma_info_memory_latency_load_l2_mlp Testing tma_info_pipeline_ipassist Testing tma_microcode_sequencer Testing tma_ms Testing tma_info_system_kernel_cpi [Failed tma_info_system_kernel_cpi] Metric contains missing events Error: No supported events found. Access to performance monitoring and observability operations is limited. Consider adjusting /proc/sys/kernel/perf_event_paranoid setting to open access to performance monitoring and observability operations for processes without CAP_PERFMON, CAP_SYS_PTRACE or CAP_SYS_ADMIN Linux capability. More information can be found at 'Perf events and tool security' document: https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html perf_event_paranoid setting is 2: -1: Allow use of (almost) all events by all users Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK >= 0: Disallow raw and ftrace function tracepoint access >= 1: Disallow CPU event access >= 2: Disallow kernel profiling To make the adjusted perf_event_paranoid setting permanent preserve it in /etc/sysctl.conf (e.g. kernel.perf_event_paranoid = ) Testing tma_info_system_kernel_utilization [Failed tma_info_system_kernel_utilization] Metric contains missing events Error: No supported events found. Access to performance monitoring and observability operations is limited. Consider adjusting /proc/sys/kernel/perf_event_paranoid setting to open access to performance monitoring and observability operations for processes without CAP_PERFMON, CAP_SYS_PTRACE or CAP_SYS_ADMIN Linux capability. More information can be found at 'Perf events and tool security' document: https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html perf_event_paranoid setting is 2: -1: Allow use of (almost) all events by all users Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK >= 0: Disallow raw and ftrace function tracepoint access >= 1: Disallow CPU event access >= 2: Disallow kernel profiling To make the adjusted perf_event_paranoid setting permanent preserve it in /etc/sysctl.conf (e.g. kernel.perf_event_paranoid = ) Testing tma_info_pipeline_retire Testing tma_info_thread_clks Testing tma_info_thread_uoppi Testing tma_memory_operations Testing tma_other_light_ops Testing tma_ports_utilization Testing tma_ports_utilized_0 Testing tma_ports_utilized_1 Testing tma_ports_utilized_2 Testing C10_Pkg_Residency [Failed C10_Pkg_Residency] Metric contains missing events WARNING: grouped events cpus do not match. Events with CPUs not matching the leader will be removed from the group. anon group { cstate_pkg/c10-residency/, msr/tsc/ } Error: No supported events found. Invalid event (cstate_pkg/c10-residency/u) in per-thread mode, enable system wide with '-a'. Testing C2_Pkg_Residency [Failed C2_Pkg_Residency] Metric contains missing events WARNING: grouped events cpus do not match. Events with CPUs not matching the leader will be removed from the group. anon group { cstate_pkg/c2-residency/, msr/tsc/ } Error: No supported events found. Invalid event (cstate_pkg/c2-residency/u) in per-thread mode, enable system wide with '-a'. Testing C3_Pkg_Residency [Failed C3_Pkg_Residency] Metric contains missing events WARNING: grouped events cpus do not match. Events with CPUs not matching the leader will be removed from the group. anon group { msr/tsc/, cstate_pkg/c3-residency/ } Error: No supported events found. Invalid event (msr/tsc/u) in per-thread mode, enable system wide with '-a'. Testing C6_Core_Residency [Failed C6_Core_Residency] Metric contains missing events WARNING: grouped events cpus do not match. Events with CPUs not matching the leader will be removed from the group. anon group { cstate_core/c6-residency/, msr/tsc/ } Error: No supported events found. Invalid event (cstate_core/c6-residency/u) in per-thread mode, enable system wide with '-a'. Testing C6_Pkg_Residency [Failed C6_Pkg_Residency] Metric contains missing events WARNING: grouped events cpus do not match. Events with CPUs not matching the leader will be removed from the group. anon group { cstate_pkg/c6-residency/, msr/tsc/ } Error: No supported events found. Invalid event (cstate_pkg/c6-residency/u) in per-thread mode, enable system wide with '-a'. Testing C7_Core_Residency [Failed C7_Core_Residency] Metric contains missing events WARNING: grouped events cpus do not match. Events with CPUs not matching the leader will be removed from the group. anon group { cstate_core/c7-residency/, msr/tsc/ } Error: No supported events found. Invalid event (cstate_core/c7-residency/u) in per-thread mode, enable system wide with '-a'. Testing C7_Pkg_Residency [Failed C7_Pkg_Residency] Metric contains missing events WARNING: grouped events cpus do not match. Events with CPUs not matching the leader will be removed from the group. anon group { cstate_pkg/c7-residency/, msr/tsc/ } Error: No supported events found. Invalid event (cstate_pkg/c7-residency/u) in per-thread mode, enable system wide with '-a'. Testing C8_Pkg_Residency [Failed C8_Pkg_Residency] Metric contains missing events WARNING: grouped events cpus do not match. Events with CPUs not matching the leader will be removed from the group. anon group { cstate_pkg/c8-residency/, msr/tsc/ } Error: No supported events found. Invalid event (cstate_pkg/c8-residency/u) in per-thread mode, enable system wide with '-a'. Testing C9_Pkg_Residency [Failed C9_Pkg_Residency] Metric contains missing events WARNING: grouped events cpus do not match. Events with CPUs not matching the leader will be removed from the group. anon group { cstate_pkg/c9-residency/, msr/tsc/ } Error: No supported events found. Invalid event (cstate_pkg/c9-residency/u) in per-thread mode, enable system wide with '-a'. Testing tma_info_core_epc Testing tma_info_system_core_frequency Testing tma_info_system_power [Skipped tma_info_system_power] Not supported events Performance counter stats for 'perf test -w noploop': Joules power/energy-pkg/u 1,013,238,256 duration_time 1.013223072 seconds time elapsed 0.995924000 seconds user 0.011903000 seconds sys Testing tma_info_system_power_license0_utilization Testing tma_info_system_power_license1_utilization Testing tma_info_system_power_license2_utilization Testing tma_info_system_turbo_utilization Testing tma_info_inst_mix_ipswpf Testing tma_info_memory_prefetches_useless_hwpf Testing tma_info_core_coreipc Testing tma_info_thread_ipc Testing tma_heavy_operations Testing tma_light_operations Testing tma_info_core_core_clks Testing tma_info_system_smt_2t_utilization Testing tma_info_thread_slots_utilization Testing UNCORE_FREQ [Skipped UNCORE_FREQ] Not supported events Performance counter stats for 'perf test -w noploop': UNC_CLOCK.SOCKET:u 1,015,993,466 duration_time 1.015949387 seconds time elapsed 1.007676000 seconds user 0.008029000 seconds sys Testing tma_info_system_socket_clks [Failed tma_info_system_socket_clks] Metric contains missing events Error: No supported events found. Invalid event (UNC_CLOCK.SOCKET:u) in per-thread mode, enable system wide with '-a'. Testing tma_info_inst_mix_instructions Testing tma_info_system_cpus_utilized Testing tma_info_system_mux Testing tma_info_system_time Testing tma_info_thread_slots Testing tma_few_uops_instructions Testing tma_4k_aliasing Testing tma_cisc Testing tma_fp_divider Testing tma_int_divider Testing tma_slow_pause Testing tma_split_loads Testing tma_split_stores Testing tma_store_fwd_blk Testing tma_alu_op_utilization Testing tma_load_op_utilization Testing tma_mixing_vectors Testing tma_store_op_utilization Testing tma_port_1 Testing tma_port_5 Testing tma_port_6 Testing smi_cycles [Skipped smi_cycles] Not supported events Performance counter stats for 'perf test -w noploop': msr/smi/u msr/aperf/u 3,965,789,327 cycles:u 1.012779591 seconds time elapsed 1.004579000 seconds user 0.007972000 seconds sys Testing smi_num [Failed smi_num] Metric contains missing events Error: No supported events found. Invalid event (msr/smi/u) in per-thread mode, enable system wide with '-a'. Testing tsx_aborted_cycles Testing tsx_cycles_per_elision Testing tsx_cycles_per_transaction Testing tsx_transactional_cycles ---- end(-1) ---- 110: perf all metrics test : FAILED! Signed-off-by: Namhyung Kim Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 8953bfd8820b ("perf tests: Skip metrics validation if system-wide recording lacks permission") Signed-off-by: Sasha Levin commit 79ddb9f98a8ae22d8e7387e6767a8e62ddb04394 Author: Ian Rogers Date: Wed Nov 19 11:30:47 2025 -0800 perf test all metrics: Fully ignore Default metric failures [ Upstream commit 41b67ab3d2f5be9d0b6e5ba9cbec97c820fc50e8 ] Determine if a metric is default from `perf list --raw-dump $m` eg: ``` $ perf list --raw-dump l1_prefetch_miss_rate Default4 l1_prefetch_miss_rate ``` If a metric has "not supported" or "no supported events" then ignore these failures for default metrics. Tidy up the skip/fail messages in the output to make them easier to spot/read. ``` $ perf list -vv "all metrics" ... Testing llc_miss_rate [Ignored llc_miss_rate] failed but as a Default metric this can be expected Error: No supported events found. The LLC-loads event is not supported. ... ``` Reported-by: Thomas Richter Closes: https://lore.kernel.org/linux-perf-users/20251119104751.51960-1-tmricht@linux.ibm.com/ Reported-by: Namhyung Kim Reported-by: James Clark Closes: https://lore.kernel.org/lkml/aRi9xnwdLh3Dir9f@google.com/ Signed-off-by: Ian Rogers Reviewed-by: James Clark Tested-by: Thomas Richter Signed-off-by: Namhyung Kim Stable-dep-of: 8953bfd8820b ("perf tests: Skip metrics validation if system-wide recording lacks permission") Signed-off-by: Sasha Levin commit 2f1b696dbbb26e3a7e3ea9c1f00116d6be771f02 Author: Ian Rogers Date: Tue Nov 11 13:22:02 2025 -0800 perf test metrics: Update all metrics for possibly failing default metrics [ Upstream commit 91c1949d768520d9befa7761eb97c3826997da25 ] Default metrics may use unsupported events and be ignored. These metrics shouldn't cause metric testing to fail. Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Stable-dep-of: 8953bfd8820b ("perf tests: Skip metrics validation if system-wide recording lacks permission") Signed-off-by: Sasha Levin commit 97660f007672adffa1e74a6411c9cf2c2fd37855 Author: Ian Rogers Date: Mon Jun 22 18:27:47 2026 -0700 perf test: Truncate test description to fit terminal width [ Upstream commit 32e6312f7e397bf0b731b43a6504966398af0788 ] The parallel test harness uses the carriage return delete escape sequence `PERF_COLOR_DELETE_LINE` ("\033[A\33[2K\r") to erase and update the "Running (X active)" progress lines. However, if a test description is longer than the terminal width, the line wraps around. When this happens, the cursor up escape sequence `\033[A` only moves the cursor to the last wrapped row, leaving the top half of the description printed on the previous line. This leads to name duplication and output corruption spilling over multiple rows on consoles narrower than the maximum description length (e.g., 101 columns wide). Fix this by dynamically querying the terminal width using `get_term_dimensions` and truncating the printed test descriptions using the `%-*.*s` printf format. We reserve 35 characters for prefix, status, and spacing metrics to guarantee the progress line never wraps. Fixes: 0e036dcad4e6 ("perf test: Display number of active running tests") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit de9c6dc47601fafdb44c71fa7261674e24578161 Author: Ian Rogers Date: Thu Jun 4 15:06:27 2026 -0700 perf test: Truncate printed test descriptions dynamically to avoid terminal wrapping [ Upstream commit 9e3fcab6fbecebbcffeafeb5db612a57688cb7f4 ] When test descriptions are extremely long (e.g., the truncated perf.data graceful handling test is 103 characters long), they wrap across terminal boundaries. Because the ANSI escape code to delete the line (PERF_COLOR_DELETE_LINE) only clears a single terminal line, visual wrapping leaves orphan wrapped lines on the screen, which results in the test description being printed multiple times. Resolve this by checking the terminal width (get_term_dimensions) and dynamically truncating the printed test description to fit within the available columns, leaving safety space for the prefix index and status suffix. Also, remove the width padding from the test suite headers which do not display inline status messages. This prevents their trailing colons from wrapping onto new lines on standard width terminals. Finally, avoid GCC 16's -Wformat-truncation warnings by delegating the description padding to pr_info's %-*s format specifier instead of padding within a temporary buffer, and clamp the truncation limit to the temporary buffer's size. JUnit XML output and the failure summary report still print the full, untruncated test descriptions. Assisted-by: Gemini-CLI:Google Gemini 3.1 Pro Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 32e6312f7e39 ("perf test: Truncate test description to fit terminal width") Signed-off-by: Sasha Levin commit 17e39d310b8845cf1c7ce166b7fe8027f5413524 Author: Ian Rogers Date: Tue Jun 2 10:41:25 2026 -0700 perf test: Add -j/--junit option for JUnit XML test reports [ Upstream commit e2c545737bf4387d1217d3608274823421e1dbf2 ] Add a -j/--junit command line option to generate standard JUnit XML format test reports. The generated file defaults to 'test.xml' if no filename is specified, but allows users to override the path (e.g. -jmytest.xml). The XML report captures individual test suite and subtest execution latency, alongside XML-escaped failure logs and skip reasons, while preserving the full multi-process concurrency speed of parallel test execution. Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20260602174129.3192312-15-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 32e6312f7e39 ("perf test: Truncate test description to fit terminal width") Signed-off-by: Sasha Levin commit bdd10298be150e3bfb63b3c680ff26a5fd3acc62 Author: Ian Rogers Date: Tue Jun 2 10:41:22 2026 -0700 perf test: Fix subtest status alignment for multi-digit indexes [ Upstream commit 94ac3ce427c8f80d699909c85a7cb70a589c562d ] When running perf test, the status column (: Ok) became misaligned when subtest indexes reached 2 or 3 digits (e.g. 9.100 vs 9.9 vs 10.1). This occurred because the subtest description field width (subw) was statically fixed to width - 2, assuming all subtest index prefixes were exactly 7 characters wide. Dynamically calculate subw based on the exact character length of the test suite and subtest index prefix. This ensures the status column is perfectly aligned vertically across all test outputs regardless of subtest index digit count. Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 32e6312f7e39 ("perf test: Truncate test description to fit terminal width") Signed-off-by: Sasha Levin commit 68a81a1eb8d3c3ad46c9ff6b3a6904d11276c644 Author: Ian Rogers Date: Tue Jun 2 10:41:21 2026 -0700 perf test: Add summary reporting [ Upstream commit 33f20342ba525ef75fd9734db71e9823fe65e769 ] Currently, when running test suites (perf test), users must scroll through hundreds of lines of console output to manually tally the number of passed, skipped, or failed test cases. Introduce an automated, global execution summary printed at the absolute tail of the test run: 1. Track counts mid-flight inside the print_test_result() accumulator, clearly separating pass counts into standalone main tests vs. individual subtests (where num_test_cases > 1). 2. Accumulate the precise descriptions of all failed test cases directly into a global string buffer, formatted with their suite indices (e.g., 3.1: Parse event definition strings) for effortless cross-referencing. 3. Define a summary printer function print_tests_summary() that emits a colored outline of the final pass, skip, and fail totals, followed by the explicit list of failed tests. 4. Invoke the summary printer right before freeing the test array at the absolute tail of __cmd_test(), guaranteeing that the summary is successfully printed even if an internal emergency signal cleanup occurs or if the user interrupts the run early. Example output: ``` $ sudo perf test -v 1: vmlinux symtab matches kallsyms : Skip 2: Detect openat syscall event : Ok 3: Detect openat syscall event on all cpus : Ok ... 163: perf trace summary : Ok === Test Summary === Passed main tests : 123 Passed subtests : 145 Skipped tests : 22 Failed tests : 6 List of failed tests: 92: perf kvm tests 95: kernel lock contention analysis test 120: perf metrics value validation 124: Check branch stack sampling 143: perftool-testsuite_probe 158: test Intel TPEBS counting mode ``` Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 32e6312f7e39 ("perf test: Truncate test description to fit terminal width") Signed-off-by: Sasha Levin commit 456e1e7ce209270b3952692e3f3dcca3d2531842 Author: Ian Rogers Date: Tue Jun 2 10:41:20 2026 -0700 perf test: Show snippet failure output for verbose=1 [ Upstream commit b5a4a361f5cfb8f6f6f0a59536fd5fad11ed9f5f ] Currently, when running tests in verbose mode (-v), if a test case fails, the entire raw standard error buffer is dumped to stderr via fprintf(stderr, "%s", child->err_output.buf). For tests that generate massive amounts of debugging or logging output before dying, this results in multi-page terminal dumps where highly critical diagnostic keywords (error, fail, segv) are easily lost. Implement a smart, bounded snippet string processor to improve failure triaging: 1. Introduce a configurable quota limit static unsigned int failure_snippet_lines = 10; accessible via a new command-line option --failure-snippet-lines . 2. Parse the raw error buffer dynamically into lines and run a three-pass extraction algorithm: - Pass 0: Always select the very first line of the log as an initial outline marker. - Pass 1: Scan forward from the top of the log to pick up to N lines that contain case-insensitive failure keywords (error, fail, segv, abort) to isolate the root cause. Automatically pull in the immediate subsequent line as highly-prioritized context. Allow adjacent matching lines to overlap without dropping context by evaluating keywords for all lines (e.g. when "Failed to report" is followed by "Error:"). - Pass 2: If quota remains, scan backward from the absolute tail of the log to capture trailing crash or abort context. 3. Output the selected lines in their original chronological order, inserting a clear ... separator between non-contiguous line jumps. 4. Wrap matched failure keywords dynamically in bold red (PERF_COLOR_RED) to immediately draw the eye to failures. 5. Invoke the smart processor purely when verbose == 1 && ret == TEST_FAIL in both finish_test and finish_tests_parallel, leaving raw full-output dumping completely untouched when running highly verbose (-vv). Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 32e6312f7e39 ("perf test: Truncate test description to fit terminal width") Signed-off-by: Sasha Levin commit a3d0aad7e44a1528cf80f98c13ddefc70442b750 Author: Ian Rogers Date: Tue Jun 2 10:41:19 2026 -0700 perf test: Refactor parallel poll loop to drain all pipes simultaneously [ Upstream commit f35450738e789b80b540f41487b9053defd0bb8d ] When running tests in parallel with verbose output (-v), child processes write to pipes. If a test produces significant output (e.g. Granite Rapids metric parsing printing hundreds of lines), it fills the 64KB pipe buffer and blocks. Previously, the parent harness (finish_test) only polled the pipe of the current test waiting to be printed. Other children blocked indefinitely until the parent reached them, severely sequentializing execution. Address this by implementing finish_tests_parallel() to poll and drain output pipes from all running children simultaneously into per-child buffers, employing safe strbuf_addstr string operations alongside thorough variable orderings for strict ISO C90 compliance. Reaping occurs out of order as children finish, while final result printing remains strictly in order. This drops parallel verbose execution time for the PMU events suite from ~35 seconds down to ~5.9 seconds. Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 32e6312f7e39 ("perf test: Truncate test description to fit terminal width") Signed-off-by: Sasha Levin commit 1acc1bedf4e69689ffcd680a827ee258b1f268a8 Author: Ian Rogers Date: Tue Jun 2 10:41:15 2026 -0700 perf test: Drain pipe after child finishes to avoid losing output [ Upstream commit 744af598719776b2ca8b0f5388b51d2493cc94b7 ] When running tests in parallel, the parent process reads output from the child's pipe. However, it might exit the loop as soon as the child is detected as finished, potentially missing data that arrived in the pipe just after the last poll or before the loop terminated. Address this by draining the pipe after the main loop in finish_test. Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 32e6312f7e39 ("perf test: Truncate test description to fit terminal width") Signed-off-by: Sasha Levin commit a2590ff90dca6f2aa1e880334df1c7b47b8e4628 Author: Aaradhana Sahu Date: Tue Jun 16 11:53:42 2026 +0530 wifi: ath12k: correct monitor destination ring size [ Upstream commit 913998f903fb1432c0046c33003db38a9e8bedb1 ] The default memory profile configures rxdma_monitor_dst_ring_size as 8092, which is a typo. The intended value is 8192, consistent with all other ring sizes in the table being powers of two. Correct the monitor destination ring size to 8192. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Fixes: defae535dd63 ("wifi: ath12k: Add a table of parameters entries impacting memory consumption") Signed-off-by: Aaradhana Sahu Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260616062342.4079796-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5d80268945dfeb662167646414364fb7466c1dc5 Author: Sean Young Date: Wed Jun 24 11:05:47 2026 +0100 media: keymaps: Remove obsolete RC_MAP_HAUPPAUGE_NEW keymap define [ Upstream commit 6e5deb2923b0d1b73c77a1a77c30b0da43d9e022 ] Since commit af86ce79f020 ("[media] remove the old RC_MAP_HAUPPAUGE_NEW RC map"), the RC_MAP_HAUPPAUGE_NEW define is no longer used. Fixes: af86ce79f020 ("[media] remove the old RC_MAP_HAUPPAUGE_NEW RC map") Signed-off-by: Sean Young Acked-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6ee86a39a2ff6b2053205463e3a272c61474dc80 Author: Sean Young Date: Wed Jun 24 10:55:51 2026 +0100 media: keymaps: Remove obsolete RC_MAP_RC5_TV keymap define [ Upstream commit 5370facb7b4461166a4610d456fefeb92ef50a82 ] Since commit 206241069ecf ("[media] rc/keymaps: Remove the obsolete rc-rc5-tv keymap"), the rc-rc5-tv keymap is no longer in the tree. Fixes: 206241069ecf ("[media] rc/keymaps: Remove the obsolete rc-rc5-tv keymap") Signed-off-by: Sean Young Acked-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 9be10543297f010a7018a333d6b63ebeeac3ac01 Author: Jinjie Ruan Date: Mon Jun 29 17:47:37 2026 +0800 riscv: kexec_file: Fix crashk_low_res not exclude bug [ Upstream commit 5fc6e7d45373571d03cd04fd4c6069c0a97fa75a ] As done in commit 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X") and commit 4831be702b95 ("arm64/kexec: Fix missing extra range for crashkres_low.") for arm64, while implementing crashkernel=X,[high,low], riscv should have excluded the "crashk_low_res" reserved ranges from the crash kernel memory to prevent them from being exported through /proc/vmcore, and the exclusion would need an extra crash_mem range. Just simply tested on qemu with crashkernel=4G with kexec in [1] mentioned in [2]. And the second kernel can be started normally. # dmesg | grep crash [ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (128 MB) [ 0.000000] crashkernel reserved: 0x000000017fe00000 - 0x000000027fe00000 (4096 MB) [1]: https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2 [2]: https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/ Cc: Guo Ren Cc: Baoquan He Fixes: 5882e5acf18d ("riscv: kdump: Implement crashkernel=X,[high,low]") Reviewed-by: Guo Ren Signed-off-by: Jinjie Ruan Link: https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2 Link: https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/ Link: https://patch.msgid.link/20260629094746.191843-2-ruanjinjie@huawei.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 68ea6dd23b732081826c36033835468383487864 Author: Daniel McCarthy Date: Thu Jun 18 01:04:51 2026 +0300 pinctrl: bcm2835: Don't remove an unregistered GPIO chip [ Upstream commit 32711f77db0641e57fd96fdc013bf1286b9f2514 ] If the devm_pinctrl_register() function fails, bcm2835_pinctrl_probe() calls gpiochip_remove() before gpiochip_add_data() has registered the GPIO chip. This means that upon failure the gpio_chip.gpiodev is NULL resulting in a null pointer dereference inside the gpiochip_remove() function. Remove the unnecessary function call to gpiochip_remove(). No GPIO cleanup is required because the GPIO chip has not yet been registered. Without this change there is potential for a kernel panic upon registration failure Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs") Signed-off-by: Daniel McCarthy Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d623e292c6a4c5f37b0ca8e7dc3098c0c0c5eb80 Author: Zide Chen Date: Thu Jun 11 09:00:29 2026 -0700 perf/x86/intel/uncore: Keep PCI PMUs working when MMIO/MSR setup fails [ Upstream commit 3012af7df3430788eddd30b3c6654d0a0a5f06c6 ] uncore_event_cpu_online() returns -ENOMEM early when both the MSR and MMIO box allocations fail. This also aborts PCI uncore setup, even though PCI PMUs are independent of the MSR/MMIO paths. Remove the early return so PCI uncore setup always runs regardless of whether MSR or MMIO box allocation succeeds. Fixes: 3da04b8a00dd ("perf/x86/intel/uncore: Support MMIO type uncore blocks") Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ian Rogers Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260611160033.66760-5-zide.chen@intel.com Signed-off-by: Sasha Levin commit 18fdd0978ec3dda0ff6865cd273e47e022180710 Author: Chen, Yu C Date: Sat Jun 20 11:54:22 2026 +0800 sched/fair: Fix overflow in update_tg_cfs_runnable() [ Upstream commit 4f166adb5cb0525d9e32d45729fd8f28c80acbee ] A divide-by-zero crash is observed when running hackbench: [14697.488452] CPU: 112 UID: 0 PID: 124791 Comm: hackbench Not tainted 7.1.0-rc2+ [14697.492627] RIP: 0010:propagate_entity_load_avg+0x35f/0x3e0 [14697.506799] [14697.507411] __dequeue_task+0x2b4/0xc70 [14697.508677] dequeue_task_fair+0x36/0x370 [14697.509047] dequeue_task+0x101/0x2f0 [14697.509426] __schedule+0x1b1/0x1a00 [14697.510868] anon_pipe_read+0x3da/0x450 [14697.511400] vfs_read+0x361/0x390 [14697.512053] __x64_sys_read+0x19/0x30 The divide-by-zero happens here: if (scale_load_down(gcfs_rq->load.weight)) { load_sum = div_u64(gcfs_rq->avg.load_sum, scale_load_down(gcfs_rq->load.weight)); } gcfs_rq->load.weight is an insane large value and is truncated to the lower 32 bits by div_u64, which happen to be 0. Using AI for investigation, the cause is a u32 overflow in update_tg_cfs_runnable(), and flat pickup became a victim when using tg_tasks(): u32 new_sum, divider; ... new_sum = se->avg.runnable_avg * divider; <-- boom The following sequence shows how this triggers the crash: propagate_entity_load_avg() update_tg_cfs_runnable() # u32 overflow corrupts runnable_sum __update_load_avg_cfs_rq() ___update_load_avg() # computes insane runnable_avg update_tg_load_avg() # propagates to tg->runnable_avg update_cfs_group() calc_concur_shares() tg_tasks() # long-to-int truncation, negative nr reweight_entity() # corrupted se->load.weight update_load_add() # corrupted cfs_rq->load.weight propagate_entity_load_avg() update_tg_cfs_load() div_u64() # divide-by-zero Fix by widening new_sum from u32 to u64 (no need to force tg_tasks() to return unsigned long after this fix) Fixes: 95246d1ec80b ("sched/pelt: Relax the sync of runnable_sum with runnable_avg") Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Chen Yu Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/a22eea2b-4c4a-4623-9a44-d7b18c0c91c8@intel.com Signed-off-by: Sasha Levin commit 912e7263488e1f05538f16b52894ef2ac2b1b515 Author: Wei Yang Date: Mon Jun 22 02:24:03 2026 +0000 mm/mm_init: fix incorrect node_spanned_pages [ Upstream commit 7783dcd79ae9c4aa48bc47bd4275772445dc4b2a ] Current node_spanned_pages is got as a summation of all zone's spanned page in calculate_node_totalpages(). Generally this is good, but if we use kernelcore=mirror, it is would be wrong. Without kernelcore=mirror: The test machine has below memory layout: memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0 memory[0x1] [0x0000000000100000-0x00000000bffdefff], 0x00000000bfedf000 bytes on node 0 flags: 0x0 memory[0x2] [0x0000000100000000-0x00000001bfffffff], 0x00000000c0000000 bytes on node 0 flags: 0x0 And the Zone range is: DMA [mem 0x0000000000001000-0x0000000000ffffff] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] Normal [mem 0x0000000100000000-0x00000001bfffffff] Then we see, with spanned_pages printed: On node 0 spanned_pages: 1835007 totalpages: 1572733 With kernelcore=mirror: The test machine has below memory layout: memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x2 memory[0x1] [0x0000000000100000-0x00000000bffdefff], 0x00000000bfedf000 bytes on node 0 flags: 0x2 memory[0x2] [0x0000000100000000-0x000000013fffffff], 0x0000000040000000 bytes on node 0 flags: 0x2 memory[0x3] [0x0000000140000000-0x00000001bfffffff], 0x0000000080000000 bytes on node 0 flags: 0x0 And the Zone range is: DMA [mem 0x0000000000001000-0x0000000000ffffff] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] Normal [mem 0x0000000100000000-0x00000001bfffffff] Device empty Movable zone start for each node Node 0: 0x0000000140000000 Then we see, with spanned_pages printed: On node 0 spanned_pages: 2359295 totalpages: 1572733 The total range of memory on node 0 doesn't change, but the spanned_pages becomes much larger. The reason is when kernelcore=mirror is specified, the range of Zone Normal and Zone Movable would overlap. So the overlapped range would be calculated twice. A wrong node_spanned_pages would effect defer_init(), since each zone_end_pfn is less than pgdat_end_pfn(). As we already passed in node_start_pfn and node_end_pfn, fix this by get it from (node_start_pfn - node_end_pfn) directly. Fixes: 342332e6a925 ("mm/page_alloc.c: introduce kernelcore=mirror option") Signed-off-by: Wei Yang Cc: Yuan Liu Link: https://patch.msgid.link/20260622022403.16375-1-richard.weiyang@gmail.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit e2a7cee341986cb5b544a8286edc7fb0494c592e Author: Henrik Grimler Date: Mon Jun 1 14:03:59 2026 +0200 drm/lima: call drm_mm_init() with a valid allocation range [ Upstream commit 3b3bce4a692ac60d9f4a341e6b597dd1fd0a28f9 ] lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2: [ 1.736297] ------------[ cut here ]------------ [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931! [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.750697] Modules linked in: [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree) [ 1.769446] Workqueue: events_unbound deferred_probe_work_func [ 1.775261] PC is at drm_mm_init+0x9c/0xa4 [ 1.779339] LR is at lima_vm_create+0x144/0x17c [ ... ] Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up. Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by: Henrik Grimler Signed-off-by: Qiang Yu Link: https://patch.msgid.link/20260601-lima-alloc-fix-v1-1-16d3f3b7b780@axis.com Signed-off-by: Sasha Levin commit d46160ed28478adf0a6a24a544c5e55957335e72 Author: Brian Masney Date: Tue May 5 20:48:57 2026 -0400 clk: imx: scu: drop redundant init.ops variable assignment [ Upstream commit 5f2db1ce201216e81333ecc2ab51494410b2fe0d ] The init.ops is assigned a default value, however right below it is an if, else if, and else where all of them also assign a value to init.ops. Drop the redundant init.ops assignment at the top. Fixes: 3b9ea606cda53 ("clk: imx: scu: add cpu frequency scaling support") Reviewed-by: Peng Fan Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 79927acbd45949b3d4ac653d33a50cf84e9ee8cf Author: Frieder Schrempf Date: Tue Jun 16 12:43:09 2026 +0200 arm64: dts: imx93-kontron: set memory node to 0x80000000/1GiB [ Upstream commit 9c269fe7eae8cb60d8d6c326dd8955818722fae9 ] The start address of the DRAM area is 0x80000000. The minimal size of the DDR on the SoM is 1 GiB. Fixes: 2b52fd6035b7 ("arm64: dts: Add support for Kontron i.MX93 OSM-S SoM and BL carrier board") Signed-off-by: Frieder Schrempf Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 6b82e11ed18333a62bed175d0c978cd11c2e1aeb Author: Weigang He Date: Wed Jun 10 15:06:25 2026 +1000 ARM: imx: fix device_node refcount leaks in imx7_src_init() [ Upstream commit 3de939b2ac843d56d88e2ab1e1b1f667cba9e1d4 ] imx7_src_init() obtains two device_node references via of_find_compatible_node() - one for "fsl,imx7d-src" and one for "fsl,imx7d-gpc" - reusing the same np variable, but never calls of_node_put() on either. On every i.MX7D boot up to two device_node refcounts are leaked: - The "fsl,imx7d-src" node is leaked both when of_iomap() fails (the early return after the mapping) and when it succeeds, because np is then overwritten by the second of_find_compatible_node() call without releasing the prior reference. - The "fsl,imx7d-gpc" node is leaked on every path leaving the function after it is acquired. Release each reference immediately after of_iomap() consumes the node. of_iomap() maps the node's registers but does not retain a reference to the device_node, so it is safe to put the node once mapped; this also drops the first reference before np is reused for the second lookup. Found by static analysis tool CodeQL. Fixes: e34645f45805 ("ARM: imx: add smp support for imx7d") Signed-off-by: Weigang He Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit cfec229dbe9abf4417a80922d0554533b45341c1 Author: Weigang He Date: Wed Jun 10 15:06:24 2026 +1000 ARM: imx: fix device_node refcount leak in imx_src_init() [ Upstream commit 936407c3563ac745cbbb9953c0cf2472128a22f4 ] imx_src_init() obtains a device_node reference via of_find_compatible_node() matching "fsl,imx51-src" and uses it only to call of_iomap(). It never releases that reference: on the success path the function returns at the end without of_node_put(np), leaking one device_node refcount on every boot of an i.MX5/6 platform. Release the reference right after of_iomap(). of_iomap() maps the node's registers but does not retain a reference to the device_node, so the node can be put once the mapping is done. The early return on a NULL np needs no put. Found by static analysis tool CodeQL. Fixes: bd3d924d71a4 ("ARM i.MX5: Add System Reset Controller (SRC) support for i.MX51 and i.MX53") Signed-off-by: Weigang He Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 9326fd5972eaa99f68447fc21ea6a0d17476fc2b Author: Min zhang Date: Tue May 12 08:06:42 2026 +0800 clk: hisilicon: reset: Use devm_kzalloc to initialize hisi_reset_controller [ Upstream commit a8036f4591542de4b38ec81d3e2ba47bc0b2652b ] Using devm_kmalloc() does not zero-initialize the allocated structure. Uninitialized members in struct hisi_reset_controller may contain garbage data, which can cause reset_controller_register() to fail unexpectedly. Replace devm_kmalloc() with devm_kzalloc() to ensure all structure fields are properly zero-initialized. Fixes: 97b7129cd2afb ("reset: hisilicon: change the definition of hisi_reset_init") Reviewed-by: Brian Masney Signed-off-by: Min zhang Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit e921cc73fae68ccee932ad0a4fb11d637557db0e Author: Shengjiu Wang Date: Thu Jun 18 10:38:18 2026 +0800 ASoC: fsl_audmix: rework runtime PM handling in probe [ Upstream commit 3359ba93d01a23b2e4249e9e44ccfe48eb9c5d71 ] After pm_runtime_enable() the AUDMIX block is powered off and stays suspended until the first runtime resume. Register writes issued between probe() and the first resume (e.g. from DAPM or ALSA control paths) target unpowered hardware and cause a system hang. Fix this by calling pm_runtime_resume_and_get() immediately after pm_runtime_enable() to power the hardware up and enable its clocks. Release the reference afterwards with pm_runtime_put() to allow the runtime PM framework to suspend the device and switch the regmap to cache-only mode when idle. When CONFIG_PM is disabled or runtime PM is not enabled, pm_runtime_* calls are stubs that do not power up the hardware. Handle this case explicitly by calling fsl_audmix_runtime_resume() directly so the hardware is always initialised and its clocks are enabled, ensuring register accesses succeed regardless of PM configuration. Fixes: be1df61cf06ef ("ASoC: fsl: Add Audio Mixer CPU DAI driver") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260618023818.31618-1-shengjiu.wang@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1e8fddab6cbe536dd02e61205e4b9bf97df6479b Author: Runyu Xiao Date: Fri Jun 19 20:23:25 2026 +0800 ASoC: rt700-sdw: always drain jack work on remove [ Upstream commit 612ccf42acd14bb2685fa60c3495ca13e63e8989 ] rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems. Fixes: 737ee8bdf682 ("ASoC: rt700-sdw: use cancel_work_sync() in .remove as well as .suspend") Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260619122325.2504287-1-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 61cae8df142192da7d941d57454ae6aa64758f60 Author: Rosen Penev Date: Tue May 19 15:26:39 2026 -0700 clk: stm32: add missing bitfield.h header [ Upstream commit 0bf68e8dcb843f094ed73c2c54e9fe58a7a4f774 ] It seems some ARM header includes this and the build passes there, but nowhere else. Note that the driver has COMPILE_TEST in depends. Fixes: 37ae8501cdb0 ("clk: stm32: introduce clocks for STM32MP21 platfor") Signed-off-by: Rosen Penev Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit c77bf8b2ca740b03fbee32cf458575bf17c607cb Author: Joey Lu Date: Thu May 21 09:42:20 2026 +0800 clk: nuvoton: ma35d1: fix ma35d1_clk_pll_determine_rate logic [ Upstream commit e1311954cb600d5f95cd9e2fe9a7376edc2ac3c5 ] ma35d1_clk_pll_determine_rate() called ma35d1_pll_find_closest() unconditionally before the switch statement, and then every case branch overwrote pll_freq by reading the current hardware registers. For CAPLL and DDRPLL this means find_closest() ran unnecessarily (and incorrectly, since those PLLs are read-only) and its result was silently discarded. Fix by moving the find_closest() call inside the APLL/EPLL/VPLL branch where it belongs. Group CAPLL and DDRPLL together as read-only PLLs that simply report their current rate; handle them with an explicit if/else to keep the CAPLL (SMIC design) and DDRPLL (standard design) paths distinct. Fixes: 691521a367cf ("clk: nuvoton: Add clock driver for ma35d1 clock controller") Signed-off-by: Joey Lu Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 4c7503f14f25b6f3b495796e7d79b95a04438a4b Author: Joey Lu Date: Thu May 21 09:42:19 2026 +0800 clk: nuvoton: ma35d1: fix PLL_CTL1_FRAC bit field width and fractional calc [ Upstream commit 26de5aed72d80bd8aec2583134aca3597c64fda9 ] PLL_CTL1_FRAC was defined as GENMASK(31, 24), covering only 8 bits. The hardware fractional field occupies bits [31:8] (24 bits), so the mask must be GENMASK(31, 8). The previous fractional-mode calculation used FIELD_MAX(PLL_CTL1_FRAC) as the denominator to obtain 2 decimal places. With the corrected 24-bit mask the old divisor is wrong; replace the arithmetic with a proper 24-bit fixed-point rounding to 3 decimal places using the kernel's DIV_ROUND_CLOSEST_ULL helper: n_frac = n * 1000 + DIV_ROUND_CLOSEST_ULL(x * 1000, 1 << 24) Fixes: 691521a367cf ("clk: nuvoton: Add clock driver for ma35d1 clock controller") Signed-off-by: Joey Lu Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit e165e15e1a9c855f3d657cb562ed45f5896acc1c Author: Joey Lu Date: Thu May 21 09:42:18 2026 +0800 clk: nuvoton: ma35d1: fix ignored div_u64 return values in PLL freq calculation [ Upstream commit b3a2223a7805c7e6759a32a5d6ca574ad07e2710 ] div_u64() does not modify its argument in place; the return value must be assigned. Both ma35d1_calc_smic_pll_freq() and ma35d1_calc_pll_freq() called div_u64() and discarded the result, leaving pll_freq holding the undivided product and thus returning a frequency orders of magnitude too high. Fixes: 691521a367cf ("clk: nuvoton: Add clock driver for ma35d1 clock controller") Reviewed-by: Brian Masney Signed-off-by: Joey Lu Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 5e273be0a987a9fd23a9503a790d784496f80d68 Author: Alexander A. Klimov Date: Tue May 26 22:42:26 2026 +0200 clk: moxart: remove unused variables, fix refcount leak [ Upstream commit 9f275f2ee9ca60ea4c092bdc0195987945ad8ad8 ] Not only these error checks are redundand, those of_clk_get() return values weren't cleaned up via clk_put(). Fixes: c7bb4fc16ead ("clk: add MOXA ART SoCs clock driver") Signed-off-by: Alexander A. Klimov Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit fe3e4196a57a9d90d3114a5334fd58b631de1ce3 Author: Myeonghun Pak Date: Tue Jun 23 18:40:18 2026 +0900 clk: versaclock7: Fix APLL clock leak on probe failure [ Upstream commit e25d8d35e8cbc1a4c04a8b86eed6aa7229f6449e ] vc7_probe() registers the APLL with clk_register_fixed_rate(), which is not devm-managed and must be explicitly unregistered on probe failure. Most later errors already unwind through err_clk, but a failure from vc7_get_bank_clk() in the output registration loop returned directly. That skipped clk_unregister_fixed_rate() and leaked the APLL clock. Route that error through the existing err_clk label so the fixed-rate clock is released consistently with the other probe failure paths. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 48c5e98fedd9 ("clk: Renesas versaclock7 ccf device driver") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 4ffaaef885fcc266075a570cea06b8f457a9f0a1 Author: Wei Hou Date: Sun Jun 28 23:58:57 2026 +0800 cxl/pci: Remove incorrect mbox.valid check in cxl_pci_type3_init_mailbox() [ Upstream commit d79b81893d0cc93737e811a465b9ef9a00156fd5 ] The driver's design intent is that missing or malformed component registers should not prevent mailbox initialization. cxl_pci_probe() already reflects this: the CXL_REGLOC_RBI_COMPONENT setup path only emits a dev_warn() and continues when component registers are absent, rather than returning an error. The check 'if (!cxlds->reg_map.device_map.mbox.valid)' violates this intent and is also technically incorrect for two reasons: 1. Wrong struct: the MEMDEV register block is enumerated into a local variable 'map', not into 'cxlds->reg_map'. The device_map.mbox.valid field inside cxlds->reg_map is never written by the MEMDEV probe and will always read as zero regardless of actual hardware capability. 2. Already validated: cxl_pci_setup_regs(CXL_REGLOC_RBI_MEMDEV) calls cxl_probe_regs() which explicitly checks mbox.valid and returns -ENXIO if the mailbox is absent. If that check passes, the mailbox is guaranteed to be present by the time cxl_pci_type3_init_mailbox() is called. The value that the check actually reads is component_map.ras.valid, which aliases device_map.mbox.valid in the union. This is populated by the COMPONENT probe, not the MEMDEV probe. On devices where the component register BAR does not implement a CXL Component Capability Array (e.g. certain DCD devices), cxl_probe_component_regs() returns early leaving ras.valid=false. Through the union, this makes mbox.valid read as false, causing cxl_pci_type3_init_mailbox() to return -ENODEV (-19) even though the mailbox hardware is fully functional. Remove the check. Mailbox presence has already been validated by cxl_pci_setup_regs(CXL_REGLOC_RBI_MEMDEV). The presence or absence of component registers is irrelevant to mailbox initialization. Fixes: 8d8081cecfb9 ("cxl: Move mailbox related bits to the same context") Reviewed-by: Richard Cheng Signed-off-by: Wei Hou Reviewed-by: Li Ming Link: https://patch.msgid.link/20260628155857.239866-1-wei.hou@scaleflux.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 31d4841eca7c4b75751ca96d24339e19303337f2 Author: Richard Cheng Date: Wed Jun 24 22:41:47 2026 +0800 cxl/mbox: Clamp mailbox output allocation to the payload size [ Upstream commit 8a13db9f899d149c3aab24abcb668121cfda5a4f ] CXL_MEM_SEND_COMMAND bounds the user's in.size to the mailbox payload size but leaves out.size unbounded, then cxl_mbox_cmd_ctor() calls kvzalloc(out.size). A large out.size drives a huge allocation, above INT_MAX it WARNs and taints, and with panic_on_warn=1 it panics. The transport __cxl_pci_mbox_send_cmd() already clamps the response copy to min(out.size, payload_size, device len), so the output buffer is never written beyond payload_size. Clamp the allocation to payload_size too, matching the RAW path. Fixes: 583fa5e71cae ("cxl/mem: Add basic IOCTL interface") Reviewed-by: Kai-Heng Feng Reviewed-by: Koba Ko Reviewed-by: Dave Jiang Reviewed-by: Davidlohr Bueso Signed-off-by: Richard Cheng Link: https://patch.msgid.link/20260624144147.53997-1-icheng@nvidia.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 5b616612511ebeeceb94d6e0b9dadb2291c53092 Author: Gui-Dong Han Date: Fri Jun 26 16:08:06 2026 +0800 media: cec-pin: Fix event FIFO ordering [ Upstream commit a1d83d1b810665bd53ce8a7b7867e054d68676c7 ] cec_pin_update() fills work_pin_events[] and work_pin_ts[], then increments work_pin_num_events. cec_pin_thread_func() uses that counter to decide when to read the FIFO entries. Do not let the counter update be observed without the event update. Also do not let a freed slot be reused before the thread has finished reading it. Use release operations when publishing an entry and releasing a slot, and acquire operations when consuming those counter updates. Leave the other work_pin_num_events users as they do not participate in this FIFO publication path. Fixes: ea5c8ef29668 ("media: cec-pin: add low-level pin hardware support") Signed-off-by: Gui-Dong Han Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f1fac4561cda137934075a50a7ea1d750b0c2447 Author: Weigang He Date: Wed Jun 10 00:38:52 2026 +1000 soc: samsung: exynos-pmu: fix of_node refcount leak in exynos_get_pmu_regmap() [ Upstream commit fa476d53edd24e8105faace04e881b9c4179738f ] exynos_get_pmu_regmap() obtains a device_node via of_find_matching_node() and passes it to exynos_get_pmu_regmap_by_phandle(np, NULL). With propname == NULL the callee uses np directly and does not drop a reference, so the reference taken by of_find_matching_node() is leaked on every call -- including on each -EPROBE_DEFER retry of the only in-tree caller, exynos_retention_init() in the Exynos pinctrl driver. Annotate np with the __free(device_node) cleanup attribute so the reference is released when the function returns. Found by static analysis tool CodeQL. Fixes: 76640b84bd7a ("soc: samsung: pmu: Provide global function to get PMU regmap") Signed-off-by: Weigang He Link: https://patch.msgid.link/20260609143852.1783558-1-geoffreyhe2@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 635914c60da26a9892f27ffb5edcc922a10effab Author: Michael Bommarito Date: Wed Jun 17 23:00:35 2026 -0400 HID: roccat: bound device-supplied profile index [ Upstream commit 43fae42628a8c10fa8981773d7ec9f1a367821a7 ] kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds). Fixes: 14bf62cde7942 ("HID: add driver for Roccat Kone gaming mouse") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit dc32c7423b3464c918a4f532c3eb16b06aca722d Author: Christos Maragkos Date: Wed Jun 3 18:21:34 2026 +0300 HID: nintendo: Fix imu_timestamp_us double increment per report [ Upstream commit 1f9b25d3fb65b9384dec16d9db13a3e71abd9145 ] Previously, the imu_timestamp_us variable was incremented twice per report, causing it to advance by two times the desired amount. This resulted in incorrect jumps in IMU timestamps reported using MSC_TIMESTAMP, so userspace applications saw corrupted timing on functions such as gyroscope-based aim and motion controls. This is fixed by removing the redundant increment at the start of the report handling so the remaining can account for the full report interval. Fixes: 4ff5b10840a88 ("HID: nintendo: add IMU support") Signed-off-by: Christos Maragkos Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 544ebb25bd58f67e821573412ab7a982b9e02211 Author: Philipp Weber Date: Tue May 19 15:00:14 2026 +0200 HID: core: quiesce input in hid_hw_stop() to prevent use-after-free [ Upstream commit a4bc41504690b7d7064931909874f5b98cd148b6 ] A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path ("hwmon: prevent packets from going to driver for probe", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit. Reported-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9eebf5f6544c5e873858 Signed-off-by: Philipp Weber Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 97093398e75a7a0e622e6233a5d35ae8bf4005c2 Author: Amin Vakil Date: Thu Jun 18 18:44:44 2026 +0330 selftests: proc: include fcntl.h in proc-pidns [ Upstream commit 879b3353d04d043a9e01525c520d9b81339421b2 ] proc-pidns.c uses open() and O_* flags, but does not include . This breaks the proc selftests build with errors such as: error: implicit declaration of function 'open' error: 'O_WRONLY' undeclared error: 'O_CREAT' undeclared error: 'O_RDONLY' undeclared Include to provide the declaration and flag definitions. Fixes: 5554d820f71c ("selftests/proc: add tests for new pidns APIs") Tested with: make -C tools/testing/selftests TARGETS=proc Signed-off-by: Amin Vakil Link: https://patch.msgid.link/20260618151444.124739-1-info@aminvakil.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit e4728288473a5024a8bdba7d43f346719606fea0 Author: Maoyi Xie Date: Thu Jun 25 21:00:56 2026 +0800 platform/chrome: cros_ec_typec: Reject out-of-bounds PD cap count [ Upstream commit a0a8cd9fc9c48b95095bcec4b146f7a99486f58e ] cros_typec_register_partner_pdos() copies the partner PDOs from the EC TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array. memcpy(caps_desc.pdo, resp->source_cap_pdos, sizeof(u32) * resp->source_cap_count); ... memcpy(caps_desc.pdo, resp->sink_cap_pdos, sizeof(u32) * resp->sink_cap_count); PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields from the EC. The only check is that they are not both zero. If either is larger than 7, the memcpy writes past the end of the array on the stack. A count of 255 overflows it by about 1 KB. The EC source arrays are only seven entries wide. A larger count reads past them too. The ChromeOS EC firmware caps these counts today, so a compliant setup does not hit this. The kernel should still validate these values rather than trust them. Validate the counts in cros_typec_register_partner_pdos() next to the memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS. The rest of cros_typec_handle_status() still runs so events are handled and cleared. Fixes: 348a2e8c93d3 ("platform/chrome: cros_ec_typec: Register partner PDOs") Suggested-by: Andrei Kuchynski Co-developed-by: Kaixuan Li Signed-off-by: Kaixuan Li Signed-off-by: Maoyi Xie Reviewed-by: Benson Leung Reviewed-by: Andrei Kuchynski Link: https://lore.kernel.org/r/20260625130056.3378097-1-maoyixie.tju@gmail.com Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit f633cc23dbcc4f0593942749c151c0bf90d9e563 Author: Jens Remus Date: Thu Jun 11 17:57:15 2026 +0200 x86/cfi: Use symmetric SYM_START and SYM_END in __CFI_TYPE() [ Upstream commit 0cfdf974f133e0ff17ed80e7895adbe7889d9522 ] Commit ccace936eec7 ("x86: Add types to indirectly called assembly functions") introduced a x86-specific implementation of __CFI_TYPE() using an asymmetric combination of SYM_START() and SYM_FUNC_END() to add a symbol to the KCFI type identifier that precedes a function. This asymmetric combination is an issue if SYM_FUNC_END() ever gets extended in a way that requires it to be used symmetrically with SYM_FUNC_START*(). For instance to emit DWARF CFI directives that denote the start/end of a function. [1] Use SYM_END() with SYM_T_FUNC instead. No functional change, as the generic implementation of SYM_FUNC_END(name) expands into SYM_END(name, SYM_T_FUNC). Fixes: ccace936eec7 ("x86: Add types to indirectly called assembly functions") Closes: https://sashiko.dev/#/patchset/20260522110427.2816637-1-jremus@linux.ibm.com?part=3 [1] Reported-by: Sashiko Signed-off-by: Jens Remus Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Nathan Chancellor Acked-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260611155716.830563-1-jremus@linux.ibm.com Signed-off-by: Sasha Levin commit 71ddadef3b912d1c752825cc0a8688afc5694334 Author: Wanwu Li Date: Mon Jun 8 15:24:57 2026 +0800 sched_ext/scx_flatcg: Fix cvtime_delta race and add hweight scaling to bypass charging [ Upstream commit a5cc43414b38decd50bdd447e558358a6fbd5864 ] 1. cgrp_cap_budget() used __sync_fetch_and_sub(&cgc->cvtime_delta, cgc->cvtime_delta) to atomically read and clear cvtime_delta. However, this is not a true atomic read-clear operation: the second argument (cgc->cvtime_delta) is evaluated as a normal read before the atomic fetch_and_sub executes. If a concurrent __sync_fetch_and_add() happens between the read and the sub, the added value gets included in the returned delta AND remains in cvtime_delta, causing double charging. Example: CPU 0 runs cgrp_cap_budget(), CPU 1 runs fcg_stopping(). Assume cvtime_delta = 100 initially. T1 CPU 0: sub_val = cvtime_delta = 100 cvtime_delta = 100 T2 CPU 1: __sync_fetch_and_add(&cvtime_delta, 10) cvtime_delta = 110 T3 CPU 0: __sync_fetch_and_sub(&cvtime_delta, sub_val) cvtime_delta = 10 returns old=110 delta = 110 (includes the 10 from CPU 1), but cvtime_delta = 10 (the 10 also remains). The 10 is charged twice: once in delta (applied to cgv_node->cvtime) and once in the residual cvtime_delta (fetched again next time). Fix by using __sync_fetch_and_and(&cgc->cvtime_delta, 0). Disassembly comparison: (1) delta = __sync_fetch_and_sub(&cgc->cvtime_delta, cgc->cvtime_delta); 228: (79) r7 = *(u64 *)(r9 +40) 229: (87) r7 = -r7 230: (db) r7 = atomic64_fetch_add((u64 *)(r9 +40), r7) //r9 may be changed (2) delta = __sync_fetch_and_and(&cgc->cvtime_delta, 0); 228: (b7) r8 = 0 229: (db) r8 = atomic64_xchg((u64 *)(r9 +40), r8) 2. The bypass charging path in fcg_stopping() charges raw execution time to cvtime_delta without scaling by the inverse of the cgroup hweight. Since cvtime_delta is eventually applied to cgv_node->cvtime which is in vtime space (weight-scaled), the bypass path should also scale by FCG_HWEIGHT_ONE / hweight to match the units used by the dispatch path. Fixes: a4103eacc2ab ("sched_ext: Add a cgroup scheduler which uses flattened hierarchy") Signed-off-by: Wanwu Li Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 9c73cf53361f287a25566eb13f10f20c86e42127 Author: Konstantin Andreev Date: Mon May 25 01:37:49 2026 +0300 smack: restrict smackfs/{direct,mapped} values to 0-255 [ Upstream commit a7c44fd9f80e37763acf9cd3c87a58058d206427 ] Both smackfs/direct and smackfs/mapped incorrectly accept the full range of integer values. For example: # cd /sys/fs/smackfs/ # cat direct ; echo 250 # cat cipso2 @ 250/2 _ 250/2,4,5,6,7,8 * 250/3,5,7 ^ 250/2,4,5,6,7 ? 250/3,4,5,6,7,8 # echo -1234 >direct ; cat direct ; echo -1234 # cat cipso2 @ -1234/2 _ -1234/2,4,5,6,7,8 * -1234/3,5,7 ^ -1234/2,4,5,6,7 ? -1234/3,4,5,6,7,8 # I noticed two things regarding this: 1) sensitivity levels are truncated to 8 bits when labeling outgoing packets (0x2e = 46 for the -1234 example above) 2) the reverse process fails: incoming packets with sensitivity level 46 do not match these smackfs/cipso2 entries. Even observation (1) on its own warrants a fix. This patch restricts smackfs/direct and smackfs/mapped accepted values to the 0-255 range. Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 01d32783bbe01488bfaf2ed0f9ac1140c46a1fd7 Author: Konstantin Andreev Date: Mon May 25 01:37:48 2026 +0300 smack: deduplicate smackfs/{direct,mapped} file_operations [ Upstream commit 577dc3b6a8cf200e6e27b2d9967cac14a1fed2f3 ] The file_operations for smackfs/direct and smackfs/mapped are identical up to a textual replacement of "direct" with "mapped" This patch combines two instances of file_operations into one, handling both files. Fixes: f7112e6c9abf ("Smack: allow for significantly longer Smack labels v4") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 845525bfb547af5db205f68c143becddd4d49e9a Author: Dmitry Antipov Date: Fri Mar 20 14:31:57 2026 +0300 smack: simplify write handlers of sysfs entries [ Upstream commit b78fede1c69a090d377bf80417ce1f7f7f314534 ] Use the convenient 'kstrto{u,s}32_from_user()' to simplify write handlers of /smack/{doi,direct,mapped,logging,ptrace} sysfs entries. Signed-off-by: Dmitry Antipov Signed-off-by: Casey Schaufler Stable-dep-of: 577dc3b6a8cf ("smack: deduplicate smackfs/{direct,mapped} file_operations") Signed-off-by: Sasha Levin commit c2ab27c2e11591524b1378c24ad18882a425d1fa Author: Konstantin Andreev Date: Mon May 11 03:17:16 2026 +0300 smack: fix incorrect task context in smack_msg_queue_msgrcv [ Upstream commit fba3d32825f4bbc8e20f0cdc3b14df57965b8fe5 ] The smack_msg_queue_msgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task. In the msgsnd() syscall path, if a receiver is already waiting, the pipelined_send() optimization is used to push the message directly to the receiver task: ipc/msg.c`pipelined_send(): ` smp_store_release(&msr->r_msg, msg) In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->r_tsk, passed as the 'target' parameter): ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, target := msr->r_tsk,,) However, smack_msg_queue_msgrcv() ignores the 'target' and checks 'current': smack_msg_queue_msgrcv(…) ` smk_curacc_msq(isp, MAY_READWRITE); // current task 'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy. Test: 1) create a sysv message queue with label “foo” 2) echo "bar foo r" >/smack/load2 3) msgrcv(,,,0,MSG_NOERROR) in "bar"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a "foo"-labeled task: "bar"-labeled task gets the message. This patch fixes the issue by checking permission on the 'target' task instead of 'current'. (2008-02-04, Casey Schaufler) Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 04e674840f7e12d89733d0a43a483107c45b995f Author: Maxime Ripard Date: Fri Jun 19 14:24:07 2026 +0200 drm/bridge: cdns-mhdp8546: Return an error pointer on allocation failure [ Upstream commit 30ac1d403438a6c6039f0af5bb2df3d021f96036 ] The drm_bridge_funcs.atomic_reset documentation states that the hook must return either a valid drm_bridge_state object or an ERR_PTR(). The cdns_mhdp_bridge_atomic_reset() callback returns NULL when the allocation of its state fails, violating this contract. Return ERR_PTR(-ENOMEM) instead. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Reviewed-by: Thomas Zimmermann Reviewed-by: Luca Ceresoli Tested-by: Luca Ceresoli # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-2-ff399263111b@kernel.org Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 97b8580a112cc0562d314502bbb2ccead72537df Author: Maxime Ripard Date: Fri Jun 19 14:24:06 2026 +0200 drm/bridge: cdns-dsi: Return an error pointer on allocation failure [ Upstream commit 79ac5c68f1a49a9fdec596ee47577d5a1d52738f ] The drm_bridge_funcs.atomic_reset documentation states that the hook must return either a valid drm_bridge_state object or an ERR_PTR(). The cdns_dsi_bridge_atomic_reset() callback returns NULL when the allocation of its state fails, violating this contract. Return ERR_PTR(-ENOMEM) instead. Fixes: a53d987756ea ("drm/bridge: cdns-dsi: Move DSI mode check to _atomic_check()") Reviewed-by: Luca Ceresoli Reviewed-by: Thomas Zimmermann Tested-by: Luca Ceresoli # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-1-ff399263111b@kernel.org Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 4614b7cfaf8132227eb2c371b5a0728bb9ca19b2 Author: Nicolas Frattaroli Date: Tue Jun 9 14:44:00 2026 +0200 drm/rockchip: vop2: Recognise 10-bit YUV422 as YUV format [ Upstream commit c1bfe8dac0a79d47eed313b9bcaa2658898684ec ] The Rockchip VOP2 video output driver has a "is_yuv_output" function, which returns true when a given bus format is a YUV format, and false otherwise. This switch statement is lacking the bus format used for YUV422 10-bit. Add the two component orderings of the YUV422 10-bit bus formats to the switch statement. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Reviewed-by: Cristian Ciocaltea Reviewed-by: Daniel Stone Signed-off-by: Nicolas Frattaroli Link: https://patch.msgid.link/20260609-color-format-v17-13-35739b5782cc@collabora.com Signed-off-by: Daniel Stone Signed-off-by: Sasha Levin commit e4c3fb6999a49b01186fa8d7f9ffc6509bfb4378 Author: Nicolas Frattaroli Date: Tue Jun 9 14:43:59 2026 +0200 drm/rockchip: vop2: Add RK3576 to the RG swap special case [ Upstream commit ae4a4e69389d576941522c3c2e01a2254fd00d10 ] Much like RK3588, RK3576 requires an RG swap to be performed for YUV444 8-bit and YUV444 10-bit bus formats. Add its version to the already existing check for RK3588, so that YUV444 output is correct on this platform. Fixes: 944757a4cba6 ("drm/rockchip: vop2: Add support for rk3576") Reviewed-by: Andy Yan Reviewed-by: Daniel Stone Signed-off-by: Nicolas Frattaroli Link: https://patch.msgid.link/20260609-color-format-v17-12-35739b5782cc@collabora.com Signed-off-by: Daniel Stone Signed-off-by: Sasha Levin commit 3a8aa74859dd73eaa76c55eb74da708e56ef51c5 Author: Maíra Canal Date: Thu Jun 4 17:32:15 2026 -0300 drm/v3d: Clear queue->active_job when v3d_fence_create() fails [ Upstream commit 25a1669907512e927fab9ad4d4fb74ff57f63cd9 ] The run_job() callbacks for BIN, RENDER, TFU and CSD assign the incoming job to queue->active_job before calling v3d_fence_create(). If v3d_fence_create() fails, the callback returns NULL without clearing active_job, leaving a dangling pointer. Create a failure path in all run_job() callbacks that clears the active job before returning NULL. The BIN path takes queue->queue_lock around the clear as it races against v3d_overflow_mem_work(); RENDER, TFU and CSD paths have no concurrent reader, so the clear is lock-free. Fixes: a783a09ee76d ("drm/v3d: Refactor job management.") Reviewed-by: Tvrtko Ursulin Link: https://patch.msgid.link/20260604-v3d-sched-misc-fixes-v4-2-c068f5bf5ccf@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 7d65d9651f104c3ffa946d6fff78cde13956a45a Author: Dmitry Baryshkov Date: Thu May 28 10:10:50 2026 +0300 drm/bridge: display-connector: trigger initial HPD event for DP [ Upstream commit 60dc0946bbad3eef8bc66a5a8b09b98dbc6e09c0 ] If the DisplayPort drivers use display-connector for the HPD detection, the internal HPD state machine might be not active and thus the hardware might be not able to handle cable detection correctly. Instead it will depend on the external HPD notifications to set the cable state, bypassing the internal HPD state machine (for example this is the case for the msm DP driver). However if the cable has been plugged before the HPD IRQ has been enabled, there will be no HPD event coming. The drivers might fail detection in such a case. Trigger the HPD notification after enabling the HPD IRQ, propagating the cable insertion state. Note, this issue only affects drivers which set OP_HPD but not OP_DETECT (like dp-connector). Here DP differs from HDMI. For HDMI there is no additional state or extra "bridge with no sinks plugged" cases. The HPD pin state is equal to the display plugged state. Nor do we have an AUX bus with timeouts, etc. Fixes: 2e2bf3a5584d ("drm/bridge: display-connector: add DP support") Reported-by: Yongxing Mou Reviewed-by: Sebastian Reichel Link: https://patch.msgid.link/20260528-dp-connector-hpd-v3-3-d656eb1079b7@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 826426c26b24358b99e2f04d1cec8eac484c5349 Author: Dmitry Baryshkov Date: Thu May 28 10:10:49 2026 +0300 drm/bridge: display-connector: don't autoenable HPD IRQ [ Upstream commit 8e9c475060bff87077cfa3bd42011edcb7fb3b0d ] If HPD IRQ is enabled in the display_connector's probe, it can be triggered too early, before the DRM connector is completely setup. Use the enable_hpd / disable_hpd callbacks to control enablement of the HPD IRQ. Fixes: 0c275c30176b ("drm/bridge: Add bridge driver for display connectors") Reviewed-by: Sebastian Reichel Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260528-dp-connector-hpd-v3-2-d656eb1079b7@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 396a193867c6e8ee810287d6f79624144b5629e9 Author: Damon Ding Date: Mon Jun 1 14:50:55 2026 +0800 drm/rockchip: analogix_dp: Fix OF node reference leak via auto cleanup [ Upstream commit 87e060521371257ddbb77964b66e60d80afcc7b2 ] Sashiko reported a reference leak in rockchip_dp_drm_encoder_enable(), the of_get_child_by_name() function does not call of_node_put() in a symmetrical way [1]. Fix the device node reference leak by using __free(device_node) to automatically manage of_node_put() for all device nodes. Fixes: 729f8eefdcad ("drm/rockchip: analogix_dp: Add support for RK3588") Link: https://sashiko.dev/#/patchset/20260527024336.191433-1-damon.ding@rock-chips.com?part=5 #1 Signed-off-by: Damon Ding Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260601065100.1103873-7-damon.ding@rock-chips.com Signed-off-by: Sasha Levin commit 55fda5c2887a2b7810d78a2ab0d3187c3110a37c Author: Damon Ding Date: Mon Jun 1 14:50:54 2026 +0800 drm/rockchip: analogix_dp: Enable hclk for RK3588 [ Upstream commit 104f20616d72825fdcf56cfdc5f89f4e96fd8dbe ] Acquire and enable the HCLK_VO1 bus clock explicitly for RK3588 eDP controller to guarantee register and datapath access. The clock was previously enabled implicitly via rockchip,vo-grf phandle reference, which relies on side effect and is fragile. Fetch optional "hclk" clock in driver to align with updated device tree binding and keep consistent with hardware clock dependency. Fixes: 729f8eefdcad ("drm/rockchip: analogix_dp: Add support for RK3588") Signed-off-by: Damon Ding Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260601065100.1103873-6-damon.ding@rock-chips.com Signed-off-by: Sasha Levin commit b4eb01616c0da4ca3a520a48a257922552ca9bd8 Author: Cristian Ciocaltea Date: Mon May 4 21:24:00 2026 +0300 drm/rockchip: vop2: Wait for layer cfg done before switching LAYERSEL_REGDONE_SEL [ Upstream commit d1ad644e572c0647ad8428439eafea0aacfccf9e ] LAYERSEL_REGDONE_SEL mask of RK3568_OVL_CTRL register controls which Video Port (VP) vsync latches the shared RK3568_OVL_{LAYER|PORT}_SEL shadow registers into the active configuration. rk3568_vop2_setup_layer_mixer() overwrites LAYERSEL_REGDONE_SEL to the current VP ID before waiting for the previous VP layer configuration to take effect. As a consequence, the previous VP vsync can no longer trigger the latch, so the wait polls a value that might never appear. Move the layer cfg done wait before the RK3568_OVL_CTRL write so the previous VP vsync can still commit the pending configuration. Fixes: 3e89a8c68354 ("drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there are multi display output on rk3588/rk3568") Signed-off-by: Cristian Ciocaltea Reviewed-by: Andy Yan Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260504-vop2-layer-cfg-tmout-v1-2-730226a7331e@collabora.com Signed-off-by: Sasha Levin commit e97f4b4efc1abd945fb46a0cfc349426cba8cbc4 Author: Cristian Ciocaltea Date: Mon May 4 21:23:59 2026 +0300 drm/rockchip: vop2: Fix wrong wait target in layer cfg done check [ Upstream commit 9f5670802df085ad343146561e69bac43e9905d2 ] rk3568_vop2_setup_layer_mixer() waits for the previous Video Port (VP) layer configuration to take effect before writing a new one to the shared RK3568_OVL_LAYER_SEL shadow register. However, it passes vop2->old_layer_sel to rk3568_vop2_wait_for_layer_cfg_done() as the expected value, which at that point already contains the new VP layer. This causes the wait to poll for a value that has not been written to the shadow register yet, resulting in spurious timeouts when two non-blocking atomic commits race: rockchip-drm display-subsystem: [drm] *ERROR* wait layer cfg done timeout [...] Pass the local old_layer_sel instead, which still holds the value captured from vop2->old_layer_sel before it was overwritten, i.e. the previous VP target that the hardware is expected to latch. Fixes: 3e89a8c68354 ("drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there are multi display output on rk3588/rk3568") Signed-off-by: Cristian Ciocaltea Reviewed-by: Andy Yan Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260504-vop2-layer-cfg-tmout-v1-1-730226a7331e@collabora.com Signed-off-by: Sasha Levin commit 362e005b816ee8052a195b98d845966689b398a1 Author: Cristian Ciocaltea Date: Mon Jun 1 19:13:46 2026 +0300 drm/rockchip: dw_dp: Release core resources [ Upstream commit cc6d7aca2f37a1525a94ef97eb3ce361732c876c ] Core resources such as the DisplayPort AUX channel get initialized and registered during dw_dp_bind(), but are never unregistered, which may lead to memory leaks and/or use-after-free: [ 224.661371] BUG: KASAN: slab-use-after-free in device_is_dependent+0xe0/0x2b0 [ 224.662015] Read of size 8 at addr ffff00011aee8550 by task modprobe/658 [ 224.662612] [ 224.662752] CPU: 7 UID: 0 PID: 658 Comm: modprobe Not tainted 7.0.0-rc2-next-20260305 #14 PREEMPT [ 224.662759] Hardware name: Radxa ROCK 5B (DT) [ 224.662762] Call trace: [ 224.662764] show_stack+0x20/0x38 (C) [ 224.662772] dump_stack_lvl+0x6c/0x98 [ 224.662777] print_report+0x160/0x4b8 [ 224.662783] kasan_report+0xb4/0xe0 [ 224.662790] __asan_report_load8_noabort+0x20/0x30 [ 224.662796] device_is_dependent+0xe0/0x2b0 [ 224.662802] device_is_dependent+0x108/0x2b0 [ 224.662808] device_link_add+0x1f8/0x10b0 [ 224.662813] devm_of_phy_get_by_index+0x120/0x200 [ 224.662819] dw_dp_bind+0x34c/0xb10 [dw_dp] [ 224.662830] dw_dp_rockchip_bind+0x194/0x250 [rockchipdrm] [ 224.662864] component_bind_all+0x3a8/0x720 [ 224.662869] rockchip_drm_bind+0x120/0x390 [rockchipdrm] [ 224.662899] try_to_bring_up_aggregate_device+0x76c/0x838 [ 224.662904] component_master_add_with_match+0x1f4/0x230 [ 224.662909] rockchip_drm_platform_probe+0x420/0x538 [rockchipdrm] [ 224.662939] platform_probe+0xe8/0x168 [ 224.662945] really_probe+0x340/0x828 [ 224.662950] __driver_probe_device+0x2e0/0x350 [ 224.662954] driver_probe_device+0x80/0x140 [ 224.662959] __driver_attach+0x398/0x460 [ 224.662964] bus_for_each_dev+0xe0/0x198 [ 224.662968] driver_attach+0x50/0x68 [ 224.662972] bus_add_driver+0x2a0/0x4c0 [ 224.662977] driver_register+0x294/0x360 [ 224.662982] __platform_driver_register+0x7c/0x98 [ 224.662987] rockchip_drm_init+0xc4/0xff8 [rockchipdrm] Since a previous commit exported dw_dp_unbind() function in DW DP core library to take care of the necessary cleanup, use this in the component's unbind() callback, as well as in its bind() error path. Fixes: d68ba7bac955 ("drm/rockchip: Add RK3588 DPTX output support") Signed-off-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260601-drm-rk-fixes-v4-3-c3f3f123e1da@collabora.com Signed-off-by: Sasha Levin commit fe000d791c60881a8c26673fdcc6f3851a5cd7da Author: Cristian Ciocaltea Date: Mon Jun 1 19:13:45 2026 +0300 drm/rockchip: dw_dp: Add missing newline in dev_err_probe() message [ Upstream commit 0a01412178047bf3ff351c7e75d373e411072a87 ] Add the missing trailing newline to dev_err_probe() call in dw_dp_rockchip_bind(). Fixes: d68ba7bac955 ("drm/rockchip: Add RK3588 DPTX output support") Fixes: 26cb3e26efa7 ("drm/rockchip: dw_dp: Simplify error handling") Signed-off-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260601-drm-rk-fixes-v4-2-c3f3f123e1da@collabora.com Stable-dep-of: cc6d7aca2f37 ("drm/rockchip: dw_dp: Release core resources") Signed-off-by: Sasha Levin commit 82861bdcafda0c85d9a8b419664df4c9681d7df0 Author: Cristian Ciocaltea Date: Tue Mar 10 00:44:32 2026 +0200 drm/rockchip: dw_dp: Simplify error handling [ Upstream commit 26cb3e26efa7cc84289966cab871889f6ca93616 ] Make the code a bit more compact by getting rid of the superfluous assignments around PTR_ERR(). While at it, also drop dev assignment in dw_dp_probe(). Signed-off-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260310-drm-rk-fixes-v2-4-645ecfb43f49@collabora.com Stable-dep-of: cc6d7aca2f37 ("drm/rockchip: dw_dp: Release core resources") Signed-off-by: Sasha Levin commit 435de4476dd878a591b66dbec0fcdf312a7082d6 Author: Andy Yan Date: Fri Feb 6 09:04:12 2026 +0800 drm/bridge: synopsys: dw-dp: Set pixel mode by platform data [ Upstream commit 77ae37018a2705f5abe8cc428e3496651258901d ] In the implementation and integration of the SoC, the DW DisplayPort hardware block can be configured to work in single, dual, quad pixel mode on differnt platforms, so make the pixel mode set by plat_data to support the upcoming rk3576 variant. Signed-off-by: Andy Yan Reviewed-by: Sebastian Reichel Tested-by: Sebastian Reichel Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260206010421.443605-3-andyshrk@163.com Stable-dep-of: cc6d7aca2f37 ("drm/rockchip: dw_dp: Release core resources") Signed-off-by: Sasha Levin commit b2bec2d4a769d5b7b8202123404c7cd1aec17861 Author: Cristian Ciocaltea Date: Mon Jun 1 19:13:44 2026 +0300 drm/bridge: synopsys: dw-dp: Support unregistering the AUX channel [ Upstream commit ed04e8e2307f35b3d8d49a554faf5e72d3d224e6 ] The DisplayPort AUX channel gets initialized and registered during dw_dp_bind(), but it is never unregistered, which may lead to resource leaks and/or use-after-free. Add the missing dw_dp_unbind() function to allow the users of the library to handle the required cleanup, i.e. unregister the AUX adapter. Fixes: 86eecc3a9c2e ("drm/bridge: synopsys: Add DW DPTX Controller support library") Reviewed-by: Andy Yan Signed-off-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260601-drm-rk-fixes-v4-1-c3f3f123e1da@collabora.com Signed-off-by: Sasha Levin commit 5afa737da00e5b10e65feda0bdd08605da6f37ba Author: Paul Kocialkowski Date: Thu Apr 2 20:33:51 2026 +0200 drm: lcdif: Wait for vblank before disabling DMA [ Upstream commit 351af554edd994898db12217c3be39979e168d35 ] It is necessary to wait for the full frame to finish streaming through the DMA engine before we can safely disable it by removing the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the hardware confused and unable to resume streaming for the next frame. This causes the FIFO underrun and empty status bits to be set and a single solid color to be shown on the display, coming from one of the pixels of the previous frame. The issue occurs sporadically when a new mode is set, which triggers the crtc disable and enable paths. Setting the shadow load bit and waiting for it to be cleared by the DMA engine allows waiting for completion. The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep. Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant") Signed-off-by: Paul Kocialkowski Co-developed-by: Lucas Stach Reviewed-by: Frieder Schrempf Tested-by: Frieder Schrempf Acked-by: Liu Ying Link: https://patch.msgid.link/20260402183351.3281123-3-paulk@sys-base.io Signed-off-by: Lucas Stach Signed-off-by: Sasha Levin commit fa633af222c82766e3f3e7d989f62acf5b855177 Author: Yicong Hui Date: Thu Apr 9 16:48:26 2026 +0100 drm: Remove unused header in drm_dumb_buffers.c [ Upstream commit 38b4ce17ef3421fb0e5e6dbdab1974282bde1165 ] Remove the header #include "drm_internal.h" from drm_dumb_buffers.c, which is included but not used. Header was introduced in commit 47f10854ca89 ("drm: Don't export the drm_gem_dumb_destroy() function") when moving functions, but was not removed in commit 96a7b60f6ddb ("drm: remove dumb_destroy callback") when the drm_gem_dumb_destroy function was removed. Compiles successfully with DRM enabled, pass kunit tests and IGT-tests in a vng virtual machine. Fixes: 96a7b60f6ddb ("drm: remove dumb_destroy callback") Signed-off-by: Yicong Hui Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260409154826.8955-1-yiconghui@gmail.com Signed-off-by: Sasha Levin commit 2a0423c648a6d7db298929ab3d5efa493030840f Author: Casey Schaufler Date: Sun Mar 22 11:04:06 2026 -0700 Smack: Fix error in capability bypass [ Upstream commit b2faddc13112489f8f11eb40b9456db8c1b58362 ] A bug in smack_inode_xattr_skipcap() was introduced in the inode capability handling. The strncmp guard at the top of the function is coded backwards, resulting in consistently incorrect results. Correct the check, and the code functions as it should. The error manifests as requiring CAP_SYS_ADMIN as well as CAP_MAC_ADMIN to change an inode's MAC attributes. Fixes: 61df7b828204 ("lsm: fixup the inode xattr capability handling") Reported-by: Bumjin Im Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 31507f01ba6d6957b07a6e248d23e258b4ee4b94 Author: Yosry Ahmed Date: Fri Sep 11 06:41:45 2026 -0400 KVM: x86: Check EFER validity on KVM_SET_SREGS* [ Upstream commit 184bd464bdb66daa9173670904f24c29c7b7f7d4 ] When handling userspace SREGS writes, check the validity of EFER (i.e. allowed bits) before writing the new value of EFER through the per-vendor set_efer callbacks. This prevents userspace from writing bogus values (e.g. EFER.SVME=1 with nested=0). Note: on KVM_SET_MSRS, KVM only checks EFER validity in terms of KVM caps, not guest caps, so it is possible to set EFER bits that are supported by KVM but not by the guest CPUID. Potentially allowing userspace to set msrs before CPUID. However, for KVM_SET_SREGS*, check the validity of the set bits against both KVM and guest caps. This is consistent with other validity checks (e.g. for CR4) that check validity against guest caps, which already imposes the need to set CPUID before SREGS. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260713180153.2728382-2-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d975b36e56876d1c5ff5cedf86b3a2ff4a274fc9 Author: Sean Christopherson Date: Fri Sep 11 06:41:44 2026 -0400 KVM: x86: Move the bulk of register specific code from x86.c to regs.c [ Upstream commit 2f5bb3fe583510cf20f9d64aa73089577be3dc36 ] Introduce regs.c, and move the vast majority of register specific code out of x86.c and into regs.c. Deliberately leave behind MSR code, as KVM's MSR support is complex enough to warrant its own compilation unit, and doesn't have much in common with the other register code. Note, "struct kvm_sregs" has fields for EFER and MSR_IA32_APICBASE, and so the {G,S}ET_REGS flows technically contain a tiny amount of MSR code. MSR_IA32_APICBASE is already managed by lapic.c, and so doesn't require a "placement decision". As for EFER, leave all other EFER handling in x86.c (later to be moved to msrs.c). The primary interface to EFER, set_efer(), is very much MSR specific, even though EFER is arguably more of a Control Register than an MSR. No functional change intended. Reviewed-by: Kai Huang Signed-off-by: Sean Christopherson Reviewed-by: Binbin Wu Message-ID: <20260613000329.732085-5-seanjc@google.com> Signed-off-by: Paolo Bonzini Stable backport notes: Move the existing 6.18 register implementations, retaining its cached register accessors, MMU-owned PDPTR array, VCPU_EXREG identifiers, and kvm_translate_gpa() calling convention. Put cross-file declarations in x86.h, since this branch still uses kvm_cache_regs.h rather than regs.h. Keep the RIP/RFLAGS helpers and kvm_post_set_cr0() in x86.c, alongside their private get_segment_base() and kvm_pv_async_pf_enabled() helpers. Omit the upstream kvm_get_effective_dr7() header change, which is not needed by this tree. Preserve all existing function bodies and the diagnostic prefix; only change linkage where required by the move. This relocates kvm_is_valid_sregs() to regs.c so that target commit 184bd464bdb66daa9173670904f24c29c7b7f7d4 applies without modification. [ sashal: Reduced backport -- upstream 2f5bb3fe58351 touches 5 file(s), this backport carries 4. Not backported here: arch/x86/kvm/regs.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 184bd464bdb6 ("KVM: x86: Check EFER validity on KVM_SET_SREGS*") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 10ddef36d1cc0bcc5fdc23bffb84418c5b74da8f Author: Sean Christopherson Date: Fri Sep 11 06:41:43 2026 -0400 KVM: x86: Rename __{g,s}et_sregs2() => kvm_vcpu_ioctl_x86_{g,s}et_sregs2() [ Upstream commit bd130c8d72a1c7dde5523b3f3fae9867eafaa1dc ] Rename the KVM_{G,S}ET_SREGS2 helpers in anticipation of moving them out of x86.c (while leaving the ioctl dispatch behind). Having globally visible APIs named __{g,s}et_sregs2() would be "fine", but ugly, given that __{g,s}et_sregs() will NOT be globally visible. As a bonus, this makes it a bit more obvious that the helpers implement newer versions of kvm_arch_vcpu_ioctl_set_sregs(). No functional change intended. Cc: Yosry Ahmed Signed-off-by: Sean Christopherson Reviewed-by: Kai Huang Message-ID: <20260613000329.732085-4-seanjc@google.com> Signed-off-by: Paolo Bonzini Stable-dep-of: 184bd464bdb6 ("KVM: x86: Check EFER validity on KVM_SET_SREGS*") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8c03b907b095590b31bdb97f3d504f1328ada029 Author: Sean Christopherson Date: Fri Sep 11 06:41:42 2026 -0400 KVM: x86: Extract REGS and SREGS runtime sync code to helpers [ Upstream commit 6a8a98aa9c147eb63f5a360f157f207bf46c05ee ] Extract the REGS and SREGS portions of {store,sync}_regs() into separate helpers in anticipation of moving the register specific code out of x86.c and into regs.c. No functional change intended. Cc: Yosry Ahmed Signed-off-by: Sean Christopherson Reviewed-by: Kai Huang Reviewed-by: Binbin Wu Message-ID: <20260613000329.732085-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Stable-dep-of: 184bd464bdb6 ("KVM: x86: Check EFER validity on KVM_SET_SREGS*") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9b046de62b8098af6e2ba820b125ec9dc5f162c8 Author: Christian Borntraeger Date: Fri Sep 11 07:49:27 2026 -0400 KVM: s390: Zero initialize data structures for inject_pfault_token [ Upstream commit 4e2c7f7cbc27418f9a290399b986c1b85ff93b90 ] __kvm_inject_pfault_token() only sets .type and .u.ext.ext_params2 of the on-stack struct kvm_s390_irq but the full ext substructure is copied into the cpu local variable on inject. ext_params and pad contain stale stack values. Interrupt delivery only uses ext_params2, so nothing leaks to the guest, but a host user can use the migration ioctls to get to the data. Fix by zero-initializing the irq struct. Do the same for the inti data structure. Fixes: 383d0b050106 ("KVM: s390: handle pending local interrupts via bitmap") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-3-borntraeger@linux.ibm.com> [ Adjusted context for missing inti_mem and ret declarations in __kvm_inject_pfault_token(). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 310df38690e9f9571993a72ce635ef092795d5c9 Author: Yosry Ahmed Date: Fri Sep 11 07:22:01 2026 -0400 KVM: x86: Disallow EFER.LME and EFER.LMA if long mode is not supported [ Upstream commit e62392bf39ebfdf60d1d082799397fe1cbf8dfc5 ] Remove EFER.LME and EFER.LMA from EFER reserved bits only if long mode is actually supported. KVM does check long-mode support before allowing the bits for guest writes and userspace writes through KVM_SET_SREGS* (in __kvm_valid_efer()), but userspace writes through KVM_SET_MSRS only check reserved bits. In practice, this doesn't really matter. The true motiviation is getting rid of the #ifdeffery when initializing efer_reserved_bits. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260713181020.2735367-3-yosry@kernel.org Signed-off-by: Sean Christopherson [ relocated hunks to x86.c and its kvm_x86_vendor_init() because msrs.c and kvm_setup_efer_caps() are absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5453b85c7ebb605febac3df42021f9471663f051 Author: Marc Zyngier Date: Fri Sep 11 06:57:48 2026 -0400 KVM: arm64: Remove VM-wide VNCR mapping counter [ Upstream commit c55bc773b6e814406658fae7dc5c15f639ed816e ] The global VNCR mapping counter is used to decide whether an L1 provided VNCR page is mapped in L0 on any CPU at the point of dealing with a TLB invalidation. It is incremented when a mapping is made in the fixmap, and decremented when unmapped. As it turns out, this tracking has several flaws: - we are trying to invalidate TLBs, and the mapping is only an opportunistic consequence of the TLB. Checking this counter to decide whether a TLB needs to be invalidated may result in missed invalidations. - an L1 vcpu invalidating its own TLB (a very likely case) will not succeed in invalidating the VNCR pseudo TLB because that page is not mapped in L0 at this stage. Given that this tracking fails at delivering the minimum guarantees that are required and is only a performance optimisation, remove it completely. Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Reviewed-by: Yuan Yao Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Acked-by: Lorenzo Stoakes (ARM) Link: https://patch.msgid.link/20260806091026.620700-2-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fd33e8abbcad10565c61890f770b1e7405c72b8b Author: Guoniu Zhou Date: Fri Sep 11 07:26:25 2026 -0400 media: dt-bindings: nxp,imx8-isi: Drop fsl,blk-ctrl requirement for i.MX8ULP [ Upstream commit fc312f830d8df6c082bd6f7250aa5c0ff063eea4 ] The i.MX8ULP variant does not require the fsl,blk-ctrl property. Add fsl,imx8ulp-isi to the exception list alongside fsl,imx91-isi. Fixes: 288517a3c6c9 ("dt-bindings: media: nxp,imx8-isi: Add i.MX8ULP ISI compatible string") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Reviewed-by: Laurent Pinchart Acked-by: Conor Dooley Link: https://patch.msgid.link/20260424-csi2_imx8ulp-v12-1-da148eabc035@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil [ added the missing fsl,blk-ctrl conditional using const instead of enum because this branch lacks i.MX91 support. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5cbd8761d001c11ada73b1753d772c4745a70e72 Author: Marc Zyngier Date: Fri Sep 11 06:59:03 2026 -0400 KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping [ Upstream commit 38640bc32be3fcf9526d477155bc19d3f146231f ] While VNCR TLB invalidation always occurs under the MMU lock, vcpu_put() doesn't, while it unmaps the VNCR page. The problem is that the invalidation evaluates vncr_tlb::cpu to decide whether an unmapping needs to take place (cpu != -1) before performing it. On the other hand, this_cpu_reset_vncr_fixmap() unconditionally unmaps if L1_VNCR_MAPPED is set. These two obviously can race, with a TOCTOU pattern on the TLBI path, and a BUG_ON() on the vcpu_put() path. And the two can end-up calling vncr_fixmap(-1), with extra lethal effects. Move the reset of vncr_tlb::cpu to -1 to a common function, and make this update atomic so that only a single thread can reset the field and perform the corresponding unmap. The vcpu_put() still need to unconditionally unmap the current VNCR to close another ugly race. Finally, the assignment of vncr_tlb::cpu is moved to be kept in sync with the actual mapping, similar to L1_VNCR_MAPPED being set. Fixes: 7270cc9157f47 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/r/20260801130237.0FD8F1F00ACA@smtp.kernel.org Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Yuan Yao Link: https://patch.msgid.link/20260806091026.620700-6-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 892fb48d9dc77366fdd9d438e29182fc362d2581 Author: Oliver Upton Date: Fri Sep 11 06:59:02 2026 -0400 KVM: arm64: nv: Fully update VNCR fixmap state in kvm_translate_vncr() [ Upstream commit 5949004d7032767e8fde1e8c986a33f241b2a192 ] kvm_translate_vncr() first invalidates the pseudo-TLB entry and corresponding fixmap in anticipation of installing a new translation. While the fixmap invalidation does clear the mapping from host stage-1, it does not clear the L1_VNCR_MAPPED flag. Depending on the state of the VNCR TLB at vcpu_put(), this could potentially precipitate a BUG_ON() if vt->cpu is reset. Share a helper with kvm_vcpu_put_hw_mmu(), ensuring that KVM's view of the VNCR fixmap is in sync with the state of the VNCR TLB. Give it a slightly verbose name to make it obvious that it is meant to be used local to a CPU, unlike other VNCR TLB maintenance. Fixes: 069a05e535496 ("KVM: arm64: nv: Handle VNCR_EL2-triggered faults") Signed-off-by: Oliver Upton Link: https://patch.msgid.link/20260602235450.103057-3-oupton@kernel.org Signed-off-by: Marc Zyngier Stable-dep-of: 38640bc32be3 ("KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8195cf3f4a82ef49d9b0651c507ed0784caf23fb Author: Bryam Vargas Date: Wed Sep 9 21:00:12 2026 -0400 dm-pcache: validate the persisted dirty_tail chain at load [ Upstream commit 58d620ee9e01d4bdbceaf2ae1450d307a2a9d58b ] The writeback worker follows the persisted dirty_tail chain, which is decoded from the cache device independently of the key_tail chain that cache_replay() walks and bounds. A crafted image, whose on-media fields are authenticated only by a crc32c with a fixed seed, can aim dirty_tail at a chain of last ksets that never terminates, so cache_writeback_fn() re-arms itself with no delay forever. Walk the dirty_tail chain once at load with the same hop cap cache_replay() uses and fail the table load with -EIO if it does not reach an end within n_segs hops. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mikulas Patocka [ replaced the unavailable cache_seg_id_valid() helper with an equivalent bounds check against cache->cache_info.n_segs ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3d5a87cb909c1f375f08065b20123fa5db5958d8 Author: Bryam Vargas Date: Wed Sep 9 21:00:29 2026 -0400 dm-pcache: bound the logical key offset from persistent memory [ Upstream commit 97fc4b53dbe4a983fdf093243067fa6a64562307 ] cache_key_decode() takes a key's logical off from the cache device and later indexes req_key_tree->subtrees[] by it in get_subtree(). An off past the device forms a subtree pointer outside the array, which rb_insert() writes through during replay. Reject a key of zero length, or whose off+len (computed in 64 bits) exceeds the device size, before it is used. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mikulas Patocka [ adjusted context to account for the missing cache_seg_id_valid() check. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 01a700e9278da5706c865b9ca3ae70fdb7b4531d Author: Bryam Vargas Date: Wed Sep 9 21:00:31 2026 -0400 dm-pcache: reject a kset that overruns its segment [ Upstream commit 7ac1f10f987a2ffae4aecf0e2ceca8f552b665cb ] cache_replay(), the writeback worker and the GC worker read a kset of get_kset_onmedia_size() bytes and advance the position by it. A forged key_num makes that size exceed the segment's remaining space, so the advance walks past the segment and trips the cache_pos_advance() BUG_ON. Reject a kset whose on-media size exceeds cache_seg_remain() before use. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mikulas Patocka [ backported missing writeback_errors support from the upstream dependency. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9693980cd7d2f5b17e5ef5922b922f2e1a770fca Author: Yuhang.chen Date: Wed Sep 9 21:00:26 2026 -0400 wifi: rtw89: pci: add .shutdown callback to stop rfkill polling on reboot [ Upstream commit 667c12782aaf8dd3cb2213e528fe63a73cb63345 ] Since the hardware rfkill polling was introduced, arm64 platforms can panic with an asynchronous SError during warm reboot: SError Interrupt on CPU8, code 0x00000000be000011 -- SError Workqueue: events_power_efficient rfkill_poll [rfkill] rtw89_pci_ops_read8+0x94/0x160 [rtw89_pci] rtw89_core_rfkill_poll+0x50/0x1e0 [rtw89_core] rtw89_ops_rfkill_poll+0x40/0x68 [rtw89_core] ieee80211_rfkill_poll+0x3c/0x70 [mac80211] cfg80211_rfkill_poll+0x40/0x2a0 [cfg80211] rfkill_poll+0x30/0x88 [rfkill] Kernel panic - not syncing: Asynchronous SError Interrupt On the reboot path the kernel only runs device_shutdown(), which calls each driver's .shutdown callback; .remove is not invoked. The rtw89 PCI driver had no .shutdown callback, so nothing stopped the rfkill polling work while the platform was tearing the PCIe link down. Once the link is gone, the next MMIO read from the poll handler targets a non-responding device and is reported as a fatal asynchronous SError on arm64. Add rtw89_pci_shutdown(), wired to all rtw89 PCI device drivers, which sets a new RTW89_FLAG_SHUTDOWN flag (mirroring the USB RTW89_FLAG_UNPLUGGED pattern). When the flag is set, rtw89_ops_rfkill_poll() returns early, so no MMIO read is issued to the chip after shutdown begins and the SError no longer occurs. This does not call the full .remove path from .shutdown, to keep the shutdown handler minimal and avoid running the non-idempotent teardown twice. Fixes: 0b38e6277aed ("wifi: rtw89: add support for hardware rfkill") Cc: stable@vger.kernel.org Suggested-by: Ping-Ke Shih Signed-off-by: Yuhang.chen Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260729014142.2746777-1-yhchen312@gmail.com [ Omitted the .shutdown registration in rtw8922de.c because the driver is absent from the target tree. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9e8dd2a7a8ccbb756771ad985b0ad3387ed3c957 Author: Jeffin Philip Date: Wed Sep 9 21:59:09 2026 -0400 usb: gadget: f_mass_storage: fix null pointer dereference in fsg_common_set_num_buffers() [ Upstream commit 2c0f5ca48674a5b5f9fa4a9c3325aa48053af0bc ] Previously fsg_num_buffers_validate() was removed as it was not necessary due to Kconfig setting the limits for n from 2 to 256 with default as 2. However, setting the page content in such a way that kstrtou8() reflects n value as either 0 or 1 bypasses these restrictions leading to a null pointer dereference if n is 0. Fix this by adding a check for n < 2 and returning -EINVAL if n is either 0 or 1 consistent with Kconfig logic. Reported-by: syzbot+791be35f1fbcc85d06d7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=791be35f1fbcc85d06d7 Fixes: fe5a6c48fd95 ("usb: gadget: storage: get rid of fsg_num_buffers_validate()") Cc: stable Signed-off-by: Jeffin Philip Acked-by: Alan Stern Link: https://patch.msgid.link/20260818035904.10324-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman [ adjusted context to retain the branch’s existing kcalloc() call instead of kzalloc_objs(). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d1856e87ee5620bc9b8f12bb1f0458db7e4a8157 Author: Pawel Laszczak Date: Wed Sep 9 21:35:23 2026 -0400 usb: cdnsp: fix wakeup from S3 after controller context loss [ Upstream commit eae6460f617382044c5afe5ef202f4d8b2c099b5 ] CDNSP controller may lose its runtime register programming across S3 suspend/resume, depending on SoC power domain configuration. After resume the operational and interrupter registers may contain reset values, which prevents the gadget side from recovering correctly and breaks wakeup from S3. Fix this by detecting whether the controller lost its register context after resume and handling both cases: - If context was lost (CFG_3XPORT_U1_PIPE_CLK_GATE_EN set or power lost): reset the controller and reprogram the state required for normal operation, including the command ring, DCBAA pointer, doorbell base, event ring, ERST base/size and event ring dequeue pointer. - If context was retained: restart the controller directly without reprogramming registers. Issue a wakeup if the link was in U3 before suspend. Move the basic controller register programming out of the one-time memory initialization path and make it reusable from the resume path. Also separate ring allocation from ring initialization so that rings can be reinitialized without reallocating DMA memory. Always perform the full suspend sequence regardless of the current link state. Previously, if the device was already in U3, the suspend callback returned early without stopping the controller, which could lead to commands being issued on a disabled slot during resume. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable Signed-off-by: Pawel Laszczak Acked-by: Peter Chen Link: https://patch.msgid.link/20260820-suspend_resume_fix-v3-1-5a713098b977@cadence.com Signed-off-by: Greg Kroah-Hartman [ Omitted the blank-line deletion in cdnsp_run() to preserve the existing USB2 register write. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3776b82c8099e413401fc7fdd9a846677ca3170d Author: Masami Hiramatsu (Google) Date: Thu Sep 10 07:30:21 2026 -0400 tracing/probes: Fix anon_stack check for unnamed bitfields in btf_find_struct_member [ Upstream commit f36d94a20ca185bcadef3a10b980cd2cfd72d53a ] btf_find_struct_member() traverses into nested anonymous structures and unions by pushing members with !member->name_off onto anon_stack. However, it does not consider the unnamed bitfields (e.g. `int : 5` or `unsigned int : 0`) which also have member->name_off == 0. If such an unnamed bitfield is pushed to anon_stack, the btf_find_struct_member() return an error even if there are other valid entries in anon_stack. To fix this, only push unnamed struct/union members to anon_stack. Also move the btf_type_is_struct() check to the entry of this function because now it is sure only struct/union are pushed to anon_stack. Link: https://lore.kernel.org/all/178827249775.123716.7813217688423513612.stgit@devnote2/ Fixes: 302db0f5b3d8 ("tracing/probes: Add a function to search a member of a struct/union") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260830143859.D56991F00A3D@smtp.kernel.org/ Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Steven Rostedt [ retained the existing kcalloc() allocation instead of upstream’s kzalloc_objs() call. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 240558d6e6caf0676ccf00bde0f54785ba54dd4e Author: Muhammad Bilal Date: Thu Sep 10 07:08:45 2026 -0400 staging: sm750fb: fix mono image source stride mismatch in lynxfb_ops_imageblit() [ Upstream commit cc7cd2a9228175c975f62ad56ed7c767701cb4fa ] sm750_hw_imageblit() advances its monochrome source pointer by src_delta per scanline, and computes the correct rounded-up stride internally as: bytes_per_scan = (width + start_bit + 7) / 8; Its only caller, lynxfb_ops_imageblit(), instead passed src_delta as image->width >> 3. For widths not a multiple of 8 this under-counted the stride, so the source pointer fell further behind the real per-scanline layout on every line, corrupting the rendered image. Rather than just fixing the caller's calculation, remove src_delta as a parameter entirely and have sm750_hw_imageblit() advance by the bytes_per_scan it already computes for itself. There has only ever been one caller, and that caller was passing an out-of-sync derivative of the same width/start_bit values sm750_hw_imageblit() already has, so keeping stride as a separate parameter served no purpose beyond letting the two calculations drift apart, which is exactly what happened here. Rounding up, rather than down, is the direction consistent with the rest of the fbdev core: struct fb_image mono bitmap data (the same image->data this driver receives) is walked elsewhere with byte strides derived from a ceiling division of width by 8. The generic mono bit iterator in drivers/video/fbdev/core/fb_imageblit.h advances scanlines with "iter->data += BITS_TO_BYTES(iter->width)", and BITS_TO_BYTES() (include/linux/bitops.h) is a ceiling division. sm750_hw_imageblit()'s own "(width + start_bit + 7) / 8" is that same ceiling division with an added start_bit offset, so the caller's ">> 3" (floor) was the one calculation out of step with how this data layout is handled everywhere else. Found by code review of sm750_hw_imageblit()'s internal stride calculation against what its only caller was passing in, and confirmed with a clean -Werror build. I do not have this hardware, so this has not been exercised at runtime on real sm750 silicon. Fixes: 81dee67e215b2 ("staging: sm750fb: add sm750 to staging") Cc: stable@vger.kernel.org Reviewed-by: Dan Carpenter Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260901113031.161610-1-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman [ Adapted the patch to the older sm750fb variable names. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e5daaf27b14dbade24836a43eb8d2cbba5d7aa9a Author: Krishna Chomal Date: Wed Sep 9 12:44:57 2026 -0400 platform/x86: hp-wmi: Add support for OMEN MAX 16-ak0xxx (8DD6) [ Upstream commit a7320d6eb9c4240c948cd9c64582b3bd04cbaf4b ] The HP OMEN MAX 16-ak0xxx (board ID: 8DD6) has the same WMI interface as other Victus S boards, but requires quirks for correctly switching thermal profile. After testing we know that (similar to another HP Omen Max 16 device, board ID 8D87), the embedded controller on this board does not expose thermal profile which means we have to intentionally disable EC readback. Add the DMI board name to victus_s_thermal_profile_boards[] table and map it to omen_v1_no_ec_thermal_params. Testing on board 8DD6 confirmed that platform profile is registered successfully and fan RPMs are readable and controllable. Tested-by: Yahia Ahmed Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Krishna Chomal Link: https://patch.msgid.link/20260623141314.33947-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen [ adapted the board entry to the older victus_s_thermal_profile_boards table using omen_v1_thermal_params. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1b5c3f11ba548d0a1183d44703feac28f80d37de Author: Mario Limonciello Date: Wed Sep 9 11:09:49 2026 -0400 platform/x86/amd/pmc: Fix msg_port restoration in amd_stb_debugfs_open_v2() [ Upstream commit cbb32ff92f8a62212e0f7384b1de986ced92082b ] amd_stb_debugfs_open_v2() switches dev->msg_port to MSG_PORT_S2D to query S2D telemetry but only restores it to MSG_PORT_PMC on one path. The early return on the dump_custom_stb path (and the error/allocation returns) leave the port stuck on MSG_PORT_S2D, so subsequent SMU communication - including the s2idle prepare/restore handlers - is directed at the wrong mailbox. Consolidate the exit path through a single label so the message port is always restored, mirroring the fix in amd_stb_s2d_init(). Reported-by: sashiko.dev Link: https://sashiko.dev/#/patchset/20260717162023.956346-1-mario.limonciello%40amd.com Fixes: 2851f4f8ed4e ("platform/x86/amd/pmc: Define enum for S2D/PMC msg_port and add helper function") Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260721181756.143084-3-mario.limonciello@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen [ adjusted allocation context to retain kmalloc(struct_size(...), GFP_KERNEL) instead of kmalloc_flex() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bf87d1ec3bc23d56739dce30cf8bf4eaec449440 Author: Dapeng Mi Date: Thu Sep 10 12:31:55 2026 -0400 perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities [ Upstream commit 8767b4d73018bd3143f4c55b672064fad292f11b ] AnyThread mode deprecation is enumerated by CPUID.0AH:EDX[15] instead of PERF_CAPABILITIES MSR. It's not a good practice to define a bit to represent "anythread deprecation" in perf_capabilities. It leads to the anythread_deprecated bit could be overwritten by the real value of PERF_CAPABILITIES MSR, just like the below code in update_pmu_cap() does. if (!intel_pmu_broken_perf_cap()) { /* Perf Metric (Bit 15) and PEBS via PT (Bit 16) are hybrid enumeration */ rdmsrq(MSR_IA32_PERF_CAPABILITIES, hybrid(pmu, intel_cap).capabilities); } It leads to the anythread_deprecated bit is cleared to 0 and the "any" attribute is incorrectly shown in the /sys/devices/cpu/format/ folder on these support Perfmon v6 platforms, like Clearwater Forest. $ grep . /sys/devices/cpu/format/* /sys/devices/cpu/format/acr_mask:config2:0-63 /sys/devices/cpu/format/any:config:21 /sys/devices/cpu/format/cmask:config:24-31 So remove the anythread_deprecated bit from perf_capabilities structure and directly depends on CPUID.0AH:EDX[15] to judge if anythread is deprecated. Fixes: cadbaa039b99 ("perf/x86/intel: Make anythread filter support conditional") Reported-by: Namhyung Kim Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Zide Chen Reviewed-by: Thomas Falcon Acked-by: Namhyung Kim Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260616044654.3468742-2-dapeng1.mi@linux.intel.com [ Adjusted hunk context for missing mediated-vPMU initialization code. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cbb25069fd2e79252d86b374da5b892c535dbe78 Author: Baolin Wang Date: Thu Sep 10 20:15:33 2026 -0400 mm: fix incorrect vm_flags usage when checking allowable orders for tmpfs [ Upstream commit 2fd4e7693674b17807a6d082feb01a3fbf86f5f8 ] Lance reported that when nothing else causes the mm to be considered for khugepaged collapse, an MADV_HUGEPAGE-advised tmpfs VMA alone does not trigger scanning. After commit 6beeab870e70 ("mm: shmem: move shmem_huge_global_enabled() into shmem_allowable_huge_orders()"), the shmem/tmpfs allowable order check reads vma->flags directly. However, when MADV_HUGEPAGE is handled, khugepaged_enter_vma() is called before the VMA's flags have been updated, so the check uses stale flags and incorrectly rejects the VMA for collapse. As a result, khugepaged does not collapse the tmpfs file into PMD order in time. Fix this by calling khugepaged_enter_vma() with the new VMA flags in madvise_update_vma(). Meanwhile we can remove the khugepaged_enter_vma() in hugepage_madvise(). Link: https://lore.kernel.org/7d5b5eb27be798f89d563b06254c947ff53db0b2.1787020910.git.baolin.wang@linux.alibaba.com Fixes: 6beeab870e70 ("mm: shmem: move shmem_huge_global_enabled() into shmem_allowable_huge_orders()") Signed-off-by: Baolin Wang Reported-by: Lance Yang Closes: https://lore.kernel.org/all/20260815181632.21453-1-lance.yang@linux.dev/ Suggested-by: Lorenzo Stoakes (ARM) Reviewed-by: Zi Yan Reviewed-by: Lorenzo Stoakes (ARM) Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Hugh Dickins Cc: Lance Yang Cc: Liam R. Howlett Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton [ adapted newer VMA flag APIs to the older scalar vm_flags_t interface. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 853043cb129473ff2fa0090602be944d96b9d5c9 Author: Lorenzo Stoakes (ARM) Date: Thu Sep 10 07:46:55 2026 -0400 mm/secretmem: properly account locked pages [ Upstream commit 97d34aa65c29cca85e3e9050f4c936389b38a054 ] secretmem accounts folios by treating memory as if it were mlock()'d and thus limited by the RLIMIT_MEMLOCK limit. However the folios are unevictable and remain so until the inode is evicted, eliminating usual mlock() semantics - mapping folios then unmapping them does not clear their unevictable state, since it depends on AS_UNEVICTABLE, not PG_mlocked. A user can therefore easily work around the RLIMIT_MEMLOCK limit - simply map then unmap and VmLck no longer counts the secretmem range. Worse, folios are not accounted in the process's RSS, meaning the OOM killer won't know to kill the process. Repeatedly mapping/unmapping (or forking) can then result in the consumption of all available system memory with unevictable folios and cause system instability. A secretmem fd can be passed between processes and over fork so a per-process limit simply does not make sense, so follow the precedent set by io_uring, perf, skbuff, iommufd and xdp by tracking the number of locked pages in user_struct->locked_vm. Since the scope tracked is actually inode lifetime, the RLIMIT_MEMLOCK applies per-user not per-process, so it doesn't make sense to bypass for users with CAP_IPC_LOCK, therefore remove this bypass. There is simply no reason to carry on marking the mapping as mlock()'d since it's misleading and the lifecycle is now correctly handled, so remove this too. Note that secretmem does not support any form of truncation (including hole punching) and the folios are unreclaimable, so the folios need only be accounted on fault and unaccounted on inode destruction. __secretmem_account_pages() is more or less a duplicate of the code that io_uring etc. use, but since this is a bug fix that needs backporting, defer any de-duplication efforts to a follow-up. test_mlock_limit() asserts mlock_future_ok() on mmap(), however this has been removed, so remove the test altogether for the fix. A new test will be sent separately for upstream. Link: https://lore.kernel.org/20260826-secretmem-accounting-v3-1-94cb04399510@kernel.org Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: Lorenzo Stoakes (ARM) Reported-by: Daehyeon Ko <4ncienth@gmail.com> Closes: https://lore.kernel.org/linux-mm/20260813225328.2010303-1-4ncienth@gmail.com/ Reviewed-by: Mike Rapoport (Microsoft) Acked-by: David Hildenbrand (Arm) Tested-by: Daehyeon Ko <4ncienth@gmail.com> Cc: Alexei Starovoitov Cc: David Hildenbrand Cc: David S. Miller Cc: Hagen Paul Pfeifer Cc: Jakub Kacinski Cc: James Bottomley Cc: Jesper Dangaard Brouer Cc: John Fastabend Cc: Liam R. Howlett Cc: Michal Hocko Cc: Stanislav Fomichev Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton [ replaced newer VMA flag helpers with direct desc->vm_flags operations ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8e3adebbdd20fc430fd5cfd4fdf46a778ad9562f Author: Lorenzo Stoakes (ARM) Date: Thu Sep 10 21:23:56 2026 -0400 mm/mremap: reset unfaulted VMA page offset for MREMAP_DONTUNMAP [ Upstream commit 35b0fb391b0df57383bc15985bb769f4555c97ba ] Uniquely an mremap() invocation using the MREMAP_DONTUNMAP flag can reset a faulted VMA into an unfaulted one. It does so after the page tables have been moved to the copied VMA with MREMAP_DONTUNMAP leaving the old VMA in place which is naturally unfaulted as the page tables it had are no longer present. However, in doing so, it violates the invariant that the anonymous page offset of an unfaulted VMA is vma->vm_start >> PAGE_SHIFT. This is because a VMA may have been faulted in, mremap()'d (causing a delta between its page offset and vma->vm_start >> PAGE_SHIFT), and then mremap()'d again with MREMAP_DONTUNMAP resulting in the unfaulting. This condition is a violation of a fundamental assumption in mm, but now also triggers an assert in assert_sane_pgoff() which explicitly checks for this condition. Correct it by resetting the VMA's page offset at the point of completing the MREMAP_DONTUNMAP operation. Link: https://lore.kernel.org/20260825-fix-mremap-dontunmap-pgoff-v1-1-39a40b2c98b3@kernel.org Fixes: 1583aa278f5f ("mm: mremap: unlink anon_vmas when mremap with MREMAP_DONTUNMAP success") Signed-off-by: Lorenzo Stoakes (ARM) Reported-by: syzbot+f12658786a4153df5113@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a87853b.ae6ddae5.3da009.0023.GAE@google.com/ Tested-by: syzbot+f12658786a4153df5113@syzkaller.appspotmail.com Acked-by: Vlastimil Babka (SUSE) Reviewed-by: Kunwu Chan Reviewed-by: Pedro Falcato Cc: Jann Horn Cc: Liam R. Howlett Cc: Li Xinhai Cc: Signed-off-by: Andrew Morton [ adapted VMA page-offset helpers to use the branch’s single vm_pgoff field. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit effe3cc6d4fdd407457eb30f7b0ef094393f0d64 Author: Usama Arif Date: Thu Sep 10 13:01:11 2026 -0400 mm/huge_memory: transfer the pmd dirty bit to the folio on zap [ Upstream commit fe6cf984939d8e12cb33a99673c8d026c5135e68 ] zap_huge_pmd_folio() propagates the pmd young bit to the folio for the file case, but not the dirty bit. The pte path does propagate it, in zap_present_folio_ptes() and so does the pmd split path, in __split_huge_pmd_locked(). For most file mappings the omission is harmless, because writing to a shared file mapping goes through page_mkwrite(), which dirties the folio. tmpfs is different: it has no page_mkwrite(), and vma_wants_writenotify() is false for it, so a *read* fault on a MAP_SHARED tmpfs mapping installs a writable pmd via do_read_fault(). do_read_fault() does not call fault_dirty_shared_page(), so subsequent stores through that mapping set only the hardware dirty bit in the pmd and never call folio_mark_dirty(). A shmem folio allocated by a fault is marked uptodate but not dirty (see the clear: block in shmem_get_folio_gfp()), so PG_dirty is never set at all. Unmapping such a folio - munmap(), or exit_mmap() when the process dies - then loses the only record that it was written, because zap_huge_pmd() drops the pmd without transferring the dirty bit. Reclaim afterwards sees a clean shmem folio: the whole swap-out block in shrink_folio_list() is inside "if (folio_test_dirty(folio))", so pageout() is skipped and the folio falls into __remove_mapping(). There, folio_is_file_lru() is false for a swapbacked folio, so no shadow entry is created and __filemap_remove_folio(folio, NULL) simply empties the i_pages slot. The data is freed without ever being written to swap, and the next fault on that index returns a freshly zeroed folio. This is silent data loss for any process that keeps state in a MAP_SHARED tmpfs segment across an unmap - for example a cache handed from one process generation to the next through /dev/shm. It requires the folio to be PMD-mapped, so it only shows up once shmem THP is enabled (which is what we did in Meta fleet and started noticing crashes); with THP off the pte path transfers the dirty bit correctly. It also only becomes visible when swap is enabled, because with no swap device shmem folios (which are on the anon LRU) are not scanned by reclaim at all, so the clean folio is never dropped. Reproduced on x86_64 with a tmpfs mounted huge=within_size: read-fault a 2MB-backed region, write a known pattern through the resulting mapping, munmap, force reclaim of the cgroup, then re-map and read back. Without this patch the region reads back as zeros and vmstat shows zswpout 0 - the data was discarded rather than swapped. With this patch the region reads back correctly and the pages are swapped out as expected. With huge=never, or when the first touch is a write, the test passes either way. Link: https://lore.kernel.org/20260819101222.3732660-1-usama.arif@linux.dev Fixes: b5072380eb61 ("thp: support file pages in zap_huge_pmd()") Signed-off-by: Usama Arif Acked-by: David Hildenbrand (Arm) Reviewed-by: Kiryl Shutsemau Acked-by: Hugh Dickins Tested-by: Lance Yang Reviewed-by: Zi Yan Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Johannes Weiner Cc: Liam R. Howlett Cc: Nhat Pham Cc: Rik van Riel Cc: Ryan Roberts Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4f3145db05fede36b35f8249b8acde5bd5d54864 Author: Adrian Hunter Date: Wed Sep 9 21:00:39 2026 -0400 i3c: master: Fix use-after-free of master->this [ Upstream commit feb0ed76601f3c2f91f08688c5a7d8b9d382f720 ] sysfs attribute callbacks for the master controller device dereference master->this. However, master->this is freed in i3c_master_detach_free_devs() before the master device itself is released. As a result, sysfs accesses can dereference a freed master->this pointer, leading to a use-after-free. Keep master->this alive until i3c_masterdev_release(), which is called after the master device and its sysfs state are being torn down. Do not free master->this as part of the normal device detach path. On the error path in i3c_master_set_info(), reset master->this and bus.cur_master to NULL before freeing the allocated device. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260807145638.168865-5-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni [ retained of_node_put(dev->of_node) instead of upstream’s fwnode_handle_put(dev->fwnode). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d0cc00957292e353ad46039034cd8f82fc4f8057 Author: Adrian Hunter Date: Wed Sep 9 21:00:14 2026 -0400 i3c: master: Do not treat master device as a duplicate target [ Upstream commit 4dc1b3eeba7991905a5b5b8129ebea51be7d87b7 ] i3c_master_search_i3c_dev_duplicate() searches the bus for another I3C device with the same PID as the reference device. The search can match master->this, causing the controller itself to be returned as a duplicate. Since the controller is not a target device, it cannot be a duplicate of one. Exclude master->this from matching so that the function only returns real duplicate target devices. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Acked-by: Mukesh Savaliya Link: https://patch.msgid.link/20260807145638.168865-4-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni [ adjusted the duplicate-device comparison to match the older branch’s PID handling without nonzero-PID checks. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 83fd7eca5ab0d3ac3f23bff889175d847e21af06 Author: Steven Rostedt Date: Thu Sep 10 09:46:00 2026 -0400 ftrace: Take trace_array reference before accessing its ftrace_ops [ Upstream commit 9100191e5acb2e5ea2313f436667bb5fce129f47 ] The trace instance files set_ftrace_filter and set_ftrace_notrace was updated to work with specific trace instances (trace_arrays). The issue is that when these files are opened, there is a small race window where it will use the ftrace_ops from the inode->private pointer to get a reference to the trace_array and then take its reference. The problem is that the ftrace_ops itself could be freed. If the rmdir on the instance happens at the same time the set_ftrace_filter file is opened, the rmdir could have also freed the ftrace_ops and referencing it will cause a use-after-free bug and crash the kernel. Instead, pass in the trace_array as the file private data (NULL for the top level instance), and then pass both the trace_array and the ftrace_ops to the ftrace_regex_open() function. If the trace_array is NULL, then it just uses the ftrace_ops without the need to take its reference (like normal). If the ftrace_ops is NULL, that is only the case for the top level instance and the global_ops can be used. This allows the trace_array to have its reference incremented before touching the ftrace_ops that could also be freed when the instance is. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260828223901.29e26edb@robin Fixes: 591dffdade9f0 ("ftrace: Allow for function tracing instance to filter functions") Reported-by: Breno Leitao Tested-by: Breno Leitao Closes: https://lore.kernel.org/all/apGORjltZgAiAYHT@gmail.com/ Signed-off-by: Steven Rostedt [ retained kzalloc(sizeof(*iter), GFP_KERNEL) instead of kzalloc_obj(*iter). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3ae455597e3ea4662a32edcc8d9d1cce2030dc33 Author: Imran Shaik Date: Thu Sep 10 21:35:05 2026 -0400 clk: qcom: Fix test_ctl_hi field for DEFAULT_EVO PLLs [ Upstream commit 830ead322c39c99bf972425b3c35323ec56c29de ] CLK_ALPHA_PLL_TYPE_DEFAULT_EVO type PLLs do not have the PLL_TEST_CTL_U1 register, so clk_alpha_pll_configure() does not program test_ctl_hi1_val for this PLL type. The GCC PLL configurations for QCM2290, Shikra and SM6115 wrongly use test_ctl_hi1_val instead of test_ctl_hi_val, deviating from the hardware recommended settings. Fix them to use test_ctl_hi_val. Fixes: 496d1a13d405 ("clk: qcom: Add Global Clock Controller driver for QCM2290") Fixes: 01cf3e27824d ("clk: qcom: Add Global clock controller support on Qualcomm Shikra SoC") Fixes: e88c533d8a2a ("clk: qcom: gcc-sm6115: Add missing PLL config properties") Cc: stable@vger.kernel.org Signed-off-by: Imran Shaik Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260729-pll-test-ctrl-fixup-v1-1-246d79589380@oss.qualcomm.com Signed-off-by: Bjorn Andersson [ Omitted gcc-shikra.c changes because the driver is absent from the target branch. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 45962da5821d0a691f638ccb13842889156d8969 Author: Taimuraz Kaitmazov Date: Thu Sep 10 15:42:37 2026 -0400 accel/amdxdna: return early from a zero-length flush [ Upstream commit dc14753664240cedf669623b27ae9922b0618b25 ] SYNC_BO does not constrain its size, so a request for zero bytes reaches drm_clflush_virt_range(), which ends with an unconditional clflushopt(end - 1). For an empty range that is the byte before the mapping, and abo->mem.kva comes from vmap(), so the access lands in the guard page below the vmalloc area and faults: BUG: unable to handle page fault for address: ffffd16fbbc70fff #PF: supervisor read access in kernel mode Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 1000 Comm: sync_bo_probe RIP: 0010:drm_clflush_virt_range+0x3c/0x70 Call Trace: amdxdna_drm_sync_bo_ioctl+0x124/0x430 [amdxdna] drm_ioctl+0x301/0x4c0 __x64_sys_ioctl+0x115/0x2f0 do_syscall_64+0xa6/0x3d0 Any process that can open the render node can do this. Reproduced 3 of 3 times on a Strix Point NPU (1022:17f0), by calling SYNC_BO with size 0 on an AMDXDNA_BO_SHARE object. The import arm takes the same request but flushes the whole scatterlist, so it survives it. Nothing needs flushing for an empty range, so answer before choosing a path. Fixes: e252e3f3488a ("accel/amdxdna: Revise device bo creation and free") Cc: stable@vger.kernel.org Signed-off-by: Taimuraz Kaitmazov Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260817230655.356785-1-taimuraz@kaitmazov.com [ moved the guard into amdxdna_drm_sync_bo_ioctl() because amdxdna_flush_bo() is absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit be072a5d5e35f4bdf2da22f600b5d6dc6c5ff491 Author: Li Chen Date: Thu Sep 10 20:34:10 2026 -0400 nvdimm: virtio_pmem: refcount requests for token lifetime [ Upstream commit e57140944b5a47a7fd5a142faab29a02af040bc8 ] KASAN reports slab-use-after-free in __wake_up_common(): BUG: KASAN: slab-use-after-free in __wake_up_common+0x114/0x160 Read of size 8 at addr ffff88810fdcb710 by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-next-20260220-00006-g1eae5f204ec3 #4 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Call Trace: dump_stack_lvl+0x6d/0xb0 print_report+0x170/0x4e2 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __virt_addr_valid+0x1dc/0x380 kasan_report+0xbc/0xf0 ? __wake_up_common+0x114/0x160 ? __wake_up_common+0x114/0x160 __wake_up_common+0x114/0x160 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 __wake_up+0x36/0x60 virtio_pmem_host_ack+0x11d/0x3b0 ? sched_balance_domains+0x29f/0xb00 ? __pfx_virtio_pmem_host_ack+0x10/0x10 ? _raw_spin_lock_irqsave+0x98/0x100 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 vring_interrupt+0x1c9/0x5e0 ? __pfx_vp_interrupt+0x10/0x10 vp_vring_interrupt+0x87/0x100 ? __pfx_vp_interrupt+0x10/0x10 __handle_irq_event_percpu+0x17f/0x550 ? __pfx__raw_spin_lock+0x10/0x10 handle_irq_event+0xab/0x1c0 handle_fasteoi_irq+0x276/0xae0 __common_interrupt+0x65/0x130 common_interrupt+0x78/0xa0 virtio_pmem_host_ack() wakes a request that has already been freed by the submitter. This happens when the request token is still reachable via the virtqueue, but virtio_pmem_flush() returns and frees it. Fix the token lifetime by refcounting struct virtio_pmem_request. virtio_pmem_flush() holds a submitter reference, and the virtqueue holds an extra reference once the request is queued. The completion path drops the virtqueue reference, and the submitter drops its reference before returning. Fixes: 6e84200c0a29 ("virtio-pmem: Add virtio pmem driver") Cc: stable@vger.kernel.org Signed-off-by: Li Chen Signed-off-by: Michael S. Tsirkin Message-ID: <20260630092338.2094628-9-me@linux.beauty> Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4fbee1039c460c9d292012d176f005a61f028607 Author: Hui Su Date: Wed Sep 9 11:09:45 2026 -0400 io_uring/waitid: avoid siginfo copy during ring teardown [ Upstream commit 2cf20c4e0f72d523b8673053e7120d092ff1f074 ] During ring teardown, io_ring_exit_work() cancels outstanding requests from a kworker with a NULL tctx. The waitid cancellation path eventually reaches io_waitid_finish(), which copies the stored siginfo to the userspace pointer supplied with the request. Ring-wide teardown does not run in the task context that submitted the request, so it must not access that task's userspace pointer. Depending on the address and mm state, the copy may fail with -EFAULT, but the uaccess itself is inappropriate from the teardown kworker. Use a no-copy cancellation callback when io_waitid_remove_all() is called without an owning task context. Complete the request with -ECANCELED while releasing the waitid state without touching siginfo. Keep the existing siginfo handling for explicit async cancellation and task-scoped cancellation. Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Cc: stable@vger.kernel.org Signed-off-by: Hui Su Link: https://patch.msgid.link/20260818103336.1922818-3-sh_def@163.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7549d2d113d4a9cbcbb8ea54051dbd1f6d492c9d Author: Li Chen Date: Thu Sep 10 20:34:09 2026 -0400 nvdimm: virtio_pmem: use READ_ONCE()/WRITE_ONCE() for wait flags [ Upstream commit 08e72a5ba1ab9dc0adf993ff0f4d606a1e3445a8 ] Use READ_ONCE()/WRITE_ONCE() for the wait_event() flags (done and wq_buf_avail). They are observed by waiters without pmem_lock, so make the accesses explicit single loads/stores and avoid compiler reordering/caching across the wait/wake paths. Acked-by: Pankaj Gupta Signed-off-by: Li Chen Signed-off-by: Michael S. Tsirkin Message-ID: <20260630092338.2094628-8-me@linux.beauty> Stable-dep-of: e57140944b5a ("nvdimm: virtio_pmem: refcount requests for token lifetime") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0879697520abda2383ed7be40572ad583b5c4b02 Author: Hui Su Date: Wed Sep 9 11:09:54 2026 -0400 io_uring/waitid: honor task_work cancellation [ Upstream commit 14572de82e5022899e5856008bc9cac97004a88c ] io_waitid_cb() may run through the fallback task_work path when task_work_add() can no longer queue work to the originating task. The fallback runs from a kworker and io_uring marks such task work as canceled through tw.cancel. io_waitid_cb() currently ignores tw.cancel and calls __do_wait(). waitid is task-context dependent: __do_wait() performs child lookup relative to current, and the retry path also uses current->signal->wait_chldexit. If the callback runs from the fallback kworker, current is therefore not the task that submitted the request. Honor tw.cancel before entering __do_wait(). Complete the request with -ECANCELED and skip the siginfo copy, since canceled task work may run without the submitting task's userspace execution context. Keep the existing siginfo handling for normal waitid completion and explicit cancellation. Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Cc: stable@vger.kernel.org Signed-off-by: Hui Su Link: https://patch.msgid.link/20260818103336.1922818-2-sh_def@163.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8c6bc1974311affe61af1686e31d3eb04614d6d7 Author: Li Chen Date: Thu Sep 10 20:34:08 2026 -0400 nvdimm: virtio_pmem: always wake -ENOSPC waiters [ Upstream commit 811808761e19fdea1c25b7c76734b8945f758f27 ] virtio_pmem_host_ack() reclaims virtqueue descriptors with virtqueue_get_buf(). The -ENOSPC waiter wakeup is tied to completing the returned token. If token completion is skipped for any reason, reclaimed descriptors may not wake a waiter and the submitter may sleep forever waiting for a free slot. Always wake one -ENOSPC waiter for each virtqueue completion before touching the returned token. Signed-off-by: Li Chen Signed-off-by: Michael S. Tsirkin Message-ID: <20260630092338.2094628-7-me@linux.beauty> Stable-dep-of: e57140944b5a ("nvdimm: virtio_pmem: refcount requests for token lifetime") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 63e1a529bb89bb0604de6013257f6fa97d5aed52 Author: Caleb Sander Mateos Date: Wed Sep 9 11:09:53 2026 -0400 io_uring: add wrapper type for io_req_tw_func_t arg [ Upstream commit c33e779aba6804778c1440192a8033a145ba588d ] In preparation for uring_cmd implementations to implement functions with the io_req_tw_func_t signature, introduce a wrapper struct io_tw_req to hide the struct io_kiocb * argument. The intention is for only the io_uring core to access the inner struct io_kiocb *. uring_cmd implementations should instead call a helper from io_uring/cmd.h to convert struct io_tw_req to struct io_uring_cmd *. Signed-off-by: Caleb Sander Mateos Signed-off-by: Jens Axboe Stable-dep-of: 14572de82e50 ("io_uring/waitid: honor task_work cancellation") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c5e2e145bc5e3d8c3f7871ef7dc931cc5704faa1 Author: Li Chen Date: Thu Sep 10 20:34:07 2026 -0400 nvdimm: virtio_pmem: stop allocating child flush bio [ Upstream commit 40f356e610df95728074b1fc2e2ccb54ca1b5659 ] pmem_submit_bio() passes the parent bio to nvdimm_flush() for REQ_FUA. For virtio-pmem this makes async_pmem_flush() allocate and submit a child PREFLUSH bio chained to the parent. That child allocation is in the block submit path. Making it blocking with GFP_NOIO can consume the same global bio mempool that submit_bio() uses, while making it GFP_ATOMIC can fail under pressure. A forced failure of the child allocation produced: virtio_pmem: forcing child bio allocation failure for test Buffer I/O error on dev pmem0, logical block 0, lost sync page write EXT4-fs (pmem0): I/O error while writing superblock EXT4-fs (pmem0): mount failed Avoid the child bio without turning REQ_FUA into a synchronous submit-path wait. Let provider flush callbacks return NVDIMM_FLUSH_ASYNC after taking ownership of parent bio completion. pmem_submit_bio() returns in that case, and virtio-pmem queues an ordered WQ_MEM_RECLAIM work item that runs the existing host flush path and completes the parent bio. This keeps the asynchronous completion model of the child-bio path while removing the child bio allocation from the submit path. Signed-off-by: Li Chen Signed-off-by: Michael S. Tsirkin Message-ID: <20260630092338.2094628-5-me@linux.beauty> Stable-dep-of: e57140944b5a ("nvdimm: virtio_pmem: refcount requests for token lifetime") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 08600173711311d44e571be2f479a700b35a2ab0 Author: Caleb Sander Mateos Date: Wed Sep 9 11:09:52 2026 -0400 io_uring: only call io_should_terminate_tw() once for ctx [ Upstream commit 4531d165ee39edb315b42a4a43e29339fa068e51 ] io_fallback_req_func() calls io_should_terminate_tw() on each req's ctx. But since the reqs all come from the ctx's fallback_llist, req->ctx will be ctx for all of the reqs. Therefore, compute ts.cancel as io_should_terminate_tw(ctx) just once, outside the loop. Signed-off-by: Caleb Sander Mateos Signed-off-by: Jens Axboe Stable-dep-of: 14572de82e50 ("io_uring/waitid: honor task_work cancellation") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d0f37d77b9b4b241e0b30ef2562f6353cbda3bec Author: Steven Rostedt Date: Thu Sep 10 08:53:19 2026 -0400 tracing: Take trace_array reference when opening options file [ Upstream commit f2951ebd15c36a1ea4820a7f0cbb0b5f1c028b73 ] The options files do not take the trace_array reference for the options they represent. This could cause a use-after-free kernel crash if one of these files is opened by one task and another task removes the instance that the option is for. Because it doesn't take a reference upon opening, it will not stop the removal which will free the options descriptor that is being used. As the options are somewhat dynamic in their creation at boot up, each file represents a flag in the trace_array. The trace_array has an array of indexes to represent each of these flags that is stored in the trace_flags_index array. The address of the index array element is used to pass to the inode->i_private pointer. Then that element is read which holds the index (which represents the flag) and then the index is used to calculate the trace_array descriptor from its trace_flags_index array. One issue is that the index element can not be referenced until the trace_array's reference is taken. To handle this, create a new helper function called: trace_array_options_get() that will iterate all the existing trace_arrays in the ftrace_trace_arrays list (under the trace_types_lock), and compare the passed in address of the index element with the entire array of the trace_array's trace_flags_index array. If it matches, then up the corresponding trace_array's reference and return. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260902121918.5a9e9d1b@gandalf.local.home Fixes: 577b785f55168 ("tracing: add tracer dependent options to options directory") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-trace-kernel/20260828135858.2AC501F000E9@smtp.kernel.org/ Signed-off-by: Steven Rostedt [ replaced the unavailable __trace_array_get(tr) call with tr->ref++ and return 0. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 23a02ff3464b2f276f751b697fd55a81b517b319 Author: Guangshuo Li Date: Thu Sep 10 12:46:42 2026 -0400 i2c: qcom-cci: fix autosuspend cleanup [ Upstream commit f98d4986482151a835b521a734722fe8dc5ca37d ] cci_probe() calls pm_runtime_use_autosuspend(), but the remove path does not call the matching pm_runtime_dont_use_autosuspend() before disabling runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without undoing the autosuspend setting during teardown, this reference is not dropped and usage_count remains unbalanced. Use devm_pm_runtime_set_active_enabled() to manage the runtime PM state. Its managed cleanup disables autosuspend and runtime PM and restores the suspended state on probe failure and driver removal. Remove the now redundant manual runtime PM cleanup. This issue was found by manual code inspection. Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver") Signed-off-by: Guangshuo Li Cc: # v5.8+ Reviewed-by: Vladimir Zapolskiy Reviewed-by: Loic Poulain Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260812094425.3515179-1-lgs201920130244@gmail.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 844839aa89e79f0077f5a8433a125995a17bceb5 Author: Sebastian Andrzej Siewior Date: Thu Sep 10 10:06:22 2026 -0400 futex: Provide rt_mutex_.*_schedule() equivalents for futex scheduling [ Upstream commit 912edebe8501a36c6bedcef03bd238ab90a7e060 ] There is rt_mutex_{pre|post}_schedule() around rt_mutex_wait_proxy_lock() to ensure that sched_submit_work()/ sched_update_worker() is invoked before we schedule out and block on rt_mutex while waiting for it become available. The reason is that blocking on rt_mutex assigns a pi_waiter for the PI chain and sched_submit_work() will also assign a pi_waiter if it blocks on lock but a this point we already have a waiter assigned. We can't skip sched_submit_work() entirely because I/O relies on the fact that I/O queue is flushed while it blocks on a sleeping lock. Therefore sched_submit_work() is moved before we block on the lock. Sleeping lock in this context means mutex or rw_semaphore not spinlock_t on PREEMPT_RT. Because the mutex abstraction on PREEMPT_RT uses the same abstraction as the futex proxy lock, the futex code ended up using rt_mutex_{pre|post}_schedule(), too. Using it is/ was just to keep the task_struct::sched_rt_mutex assertion happy. Futex proxy lock is used only in the syscall context of a task. At this point it never got any I/O that needs to be flushed and it can't be a workqueue that needs to notify that it will be scheduled out. Therefore sched_submit_work() does nothing here. By mistake futex_wait_requeue_pi() -> rt_mutex_wait_proxy_lock() did not get the rt_mutex_{pre|post}_schedule() annotation. This was not noticed because in this callchain the lock is (usually) not contended and so rt_mutex_slowlock_block() does not schedule, triggering the assert. Adding rt_mutex_pre_schedule() here looks wrong (as noted by PeterZ) because at this point there is a pi_waiter recorded and invoking sched_submit_work() with a possible lock contention would be wrong. Add rt_mutex_futex_{pre|post}_schedule() which toggles the sched_rt_mutex assert and does not involve sched_submit_work(). Add asserts here to ensure that sched_submit_work() would do nothing. Use it only in futex proxy lock case which is rt_mutex_wait_proxy_lock(). Remove it from futex_lock_pi(). Fixes: d14f9e930b90 ("locking/rtmutex: Use rt_mutex specific scheduler helpers") Reported-by: Yao Kai Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901135453.3121948-2-bigeasy@linutronix.de Closes: https://lore.kernel.org/all/20260717084922.4153317-2-yaokai34@huawei.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 770a90c2127220f0fc194ce909ad4f0842e141cb Author: Li Chen Date: Thu Sep 10 20:34:06 2026 -0400 nvdimm: pmem: keep PREFLUSH before data writes [ Upstream commit c644a2f8fef5618fcf453c591177700fd07dd024 ] pmem_submit_bio() records a REQ_PREFLUSH error, but continues to copy the bio data and can later overwrite the error with a successful REQ_FUA flush. That lets data writes run after a failed preflush and can complete the bio successfully despite the failed ordering barrier. Run the REQ_PREFLUSH flush synchronously before touching the bio data and complete the bio with the flush error if it fails. Keep asynchronous flush chaining for REQ_FUA. At that point, data copy has completed and the parent bio can wait for the chained flush bio. Signed-off-by: Li Chen Signed-off-by: Michael S. Tsirkin Message-ID: <20260630092338.2094628-3-me@linux.beauty> Stable-dep-of: e57140944b5a ("nvdimm: virtio_pmem: refcount requests for token lifetime") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 15d10440b79685971dce0263066d2f150df0df5b Author: Jens Axboe Date: Wed Sep 9 11:09:51 2026 -0400 io_uring/waitid: have io_waitid_complete() remove wait queue entry [ Upstream commit a48c0cbf28c03f6c590a14ceb31bf6e619c2f6da ] Both callers of this need the entry potentially removed, so shift the removal into the completion side and kill it from the two callers. While at it, add a helper for removing the wait_queue_entry based on the passed in io_kiocb. Signed-off-by: Jens Axboe Stable-dep-of: 14572de82e50 ("io_uring/waitid: honor task_work cancellation") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 76648677aa6ef259c4218b87c10dac1b85befd23 Author: Steven Rostedt Date: Thu Sep 10 08:53:18 2026 -0400 tracing: Make printk_trace global for tracing system [ Upstream commit 1c53d781d42541adc5ba76b4f843a3ff382e01fb ] The printk_trace is used to determine which trace_array trace_printk() writes to. By making it a global variable among the tracing subsystem it will allow the trace_printk functions to be moved out of trace.c and still have direct access to that variable. Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Link: https://patch.msgid.link/20260208032450.144525891@kernel.org Signed-off-by: Steven Rostedt (Google) Stable-dep-of: f2951ebd15c3 ("tracing: Take trace_array reference when opening options file") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 538ef70da52290bc9c773524b7cac489da068199 Author: Vladimir Zapolskiy Date: Thu Sep 10 12:46:41 2026 -0400 i2c: qcom-cci: Remove overcautious disable_irq() calls [ Upstream commit f0285c286bca5a1e018ba25040cef6c7806c31ef ] In cci_probe() the controller's interrupt is requested using a devres managed API, and in cci_probe() error path and cci_remove() it'd be safe to rely on devres mechanism to free and shutdown the interrupt, thus explicit disable_irq() calls can be removed as unnecessary ones. Signed-off-by: Vladimir Zapolskiy Reviewed-by: Loic Poulain Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260515234121.1607425-5-vladimir.zapolskiy@linaro.org Stable-dep-of: f98d49864821 ("i2c: qcom-cci: fix autosuspend cleanup") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 884e8484c5fe827d299d49d0400423c3da94965d Author: Peter Zijlstra Date: Thu Sep 10 10:06:21 2026 -0400 futex: Optimize futex hash bucket access patterns [ Upstream commit a734d9fca84e1d4fa0cb442ef5f84c88f8212d32 ] Breno reported significant c2c HITM in a futex hash heavy workload. It turns out that the hash bucket to private hash table reverse pointer (futex_hash_bucket::priv) was to blame. Notably when the hash buckets are heavily contended, the: 'fph = bh->priv;' load in futex_hash() will typically miss and consequently become quite expensive. Since this load in particular is quite superfluous, removing it is fairly straight forward. However, removing it does not in fact achieve anything much. The pain moves to the next user, notably: futex_hash_put(). Therefore rework the whole private hash refcounting to avoid needing this back pointer (and removing it). Instead of passing around 'struct futex_hash_bucket *hb', pass around a new structure that contains it and the related 'struct futex_private_hash *fph' pointer in tandem. Funnily this turns out to remove more code than it adds and significantly improves futex hash performance (as measured by 'perf bench futex hash'): SKL dual socket 112 threads: Baseline Patched shared (16k) 1571857 1641435 + 4.4% autosize (512) 646390 903371 +39.7% -b 256 464395 587014 +26.4% -b 512 715687 995943 +39.2% -b 1024 995085 1396328 +40.3% -b 2048 1293114 1668395 +29.0% -b 4096 2124438 2240228 + 5.5% Zen3 dual socket 256 threads: Baseline Patched shared (16k) 1275840 1381279 + 8.2% autosize (512) 1252745 1482179 +18.3% -b 256 856274 955455 +11.5% -b 512 1267490 1544010 +21.8% -b 1024 1424013 1625424 +14.1% -b 2048 1505181 1669342 +10.9% -b 4096 1465993 1688932 +15.2% AMD EPYC 9D64 (Zen4, single socket) 176 threads: Baseline Patched Delta shared (16k) 1,230,599 1,368,655 +11.2% autosize (1024) 1,285,440 1,556,946 +21.1% -b 256 1,341,471 1,520,303 +13.3% -b 512 1,438,330 1,599,319 +11.2% -b 1024 1,443,772 1,622,493 +12.4% -b 2048 1,472,108 1,643,975 +11.7% -b 4096 1,333,098 1,570,897 +17.8% Reported-by: Breno Leitao Signed-off-by: Peter Zijlstra (Intel) Tested-by: Breno Leitao Tested-by: Thomas Gleixner Link: https://patch.msgid.link/20260610135510.GB1430057@noisy.programming.kicks-ass.net [ Stable adaptation: use mm->futex_phash in __futex_hash(), since this branch does not contain the mm_struct futex field consolidation. Preserve the final-put use-after-free fix by saving fph->mm before futex_ref_put(), and restore the NULL guard needed by the direct private-hash put callers. futex_key_is_private() is already in futex.h; no new functions are introduced. Keep the bucket-reference conversion so 912edebe8501 applies without changes. ] Stable-dep-of: 912edebe8501 ("futex: Provide rt_mutex_.*_schedule() equivalents for futex scheduling") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5f00df2a88ab47fa00e460c0cd12e42329ad6d6f Author: Jan Kara Date: Wed Sep 9 21:21:03 2026 -0400 udf: Fix data loss when converting inline inodes to out of line [ Upstream commit 62333e480d12ab186f89fe2725b372d12f72d5eb ] When udf_expand_file_adinicb() converts file from inline format to out of line, we use filemap_fdatawrite() to writeout the data to the new blocks. However since 36580ed08776 ("udf: Do not allocate blocks on page writeback") the writeback actually doesn't allocate the new block and the folio dirty bit is just silently cleared. Thus unless the file is written to after the conversion (as it can easily happen in case of truncate up), the data is just lost. Fix the problem by explicitely allocating the block underlying the data before starting writeback. Fixes: 36580ed08776 ("udf: Do not allocate blocks on page writeback") CC: stable@vger.kernel.org Link: https://patch.msgid.link/20260730104232.4086759-4-jack@suse.cz Signed-off-by: Jan Kara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e4cb2bbe730894ac74be237ba02e63ad1543fb32 Author: Masami Hiramatsu (Google) Date: Thu Sep 10 07:51:39 2026 -0400 tracing/probes: Fix BTF kflag check for anonymous struct member access [ Upstream commit 47e93045a2db80d24f5fef65adecc6b2b32efa23 ] btf_find_struct_member() traverses into nested anonymous structures and unions to find a struct member. However, get_bitoffset_of_field() in trace_probe.c checked btf_type_kflag(type) using the outer parent type instead of the actual anonymous structure/union that directly contains the found member. If the parent structure and anonymous structure have mismatched kflags (e.g., the parent has kflag=0 while the anonymous structure has kflag=1 because it contains bitfields), the bitfield size encoded in the upper 8 bits of member->offset is erroneously treated as part of the byte/bit offset, corrupting the resolved offset and failing to set last_bitsize. Similarly, btf_find_struct_member() pushed anonymous member offsets onto anon_stack without masking BTF_MEMBER_BIT_OFFSET() when kflag is set. To fix this problem, update btf_find_struct_member() to return actual containing structure/union type via member_type, use appropriate __btf_member_bit_offset() to get bit offset, and use member_type for btf_type_kflag() in get_bitoffset_of_field(). Link: https://lore.kernel.org/all/178827250904.123716.17452648791331881284.stgit@devnote2/ Fixes: c440adfbe302 ("tracing/probes: Support BTF based data structure field access") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260822095110.0772E1F000E9@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.7-flash Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Steven Rostedt [ applied changes to parse_btf_field() because get_bitoffset_of_field() is absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4420cc71841b50e31a7868ef7acb011c0e08d294 Author: Muhammad Bilal Date: Thu Sep 10 07:09:10 2026 -0400 staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie() [ Upstream commit 28a289beaf226b30b1e6e7d7b1a2946fe2d6e852 ] rtw_restruct_wmm_ie() scans in_ie for a WMM IE with: while (i < in_len) { ... if (i + 5 < in_len && in_ie[i] == 0xDD && ...) { ... break; } i += (in_ie[i + 1] + 2); /* to the next IE element */ } When the "i + 5 < in_len" match check fails simply because i is within 5 bytes of the end of the buffer (i.e. no WMM IE was found near the tail of in_ie), execution falls through to "i += (in_ie[i + 1] + 2)", which reads in_ie[i + 1]. If i == in_len - 1 at that point, this is a 1-byte out-of-bounds read of an attacker-influenced IE buffer built from association/scan data. Commit a75281626fc8f ("staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie") added the "i + 5 < in_len" guard to the match condition itself, but did not add an equivalent guard before the fallthrough advance, so the same class of OOB read remained reachable through the non-matching path. Add an explicit bounds check before advancing to the next IE. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260728125456.32359-4-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6ba2bacc2dd3e55288914b3f5b5165bdd86a0d7b Author: Vincent Donnefort Date: Thu Sep 10 15:08:55 2026 -0400 ring-buffer: Allow splice reads on static buffers [ Upstream commit 6365c44a824ff138e7926413932bb5c2e28a4c8c ] ring_buffer_read_page() rejects splice (full=1) reads on static buffers (that is user-mapped, persistent or remote) because !read check assumes unread pages must be swapped. However for those buffers we have no other choice than memcpy the data. For the memcpy case, only return an error when the writer is still on the reader page for the splice interface to wait. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901155445.1475405-2-vdonnefort@google.com Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f5eed5182d6646b7210e393329d97351fe5db52c Author: Srinivas Pandruvada Date: Wed Sep 9 10:10:41 2026 -0400 platform/x86: ISST: Validate max level for set feature [ Upstream commit e45d6b8472861d3bac86bb37f8556a7c5aca3266 ] Validate the level before setting, so that it fails early instead of failing later when checking the bit mask for allowed levels. Fixes: ea009e4769fa3 ("platform/x86: ISST: Add SST-PP support via TPMI") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260811221514.3905817-3-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 08dab7065f9369dd0a0aa740071bcd884c4848b0 Author: Abdun Nihaal Date: Wed Sep 9 10:50:32 2026 -0400 platform/x86: int1092: Fix potential memory leak in sar_probe() [ Upstream commit 30c906cff490c3601ee9ff110fe8115fabe75fd4 ] The memory allocated for device_mode_info in parse_package() called by sar_get_data() is not freed in some of the error paths in sar_probe(). Fix that by converting to use device managed allocations. Fixes: dcfbd31ef4bc ("platform/x86: BIOS SAR driver for Intel M.2 Modem") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20260723-platx86-v4-1-93b4a178b595@cse.iitm.ac.in Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 929cb3b9dc818dd9fa89d510d4ff2b255e42badd Author: Yilin Zhang Date: Thu Sep 10 12:45:22 2026 -0400 perf: Fix use-after-free when perf mmap() revival races with the last munmap() [ Upstream commit 58a8108bc73de0740d5b88150465d6690ea5f85f ] perf_mmap_close() drops rb->mmap_count *without* holding event->mmap_mutex (the refcount_dec_and_test() right before the refcount_dec_and_mutex_lock() of event->mmap_count). A concurrent perf_mmap_rb() can slot its entire "revival" path into that window (perf_mmap holds event->mmap_mutex for its whole duration, including rb_alloc): munmap side (perf_mmap_close) mmap side (perf_mmap_rb) ----------------------------------- -------------------------------- rb->mmap_count 1 -> 0 (no lock) (holds event->mmap_mutex) inc_not_zero(rb->mmap_count) fails ring_buffer_attach(event, NULL) rb_alloc() + attach new rb refcount_set(&event->mmap_count, 1) lock; event->mmap_count 1 -> 0 ring_buffer_attach(event, NULL) ring_buffer_put() -> frees the *new* rb The revival's refcount_set(&event->mmap_count, 1) is an invisible 1 -> 1 write: the close frees the just-revived buffer although the other process still has it mapped -- a page-level use-after-free allowing local privilege escalation to root by any unprivileged user (default kernel.perf_event_paranoid=2). Swap the order of the two counter updates: event->mmap_count is dropped first via refcount_dec_and_mutex_lock(), so its 1 -> 0 transition and the ring_buffer_attach() stay serialized with perf_mmap(). rb->mmap_count == 0 then implies every event using the buffer is detached already, so the result of the rb->mmap_count drop can gate the remaining teardown directly and detach_rest is no longer needed. An earlier fix for this race from Kyle Zeng and David Lee takes event->mmap_mutex around both counter updates [0]; here the not-last close stays lockless. Fixes: 59741451b49c ("perf: Identify the 0->1 transition for event::mmap_count") Reported-by: Kimi Security Team Suggested-by: Peter Zijlstra Co-developed-by: Weiming Shi Signed-off-by: Weiming Shi Signed-off-by: Yilin Zhang Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/linux-perf-users/20260804060931.711308-1-david.lee@trailofbits.com/ [0] Cc: Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260831162155.1437652-1-yilinzhang@moonshot.ai Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2050d900f9adbd6d6f38d30e182bcd9ad3108467 Author: Farhan Ali Date: Wed Sep 9 10:14:34 2026 -0400 PCI: Allow per function PCI slots to fix slot reset on s390 [ Upstream commit dcc5bec09e23bbc4f9de055a11fce9937244f2c8 ] On s390 systems, which use a machine level hypervisor, PCI devices are always accessed through a form of PCI pass-through which fundamentally operates on a per PCI function granularity. This is also reflected in the s390 PCI hotplug driver which creates hotplug slots for individual PCI functions. Its reset_slot() function, which is a wrapper for zpci_hot_reset_device(), thus also resets individual functions. Currently, the pci_create_slot() assigns the same pci_slot object to multifunction devices. This approach worked fine on s390 systems that only exposed virtual functions as individual PCI domains to the operating system. Since commit 44510d6fa0c0 ("s390/pci: Handling multifunctions") s390 supports exposing the topology of multifunction PCI devices by grouping them in a shared PCI domain. This creates a problem when resetting a function through the hotplug driver's slot_reset() interface. When attempting to reset a function through the hotplug driver, the shared slot assignment causes the wrong function to be reset instead of the intended one. It also leaks memory as we do create a pci_slot object for the function, but don't correctly free it in pci_slot_release(). Add a flag for struct pci_slot to allow per function PCI slots for functions managed through a hypervisor, which exposes individual PCI functions while retaining the topology. Since we can use all 8 bits for slot 'number' (for ARI devices), change slot 'number' u16 to account for special values PCI_SLOT_PLACEHOLDER and PCI_SLOT_ALL_DEVICES. Fixes: 44510d6fa0c0 ("s390/pci: Handling multifunctions") Suggested-by: Niklas Schnelle Signed-off-by: Farhan Ali Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Schnelle Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260805165518.794-3-alifm@linux.ibm.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7fad53ae2052a2b4fc7ca567d6555bdb1176ba35 Author: Chao Shi Date: Thu Sep 10 15:15:36 2026 -0400 nvme: skip the zoned limits update if the zone info query failed [ Upstream commit 3838e80fcfb32e62baffb63c6dc0a60153665a4d ] nvme_query_zone_info() returns either a negative errno or a positive NVMe status code, but nvme_update_ns_info_block() only tests for the negative case: ret = nvme_query_zone_info(ns, lbaf, &zi); if (ret < 0) goto out; If the device fails the Identify Namespace (I/O Command Set specific) command, or the Identify Controller command issued by nvme_set_max_append(), the positive status falls through and setup continues with the zero-initialized zone info. nvme_update_zone_info() then marks the queue zoned with chunk_sectors and ns->head->zsze set to zero. blk_validate_zoned_limits() does not check chunk_sectors, so the limits commit succeeds. blk_revalidate_disk_zones() does reject the zero zone size, but by then the limits are live and nothing rolls them back, so I/O keeps being submitted to a zoned queue with a zero zone size and disk_zone_no() shifts by ilog2(0): nvme0n1: Invalid non power of two zone size (0) UBSAN: shift-out-of-bounds in include/linux/blkdev.h:747:16 shift exponent -1 is negative disk_zone_no include/linux/blkdev.h:747 [inline] bio_straddles_zones include/linux/blkdev.h:1058 [inline] blk_zone_wplug_handle_write block/blk-zoned.c:1423 [inline] blk_zone_plug_bio.cold+0x25/0x1c8 block/blk-zoned.c:1605 blk_mq_submit_bio+0x18fb/0x2870 block/blk-mq.c:3196 submit_bh_wbc+0x575/0x740 fs/buffer.c:2824 __block_write_full_folio+0x728/0xdd0 fs/buffer.c:1933 Any device, firmware or NVMe-oF target that fails this one command reaches this. Skip the zoned limits update in that case, and log which of the two things happened: during a revalidation the queue keeps the zone geometry it was last validated with, and on a first scan the namespace is registered without zoned limits, so that it is still available as a handle for admin commands. Neither of the paths in nvme_query_zone_info() that return a positive status logs anything, so the failure would otherwise be silent. zi.zone_size is an exact indicator: every path that returns a positive status returns before it is assigned, and after that the only failure left is -ENODEV, which the caller already handles. Found by FuzzNvme. Fixes: c85c9ab926a5 ("nvme: split nvme_update_zone_info") Cc: stable@vger.kernel.org Cc: Weidong Zhu Suggested-by: Keith Busch Reviewed-by: Christoph Hellwig Signed-off-by: Chao Shi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6906fb70af2ded77ebdf27f8840d2d5148c95ded Author: Glenn Judd Date: Wed Sep 9 13:32:14 2026 -0400 net/mlx5e: do not HW-GRO coalesce small frames [ Upstream commit e2466392a0b8496000e12181cb1ee1535eb0da25 ] When hardware GRO (SHAMPO) coalesces a small IPv4/TCP segment that was padded up to the 60-byte minimum Ethernet frame, the trailing padding is folded into the merged payload causing padding to be delivered to the user as payload. Detecting and reproducing the issue: the selftest tools/testing/selftests/drivers/net/gro.py subtest hw_ipv4_data_lrg_1byte sends {100, 1} expecting to receive {101}. In current code, it receives {106} (100 + 1 payload + 5 pad) instead. This patch avoids giving the user padding as payload by simply not coalescing small packets (which fails the subtest; the same approach and behavior as sw gro). This gains code simplicity at the cost of more computation (passing an extra skb up the stack) for small packets that could be coalesced. The threshold is chosen as ETH_ZLEN + 2 * VLAN_HLEN. This is the largest frame that may still contain minimum-frame padding (+ 2 VLAN tags), so anything larger is safe to consider for coalesce. (We do not include ETH_FCS_LEN in that threshold computation as netdev_fix_features() drops NETIF_F_GRO_HW whenever NETIF_F_RXFCS is set, so retained FCS can't reach this path.) Fixes: 92552d3abd32 ("net/mlx5e: HW_GRO cqe handler implementation") Cc: stable@vger.kernel.org Signed-off-by: Glenn Judd Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260816064259.3279548-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 558bfaea4926c3b20a907c3906559c1c747c24a5 Author: Miquel Raynal (DAVE) Date: Thu Sep 10 20:41:58 2026 -0400 mtd: rawnand: pl353: Make sure we use the monolithic helpers for raw accesses [ Upstream commit 80ecacd054ffeb60cd28e46ed5cd6bd0d2de318b ] Any access not using the hardware ECC engine should be monolithic because the controller has its very own way of handling the end of a transaction during operation configuration, so we cannot easily make repeated reads. This has the side effect of fixing support for software ECC engines. Suggested-by: Andrea Scian Cc: stable@vger.kernel.org Fixes: 08d8c62164a3 ("mtd: rawnand: pl353: Add support for the ARM PL353 SMC NAND controller") Signed-off-by: Miquel Raynal (DAVE) Acked-by: Michal Simek Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 824348676a50fc5fd2ff2715a61aa9bf4b5b63ef Author: Baineng Shou Date: Thu Sep 10 11:52:34 2026 -0400 misc: fastrpc: don't publish fd before copy_to_user() succeeds [ Upstream commit a4a1a2bfcb29785292d634d7787edc6fb550714d ] fastrpc_ioctl_alloc_dmabuf() calls dma_buf_fd() which installs the fd into the caller's fd table before copy_to_user() copies the fd number back to userspace. If copy_to_user() fails, the fd is already visible to other threads in the same process but the ioctl returns -EFAULT. The existing comment in the code even acknowledges the problem: "The usercopy failed, but we can't do much about it, as dma_buf_fd() already called fd_install()..." Now that dma_buf_fd_install() is available (introduced to fix the same issue in dma-heap), apply the same pattern here: reserve the fd with get_unused_fd_flags(), attempt copy_to_user(), and only on success call dma_buf_fd_install() to publish it atomically with the tracepoint. On copy_to_user() failure, put_unused_fd() and dma_buf_put() cleanly unwind without any user-visible side effects. Fixes: 6cffd79504ce ("misc: fastrpc: Add support for dmabuf exporter") Cc: stable@vger.kernel.org Acked-by: Christian König Acked-by: Sumit Semwal Signed-off-by: Baineng Shou Link: https://lore.kernel.org/r/20260817050457.1005285-3-shoubaineng@gmail.com Signed-off-by: Christian König Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f3d97800b03cd39ec135e544dcd0a93ffd18e4c7 Author: Moksh Panicker Date: Thu Sep 10 22:30:57 2026 -0400 iio: light: apds9306: fix PM reference leak in apds9306_read_data() [ Upstream commit d378fceaafd79e0dc59d3546bda251a3058062c0 ] apds9306_read_data() calls pm_runtime_resume_and_get() but several error paths return directly without calling pm_runtime_put_autosuspend(), leaking the runtime PM reference and preventing the device from autosuspending. Use PM_RUNTIME_ACQUIRE_AUTOSUSPEND() and PM_RUNTIME_ACQUIRE_ERR() to automatically handle runtime PM reference release on all return paths. Fixes: 620d1e6c7a3f ("iio: light: Add support for APDS9306 Light Sensor") Signed-off-by: Moksh Panicker Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b25232f66e8cd653d0c6bfdbe534e62a2f9d6a1b Author: Adrian Hunter Date: Wed Sep 9 16:50:47 2026 -0400 i3c: master: Fix recursive locking during device registration [ Upstream commit 456f832e5fc26fbfd3b8200fd4553eee520cc377 ] i3c_master_register_new_i3c_devs() registers newly discovered devices while holding i3c_bus_normaluse_lock(), a down_read(). device_register() can immediately probe the device, and probe callbacks typically invoke I3C helpers that take i3c_bus_normaluse_lock() again, leading to a recursive acquisition of the same rwsem. rwsems do not support recursive read locking and can deadlock when a writer is waiting. See the "Recursive read locks" section of Documentation/locking/lockdep-design.rst. For example, with Intel LPSS I3C, LOCKDEP generates a WARNING like: # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/unbind # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/bind WARNING: possible recursive locking detected kworker/5:1/94 is trying to acquire lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_device_match_id+0x45/0x370 but task is already holding lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_master_reg_work_fn+0x21/0x5f0 Fix this by separating device creation from device registration. Populate desc->dev under the maintenance lock, collect the devices that still need registration into a local list, then release the lock before calling device_register(). Finally retake the lock and clean up any devices that failed to register. Use the maintenance lock rather than the normal-use lock while adding device objects. A write-side maintenance lock prevents readers from observing a partially initialized desc->dev during initial device population, or desc->dev disappearing if registration fails. The local list requires a list node, so add a list node member to struct i3c_device. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260807145638.168865-2-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e9e52437120fb5f802152877ba20c4b406c9fa9e Author: Baul Lee Date: Wed Sep 9 14:55:24 2026 -0400 ALSA: FCP: do not copy out an uninitialised init response [ Upstream commit 4335e387786479889e6db691fe06d345e52ea536 ] fcp_ioctl_init() allocates its response buffer with kmalloc() and copies the whole buffer back to userspace: buf_size = init.step0_resp_size + init.step2_resp_size; void *resp __free(kfree) = kmalloc(buf_size, GFP_KERNEL); ... if (copy_to_user(arg->resp, resp, buf_size)) return -EFAULT; Nothing clears the buffer, and the only writer of its leading step0_resp_size bytes is the step-0 control transfer: err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), FCP_USB_REQ_STEP0, USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN, 0, private->bInterfaceNumber, step0_resp, private->step0_resp_size); if (err < 0) return err; usb_fill_control_urb() does not set URB_SHORT_NOT_OK, so a short or zero-length data stage completes with status 0 and snd_usb_ctl_msg() returns a small actual_length. The only check is err < 0, so a short transfer is accepted as success. snd_usb_ctl_msg() copies the full size back unconditionally: buf = kmemdup(data, size, GFP_KERNEL); ... memcpy(data, buf, size); Bytes the device never wrote are therefore restored into resp unchanged and copied to userspace. step0_resp_size and step2_resp_size are each validated only to 1..255, so the caller also picks the slab cache, from kmalloc-8 up to kmalloc-512. On 7.2.0-rc5 (arm64), device answering step 0 with a zero-length data stage, s0 = s2 = 255: # init_on_alloc off, no spray step0 window [0,255): nonzero=94/255 000: 00 80 60 06 00 00 ff ff 18 00 00 00 57 01 ea 01 010: 08 78 22 13 00 00 ff ff a8 c4 5f 80 00 80 ff ff # same kernel, kmalloc-512 pre-seeded with an 8-byte tag step0 window [0,255): nonzero=219/255 tagbytes=232 # identical run, init_on_alloc=1 step0 window [0,255): nonzero=0/255 tagbytes=0 # all three runs step2 window [255,510): device words matched=62/62 a8 c4 5f 80 00 80 ff ff is the little-endian kernel text address ffff8000805fc4a8. The step-2 window is unaffected, so the disclosure is exactly the step-0 region. Zero the buffer, and require the step-0 transfer to deliver the full step0_resp_size bytes so a short data stage is reported as an error. Discovered by XBOW, triaged by Baul Lee Fixes: 46757a3e7d50 ("ALSA: FCP: Add Focusrite Control Protocol driver") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260805013804.38839-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5881506012f394353acb2aa3124ca51b4250ab14 Author: Li Chen Date: Thu Sep 10 20:34:05 2026 -0400 nvdimm: preserve flush callback -ENOMEM [ Upstream commit 6b7108712a4b1c37cac69815aede1dde202b3187 ] nvdimm_flush() maps provider flush failures to -EIO. Keep that default because provider callbacks can report host-side or backend failures that should remain generic I/O errors to the guest. Guest-side allocation failures should not be reported as I/O errors. In the virtio-pmem path, the flush request allocation can fail with -ENOMEM before any request is submitted to the host. Mapping that to -EIO makes resource pressure look like media failure. Preserve -ENOMEM from provider callbacks and continue to map other non-zero provider failures to -EIO. The generic flush path still returns 0, and pmem_submit_bio() already converts errno values to block status for bio completion. Suggested-by: Pankaj Gupta Signed-off-by: Li Chen Signed-off-by: Michael S. Tsirkin Message-ID: <20260630092338.2094628-2-me@linux.beauty> Stable-dep-of: e57140944b5a ("nvdimm: virtio_pmem: refcount requests for token lifetime") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 545daf11333238b57076df6a9fad261a8fec8e93 Author: Jens Axboe Date: Wed Sep 9 11:09:50 2026 -0400 io_uring: unify task_work cancelation checks [ Upstream commit 7be20254a743be4f02414b9d56cc3fe5f84e6500 ] Rather than do per-tw checking, which needs to dip into the task_struct for checking flags, do it upfront before running task_work. This places a 'cancel' member in io_tw_token_t, which is assigned before running task_work for that given ctx. This is both more efficient in doing it upfront rather than for every task_work, and it means that io_should_terminate_tw() can be made private in io_uring.c rather than need to be called by various callbacks of task_work. Signed-off-by: Jens Axboe Stable-dep-of: 14572de82e50 ("io_uring/waitid: honor task_work cancellation") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 400607f57f11dcd6e81a2de654f945a9410644d4 Author: Steven Rostedt Date: Thu Sep 10 08:53:17 2026 -0400 tracing: Clean up use of trace_create_maxlat_file() [ Upstream commit ba73713da50e5c24499ca8941171593466ea34f7 ] In trace.c, the function trace_create_maxlat_file() is defined behind the #ifdef CONFIG_TRACER_MAX_TRACE block. The #else part defines it as: #define trace_create_maxlat_file(tr, d_tracer) \ trace_create_file("tracing_max_latency", TRACE_MODE_WRITE, \ d_tracer, tr, &tracing_max_lat_fops) But the one place that it it used has: #ifdef CONFIG_TRACER_MAX_TRACE trace_create_maxlat_file(tr, d_tracer); #endif Which is pointless and also wrong! It only gets created when both CONFIG_TRACE_MAX_TRACE and CONFIG_FS_NOTIFY is defined, but the file itself should not be dependent on CONFIG_FS_NOTIFY. Always create that file when TRACE_MAX_TRACE is defined regardless if FS_NOTIFY is or is not. Cc: Mathieu Desnoyers Acked-by: Masami Hiramatsu (Google) Link: https://patch.msgid.link/20260207191101.0e014abd@robin Signed-off-by: Steven Rostedt (Google) Stable-dep-of: f2951ebd15c3 ("tracing: Take trace_array reference when opening options file") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 871019760cd42e19a5ee81ea8c748536ab3e481a Author: Vladimir Zapolskiy Date: Thu Sep 10 12:46:40 2026 -0400 i2c: qcom-cci: Do not check return value of cci_init() [ Upstream commit 17c5d247e3e4708cac05ff087c8013c0dda383a2 ] The cci_init() function is not supposed to fail, and it never returns a non-zero, so it'd make sense to convert its signature to void. Signed-off-by: Vladimir Zapolskiy Reviewed-by: Loic Poulain Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260515234121.1607425-3-vladimir.zapolskiy@linaro.org Stable-dep-of: f98d49864821 ("i2c: qcom-cci: fix autosuspend cleanup") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 54bc09b41bf3a40ef21ebc8ef27dd89794e73296 Author: Marco Elver Date: Thu Sep 10 10:06:20 2026 -0400 compiler_types: Move lock checking attributes to compiler-context-analysis.h [ Upstream commit de15fecae44df8254fa597bad7eb3680a8b1c10c ] The conditional definition of lock checking macros and attributes is about to become more complex. Factor them out into their own header for better readability, and to make it obvious which features are supported by which mode (currently only Sparse). This is the first step towards generalizing towards "context analysis". No functional change intended. Signed-off-by: Marco Elver Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20251219154418.3592607-2-elver@google.com Stable-dep-of: 912edebe8501 ("futex: Provide rt_mutex_.*_schedule() equivalents for futex scheduling") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9e5abb5e2ade0b6fd0e47209711115d47a255176 Author: Bryam Vargas Date: Wed Sep 9 21:17:27 2026 -0400 wifi: mt76: mt7996: bound the device EEPROM address before the EFUSE copy [ Upstream commit 13b3c29a782033ce4a230be9e5618032813dbcd4 ] mt7996_mcu_get_eeprom() derives the destination of the EFUSE/EXT block copy from the address reported by the MCU response (event->addr, a device-controlled __le32) and clamps only the copy length, never the destination offset into dev->mt76.eeprom.data. A malicious or malfunctioning device can report an arbitrary address and drive an out-of-bounds write of up to MT7996_EXT_EEPROM_BLOCK_SIZE bytes past eeprom.data. Reject a response whose address would place the copy outside eeprom.data before deriving the destination pointer. Devices that echo the requested in-bounds offset are unaffected. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260625-b4-disp-16f99062-v1-2-aee52ecf61b9@proton.me Signed-off-by: Felix Fietkau [ Replaced the mode-dependent block size with MT7996_EEPROM_BLOCK_SIZE for the older EFUSE-only implementation. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 84d983e550c7531bb32bc3f34cfa0d96b64ccbe9 Author: Jan Kara Date: Wed Sep 9 21:21:02 2026 -0400 udf: Move udf_map_block() up [ Upstream commit 97e9d759a4193eabe4d8b6ecac093aac664c16e3 ] Move udf_map_block() in the file to avoid forward declarations. Link: https://patch.msgid.link/20260730104232.4086759-3-jack@suse.cz Signed-off-by: Jan Kara Stable-dep-of: 62333e480d12 ("udf: Fix data loss when converting inline inodes to out of line") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7d73adba5c85135d15f759f652c033cfe72d0be1 Author: Martin Kaiser Date: Thu Sep 10 07:51:38 2026 -0400 tracing/probes: ignore id update from btf_type_skip_modifiers [ Upstream commit 823b37855829bc328d46102a56e4d0b2f7a3d0d1 ] We can pass NULL as id pointer to btf_type_skip_modifiers if we do not need the id of the returned btf_type. Link: https://lore.kernel.org/all/20260623132937.3494895-1-martin@kaiser.cx/ Signed-off-by: Martin Kaiser Signed-off-by: Masami Hiramatsu (Google) Stable-dep-of: 47e93045a2db ("tracing/probes: Fix BTF kflag check for anonymous struct member access") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 956cb6c72ae5cb055689ca0070fdebe67847c4d7 Author: Vivek BalachandharTN Date: Thu Sep 10 07:09:09 2026 -0400 staging: rtl8723bs: fix spacing around operators [ Upstream commit 2038fe84b8bdf894b634f777096685e78e8f3774 ] Fix several instances where operators lacked spaces around them. This improves readability and brings the driver closer to kernel coding-style guidelines. No functional change. Signed-off-by: Vivek BalachandharTN Link: https://patch.msgid.link/20251205021417.2705864-3-vivek.balachandhar@gmail.com Signed-off-by: Greg Kroah-Hartman For this stable dependency, retain only the spacing change to the IE advance in rtw_restruct_wmm_ie(). This supplies the exact context needed by target commit 28a289beaf226 ("staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie()"). Drop the unrelated operator-spacing hunks. Keep the existing bounds-first WMM match condition from stable commit 4dd2d9cf563c5 (upstream a75281626fc8f); applying the older condition would undo its out-of-bounds-read fix. No functional change. Stable-dep-of: 28a289beaf22 ("staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cca153095a18595273f1e91db063f8cea9102d0d Author: Steven Rostedt Date: Thu Sep 10 15:08:54 2026 -0400 ring-buffer: Show persistent buffer dropped events in trace_pipe file [ Upstream commit 8928e4a3be34bf053f9ef1cad67263604bf4f05e ] When the persistent ring buffer is validated on boot up, if a subbuffer is deemed invalid, it resets the buffer and continues. Have the code preserve the RB_MISSED_EVENTS flag in the commit portion of the subbuffer header and pass that back so that the trace_pipe file can show the missed events like the trace file does. For example: <...>-1242 [005] d.... 4429.120116: page_fault_user: address=0x7ffaebb6e728 ip=0x7ffaeb9d4960 error_code=0x7 <...>-1242 [005] ..... 4429.120124: mm_page_alloc: page=00000000055254f3 pfn=0x1373bd order=0 migratetype=1 gfp_flags=GFP_HIGHUSER_MOVABLE|__GFP_COMP <...>-1242 [005] d..2. 4429.120132: tlb_flush: pages:1 reason:local MM shootdown (3) CPU:5 [LOST EVENTS] <...>-1242 [005] d.... 4429.120661: page_fault_user: address=0x55ba7c2d0944 ip=0x55ba7c20cd02 error_code=0x7 <...>-1242 [005] ..... 4429.120669: mm_page_alloc: page=0000000005a02500 pfn=0x12b6e4 order=0 migratetype=1 gfp_flags=GFP_HIGHUSER_MOVABLE|__GFP_COMP <...>-1242 [005] d..2. 4429.120680: tlb_flush: pages:1 reason:local MM shootdown (3) Link: https://patch.msgid.link/20260522171052.156419479@kernel.org Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Backport notes for 6.18: Keep the ring_buffer_read_page() changes needed as context for 6365c44a824f ("ring-buffer: Allow splice reads on static buffers"). Separate the raw commit flags from the page byte count and preserve the lost-events flag when copying page contents. Keep the existing bpage name, rb_page_capacity(reader) bounds and unsigned lost-event count. Read and mask bpage->commit directly instead of adding the newer data-page helpers. Drop the reader-page unknown-loss propagation: this tree lacks the persistent invalid-subbuffer recovery and signed-loss reporting changes that make that path meaningful. Keep the copy loop bounded by the page size, not event_size, avoiding the one-event-per-read regression subsequently fixed by af05b4e06279. Preserve the loss flag when trimming a swapped page to real_end, and combine output flags with bitwise OR so an already-set flag is not added a second time. Stable-dep-of: 6365c44a824f ("ring-buffer: Allow splice reads on static buffers") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 803208a50b042ef4bd61be18b04bb498d55caae0 Author: Rafael J. Wysocki Date: Thu Sep 10 22:30:56 2026 -0400 PM: runtime: Wrapper macros for ACQUIRE()/ACQUIRE_ERR() [ Upstream commit ef8057b07c72a817537856b98d6e7493b9404eaf ] Add wrapper macros for ACQUIRE()/ACQUIRE_ERR() and runtime PM usage counter guards introduced recently: pm_runtime_active_try, pm_runtime_active_auto_try, pm_runtime_active_try_enabled, and pm_runtime_active_auto_try_enabled. The new macros should be more straightforward to use. For example, they can be used for rewriting a piece of code like below: ACQUIRE(pm_runtime_active_try, pm)(dev); if ((ret = ACQUIRE_ERR(pm_runtime_active_try, &pm))) return ret; in the following way: PM_RUNTIME_ACQUIRE(dev, pm); if ((ret = PM_RUNTIME_ACQUIRE_ERR(&pm))) return ret; If the original code does not care about the specific error code returned when attepmting to resume the device: ACQUIRE(pm_runtime_active_try, pm)(dev); if (ACQUIRE_ERR(pm_runtime_active_try, &pm)) return -ENXIO; it may be changed like this: PM_RUNTIME_ACQUIRE(dev, pm); if (PM_RUNTIME_ACQUIRE_ERR(&pm)) return -ENXIO; Link: https://lore.kernel.org/linux-pm/5068916.31r3eYUQgx@rafael.j.wysocki/ Signed-off-by: Rafael J. Wysocki Reviewed-by: Dan Williams Reviewed-by: Dhruva Gole Reviewed-by: Jonathan Cameron Reviewed-by: Frank Li Link: https://patch.msgid.link/3400866.aeNJFYEL58@rafael.j.wysocki Stable-dep-of: d378fceaafd7 ("iio: light: apds9306: fix PM reference leak in apds9306_read_data()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0d4fb4f15e550139b045e1e092d2dbdd1a444a2c Author: Srinivas Pandruvada Date: Wed Sep 9 10:10:40 2026 -0400 platform/x86: ISST: Check for admin capability for write commands [ Upstream commit 69cd1ca440a96c85dcedcddfa5e0af6012f60b8b ] In some SST deployments, administrators want to allow reading SST capabilities for non-root users. This can be achieved by changing file permissions for "/dev/isst_interface", but they still want to prevent any changes to the SST configuration by non-root users. This capability was available before for non-TPMI SST. Extend the same capability for TPMI SST by adding a check for CAP_SYS_ADMIN for all write commands. Signed-off-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260107060729.1634420-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Stable-dep-of: e45d6b847286 ("platform/x86: ISST: Validate max level for set feature") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e94b156e5cad0c5511aa1577313e320b48bd4705 Author: Rafael J. Wysocki Date: Wed Sep 9 10:50:31 2026 -0400 platform/x86: intel_sar: Check ACPI_HANDLE() against NULL [ Upstream commit 2765f16c12af7c2533763e46b8113b727354012d ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_HANDLE() check against NULL to the platform/x86 intel_sar driver. Fixes: dcfbd31ef4bc ("platform/x86: BIOS SAR driver for Intel M.2 Modem") Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/14023870.uLZWGnKmhe@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen For this stable dependency, also convert the existing allocations in parse_package() and sar_probe() to kmalloc_objs() and kzalloc_obj(). Both helpers are already available in this tree and retain the same allocation sizes and GFP_KERNEL flags. This makes intel_sar.c match the parent of 30c906cff490 ("platform/x86: int1092: Fix potential memory leak in sar_probe()"), allowing that target to apply unchanged. No new functions or allocation helpers are introduced. Stable-dep-of: 30c906cff490 ("platform/x86: int1092: Fix potential memory leak in sar_probe()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b07bcdca18fb9437ebc54636db766c44f3f2fc75 Author: Peter Zijlstra Date: Thu Sep 10 12:45:21 2026 -0400 perf/core: Fix deadlock in perf_mmap() failure path [ Upstream commit c69df06e4e26e50611190ce04eab92c5cc261b61 ] Ian noted that commit 77de62ad3de3 ("perf/core: Fix refcount bug and potential UAF in perf_mmap") would cause a deadlock due to event->mmap_mutex recursion. This happens because we're now calling perf_mmap_close() under mmap_mutex, while that function itself can also take mmap_mutex. Solve this by noting that perf_mmap_close() is far more complicated than we need at this particular point, since it deals with scenarios that cannot happen in this particular case. Replace the call to perf_mmap_close() with a very narrow undo for the case of first-exposure. If this is not the first mmap(), there is no race and it is fine to drop the lock and call perf_mmap_close() to handle to more complicated scenarios. Note: move the rb->mmap_user (namespace) handling into the rb init/free code such that it does not complicate the mmap handling. Fixes: 77de62ad3de3 ("perf/core: Fix refcount bug and potential UAF in perf_mmap") Reported-by: Ian Rogers Closes: https://patch.msgid.link/CAP-5%3DfVJyVMZw%3DDqP53Kxg58nUmJ_0bxoaeOKAbC03BVc11HaA%40mail.gmail.com Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260326112821.GK3738786@noisy.programming.kicks-ass.net Stable-dep-of: 58a8108bc73d ("perf: Fix use-after-free when perf mmap() revival races with the last munmap()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1d7be6ff21edca746afd3ff84d382ba8df91cb14 Author: Farhan Ali Date: Wed Sep 9 10:14:33 2026 -0400 PCI: Introduce PCI_SLOT_PLACEHOLDER constant for slot_nr placeholder value [ Upstream commit c243e6c470c4695965cc8287767925bc1d9a7867 ] Introduce a constant for placeholder value and update the kerneldoc for pci_create_slot() to reference PCI_SLOT_PLACEHOLDER instead of -1 throughout. No functional change. Suggested-by: Bjorn Helgaas Signed-off-by: Farhan Ali Signed-off-by: Bjorn Helgaas Cc: Madhavan Srinivasan Cc: Tyrel Datwyler Cc: linuxppc-dev@lists.ozlabs.org Link: https://patch.msgid.link/20260805165518.794-2-alifm@linux.ibm.com Stable backport: this tree predates 102c8b26b54e ("PCI: Allow all bus devices to use the same slot"). Include its PCI_SLOT_ALL_DEVICES definition, slot-number documentation, and core matching/address handling so that subsequent commit dcc5bec09e23 ("PCI: Allow per function PCI slots to fix slot reset on s390") applies without conflicts. Keep the PCIe hotplug callers unchanged; enabling bus-wide slots there is outside this dependency. Retain the stable tree's kzalloc() and ATTRIBUTE_GROUPS() implementations. The placeholder conversion covers both PowerPC hotplug callers and the PCI core. All code changes stay within existing functions. Stable-dep-of: dcc5bec09e23 ("PCI: Allow per function PCI slots to fix slot reset on s390") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b8adb1ffa263c635b1c65ebe1cab98fbdeefcb41 Author: Caleb Sander Mateos Date: Thu Sep 10 15:15:35 2026 -0400 nvme: fold nvme_config_discard() into nvme_update_disk_info() [ Upstream commit 9110b85244f142ca4bcaea27be408c778d3c48d0 ] The choice of what queue limits are set in nvme_update_disk_info() vs. nvme_config_discard() seems a bit arbitrary. A subsequent commit will compute the discard_granularity limit using struct nvme_id_ns, which is only passed to nvme_update_disk_info() currently. So move the logic in nvme_config_discard() to nvme_update_disk_info(). Replace several instances of ns->ctrl in nvme_update_disk_info() with the ctrl variable brought from nvme_config_discard(). Signed-off-by: Caleb Sander Mateos Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Stable-dep-of: 3838e80fcfb3 ("nvme: skip the zoned limits update if the zone info query failed") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2158e178dfc850a974f1a02fc198fa27455913d4 Author: Dragos Tatulea Date: Wed Sep 9 13:32:13 2026 -0400 net/mlx5e: SHAMPO, Always calculate page size [ Upstream commit dff1c3164a69284ac9fedb1c25d4c008139e9fb8 ] Adapt the rx path in SHAMPO mode to calculate page size based on configured page_shift when dealing with payload data. This is necessary as an upcoming patch will add support for using different page sizes. This change has no functional changes. Signed-off-by: Dragos Tatulea Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260223204155.1783580-9-tariqt@nvidia.com Signed-off-by: Paolo Abeni Backport to 6.18: preserve the XDP fragment accounting fix from 7d7342a18fadc ("net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ"). Keep new_nr_frags and the original frag_page endpoint; only replace PAGE_SIZE with page_size in the truesize adjustment. Reintroducing the old frag_page rewind would break page reference accounting for fragments consumed by XDP. Retain the page-size calculations and SHAMPO space-check changes so e2466392a0b8496000e12181cb1ee1535eb0da25 ("net/mlx5e: do not HW-GRO coalesce small frames") applies without modification. No functions are added. Stable-dep-of: e2466392a0b8 ("net/mlx5e: do not HW-GRO coalesce small frames") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 285f7f3a651c7362ba8c5787f2824618c0402b9c Author: Andrea Scian Date: Thu Sep 10 20:41:57 2026 -0400 mtd: rawnand: pl353: Add message about ECC mode [ Upstream commit 1e06dbfdfb851170b243d6498e442b449324c664 ] This just add some information on kernel log about the selected ECC Signed-off-by: Andrea Scian Signed-off-by: Miquel Raynal Stable-dep-of: 80ecacd054ff ("mtd: rawnand: pl353: Make sure we use the monolithic helpers for raw accesses") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7ef12e1dd06e442eebf370f6e53c41bd056d0f22 Author: Adrian Hunter Date: Wed Sep 9 16:50:46 2026 -0400 i3c: master: Fix device_register() error path [ Upstream commit 74be657d98a8d684c0475f3cbd450ef2a30ffc73 ] When device_register() fails in i3c_master_register_new_i3c_devs(), put_device() is called to drop the reference taken by device_register(). That drops the last reference, so the device's release callback i3c_device_release() runs and frees the i3c_device. Two problems follow from that: i3c_device_release() does WARN_ON(i3cdev->desc), so it warns because desc->dev->desc still points back at the descriptor. Clear it before calling put_device(). After put_device() frees the i3c_device, desc->dev is left pointing at freed memory, so clear desc->dev as well. That prevents, for example, i3c_master_unregister_i3c_devs() seeing desc->dev as non-NULL and dereferencing it. Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/linux-i3c/20260701203053.8F3971F000E9@smtp.kernel.org/ Fixes: cab63f6488761 ("i3c: Fix potential refcount leak in i3c_master_register_new_i3c_devs") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260702183644.60827-1-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Stable-dep-of: 456f832e5fc2 ("i3c: master: Fix recursive locking during device registration") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 69d57dbadb27ffd5eef34fd184bab145500cdabc Author: Baineng Shou Date: Thu Sep 10 11:52:33 2026 -0400 dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds [ Upstream commit 30d0aff2c65a277135cfd8ea28fa1ee75e0ea4e0 ] DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/ remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/ Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework") Cc: stable@vger.kernel.org Reviewed-by: T.J. Mercier Acked-by: Christian König Acked-by: Sumit Semwal Signed-off-by: Baineng Shou Link: https://lore.kernel.org/r/20260817050457.1005285-2-shoubaineng@gmail.com Signed-off-by: Christian König Stable adaptation for 6.18: - Resolve the dma-heap conflict without importing the absent mem_accounting module parameter; retain the existing kzalloc() form. - This tree has neither DMA_BUF_TRACE nor trace_dma_buf_fd. Omit the new dma-buf.c function and export, and provide dma_buf_fd_install as a single-evaluation macro around the existing fd_install() in dma-buf.h. This preserves the reserved-fd publication semantics without adding functions or importing the unrelated tracing infrastructure. - Retain the heap allocation and usercopy cleanup changes, and expose the interface needed for the target FastRPC fix to apply unchanged. [ sashal: Reduced backport -- upstream 30d0aff2c65a2 touches 3 file(s), this backport carries 2. Not backported here: drivers/dma-buf/dma-buf.c This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: a4a1a2bfcb29 ("misc: fastrpc: don't publish fd before copy_to_user() succeeds") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9d89ffd9101c83a7e61958dab18a7b2cca1b54cb Author: Takashi Iwai Date: Wed Sep 9 14:55:23 2026 -0400 ALSA: usb-audio: Relax __free() variable declarations [ Upstream commit 03f705b9ca58b91c6dffe64875ea3d9a38cad9b5 ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Note that there are still a few remaining __free(kfree) with NULL initializations; they are because of the code complexity (the data size calculation). Fixes: 43d4940c944c ("ALSA: usb: scarlett2: Clean ups with guard() and __free()") Fixes: 46757a3e7d50 ("ALSA: FCP: Add Focusrite Control Protocol driver") Fixes: f7d306b47a24 ("ALSA: usb-audio: Fix a DMA to stack memory bug") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-12-tiwai@suse.de Stable-dep-of: 4335e3877864 ("ALSA: FCP: do not copy out an uninitialised init response") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 37ac5eb981f42972ae6303f511a44a5d3fe0aa56 Author: Sven Eckelmann Date: Wed Sep 9 20:49:10 2026 +0200 batman-adv: fix TX priority extraction for BATADV_FORW_MCAST commit 7aedb59b80993c912ab45ce24386a2775150962b upstream. batadv_mcast_forw_mode_by_count() pushs the skb->data for BATADV_FORW_MCAST forwarding via batadv_mcast_forw_mcsend(). But the batadv_skb_set_priority() expects the ethernet header directly before (skb->data + offset). With the moved skb->data, just some random data would be accessed to get the priority data. Move the batadv_skb_set_priority() before the decision about the handling multicast packets and potential header modifications. Cc: stable@vger.kernel.org Fixes: 90039133221e ("batman-adv: mcast: implement multicast packet generation") [ Context ] Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit a1a0959b2da034e90967a23bf62c690dcc03afcb Author: SJ Park Date: Wed Sep 9 17:41:53 2026 -0700 mm/damon/sysfs: read ops_id only once in damon_sysfs_apply_inputs() [ Upstream commit 5adaaa28be8a79ddd7e103b171f9d6e14e7fc26e ] damon_sysfs_apply_inputs() reads ops_id twice. It could race with ops_id_store(). As a result, the min_region_sz could wrongly be set up. Read it once. The user impact is trivial. Sane users ain't update the parameter in parallel. Even if it happens, the DAMON core layer handles the wrong min_region_sz (!is_power_of_2()). Even if somehow the race ended up making a min_region_sz that is different from the user's intention but still valid, only monitoring itself runs differently than expected. No critical consequences like kernel panic or memory corruption happen The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-7-sj@kernel.org Link: https://lore.kernel.org/20260703172417.95426-1-sj@kernel.org [1] Fixes: 8d009da32f13 ("mm/damon/sysfs: set damon_ctx->min_sz_region only for paddr use case") Signed-off-by: SJ Park Cc: # 6.18.x Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8bcfa58c4277bff1882a23547c37ab08aa1de12f Author: Sven Eckelmann Date: Wed Sep 9 20:46:17 2026 +0200 batman-adv: bla: avoid CRC corruption due to parallel claim add commit 08645ab95768b88e2ff85a89211994651710465b upstream. batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either * add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone But when the "new" claim code was running in parallel to the "change backbone" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the "new" claim code path: * CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point. * CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc. * CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc The CRC is then wrong for both: * claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs. To avoid this, split the functionality in clear separate parts: * new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back) * update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") [ Context ] Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit a5e4d6cb4f6848b8906c1c493f99a8ccc0638515 Author: Sven Eckelmann Date: Wed Sep 9 20:47:33 2026 +0200 batman-adv: dat: atomically update mac addresses commit e6de568d3eda3e3c01c868fabd7a9535d5ee4a73 upstream. When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 2f1dfbe18507 ("batman-adv: Distributed ARP Table - implement local storage") [ Context ] Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 463743d1d5ef2f336a4f95a39a7120cbbc647c36 Author: Akhmed Zhitaev Date: Wed Sep 9 20:26:35 2026 +0500 drm/amd/display: Scale custom brightness curve from full range [ Upstream commit 6fd83a1c2cdea48c396f600795217fbdfb8124f6 ] Custom brightness curves use an 8-bit input signal. After exporting the full PWM range to userspace, the curve normalizer still divides requests by the physical PWM span. On panels with a nonzero minimum PWM level, this can produce a curve input greater than 255 and send an invalid backlight level to DC. Scale the userspace [0..max] range to the curve's [0..255] range instead. This retains the full advertised range and keeps the reverse readback conversion unchanged. [ Backport note: In 6.18.y the brightness helpers still live in amdgpu_dm.c, while upstream changes the later amdgpu_dm_backlight.c. Apply the same semantic change at the old location; the logic is otherwise unchanged. ] Fixes: 8dbd72cb7900 ("drm/amd/display: Export full brightness range to userspace") Cc: stable@vger.kernel.org Signed-off-by: Akhmed Zhitaev Reviewed-by: Mario Limonciello (AMD) (Move to amdgpu_dm_backlight.c) Link: https://patch.msgid.link/20260813170959.22073-1-zhitaevakh@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7e56deae5a796fd9f70f8c97d5fc6dd1ce523721 Author: Mario Limonciello Date: Wed Sep 9 20:26:34 2026 +0500 drm/amd/display: Fix backlight max_brightness to match exported range [ Upstream commit bd9e2b5b0473c75abc0f4134dfe79ecbfb16610d ] [Why] FWTS autobrightness fails on eDP panels because actual_brightness can read higher than the advertised max_brightness (e.g. 63576 vs 62451). The conversion helpers expose the firmware PWM range to userspace as [0..max]. But max_brightness is advertised as (max - min), which is smaller. So reading the level can return a value above max_brightness. This regressed in commit 4b61b8a39051 ("drm/amd/display: Add debugging message for brightness caps"), which changed max_brightness to (max - min) and undid commit 8dbd72cb7900 ("drm/amd/display: Export full brightness range to userspace"). [How] Advertise max_brightness as max, and scale the initial AC/DC brightness against max too. Update the KUnit expectations to match. [ Backport note: In 6.18.y the backlight property setup still lives in amdgpu_dm.c, so apply the same property changes there. The upstream KUnit file was introduced by a later refactoring and is not present. ] Fixes: 4b61b8a39051 ("drm/amd/display: Add debugging message for brightness caps") Reviewed-by: Alex Hung Signed-off-by: Mario Limonciello Signed-off-by: George Zhang Signed-off-by: Alex Deucher Signed-off-by: Akhmed Zhitaev Signed-off-by: Sasha Levin commit 54a97ef1025236cc1bc54d79c7ae2eb8027ce4b8 Author: Dragos Tatulea Date: Wed Sep 9 14:13:32 2026 +0000 net/mlx5e: xsk: Fix unlocked writing to ICOSQ commit c326f9c68921e2f14dfcecb2f6b4216313d50248 upstream. During napi poll, when the affinity changes and there's still XSK work to be done, we trigger an ICOSQ interrupt on the new CPU. However, this triggering on the ICOSQ is done unprotected. There are 2 such races: A) mlx5e_trigger_irq() is called while mlx5e_xsk_alloc_rx_mpwqe() is running from a different CPU due to affinity change. This can happen because IRQ triggering is done after napi_complete_done(). At this point the NAPI can be scheduled on a different CPU. Like this: CPU A (old affinity, NAPI tail) CPU B (new affinity, fresh NAPI) ------------------------------- -------------------------------- napi_complete_done() clears SCHED mlx5e_cq_arm(...) napi_schedule_prep() sets SCHED mlx5e_napi_poll() mlx5e_xsk_alloc_rx_mpwqe() mlx5e_icosq_sync_lock() // noop memcpy 640 B UMR body advance sq->pc by 10 mlx5e_trigger_irq(&c->icosq) wqe_info[pi] = {NOP, 1} mlx5e_post_nop() advances sq->pc B) mlx5e_trigger_irq() is called on the ICOSQ when mlx5e_trigger_napi_icosq() is running. The obvious fix would be to lock the ICOSQ. But ICOSQ has an optimized locking scheme that doesn't work for this scenario. Kick the async ICOSQ instead which is always locked. This issue was noticed in the wild with the following splat: netdevice: ge-0-0-1: Bad OP in ICOSQ CQE: 0xd WARNING: drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:826 [...] [...] Call Trace: mlx5e_napi_poll+0x11d/0x7f0 [mlx5_core] __napi_poll+0x30/0x200 ? skb_defer_free_flush+0x9c/0xc0 net_rx_action+0x2fe/0x3f0 handle_softirqs+0xd8/0x340 __irq_exit_rcu+0xbc/0xe0 common_interrupt+0x85/0xa0 asm_common_interrupt+0x26/0x40 [...] ---[ end trace 0000000000000000 ]--- mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2022, qn 0x8f4, opcode 0xd, syndrome 0x2, vendor syndrome 0x68 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 68 02 01 00 08 f4 de 14 59 d2 WQE DUMP: WQ size 16384 WQ cur size 0, WQE index 0x1e14, len: 64 00000000: 00 00 00 01 d9 ed 80 02 00 00 00 01 d9 ed 90 02 00000010: 00 00 00 01 d9 ed a0 02 00 00 00 01 d9 ed b0 02 00000020: 00 00 00 01 d9 ed c0 02 00 00 00 01 d9 ed d0 02 00000030: 00 00 00 01 d9 ed e0 02 00 00 00 01 d9 ed f0 02 mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2023, qn 0x8f4, opcode 0xd, syndrome 0x5, vendor syndrome 0xf9 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 f9 05 01 00 08 f4 de 15 cf d2 [ Backport to 6.18.y and older: upstream commit calls mlx5e_trigger_napi_async_icosq(), which was introduced by commit 0da1dba72616 ("net/mlx5e: XSK, Fix unintended ICOSQ change") and is not present here. In these trees mlx5e_trigger_napi_icosq() is the equivalent helper: it takes c->async_icosq_lock and triggers c->async_icosq, which is unconditionally opened, activated, polled and armed for every channel. Race B does not apply, as it concerns the sync-ICOSQ variant of mlx5e_trigger_napi_icosq() that only exists upstream, and mlx5e_icosq_sync_lock() in the race A diagram has no equivalent here. ] Fixes: db05815b36cb ("net/mlx5e: Add XSK zero-copy support") Reported-by: Paul Saab Signed-off-by: Dragos Tatulea Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260513064613.334602-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f2573c2a3326d2d38592e9fe57d4a685e8dc6263 Author: Alexandre Frade Date: Sat Sep 12 18:30:24 2026 +0000 Linux 6.18.51-xanmod1 Signed-off-by: Alexandre Frade commit 71f9c06ccf3618b4cd82d35e6ef8dee5957a5bde Merge: 211a65465dd9 f6388029ea9e Author: Alexandre Frade Date: Sat Sep 12 18:29:29 2026 +0000 Merge tag 'v6.18.51' into 6.18 This is the 6.18.51 stable release commit f6388029ea9e2c9e807d73827658738ea131faee Author: Greg Kroah-Hartman Date: Fri Sep 11 11:49:46 2026 +0200 Linux 6.18.51 Link: https://lore.kernel.org/r/20260909134237.773280130@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Wentao Guan Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Peter Schneider Signed-off-by: Greg Kroah-Hartman commit d83a9de7cecd401c3d3e00ed6371194dcd7313e4 Author: Namjae Jeon Date: Tue Aug 25 09:31:35 2026 +0900 ksmbd: zero pipe read compound padding commit 73f860489e3be2245598d1819226304fc5b87291 upstream. Compound response handling extends the last response iov to an eight-byte boundary. smb2_read_pipe() allocates only the payload size, so the alignment padding can expose up to seven bytes of uninitialized kernel heap memory. Allocate the aligned size and clear the unused tail before pinning the response buffer. Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Reported-by: Cheryl Babcock Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 75640976cf474eb41682a13f2dbe9534ac26ca50 Author: Frank Sorenson Date: Sat Jul 25 21:04:44 2026 +0000 cifs: add fscache_resize_cookie() to cifs_setsize() commit fa724e235cfdb0fb0bb427d0f9dfe864ae27403e upstream. Several code paths update the VFS inode size by calling netfs_resize_file() and cifs_setsize(), but omit the corresponding fscache_resize_cookie() call, leaving the fscache cookie out of sync with the actual file size: - cifs_file_set_size() in inode.c: server-side truncation via setattr - cifs_do_truncate() in file.c: truncates to zero on O_TRUNC open - smb2_duplicate_extents() in smb2ops.c: file clone extending EOF - smb3_simple_falloc() in smb2ops.c: two branches that extend EOF via write-range and SMB2_set_eof respectively Since every caller of cifs_setsize() must resize the fscache cookie, add the call to cifs_setsize() itself, consistent with how truncate_pagecache() is already consolidated there. Fixes: 70431bfd825d ("cifs: Support fscache indexing rewrite") Fixes: 93a43155127f ("cifs: Fix missing set of remote_i_size") Fixes: 110fee6b9bb5 ("smb: client: fix missing timestamp updates with O_TRUNC") Fixes: 7a06d3b816d7 ("smb/client: emulate small EOF-extending mode 0 fallocate ranges") Cc: stable@vger.kernel.org Cc: David Howells Cc: Paulo Alcantara Cc: Huiwen He Signed-off-by: Frank Sorenson Reviewed-by: Paulo Alcantara Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d73f79d1a2c26a8cdf0558d9a0203ee64d9b4f51 Author: Muchun Song Date: Mon May 25 10:52:13 2026 +0800 mm/hugetlb_vmemmap: fix incorrect vmemmap restore in rollback commit c7bde43f6daf70e05a64fbca7efdf6fa93e057dc upstream. vmemmap_restore_pte() rebuilds restored vmemmap pages from a tail-page template derived from compound_head(). This is wrong when the current PTE already maps a page whose contents are not tail-page metadata. In the rollback path of vmemmap_remap_free(), the first restored PTE is backed by vmemmap_head and contains head-page metadata. Reconstructing that page from a tail-page template overwrites the head-page state and corrupts the restored vmemmap page. Fix this by copying the full page from the page currently mapped by the PTE. Also pass vmemmap_tail to the rollback walk so only PTEs backed by the shared tail page are restored, while the head PTE remains mapped to vmemmap_head. Add VM_WARN_ON_ONCE() checks for unexpected cases. Link: https://lore.kernel.org/20260525025213.2229628-1-songmuchun@bytedance.com Fixes: c0b495b91a47 ("mm/hugetlb: refactor code around vmemmap_walk") Signed-off-by: Muchun Song Acked-by: Kiryl Shutsemau Acked-by: Oscar Salvador (SUSE) Cc: David Hildenbrand Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 15803e2276067529faa6bb46eb4d2c67bf053cfd Author: Christian Brauner Date: Wed Dec 24 13:00:24 2025 +0100 pidfs: protect PIDFD_GET_* ioctls() via ifdef commit 75ddaa4ddc86d31edb15e50152adf4ddee77a6ba upstream. We originally protected PIDFD_GET__NAMESPACE ioctls() through ifdefs and recent rework made it possible to drop them. There was an oversight though. When the relevant namespace is turned off ns->ops will be NULL so even though opening a file descriptor is perfectly legitimate it would fail during inode eviction when the file was closed. The simple fix would be to check ns->ops for NULL and continue allow to retrieve namespace fds from pidfds but we don't allow retrieving them when the relevant namespace type is turned off. So keep the simplification but add the ifdefs back in. Link: https://lore.kernel.org/20251222214907.GA189632@quark Link: https://patch.msgid.link/20251224-ununterbrochen-gagen-ea949b83f8f2@brauner Fixes: a71e4f103aed ("pidfs: simplify PIDFD_GET__NAMESPACE ioctls") Tested-by: Brendan Jackman Tested-by: Eric Biggers Reported-by: Eric Biggers Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit ed7380f4621f61e4293c0265d035c0f70f7750e4 Author: Zi Yan Date: Thu Sep 3 14:26:50 2026 -0400 mm/huge_memory: use folio's memcg inside __folio_split() [ Upstream commit c299a2285d9d8bda4da024455de65e3d00de6f17 ] Patch series "Honor XA_FLAGS_ACCOUNT in xas_split_alloc() and charge to folio's memcg", v3. __GFP_ACCOUNT is needed for xarray node allocation accounting when XA_FLAGS_ACCOUNT is set. Commit 7b785645e8f13 ("mm: fix page cache convergence regression") fixed a workingset regression with it. xas_split_alloc() does not have it and needs to be fixed. In addition, based on Sashiko's review[1] and Johannes' confirmation[2], to charge the right memcg, folio's memcg needs to be active during folio split. Add that before adding __GFP_ACCOUNT. There is no workingset convergence regression related to missing __GFP_ACCOUNT in xas_split_alloc() and the impact to userspace should be minor. This patch (of 2): During a pagecache folio split, an xarray node allocation can happen and needs to charge at folio's memcg instead of folio split invoker's memcg, because for example folio split can happen during reclaim and reclaim's active memcg might not be folio's memcg. Switch to folio's memcg at the beginning and switch back afterwards. Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-0-38cb3ff325c5@nvidia.com Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-1-38cb3ff325c5@nvidia.com Link: https://sashiko.dev/#/patchset/20260727-add-gfp_account-to-xas_split_alloc-v1-1-9fae6bf64838%40nvidia.com?part=1 [1] Link: https://lore.kernel.org/all/amtcBZ-_QVRgCd6b@cmpxchg.org/ [2] Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache") Signed-off-by: Zi Yan Suggested-by: Johannes Weiner Reviewed-by: Baolin Wang Acked-by: Lorenzo Stoakes (ARM) Acked-by: Johannes Weiner Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Matthew Wilcox (Oracle) Cc: Ryan Roberts Cc: William Kucharski Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 80656031dfcd4ea8d9fda2913859efde9832edb5 Author: Matthew Wilcox (Oracle) Date: Thu Sep 3 14:26:49 2026 -0400 migrate: replace RMP_ flags with TTU_ flags [ Upstream commit 832d95b5314eea558cf4cc9ca40db10122ce8f63 ] Instead of translating between RMP_ and TTU_ flags, remove the RMP_ flags and just use the TTU_ flag space; there's plenty available. Possibly we should rename these to RMAP_ flags, and maybe even pass them in through rmap_walk_arg, but that can be done later. Link: https://lkml.kernel.org/r/20260109041345.3863089-3-willy@infradead.org Signed-off-by: Matthew Wilcox (Oracle) Acked-by: David Hildenbrand (Red Hat) Reviewed-by: Lorenzo Stoakes Reviewed-by: Zi Yan Cc: Alistair Popple Cc: Byungchul Park Cc: Gregory Price Cc: Jann Horn Cc: Joshua Hahn Cc: Lance Yang Cc: Liam Howlett Cc: Matthew Brost Cc: Rakie Kim Cc: Rik van Riel Cc: Vlastimil Babka Cc: Ying Huang Signed-off-by: Andrew Morton Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e4307837d92cac760519a7048c0ca83a10ed86f3 Author: Zi Yan Date: Thu Sep 3 14:26:48 2026 -0400 mm/huge_memory: replace can_split_folio() with direct refcount calculation [ Upstream commit 5842bcbfc316738cbfcbdb4def5a7592aa03ebf2 ] can_split_folio() is just a refcount comparison, making sure only the split caller holds an extra pin. Open code it with folio_expected_ref_count() != folio_ref_count() - 1. For the extra_pins used by folio_ref_freeze(), add folio_cache_ref_count() to calculate it. Also replace folio_expected_ref_count() with folio_cache_ref_count() used by folio_ref_unfreeze(), since they are returning the same values when a folio is frozen and folio_cache_ref_count() does not have unnecessary folio_mapcount() in its implementation. Link: https://lkml.kernel.org/r/20251126210618.1971206-3-ziy@nvidia.com Signed-off-by: Zi Yan Suggested-by: David Hildenbrand (Red Hat) Reviewed-by: Wei Yang Acked-by: David Hildenbrand (Red Hat) Cc: Balbir Singh Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Signed-off-by: Andrew Morton Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f07c94cd3cc203dcae79311b51bcd4bb4cd04c55 Author: Zi Yan Date: Thu Sep 3 14:26:47 2026 -0400 mm/huge_memory: change folio_split_supported() to folio_check_splittable() [ Upstream commit bdd0d69a32c2aa6437d23e35acc705758b835a75 ] Patch series "Improve folio split related functions", v4. This patchset improves several folio split related functions to avoid future misuse. The changes are: 1. Consolidated folio splittable checks by moving truncated folio check, huge zero folio check, and writeback folio check into folio_split_supported(). Changed the function return type. Renamed it to folio_check_splittable() for clarification. 2. Replaced can_split_folio() with open coded folio_expected_ref_count() and folio_ref_count() and introduced folio_cache_ref_count(). 3. Changed min_order_for_split() to always return an order. 4. Fixed folio split stats counting. Motivation ========== This is based on Wei's observation[1] and solves several potential issues: 1. Dereferencing NULL folio->mapping in try_folio_split_to_order() if it is called on truncated folios. 2. Not handling of negative return value of min_order_for_split() in mm/memory-failure.c There is no bug in the current code. This patch (of 4): folio_split_supported() used in try_folio_split_to_order() requires folio->mapping to be non NULL, but current try_folio_split_to_order() does not check it. There is no issue in the current code, since try_folio_split_to_order() is only used in truncate_inode_partial_folio(), where folio->mapping is not NULL. To prevent future misuse, move folio->mapping NULL check (i.e., folio is truncated) into folio_split_supported(). Since folio->mapping NULL check returns -EBUSY and folio_split_supported() == false means -EINVAL, change folio_split_supported() return type from bool to int and return error numbers accordingly. Rename folio_split_supported() to folio_check_splittable() to match the return type change. While at it, move is_huge_zero_folio() check and folio_test_writeback() check into folio_check_splittable() and add kernel-doc. Remove all warnings inside folio_check_splittable() and give warnings in __folio_split() instead, so that bool warns parameter can be removed. Link: https://lkml.kernel.org/r/20251126210618.1971206-1-ziy@nvidia.com Link: https://lkml.kernel.org/r/20251126210618.1971206-2-ziy@nvidia.com Signed-off-by: Zi Yan Reviewed-by: Wei Yang Acked-by: Balbir Singh Acked-by: David Hildenbrand (Red Hat) Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Signed-off-by: Andrew Morton Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 305f9b6eb8a06a9c0663f69fae65e0c51227dd4a Author: Muchun Song Date: Thu Sep 3 14:26:46 2026 -0400 mm: thp: use folio_batch to handle THP splitting in deferred_split_scan() [ Upstream commit 776bde7caf80f6af72b087cafe7d9f607b14716d ] The maintenance of the folio->_deferred_list is intricate because it's reused in a local list. Here are some peculiarities: 1) When a folio is removed from its split queue and added to a local on-stack list in deferred_split_scan(), the ->split_queue_len isn't updated, leading to an inconsistency between it and the actual number of folios in the split queue. 2) When the folio is split via split_folio() later, it's removed from the local list while holding the split queue lock. At this time, the lock is not needed as it is not protecting anything. 3) To handle the race condition with a third-party freeing or migrating the preceding folio, we must ensure there's always one safe (with raised refcount) folio before by delaying its folio_put(). More details can be found in commit e66f3185fa04 ("mm/thp: fix deferred split queue not partially_mapped"). It's rather tricky. We can use the folio_batch infrastructure to handle this clearly. In this case, ->split_queue_len will be consistent with the real number of folios in the split queue. If list_empty(&folio->_deferred_list) returns false, it's clear the folio must be in its split queue (not in a local list anymore). In the future, we will reparent LRU folios during memcg offline to eliminate dying memory cgroups, which requires reparenting the split queue to its parent first. So this patch prepares for using folio_split_queue_lock_irqsave() as the memcg may change then. Link: https://lkml.kernel.org/r/59cb6b6fb5ffcff9d23b81890b252960139ad8e7.1762762324.git.zhengqi.arch@bytedance.com Signed-off-by: Muchun Song Signed-off-by: Qi Zheng Reviewed-by: Zi Yan Acked-by: David Hildenbrand Acked-by: Shakeel Butt Reviewed-by: Wei Yang Reviewed-by: Harry Yoo Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Hugh Dickins Cc: Johannes Weiner Cc: Lance Yang Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Nico Pache Cc: Roman Gushchin Cc: Ryan Roberts Signed-off-by: Andrew Morton Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0a4a3d7202640d1d0e4dc696322d69a0a3800670 Author: Muchun Song Date: Thu Sep 3 14:26:45 2026 -0400 mm: thp: introduce folio_split_queue_lock and its variants [ Upstream commit ad7c7f4576a5977b4ec4ac5dd090ab3f81ca7c6f ] In future memcg removal, the binding between a folio and a memcg may change, making the split lock within the memcg unstable when held. A new approach is required to reparent the split queue to its parent. This patch starts introducing a unified way to acquire the split lock for future work. It's a code-only refactoring with no functional changes. Link: https://lkml.kernel.org/r/a31a90bcac04dc754f775e87ae3205be3170b571.1762762324.git.zhengqi.arch@bytedance.com Signed-off-by: Muchun Song Signed-off-by: Qi Zheng Acked-by: Johannes Weiner Reviewed-by: Zi Yan Acked-by: Shakeel Butt Acked-by: David Hildenbrand Reviewed-by: Harry Yoo Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Hugh Dickins Cc: Lance Yang Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Nico Pache Cc: Roman Gushchin Cc: Ryan Roberts Cc: Wei Yang Signed-off-by: Andrew Morton Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d913a85cc5f7abe7d41ce37d877f7b2cd6e6ac67 Author: SJ Park Date: Fri Jul 17 17:14:35 2026 -0700 mm/damon/core: initialize damos->last_applied commit af5f76aeb9c9aa9c77d5e1d94e0ee4618c805239 upstream. Patch series "mm/damon: fix uninitialized DAMOS field and kunit exec expectation bugs". Fix a few Sashiko-found unurgent bugs. Patch 1 fixes use of uninitialized damos->last_applied field. Patches 2-7 fix DAMON kunit tests that do invalid memory access under test failures. The bugs are better to be fixed and eventually merged into stable@ kernel. That said, the fixes are arguably not urgent. Patch 1 only introduces negligible DAMOS efficiency degradation in occasional cases. Kunit fixes could introduce quite bad consequences but those are test code that affect only test run setups. This patch (of 7): Multiple DAMON regions could exist across a folio. If they fulfill the condition to apply a DAMOS scheme, the scheme could be applied multiple times to the folio. To avoid this, each DAMOS scheme stores the folio that the scheme was applied to last time in the damos->last_applied field and skips repeatedly applying the same scheme to the same folio. The field is being used without initialization, though. Hence, the mechanism could wrongly skip applying a scheme to a folio at the very first time of DAMOS run. The user impact is trivial. DAMON might unexpectedly skip applying DAMOS action for one folio for the first time per scheme. In the DAMON's best-effort world, this is never a real problem. No critical consequences such as kernel panic or memory corruption happen. It is a clear bug, though, and the fix is straightforward. Fix the issue by initializing the field in DAMOS scheme creation function, damon_new_scheme(). The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-1-sj@kernel.org Link: https://lore.kernel.org/20260718001442.87129-2-sj@kernel.org Link: https://lore.kernel.org/20260714055436.120034-1-sj@kernel.org [1] Fixes: 94ba17adaba0 ("mm/damon: avoid applying DAMOS action to same entity multiple times") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.15.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 05bdb7b867bef9d931d5e9ca6166c75d30d835df Author: SJ Park Date: Fri Jul 17 17:14:38 2026 -0700 mm/damon/core-kunit: handle region split failure in filter_out() commit 3423fe70395210e2f0cd795270292f6a27cd57b5 upstream. damos_test_filter_out() test checks if damos_filter_match() of an address filter splits the region as expected under a given condition. But, the test continued regardless of the split successes. As a result, the later part of the test could dereference invalid pointers that returned from damon_next_region(). Further, it could corrupt memory from damon_destroy_region(). The consequent user impact (memory corruption) is quite bad. The realistic user impact would be limited, though. It would affect only test run setups. Fix it by exiting early for the number of regions test failure. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-5-sj@kernel.org Link: https://lore.kernel.org/20260714142352.100478-1-sj@kernel.org [1] Fixes: 26713c890875 ("mm/damon/core-test: add a unit test for __damos_filter_out()") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.6.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7d4ecfb507f338de5b9c4b54a73f02a00e6a3557 Author: SJ Park Date: Tue Jul 14 20:10:00 2026 -0700 mm/damon/sysfs: read addr_unit only once in damon_sysfs_apply_inputs() commit ab4d9358e32316fa39b5f1f5360292135978c3d9 upstream. damon_sysfs_apply_inputs() reads addr_unit twice. It could race with addr_unit_store(). As a result, the min_region_sz could wrongly be set up. Read it once. The user impact is trivial. Sane users ain't update the parameter in parallel. Even if it happens, the DAMON core layer handles the wrong min_region_sz (!is_power_of_2()). Even if somehow the race ended up making a min_region_sz that is different from the user's intention but still valid, only monitoring itself runs differently than expected. No critical consequences like kernel panic or memory corruption happen. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-6-sj@kernel.org Link: https://lore.kernel.org/20260714142950.100711-1-sj@kernel.org [1] Fixes: 540a2aebc657 ("mm/damon/sysfs: implement addr_unit file under context dir") Signed-off-by: SJ Park Cc: # 6.18.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit cd6d7f45abc825002343801f6b621dc254e07ada Author: SJ Park Date: Sun Jul 12 09:54:30 2026 -0700 mm/damon/core: skip aging from repeated aggressive merging commit 0250dbe08c730d003ef9f484da56ae09a1ea0c4c upstream. The number of DAMON regions could temporarily exceed the user-defined maximum number of regions limit for corner cases. For example, users could lower the limit via runtime parameters update. For such a case, kdamond_merge_regions() repeats merging regions in the case doubling the merge threshold. The repeated merge operation could update the age of regions multiple times. This corrupts the monitoring results. Fix the issue by asking the merge operation to skip aging for the corner case. The user impact is degradation of the monitoring quality. The impact should be mild, since the degradation is only temporal, and it is not common to happen in realistic setups. The issue was discovered [1,2] by Sashiko. Link: https://lore.kernel.org/20260712165432.87609-1-sj@kernel.org Link: https://lore.kernel.org/20260621203548.10718-1-sj@kernel.org [1] Link: https://lore.kernel.org/20260709145425.96247-1-sj@kernel.org [2] Fixes: 310d6c15e910 ("mm/damon/core: merge regions aggressively when max_nr_regions is unmet") Signed-off-by: SJ Park Cc: # 6.10 Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 081ee85b430968fffa449e7213b1bb09dba328a3 Author: SJ Park Date: Sun Jul 19 09:11:33 2026 -0700 mm/damon/ops-common: use nr_accesses moving sum for quota score commit 6c25083f7ae7e2660d766169e5b4d3e96010503f upstream. Since commit 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval"), DAMOS scheme can be applied at any time. At that time, nr_accesses may not be fully aggregated. But the quota prioritization score is calculated using the not fully aggregated count. As a result, the performance of DAMOS could be degraded. Fix by using damon_nr_accesses_mvsum() instead. The user impact of the issue is suboptimum DAMOS performance under certain setups. Nonetheless, the bug was there from the beginning of the setup availability. In other words, the suboptimum performance is the baseline of the setup and hence it didn't cause regression. Also the extent of the suboptimality was not big enough to be found from users and testers. Still, this is a clear bug that is better to be fixed, and can be easily fixed. Link: https://lore.kernel.org/20260719161136.90191-1-sj@kernel.org Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval") Signed-off-by: SJ Park Cc: # 6.7.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit cf94a9043f4a64bae68a14e4ab2e7e16cca03798 Author: SJ Park Date: Tue Jul 14 20:09:59 2026 -0700 mm/damon/paddr: drop last same folio access check reuse optimization commit f23f0aa62b2f32c2b12f95959fc4603ef81678b2 upstream. It can race when multiple kdamonds are being used. The problem from the race is doubtful, but the gain from the optimization is also doubtful. Simply drop the optimization in favor of code simplicity. The user impact is doubtfully trivial. After all, this kind of interference can happen only by intentional user setup. Even if it happens, it will be rare, and the consequence is degradation of the best-effort monitoring results. No critical consequences like kernel panic or memory corruption happen. The race was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-5-sj@kernel.org Link: https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org [1] Fixes: a28397beb55b ("mm/damon: implement primitives for physical address space monitoring") Signed-off-by: SJ Park Cc: # 5.16.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 11e4859ec0d8bbc0cfdd32e189187cfbc1ce4cbf Author: SJ Park Date: Tue Jul 14 20:09:58 2026 -0700 mm/damon/vaddr: drop last same folio access check optimization commit 831846078caa14b7d00b2ccca8b8fe522afe3204 upstream. The optimization can race when multiple kdamonds are running. Meanwhile, the impact of the optimization is quite doubtful. Just remove it. The user impact of the issue should be quite trivial. After all, the race can happen only when the user intentionally setup DAMON in the way. Even if it happens, it would be rare and only degrade the best-effort monitoring results. No critical consequences like kernel panic or memory corruption happen. The race possibility was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-4-sj@kernel.org Link: https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org [1] Fixes: 3f49584b262c ("mm/damon: implement primitives for the virtual memory address spaces") Signed-off-by: SJ Park Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 4c7275444ac65692c6a9c9b3c3367c789f891978 Author: SJ Park Date: Tue Jul 14 20:09:57 2026 -0700 mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of() commit b640708929aa956235866bf7717d89018c661083 upstream. KUNIT_EXPECT_EQ() does not abort the execution of test code when the expectation is not met. But damon_test_merge_regions_of() code after its initial KUNIT_EXPECT_EQ() call assumes the expectation is met. It does a per-region test with a hard-coded number of regions that is correct only if the expectation was met. As a result, __nth_region_of() could return NULL, and the test code can dereference NULL pointers. Fix the issue by catching the expectation failure and skip the per-region tests. The user impact on realistic setups should be negligible, as it is a unit test. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-3-sj@kernel.org Link: https://lore.kernel.org/20260710144937.26981-1-sj@kernel.org [1] Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests") Signed-off-by: SJ Park Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 05dc22d5c4fac2469c0ea23c9bde36aa415cff9f Author: Robin Murphy Date: Wed Sep 9 07:48:02 2026 -0400 iommu/arm-smmu-v3: Add HAFT support for SVA [ Upstream commit f99d3b4bb095c4966cf58154077e8bb69ee4827f ] Since table access flags cannot be software-managed, if process pagetables are using HAFT then SVA must require the SMMU to support and enable it too, otherwise page aging is liable to get out of whack. For unbinding, we can't disable HAFT atomically with HA as might be desired, but luckily we can get away with just not disabling HA either. Cc: stable@vger.kernel.org Fixes: 62df5870ebf7 ("arm64: Enable ARCH_HAS_NONLEAF_PMD_YOUNG") Signed-off-by: Robin Murphy Reviewed-by: Jason Gunthorpe Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c660c017dec1fd7cd88e1103c5ae1aae6ce636bf Author: Fan Wu Date: Wed Sep 9 07:31:01 2026 -0400 power: supply: ab8500_fg: fix use-after-free on remove [ Upstream commit 75b1e88d34254f4fb7753345e21bfee47abddd7f ] ab8500_fg_remove() destroys the driver workqueue while the threaded interrupt handlers are still armed; they are devm-managed and freed only after ->remove() returns, so a handler that fires in that window queues work on the freed workqueue. Tear the workqueue down through devm instead, registering its cleanup after the power supply and before the interrupt requests. devm then frees the interrupts first, so the handlers can no longer queue work, before disabling the delayed and plain work items and destroying the workqueue. Disabling the items, rather than cancelling them, keeps them disabled so no producer (including the power-supply external_power_changed callback) can requeue them. Found by an in-house static analysis tool. Fixes: 13151631b5bd ("ab8500-fg: A8500 fuel gauge driver") Cc: stable@vger.kernel.org # v6.10+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260802020316.417757-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 68916940332d17ee4e36bc0903576da994df1330 Author: Pan Chuang Date: Wed Sep 9 07:31:00 2026 -0400 power: supply: ab8500_fg: Remove redundant dev_err()/dev_err_probe() [ Upstream commit aa5f4decedfb4fc5cd0fe49ab256ad4304d192e4 ] The devm_request_threaded_irq() and devm_request_irq() now automatically log detailed error messages on failure. This eliminates the need for driver-specific dev_err() and dev_err_probe() calls that previously printed generic messages. Signed-off-by: Pan Chuang Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260709033428.362970-7-panchuang@vivo.com Signed-off-by: Sebastian Reichel Stable-dep-of: 75b1e88d3425 ("power: supply: ab8500_fg: fix use-after-free on remove") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 62fb3124bf7405094264302b6c3a5d2b3988ae9a Author: Song Hu Date: Tue Jul 14 07:01:13 2026 -0700 Docs/ABI/damon: fix typo in intervals_goal sysfs path commit 1b492fc82368399123413c937f13da6ed312ee4d upstream. Patch series "Docs/ABI/damon: sysfs ABI document fixes and additions", v2. This series fixes typos and fills in missing entries in the DAMON sysfs ABI document (Documentation/ABI/testing/sysfs-kernel-mm-damon). Patch 1 fixes a path typo, "intrvals_goal" -> "intervals_goal", in four What: entries; the documented path points to a non-existent directory, so it is Cc'ed to stable. Patch 2 fixes two further typos ("WDate:", "manimum"). Patches 3 and 4 add ABI entries that exist in the kernel and are already described in usage.rst but are missing from the canonical ABI document: the 'update_tuned_intervals' state command (patch 3) and the 'tried_regions//probes/

/hits' file (patch 4). This patch (of 4): The ABI document spells the DAMON sysfs directory as "intrvals_goal" (missing 'e') in four What: entries, but the kernel creates it as "intervals_goal" (mm/damon/sysfs.c). Following the documented path therefore yields a non-existent directory. Link: https://lore.kernel.org/20260714140117.94147-1-sj@kernel.org Link: https://lore.kernel.org/20260714140117.94147-2-sj@kernel.org Fixes: e2b23dc62369 ("Docs/ABI/damon: document intervals auto-tuning ABI") Signed-off-by: Song Hu Reviewed-by: SJ Park Signed-off-by: SJ Park Cc: David Hildenbrand Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Jonathan Corbet Cc: Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 1811bd8792ee10193b2d3d9ea7625d7ba7f5cc69 Author: Muchun Song Date: Thu Sep 3 12:59:14 2026 -0400 mm/hugetlb_vmemmap: fix __hugetlb_vmemmap_optimize_folios() [ Upstream commit 6e25c6a9c7eff141ecfc966ecdb7801db2a8810e ] __hugetlb_vmemmap_optimize_folios() uses incorrect arguments when handling bootmem HugeTLB folios. The section number passed to register_page_bootmem_memmap() is derived from the vmemmap virtual address of folio->page instead of the folio PFN, so the bootmem memmap metadata can be registered against the wrong section. The helper is also given HUGETLB_VMEMMAP_RESERVE_SIZE even though it expects a page count, not a size in bytes. In addition, the write-protect range is based on pages_per_huge_page(h), which does not cover the full HugeTLB vmemmap area and can leave part of the shared tail vmemmap mapping writable. Fix the section lookup to use folio_pfn(folio), use HUGETLB_VMEMMAP_RESERVE_PAGES when registering the reserved memmap pages, and use hugetlb_vmemmap_size(h) for the write-protect range. Link: https://lore.kernel.org/20260612035903.2468601-3-songmuchun@bytedance.com Fixes: 752fe17af693 ("mm/hugetlb: add pre-HVO framework") Signed-off-by: Muchun Song Acked-by: Oscar Salvador Reviewed-by: Frank van der Linden Cc: "Aneesh Kumar K.V" Cc: David Hildenbrand Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Mike Rapoport (Microsoft) Cc: Nicholas Piggin Cc: Oscar Salvador (SUSE) Cc: "Ritesh Harjani (IBM)" Cc: Usama Arif Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dba93b8cceb0048071389352fc29dcb0a7fe666f Author: Kiryl Shutsemau Date: Thu Sep 3 12:59:13 2026 -0400 hugetlb: remove VMEMMAP_SYNCHRONIZE_RCU [ Upstream commit 01b1d0ffb6f7f37f466033cf167959946309ed3d ] The VMEMMAP_SYNCHRONIZE_RCU flag triggered synchronize_rcu() calls to prevent a race between HVO remapping and page_ref_add_unless(). The race could occur when a speculative PFN walker tried to modify the refcount on a struct page that was in the process of being remapped to a fake head. With fake heads eliminated, page_ref_add_unless() no longer needs RCU protection. Remove the flag and synchronize_rcu() calls. Link: https://lkml.kernel.org/r/20260227194302.274384-15-kas@kernel.org Signed-off-by: Kiryl Shutsemau Reviewed-by: Muchun Song Reviewed-by: David Hildenbrand (Arm) Cc: Albert Ou Cc: Alexandre Ghiti Cc: Baoquan He Cc: Christoph Lameter Cc: David Rientjes Cc: Frank van der Linden Cc: Harry Yoo Cc: Huacai Chen Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Oscar Salvador Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Roman Gushchin Cc: Usama Arif Cc: Vlastimil Babka Cc: WANG Xuerui Cc: Zi Yan Signed-off-by: Andrew Morton Stable-dep-of: 6e25c6a9c7ef ("mm/hugetlb_vmemmap: fix __hugetlb_vmemmap_optimize_folios()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e4d1300b457e2dc4cca89daa76231487faf9fd35 Author: Kiryl Shutsemau Date: Thu Sep 3 12:59:10 2026 -0400 mm: rework compound_head() for power-of-2 sizeof(struct page) [ Upstream commit 8c846c879e226c312c2c7a7bc1e323779903530f ] For tail pages, the kernel uses the 'compound_info' field to get to the head page. The bit 0 of the field indicates whether the page is a tail page, and if set, the remaining bits represent a pointer to the head page. For cases when size of struct page is power-of-2, change the encoding of compound_info to store a mask that can be applied to the virtual address of the tail page in order to access the head page. It is possible because struct page of the head page is naturally aligned with regards to order of the page. The significant impact of this modification is that all tail pages of the same order will now have identical 'compound_info', regardless of the compound page they are associated with. This paves the way for eliminating fake heads. The HugeTLB Vmemmap Optimization (HVO) creates fake heads and it is only applied when the sizeof(struct page) is power-of-2. Having identical tail pages allows the same page to be mapped into the vmemmap of all pages, maintaining memory savings without fake heads. If sizeof(struct page) is not power-of-2, there is no functional changes. Limit mask usage to HugeTLB vmemmap optimization (HVO) where it makes a difference. The approach with mask would work in the wider set of conditions, but it requires validating that struct pages are naturally aligned for all orders up to the MAX_FOLIO_ORDER, which can be tricky. Link: https://lkml.kernel.org/r/20260227194302.274384-8-kas@kernel.org Signed-off-by: Kiryl Shutsemau Reviewed-by: Muchun Song Reviewed-by: Zi Yan Acked-by: David Hildenbrand (Arm) Acked-by: Usama Arif Reviewed-by: Vlastimil Babka Cc: Albert Ou Cc: Alexandre Ghiti Cc: Baoquan He Cc: Christoph Lameter Cc: David Rientjes Cc: Frank van der Linden Cc: Harry Yoo Cc: Huacai Chen Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Oscar Salvador Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Roman Gushchin Cc: WANG Xuerui Signed-off-by: Andrew Morton [ stable: Drop the original compound_info conversion, which depends on preparatory interface changes absent from this tree and is not needed by the target fix. Move the stable-only HVO static-key increment ahead of the target's context without changing its behavior. ] For tail pages, the kernel uses the 'compound_info' field to get to the head page. The bit 0 of the field indicates whether the page is a tail page, and if set, the remaining bits represent a pointer to the head page. For cases when size of struct page is power-of-2, change the encoding of compound_info to store a mask that can be applied to the virtual address of the tail page in order to access the head page. It is possible because struct page of the head page is naturally aligned with regards to order of the page. The significant impact of this modification is that all tail pages of the same order will now have identical 'compound_info', regardless of the compound page they are associated with. This paves the way for eliminating fake heads. The HugeTLB Vmemmap Optimization (HVO) creates fake heads and it is only applied when the sizeof(struct page) is power-of-2. Having identical tail pages allows the same page to be mapped into the vmemmap of all pages, maintaining memory savings without fake heads. If sizeof(struct page) is not power-of-2, there is no functional changes. Limit mask usage to HugeTLB vmemmap optimization (HVO) where it makes a difference. The approach with mask would work in the wider set of conditions, but it requires validating that struct pages are naturally aligned for all orders up to the MAX_FOLIO_ORDER, which can be tricky. [ sashal: Reduced backport -- upstream 8c846c879e226 touches 3 file(s), this backport carries 1. Not backported here: include/linux/page-flags.h mm/slab.h mm/util.c This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 6e25c6a9c7ef ("mm/hugetlb_vmemmap: fix __hugetlb_vmemmap_optimize_folios()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5cec3e60e9f2d1324179df3aa91656f90095cf8f Author: Sergey Senozhatsky Date: Fri Sep 4 16:32:11 2026 -0400 zram: set default primary compressor in zram_destroy_comps() [ Upstream commit dde75313eed0b014c437f48dd75c0308b592cbf9 ] Patch series "zram: fix zram issues reported by sashiko". Sashiko drove by and reported [1] a couple of zram issues: a possible BUG_ON() in zlib code due to missing winbits range validation and one possible NULL-ptr dereference in zcomp. Both are low risk yet still worth fixing. This patch (of 2): zram_destroy_comps() resets all compressors and leaves them set to NULL, including the primary one, which is invalid device state, as now comp_algorithm_show()->strcmp() can be called on a NULL compressor. Set default primary compressor in zram_destroy_comps(). Link: https://lore.kernel.org/20260729045745.775973-2-senozhatsky@chromium.org Fixes: 486fd58af7ac ("zram: don't free statically defined names") Link: https://sashiko.dev/#/patchset/20260728092935.31139-1-haoqinhuang7@gmail.com [1] Signed-off-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Haoqin Huang Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fb0e9ecffae59d5479f26500972eea87160d32a9 Author: Yuwen Chen Date: Fri Sep 4 16:32:10 2026 -0400 zram: fix the issue that the write - back limits might overflow [ Upstream commit 04d31610a7221cca624646241b1f6b3edd6c99fd ] When the page size exceeds 4KB, if bd_wb_limit is set to a value that is not aligned with the page size, it will cause a numerical wrap-around issue for bd_wb_limit. For example, when the page size is set to 16KB and bd_wb_limit is set to 3, after one write-back operation, the value of bd_wb_limit will become -1. More seriously, since bd_wb_limit is an unsigned number, its value may become as large as 2^64 - 1. The core reason for this problem is that the unit of bd_wb_limit is 4KB. For example, when a write-back occurs on a system with a page size of 16KB, 4 needs to be subtracted from bd_wb_limit. This operation takes place in the zram_account_writeback_submit function. This patch fixes the issue by limiting bd_wb_limit to be an integer multiple of PAGE_SIZE / 4096. Link: https://lkml.kernel.org/r/tencent_5936CFE72BAB2BA76887BB69DCC1B5E67C05@qq.com Fixes: 1d69a3f8ae77 ("zram: idle writeback fixes and cleanup") Signed-off-by: Yuwen Chen Acked-by: Sergey Senozhatsky Cc: Brian Geffon Cc: Minchan Kim Cc: Richard Chang Signed-off-by: Andrew Morton Stable-dep-of: dde75313eed0 ("zram: set default primary compressor in zram_destroy_comps()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9a78de3befad667bf8ef7318dec319493549e2c6 Author: Sergey Senozhatsky Date: Fri Sep 4 16:32:09 2026 -0400 zram: read slot block idx under slot lock [ Upstream commit 1b1a4e4d6797a57fefa40569fc920ce573bbf75b ] Read slot's block id under slot-lock. We release the slot-lock for bdev read so, technically, slot still can get freed in the meantime, but at least we will read bdev block (page) that holds previous know slot data, not from slot->handle bdev block, which can be anything at that point. Link: https://lkml.kernel.org/r/20251122074029.3948921-7-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Cc: Brian Geffon Cc: Minchan Kim Cc: Richard Chang Cc: Yuwen Chen Signed-off-by: Andrew Morton Stable-dep-of: dde75313eed0 ("zram: set default primary compressor in zram_destroy_comps()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fcd467124b19fd355b3752c87f0ff7e99c04645e Author: Sergey Senozhatsky Date: Fri Sep 4 16:32:08 2026 -0400 zram: drop wb_limit_lock [ Upstream commit a4f506c569e1320c2db4a32955e47961fcf02b05 ] We don't need wb_limit_lock. Writeback limit setters take an exclusive write zram init_lock, while wb_limit modifications happen only from a single task and under zram read init_lock. No concurrent wb_limit modifications are possible (we permit only one post-processing task at a time). Add lockdep assertions to wb_limit mutators. While at it, fixup coding styles. Link: https://lkml.kernel.org/r/20251122074029.3948921-5-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Reviewed-by: Brian Geffon Cc: Minchan Kim Cc: Richard Chang Cc: Yuwen Chen Signed-off-by: Andrew Morton Stable-dep-of: dde75313eed0 ("zram: set default primary compressor in zram_destroy_comps()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d1743ec2dd2c8a3a701277fab82492c67a48f3d5 Author: Sergey Senozhatsky Date: Fri Sep 4 16:32:07 2026 -0400 zram: take write lock in wb limit store handlers [ Upstream commit 7c929664fddfdaaa4afe5ae833d0f3044709d95c ] Write device attrs handlers should take write zram init_lock. While at it, fixup coding styles. Link: https://lkml.kernel.org/r/20251122074029.3948921-4-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Reviewed-by: Brian Geffon Cc: Minchan Kim Cc: Richard Chang Cc: Yuwen Chen Signed-off-by: Andrew Morton Stable-dep-of: dde75313eed0 ("zram: set default primary compressor in zram_destroy_comps()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e7dbcb7a561a21e9a8f5b5fa90bb95aefbd0739d Author: Longlong Xia Date: Fri Sep 4 11:58:52 2026 -0400 zram: fix out-of-bounds access in read_block_state() [ Upstream commit 391f057f44a51cc9418da5cba78b014324174264 ] read_block_state() calculates nr_pages before taking dev_lock. If the device is reset and reinitialized with a smaller disksize before lock acquisition, nr_pages still describes the old table. The subsequent loop can then call slot_lock() past the end of the newly allocated table. Read disksize after acquiring dev_lock and checking that the device is initialized. The read lock then keeps the table and its bound stable for the duration of the scan. Link: https://lore.kernel.org/20260804065919.3970386-3-xialonglong2025@163.com Fixes: c0265342bff4 ("zram: introduce zram memory tracking") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Longlong Xia Reviewed-by: Sergey Senozhatsky Cc: Jens Axboe Cc: Minchan Kim Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 878edb39ecf481b76f3e51ab533ff2c4a8332b74 Author: Sergey Senozhatsky Date: Fri Sep 4 11:58:51 2026 -0400 zram: fixup read_block_state() [ Upstream commit 8b05d2d8af817c6a1e23032df51e7ad83030d543 ] ac_time is now in seconds, do not use ktime_to_timespec64() [akpm@linux-foundation.org: remove now-unused local `ts'] [akpm@linux-foundation.org: fix build] Link: https://lkml.kernel.org/r/20260115033031.3818977-1-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Reported-by: Chris Mason Closes: https://lkml.kernel.org/r/20260114124522.1326519-1-clm@meta.com Cc: Brian Geffon Cc: David Stevens Cc: Minchan Kim Cc: Richard Chang Signed-off-by: Andrew Morton [ Stable tree note: The ac_time conversion described above is not present here, so retain the ktime_t conversion and microsecond output. Move the timespec64 temporary into the scan loop instead, allowing the follow-up bounds fix to move nr_pages initialization under init_lock cleanly. ] Stable-dep-of: 391f057f44a5 ("zram: fix out-of-bounds access in read_block_state()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 83dd59ac1c3455c2c7d8ddb582d980a13199b9b3 Author: Chuck Lever Date: Mon Sep 7 18:59:27 2026 -0400 NFSD: Prevent client use-after-free during close_lru reaping [ Upstream commit 2330b788d732f43668b965b3105b37ceb276dfea ] An nfs4_openowner left on nn->close_lru after its final CLOSE keeps its last closed stateid in oo_last_closed_stid, holding only a raw pointer to its nfs4_client. The laundromat reaps timed-out entries, drops nn->client_lock, and calls nfs4_put_stid(), which dereferences the client through cl_lock. Nothing pins the client across that window, so a concurrent force_expire_client() can free it and nfs4_put_stid() reads freed memory. __destroy_client() hits the same race, walking clp->cl_openowners without cl_lock. Pin the client with cl_rpc_users before dropping client_lock, and skip clients already expiring. __destroy_client() then cleans up its own close_lru entries through release_last_closed_stateid(), so teardown no longer races the laundromat. Fixes: 217526e7ecc9 ("nfsd: protect the close_lru list and oo_last_closed_stid with client_lock") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-8-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cd489b03587378645fe0d20142a33f1ed60bac98 Author: Chuck Lever Date: Mon Sep 7 18:46:03 2026 -0400 NFSD: Prevent client use-after-free during blocked-lock reaping [ Upstream commit 9026932ac8be4d0ae01db47f23619a98cc57b671 ] A bare lock owner -- its only remaining reference a blocked lock on nn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but no reference keeping the client alive. When the per-net laundromat reaps such a lock, freeing the nbl drops the owner reference held through flc_owner, and the final nfs4_put_stateowner() takes the client's cl_lock. Because the laundromat detaches the nbl first, __destroy_client() no longer finds it, so a concurrent force_expire_client() can free the client before nfs4_put_stateowner() runs, dereferencing cl_lock in freed memory. Pin the client with cl_rpc_users before dropping nn->blocked_locks_lock, and skip clients already expiring, whose blocked locks __destroy_client() frees while holding an owner reference. Take nn->client_lock outside nn->blocked_locks_lock. Every other site holds nn->blocked_locks_lock as a leaf, acquiring no further lock, so placing nn->client_lock outside it cannot form a lock-order cycle. Fixes: 7919d0a27f1e ("nfsd: add a LRU list for blocked locks") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-7-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7f1abc50ce2537050a62acfabd07de14e49f63a9 Author: Chuck Lever Date: Mon Sep 7 18:46:02 2026 -0400 NFSD: Consolidate the revocation-path client unpin [ Upstream commit 3308cf3f11ed23c79f9f3f90b34bbbad3e3a6ea9 ] The client use-after-free fixes in the state-revocation paths left four open-coded copies of one idiom: drop a cl_rpc_users pin without renewing the client's lease, waking force_expire_client() when the last pin drops on a client it is tearing down. The accompanying "do not renew" rationale was documented at only one of the four sites. put_client_renew_locked() and put_client_renew() already carry the same pin-drop logic, but they renew a non-expired client's lease and so would resurrect the client whose state is being revoked. Factor the common pin-drop into __put_client_locked(), parameterized by whether to renew. The renew helpers pass true; the new put_client_no_renew_locked() and put_client_no_renew() pass false and carry the revocation paths, which must not revive the client they are tearing down. No change in behavior. Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-6-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Stable-dep-of: 9026932ac8be ("NFSD: Prevent client use-after-free during blocked-lock reaping") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3be89e8039a85fa3b6cd5f9dcc4c1459eb356c2d Author: Bryam Vargas Date: Mon Sep 7 11:14:49 2026 -0400 smb: client: reject a tree connect response whose byte count is too small [ Upstream commit 65deb18359341141d37dc86fc7853511be3c87a7 ] CIFSTCon() bounds its strnlen() over the byte area with the server's ByteCount minus two, which for ByteCount 0 or 1 goes negative as an int and converts to a huge size_t. The later subtraction wraps the __u16 bytes_left, and that is what bounds cifs_strndup_from_utf16(): a bound of up to 65535 against a ~16 KB cifs_req_poolp object runs off the end of the slab object, and the bytes reach userspace through tcon->nativeFileSystem in /proc/fs/cifs/DebugData. Reject a byte area too small for what the parser consumes. Two bytes is the least it can consume, and no conformant response carries fewer. The new trace point is the 129th smb_eio_trace entry, which __mode(byte) cannot represent, so the attribute goes with it. Fixes: cc20c031bb06 ("cifs: convert CIFSTCon to use new unicode helper functions") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b7e74bccf58879fdfb6eb787c26551a55f1690f6 Author: David Howells Date: Mon Sep 7 11:14:46 2026 -0400 cifs: Do some preparation prior to organising the function declarations [ Upstream commit 32a60868093aed5ccaa5e57f3b57f791f22ac133 ] Make some preparatory cleanups prior to running a script to organise the function declarations within the fs/smb/client/ headers. These include: (1) Remove "inline" from the dummy cifs_proc_init/clean() functions as they are in a .c file. (2) Move should_compress()'s kdoc comment to the .c file and remove kdoc markers from the comments. (3) Rename CIFS_ALLOW_INSECURE_LEGACY in #endif comments to have CONFIG_ on the front to allow the script to recognise it. (4) Don't let comments have bare words at the left margin as that confused the simplistic function detection code in the script. (5) Adjust some argument lists so that when and if the cleanup script is run they don't end up over 100 chars. (6) Fix a few comments to have missing '*' added or the "*/" moved to their own lines so that checkpatch doesn't moan over the cleanup script patch. (7) Move struct cifs_calc_sig_ctx to cifsglob.h. (8) Remove some __KERNEL__ conditionals. Signed-off-by: David Howells Reviewed-by: Paulo Alcantara (Red Hat) cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French Stable-dep-of: 65deb1835934 ("smb: client: reject a tree connect response whose byte count is too small") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 672cf86aa6aa0fb4012ce4c3b3498df42ad67a4e Author: Frank Sorenson Date: Mon Sep 7 07:47:27 2026 -0400 smb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2() [ Upstream commit 6343c1da561962688f203362d80d6a3bfa39fa1b ] coalesce_t2() computes data pointers directly from server-supplied DataOffset fields with no validation against buffer bounds: data_area_of_tgt = (char *)&pSMBt->hdr.Protocol + get_unaligned_le16(&pSMBt->t2_rsp.DataOffset); data_area_of_src = (char *)&pSMBs->hdr.Protocol + get_unaligned_le16(&pSMBs->t2_rsp.DataOffset); data_area_of_tgt += total_in_tgt; ... memcpy(data_area_of_tgt, data_area_of_src, total_in_src); A small DataOffset can push a pointer below the actual byte area, overwriting header fields; a large one can push it past the buffer end, causing out-of-bounds heap reads (source) or writes (target). The BCC overflow guard does not prevent this: BCC reflects how much data is present, while DataOffset controls where in the buffer it starts. The "validate target area" comment present since the function was first written in 2005 was a placeholder that was never implemented. Add lower- and upper-bound checks for both data pointers before the memcpy, and before any target header fields are modified. Fixes: e4eb295d38b5 ("[PATCH] cifs: Handle multiple response transact2 part 1 of 2") Cc: stable@vger.kernel.org Reported-by: Shen Yongchao Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9eed72e9534b10a6d9f8f5146feff3db53aebdba Author: Frank Sorenson Date: Mon Sep 7 07:47:14 2026 -0400 smb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2 [ Upstream commit 730d0bb19507b9e19c2fe5343109ac618e2fbce5 ] When a valid primary TRANSACT2 response has been received (mid->resp_buf set, mid->multiRsp true) and a subsequent secondary response causes cifs_check_trans2() to return false -- either because the SMB header is invalid (malformed != 0) or because check2ndT2() rejects the PDU -- handle_mid() overwrites mid->resp_buf with the new buffer (leaking the primary buffer) and, because mid->multiRsp is set, skips the server->smallbuf/bigbuf NULL-out. When the user thread frees mid->resp_buf, server->smallbuf or server->bigbuf is left dangling; the demux thread reuses it for the next packet, resulting in a use-after-free. Combine both early-exit conditions and, when mid->multiRsp is already set, abort the pending transaction inline: set multiEnd, call dequeue_mid() with malformed=true, and return true so handle_mid() exits without touching mid->resp_buf or the server buffer pointers. Fixes: 316cf94a910f ("CIFS: Move trans2 processing to ops struct") Cc: stable@vger.kernel.org # cifs_check_trans2() is in smb1ops.c on kernels < 7.0 Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara [ changed dequeue_mid(server, mid, true) to the older dequeue_mid(mid, true) API ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 31307a05ed827fcabfcf8941b33269bf1b1f8bd6 Author: David Howells Date: Mon Sep 7 07:47:13 2026 -0400 cifs: SMB1 split: Separate out SMB1 decls into smb1proto.h [ Upstream commit 645427b7a6c59e0074df29bf939aec2e9d6f2819 ] Separate out SMB1 declarations scriptedly into smb1proto.h. Script below: #!/usr/bin/perl -w use strict; unless (@ARGV) { die "Usage: $0 [ ...]\n"; } # Data tracking my %funcs = (); # Func name => { func prototype } my %headers = (); # Header filename => { header content } my %c_files = (); # C filename => { ordered func list, header pref } my %cmarkers = (); # C filename marker => { header filename it's in } # Parse state my $pathname = "-"; my $lineno = 0; sub error(@) { print STDERR $pathname, ":", $lineno, ": ", @_, "\n"; exit(1); } sub pad($) { # Reindent the function arguments to line the arguments up with the char # after the opening bracket on the func argument list my ($lines) = @_; return $lines if ($#{$lines} <= 0); my $has_empty = 0; for (my $i = 0; $i <= $#{$lines}; $i++) { $lines->[$i] =~ s/^[ \t]+//; $has_empty = 1 if ($lines->[$i] eq ""); } if ($has_empty) { my @clean = grep /.+/, @{$lines}; $lines = \@clean; } my $indlen = index($lines->[0], "("); return $lines if ($indlen < 0); my $indent = ""; $indlen++; $indent .= "\t" x ($indlen / 8); $indent .= " " x ($indlen % 8); my @padded = (); my $acc = ""; my $len = -$indlen; for (my $i = 0; $i <= $#{$lines}; $i++) { my $argument = $lines->[$i]; my $arglen = length($argument); my $last = ($i == $#{$lines} ? 1 : 0); if ($i == 0 || $i == 1) { $acc .= $argument; $acc .= ";" if ($last); $len += $arglen + $last; next; } if (!$acc) { $acc = $indent . $argument; $acc .= ";" if ($last); $len += $arglen + $last; next; } if ($indlen + $len + 1 + $arglen + $last > 79) { push @padded, $acc; $acc = $indent . $argument; $acc .= ";" if ($last); $len = $arglen + $last; next; } $acc .= " " . $argument; $acc .= ";" if ($last); $len += 1 + $arglen + $last; } push @padded, $acc if ($acc); return \@padded; } sub earliest(@) { my $ret = -1; foreach (@_) { $ret = $_ if ($ret < 0 || ($_ >= 0 && $_ < $ret)); } return $ret; } foreach my $file (@ARGV) { # Open the file for reading. next if $file =~ /trace[.]h$/; next if $file =~ /smbdirect[.][ch]$/; open my $fh, "<$file" or die "Could not open file '$file'"; $pathname = $file; $lineno = 0; my $filename; my @file_content = (); my @copy = (); my $state = 0; my $qual = ""; my $type = ""; my $funcname = ""; my @funcdef = (); my $bracket = 0; my $comment = 0; my $smb1 = 0; my $header = 0; my $inline = 0; my $file_marker = ""; my $config = ""; my $c_file = 0; $filename = $pathname; $filename =~ s!.*/!!; if ($file =~ m!.h$!) { my %new_h_file = ( path => $pathname, fname => $filename, content => [], ); $header = \%new_h_file; $headers{$filename} = \%new_h_file; } elsif ($file =~ m!.c$!) { my %new_c_file = ( path => $pathname, fname => $filename, funcs => [], ); $c_file = \%new_c_file; $c_files{$filename} = \%new_c_file; } else { warn("Ignoring unexpected file $file\n"); next; } $smb1 = 1 if ($file =~ m!/smb1ops.c|/cifssmb.c|/cifstransport.c!); foreach my $line (<$fh>) { $lineno++; chomp($line); push @copy, $line; if (!$line) { # Blank line push @file_content, @copy; @copy = (); next; } # Handle continuation or end of block comment. Look for C file # prototype insertion point markers. if ($comment) { if ($line =~ m![*]/!) { if ($comment == 2 && $file_marker) { $cmarkers{$file_marker} = $file_marker; push @copy, "#C_MARKER " . $file_marker; $file_marker = 0; } $comment = 0; } else { $comment++; if ($comment == 2 && $line =~ m! [*] ([a-z][a-z_0-9]*[.][c])$!) { $file_marker = $1; print("Found file marker ", $file_marker, " in ", $filename, "\n"); } } push @file_content, @copy; @copy = (); next; } # Check cpp directives, particularly looking for SMB1 bits if ($line =~ /^[#]/) { if ($header) { if ($line =~ /ifdef.*(CONFIG_[A-Z0-9_])/) { error("multiconfig") if $config; $config = $1; $smb1++ if ($config eq "CONFIG_CIFS_ALLOW_INSECURE_LEGACY"); } elsif ($line =~ /endif/) { $smb1-- if ($config eq "CONFIG_CIFS_ALLOW_INSECURE_LEGACY"); $config = ""; } } push @file_content, @copy; @copy = (); next; } # Exclude interference in finding func names and return types if ($line =~ /^[{]/ || $line =~ /##/ || $line =~ /^[_a-z0-9A-Z]+:$/ || # goto label $line =~ /^do [{]/ || $line =~ m!^//!) { push @file_content, @copy; @copy = (); next; } # Start of a block comment if ($line =~ m!^/[*]!) { $comment = 1 unless ($line =~ m![*]/!); push @file_content, @copy; @copy = (); next; } # End of a braced section, such as a function implementation if ($line =~ /^[}]/) { $type = ""; $qual = ""; $funcname = ""; @funcdef = (); push @file_content, @copy; @copy = (); next; } if ($line =~ /^typedef/) { $type = ""; $qual = ""; $funcname = ""; @funcdef = (); push @file_content, @copy; @copy = (); next; } # Extract function qualifiers. There may be multiple of these in more # or less any order. Some of them cause the func to be skipped (e.g. inline). if ($line =~ /^(static|extern|inline|noinline|noinline_for_stack|__always_inline)\W/ || $line =~ /^(static|extern|inline|noinline|noinline_for_stack|__always_inline)$/) { error("Unexpected qualifier '$1'") if ($state != 0); while ($line =~ /^(static|extern|inline|noinline|noinline_for_stack|__always_inline)\W/ || $line =~ /^(static|extern|inline|noinline|noinline_for_stack|__always_inline)$/) { $qual .= " " if ($qual); $qual .= $1; $inline = 1 if ($1 eq "inline"); $inline = 1 if ($1 eq "__always_inline"); $line = substr($line, length($1)); $line =~ s/^\s+//; } } if ($state == 0) { # Extract what we assume to be the return type if ($line =~ /^\s/) { push @file_content, @copy; @copy = (); next; } while ($line =~ /^(unsigned|signed|bool|char|short|int|long|void|const|volatile|(struct|union|enum)\s+[_a-zA-Z][_a-zA-Z0-9]*|[*]|__init|__exit|__le16|__le32|__le64|__be16|__be32|__be64)/) { $type .= " " if $type; $type .= $1; $line = substr($line, length($1)); $line =~ s/^\s+//; } if ($line =~ /^struct [{]/) { # Ignore structure definitions $type = ""; $qual = ""; $funcname = ""; @funcdef = (); push @file_content, @copy; @copy = (); next; } if (index($line, "=") >= 0) { # Ignore assignments $type = ""; $qual = ""; $funcname = ""; @funcdef = ""; push @file_content, @copy; @copy = (); next; } # Try and extract a function's type and name while ($line =~ /(^[_a-zA-Z][_a-zA-Z0-9]*)/) { my $name = $1; $line = substr($line, length($name)); next if ($line =~ /^[{]/); $line =~ s/^\s+//; my $ch = substr($line, 0, 1); last if ($ch eq "[" || $ch eq ";"); # Global variables if ($ch eq "(") { # Found the function name $state = 1; $line = substr($line, 1); $funcname = $name; my $tmp = $qual . $type . " " . $funcname . "("; $tmp =~ s/[*] /*/; push @funcdef, $tmp; $bracket = 1; last; } if ($type) { last if (index($line, ";") >= 0 && index($line, "(") == -1); error("Unexpected name '$name' after '$type'"); } $type .= " " if $type; $type .= $name; if ($line =~ /^(\s*[*]+)/) { my $ptr = $1; $type .= $ptr; $line = substr($line, length($ptr)); } } } # Try and extract a function's argument list my $from = 0; if ($state == 1) { while (1) { my $o = index($line, "(", $from); my $c = index($line, ")", $from); my $m = index($line, ",", $from); my $b = earliest($o, $c, $m); if ($b < 0) { push @funcdef, $line unless ($line eq ""); last; } my $ch = substr($line, $b, 1); # Push the arguments separately on to the list if ($ch eq ",") { push @funcdef, substr($line, 0, $b + 1); $line = substr($line, $b + 1); $from = 0; } elsif ($ch eq "(") { # Handle brackets in the argument list (e.g. function # pointers) $bracket++; $from = $b + 1; } elsif ($ch eq ")") { $bracket--; if ($bracket == 0) { push @funcdef, substr($line, 0, $b + 1); $line = substr($line, $b + 1); $state = 2; last; } $from = $b + 1; } } } if ($state == 2) { $inline = 1 if ($qual =~ /inline/); #print("QUAL $qual $type $funcname $inline ", $#funcdef, "\n"); if (!$header && $qual !~ /static/ && $funcname ne "__acquires" && $funcname ne "__releases" && $funcname ne "module_init" && $funcname ne "module_exit" && $funcname ne "module_param" && $funcname ne "module_param_call" && $funcname ne "PROC_FILE_DEFINE" && $funcname !~ /MODULE_/ && $funcname !~ /DEFINE_/) { # Okay, we appear to have a function implementation my $func; my $dup = 0; if (exists($funcs{$funcname})) { $func = $funcs{$funcname}; if (exists $func->{body}) { print("dup $funcname\n"); $dup = 1; } } else { my %new_func = ( name => $funcname, cond => "", legacy => 0, ); $func = \%new_func; $funcs{$funcname} = $func; $func->{body} = pad(\@funcdef); } $func->{body} = pad(\@funcdef); $func->{legacy} = 1 if $smb1; if ($funcname eq "cifs_inval_name_dfs_link_error") { $func->{cond} = "#ifdef CONFIG_CIFS_DFS_UPCALL"; } elsif ($funcname eq "cifs_listxattr") { $func->{cond} = "#ifdef CONFIG_CIFS_XATTR"; } push @{$c_file->{funcs}}, $func unless $dup; } elsif (!$header || $inline) { # Ignore inline function implementations and other weirdies push @file_content, @copy; } elsif ($header && !$inline) { push @file_content, "#FUNCPROTO " . $funcname; my $func; if (exists($funcs{$funcname})) { $func = $funcs{$funcname}; $func->{lineno} = $lineno; $func->{pathname} = $pathname; } else { my %new_func = ( name => $funcname, cond => "", lineno => $lineno, pathname => $pathname, legacy => 0, ); $func = \%new_func; $funcs{$funcname} = $func; } $func->{legacy} = 1 if $smb1; } @funcdef = (); $type = ""; $qual = ""; $funcname = ""; $inline = 0; $state = 0; @copy = (); } if ($line =~ /;/) { $type = ""; $qual = ""; $funcname = ""; @funcdef = (); $state = 0; push @file_content, @copy; @copy = (); } } close($fh); if ($header) { $header->{content} = \@file_content; } } sub write_header($) { my ($header) = @_; my $path = $header->{path}; my $legacy = 0; $legacy = 1 if ($path =~ m!smb1proto[.]h!); my @output = (); foreach my $line (@{$header->{content}}) { if ($line =~ "^[#]C_MARKER (.*)") { my $file_marker = $cmarkers{$1}; my $c_file = $c_files{$file_marker}; print("Found $line\n"); foreach my $func (@{$c_file->{funcs}}) { print("func ", $func->{name}, "\n"); push @output, @{$func->{body}}; } next; } elsif ($line =~ "^[#]FUNCPROTO ([_a-zA-Z0-9]+)") { my $funcname = $1; my $func = $funcs{$funcname}; if (!$func->{body}) { print($func->{pathname}, ":", $func->{lineno}, ": '", $funcname, "' dead prototype\n"); next; } if ($func->{legacy} == $legacy) { #push @output, $line; push @output, @{$func->{body}}; } } else { push @output, $line; } } open my $fh, ">$path" or die "Could not open file '$path' for writing"; foreach my $f (@output) { print($fh $f, "\n") or die $path; } close($fh) or die $path; } foreach my $h (keys(%headers)) { write_header($headers{$h}); } Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya Signed-off-by: Steve French [ sashal: Reduced backport -- upstream 645427b7a6c59 touches 3 file(s), this backport carries 3. Not backported here: fs/smb/client/cifsproto.h fs/smb/client/fscache.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 730d0bb19507 ("smb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6493277a52b2446fe318d2aa794bbcd8d6c5aed4 Author: David Howells Date: Mon Sep 7 07:47:12 2026 -0400 cifs: SMB1 split: Create smb1proto.h for SMB1 declarations [ Upstream commit 86c666506ea2c42649879eeac7f29e7bedef2f23 ] Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya Signed-off-by: Steve French Stable-dep-of: 730d0bb19507 ("smb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e7779c9f7e7f991777a06d4a52b77054b4a95776 Author: David Howells Date: Mon Sep 7 07:47:10 2026 -0400 cifs: Remove dead function prototypes [ Upstream commit 9146c7e53fa8e5024e0f61d67129afd45a179a3b ] Remove a bunch of dead function prototypes. Signed-off-by: David Howells cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Stable-dep-of: 730d0bb19507 ("smb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b10015807e4c628095d1d1d1c9307efc8cdd9e1b Author: Jiangshan Yi Date: Sun Sep 6 21:03:02 2026 -0400 smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions [ Upstream commit b8e5dc4f95e5484159b343903f302eb6d783f2e6 ] When a file has the setuid or setgid bit set and is written to, the VFS strips those bits and issues a setattr with ATTR_KILL_SUID/ATTR_KILL_SGID together with an ATTR_MODE carrying the already-cleared mode. Both cifs_setattr_unix() and cifs_setattr_nounix() unconditionally dropped ATTR_MODE in that case: /* skip mode change if it's just for clearing setuid/setgid */ if (attrs->ia_valid & (ATTR_KILL_SUID|ATTR_KILL_SGID)) attrs->ia_valid &= ~ATTR_MODE; This is fine for the default mount, where the mode is only emulated via the DOS read-only attribute and cannot represent the setuid/setgid bits anyway. However, with the "cifsacl" or "modefromsid" mount options the mode is stored on the server through an ACL (id_mode_to_cifs_acl()), with the SMB3.1.1 POSIX extensions the mode is sent to the server directly, and with the SMB1 Unix extensions (cifs_setattr_unix) the mode is sent via CIFSSMBUnixSetPathInfo(). In all those cases dropping ATTR_MODE means the cleared mode is never pushed to the server, so the setuid/setgid bit survives the write. This is a security issue: on local filesystems the setuid bit is stripped when a file is written, but over these cifs.ko mounts the bit persists on the server, potentially allowing an unexpected privilege escalation on subsequent execution. Fix this in two places: 1. cifs_setattr_nounix(): only take the "skip mode change" shortcut when the mode is emulated via the DOS read-only attribute (i.e. neither cifsacl/modefromsid nor the SMB3.1.1 POSIX extensions are in effect), so that the cleared mode is propagated to the server in the ACL / POSIX cases. 2. cifs_setattr_unix(): this function is only called when Unix extensions are in effect, so the mode is always stored on the server. Remove the shortcut entirely so that the cleared mode is always pushed. Fixes: d32c4f2626ac ("CIFS: ignore mode change if it's just for clearing setuid/setgid bits") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a3e8b98c823d51b230c9ff60e538d4dcb7616920 Author: David Howells Date: Sun Sep 6 21:03:01 2026 -0400 cifs: Scripted clean up fs/smb/client/smb2proto.h [ Upstream commit 1e009e3346db230787685a3989fd9c346fb412fb ] Remove externs, correct argument names and reformat declarations. Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya Signed-off-by: Steve French For the stable backport, drop the original smb2proto.h cleanup because the stable header has gained and changed declarations that make the scripted rewrite conflict, while the target does not touch or depend on the header. Instead, carry only behavior-preserving context preparation in inode.c: use the type-safe kmalloc_obj() spelling and the existing local sbflags snapshot, and brace the adjacent else-if. This allows both target hunks to apply cleanly without pre-applying the target's behavioral change. [ sashal: Reduced backport -- upstream 1e009e3346db touches 1 file(s), this backport carries 1. Not backported here: fs/smb/client/smb2proto.h This note is generated from the file lists only; see the resolution record for the reasoning. ] [ sashal: Reduced backport -- upstream 1e009e3346db2 touches 1 file(s), this backport carries 1. Not backported here: fs/smb/client/smb2proto.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: b8e5dc4f95e5 ("smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 72796c2ec6e90f0ec9a1bf7fe215650bee6ef710 Author: David Howells Date: Sun Sep 6 21:03:00 2026 -0400 cifs: Scripted clean up fs/smb/client/fs_context.h [ Upstream commit 047e504766a357ab751f76ccdec7a2e824e75e6d ] Remove externs, correct argument names and reformat declarations. Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya Signed-off-by: Steve French Stable-dep-of: b8e5dc4f95e5 ("smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4fb5a561866c495849d28d42e47f2e40c6d6f935 Author: David Howells Date: Sun Sep 6 21:02:59 2026 -0400 cifs: Scripted clean up fs/smb/client/fscache.h [ Upstream commit bc3de356aae666de5d8b5131545be87cf7754431 ] Remove externs, correct argument names and reformat declarations. Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya Signed-off-by: Steve French Stable-dep-of: b8e5dc4f95e5 ("smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1537c6c675104f00813100d9e8ea4e67cc0458cc Author: David Howells Date: Sun Sep 6 21:02:58 2026 -0400 cifs: Scripted clean up fs/smb/client/cifs_unicode.h [ Upstream commit 696ca7d95658224ba807813101d0d5714d1d8aa4 ] Remove externs, correct argument names and reformat declarations. Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya Signed-off-by: Steve French For the stable backport, drop the original header cleanup because the stable-only __KERNEL__ guard makes it conflict and the target does not touch or depend on those declarations. Instead, carry only a behavior-preserving local snapshot of mnt_cifs_flags in cifs_setattr_nounix(); the target patch refers to that snapshot in its new setuid/setgid condition. cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org [ sashal: Reduced backport -- upstream 696ca7d956582 touches 1 file(s), this backport carries 1. Not backported here: fs/smb/client/cifs_unicode.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: b8e5dc4f95e5 ("smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 549bd9868e9d77b07ea94870940d64342829c6ad Author: Chuck Lever Date: Sat Sep 5 22:13:30 2026 -0400 NFSD: Prevent client use-after-free during admin state revocation [ Upstream commit e270e5a0778e5bff852c8862ce9576ce70359393 ] A stateid holds only a bare pointer to its nfs4_client; a stateid reference does not pin it. The client survives only because __destroy_client() drains its stateids before free_client() runs. nfsd4_revoke_states() drops nn->client_lock across revoke_one_stid(), which dereferences the client to revoke a stateid and read clp->cl_minorversion. A teardown racing the dropped lock can free the client first. Pinning cl_rpc_users under client_lock blocks the DESTROY_CLIENTID and EXCHANGE_ID teardown, which refuses while cl_rpc_users is non-zero. force_expire_client() ignores it: once its wait for cl_rpc_users to reach zero has passed, a later pin goes unnoticed. Under client_lock, skip a client whose cl_time is already zero -- force_expire_client() clears it there before waiting -- otherwise pin cl_rpc_users before dropping the lock. The walk then either sees the expiry and skips, or pins in time for that wait to cover the revoke. Fixes: 1c13bf9f2e3c ("nfsd: allow lock state ids to be revoked and then freed") Cc: stable@vger.kernel.org Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-3-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever [ adapted revoke_one_stid() calls to the branch’s inline revocation logic ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3c0a53ee0b442348d8d2286d6960d3f07bb3a3d3 Author: Chuck Lever Date: Sat Sep 5 22:13:33 2026 -0400 NFSD: Prevent client use-after-free during delegation revoke [ Upstream commit 4683ca76b3b7e5808338491c6eb3c20e6b4894d5 ] A delegation stateid holds only a bare pointer to its owning nfs4_client and does not keep it alive. The client survives its stateids only because __destroy_client() drains cl_delegations and cl_revoked before free_client() runs. nfs4_laundromat() breaks that invariant: it unhashes an expired delegation from cl_delegations, drops deleg_lock, then revoke_delegation() relinks it onto cl_revoked under cl_lock. In that window the delegation is on neither list, so client_has_state() can report no remaining state. Every teardown path first requires cl_rpc_users to be zero, but the laundromat holds no such reference. A client whose recalled delegation has just timed out can therefore reach free_client() while revoke_delegation() is still about to dereference cl_lock, a use-after-free. Pin the client with cl_rpc_users across the revoke so teardown blocks until it completes, then reap the delegation from cl_revoked. A client already expiring reaps its own, so skip it and leave the delegation on del_recall_lru. Fixes: 3bd64a5ba171 ("nfsd4: implement SEQ4_STATUS_RECALLABLE_STATE_REVOKED") Cc: stable@vger.kernel.org Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-2-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 969b1fefb07d16a2a51669229893f2757c82174c Author: Jeff Layton Date: Sat Sep 5 22:13:32 2026 -0400 nfsd: convert global state_lock to per-net deleg_lock [ Upstream commit 8be12e0cf21110f1e0b7fd21711ff13fb75bee72 ] Replace the global state_lock spinlock with a per-nfsd_net deleg_lock. The state_lock was only used to protect delegation lifecycle operations (the del_recall_lru list and delegation hash/unhash), all of which are scoped to a single network namespace. Making the lock per-net removes a source of unnecessary contention between containers. Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Stable-dep-of: 4683ca76b3b7 ("NFSD: Prevent client use-after-free during delegation revoke") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6d6b9f6a75c3767250e9c23ace4e384ab8f7843e Author: Jeff Layton Date: Sat Sep 5 16:05:38 2026 -0400 nfsd: close shrinker/GC/fsnotify vs per-net shutdown race in filecache [ Upstream commit 40162cfea79b9510380decfdd1795b754dc9f972 ] The shrinker, GC worker, and fsnotify/lease callbacks can unhash an nfsd_file from the rhashtable and then call nfsd_file_dispose_list_delayed() to move it to the per-net dispose list. If nfsd_file_cache_shutdown_net() runs concurrently, its rhashtable walk misses the already-unhashed file, and its drain of the per-net dispose list can run before the file has been queued. The file then sits on the per-net list with no thread to drain it, leaking both the file and its associated state. The GC worker and shrinker already hold nfsd_gc_lock while walking the LRU, but in the original code they release it before calling nfsd_file_dispose_list_delayed(). The fsnotify/lease path (nfsd_file_close_inode) has no synchronization at all. Fix this by: 1. Widening nfsd_gc_lock in both nfsd_file_gc() and nfsd_file_lru_scan() to cover the nfsd_file_dispose_list_delayed() call. 2. Wrapping nfsd_file_close_inode() in nfsd_gc_lock so that all three callers of nfsd_file_dispose_list_delayed() hold the lock. 3. Adding a spin_lock/unlock(nfsd_gc_lock) barrier in nfsd_file_cache_shutdown_net() after the purge, so that any in-progress disposal has fully completed before the per-net list is drained. All operations inside the lock are non-sleeping (rhashtable lookups, atomic bit/refcount ops, list moves, svc_wake_up), so the spinlock is appropriate. Fixes: ffb402596147 ("nfsd: Don't leave work of closing files to a work queue") Cc: stable@vger.kernel.org # v6.15+ Signed-off-by: Jeff Layton Assisted-by: Claude:claude-opus-4-8 Link: https://patch.msgid.link/20260604-nfsd-testing-v4-1-3aeb1479c5bb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9031493ef7369d5c59c4bacc96f0c85965f09a98 Author: Jeff Layton Date: Sat Sep 5 16:05:31 2026 -0400 nfsd: fix UAF in async copy cancel and shutdown [ Upstream commit 62c0f6eaf050bb9284c1f9cac6ed1770092e6b95 ] An async copy could be freed or used after free while a teardown caller (OFFLOAD_CANCEL, nfsd4_shutdown_copy, nfsd4_cancel_copy_by_sb) raced the copy kthread: - find_async_copy() bumped copy->refcount but left the copy on clp->async_copies, so the reaper's cleanup_async_copy() could run release_copy_files() concurrently with a cancel/shutdown caller. Both put and NULL nf_src/nf_dst without a common lock, double-putting the nfsd_file and freeing it early. - nfsd4_do_async_copy() set NFSD4_COPY_F_STOPPED before its final uses of the copy (nfsd_update_cmtime_attr() on copy->nf_dst, nfsd4_send_cb_offload()). nfsd4_stop_copy() treats a set STOPPED bit as "kthread done, skip kthread_stop()", so a teardown caller ran release_copy_files() -- which puts and NULLs nf_dst -- while the kthread still dereferenced it (NULL/UAF). - copy->copy_task was never pinned. The one-shot kthread self-reaps on return, so kthread_stop()'s get_task_struct() could touch a freed task_struct. - co_cb is embedded in the copy, but nfsd4_send_cb_offload() held a reference only on the client, so a concurrent teardown could free the copy while the CB_OFFLOAD callback was in flight. Fix the teardown lifetime as a whole: - find_async_copy() unlinks the copy (clear cp_clp, list_del_init) under async_lock; the cancel, shutdown, and sb-cancel paths drop the list-membership reference via nfs4_put_copy() after nfsd4_stop_copy(). Drop the now-redundant list_del fixup from cleanup_async_copy(). - Because unlinking hides the copy from the reaper, its cleanup_async_copy() can no longer remove the copy's s2s_cp_stateids entry; the cancel/shutdown/sb-cancel paths now call nfs4_free_copy_state() themselves (while cp_clp is still valid) so the entry does not dangle at freed memory for the laundromat and manage_cpntf_state() to dereference. - Give the kthread its own reference, taken in nfsd4_copy() before wake_up_process() and dropped at the end of nfsd4_do_async_copy(); call wake_up_process() before list_add(). - Pin the task_struct with get_task_struct() in nfsd4_copy(), released in nfs4_put_copy(), so kthread_stop() is safe whenever the kthread exits. Set NFSD4_COPY_F_STOPPED only in nfsd4_stop_copy(), which now always kthread_stop()s before release_copy_files(); completion is still reported via NFSD4_COPY_F_COMPLETED, so nfsd4_has_active_async_copies() is unaffected. Each teardown caller removes the copy from clp->async_copies first, so kthread_stop() runs exactly once. - Take a copy reference in nfsd4_send_cb_offload(), dropped in nfsd4_cb_offload_release(). The kthread still holds its own reference there, so the refcount_inc() cannot race the final free. - Read cp_clp with smp_load_acquire() to pair with the unordered set_bit()/clear_bit() writers (Documentation/atomic_bitops.rst). Fixes: e0639dc5805a ("NFSD introduce async copy feature") Cc: stable@vger.kernel.org Fixes: ac0514f4d198 ("NFSD: Add a laundromat reaper for async copy state") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260710-nfsd-testing-v3-2-a0ff7db6aa3e@kernel.org Signed-off-by: Chuck Lever [ omitted superblock-wide copy cancellation and related client/error helpers absent in v6.18. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba0ee9e04b7a0356c28d5a2fe445db675d24e572 Author: Jeff Layton Date: Sat Sep 5 11:46:28 2026 -0400 nfsd: fix fcache_disposal UAF by inlining dispose state into nfsd_net [ Upstream commit bbf13732f74351d21c5e0e8dd9bd8e1c48dc35d4 ] nfsd_file_dispose_list_delayed() defers fput() to nfsd service threads via a per-net freeme queue, preventing the shrinker and GC worker from bearing the cost of closing files (see ffb402596147). However, the queue lives in a separately-allocated struct nfsd_fcache_disposal that is freed by nfsd_free_fcache_disposal_net() during per-net teardown. The global shrinker, laundrette, and fsnotify callbacks can still be inside nfsd_file_dispose_list_delayed() dereferencing that pointer, causing a use-after-free. Inline the spinlock and freeme list directly into struct nfsd_net (as fcache_dispose_lock and fcache_dispose_list), eliminating the separately allocated struct nfsd_fcache_disposal entirely. These fields now have the same lifetime as the net namespace itself, so there is no dangling pointer to chase. nfsd_file_cache_start_net() now just initializes the inline fields and cannot fail due to allocation. nfsd_file_cache_shutdown_net() drains the inline list directly instead of freeing a separate struct. The alloc/free helpers are removed. Fixes: 1463b38e7cf3 ("NFSD: simplify per-net file cache management") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260602-nfsd-testing-v2-7-e4ea62e3cd5c@kernel.org Signed-off-by: Chuck Lever [ adapted removal of kmalloc_obj() allocator to older kmalloc() implementation ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f9cec313efb2fd18d962aad738a4892bce806016 Author: Jeff Layton Date: Sat Sep 5 07:02:45 2026 -0400 nfsd: fix clock domain mismatch in clients_still_reclaiming() [ Upstream commit 09ea3eb9a518565f5bca386e81b993ed8825f5e8 ] clients_still_reclaiming() computes a deadline from nn->boot_time (CLOCK_REALTIME, ~1.7 billion) but compares it against ktime_get_boottime_seconds() (CLOCK_BOOTTIME, seconds since boot). The comparison is always false — it would take ~54 years of uptime for BOOTTIME to exceed the REALTIME-derived deadline. This means any client can hold the server in grace indefinitely by sending CLAIM_PREVIOUS OPEN requests, blocking all non-reclaim operations for all other clients. Add boot_time_bt (CLOCK_BOOTTIME) alongside the existing boot_time and use it for the deadline computation. boot_time (CLOCK_REALTIME) is preserved for its cl_boot clientid-nonce role. Fixes: 20b7d86f29d3 ("nfsd: use boottime for lease expiry calculation") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-12-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever [ preserved the branch’s boolean fields instead of the upstream flags bitmap ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 03c512f22d3fbe7a3767d6df5e3d88b8e7c105e5 Author: Jeff Layton Date: Tue Jun 2 12:23:17 2026 -0400 nfsd: widen nfsd_genl_rqstp address fields to sockaddr_storage commit a99d720ed2a5258564e5e9d5f39f3184a030d354 upstream. struct nfsd_genl_rqstp declares rq_daddr and rq_saddr as plain "struct sockaddr" (16 bytes). When an IPv6 NFS client is connected, nfsd_genl_rpc_status_compose_msg() casts these fields to "struct sockaddr_in6 *" (28 bytes) and reads sin6_addr at offset 8..24, which extends 8 bytes past the end of the 16-byte sockaddr field into the adjacent rq_flags member. The 16-byte nla_put_in6_addr then ships 8 bytes of truncated IPv6 address followed by 8 bytes of rq_flags to userspace via the NFSD_A_RPC_STATUS_SADDR6/DADDR6 netlink attributes. This is reachable by any unprivileged process in the network namespace because NFSD_CMD_RPC_STATUS_GET uses GENL_CMD_CAP_DUMP without GENL_ADMIN_PERM. Fix by widening rq_daddr and rq_saddr to struct sockaddr_storage so the IPv6 casts operate within bounds, copying sizeof(struct sockaddr_storage) bytes in the memcpy calls so the full address is captured, and zero-initializing the genl_rqstp stack variable to prevent leaking uninitialized tail bytes through netlink. Fixes: bd9d6a3efa97 ("NFSD: add rpc_status netlink support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260602-nfsd-testing-v2-5-e4ea62e3cd5c@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ccc069d5c47cd727717ac910e10783d5585d0d8e Author: Jeff Layton Date: Wed Mar 25 10:40:22 2026 -0400 nfsd: move struct nfsd_genl_rqstp to nfsctl.c commit 1ed3df33bdbda5fd639571afe9c7cd282ff82cd9 upstream. It's not used outside of that file. Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Stable-dep-of: a99d720ed2a5 ("nfsd: widen nfsd_genl_rqstp address fields to sockaddr_storage") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 430ed49a16cf9ca249d0fb51490582090bc4848b Author: Jeff Layton Date: Thu Jun 11 16:00:48 2026 -0400 nfsd: check nfsd4_acl_to_attr() return value in nfsd4_create() commit 2c7912732184773dbd371a411da87af1cc080b86 upstream. nfsd4_create() stores the return value of nfsd4_acl_to_attr() in status, but the switch(create->cr_type) block unconditionally overwrites it in every branch. ACL translation errors are silently discarded, and the CREATE proceeds without the requested ACL. Add an early exit check after nfsd4_acl_to_attr(), matching the pattern already used in nfsd4_setattr(). Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton [ cel: prefer NFS4ERR_BADTYPE over NFS4ERR_ATTRNOTSUPP ] Link: https://patch.msgid.link/20260611-nfsd-testing-v2-5-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever [ retained unconditional ACL conversion because the older helper already handles null ACLs ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 380d138a6b086b4fa33013b46b0fb155faf98d88 Author: Jiayuan Chen Date: Sat Aug 15 15:03:36 2026 +0800 net: advertise TCP MSS from the configured MTU, not the learned PMTU commit 2640e64195948a601430d230c9864f5426574cde upstream. The MSS a host puts in its SYN tells the peer how big a segment it may send us. Right now we can shrink it with a PMTU we learned on our own send path, which is the wrong direction entirely. On asymmetric paths this bites - think DSR load balancers, where the request side goes through a smaller-MTU overlay. We learn a small PMTU going out, then advertise a small MSS, and the peer stays capped for the whole connection even though its path back to us is wide. MSS only shows up in the SYN and never grows back. On symmetric paths we lose nothing by dropping it either: the peer runs its own PMTU discovery and usually already knows the real path MTU. So work out the advertised MSS from the configured route or device MTU and ignore the learned PMTU. Our send side is unchanged, still clamped by tcp_current_mss(). Add ip_dst_mtu_configured()/ip6_dst_mtu_configured() and use them from the two default_advmss() paths. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 164a5e7ad531 ("ipv4: ipv4_default_advmss() should use route mtu") Cc: stable@vger.kernel.org Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260815070413.294559-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cfb44c6028e6f979720315e0772bbd0d4d33ed61 Author: Yong Wang Date: Mon Aug 31 20:20:57 2026 -0400 tcp: clamp route advmss to TCP_MIN_MSS [ Upstream commit 870a9e42ecc6fe1b8c25d87af043cb0d9c178fe1 ] tcp_select_initial_window() assumes that callers never pass an MSS smaller than 1, but route-derived advmss values can violate that assumption. A too-small explicit RTAX_ADVMSS is one way to get there, but it is not the only one. The same divide-by-zero can also be reached through the "default advmss" path when RTAX_ADVMSS is left at 0 and the effective advmss is later driven down by route MTU and min_adv_mss. Introduce a tcp_dst_advmss() helper that clamps route advmss to TCP_MIN_MSS before TCP consumes it, and use it in the TCP paths that derive advmss from dst metrics. This keeps the effective MSS from dropping to zero before tcp_select_initial_window() rounds the receive window. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Yong Wang Signed-off-by: Ren Wei Link: https://patch.msgid.link/251eaf8277fa7c66364c9815c5da01662d269181.1787074852.git.edragain@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ea44679bc7d218f5e27f609bf3a6ba97009df42b Author: Eric Dumazet Date: Mon Aug 31 20:20:56 2026 -0400 ipv4: use dst4_mtu() instead of dst_mtu() [ Upstream commit fe8570186f100b6cc499b2f7705946baf1388cde ] When we expect an IPv4 dst, use dst4_mtu() instead of dst_mtu() to save some code space. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260130210303.3888261-8-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 870a9e42ecc6 ("tcp: clamp route advmss to TCP_MIN_MSS") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a615a2c8c30629065edd53573d4a86d438f32589 Author: Eric Dumazet Date: Mon Aug 31 20:20:55 2026 -0400 ipv6: use dst6_mtu() instead of dst_mtu() [ Upstream commit b40f0130a23b6bab8b359e158a40af81f11f14be ] When we expect an IPv6 dst, use dst6_mtu() instead of dst_mtu() to save some code space. Due to current dst6_mtu() implementation, only convert users in IPv6 stack. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260130210303.3888261-7-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 870a9e42ecc6 ("tcp: clamp route advmss to TCP_MIN_MSS") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 920dacce8734db1de0a641cda961fc869ac456d8 Author: Eric Dumazet Date: Mon Aug 31 20:20:54 2026 -0400 inet: add dst4_mtu() and dst6_mtu() helpers [ Upstream commit 8776c4ef3ab22b95f55713f00a7a576e6402507d ] With CONFIG_MITIGATION_RETPOLINE=y dst_mtu() is a bit fat, because it is generic. Indeed, clang does not always inline it. Add dst4_mtu() and dst6_mtu() helpers for callers that expect either ipv4_mtu() or ip6_mtu() to be called. These helpers are always inlined. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260130210303.3888261-6-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 870a9e42ecc6 ("tcp: clamp route advmss to TCP_MIN_MSS") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b650560c5ee21b7dc74c46434350142bb08304ff Author: Eric Dumazet Date: Mon Aug 31 20:20:53 2026 -0400 ipv6: add some unlikely()/likely() clauses in ip6_output.c [ Upstream commit 2855e4925416c5900a9c6cece11f4a2e56bf6e63 ] 1) daddr is unlikely a multicast in ip6_finish_output2(). 2) ip6_finish_output_gso_slowpath_drop() should not be called often. 3) ip6_fragment() should not be called often. 4) opt is unlikely to be set. 5) ip6_xmit() and ip6_forward() mostly sends not too big packets. 6) Most __ip6_make_skb() calls are for UDP packets, not ICMPV6 ones. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260130210303.3888261-3-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 870a9e42ecc6 ("tcp: clamp route advmss to TCP_MIN_MSS") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a294168185fe8e5b4688e1f1763d078734e4a0a8 Author: Eric Dumazet Date: Mon Aug 31 20:20:52 2026 -0400 ipv6: pass proto by value to ipv6_push_nfrag_opts() and ipv6_push_frag_opts() [ Upstream commit 1bc46dd209667346c5aa56c351995e7c260696d0 ] With CONFIG_STACKPROTECTOR_STRONG=y, it is better to avoid passing a pointer to an automatic variable. Change these exported functions to return 'u8 proto' instead of void. - ipv6_push_nfrag_opts() - ipv6_push_frag_opts() For instance, replace ipv6_push_frag_opts(skb, opt, &proto); with: proto = ipv6_push_frag_opts(skb, opt, proto); Note that even after this change, ip6_xmit() has to use a stack canary because of @first_hop variable. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260130210303.3888261-2-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 870a9e42ecc6 ("tcp: clamp route advmss to TCP_MIN_MSS") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 194d0fb0ea4720535ff3168c9d04c7632cec7071 Author: Xiang Mei Date: Mon Aug 31 18:20:04 2026 -0400 fuse: copy request headers via a stack buffer for io-uring [ Upstream commit fd10f40af314f07b6d6e028b1ca25c8b49903aab ] The fuse-io-uring transport copies req->in.h out to the ring in fuse_uring_copy_to_ring() and req->out.h back in fuse_uring_commit(). Both headers live inside the fuse_request slab object, whose cache (fuse_req_cachep) is created without a usercopy whitelist, so copying them directly to/from userspace trips CONFIG_HARDENED_USERCOPY and panics: usercopy: Kernel memory exposure attempt detected from SLUB object 'fuse_request' (offset 56, size 40)! kernel BUG at mm/usercopy.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:usercopy_abort (mm/usercopy.c:90) Call Trace: __check_heap_object (mm/slub.c:8268) __check_object_size (mm/usercopy.c:197 mm/usercopy.c:258 mm/usercopy.c:223) copy_header_to_ring (fs/fuse/dev_uring.c:618) fuse_uring_prepare_send (fs/fuse/dev_uring.c:776 fs/fuse/dev_uring.c:785) fuse_uring_send_in_task (fs/fuse/dev_uring.c:1306) tctx_task_work_run (io_uring/tw.c:96) task_work_run (kernel/task_work.c:233) io_run_task_work (io_uring/tw.h:84) io_cqring_wait (io_uring/wait.c:278) __do_sys_io_uring_enter (io_uring/io_uring.c:2685) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Bounce both headers through an on-stack copy so the usercopy touches stack memory, not the slab object. Fixes: c090c8abae4b ("fuse: Add io-uring sqe commit and fetch support") Cc: stable@vger.kernel.org Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Reviewed-by: Bernd Schubert Reviewed-by: Joanne Koong Signed-off-by: Miklos Szeredi [ merged declaration of `in_header`/`out_header` alongside pre-existing `ring`/`fc` locals introduced by prior refactors ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b96b0d2c25d141103a1b78c574dbf6b88f91ddbd Author: Joanne Koong Date: Mon Aug 31 18:20:03 2026 -0400 fuse-uring: use named constants for io-uring iovec indices [ Upstream commit 8bbb2ad1f687633a991839bd3efae04ccfb29e19 ] Replace magic indices 0 and 1 for the iovec array with named constants FUSE_URING_IOV_HEADERS and FUSE_URING_IOV_PAYLOAD. This makes the usages self-documenting and prepares for buffer ring support which will also reference these iovec slots by index. Reviewed-by: Bernd Schubert Reviewed-by: Jeff Layton Reviewed-by: Baokun Li Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Stable-dep-of: fd10f40af314 ("fuse: copy request headers via a stack buffer for io-uring") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f12ebb0a3ed7d45521d1535dfc5d272cd8c65618 Author: Joanne Koong Date: Mon Aug 31 18:20:02 2026 -0400 fuse-uring: refactor setting up copy state for payload copying [ Upstream commit c0f9203732fc70de8d20697270bfe405481eac14 ] Add a new helper function setup_fuse_copy_state() to contain the logic for setting up the copy state for payload copying. Reviewed-by: Bernd Schubert Reviewed-by: Jeff Layton Reviewed-by: Baokun Li Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Stable-dep-of: fd10f40af314 ("fuse: copy request headers via a stack buffer for io-uring") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 121fc8edf583226e02f351ea3d6ca3b94c3440e3 Author: Joanne Koong Date: Mon Aug 31 18:20:01 2026 -0400 fuse-uring: use enum types for header copying [ Upstream commit b2bbd7dcd2433e29b7e9a726aaa9571a78fa8d5f ] Use enum types to identify which part of the header needs to be copied. This improves the interface and will simplify both kernel-space and user-space header addresses copying when buffer rings are added. Reviewed-by: Bernd Schubert Reviewed-by: Jeff Layton Reviewed-by: Baokun Li Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Stable-dep-of: fd10f40af314 ("fuse: copy request headers via a stack buffer for io-uring") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c46805193fbefe25d642ed69bc7b9807a0c2f846 Author: Joanne Koong Date: Mon Aug 31 18:20:00 2026 -0400 fuse-uring: refactor io-uring header copying from ring [ Upstream commit ba7d47897fd895533c19af436ca7fc4f6b171238 ] Move header copying from ring logic into a new copy_header_from_ring() function. This makes the copy_from_user() logic more clear and centralizes error handling / rate-limited logging. Reviewed-by: Bernd Schubert Reviewed-by: Jeff Layton Reviewed-by: Baokun Li Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Stable-dep-of: fd10f40af314 ("fuse: copy request headers via a stack buffer for io-uring") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6bb5347e9f8aa3c9bdd4785315a17b2d857feb69 Author: Joanne Koong Date: Mon Aug 31 18:19:59 2026 -0400 fuse-uring: refactor io-uring header copying to ring [ Upstream commit 6582f8a06698403dccf8a01b7eef176b2c6dd7ff ] Move header copying to ring logic into a new copy_header_to_ring() function. This makes the copy_to_user() logic more clear and centralizes error handling / rate-limited logging. Reviewed-by: Bernd Schubert Reviewed-by: Jeff Layton Reviewed-by: Baokun Li Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Stable-dep-of: fd10f40af314 ("fuse: copy request headers via a stack buffer for io-uring") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8974575898cd7a4c818088f102b2e7a0286d3302 Author: Joanne Koong Date: Thu Jul 16 11:31:42 2026 -0700 fuse: fix missing barrier when checking io-uring readiness commit edb310bc27f0ad83e7fd558a3caf1a94ca511654 upstream. fuse_block_alloc() reads fch->initialized and then fch->io_uring. fch->io_uring is set before fch->initialized, ordered by the smp_wmb() in fuse_chan_set_intialized(), but fuse_block_alloc() has no matching read barrier between the two loads. This may lead a CPU to observe fch->initialized=1 but fch->io_uring=0, and skip the check that blocks request allocation until the io-uring queues are ready. This can reintroduce the lock-order inversion deadlock that commit 3393ff964e0f prevents. Add an smp_rmb() barrier to pair with the smp_wmb() in fuse_chan_set_initialized() to prevent this. Fixes: 3393ff964e0f ("fuse: block request allocation until io-uring init is complete") Cc: stable@vger.kernel.org Reviewed-by: Bernd Schubert Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi [ renamed `fch`/`struct fuse_chan` to `fc`/`struct fuse_conn` and `fuse_chan_set_initialized()` to `fuse_set_initialized()` in the comment ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f1c91222188be68df7e29429dfd52b36b11f4158 Author: Ali Tariq Date: Wed Sep 9 07:40:43 2026 -0400 PCI: starfive: Fix resource leaks on error paths in host_init() [ Upstream commit 22877a061f81c5d58041e384b3131684bec636b9 ] starfive_pcie_host_init() acquires the PHY, clocks/resets, and an optional regulator in sequence, but does not correctly unwind these resources when a later step fails. If starfive_pcie_clk_rst_init() fails after the PHY has already been successfully enabled, the function returns directly without disabling the PHY, leaking it and leaving it powered. If regulator_enable() fails for the optional vpcie3v3 regulator, the failure is only logged; the function falls through and returns success, leaving the driver believing the regulator is enabled while continuing to configure PCIe hardware that may be unpowered. This also leaves the clocks and PHY enabled with nothing to clean them up. Disable the PHY on the clk/reset failure path, and disable the clocks/resets and PHY, then return the error, if the regulator fails to enable. Build-tested and boot-tested on StarFive VisionFive 2 v1.2A Fixes: 05a75df4182e ("PCI: starfive: Use regulator APIs to control the 3v3 power supply of PCIe slots") Fixes: 39b91eb40c6a ("PCI: starfive: Add JH7110 PCIe controller") Signed-off-by: Ali Tariq Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260716102053.185276-1-alitariq45892@gmail.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e5c1d10003b4de27485ed0b11b01c4c471cd2a8d Author: Hal Feng Date: Wed Sep 9 07:40:42 2026 -0400 PCI: starfive: Use regulator APIs to control the 3v3 power supply of PCIe slots [ Upstream commit 05a75df4182e301a1b0059606f77b65c74deaa9b ] The driver has been using the "enable-gpios" property to control the 3v3 power supply of PCIe slots. But it is not documented in the dt-bindings and also using GPIO APIs is not a standard way to control PCIe slot power, so use the documented "vpcie3v3-supply" property and regulator APIs to control the slot supply. This change will break the DTs which used "enable-gpio" or "enable-gpios" property under the controller node. Since these properties were not defined in the bindings, it is safe to switch to "vpcie3v3-supply". Any out-of-tree DTS impacted by this change should migrate to "vpcie3v3-supply" instead. Signed-off-by: Hal Feng [mani: reworded description] Signed-off-by: Manivannan Sadhasivam Acked-by: Kevin Xie Link: https://patch.msgid.link/20251218102149.28062-1-hal.feng@starfivetech.com Stable-dep-of: 22877a061f81 ("PCI: starfive: Fix resource leaks on error paths in host_init()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0d72e78c9d38d5377a059a4837f82b65b91cdcf6 Author: Oscar Ou Date: Wed Sep 9 06:34:31 2026 -0400 lockd: fix swapped arguments in nlmsvc_match_ip() [ Upstream commit b9060689f49dc663e9a3d069c4a65ff63a836e66 ] When releasing locks by server IP address via /proc/fs/nfsd/unlock_ip, nlmsvc_unlock_all_by_ip() calls nlm_traverse_files() with the server sockaddr as the opaque @data argument: nlm_traverse_files(server_addr, nlmsvc_match_ip, NULL); The match callback is later invoked from nlm_traverse_locks() as: match(lockhost, host); where the first argument is the nlm_host that owns the lock, and the second argument is the @data that was originally passed down (here the server sockaddr). This is the convention every other match callback relies on (nlmsvc_mark_host(), nlmsvc_same_host(), nlmsvc_is_client()): arg1 is the real nlm_host, arg2 is the caller-supplied reference value. nlmsvc_match_ip() has had these two arguments reversed ever since the unlock-by-IP feature was introduced in commit 4373ea84c84d ("lockd: unlock lockd locks associated with a given server ip"): return rpc_cmp_addr(nlm_srcaddr(host), datap); Here @host is actually the server sockaddr, so nlm_srcaddr(host) dereferences a struct sockaddr as a struct nlm_host and reads garbage at the offset of h_srcaddr; meanwhile @datap is actually the lock owner's nlm_host but is compared as a sockaddr. As a result the comparison practically never matches and locks are not released for the requested IP. Swap the arguments so the lock owner's source address is compared against the requested server address: return rpc_cmp_addr(nlm_srcaddr(datap), (struct sockaddr *)host); Fixes: 4373ea84c84d ("lockd: unlock lockd locks associated with a given server ip") Cc: stable@vger.kernel.org Signed-off-by: Oscar Ou [ cel: fix the misleading typedef parameter names too ] Link: https://patch.msgid.link/20260617075738.1151797-1-oscarou@synology.com Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fcfcba8fe17dbf2c8805690b8cc25e32d81249a4 Author: Doruk Tan Ozturk Date: Wed Sep 9 06:11:43 2026 -0400 ocfs2: validate directory-index entry counts when reading metadata [ Upstream commit bc70726ddad53c7e9a9a85915bf2415b0d4f42f9 ] ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() check the ECC and signature of an indexed-directory block before it reaches higher-level callers, but neither validator bounds the ocfs2_dx_entry_list counts against the capacity of the block that holds them. ocfs2_dx_dir_search() then walks for (i = 0; i < le16_to_cpu(entry_list->de_num_used); i++) dx_entry = &entry_list->de_entries[i]; over de_num_used entries with no bounds check. entry_list is either dx_leaf->dl_list (from ocfs2_read_dx_leaf) or, for an inline root, dx_root->dr_entries. A crafted on-disk image can set de_num_used (and de_count, which is the __counted_by_le() bound of de_entries) to 0xffff and make the walk read far past the end of the 4KB metadata block, giving a slab out-of-bounds read reachable from any path lookup, stat() or open() on an indexed directory once the image is mounted. Commit 775c17386a6f ("ocfs2: validate dx_root extent list fields during block read") already bounds dr_list for the non-inline dx_root, but left the inline dr_entries path and the dx_leaf dl_list unchecked. Add the same read-time validation for both entry lists: de_count must equal the capacity of the block (ocfs2_dx_entries_per_leaf()/per_root()) and de_num_used must not exceed de_count, rejecting corrupted metadata with -EFSCORRUPTED before ocfs2_dx_dir_search() can walk an out-of-range entry array. de_count is always written as exactly the block capacity when a leaf or inline root is formatted, so the equality check does not reject any valid image. Found by 0sec automated security-research tooling (https://0sec.ai). Link: https://lore.kernel.org/20260713205625.92391-1-doruk@0sec.ai Fixes: 9b7895efac90 ("ocfs2: Add a name indexed b-tree to directory inodes") Fixes: 4ed8a6bb083b ("ocfs2: Store dir index records inline") Assisted-by: 0sec:claude-opus-4-8 Signed-off-by: Doruk Tan Ozturk Reviewed-by: Joseph Qi Cc: Joel Becker Cc: Kees Cook Cc: Mark Fasheh Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 625e00fd25ef55bd14ce5d60f43ce1640c5bdd4d Author: Joseph Qi Date: Wed Sep 9 06:11:42 2026 -0400 ocfs2: validate dx_root extent list fields during block read [ Upstream commit 775c17386a6fd695f999d4cda90e3931386570dd ] Patch series "ocfs2: consolidate extent list validation into block read callbacks". ocfs2 validates extent list fields (l_count, l_next_free_rec) at various points during extent tree traversal. This is fragile because each caller must remember to check for corrupted on-disk data before using it. This series moves those checks into the block read validation callbacks (ocfs2_validate_dx_root and ocfs2_validate_extent_block), so corrupted fields are caught early at block read time. Redundant post-read checks are then removed. This patch (of 4): Move the extent list l_count validation from ocfs2_dx_dir_lookup_rec() into ocfs2_validate_dx_root(), so that corrupted on-disk fields are caught early at block read time rather than during directory lookups. Additionally, add a l_next_free_rec <= l_count check to prevent out-of-bounds access when iterating over extent records. Both checks are skipped for inline dx roots (OCFS2_DX_FLAG_INLINE), which use dr_entries instead of dr_list. Link: https://lkml.kernel.org/r/20260403090803.3860971-1-joseph.qi@linux.alibaba.com Link: https://lkml.kernel.org/r/20260403090803.3860971-2-joseph.qi@linux.alibaba.com Signed-off-by: Joseph Qi Reviewed-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Signed-off-by: Andrew Morton Stable-dep-of: bc70726ddad5 ("ocfs2: validate directory-index entry counts when reading metadata") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a1dabe68fb53730bc0be60c5dbfd3f4c560084e7 Author: Vincent Donnefort Date: Wed Sep 9 06:11:35 2026 -0400 ring-buffer: Make cpu_buffer::free_page a buffer_data_read_page [ Upstream commit 7a1fb95de5404134f8758c1295ce88986bdf117c ] Discarding a cached reader page after a concurrent ring buffer resize uses the new global subbuf_order for the free_pages() call. This mismatched order may crashes the kernel or leaks memory because the cached page was allocated under the old size. Save the actual free_page order alongside the page address to ensure we always refer to the correct value and do not rely on the potentially stalled cpu_buffer->subbuf_order value. The simplest is to make free_page a buffer_data_read_page which already covers exactly what we need: a page address and a page order. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260813131152.3589632-4-vdonnefort@google.com Fixes: 8e7b58c27b3c ("ring-buffer: Just update the subbuffers when changing their allocation order") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt [ Changed upstream’s dpage variable to bpage in ring_buffer_free_read_page(). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a6f3b8dfbdf4f43182b4544e8bfd007f1591fe99 Author: Jorijn van der Graaf Date: Wed Sep 9 06:11:03 2026 -0400 ASoC: codecs: aw88261: only check PLL and clock state at power-up [ Upstream commit 06b6f1245567a4be862c3e1cc74577922ceb05fb ] The SYSST check performed during device start requires SWS (amplifier switching, bit 8) and BSTS (boost finished, bit 9) on top of PLL lock and clock stability. Those bits cannot be asserted at this point in the sequence: the check runs after amppd release but before the hmute/ULS-hmute release, and the amplifier neither switches nor finishes ramping its boost converter while it is still muted. With the Fairphone (Gen. 6) firmware profile, aw88261_dev_start() therefore always fails with check sysst fail, reg_val=0x0011, check:0x311 and playback aborts, even though the amplifier is fine and PLL lock and stable clocks are present. Check only PLL lock and clock stability, for which a definition already exists; this still re-validates the clocks after amppd release (aw88261_dev_check_syspll() checked them before it). This matches the vendor aw882xx driver, which only validates PLL lock and clock stability at this stage, and the in-tree aw88399 driver, which skips the SWS check whenever the amplifier may legitimately not be switching (AW88399_BIT_SYSST_NOSWS_CHECK). Fixes: 028a2ae25691 ("ASoC: codecs: Add aw88261 amplifier driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Jorijn van der Graaf Link: https://patch.msgid.link/20260704192857.88366-1-jorijnvdgraaf@catcrafts.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0ac722e964cdc80ecd36402f554d2a55ab30caa9 Author: Val Packett Date: Wed Sep 9 06:11:02 2026 -0400 ASoC: codecs: aw88261: reduce log spam [ Upstream commit d90c361af215a9fa2a986d9f47d554d0cf3401dd ] This driver would create a wall of logspam during initialization due to e.g. the PLL not being ready while waiting for it to stabilize. Change intermediate dev_err() calls to dev_dbg() to reduce the noise. While here, log the detected chip ID when that check fails. Signed-off-by: Val Packett Tested-by: Luca Weiss Link: https://patch.msgid.link/20260529200550.529719-4-val@packett.cool Signed-off-by: Mark Brown Stable-dep-of: 06b6f1245567 ("ASoC: codecs: aw88261: only check PLL and clock state at power-up") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d013b7de4dccfde73d7c004b4d5338300103c4a2 Author: Mukesh Ojha Date: Wed Sep 9 06:10:56 2026 -0400 remoteproc: qcom: pas: Guard dtb metadata release with dtb_pas_id check [ Upstream commit c06c5ab4945392d2c2aded6d832ab6b58cabe351 ] All other call sites of qcom_scm_pas_metadata_release() for the DTB context are guarded by a check on pas->dtb_pas_id, but the call inside qcom_pas_load() was not. Fix this by moving the call to the guarded block. Reviewed-by: Konrad Dybcio Fixes: 29814986b82e ("remoteproc: qcom_q6v5_pas: add support for dtb co-firmware loading") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260724182858.1868271-3-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson [ adapted DTB cleanup to the older separate initialization and loading APIs. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d6eab9066be0f2aba5528535dd45a39a47d8b4e6 Author: Mukesh Ojha Date: Wed Sep 9 06:10:55 2026 -0400 firmware: qcom_scm: Rename peripheral as pas_id [ Upstream commit 69054348cc1c2d87acad90aec5e6e0d191012aff ] Peripheral and pas_id refers to unique id for a subsystem and used only when peripheral authentication service from secure world is utilized. Lets rename peripheral to pas_id to reflect closer to its meaning. Reviewed-by: Bryan O'Donoghue Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-3-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: c06c5ab49453 ("remoteproc: qcom: pas: Guard dtb metadata release with dtb_pas_id check") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9d69422ddaa13526c2223444e237d948d6e44728 Author: Tejun Heo Date: Wed Sep 9 05:26:31 2026 -0400 sched/core: Make core-sched flips wait for in-flight selections [ Upstream commit f3629c63a4af3e491381780bc6c123cb498c4c40 ] Core scheduling's pick_next_task() operates on all sibling rqs under one acquisition of the shared core-wide lock. A ->pick_task() that releases the rq lock leaves every sibling __lock momentarily free, letting __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under it. The selection resumes on the split locks, touching sibling state it no longer protects, and __schedule() finally releases a lock that was never taken while leaking the one that was. Count in-flight core-wide selections in the leader's rq->core_pick_in_flight and make __sched_core_flip() wait for the count to drain. The count only changes under the shared lock, which the flip holds while sampling, so no other ordering is needed. The wait can repeat while selections overlap, but the flip backs off between samples and flips are rare cookie-lifetime events. sched_core_cpu_deactivate() moves the count to the new leader - a stale copy left behind would bias it forever if that CPU later returns as its own leader. Fixes: 539f65125d20 ("sched: Add core wide task selection and scheduling") Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Tejun Heo Acked-by: Peter Zijlstra (Intel) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fef4b8f17e1c54522957b873ed81e6a60897625d Author: John Stultz Date: Wed Sep 9 05:26:30 2026 -0400 sched: Rework prev_balance() to avoid stale prev references [ Upstream commit 7a3a6bfbd62a2ba3e0ef1e92d6b71abb66890825 ] Historically, the prev value from __schedule() was the rq->curr. This prev value is passed down through numerous functions, and used in the class scheduler implementations. The fact that prev was on_cpu until the end of __schedule(), meant it was stable across the rq lock drops that the class->balance() implementations often do. However, with proxy-exec, the prev passed to functions called by __schedule() is rq->donor, which may not be the same as rq->curr and may not be on_cpu, this makes the prev value potentially unstable across rq lock drops. A recently found issue with proxy-exec, is when we begin doing return migration from try_to_wake_up(), its possible we may be waking up the rq->donor. When we do this, we proxy_resched_idle() to put_prev_set_next() setting the rq->donor to rq->idle, allowing the rq->donor to be return migrated and allowed to run. This however runs into trouble, as on another cpu we might be in the middle of calling __schedule(). Conceptually the rq lock is held for the majority of the time, but in calling prev_balance() its possible the class->balance() handler call may briefly drop the rq lock. This opens a window for try_to_wake_up() to wake and return migrate the rq->donor before the class logic reacquires the rq lock. Unfortunately prev_balance() pass in a prev argument, to which we pass rq->donor. However this prev value can now become stale and incorrect across a rq lock drop. So, to correct this, rework the prev_balance() call so that it does not take a "prev" argument. Signed-off-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260512025635.2840817-2-jstultz@google.com Backport adaptation for 6.18: Keep the existing sched_class::pick_next_task callbacks, pick_task interfaces, SCX balancing setup and proxy-execution flow. The later upstream scheduler refactors and lock annotations are not prerequisites for this dependency. Convert all six balance callbacks, including the fair and SCX callbacks still present here, to the new signature. Read rq->donor at the existing selection and balance call sites, and refresh prev after new-idle balancing in pick_next_task_fair() because that path still drops the rq lock inside the stable pick_next_task implementation. This preserves the existing functions and supplies the selection context needed for f3629c63a4af (sched/core: Make core-sched flips wait for in-flight selections) to apply without changes. Stable-dep-of: f3629c63a4af ("sched/core: Make core-sched flips wait for in-flight selections") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c522333c35d483123e365ed0ae4ea34ff5e6c06f Author: John Stultz Date: Wed Sep 9 05:26:29 2026 -0400 sched: Add assert_balance_callbacks_empty helper [ Upstream commit f9530b3183358bbf945f7c20d4a6e2048061ec50 ] With proxy-exec utilizing pick-again logic, we can end up having balance callbacks set by the preivous pick_next_task() call left on the list. So pull the warning out into a helper function, and make sure we check it when we pick again. Suggested-by: Peter Zijlstra Signed-off-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: K Prateek Nayak Link: https://patch.msgid.link/20260324191337.1841376-8-jstultz@google.com Stable-dep-of: f3629c63a4af ("sched/core: Make core-sched flips wait for in-flight selections") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c97be9d5ab04c7e26bc1671c551289b0d951d6c0 Author: Tejun Heo Date: Wed Sep 9 05:26:27 2026 -0400 sched_ext: Fix inverted ops.core_sched_before() invocation [ Upstream commit f7b6d128dd49a6eec09066ecfd29095f12588786 ] scx_prio_less() implements prio_less() semantics - %true means that @a is the lower priority and should run after @b. ops.core_sched_before() is documented to return %true when @a should run before @b. scx_prio_less() returns the op's value as-is, inverting the documented semantics at runtime. Call the op with the arguments swapped. scx_qmap followed the wiring instead of the documentation and returned %true for the younger task, so the two inversions canceled out and it behaved as intended. Flip its comparison to match. scx_qmap is likely the only current user in or out of the kernel tree. Any scheduler written the same way needs the same flip, while schedulers following the documentation are fixed by this change. Fixes: 7b0888b7cc19 ("sched_ext: Implement core-sched support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Tejun Heo [ adapted kernel/sched/ext/ext.c changes to the older kernel/sched/ext.c layout ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c4ade059aaeb51fdb3f4ae71e1ea3e2019b85178 Author: Linkai Gong Date: Wed Sep 9 05:26:10 2026 -0400 scsi: fnic: Use GFP_ATOMIC for VLAN alloc under spinlock [ Upstream commit 9639c6324524ea3f934908bd51f02430000954ab ] fnic_fcoe_process_vlan_resp() allocates a VLAN descriptor with kzalloc_obj() (default GFP_KERNEL) while holding vlans_lock via spin_lock_irqsave(). GFP_KERNEL may sleep, which is not allowed in this atomic context and can trigger a sleeping-from-invalid-context warning or deadlock. Pass GFP_ATOMIC so the allocation is safe under the IRQ-safe spinlock. Fixes: 098585aa8aca ("scsi: fnic: Add and integrate support for FIP") Cc: stable@vger.kernel.org Signed-off-by: Linkai Gong Reviewed-by: Karan Tilak Kumar Link: https://patch.msgid.link/20260731073820.16449-1-gonglinkai@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) [ adapted kzalloc_obj(*vlan, GFP_ATOMIC) to kzalloc(sizeof(*vlan), GFP_ATOMIC). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c98197ee3cd28288da13dc9881bb9e74daa7cbbc Author: Abhijit Gangurde Date: Wed Sep 9 05:25:57 2026 -0400 RDMA/ionic: Embed counter driver data in rdma_counter allocation [ Upstream commit cf3ebd89e754015625fee90aa938f6bc79a2c974 ] Commit 7e53b31acc7f ("RDMA/core: Create and destroy rdma_counter using rdma_zalloc_drv_obj()") requires drivers implementing counter ops to embed struct rdma_counter in a driver-specific struct, register its size via INIT_RDMA_OBJ_SIZE, and provide a counter_init callback. The ionic driver was merged without this adaptation, causing a NULL pointer dereference in alloc_and_bind() since rdma_zalloc_drv_obj() allocates zero bytes when size_rdma_counter is unset. Consolidate struct ionic_counter into a new struct ionic_rdma_counter that embeds struct rdma_counter, replace the xarray with a lightweight ida for ID allocation, and add the required counter_init and INIT_RDMA_OBJ_SIZE declarations. Fixes: ea4c399642b8 ("RDMA/ionic: Implement device stats ops") Cc: stable@vger.kernel.org # 6.18 Signed-off-by: Abhijit Gangurde Link: https://patch.msgid.link/20260805053254.4023262-2-abhijit.gangurde@amd.com Signed-off-by: Leon Romanovsky [ adapted kzalloc_obj(*cntr) removal to the older kzalloc(sizeof(*cntr), GFP_KERNEL) allocation. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 27b7b0dacae79ab0476d7b32abd023b46e34cd93 Author: fangqiurong Date: Tue Sep 8 21:53:44 2026 -0400 sched_ext: Fix exit_task leak on fork failure during enable [ Upstream commit 03506edca637a8465dba9f635c50e9884fbcaf4e ] scx_fork() initializes tasks when scx_init_task_enabled is set, but scx_cancel_fork() only exits them when scx_enabled() is true. A fork that fails in the enable window (between releasing scx_fork_rwsem and setting __scx_enabled) runs ops.init_task() but never ops.exit_task(). Gate scx_cancel_fork() on scx_init_task_enabled. Fixes: 4269c603cc26 ("sched_ext: Enable scx_ops_init_task() separately") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: fangqiurong Signed-off-by: Tejun Heo [ Adjusted the target file path from kernel/sched/ext/ext.c to kernel/sched/ext.c. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1a3af2262cb384112ef38632de4690682be528b4 Author: Chuck Lever Date: Tue Sep 8 20:52:01 2026 -0400 svcrdma: Reject Read lists that exceed the page budget [ Upstream commit 0ca487abb3bdf581851664b5db21f364caf57682 ] Individual Read segment lengths are validated at decode time, but nothing prevents a requester from sending multiple segments whose cumulative length exceeds the rq_pages array budget. When one segment fills the page array exactly, the runtime guard in svc_rdma_build_read_segment() is bypassed because len reaches zero. A subsequent segment then accesses the NULL sentinel slot at rq_pages[rq_maxpages], resulting in a NULL pointer dereference during DMA mapping. Accumulate pages across all Read segments and reject the message at decode time when the total would overflow the page budget. Fixes: 026d958b38c6 ("svcrdma: Add recvfrom helpers to svc_rdma_rw.c") Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 59bcf1b38f89879e0a41aecb152f1b076c4b6ac6 Author: Chuck Lever Date: Tue Sep 8 20:52:00 2026 -0400 svcrdma: Reject oversized Read segments at decode time [ Upstream commit af6f0e06bed818ee7fc8b869915964410020a1c5 ] The RPC/RDMA Read list decoder stores wire-supplied segment lengths without validation. xdr_count_read_segments() checks 4-byte alignment for non-zero position values but does not cap the segment length. An oversized rs_length reaches svc_rdma_build_read_segment(), which derives nr_bvec from it and can drive a large dynamic bvec allocation before verifying that enough rq_pages remain. If the post-allocation page-overrun guard fires, the freshly acquired rw context is not returned, leaking the resource. Reject any segment whose length exceeds the receive context's page budget during Read list decoding, consistent with how xdr_check_write_chunk() bounds Write segment counts against rc_maxpages. Also return the rw context on the existing post-allocation overrun path in svc_rdma_build_read_segment(), keeping that defensive guard balanced. Fixes: 5ee62b4a9113 ("svcrdma: use bvec-based RDMA read/write API") Cc: stable@vger.kernel.org Acked-by: Jeff Layton Link: https://patch.msgid.link/20260526-rpc-kernel-bugs-v1-3-e251306ccca9@oracle.com Signed-off-by: Chuck Lever Stable-dep-of: 0ca487abb3bd ("svcrdma: Reject Read lists that exceed the page budget") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3c97b8e76ca2bba9e8770571413aed694068e78e Author: Chuck Lever Date: Tue Sep 8 19:21:09 2026 -0400 rpcrdma: arm rn_done before publishing the notification [ Upstream commit 5b06f706374c37375bdff9d21cc10e61df925a92 ] rpcrdma_rn_register() inserts @rn into rd_xa with xa_alloc() before storing the caller's callback in rn->rn_done. The xarray makes @rn reachable to rpcrdma_remove_one(), which walks rd_xa and invokes rn->rn_done(rn) for every registered notification. A device removal that races a fresh registration can therefore observe @rn with rn_done still NULL, because the notification objects are zero allocated by their owners, and call through a NULL function pointer. Store rn->rn_done before xa_alloc() publishes @rn. The xarray's store-side and load-side ordering then guarantees that any CPU which finds @rn in rd_xa also observes the armed callback. rpcrdma_rn_unregister() treats a non-NULL rn_done as the sentinel for a completed registration, so the early store must not survive a failed registration. Clear rn_done again when xa_alloc() fails. Were it left set, the failed-accept cleanup path would call rpcrdma_rn_unregister() on an @rn that was never inserted, erasing an unrelated rd_xa slot and underflowing rd_kref. Fixes: 7e86845a0346 ("rpcrdma: Implement generic device removal") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260601201703.46078-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9f2f5d0999364c7070306cd422d8babc2621070d Author: Chuck Lever Date: Tue Sep 8 19:19:28 2026 -0400 svcrdma: Reorder rpcrdma_rn_unregister before rdma_destroy_id [ Upstream commit 4488e912973773d64368828acf3b8e39d93650ae ] svc_rdma_free() caches rdma->sc_cm_id->device before teardown, then calls rdma_destroy_id(sc_cm_id) which frees the cm_id. rpcrdma_rn_unregister() follows, but between those two calls the transport's sc_rn entry is still installed in the device's rd_xa. A concurrent ib_unregister_device walk can dispatch svc_rdma_xprt_done() against the now-freed sc_cm_id. Move rpcrdma_rn_unregister() before rdma_destroy_id() so the transport's notification entry is removed from the xarray before the cm_id it references is destroyed. Also guard the sc_cm_id dereference with a NULL check: the following patches introduce paths that reach svc_rdma_free() with sc_cm_id == NULL (listener create failure, ADDR_CHANGE replacement failure). Fixes: c4de97f7c454 ("svcrdma: Handle device removal outside of the CM event handler") Cc: stable@vger.kernel.org Acked-by: Jeff Layton Link: https://patch.msgid.link/20260527-rdma-follow-on-v1-2-1b09bd87b6cd@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ee7f6e5600ae163b08e825185d9cd488e7d5b4be Author: Chuck Lever Date: Tue Sep 8 19:19:27 2026 -0400 svcrdma: Release transport resources synchronously [ Upstream commit bf94dea7fd4e6708d1a784be23db65eff84d82f1 ] NFSD has always supported added network listeners. The new netlink protocol now enables the removal of listeners. Olga noticed that if an RDMA listener is removed and immediately re-added, the deferred __svc_rdma_free() function might not have run yet, so some or all of the old listener's RDMA resources linger, which prevents a new listener on the same address from being created. Also, svc_xprt_free() does a module_put() just after calling ->xpo_free(). That means if there is deferred work going on, the module could be unloaded before that work is even started, resulting in a UAF. Neil asks: > What particular part of __svc_rdma_free() needs to run in order for a > subsequent registration to succeed? > Can that bit be run directory from svc_rdma_free() rather than be > delayed? > (I know almost nothing about rdma so forgive me if the answers to these > questions seems obvious) The reasons I can recall are: - Some of the transport tear-down work can sleep - Releasing a cm_id is tricky and can deadlock We might be able to mitigate the second issue with judicious application of transport reference counting. Reported-by: Olga Kornievskaia Closes: https://lore.kernel.org/linux-nfs/20250821204328.89218-1-okorniev@redhat.com/ Suggested-by: NeilBrown Signed-off-by: Chuck Lever Stable-dep-of: 4488e9129737 ("svcrdma: Reorder rpcrdma_rn_unregister before rdma_destroy_id") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3ff45361e9469e85c0f86b8e7b82c63e50bab8ef Author: Chris Mason Date: Tue Sep 8 15:28:25 2026 -0400 SUNRPC: fix gssx_dec_option_array error path bugs [ Upstream commit 5e9a94539b1ec17a89177d952badfd0d844d694a ] Four coupled defects in the gssx XDR option-array decoder make the error paths unsafe: a NULL deref in the caller, a refcount leak on the decoded group_info, and a latent use-after-free that the leak fix would otherwise expose. gssx_dec_option_array() sets oa->count = 1 before allocating oa->data. If that allocation fails, -ENOMEM is returned with oa->count == 1 and oa->data == NULL. All other error paths jump to free_oa: which frees oa->data and NULLs it but also leaves oa->count == 1. The caller trusts the count: gssp_accept_sec_context_upcall() gssx_dec_accept_sec_context() gssx_dec_option_array() /* fails, count=1 data=NULL */ data = res.options.data[0].value /* NULL deref */ Independently, free_creds: releases the partially decoded svc_cred with a bare kfree(creds). gssx_dec_linux_creds() installs a groups_alloc() result into creds->cr_group_info; that object is kvmalloc-backed and refcounted, and only put_group_info() reaches kvfree(). A plain kfree(creds) drops the wrapper and leaks the group_info allocation. The natural fix for the leak is to call free_svc_cred(creds) before kfree(creds), but free_svc_cred() invokes put_group_info() on creds->cr_group_info unconditionally when non-NULL. The existing out_free_groups: path in gssx_dec_linux_creds() already called groups_free() on that pointer without clearing it, so once free_svc_cred() is wired in, the subsequent put_group_info() would touch freed memory. Fix all four together: - Move the oa->count = 1 assignment below the oa->data allocation so it is never set when oa->data is NULL. - Reset oa->count to 0 at free_oa: so count and data stay coherent and the caller sees an empty option array. - Call free_svc_cred(creds) before kfree(creds) at free_creds: so the refcounted cr_group_info is released. free_svc_cred() either NULL-guards each field explicitly (cr_group_info has an if() check) or delegates to a helper that is NULL-safe itself (kfree for the string fields, gss_mech_put() which guards with if(gm) at gss_mech_switch.c:342), so it is safe to call on a partially decoded svc_cred where only cr_uid/cr_gid/cr_group_info have been written and everything else is zero from kzalloc. - In gssx_dec_linux_creds()'s out_free_groups: path, release cr_group_info with put_group_info() rather than groups_free() so the teardown matches free_svc_cred()'s refcount-aware path, and clear the pointer so a later free_svc_cred() on the same creds does not release it a second time. Fixes: 3cfcfc102a5e ("SUNRPC: fix some memleaks in gssx_dec_option_array") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260528-tier2-v1-2-d026a1415e0b@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5563db13c9528a56c7161260ec75ec8690dc5608 Author: Dave Jiang Date: Tue Sep 8 12:01:37 2026 -0400 cxl/mce: Make the MCE notifier per-region [ Upstream commit 775d0f4558f4cec0ee0c8966595d1add1791f36e ] Flavien Solt reported lifetime issues with the CXL MCE notifier, which can lead to NULL dereferences and use-after-free in the MCE handler. The notifier was registered per memory device and stored in 'struct cxl_memdev_state', even though it only needs the region state (the region's SPA range and its extended linear cache size). Instead of keeping the memory device and endpoint alive, the correct fix is to move the notifier into 'struct cxl_region' and register it from cxl_region_probe() as it should be a per-region notifier. Setup the registration to only happen for regions that have an extended linear cache as that is the only current usage. Remove cxl_port_get_spa_cache_alias() as it is now dead code. [ dj: Update dev_warn() when notifier fails due to kconfig. (Ben) ] Reported-by: Flavien Solt Suggested-by: Dan Williams Fixes: 516e5bd0b6bf ("cxl: Add mce notifier to emit aliased address for extended linear cache") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Alison Schofield Reviewed-by: Ben Cheatham Link: https://patch.msgid.link/20260616224912.2567474-1-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 513a9613f7a638f31afbabea1ac809bfc8bb0437 Author: Smita Koralahalli Date: Tue Sep 8 12:01:36 2026 -0400 cxl/region: Add helper to check Soft Reserved containment by CXL regions [ Upstream commit 8e65f99b525b3f49b87db0db0d0e0fc1a0c53e40 ] Add a helper to determine whether a given Soft Reserved memory range is fully contained within the committed CXL region. This helper provides a primitive for policy decisions in subsequent patches such as co-ordination with dax_hmem to determine whether CXL has fully claimed ownership of Soft Reserved memory ranges. Signed-off-by: Smita Koralahalli Reviewed-by: Jonathan Cameron Reviewed-by: Dave Jiang Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260322195343.206900-8-Smita.KoralahalliChannabasappa@amd.com Signed-off-by: Dan Williams Signed-off-by: Dave Jiang [ sashal: Reduced backport -- upstream 8e65f99b525b3 touches 2 file(s), this backport carries 2. Not backported here: include/cxl/cxl.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 775d0f4558f4 ("cxl/mce: Make the MCE notifier per-region") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 040cface98ffd8b397943ca10ad8e6ee1c5a5624 Author: Dan Williams Date: Tue Sep 8 12:01:35 2026 -0400 dax/cxl, hmem: Initialize hmem early and defer dax_cxl binding [ Upstream commit 39aa1d4be12bf9f685adaa06aa2d997c1c611b16 ] Move hmem/ earlier in the dax Makefile so that hmem_init() runs before dax_cxl. In addition, defer registration of the dax_cxl driver to a workqueue instead of using module_cxl_driver(). This ensures that dax_hmem has an opportunity to initialize and register its deferred callback and make ownership decisions before dax_cxl begins probing and claiming Soft Reserved ranges. Mark the dax_cxl driver as PROBE_PREFER_ASYNCHRONOUS so its probe runs out of line from other synchronous probing avoiding ordering dependencies while coordinating ownership decisions with dax_hmem. Signed-off-by: Smita Koralahalli Reviewed-by: Dave Jiang Reviewed-by: Jonathan Cameron Tested-by: Tomasz Wolski Link: https://patch.msgid.link/20260322195343.206900-6-Smita.KoralahalliChannabasappa@amd.com Signed-off-by: Dan Williams Signed-off-by: Dave Jiang Stable-dep-of: 775d0f4558f4 ("cxl/mce: Make the MCE notifier per-region") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dfc86b0c2698e0a48acb050fc1cb18d83a763f83 Author: Terry Bowman Date: Tue Sep 8 09:26:31 2026 -0400 cxl/ras: Fix cxl_rch_get_aer_severity() wrong severity register [ Upstream commit 9d399526128bae184b153deab42b49f5f3eea2ed ] cxl_rch_get_aer_severity() classifies RCH Downstream Port uncorrectable errors as fatal or non-fatal by ANDing uncorrectable status with PCI_ERR_ROOT_FATAL_RCV. This is wrong because PCI_ERR_ROOT_FATAL_RCV is a Root Error Status register bit (bit 6), not a severity bit. ANDing it against uncorrectable status tests a reserved bit and produces incorrect severity classification. Fix by ANDing the unmasked uncor_status against uncor_severity. Per PCIe Base Spec r6.0 Section 7.8.4.4, each bit in the Uncorrectable Error Severity register indicates whether the corresponding error is fatal (1) or non-fatal (0). Fixes: 6ac07883dbb5 ("cxl/pci: Add RCH downstream port error logging") Cc: stable@vger.kernel.org Signed-off-by: Terry Bowman Reviewed-by: Jonathan Cameron Reviewed-by: Dave Jiang Reviewed-by: Richard Cheng Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260803221810.3685703-3-terry.bowman@amd.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ccf481d73bce6e851cec364fe831c86fe66877cf Author: Jiri Olsa Date: Tue Sep 8 09:12:09 2026 -0400 bpf: Disable preemption in bpf_get_stackid [ Upstream commit 15f1bd8574662f1b7b26aaa2e23ebf4066f0117d ] The get_perf_callchain call needs disabled preemption plus we need it disabled as long as we access its returned trace entries buffer. Note the bpf_get_stackid_pe function is executed already with preemption disabled. Fixes: d5a3b1f69186 ("bpf: introduce BPF_MAP_TYPE_STACK_TRACE") Reported-by: Tao Chen Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260803210149.296496-6-jolsa@kernel.org Closes: https://lore.kernel.org/bpf/20260206090653.1336687-2-chen.dylane@linux.dev/ [ adapted get_perf_callchain() to the older six-argument form ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b466ff95324f8fd093bb2127c4b89fa34a5473f7 Author: Jiri Olsa Date: Tue Sep 8 09:12:08 2026 -0400 bpf: Use stack id functions instead of __bpf_get_stackid [ Upstream commit 09b3fd6caa0b57f8a39254ee5db3af30bdd53c18 ] Replacing __bpf_get_stackid calls with sequence of following functions: stackid_fastpath stackid_new_bucket stackid_install This makes code more structured and allows us to easily disable preemption only in bpf_get_stackid in following changes. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-5-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 73ebef25aec4936743d647bde0649563eddc7914 Author: Jiri Olsa Date: Tue Sep 8 09:12:07 2026 -0400 bpf: Factor stackid_new_bucket from __bpf_get_stackid [ Upstream commit bb4e6f4e1b68fe60c04ca04c564c6624e837dbf4 ] The new stackid_new_bucket allocates the new bucket and initializes it with the trace data. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-4-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba1e22a224c39fcbfb5e40070455ed69b9e2d561 Author: Jiri Olsa Date: Tue Sep 8 09:12:06 2026 -0400 bpf: Factor stackid_fastpath function from __bpf_get_stackid [ Upstream commit 0ca56befcffec3a6c9d1842eae06c74e1cf41f11 ] The new stackid_fastpath does the fast stack hash and trace check, that does not need new bucket allocation. It covers both just-ip and buildid code paths. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-3-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 201a381bef3ac4e2b2d36acbb0db25b8feb701e8 Author: Jiri Olsa Date: Tue Sep 8 09:12:05 2026 -0400 bpf: Factor stackid_init function from __bpf_get_stackid [ Upstream commit 15b837759a97237d647962f9943afe0d55af615a ] The new stackid_init function stores all the necessary bits for stackid trace and it will be used by other functions in following changes. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-2-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7c19b94c625dc7042b0a7dff4c8da158358ffa2c Author: Haoxiang Li Date: Tue Sep 8 08:58:56 2026 -0400 cpufreq: apple-soc: Fix OPP table cleanup [ Upstream commit d87cb889dc7ab1f2deecadf2a5e9023184bd7900 ] apple_soc_cpufreq_init() adds OPP tables from firmware, but some failure paths do not remove them. The driver also uses dev_pm_opp_remove_all_dynamic(), which is not the right cleanup helper for OPP tables loaded from firmware. Use the cpumask OPP helper after the policy CPU mask has been populated. Pair it with the matching cpumask remove helper on failure paths and in apple_soc_cpufreq_exit(). This also removes the separate dev_pm_opp_set_sharing_cpus() call, as the cpumask helper loads the DT OPP tables for all CPUs in the policy. Fixes: 6286bbb40576 ("cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Viresh Kumar [ retained kzalloc(sizeof(*priv), GFP_KERNEL) instead of upstream kzalloc_obj(*priv) ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e989cede44392262d0560413558b9c6a71313387 Author: Rafael J. Wysocki Date: Tue Sep 8 08:20:04 2026 -0400 ACPI: TAD: Add locking around AML evaluations [ Upstream commit a3df8bbe0a704fa5c1609b9666b594f350558fe0 ] In the ACPI TAD driver, there are hidden assumptions that the ACPI control methods used by it will not be evaluated concurrently due to ACPICA namespace and interpreter locking. However, that may not be the case since ACPICA may drop and re-acquire the namespace and interpreter locks during the evaluation of a given object in a few cases, including the one in which the AML in question sleeps causing acpi_ex_system_do_sleep() to be called. In that case, the evaluation of one control method may be started while the evaluation of another one is still in progress. For this reason, add a global lock to the ACPI TAD driver and acquire it every time before evaluating an ACPI control method, except for the initial evaluation of _GCP in acpi_tad_probe(). Fixes: 95c513ec84f7 ("ACPI: Add Time and Alarm Device (TAD) driver") Cc: All applicable Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/12951141.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dd440f6a2e67f807c8a76c2d57d922e5c5ac6f0b Author: Rafael J. Wysocki Date: Tue Sep 8 08:20:03 2026 -0400 ACPI: TAD: Rearrange RT data validation checking [ Upstream commit 3329a1416c3350449081ca5daaa94802a65b2992 ] Move RT data validation checks from acpi_tad_set_real_time() to a separate function called acpi_tad_rt_is_invalid() and use it also in acpi_tad_get_real_time() to validate data coming from the platform firmware. Also make acpi_tad_set_real_time() return -EINVAL when the RT data passed to it is invalid (instead of -ERANGE which is somewhat confusing) and introduce ACPI_TAD_TZ_UNSPEC to represent the "unspecified timezone" value. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3409319.aeNJFYEL58@rafael.j.wysocki Stable-dep-of: a3df8bbe0a70 ("ACPI: TAD: Add locking around AML evaluations") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0a7a192862232983322f5aaf0b934ae952570d65 Author: Rafael J. Wysocki Date: Tue Sep 8 08:20:02 2026 -0400 ACPI: x86/rtc-cmos: Use platform device for driver binding [ Upstream commit 2a78e42104444f948698f1225deaf515e9b7224d ] Modify the rtc-cmos driver to bind to a platform device on systems with ACPI via acpi_match_table and advertise the CMOST RTC ACPI device IDs for driver auto-loading. Note that adding the requisite device IDs to it and exposing them via MODULE_DEVICE_TABLE() is sufficient for this purpose. Since the ACPI device IDs in question are the same as for the CMOS RTC ACPI scan handler, put them into a common header file and use the definition from there in both places. Additionally, to prevent a PNP device from being created for the CMOS RTC if a platform one is present already, make is_cmos_rtc_device() check cmos_rtc_platform_device_present introduced previously. Signed-off-by: Rafael J. Wysocki Acked-by: Alexandre Belloni Link: https://patch.msgid.link/13969123.uLZWGnKmhe@rafael.j.wysocki Stable-dep-of: a3df8bbe0a70 ("ACPI: TAD: Add locking around AML evaluations") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ec2d81115485de3f604f86edc4d9119a213a59bf Author: Rafael J. Wysocki Date: Tue Sep 8 08:20:01 2026 -0400 ACPI: x86: cmos_rtc: Create a CMOS RTC platform device [ Upstream commit 1ae2f435350ec05224a39995c3a680aa6fdae5a5 ] Make the CMOS RTC ACPI scan handler create a platform device that will be used subsequently by rtc-cmos for driver binding on x86 systems with ACPI and update add_rtc_cmos() to skip registering a fallback platform device for the CMOS RTC when the above one has been registered. Signed-off-by: Rafael J. Wysocki Acked-by: Dave Hansen # x86 Link: https://patch.msgid.link/1962427.tdWV9SEqCh@rafael.j.wysocki Stable-dep-of: a3df8bbe0a70 ("ACPI: TAD: Add locking around AML evaluations") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f2e08c3f994c9c342cb13270c3a8a5d92efd983e Author: Christian Loehle Date: Mon Sep 7 21:38:44 2026 -0400 ACPI: CPPC: Reject desired_perf reads on _CPC revision 4+ [ Upstream commit df5a1d4a8cdfda20eb2581a85e81c7d436866534 ] When CPPC feedback counters cannot provide a usable sample, cppc-cpufreq calls cppc_get_desired_perf() because some platforms repurpose Desired Performance to report actual delivered performance. ACPI 6.5 defines _CPC revision 3 and lists Read/Write as the Optional Attribute of Desired Performance. ACPI 6.6 advances _CPC to revision 4 and lists only Write, so invoking that workaround for revision 4 or later would require a register read that the interface no longer specifies. Make cppc_get_desired_perf() return -EOPNOTSUPP for _CPC revision 4 or later. Use the revision retained in the per-CPU CPC descriptor rather than the platform-wide FADT revision. The _CPC revision may still not accurately describe the implemented register semantics. If a nominally revision 3 platform implements a non-readable Desired Performance register, a read may return zero and make cppc_cpufreq_get_rate() report 0 kHz. Treat a zero read as unusable and fall back to the cached OSPM request, just as for a failed read. Fixes: c47195631960 ("cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged") Cc: stable@vger.kernel.org Suggested-by: Sumit Gupta Signed-off-by: Christian Loehle Link: https://patch.msgid.link/20260803203531.1268651-2-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki [ preserved the raw firmware revision while limiting parsing to the v3-sized register prefix ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7267557ce98ccd07faaf3bc86382448950cc4ff6 Author: Nikhil Gurudasani Date: Mon Sep 7 21:01:03 2026 -0400 erofs: skip sufficiently large global buffers when resizing [ Upstream commit a7d097cf01301c5da37927c8f26123d006f0fd8a ] z_erofs_gbuf_nrpages is advanced only after every global buffer has been grown. If a resize fails after some buffers were enlarged, a retry revisits those enlarged buffers. Retrying the same size then returns -ENOMEM because alloc_pages_bulk() has no pages to add and the unchanged return value is treated as a failure. Retrying an intermediate size allocates a temporary pointer array smaller than gbuf->nrpages and copies more existing pointers than the array can hold. Skip buffers that already satisfy the request. Once all remaining buffers have caught up, advancing z_erofs_gbuf_nrpages again describes the guaranteed minimum size across the pool. Fixes: d6db47e571dc ("erofs: do not use pagepool in z_erofs_gbuf_growsize()") Cc: stable@vger.kernel.org # 6.10+ Signed-off-by: Nikhil Gurudasani Reviewed-by: Gao Xiang Reviewed-by: Chao Yu Signed-off-by: Gao Xiang [ preserved the existing kcalloc() allocation instead of upstream kzalloc_objs() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 03c34309eb1bce1b3b5f7c4a94b703f419120383 Author: Jiangshan Yi Date: Mon Sep 7 17:36:33 2026 -0400 HID: mcp2221: clear rxbuf after I2C/SMBus transfer completes [ Upstream commit db2333f88729c8aae062cb171ed058725ff5c901 ] mcp_i2c_smbus_read() stores the caller-supplied buffer pointer in mcp->rxbuf for the duration of a transfer but never clears it when the transfer finishes or times out. Once the caller frees or reuses the buffer, mcp->rxbuf becomes a dangling pointer. A delayed or spurious MCP2221_I2C_GET_DATA report can then drive mcp2221_raw_event() to memcpy device data into the freed memory, causing a write use-after-free. Route all return paths through a single exit point that clears mcp->rxbuf and mcp->rxbuf_size, so that the existing !mcp->rxbuf guard in the raw_event handler can reject any report arriving after the transfer has ended. Fixes: 67a95c21463d ("HID: mcp2221: add usb to i2c-smbus host bridge") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1a503fbb116dae0e73fcb4f904b1fb6b19cd3377 Author: Florian Pradines Date: Mon Sep 7 17:36:32 2026 -0400 HID: mcp2221: fix OOB write in mcp2221_raw_event() [ Upstream commit f097d246677b03db814c5862f368cea341b76a00 ] mcp2221_raw_event() copies device-supplied data into mcp->rxbuf at offset rxbuf_idx without checking that the copy fits within the destination buffer. A device responding with up to 60 bytes to a small I2C/SMBus read can overflow the buffer. Add a rxbuf_size field to struct mcp2221, set it alongside rxbuf in mcp_i2c_smbus_read(), and check rxbuf_idx + data[3] <= rxbuf_size before the memcpy. Reported-by: Benoît Sevens Signed-off-by: Florian Pradines Signed-off-by: Jiri Kosina Stable-dep-of: db2333f88729 ("HID: mcp2221: clear rxbuf after I2C/SMBus transfer completes") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3b4709e4864908bb06c48c500cc8db8d3d55d139 Author: Doruk Tan Ozturk Date: Mon Sep 7 16:00:36 2026 -0400 HID: sony: clean up device list on probe failure [ Upstream commit 7c65699a3a311198a07659a614fe64d45924839e ] sony_input_configured() adds some controllers to sony_device_list before HID core registers their input devices. input_register_device() can fail after the callback returns successfully. sony_probe() then observes that HID_CLAIMED_INPUT is clear and unwinds, but only stops the HID hardware. The devres-managed sony_sc is freed while its list node remains linked, so the next matching controller traverses freed memory. Initialize the list node and device ID to inactive states. Make list removal idempotent and run the driver-private cleanup on every probe failure path. This also makes a second cleanup safe when sony_input_configured() already unwound a partial initialization before sony_probe() handles the missing input claim. Found by 0sec (https://0sec.ai) using automated source analysis; verified against the HID input registration and probe unwind paths. Fixes: 4f967f6d7374 ("HID: sony: Fix memory issue when connecting device using both Bluetooth and USB") Cc: stable@vger.kernel.org Reported-by: Doruk Tan Ozturk Link: https://lore.kernel.org/linux-input/20260724143925.007D61F00A3A@smtp.kernel.org/ Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a15def9a6311e85a01fa41dddbb255ce2eddb581 Author: Rosalie Wanders Date: Mon Sep 7 16:00:35 2026 -0400 HID: sony: use guard() and scoped_guard() [ Upstream commit da4f817ad273bca9aefd8636d347a8c101069111 ] This replaces the spin_lock_irqsave() and spin_unlock_irqrestore() calls with the RAII guard() and scoped_guard(). Signed-off-by: Rosalie Wanders Signed-off-by: Jiri Kosina Stable-dep-of: 7c65699a3a31 ("HID: sony: clean up device list on probe failure") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d2dd2cced65bc4b0523b19070d5811123ffdd350 Author: Frank Sorenson Date: Sun Sep 6 15:30:52 2026 -0400 cifs: add cifs_resize_file_locked() to guard fscache_resize_cookie() under i_rwsem [ Upstream commit 32a7af68df7361fe7cf153cf36124d04b94aec00 ] cifs_setsize() calls fscache_resize_cookie() without holding i_rwsem. When the fscache cookie is active (FSCACHE_COOKIE_IS_CACHING is set), fscache_resize_cookie() performs a real resize that requires i_rwsem held exclusively. If another file descriptor has the same inode open, fscache_use_cookie() was already called from that cifs_open(), making the cookie active. In that case, calling cifs_setsize() from cifs_do_truncate() (invoked from cifs_open() without i_rwsem) races against concurrent fscache I/O. Strip fscache_resize_cookie() from cifs_setsize(), making it a pure size/page-cache helper. Add cifs_resize_file_locked() for callers that already hold i_rwsem: it calls netfs_resize_file() and cifs_setsize(), then temporarily activates the cookie with fscache_use_cookie() to perform the resize under the lock, then deactivates it with cifs_fscache_unuse_inode_cookie(). Using fscache_use_cookie() before the resize ensures correctness whether or not another fd already holds the cookie active. Switch cifs_file_set_size(), smb2_duplicate_extents(), and both size- extension branches of smb3_simple_falloc() to the new wrapper; those paths already hold i_rwsem via VFS setattr, lock_two_nondirectories(), or cifs_fallocate() respectively. cifs_do_truncate() continues to call cifs_setsize() followed by cifs_invalidate_cache(), since it runs without i_rwsem. Fixes: fa724e235cfd ("cifs: add fscache_resize_cookie() to cifs_setsize()") Cc: stable@vger.kernel.org Cc: David Howells Cc: Paulo Alcantara Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 85d239160dc1b9ad7cae64aad760fb926ec9e33c Author: Huiwen He Date: Sun Sep 6 15:30:51 2026 -0400 smb/client: emulate small EOF-extending mode 0 fallocate ranges [ Upstream commit 7a06d3b816d73448b4e38b83d65049f090b7b201 ] When a mode 0 fallocate extends EOF from 1G to 2G + 1M, the client currently sends SetEOF for 2G + 1M. This can make fallocate return success without allocating the requested range, or allocate extra space before that range. For example, on a fresh file: xfs_io -f \ -c "falloc 0 1G" \ -c "falloc 2G 1M" \ -c "truncate 3G" test The second fallocate should allocate [2G, 2G + 1M), leaving [1G, 2G) as a hole. Before this change, the result depended on the server allocation policy. With Samba "strict allocate = no", SetEOF could return success without allocating [2G, 2G + 1M). With "strict allocate = yes": # filefrag -v test [0, 1G) allocated [1G, 2G) allocated unexpectedly [2G, 2G + 1M) allocated SMB cannot allocate that arbitrary range, so write zeroes to small EOF-extending ranges instead. Limit this to 1 MiB to bound the client-side I/O cost. With "strict allocate = no", the requested range [2G, 2G + 1M) is allocated by the writes. With "strict allocate = yes": # filefrag -v test [0, 1G) allocated [1G, 2G) hole [2G, 2G + 1M) allocated This fixes the small EOF-extending range case exercised by generic/213. Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Stable-dep-of: 32a7af68df73 ("cifs: add cifs_resize_file_locked() to guard fscache_resize_cookie() under i_rwsem") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 41f4c997873988e3d184bb1328410ef9423880df Author: Huiwen He Date: Sun Sep 6 15:30:50 2026 -0400 smb/client: reduce fallocate zero buffer allocation [ Upstream commit 9e4ec3be67af41ab859302d7109b34976efd9258 ] The fallocate emulation allocates a 1 MiB zero-filled buffer even though each SMB2_write request is limited to SMB2_MAX_BUFFER_SIZE, which is 64 KiB. A high-order 1 MiB allocation is more likely to fail on a fragmented system. Allocate only the smaller of the requested range and SMB2_MAX_BUFFER_SIZE, and reuse that zero-filled buffer for every write request. Also reject a successful write that makes no progress to avoid looping indefinitely. This reduces the contiguous allocation required by fallocate emulation without changing the written data or range semantics. Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Stable-dep-of: 32a7af68df73 ("cifs: add cifs_resize_file_locked() to guard fscache_resize_cookie() under i_rwsem") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c2ae13662137c822c9192be902b942393e28524b Author: ZhangGuoDong Date: Sun Sep 6 15:30:49 2026 -0400 smb: move some definitions from common/smb2pdu.h into common/fscc.h [ Upstream commit a5e581093b1d9321cbb627dd8c209d0d4e0a988a ] These definitions are specified in MS-FSCC, so move them into fscc.h. Only add some documentation references, no other changes. Signed-off-by: ZhangGuoDong Reviewed-by: ChenXiaoSong Reviewed-by: Steve French Acked-by: Namjae Jeon Signed-off-by: Steve French The original header relocation is not applicable to this stable tree: fscc.h is absent and the relevant definitions are already kept in smb2pdu.h. For this stable-only dependency adaptation, prepare the existing fallocate paths for EOF-extending ranges and allocation metadata refresh, and align the cifs declarations with the target patch context. This lets the fscache resize locking fix apply without adding its new helper in the dependency. [ sashal: Reduced backport -- upstream a5e581093b1d9 touches 2 file(s), this backport carries 2. Not backported here: fs/smb/common/fscc.h fs/smb/common/smb2pdu.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 32a7af68df73 ("cifs: add cifs_resize_file_locked() to guard fscache_resize_cookie() under i_rwsem") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 110747ff535e3d98ac17d68dbd056bb6ef000e23 Author: Sam Edwards Date: Sun Sep 6 13:42:14 2026 -0400 ceph: properly decrypt filenames in vmalloc() buffers [ Upstream commit e939fc6a7bd969a58a150b7f188c1047138403e3 ] The fscrypt subsystem uses the scatterlist crypto API, inheriting its requirement that any buffers are in the linear mapping region. However, the messenger client uses kvmalloc() to create buffers for messages, which will occasionally place those buffers in the vmalloc() region when physical memory fragmentation doesn't permit a large enough kmalloc(). The various callers of ceph_fname_to_usr() directly pass (slices of) raw messages from the MDS without considering that the messages may be in vmalloc() buffers, resulting in oopses especially on non-x86 platforms (see 'Closes:' for more details and a reproducer). Make ceph_fname_to_usr() explicitly tolerant of vmalloc()-allocated fname->ctext, fname->name, and/or oname->name buffers, using `tname` (which, when non-null, must be a linear address; when null, is briefly allocated as necessary) as a bounce buffer to avoid passing any inappropriate addresses to fscrypt_fname_disk_to_usr(). Additionally change parse_reply_info_readdir() -- the only function to supply its own `tname` -- to follow the new "tname must never come from vmalloc()" rule by passing NULL when the message is not in the linear region. Though this causes a per-dentry kmalloc()+kfree(), this overhead exists only when processing the minority of messages that spill into vmalloc(). My (crude) testing puts this at only about 1 in 8,000 readdir messages. Still, if the overhead proves unreasonable in the future, it is easy enough to mitigate: a future change could allocate a bounce buffer in parse_reply_info_readdir() and use that as `tname` instead. Cc: stable@vger.kernel.org # 888d33b208bd: ceph: pass fscrypt `tname` buffers directly Cc: stable@vger.kernel.org Fixes: 457117f077c6 ("ceph: add helpers for converting names for userland presentation") Closes: https://lore.kernel.org/ceph-devel/20260415034020.11530-1-CFSworks@gmail.com/ Signed-off-by: Sam Edwards Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov [ adapted raw tname buffer accesses to the legacy tname->name interface ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 104a51265042b4424085741c963cb858ac29ec0b Author: Chuck Lever Date: Sun Sep 6 11:04:40 2026 -0400 NFSD: Guard admin state-revocation walks with NFSD_NET_UP [ Upstream commit 2f3e6638aebc0ab8afb8b4e9816ea9a1cad85378 ] Writing to /proc/fs/nfsd/unlock_filesystem, or sending the NFSD_CMD_UNLOCK_FILESYSTEM or NFSD_CMD_UNLOCK_EXPORT netlink command, walks the NFSv4 client hash tables to revoke open state and cancel async COPY operations. All three handlers gate that walk on nn->nfsd_serv, but a listener added via portlist or netlink listener_set sets nn->nfsd_serv before any nfsd thread starts. nfsd_startup_net() has not yet allocated nn->conf_id_hashtbl, so the walkers dereference a NULL table. A local administrator with CAP_SYS_ADMIN can crash the kernel this way without ever starting the server. nn->nfsd_serv is set when the service is created, which precedes table allocation. NFSD_NET_UP instead brackets the window where the tables are live: set at the end of nfsd_startup_net() and cleared in nfsd_shutdown_net() after they are freed, both under nfsd_mutex. Gating the three unlock paths on NFSD_NET_UP fixes the startup-time NULL dereference while preserving the earlier post-shutdown use-after-free fix. Reported-by: XIAO WU Fixes: 1ac3629bf012 ("nfsd: prepare for supporting admin-revocation of state") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260621162551.2469460-1-cel@kernel.org Signed-off-by: Chuck Lever [ adapted NFSD_NET_UP flag check to the older nfsd_net_up boolean ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0e763ab306a81b5a1d65c14e9a9119a0eefea155 Author: Max Kellermann Date: Sun Sep 6 10:22:18 2026 -0400 ceph: force a cap message when a deferred revoke can't be acked immediately [ Upstream commit 8fdf946445732c2bcd685abc8bd0e509d2ebc158 ] When the MDS revokes capabilities, handle_cap_grant() normally guarantees a response by setting `CHECK_CAPS_FLUSH_FORCE` (see commit 31634d7597d8 ("ceph: force sending a cap update msg back to MDS for revoke op")), so ceph_check_caps() sends a cap message even if the client would otherwise decide it has nothing to do. That guarantee is skipped whenever the revoke has to be deferred (via revoke_wait): revoking Fb while dirty data is still buffered (writeback is queued first) or revoking Fc while pages are cached (async invalidation is queued first). In those cases, the ack is left to the deferred completion (ceph_put_wrbuffer_cap_refs() after writeback, or the invalidate worker after invalidation); both of which call ceph_check_caps(ci,0) i.e. without `CHECK_CAPS_FLUSH_FORCE`. Nothing gets sent under one of the following conditions: - the inode is retaining caps because the file was used recently (file_wanted != 0; retain |= CEPH_CAP_ANY) - the revoked cap is still used because the page was re-cached (e.g. a file being re-read) - the MDS has meanwhile re-granted, so `issued==implemented` and the client sees nothing being revoked The client then never emits the cap message which the MDS is waiting for. The MDS blocks on the revoke indefinitely and logs, for minutes or hours: client.NNN isn't responding to mclientcaps(revoke), ino 0x... pending pAsxLsXsxFsxcrwb issued pAsxLsXsxFsxcrwb, sent 964.899182 seconds ago The client-side state at that point shows the full cap set still issued, nothing in the revoking/flushing sets. Thus nothing gets sent. This patch fixes it by remembering that a forced response is expected. When a revoke is deferred, set `CEPH_I_FLUSH_FORCE` on the inode. ceph_check_caps() replays it as `CHECK_CAPS_FLUSH_FORCE`, so whichever path re-checks the inode next (the writeback/invalidate completion, the delayed worker, or any other caller) is guaranteed to send a cap message to the MDS. __prep_cap() clears the flag once a message is actually built. This is the deferred-path counterpart of the existing `CHECK_CAPS_FLUSH_FORCE` handling; a normal (non-deferred) revoke still forces the response inline as before. Cc: stable@vger.kernel.org Fixes: 31634d7597d8 ("ceph: force sending a cap update msg back to MDS for revoke op") Fixes: 257e6172ab36 ("ceph: don't let check_caps skip sending responses for revoke msgs") Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov [ adapted named atomic Ceph inode flag operations to lock-protected mask operations ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c040e139f1a629b767f900bbbc3f9892c290ed85 Author: Michael Bommarito Date: Sun Sep 6 10:22:14 2026 -0400 ceph: cap delegated inode count in ceph_parse_deleg_inos() [ Upstream commit 4bd3158bd62466d57ed72a3f7bc5f205fedd6919 ] ceph_parse_deleg_inos() decodes interval sets of delegated inode numbers from an MDS create-with-delegation reply. For each set it reads a 64-bit start and a 64-bit len with ceph_decode_64_safe(), which only validates that the eight bytes are present in the message, not the value, and then loops over len while inserting entries into s_delegated_inos. len is fully attacker controlled. A malicious or compromised MDS can send one huge interval, many intervals in one reply, duplicate intervals, or repeated replies that accumulate delegated inodes on the same session. The original code bounded none of these and could spin the insert loop or grow the xarray without limit. Bound both dimensions with a single enforcement point. Track the number of delegated inodes held by each MDS session in an atomic counter and grow it only in ceph_insert_deleg_ino(), which uses atomic_add_unless() to refuse to push the count past CEPH_MAX_DELEG_INOS. Because that helper is the only place the counter grows, the per-session population can never exceed the cap, so no separate per-session pre-check is needed. The counter is decremented when async create consumes a delegated inode or when an insert fails, incremented when a delegated inode is restored, initialized with the session xarray, and reset when reconnect destroys the xarray. A per-session cap alone still lets one reply spin the insert loop on duplicate ranges without growing the counter, so also cap the aggregate interval length accepted from a single reply. Together these bound both the loop trip count per reply and the xarray population across replies. The cap is a fixed, client-chosen constant rather than a value derived from the MDS. mds_client_prealloc_inos is a userspace MDS configuration option; it is never sent to the kernel client on the wire, and a server-supplied bound could not be trusted for a defensive limit in any case. The constant is set well above that option's documented default of 1000 (a generous multiple), so legitimate refill behavior is unaffected while the CPU and xarray memory a malformed delegation stream can consume stays bounded. Impact: a malicious or compromised Ceph MDS can no longer make a client spin through an unbounded delegated-inode interval or grow one session's delegated-inode xarray without limit. Cc: stable@vger.kernel.org Fixes: d48464878708 ("ceph: decode interval_sets for delegated inos") Suggested-by: Viacheslav Dubeyko Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov [ adapted counter reset placement to the older reconnect control flow ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8bd3523df1319edc61cd391e695c84a4618516df Author: Terry Bowman Date: Fri Sep 4 10:32:46 2026 -0400 cxl/ras: Fix cxl_rch_get_aer_info() out-of-bounds AER register read [ Upstream commit 29458e62d0829cbc99435f3e44fd560f9bbf1da7 ] cxl_rch_get_aer_info() copies the RCH Downstream Port AER capability from the RCRB MMIO block using a readl() loop bounded by sizeof(struct aer_capability_regs). This struct is a software layout and its embedded struct pcie_tlp_log is larger than the on-wire AER capability. As a result the loop reads past the mapped AER register block. The over-read also populates the software-only tail fields including header_log.header_len. An out-of-range header_len passed to pcie_print_tlp_log() can then loop past the header log buffer and cause a second out-of-bounds read. The read was correct when introduced, but struct pcie_tlp_log has since grown (Header Log and TLP Prefix Log sizes, header_len and flit fields), so sizeof(struct aer_capability_regs) no longer matches the physical AER capability. Bound the read to the physical AER registers, header through the 16 byte Header Log. Zero the destination first so the software-only fields are deterministic. Fixes: 6ac07883dbb5 ("cxl/pci: Add RCH downstream port error logging") Reported-by: Sashiko Cc: stable@vger.kernel.org Signed-off-by: Terry Bowman Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260803221810.3685703-2-terry.bowman@amd.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6f9b62687a3832528d60d50bf914b99695c8c893 Author: Terry Bowman Date: Fri Sep 4 10:32:45 2026 -0400 cxl/pci: Move CXL driver's RCH error handling into core/ras_rch.c [ Upstream commit 0ff60f2ec3e4043a442e805f80f8a2445113ec8f ] Restricted CXL Host (RCH) protocol error handling uses a procedure distinct from the CXL Virtual Hierarchy (VH) handling. This is because of the differences in the RCH and VH topologies. Improve the maintainability and add ability to enable/disable RCH handling. Move and combine the RCH handling code into a single block conditionally compiled with the CONFIG_CXL_RCH_RAS kernel config. Signed-off-by: Terry Bowman Reviewed-by: Jonathan Cameron Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260114182055.46029-9-terry.bowman@amd.com Signed-off-by: Dan Williams Signed-off-by: Dave Jiang Stable-dep-of: 29458e62d082 ("cxl/ras: Fix cxl_rch_get_aer_info() out-of-bounds AER register read") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 153b5ecd29ed055562400bc17c91df3fd869b0ce Author: Neill Kapron Date: Fri Sep 4 10:29:39 2026 -0400 usb: gadget: f_fs: Fix Use-After-Free in AIO error path [ Upstream commit e78dcb1f7ec271449c54984dc90c62a5ba272de7 ] In ffs_epfile_write_iter() and ffs_epfile_read_iter(), when ffs_epfile_io() fails with an error other than -EIOCBQUEUED, the io_data structure (`p`) is freed. However, for AIO operations, the kiocb cancel function was already armed and kiocb->private was set to `p`. If a concurrent cancel operation (such as sys_io_cancel()) executes after ffs_epfile_io() fails but before the function frees `p`, a Use-After-Free can occur when the cancellation handler accesses the freed pointer. To securely fix this race condition, we must properly un-arm the cancellation. Invoking `kiocb->ki_complete()` does exactly this by acquiring `ctx->ctx_lock` and safely removing the kiocb from the active sequence. In doing so, it ensures that a parallel io_cancel can no longer discover the kiocb, effectively closing the race window. We then return -EIOCBQUEUED to notify the VFS layer that the kiocb has been consumed and it should avoid attempting to complete the request again or triggering subsequent completion handlers. Fixes: de2080d41b5d ("gadget/function/f_fs.c: close leaks") Cc: stable@vger.kernel.org Reported-by: Xingyu Jin Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Neill Kapron Link: https://patch.msgid.link/20260724235100.106011-1-nkapron@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f3d31484b3f26d63c09e5569ebfaa1079a17f171 Author: Gabriel Prostitis Date: Fri Sep 4 10:29:38 2026 -0400 USB: gadget: ffs: fix mm lifetime handling [ Upstream commit 5eb5c72c72fef76cb765ef1669b62b6a3ba1bfc8 ] io_data stores a pointer to the submitting task's mm_struct, but does not currently hold a reference to it while async requests are pending. This can result in a use-after-free if the task exits before completion handling finishes. Take a reference with mmgrab() when queuing the read request and release it with mmdrop() on request completion. Reported-by: Gabriel Prostitis Signed-off-by: Gabriel Prostitis Link: https://patch.msgid.link/20260601-mm-uaf-fix-v2-1-3c942a707bce@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: e78dcb1f7ec2 ("usb: gadget: f_fs: Fix Use-After-Free in AIO error path") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 06c76d3c389ff504052f64b1acee44651bd847fa Author: Brendan Jackman Date: Fri Sep 4 09:50:25 2026 -0400 mm/page_alloc: don't spin_trylock() in NMI on UP [ Upstream commit 3105ae628fb785d48b49256468be4f21a7b3cfc0 ] Patch series "mm/page_alloc: fixes for free_pages_nolock() on RT/UP". Pre-existing bugs found by Sashiko during review of this other series: https://lore.kernel.org/all/20260703-alloc-trylock-v5-0-c87b714e19d3@google.com/ I have not reproduced these bugs, and I suspect there is no real-world user that is affected by them. This patch (of 2): As noted in can_spin_trylock(), using this is unsafe in this context. commit 620b46ed6ae17 ("mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP") fixed this on the alloc side but missed the free side. Impact: If BPF programs using these features in NMI (probably tracing) are present on non-SMP builds this might crash the kernel and is probably exploitable by local attackers for privilege escalation. Link: https://lore.kernel.org/20260715-alloc-nolock-fixes-v1-0-fadc49952dda@google.com Link: https://lore.kernel.org/20260715-alloc-nolock-fixes-v1-1-fadc49952dda@google.com Fixes: 8c57b687e833 ("mm, bpf: Introduce free_pages_nolock()") Signed-off-by: Brendan Jackman Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260703-alloc-trylock-v5-0-c87b714e19d3%40google.com?part=18 Reviewed-by: Vlastimil Babka (SUSE) Reviewed-by: Harry Yoo (Oracle) Cc: Brendan Jackman Cc: Alexei Starovoitov Cc: Johannes Weiner Cc: Michal Hocko Cc: Sebastian Andrzej Siewior Cc: Shakeel Butt Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 22bbde1960d1d90f21530a06e8fd1f2b357688db Author: Roger Pau Monne Date: Fri Sep 4 06:30:47 2026 -0400 x86/xen: fix init of balloon stats again [ Upstream commit 5d00a11d484e7b31a358cd81afebccb4602dbe8c ] The handling of extra memory regions done in balloon_add_regions() is not correct for PV guests, since the initial target is set to reflect the real memory the system has, not what's described on the memory map, which can be higher if memory != maxmem. Introduce separate logic for addition vs subtraction in balloon_add_regions() and handle extra regions correctly by adding them to the total amount of pages, instead of subtracting from the current and target pages amounts. In the common case PV domU/dom0 and PVH dom0 will use the addition path, since the initial target reflects the real assigned memory. HVM and PVH domUs use the subtraction path, since the target is set based on the amount of memory reported in the memory map, without accounting for released regions. Fixes: 87af633689ce ("x86/xen: fix balloon target initialization for PVH dom0") Fixes: 0949c646d646 ("Partial revert "x86/xen: fix balloon target initialization for PVH dom0"") Signed-off-by: Roger Pau Monné Cc: stable@vger.kernel.org Reviewed-by: Juergen Gross Tested-by: Matthias Goergens Signed-off-by: Juergen Gross Message-ID: <20260805094008.95778-1-roger@xenproject.org> Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6f53c64a880ff353512c1a8b89e8ac4c2f5b0322 Author: Roger Pau Monne Date: Fri Sep 4 06:30:46 2026 -0400 xen/balloon: improve accuracy of initial balloon target for dom0 [ Upstream commit b13cd24c15d74f6dfcddf0d53ae6efb58d3f0461 ] The dom0 balloon target set by the toolstack is the value returned by XENMEM_current_reservation. Do the same in the kernel balloon driver and set the current allocation to the value returned by XENMEM_current_reservation. On my test system this causes the kernel balloon driver target to exactly match the value set by the toolstack in xenstore. Note this approach can be used by both PV and PVH dom0s, as the toolstack always uses XENMEM_current_reservation to set the initial target regardless of the dom0 type. Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260128110510.46425-3-roger.pau@citrix.com> Stable-dep-of: 5d00a11d484e ("x86/xen: fix init of balloon stats again") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b4a6050bde9ec93e2cee2a1c8189b9b20e9dc12f Author: Li Xiasong Date: Thu Sep 3 20:20:22 2026 -0400 mm/slub: fix missing debugfs entries for caches created before sysfs init [ Upstream commit 7e98f856395618011c517f767fb80ac3fe90de2b ] slab_debugfs_init() creates the slab debugfs root at device initcall time, while slab_sysfs_init() moves slab_state to FULL at late initcall time. SLAB_STORE_USER caches created in this window miss their debugfs entries because do_kmem_cache_create() skips debugfs_slab_add() when slab_state <= UP. This was observed with MPTCP's request_sock_subflow_v6 cache, whose slab debugfs directory was missing. The affected window is: slab_debugfs_init() slab_debugfs_root = debugfs_create_dir(...) list_for_each_entry(s, &slab_caches, list) debugfs_slab_add(s) kmem_cache_create(..., SLAB_STORE_USER, ...) do_kmem_cache_create() if (slab_state <= UP) return without debugfs entries slab_sysfs_init() slab_state = FULL Initialize the debugfs root and add debugfs entries while holding slab_mutex, walking slab_caches exactly once and handling both sysfs and debugfs entries in the same pass. This gives the sysfs and debugfs initialization an explicit order and prevents caches from being created between the debugfs scan and slab_state reaching FULL. Gate the new slab_late_init() on either sysfs or debugfs being enabled, with the slab_kset creation and alias_list processing factored into helpers that have empty no-sysfs variants, as suggested by Vlastimil Babka. On slab_kset_init() failure, slab_state stays below FULL so kmem_cache_create() keeps taking the early-boot path, matching prior behavior. Guard debugfs_slab_release() against an uninitialized debugfs root, since the root is now created later and a cache may be released before it exists. Fixes: 1a5ad30b89b4 ("mm: slub: make slab_sysfs_init() a late_initcall") Cc: stable@vger.kernel.org Suggested-by: Vlastimil Babka Signed-off-by: Li Xiasong Link: https://patch.msgid.link/20260729101849.3734287-1-lixiasong1@huawei.com Reviewed-by: Harry Yoo (Oracle) Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d08ea0fd703868c714fee3a2e842bcc776ccdf99 Author: Vlastimil Babka Date: Thu Sep 3 20:20:21 2026 -0400 mm/slab: move and refactor __kmem_cache_alias() [ Upstream commit 8598351edc42f38d2a1eaed9abca39c98e7b0bbf ] Move __kmem_cache_alias() to slab_common.c since it's called by __kmem_cache_create_args() and calls find_mergeable() that both are in this file. We can remove two slab.h declarations and make them static. Instead declare sysfs_slab_alias() from slub.c so that __kmem_cache_alias() can keep calling it. Add args parameter to __kmem_cache_alias() and find_mergeable() instead of align and ctor. With that we can also move the checks for usersize and sheaf_capacity there from __kmem_cache_create_args() and make the result more symmetric with slab_unmergeable(). No functional changes intended. Reviewed-by: Harry Yoo Reviewed-by: Suren Baghdasaryan Reviewed-by: Liam R. Howlett Signed-off-by: Vlastimil Babka Stable-dep-of: 7e98f8563956 ("mm/slub: fix missing debugfs entries for caches created before sysfs init") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e7bd804e3c7194c8a19732e64cb6dd9f46de9c6a Author: Dev Jain Date: Thu Sep 3 20:13:42 2026 -0400 mm/rmap: use huge_ptep_get() in try_to_migrate_one() [ Upstream commit 9be12ffa78cd087d41086f937a156435d4e588e9 ] try_to_migrate_one() is used by folio migration to replace a present mapping with a migration entry. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads the huge pte entry with ptep_get(). On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave. It is not clear whether this has a trivially visible effect to userspace. Use huge_ptep_get() to dereference a huge pte pointer. Commit a98a2f0c8ce1 copied the bug from try_to_unmap_one into try_to_migrate_one. [akpm@linux-foundation.org: coding-style cleanups] Link: https://lore.kernel.org/20260703114202.365553-4-dev.jain@arm.com Fixes: a98a2f0c8ce1 ("mm/rmap: split migration into its own function") Signed-off-by: Dev Jain Acked-by: Muchun Song Acked-by: David Hildenbrand (Arm) Cc: Alistair Popple Cc: Andi Kleen Cc: Anshuman Khandual Cc: Byungchul Park Cc: Catalin Marinas Cc: Dave Hansen Cc: Gregory Price Cc: Harry Yoo Cc: "Huang, Ying" Cc: Jann Horn Cc: Josh Poimboeuf Cc: Joshua Hahn Cc: Jun'ichi "Nick" Nomura Cc: Kiryl Shutsemau Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Mel Gorman Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Pedro Falcato Cc: Rakie Kim Cc: Ralph Campbell Cc: Rik van Riel Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Will Deacon Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 54a58d6656dd403b686b247f0bad8507cbfb45df Author: Kairui Song Date: Thu Sep 3 13:31:51 2026 -0400 mm/mglru: fix and remove redundant unevictable folio handling [ Upstream commit f7e698e326b239a91ea15844817551921209e826 ] sort_folio() has a shortcut for moving folios that are no longer evictable but are still sitting on a generation list. However, this shortcut is buggy. It does not follow the PG_lru usage convention, and it has a more serious issue. Unevictable folios are not threaded on lists[LRU_UNEVICTABLE], so that folio->lru can be reused to hold folio->mlock_count (see the comment in lruvec_init()). Hence lruvec_add_folio() skips the list_add() for them, and every other place that turns a folio unevictable initialises mlock_count explicitly: lru_add() sets it to 0, __mlock_folio() and __mlock_new_folio() set it to !!folio_test_mlocked(folio). sort_folio() sets nothing, and the lru_gen_del_folio() right above it may have already poisoned folio->lru via list_del(), so mlock_count ends up aliasing LIST_POISON2, which reads as 0x122, i.e. 290. The result is user visible. On munlock, __munlock_folio() decrements that bogus count, finds it still non-zero and bails out before clearing PG_mlocked, so the folio remains unevictable and the Mlocked accounting stays inflated until the folio is freed. The shortcut also touches the LRU flags in the wrong order. It calls lru_gen_del_folio() while PG_lru is still set, so a concurrent folio_test_clear_lru() (e.g. compaction, folio_isolate_lru()) can succeed on a folio that has already been taken off the generation list, which may lead to unexpected behavior. So fix it by isolating them as common folios and letting the generic shrink path cull them. This matches the classical LRU behavior, and there should be no visible effect on the generic eviction or isolation behavior. There is no performance concern either, such a folio goes through this once, and then it is off the generation lists for good. Link: https://lore.kernel.org/20260812-mglru-mlock-fix-v2-1-a3fec5853c08@tencent.com Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation") Signed-off-by: Kairui Song Reviewed-by: Barry Song Reviewed-by: Baolin Wang Cc: Axel Rasmussen Cc: Brian Geffon Cc: David Hildenbrand Cc: Jan Alexander Steffens (heftig) Cc: Johannes Weiner Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Oleksandr Natalenko Cc: Shakeel Butt Cc: Steven Barrett Cc: Suleiman Souhlal Cc: Wei Xu Cc: Yuanchu Xie Cc: Yu Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d4812d21689f1fa7d88a132e7f57cd6ebc245c0c Author: Kairui Song Date: Thu Sep 3 13:31:50 2026 -0400 mm/mglru: use the common routine for dirty/writeback reactivation [ Upstream commit 75d4c3f5fb980de1b620adede47e43dff4d6a5f3 ] Currently MGLRU will move the dirty writeback folios to the second oldest gen instead of reactivate them like the classical LRU. This might help to reduce the LRU contention as it skipped the isolation. But as a result we will see these folios at the LRU tail more frequently leading to inefficient reclaim. Besides, the dirty / writeback check after isolation in shrink_folio_list is more accurate and covers more cases. So instead, just drop the special handling for dirty writeback, use the common routine and re-activate it like the classical LRU. This should in theory improve the scan efficiency. These folios will be rotated back to LRU tail once writeback is done so there is no risk of hotness inversion. And now each reclaim loop will have a higher success rate. This also prepares for unifying the writeback and throttling mechanism with classical LRU, we keep these folios far from tail so detecting the tail batch will have a similar pattern with classical LRU. The micro optimization that avoids LRU contention by skipping the isolation is gone, which should be fine. Compared to IO and writeback cost, the isolation overhead is trivial. And using the common routine also keeps the folio's referenced bits (tier bits), which could improve metrics in the long term. Also no more need to clean reclaim bit as the common routine will make use of it. Note the common routine updates a few throttling and writeback counters, which are not used, and never have been for the MGLRU case. We will start making use of these in later commits. Link: https://lore.kernel.org/20260428-mglru-reclaim-v7-10-02fabb92dc43@tencent.com Signed-off-by: Kairui Song Reviewed-by: Axel Rasmussen Reviewed-by: Barry Song Reviewed-by: Baolin Wang Cc: Chen Ridong Cc: Chris Li Cc: David Hildenbrand Cc: David Stevens Cc: Johannes Weiner Cc: Kalesh Singh Cc: Leno Hou Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Vernon Yang Cc: Wei Xu Cc: Yafang Cc: Yuanchu Xie Cc: Yu Zhao Signed-off-by: Andrew Morton Stable-dep-of: f7e698e326b2 ("mm/mglru: fix and remove redundant unevictable folio handling") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 09505232eced5f1c42902d8f28740f070c3fc6dc Author: Muchun Song Date: Thu Sep 3 12:33:47 2026 -0400 mm/hugetlb: initialize gigantic bootmem hugepage struct pages earlier [ Upstream commit b1b7c045e808c761b1cc8c19b3040fadedda3fef ] Gigantic bootmem HugeTLB pages are currently initialized from hugetlb_init(), but page_alloc_init_late() runs earlier and walks pageblocks to determine zone contiguity. If a bootmem HugeTLB region is marked noinit, set_zone_contiguous() can observe still-uninitialized struct pages through __pageblock_pfn_to_page(). This may not trigger an immediate failure, but it can make set_zone_contiguous() compute the wrong zone contiguity state. If extra poisoned-page checks are added in this path, such as PF_POISONED_CHECK() in page_zone_id(), it can also trigger an early boot panic. Initialize gigantic bootmem HugeTLB struct pages from page_alloc_init_late(), before zone contiguity is evaluated, so later page allocator setup only sees valid struct page state. This also makes the initialization order more natural, as struct pages should be initialized before later code inspects them. Link: https://lore.kernel.org/20260612035903.2468601-5-songmuchun@bytedance.com Fixes: fde1c4ecf916 ("mm: hugetlb: skip initialization of gigantic tail struct pages if freed by HVO") Signed-off-by: Muchun Song Acked-by: Mike Rapoport (Microsoft) Acked-by: Oscar Salvador Cc: "Aneesh Kumar K.V" Cc: David Hildenbrand Cc: Frank van der Linden Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Oscar Salvador (SUSE) Cc: "Ritesh Harjani (IBM)" Cc: Usama Arif Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton [ adapted the header context and omitted a comment update for an absent HVO helper. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit daeffb841bb966a64bca893dce9ecc392f1d09aa Author: Kiryl Shutsemau Date: Thu Sep 3 12:33:46 2026 -0400 mm/hugetlb: refactor code around vmemmap_walk [ Upstream commit c0b495b91a47b6c5ee54cf00e620dbadeb884253 ] To prepare for removing fake head pages, the vmemmap_walk code is being reworked. The reuse_page and reuse_addr variables are being eliminated. There will no longer be an expectation regarding the reuse address in relation to the operated range. Instead, the caller will provide head and tail vmemmap pages. Currently, vmemmap_head and vmemmap_tail are set to the same page, but this will change in the future. The only functional change is that __hugetlb_vmemmap_optimize_folio() will abandon optimization if memory allocation fails. Link: https://lkml.kernel.org/r/20260227194302.274384-11-kas@kernel.org Signed-off-by: Kiryl Shutsemau Reviewed-by: Muchun Song Cc: Albert Ou Cc: Alexandre Ghiti Cc: Baoquan He Cc: Christoph Lameter Cc: David Hildenbrand (arm) Cc: David Rientjes Cc: Frank van der Linden Cc: Harry Yoo Cc: Huacai Chen Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Oscar Salvador Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Roman Gushchin Cc: Usama Arif Cc: Vlastimil Babka Cc: WANG Xuerui Cc: Zi Yan Signed-off-by: Andrew Morton Stable-dep-of: b1b7c045e808 ("mm/hugetlb: initialize gigantic bootmem hugepage struct pages earlier") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b662d7bcb5ecde2257ca2594512803aa77f983df Author: Kiryl Shutsemau (Meta) Date: Thu Sep 3 12:33:45 2026 -0400 mm/hugetlb: defer vmemmap population for bootmem hugepages [ Upstream commit 209e6d9eb13aaf1b6e0fc6f76afc00d055e5ba12 ] Currently, the vmemmap for bootmem-allocated gigantic pages is populated early in hugetlb_vmemmap_init_early(). However, the zone information is only available after zones are initialized. If it is later discovered that a page spans multiple zones, the HVO mapping must be undone and replaced with a normal mapping using vmemmap_undo_hvo(). Defer the actual vmemmap population to hugetlb_vmemmap_init_late(). At this stage, zones are already initialized, so it can be checked if the page is valid for HVO before deciding how to populate the vmemmap. This allows us to remove vmemmap_undo_hvo() and the complex logic required to rollback HVO mappings. In hugetlb_vmemmap_init_late(), if HVO population fails or if the zones are invalid, fall back to a normal vmemmap population. Postponing population until hugetlb_vmemmap_init_late() also makes zone information available from within vmemmap_populate_hvo(). Link: https://lkml.kernel.org/r/20260227194302.274384-10-kas@kernel.org Signed-off-by: Kiryl Shutsemau (Meta) Acked-by: David Hildenbrand (Arm) Cc: Albert Ou Cc: Alexandre Ghiti Cc: Baoquan He Cc: Christoph Lameter Cc: David Rientjes Cc: Frank van der Linden Cc: Harry Yoo Cc: Huacai Chen Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Oscar Salvador Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Roman Gushchin Cc: Usama Arif Cc: Vlastimil Babka Cc: WANG Xuerui Cc: Zi Yan Signed-off-by: Andrew Morton Stable-dep-of: b1b7c045e808 ("mm/hugetlb: initialize gigantic bootmem hugepage struct pages earlier") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit edc017be82664226bbbf0af8c8d61873380249db Author: FUJITA Tomonori Date: Thu Sep 3 11:01:02 2026 -0400 rust: bug: prevent dead_code warning from warn_on!'s flags constant [ Upstream commit e66cfc29e0d06fec34c06bb40d4d281f595677b1 ] Fix the following dead_code warning on some configurations in an atomic development branch: warning: constant `WARN_ON_FLAGS` is never used --> linux/rust/kernel/bug.rs:126:19 | 126 | const WARN_ON_FLAGS: u32 = $crate::bug::bugflag_taint($crate::bindings::TAINT_WARN); | ^^^^^^^^^^^^^ | ::: linux/rust/kernel/sync/srcu.rs:106:12 | 106 | if crate::warn_on!( | ____________- 107 | | // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct` 108 | | // and `srcu_readers_active()` only checks the active reader count. 109 | | unsafe { bindings::srcu_readers_active(ptr) } 110 | | ) { | |_________- in this macro invocation | = note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default = note: this warning originates in the macro `crate::warn_on` (in Nightly builds, run with -Z macro-backtrace for more info) The warn_on! macro always defines a WARN_ON_FLAGS constant and hands it to warn_flags!. On configurations where warn_flags! does not reference its flags argument (the LOONGARCH/ARM variant, which only calls WARN_ON(), and the !CONFIG_BUG no-op variant), the constant is left unused and triggers a dead_code warning. warn_flags! is the macro that accepts (and here discards) the flags argument, so make it responsible for the argument it drops. Also rename `_COND_STR` to `COND_STR` and consume `$file` for consistency. Fixes: dff64b072708 ("rust: Add warn_on macro") Signed-off-by: FUJITA Tomonori Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260801024841.786664-1-tomo@flapping.org [ Added newlines. - Miguel ] Signed-off-by: Miguel Ojeda [ adapted unreachable flag consumption to the older one-argument warn_flags! interface. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cf24ce48d60225fdbee68ed2058763a1fd172ff3 Author: Chen Linxuan Date: Thu Sep 3 08:22:36 2026 -0400 pidfd: hold exec_update_lock around namespace ioctl [ Upstream commit 9688a46802939da28f00cb40e8129615d5d4af39 ] The PIDFD_GET_*_NAMESPACE ioctls in pidfd_ioctl() perform a filesystem credentials ptrace access check before handing out a namespace file descriptor. The accompanying comment states that the code "mirrors nsfs behavior", but, unlike the corresponding procfs paths, it does so without holding the target task's exec_update_lock. proc_ns_get_link() and proc_ns_readlink() both take exec_update_lock for reading around the ptrace check and the namespace lookup, so that the credentials used for the access decision match those of the task when its namespace is read. Without it, a caller can pass the check against the target's old credentials and then read the namespace after the target has execve()'d a setuid binary and committed new credentials -- accessing namespace information it should have been denied. Hold exec_update_lock for reading around the ptrace check and the namespace lookup so that pidfd truly mirrors nsfs behavior, as the comment already claims. open_namespace() itself runs outside the lock: once a namespace reference is obtained it carries its own refcount and is opened with the caller's own credentials, so a concurrent execve() on the target can no longer affect the outcome. Fixes: 5b08bd408534 ("pidfs: allow retrieval of namespace file descriptors") Cc: stable@vger.kernel.org Signed-off-by: Chen Linxuan Link: https://patch.msgid.link/20260731-pidfd-exec-update-lock-v1-1-b388f2f3a8b0@black-desk.cn Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7aa9ab5321589ac80dbb05857de9082eeb8ed01a Author: Christian Brauner Date: Thu Sep 3 08:22:35 2026 -0400 pidfs: simplify PIDFD_GET__NAMESPACE ioctls [ Upstream commit a71e4f103aed69e7a11ea913312726bb194c76ee ] We have reworked namespaces sufficiently that all this special-casing shouldn't be needed anymore Link: https://patch.msgid.link/20251117-eidesstattlich-apotheke-36d2e644079f@brauner Signed-off-by: Christian Brauner Stable-dep-of: 9688a4680293 ("pidfd: hold exec_update_lock around namespace ioctl") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2fa220bc0f84597cb6de665e5b5021c5901ddf00 Author: Vivek Parikh Date: Thu Sep 3 08:22:32 2026 -0400 ovl: fix double end_creating() on the casefold-mismatch path [ Upstream commit 077ab8985ee278c3d8618182d335b0f0cd919e16 ] ovl_create_real() releases the new dentry twice when the casefold consistency check fails. The S_IFDIR branch calls end_creating() and sets err, then falls through to the common out: label which calls end_creating() on the same dentry again: case S_IFDIR: newdentry = ovl_do_mkdir(ofs, dir, newdentry, attr->mode); err = PTR_ERR_OR_ZERO(newdentry); if (!err && ofs->casefold != ovl_dentry_casefolded(newdentry)) { pr_warn_ratelimited(...); end_creating(newdentry); /* first */ err = -EINVAL; } break; ... if (err) goto out; ... out: if (err) { end_creating(newdentry); /* second, same dentry */ return ERR_PTR(err); } end_creating() is end_dirop(), which does inode_unlock() on the parent and dput() on the dentry, so the parent directory's i_rwsem is unlocked twice and the dentry is put twice. The second unlock releases a lock that is not held, which is what wedges every later creation under that parent, and the second dput() drops a reference that was never taken. The branch was added by commit dfc7da402ccc ("ovl: Check for casefold consistency when creating new dentries") as a bare dput(), which already released the reference twice; commit fe497f0759e0 ("VFS: change vfs_mkdir() to unlock on failure.") converted both sites to end_creating(), adding the double unlock. This is reachable by an unprivileged user. The casefold consistency of the layers is validated at mount time in ovl_parse_layer(), and again on every lookup in ovl_lookup_single(), but ofs->workdir is the internal "work" subdirectory created inside the user-supplied workdir, and that subdirectory is not re-checked. Marking it casefolded after the mount therefore makes every ovl_create_temp() inherit the wrong state - and that path reaches ovl_create_real() through ovl_start_creating_temp(), which uses start_creating() with a generated name and so never runs the lookup-time check. unshare -Urm mount -t tmpfs -o casefold=utf8-12.1.0 tmpfs mnt mkdir -p mnt/lower/d mnt/upper mnt/work mnt/merged mount -t overlay ovl -o lowerdir=mnt/lower,\ upperdir=mnt/upper,workdir=mnt/work mnt/merged chattr +F mnt/work/work mkdir mnt/merged/d/sub # directory copy-up overlayfs: wrong inherited casefold (work/#5) and the next copy-up blocks forever on the parent's i_rwsem: mkdir D start_creating+0x65/0xb0 ovl_start_creating_temp+0xb0/0xe0 [overlay] ovl_create_temp+0xa3/0x1d0 [overlay] ovl_copy_up_one+0x1f1c/0x21c0 [overlay] ovl_copy_up_flags+0xf5/0x140 [overlay] ovl_create_object+0xb7/0x220 [overlay] ovl_mkdir+0x23/0x40 [overlay] Drop the end_creating() from the branch and let out: own the cleanup, which is what every other error path in this function already does. Fixes: dfc7da402ccc ("ovl: Check for casefold consistency when creating new dentries") Cc: stable@vger.kernel.org Signed-off-by: Vivek Parikh Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Amutable) [ adapted end_creating() cleanup removal to the older dput() API ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1c4b90902c05cc94ef64fa55d0222d8ac36d1401 Author: Thorsten Blum Date: Tue Sep 1 17:44:16 2026 -0400 crypto: atmel-ecc - avoid stale fallback key after set_secret failure [ Upstream commit f07a0d251db7606e4792d2610788fbcc7b2c0d12 ] Clear ->do_fallback before decoding a new ECDH secret and enable it only after the software fallback accepts a caller-provided private key. This avoids using a stale fallback key should crypto_kpp_set_secret() fail. Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5c1e763b713f053c52819c6eca1383951db03190 Author: Thorsten Blum Date: Tue Sep 1 17:44:15 2026 -0400 crypto: atmel-ecc - clean up and improve ECDH comments [ Upstream commit 3e84fb698abada239d3e35ed3d52a24dbfda5f6a ] Improve the kerneldoc for struct atmel_ecdh_ctx by removing the stale "unsupported curves" wording, since the device only supports a single curve (P-256), and move the set_secret() constraint to the description. In atmel_ecdh_set_secret(), clarify that the device generates the private key, and drop the redundant "only supports NIST P256" comment. In atmel_ecdh_done() and atmel_ecdh_generate_public_key(), clarify the truncation comments. Also note that a P-256 public key consists of two 32-byte coordinates in atmel_ecdh_compute_shared_secret(), and remove the unnecessary fall-through comment and other redundant comments. Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Stable-dep-of: f07a0d251db7 ("crypto: atmel-ecc - avoid stale fallback key after set_secret failure") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e39767b9a54d9144e8e534ac5a24053dbee11d26 Author: Thorsten Blum Date: Tue Sep 1 17:44:14 2026 -0400 crypto: atmel-ecc - replace min_t with min [ Upstream commit 5b085b2a038a1458f9398cb3b3b03cba6e38e1e0 ] Use the simpler min() macro since the values are all unsigned and compatible. Signed-off-by: Thorsten Blum Reviewed-by: David Laight Signed-off-by: Herbert Xu Stable-dep-of: f07a0d251db7 ("crypto: atmel-ecc - avoid stale fallback key after set_secret failure") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fc933a4a419ba8a75da28666a018602c44846953 Author: Vinicius Costa Gomes Date: Tue Sep 1 15:43:49 2026 -0400 crypto: iaa - unmap dst before software fallback on decompress [ Upstream commit 94a25930477113730372e0fa2985da4c5ac95c9a ] On a hardware analytics error, decompress retries through the software fallback, which writes req->dst with the CPU while it is still mapped DMA_FROM_DEVICE. With SWIOTLB active the later dma_unmap_sg() copies the stale bounce buffer over req->dst, corrupting the result. Unmap before the fallback runs. The async path unmaps inline; the sync path signals the retry with -EAGAIN so iaa_comp_adecompress() runs the fallback after unmapping. Fixes: 2ec6761df889 ("crypto: iaa - Add support for deflate-iaa compression algorithm") Cc: stable@vger.kernel.org Signed-off-by: Vinicius Costa Gomes Signed-off-by: Herbert Xu [ adapted unavailable iaa_unmap_src() calls to single-entry dma_unmap_sg() calls ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4fcbc9f4082ca622271f213ec664554aca8cab2d Author: Giovanni Cabiddu Date: Tue Sep 1 15:43:48 2026 -0400 crypto: iaa - fall back to software for multi-entry scatterlists [ Upstream commit c7fdfd2bee1cf1448e5244da1a734e680f634b02 ] IAA cannot process source or destination scatterlists with more than one entry directly. Instead of failing these requests, route them through a separate deflate acomp transform and keep the request alive in software. The IAA driver has never handled multi-entry scatterlists, but the limitation was latent until commit e2c3b6b21c77 ("mm: zswap: use SG list decompression APIs from zsmalloc") made zswap pass the raw zsmalloc SG list directly to crypto drivers, so objects spanning multiple pages now reach IAA as multi-entry sources and would otherwise fail decompression. Fallback to the generic DEFLATE implementation for scatterlists with more than one entry. After the multi-entry cases fall back early, simplify the DMA mapping path to a single scatterlist entry and fall back on mapping failure as well. Add counters to track the number of requests processed by the software implementation on the compression direction. Fixes: 2ec6761df889 ("crypto: iaa - Add support for deflate-iaa compression algorithm") Fixes: e2c3b6b21c77 ("mm: zswap: use SG list decompression APIs from zsmalloc") Cc: stable@vger.kernel.org Signed-off-by: Giovanni Cabiddu Signed-off-by: Vinicius Costa Gomes Signed-off-by: Herbert Xu Stable-dep-of: 94a259304771 ("crypto: iaa - unmap dst before software fallback on decompress") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1517d1996b5236fe69eccd9d253f725e06996eb1 Author: Eric Dumazet Date: Tue Sep 1 07:20:04 2026 -0400 vlan: fix skb_under_panic and races when toggling HW VLAN offload [ Upstream commit 447cbe95ebb95392b5d8f6a01c0556826919ce23 ] Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(), which dynamically changed vlandev->hard_header_len. This causes two issues: 1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2) read dev->hard_header_len without holding RTNL lock. Mutating hard_header_len dynamically under RTNL creates a data race where upper layers reserve insufficient headroom based on a stale hard_header_len, resulting in skb_under_panic when vlan_dev_hard_header() is called. 2. In addition, vlan_transfer_features() updated hard_header_len without updating header_ops, causing a mismatch between allocated headroom and header creation. Always setting dev->hard_header_len = real_dev->hard_header_len and dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN unconditionally ensures: - dev->hard_header_len remains 100% static and immutable at real_dev->hard_header_len, eliminating all dynamic runtime updates and data races on hard_header_len. - Upper layers allocating skbs via LL_RESERVED_SPACE() will always reserve sufficient headroom for software VLAN tag insertion (real_dev->hard_header_len + real_dev->needed_headroom + VLAN_HLEN). - vlandev inherits real_dev->needed_tailroom so underlying trailer/padding/ICV requirements are honored. - AF_PACKET SOCK_RAW network header offsets remain correctly aligned at real_dev->hard_header_len. - vlan_header_ops is used unconditionally. Note to stable teams: Make sure to backport these commits: e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") cef51860becd ("macvlan: inherit needed_headroom and needed_tailroom from lowerdev") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Tangxin Xie Closes: https://lore.kernel.org/netdev/99d678ae-c7b2-4b44-b534-b8320679deb3@h-partners.com/ Cc: # 3.19: e16e960d55a4: ipvlan: inherit needed_headroom and needed_tailroom from phy_dev Cc: # 3.19: cef51860becd: macvlan: inherit needed_headroom and needed_tailroom from lowerdev Cc: # 3.19 Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260811085246.2267779-1-edumazet@google.com Signed-off-by: Jakub Kicinski [ moved the vlan_transfer_features() hunk to its pre-refactor location in vlan.c ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ed25ed29034ddc3dbe451ccbaa58ab9932f99d8b Author: Kyle Zeng Date: Tue Sep 1 07:11:07 2026 -0400 net/packet: defer vmalloc TX_RING free until skbs finish [ Upstream commit 992cc9f94ca924089a506ba9b327caa9af797529 ] AF_PACKET TX_RING skbs keep a raw pointer to their ring frame. The skb page references preserve page-backed ring blocks after pg_vec is freed, but they do not preserve a vmalloc mapping. tpacket_destruct_skb() currently drops the pending reference before writing the timestamp and TP_STATUS_AVAILABLE to the frame. Move the decrement after those stores. The smp_wmb() in __packet_set_status() orders the frame stores before the decrement. Also recheck pending TX frames under pg_vec_lock before non-closing ring replacement, so a racing send cannot add a pending skb between the initial check and the ring swap. Ring allocation can produce a mixture of page-backed and vmalloc-backed blocks. Allocate deferred-work storage during TX ring setup when the first vmalloc-backed block is encountered, and keep its pointer in the pg_vec allocation header. If allocation fails, return -ENOMEM from ring setup. On socket close, a non-NULL pointer identifies a vmalloc-backed vector without a scan. If TX skbs remain, defer the whole vector to system_long_wq. After pg_vec is detached, a late destructor can skip the pending decrement. Use socket write-memory accounting as the deferred lifetime gate instead: an skb remains charged through its final sock_wfree(), after all ring-frame accesses. The delayed work retains a socket reference and reschedules itself until no TX skbs remain. Move pending_refcnt release to packet_sock_destruct() so late skb destructors and deferred cleanup can safely use it after packet_release(). Page-backed teardown remains synchronous, and no lock is added to the TX completion hot path. Fixes: b013840810c2 ("packet: use percpu mmap tx frame pending refcount") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/netdev/20260721015824.45829-1-kylebot@openai.com/ Suggested-by: Eric Dumazet Suggested-by: Willem de Bruijn Reviewed-by: Willem de Bruijn Signed-off-by: Kyle Zeng Link: https://patch.msgid.link/20260816235646.76500-1-kylebot@openai.com Signed-off-by: Jakub Kicinski [ adapted the kzalloc_objs() allocation context to the older kcalloc() form ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0f930904452945f409eeeb0c9afa08bf27185cb1 Author: Miklos Szeredi Date: Mon Aug 31 12:43:13 2026 -0400 fuse: fix race between interrupt and resend [ Upstream commit ed9c881f3b498383f73c42712b359419da42a7b0 ] After commit f8fce75fedf7 ("fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req") the WARN_ON(!list_empty(&req->intr_entry)) in fuse_request_free() still triggers due to the following race: In request_wait_answer() if (test_bit(FR_SENT, &req->flags)) -> returns true In fuse_chan_resend() clear_bit(FR_SENT, &req->flags) In request_wait_answer() queue_interrupt(req) Fix by: - move clearing FR_SENT inside fpq->lock - move setting FR_PENDING inside fiq->lock - recheck FR_SENT after acquiring fiq->lock in fuse_dev_queue_interrupt() Reported-by: zdi-disclosures@trendmicro.com Fixes: f8fce75fedf7 ("fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req") Cc: stable@vger.kernel.org # 6.9 Signed-off-by: Miklos Szeredi [ adjusted context to use `fc->iq` in `fuse_resend()` since `struct fuse_chan` doesn't exist in this tree ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f98640c27cde35fdc516f6144063ff28eaf21f2c Author: Miklos Szeredi Date: Mon Aug 31 12:43:12 2026 -0400 fuse: remove fm arg of args->end callback [ Upstream commit a697d95fcdbb3bbe25cdc29db5542ddcebb831c1 ] Only used by FUSE_INIT and CUSE_INIT, these can store the relevant pointer in their structs derived from fuse_args. Signed-off-by: Miklos Szeredi Stable-dep-of: ed9c881f3b49 ("fuse: fix race between interrupt and resend") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 952f7a6d392b824d1fafd38d2d3321ec931718bd Author: Miklos Szeredi Date: Mon Aug 31 12:43:11 2026 -0400 fuse: split off fuse_args and related definitions into a separate header [ Upstream commit 229f9b9b66ab5be9e015422cf30b97740cfbdc8d ] This is going to be used by both layers (transport and filesystem) Signed-off-by: Miklos Szeredi Stable-dep-of: ed9c881f3b49 ("fuse: fix race between interrupt and resend") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a5bb215dbc34b4c6a5e144ea1416bf66450d519f Author: Joanne Koong Date: Mon Aug 31 12:43:03 2026 -0400 fuse: publish io-uring queues with release semantics [ Upstream commit 42df916e5a5f8fb4b60c8cefb54318d1ec02c580 ] fuse_uring_create_queue() initializes a fuse_ring_queue and then publishes the pointer into ring->queues[qid] with WRITE_ONCE() under the fch->lock. There are several readers that may concurrently be fetching that pointer locklessly and then deferencing it. WRITE_ONCE() doesn't ensure ordering of the queue's field initialization before the ring->queues[qid] pointer assignment. The queue must be published with smp_store_release() so the field initialization is guaranteed to happen before. Readers in paths where the read may happen concurrently with the store need to use READ_ONCE() because any race involving a plain access is undefined. Fixes: 24fe962c86f5 ("fuse: {io-uring} Handle SQEs - register commands") Cc: stable@vger.kernel.org Reviewed-by: Bernd Schubert Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi [ renamed `fch->lock` to `fc->lock` since this tree lacks `struct fuse_chan` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c051f66b621695ad7c8438a9497d79e1f4f05edb Author: Breno Leitao Date: Mon Aug 31 09:27:09 2026 -0400 usb: xhci: bail out of setup if the controller is inaccessible [ Upstream commit 78203d5b54a40f0e36196ebf31c9c7a380fc8811 ] xhci_gen_setup() locates the operational registers using the capability length read from the very first register: xhci->op_regs = hcd->regs + HC_LENGTH(readl(&xhci->cap_regs->hc_capbase)); If the controller is dead or has dropped off the bus, that read returns ~0, HC_LENGTH() truncates it to 0xff, and op_regs ends up 0xff bytes past the page-aligned MMIO base, i.e. unaligned. The first access through it, xhci_halt() -> xhci_handshake() reading op_regs->status, is then an unaligned readl() on device memory. arm64 faults on unaligned device accesses, so instead of xhci_handshake() catching the all-ones value and returning -ENODEV, setup oopses: xhci-pci-renesas 0005:08:00.0: Unable to change power state from D3cold to D0, device inaccessible xhci-pci-renesas 0005:08:00.0: xHCI Host Controller xhci-pci-renesas 0005:08:00.0: new USB bus registered, assigned bus number 1 Unable to handle kernel paging request at virtual address ffff80030a770103 ESR = 0x0000000096000021 FSC = 0x21: alignment fault Internal error: Oops: 0000000096000021 [#1] SMP pc : xhci_halt [xhci_hcd] Call trace: xhci_halt xhci_gen_setup xhci_pci_setup usb_add_hcd usb_hcd_pci_probe xhci_pci_common_probe xhci_pci_renesas_probe This was hit with a Renesas uPD720201 that failed to power up ("Unable to change power state from D3cold to D0, device inaccessible") yet still reached the HCD probe path. Read the capability register once, and if it reads back the all-ones value (as xhci_handshake() and xhci_reset() already test for), abort setup with -ENODEV before op_regs is derived from it. Reading it once also avoids re-reading a register that may change under a concurrent hot-removal. Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260806142113.2436238-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f0ccc2d323d06a9b9124988fcbf18143d4157941 Author: Niklas Neronin Date: Mon Aug 31 09:27:08 2026 -0400 usb: xhci: simplify handling of Structural Parameters 1 values [ Upstream commit df08973556851b29bd78e79db696d992ed1b43f0 ] The 32-bit read-only HCSPARAMS1 register contains the following fields: Bits 7:0 - Number of Device Slots (MaxSlots) Bits 18:8 - Number of Interrupters (MaxIntrs) Bits 23:19 - Reserved Bits 31:24 - Number of Ports (MaxPorts) Since the register value is constant for the lifetime of the controller, it is cached in 'xhci->hcs_params1'. However, platform drivers may override the number of interrupters through a separate variable, 'xhci->max_interrupters', leaving only the maximum slots and ports values still derived from the cached register. To simplify the code and improve readability, replace 'xhci->hcs_params1' with two dedicated 'u8' fields: 'xhci->max_slots' and 'xhci->max_ports'. These values are initialized once and used directly instead of calling 'HCS_MAX_SLOTS()' and 'HCS_MAX_PORTS()' macros. This change reduces code clutter without increasing memory usage. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-16-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman [ Sasha: context conflict in xhci_gen_setup() only. 6.18.y carries fe7892d46921 ("usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits") out of order -- it landed upstream after this commit -- so the "xhci->dma_mask_bits = 64;" line sits exactly where the new max_slots and max_ports assignments are inserted. Kept both, with dma_mask_bits first, which matches the resulting upstream ordering. No functional change; every other hunk is verbatim. ] Stable-dep-of: 78203d5b54a4 ("usb: xhci: bail out of setup if the controller is inaccessible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 46fb722a3bcf0d75fc4dac7a8e2d0493cd7762dc Author: Niklas Neronin Date: Mon Aug 31 09:27:07 2026 -0400 usb: xhci: use cached HCSPARAMS1 value [ Upstream commit 70651cc3f5a4c7cec529f121e36ea3b45ea84778 ] The Structural Parameters 1 (HCSPARAMS1) register is read and cached in 'xhci->hcs_params1' during host controller initialization. Since this register is read-only and its value remains constant for the lifetime of the controller, re-reading it later is unnecessary. Replace subsequent register reads with the cached 'xhci->hcs_params1' value to avoid redundant MMIO access. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-15-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 78203d5b54a4 ("usb: xhci: bail out of setup if the controller is inaccessible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4e141571d0257f4406312a9e5b7cc53511c7d535 Author: Niklas Neronin Date: Mon Aug 31 09:27:06 2026 -0400 usb: xhci: implement USB Port Register Set struct [ Upstream commit f2469d89a70cc6eb3d8141770995a3b251afa6ff ] Previously, each port's 'addr' field pointed to the base of the Host Controller USB Port Register Set, and specific registers were accessed using macros such as (port->addr + PORTPMSC). This patch replaces the raw '__le32 __iomem *addr' pointer with a typed 'struct xhci_port_regs __iomem *port_reg' pointer. With this change, individual registers can be accessed directly through the structure fields: Before: port->addr port->addr + PORTPMSC port->addr + PORTLI port->addr + PORTHLPMC After: port->port_reg->portsc port->port_reg->portpmsc port->port_reg->portli port->port_reg->porthlpmc This improves code readability and makes register access more intuitive by using named struct members instead of pointer arithmetic and macros. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 78203d5b54a4 ("usb: xhci: bail out of setup if the controller is inaccessible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8dbc9c86c3186b342d3c66b83fa991350838dc56 Author: Niklas Neronin Date: Mon Aug 31 09:27:05 2026 -0400 usb: xhci: add USB Port Register Set struct [ Upstream commit 377a91594e008848363641d07f51d2e48f4bdde5 ] Introduce a new struct for the Host Controller USB Port Register Set to enhance readability and maintainability. The Host Controller Operational Registers (struct 'xhci_op_regs') span from offset 0x0 to 0x3FF and consist of fixed fields. Following these fixed fields are the Host Controller USB Port Register Sets, which are dynamic and repeat from 1 to MaxPorts, as defined by HCSPARAMS1. Currently, the struct 'xhci_op_regs' includes: __le32 port_status_base; The first PORTSC __le32 port_power_base; The first PORTPMSC __le32 port_link_base; The first PORTLI __le32 reserved5; The first PORTHLPMC, not reserved __le32 reserved6[NUM_PORT_REGS*254]; Port registers 2 to MaxPorts Replace this with the simpler: struct xhci_port_regs port_regs[]; Port registers 1 to MaxPorts Host Controller USB Port Register Set: | Offset | Mnemonic | Register Name -------------------------------------------------------------------------- | 0x0 | PORTSC | Port Status and Control | 0x4 | PORTPMSC | Port Power Management Status and Control | 0x8 | PORTLI | Port Link Info | 0xC | PORTHLPMC | Port Hardware LPM Control Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 78203d5b54a4 ("usb: xhci: bail out of setup if the controller is inaccessible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8b7ca0029e94b3febc64da0eacba59285fb79ee2 Author: Niklas Neronin Date: Mon Aug 31 09:27:04 2026 -0400 usb: xhci: add helper to read PORTSC register [ Upstream commit 511afe80b82d2b21086e459906e6c97b4eaeed20 ] Add a dedicated helper function to read the USB Port Status and Control (PORTSC) register. This complements xhci_portsc_writel() and improves code clarity by providing a clear counterpart for reading the register. Suggested-by: Peter Chen Reviewed-by: Peter Chen Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 78203d5b54a4 ("usb: xhci: bail out of setup if the controller is inaccessible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a363197790a87f892ee10cbc18c77c1ecbf8705f Author: Niklas Neronin Date: Mon Aug 31 09:27:03 2026 -0400 usb: xhci: add tracing for PORTSC register writes [ Upstream commit 829738e59f1fad90ef7b63d6a1a4de9d5d22544a ] Introduce a dedicated write function for the USB Port Register Set (PORTSC) that includes tracing capabilities for values written to the PORTSC register. This enhancement minimizes code duplication and improves debugging. The PORTSC register is part of the Host Controller USB Port Register Set, comprising 4 x 32-bit registers. As the first register, PORTSC is accessed directly via 'port->addr'. Future commits will introduce a dedicated Port register struct to further streamline access. By adding the xhci_portsc_writel() function prior to these changes, we significantly reduce the number of same line modifications required. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 78203d5b54a4 ("usb: xhci: bail out of setup if the controller is inaccessible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 78e8ee25a5e8f2eb85bbabbeb15c8a2445b4a67f Author: David Howells Date: Mon Jun 22 10:08:50 2026 +0100 afs: Fix leak of ungot volume commit d672c276f685a540ed2b2a8bafaed4650a89022c upstream. Fix afs_lookup_volume_rcu() so that it doesn't leak a dying volume if afs_try_get_volume() fails. Fixes: 32222f09782f ("afs: Apply server breaks to mmap'd files in the call processor") Closes: https://sashiko.dev/#/patchset/20260609081738.770127-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-17-dhowells@redhat.com cc: Marc Dionne cc: Deepakkumar Karn cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Alexander Martyniuk Signed-off-by: Greg Kroah-Hartman commit c8279ae8df68cce9cd3b785e85f7a86c80a46e78 Author: Abdifatah Suruur Date: Sat Aug 29 18:40:22 2026 +0300 ksmbd: fix use-after-free in oplock break notification commit 0e753899627b5e28a9fea8bca98262a6f65a2452 upstream. smb2_oplock_break_noti() reads opinfo->conn without any lock and dereferences it after two allocations which may sleep. When the durable handle owning the oplock is disconnected, session_fd_check() clears opinfo->conn and drops its conn reference under ci->m_lock, and the last ksmbd_conn_put() frees the connection. A break triggered by another connection that races with the teardown can then resurrect the freed connection: ksmbd_conn_get() is a plain atomic_inc, and the queued break work later dereferences the stale conn via ksmbd_conn_write(), a use-after-free reachable by any authenticated client holding a durable batch oplock. Thread the caller's inode into the notification path instead of taking a new reference on it. Every caller of oplock_break() already holds a live ksmbd_file (or an explicit ksmbd_inode_lookup_lock() reference, in the parent lease break paths) on the inode that owns the break target's oplock list, so ci cannot be freed during the call, and its lock can be taken without dereferencing opinfo->o_fp, which a concurrent close may free. Select and pin the connection under ci->m_lock, the same lock session_fd_check() and ksmbd_reopen_durable_fd() use to update opinfo->conn, so a concurrent detach either loses the race to the clear or keeps the connection alive until the notification work releases it. Transfer the reference to the work item and release it on allocation failures. Fixes: b003086d7696 ("ksmbd: fix NULL-deref of opinfo->conn in oplock/lease break notifiers") Cc: stable@vger.kernel.org Signed-off-by: Abdifatah Suruur Signed-off-by: Namjae Jeon Signed-off-by: Abdifatah Suruur Signed-off-by: Greg Kroah-Hartman commit e5e7a61fa9e82c008e0be6eba59d9cc8e66760cc Author: Mohamed Ahmed Date: Tue Aug 25 04:14:06 2026 +0400 drm/nouveau/gsp: fix vblank interrupts on GB20x commit 5bb489b333237c1bf63a891a4362986253a0060a upstream. The GSP path programs per-head timing (vblank) interrupts the same way on every generation. NVD5.0 (GB20x) reworked the FE interrupt frontend around four message-based kernel vectors (high latency, low latency, PMU, and GSP) and moved RM head-timing interrupts to the dedicated low-latency vector: - The enable is NV_PDISP_FE_RM_INTR_EN1_HEAD_TIMING, 0x611ef0 + head*4 (570.144 kernel_head_0501.c, renamed kernel_head_0502.c from 575.51.02 on, and v05_01 dev_disp.h). - The vector is reported as a separate interrupt table entry, MC_ENGINE_IDX_DISP_LOW (intr_gb202.c, intrCacheDispIntrVectors). - The vector must be re-armed through NV_PDISP_FE_INTR_RETRIGGER(1) at 0x611f34 after servicing (kdispServiceInterrupt -> kdispIntrRetrigger_v05_01). The event latch (0x611800), per-head status (0x611c00), and dispatch summary (0x611ec0) the interrupt handler uses are unchanged on GB20x (kheadReadPendingVblank_v03_00 and kheadResetPendingLastData_v03_00 remain for DISPv0502+). On GB20x the old code enables head timing onto the legacy vector, leaves its handler there, and never re-arms the message-based vectors. Page flips still complete (nv50 sends those events from the commit path), so the desktop looks fine while DRM vblank waits and vblank sequence queries are affected. Supply GB20x vblank enables and an interrupt handler that re-arms the vector after servicing through gb202_gsp_disp, translate the low-latency interrupt table entry as a second NVKM_ENGINE_DISP instance, and add a gsp.intr_low_latency flag so r535_disp_oneinit() attaches the handler to that instance. GB20x was the last cross-file user of the TU1xx vblank enables, so make those static and drop their head.h prototypes. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-9-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit dc7c40ffaa1b6ed09e4d056e7d0a8db9b078b4de Author: Mohamed Ahmed Date: Tue Aug 25 04:14:05 2026 +0400 drm/nouveau/disp: fix head state readback on GB20x commit 9421dfe912e55360e6b9301a110acb00df7e7320 upstream. The GSP path reads armed head state and the RG scanout position through gv100_head_state() and gv100_head_rgpos() on every generation. gv100_head_state() reads the core channel's state mirror at a 0x400 per-head stride, which NVD5.0 (GB20x) doubled. Per NVIDIA's published CA7D class header every HEAD_SET method sits at 0x2000 + head * 0x800, while the mirror bases are unchanged (assembly at 0x680000, armed at +0x8000, per OpenRM's v03_00 channel-user-base HAL which is still used on DISPv0502). Add gb202_head_state(), the same readback at the 0x800 stride, and a gb202_gsp_head table to supply it. gv100_head_rgpos() is kept. The RG registers keep their per-head 0x800 stride on NVD5.0, and OpenRM's kdispReadRgLineCountAndFrameCount_v03_00 still reads NV_PDISP_RG_DPCA on DISPv0502. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-8-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0e346b65a413045fa87123c7956a98712350980b Author: Mohamed Ahmed Date: Tue Aug 25 04:14:03 2026 +0400 drm/nouveau/disp: fix HDMI GCP AVMute register offsets on GB20x commit 764deff8450c9a83e335c17c32ea258ec25bb71e upstream. The GSP path brackets audio enablement with a General Control Packet AVMute toggle. r535_sor_hdmi_audio() calls the gsp.hdmi_gcp hook, which every chip so far serves with tu102_sor_hdmi_gcp() and the legacy GCP unit at 0x6f00c0/0x6f00cc. On GB20x the SF packet units were compacted and the old generic and VSI units are gone (ACR keeps slot 2) and the GCP unit moved from slot 3 to slot 1 (control 0x6f0040 and subpack 0x6f004c from NVIDIA's published clc971.h. The same offsets are also used by OpenRM's hdmiWriteGeneralCtrlPacketC871() on these chips). The old addresses are reserved on GB20x, so the AVMute writes were silent no-ops and mitigated only by the equivalent GCP r535_sor_hdmi_audio() already sends through the SET_OD_PACKET RM control. Add a GB20x GCP writer using the new offsets and hook it into gb202_gsp_disp, keeping the direct MMIO path in sync with the hardware as on earlier chips. Only SB0 (the AVMute bit) is written. On NVD5.0 the subpack register also carries SB1_CTRL (bit 24), which selects where the deep-color CD/PP fields are generated (hardware or from the driver, with the default being HW). hdmiWriteGeneralCtrlPacketC871() likewise writes only SB0-SB2. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-6-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit ecb110991bc9431ebb6c4a9edcc7b154a2149bde Author: Mohamed Ahmed Date: Tue Aug 25 04:14:02 2026 +0400 drm/nouveau/disp: fix HDMI vendor infoframes on GB20x commit 92f09dcb4e8473ab25764e950994ab7b6abce6dd upstream. The GSP path reuses the GV100 direct-MMIO infoframe writers on every chip. On GB20x that is only half right as while the legacy SF AVI unit is unchanged, the legacy VSI unit at 0x6f0100 was removed, so gv100_sor_hdmi_infoframe_vsi() writes into a reserved area and no vendor infoframe ever reaches the HW. This affects HDMI-VIC signalling which can impact some 4K modes for legacy HDMI 1.4 sinks. GB20x (NVDisplay 5.0+) reorganised the SF HDMI packet units. Per NVIDIA's published C971/CA71 DISP_SF_USER class headers, only three legacy units remain (AVI at +0x000, GCP at +0x040, ACR at +0x080), and vendor infoframes must instead be sent through the shared generic infoframe units at +0x130, whose 9-dword packet slots are loaded through the shared data port at +0x3f0/+0x3f4. Add a VSI writer using the same programming sequence OpenRM uses on these chips (nvhdmipkt_C971.c, programAdvancedInfoframeC971()): disable the unit and wait for it to idle, clear the SENT status, write the packet through the data port with a zero inserted in HB3 after the three header bytes, then enable the unit for every-frame transmission during vblank. Generic unit 1 is used for the VSI, matching the slot assignment in NVIDIA's nvkms (NVHDMIPKT_TYPE_SHARED_GENERIC2, unit 0 is reserved for extended metadata packets and unit 2 for the HDR DRM infoframe, if those are wired up later). GB20x so far shared GA10x's display entry point. Give it its own, gb202_disp_new(), with a gb202_gsp_disp table that supplies the VSI writer to the GSP path and otherwise carries the same hooks as GA10x. The following fixes fill in the rest of the GB20x differences there. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-5-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 4739d519def725d749b0794652c9117c2e3aaa88 Author: Mohamed Ahmed Date: Tue Aug 25 04:14:01 2026 +0400 drm/nouveau/disp: route GSP-RM display MMIO through nvkm_disp_func hooks commit 9886aad51f4b5e7082209a153e404bcd8101356c upstream. The GSP-RM display code in rm/r535/disp.c borrows a few register-programming routines from engine/disp (the head-timing interrupt handler, vblank enables, armed head state and scanout position readback, the AVI/VSI infoframe writers and the GCP AVMute write) and so far picked them by name, which means it has to know which chip it runs on the moment a generation changes any of them. Give nvkm_disp_func a .gsp table that each chip fills with exactly those hooks, add tu102_gsp_disp (TU1xx) and ga102_gsp_disp (GA10x onwards) carrying the current functions, hand them to r535_disp_new() instead of the full hardware tables, and make rm/r535/disp.c call through the hooks. The head hooks are a whole nvkm_head_func, so r535_head goes away and the chip's own table is handed to nvkm_head_new_(). r535_sor_hdmi gets infoframe forwarders, r535_sor_hdmi_audio() calls the GCP hook, and the interrupt handler comes from the table. The tables are per chip even though the two currently coincide, so a generation that changes a hook only touches its own file. rm/r535/disp.c no longer contains chip-specific register code, and a new display generation only has to provide its own table. No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-4-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 94d8195eb41854c154ea3d3bc49059c5e98b7423 Author: Mohamed Ahmed Date: Tue Aug 25 04:14:00 2026 +0400 drm/nouveau/disp: move the GSP HDMI GCP AVMute write to engine/disp commit eb1ffc3dc72d379a41e367a44b99fb61a15bf8ba upstream. r535_sor_hdmi_audio() pairs two RM controls (a SET_OD_PACKET carrying the same General Control Packet, and the audio mute-stream toggle) with a direct write of the GCP AVMute bit through the SF GCP unit. The controls are RM and stay, but the direct write is register programming and moves next to the other per-chip display code as tu102_sor_hdmi_gcp(). No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-3-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit a046e789ab66e65f77f296cb9c5c1e2cfc16e933 Author: Mohamed Ahmed Date: Tue Aug 25 04:13:59 2026 +0400 drm/nouveau/disp: move GSP head-timing ISR and vblank helpers to tu102.c commit c6659e0ffc19b4ef0b3273c185cb8409a154eada upstream. The GSP-RM display code in rm/r535/disp.c owns a handful of direct MMIO routines: the head-timing (vblank) interrupt handler and the per-head vblank enable/disable. They program display registers, not RM, so they belong with the rest of the per-chip register code in engine/disp/. Move them to tu102.c (Turing is the first GSP-capable generation) as tu102_disp_intr() and tu102_head_vblank_get()/put(), exported for rm/r535/disp.c, which keeps calling them by name for now. No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-2-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 1101cbfe7f342e5eaaf7444965d4f1215abdac4c Author: Zhenhao Wan Date: Tue Aug 11 16:46:30 2026 +0800 drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE commit 38a62306c4266bcb3cd89e33c7111ee33096ebb3 upstream. A successful OP_UNMAP_SPARSE marks its region dirty with nouveau_uvma_region_dirty() and defers the teardown to nouveau_uvmm_bind_job_cleanup(); it does not remove the region from uvmm->region_mt. If a later op in the job fails, the unwind path never clears reg->dirty (set in one place, cleared nowhere) and sets op->reg = NULL, so cleanup skips the teardown. The region is left in the tree with dirty set and its completion never signalled. Later binds over that range then fail permanently -- -ENOENT or -EINVAL from the dirty checks, or an unkillable wait_for_completion() in bind_validate_region() -- for the lifetime of the uvmm. Clear reg->dirty when the unwind reverts the sparse unmap, restoring the region to the state it was found in. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-3-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 24c25b182d17d1bdfde0088c96bdf6f93e8f46bc Author: Zhenhao Wan Date: Tue Aug 11 16:46:29 2026 +0800 drm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSE commit ccf930812f23b8259ef64fd3394d53b093e4651a upstream. In nouveau_uvmm_bind_job_submit()'s OP_UNMAP_SPARSE arm, op->reg is set from nouveau_uvma_region_find(), which only looks the region up and takes no reference; a region's sole reference is its membership in uvmm->region_mt. Two failure paths leave op->reg set: the -ENOENT check when the region is busy, and the drm_gpuvm_sm_unmap_ops_create() failure. The sibling nouveau_uvmm_sm_unmap_prepare() failure just below clears op->reg; these two do not. unwind_continue steps back one op, so the failing op is skipped by the unwind loop and its op->reg stays set. nouveau_uvmm_bind_job_cleanup() then enters its if (op->reg) branch and calls nouveau_uvma_region_remove() and nouveau_uvma_region_put() on it, dropping the tree's sole reference and freeing a region this job never created. The comment above the cleanup loop documents the broken invariant: op->reg must be NULL on submit failure. This frees a live region on an unrelated failure, reachable single-job when drm_gpuvm_sm_unmap_ops_create() returns -ENOMEM; if another job owns the same region, its cleanup then removes and puts the freed region, a use-after-free. Clear op->reg on both failure paths. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-2-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit b7dc03e09313d22a6d230b759de3b05d504c008f Author: Zhenhao Wan Date: Tue Aug 11 16:46:28 2026 +0800 drm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE op commit 412a6ceb56d501ef2f8202e26ab4b5d4dfbca566 upstream. Each bind_job_op is zeroed by kzalloc_obj() in bind_job_op_from_uop(), and the OP_MAP_SPARSE case in nouveau_uvmm_bind_job_submit() only creates a region, so op->ops stays NULL for a successfully processed sparse map. If a later op in the same job fails, the reverse unwind loop revisits that op and calls drm_gpuva_ops_free(&uvmm->base, op->ops) unconditionally. drm_gpuva_ops_free() dereferences its argument right away (list_for_each_entry_safe on &ops->list), so a NULL op->ops oopses. The path is reachable by any render-node fd holder, since NOUVEAU_VM_BIND is DRM_RENDER_ALLOW. Guard the free with IS_ERR_OR_NULL(), as nouveau_uvmm_bind_job_cleanup() already does for the identical free. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-1-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 4cf436de06ca9970a00adcbace96ac8f8e402c2b Author: Faith Ekstrand Date: Fri Aug 21 23:42:59 2026 -0500 drm/nouveau: Use write-combined maps for coherent commit 774b73428e6eabb4f0382aeeb76e569c7b106a29 upstream. On Tegra devices, uncached maps translate to device memory, causing unaligned accesses by userspace resulting in a SIGBUS. Instead, use write-combined maps to ensure proper access. This would also affect discrete cards on any Arm device. It was determined that discrete cards regardless of cpu arch should use write-combined maps for coherent anyways. Thus this change is made for all gpu types. Cc: stable@vger.kernel.org Signed-off-by: Faith Ekstrand Co-developed-by: Aaron Kling Signed-off-by: Aaron Kling Fixes: 1b4ea4c5980f ("drm/ttm: set the tt caching state at creation time") Link: https://patch.msgid.link/20260821-tegra-coherent-wc-v2-1-2b1ddb67bf18@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit f3830fdd6930e233d727f29eee1617f7e6a0e9e5 Author: Marek Czernohous Date: Thu Aug 13 01:13:27 2026 +0200 drm/nouveau: unsubscribe the channel-kill event before the fence context commit 511585987d27d8cb668acebd399fc4deda23404c upstream. nouveau_channel_del() tears the fence context down first and only drops the channel-kill subscription later, in the middle of the nvif object teardown: if (chan->fence) nouveau_fence(chan->cli->drm)->context_del(chan); ... nvif_object_dtor(&chan->vram); nvif_event_dtor(&chan->kill); The subscribed handler is nouveau_channel_killed(), which calls nouveau_channel_kill() and from there nouveau_fence_context_kill() on chan->fence. A kill event delivered in that window takes fctx->lock and walks fctx->pending on a fence context that context_del() has already freed. Nothing reaches this below Fermi today, because the subscription is gated on FERMI_CHANNEL_GPFIFO and nothing kills a channel there. On Fermi and newer the window is real but narrow, since a kill has to land exactly while the channel is being destroyed. That is reason enough on its own, which is why this carries a Fixes: tag. The last patch in this series subscribes Tesla channels as well; nothing kills those today, so it does not widen the exposure now, but it is the groundwork for a recovery path that would, and the ordering is better fixed before that lands than alongside it. Drop the subscription before anything it depends on is torn down. Fixes: ea13e5abf807 ("drm/nouveau: signal pending fences when channel has been killed") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Marek Czernohous Fixes: ea13e5abf807 ("drm/nouveau: signal pending fences when channel has been killed") Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260812231330.705425-2-mczernohous@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5ba4bcb3b96cda05f3c283fda3842580b8e84590 Author: Mohamed Ahmed Date: Tue Aug 25 04:14:04 2026 +0400 drm/nouveau/gsp: use per-version DP_CONFIG_STREAM params on r570 firmware commit 39fd4b742720c68da8695ee1ffa85c5fea4f8e11 upstream. NVIDIA removed the deprecated actualPclkHz/linkClkFreqHz fields and the whole Legacy{activeCnt, activeFrac, activePolarity, mvidWarEnabled, MvidWarParams} block from the SST sub-struct of NV0073_CTRL_CMD_DP_CONFIG_STREAM_PARAMS between the 535 and 570 releases (compared in OpenRM tags 535.113.01 vs 570.144), shrinking the struct. Everything nouveau writes sits at identical offsets in both layouts except the trailing SST.bEnableAudioOverRightPanel (written as zero), but the size is wrong on r570, which means r535_sor_dp_sst() and r535_sor_dp_vcpi() are sent with an incorrect size. Route the .sst/.vcpi IOR functions through nvkm_rm_api_disp the same way bl_ctrl and dp.get_caps/set_indexed_link_rates already are. Keep the existing implementation for r535 and add an r570 implementation built against the 570.144 layout, which already exists in r570/nvrm/disp.h but was unused until now. Also add the NV0073_CTRL_CMD_DP_CONFIG_STREAM define that was missing from the layout. Other DP controls sent through shared r535 code did not change layout between the tags. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-7-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 859d8b6c5b274c79f8b2122a384a9d11a347dd29 Author: Shixiong Ou Date: Fri Jul 31 19:17:29 2026 +0800 drm/sysfb: ofdrm: Fix is_avivo() constant comparison bug commit 958f35cbb8955ca3fa439cd9f2092cb42414aa8c upstream. The is_avivo() function has a logic error where it compares a constant to another constant instead of checking the device parameter: (PCI_VENDOR_ID_ATI_R600 >= 0x9400) Signed-off-by: Shixiong Ou Reviewed-by: Thomas Zimmermann Fixes: f496834e1674 ("drm/ofdrm: Add per-model device function") Signed-off-by: Thomas Zimmermann Cc: # v6.2+ Link: https://patch.msgid.link/20260731111729.703116-1-oushixiong1025@163.com Signed-off-by: Greg Kroah-Hartman commit ded6ad826fe0fd059333d3a3b3e1742c8e45ff41 Author: Shixiong Ou Date: Tue Aug 25 18:41:34 2026 +0800 drm/sysfb: ofdrm: Fix integer overflow in fb_size calculation commit c6f48e59ece0123f6a11527ad4d89b21c2d65b87 upstream. The framebuffer size calculation `fb_size = linebytes * height` can overflow when both values are large (e.g., 46341 * 46341 > INT_MAX). Since linebytes and height are both int types, the multiplication is performed as int * int, which results in undefined behavior on overflow. Use check_mul_overflow() to detect and prevent this overflow, consistent with the approach used in simpledrm.c and corebootdrm.c. Signed-off-by: Shixiong Ou Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Fixes: c8a17756c425 ("drm/ofdrm: Add ofdrm for Open Firmware framebuffers") Cc: # v6.2+ Link: https://patch.msgid.link/20260825104134.669676-1-oushixiong1025@163.com Signed-off-by: Greg Kroah-Hartman commit 6892f0a2f6b5990b9572ba043dd14dd4df6bb3f0 Author: Thomas Zimmermann Date: Thu Jun 25 11:39:36 2026 +0200 drm/sysfb: simpledrm: Improve stride validation commit df6533f11688aa30be3bb883c7637f4ffdbb7cbd upstream. Validate the computed stride against the maximum value INT_MAX. Signed-off-by: Thomas Zimmermann Reviewed-by: Thierry Reding Reviewed-by: Maxime Ripard Reviewed-by: Javier Martinez Canillas Fixes: 7bfa5c7b28d6 ("drm/simpledrm: Compute linestride with drm_format_info_min_pitch()") Cc: # v6.1+ Link: https://patch.msgid.link/20260625094509.157581-5-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 54e32ad5e0c74c7087a4a508f9274057fcdb4a2f Author: Thomas Zimmermann Date: Thu Jun 25 11:39:34 2026 +0200 drm/sysfb: simpledrm: Improve panel-size validation commit 3a75a0761914d01c7362adf1f906cc1d1762c189 upstream. Validate the panel size from the device-tree node against the limitations of struct drm_display_mode. The type only stores sizes in 16-bit fields. Fail transparently on errors; do not warn. v3: - move comments to a more prominent place (Thierry) v2: - only use initialized values in debugging output (Sashiko) Signed-off-by: Thomas Zimmermann Reviewed-by: Thierry Reding Reviewed-by: Maxime Ripard Reviewed-by: Javier Martinez Canillas Fixes: 2a6d731a8f16 ("drm/simpledrm: Allow physical width and height configuration via panel node") Cc: Rayyan Ansari Cc: # v6.4+ Link: https://patch.msgid.link/20260625094509.157581-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 8d65b8d1722d8db40c7d41eecc7cb8e081b86a35 Author: Thomas Zimmermann Date: Thu Jun 25 11:39:33 2026 +0200 drm/sysfb: simpledrm: Improve framebuffer-size validation commit 03f1a3545b721fa7fdadd00080e237519a286a97 upstream. Validate the framebuffer size from the firmware against the limitations of struct drm_display_mode. The type only stores sizes in 16-bit fields. Fail probing on errors. v2: - remove unused function simplefb_get_validated_int0() (Sashiko) Signed-off-by: Thomas Zimmermann Reviewed-by: Thierry Reding Reviewed-by: Maxime Ripard Reviewed-by: Javier Martinez Canillas Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Cc: # v5.14+ Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Link: https://patch.msgid.link/20260625094509.157581-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit fd3462acf6590687ec1f2e062109723a76a49cbc Author: Sunday Clement Date: Thu Aug 6 10:59:34 2026 -0400 drm/amdkfd: Reject zero-sized AQL queue allocations after size halving commit 40ba09e11188d1b7f79d51fc28aca5ea45e0c138 upstream. KFD_IOC_ALLOC_MEMORY_OF_GPU with flag KFD_IOC_ALLOC_MEM_FLAGS_AQL_QUEUE_MEM and size=1 triggers the AQL wraparound workaround (size >>= 1), reducing size to 0. The resulting zero passes through PAGE_ALIGN(0) = 0 without validation, bypassing the per-process VRAM quota check in reserve_mem_limit() (vram_used + 0 > vram_available is always false). The fix adds post-halving zero-size validation in the primary allocation path (amdgpu_amdkfd_gpuvm.c). The check happens after size halving but before reserve_mem_limit(), and uses err_alignment_size error path to properly clean up the allocated kgd_mem structure and mutex. Cc: stable@vger.kernel.org Signed-off-by: Sunday Clement Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ebffa44e7a21ead59ac4b4264e8fc2cbb44c4a21 Author: Vladimir Marioukhine Date: Wed Aug 12 12:58:12 2026 -0400 drm/amdkfd: guard against NULL restore_mqd in CRIU queue restore commit 6aa530642f95d5c48aa336416f94a35e7949b647 upstream. Both create_queue_cpsch() and create_queue_nocpsch() unconditionally call mqd_mgr->restore_mqd() when a CRIU restore is in progress (qd != NULL), with no NULL guard. On any system where restore_mqd is not implemented for the given queue type, a user holding CAP_CHECKPOINT_RESTORE can trigger a kernel NULL pointer dereference and panic the machine by issuing KFD_IOC_CRIU_OP_RESTORE with a crafted queue restore object. Note that checkpoint_mqd is likewise unimplemented on GFX12, so no legitimate CRIU image can reach this path — only a hand-crafted restore payload. Add a NULL guard for restore_mqd immediately after mqd_mgr is resolved, unwinding via the existing error labels and returning -EOPNOTSUPP if the callback is not implemented. This mirrors the existing checkpoint_mqd guard in checkpoint_mqd(). Fixes: 48f0bdf4e38e ("drm/amdkfd: Added MQD manager files for GFX12.") Cc: stable@vger.kernel.org Signed-off-by: Vladimir Marioukhine Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ae806a95b28fcecb913430cfa45a252e91a945d6 Author: Xiaogang Chen Date: Sun Aug 23 15:47:15 2026 -0500 drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram commit 520e345ffe05aabef1db82beda4288afb1757ff2 upstream. When migration vm range is hole at cpu side(MIGRATE_PFN_MIGRATE set + MIGRATE_PFN_VALID unset) driver still allocates device pages. There is no dma map of src pages and migration. j is 0 and svm_migrate_copy_memory_gart() will return an uninitialized r. That can trigger out_free_vram_pages to drop all VRAM just set up. Initialize r and only call the last svm_migrate_copy_memory_gart if j > 0. Current code postponed the last page to the final copy. This patch flushes on the last page when reach to the end of current drm_buddy_block; avoids another svm_migrate_copy_memory_gart. Cc: stable@vger.kernel.org Signed-off-by: Xiaogang Chen Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit da87bcad1f781d822e7ced6d1de9dbc6d381c72e Author: Xiaogang Chen Date: Sun Aug 23 15:22:54 2026 -0500 drm/amdkfd: Fix error path at svm_migrate_copy_to_ram commit 960c4a8069bfd352c48cc88592618f1ebe24c69e upstream. If page migration from device to sys ram fails for some reasons driver needs release and unlock allocated system pages. To do that driver should use page physical address, or pfn, then get struct page*. Current driver uses dma address(for adev) that is not correct with IOMMU enabled, or even in general. The patch releases and unlocks allocated system pages based on where migration failed by struct page* of sys ram pages. Also dma_unmap correspodent system ram pages at error path. Cc: stable@vger.kernel.org Signed-off-by: Xiaogang Chen Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e230c546ed93741833ab5babb0b202f9c2052b45 Author: Priya Hosur Date: Thu Aug 27 15:02:46 2026 +0530 drm/amdkfd: Add TLB flush after MES queue eviction/suspension commit 94e25cb6ab7f4f025bcdcd8ea79fda30f12843a4 upstream. MES (Micro Engine Scheduler) does not perform heavy-weight TLB invalidation after unmapping queues, unlike HWS which does this automatically. This causes a race condition where in-flight DMA descriptors can access memory that has been unmapped, leading to page faults and GPU queue hangs during SVM page migration. The issue manifests as KFDSVMRangeTest.MultiThreadMigrationTest failures on gfx1151 (Strix Point) with XNACK mode 1 enabled - the GPU compute queue hangs with packets submitted but never consumed. Add kfd_flush_tlb() calls after MES queue removal in two locations: - evict_process_queues_cpsch(): after all queues removed during eviction - suspend_queues(): after debug/criu queue suspension (with mem_fence barrier) This ensures all in-flight memory accesses from unmapped queues are flushed before memory is freed or migrated. Signed-off-by: Priya Hosur Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2e4b909fab96c557e43f661a8944d979db6dada9 Author: Sunil Khatri Date: Thu Aug 27 20:33:35 2026 +0530 drm/amdgpu: use AMDGPU_GPU_PAGE_SHIFT instead of PAGE_SHIFT commit d6e16df7df4d2c39e2b04b355d0434fb90e2d62c upstream. For different address types the variable PAGE_SHIFT might not work well and it's better to use the GPU specific one Signed-off-by: Sunil Khatri Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 3494b77d10375e0f9ab784e9b20763339844b55b) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 65e643703f1509f12395843f264782f1f7e60d7d Author: Sunil Khatri Date: Mon Aug 31 20:18:31 2026 +0530 drm/amdgpu: update the fw version for gfx12 userqueues commit 49a74a2388528c1a2e96f01114c4513e635605fe upstream. Update to the latest stable fw versions where userqueues is working as it is expected with major fixes. Signed-off-by: Sunil Khatri Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 69fa36e3ac92f2544ee7a1b719ec212b8247a2da) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b7cb1b66961371bd565d85773d5a679c8428d6f3 Author: Sunil Khatri Date: Mon Aug 31 20:17:17 2026 +0530 drm/amdgpu: update the fw version for gfx11 userqueues commit c748dd03df33360549ad60cdccee13570e9c0f90 upstream. Update to the latest stable fw versions where userqueues is working as it is expected with major fixes. Signed-off-by: Sunil Khatri Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit d50201b891604ab97f305d4a20d888ba93305b48) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8de8b4e11ce487bccde37cc23c350f5084a86818 Author: Kanala Ramalingeswara Reddy Date: Mon Aug 31 19:59:11 2026 +0530 drm/amdgpu: Skip accessing psp rum time db for APUs commit a26301203a196a991527f7b1ab884d4dd0e7c95e upstream. Psp runtime DB is for dGPUs only. Signed-off-by: Kanala Ramalingeswara Reddy Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit dce8195027f146467c9378efb2bb1b0859cb735e) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 492dbf832964c30e7e837773ecc7ac6bf152f3f0 Author: Guangshuo Li Date: Sat Aug 8 20:09:34 2026 +0800 drm/amdgpu: fix autosuspend cleanup during removal commit ef5fcf2a6c320676bf8be2dadac93d9023b468b7 upstream. amdgpu_pci_probe() calls pm_runtime_use_autosuspend(), but amdgpu_pci_remove() does not call the matching pm_runtime_dont_use_autosuspend(). If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to the remove path. This issue was found by manual code inspection. Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260808120934.2813010-1-lgs201920130244@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 812c406f752914d8897da37c8fb2e86488054623 Author: Yang Wang Date: Wed Aug 5 11:44:54 2026 +0800 drm/amdgpu: Disable runtime PM for externally attached dGPUs commit c52feb4365396b6a881b5e8a95540517ffabb3b7 upstream. pci_is_thunderbolt_attached() requires an upstream PCI bridge with is_thunderbolt set from an Intel Thunderbolt VSEC. This does not cover the affected ASM4242 USB4 PCI hierarchy: 00:02.2 \- 0f:00.0 [1b21:2421] +- 10:01.0 [1b21:2423] -> 45:00.0 -> 46:00.0 | -> 47:00.0 -> 48:00.0 -> 49:00.0 [1002:7590] \- 10:03.0 -> 76:00.0 [1b21:2425] USB4 Host Router The host router is outside the GPU upstream bridge chain, leaving no ancestor with is_thunderbolt set. PCI core propagates DEVICE_REMOVABLE below the external-facing PCIe tunnel. Disable Runtime PM when either pci_is_thunderbolt_attached() or dev_is_removable() is true. Cc: stable@vger.kernel.org Signed-off-by: Yang Wang Reviewed-by: Candice Li Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 964de255497ffd7cb8a86e405b8ac6d927e7e177 Author: Xiang Liu Date: Fri Aug 21 17:41:57 2026 +0800 drm/amdgpu: clamp the isolation index for rings outside a partition commit b30900566642ceb2c9e12b56c2afec28d0fd91a0 upstream. adev->isolation[] has one slot per partition, but a ring that is not assigned to one keeps AMDGPU_XCP_NO_PARTITION, which is ~0, so indexing the array with it is out of bounds. SDMA submissions hit this on both the isolation enforcement and the VM flush path and trip UBSAN. Fall back to the first slot the way the cleaner shader path already does, and stop taking the address before the ring type check that makes it relevant. Cc: stable@vger.kernel.org Signed-off-by: Xiang Liu Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b3a7e0b69903e76415abb057119640e1398ab2e8 Author: Yang Wang Date: Wed Aug 12 11:08:40 2026 +0800 drm/amdgpu: check thunderbolt before switcheroo registration commit 8587d48d694da5aca580f92461658ec14470592b upstream. Introduce a helper to consolidate the vga_switcheroo registration condition used by the init and fini paths. Keep the explicit pci_is_thunderbolt_attached() check, as dev_is_removable() does not provide equivalent coverage for Thunderbolt-attached GPUs. This ensures such devices remain excluded from switcheroo registration while preserving the existing PX and Apple gmux handling. Cc: stable@vger.kernel.org Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 66b1b309886337745d395bbc158440ab196305ce Author: Thadeu Lima de Souza Cascardo Date: Mon Jul 27 17:45:49 2026 -0300 drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used commit 4d4be202165e832d74849b4a68e289a2a377039c upstream. Commit 1c6ceeee6ebb ("drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms. Fixes: 24835e442f28 ("drm: reference count event->completion") Cc: stable@vger.kernel.org Signed-off-by: Thadeu Lima de Souza Cascardo Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patch.msgid.link/20260727-drm_crtc_atomic_commit_leak-v1-1-23d9948a9d7c@igalia.com Signed-off-by: Greg Kroah-Hartman commit acd2dd6ecd89e9c2af43397b47e5c60deec4be51 Author: Kavan Smith Date: Mon Jul 6 18:32:40 2026 -0700 drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value commit 6cd33b6f4155efc20485929fd0b56bb704641db9 upstream. MSM8916 runtime DSI commands still go through msm_dsi_host_xfer_prepare(), which re-applies the link clock rate before enabling the link clocks. That is fine in principle, but on DSI 6G the requested byte clock rate often does not exactly match the DSI PHY PLL's realizable rate. For example, the driver can request 56250000 Hz while the PLL actually runs at 56246337 Hz. Because the requested and actual rates differ slightly, every later link_clk_set_rate() call is treated as a real clock change and re-locks the PLL. On a video-mode panel without an internal timing generator, such as samsung,s6d7aa0 / lsl080al03 on MSM8916, that live-clock glitch makes the panel lose pixel lock and visibly corrupts scanout on each runtime DCS command, including backlight writes. Fix this by rounding the computed 6G byte clock rate up front, before it is stored in msm_host->byte_clk_rate and reused by later transfers. Once the host carries the PLL-achievable rate instead of the idealized one, repeated link_clk_set_rate() calls become no-ops in the common clock framework and no longer re-lock the PLL. This keeps the normal transfer callback sequencing intact, preserves the OPP vote path in link_clk_set_rate(), and matches the fix direction suggested in the original 2018 discussion. Reported-by: Daniel Mack Closes: https://lore.kernel.org/all/1a682c5b-7fc9-3aaa-120b-64b239a355a3@zonque.org/ Fixes: 6b16f05aa39f ("drm/msm/dsi: Split clk rate setting and enable") Cc: stable@vger.kernel.org Signed-off-by: Kavan Smith Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/738234/ Link: https://lore.kernel.org/r/20260707013240.681012-1-kavansmith82@gmail.com [DB: dropped extra chunk from the patch] Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit 72a95df6bbc7d20c7af1e39d86b3e910cccd01ad Author: Tao Yu Date: Wed Aug 19 15:28:35 2026 +0800 drm/gud: validate TV mode names before creating enum property commit da1ea35fea67ad841f4ada28dd61b41be65e5437 upstream. The GUD protocol returns TV mode names as fixed-size GUD_CONNECTOR_TV_MODE_NAME_LEN entries and requires each name to be NUL-terminated. gud_connector_add_tv_mode() currently passes each fixed-size entry directly to drm_mode_create_tv_properties_legacy(), which eventually reaches drm_property_add_enum() and strlen(). If a device returns an entry without a terminating NUL byte, strlen() reads past the end of the slot and can run beyond the allocated buffer, triggering an out-of-bounds read. Validate that each returned TV mode name contains a NUL terminator within its fixed-size slot before passing it to the DRM property code. If a malformed entry is found, reject the device response with -EIO. This fixes the out-of-bounds read without changing the handling of valid devices, and avoids silently truncating malformed protocol data. Reported-by: syzbot+9ae8e7884e451eaed5b4@syzkaller.appspotmail.com Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Signed-off-by: Tao Yu Reviewed-by: Ruben Wauters Cc: Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260819072835.4074130-1-tao1.yu@intel.com Signed-off-by: Greg Kroah-Hartman commit b86438a5c6b0250ccb07dd380184d1e70e0dea6c Author: Deepanshu Kartikey Date: Sun Aug 16 14:22:34 2026 +0530 drm/gud: NUL-terminate TV mode names read from the device commit 500cb24cd61bad8a2747ddfc49b7034899c82d94 upstream. gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use. Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Reported-by: syzbot+916c888ba5f1a54c9526@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=916c888ba5f1a54c9526 Tested-by: syzbot+916c888ba5f1a54c9526@syzkaller.appspotmail.com Signed-off-by: Deepanshu Kartikey Acked-by: Ruben Wauters Cc: Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260816085234.22053-1-kartikey406@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7e28853c78c20bb8ba4c1dba702430cd05e09f76 Author: David (Ming Qiang) Wu Date: Fri Aug 7 15:12:14 2026 -0400 drm/amdgpu/vcn: fix integer overflow in dec_msg buffer count check commit 4d7390530853eb7befda9cc786e4c86e8ad7ac9e upstream. If the supplied msg[2] (num_buffers) is 0x3FFFFFFF, the expression 6 + num_buffers * 4 wraps to 2 and the bounds check passes, letting the parser loop far past the end of the message BO. Triggering it additionally requires a ~4GiB mapping so that msg[1] survives the earlier "header does not fit in BO" check. Rewrite the test in division form, which is overflow-free by construction. Also update the message to reflect that msg is invalid. Fixes: b193019860d6 ("drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg") Fixes: 0a78f2bac142 ("drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg") Cc: stable@vger.kernel.org Signed-off-by: David (Ming Qiang) Wu Reviewed-by: Leo Liu Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 0b2615b8b54f58bbdf986dffb38cbc35214a5cc5 Author: Harry Wentland Date: Tue Aug 4 17:04:05 2026 -0400 drm/amd/display: validate plane degamma LUT size for private color prop commit e4c3ab59021e7c146a84b6671f0d530972bd58b4 upstream. Unlike the CRTC degamma path, which is guarded by amdgpu_dm_verify_lut_sizes(), the per-plane degamma LUT size was never validated before use. __set_dm_plane_degamma() passed the user-supplied size straight into __is_lut_linear() and, for a non-linear LUT, into __set_input_tf() -> __drm_lut_to_dc_gamma(), the latter always iterating MAX_COLOR_LUT_ENTRIES entries regardless of the actual LUT size. A malformed AMD_PLANE_DEGAMMA_LUT blob (e.g. a single entry) could thus trigger a divide-by-zero in __is_lut_linear() or an out-of-bounds read in __drm_lut_to_dc_gamma(). Reject any plane degamma LUT whose size does not match MAX_COLOR_LUT_ENTRIES, mirroring the invariant the code already asserts a few lines below (and which the CRTC path enforces). The AMD_PLANE_DEGAMMA_LUT property is only exposed on builds with AMD_PRIVATE_COLOR defined. Fixes: 980f8710075a ("drm/amd/display: add plane degamma TF and LUT support") Cc: stable@vger.kernel.org Signed-off-by: Harry Wentland Reviewed-by: Melissa Wen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 295d2bf42061db490254e748f9344545bb7faf19 Author: Linkai Gong Date: Wed Aug 19 13:47:42 2026 +0800 drm/amd/display: fix dc_lock leak on GPU reset error paths commit 92a9eebd2a1f892fe482154d83f9f1626bc73d3b upstream. On GPU reset, dm_suspend() takes dc_lock and leaves it for dm_resume() to drop. If amdgpu_dm_commit_zero_streams() or dm_dmub_hw_init() fails, the function returns with the lock still held. The matching resume path is then skipped, so every later dc_lock take hangs. Release the cached DC state and unlock before returning the error. Fixes: 3cf7a0bc87f0 ("drm/amd/display: Catch failures for amdgpu_dm_commit_zero_streams()") Fixes: 2b6943df5413 ("drm/amd/display: Pass up errors for reset GPU that fails to init HW") Cc: stable@vger.kernel.org Signed-off-by: Linkai Gong Reviewed-by: Mario Limonciello Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ee28fafb50f58b847509b5240b431ddec673bdfe Author: Harry Wentland Date: Tue Aug 4 17:04:04 2026 -0400 drm/amd/display: avoid divide-by-zero in __is_lut_linear() commit 4f40873f8a4107df2b9c8e68c947c4fd0cd519d2 upstream. __is_lut_linear() computes the expected value of each entry with expected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero. Fixes: 086247a4b2fb ("drm/amd/display: Use 4096 lut entries") Cc: stable@vger.kernel.org Signed-off-by: Harry Wentland Reviewed-by: Melissa Wen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4ac7677221754f4e0b3054bc9e8d23b9e12486d3 Author: Thomas Zimmermann Date: Thu Jun 18 14:28:39 2026 +0200 drm/hibmc: Use drm_atomic_helper_check_plane_state() commit 715c5db68bdbd4a524b79ebf20fb61e880fffea0 upstream. Call drm_atomic_helper_check_plane_state() from the primary plane's atomic-check helper and replace the custom implementation. All plane's implementations of atomic_check should call the shared _check_plane_state() helper first. It adjusts the plane state for correct positioning, rotation and scaling of the plane. Do this even if the plane's CRTC has been disabled by setting the parameter can_update_disabled. The original code returned early in this case, but it's safe to so and cleaner to have all plane state initialized. As we don't set can_position, drm_atomic_helper_check_plane_state()'s visibility check tests if the plane covers all of the CRTC. This is a small change from the original code, which tested if the plane is exactly the size of the CRTC. With the new test, the plane still has to cover all of the CRTC, but can be larger than the CRTC's size. A later patch can fully implement this feature in hibmc. If the plane is disabled, the helper clears the visibility flag in the plane state. On errors or if the plane is not visible, the atomic-check helper can return early. Implement all this in hibmc and drop the custom code that does some of it. v2: - extend the commit description (Yongbang) Signed-off-by: Thomas Zimmermann Fixes: da52605eea8f ("drm/hisilicon/hibmc: Add support for display engine") Reviewed-by: Yongbang Shi Cc: Rongrong Zou Cc: Sean Paul Cc: Xinliang Liu Cc: Dmitry Baryshkov Cc: Baihan Li Cc: Yongbang Shi Cc: # v4.10+ Link: https://patch.msgid.link/20260618123142.92298-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit ed38f0be5b61d96cfd16311db22b022277866b23 Author: Thomas Zimmermann Date: Thu Jun 18 14:28:40 2026 +0200 drm/hibmc: Fix list of formats on the primary plane commit 0e682e136c466ae37c62f18099f591c096260ee0 upstream. Remove all formats from the primary plane that are unsupported for various reasons. * Formats with alpha channel: planes should not announce alpha channels unless they support transparency. There's no transparency support in the primary plane's implementation. * Formats with BGR order. The common format is in RGB channel order. There's no BGR support in the primary plane's implementation. * RGB888: atomic_update programs the format from cpp[0] * 8 / 16. For RGB888's cpp value of 3 this returns 1.5; rounded to 1. Programming the value of 1 to HIBMC_CRT_DISP_CTL_FORMAT sets up RGB565. Hence, the output is distorted. This can be tested by booting with video=1024x768-24. Removing all unsupported formats leaves XRGB8888 and RGB565. Both of which are supported and work correctly. Signed-off-by: Thomas Zimmermann Fixes: da52605eea8f ("drm/hisilicon/hibmc: Add support for display engine") Reviewed-by: Yongbang Shi Cc: Rongrong Zou Cc: Sean Paul Cc: Xinliang Liu Cc: Dmitry Baryshkov Cc: Yongbang Shi Cc: Baihan Li Cc: # v4.10+ Link: https://patch.msgid.link/20260618123142.92298-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit f5acd8f48cacc6e4b682c384317d11ef5c33bc8d Author: Lyude Paul Date: Tue Apr 28 23:03:40 2026 -0400 drm/nouveau/disp/r535: Add scanline position support + head state support commit 804cb093b245c752f15d17186e0d404f10303593 upstream. That's right! It looks like this never actually got finished, something which I just noticed today when I saw this fun message spamming one of my test machine's kernel logs when enabling display debug output for nouveau: [drm:drm_crtc_vblank_helper_get_vblank_timestamp_internal] crtc 0 : scanoutpos query failed. So it looks like we've been falling back to DRM's core fallback for a while now, whoops. So, while it seems that we do have the option of doing this through GSP - that doesn't seem like a great idea. Mainly because reading this from GSP would involve a lot more latency then we should have for vblank handling due to the RPC communication. So instead of implementing that, just use gv100_head_state and gv100_head_rgpos for implementing .state and .rgpos. It seems to work perfectly fine! Fixes: 9e9944449023 ("drm/nouveau/disp/r535: initial support") Cc: Ben Skeggs Cc: Dave Airlie Cc: Timur Tabi Cc: Ben Skeggs Cc: James Jones Cc: Faith Ekstrand Cc: Suraj Kandpal Cc: Lyude Paul Cc: Aaron Kling Cc: Danilo Krummrich Cc: Zhang Enpei Cc: # v6.7+ Signed-off-by: Lyude Paul Signed-off-by: Dave Airlie Link: https://patch.msgid.link/20260429030348.3930866-1-lyude@redhat.com Signed-off-by: Greg Kroah-Hartman commit 6f9bdbe713fdfc2bbe74708993fa371d851358df Author: Amit Barzilai Date: Mon Jun 22 15:26:04 2026 +0300 drm/ssd130x: fix column and row end address in partial updates in ssd133x commit b7fcb70162acd7f15ed20bc64a14c150db34256f upstream. On partial screen updates, SSD133X controllers expect to get the rectangle addresses as arguments of the "Set Column Address" and "Set Row Address" commands. Each command expects the start address and end address of the row/column in absolute format, however the end addresses were being sent in a relative format (relative to the start address). The relative end addresses work only when the start address is 0. In those situations, there is no value difference between relative and absolute addresses. Fixes: b4299c936d8fd ("drm/ssd130x: Add support for the SSD133x OLED controller family") Cc: stable@vger.kernel.org Signed-off-by: Amit Barzilai Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260622122604.32500-4-amit.barzilai22@gmail.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Greg Kroah-Hartman commit 6f776d0e43e041ab737225b2d46d5c5ec08dadfd Author: Wentao Liang Date: Sun Jun 7 03:09:50 2026 +0000 drm/sun4i: fix refcount leak in sun4i_backend_init_sat() commit f7a56ff6240e6fd0cb36a3c0a911a1cd54789ce2 upstream. When sun4i_backend_init_sat() calls reset_control_deassert() it increments the deassert_count of the reset controller, and must pair that with a reset_control_assert() call to decrement it. In the error path where clk_prepare_enable() fails, the function returns immediately without calling reset_control_assert(), leaking the reference count. Other error paths, like the devm_clk_get() failure, correctly jump to the err_assert_reset label which performs the missing assert. Fix the leak by using the existing err_assert_reset label in the clk_prepare_enable error path instead of returning directly. Cc: stable@vger.kernel.org Fixes: 440d2c7b127a ("drm/sun4i: backend: Handle the SAT") Signed-off-by: Wentao Liang Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260607030950.83636-1-vulab@iscas.ac.cn Signed-off-by: Chen-Yu Tsai Signed-off-by: Greg Kroah-Hartman commit 63c70e292e6b491bdcad3afdab519900c9ec66f4 Author: Amit Barzilai Date: Mon Jun 22 15:26:02 2026 +0300 drm/ssd130x: fix column and row end address in partial updates for ssd132x commit 99e9c09358195454ecd200b9c6aba6b7d209fad4 upstream. On partial screen updates, SSD132X controllers expect to get the rectangle addresses as arguments of the "Set Column Address" and "Set Row Address" commands. Each command expects the start address and end address of the row/column in absolute format, however the end addresses were being sent in a relative format (relative to the start address). The relative end addresses work only when the start address is 0. In those situations, there is no value difference between relative and absolute addresses. Fixes: fdd591e00a9c9 ("drm/ssd130x: Add support for the SSD132x OLED controller family") Cc: stable@vger.kernel.org Signed-off-by: Amit Barzilai Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260622122604.32500-2-amit.barzilai22@gmail.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Greg Kroah-Hartman commit 18b3433f10ee9c69e3252046028aa2be421f2d4d Author: Deepanshu Kartikey Date: Thu Aug 13 12:19:02 2026 +0530 drm/i915: Guard against NULL driver_data in i915_pci_probe() commit 3785d40831ba5601296283e0197e10e089392757 upstream. pci_match_device() can return the dummy pci_device_id_any entry when a device is force-bound via sysfs driver_override, in which case ->driver_data is unset (NULL). i915_pci_probe() casts it to struct intel_device_info * unconditionally and dereferences intel_info->require_force_probe, causing a NULL-ptr-deref. Reported-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=db96c5ff032f4292a8dc Tested-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260813064902.367504-1-kartikey406@gmail.com Signed-off-by: Jani Nikula (cherry picked from commit 2727922084672cc274ecea726ea00363c2893731) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 79d09cfe90304ff4f195e47d569800f5e0f8b854 Author: Danilo Krummrich Date: Sun Jun 28 16:53:36 2026 +0200 drm: fix race between partial drm_dev_register() failure and ioctl commit eb197f7d60f00d0f5b1b3505dfc86a7e36045a3e upstream. If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register(). Fixes: bee330f3d672 ("drm: Use srcu to protect drm_device.unplugged") Cc: stable@vger.kernel.org Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260620190648.2E9F61F000E9@smtp.kernel.org/ Reviewed-by: Alexandre Courbot Reviewed-by: Lyude Paul Tested-by: Deborah Brouwer Link: https://patch.msgid.link/20260628145406.2107056-17-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 0259846b15a665c6762a86b3fa0eb8b674b35d1c Author: Johan Hovold Date: Fri Jul 17 16:31:18 2026 +0200 drm/panel-edp: fix i2c adapter leak on probe failure commit e2a9e291275a74e309a21cbb1def6296a72d6aed upstream. Make sure to drop the i2c adapter reference on probe failure (e.g. probe deferral) and on driver unbind also if a devicetree redundantly uses the 'ddc-i2c-bus' property to point to the aux ddc bus. Fixes: cc5a3fc041f0 ("drm/panel: panel-simple: Stash DP AUX bus; allow using it for DDC") Cc: stable@vger.kernel.org # 5.15 Reported-by: Douglas Anderson Link: https://lore.kernel.org/r/CAD=FV=VZPhzHU+Pet2m3L+Pqc7mOPfZC-f5p0OuNL79wNZPxRg@mail.gmail.com Signed-off-by: Johan Hovold Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260717143119.1815106-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit b51d8fb5e58c2a272bdf40f2170ebae25116ce87 Author: Johan Hovold Date: Fri Jul 17 11:08:19 2026 +0200 drm/bridge: dw-hdmi: fix i2c adapter leak on probe failure commit 09b195a7bb23df56269cd2a95d01ba3a5533af13 upstream. Make sure to drop the i2c adapter device and module references before returning when detecting a malformed devicetree during probe. Fixes: 80e2f97968b5 ("drm: bridge: dw-hdmi: Switch to regmap for register access") Cc: stable@vger.kernel.org # 4.12 Cc: Neil Armstrong Signed-off-by: Johan Hovold Reviewed-by: Luca Ceresoli Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260717090819.1630965-1-johan@kernel.org Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 80c9528661c774f899281c9a72011208ff39929e Author: Osama Abdelkader Date: Mon Jul 20 15:44:35 2026 +0200 drm/panthor: fix firmware control interface bounds checks commit 6a47f9fd2d970674ed9dedc52fc7ab76fd015785 upstream. panthor_init_cs_iface() and panthor_init_csg_iface() validate firmware control interface offsets with 32-bit arithmetic and the size of the host wrapper structures. The offsets are derived from firmware-provided strides, so the arithmetic can wrap before the bounds check, and the host wrapper size is not the size of the firmware control interface being mapped. Use 64-bit arithmetic for the computed offsets and validate against the actual firmware control interface structure sizes with subtraction-based bounds checks. Also validate that the shared section is large enough for the global control interface before using it. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Steven Price Reviewed-by: Liviu Dudau Link: https://patch.msgid.link/20260720134435.13377-1-osama.abdelkader@gmail.com Signed-off-by: Steven Price Signed-off-by: Greg Kroah-Hartman commit 5516f1acfd07564361cf306cc90a8e513df0f096 Author: Osama Abdelkader Date: Mon Jul 20 13:32:11 2026 +0200 drm/panthor: harden firmware build-info bounds checks commit 8321b093fa6c297b80586460ce6914d9655df170 upstream. panthor_fw_read_build_info() checks whether the metadata range fits in the firmware image with hdr.meta_start + hdr.meta_size. Both fields are u32, so the addition can wrap and let an out-of-bounds range pass validation. The function also reads the "git_sha: " prefix without first checking that the metadata is long enough, and meta_size == 0 can underflow the NULL terminator index. Use subtraction-based bounds checking and reject metadata that is too short to contain the expected prefix and trailing NULL byte. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patch.msgid.link/20260720113212.11981-1-osama.abdelkader@gmail.com Signed-off-by: Greg Kroah-Hartman commit ef41e8e4ae5b737861db2dfdb540485affb3b753 Author: Matthew Auld Date: Wed Sep 2 13:41:20 2026 +0100 drm/xe/vram: report FLAT_CCS base misalignment commit 0e68c74e44da81a4599c52437ee1f63a2c234470 upstream. So we can easily check if a machine had the CCS bug, when looking back over bug reports where we have the same machine with newer kernel. Example print for a machine with the CCS bug: FLAT_CCS base:27bbff800, aligned:no v2 (Matt B): - Unconditionally print the base + alignment Fixes: 37173392741c ("drm/xe/vram: fix ccs offset calculation") Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: Rodrigo Vivi Cc: stable@kernel.org Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260902124117.918018-9-matthew.auld@intel.com (cherry picked from commit d00b7f4f03bbeb2efad872f1686130e18c2b4141) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit e184e46ca1ba652ab8053a10a51b39aad06d3f5c Author: Thomas Hellström Date: Sat Jul 25 12:00:31 2026 +0200 drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init() commit e773798e14ac0aea54ca9676083b91f445e5bc59 upstream. drmm_cgroup_register_region() is called before INIT_LIST_HEAD() and gpu_buddy_init() in amdgpu_vram_mgr_init(). If it fails, the function returns early and bypasses those initializations. Since adev->mman.initialized is set to true before amdgpu_vram_mgr_init() is called, a failure triggers amdgpu_ttm_fini(), which calls amdgpu_vram_mgr_fini(), which then: - Calls list_for_each_entry_safe() on reservations_pending and reserved_pages, whose list_head::next pointers are zero-initialized (NULL). The loop does not recognize them as empty and dereferences NULL. - Calls gpu_buddy_fini(), which iterates free_trees[] unconditionally via for_each_free_tree(). Since mm->free_trees is NULL (never allocated), this dereferences NULL. Both result in a kernel panic on the module load error path. Fix by moving drmm_cgroup_register_region() to after the list and buddy allocator are fully initialized, so the teardown path is safe to run. Reported-by: Sashiko-bot Closes: https://sashiko.dev/#/patchset/20260428073116.15687-1-thomas.hellstrom@linux.intel.com?part=4 Fixes: 2b624a2c1865 ("drm/ttm: Handle cgroup based eviction in TTM") Cc: Friedrich Vock Cc: Maarten Lankhorst Cc: Tejun Heo Cc: Maxime Ripard Cc: Christian König Cc: Alex Deucher Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org # v6.14+ Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström Reviewed-by: Arunpravin Paneer Selvam Reviewed-By: Maarten Lankhorst Tested-by: Thadeu Lima de Souza Cascardo Link: https://patch.msgid.link/20260725100036.2372-2-thomas.hellstrom@linux.intel.com Acked-by: Christian König Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit 91ec55ddc097ccddd25ffb95a3d079b2ef362372 Author: Chao Yu Date: Tue Aug 11 15:16:37 2026 +0800 f2fs: fix to zero post-EOF data when extending file size commit 5eced87b7d19dbc76ebdddaf322046f9ac582fcb upstream. generic/794 4s ... - output mismatch (see /share/git/fstests/results//generic/794.out.bad) # --- tests/generic/794.out 2026-06-12 08:46:32.766426241 +0800 # +++ /share/git/fstests/results//generic/794.out.bad 2026-07-05 18:32:55.000000000 +0800 # @@ -1,4 +1,16 @@ # QA output created by 794 # append_write # +FAIL: non-zero data in gap [4080,4096) after shutdown+remount # +000000 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a >ZZZZZZZZZZZZZZZZ< # +* # +001000 # truncate_up # ... # (Run 'diff -u /share/git/fstests/tests/generic/794.out /share/git/fstests/results//generic/794.out.bad' to see the entire diff) Ran: generic/794 Failures: generic/794 Failed 1 of 1 tests Steps of generic/794: 1. write 4096 bytes to file w/ 0x5a 2. use fiemap to get PBA of first block in file 3. truncate file to 4080 4. umount; write 4096 bytes to file w/ 0x5a directly via PBA; mount 5. extend filesize via a) append 4096 from offset 4096, or b) truncate 8192, or c) fallocate 4096 from offset 4096 6. verify the gap is zeroed in memory [4080,4096) 7. sync range 4096 from offset 4096; shutdown -f (flush meta before shutdown) 8. umount; mount; verify [4080,4096) is zeroed or not. When extending file size (e.g. via truncate, fallocate, or write) across an unaligned EOF boundary, we need to ensure that post-EOF data in the partial page is zeroed out in pagecache and marked dirty, then writeback the cache to persist zeroed data before committing inode w/ updated i_size. This help to prevent stale disk data beyond the previous EOF from being exposed after remounting or crash recovery. Since f2fs is a LFS filesystem, we only support direct write via PBA in pinfile, and pinfile has section-aligned filesize, so in Android, there should no problem, but for other usage in different environment, let's fix this w/ fsync_mode=strict mount option. Cc: stable@kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit a984446aa9d5b787afa3023fc7b44017b80fe3bc Author: Chao Yu Date: Thu Aug 6 20:35:37 2026 +0800 f2fs: fix to pass folio->index to f2fs_sanity_check_node_footer() commit 7e188e9f9437ab47c3237d609f1b26348d6fea1a upstream. Otherwise in f2fs_sanity_check_node_footer(), it will check the same nid incorrectly. Cc: stable@kernel.org Fixes: 0a736109c9d2 ("f2fs: fix to do sanity check on node footer in __write_node_folio()") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit dde99df5a9d3b0ca6ac0a86f98799685f7399432 Author: Chen Changcheng Date: Tue Aug 4 08:54:02 2026 +0800 f2fs: fix valid block count leak on data block allocation failure commit 0f9af07ecc1ab486038373db6ae0436c5d674b19 upstream. In __allocate_data_block(), when allocating a new data block (dn->data_blkaddr == NULL_ADDR), inc_valid_block_count() is called first to increment total_valid_block_count and i_blocks. If the subsequent f2fs_allocate_data_block() fails, the function returns the error directly without rolling back the already-incremented block counts, causing a permanent leak. Fix this by calling dec_valid_block_count() to undo the increment before returning the error. The condition old_blkaddr == NULL_ADDR precisely identifies the case where inc_valid_block_count() was called. Fixes: 7d009e048d7c ("f2fs: fix to handle segment allocation failure correctly") Cc: Reviewed-by: Chao Yu Signed-off-by: Chen Changcheng Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit ab35ae07f2b5b4e118ea47b88577fc7d0e797b17 Author: Chao Yu Date: Wed Aug 5 12:29:20 2026 +0000 f2fs: fix to clear dirty flag on folio in error path commit 5b86eab84ac8e9289b5afc52ef88ab18ba5bacab upstream. If node block is corrupted due to chksum mismatch or inconsistent footer info, it needs to drop clear flag of node folio, in order to persist inconsistent node data to storage. Cc: stable@kernel.org Fixes: b42b179bda9f ("f2fs: fix to do checksum even if inode page is uptodate") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit c16cc4622e4b6619f62ac270a24036478f91a998 Author: Chao Yu Date: Tue Aug 11 15:16:36 2026 +0800 f2fs: fix to off-by-one issue in f2fs_zero_post_eof_page() commit b2205d3cfd6c76fd5c5443ee9fdb498cfb0e1c66 upstream. Otherwise, it will drop one more page after new_size which is not necessary. Cc: stable@kernel.org Fixes: ba8dac350faf ("f2fs: fix to zero post-eof page") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit f6c49fae98f0fc98d4b62f388ade84a11bc1673f Author: Zhan Xusheng Date: Tue Aug 18 22:55:35 2026 +0800 f2fs: fix i_size when pinned fallocate partially fails commit 0f448bb3767ef6119f5cdeabcae3f10d6e75aed6 upstream. From: Zhan Xusheng Commit 4275b59673eb ("f2fs: fix to round down start offset of fallocate for pin file") moved the allocation loop's start down to a section boundary, but the error path still converts @expanded against @pg_start, which holds the unrounded start. @pg_start exists for that conversion: commit 88f2cfc5fa90 ("f2fs: fix to update last i_size if fallocate partially succeeds") added it as an immutable base because map.m_lblk moves every round. Each round now maps exactly sec_blks blocks starting from rounddown(pg_start, sec_blks), so pg_start + expanded overshoots the last allocated block by pg_start % sec_blks, and a partial failure leaves i_size covering a tail that was never allocated. Nothing corrects that afterwards either, since file_dont_truncate() has already cleared FADVISE_TRUNC_BIT. It needs a start offset that is not section aligned plus a fallocate that hits ENOSPC partway, so the error path runs with expanded > 0. On an 80 MiB image with 2 MiB sections: truncate -s 80M img mkfs.f2fs -s 1 -f img mount -o loop img /mnt touch /mnt/pinned f2fs_io pinfile set /mnt/pinned # 2093056 = block 511, so pg_start % sec_blks = 511 f2fs_io fallocate 0 2093056 536870912 /mnt/pinned stat -c %s /mnt/pinned filefrag -v /mnt/pinned The last extent ends at block 10737 either way. Before, i_size is 46075904, block 11249, so 511 blocks of it were never allocated, and filefrag does not mark the last extent eof. After, i_size is 43982848, block 10738, and eof is back. A kernel from before that commit also shows no overshoot. Keep @pg_start pointing at where allocation actually begins. Fixes: 4275b59673eb ("f2fs: fix to round down start offset of fallocate for pin file") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 161513f53e4ac90fd356433bdf8e31e6adeb92af Author: Chao Yu Date: Mon Aug 24 21:17:29 2026 +0800 f2fs: fix to avoid potential deadloop in f2fs_fsync_node_pages() commit ce366bfa821ec81dd45bde547ee31e659306cc61 upstream. There is potential deadloop in race condition: Thread A Thread B - fsync - f2fs_do_sync_file - f2fs_fsync_node_pages - last_fsync_dnode - folio_get(last_folio) - f2fs_setattr - f2fs_truncate - f2fs_truncate_blocks - f2fs_do_truncate_blocks - f2fs_truncate_inode_blocks - truncate_dnode - truncate_node - invalidate_mapping_pages - folio->mapping = NULL - is_node_folio alwasy return false - atomic && !marked is always true, then goto retry Cc: stable@kernel.org Fixes: 608514deba38 ("f2fs: set fsync mark only for the last dnode") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit b8ae1228c153622afa71a179c9d4dc268117e0f0 Author: Daeho Jeong Date: Wed Aug 19 11:06:35 2026 -0700 f2fs: fix to migrate all curseg types during free_segment_range commit 8ec06f50ddd8d201bd7e55b896ae28ed9d4cb7d1 upstream. In free_segment_range(), the curseg evacuation loop only iterates up to NR_CURSEG_PERSIST_TYPE (0..5), missing non-persistent in-memory curseg types such as CURSEG_COLD_DATA_PINNED and CURSEG_ALL_DATA_ATGC. Even though these in-memory curseg types are not saved in the on-disk checkpoint header, they still occupy active physical segments at runtime. If an active in-memory curseg happens to be allocated within the segment range being truncated during filesystem shrink, failing to evacuate it will cause subsequent writes to the curseg attempting out-of-bounds I/O on the truncated storage range. Fix this by expanding the curseg evacuation loop upper bound to NR_CURSEG_TYPE to ensure all active curseg types are safely migrated out of the target range. Fixes: d0b9e42ab615 ("f2fs: introduce inmem curseg") Cc: stable@vger.kernel.org Signed-off-by: Daeho Jeong Signed-off-by: Sunmin Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit aefcec3bebdeed2bff444378122300763325ba23 Author: Wenjie Qi Date: Tue Aug 4 09:48:48 2026 +0800 f2fs: avoid NULL checkpoint thread access in sysfs commit 5cb33b00c8fbb6e8f1fa3d281c3036d5f7c7c41f upstream. checkpoint_merge can be enabled even when no checkpoint merge thread is running. A read-only mount is one case: f2fs does not start f2fs_issue_ckpt there, but ckpt_thread_ioprio is still writable through sysfs. The ckpt_thread_ioprio store path updates the saved ioprio value and, when checkpoint_merge is enabled, calls set_task_ioprio() for the checkpoint thread. If cprc->f2fs_issue_ckpt is NULL, that dereferences a NULL task pointer. Protect ckpt_thread_ioprio sysfs writes with s_umount as well, so the checkpoint thread cannot disappear under the store path while updating its ioprio. Fixes: e65920661708 ("f2fs: add ckpt_thread_ioprio sysfs node") Cc: stable@kernel.org Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit aefb4b0f465b6f95fe02b52d1822a3fb4a9ae922 Author: Guanghui Yang <3497809730@qq.com> Date: Sun Jul 19 16:45:14 2026 +0800 f2fs: fix dentry folio leak in find_in_level commit cca7d3e30bf30333314e31bc70b9a739f1342167 upstream. find_in_level() gets a dentry folio with f2fs_find_data_folio() before calling find_in_block(). If find_in_block() returns an error, the function stores the error in res_folio and breaks out of the loop without dropping the dentry folio. This leaks the folio reference on the find_in_block() error path. Drop the dentry folio before returning the error to the caller. Fixes: 7ad08a58bf67 ("f2fs: Handle casefolding with Encryption") Cc: stable@vger.kernel.org Reviewed-by: Chao Yu Signed-off-by: Guanghui Yang <3497809730@qq.com> Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 94917ffab3a9446da46ff494c609c4be287944bc Author: Chao Yu Date: Mon Jun 29 11:49:18 2026 +0000 f2fs: fix to avoid potential section-unaligned pinfile commit d0a481fad5c7a3a56ecf54a099651216869f4d0a upstream. Blocks of pinfile may not aligned to section size due to wrong use on pinfile, result in heavy overhead of GC, let avoid this by adding additional check condition in f2fs_setattr(). - truncate -s 8mb pinfile : random checkpoint may persist filesize w/ inode - fallocate -o 0 -l 8mb pinfile - f2fs_fallocate - f2fs_expand_inode_data - f2fs_allocate_pinning_section - f2fs_map_blocks - f2fs_map_lock - __allocate_data_block - file_need_truncate : w/ FADVISE_TRUNC_BIT, we can expect unaligned mapping can be truncated while open() if f2fs is not umount abnormally - f2fs_map_unlock : following f2fs checkpoint and sudden power-cut - mount - open pinfile - f2fs_file_open - finish_preallocate_blocks - truncate_setsize : filesize is 8mb - f2fs_truncate : can only truncate block outside filesize, rather than truncating unaligned blocks inside filesize Fixes: f5a53edcf01e ("f2fs: support aligned pinned file") Cc: stable@kernel.org Cc: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 3e61c3944b83c1a278220a30a7b63e28ee33b205 Author: Wenjie Qi Date: Mon Jul 27 15:49:10 2026 +0800 f2fs: return writeback error from collapse range commit f8a4108800254d6f7b2755515fbbd9d0caac561e upstream. f2fs_collapse_range() writes back pages moved by f2fs_do_collapse(), but ignores the return value. If writeback fails, the ioctl can still truncate page cache, shrink blocks, and report success. Return the error before truncating page cache or updating the file size. Fixes: b4ace3370324 ("f2fs: support FALLOC_FL_COLLAPSE_RANGE") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 3b681229e9f8fb1dd29bc65983bf3c87779e4ca3 Author: Zhan Xusheng Date: Thu Jul 16 10:59:08 2026 +0800 f2fs: use the mount idmap for the owner check in f2fs_xattr_advise_set() commit a54ffce4637acb0db8e695188a6c7f99f14c3576 upstream. f2fs_xattr_advise_set() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing the "system.advise" xattr to be set, instead of the idmap that the VFS passes to the ->set() handler. f2fs supports idmapped mounts, so on such a mount this checks the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EPERM and an unrelated caller wrongly allowed. Pass the handler's idmap instead. Fixes: 01beba7957a2 ("fs: port inode_owner_or_capable() to mnt_idmap") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Reviewed-by: Chao Yu Acked-by: Christian Brauner (Amutable) Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit db504781ea9b0f08855d342919129a1f6b32c4aa Author: Joanne Chang Date: Tue Jun 23 06:34:28 2026 +0000 f2fs: dirty directory inodes on mtime/ctime update commit 9ec09d5f4b317a417c8655c14056f70cbe71eb6c upstream. Xfstests generic/547 sometimes fail with mismatched directory metadata before and after a power failure. This happens because when a directory entry is added, renamed, or deleted, its mtime and ctime are updated and the inode is marked dirty via f2fs_mark_inode_dirty_sync(dir, sync=false). The sync=false flag means the dirty inode is not added to the global DIRTY_META list. Therefore, subsequent checkpoints skip flushing these updated directory blocks, causing directory timestamps to revert to stale values after a sudden power failure. Address this by changing the dirtying parameter to sync=true during directory entry mutations and renames. This forces F2FS to immediately queue the updated directory blocks on the global DIRTY_META list, ensuring timestamps are committed to checkpoints. Fixes: 7c45729a4d6d ("f2fs: keep dirty inodes selectively for checkpoint") Cc: stable@vger.kernel.org Signed-off-by: Joanne Chang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit dc652b2fe916cbcb3ed215c576444f8132dc27c0 Author: Chao Yu Date: Tue Jun 23 20:48:23 2026 +0800 f2fs: fix to avoid move_range and defragment on device_alias file commit 1b4db09b7f10895dc1a0bc32704c7de05188fb1d upstream. It's forbidden to migrate blocks of device alias file. Cc: stable@kernel.org Fixes: 128d333f0dff ("f2fs: introduce device aliasing file") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 445e4a1e6025ecd5312e9a95c1b234192c976ca1 Author: Wenjie Qi Date: Mon Jul 27 21:04:29 2026 +0800 f2fs: only redirty pinned folios in redirty_blocks commit 85171332742e741ccd6f401c69b6e0d698119e72 upstream. redirty_blocks() pins folios with read_cache_folio() and then walks the same range again with filemap_lock_folio() to redirty them and drop the references it took. Commit 5951fee46bef ("f2fs: Use a folio in redirty_blocks()") changed the second pass to a do/while loop. If read_cache_folio() fails before anything is pinned, page_idx does not advance but the cleanup loop still runs once. If readahead has already populated the failed folio in page cache, that extra iteration finds it and folio_put_refs(folio, 2) drops one reference too many. Later drop_caches or reclaim can then report "BUG: Bad page state". Only redirty the range that was pinned successfully. Fixes: 5951fee46bef ("f2fs: Use a folio in redirty_blocks()") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 7f89e2775d5bb8d49cea8560489cad25c778f740 Author: Hao-Qun Huang Date: Wed Jul 8 14:54:39 2026 +0800 f2fs: reject overlapping move range after len expansion commit 28c1ef094e7c86977d9bf570dc0362fc54e36437 upstream. F2FS_IOC_MOVE_RANGE treats a zero length as a request to move data from pos_in to EOF. However, the same-file overlap check runs before that expansion, so a request with len == 0 bypasses the overlap rejection added for same-file moves. For example, with a four-block file, moving from block 0 to block 1 with len == 0 is accepted by the old check because pos_in + len is still pos_in at that point. The code then expands len to cover the rest of the file and calls __exchange_data_block() on overlapping source and destination ranges in the same inode, which is the data-corruption case the overlap check was meant to reject. Move the overlap check after the source range has been validated and len == 0 has been expanded, so it sees the effective length. This is a no-op for non-zero len (the value is unchanged there) and keeps the existing early return for identical positions. Fixes: d95fd91c1ac1 ("f2fs: exclude special cases for f2fs_move_file_range") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Hao-Qun Huang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 95d5975c9d1c5629684668e0098a72946ed9d07d Author: Wenjie Qi Date: Mon Aug 10 21:38:32 2026 +0800 f2fs: return symlink writeback errors commit a2c73a7a677afdaa8b16d775188f9ef5cfbfd8b2 upstream. F2FS writes long symlink data with page_symlink() and then flushes the symlink mapping to reduce the chance of exposing a broken symlink. That flush result is currently ignored. If the writeback fails, symlink() still returns success even though the symlink is not durable and the same operation can already surface -EIO through syncfs(). Return the writeback error to userspace and skip the dirsync flush once the symlink data flush has failed. Fixes: d0cae97cb600 ("f2fs: flush symlink path to avoid broken symlink after POR") Cc: stable@kernel.org Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit ac4b019ac07844d3f67ea5e48b1d982b2170d1a7 Author: Nilesh Javali Date: Thu Jul 30 21:28:30 2026 +0530 scsi: qla2xxx: Skip NVMe LS reject IOCB when FW not started commit f7e46ebffc5781aab3f1f5a5d4350addbb5833f4 upstream. qla_nvme_xmt_ls_rsp() bails out to the out: label when firmware is not started (!ha->flags.fw_started), but the out: path unconditionally calls qla_nvme_ls_reject_iocb(), which ends in qla2x00_start_iocbs() and an unconditional doorbell write to the request queue in-pointer register. This rings the firmware doorbell and queues an IOCB that stopped or resetting firmware cannot consume, and touches MMIO during the reset/EEH window where fw_started is also clear. Only emit the LS reject IOCB (and ring the doorbell) when fw_started is set; otherwise just clean up and return. The post-allocation failure cases (SRB alloc / qla2x00_start_sp() failure) run with firmware started and still send the reject. Apply the same guard to the reject emission in qla2xxx_process_purls_pkt(). Fixes: 875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-26-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 4fe5790674097897a1af1367d1e384f7e5a62fb7 Author: Nilesh Javali Date: Thu Jul 30 21:28:34 2026 +0530 scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak commit b93d3bb3afe1b44489927de1eb4e66e8536a5935 upstream. Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory. Fixes: 697a4bc69159 ("[SCSI] qla2xxx: Provide method for updating I2C attached VPD.") Fixes: 9ebb5d9c69f1 ("[SCSI] qla2xxx: Add I2C BSG interface.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-30-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 0bdd0f7a1094a75c892e9c63997863e8c9aa3296 Author: Nilesh Javali Date: Thu Jul 30 21:28:33 2026 +0530 scsi: qla2xxx: Use coherent DMA buffer for D_Port diagnostics commit 7c4f3f50d83af4545efaa99b3d0d46fb8d52031e upstream. qla26xx_dport_diagnostics() streaming-maps the caller's result buffer with dma_map_single(). The bsg path passes &dd->buf from the __packed struct qla_dport_diag, where buf lands at a 2-byte offset and shares cachelines with the surrounding options/unused fields. Mapping such a misaligned sub-buffer violates the DMA API requirement that streaming buffers be cacheline aligned and not share a cacheline with other data, and can corrupt data on non-DMA-coherent architectures. Allocate a dedicated DMA-coherent buffer inside qla26xx_dport_diagnostics() for the mailbox command and copy the result back into the caller's buffer. This removes the streaming map of the misaligned sub-buffer entirely; the caller's buffer is now only a plain CPU buffer, so its packing no longer matters. Fixes: ec89146215d1 ("qla2xxx: Add bsg interface to support D_Port Diagnostics.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-29-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 776e4e8cbcf155302f430ce9793d1502e3c113a0 Author: Nilesh Javali Date: Thu Jul 30 21:28:28 2026 +0530 scsi: qla2xxx: Hold vport_slock for host map update in report ID acquisition commit 7944039ba9cb5c3a935d17c91004e3b8649ff58e upstream. qla24xx_report_id_acquisition() format-1 handling drops vport_slock after taking the vport reference and then calls qla_update_host_map() without the lock. That reaches qla_update_vp_map(), which mutates the ha->host_map btree via btree_insert32()/btree_update32()/btree_remove32() and is documented to require vport_slock to be held by the caller. Running it unlocked can race concurrent host_map updates and corrupt the btree. The format-2 path in the same function already wraps its host_map update (SET_AL_PA) in vport_slock; the format-1 path is the lone outlier. Hold vport_slock across the format-1 qla_update_host_map() call to honor the documented locking contract. The vref_count taken in the loop keeps the vport valid, so this only adds the missing host_map serialization. Fixes: 430eef03a763 ("scsi: qla2xxx: Relocate/rename vp map") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-24-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 16c731c4f296180d708f94125fbc4f76725a4398 Author: Nilesh Javali Date: Thu Jul 30 21:28:27 2026 +0530 scsi: qla2xxx: Drop vport reference under lock in report ID acquisition commit 1154b16439ffc562f9461494c4508c63446eb684 upstream. qla24xx_report_id_acquisition() format-1 handling takes the vport reference under vport_slock but drops it outside the lock, after setting vp->vp_flags and vp->dpc_flags: set_bit(VP_IDX_ACQUIRED, &vp->vp_flags); set_bit(REGISTER_FC4_NEEDED, &vp->dpc_flags); set_bit(REGISTER_FDMI_NEEDED, &vp->dpc_flags); atomic_dec(&vp->vref_count); Neither set_bit() nor atomic_dec() imply a memory barrier, so on a weakly ordered architecture the decrement can become visible before the flag stores. qla24xx_deallocate_vp_id() polls vref_count under vport_slock and unlinks the vport once it reads zero, after which qla24xx_vport_delete() frees it via scsi_host_put(). The poller could therefore observe vref_count == 0 early and tear the vport down while the pending vp_flags/ dpc_flags stores land on freed memory. Drop the reference under vport_slock, as is done for the matching increment and by every other vref_count user. The unlock release pairs with the deallocate poller's lock acquire so the flag stores are ordered before vref_count == 0 can be observed. Fixes: 793cedee296f ("scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition()") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-23-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 17fb63c1d0fcd121b766389bf673338b3185a8c7 Author: Nilesh Javali Date: Thu Jul 30 21:28:29 2026 +0530 scsi: qla2xxx: Fix NVMe abort reference leak on repeated abort commit 06b5b2a5d499323f1c3256ead35798e8e3d15e60 upstream. qla_nvme_ls_abort() and qla_nvme_fcp_abort() take a command reference with kref_get_unless_zero() and then call schedule_work() on priv->abort_work, ignoring its return value. qla_nvme_abort_work() runs once and drops exactly one reference via kref_put(&sp->cmd_kref, sp->put_fn). Since the per-abort INIT_WORK() was moved to submission time, schedule_work() now returns false when the work is already pending, for example on a concurrent transport teardown and timeout-driven abort of the same command. In that case the reference taken for the second abort is never released because the work still executes only once, leaking a reference. The command is then never returned to the NVMe-FC transport, which can hang the port. Drop the reference when schedule_work() returns false, so each kref_get_unless_zero() is balanced regardless of whether the work was newly queued. The held reference keeps priv->sp valid for the put. Fixes: 7e85f6dbc856 ("scsi: qla2xxx: Initialize NVMe abort_work once at submission") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-25-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 5dd9bec8004ba93cee8b689bf54ce294f59e5e3c Author: Nilesh Javali Date: Thu Jul 30 21:28:21 2026 +0530 scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() commit deb8abde83a799d2501f3977f6d6051000253f5e upstream. qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference. Fixes: a6fe35c052c4 ("[SCSI] qla2xxx: Avoid invalid request queue dereference for bad response packets.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-17-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit d7f7746ff031ae45724881261804f4bf5317c985 Author: Nilesh Javali Date: Thu Jul 30 21:28:20 2026 +0530 scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read commit ca6d880d6c70cb7946e7b3e05d7285f271b6d99e upstream. In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: if (IS_FWI2_CAPABLE(ha)) { sense_data += rsp_info_len; par_sense_len -= rsp_info_len; } rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): if (sense_len > par_sense_len) sense_len = par_sense_len; memcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites. Fixes: 5544213be7b4 ("[SCSI] qla2xxx: Correct extended sense-data handling.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-16-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 9fa1d71233a82416492d9c9de9756ebe140fe714 Author: Nilesh Javali Date: Thu Jul 30 21:28:25 2026 +0530 scsi: qla2xxx: Avoid double completion in async IOCB timeout commit bb45bc4bd53c95a7bf6f782577b5ede94c0f8aa8 upstream. qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates "if (sp->comp) complete(sp->comp)"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout(). Fixes: f6145e86d21f ("scsi: qla2xxx: Fix race between switch cmd completion and timeout") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-21-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 10e9f05f7fd0a103886a867ec8afe621fe4b906a Author: Nilesh Javali Date: Thu Jul 30 21:28:22 2026 +0530 scsi: qla2xxx: Quiesce response IRQ before freeing request queue commit 505753ec2594c6af09a601f0dd60be7d840c1d2d upstream. qla2xxx_delete_qpair() deletes the request queue before the response queue. qla25xx_delete_req_que() frees the request queue memory (kfree(req) in qla25xx_free_req_que()), but the response-queue MSI-X is only released later, in qla25xx_free_rsp_que(). In that window the response interrupt can still fire, qla2xxx_msix_rsp_q() queues qpair->q_work, and qla_do_work() -> qla24xx_process_response_queue() dereferences the now-freed rsp->req (LOGINOUT/CT/ELS entries and the status path), a use-after-free. The cancel_work_sync() added for the qpair teardown lives in the response free path, which runs after the request queue is already freed, so it does not protect rsp->req. Release the response-queue interrupt and flush qpair->q_work before deleting the request queue, so no late completion can reach the freed request queue. Clearing have_irq makes the subsequent qla25xx_free_rsp_que() skip its free_irq(), and the firmware queue-delete order (request then response) is preserved; the request-delete mailbox completes on the default vector and is unaffected by dropping the qpair response interrupt early. Fixes: d74595278f4a ("scsi: qla2xxx: Add multiple queue pair functionality.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-18-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 31715d1e1cbf3a37ce3452635c5602f73fd7abd4 Author: Nilesh Javali Date: Thu Jul 30 21:28:18 2026 +0530 scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb() commit 3ba019bdd89d931499d9476456b5d9c7ab7fa753 upstream. qla24xx_process_response_queue() advances ring_ptr past the head IOCB before dispatching, so by the time __qla_consume_iocb() runs, ring_ptr already points at the first continuation IOCB. The function however looped purex->entry_count times starting at ring_ptr. As entry_count includes the head, this consumed one entry too many: it stamped RESPONSE_PROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked. Mark the head processed and account for it, then consume only the entry_count - 1 continuation IOCBs, matching __qla_copy_purex_to_buffer(). Fixes: fac2807946c1 ("scsi: qla2xxx: edif: Add extraction of auth_els from the wire") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-14-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit e93aa3c5125d9a4352ac0fa8ba4a7f8f87881805 Author: Nilesh Javali Date: Thu Jul 30 21:28:23 2026 +0530 scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path commit 0f41d07d72f2245208c45374ca8d0a1846cad667 upstream. qla2x00_status_entry() filters out non-TYPE_SRB entries and the SRB_NVME_CMD, SRB_BIDI_CMD and SRB_TM_CMD types, then falls through to a SCSI fast path that assumes the command is an SRB_SCSI_CMD. The first thing on that path, qla_chk_edif_rx_sa_delete_pending(), and the subsequent handling both evaluate GET_CMD_SP(sp), i.e. sp->u.scmd.cmd. The srb u union overlays the SCSI command pointer with other command layouts (bsg_job, iocb_cmd). If firmware delivers an unexpected STATUS_TYPE IOCB for a non-SCSI handle, sp->u.scmd.cmd can read as a non-NULL garbage pointer, bypassing the NULL checks in qla_chk_edif_rx_sa_delete_pending() and at the cp == NULL test, and leading to a wild pointer dereference. Reject any SRB whose type is not SRB_SCSI_CMD before entering the fast path. The outstanding_cmds slot is left untouched so a genuinely non-SCSI command still completes through its proper handler. Fixes: dd30706e73b7 ("scsi: qla2xxx: edif: Add key update") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-19-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit a194684853dceaa1d6b7a9a02bc12f479232ad9b Author: Nilesh Javali Date: Thu Jul 30 21:28:12 2026 +0530 scsi: qla2xxx: Don't query firmware state while chip is down commit e0cebe20dcffbed9c078fe30e2d18cd5046d9eff upstream. qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy. Fixes: b6faaaf796d7 ("scsi: qla2xxx: Serialize mailbox request") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-8-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 7203d4aed8f444e7376c2dee8d93577b37cf9989 Author: Nilesh Javali Date: Thu Jul 30 21:28:14 2026 +0530 scsi: qla2xxx: Fix FCE trace enable parsing in debugfs commit b7368687e3d11f51392d3c4774ec0263d5fbf31f upstream. qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as "disable" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace. Fixes: 841df27d619e ("scsi: qla2xxx: Move FCE Trace buffer allocation to user control") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-10-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit e6cfb1ee18336aab41a0941d6d3ea5009aaafc05 Author: Nilesh Javali Date: Thu Jul 30 21:28:13 2026 +0530 scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() commit 9efaa782845b4d5fb3e01242be0d06ebc7428d8f upstream. The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents. Fixes: 4d4df1932b6b ("[SCSI] qla2xxx: Add ISP84XX support.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-9-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 8e7a26931b6111583cfeaf49c068f26524dc3af2 Author: Nilesh Javali Date: Thu Jul 30 21:28:15 2026 +0530 scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump commit 53298efcbbb0f0438366d45cb7ed7e6d93dd5531 upstream. qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it. Fixes: 841df27d619e ("scsi: qla2xxx: Move FCE Trace buffer allocation to user control") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-11-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 8286a9095fb59751fba171afa2b4f590271c87d5 Author: Nilesh Javali Date: Thu Jul 30 21:28:11 2026 +0530 scsi: qla2xxx: Fix cs84xx use-after-free on host teardown commit 33d102102d925357c5fd172dd6672a27d74b3215 upstream. qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed. Fixes: fe1b806f4f71 ("[SCSI] qla2xxx: Refactor shutdown code so some functionality can be reused.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-7-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 8d116137119371349fb09685fe05413d8fc92efe Author: Nilesh Javali Date: Thu Jul 30 21:28:08 2026 +0530 scsi: qla2xxx: Serialize flash version read in reset handler commit f606ed93de0c4f1e7e3618779e9fad731455314a upstream. The "update cache versions without reset" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path. Fixes: 8c2cf7d4e387 ("[SCSI] qla2xxx: Add a new interface to update versions.") Reported-by: Sashiko Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-4-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 7a448f5ed0b283dbde4e9183dd1e98c221432dab Author: Nilesh Javali Date: Thu Jul 30 21:28:06 2026 +0530 scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation commit ebfd35c64433821bd5619a6d07ccc2df8b5b1de3 upstream. ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as "ha->max_req_queues = ha->msix_count - 1" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent "ha->max_req_queues--" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following "ha->req_q_map[0] = req" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs). Fixes: d74595278f4a ("scsi: qla2xxx: Add multiple queue pair functionality.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-2-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 11834e5773e20fd3742d7eb900876e66b9e7d029 Author: Nilesh Javali Date: Thu Jul 23 10:34:09 2026 +0530 scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject commit f743488e4a203049f27ec5d8cd0caccc483af01e upstream. qla_nvme_ls_reject_iocb() allocates from and advances the request ring through __qla2x00_alloc_iocbs() (which assumes the hardware_lock is held) and qla2x00_start_iocbs() (which advances the ring and rings the request-in doorbell), but takes no lock itself. Two of its callers invoke it without the producer lock held: - qla_nvme_xmt_ls_rsp(), the NVMe-FC .xmt_ls_rsp transport callback, on its error path, and - qla2xxx_process_purls_pkt(), run from the purex work/DPC context. Both use ha->base_qpair, whose qp_lock_ptr is hardware_lock, so they can run concurrently with normal I/O submission on the base ring and corrupt the ring producer state, leading to duplicated or dropped commands. The third caller, qla2xxx_process_purls_iocb(), runs inside qla24xx_process_response_queue() with the qpair lock already held and is safe; that is also why the lock cannot be taken inside the helper itself (it would recursively re-acquire hardware_lock on the response path). Take qp_lock_ptr around the two unlocked callers and document the helper as caller-locked. Both run in process context, so spin_lock_irqsave() is used and nothing in the locked region sleeps. Fixes: 875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-53-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 7b22b4cb8822805cef7ba618da6f76e1474d68bd Author: Nilesh Javali Date: Thu Jul 23 10:34:12 2026 +0530 scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() commit de62cf265dbe309f34f144a6cdbca9240317727e upstream. qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer. Fixes: 697a4bc69159 ("[SCSI] qla2xxx: Provide method for updating I2C attached VPD.") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-56-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 5ecdb336df2a9df3b4a6d2b1c74271f8765619e7 Author: Nilesh Javali Date: Thu Jul 23 10:34:06 2026 +0530 scsi: qla2xxx: Check entry_status in qla24xx_modify_vp_config() commit 9101c51649f5b6773a97bf5271785c948589ea1d upstream. The Modify VP Config completion handler labelled its first error branch "error status" but tested vpmod->comp_status instead of vpmod->entry_status. Because CS_COMPLETE is 0, the following "comp_status != CS_COMPLETE" branch duplicated that test and was dead code, and entry_status was never examined at all. When firmware rejects the IOCB early it sets entry_status while leaving comp_status zero. As the IOCB is allocated with dma_pool_zalloc(), both comp_status branches evaluate false and the handler falls through to the success path, calling fc_vport_set_state(FC_VPORT_INITIALIZING) for a configuration the firmware never accepted. This can leave the virtual port enabled on top of an invalid config and surface later as login timeouts or follow-on firmware errors. Test entry_status in the first branch, matching qla_ctrlvp_completed() and the login/logout/abort/reset IOCB handlers; the comp_status branch then becomes the live completion-status check. Fixes: 2c3dfe3f6ad8 ("[SCSI] qla2xxx: add support for NPIV") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-50-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 67f0d5187c29360388f7e1e503c627ec45d01089 Author: Nilesh Javali Date: Thu Jul 23 10:34:08 2026 +0530 scsi: qla2xxx: Initialize NVMe abort_work once at submission commit 7e85f6dbc85616de2172bce8eaf84b387a723cd1 upstream. qla_nvme_fcp_abort() and qla_nvme_ls_abort() ran INIT_WORK() on priv->abort_work immediately before schedule_work(). INIT_WORK() reinitializes the work_struct, resetting its list head and clearing the pending bit. If an abort is issued more than once for the same command (for example, concurrent transport teardown and a timeout-driven abort), the second INIT_WORK() reinitializes a work item that is already queued, which can corrupt the workqueue list and lead to crashes or a looping worker. Initialize priv->abort_work once at command submission, next to the existing per-command spin_lock_init(&priv->cmd_lock), and leave only schedule_work() in the abort paths. schedule_work() already does nothing when the work item is still pending, so a repeated abort no longer disturbs an in-flight work item. The command is not returned to the transport until the final kref_put()/release callback runs after abort_work has completed, so the work item is idle before priv is reused and the single submission-time INIT_WORK() is safe. Fixes: e473b3074104 ("scsi: qla2xxx: Add FC-NVMe abort processing") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-52-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 47272152a13d202d98496208f9bf382c1cf4d4fb Author: Nilesh Javali Date: Thu Jul 23 10:34:07 2026 +0530 scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() commit 793cedee296fd819bfadc2a7ec4d52faf9c09a0a upstream. In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals. Fixes: 2c3dfe3f6ad8 ("[SCSI] qla2xxx: add support for NPIV") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-51-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 206df5ffa72dc850fea700e7ba448701f81829b9 Author: Nilesh Javali Date: Thu Jul 23 10:34:04 2026 +0530 scsi: qla2xxx: Fix Name Server logout detection on FWI2 adapters commit eb137255fd7aa834c4d639ae7b5e9e8ecf3a4fb2 upstream. In the CS_PORT_LOGGED_OUT case of qla2x00_chk_ms_status(), the FWI2-capable branch compared ms_pkt->loop_id.extended against NPH_SNS to decide whether the Name Server had logged out. On FWI2 and later adapters the response is a ct_entry_24xx / ct_entry_24xx_ext, where loop_id.extended (via the legacy ms_iocb_entry_t view) aliases offset 8, which is comp_status, not nport_handle (offset 10). As this code runs under CS_PORT_LOGGED_OUT, the field read back 0x29 (CS_PORT_LOGGED_OUT) and the comparison against NPH_SNS (0x7fc) was always false. As a result the driver never recognized a Name Server logout on FWI2/ 29xx adapters: it returned the generic QLA_FUNCTION_FAILED instead of QLA_NOT_LOGGED_IN and skipped setting LOOP_RESYNC_NEEDED / LOCAL_LOOP_UPDATE, so the fabric rediscovery triggered by an SNS logout did not happen. Read nport_handle from the ct_entry_24xx layout (offset 10) instead. nport_handle is at the same offset in ct_entry_24xx and ct_entry_24xx_ext, so a single cast covers 24xx-class and 29xx. The non-FWI2 branch keeps using loop_id.extended, which is correct for the ms_iocb_entry_t response on those adapters. Fixes: b98ae0d748db ("scsi: qla2xxx: Fix name server relogin") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-48-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 94bfb61478bcb207d27f8cd24fd231421059519f Author: Nilesh Javali Date: Thu Jul 23 10:34:03 2026 +0530 scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check commit c20ee380ca59c5a8646750c4849969a815924e2e upstream. qla_chk_edif_rx_sa_delete_pending() obtains the SCSI command via GET_CMD_SP(sp) and immediately dereferences cmd->sc_data_direction. That command pointer can be NULL: the firmware may post a status completion for a command that has already been returned or aborted. The caller qla2x00_status_entry() acknowledges this on the very same status path, re-fetching GET_CMD_SP(sp) and bailing out with the "Command already returned" message when it is NULL -- but that check runs only after qla_chk_edif_rx_sa_delete_pending() has already dereferenced the pointer, so a NULL cmd crashes the kernel in interrupt context. Return early when cmd is NULL, before touching cmd->sc_data_direction. Fixes: dd30706e73b7 ("scsi: qla2xxx: edif: Add key update") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-47-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 97ca58b0fb026799b99e3d552d5f69cf9a3113ad Author: Nilesh Javali Date: Thu Jul 30 21:28:37 2026 +0530 scsi: qla2xxx: Bound i2c->length in I2C bsg handlers commit 0918ee2c0eeb4d7f45b82b3dc11e65c2d9b7ad59 upstream. struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: struct qla_i2c_access { uint16_t device, offset, option, length; uint8_t buffer[0x40]; } __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers. Fixes: 9ebb5d9c69f1 ("[SCSI] qla2xxx: Add I2C BSG interface.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-33-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit b157256c28086c434afd70cc78bf9b4d8caf1276 Author: Nilesh Javali Date: Thu Jul 30 21:28:36 2026 +0530 scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers commit b47d4a1547d9ef21b2e9d1a739fe2204d4be05dc upstream. The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: if (len == 1) opt |= BIT_0; if (opt & BIT_0) len = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents. Fixes: 697a4bc69159 ("[SCSI] qla2xxx: Provide method for updating I2C attached VPD.") Fixes: 9ebb5d9c69f1 ("[SCSI] qla2xxx: Add I2C BSG interface.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-32-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit dec5624a3f8cb2bd1a0354038151294f4259d8bd Author: Jackson Lee Date: Fri Jun 26 10:22:27 2026 +0900 media: chips-media: wave5: Set inst->std during default format initialization commit cfcefc5a996f6a00b310c963b5f811430f28a30a upstream. When the encoder is opened, wave5_set_default_format() sets up the default capture format (e.g. H.264) but does not initialize inst->std. As a result, inst->std remains zero, which does not match any valid encoder codec. If STREAMON is called before the user explicitly calls S_FMT on the capture queue — as v4l2-compliance does in testBlockingDQBuf — the codec/product check in wave5_vpu_enc_init_seq() fails with "Unsupported encoder-codec & product combination" because inst->std is neither W_HEVC_ENC nor W_AVC_ENC, returning -EOPNOTSUPP. Fix this by setting inst->std via wave5_to_vpu_std() in wave5_set_default_format(), so that the codec type is always consistent with the default capture pixel format from the moment the instance is opened. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a0506198a77b9e2063b30d718b786cb0203e9061 Author: Jackson Lee Date: Fri Jun 26 10:22:26 2026 +0900 media: chips-media: wave5: Guard bit depth check with initial_info_obtained commit 1551386934ad43d934c3bb7317929207e1edcd6a upstream. When CAPTURE STREAMON is called before the VPU has completed sequence initialization (initial_info_obtained == false), the initial_info fields contain uninitialized data. The driver checks luma_bitdepth and rejects anything other than 8-bit, so garbage values (e.g. 15) cause STREAMON to fail spuriously. This is reproducible with the following multi-threaded test scenario: 1. Allocate 2 CAPTURE buffers. 2. Call STREAMON on the CAPTURE queue. 3. Call DQBUF, which blocks waiting for a decoded frame. 4. A second thread calls STREAMOFF on the CAPTURE queue. 5. The blocked DQBUF should be released, allowing graceful termination. At step 2, STREAMON reads uninitialized luma_bitdepth and rejects the stream, causing the test to fail. Fix this by checking initial_info_obtained before accessing the bit depth fields, so the validation is only performed when the sequence info has actually been parsed by the VPU. Fixes: 035371c9e509 ("media: chips-media: wave5: Fix timeout while testing 10bit hevc fluster") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ff98cd2b8b54cf96bccace2f7b7e4775cdccaf02 Author: Hungyu Lin Date: Tue Jun 30 15:26:17 2026 +0000 media: qcom: iris: use disable_irq() during power-off commit b9c2215bdedc9c532a7e9d57ec49ee1b6381f863 upstream. The IRQ is registered as a threaded IRQ. Using disable_irq_nosync() in iris_vpu_power_off() does not wait for an already queued threaded IRQ handler to complete before returning. As a result, a threaded IRQ handler may still run after the VPU has been powered down and access hardware registers after power-off. Replace disable_irq_nosync() with disable_irq() so the power-off path waits for any in-flight threaded IRQ handler to complete before returning. Fixes: bb8a95aa038e ("media: iris: implement power management") Cc: stable@vger.kernel.org Suggested-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Hungyu Lin Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit ab6f088a44ef79a7c52f026a89cbb40315ccd211 Author: Dikshita Agarwal Date: Sun May 31 11:20:36 2026 +0530 media: qcom: iris: fix state-change debug log printing stale value commit 460d3257a6dffc7f0bf58009daeb7e0b6eb2d9d3 upstream. The state‑change debug log in iris_inst_change_state() always prints the same value for the old and new state, rendering it useless for debugging. This happens because the state is updated before the log is emitted. Log the transition before updating the state so the previous value is preserved, consistent with the existing sub‑state handling. Fixes: 11712ce70f8e ("media: iris: implement vb2 streaming ops") Reviewed-by: Bryan O'Donoghue Reviewed-by: Konrad Dybcio Signed-off-by: Dikshita Agarwal Signed-off-by: Vishnu Reddy Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit f1c4f3885df1f09bcab5296d86834d104f865e86 Author: Ruoyu Wang Date: Wed Jul 8 22:33:49 2026 +0800 media: zoran: Avoid freeing a registered video_device twice commit 0735e0b5a96761a9ce277a238e834008ad92a0a5 upstream. zoran_init_video_device() installs zoran_vdev_release() as the video_device release callback through zoran_template. After video_register_device() succeeds, video_unregister_device() drops the registered video_device reference and the V4L2 core eventually invokes that release callback, which kfree()s the video_device. zoran_exit_video_devices() called video_unregister_device() and then kfree(zr->video_dev), so device teardown could free the same video_device twice. Remove the direct kfree() and clear the cached pointer after unregistering. The pre-registration failure path keeps its manual free because the video_device was not registered there. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 82e3a496eb56 ("media: staging: media: zoran: move videodev alloc") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit dc005cb7ccb0c551992d59bbb3e8def48521caec Author: Arash Golgol Date: Wed Jul 22 20:14:51 2026 +0330 media: vimc: fix pixel format lookup in enum_framesizes commit ad4c65fa30cfb00e2e06adae9a8eb407086eaa66 upstream. vimc_capture_enum_framesizes() looks up the requested format using vimc_pix_map_by_code(), which searches the pix map table by media bus code (MEDIA_BUS_FMT_*). However, v4l2_frmsizeenum::pixel_format holds a V4L2 pixel format (V4L2_PIX_FMT_*), not a media bus code, so valid pixel formats end up being rejected with -EINVAL. Fix this by using vimc_pix_map_by_pixelformat() instead, which performs the lookup by pixel format as the ioctl expects. Fixes: 09c41a23a2e2 ("media: Revert "media: vimc: propagate pixel format in the stream"") Cc: stable@vger.kernel.org Signed-off-by: Arash Golgol Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 52fd9d80c0cea7bf09e7ee36cad316e5c39b7fe6 Author: Uday Khare Date: Mon Jul 6 20:58:33 2026 +0530 media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure commit 76e379754ba618989f6215be608d5c04774a611d upstream. kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path. Fixes: 5cebaac60974 ("media: video-i2c: add video-i2c driver") Cc: stable@vger.kernel.org Signed-off-by: Uday Khare Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4a187d94438457d2d99aa0770c8b9baa1c8387b6 Author: Mohammed EL Kadiri Date: Wed Jun 10 13:56:55 2026 +0100 media: venus: fix payload size calculation in parse_raw_formats() commit bd595b745eb770e80347c31ffc25351046935305 upstream. The consumed size is computed after the loop using the num_planes value from the last iteration for all entries. When entries have different plane counts, this produces an incorrect total. Accumulate the actual size during the loop instead. Fixes: 9edaaa8e3e15 ("media: venus: hfi_parser: refactor hfi packet parsing logic") Cc: stable@vger.kernel.org Signed-off-by: Mohammed EL Kadiri Reviewed-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit d031b5ecc4b39a909842a377dc665faa0926f692 Author: Mohammed EL Kadiri Date: Wed Jun 10 13:56:54 2026 +0100 media: venus: fix payload size returned by parse_caps() and parse_alloc_mode() commit a51cea23e409278f6e2ea072280aba93cc1dd75e upstream. parse_caps() and parse_alloc_mode() return only the size of their fixed header fields, excluding the flexible array payload. hfi_parser() uses this return value to advance through the firmware response buffer, so underreporting causes parser desynchronization. Return the full consumed size (header + entries), matching the correct pattern used by parse_profile_level(). Fixes: 9edaaa8e3e15 ("media: venus: hfi_parser: refactor hfi packet parsing logic") Cc: stable@vger.kernel.org Signed-off-by: Mohammed EL Kadiri Reviewed-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit 3ced388b7908270529e5aa6d221840114b6c33bc Author: Biren Pandya Date: Fri Jun 19 13:41:30 2026 +0530 media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link commit a6e86efd7f85e519bf48417f41923f8bd51f1597 upstream. In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. Signed-off-by: Biren Pandya Fixes: ca50c197bd96 ("[media] v4l: fwnode: Support generic fwnode for parsing standardised properties") Cc: stable@vger.kernel.org [Sakari Ailus: Fix subject prefix and coding style a little.] Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 331f22dd63bf97643c0569cc988448e01acd330d Author: Ming Qian Date: Mon Jul 20 18:17:26 2026 +0900 media: v4l2-ctrls: Allow unknown HDR10 white point and luminance commit 49af0c7cad889f7dabe5cf080b019392066122a3 upstream. SMPTE ST 2086 defines the nominal ranges for mastering display chromaticity and luminance values. Its Annex A also documents that CTA 861-G uses zero maximum and minimum luminance values to signal that the corresponding values are unknown, and the xy chromaticity coordinate (0, 0) to signal that the white point chromaticity is unknown. The V4L2 HDR10 mastering display compound control currently rejects these values. Consequently, an unknown white point or luminance value prevents the entire compound control from being updated, making the other valid mastering display metadata unavailable to userspace. Accept (0, 0) as an unknown white point and zero as an unknown maximum or minimum mastering luminance. Continue to reject partially zero white point coordinates and non-zero values outside the nominal ranges. Display primary validation remains unchanged. Document the newly accepted unknown values in the V4L2 userspace API. Fixes: 1ad0de78e794 ("media: v4l: Add HDR10 static metadata controls") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 3345746e0957bce6c53644838e4955710a82a962 Author: Xu Rao Date: Mon Aug 10 17:50:12 2026 +0800 media: v4l2-async: avoid deleting unlinked ASC entry on link error commit 47d82b605351c0e04f6365e42c8ffe2fcfdba615 upstream. v4l2_async_match_notify() creates ancillary media links before adding asc->asc_subdev_entry to sd->asc_list. If ancillary link creation fails, the function jumps to err_call_unbind while asc_subdev_entry has not been linked yet. Async connections are zero-allocated, so the list entry still has NULL next and prev pointers on this path. Calling list_del() on it can therefore dereference NULL instead of returning the original link creation error. Do not delete asc_subdev_entry from err_call_unbind. There is no list insertion to undo on this path; the bound callback and sub-device registration are the operations that need to be rolled back. Fixes: 28a1295795d8 ("media: v4l: async: Allow multiple connections between entities") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 7c62bd653563939ff0d0fdfd4b8c73c4f97a1dcc Author: Ilya Krutskih Date: Sun Jul 19 13:08:35 2026 +0000 media: tda18250: fix possible integer overflow commit 6dd8e257f7cafda7fbf10d81b3c55c9bba4825f4 upstream. Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior. Fixes: 148abd3b5b14 ("media: tda18250: support for new silicon tuner") Cc: stable@vger.kernel.org Signed-off-by: Ilya Krutskih Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4d2048466af9e2c960c5be6dcd317e3b657d268b Author: Guangshuo Li Date: Sat Jul 18 14:10:11 2026 +0800 media: saa7164: fix cleanup on resource allocation failure commit 28e84c6e2e6753ed238ea097b2842a32a6a6879b upstream. saa7164_dev_setup() adds the device to the global saa7164_devlist before requesting the PCI BAR memory regions. If get_resources() fails, saa7164_dev_setup() decrements the device count and returns an error, but leaves the device on saa7164_devlist. The probe error path then frees the device, leaving a dangling entry on the global list. Reuse the existing MMIO mapping error path to remove the device from saa7164_devlist and decrement the device count before returning. Also release BAR0 if it was successfully requested but the BAR2 request fails. Fixes: 443c1228d505 ("V4L/DVB (12923): SAA7164: Add support for the NXP SAA7164 silicon") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 342632a4d8ba3fafc1556deee0b7a48dd7860336 Author: Lei Huang Date: Tue Jul 14 14:52:02 2026 +0800 media: s2255: check firmware size before reading trailing marker commit 330f2936ab768c7215322a476f033143e8891d28 upstream. s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing. Fixes: 14d962602c8b ("V4L/DVB (8752): s2255drv: firmware improvement patch") Cc: stable@vger.kernel.org Signed-off-by: Lei Huang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 68d664f1b4efe525e99154b7058fcb0378bdaff7 Author: HyeongJun An Date: Wed Jul 1 20:45:36 2026 +0900 media: s2255: bound JPEG frame size before copying into the buffer commit e504cc888f42999dd76b6a43788c422610f2aad2 upstream. s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: payload = le32_to_cpu(pdword[3]); if (payload > vc->req_image_size) /* payload is checked ... */ return -EINVAL; vc->pkt_size = payload; vc->jpg_size = le32_to_cpu(pdword[4]); /* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it. Fixes: 38f993ad8b1f ("V4L/DVB (8125): This driver adds support for the Sensoray 2255 devices.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 93e6ed88f508448faaa8aeba9da9869a6f4bed78 Author: Tommaso Merciai Date: Wed Jul 29 12:55:46 2026 +0200 media: rzg2l-cru: Align bytesperline to hardware DMA stride requirement commit 56c29fa3ee666197516a231e75aed789ae9c530d upstream. The RZ/G3E CRU programs the line stride via the AMnIS register, whose IS field encodes the value in units of 128 bytes. If bytesperline is not a multiple of 128, the division truncates and the hardware uses a wrong stride, causing horizontal banding. Commit ace92ccef0c9 ("media: platform: rzg2l-cru: Use v4l2_fill_pixfmt()") replaced the open-coded aligned calculation with v4l2_fill_pixfmt(), which sets no alignment, reintroducing the issue. Round bytesperline up to RZG2L_CRU_STRIDE_ALIGN and recompute sizeimage when info->has_stride is set. RZ/G2L has no AMnIS register and keeps the values from v4l2_fill_pixfmt() unchanged. Fixes: ace92ccef0c9 ("media: platform: rzg2l-cru: Use v4l2_fill_pixfmt()") Cc: stable@vger.kernel.org Signed-off-by: Tommaso Merciai Reviewed-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 26a2a985bbeee3eaa6f80ff7de732161a171ec9f Author: Valery Borovsky Date: Sat May 23 19:53:58 2026 +0300 media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure commit fe50cdaebf12cd32ff9a44d92bfd6fbc2300dbd4 upstream. rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module") Cc: stable@vger.kernel.org Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7443b16b6dd8889a3b9c5236a09e7c58f0d11dae Author: Valery Borovsky Date: Sat May 23 19:53:37 2026 +0300 media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak commit dabb047c62668f280998e29117c55e41aabac336 upstream. rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module") Cc: stable@vger.kernel.org Suggested-by: Hans Verkuil Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 12b88016c199ef5665462396095cc92811b63857 Author: Narasimharao Vadlamudi Date: Wed Jul 1 16:42:03 2026 +0530 media: rkvdec: Propagate platform_get_irq() errors commit c37aca64206fafe938119e801a3fd10a537a051f upstream. platform_get_irq() returns a positive IRQ number on success and a negative error code on failure. It no longer returns zero. The driver currently returns -ENXIO for all failures, which loses useful errors such as -EPROBE_DEFER. Return the error from platform_get_irq() directly. Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Cc: stable@vger.kernel.org Signed-off-by: Narasimharao Vadlamudi Reviewed-by: Detlev Casanova Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5b58d8c206f37525c8217171e1f3e91dd2fa55e5 Author: Myeonghun Pak Date: Wed May 13 16:11:03 2026 +0900 media: rc: sunxi-cir: Unregister rc device on probe failure commit 479aa6fa8c50f1052f1451326ef7d4d586d340c3 upstream. After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds. Fixes: b4e3e59fb59c ("[media] rc: add sunxi-ir driver") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Sean Young Signed-off-by: Greg Kroah-Hartman commit 8281acf5d70498edde19def67320b9f5d23f7d94 Author: Guoniu Zhou Date: Tue Jul 28 14:58:56 2026 +0800 media: nxp: imx8-isi: Use BIT_ULL() for 64-bit stream masks commit 77e60a2c5d824ad2d493f53dc17137ae065753fe upstream. Use BIT_ULL() instead of BIT() for u64 stream masks to avoid incorrect results on 32-bit architectures when stream IDs are 32 or greater. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Reviewed-by: Laurent Pinchart Reviewed-by: Frank Li Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20260728-isi-v5-1-1d22ab91602a@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9392375dd4c01544ca2779b158b3c3e0092dc74f Author: Guoniu Zhou Date: Mon Jul 20 11:34:07 2026 +0800 media: nxp: imx8-isi: Correct color map between V4L2 and ISI commit 4640ec1cb0121473867e7a6850c7449340dcd428 upstream. Fix the ISI input format for the color map V4L2_PIX_FMT_XBGR32 in memory-to-memory mode. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Tested-by: Laurent Pinchart Reviewed-by: Laurent Pinchart Reviewed-by: Frank Li Link: https://patch.msgid.link/20260720-isi-v2-5-45845bc5d4fa@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2f9b2768d5ceb6eae6966dad58d29ec0a494165a Author: Guoniu Zhou Date: Mon Jul 20 11:34:03 2026 +0800 media: nxp: imx8-isi: Fix stream ID validation bypass in crossbar routing commit 795bd2863591f2fee33fab8f10cf9c383c94342e upstream. The crossbar routing validation has a critical bug where it validates the wrong routing table, allowing userspace to bypass validation entirely. The __mxc_isi_crossbar_set_routing() function is called to validate and apply a new routing table from userspace. However, the validation loop iterates over state->routing (the currently active routing table) instead of the routing parameter (the new table being validated): for_each_active_route(&state->routing, route) { This means userspace can submit any invalid routing configuration and it will pass validation as long as the currently active routing is valid. This is a security issue as it allows userspace to configure routes that violate hardware constraints, potentially causing undefined hardware behavior. Fix by validating the routing table that will actually be applied. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Reviewed-by: Laurent Pinchart Reviewed-by: Frank Li Link: https://patch.msgid.link/20260720-isi-v2-1-45845bc5d4fa@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5026f927ef4150ba12da6f1098cf7952d77b14b6 Author: Johan Hovold Date: Mon Jul 6 08:59:27 2026 +0200 media: platform: mtk-mdp3: fix NULL deref on failed SCP lookup commit 90368323fb244da0504e3da37a182f8e89bcc3b9 upstream. Add the missing sanity check after looking up the SCP to avoid dereferencing a NULL-pointer in case its driver has not yet been bound. Fixes: 61890ccaefaf ("media: platform: mtk-mdp3: add MediaTek MDP3 driver") Cc: stable@vger.kernel.org # 6.1 Cc: Moudy Ho Signed-off-by: Johan Hovold Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 252850653569fdb1a259937e02325cf32c8f0970 Author: Guangshuo Li Date: Sun Jul 5 01:31:19 2026 +0800 media: platform: mtk-mdp3: Fix SCP device refcounting commit 55793e4665b7f15151e6f5ab51ca980e73abed5d upstream. mdp_probe() first tries to get the SCP handle with scp_get(). When that fails, it falls back to looking up the SCP platform device with __get_pdev_by_id() and then reads its driver data. The fallback lookup returns the platform device with a reference, just like scp_get() does. However, the fallback path currently drops that reference immediately after platform_get_drvdata(). The driver later still calls scp_put(mdp->scp) unconditionally from the probe error path and from mdp_video_device_release(), which drops the SCP device reference again. Keep the fallback reference until the existing scp_put() call, so that the fallback path follows the same ownership rules as the scp_get() path. Fixes: 8f6f3aa21517 ("media: platform: mtk-mdp3: fix device leaks at probe") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Johan Hovold Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 96dafbae77f50bfe2228bcfedcd8652c5e5f08e8 Author: Christian Hewitt Date: Wed Jun 24 06:58:08 2026 +0000 media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common commit 20aa934ace6917262ff579a73ec018d06a7bad1c upstream. When VIDIOC_TRY_FMT is called with an unsupported pixel format on the OUTPUT queue, vdec_try_fmt_common() falls back to V4L2_PIX_FMT_MPEG2. However, if a distro has locally patched MPEG2 support out (as it has been broken for some time) the platform format table does not contain MPEG2 so find_format() returns NULL and the subsequent dereference of fmt_out->max_width triggers a NULL pointer dereference. Fix this by falling back to the first format in the platform's format array instead of hardcoding V4L2_PIX_FMT_MPEG2. This is always valid since every platform defines at least one format. Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver") Cc: stable@vger.kernel.org Signed-off-by: Christian Hewitt Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 24aca883903880a7840f5ba4441ec32dc0d82063 Author: Bryan O'Donoghue Date: Tue Jun 2 14:59:21 2026 +0100 media: iris: Enumerate cap->bus_info to differentiate between encoder and decoder commit 94ef75095d5e76df848a2e5508d71a4532a6ce23 upstream. commit 66c744e28b69 ("media: venus: assign unique bus_info strings for encoder and decoder") introduced the naming convention plat:node-addr:video-codec{enc|dec}. Right now Iris does not replicate this naming convention. When we do v4l2-ctrl --list -devices we see: Iris Decoder (platform:aa00000.video-codec): /dev/video0 /dev/video1 Enumerate the bus_info field of the capabilities structure for namespace parity and appropriate differentiation: Iris Decoder (plat:aa00000.video-codec:dec): /dev/video0 Iris Encoder (plat:aa00000.video-codec:enc): /dev/video1 Fixes: 5ad964ad5656 ("media: iris: Initialize and deinitialize encoder instance structure") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Reviewed-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit 27b7997be552ee37b3e01beacfeb4131f1bebb5f Author: Cong Nguyen Date: Sat Aug 8 16:10:02 2026 +0700 media: intel/ipu6: fix async notifier cleanup leak on parse error commit abb1f808ceab5a3275f8a6b4e37cff17f9f781c1 upstream. isys_notifier_init() calls v4l2_async_nf_init() and then adds fwnode remote subdevs in a loop with v4l2_async_nf_add_fwnode_remote(). If an endpoint parse or add fails partway through the loop, it jumps to err_parse and returns without calling v4l2_async_nf_cleanup(), leaking every v4l2_async_connection already added to the notifier's waiting list. The register-failure path just below already cleans up correctly, and the caller only tears the notifier down (isys_notifier_cleanup()) once isys_notifier_init() has returned success. Clean up the notifier on the parse error path too. Fixes: f50c4ca0a820 ("media: intel/ipu6: add the main input system driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 1d59c5254c33aacd7cb0ec5f998a8b68542b8388 Author: Dave Stevenson Date: Wed Jul 15 12:43:14 2026 +0100 media: imx355: Avoid calling imx355_power_off twice in error path commit ee737bc3ccae7dc713ccaa83ffa46080c6031b3e upstream. If v4l2_async_register_subdev_sensor failed, then the sensor had already been powered down by pm_runtime_idle, but the error path then also explicitly called imx355_power_off as well. That left an imbalance in the regulator and clock calls. Call pm_runtime_idle only after v4l2_async_register_subdev_sensor succeeds to avoid this. Fixes: efa5fe19c0a9 ("media: imx355: Enable runtime PM before registering async sub-device") Cc: stable@vger.kernel.org Signed-off-by: Dave Stevenson Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit af81f35e4f429e769b784754e1aa4d7a922470ac Author: Biren Pandya Date: Wed Jul 8 18:27:23 2026 +0530 media: i2c: ov7740: fix use-after-destroy in remove commit 5d1b3dea5a44124bab6c14a2d71b977dabed54e7 upstream. The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order. Fixes: 39c5c4471b8d ("media: i2c: Add the ov7740 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Biren Pandya Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 90f9b421fc6d4f2edab7521efdb1e58571468d33 Author: Biren Pandya Date: Wed Jul 8 18:35:33 2026 +0530 media: i2c: ov02a10: fix endpoint parsing use-after-free commit 94971ba0592ca77ec99b292226a4b398763315b8 upstream. The ov02a10_check_hwcfg() function calls fwnode_handle_put(ep) immediately after allocating and parsing the endpoint. However, it subsequently calls fwnode_property_read_u32() using the same 'ep' handle, leading to a potential use-after-free. Additionally, reading the optional 'ovti,mipi-clock-voltage' property used to overwrite the 'ret' variable. If the property was missing, 'ret' would become negative, and this failure code would be incorrectly returned at the end of the function, causing probe to fail entirely. Fix the use-after-free by moving fwnode_property_read_u32() before the endpoint is parsed and freed. Avoid the error leak by not assigning the result of fwnode_property_read_u32() to 'ret'. Fixes: 91807efbe8ec ("media: i2c: add OV02A10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Biren Pandya Reviewed-by: Vladimir Zapolskiy Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 4f8fd40b39bf7d8299c92e0758eb682306a8c500 Author: Narasimharao Vadlamudi Date: Wed Aug 5 19:26:34 2026 +0530 media: i2c: imx415: Return test pattern write errors commit 8cd5735b88d76dda80b089031747b6f18ee0bca2 upstream. imx415_set_testpattern() accumulates failures from cci_write(), but drops the value and always returns success. Return the accumulated error so V4L2 reports failures to userspace. Fixes: d5df1c7f3f83 ("media: i2c: imx415: Convert to new CCI register access helpers") Cc: stable@vger.kernel.org Reviewed-by: Michael Riesch Signed-off-by: Narasimharao Vadlamudi Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 1aa66bb3ba440aabb3bfe65ba5f19bef86a0f823 Author: Narasimharao Vadlamudi Date: Wed Aug 5 19:26:35 2026 +0530 media: i2c: imx415: Release runtime PM reference on VBLANK error commit bea3001e0f32527a291444e527e84a7ea9b546d4 upstream. The VBLANK path returned immediately when programming VMAX failed after pm_runtime_get_if_in_use() had taken a runtime PM reference. Break out of the switch instead so the common pm_runtime_put() path is used. Fixes: 3bcae55ab96a ("media: i2c: imx415: Add read/write control of VBLANK") Cc: stable@vger.kernel.org Reviewed-by: Michael Riesch Signed-off-by: Narasimharao Vadlamudi Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 312c68e9ed8a4f765f7231f6fd51c8dd3deef2c2 Author: Martin Hecht Date: Fri May 22 13:41:12 2026 +0200 media: i2c: alvium: Fix: Correct name of register in alvium_set_ctrl_auto_exposure commit 58ca8a0bff9e78841a39863474b96e59ef60da19 upstream. Write value for auto-exposure into correct register REG_BCRM_EXPOSURE_AUTO_RW instead of wrong register REG_BCRM_WHITE_BALANCE_AUTO_RW. Fixes: 0a7af872915e ("media: i2c: Add support for alvium camera") Cc: stable@vger.kernel.org Signed-off-by: Martin Hecht Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 0745a59945d927652d892437f9647ed6e87c0677 Author: Shuangpeng Bai Date: Mon Jul 6 16:50:15 2026 -0400 media: go7007: defer the ALSA v4l2 put until card release commit 1bd456afeb8a515137e567967069fce6f8fcd23e upstream. go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime. Closes: https://lore.kernel.org/r/178144969601.60470.6005237146425573205@gmail.com Fixes: d5d3a7cc127d ("[media] go7007: fix unregister/disconnect handling") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0782807552b6aff41b4656c6c9076a3231d3e79d Author: Jiangong.Han Date: Tue Jun 30 22:54:34 2026 +0800 media: em28xx: fix use-after-free of dev_next->devlist on disconnect commit 826915b6b65e2d3251e7248ea54289a22d748c84 upstream. When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 ("USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed. Fixes: f410b4093fdd ("media: em28xx: split up em28xx_dvb_init to reduce stack size") Cc: stable@vger.kernel.org Reported-by: syzbot+99d6c66dbbc484f50e1c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=99d6c66dbbc484f50e1c Signed-off-by: Jiangong.Han Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f9322ac9f862961d7f377b87ec26c8565af7e073 Author: Diego Fernando Mancera Gomez Date: Thu Jul 23 12:22:42 2026 -0600 media: em28xx: defer audio-only extension registration commit 95f76f51937fdfb0fc1e14cae606b1ef574a56f3 upstream. The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next. Fixes: 4a089668ef22 ("media: em28xx-cards: rework the em28xx probing code") Cc: stable@vger.kernel.org Reported-by: syzbot+a11c46f37ee083a73deb@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/66ec3c83.050a0220.29194.002f.GAE@google.com/T/ Suggested-by: Fedor Pchelkin Signed-off-by: Diego Fernando Mancera Gomez Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit bf3f49273d5bf6acbdad18ff44c01ffcf7a7a146 Author: Fan Wu Date: Mon Jul 20 13:17:08 2026 +0000 media: cx23885: cancel NetUP CI work before teardown commit 4e143d662ca94888b494b2427fc9e34494eb933a upstream. netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool. Fixes: c184dcd28233 ("V4L/DVB (10798): Add CIMax(R) SP2 Common Interface code for NetUP Dual DVB-S2 CI card") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7087bef6510c7df5df0b19192633b8ecc0f33a6f Author: Bryam Vargas Date: Mon Jun 15 18:40:48 2026 -0500 media: cx231xx: reject geometry changes while the VBI queue is busy commit 627a121c15fe05a541f44d86016294b80bada75d upstream. vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: offset = lines_completed * (dev->width << 1) + ...; if (dma_q->current_field == 2) offset += dev->width * 2 * dma_q->lines_per_field; memcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer. Fixes: 7c617138b825 ("media: cx231xx: convert to the vb2 framework") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit cb1218da234ea15fa14d90e2d049d686874d7aa3 Author: Ruoyu Wang Date: Wed Jul 8 22:33:38 2026 +0800 media: cobalt: Avoid freeing ALSA private data twice commit 3a7d6b9c4cb5ac18cbd3f1c7f8c7b159c42ba0b1 upstream. snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 85756a069c55 ("[media] cobalt: add new driver") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f78cf36cabf911da348ea80e4e9f430d74f6905c Author: Dawei Feng Date: Wed Jun 24 16:59:20 2026 +0800 media: cedrus: fix memory leak in cedrus_init_ctrls() commit 9df2fbe563194da1967a5db083442186c1323efe upstream. In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed. Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng Acked-by: Jernej Skrabec Reviewed-by: Dan Carpenter Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5c62095acc2a952099688774513c4a637bcdb2b5 Author: Ruoyu Wang Date: Wed Jul 8 11:01:02 2026 +0800 media: cec: Serialize exclusive follower delivery commit 1924d0788caa6c66fd320dd4704fae99487fd2c7 upstream. cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release. Fixes: 9881fe0ca187 ("[media] cec: add HDMI CEC framework (adapter)") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 38c14532adb3463632ec275f7b0cbb4cc191488e Author: Yi Ding Date: Thu May 28 23:00:05 2026 -0700 media: cec: meson: ao-cec-g12a: name the CEC core regmap to avoid debugfs clash commit 172c5a7d81deb922ddedd1bc920751c7fed6c43c upstream. The driver registers two regmaps on the same platform device: an MMIO regmap for the AO CEC registers, and an indirect regmap (using reg_read()/reg_write() callbacks) for the CEC controller core registers. Neither regmap_config sets a .name, so both default their debugfs directory to the device name and collide: debugfs: 'ff800280.cec' already exists in 'regmap' Because of the clash the second regmap's debugfs directory fails to register, so its registers can no longer be inspected via debugfs. Give the indirect CEC core regmap a distinct name. The two debugfs directories then become ".cec" and ".cec-core". This only affects debugfs naming; register access is unchanged. Tested on an ODROID-N2 (Amlogic S922X): the warning is gone and both /sys/kernel/debug/regmap/ff800280.cec and ff800280.cec-core are present. Fixes: b7778c46683c ("media: platform: meson: Add Amlogic Meson G12A AO CEC Controller driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yi Ding Reviewed-by: Neil Armstrong Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 673611cc2ab9769929644ce879f7ea34932a3011 Author: Hans Verkuil Date: Thu Jun 18 13:03:19 2026 +0200 media: cec: extron-da-hd-4k-plus: add sanity check commit abac9820b26b5cfcb01eb79efe2abdd0ac7e07c3 upstream. Add check to prevent overflowing msg.msg[] in case the incoming data is malformed. Signed-off-by: Hans Verkuil Reviewed-by: Sean Young Fixes: 056f2821b631 ("media: cec: extron-da-hd-4k-plus: add the Extron DA HD 4K Plus CEC driver") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a3adb63b121937b97f7fdc51e96564c7c799538b Author: Biren Pandya Date: Sun Jun 21 10:04:37 2026 +0530 media: cec: disable delayed work before freeing an interrupted transmit commit 0fbd5c2327020858c45b2d1c65775d64cdeca523 upstream. cec_transmit_msg_fh() drops adap->lock to wait for a blocking transmit in wait_for_completion_killable(). If that wait is interrupted by a signal, cancel_delayed_work_sync() can run before the CEC kthread arms the reply timeout via schedule_delayed_work(&data->work) in cec_transmit_done_ts(). The work is then armed after the cancel, and the data is freed with its delayed_work still pending: ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout Use disable_delayed_work_sync(): it cancels the work and disables it, so the later schedule_delayed_work() becomes a no-op and the work cannot be re-armed. The data is freed right after, so it need not be re-enabled. Fixes: 490d84f6d73c ("media: cec: forgot to cancel delayed work") Reported-by: syzbot+051024d603432b4ab395@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=051024d603432b4ab395 Suggested-by: Hillf Danton Cc: stable@vger.kernel.org Signed-off-by: Biren Pandya Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 695063fc57574dd117b1bc750ca189cf03a2caad Author: Jonas Karlman Date: Fri May 29 09:59:26 2026 +0000 media: cec: core: Fix kmemleak due to missed rc_free_device() call commit a24ba0653f7154e671dc8d2bf64682ab2d042792 upstream. The commit dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") removed the implicit call to rc_free_device() from rc_unregister_device(). However, the commit missed to remove the NULL assignment of adap->rc that is now causing rc_free_device() to never be called on an allocated rc device. kmemleak reports following after e.g. dw-hdmi unbind: unreferenced object 0xffff00010ac10000 (size 4096): comm "kworker/u16:1", pid 39, jiffies 4294897739 hex dump (first 32 bytes): 20 23 4b 0a 01 00 ff ff 08 00 c1 0a 01 00 ff ff #K............. 08 00 c1 0a 01 00 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc e11baccc): kmemleak_alloc+0x38/0x44 __kmalloc_cache_noprof+0x4a8/0x5e0 rc_allocate_device+0x48/0x2a0 cec_allocate_adapter+0x3ac/0x800 dw_hdmi_cec_probe+0x264/0x634 platform_probe+0xc0/0x188 really_probe+0x4a4/0x8e0 __driver_probe_device+0x2f8/0x440 driver_probe_device+0x60/0x160 __device_attach_driver+0x1a0/0x2a0 bus_for_each_drv+0x100/0x1a0 __device_attach+0x174/0x350 device_initial_probe+0x90/0xb0 bus_probe_device+0x4c/0x120 device_add+0xdec/0x116c platform_device_add+0x354/0x598 Remove the assignment of adap->rc to NULL to let cec_delete_adapter() free the allocated rc device after last user of the cec device exits to fix the kmemleak. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Cc: stable@vger.kernel.org Signed-off-by: Jonas Karlman Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit cb7a4cf63fa20a83172b1126cd600148f759eccd Author: Ming Qian Date: Thu Jun 11 17:17:00 2026 +0900 media: amphion: Remove obsolete frame_count check in venc_start_session commit 2be6ee86385badab95b1bace984735bde6e0fec0 upstream. The dev_err() log warning about no input when starting was originally meaningful when min_queued_buffers was set, as it indicated an abnormal condition. However, since commit 5633ec763a2a ("media: amphion: Drop min_queued_buffers assignment") removed the min_queued_buffers assignment, having frame_count == 0 at start is a normal condition. Remove this misleading log that no longer serves any purpose. Fixes: 5633ec763a2a ("media: amphion: Drop min_queued_buffers assignment") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Frank Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 297fee023f46d771a844520675692ea089d80d9d Author: Valery Borovsky Date: Sat May 23 19:53:49 2026 +0300 media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref commit 2f378dc45e685fc825d2dd08e7864666d6fcc009 upstream. airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 634fe5033951 ("[media] airspy: AirSpy SDR driver") Cc: stable@vger.kernel.org Suggested-by: Hans Verkuil Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 347e9d2246b898be53a93a10e997754d543f77b7 Author: Danilo Krummrich Date: Sun Jun 28 16:53:21 2026 +0200 rust: drm: ioctl: fix unbounded lifetimes in ioctl handler arguments commit 68b151bc6145dea3db5598ebaf4b776cd205e395 upstream. References to dev, data, and file in the declare_drm_ioctls! macro are created via unsafe pointer dereferences, producing unbounded lifetimes. If an ioctl handler explicitly annotates its parameters with 'static, the compiler accepts this, allowing the handler to stash references that outlive the ioctl call. Fix this by adding a higher-ranked function pointer coercion that enforces the handler accepts universally quantified lifetimes: let _: for<'a> fn(&'a _, &'a mut _, &'a _) -> _ = $func; Since the handler must be coercible to a function pointer accepting any lifetime 'a, it can no longer demand 'static on any parameter. Cc: stable@vger.kernel.org Fixes: 9a69570682b1 ("rust: drm: ioctl: Add DRM ioctl abstraction") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260620011346.A47D01F000E9@smtp.kernel.org/ Suggested-by: Gary Guo Reviewed-by: Alexandre Courbot Reviewed-by: Lyude Paul Tested-by: Deborah Brouwer Link: https://patch.msgid.link/20260628145406.2107056-2-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 76395109a051b53860faaec96522ef08ae9e8e27 Author: Jérémy Jean Date: Fri Sep 4 21:44:43 2026 +0800 LoongArch: Avoid preempt count underflow without probe commit 72ce4b24676e8b3b75376c4c559dd81c1ac52d5a upstream. LoongArch uses break 11 for the breakpoint placed after an instruction that Kprobes executes out of line. Since userspace can issue the same break instruction, do_bp() can reach kprobe_singlestep_handler() when there is no current probe. The handler actually returns false in this case, but it first calls preempt_enable_no_resched(). The corresponding preempt_disable() is done by kprobe_breakpoint_handler() on a real Kprobe hit, so it has not run here. As a result, an ordinary userspace breakpoint (code 11) underflows the current task's preempt count. This also makes in_interrupt() return true until the task schedules. One visible consequence is the socket cgroup attribution: cgroup_sk_alloc() treats the allocation as interrupt context and assigns the socket to the root cgroup. A socket opened from the SIGTRAP handler can then avoid a BPF_CGROUP_INET_SOCK_CREATE policy attached to the task's own cgroup. Return as soon as kprobe_running() reports no active probe. The same check has appeared in [PATCH v10 2/4] of the original LoongArch Kprobes series, but was dropped before the feature reached mainline. Cc: stable@vger.kernel.org Fixes: 6d4cc40fb5f5 ("LoongArch: Add kprobes support") Link: https://lore.kernel.org/loongarch/1670575981-14389-3-git-send-email-yangtiezhu@loongson.cn/ Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 266ffc92e68593759adfe3d58f188773d32782c3 Author: Wentao Guan Date: Fri Sep 4 21:44:43 2026 +0800 LoongArch: Do not save/restore percpu base register in rethook trampoline commit c3f2feace5e4f4b01b68b9f947b19adb4155c32e upstream. The rethook trampoline saves $r21 ($u0), the percpu base, into its frame at entry and restores it at exit. Inbetween rethook_trampoline_handler() may schedule via preempt_enable_notrace(). If the task migrates to another CPU, the frame's $r21 holds the old CPU's percpu base, and restoring it poisons $r21 on the new CPU. Until the next user->kernel transition heals $r21, all this_cpu_*() accesses (runqueues, RCU per-CPU data, timer tick programming, FPU ownership) hit the wrong CPU's percpu area. Under kretprobe-heavy preemptible load this can corrupt scheduler and timer state: scheduling-while-atomic splats, wrong-CPU RCU warnings, WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and CPUs parking in the idle loop with the constant timer never re-armed (hard lockup). Reproduces on a Loongson-3A6000 with kretprobes on VFS paths plus heavy file churn (OS install / unsquashfs). By convention $r21 always holds the current CPU's percpu base in kernel mode: SAVE_SOME() at exception entry reloads it only when coming from user mode, and RESTORE_SOME() restores it only when returning to user mode; the context-switch path never writes it. Therefore the live $r21 at trampoline exit is already correct, and nothing inbetween can change it legitimately (kernel C code cannot write a global register variable). The same flaw existed even in the pre-rethook kretprobe trampoline since v6.3; it was carried over when rethook replaced it. Drop both the save and the restore here. Drop the restore is enough to solve the issue, and drop the save is to keep the code tidy and no need to clear it. Cc: stable@vger.kernel.org # v6.3+ Fixes: 3f5536860086d ("LoongArch: Add kretprobes support") Assisted-by: Kimi:Kimi-K3 # debug and root-cause analysis Signed-off-by: Wentao Guan Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit d692b825dc2461f0d82f689ace01b9e72460f54f Author: Nathan Chancellor Date: Fri Sep 4 21:44:23 2026 +0800 LoongArch: Do not select HAVE_RUST when KASAN is enabled commit 63b6a48c951d63bf39d44603ada48a987ccf66eb upstream. After commit 2625480a1bf7 ("hardening: Default randstruct off with rust for better allmodconfig support"), which allows Rust to be enabled for allmodconfig, ARCH=loongarch allmodconfig starts failing with: error: kernel-address sanitizer is not supported for this target error: aborting due to 1 previous error make[4]: *** [rust/Makefile:741: rust/core.o] Error 1 For the same reason as the commit 84a0f7caafc679f7 ("ARM: Do not select HAVE_RUST when KASAN is enabled"), do not select HAVE_RUST when KASAN is enabled until the loongarch64-unknown-none-softfloat target in rustc supports KASAN. Cc: stable@vger.kernel.org Fixes: 90868ff9cade ("LoongArch: Enable initial Rust support") Acked-by: Miguel Ojeda Signed-off-by: Nathan Chancellor Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit d3fd094c13c6d0b74f246461ca4cf427d539c8e8 Author: Bibo Mao Date: Mon Aug 17 22:07:05 2026 +0800 LoongArch: Fix acpi_package_ids[] array overflow commit 2a2367d46d7a4ee4122b7a86e57125542dbbe963 upstream. With LoongArch virt machine, a typical setting is one core per socket, there will max 256 sockets (packages) on one VM. With PPTT acpi table, array acpi_package_ids[] will be overflowed. Here change the array size of acpi_package_ids[] with the max value of MAX_PACKAGES and KVM_MAX_VCPUS. Cc: stable@vger.kernel.org # 6.7+ Fixes: 4e8f58620f67 ("LoongArch: Retrieve CPU package ID from PPTT when available") Reviewed-by: Tao Cui Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 882b8912b7e92341fdb115ba0e2e5142a28684ff Author: Tiezhu Yang Date: Mon Aug 17 22:07:23 2026 +0800 LoongArch: BPF: Refactor jump offset calculation in tail call commit 37d545d12f21c4d50612ecaebd7ae1e5bf91b2d8 upstream. The old macro-based jmp_offset calculation derives the jump distance from a stale prior-pass code stride, which can lead to wrong branch offsets and soft lockups under extra JIT passes. Fix this by calculating the offset directly on the absolute target: "ctx->offset[insn + 1] - ctx->idx". To avoid a false 16-bit range check abort during size estimation, add a "ctx->image == NULL" guard to inject a safe dummy offset. Cc: stable@vger.kernel.org Fixes: cd39d9e6b7e4 ("LoongArch: BPF: Fix jump offset calculation in tailcall") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 462e6abc8293f9f75b9e5d40d6105cb8edc0ebc0 Author: Tiezhu Yang Date: Mon Aug 17 22:07:23 2026 +0800 LoongArch: BPF: Optimize redundant TCC loads in epilogue commit fd3cb1bfeb9d98618bd709bfee9c1133e9f189e6 upstream. The legacy epilogue implementation pops the tail call counter (TCC) context via a redundant double-load pattern. It first decrements the load_offset by 2 slots to fetch 'tcc_ptr', and then immediately bumps it back up by 1 slot to load the original 'tcc' value into REG_TCC, unnecessarily overwriting the register. Optimize this sequence by adjusting the load_offset by only 1 slot. This aligns the offset directly with the higher stack slot containing the entry TCC counter (or caller state), allowing us to restore the REG_TCC register safely with a single load. This removes one redundant instruction from the epilogue hot path, improves code readability, and ensures the correct TCC register context is handed back cleanly upon normal return. Cc: stable@vger.kernel.org Fixes: c0fcc955ff82 ("LoongArch: BPF: Fix the tailcall hierarchy") Fixes: ef54c517a937 ("LoongArch: BPF: Implement PROBE_MEM32 pseudo instructions") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit ab275a23b4d9f04ca6c2f5f6a3246194e045a761 Author: Han Gao Date: Mon Aug 17 22:07:05 2026 +0800 LoongArch: Add DIRECT_MAP_PHYSMEM_END definition commit 2677f97a67fdbc62a82ce1faa67791f54451d36f upstream. get_free_mem_region() and mhp_get_pluggable_range() bound their search to DIRECT_MAP_PHYSMEM_END. LoongArch does not define it, so the fallback in include/linux/mm.h applies: under CONFIG_SPARSEMEM_VMEMMAP it is (1ULL << MAX_PHYSMEM_BITS) - 1, a compile-time constant that does not adapt to the CPU's physical address space bits (cpu_pabits, probed from CPUCFG1). The vmemmap window only covers physical space below 2^(cpu_pabits+1) (i.e. VMEMMAP_SIZE), so on CPUs with fewer physical address bits than MAX_PHYSMEM_BITS the fallback allows get_free_mem_region() to return a ZONE_DEVICE region outside the vmemmap window; vmemmap_populate() then wraps the memmap range around and maps it into low memory, silently corrupting the page tables. The same search also picked the top-of- address-space region that crashed memmap_init_zone_device() with amdkfd on Loongson-3C6000 in 6.16 [1]; the commit 2969b42c8f99 ("LoongArch/mm: align vmemmap to maximal folio size") keeps that region in bounds on current Loongson-3C6000 configs, but CPUs with smaller cpu_pabits (e.g. the Loongson-2K series) are still affected. Define DIRECT_MAP_PHYSMEM_END as the vmemmap-covered physical range, (1ULL << (cpu_pabits + 1)) - 1, capped at (1ULL << MAX_PHYSMEM_BITS) - 1 under CONFIG_SPARSEMEM, similar to the commit f3336b48cf9d ("riscv: mm: Define DIRECT_MAP_PHYSMEM_END"). [1] https://lore.kernel.org/amd-gfx/20250814032153.227285-1-jeffbai@aosc.io/ Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Han Gao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 4e4dbc341b1581dc512b85d98b768373b0398366 Author: Zeng Chi Date: Fri Sep 4 21:45:13 2026 +0800 LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY commit 27a9bfee3bbcb3cabb77797354f07e0e44e49831 upstream. kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE, only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every other change. But the generic code allocates a zeroed memslot for every change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update, e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active memslot has arch.flags == 0. With both flags clear, fault_supports_huge_mapping() falls through to the alignment check on the HVA range alone, which no longer verifies that the GPA and HVA have the same offset within a PMD. A memslot that was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can then be mapped with PMD entries on read faults, and since kvm_map_page() aligns the gfn and the pfn independently, the guest ends up accessing the wrong host pages, exactly the "d -> f, e -> g" case described in the comment above the check. Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY, as the GPA, HVA and size are guaranteed to be unchanged for that case. Cc: stable@vger.kernel.org Fixes: 7ab6fb505b2a ("LoongArch: KVM: Optimization for memslot hugepage checking") Tested-by: Tao Cui Reviewed-by: Tao Cui Reviewed-by: Bibo Mao Signed-off-by: Zeng Chi Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 6b78786ee7260d9818cf1d7a245b7a655ef83076 Author: Chaithanya Lagisetty Date: Fri Sep 4 21:44:53 2026 +0800 LoongArch: KVM: Free init resources if kvm_init() fails commit f7a1064cce3b100b54780c68529176232d8eb01e upstream. kvm_loongarch_init() calls kvm_loongarch_env_init() to allocate the per-CPU kvm_context (vmcs) and kvm_loongarch_ops and to register the perf callbacks, and then calls kvm_init(). If kvm_init() fails its result is returned directly, but since module_init() does not run the module_exit() stuff on failure, so kvm_loongarch_env_exit() is never called and those resources are leaked. So call kvm_loongarch_env_exit() when kvm_init() fails, matching the teardown-on-failure pattern used by riscv_kvm_init(). Cc: stable@vger.kernel.org Fixes: 2bd6ac687261 ("LoongArch: KVM: Implement kvm module related interface") Reviewed-by: Bibo Mao Signed-off-by: Chaithanya Lagisetty Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 07c3037e45c9414bb97d3f6b50a51be7b69da105 Author: Tao Cui Date: Fri Sep 4 21:45:13 2026 +0800 LoongArch: KVM: Fix TOCTOU race on pv_features commit 9296375902579f9b0e456bbb76e5cf179e5a4e0b upstream. In kvm_loongarch_cpucfg_set_attr() the check-then-set on kvm->arch.pv_features is lockless, so two vCPUs can race past the validation and set different values. Add a spinlock to protect it. Cc: stable@vger.kernel.org Reviewed-by: Bibo Mao Signed-off-by: Tao Cui Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit b7fab314ade26ccb458a1b13e66951aa26dfc7fc Author: Zeng Chi Date: Mon Aug 10 12:21:50 2026 +0800 LoongArch: KVM: Fix PC double advance in kernel MMIO read fast path commit fd4021529faa931818186b6e83bd46f5de7517eb upstream. In the in-kernel MMIO read fast path of kvm_emu_mmio_read(), kvm_complete_mmio_read() already advances the guest PC via update_pc(). The explicit update_pc() call right after it advances the PC a second time, so PC moves forward by 8 bytes instead of 4, and the instruction following the MMIO read is silently skipped. The user space MMIO read completion path in kvm_arch_vcpu_ioctl_run() calls kvm_complete_mmio_read() only once, and the MMIO write fast path advances the PC exactly once as well. Here remove the redundant update_pc() so the kernel MMIO read fast path advances the PC by a single instruction. Cc: stable@vger.kernel.org Fixes: 80edf90831a2 ("LoongArch: KVM: Add sign extension with kernel MMIO read emulation") Reviewed-by: Bibo Mao Reviewed-by: Tao Cui Signed-off-by: Zeng Chi Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 566b1f08d983615f731cc693f2ad59db302c6b57 Author: Marc Zyngier Date: Mon Aug 10 18:06:16 2026 +0100 KVM: arm64: Correctly cap TLBI Range to the architural limit commit 69a598288195947a1662b53de702eb6976af96b7 upstream. TLB Invalidation by Range has a fairly powerful way of encoding pretty large ranges in a small number of bits. This range can be based on an arbitrary VA, which means it is pretty easy for a guest to generate an overflow should the hypervisor be naive enough to add the range to the base... Make sure the range is capped to the limit dictated by the address bit that determines the VA range. For an IPA invalidation, this is further corrected down the line to ignore the upper range. Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Reported-by: Wei-Lin Chang Link: https://lore.kernel.org/r/yifz3wn5gk5sr6mapi32trgk5m5kp33bquctsjmkifebnsnndt@fix6u4rthx4g Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Wei-Lin Chang Link: https://patch.msgid.link/20260810170616.746100-1-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 3d4c26b16a04a084fe0bde08ccdd8086570f8bbe Author: Fuad Tabba Date: Fri Aug 7 11:40:59 2026 +0100 KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save commit c6c156d931c33b92362383cf76f6d6e1291dcbfe upstream. MAPC with V=0 drops ite->collection but leaves the ITE on the device's ITT list, and vgic_its_save_ite() dereferences it unconditionally. A guest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the host when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it. That sequence is UNPREDICTABLE per the architecture, but KVM already handles the resulting state in the translate, MOVI and DISCARD paths. Save a zeroed entry, which vgic_its_restore_ite() reads back as invalid. Skipping the ITE instead would leave the ITT slot holding whatever is in guest memory, and restore rejects an entry naming a collection the restored collection table does not have. Fixes: eff484e0298da ("KVM: arm64: vgic-its: ITT save and restore") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260807104102.2410744-2-fuad.tabba@linux.dev Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 2f1a571af300ea019db33c57e2efdef113950f89 Author: Fuad Tabba Date: Sun Aug 2 16:08:45 2026 +0100 KVM: arm64: vgic: Reset in_kernel on private IRQ allocation failure commit 43347154e7ab642474c886bc54ad090166c0d9c9 upstream. kvm_vgic_create() sets vgic.in_kernel before allocating the per-vCPU private IRQs, but the allocation-failure path resets only vgic_model and leaves in_kernel set. As irqchip_in_kernel() is !!in_kernel, the VM is left with an in-kernel irqchip but no model, and the -EEXIST guard at the top of kvm_vgic_create() rejects every retry, so userspace cannot recover from a transient -ENOMEM. Reset in_kernel alongside vgic_model on the failure path. Fixes: 9435c1e1431003 ("KVM: arm64: gic: Set vgic_model before initing private IRQs") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Acked-by: Marc Zyngier Link: https://patch.msgid.link/20260802150845.3485757-1-fuad.tabba@linux.dev Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit de9b4e8f37ce6b532e1c1ec41598c988f9d408db Author: Kajetan Puchalski Date: Mon Aug 10 11:29:24 2026 +0100 KVM: arm64: vgic: Fix detection of MI on no pending LR commit a342faadc5acbd5d9fd894fd4499d4fd614dfcf6 upstream. As per the ARM GICv3 spec, the maintenance interrupt identified by ICH_MISR_EL2.NP is asserted when it is enabled and no List register is in pending state. This is further described in the document as "no List registers with the State field set to 0b01 (pending)". By checking only the pending bit of the LR (bit 62), KVM currently asserts the MI when there are no LRs in "pending" or "pending and active" states. Fix the detection logic to consider only the "pending" state. Cc: stable@vger.kernel.org Fixes: 96c2f03311de ("KVM: arm64: nv: Plumb handling of GICv3 EL2 accesses") Signed-off-by: Kajetan Puchalski Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260810102923.2426475-2-kajetan.puchalski@arm.com Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 7631f95297560157d3a9283cb999e3be00103348 Author: Qihang Date: Fri Aug 7 10:55:34 2026 +0800 KVM: arm64: vgic-v3: take an LPI reference in vgic_v3_save_pending_tables commit f5b8f203bfc07a5a257dff859e66d2c500f9f509 upstream. vgic_v3_save_pending_tables() iterates dist->lpi_xa using xa_for_each() and dereferences the returned struct vgic_irq in the loop body without holding a reference on the LPI. The xarray iterator only provides temporary RCU coverage while looking up the current entry. That is not sufficient for this loop body, which reads fields from struct vgic_irq and performs guest memory accesses before the iteration completes. A concurrent path can trigger this race: the irqfd cached injection path (vgic_its_inject_cached_translation) obtains a transient LPI reference via vgic_its_check_cache() without holding kvm->lock, vcpu->mutex, config_lock, or its_lock. If guest ITS DISCARD then drops the cache and ITE references under its_lock, the transient inject reference may become the final one. When vgic_put_irq() drops it, the LPI is erased from lpi_xa and freed via kfree_rcu(). Meanwhile, vgic_v3_save_pending_tables() may still hold a stale pointer obtained from the xarray iterator and dereference it after the RCU grace period completes. Fix this by re-fetching each iterated LPI via vgic_get_irq(), which takes a stable reference, and dropping it with vgic_put_irq() on all paths. This matches the pattern already used by other lpi_xa iterators in the vgic ITS code. Cc: stable@vger.kernel.org Signed-off-by: Qihang Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260807025534.34125-1-q.h.hack.winter@gmail.com Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 72bce82c4171bf330919ff1b64dc0a36c254ec7d Author: Marc Zyngier Date: Thu Aug 6 10:10:24 2026 +0100 KVM: arm64: Sign-extend VA for range-based TLBI invalidation commit 2393470085649f0b973ecceb26fe8fc71edde0c1 upstream. When the decode_range_tlbi() helper was moved to be used for S1 TLBIs, the required sign extension was omitted. Add it. As a result, special care must be taken to not overflow PA bits when this is used for S2 invalidation. Fixes: 85bba00425ae0 ("KVM: arm64: nv: Move TLBI range decoding to a helper") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/r/20260801130337.EB2BA1F00AC4@smtp.kernel.org Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-7-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit d8580e7aa189b0c6c5bb4d94b8352728a7c35bbd Author: Marc Zyngier Date: Thu Aug 6 10:10:25 2026 +0100 KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry commit 2b7324f3a0c1072b9d578b8d42f199506753f26e upstream. A VNCR TLB invalidation can occur on one vcpu while another vcpu is faulting in this same page. Without correctly handling this, we can end up with the following scenario: - vcpu A walks the PTs to translate VNCR - before vcpu A is able to grab the MMU lock to insert the TLB, vcpu B updates the S1 PTs with an invalid entry, and issues a TLBI S1E2 for this VA - vcpu A inserts the TLB for something that is now invalid This isn't a new problem, and we manage S2 by having the MMU notifier to bump up mmu_invalidate_seq on invalidation so that the fault can be replayed. We can perform something similar here, and extend invalidate_vncr_va() to update the same counter, clearly indicating that the context has changed under our feet. This is safe as the invalidation always happen while holding the MMU lock for write, and that we sample the sequence number before walking S1. Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/r/20260801130454.5D9F11F00AC4@smtp.kernel.org Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-8-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit ce447651a52ec077694172af10c4fffb11f56c43 Author: Marc Zyngier Date: Thu Aug 6 10:10:22 2026 +0100 KVM: arm64: Correctly handle end of VA space TLBI invalidation commit 34af2c3e31f91a739dc175459fdbd99ed952b457 upstream. Our TLB invalidation by VA code is based on comparing two ranges, one defined by the TLB, and one defined by the TLBI instruction. Each range is defined by a start and a size. However, the way the comparison is done doesn't account for address rollover, as it compares an address with (base + size). This works nicely until this expression represent the last page/block in the TTBR1 VA space, as the result is a big fat 0. And a failed TLB invalidation. Rewrite the comparison in a way that is immune to the address rollover (making the end address inclusive instead of exclusive), and move this into a common helper that is used by both VA and IPA invalidations, as suggested by Hyunwoo Kim (although the IPA version didn't suffer from this particular problem, obviously). Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Reviewed-by: Yuan Yao Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-5-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit be54a70067c7dbe1381157e8a238fa4b16ea9c05 Author: Marc Zyngier Date: Thu Aug 6 10:10:20 2026 +0100 KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation commit 8053393680d4fa3eb962667d2be95dd39f0940e5 upstream. Computing the effects of a TLB invalidation involves looking at the size of the mapping cached by the TLB. For S1 mappings such as VNCR, this is deducted from the combination of the base granule size and the mapping level. However, this implies that the S1 MMU is *on*. When the MMU is off, we indicate this with the level being set to a "creative" value of -127 (S1_MMU_DISABLED). This ends-up being misinterpreted by pgshift_level_to_ttl() as it doesn't handle negative levels at all (the level is immediately cast to a u8 and only the bottom two bits considered), leading to an invalidation size of 0. Not helpful. Tidy-up pgshift_level_to_ttl() to handle these negative levels, and ttl_to_size() to always return SZ_1G when no valid TTL is present. This allows the removal of open-coded checks for similar situations. Note that the check for a negative value not explicitely checking for S1_MMU_DISABLED is deliberate, so that actual negative levels introduced with LVA2 and D128 can take the same path if we ever support them. Fixes: 7270cc9157f47 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers") Reported-by: Hyunwoo Kim Link: https://lore.kernel.org/r/ameGoxbn2wzBq2kL@v4bel Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-3-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 6408605cbd509e6625e4c2145b1467bdd2807e95 Author: Marc Zyngier Date: Thu Aug 6 10:10:21 2026 +0100 KVM: arm64: Consider SCTLR_EL2.M when mapping the L1 VNCR page commit 8c774604b6ecaca495fa3d27c21593269627f48f upstream. We record a VNCR TLB even when SCTLR_EL2.M is 0 in order to make our life easier. But this is not something that the architecture anticipate. As a consequence, a hypervisor is free to set VNCR_EL2 to some PA when SCTLR_EL2.M==0, use it to run a guest which indirectly accesses the VNCR page, then eventually set SCTLR_EL2.M==1 with the same VA. Yes, this is odd, but apparently legal. A common trick in HW is to invalidate the TLBs on SCTLR_ELx.M being flipped. But doing this is a not a good idea for us (we'd need to trap SCTLR accesses), and wouldn't scale as we nest deeper. Instead, use the fact that the S1 MMU being off at the point of translation is cached in our TLB, and if it doesn't match the current MMU state, leave the VNCR unmapped. Fixes: 2a359e072596f ("KVM: arm64: nv: Handle mapping of VNCR_EL2 at EL2") Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-4-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 150c43473dcf02c1b3e1942afaecc538a9e1198c Author: Christian Borntraeger Date: Tue Aug 11 17:37:38 2026 +0200 KVM: s390: Restore sigset on error path commit c44d36d8e6501c4934412d9014e5e02da9efdb8f upstream. kvm_sigset_activate() installs vcpu->sigset via sigprocmask() and stashes the caller's mask in current->real_blocked; only kvm_sigset_deactivate() restores it. For KVM_RUN on a STOPPED vcpu the error path will not restore the userspace mask. Re-arrange the error handling to also restore the signal mask. Fixes: 6352e4d2dd9a3 ("KVM: s390: implement KVM_(S|G)ET_MP_STATE for user space state control") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260811153738.206885-5-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 5ed801685a8a34dfc2745a22157318eb10bdc5d9 Author: Christian Borntraeger Date: Tue Aug 11 17:37:37 2026 +0200 KVM: s390: pv: Fix rc/rrc offset for PVM_DUMP commit 1e3c8e7b3465fb8a49d3623d2d0f449c0b5b48f3 upstream. The rc/rrc value is copied to the cmd location of the cmd in the kvm_pv_cmd structure. Fix the offset. Fixes: 8aba09588d2a ("KVM: s390: Add CPU dump functionality") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260811153738.206885-4-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 6ee52d3af2a1bf70349cf3f860933c8d221e229a Author: Christian Borntraeger Date: Thu Aug 6 16:58:35 2026 +0200 KVM: s390: Fix memory corruption by not reinjecting CK machine checks commit 546dde823a36d7283dcf46127c2f3d093443860f upstream. Channel-subsystem damage machine checks are for the host channel subsystem. The guest channel subsystem is emulated in the userspace VMM. There is no point in forwarding such machine checks into the guest. This also simplifies the machine check reinjection and avoids kfree of a stack variable as reported by sashiko. There might be still machine checks that have the ck bit set with another bit (like instruction damage), mask out the CK bit in s390_backup_mcck_info(), like the CP and ED bits already are. Fixes: 4d62fcc0b692 ("KVM: s390: Inject machine check into the guest") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Acked-by: Heiko Carstens Acked-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260806145835.31818-1-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 3904a3296e40d95918d259f3fe43bf6186aee70e Author: Christian Borntraeger Date: Wed Aug 5 13:04:50 2026 +0200 KVM: s390: Zero initialize irq in reinject_machine_check commit b239410c7653ff6781d4cf1d63cfc52a1bb71788 upstream. kvm_s390_reinject_machine_check() fills cr14, mcic, ext_damage_code and failing_storage_address of the on-stack struct kvm_s390_irq, but struct kvm_s390_mchk_info also has a pad word and a 16 byte fixed_logout array. struct mcck_volatile_info carries no logout data, so there is nothing to copy there and both stay whatever was on the stack. __inject_mchk() then memcpy()s fixed_logout into the vcpu local interrupt state unconditionally. This will reach the guest during deliver and userspace during migration. Reflecting zeroes is the correct behaviour here, as KVM has no logout data for a reinjected machine check. This needs a host machine check while the cpu is in SIE so not trivial to trigger. Fixes: 4d62fcc0b692 ("KVM: s390: Inject machine check into the guest") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-4-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit cc710ee45395efb4937e042960f791d33924e5f6 Author: Christian Borntraeger Date: Wed Aug 5 13:04:53 2026 +0200 KVM: s390: Take srcu when importing watchpoint data commit a4e482def8533ebace517d9f67f1465841b1f982 upstream. __import_wp_info() backs up the original guest memory contents of a watchpoint with read_guest_abs(), which is kvm_read_guest() and therefore resolves the memslot via __kvm_memslots(). That requires kvm->srcu (or kvm->slots_lock) to be held, otherwise a concurrent memslot update can free the memslots array under us once its SRCU grace period has elapsed. As this is not fast path, following lock ordering (mutex first, then srcu) take the big hammer and hold the srcu for the full import. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-7-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit b5acacfdb8966abff91836c1c5bd7da59d8a526e Author: Christian Borntraeger Date: Wed Aug 5 13:04:54 2026 +0200 KVM: s390: Free guest debug data on vcpu destroy commit e7f698b09d4a7c36b299acf680fc50fe868e2bcd upstream. kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-8-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit f55e4d415d95342d5753e528e05a1e8623992c3f Author: Christian Borntraeger Date: Wed Aug 5 13:04:52 2026 +0200 KVM: s390: Fix old_data leak in guest debug error path commit aa9c8e8baf1e765fa65b93212522c636f25d846f upstream. __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-6-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 44bf3792c10f4bb3de507391f1837e020d92eaa2 Author: Christian Borntraeger Date: Wed Aug 5 13:04:51 2026 +0200 KVM: s390: Fix memory leak in guest debug handling commit 121ea1de927c8b9bfdf53c31cad27b86d5de0293 upstream. bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-5-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit beb9c55af609c4c7308259d7191688c75a4e3d4a Author: Christian Borntraeger Date: Wed Aug 5 13:04:55 2026 +0200 KVM: s390: Fix length check __import_wp_info() commit 4c07680a467e2f7697245bcd11691bffb2a6f0ed upstream. struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: wp_info->len = bp_data->len; [...] if (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) return -EINVAL; wp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-9-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 39f7abd5927bf8a53247a43b804401b464bf5785 Author: Sean Christopherson Date: Thu Jul 9 13:49:36 2026 -0700 KVM: x86: Ensure runtime reads of disabled_quirks are resolved once commit ed15cb21999217e549414c128b4a0485debf6278 upstream. Wrap the sole reader of disabled_quirks with READ_ONCE(), and wrap the post-VM-creation write to disabled_quirks with WRITE_ONCE(), to ensure checking the status of a quirk doesn't re-read disabled_quirks *if* the caller needs such a guarantee. This will allow splitting the "fast" MMU zap into front and back halves, without potentially skipping the back half if SLOT_ZAP_ALL were concurrently disabled (which would be "fine" in the current code base, but far from ideal). Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-7-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 929fd2d87851af385df914f4f506ab3a6825b8a2 Author: Sean Christopherson Date: Thu Jul 9 13:49:35 2026 -0700 KVM: x86: Serialize writes to disabled_quirks using kvm->lock commit ba76b23ed36ab230fc2577aba24f65851114902f upstream. Protect writes to disabled_quirks with kvm->lock to ensure KVM doesn't clobber state in the unlikely scenario that userspace disables disparate quirks from multiple tasks. More importantly, this will allow wrapping accesses with {READ,WRITE}_ONCE without "needing" to also guard the writer with a useless and confusing READ_ONCE (since the RMW wouldn't be atomic anyways). Ideally, KVM would disallow disabling quirks once quirks are "live", but that would be a potentially breaking userspace ABI change, and while all existing quirks are fully live only after vCPUs have been created, several MMU-related quirks, IGNORE_GUEST_PAT and SLOT_ZAP_ALL, are partially live at all times. Because populating MMUs requires a vCPU, the guest-visible behavior of IGNORE_GUEST_PAT and SLOT_ZAP_ALL requires a vCPU, but for KVM itself, processing the quirk (or not) has functional impact, i.e. for all intents and purposes, KVM can't prevent those quirks from being disabled after they've been consumed. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-6-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 3097582b73a8ed1cd6f6790fa78706f4a79b5a49 Author: Carlos López Date: Tue Jul 14 15:32:13 2026 +0200 KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock commit 0ca49fbd2883cd53d32d85b50feef17fa04d0fbf upstream. Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d077 R09: 1ffffffff1f87a0e R10: dffffc0000000000 R11: fffffbfff1f87a0f R12: dffffc0000000000 R13: 0000000000000000 R14: ffff8880b8628240 R15: 1ffff92000814e64 hrtimer_start include/linux/hrtimer.h:259 [inline] stimer_start arch/x86/kvm/hyperv.c:682 [inline] kvm_hv_process_stimers+0xd0a/0x16a0 arch/x86/kvm/hyperv.c:893 vcpu_enter_guest arch/x86/kvm/x86.c:11193 [inline] vcpu_run+0x2240/0x76b0 arch/x86/kvm/x86.c:11639 kvm_arch_vcpu_ioctl_run+0x1148/0x1c90 arch/x86/kvm/x86.c:11984 kvm_vcpu_ioctl+0x99a/0xed0 virt/kvm/kvm_main.c:4492 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f635278f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f635365c038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f63529e5fa0 RCX: 00007f635278f749 RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00007f6352813f91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f63529e6038 R14: 00007f63529e5fa0 R15: 00007ffd5b219358 Fix this by clamping the deadline computation to KTIME_MAX, which preserves the intent of arming a timer very far in the future. ktime_add_safe() already does this type of clamping, so use it after checking that that multiplying by the 100ns time tick also does not overflow. Reviewed-by: Vitaly Kuznetsov Reported-by: syzbot+3d5461510f8dc4adfe30@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3d5461510f8dc4adfe30 Fixes: 1f4b34f825e8 ("kvm/x86: Hyper-V SynIC timers") Cc: stable@vger.kernel.org Signed-off-by: Carlos López Link: https://patch.msgid.link/20260714133212.3916611-3-clopez@suse.de [sean: tag for stable] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 41debfc98526c0a95c41a62435aca0a70340a26d Author: Phil Rosenthal Date: Mon Jul 20 13:45:49 2026 -0400 KVM: x86/mmu: Consume the locked rmap value in the lockless rmap walk commit e428f9779a43737d830111238816f1928b07aefb upstream. __kvm_rmap_lock() deliberately elides the rmap lock when it observes an empty rmap. In that case kvm_rmap_lock_readonly() also re-enables preemption and returns zero, so the caller holds neither the rmap lock nor a preemption reference. The elision documents the invariant it relies on: * Elide the lock if the rmap is empty, as lockless walkers (read-only * mode) don't need to (and can't) walk an empty rmap, nor can they add * entries to the rmap. I.e. the only paths that process empty rmaps * do so while holding mmu_lock for write, and are mutually exclusive. kvm_rmap_age_gfn_range() ignores the returned value and unconditionally enters for_each_rmap_spte_lockless(). The iterator started with rmap_get_first(), which re-reads rmap_head->val rather than using the value returned by the lock. If a writer populates the rmap between the lock's read and the iterator's re-read, the aging path walks the newly installed rmap without holding its lock. For a KVM_RMAP_MANY rmap this leaves the walker following a pte_list_desc chain that it never locked. A writer holding mmu_lock for write may free that chain (e.g. kvm_zap_all_rmap_sptes() on the recycle path, or any rmap zap) via kmem_cache_free() while the walk is in progress, giving a slab use-after-free. Nothing serialises the two: the aging path runs without mmu_lock when CONFIG_KVM_MMU_LOCKLESS_AGING=y, and the rmap lock that would otherwise exclude the writer was elided. Because the empty path re-enables preemption, the interval between the two reads can span an arbitrary scheduling delay. Fix the class of bug by having the lockless walk consume the value returned by the lock instead of re-reading the rmap. Split rmap_get_first() into __rmap_get_first(), which starts an iterator from an already-read rmap value, and make for_each_rmap_spte_lockless() take that value and call __rmap_get_first() directly. kvm_rmap_age_gfn_range() passes the value returned by kvm_rmap_lock_readonly(): when the lock was elided the value is zero, __rmap_get_first() returns NULL, and the walk is skipped. No lockless walker re-reads the rmap, so the lock-elision invariant cannot be violated, and no lock()-without-paired-unlock() path is added to the aging code. Fixes: af3b6a9eba48 ("KVM: x86/mmu: Walk rmaps (shadow MMU) without holding mmu_lock when aging gfns") Suggested-by: Sean Christopherson Cc: stable@vger.kernel.org Signed-off-by: Phil Rosenthal Link: https://patch.msgid.link/20260720-rmap-age-elided-submit-v2-1-668973030d47@phil.gs Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 7b2721d66525fda5dd2b9f7547e7f0eea7efc8c1 Author: Sean Christopherson Date: Thu Jul 9 13:49:39 2026 -0700 KVM: x86/mmu: Use split "zap all fast" helpers when invalidating memslot commit db095727ff5739f4f46ee641ee6ef450032886db upstream. Manually invoke the front half and back half of the "zap all fast" flow when invalidating a memslot so that mmu_lock is acquired at function scope in kvm_arch_flush_shadow_memslot(). This will allow putting more code inside the critical section without having to take mmu_lock twice in quick succession. Opportunistically open code checking whether or not to do the fast zap, to discourage removing the local "zap_all" in a future cleanup, i.e. to ensure the SLOT_ZAP_ALL quirk is queried exactly once. Processing the front half but not the back half of the fast zap (if SLOT_ZAP_ALL were disabled concurrently) would result in KVM unnecessarily keeping invalid TDP MMU roots until the VM is destroyed. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-10-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 0a25ee42e7d1a9bff2355884d43677f3eaff3d4a Author: Sean Christopherson Date: Mon Jul 27 17:22:35 2026 -0700 KVM: x86/mmu: Use CMPXCHG when clearing Accessed bit in TDP MMU commit 3d679b7cb31f74bf2303123ce4ee3266eeee999a upstream. Use LOCK CMPXCHG instead of LOCK AND to clear the Accessed bit when aging SPTEs in the TDP MMU, as doing a LOCK AND can corrupt a FROZEN SPTE and allow a third CPU to effectively overwrite the FROZEN SPTE. As pointed out by AI of some kind, because the magic FROZEN_SPTE value is a "full" SPTE, not a single bit, and includes the Accessed bit, clearing the Accessed bit in a FROZEN SPTE will result in is_frozen_spte() getting a false negative. E.g. if CPU0 freezes an SPTE, and CPU1 clears the Accessed bit in the frozen SPTE, then CPU2 could come along and overwrite the frozen SPTE with a shadow-present SPTE. Thankfully, the false negative is largely benign, because outside of TDX, which doesn't support aging, KVM only freezes leaf SPTEs when removing an upper level shadow page. So while KVM could clobber a frozen SPTE back to a shadow-present SPTE, and could even use the new SPTE, the subsequent TLB flush will make the orphaned, shadow-present SPTE unreachable. Failure to ever zap the orphaned leaf SPTE would show up in KVM's stats, but otherwise is benign (because KVM no longer keeps an elevated refcount for leaf SPTEs). Opportunistically add a comment to warn future developers away from using kvm_tdp_mmu_write_spte_atomic() and tdp_mmu_clear_spte_bits_atomic(), as they are generally unsafe. Keep the helpers, e.g. instead of open-coding the atomic64_fetch_and() in tdp_mmu_clear_spte_bits(), as scary warnings usually are more effective deterrent against recidivism than removal of the dangerous code. Alternatively, KVM could use different bits for the magic FROZEN_SPTE value, e.g. setting the Dirty bits (with effective IPAT and Global aliases) would likely be "ok", as IPAT/Global are extremely unlikely to be cleared without doing a full SPTE write, and KVM's clearing of Dirty bits shares logic with Write-Protection, which must do a full SPTE write (via cmpxchg64() in the TDP MMU) to ensure KVM isn't clobbering state. But there is zero reason to carry that risk (beyond stubbornness in wanting to preserve a "cute" idea), as the cost of LOCK CMPXCHG and LOCK AND are within 1-2 uops of each other on modern hardware. Fixes: b146a9b34aed ("KVM: x86/mmu: Age TDP MMU SPTEs without holding mmu_lock") Cc: stable@vger.kernel.org Reviewed-by: Kai Huang Reviewed-by: James Houghton Link: https://patch.msgid.link/20260728002236.869865-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit e29e9a9d81140f52df69bf9faf5b0f80de0eb224 Author: Sean Christopherson Date: Thu Jul 9 13:49:38 2026 -0700 KVM: x86/mmu: Split kvm_mmu_zap_all_fast() into "front" and "back" halves commit b27622c4eeb125814081baaefe9175191be5b94d upstream. Split kvm_mmu_zap_all_fast() into a "front half" and a "back half", where the front half is everything that runs with mmu_lock held for write, and the back half is the code that runs outside of mmu_lock. This will allow putting more code inside kvm_arch_flush_shadow_memslot()'s critical section without having to take mmu_lock twice in quick succession. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-9-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 93b7f6eb76a134f80f904d1981f0ca063d84ca0e Author: Sean Christopherson Date: Thu Jul 9 13:49:37 2026 -0700 KVM: x86/mmu: Fold kvm_mmu_zap_memslot() into kvm_arch_flush_shadow_memslot() commit 06d38eaa78fdac1cc889f261fa420eba8e9caa1a upstream. Fold kvm_mmu_zap_memslot() into its sole caller so that its GFN range structure can be used to trigger guest_memfd invalidations regardless of whether KVM will do a partial or full zap of the MMU. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-8-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 27bdeb5fd19046ffba9ff234e92fe553eb2efb30 Author: Yosry Ahmed Date: Tue Jun 16 21:46:52 2026 +0000 KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU commit 6d00e67326d831e6e610933a3800712f4ffe6ec1 upstream. When emulating INVVPID, KVM executes INVVPID on the physical CPU using vpid02 (instead of the L1 assigned VPID), after doing some validations on the operands. However, it is possible that the physical CPU KVM executes INVVPID on is different from the CPU L2 is running on. For example, in the following scenario: - L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1) - L1 migrates to CPU #2 and executes INVVPID - KVM executes INVVPID on CPU #2 - L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02.cpu=1) The TLB entries on CPU #1 are never invalidated, because INVVPID was executed on CPU #2, and vmcs02 never ran on a different pCPU (i.e. vmx_vcpu_load_vmcs() will *not* request KVM_REQ_TLB_FLUSH). Ensure that INVVPID is being executed on the same pCPU that L2 last ran on, and if not, fallback to clearing last_vpid=0 to trigger a full VPID flush on the next nested VM-Enter (as KVM will detect L1 using a different VPID for L2). If L2 ends up running on a different pCPU, KVM will flush the TLB anyway through vmx_vcpu_load_vmcs(). Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Reviewed-by: Kai Huang Link: https://patch.msgid.link/20260616214652.2157032-4-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit c43563e7518e65ec6ccaa6a65f84c5af5ca5d379 Author: Yosry Ahmed Date: Wed Jul 22 23:01:28 2026 +0000 KVM: nVMX: Service local TLB flushes on failed nested VM-Enter commit 05a0b701d1089fb57beeb8982f23c3bbafe0fa8b upstream. KVM services local TLB flushes on "full" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated. Fixes: 5c614b3583e7 ("KVM: nVMX: nested VPID emulation") Cc: stable@vger.kernel.org Reported-by: Sashiko # Internal review Suggested-by: Sean Christopherson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260722230128.1587363-1-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 674a3244f07f323f21a106a7bdcaebb6db6a5058 Author: Sean Christopherson Date: Thu Jul 23 17:47:52 2026 -0700 KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit commit 11722439fb206c88e6f31be54173efa9880b4ccb upstream. Always check and clear KVM_REQ_GET_NESTED_STATE_PAGES when emulating a nested VM-Exit to ensure the request is cleared, even when KVM was built with CONFIG_KVM_HYPERV=n, as KVM subtly relies on the "check" to clear the flag and thus avoid double-mapping the vmcs12 pages, e.g. if KVM manages to bail from VM-Enter without processing the request, and then emulates VMLAUNCH or VMRESUME. Fixes: b4f69df0f65e ("KVM: x86: Make Hyper-V emulation optional") Cc: stable@vger.kernel.org Reported-by: Yosry Ahmed Reviewed-by: Yosry Ahmed Link: https://patch.msgid.link/20260724004757.131420-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit d689dd4eae48d5a7d91ec3e0dea108c37c1cd899 Author: Sean Christopherson Date: Tue Jun 16 21:46:51 2026 +0000 KVM: nVMX: Decouple INVVPID operand checks from flushing of vpid02 commit 32912404b4b1ee98400744941c78f019a63d6e8f upstream. Separate the INVVPID operand checks from the actual flushing of vpid02 so the flushing can be adjusted to do the right thing when vmcs02 was last loaded on a different pCPU, without having to duplicate the logic across multiple case-statements. Opportunistically let the VM-Fail paths poke out past 80 chars. No functional change intended. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Reviewed-by: Kai Huang Link: https://patch.msgid.link/20260616214652.2157032-3-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 22dfcc22c95e91295119a1c3b469816ce44c4804 Author: Yosry Ahmed Date: Tue Jun 16 21:46:50 2026 +0000 KVM: nVMX: Always flush vpid02 on first use commit f0772389413dce9657c7d6950abf3edbbd511356 upstream. Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Reviewed-by: Kai Huang Reviewed-by: Jim Mattson Link: https://patch.msgid.link/20260616214652.2157032-2-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 5778dda871f15afc0ee56dcc6a28c157b329bb2e Author: Amit Machhiwal Date: Tue Jul 14 23:24:32 2026 +0530 KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode commit 884ea0283f4effac97ee8f451464a7d1be480d7c upstream. On IBM POWER systems, newer processor generations can operate in compatibility modes corresponding to earlier generations. This becomes relevant for nested virtualization, where nested KVM guests may need to run with a specific processor compatibility level. Currently, when running a nested KVM guest (L2) inside a Power11 pSeries logical partition (L1) booted in Power10 compatibility mode, the guest fails to boot while setting 'arch_compat'. This happens because the CPU class is derived from the hardware PVR (via mfspr()), which reflects the physical processor generation (Power11), rather than the effective compatibility mode (Power10). As a result, userspace may request a Power11 arch_compat for the L2 guest. However, the L1 partition, running in Power10 compatibility, has only negotiated support up to Power10 with the Power Hypervisor (L0). When H_GUEST_SET_STATE is invoked with a Power11 Logical PVR, the hypervisor rejects the request, leading to a late guest boot failure: KVM-NESTEDv2: couldn't set guest wide elements [..KVM reg dump..] This situation should be detected earlier and rejected by KVM. Without proper validation, if userspace ignores the error, the guest may continue to boot in Power11 raw mode on a Power10 compatibility host, which should not be allowed. Introduce a validation mechanism that detects unsupported arch_compat values early in the guest initialization path. When an unsupported arch_compat is requested (e.g., Power11 on a Power10 compatibility mode host), kvmppc_set_arch_compat() uses cpu_has_feature(CPU_FTR_P11_PVR) to detect the mismatch and sets arch_compat to PVR_ARCH_INVALID (0xffffffff). This sentinel value is architecturally safe: PAPR specifies that valid logical PVR values must have 0x0f as the first byte, ensuring 0xffffffff lies permanently outside the specification-defined range. Setting this value triggers kvmppc_sanity_check() to mark the vCPU as invalid by setting vcpu->arch.sane to false. On the next vCPU run, kvmppc_vcpu_run_hv() checks this flag and returns -EINVAL, preventing the guest from running with an invalid processor compatibility configuration. With this, when a Power11 arch_compat is requested on a Power10 compatibility mode host, the guest fails early during boot with: error: kvm run failed Invalid argument This provides a much clearer failure mode compared to the previous behavior where the guest could boot in Power11 raw mode (if userspace ignored the error) or fail late during H_GUEST_SET_STATE. Suggested-by: Vaibhav Jain Reviewed-by: Vaibhav Jain Tested-by: Anushree Mathur Acked-by: Gautam Menghani Cc: stable@vger.kernel.org # v6.13+ Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Amit Machhiwal Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260714175432.86388-1-amachhiw@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit c9f2c50bad37d573ef7d2a02e576b6c01fcccd92 Author: Nikhil Gautam Date: Tue Jul 14 17:01:34 2026 +0530 iio: light: opt4001: Fix reversed GENMASK() arguments in fault count mask commit d64bfd9f3352b9d9bdeca06de1a0a1c1bd47b896 upstream. GENMASK(h, l) requires h >= l, but OPT4001_CTRL_FAULT_COUNT is defined as GENMASK(0, 1). The define is currently unused so there is no functional impact, but fix it before anyone builds on it, and add the _MASK suffix for consistency with the neighbouring definitions. Fixes: 9a9608418292 ("iio: light: Add support for TI OPT4001 light sensor") Signed-off-by: Nikhil Gautam Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b6cedf011bd95c752a1dc7bed3be38bd08494221 Author: Nikhil Gautam Date: Tue Jul 14 17:01:33 2026 +0530 iio: light: opt4001: Reject integration times with a non-zero seconds part commit d0f21621f8b2b46661ea066d20705dbf7253db87 upstream. opt4001_write_raw() only looks at val2 when setting the integration time, so a write such as 1.000600 is silently accepted as 600 us. Return -EINVAL if val is non-zero. Fixes: 9a9608418292 ("iio: light: Add support for TI OPT4001 light sensor") Signed-off-by: Nikhil Gautam Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 958d691403936ed317eecb7f9461025d1a1093c6 Author: Nikhil Gautam Date: Tue Jul 14 17:01:32 2026 +0530 iio: light: opt4001: Fix incompatible pointer type passed to div_u64_rem() commit afa28741c9a2cf6edb2e41e25ff146a562160bb3 upstream. div_u64_rem() takes a u32 * for the remainder but is passed val2, which is an int *. There is no functional impact as int and u32 have the same size and representation on all supported architectures and the remainder is always smaller than the divisor, so it fits in the positive range of int. Fix the type mismatch by using a local u32 for the remainder and assigning the result to *val2. Fixes: 9a9608418292 ("iio: light: Add support for TI OPT4001 light sensor") Signed-off-by: Nikhil Gautam Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4a9820aa8ef7e86774152f410d2774e89bc99636 Author: Nikhil Gautam Date: Tue Jul 14 17:01:31 2026 +0530 iio: light: opt4001: Fix power down clearing bits of the wrong register commit 3b2cd82c524c75a2173f2e3f874652a75f81cd1d upstream. opt4001_power_down() intends to clear the operating mode bits in the CTRL register but reads OPT4001_DEVICE_ID instead of OPT4001_CTRL, so the value written back to CTRL contains device ID bits rather than the current configuration. Fix and simplify this by using regmap_clear_bits() on the CTRL register directly in the devm action, and drop opt4001_power_down() which has no other users. Suggested-by: Jonathan Cameron Fixes: 9a9608418292 ("iio: light: Add support for TI OPT4001 light sensor") Signed-off-by: Nikhil Gautam Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6d00b4fec5bf2f8c57d6bf2257d5f8598e0d9264 Author: Vidhu Sarwal Date: Wed Jul 15 06:45:44 2026 +0530 iio: light: opt4060: Fix incorrect register name in threshold read error message commit ad367638212a9f2495ecfa59c886f0cfb7934e9c upstream. opt4060_get_thresholds() correctly reads OPT4060_THRESHOLD_HIGH, but logs "Failed to read THRESHOLD_LOW." if the read fails. This is a copy-and-paste mistake, as the preceding low-threshold read already uses the correct error message. Update the error message to reference OPT4060_THRESHOLD_HIGH. Fixes: 0c6db4506ad0 ("iio: light: Add support for TI OPT4060 color sensor") Signed-off-by: Vidhu Sarwal Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 38f58a02496667d17e1312782d6bc3c2f756bd64 Author: Vidhu Sarwal Date: Wed Jul 15 06:45:42 2026 +0530 iio: light: opt4060: Reject integration times with a non-zero seconds part commit b7e6e9af0d723afdec92364d5e7e064eeef44c8e upstream. When setting the integration time, opt4060_write_raw() only uses val2 and ignores val. As a result, a write such as 1.000600 is accepted and programmed as 600 us, silently discarding the whole seconds part. Since all supported integration times are less than one second, any non-zero val represents an invalid input. Reject such values instead of silently accepting them. Fixes: 0c6db4506ad0 ("iio: light: Add support for TI OPT4060 color sensor") Signed-off-by: Vidhu Sarwal Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit fcddb4da54ab94bb2fc6c45447ec4a940e6e6bd6 Author: Paul Geurts Date: Mon Jul 6 09:48:03 2026 +0200 iio: ti-ads7138: Disable STATS_EN bit while reading conversion results commit bcb721c1bcb02ab225b3937bf131a0bc6fc1fecd upstream. There is a data race in reading the STATS registers, resulting in wrong data being read. When the data in the RECENT register switches between 0x24F0 and 0x2500, occasionally value 0x2400 or 0x25F0 is read. This happens when the value is updated in between reading MSB and LSB. The data sheet says: "Until a new conversion result is available, previous values can be read from the statistics registers. Before reading the statistics registers, set STATS_EN to 0 to prevent any updates to this register block." As the STATS_EN is currently not cleared, the values of the stats registers might change mid read, giving faulty values. Disable the STATS_EN bit before reading one of the statistics registers to make sure the device does not update the register mid read. This is applicable to registers MAX_CHn_xSB, MIN_CHn_xSB and RECENT_CHn_xSB. This means reading one of the statistics registers resets the MAX and MIN registers. This is unfortunate, but necessary to get correct data from the device. Signed-off-by: Paul Geurts Fixes: 024b08fee342 ("iio: adc: Add driver for ADS7128 / ADS7138") Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c0d491c243e70e80fb887b6900fb462be11592ef Author: Sanjay Chitroda Date: Thu Jun 25 17:46:11 2026 +0530 iio: temperature: hid-sensor-temperature: switch to non-devm iio_device_register() commit 967d066f5334740f656577bc51c381a1bb707b61 upstream. Avoid using devm_iio_device_register(), as this driver requires explicit error handling and teardown ordering. With devm_iio_device_register(), IIO device remains registered until the devres cleanup phase. However, driver's remove() callback removes the sensor hub callback and trigger support. This can create a race window where IIO device is still visible and read_raw() requests are issued. These requests might call sensor_hub_input_attr_get_raw_value(), which waits up to 5 seconds for a response from the sensor hub callback that has already been removed. Add an explicit iio_device_unregister() call in the teardown path to ensure deterministic cleanup, so that userspace can no longer access the device once backend resources begin to be dismantled. Fixes: 59d0f2da3569 ("iio: hid: Add temperature sensor support") Cc: stable@vger.kernel.org Reviewed-by: Maxwell Doose Reviewed-by: Andy Shevchenko Signed-off-by: Sanjay Chitroda Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c2d6437663d7c33132956c09f0150104dce111d0 Author: Cong Nguyen Date: Mon Jul 27 22:51:15 2026 +0700 iio: srf04: fix pm_runtime handling on probe error path commit a40b2e7a17f26e38ab054363c9c7cde149588357 upstream. When pm_runtime_set_active() fails during probe, the driver logs the error and unregisters the IIO device, but then falls through and still calls pm_runtime_enable() before returning the error. Since probe returns an error, srf04_remove() is never called, so runtime PM is left enabled without a matching pm_runtime_disable(). This leaks the enable and triggers an "Unbalanced pm_runtime_enable!" warning on a subsequent bind of the device. Return the error right after unregistering the IIO device so that runtime PM is not enabled on the failure path. Fixes: 2251157b335b ("iio: srf04: add power management feature") Cc: stable@vger.kernel.org Signed-off-by: Cong Nguyen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit eef652190b00f68a46215c24004378b083e00dd6 Author: Can Peng Date: Mon Jul 20 10:43:12 2026 +0800 iio: pressure: mpl115: Fix runtime PM cleanup commit 0b5e142ced4bcf20532da051934bd694d1bbd470 upstream. mpl115_probe() enables runtime PM when a shutdown GPIO is present and then returns the result of devm_iio_device_register(). If registration fails, runtime PM remains enabled and autosuspend remains selected. The same unmanaged runtime PM state is also left behind on driver unbind, as the IIO device registration is managed but the runtime PM setup is not. Use devm_pm_runtime_enable() so runtime PM is disabled automatically on probe failure and driver unbind, and check pm_runtime_set_active() so setup errors are reported. Set the autosuspend parameters before enabling runtime PM. Once probe has completed, the driver core queues an idle request for the device, so an explicit pm_runtime_get_noresume()/pm_runtime_put() pair is not needed to start autosuspend. Fixes: 0c3a333524a3 ("iio: pressure: mpl115: Implementing low power mode by shutdown gpio") Cc: stable@vger.kernel.org Suggested-by: jonathan.cameron@oss.qualcomm.com Signed-off-by: Can Peng Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7ded5b76ec2df6a3fb1bfde0d1869cde363fef30 Author: Rupesh Majhi Date: Sun Jul 19 03:07:52 2026 +0300 iio: pressure: dps310: fix NULL pointer dereference on ACPI probe commit 26e9213898fc949923188ef0aeea31fc87708836 upstream. When the device is enumerated through its ACPI HID (IFX3100), i2c_client_get_device_id() returns NULL: the ACPI-derived client name does not match the driver's i2c_device_id table. dps310_probe() then dereferences that NULL pointer in "iio->name = id->name" and crashes the kernel during probe. The IIO device name is always "dps310", so set it directly and drop the now-unused device-id lookup. Fixes: 72ff282819d0 ("iio: pressure: dps310: Add ACPI HID table") Cc: stable@vger.kernel.org Signed-off-by: Rupesh Majhi Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0614928a3eda35bddd8c2f02311e286b59bbe746 Author: Vidhu Sarwal Date: Mon Jul 13 07:58:29 2026 +0530 iio: light: ltrf216a: fix runtime PM reference leak in error path commit c132aef0e757a39036b1d40faf0569f2e343b13e upstream. ltrf216a_get_lux() acquires a runtime PM reference by calling ltrf216a_set_power_state(data, true). However, if ltrf216a_read_data() fails, the function returns immediately without dropping the reference. This leaves the runtime PM usage count unbalanced, preventing the device from autosuspending after a failed read. Fix this by releasing the runtime PM reference before returning from the error path. Fixes: 83f0bcd40d5c ("iio: light: Add support for ltrf216a sensor") Signed-off-by: Vidhu Sarwal Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 1ce47f00e9c00b93714831b5468eed3d64dd7032 Author: Laxman Acharya Padhya Date: Sat Jul 4 14:19:12 2026 +0545 iio: light: gp2ap002: Disable regulators on resume failure commit a41000ba3a230bed1e422f283486ff8f77fe0d30 upstream. If enabling VIO fails after VDD has been enabled, runtime resume returns without disabling VDD. Likewise, if device reinitialization fails, both supplies remain enabled. The runtime PM core keeps the device suspended when its resume callback fails, so the supplies must be restored to the suspended state. Disable the supplies enabled by the callback before returning an error. Fixes: 97d642e23037 ("iio: light: Add a driver for Sharp GP2AP002x00F") Assisted-by: Codex:gpt-5 Signed-off-by: Laxman Acharya Padhya Reviewed-by: Linus Walleij Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9c1b74fdcffa461ba801580a187e42cbb3bedac8 Author: Giorgi Tchankvetadze Date: Fri Jul 31 17:20:48 2026 +0400 iio: light: cm32181: return zero after writing calibscale commit 8756acd30919a3e9f547ea4a1d4b7f7895f4d340 upstream. The write_raw callback is documented to return 0 on success or a negative error code. However, the IIO_CHAN_INFO_CALIBSCALE case returns 'val' (the user-supplied value) instead of 0. Fix it by returning 0 on success, matching the behavior of other calibscale implementations in the subsystem. Fixes: 971672c0b3cc ("iio: add Capella CM32181 ambient light sensor driver.") Signed-off-by: Giorgi Tchankvetadze Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d2b32b71fa5bdaba3711d966faa4c93e3d7e84a2 Author: Cong Nguyen Date: Sun Aug 2 13:55:40 2026 +0700 iio: gyro: mpu3050: fix sign of raw angular velocity readings commit 06fab97602fe400bea843176f485bbac07a668e2 upstream. The MPU-3050 gyroscope output registers hold 16-bit two's complement values; the angular velocity channels are declared with .sign = 's'. When mpu3050_read_raw() handles IIO_CHAN_INFO_RAW it reads the register via a big-endian regmap_bulk_read() and assigns it with: *val = be16_to_cpu(raw_val); be16_to_cpu() yields an unsigned 16-bit quantity, so negative rates (bit 15 set) are reported to userspace as large positive integers (e.g. -1 becomes 65535) instead of the correct negative value. Cast to s16 before the assignment, matching the temperature channel a few lines above which already handles the sign correctly. Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Reviewed-by: Linus Walleij Reviewed-by: Joshua Crofts Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 08ac8d2976d57aa943d64e351c4d0bd8bb0c6de9 Author: Erick Henrique Date: Fri Jul 3 17:52:36 2026 -0300 iio: dac: m62332: Fix regulator reference count imbalance commit a130404ce0b69ca1438126bd81c1985d3b4d2e6f upstream. m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails. Fixes: b87b0c0f81e8 ("iio: add m62332 DAC driver") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260418130322.106769-1-erick.henrique.rodrigues%40usp.br Cc: stable@vger.kernel.org Signed-off-by: Erick Henrique Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit bcc324f3033cd3e6e789b0ee10d934ea335991d9 Author: Babanpreet Singh Date: Sat Jul 18 18:22:36 2026 +0000 iio: dac: ad3552r-hs: fix scnprintf() buffer bound in data source show commit f2c5c76306fadb834dd5ea76cab0b7cd447e6035 upstream. ad3552r_hs_show_data_source_avail() formats the available data source names into a 128-byte stack buffer, but bounds each scnprintf() with PAGE_SIZE instead of the buffer size, so the bound does not protect the destination at all. This cannot overflow today - dbgfs_attr_source[] has two entries, "normal" and "ramp-16bit", 18 bytes formatted - but the bound stops protecting the stack the day the table grows. Use sizeof(buf) so the bound matches the destination. Found by smatch: drivers/iio/dac/ad3552r-hs.c:593 ad3552r_hs_show_data_source_avail() error: scnprintf() 'buf[len]' too small (128 vs 4096) Fixes: b1c5d68ea66e ("iio: dac: ad3552r-hs: add support for internal ramp") Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Babanpreet Singh Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2d386efb4c37a50739db19c7c8e49564fd53a570 Author: Linmao Li Date: Wed Jul 22 15:48:37 2026 +0800 iio: chemical: sgp30: Handle IAQ thread creation failure commit 1135d6875d2dbda3f6ec718f3421a6ce4378bd63 upstream. kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead. Fixes: ce514124161a ("iio: chemical: sgp30: Support Sensirion SGP30/SGPC3 sensors") Signed-off-by: Linmao Li Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2071624c3d0f497ca91da78858e6f30d7112fea6 Author: Fan Wu Date: Sun Aug 2 07:18:58 2026 +0000 iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF commit be61c8c6252671ecf1fee0ad90f87669e0be1e20 upstream. The atlas driver requests its hardware data-ready IRQ with devm_request_threaded_irq(); its threaded handler queues an irq_work, atlas_work_handler(), that calls iio_trigger_poll(data->trig). The IRQ is devm-managed, so free_irq() runs from the devres unwind after atlas_remove() returns without flushing that irq_work. Once a buffer is enabled, conversion-complete IRQs keep firing and queueing it; a pending irq_work can therefore run after the unwind has freed atlas_data/indio_dev and the trigger, when atlas_work_handler() derives the atlas_data pointer via container_of() and dereferences data->trig, a use-after-free. Call iio_trigger_poll_nested() directly from the threaded handler instead of bouncing through irq_work. free_irq() then drains the threaded handler, closing the window; other iio drivers with a threaded data-ready IRQ do the same (e.g. bmi270). This issue was found by an in-house static analysis tool. Fixes: 7103b99b031c ("iio: chemical: atlas-ph-sensor: reorg driver to allow multiple chips") Cc: stable@vger.kernel.org # v6.4+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 43bce901047e95bbf8fb63eb471460642e497604 Author: Moksh Panicker Date: Mon Jul 13 03:00:46 2026 +0000 iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable commit bcd3f72e26314edfce7eaf8d7160b3119c7b7fed upstream. atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference. Fixes: 0e4f336f50de ("iio: chemical: atlas-sensor: Balance runtime pm + pm_runtime_resume_and_get()") Cc: stable@vger.kernel.org Signed-off-by: Moksh Panicker Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 510497e31be4f241103507315a859e2085ccb081 Author: Lars-Peter Clausen Date: Wed Jul 15 08:42:44 2026 -0700 iio: buffer: Tie IIO dma fence lock lifetime to the fence commit f25ec4627d935dedfb5fe83bd2c2678cdcc19611 upstream. The `iio_dma_fence` implementation currently uses a lock embedded in the `iio_dmabuf_priv`. But the `iio_dma_fence` can outlive the `iio_dmabuf_priv`, which can cause a use-after-free. Tie the lifetime of the lock to the lifetime of the fence by embedding them in the same struct. We can't just hold a reference to the `iio_dmabuf_priv` from the `iio_dma_fence` since `iio_buffer_dmabuf_release()` might sleep and the fence release callback is not allowed to sleep. Note that the `dma_fence` framework now has an internal lock that gets used when the passing `NULL` for `lock` in `dma_fence_init()`, but in order to allow this patch to be backportable use an external lock. Reported-by: codex:gpt-5.6 Fixes: 3e26d9f08fbe ("iio: core: Add new DMABUF interface infrastructure") Signed-off-by: Lars-Peter Clausen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 06a9460b8b792e109cbc934a856d02e5cff217ef Author: Lars-Peter Clausen Date: Wed Jul 15 08:42:45 2026 -0700 iio: buffer: Make IIO DMA fence release RCU-safe commit 8662e56c31cf23b61ca3d11b516efb94c35b8026 upstream. The `dma_fence` documentation states that if a custom release implementation is provided, the `dma_fence` object must be freed in an RCU-safe way. The current `iio_dma_fence` implementation uses `kfree()`, which might result in a use-after-free. Remove the custom `release` implementation. This makes the DMA fence core fall back to `dma_fence_free()`, which calls `kfree_rcu()` on the fence. This requires that the fence be the first member of `struct iio_dma_fence`. Using the default release method for extended DMA fence structures is a common pattern. Reported-by: codex:gpt-5.6 Fixes: 3e26d9f08fbe ("iio: core: Add new DMABUF interface infrastructure") Signed-off-by: Lars-Peter Clausen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f1f8f0e8e0af9cae8150658dc7bb51332f984893 Author: Lars-Peter Clausen Date: Wed Jul 15 08:42:43 2026 -0700 iio: buffer: Fix potential use-after-free in anonymous buffer release commit 6288b593e76eb10329326f2cd51e32557203b9e5 upstream. An anonymous buffer handle holds a reference to the underlying IIO device. The reference is dropped in the buffer handle's release function. If the device has been removed, either through unbind or hot-unplug, the buffer handle might hold the last reference. The release function takes the mutex for the buffer using a guard, which means the unlock happens after all the code in the function, including `iio_device_put()`. If the anonymous buffer holds the last reference this might free both the IIO device and the buffer, which contains the mutex, leading to use-after-free when the mutex is unlocked. Fix this by using a scoped guard just around the buffer dmabuf list access, making sure the mutex is unlocked before releasing the IIO device. Version 10 of the patch that introduced this issue used this exact scheme of first unlocking and then dropping the reference [1]. During review it was suggested to use a guard instead, and version 11 made that change [2]. Reported-by: codex:gpt-5.6 Fixes: 3e26d9f08fbe ("iio: core: Add new DMABUF interface infrastructure") Signed-off-by: Lars-Peter Clausen Link: https://lore.kernel.org/linux-iio/20240605110845.86740-4-paul@crapouillou.net #[1] Link: https://lore.kernel.org/linux-iio/20240618100302.72886-4-paul@crapouillou.net #[2] Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8de90e0e0f6d99f086f79683868c806bba8b183d Author: Cong Nguyen Date: Sun Aug 2 14:12:46 2026 +0700 iio: adc: pac1921: fix wrong channel used in trigger handler read commit 3364c56b20c1c496bdb8c8df32f96a9947dbf98e upstream. pac1921_trigger_handler() walks the enabled channels with iio_for_each_active_channel(), which yields the scan index (bit) of each active channel, while ch is a separate counter used to pack the samples contiguously into the scan buffer. The register to read was looked up with the packing counter instead of the scan index: ret = pac1921_read_res(priv, idev->channels[ch].address, &val); pac1921_channels[] is ordered by scan index, so channels[bit] is the channel that is actually enabled, whereas channels[ch] is merely the ch-th array entry. These coincide only when the enabled channels form a contiguous prefix (e.g. all channels enabled). With a sparse scan mask - for example when only the power channel (scan index 3) is enabled - the handler reads the wrong register (VBUS instead of VPOWER) and pushes it to userspace as the enabled channel's data. Index the channel array by the scan index (bit) to read the correct register, keeping ch only for contiguous packing into the scan buffer. Fixes: 371f778b83cd ("iio: adc: add support for pac1921") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Acked-by: Matteo Martelli Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit beec14368c943a1d87d63381d1706b50965b3150 Author: Joshua Crofts Date: Wed Jul 8 07:34:13 2026 +0200 iio: adc: max34408: add missing 'select REGMAP_I2C' to Kconfig commit 947f1079074a260ba200419d5cba6b8549d5ac0c upstream. The Kconfig entry for the MAX34408 is missing a 'select REGMAP_I2C', causing build failures. Fixes: cf27775838c5 ("iio: adc: Add driver support for MAX34408/9") Cc: stable@vger.kernel.org Signed-off-by: Joshua Crofts Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d2ed166c901e954f85518062cdf3080539ae23e3 Author: Antoniu Miclaus Date: Mon Jul 13 11:40:42 2026 +0300 iio: adc: adi-axi-adc: add data size support for AD408X backend commit 60f6f7fd5f89c7f55991c5dc59f3ccc74cd6efd7 upstream. The AD408X AXI core can pack the sample data on the bus using different word widths. Expose this through the data_size_set backend operation so that frontends can program the packet format field (bits 3:2 of the CNTRL_3 register) according to the ADC resolution: 20-bit, 16-bit and 14-bit map to packet format values 0, 1 and 2 respectively. Signed-off-by: Antoniu Miclaus Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e9627244ac0d737efef54459f45d42269a886380 Author: WenTao Liang Date: Sat Jun 27 11:52:51 2026 +0800 ASoC: samsung: aries_audio_probe: double of_node_put due to direct assignment without of_node_get commit fb5d1b1c5f8a920ee697545fa6dee16825085717 upstream. In aries_audio_probe(), aries_dai[0].platforms->of_node is assigned the same pointer as aries_dai[0].cpus->of_node (from of_parse_phandle) without calling of_node_get(). When the sound card is deregistered, the ASoC framework calls of_node_put() on both cpus->of_node and platforms->of_node, causing a double put on the same node and a refcount underflow. Add of_node_get(aries_dai[0].cpus->of_node) before the assignment. Cc: stable@vger.kernel.org Fixes: 7a3a7671fa6c ("ASoC: samsung: Add driver for Aries boards") Signed-off-by: WenTao Liang Link: https://patch.msgid.link/20260627035251.60172-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4e580d84a638f007b5b68d50d7633de502f325e7 Author: Binbin Zhou Date: Fri Jun 26 10:27:03 2026 +0800 ASoC: loongson: Fix error handling in ACPI property parsing commit 0eb0e3c623ac1da8b85d518043fef7660af7805d upstream. In loongson_card_parse_acpi(), the return value of device_property_read_string() for the `codec-dai-name` property was ignored. If the property is missing or invalid, an uninitialized pointer would be used later, potentially leading to undefined behavior. Fix this by checking the return value and propagating the error appropriately. Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/cover.1780538113.git.zhoubinbin@loongson.cn?part=5 Fixes: ddb538a3004b ("ASoC: loongson: Factor out loongson_card_acpi_find_device() function") Signed-off-by: Binbin Zhou Link: https://patch.msgid.link/08e44a54708eae053be148524346bb8dfcd55b03.1782439646.git.zhoubinbin@loongson.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e11b056d69b8c9ff47493d57478d0a90ff4ae854 Author: Haoxiang Li Date: Mon Jun 22 17:16:20 2026 +0800 AsoC: intel: sst: fix PCI device reference leak on probe failure commit 016f29997ebd29d6ab59c8162ce0e7f73bd1e517 upstream. intel_sst_probe() takes a reference to the PCI device with pci_dev_get(). If sst_platform_get_resources() fails afterwards, the probe error path cleans up the driver context but does not drop the PCI device reference. Add a pci_dev_put() error path for failures after pci_dev_get(). Fixes: f533a035e4da ("ASoC: Intel: mrfld - create separate module for pci part") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260622091620.897478-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e8ea01a0457080b0cc7c69c430c0ab65d84dc377 Author: Haoxiang Li Date: Mon Jun 22 22:56:45 2026 +0800 ASoC: hdac_hda: Fix hlink refcount leak on component registration failure commit 6ad4892c4f5cb437a928a02f5b7d37d496aa9268 upstream. hdac_hda_dev_probe() gets the HDA link with snd_hdac_ext_bus_link_get() before registering the ASoC component. If component registration fails, the function returns without dropping the link reference. Always call snd_hdac_ext_bus_link_put() after the registration attempt so the reference taken during probe is balanced on both success and failure. Fixes: 6bae5ea94989 ("ASoC: hdac_hda: add asoc extension for legacy HDA codec drivers") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260622145645.1184986-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0966b76a0e23cc208e1caf3a7690ed56cff24206 Author: wangdicheng Date: Fri Jul 17 17:15:42 2026 +0800 ASoC: fsl_easrc: Use div64_u64 for 64-by-64 division commit a46ccc71877e962783e0fffa105e41615904c511 upstream. Fix a coccinelle warning about do_div() truncating a 64-bit divisor: sound/soc/fsl/fsl_easrc.c:2061:2-8: WARNING: do_div() does a 64-by-32 division, please consider using div64_u64 instead. In fsl_easrc_m2m_calc_out_len(), val1 is computed as: val1 = (u64)in_rate << frac_bits; // frac_bits up to 39 do_div(val1, out_rate); val1 += (s64)ctx_priv->ratio_mod << (frac_bits - 31); val1 = val1 >> 12; In the worst case (in_rate=384000, out_rate=8000, frac_bits=39): val1 = 384000 << 39 / 8000 = 26,388,279,068,672 val1 >> 12 = 6,440,497,829 (33 bits, exceeds 32-bit range) val1 is then used as the divisor in do_div(val2, val1), where do_div() silently truncates it to 32 bits, producing incorrect results. Use div64_u64() to perform a proper 64-by-64 division. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Cc: stable@vger.kernel.org Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260717091542.721877-4-wangdich9700@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5ca4bd7543524a9715205b2fc6251cdeb92a78df Author: Haoxiang Li Date: Mon Jun 22 17:48:22 2026 +0800 ASoC: fsl: mpc5200-i2s: Free DMA resources on probe failure commit 3a89ddcf0c3d9a068631e8c24d5c9e81d1e6512a upstream. mpc5200_audio_dma_create() creates the DMA resources before registering the component. If snd_soc_register_component() fails, the function returns directly and leaves the DMA resources allocated. Call mpc5200_audio_dma_destroy() before returning from this error path. Fixes: f515b67381de ("ASoC: fsl: mpc5200 combine psc_dma platform data") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260622094822.926166-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5a4fe7a87841af23ba80bae31b80355b16926cf4 Author: Runyu Xiao Date: Fri Jun 12 00:15:53 2026 +0800 ASoC: cs35l34: drain threaded IRQ before runtime suspend commit 4105a4c0678b2808fc8046b60321b4f1cc7dae75 upstream. cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it. Fixes: c1124c09e103 ("ASoC: cs35l34: Initial commit of the cs35l34 CODEC driver.") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260611161553.3378721-3-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6e369bc46663b4bfce3d5f8b8ed08e71ecea13a2 Author: Runyu Xiao Date: Fri Jun 12 00:15:52 2026 +0800 ASoC: cs35l33: drain threaded IRQ before runtime suspend commit e074c12c428c633e079154301207a6079a208583 upstream. cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it. Fixes: 3333cb7187b9 ("ASoC: cs35l33: Initial commit of the cs35l33 CODEC driver.") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260611161553.3378721-2-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit eb5d39dd862f5c91c2e2dba384b6d100ee90f05b Author: Linkai Gong Date: Thu Aug 13 17:56:17 2026 +0800 i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure commit 62edb8ca0aa44517cc23cfa26cd8a51f15ea92fe upstream. of_parse_phandle() takes a reference on the parent node. If a later devm_kstrdup() fails, err_rollback only releases nodes for indices 0..i-1, so the current node is leaked. of_node_put() the current parent before rolling back. Fixes: 7c0195fa9a9e ("i2c: mux: demux-pinctrl: check the return value of devm_kstrdup()") Signed-off-by: Linkai Gong Cc: # v6.6+ Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260813095617.2246320-1-gonglinkai@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit b2b87f2e0bb167c1f2996fea436b4afd939365ec Author: Stephan Gerhold Date: Mon Jul 6 17:02:15 2026 +0200 clk: qcom: gcc-mdm9607: Drop incorrect BIMC PLL and related clocks commit e111ddda092ad961870a634e4c9263c10a3e8485 upstream. The gcc-mdm9607 driver was originally based on gcc-msm8916, but a closer match nowadays is gcc-msm8909. Looking at the differences between gcc-mdm9607 and gcc-msm8909, there is quite some confusion around the definitions for the BIMC PLL. It turns out the BIMC PLL on MDM9607 is actually an Alpha PLL just like on MSM8909. We can vote for it using BIT(2), which explains why BIT(3) was used for GPLL2. In practice, the BIMC PLL is exclusively controlled by the RPM firmware and Linux should not touch it. So far, it was defined to model the full clock hierarchy, but even in read-only mode with CLK_GET_RATE_NOCACHE this is problematic since the RPM will silently change the clock parents without notifying Linux about it. The clock framework reads the clock parent only once during boot, so the resulting rates will still be often wrong. Follow the example of more recent SoCs and drop the BIMC PLL and all remaining related clocks to avoid reporting stale status data. This means we cannot determine the rate of these clocks anymore. This is not a big problem in practice, since these are NoC-related clocks that are independently managed through the interconnect subsystem. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Signed-off-by: Stephan Gerhold Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-8-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 4763197c6f344be19ce69c4bae07edbe65e331df Author: Stephan Gerhold Date: Mon Jul 6 17:02:11 2026 +0200 clk: qcom: gcc-mdm9607: Fix halt_reg for gcc_apss_axi_clk commit ca7e6cc30cde4f0cbeff2e205a84bedf431e9156 upstream. gcc_apss_axi_clk specifies a halt_reg of 0x4601c, but this is already used by gcc_apss_ahb_clk. The correct value according to the downstream driver is 0x46020. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Taniya Das Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-4-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit bd326b0c5b3393281dfdf47a9b89578470a67d23 Author: Stephan Gerhold Date: Mon Jul 6 17:02:10 2026 +0200 clk: qcom: gcc-mdm9607: Fix enable_reg for gcc_blsp1_sleep_clk commit 944d0fb38cffe57a1d1ebf82c5c077bad82dcdbb upstream. MDM9607 is similar to MSM8909, where the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-3-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit c67fc2fd713959a744b47ec366c7ffb4f2ed3f31 Author: Stephan Gerhold Date: Mon Jul 6 17:02:14 2026 +0200 clk: qcom: gcc-mdm9607: Drop incorrect system_noc_bfdcd_clk_src commit 17784427df923a0573a7ea83f9198456ff1ec1a5 upstream. This clock does not exist on MDM9607. Reading/writing the registers always results in 0. Presumably, this definition was mistakenly copied from gcc-msm8916. On MSM8916, this root clock is used for multimedia subsystems (camera, display, video). MDM9607 has none of that, so this clock was probably omitted in the hardware. There are no users inside gcc-mdm9607, so we can just drop it. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-7-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 206a6e21a0cf481351acde2d4b29b3e3a11ac683 Author: Stephan Gerhold Date: Mon Jul 6 17:02:13 2026 +0200 clk: qcom: gcc-mdm9607: Drop incorrect apss_tcu_clk_src commit 38d06956f60675f906dc3f5b70b3b52103b86a7d upstream. This clock does not exist on the specified address on MDM9607. Reading/writing the registers always results in 0 or crashes. The math in the frequency table is also broken. GPLL2 on MDM9607 runs at 480 MHz, so: - F(155000000, P_GPLL2, 6, 0, 0), // 480 MHz/6 = 80 MHz, not 155 MHz - F(310000000, P_GPLL2, 3, 0, 0), // 480 MHz/3 = 160 MHz, not 310 MHz Presumably, this definition was mistakenly copied as-is from gcc-msm8916 (which uses 930 MHz for GPLL2). There are no branch consumers of this root clock inside gcc-mdm9607 (notably, gcc_apss_tcu_clk has bimc_ddr_clk_src as parent instead of this clock), so we can just drop it. It seems like this clock does exist on this SoC on a different address, but since there is no user and reference code for it, it is still better to drop it. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-6-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 526b0a71a4d914aed35e9a9b9e987eeaf1c76871 Author: Heiko Stuebner Date: Wed Mar 4 13:14:25 2026 +0100 clk: rockchip: rk3588: Don't change PLL rates when setting dclk_vop2_src commit 13b10571cc353448275365ede1a5396d20dfe839 upstream. dclk_vop2_src currently has the CLK_SET_RATE_PARENT flag set, which is very different from dclk_vop0_src or dclk_vop1_src, which don't have it. With this flag in dclk_vop2_src, actually setting the clock then results in a lot of other peripherals breaking, because setting the rate results in the PLL source getting changed: [ 14.898718] clk_core_set_rate_nolock: setting rate for dclk_vop2 to 152840000 [ 15.155017] clk_change_rate: setting rate for pll_gpll to 1680000000 [ clk adjusting every gpll user ] This includes possibly the other vops, i2s, spdif and even the uarts. Among other possible things, this breaks the uart console on a board I use. Sometimes it recovers later on, but there will be a big block of garbled output for a while at least. Shared PLLs should not be changed by individual users, so drop this flag from dclk_vop2_src. Fixes: f1c506d152ff ("clk: rockchip: add clock controller for the RK3588") Cc: stable@vger.kernel.org Tested-by: Quentin Schulz # RK3588 Tiger w/ DP Signed-off-by: Heiko Stuebner Reviewed-by: Quentin Schulz Tested-by: Chris Morgan Link: https://patch.msgid.link/20260304121426.1184680-2-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit cc2941bc37351dca9e744012d63fc3add645798d Author: Stephan Gerhold Date: Mon Jul 6 17:02:09 2026 +0200 clk: qcom: gcc-msm8939: Fix enable_reg for gcc_blsp1_sleep_clk commit fc611445b021262b0d4ace6f716a360663816287 upstream. MSM8939 is similar to MSM8916, where the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-2-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 51b40cb17c216aaa2904059f01408ea705a622d0 Author: Stephan Gerhold Date: Mon Jul 6 17:02:08 2026 +0200 clk: qcom: gcc-msm8916: Fix enable_reg for gcc_blsp1_sleep_clk commit c5339edc6abb601ea10df910ea0b1592fa1016f3 upstream. According to the APQ8016E TRM, the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-1-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 4582949b7badcb91bb537ca522d69b8a35131e72 Author: Martin Blumenstingl Date: Tue Jun 23 22:19:56 2026 +0200 clk: meson: align gxbb_32k_clk_sel number of parents with actual count commit 628b6fee9fca292f12d07f0f1bcf1edefa949d81 upstream. The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c ("clk: amlogic: gxbb: drop non existing 32k clock parent") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future). Fixes: 7915d7d5407c ("clk: amlogic: gxbb: drop non existing 32k clock parent") Reported-by: Christian Hewitt Cc: stable@vger.kernel.org Tested-by: Christian Hewitt Signed-off-by: Martin Blumenstingl Link: https://patch.msgid.link/20260623201956.1324992-1-martin.blumenstingl@googlemail.com Signed-off-by: Jerome Brunet Signed-off-by: Greg Kroah-Hartman commit 88fe6792be2b35a104527c7cffb3bf8f1f70367b Author: Akari Tsuyukusa Date: Fri May 22 22:30:23 2026 +0900 clk: mediatek: mt8196: Select REGMAP_MMIO for vlpckgen commit f63aecdb45e9dd19c340fd62df698374d95b9024 upstream. The MediaTek MT8196 vlpckgen clock driver uses __devm_regmap_init_mmio_clk() by devm_regmap_init_mmio(), which is defined in drivers/base/regmap/regmap-mmio.c. However, the driver's Kconfig entry does not select REGMAP_MMIO. This causes a linker error when REGMAP_MMIO is not enabled. Fix this by selecting REGMAP_MMIO in the Kconfig entry. Fixes: 2f8b3ae6f0cb ("clk: mediatek: Add MT8196 vlpckgen clock support") Cc: stable@vger.kernel.org Signed-off-by: Akari Tsuyukusa Reviewed-by: Brian Masney Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Brian Masney Signed-off-by: Greg Kroah-Hartman commit 05952e503cf65001313386e0804da90adc4da390 Author: Pavel Löbl Date: Fri Jun 5 15:03:40 2026 +0200 clk: clocking-wizard: fix integer overflow in rate calculation commit 4adf593c6fc5aed4639add011f71a074a1bd3966 upstream. When using driver on Zynq-7000 (32-bit) determine_rate calculation overflows. For instance requesting 32MHz with 100MHz parent clock results in 100000000*(4*1000+0) 32-bit multiplication. Replace the expression with mult_frac which is already used in clk_wzrd_recalc_ratef. Cc: stable@vger.kernel.org Fixes: 7681f64e6404 ("clk: clocking-wizard: calculate dividers fractional parts") Signed-off-by: Pale Löbl Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Greg Kroah-Hartman commit 82f78c2b3af8fc9254cb4999bb4e4bed08c5317a Author: Sven Eckelmann Date: Sun Jul 5 22:21:50 2026 +0200 batman-adv: bla: prevent CRC corruptions after claim flush commit 89f3502ff6878798be96461b2eebd64ba3c3874c upstream. When batadv_bla_del_backbone_claims() tried to remove all claims of a backbone, it sets the CRC to 0. It assumes that the it had the last reference of the claims because batadv_claim_release() (which runs after the last reference was released), is XORing the crc16 of the claim address with the backbone CRC. If there would be a parallel holder of any of these references, it could happen that the backbone CRC is (0 ^ crc16(delayed_released_claim)). Which is the wrong starting point for the new claims it may receive when the remote answers the claim request from batadv_bla_send_request(). This reinitializations can be completely dropped to avoid this problem. batadv_claim_release() will take care of fixing the backbone CRC. Cc: stable@vger.kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 871acdf97f64cee8398f72b88b89e8b4f4816dbe Author: Sven Eckelmann Date: Wed Jul 22 12:08:09 2026 +0200 batman-adv: bla: fix freeing of claims on meshif deletion commit 8d128c932bced74e3b1625ba3d7c78ef122a88a7 upstream. When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 1cfa7d5f70d54cb8c7e82df739430782d1996ee1 Author: Sven Eckelmann Date: Mon Jul 6 19:46:37 2026 +0200 batman-adv: dat: avoid unaligned fault in IP extraction commit 0121afa52cdb88cfb4d5d7bd126a23a9100121d8 upstream. Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 5c3a0e553593 ("batman-adv: Distributed ARP Table - add ARP parsing functions") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit c32e5e25c41201c8c3b796a4ab2c45103187091e Author: Sven Eckelmann Date: Thu Jul 9 21:26:13 2026 +0200 batman-adv: mcast: linearize skbuff for packet generation commit 6a30a59e2660afd03c975f1b8eae6a2301161197 upstream. batadv_mcast_forw_packet() and batadv_mcast_forw_scrape() is not only called (indirectly) by the unsharing+linearizing batadv_recv_mcast_packet() handler. When it is called (indirectly) by batadv_mcast_forw_mcsend() then it will be unshared but not linearized. The SKB_LINEAR_ASSERT() can therefore cause a fatal BUG(). The linearization should happen during the expansion of the head because the scrape function can be hit already during the initial batadv_mcast_forw_mode() selection code: * batadv_interface_tx * batadv_mcast_forw_mode * batadv_mcast_forw_mode_by_count() * batadv_mcast_forw_push() -> calls batadv_mcast_forw_expand_head() before everything else * batadv_mcast_forw_push_tvlvs() * batadv_mcast_forw_push_dests() * batadv_mcast_forw_push_adjust_padding() * batadv_mcast_forw_scrape() Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 90039133221e ("batman-adv: mcast: implement multicast packet generation") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit cedacfecf4b4099f8b6f11c178589e379bb53b17 Author: Sven Eckelmann Date: Thu Jul 9 21:17:08 2026 +0200 batman-adv: mcast: ensure unshared skb for multicast packets commit 82bf207f48ebb7a38157f1d91dac884fc9b8cfd8 upstream. When a packet is transmitted via a batman-adv interface and has already enough room for the header then nothing will make sure that the skbuff is unshared. But it is not allowed to modify a currently shared skbuff. Always make sure that the pskb_expand_head() is not only called for a too small header but also for shared skbuffs. Cc: stable@vger.kernel.org Fixes: 90039133221e ("batman-adv: mcast: implement multicast packet generation") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit e91d2cc7441d89a45bad73ad9789159c7441cb80 Author: Zhiling Zou Date: Fri Jul 31 11:18:49 2026 +0800 batman-adv: fix stale receive device on merged fragments commit ad46c907d7d9975a285c1e89a4adde652eaa93f5 upstream. Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown. Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit c8f86e375b39cada09fd8cb33dd3bb3641e84a62 Author: Pengpeng Hou Date: Mon Jul 20 19:57:25 2026 +0800 mtd: rawnand: validate ONFI extended parameter page sections commit e5e415262330bd70f983e091d8919d9dcd99e475 upstream. nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section. Fixes: 6dcbe0cdd83f ("mtd: get the ECC info from the Extended Parameter Page") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 4b282dc6a9e9644c1dbaebcff72c6bca93222392 Author: Pengpeng Hou Date: Wed Jul 8 09:47:12 2026 +0800 mtd: nand: realtek-ecc: add missing MODULE_DEVICE_TABLE() commit 5b2444b4d575d8117809c57801562ef37ca2d4af upstream. The Realtek external ECC engine driver has an OF match table wired into its platform driver, but the table is not exported with MODULE_DEVICE_TABLE(). When the driver is built as a module, the missing OF module alias prevents automatic module loading from the compatible string. Add the missing MODULE_DEVICE_TABLE() entry. Fixes: 3148d0e5b1c5 ("mtd: nand: realtek-ecc: Add Realtek external ECC engine support") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit d06f91a52af11630c9f7e487f6daf242ac310cb8 Author: Xu Rao Date: Mon Jul 13 13:22:03 2026 +0800 mtd: mtdoops: free page bitmap when the backing MTD is removed commit 956e7da12c114f13c63d126ab1d79c3b6a819060 upstream. mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event. Fixes: be95745f0167 ("mtd: mtdoops: keep track of used/unused pages in an array") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 18916f475057cbd2fb8ea6ae86e6b85884ad1d53 Author: Pengpeng Hou Date: Wed Jul 8 09:49:06 2026 +0800 mtd: afs: validate v2 image info bounds commit e9290031f736e99ad17c25c00311c92c266843b7 upstream. The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries. Fixes: b7cf5e2830bb ("mtd: afs: add v2 partition parsing") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Acked-by: Linus Walleij Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit e8bcb9d54429ba22baa504f665c8f6c89f972ca6 Author: Anthony Krowiak Date: Wed Aug 12 16:02:35 2026 -0400 s390/vfio-ap: Fix required lock not held during update of ap_matrix_mdev object commit 5883528250be57fa92270459b33603ff52de0a91 upstream. In the vfio_ap_mdev_cfg_add function, the apm_add, aqm_add and adm_add fields of an ap_matrix_mdev object fields are modified while not holding the matrix_dev->mdevs_lock. This lock must be held while making these to guard against a race condition with another caller that may be concurrently modifying these fields or any of the fields in the matrix_mdev->matrix. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 6d554f2571e6b4db242593ba561efd6a6d1f99a9 Author: Anthony Krowiak Date: Wed Aug 12 16:02:37 2026 -0400 s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap commit bf09b9d7cd7890bc3a3b7eb63d5ece15f88bfde7 upstream. The DECLARE_BITMAP(apm_filtered, AP_DEVICES) macro allocates the bitmap on the stack without zero-initializing it. In vfio_ap_mdev_hot_plug_cfg(), the vfio_ap_mdev_filter_matrix() function is only called to initialize and populate apm_filtered if either filter_adapters or filter_domains is true. If the hot plug configuration change only adds control domains (meaning filter_cdoms is true, but filter_adapters and filter_domains are both false), vfio_ap_mdev_filter_matrix() is bypassed. Consequently, apm_filtered is passed to reset_queues_for_apids() with uninitialized stack garbage. This can cause reset_queues_for_apids() to interpret arbitrary stack garbage bits as valid APIDs to reset, potentially performing unintended guest hardware queue resets. Fix this by zero-initializing the apm_filtered bitmap at the beginning of vfio_ap_mdev_hot_plug_cfg() using bitmap_zero(). Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 69632952aca04caa71e49953b6949fc04e788e67 Author: Anthony Krowiak Date: Wed Aug 12 16:02:39 2026 -0400 s390/vfio-ap: Fix NULL deref in status_show() during queue probe commit dd6f4ef6f8a37412909ad787c837332fb070159c upstream. When vfio_ap_mdev_probe_queue() creates the sysfs attribute group, the queue's driver data has not yet been set. A concurrent read of the 'status' attribute can therefore call dev_get_drvdata() and get NULL, which is then passed directly to vfio_ap_mdev_for_queue() where q->apqn is unconditionally dereferenced, causing a NULL pointer dereference. Fix this by acquiring the update locks before calling sysfs_create_group(). The status_show() function acquires guests_lock before reading the driver data, so any concurrent read will block until after dev_set_drvdata() has been called and the update locks are released. As a bonus, the APQN no longer needs to be read from the queue struct after allocation — it can be read directly from apdev before allocation and stored in a local variable, which is then assigned to q->apqn once the allocation succeeds. Fixes: 260f3ea141382 ("s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 647916988272fe5ecb4bb30cd02b51af9960618a Author: Anthony Krowiak Date: Wed Aug 12 16:02:34 2026 -0400 s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects commit 7fa61c29850d05e40ca9ed41bfdf57673023f581 upstream. In order to traverse or add/remove ap_matrix_mdev objects in the matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held. There are two functions that access the list without holding the mutex: vfio_ap_mdev_probe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock mutex to guard the add of a newly created ap_matrix_mdev object to the matrix_dev->mdev_list. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an ap_matrix_mdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently. The adding of an ap_matrix_mdev object to matrix_dev->mdev_list is now guarded by the matrix_dev->guests_lock which is the correct way to protect against concurrent mdev_list access. Also removed the following two lines of code because the matrix_mdev is allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger and cfg_chg_trigger are already zero-initialised when the struct is allocated before the call to vfio_register_emulated_iommu_dev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace. matrix_mdev->req_trigger = NULL; matrix_mdev->cfg_chg_trigger = NULL; vfio_ap_mdev_for_queue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The status_show function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue function which iterates the matrix_dev->mdev_list to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrix_dev->guests_lock mutex must be held. To fix this, the guests_lock mutex is taken prior to taking the matrix_dev->mdevs_lock mutex in the status_show function. It is taken there rather than the vfio_ap_mdev_for_queue function - where it is needed - because it must be taken prior to the mdevs_lock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevs_lock is needed there to access fields within the matrix_mdev object in that function. See the vfio-ap-locking.rst in the linux kernel tree. Fixes: 2c1ee8983aa3 ("s390/vfio-ap: prepare for dynamic update of guest's APCB on queue probe/remove") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit c45753c32d452d10d8efaeb52587e9e6e8126e33 Author: Anthony Krowiak Date: Wed Aug 12 16:02:38 2026 -0400 s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed commit 917f509bfb88048094dbb85c4e9dbc4d6fe4a886 upstream. The vfio_ap_mdev_hot_unplug_cfg() function uses the return value of bitmap_andnot() to determine whether the guest APCB needs to be updated. However, bitmap_andnot() returns false when the resulting destination bitmap is empty. This means that if the only adapter, domain or control domain assigned to an mdev is removed from the host's AP configuration, the bit is correctly cleared from the shadow APCB, but bitmap_andnot() returns false because the result is an empty bitmap. Consequently, do_hotplug remains 0 and vfio_ap_mdev_update_guest_apcb() is never called, leaving the KVM guest with stale hardware access to the unplugged AP devices. Fix this by replacing the bitmap_andnot() return value check with bitmap_intersects() to determine whether the shadow APCB actually overlaps with the removal mask. If there is an intersection, call bitmap_andnot() solely for its side effect of clearing the bits, then unconditionally set do_hotplug to trigger the guest APCB update. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 178ea7a1c2c3c0c01d14b8f60aa35f1e0cdc6b78 Author: Anthony Krowiak Date: Wed Aug 12 16:02:33 2026 -0400 s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL commit d50346801b4f144e42b49cd4f1496010498ab114 upstream. The ap_driver structure has two fields which are function pointers to callbacks: * .on_config_changed: called at the start of the AP bus scan function to notify the device driver that the host AP configuration has changed and the associated AP devices will be added or removed accordingly. This gives the implementor a chance to evaluate the configuration changes and respond to them before the associated devices are added or removed. * .on_scan_complete: Called at the end of the AP bus scan function to notify the device driver that the host AP configuration has changed and the AP devices have been added or removed accordingly. This gives the implementor the opportunity to respond to the changes after the associated devices are added or removed. These two callbacks are implemented in the vfio_ap device driver via the vfio_ap_on_cfg_changed and vfio_ap_on_scan_complete functions respectively. Within the call stack of these two callback functions the matrix_mdev->kvm->lock mutex is taken without checking whether matrix_mdev->kvm is NULL or not. If matrix_mdev->kvm has never been set, trying to take the lock will trigger a NULL pointer dereference. This patch adds checks for matrix_mdev->kvm == NULL before taking the matrix_mdev->kvm->lock mutex. Note that the matrix_mdev->kvm->lock mutex taken in the vfio_ap_mdev_hot_plug_config function is moved to the calling function along with the matrix_dev->mdevs_lock which is needed there to access the fields of the matrix_mdev. It makes little sense to make the change the check for matrix_mdev->kvm there before taking the kvm->lock mutex only to have to move it out via another patch, so it is done in this patch. It is important to make note of the following: 1. The matrix_dev->guests_lock is acquired at the start of both callback functions. This ensures that matrix_mdev will not be removed via the vfio_ap_mdev_remove function because it too takes matrix_dev_guests_lock before removing the object; so, matrix_mdev will be available for the duration of the callback functions. 2. The matrix_dev->mdevs_lock mutex must be taken in order to access fields within the matrix_mdev structure 3. matrix_mdev->kvm->lock mutex must be taken before the matrix_dev->mdevs_lock to prevent a lockdep splat. 4: The kvm->lock must be held while plugging the guest's AP configuration into its SIE state description via the vfio_ap_mdev_update_guest_apcb function. 5. The vfio_ap_mdev_update_guest_apcb checks matrix_mdev->kvm to verify it is not NULL before doing the hot plug of the guest's AP configuration. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit f7d66afc34bc6e833c8ebe56973afec35f473bc1 Author: Anthony Krowiak Date: Wed Aug 12 16:02:36 2026 -0400 s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove commit 6b8a02e216f6b520cc029e43ddc83956605135d5 upstream. The vfio_ap_config_remove function uses the bitmap_andnot function to clear bits from the matrix_mdev->matrix.adm bitmap (specifies the control domains assigned to the mdev). This prevents the explicitly unplugged control domains from being removed the KVM guest. The bitmap_and function is used instead. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 3c5f51f257e14d657fe2b37e3547dedf3f744e91 Author: Anthony Krowiak Date: Wed Aug 12 16:02:32 2026 -0400 s390/vfio-ap: Fix stale do_remove flag across iterations in vfio_ap_mdev_cfg_remove commit b1f092d94f621307927f145e3cc31893da51fc08 upstream. The do_remove flag in vfio_ap_mdev_cfg_remove() is initialised to zero before the loop that iterates over the list of matrix mdevs, but is never reset at the start of each iteration. Since do_remove is OR-accumulated across iterations, a positive result from one mdev carries over to subsequent mdevs. The fix is to set the do_remove flag with the first call to bitmap_and; for example: do_remove = bitmap_an rather than do_remove |= bitmap_and. Fixes: eeb386aeb5b7 ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit fc069d00a0dbef40042fd681554d48dcd5a1d524 Author: Anthony Krowiak Date: Thu Aug 6 13:34:35 2026 -0400 s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm() commit 4400270ec0348d05dc0439d8f0130853ce7f9e20 upstream. In vfio_ap_mdev_set_kvm(), kvm->arch.crypto.pqap_hook is set to &matrix_mdev->pqap_hook before the update locks are acquired and the mdev list is checked for a conflicting assignment. If another mdev is already attached to the same KVM instance, the function returns -EPERM without restoring the hook pointer, leaving kvm->arch.crypto.pqap_hook pointing at the failing matrix_mdev instead of the mdev that legitimately owns the KVM. Since matrix_mdev->kvm is never set on this error path, vfio_ap_mdev_unset_kvm() will not clean up the hook when matrix_mdev is later closed. If matrix_mdev is subsequently freed, any PQAP instruction executed by the guest will dereference the stale pointer through pqap_hook_rwsem, resulting in a use-after-free. Since kvm->arch.crypto.pqap_hook is only set in the vfio_ap_mdev_set_kvm() function and is cleared in the vfio_ap_mdev_unset_kvm() function, a check for 'kvm->arch.crypto.pqap_hook != NULL' is all that is needed to determine whether it belongs to another mdev. This will alleviate the need to iterate the matrix_dev->mdev_list list to see if the kvm object is assigned to another mdev.This was introduced in v3 to alleviate the need to take the mdevs_lock while iterating the list; however, this did not prevent a potential race condition. The pqap_hook_rwsem(write) is now performed inside get_update_locks_for_kvm(), which is updated to acquire pqap_hook_rwsem(write) between kvm->lock and mdevs_lock. This ordering is consistent with the PQAP intercept path, which acquires pqap_hook_rwsem in read mode while srcu is held under vcpu->mutex, establishing the dependency: kvm->lock -> vcpu->mutex -> srcu -> pqap_hook_rwsem(read). The pqap_hook_rwsem is now released inside the release_update_locks_for_kvm(), which is updated to release pqap_hook_rwsem(write) between mdevs_lock and kvm->lock. Additionally, kvm_put_kvm() in vfio_ap_mdev_unset_kvm() is moved after release_update_locks_for_kvm(). Previously it was called while kvm->lock was held; if it were ever the last reference, kvm_destroy_vm() would run under kvm->lock, which would deadlock. Fixes: 86956e70761b3 ("s390/vfio-ap: replace open coded locks for VFIO_GROUP_NOTIFY_SET_KVM notification") Cc: stable@vger.kernel.org Co-developed-by: Matthew Rosato Signed-off-by: Matthew Rosato Signed-off-by: Anthony Krowiak Acked-by: Christian Borntraeger Signed-off-by: Claudio Imbrenda Message-ID: <20260806173435.105044-1-akrowiak@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 3b90d769b351a9240a2b97de52638d8839d25b80 Author: Sourabh Jain Date: Mon Jul 27 11:04:16 2026 +0530 powerpc/crash: stop watchdogs before booting kdump kernel commit fb43ba4256543ce18ca0540fc37022bda438a293 upstream. On pseries LPAR systems, watchdog timers configured from userspace can remain active after a kernel panic. When a panic triggers kdump, the crashing kernel jumps directly to the kdump kernel without stopping active watchdogs. As a result, the watchdogs remain active after the kdump kernel starts. If dump capture takes longer than the watchdog timeout, PHYP resets the LPAR before the dump is fully captured, causing dump capture to fail. Fix this by issuing the `H_WATCHDOG` hcall during the crash shutdown sequence to stop all active watchdogs before booting the kdump kernel. Cc: stable@vger.kernel.org Fixes: 69472ffa6575 ("watchdog/pseries-wdt: initial support for H_WATCHDOG-based watchdog timers") Reported-by: Mahesh Kumar G Suggested-by: Ritesh Harjani (IBM) Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727053416.276317-4-sourabhjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 36dcb8c2e3391126bb7c9c41b057a3609ea2d4a8 Author: Sourabh Jain Date: Mon Jul 27 11:04:14 2026 +0530 powerpc/pseries: Move H_WATCHDOG definitions to a common header commit 516a254918453ec99660201263d01189c082332c upstream. The H_WATCHDOG input and output definitions are currently local to the pseries watchdog driver. The next patch in this series also needs these definitions to issue H_WATCHDOG hypercalls outside the watchdog driver. Move the H_WATCHDOG definitions to a new common header, asm/papr-watchdog.h, so they can be shared without duplicating the PAPR watchdog definitions. No functional changes. Cc: stable@vger.kernel.org Suggested-by: Ritesh Harjani (IBM) Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727053416.276317-2-sourabhjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit d2be3dd20e8337dc90451c0f298b2d9aa20f0448 Author: Sourabh Jain Date: Mon Jul 27 11:04:15 2026 +0530 powerpc/pseries: Handle and log pseries-wdt registration failures commit e65b526affa621b50646cafdf6b06505af07032e upstream. The pseries watchdog initialization registers the pseries-wdt platform device using platform_device_register_simple(), but currently ignores its return value. Check the returned pointer for errors, log a descriptive error message when registration fails, and propagate the failure code to the caller. This avoids silently ignoring platform device registration failures. Cc: stable@vger.kernel.org Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727053416.276317-3-sourabhjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 9c914b7a0bd18834505c65f22225ce22c152b2d9 Author: Muchun Song Date: Fri Jun 12 11:58:47 2026 +0800 powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population commit 89a4ae32764172468dea303eb6ae90fe6c859712 upstream. vmemmap_populate_compound_pages() uses addr_pfn to determine the PFN offset within a compound page and to decide whether the current vmemmap slot should be populated as a head page mapping or should reuse a tail page mapping. However, addr_pfn is advanced manually in parallel with addr. The loop itself progresses in vmemmap address space, so each PAGE_SIZE step in addr covers PAGE_SIZE / sizeof(struct page) struct page slots. Since addr_pfn is compared against nr_pages in data-PFN units, it should advance by the same number of PFNs. The existing manual increments do not match that and therefore do not reliably track the PFN corresponding to the current addr. As a result, pfn_offset can be computed from the wrong PFN and the code can make the head/tail decision for the wrong compound-page position. Fix this by deriving addr_pfn directly from the current vmemmap address instead of carrying it as loop state. Link: https://lore.kernel.org/20260612035903.2468601-4-songmuchun@bytedance.com Fixes: f2b79c0d7968 ("powerpc/book3s64/radix: add support for vmemmap optimization for radix") Signed-off-by: Muchun Song Acked-by: Oscar Salvador Reviewed-by: Ritesh Harjani (IBM) Cc: "Aneesh Kumar K.V" Cc: David Hildenbrand Cc: Frank van der Linden Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Mike Rapoport (Microsoft) Cc: Nicholas Piggin Cc: Oscar Salvador (SUSE) Cc: Usama Arif Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit da88a2a2119e4fd0e8919a7a2448682f574e1545 Author: Jinjie Ruan Date: Wed Jul 29 09:29:48 2026 +0800 powerpc/kexec_file: Prevent kexec range truncation commit fa40f9dbdd4af53e7445d9135b5b207eb8adf372 upstream. Sashiko AI review pointed out the following issue. The __merge_memory_ranges() function incorrectly handles overlapping memory ranges when merging them. Although sort_memory_ranges() sorts all ranges by their start address in ascending order beforehand, the merge logic remains defective in two ways: 1. It compares the current range's start against the previous element (i-1) instead of the running target index (idx) 2. It unconditionally overwrites 'ranges[idx].end' with 'ranges[i].end'. This logic flaw leads to critical memory truncation when a larger memory range completely subsumes subsequent smaller ranges. For example, consider a sorted input array with three ranges: Range A (idx=0): [0x1000 - 0x9000] Range B (i=1): [0x2000 - 0x5000] (completely inside Range A) Range C (i=2): [0x6000 - 0x8000] (completely inside Range A) 1. When i=1 (Range B): ranges[1].start (0x2000) <= ranges[0].end + 1 (0x9001) is TRUE. The code executes: ranges[0].end = ranges[1].end, which erroneously shrinks Range A's end from 0x9000 down to 0x5000. 2. When i=2 (Range C): ranges[2].start (0x6000) <= ranges[1].end + 1 (0x5001) is FALSE. The code falls into the else block, creating a broken new range. As a result, valid memory fragments [0x5001 - 0x5fff] and [0x8001 - 0x9000] are completely lost from the kexec exclude lists, potentially allowing the crash kernel to overwrite active memory, causing data corruption or crashes. Fix this by ensuring the start of the current range is compared against the end of the active merged range (idx), and use max() to safely prevent the outer boundary from being truncated. Cc: stable@vger.kernel.org Fixes: 180adfc532a8 ("powerpc/kexec_file: Add helper functions for getting memory ranges") Signed-off-by: Jinjie Ruan Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260729012948.2797865-4-ruanjinjie@huawei.com Signed-off-by: Greg Kroah-Hartman commit df45337587db21c502fe5251d3bcc7887428f4fb Author: Jinjie Ruan Date: Wed Jul 29 09:29:47 2026 +0800 powerpc/kexec_file: Fix null-ptr-def in extra size calculation commit 761eda315a6e1fda3e8e2185b28430771fb1ac29 upstream. A static Sashiko AI review identified a potential NULL pointer dereference in kexec_extra_fdt_size_ppc64(). On platforms without any reserved memory regions, get_reserved_memory_ranges() can return 0 while leaving 'rmem' unallocated as NULL. Passing it directly leads to a kernel panic when evaluating 'rmem->nr_ranges'. Add a NULL check for 'rmem' to prevent this crash. Cc: stable@vger.kernel.org Fixes: 0d3ff067331e ("powerpc/kexec_file: fix extra size calculation for kexec FDT") Signed-off-by: Jinjie Ruan Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260729012948.2797865-3-ruanjinjie@huawei.com Signed-off-by: Greg Kroah-Hartman commit 6ae9306c7598184da7b66fdce3c5f47ffa10c277 Author: Helge Deller Date: Sat Aug 15 11:59:20 2026 +0200 parisc: Fix alignment of asm statements in head.S commit 04cf68c9a76e3c6b67ad056a66a14923abf85925 upstream. All assembler statements need to be 4-byte aligned. Prevent a possible misalignment if someone changes the preceeding string and it's length is then suddenly not a multiple of 4 any longer. Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 3e2691eeee83a819125dba3f42c74e1b6730d5cd Author: Pei Xiao Date: Mon Aug 17 11:29:25 2026 +0800 parisc: eisa: Fix infinite loop when parsing invalid IRQ value commit 8b585431a16cfb9d8f2955a9fa0787ce3dceb3c2 upstream. When an invalid value is passed via the "eisa_irq_edge=" kernel command line parameter (e.g. "eisa_irq_edge=16,5"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally. Signed-off-by: Pei Xiao Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 6b1faf1f099f7060b5f1f2f0d024132581f1726e Author: Bryam Vargas Date: Sat Jun 20 16:41:31 2026 -0500 nvdimm/btt: reject an arena whose nfree is below the lane count commit 6a1f2e5ed9267ca19187038ac635393c165213ac upstream. The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant. Fixes: 5212e11fde4d ("nd_btt: atomic sector updates") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Alison Schofield Tested-by: Alison Schofield Link: https://patch.msgid.link/20260620-b4-disp-88b2514b-v1-1-3834e707d232@proton.me Signed-off-by: Alison Schofield Signed-off-by: Greg Kroah-Hartman commit bdd929e60bc54d7756165088a3e1b4ec13ac513e Author: Narek Jilavyan Date: Mon Aug 17 10:34:33 2026 +0000 mm/hugetlb_cgroup: call page_counter_set_max() outside VM_BUG_ON() commit eedc8474d469a2e88f4dc61f8cfe05c147478b43 upstream. hugetlb_cgroup_css_alloc() rounds the counter limit down to a multiple of the huge page size and then applies it inside an assertion: VM_BUG_ON(page_counter_set_max(fault, limit)); VM_BUG_ON(page_counter_set_max(rsvd, limit)); With CONFIG_DEBUG_VM=n, VM_BUG_ON(cond) is BUILD_BUG_ON_INVALID(cond), i.e. ((void)(sizeof((__force long)(cond)))), whose operand is never evaluated. page_counter_set_max() is not a predicate - it performs xchg(&counter->max, nr_pages) - so on every non-debug kernel the limit is never applied and the counters keep page_counter_init()'s PAGE_COUNTER_MAX. That is user-visible, because hugetlb_cgroup_read_u64_max() recomputes the same rounded value and uses equality as its "unlimited" sentinel. PAGE_COUNTER_MAX is LONG_MAX / PAGE_SIZE = 2251799813685247, which is odd, so round_down() really does change it and the two sides disagree. With CONFIG_DEBUG_VM=n: $ cat /sys/fs/cgroup/t/hugetlb.2MB.max 9223372036854771712 and with this patch: $ cat /sys/fs/cgroup/t/hugetlb.2MB.max max A debug option should not change cgroup output. Call the function, then assert the result, as v6.12 did. Use VM_WARN_ON_ONCE() rather than restoring VM_BUG_ON(): the two are identical under CONFIG_DEBUG_VM=n, and checkpatch asks that new code not use BUG() variants. Link: https://lore.kernel.org/20260817103433.191266-1-njilav@gmail.com Fixes: 0e2759afcaf9 ("page_counter: track failcnt only for legacy cgroups") Signed-off-by: Narek Jilavyan Reviewed-by: Muchun Song Cc: David Hildenbrand Cc: Oscar Salvador Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 631d8f39b33e73672d1ff113061984b64ac4f905 Author: Longlong Xia Date: Fri Aug 14 16:30:27 2026 +0800 mm/hugetlb: keep max_huge_pages when dissolving surplus folios commit 267bede12d3b108ca29997ce280e927a570ec97f upstream. dissolve_free_hugetlb_folio() can remove a free folio as surplus when its node has surplus pages. In that case remove_hugetlb_folio() decrements both nr_huge_pages and surplus_huge_pages, leaving the persistent pool size unchanged. Updating max_huge_pages as if a persistent folio had been removed can therefore corrupt the persistent pool target and underflow it when max_huge_pages is zero. Keep max_huge_pages unchanged for surplus folios, including the vmemmap restoration rollback path. Link: https://lore.kernel.org/20260814083027.1419487-1-xialonglong2025@163.com Fixes: cb402bbdabca ("mm/hugetlb: fix surplus pages in dissolve_free_huge_page()") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Longlong Xia Reviewed-by: Muchun Song Cc: David Hildenbrand Cc: Jinjiang Tu Cc: Longlong Xia Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ae6a8b0c69901927de5c4ee16cf1ba1e5960e0bc Author: Wupeng Ma Date: Tue Jul 7 19:02:54 2026 +0800 mm/hugetlb: fix missing migratable flag on same-node hugetlb migration commit 8ee1ef0f2f8ce29338f4ab00a3d344c010208058 upstream. Commit ba23f58de896 ("mm/migrate: don't call folio_putback_active_hugetlb() on dst hugetlb folio") moved setting of the migratable flag and active-list placement from folio_putback_active_hugetlb(dst) into move_hugetlb_state(), so that the freshly allocated destination folio is handled where allocation is known to have succeeded. Unfortunately, the new code was appended after the existing temporary-folio block in move_hugetlb_state(), which contains an early return added earlier by commit 5af1ab1d24e08 ("mm/hugetlb: optimize the surplus state transfer code in move_hugetlb_state()"): if (folio_test_hugetlb_temporary(new_folio)) { ... if (new_nid == old_nid) return; <-- skips the new code ... } /* added by ba23f58 */ folio_set_hugetlb_migratable(new_folio); list_move_tail(&new_folio->lru, ...&h->hugepage_activelist); When the destination folio is temporary (i.e. the hugetlb pool was exhausted and the migration callback fell back to alloc_migrate_hugetlb_folio()) and the migration does not cross a node -- the common case, and always true on a single-NUMA system -- move_hugetlb_state() returns before setting the migratable flag or adding the new folio to the active list. The destination folio is then installed in the page table but cannot be isolated afterwards, since folio_isolate_hugetlb() rejects folios without the migratable flag; a subsequent soft-offline, hard-offline or memory-hotplug offline of that folio fails with -EBUSY. This was reproduced on a single-NUMA arm64 VM: a second MADV_SOFT_OFFLINE on an already-migrated hugetlb page returned EBUSY and logged "hugepage isolation failed". Keep the surplus adjustment, which is the only part that depends on the node crossing, guarded by `if (new_nid != old_nid)', while making the migratable flag and active-list placement unconditional. This preserves the cleanup intent of ba23f58 and closes the early-return hole. Link: https://lore.kernel.org/20260707110254.3147686-1-mawupeng1@huawei.com Fixes: ba23f58de896 ("mm/migrate: don't call folio_putback_active_hugetlb() on dst hugetlb folio") Signed-off-by: Wupeng Ma Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Muchun Song Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8e287f463fc4fc81f1cc6d66db24293ec10c894b Author: caina Date: Fri Aug 21 17:17:20 2026 +0800 Revert "irqchip/mbigen: Fix mbigen node address layout" commit e67091609cf85962f64391c1b0f93d4cbfcd4e22 upstream. This reverts commit 6be6cba9c4371d27f78d900ccfe34bb880d9ee20. Commit 6be6cba9c437 ("irqchip/mbigen: Fix mbigen node address layout") appears to cause a regression on Hi1616. On-board hns NIC has two ports, enahisic2i0 and enahisic2i1, both behind mbigen-v2. Port 0 works; port 1 cannot pass any traffic. Their interrupt pins fall on different mbigen nodes: enahisic2i0: pins 1152-1198 -> all in node 9 enahisic2i1: pins 1200-1246 -> node 9 (1200-1215) + node 10 (1216-1246) (nid = (hwirq - 64) / 128 + 1; pin 1215 = node 9, pin 1216 = node 10) /proc/interrupts shows the break happens exactly at the node boundary: enahisic2i1-rx0 pin 1200 count 102 <- node 9 enahisic2i1-rx5 pin 1215 count 1 <- node 9, last pin enahisic2i1-tx5 pin 1216 count 0 <- node 10, first pin enahisic2i1-rx6 pin 1218 count 0 <- node 10 ...all node 10 pins stay at zero. Port 0 (entirely node 9) is unaffected. Reverting the commit restores normal operation. The commit assumes CLEAR occupies a full 4 KB page at [0xa000, 0xb000) and collides with node 10, so node 10+ gets shifted by 0x1000. But get_mbigen_clear_reg() uses flat, chip-wide addressing -- it never multiplies by the node ID: *addr = (hwirq / 32) * 4 + REG_MBIGEN_CLEAR_OFFSET; /* 0xa000 */ Over the valid hwirq range [64, 1407], CLEAR only spans 0xa008-0xa0af (168 bytes). Node 10's registers are: TYPE: 0xa000-0xa00f (16 B) overlaps CLEAR by 8 B (0xa008-0xa00f) VEC: 0xa200-0xa3ff (512 B) no overlap with CLEAR Shifting the whole page moves VEC from 0xa200 to 0xb200. The hardware reads the event ID from the fixed silicon address 0xa200 on interrupt firing, but software wrote it to 0xb200 -- so the hardware gets an uninitialised value and the interrupt is lost. The only real overlap is 8 bytes of TYPE. It can only trigger when a single mbigen instance has devices on both node 1 (CLEAR 0xa008) and node 10 (TYPE 0xa008). On Hi1616 those nodes are on separate mbigen instances, so it never triggers. Fixes: 6be6cba9c4371d27f78d900ccfe34bb880d9ee20 ("irqchip/mbigen: Fix mbigen node address layout") Suggested-by: Marc Zyngier Signed-off-by: caina Signed-off-by: Thomas Gleixner Acked-by: Yipeng Zou Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260821091720.16665-1-caina@uniontech.com Signed-off-by: Greg Kroah-Hartman commit 6e96e2bb1065bde4e693787ff84c75867fad2c6f Author: Christian Marangi Date: Fri Aug 21 10:52:15 2026 +0200 pmdomain: airoha: fix unselectable AIROHA_CPU_PM_DOMAIN kconfig commit 6d94c47a2e3a38170a0a141547e4c52fbe232cc3 upstream. The AIROHA_CPU_PM_DOMAIN config was wrongly guarded under the Mediatek PM Domains menu and was unselectable. Move it outside the menu so it's now visible and correctly selectable by default on Airoha SoC. Cc: stable@vger.kernel.org Fixes: 82e703dd438b ("pmdomain: airoha: Add Airoha CPU PM Domain support") Signed-off-by: Christian Marangi Reviewed-by: Abel Vesa Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit cf1484d9a75de6809ef331e16f525aaa41b0e16d Author: Shivam Kumar Date: Thu Aug 27 15:24:55 2026 -0400 nvmet-tcp: reject unsolicited H2CData PDUs commit db62b35cbca052860c519cbcabe7650708528738 upstream. nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the "list_add double add" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Cc: stable@vger.kernel.org Reviewed-by: Sagi Grimberg Signed-off-by: Shivam Kumar Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit dbc4acbdb3ca8c81441368ad7409b8f77d4de8f6 Author: Shivam Kumar Date: Fri Aug 14 15:48:11 2026 -0400 nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU commit 14cc5a7e77731497d5bea70f3bb05df7eda982e4 upstream. nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as queue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Shivam Kumar Cc: stable@vger.kernel.org Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 7555ddd60af72df2862dd8f9b730a9848577edda Author: Kazuki Hanai Date: Sun Aug 30 22:11:05 2026 +0900 nvmet-auth: Synchronize timeout work during SQ teardown commit eaa948c0e19b1bb2d93262207bca0c3d19cc3406 upstream. nvmet_auth_sq_free() cancels auth_expired_work with cancel_delayed_work(). If the work has already started, cancellation does not wait for the callback. Transport teardown can consequently free or reuse the queue containing struct nvmet_sq while nvmet_auth_expired_work() still accesses that SQ. Add a teardown-specific helper that synchronously drains the delayed work before freeing authentication state, and use it from nvmet_sq_destroy(). Keep the non-synchronous helper for in-band authentication state cleanup, where the SQ owner remains alive. Fixes: 1a70200f404a ("nvmet-auth: expire authentication sessions") Cc: stable@vger.kernel.org Signed-off-by: Kazuki Hanai Reviewed-by: Sagi Grimberg Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit d663944dbad81bb0e3635d7090db4713e6300858 Author: Tristan Madani Date: Sat Aug 15 00:14:27 2026 +0000 nvme: add missing SRCU grace period in error path commit ef248d5de4469fb6bbaf8dbe0c4c47800080d648 upstream. nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs. The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path. Fixes: ed754e5deeb1 ("nvme: track shared namespaces") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Reviewed-by: Sagi Grimberg Reviewed-by: John Garry Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit b4af7999a998787d5eb6facb5a333e04a4f1d2d9 Author: Yehyeong Lee Date: Tue Aug 18 20:04:05 2026 +0900 nvme-tcp: check the data direction of a C2HData PDU commit f83af377c148f6ad94b41c0e8313f12adf45e1c1 upstream. nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14 Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 7df913a7ced5d7349f0b23bdcf25ad54fe83a1c1 Author: Niklas Cassel Date: Fri Aug 14 16:38:34 2026 +0200 nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails commit 56e6279266f6962bb2d38a54397e3c605165b0c5 upstream. nvmf_create_ctrl() owns the fabrics options and frees them whenever ->create_ctrl() returns an error, so a transport must not free them on its own error paths. nvme-fc tracks this by testing ctrl->ctrl.opts in nvme_fc_ctrl_free(), which requires nvme_fc_init_ctrl() to clear that pointer on every error exit. The coupling is implicit, and commit 1a9e218195a5 ("nvme: split device add from initialization") broke it by adding a second error exit. When nvme_add_ctrl() fails, nvme_fc_init_ctrl() jumps to out_put_ctrl:, past the "ctrl->ctrl.opts = NULL" that only sits on the fail_ctrl: path, so nvme_fc_ctrl_free() frees the options and nvmf_create_ctrl() frees them a second time: BUG: KASAN: slab-use-after-free in nvmf_free_options+0x30/0x190 nvmf_free_options+0x30/0x190 drivers/nvme/host/fabrics.c:1284 nvmf_create_ctrl drivers/nvme/host/fabrics.c:1374 [inline] Freed by task 5534: nvme_fc_ctrl_free drivers/nvme/host/fc.c:2374 [inline] nvme_fc_init_ctrl+0xe17/0x1450 drivers/nvme/host/fc.c:3605 nvme_add_ctrl() fails when dev_set_name() cannot allocate, so this is reachable under memory pressure or fault injection. Without KASAN the options are freed twice. Rather than clear the pointer on the second exit as well, derive ownership the way nvme-tcp, nvme-rdma and nvme-loop do, from list membership: their free_ctrl leaves the options alone unless the controller made it onto the transport list. The list cannot simply be populated on the success path as it is there. nvme-fc runs the initial connect synchronously via flush_delayed_work(), and the controller has to be reachable on rport->ctrl_list for the whole of it: nvme_fc_unregister_remoteport() needs to find it to signal connectivity loss, nvme_fc_match_disconn_ls() matches an incoming Disconnect Association LS against ctrl->association_id, which is only assigned during that window, nvme_fc_resume_controller() needs it on remoteport re-registration, and nvme_fc_existing_controller() uses it to reject a duplicate connect racing the one in flight. Keep the insertion where it is and add a fail_unlist: label, falling into fail_ctrl:, for the error paths that run after it. The earlier error paths never reach the insertion and keep using fail_ctrl: directly, so the list is only touched where the controller is actually on it. nvme_fc_ctrl_free() cannot use the plain "goto free_ctrl" the other transports use, because it still has to put_device(), release the rport reference and free the ida entry for resources taken before the insertion. Sample list_empty() under rport->lock instead. ctrl->ctrl.opts also stays valid for the whole teardown now. That is not the bug being fixed, but it removes some fragility around the old idiom: nvme_free_ctrl() calls nvme_auth_free() before ->free_ctrl(), and ctrl_max_dhchaps() dereferences ctrl->opts without a NULL check when ctrl->dhchap_ctxs is set, which nvme-fc permits since NVMF_ALLOWED_OPTS allows the dhchap options. The nvme sysfs attributes that dereference ctrl->opts, such as hostnqn and address, evaluate their is_visible() test once at device_add() time and stay readable until cdev_device_del(). Fixes: 1a9e218195a5 ("nvme: split device add from initialization") Cc: stable@vger.kernel.org Reported-by: syzbot+f58e57380a6083c4041d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f58e57380a6083c4041d Signed-off-by: Niklas Cassel Tested-by: Rihyeon Kim Reviewed-by: Hannes Reinecke Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 15d7a35a489287109b5a7c157d53d9b8214f0318 Author: Xu Rao Date: Thu Aug 13 16:31:07 2026 +0800 nvme-fabrics: fix DHCHAP secret leak on parse failure commit afdee49a1b88ed9bb44e2b30e855297c169bcc53 upstream. nvmf_parse_options() duplicates dhchap_secret and dhchap_ctrl_secret with match_strdup() before validating the DHHC-1: representation. If validation fails, the parser returns -EINVAL before the temporary string in p is assigned to opts->dhchap_secret or opts->dhchap_ctrl_secret. nvmf_create_ctrl() subsequently frees opts, but nvmf_free_options() cannot release the unassigned temporary string. Each rejected option therefore leaks one allocation. This is easy to miss because valid secrets transfer ownership to opts and are freed normally, while the malformed-secret path still returns the expected -EINVAL to userspace. With CONFIG_NVME_HOST_AUTH enabled, the leak is reachable before the required-option checks and transport lookup. No NVMe-oF target or working transport connection is required; for example, repeatedly writing dhchap_secret=BAD or dhchap_ctrl_secret=BAD to /dev/nvme-fabrics deterministically takes the leaking parse path. Free the temporary string before leaving both validation error paths. Use kfree_sensitive() because the copied option may contain secret material even when its representation is rejected, matching the sensitive cleanup used for stored DHCHAP secrets. Fixes: f50fff73d620 ("nvme: implement In-Band authentication") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Xu Rao Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 7ad2ea7c10044b08ecf7b04376916faf12e17a99 Author: Takashi Iwai Date: Fri Aug 28 13:55:39 2026 +0200 ALSA: pcm: Fix race between non-atomic ops and trigger-start commit acac7b5e07349a9d10d78873afb4b93cd1dc721f upstream. We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running. Reported-by: syzbot+225231fce6755d40d078@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a8f0de8.1d9ded08.62e62.00b5.GAE@google.com Cc: Link: https://patch.msgid.link/20260828115542.3999-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 89992bda7dfbba7ded2ba4185730453c57fa65bc Author: Runyu Xiao Date: Sun Aug 30 14:34:11 2026 +0800 ALSA: harmony: initialize locks before requesting IRQ commit 33abb7491e89285a41565670945293dda841afc4 upstream. snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260830063411.2215691-1-runyu.xiao@seu.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1e67ad10373ea2112310ec525eecba91a292481f Author: HyeongJun An Date: Wed Sep 2 21:50:58 2026 +0900 ALSA: rawmidi: Return the error from snd_rawmidi_input_params() commit f4a23e17d84fd2a152d9e12369761934e1af0ee8 upstream. The snd_rawmidi_input_params() computes err for the three invalid mode combinations and for resize_runtime_buffer(), applies the new framing and clock type only when err is zero, and then returns 0 anyway. A caller that asked for parameters the kernel rejected is told the change succeeded, and the substream keeps its old buffer. The open_mutex conversion turned the early returns into assignments. It handled the output sibling correctly, which still returns err, and left this one behind. Fixes: 94b98194b62e ("ALSA: rawmidi: Take open_mutex around parameter changes") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260902125058.19499-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cd090af03f5dfa137ef2cb460cd131ce913f053f Author: Khushit Shah Date: Mon Aug 31 10:54:44 2026 +0000 arm64: errata: pass REVIDR when matching target implementation CPUs commit 5541432e09dc2031978188f3e8a00b9fc78cf097 upstream. When target implementation CPUs are provided, is_affected_midr_range() accidentally passed the MIDR as both arguments to __is_affected_midr_range(), so the REVIDR mask check operated on the wrong register. Pass REVIDR as intended. Fixes: 86edf6bdcf05 ("smccc/kvm_guest: Enable errata based on implementation CPUs") Cc: stable@vger.kernel.org Signed-off-by: Khushit Shah Reviewed-by: Zenghui Yu (Huawei) Acked-by: Marc Zyngier Reviewed-by: Shameer Kolothum Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 68cbd70795dd8c06e7ccdc4eb0b74c5b180076c3 Author: Karl Mehltretter Date: Fri Aug 28 19:41:31 2026 +0200 arm64: mm: Fix the lockless page-table walk in show_pte() commit a77644d009dece1104b6fcc6e322b0e4503db0d6 upstream. show_pte() walks page tables locklessly and can run with interrupts enabled. A concurrent teardown can free a table page while it is being walked. It can also clear a parent entry after show_pte() checked it; the regular pXd_offset() helpers then reread the cleared entry and can derive a bogus lower-level pointer and fault again. Use the lockless offset helpers with the saved parent entries, as gup_fast() does, and pass the saved PMD to pte_offset_map(). For task page tables, arm64 selects MMU_GATHER_RCU_TABLE_FREE. Disable local interrupts around the walk to hold off RCU-deferred table frees and block the tlb_remove_table_sync_one() IPI until the walk is finished. Place the IRQ guard after the header print. This does not make the output a consistent snapshot, but prevents the task page-table walk from dereferencing a released table page or deriving a pointer from a different parent value. Fixes: 1d18c47c735e ("arm64: MMU fault handling and page table management") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 2b3b06cb709c4bf75a3fe3da3a0ca368ee3b40e5 Author: Ahmad Byagowi Date: Sun Aug 23 09:34:36 2026 -0700 i2c: mux: Fix channel node leak on adapter add failure commit 385c7af4e3b95d0769fd211831674e83b16a2ebf upstream. i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data. Fixes: bc45449b1444 ("i2c/of: Automatically populate i2c mux busses from device tree data.") Signed-off-by: Ahmad Byagowi Cc: # v3.5+ Acked-by: Peter Rosin Signed-off-by: Andi Shyti Link: https://patch.msgid.link/b3e46bbee781b3cb4029aca9a71316cc5e36dc17.1787502619.git.ahmadexp@gmail.com Signed-off-by: Greg Kroah-Hartman commit 112b3d48084c820bbccf41d9783fd122e3ac4cb0 Author: Vasileios Almpanis Date: Wed Aug 12 11:14:48 2026 +0200 i2c: core: fix debugfs UAF on adapter removal commit b15b548d52b43ba8ac4652bc2c7244a8dd1e9622 upstream. i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left. Fixes: 73febd775bdb ("i2c: create debugfs entry per adapter") Reported-by: syzbot+23ad911c819b923238b7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=23ad911c819b923238b7 Signed-off-by: Vasileios Almpanis Cc: # v6.8+ Tested-by: syzbot+23ad911c819b923238b7@syzkaller.appspotmail.com Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260812-i2c-v2-1-5efaab4c3334@gmail.com Signed-off-by: Greg Kroah-Hartman commit 954f30c8df0a07ea11bb93e6378d9ebb88b44b53 Author: Kathiravan Thirumoorthy Date: Wed Aug 12 14:00:55 2026 +0530 i2c: qcom-geni: update frequency table to fix timing parameters commit a4f3fbccb65de757569686baaf2b72e329096aba upstream. In IPQ5424, to meet the setup and hold timing requirements in the standard mode, update the frequency table with the values recommended by HW design team. Also remove the stray space in the I2C_MAX_FAST_MODE_FREQ entry. Fixes: 85c34532849d ("i2c: qcom-geni: fix I2C frequency table to achieve accurate bus rates") Fixes: 506bb2ab0075 ("i2c: qcom-geni: Support systems with 32MHz serial engine clock") Signed-off-by: Kathiravan Thirumoorthy Cc: # v6.13+ Reviewed-by: Mukesh Savaliya Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260812-ipq5424_i2c_scl_updates-v2-1-e09cd39d01d7@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit c643b6e7852e9fa35ebe258d3a14b2e5cb47cafe Author: Hongbo Yao Date: Wed Aug 26 15:05:47 2026 +0800 i2c: designware: Enable interrupt mask workaround for HJMC3001 commit 77549d01edecc20da73c8599e14648877198ce9b upstream. On HJMicro ARM64 servers, the DesignWare I2C controller does not retrigger a pending interrupt if the interrupt status changes after the current status bits have been cleared. The issue is exposed under heavy system load when the corresponding SPI is routed across sockets to a core in the remote socket. The interrupt is then lost and the I2C transfer times out. Enable ACCESS_INTR_MASK for HJMC3001. This toggles DW_IC_INTR_MASK before returning from the interrupt handler and retriggers any pending interrupt. Fixes: 6816ce57c479 ("i2c: designware: Add a new ACPI HID for HJMC01 I2C controller") Signed-off-by: Hongbo Yao Cc: # v6.13+ Acked-by: Mika Westerberg Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260826070547.268672-1-andy.xu@hj-micro.com Signed-off-by: Greg Kroah-Hartman commit 19d65da9f749785a3a4606583174529113f4f058 Author: Sizhe Liu Date: Thu Jul 30 14:27:07 2026 +0800 perf hisi-ptt: Fix PTT trace TLP header parsing commit 2b8a2e5d424f0b3369054305d0bf6a5b9faee6c1 upstream. TLP Headers traced by HiSilicon PCIe tune and trace device (PTT) in 4DW format are shown in the document as below: bits [31:30] [ 29:25 ][24][23][22][21][ 20:11 ][ 10:0 ] |-----|---------|---|---|---|---|-------------|-------------| DW0 [ Fmt ][ Type ][T9][T8][TH][SO][ Length ][ Time ] DW1 [ Header DW1 ] DW2 [ Header DW2 ] DW3 [ Header DW3 ] Problem: The DW0 bit field layout of the hisi_ptt_4dw union does not match the actual bit ordering in little-endian memory, causing incorrect field decoding. Test on Kunpeng 930 SOC, generating data flow with `iperf` commands: - server side: iperf -s - client side: iperf -c $ip_addr -t 30 Trace the TLP headers with hisi_ptt on server side at the same time: perf record -e hisi_ptt12_0/type=4,filter=0x05101,direction=2,format=0/ \ --max-size 50M -o perf.data & The trace aims to capture completion TLPs, learn more in the document: https://docs.kernel.org/trace/hisi-ptt.html Decode perf.data with hisi_ptt decoder: perf report -D The hisi_ptt decoder produces the following result: [...perf headers and other information] . ... HISI PTT data: size 8388608 bytes . 00000000: 68 87 20 94 Format 3 Type 1a T9 0 T8 1 TH 1 SO 1 Length 10 Time 4a1 . 00000004: 40 00 00 00 Header DW1 . 00000008: 40 00 01 51 Header DW2 . 0000000c: 00 00 00 00 Header DW3 [...other hisi_ptt TLP headers] According to PCIe r5.0 sec 2.2.1, the Fmt & Type of Cpl/CplD is supposed to be 8b'00001010' / 8b'01001010' However, the Format & Type decoder analyzing result is 8b'01111010'. It does not match field encodings of any TLP. Correct decoder result should be: [...perf headers and other information] . ... HISI PTT data: size 8388608 bytes . 00000000: 94 20 87 68 Format 2 Type a T9 0 T8 0 TH 0 SO 1 Length 10 Time 768 . 00000004: 00 00 00 40 Header DW1 . 00000008: 51 01 00 40 Header DW2 . 0000000c: 00 00 00 00 Header DW3 [...other hisi_ptt TLP headers] To solve the problem: 1. Drop the union and C bitfield struct, store the raw DW value in a plain uint32_t, and extract the fields with FIELD_GET() against GENMASK/BIT masks declared in the header so they can be reused by other translation units. The masks are portable across endianness and compilers. 2. Print all DW hex values in big-endian byte order for readability, matching the bit field layout shown in the 4DW format diagram. 3. Read the DW value with get_unaligned_le32() instead of an unaligned pointer cast, avoiding both strict-aliasing violations and alignment hazards on hosts that do not support unaligned access. Cc: stable@vger.kernel.org Fixes: 5e91e57e6809 ("perf auxtrace arm64: Add support for parsing HiSilicon PCIe Trace packet") Reviewed-by: James Clark Signed-off-by: Sizhe Liu Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit 2421389840738c782ab70a36c85c21384b817602 Author: Viktor Malik Date: Tue Jul 7 08:52:47 2026 +0200 perf trace: Refactor augmented_raw_syscalls using bpf_for commit ea6992784d65ef2c01f3525217dbf3a44afa9917 upstream. The loop for processing syscall args in augment_raw_syscalls has a history of breaking with Clang updates, see e.g. commit 013eb043f37b ("perf trace: Fix BPF loading failure (-E2BIG)") from Clang 15 to 16. Now, a similar thing happened between Clang 21 and 22. While the issue is mitigated on the main line by a recent verifier update, it remains broken on the 6.12 and 6.18 stable branches: [linux-6.18.y]# sudo perf trace true libbpf: prog 'sys_enter': BPF program load failed: -E2BIG libbpf: prog 'sys_enter': -- BEGIN PROG LOAD LOG -- [...] BPF program is too large. Processed 1000001 insn processed 1000001 insns (limit 1000000) max_states_per_insn 40 total_states 37941 peak_states 232 mark_read 0 -- END PROG LOAD LOG -- libbpf: prog 'sys_enter': failed to load: -E2BIG libbpf: failed to load object 'augmented_raw_syscalls_bpf' libbpf: failed to load BPF skeleton 'augmented_raw_syscalls_bpf': -E2BIG Error: failed to get syscall or beauty map fd [...] The reason is that the loop is quite complex and the BPF verifier often struggles to prove that it terminates. Fix the issue by replacing the standard for loop with the bpf_for macro, which uses a numeric BPF iterator. This should prevent future breakages of this kind since the verifier has a much easier job proving that the loop terminates. Small adjustments were necessary for the loop to make it work. The main problem is that the verifier sometimes has problems with bpf_for loops that use a carry-over state, such as the `payload_offset` and `output` vars here, since the verifier tries to track their values too precisely and cannot prove loop convergence. To resolve the issue, we (1) explicitly recompute `payload_offset` in every iteration and (2) use a trick with adding a global zero to `output` to help the verifier forget its precise state and use a range instead. Finally, to keep backwards compatibility with older kernel versions that don't have bpf_for (i.e. numeric iterators), fall back to standard loop. Signed-off-by: Viktor Malik Cc: stable@vger.kernel.org Suggested-by: Andrii Nakryiko Fixes: a68fd6a6cdd3 ("perf trace: Collect augmented data using BPF") Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit f3a6663138496a66f90636f6917d42fb19f701b6 Author: Viktor Malik Date: Tue Jul 7 08:52:46 2026 +0200 perf trace: Factor out BPF loop body commit acff3e1a9cc29a6a039b76b81a438c56016bc0e3 upstream. The BPF program in augmented_raw_syscalls uses a for loop to iterate all syscall arguments. The loop body is quite complex and often poses problems for the BPF verifier. As a preparation step for addressing this issue, factor out the loop body into a separate function. Signed-off-by: Viktor Malik Cc: stable@vger.kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit 3c492c8eba02698ca893a9a13388d2adf6dfb839 Author: Dapeng Mi Date: Tue Jun 16 12:46:50 2026 +0800 perf/x86/intel: Fix kernel address leakages in LBR stack commit e2b0575900ff72aa82748af96e7bd564ade5157a upstream. Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks. Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR") Reported-by: Ian Rogers Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260616044654.3468742-5-dapeng1.mi@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 267f0a4fb9fe7fa35fb15f8e1fecc472b2b952d9 Author: Lad Prabhakar Date: Fri Aug 21 22:10:21 2026 +0100 rtc: rzn1: Disable alarm interrupt before reprogramming alarm registers commit 51458d5b0a1cfb1b6013400abc95aadf16ed2a57 upstream. rzn1_rtc_set_alarm() updates RZN1_RTC_ALM, RZN1_RTC_ALH and RZN1_RTC_ALW using separate MMIO writes without first disabling the alarm interrupt. If a previous alarm is still enabled, the interrupt can fire while the alarm registers contain a mixture of old and newly written values. Fix this by disabling the alarm interrupt before reprogramming ALM, ALH and ALW with a call to rzn1_rtc_alarm_irq_enable(). Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-7-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 3a2b79eae5bef7bcf560fee36e4686a0ba27caf6 Author: Lad Prabhakar Date: Fri Aug 21 22:10:19 2026 +0100 rtc: rzn1: Handle unset alarm weekday in rzn1_rtc_read_alarm commit 457b5dbce31209e65e1184716ed3af59cb1c0372 upstream. RZN1_RTC_ALW is a weekday bitmask where bit N represents weekday N. When no alarm has been configured, the register has its power-on-reset value of zero. rzn1_rtc_read_alarm() uses fls() to convert the weekday bitmask into a weekday number. When RZN1_RTC_ALW is zero, fls(0) returns zero and fls(wday) - 1 evaluates to -1. This invalid weekday is then used to calculate the alarm date and can either leave tm_wday set to -1 or produce a fabricated alarm date. Treat a zero RZN1_RTC_ALW value as an unset alarm weekday and return without calculating the alarm date. Move reading RZN1_RTC_CTL1 before this check so that alrm->enabled is updated for both configured and unconfigured alarms. Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit a4d6666a65d6f2ffd0537ec53576aa662e5c84c1 Author: Lad Prabhakar Date: Fri Aug 21 22:10:18 2026 +0100 rtc: rzn1: Fix weekday underflow when alarm crosses month boundary commit 022a2839a52006531804a8db55d3228084400b48 upstream. rzn1_rtc_set_alarm() calculates the alarm weekday from the difference between the alarm day and the current day of the month. When the alarm crosses a month boundary, this difference can become negative. Since days_ahead is unsigned, it underflows and results in an incorrect weekday being programmed into RZN1_RTC_ALW. The RTC core already provides a fully populated struct rtc_time for the alarm, including the correct tm_wday. Use tm->tm_wday directly instead of recalculating the weekday from the day-of-month. This avoids the underflow and ensures alarms scheduled across a month boundary use the correct weekday. Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Suggested-by: Wolfram Sang Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 350cb7821b3d2c4bd1dfcceb64ace82405c25f0f Author: Lad Prabhakar Date: Fri Aug 21 22:10:17 2026 +0100 rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt commit 708546aa39560a11cf44c7ba99492c8395a6c2fb upstream. Check for -EPROBE_DEFER from platform_get_irq_byname_optional() and handle the deferred probe request properly. Although the "pps" interrupt is optional, an error code of -EPROBE_DEFER indicates that the interrupt subsystem is not yet ready. Intercept this specific error condition, assign it to the return value, and jump to the dis_runtime_pm label to avoid ignoring a valid probe deferral. Fixes: eea7791e00f33 ("rtc: rzn1: implement one-second accuracy for alarms") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 0a90e268cce7023f34087bfa4affb42e29ff5f45 Author: Shakeel Butt Date: Tue Aug 11 13:31:55 2026 -0700 memcg: make the v1 soft limit knob inert commit a3417097fb107cea3358b19bcbb4eb655fd67f8c upstream. The v1 soft limit has been deprecated since v6.12 and nobody has reported depending on it. Start the removal by decoupling the interface from the implementation: keep memory.soft_limit_in_bytes, but ignore writes to it and always report the maximum value on read similar to what memory.kmem.limit_in_bytes already does. Writes are still parsed, so malformed input keeps returning -EINVAL. The knob now also behaves the same everywhere: it used to return -EOPNOTSUPP on PREEMPT_RT, where soft limit reclaim has always been disabled. This also fixes the syzbot report linked below. Soft limit reclaim is the only caller that runs shrink_lruvec() from kswapd against a specific memcg, so it is the only way to reach lru_gen_shrink_lruvec() and in turn set_mm_walk(), which warns when called from kswapd. Link: https://lore.kernel.org/20260811203203.3456029-2-shakeel.butt@linux.dev Signed-off-by: Shakeel Butt Reported-by: syzbot+12ee2725d5fde63a9c96@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a7a6929.b50370da.49fe0.005e.GAE@google.com/ Acked-by: Michal Hocko Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Johannes Weiner Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 801bcbdbfd595cc7f0de95f2802b5596c8971315 Author: Shakeel Butt Date: Tue Jul 28 19:46:12 2026 -0700 memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done commit 6b0d1083364fc8e7cc2f7d1f93ee3ee78f4d52f7 upstream. At Meta, we are seeing instances where an OOM killed job is stuck in the exit path for several hours. In one particular case, the job was stuck for more than 8 hours and I had to manually remove the memory.max limits to allow the process to exit. The job was a single process job and had ~55 GiB memory.max and zswap enabled. It had almost 0 anon in memory and ~111 GiB in zswap compressed to ~51 GiB zswap pool (i.e. almost all of memory.current was zswap). Nothing was left on the LRUs to reclaim. On further inspection, I observed ~20k threads of that process stuck with the following stack: [<0>] mem_cgroup_out_of_memory+0x4e/0xa0 [<0>] charge_memcg+0x8bf/0x990 [<0>] mem_cgroup_swapin_charge_folio+0x4e/0x80 [<0>] __read_swap_cache_async+0x10c/0x260 [<0>] swapin_readahead+0x116/0x3f0 [<0>] do_swap_page+0x13c/0x1ce0 [<0>] handle_mm_fault+0x61d/0x11f0 [<0>] do_user_addr_fault+0x3e7/0x6d0 [<0>] exc_page_fault+0x8f/0x110 [<0>] asm_exc_page_fault+0x22/0x30 [<0>] __get_user_8+0x14/0x20 [<0>] futex_cleanup+0x27/0x1c0 [<0>] futex_exit_release+0x47/0x60 [<0>] do_exit+0x107/0x940 [<0>] do_group_exit+0x81/0xa0 [<0>] get_signal+0x2b1/0x6e0 [<0>] arch_do_signal_or_restart+0x1a/0x1c0 [<0>] exit_to_user_mode_loop+0xa8/0x1c0 [<0>] do_syscall_64+0x152/0x250 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 In addition the dmesg was filled with "Out of memory and no killable processes..." messages. I have no idea why oom reaper was not able to reap/unmap the process. My guess is that since oom reaper tries to acquire mmap_lock in read mode limited number of times and then gives up, there might be a thread of that process which had mmap_lock in write mode at that time. My initial suspicion was the futex_cleanup and kernel page fault causing infinite fault and charge retries but that was put to rest in previous discussions happened on similar problem [1]. My current theory is that it is just a simple slow serialization behind the oom_lock. Unlike page allocator, memcg charge code takes the oom_lock without the "try". Though memcg oom code uses mutex_lock_killable(), note that in the call stack get_signal() consumes SIGKILL (or sigdelset(SIGKILL)) before calling do_group_exit(). So this mutex_lock_killable() is just a mutex_lock() here. Therefore 10s of thousands of threads are waiting on oom_lock and one by one they get -EFAULT from get_user() in the futex cleanup code and bails out. Discussion from [1] led to commit a75ffa26122b ("memcg, oom: do not bypass oom killer for dying tasks") which routes dying tasks into the OOM path precisely so the oom_reaper can reap their mm and free the memory asynchronously. But the reaper is best-effort and one-shot: if it cannot take mmap_lock for read (e.g. a sibling thread holds it for write) it sets MMF_OOM_SKIP and never retries, leaving only the glacial oom_lock-serialized synchronous drain. Once MMF_OOM_SKIP is set there is no more asynchronous reclaim coming for the mm, so a dying task charging against it has nothing left to wait for: it frees its memory only once it finishes exiting. Running reclaim and the (no-victim) OOM killer for it is then pointless, and doing it for 10s of thousands of exiting threads is what serializes them behind oom_lock. So before reclaim, if current is an OOM victim whose reaper is done, fail the charge. Reproduced with 20k threads, each parking a robust futex head on its own zswapped page, OOM-group-killed while a sibling holds mmap_lock for write so the reaper gives up and sets MMF_OOM_SKIP. Tested on next-20260728 and baseline show ~90 seconds exit time while with the patch the exit time reduced to ~3 seconds. Link: https://lore.kernel.org/20260729024612.3369005-1-shakeel.butt@linux.dev Link: https://lore.kernel.org/7a4e5591f45df455e6a485fc5400989569d3d22d.camel@surriel.com/ [1] Signed-off-by: Shakeel Butt Acked-by: Johannes Weiner Acked-by: Michal Hocko Cc: David Rientjes Cc: Muchun Song Cc: Nhat Pham Cc: Rik van Riel Cc: Roman Gushchin Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7269bd95d707e26da9ec343ccf20cbdb06d1933e Author: Pengpeng Hou Date: Mon Apr 6 21:52:34 2026 -0700 Input: aiptek - validate raw macro indices before updating state commit 95dffe32a66cbed07fbfa7afed39d56d5014e04f upstream. aiptek_irq() derives macro key indices directly from tablet reports and then uses them to index macroKeyEvents[]. Report types 4 and 5 also save the derived value in aiptek->lastMacro and later use that state to release the previous key. Validate the raw macro index once before it enters that state machine, so lastMacro only ever stores an in-range macro key. Keep direct bounds checks for report type 6, which reads the macro number from the packet body and uses it immediately. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260329001711.88076-1-pengpeng@iscas.ac.cn [dtor: fix macro fallback in report 5s to use -1] Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d07e281f2a7710502985d6f80b95ddac8f4e81d5 Author: HE WEI（ギカク） Date: Wed Jun 10 09:29:29 2026 +0900 fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list() [ Upstream commit 7c4841e2a62794a3bab7c1ff0540580f387e377f ] ni_create_attr_list() allocates a fixed buffer of al_aligned(record_size) (== record_size) bytes and then walks every attribute of the primary MFT record, writing one ATTR_LIST_ENTRY per attribute and advancing the cursor by le_size(name_len), with no check against the end of the buffer; the total size is only computed after the loop. A minimum-size resident attribute occupies SIZEOF_RESIDENT (0x18 = 24) bytes on disk, but an unnamed attribute expands to le_size(0) (0x20 = 32) bytes in the list. Because the number of attributes in a record is not bounded (mi_enum_attr() accepts arbitrarily many equal-type, nameless minimum-size attributes), a crafted record packed with such attributes produces a list larger than record_size and overflows the heap buffer. This is reachable from a crafted, loop-mounted NTFS image: opening the file and adding an attribute (e.g. via setxattr) drives ntfs_set_ea() -> ni_insert_resident() -> ni_insert_attr() -> ni_ins_attr_ext() -> ni_create_attr_list(). BUG: KASAN: slab-out-of-bounds in ni_create_attr_list+0xc48/0x1058 Write of size 4 at addr ffff000008984c00 by task setfattr/345 ni_create_attr_list+0xc48/0x1058 ni_ins_attr_ext+0x510/0x7c0 ni_insert_attr+0x3f8/0x70c ni_insert_resident+0xc8/0x3b0 ntfs_set_ea+0x66c/0xd28 ntfs_setxattr+0x4d8/0x5b0 __arm64_sys_setxattr+0xa4/0x124 Allocated by task 345: ni_create_attr_list+0x188/0x1058 The buggy address belongs to the cache kmalloc-1k of size 1024 (the write lands at object+1024). Size the buffer from the actual attributes instead of assuming a single record_size is always enough. Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: HE WEI（ギカク） Signed-off-by: HE WEI（ギカク） Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 4d6ccd3883df6df1e33229d22d02b8c0dbfcb98a Author: Nirbhay Sharma Date: Tue Oct 7 04:08:04 2025 +0530 fs/ntfs3: fix KMSAN uninit-value in ni_create_attr_list [ Upstream commit 5f33da04e6ceee849e76e6592cc283c72fef7af9 ] The call to kmalloc() to allocate the attribute list buffer is given a size of al_aligned(rs). This size can be larger than the data subsequently copied into the buffer, leaving trailing bytes uninitialized. This can trigger a KMSAN "uninit-value" warning if that memory is later accessed. Fix this by using kzalloc() instead, which ensures the entire allocated buffer is zero-initialized, preventing the warning. Reported-by: syzbot+83c9dd5c0dcf6184fdbf@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=83c9dd5c0dcf6184fdbf Signed-off-by: Nirbhay Sharma Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 0ceda28f371df9e0bbdaa29214f71fe8298f23d8 Author: Eric Dumazet Date: Fri Aug 21 17:04:07 2026 +0000 mm/mempolicy: fix sleeping allocation in alloc_pages_bulk_weighted_interleave() commit 540e583b66d6402bf556fde5e53c817a54c1afe5 upstream. syzbot reported a sleeping function called from invalid context splat in bucket_table_alloc(). When rhashtable_insert_slow() rehashes the table under rcu_read_lock(), it calls bucket_table_alloc(..., GFP_ATOMIC | __GFP_NOWARN). If the bucket table allocation uses vmalloc, __vmalloc_node_range_noprof() invokes vm_area_alloc_pages() -> alloc_pages_bulk_mempolicy_noprof() with the passed GFP_ATOMIC flags. If the current task has an MPOL_WEIGHTED_INTERLEAVE mempolicy, alloc_pages_bulk_weighted_interleave() is called and currently hardcodes GFP_KERNEL when allocating the temporary weights array, triggering a might_alloc() splat in atomic/RCU contexts. Pass the gfp flags (masked with GFP_RECLAIM_MASK to strip page-allocator zone modifiers like __GFP_HIGHMEM) received by alloc_pages_bulk_weighted_interleave() to kmalloc() instead of hardcoding GFP_KERNEL. Since the weights buffer is immediately initialized in full, kmalloc() is sufficient. Link: https://lore.kernel.org/20260821170407.3721004-1-edumazet@google.com Fixes: fa3bea4e1f82 ("mm/mempolicy: introduce MPOL_WEIGHTED_INTERLEAVE for weighted interleaving") Signed-off-by: Eric Dumazet Reported-by: syzbot+0dbf6d295b3350944f0b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/6a88837e.ae6ddae5.3da009.0040.GAE@google.com/T/#u Reviewed-by: Andrew Morton Reviewed-by: Gregory Price (Meta) Acked-by: David Hildenbrand (Arm) Cc: Alistair Popple Cc: Byungchul Park Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5da247e4d1e8661d4d6f997101d59967e8994e32 Author: Masami Hiramatsu (Google) Date: Sun Aug 30 23:27:23 2026 +0900 kprobes: Protect kprobe_blacklist with RCU commit 0c4256196b3a105307e2235fbfd85e768bbcdd0f upstream. __within_kprobe_blacklist() traverses kprobe_blacklist without holding kprobe_mutex. When a module is unloaded, kprobe_remove_area_blacklist() removes blacklist entries and immediately frees them with kfree(). A concurrent call to within_kprobe_blacklist() can therefore dereference freed memory. Furthermore, within_kprobe_blacklist() can be called in atomic or non-preemptible contexts where the sleeping kprobe_mutex cannot be taken. Protect kprobe_blacklist with RCU. Use guard(rcu)() and list_for_each_entry_rcu() for traversal, list_add_tail_rcu() for insertions, list_del_rcu() for deletions, and kfree_rcu() to reclaim entries safely after a grace period. Link: https://lore.kernel.org/all/178810004323.64882.16493230858653316962.stgit@devnote2/ Fixes: 376e242429bf ("kprobes: Introduce NOKPROBE_SYMBOL() macro to maintain kprobes blacklist") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260807155802.F06041F000E9@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.7-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 863f6726a5c02a309b8cfcb1e1be5c8b1dd7b59a Author: Ju Nan Date: Fri Aug 21 10:47:57 2026 +0800 irqchip/stm32mp-exti: Fix the unit of the hwspinlock timeout commit d31fbbade43f880b7e59e2b3a72722fe2725d93f upstream. HWSPNLCK_TIMEOUT is passed to hwspin_lock_timeout_in_atomic(), whose timeout argument is in milliseconds, not microseconds: atomic_delay += HWSPINLOCK_RETRY_DELAY_US; if (atomic_delay > to * 1000) return -ETIMEDOUT; So stm32mp_exti_set_type() asks for a 1 second timeout where the comment next to the macro says it wants 1 millisecond. The semaphore is polled with udelay() from a section that holds chip_data->rlock, a raw_spinlock_t, so preemption stays disabled for the whole wait on every configuration, PREEMPT_RT included. The hwspinlock core documents this explicitly: If the mode is HWLOCK_IN_ATOMIC (called from an atomic context) the timeout is handled with busy-waiting delays, hence shall not exceed few msecs. Fixes: 5257169ade8c ("irqchip/stm32-exti: Use the hwspin_lock_timeout_in_atomic() API") Signed-off-by: Ju Nan Signed-off-by: Thomas Gleixner Reviewed-by: Radu Rendec Reviewed-by: Antonio Borneo Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260821024756.24927-2-junan76@163.com Signed-off-by: Greg Kroah-Hartman commit f8a2f2a4602318eb93d49d27fd0d0fdaab17edde Author: Bradley Morgan Date: Thu Aug 27 17:43:38 2026 +0000 ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() commit 8861f6d5c0678a7c5089c7b272509fc5931b8437 upstream. dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing. Fixes: 4f2946aa0c45 ("IMA: introduce a new policy option func=SETXATTR_CHECK") Cc: stable@vger.kernel.org Reported-by: syzbot+5ebeb3089ea6439c37be@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/6a8f89e5.1d9ded08.62e62.00bf.GAE@google.com/ Signed-off-by: Bradley Morgan Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 685c195fbd7d4c4af3234ac31276640d96888e32 Author: Hajo Noerenberg Date: Mon Aug 31 14:43:03 2026 +0200 ata: ahci: work around lost interrupts on Marvell 88SE61xx commit dc3565a4ae538e584e5e63b3b3cd1eaf502593c1 upstream. ahci_single_level_irq_intr() services the ports first and clears the global HOST_IRQ_STAT afterwards, as recommended by AHCI 1.1 section 10.6.2. The Marvell 88SE6111/6121/6145 family stops reporting interrupts for a port when HOST_IRQ_STAT is cleared while PxIS still holds bits: PxIS keeps its content, HOST_IRQ_STAT reads back as 0, the port is never looked at again, and the command in flight only ends in a timeout. Measured on a Seagate Blackarmor NAS440 (Marvell 88F6281 Kirkwood, 88SE6121 rev B2 behind PCIe) by polling the AHCI registers from userspace while an IDENTIFY was outstanding: t=303.046 irqs 127 PxIS 0x00000000 PxCI 0x00000001 IDENTIFY issued t=303.057 irqs 128 PxIS 0x00000020 PxCI 0x00000000 CI cleared, DPS set, one interrupt taken ... PxIS stays 0x00000020, HOST_IRQ_STAT stays 0 ... t~308.05 qc timeout after 5000 msecs The command had completed - PxCI was clear and PxIS had DPS set - so ahci_qc_complete() would have completed it. It never got the chance because the handler read HOST_IRQ_STAT as 0 and returned IRQ_NONE. Marvell's own driver for these chips clears the two registers in the opposite order and says so ("clear global before channel"), and ahci_xgene handles its broken edge latch the same way. Since the reordering costs at most one spurious interrupt per valid one on conforming controllers, do it in a private interrupt handler selected for board_ahci_mv instead of changing libahci for everyone. With this applied, SATA-2 and SATA-3 disks work at 3.0 Gbps on the 88SE6121 without the drive-side 1.5 Gbps jumper that was needed before. Time from link up to a successful IDENTIFY: WDC WD5000AADS-00S9B0 port 0 7 ms (never identified before) WDC WD3202ABYS-01B7A0 port 1 28 ms WDC WD30EFRX-68EUZN0 port 1 200 ms (3 TB, HPA detection ok) Only the 88SE6121 was tested; board_ahci_mv also covers the 88SE6145, which Marvell's driver treats identically. Fixes: cd70c26617f4 ("[libata] AHCI: Add support for Marvell AHCI-like chips (initially 6145)") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-ide/db6b48b7-d69a-564b-24f0-75fbd6a9e543@noerenberg.de/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=216094 Signed-off-by: Hajo Noerenberg Reviewed-by: Damien Le Moal Acked-by: Pali Rohar Link: https://lore.kernel.org/r/20260831124303.920391-1-hajo-linux-ide@noerenberg.de Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit ca5bfea2045ef2eb3305cf2a9d8da549b76c37d3 Author: Max Kellermann Date: Mon Aug 24 18:47:07 2026 +0200 ceph: lock mutex in ceph_mds_check_access() commit a61c6ae1dae2611082b831b4aaa780878099c012 upstream. MDS session OPEN handling replaces mdsc->s_cap_auths under mdsc->mutex, freeing the previous array and its strings. ceph_mds_check_access() traverses this array without holding the mutex. A concurrent session reopen can therefore free the array while it is being inspected, resulting in a use-after-free like this: Unable to handle kernel paging request at virtual address 003aaad64b2c8bb9 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 56 UID: 2953037534 PID: 1253231 Comm: php-cgi8.4 Not tainted 6.18.45-i2-ampere #1146 NONE [..] pc : ceph_mds_check_access+0xd4/0x550 lr : ceph_mds_check_access+0xc8/0x550 [...] Call trace: ceph_mds_check_access+0xd4/0x550 (P) ceph_atomic_open+0x138/0xbe8 path_openat+0xa24/0xfa8 do_filp_open+0x94/0x158 do_sys_openat2+0x88/0xf8 Cc: stable@vger.kernel.org Fixes: 596afb0b8933 ("ceph: add ceph_mds_check_access() helper") Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit a24a146ae2cb5d9faeea96d10010fcb6579abe1f Author: Hui Su Date: Fri Aug 7 01:56:00 2026 +0800 bpf: Fix infinite loop in pcpu_freelist push with one possible CPU commit efebf6496685c93150df5bb0794363ae70c5f58a upstream. __pcpu_freelist_push() can loop forever when only one CPU is possible and an NMI re-enters pcpu_freelist_push() while the interrupted context holds that CPU's freelist lock. After the current-CPU fast path fails, the fallback loop walks cpu_possible_mask while skipping the current CPU. With CONFIG_SMP=n, or when an SMP kernel is limited to one possible CPU with nr_cpus=1 or possible_cpus=1, there are no other possible CPUs to examine. The loop therefore makes no lock acquisition attempt and can never make progress. The following stack was observed on a UP system: NMI context: pcpu_freelist_push free_htab_elem htab_map_delete_elem [perf-event BPF program] __perf_event_overflow perf_event_nmi_handler exc_nmi Interrupted context: __pcpu_freelist_push pcpu_freelist_push free_htab_elem htab_map_delete_elem [raw_tp/sys_enter BPF program] __bpf_trace_sys_enter do_syscall_64 raw_res_spin_lock() detects the same-CPU recursive acquisition and returns -EDEADLK, but the subsequent fallback loop has no candidate head on a system with one possible CPU. Restore the extra fallback head that existed before the rqspinlock conversion. Keep the current-CPU fast path, then try the other possible CPUs and finally the extra head. The additional head lets a push, which cannot fail without losing a preallocated element, make progress when the only per-CPU head is held by the interrupted context. Also check the extra head from the pop path so that nodes placed there can be reused. Fixes: f2ac0e5d1c4d ("bpf: Convert percpu_freelist.c to rqspinlock") Signed-off-by: Hui Su Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260806175600.1993595-1-sh_def@163.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Greg Kroah-Hartman commit bfb469f20aa9ecad5fc9b42a5046d7ca360a863c Author: Damien Le Moal Date: Mon Aug 31 11:50:50 2026 +0900 block: flag zoned disks with GENHD_FL_NO_PART commit 3f9c7a108c0e8f14425384912017071b71341e3b upstream. Zoned block devices do not support partitions. However, the partition table is nevertheless still inspected, and any partition found ignored with a warning in add_partition(). While this is generally not a problem, and in fact beneficial to the user as it indicates an invalid use of a zoned block device, scanning for a partition table on the device may result in issuing read operations to offline zones (e.g. after a disk head is depopulated for disks that support head management operations). Since partitions are ignored anyway, completely disable partition scanning for zoned gendisks by setting the flag GENHD_FL_NO_PART in __add_disk(). The existing check in add_partition() is left as-is to ensure that we still get a warning if for whatever reason, despite GENHD_FL_NO_PART, we still endup trying to add partitions. Flagging zoned disks with GENHD_FL_NO_PART also has the benefit to expose through sysfs the ext_range attribute with the value of 1 instead of the default DISK_MAX_PARTS, thus correctly advertizing the fact that zoned disks do not support partitions. Fixes: 5eac3eb30c9a ("block: Remove partition support for zoned block devices") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Bart Van Assche Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260831025050.667758-1-dlemoal@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 634e2d23736d4ded7c0667d686d49036b81cb5bf Author: Ulf Hansson Date: Wed Aug 26 10:45:32 2026 +0200 cpuidle: psci: Fix support for probe deferral by dropping the faux device commit 0606f2114e2dc88fe293858fd991cda2688b8c3a upstream. At the conversion to the faux driver/device we broke the support for probe deferral. In hindsight, the move to the faux device seems questionable, as it simply makes the code more complicated and for no good reason. To fix the support for the probe deferral let's therefore restore the old code and drop the faux device. Fixes: af5376a77e87 ("cpuidle: psci: Transition to the faux device interface") Fixes: 5836ebeb4a2b ("cpuidle: psci: Avoid initializing faux device if no DT idle states are present") Fixes: 39cdf87a97fd ("cpuidle: psci: Fix uninitialized variable in dt_idle_state_present()") Cc: stable@vger.kernel.org Reviewed-by: Abel Vesa Signed-off-by: Ulf Hansson Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit b519dfce1998c323e54a56f911cf708d9ba0e076 Author: Linkai Gong Date: Fri Aug 21 15:57:28 2026 +0800 cpuidle: dt_idle_genpd: kfree() the original name allocation commit 2b0ac85512b7f67479127b2713254490662eb13d upstream. dt_idle_pd_alloc() kasprintf()s the full node path, then points pd->name at kbasename() of that string. dt_idle_pd_free() kfree()s pd->name, which is no longer the start of the allocation. Copy the basename instead. Fixes: 9d976d6721df ("cpuidle: Factor-out power domain related code from PSCI domain driver") Signed-off-by: Linkai Gong Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit fac202d73e7a649b7d4010325c6c6dcd9334fe65 Author: Koichiro Den Date: Tue Jul 21 15:28:05 2026 +0900 dmaengine: dw-edma: Initialize IRQ data before requesting IRQs commit 647217abea849d3d45f8cb0b8ee5b78d50f26985 upstream. dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260721062815.4117887-5-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 8fd47ccbba86c283ce1175bb2096df2abfa26586 Author: Koichiro Den Date: Sat Jul 18 03:06:34 2026 +0900 dmaengine: dw-edma: Complete descriptors before pausing commit c154060016a9db2ac889bfdb0a3c1322f9be8ded upstream. If PAUSE is requested while the final burst of a descriptor is in flight, the DONE interrupt takes the PAUSE path without checking whether the descriptor has been depleted. The depleted descriptor remains on the issued list and the channel enters EDMA_ST_PAUSE. On resume, dw_edma_start_transfer() can select that depleted descriptor again even though no burst remains, leaving the channel in an invalid busy state. Check for descriptor completion before acknowledging PAUSE. If there is no work to start on resume, leave the channel idle. Also ignore DONE interrupts while the channel is paused so a stale or repeated interrupt cannot change its state or start queued work. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-5-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 3b313f7a00d146108708631398c85b96b1788789 Author: Koichiro Den Date: Sat Jul 18 03:06:31 2026 +0900 dmaengine: dw-edma: Fix HDMA channel status register access commit ef1b080e03acc83d5bde841da67036985acd50dc upstream. GET_CH_32() takes the direction before the channel ID, but dw_hdma_v0_core_ch_status() passed them in the opposite order. This can make the status callback read another HDMA channel status register. Use the same argument order as the other HDMA register accesses. Fixes: e74c39573d35 ("dmaengine: dw-edma: Add support for native HDMA") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-2-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit d382aaf5fed38c6dd2e0cc710d97cb81d660ffa7 Author: Martin Kaiser Date: Sat Jul 18 14:58:48 2026 +0200 dmaengine: fsl-edma: tracing: no ptr dereference during log output commit 2ea04dca8e627f722caa7a2037cfbae0257f3501 upstream. The fsl edma events store a pointer to a struct fsl_edma_engine in the ringbuffer and dereference it when a log entry is printed. At this time, the pointer may no longer be valid. Event injection can be used to trigger a crash: $ cd /sys/kernel/tracing $ echo 'value = 0' > events/fsl_edma/edma_writeb/inject $ cat trace The log output needs only edma->membase. Add a membase field at the end of the event and use the new field for log output. Keep the existing fields for backward compatibility. Fixes: 11102d0c343b ("dmaengine: fsl-edma: add trace event support") Cc: stable@vger.kernel.org Reviewed-by: Steven Rostedt Signed-off-by: Martin Kaiser Reviewed-by: Frank Li Link: https://patch.msgid.link/20260718130024.341243-1-martin@kaiser.cx Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 408ff2d5bf555bd3f4c84a2edb95c0690bf9edc8 Author: Aneesh Kumar K.V (Arm) Date: Fri Jul 17 23:34:19 2026 +0530 dma-direct: return struct page from dma_direct_alloc_from_pool() commit 94a04ad732c9f8b9554270fc4038a06737de5c22 upstream. Commit 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper") changed dma_direct_alloc_from_pool() to return the CPU address from dma_alloc_from_pool(). That fits dma_direct_alloc(), but dma_direct_alloc_pages() also uses the helper and expects a struct page *. Fix this by making dma_direct_alloc_from_pool() return the struct page * again, and pass the CPU address back through an out-parameter for the dma_direct_alloc() caller. Fixes: 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper") Cc: stable@vger.kernel.org Tested-by: Michael Kelley Tested-by: Mostafa Saleh Reviewed-by: Jason Gunthorpe Signed-off-by: Aneesh Kumar K.V (Arm) Reviewed-by: Mostafa Saleh Link: https://lore.kernel.org/r/20260717180442.110954-2-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski Signed-off-by: Greg Kroah-Hartman commit 36177beff2a9df035991ad8d16ccf8d363ed93ee Author: Mikulas Patocka Date: Mon Jul 27 22:26:36 2026 +0200 dm: fix resume-vs-remove race commit 44b43ec132f1cf3275ecc182d0c82f50c3c4c3d5 upstream. If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit af1f32ccf8051f4691ced11feb452b9d13561727 Author: Mikulas Patocka Date: Mon Jul 27 22:27:07 2026 +0200 dm: fix race when loading and unloading a table commit 5380c7f6335cc6d77eb77d065105e81155c4d9d3 upstream. If the userspace calls two concurrent table load ioctls and one of them succeeds and the other fails, there is a race condition because dm_setup_md_queue walks &md->table_devices without any lock. If the walk races with dm_table_destroy -> free_devices -> dm_put_table_device, there is access to invalid memory. Fix this race by extending the lock over the list walk. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 74ec08f7b81c2726578039ca6dea0fec136c38ea Author: Ibrahim Hashimov Date: Mon Jul 13 11:34:14 2026 +0200 HID: wacom: validate report length in wacom_intuos_pro2_bt_irq commit a8e04f3f894ccb52cfcd7e60125a9f35da4a616d upstream. wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: wacom_intuos_pro2_bt_pen(wacom); if (type == INTUOSP2_BT || type == INTUOSP2S_BT) { wacom_intuos_pro2_bt_touch(wacom); wacom_intuos_pro2_bt_pad(wacom); wacom_intuos_pro2_bt_battery(wacom); } else { wacom_intuos_gen3_bt_pad(wacom); wacom_intuos_gen3_bt_battery(wacom); } Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] (the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT ("gen3"): wacom_intuos_gen3_bt_battery() reads data[45], so the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 ("HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior. Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Acked-by: Jason Gerecke Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit f4cb9c4556dcb593e66dbb855179dbd351dbb053 Author: Wei Jie Law <98lawweijie@gmail.com> Date: Tue Aug 25 18:31:17 2026 +0800 HID: rmi: fix OOB access with undersized RMI reports commit 4956993bb3befdf791d71a4952d8d13bcfd44c7b upstream. The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: data->input_report_size = hid_report_len(input_report); data->output_report_size = hid_report_len(output_report); alloc_size = data->output_report_size + data->input_report_size; data->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); data->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly "this probe validated the reports"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles a reply carrying fewer bytes than requested, and a write longer than the output report was overrunning the buffer already. Verified on v6.12.69 and on v6.12.105 built with CONFIG_KASAN=y and booted kasan_multi_shot, whose hid-rmi.c is identical to mainline here. An emulated RMI4 device driven over /dev/uhid, and the same device again over dummy_hcd plus raw-gadget, give identical results: BUG: KASAN: slab-out-of-bounds in rmi_hid_read_block+0x409/0x750 [hid_rmi] Read of size 21 at addr ffff88800bf33bba by task kworker/0:3/285 __asan_memcpy+0x23/0x60 rmi_hid_read_block+0x409/0x750 [hid_rmi] rmi_f01_probe+0x5dd/0x1dc0 [rmi_core] BUG: KASAN: slab-out-of-bounds in rmi_hid_write_block+0x1a9/0x350 [hid_rmi] Write of size 35 at addr ffff88810a2b24ac by task kworker/1:10/666 __asan_memcpy+0x3c/0x60 rmi_hid_write_block+0x1a9/0x350 [hid_rmi] rmi_driver_set_irq_bits+0x1f6/0x4d0 [rmi_core] rmi_driver_probe+0x636/0xbf0 [rmi_core] rmi_input_configured+0x184/0x2e0 [hid_rmi] rmi_probe+0x952/0xcf0 [hid_rmi] and, for the zero-length reply, a probe worker left in D state in rmi_hid_read_block() after 225 replies at 200 ms intervals. After this change the undersized descriptor is refused at probe with "rmi reports too small (out=2 in=2)", the oversized read and write are both rejected, the zero-length reply fails the read with -EIO while later reads on the same device keep working, and a device declaring reports large enough for a 21-byte register read still probes normally and reports its real product id. A device bound through new_id with RMI_DEVICE in its driver_data no longer reaches rmi_set_page() with an unallocated writeReport either. Link: https://lore.kernel.org/linux-input/20260822121007.153988-1-98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/00a489f38b240624dcb5a4bae36a53fcba9cfb47.1787549195.git.98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/20260824122708.76168-1-98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/20260825060954.104890-1-98lawweijie@gmail.com/ Fixes: 9fb6bf02e3ad ("HID: rmi: introduce RMI driver for Synaptics touchpads") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Assisted-by: GLM:glm-5.3 Signed-off-by: Wei Jie Law <98lawweijie@gmail.com> Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit c7f927aa8b55008ed5ea0814313d5dad771dcf3c Author: Shen Yongchao Date: Mon Aug 3 22:31:57 2026 +0800 HID: bpf: serialize device reference release in struct_ops destroy path commit 9cdc7e6dc7a99ad7311ad5e7c145f2b9ce4e24b0 upstream. __hid_bpf_ops_destroy_device() and hid_bpf_unreg() can race on the same registration reference, double-putting struct hid_device and freeing it while hid_destroy_device() still uses it. Serialize the remove/NULL decision under hdev->bpf.prog_list_lock so exactly one path releases each registration reference: unreg re-checks ops->hdev under the lock and returns without putting when the destroy path already cleared it; all put_device() calls happen after the lock is dropped, which is safe because a concurrent unreg then observes ops->hdev == NULL under the lock. Background: each successful attach (hid_bpf_ops_reg) acquires one device reference (hid_get_device()). Two paths can release it: - device destruction: hid_destroy_device() -> hid_bpf_destroy_device() -> __hid_bpf_ops_destroy_device(), which walks hdev->bpf.prog_list under rcu_read_lock() and drops one reference per attached program; - BPF link release: bpf map delete (no BPF_F_LINK) synchronously calls st_ops->unreg() -> hid_bpf_unreg(), which drops the reference for its own registration. The coordination handshake (e->hdev = NULL on the destroy side vs "if (!hdev) return" on the unreg side) is a TOCTOU check: the two paths run under different lock domains (rcu_read_lock vs prog_list_lock), so a concurrent unreg can read ops->hdev as non-NULL, block on prog_list_lock, and then proceed while the destroy traversal executes - both paths then drop the same reference. The refcount reaches zero legitimately (each decrement is individually valid), so no refcount_t saturation fires: the device is simply freed while the transport is still inside hid_destroy_device(), and subsequent teardown touches freed memory. The fix serializes the remove/NULL decision under prog_list_lock on both sides and moves the destroy-side puts outside the lock. With the lock held, plain reads/writes of ops->hdev are sufficient; no READ_ONCE/WRITE_ONCE are added, keeping the patch minimal. Unlocked-read safety: the unlocked read of ops->hdev at the top of hid_bpf_unreg() cannot touch a freed device, because the unreg path itself still holds this registration's reference (released only by its own hid_put_device() after the lock is dropped), and a destroy traversal that already cleared ops->hdev makes the lock-internal re-check return early without any put. At most one of the two paths releases each registration reference. Fixes: ebc0d8093e8c ("HID: bpf: implement HID-BPF through bpf_struct_ops") Cc: stable@vger.kernel.org Signed-off-by: Shen Yongchao Assisted-by: Hermes:kimi-k3 Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 078adc03f6e603cbf4af6e84aa6c2d189f70e0b1 Author: Steven Rostedt Date: Wed Sep 2 09:55:01 2026 -0400 ftrace: Synchronize the initialization of ftrace_ops commit 4617721c502b2ddaa4e324e86da4997edf738fa5 upstream. There's some internal state that ftrace_ops needs to have set, but since it can be declared outside of the ftrace.c code, it calls ftrace_ops_init() on the ops in every global function. The issue is that if two tasks call it on the same ops at the same time it is possible to have the initialization of one corrupt the initialization of the other call. Create a ops_mutex to use to synchronize every initialization of the ftrace_ops. The mutex is taken within checking the ftrace_ops flag that states it was initializied but the flag is checked again after the mutex has been taken. Checking first outside the mutex allows it to shortcut having to take the mutex. But then the check needs to be done again after the mute is taken in case of races. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260902095501.6b59af20@gandalf.local.home Fixes: f04f24fb7e48d ("ftrace, kprobes: Fix a deadlock on ftrace_regex_lock") Reported-by: sashiko-bot@kernel.org Close: https://lore.kernel.org/all/20260829025528.49A831F000E9@smtp.kernel.org/ Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 7d1559126d86be6e4f6a85663dfbfe85caa47e37 Author: Yao Kai Date: Tue Sep 1 15:54:52 2026 +0200 futex: Prevent rcuwait use-after-free during requeue PI commit a3b8d46fe401cba3a5c46dea610e6eb3dc15370e upstream. On PREEMPT_RT, FUTEX_CMP_REQUEUE_PI can trigger a KASAN report (slab-out-of-bounds) in futex_requeue_pi_complete() invocation of rcuwait_wake_up(). The futex_q used by futex_wait_requeue_pi() is allocated on the waiter's stack. An early wakeup can race with a PI requeue as follows: waiter requeue task ------ ------------ futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS * timeout/ signal wakes waiter * futex_requeue_pi_wakeup_sync() Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT requeue_pi_wake_futex futex_requeue_pi_complete() cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED rcuwait_wait_event() if (atomic_read(&q->requeue_state) != Q_REQUEUE_PI_WAIT) break /* no schedule() */ /* q.pi_state->owner == current */ futex_private_hash_put() /* return from syscall */ rcuwait_wake_up(&q->requeue_wait) /* q is gone */ futex_requeue_pi_complete() publishes Q_REQUEUE_PI_LOCKED before calling rcuwait_wake_up(). The waiter observes this state in rcuwait_wait_event() before invoking schedule() in rcuwait_wait_event(). Here, the waiter is free leave the syscall before requeue task can complete the wake. To address this race skip rcuwait_wake_up() in the Q_REQUEUE_PI_LOCKED case. This state is only published by requeue_pi_wake_futex(), which saves q->task before futex_requeue_pi_complete() and wakes the waiter via wake_up_state(). This wake is intended to wake the waiter from its futex_do_wait() sleep. If the waiter is still sleeping there, it can not get into the Q_REQUEUE_PI_WAIT state (and require this removed wake). Should the waiter be woken up from futex_do_wait() by other means (as in this example) and sleep in futex_requeue_pi_wakeup_sync() then the wake_up_state() from requeue_pi_wake_futex() will wake it, too. Should the waiter task terminate before wake_up_state() had a chance to wake the task then the task pointer does not become invalid because the futex_hash_bucket::lock is held and the task pointer is RCU protected. [bigeasy: Updated comment and commit message] Fixes: 07d91ef510fb1 ("futex: Prevent requeue_pi() lock nesting issue on RT") Signed-off-by: Yao Kai Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Sebastian Andrzej Siewior Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901135453.3121948-3-bigeasy@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 1cd41131bc4b8b1eabe582496145d0a0bc42da15 Author: SJ Park Date: Fri Jul 17 17:14:36 2026 -0700 mm/damon/core-kunit: check region count before testing in split_at() commit 9b18ef3c3aa1ce24176e340061caf15fa2742564 upstream. damon_test_split_at() test next region that is assumed to be created by damon_split_region_at() invocation. But the split might fail. In this case, the succeeding test may dereference invalid pointers returned by damon_next_region(). The invalid pointer may not cause a really bad user impact, because of the implementation detail. It would only read wrong contents in the belonging damon_target struct. Depending on the future change of the offset from the link header to the accessing field, this could also be really dangerous, though. Still, the realistic user impact would be limited. It would affect only test run setups. Fix it by testing if the number of regions was also changed as expected and exit early for the failure. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-3-sj@kernel.org Link: https://lore.kernel.org/20260714142352.100478-1-sj@kernel.org [1] Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 382e58c24eabf1c9a47c9221c75de217eb1db3cb Author: SJ Park Date: Sun Jun 28 15:01:10 2026 -0700 mm/damon/sysfs: kobject_del() target (normal), context and kdamond dirs commit 263af33a72d1995ae6cdc22b08d527e2bda17259 upstream. Patch series "mm/damon/sysfs: kobject_del() directories that users can create/remove". DAMON sysfs interface allows users to create and remove arbitrary number of directories on sysfs, using a few files having 'nr_' prefix. For example, 'nr_kdamonds'. When the user writes a number 'N' to the files, directories having name starting from '0' to 'N - 1' are created in the same directory. The pre-existing number-named directories are removed before creating the new directories. For the removal of the existing directories, DAMON sysfs interface use only kobject_put(). Because DAMON sysfs interface is the only kernel component that manages the directories, there is no problem in normal situations. However, if CONFIG_DEBUG_KOBJECT_RELEASE is enabled, the removal of dirs are delayed. Let's suppose a user writes a non-zero number to the 'nr_*' files while there are pre-existing number-named directories, on the config enabled kernel. DAMON sysfs interface decreases the reference counts of the existing directories and immediately creates new directories. Because the removal of the sysfs directories is delayed, it shows some pre-existing directories of the same names when it tries to create the new directories, and fails. For example, the issue can be triggered like below: # grep DEBUG_KOBJECT_RELEASE /boot/config-$(uname -r) CONFIG_DEBUG_KOBJECT_RELEASE=y # ls nr_kdamonds # echo 1 > nr_kdamonds # echo 1 > nr_kdamonds bash: echo: write error: File exists # dmesg [...] [ 300.880458] kobject: kobject_add_internal failed for 0 with -EEXIST, don't try to register things with the same name in the same directory. [...] Some of the error handling paths of the directories also lack the kobject_del() call. If the user uses nr_* file right after the errors, similar issues can happen. This doesn't cause catastrophic issues like kernel panics or memory corruptions. Users can work around by removing all directories first (write 0 to the nr_* files) and then create new directories after confirming the old directories are gone. But, this is definitely a bug that causes a bad user experience. Fix the issues by calling kobject_del() before creating new directories. This patch (of 11) On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for normal creation paths of target, context and kdamond directories, and error paths of context and kdamond directories by adding kobject_del() calls. Note that this fix for target directories is not complete since it has a similar issue in the damon_sysfs_targets_add_dirs() error path. Because the normal path issue and the error path issue are introduced by different commits, this commit is fixing only the normal path issue. A commit for the error path will be added next. Link: https://lore.kernel.org/20260628220121.97360-1-sj@kernel.org Link: https://lore.kernel.org/20260628220121.97360-2-sj@kernel.org Fixes: c951cd3b8901 ("mm/damon: implement a minimal stub for sysfs-based DAMON interface") Signed-off-by: SJ Park Cc: # 5.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 368f84ec79104761e007ea74380c44c7f3303144 Author: SJ Park Date: Sun Jun 28 15:01:11 2026 -0700 mm/damon/sysfs: kobject_del() region and target (error) dirs commit 2603ef6f6ec3d3f7de2d6a07e7c9a683cebac419 upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for the normal creation path of region directories and the error path of target directories, by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-3-sj@kernel.org Fixes: 2031b14ea757 ("mm/damon/sysfs: support the physical address space monitoring") Signed-off-by: SJ Park Cc: # 5.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 23c7b91895ff0f38ae08f699d50a8744efb8f304 Author: SJ Park Date: Sun Jun 28 15:01:13 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme region dirs commit f3ec3271210781c255e737498b84d5790e8176b4 upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme region directories by adding kobject_del() calls. This issue was discovered [1] by Sashiko, though its analysis was partially incorrect. Link: https://lore.kernel.org/20260628220121.97360-5-sj@kernel.org Link: https://lore.kernel.org/20260517205828.6204-1-sj@kernel.org [1] Fixes: 9277d0367ba1 ("mm/damon/sysfs-schemes: implement scheme region directory") Signed-off-by: SJ Park Cc: # 6.2.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 20a40e7eb5ec37949af9ea65277377212d3d9f90 Author: SJ Park Date: Sun Jun 28 15:01:15 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme quota goal dirs commit 0d4397ca921ceaf80fc3eca4c8194812ff79a979 upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme quota goal directories by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-7-sj@kernel.org Fixes: 7f262da0a30d ("mm/damon/sysfs-schemes: implement files for scheme quota goals setup") Signed-off-by: SJ Park Cc: # 6.8.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e608e7bbe82cb3a817ff68b9374a15e62f0c2265 Author: SJ Park Date: Sun Jun 28 15:01:14 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme filter dirs commit 3c453bddacd4c04ecb38cf79dbfa41e7dfe0531b upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme filter directories by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-6-sj@kernel.org Fixes: 472e2b70eda6 ("mm/damon/sysfs-schemes: connect filter directory and filters directory") Signed-off-by: SJ Park Cc: # 6.3.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8a1ebb241fc708dee1f41c6a92fc6c4147b208ee Author: SJ Park Date: Sun Jun 28 15:01:12 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme dirs commit 05fb6ac98c49be870c5f9ccdfdf95f0107e564ae upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme directories by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-4-sj@kernel.org Fixes: 7e84b1f8212a ("mm/damon/sysfs: support DAMON-based Operation Schemes") Signed-off-by: SJ Park Cc: # 5.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b9847d539b9c884280dca56dae706547fc80d08e Author: SJ Park Date: Sun Jun 28 15:01:16 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme action destination dirs commit 286380c78bc51e6c578621b9ae660bf9e5ad2563 upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme action destination directories by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-8-sj@kernel.org Fixes: 2cd0bf85a203 ("mm/damon/sysfs-schemes: implement DAMOS action destinations directory") Signed-off-by: SJ Park Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cb55606449fd6d929be2d43face0f8e7b173acde Author: SJ Park Date: Sun Jun 28 14:54:44 2026 -0700 samples/damon/wsse: stop and free damon ctx when damon_call() fails commit a2c6fa6c23ad87c61e1379b05dc05cf5fed4bf8d upstream. damon_sample_wsse_start() calls damon_call() right after damon_start() is succeeded. The kdamond that has started by the damon_start() could be terminated by itself before or in the middle of the damon_call() execution. There could be multiple reasons for such a stop including monitoring target process termination and kdamond_fn() internal memory allocation failures. In the case, damon_call() will fail and return an error without cleaning up the DAMON context object. The damon_sample_wsse_start() caller assumes it would clean up the object, though. When the user requests to start DAMON again, damon_sample_wsse_start() is called again, allocates a new DAMON context object and overwrites the pointer for the previous object. As a result, the previous context object is leaked. Safely stop the kdamond and deallocate the context object when the failure is returned. Note that the kdamond should be stopped first, because damon_call() failure means not complete termination of the kdamond but only the fact that the termination process has started. The user impact shouldn't be that significant because the race is not easy to happen, and only up to one DAMON context object can be leaked per race. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-6-sj@kernel.org Link: https://lore.kernel.org/20260610034828.4632-1-sj@kernel.org [1] Fixes: cc9c1b8c205b ("samples/damon/wsse: use damon_call() repeat mode instead of damon_callback") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6179c7f47876d576dfe30efa8fbf1b0b1fdd13c0 Author: SJ Park Date: Sun Jun 28 14:54:40 2026 -0700 samples/damon/wsse: handle damon_start() failure commit e4742be45ea45bf554399ce89a09f71e525d7981 upstream. Patch series "samples/damon: handle damon_{start,stop}() failures". All DAMON sample modules are not correctly handling failures from damon_start(). Among those, mtier also has an additional problem for handling of damon_stop() failures. wsse and prcl also have a problem in their damon_call() failure handling. As a result, memory leaks, next DAMON operation disruptions, and use-after-free can happen. Fix those. Note that only the damon_start() failure caused issues can reliably be reproduced. Reproducing those issues require the admin permission, though. This patch (of 6): damon_sample_wsse_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it leaks the memory for DAMON context. Free the context in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo $$ | sudo tee /sys/module/damon_sample_wsse/parameters/target_pid $ echo Y | sudo tee /sys/module/damon_sample_wsse/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the third command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the third and the fourth commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-2-sj@kernel.org Link: https://lore.kernel.org/20260609145814.70163-1-sj@kernel.org [1] Fixes: b757c6cfc696 ("samples/damon/wsse: start and stop DAMON as the user requests") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.14.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2446d3820cbaf88c386b8836194bdd42464115ec Author: SJ Park Date: Sun Jun 28 14:54:45 2026 -0700 samples/damon/prcl: stop and free damon ctx when damon_call() fails commit a73fa45d3f0f42c446ae55c5799e3d5ef044cd5d upstream. damon_sample_prcl_start() calls damon_call() right after damon_start() is succeeded. The kdamond that has started by the damon_start() could be terminated by itself before or in the middle of the damon_call() execution. There could be multiple reasons for such a stop including monitoring target process termination and kdamond_fn() internal memory allocation failures. In the case, damon_call() will fail and return an error without cleaning up the DAMON context object. The damon_sample_prcl_start() caller assumes it would clean up the object, though. When the user requests to start DAMON again, damon_sample_prcl_start() is called again, allocates a new DAMON context object and overwrites the pointer for the previous object. As a result, the previous context object is leaked. Safely stop the kdamond and deallocate the context object when the failure is returned. Note that the kdamond should be stopped first, because damon_call() failure means not complete termination of the kdamond but only the fact that the termination process has started. The user impact shouldn't be that significant because the race is not easy to happen, and only up to one DAMON context object can be leaked per race. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-7-sj@kernel.org Link: https://lore.kernel.org/20260610035214.4850-1-sj@kernel.org [1] Fixes: a6c33f1054e3 ("samples/damon/prcl: use damon_call() repeat mode instead of damon_callback") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9f370353bba7f4bbe87a1c82fcf9f579ace1e3f1 Author: SJ Park Date: Sun Jun 28 14:54:41 2026 -0700 samples/damon/prcl: handle damon_start() failure commit 8b724349229bb6ebbf781178be011ba9bc2cca57 upstream. damon_sample_prcl_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it leaks the memory for DAMON context. Free the context in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo $$ | sudo tee /sys/module/damon_sample_prcl/parameters/target_pid $ echo Y | sudo tee /sys/module/damon_sample_prcl/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the third command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the third and the fourth commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-3-sj@kernel.org Link: https://lore.kernel.org/20260609145814.70163-1-sj@kernel.org [1] Fixes: 2aca254620a8 ("samples/damon: introduce a skeleton of a smaple DAMON module for proactive reclamation") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.14.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3c07c57b894116ae26f01b84c68e68b538ada7ed Author: SJ Park Date: Sun Jun 28 14:54:43 2026 -0700 samples/damon/mtier: handle damon_stop() failure commit 9dc5b6d66fd51b103eff21ed0df3e292f489ebc0 upstream. damon_sample_mtier_stop() assumes its damon_stop() call will always successfully stops the two DAMON contexts. Hence it deallocates the two DAMON contexts after the damon_stop() call. However, if a given context is already stopped, damon_stop() fails and returns an error while letting the DAMON contexts that have not yet stopped keep running. This kind of unexpected early DAMON context stops could happen due to memory allocation failures in kdamond_fn(). Because damon_sample_mtier_stop() just deallocates all DAMON contexts with damon_target and damon_region objects that are linked to the contexts, the execution of the unstopped DAMON context (kdamond) ends up using the memory that freed (use-after-free). Fix the issue by separating the damon_stop() to be invoked per context. Note that DAMON_SYSFS also allows multiple DAMON contexts execution. But, it calls damon_stop() for each context one by one. Hence this issue is only in mtier. For the long term, it would be better to refactor damon_stop() to always ensure stopping all contexts regardless of the failures in the middle. Make this fix in the current way, though, to keep it simple and easy to backport. I will do the refactoring later. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-5-sj@kernel.org Link: https://lore.kernel.org/20260609014219.3013-1-sj@kernel.org [1] Fixes: 82a08bde3cf7 ("samples/damon: implement a DAMON module for memory tiering") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.16.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f0808262a76165fbde6b4f1c2a8856a1e2b45512 Author: SJ Park Date: Sun Jun 28 14:54:42 2026 -0700 samples/damon/mtier: handle damon_start() failure commit c7230d08ee79b13127bd2b45a3648d361ac912fc upstream. damon_sample_mtier_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it could leak the memory for DAMON context. Also, if damon_start() fails for only the second context, the first context will indefinitely run, and avoid starting other DAMON contexts since it is running in the exclusive mode. Stop possibly started DAMON context and free the contexts in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo Y | sudo tee /sys/module/damon_sample_mtier/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the second command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the second and the third commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-4-sj@kernel.org Link: https://lore.kernel.org/20260608112455.274231F00893@smtp.kernel.org [1] Fixes: 82a08bde3cf7 ("samples/damon: implement a DAMON module for memory tiering") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.16.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 71de5a082d2ca4dcdf48b2f73ff8c6ed5a5f5aeb Author: SJ Park Date: Fri Jul 17 17:14:37 2026 -0700 mm/damon/vaddr-kunit: check region count in three_regions test commit 5fea07e460874c8c7cf00f728efbe22abc62c8d8 upstream. damon_do_test_apply_three_regions() iterates regions after damon_set_regions() call assuming the function would succeed at setting the number of regions the same to the expected one. It might have failed. In this case, __nth_region_of() in the iteration could return NULL and NULL dereference can happen in the test. The consequent user impact (NULL dereference) is quite bad. The realistic user impact would be limited, though. It would affect only test run setups. Fix it by testing if the number of regions was also changed as expected and exit early for the failure. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-4-sj@kernel.org Link: https://lore.kernel.org/20260713144757.39740-1-sj@kernel.org [1] Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit dd817463c9b42a3a9e23d15b86c6c77a6cfb809d Author: Runyu Xiao Date: Mon Aug 24 19:36:18 2026 +0800 scsi: pm8001: Use rollback index when freeing MSI-X vectors commit 3f92a64545165bdbb36dee8fa35626b295463313 upstream. pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop. Fixes: a76037ff3479 ("scsi: pm8001: switch to pci_irq_alloc_vectors") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Acked-by: Jack Wang Link: https://patch.msgid.link/20260824113618.2239100-1-runyu.xiao@seu.edu.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 4bb34769ef44ab3770b89e4055de6af4a458bec9 Author: Thomas Lamprecht Date: Thu Aug 27 19:24:24 2026 +0200 scsi: megaraid_sas: Limit NVMe request size to the PRP chain frame commit af8c27375733fb6a6df9fa484cda77cc3dd0cb80 upstream. megasas_make_prp_nvme() builds a command's PRP list in cmd->sg_frame, a DMA pool buffer of instance->max_chain_frame_sz bytes, spending one entry per NVMe page of the transfer plus one per page of the buffer for the chain pointer. The loop runs until the transfer is described and never checks the buffer bound. max_hw_sectors comes straight from the MDTS the firmware reports for the drive. On drives with a large MDTS the only thing keeping the list inside the buffer was the block layer default of 1280 KiB, which needs 320 entries, which fit into a 4 KiB frame as that holds 512. But since commit 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") that default is 4 MiB, and such a transfer needs 1025 entries, so the list runs a full page past the end of the frame: sd 1:0:1:0: [sdb] tag#630 page boundary ptr_sgl: 0x00000000ba62d13f BUG: unable to handle page fault for address: ff663bcb81e7c000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:megasas_build_and_issue_cmd_fusion+0xeaa/0x1870 [megaraid_sas] If the page after the frame happens to be mapped, the overrun does not fault but silently corrupts the neighbouring pool entry, which is another in-flight command's PRP list. Cap max_hw_sectors at what the chain frame can describe, less one page for transfers that do not start on a page boundary and so need one entry more. This is the megaraid_sas counterpart of commit 04631f55afc5 ("scsi: mpt3sas: Limit NVMe request size to 2 MiB"), but derives the limit from max_chain_frame_sz rather than hardcoding it. Cc: stable@vger.kernel.org Fixes: 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") Reported-by: Lukasz Magiera Closes: https://lore.kernel.org/all/GPhsSM0vkgyIrs0DIZ62qeUZX7X4RxwQXVKiuvMx-lHQVSPDxpztUyQOGS0xikqvJ-Z94hMV-dW_5KN_0CX2hsfV7kTf_t0MTf6vdAAaSEc=@magik.net/ Reported-by: Mira Limbeck Closes: https://lore.kernel.org/all/d171cc76-bf25-48ce-b482-d344669dfc24@proxmox.com/ Suggested-by: Martin K. Petersen Link: https://lore.kernel.org/all/yq17bmzd5jr.fsf@ca-mkp.ca.oracle.com/ Signed-off-by: Thomas Lamprecht Closes: https://lore.kernel.org/linux-scsi/20260827182106.535D61F000E9@smtp.kernel.org Link: https://patch.msgid.link/20260827175743.734593-1-t.lamprecht@proxmox.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 1624bff4c5118ad494d50ad94d44f22064667a7f Author: Sujal Tuladhar Date: Sat Aug 1 21:30:00 2026 +0545 scsi: target: iscsi: Reserve a terminator byte for the login payload commit f4825922d2fb371e2b969697d792077f1b62b62c upstream. iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where padding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated. Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Assisted-by: Claude Opus5 (custom harness) Cc: stable@vger.kernel.org Signed-off-by: Sujal Tuladhar Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit a38051fa2ddedbc8ec15292c55e276880ec5b9a4 Author: Honghui Jiang Date: Fri Aug 14 11:14:15 2026 +0800 spi: Fix DMA mapping ownership on partial map failure commit 367cea239fc93094e5c16a72724800e0358f5c46 upstream. If RX mapping fails after TX mapping succeeds, __spi_map_msg() unmaps TX but leaves tx_sg_mapped set. If TX mapping fails on a later transfer, mappings created for earlier transfers remain active. In both cases, cur_{tx,rx}_dma_dev have not yet been updated because they are assigned only after every transfer has been mapped. The subsequent spi_unmap_msg() may therefore unmap the TX mapping again or release earlier mappings using a NULL or stale device. Using a NULL device can trigger an oops. An empty SG table does not prevent the NULL dereference because dma_unmap_sg_attrs() accesses the device before checking the entry count. Publish both mapping devices before mapping starts and unwind all failures through __spi_unmap_msg(). This clears the mapping flags and releases each mapping once with the device that created it. Publishing the devices before the loop also refreshes them when no transfer needs mapping. No mapping flag is set in that case, so current users do not use the pointers as mapping owners. Fixes: e289df82344f ("spi: Rework per message DMA mapped flag to be per transfer") Cc: stable@vger.kernel.org Signed-off-by: Honghui Jiang Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260814031419.43378-2-jiang_hh2019@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 148a3f03aec892d9a397f095faa087d458fd11ac Author: Can Peng Date: Tue Aug 4 15:19:04 2026 +0800 spi: bcmbca-hsspi: disable clocks on resume failure commit d2f5a606710ad70c341dc609430a20a5645618d5 upstream. bcmbca_hsspi_resume() enables the HSSPI clock, and optionally the PLL clock, before restarting the SPI controller queue. If spi_controller_resume() fails, the function currently reports success and leaves those clocks enabled. Propagate the error and disable the clocks before returning. Fixes: a38a2233f23b ("spi: bcmbca-hsspi: Add driver for newer HSSPI controller") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Reviewed-by: Kursad Oney Link: https://patch.msgid.link/20260804071904.860842-1-pengcan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0acbfd61aee188dc25adac8a2402601fda18f98b Author: Can Peng Date: Tue Aug 4 15:18:31 2026 +0800 spi: bcm63xx: disable clock on resume failure commit 2b62c2c134fa32d9d3a9e7323c8ac74518eeb4ac upstream. bcm63xx_spi_resume() enables the controller clock before restarting the SPI controller queue. If spi_controller_resume() fails, the function currently reports success and leaves the clock enabled. Propagate the error and disable the clock before returning. Fixes: b42dfed83d95 ("spi: add Broadcom BCM63xx SPI controller driver") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Link: https://patch.msgid.link/20260804071831.860784-1-pengcan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b782a7cb0a424c1e25b48eee6564e944eea3750d Author: Can Peng Date: Tue Aug 4 15:20:17 2026 +0800 spi: bcm63xx-hsspi: disable clocks on resume failure commit 3b0cee02664041aea7e4f787c66cb86c82eb4e97 upstream. bcm63xx_hsspi_resume() enables the HSSPI clock, and optionally the PLL clock, before restarting the SPI controller queue. If spi_controller_resume() fails, the function currently reports success and leaves those clocks enabled. Propagate the error and disable the clocks before returning. Fixes: 142168eba9dc ("spi: bcm63xx-hsspi: add bcm63xx HSSPI driver") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Reviewed-by: Kursad Oney Link: https://patch.msgid.link/20260804072017.860974-1-pengcan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 907752a7b64a6b47ad36fc63e924a475335b0f9d Author: Viken Dadhaniya Date: Thu Jul 2 11:12:23 2026 +0530 soc: qcom: geni-se: Use HW PROG_RAM_DEPTH to validate firmware size commit 522bfb4f33c0930b3d14d5c5ee80bc93a883b544 upstream. The hardcoded MAX_GENI_CFG_RAMn_CNT limit is not accurate for all SoCs: some targets have less CFG RAM than the constant implies, while others like QCS615 need more entries than the old limit of 455 allowed, causing valid firmware to be rejected at load time. Rather than hardcoding a constant, read PROG_RAM_DEPTH from SE_HW_PARAM_2 at runtime to get the actual CFG RAM depth of the hardware instance and use that as the upper bound for firmware size validation. Fixes: d4bf06592ad6 ("soc: qcom: geni-se: Add support to load QUP SE Firmware via Linux subsystem") Cc: stable@vger.kernel.org Reviewed-by: Konrad Dybcio Signed-off-by: Viken Dadhaniya Link: https://lore.kernel.org/r/20260702-qup-se-increase-ram-cnt-v3-1-80b363373a5b@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit e373c1acdbcf88cec533ece9f589020adaed0a78 Author: Kanishka De Silva Date: Sun Aug 30 12:31:33 2026 +0530 ublk: clear VM_MAYWRITE on read-only ublk char device mmap commit 6e2b571b0a54755b06e092501913e1dfefe75d6c upstream. ublk_ch_mmap() rejects mmap requests with VM_WRITE set, but never clears VM_MAYWRITE on the resulting read-only mapping. This allows a userspace daemon to mmap the per-queue command buffer PROT_READ, then upgrade it to PROT_WRITE via mprotect(), since VM_MAYWRITE was never cleared. The command buffer holds struct ublksrv_io_desc entries that are kernel-written ABI; a writable mapping lets an unprivileged daemon process corrupt fields such as addr, op_flags, nr_sectors, and start_sector. Same bug class as the drm/panthor and drm/vc4 VM_MAYWRITE fixes, and the 2026-08-13 ptp/vmclock fix (a5edadbae57e). Verified via mprotect() PoC: before the fix, a PROT_READ mapping can be upgraded to PROT_READ|PROT_WRITE and a write into the command buffer corrupts io_desc fields (confirmed under KASAN). After the fix, mprotect() returns -EACCES. Fixes: 3fee8d7599e1 ("ublk_drv: add io_uring based userspace block driver") Cc: stable@vger.kernel.org Signed-off-by: Kanishka De Silva Reviewed-by: Ming Lei Link: https://patch.msgid.link/20260830070133.559-1-kpskanna1915@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 89f06342743ca7b54a8f6734bd44533ba8a10638 Author: Bryan Lim Date: Wed Aug 19 10:08:24 2026 +0700 userfaultfd: reset err to be 0 when move_pages_ptes succeeded commit f025ca73decda1f895a4b80b961d3bc88825298a upstream. During move_pages() operation, when move_pages_ptes() returns EAGAIN, the error code is not cleared even after we processed it. This leads to a successful retry but then the same pages are retried again due to the stale error code. This time move fails because pages are already moved, loop is terminated and move_pages() reports a failure. Clear the error code once we processes EAGAIN. Link: https://lore.kernel.org/e1e0b5f8-c3c6-0537-670b-4397f822f980@gmail.com Fixes: 50944692052b ("userfaultfd: opportunistic TLB-flush batching for present pages in MOVE") Assisted-by: ChatGPT:GPT-5.6-Luna Signed-off-by: Bryan Lim Reviewed-by: Suren Baghdasaryan Acked-by: Mike Rapoport (Microsoft) Cc: Peter Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 65c2029f3bbae5cd7f9fff4ce7c7fc3ef7879b25 Author: Can Peng Date: Wed Jul 22 15:56:25 2026 +0800 thermal/drivers/qoriq: Disable clock on resume failure commit fcbf9964b67a6d6704c50ed28daa24c3b164f01c upstream. qoriq_tmu_resume() enables the TMU clock before clearing the power-down bit and enabling monitoring. If either register update fails, the function returns with the clock still enabled. This leaves the clock enable count unbalanced after a failed resume. Disable the clock on those failure paths before returning the error. Fixes: 51904045d4aa ("thermal: qoriq: Add clock operations") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260722075625.452684-1-pengcan@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit ec2db87a0bbb8fa431b43ba9864ad00ce7d8c306 Author: Can Peng Date: Wed Jul 22 16:49:09 2026 +0800 thermal/drivers/imx: Disable clock on runtime resume failure commit bcc6d886e5006a4656901d2d7fb6a215c96068a0 upstream. imx_thermal_runtime_resume() enables the thermal clock before powering up the sensor and enabling measurements. If either regmap_write() fails, the function returns with the clock still enabled. This leaves the clock enable count unbalanced after a failed runtime resume. Disable the clock on those failure paths before returning the error. Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Signed-off-by: Daniel Lezcano Reviewed-by: Frank Li Link: https://patch.msgid.link/20260722084909.463437-1-pengcan@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit efaab8938fb92979be6df359f7d1a43fb7e4717d Author: Arthur Gautier Date: Mon Aug 31 12:04:48 2026 +0300 xhci: fix lost bounce buffers on TDs spanning several ring segments commit ff44dfb03a293bf30e31f98772a1dd316a6071d1 upstream. When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.] Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer") Cc: stable@vger.kernel.org Suggested-by: Michal Pecio Signed-off-by: Arthur Gautier Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260831090448.95644-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit b041e3f35e0d262d42a711094ab594634d72744a Author: Muhammad Bilal Date: Tue Jul 28 17:54:55 2026 +0500 staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() commit ff917923f4fb9c83717ba135ee47d7e4c1567bb7 upstream. rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: const u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); ... c = frame_body[0]; ... a = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260728125456.32359-3-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman commit ff61aa3289355dafa811550a1764691cd1f5d33b Author: Muhammad Bilal Date: Tue Jul 28 17:54:54 2026 +0500 staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() commit 99aa998dec83ba180822f70e6d48a514fc81c20d upstream. rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: if (attr_ptr + 4 > wps_ie + wps_ielen) break; u16 attr_id = get_unaligned_be16(attr_ptr); u16 attr_data_len = get_unaligned_be16(attr_ptr + 2); u16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: memcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack "u8 sr"/"u8 selected_registrar" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The "attr_ptr + 4 > wps_ie + wps_ielen" header check above was added by commit 1463ca3ec6601 ("staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260728125456.32359-2-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit d3a7fa61997db3bf6dadef4c1bd87a4fa782a817 Author: Jeffin Philip Date: Sun Aug 16 11:47:12 2026 +0530 usb: gadget: fix null pointer dereference in usb_put_function_instance() commit 6e74ac5c596fd246e37eadfc354567179ccbe9aa upstream. usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null. Reported-by: syzbot+fd6ef980cf1c722be639@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fd6ef980cf1c722be639 Fixes: 0062f6e56f70 ("usb: gadget: add a forward pointer from usb_function to its "instance"") Cc: stable Signed-off-by: Jeffin Philip Link: https://patch.msgid.link/20260816061712.15547-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit c29a83c1ff3f06d5751f6d365b606c9f81ccc4cb Author: Lovekesh Solanki Date: Tue Aug 25 22:43:43 2026 +0530 USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() commit dd0eed9e165b1a6292f49e622e3dd0b7d99b106d upstream. gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently. Cc: stable Reported-by: Eulgyu Kim Link: https://lore.kernel.org/all/20260824113510.1141236-1-jjy600901@snu.ac.kr/ Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/all/20260824113510.1141236-1-jjy600901@snu.ac.kr/ Signed-off-by: Lovekesh Solanki Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260825171343.459630-1-lovekeshsolanki00@gmail.com Signed-off-by: Greg Kroah-Hartman commit 02ac76f27db23ef652358458c272d9d2d6f51167 Author: Jeffin Philip Date: Sat Aug 15 11:10:06 2026 +0530 usb: gadget: f_midi: initialize work in f_midi_alloc() commit 7e07d3e4c389217d7d7171d80edf2e23ac70f1ea upstream. f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc(). Reported-by: syzbot+d5fa3d224505c8610702@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d5fa3d224505c8610702 Fixes: 8653d71ce376 ("usb/gadget: f_midi: Replace tasklet with work") Cc: stable Signed-off-by: Jeffin Philip Reviewed-by: Takashi Iwai Link: https://patch.msgid.link/20260815054006.102325-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit e89e30f0b5d3004fe5955250bd8b04f3733e32ce Author: Ivy Lopez Date: Sat Aug 15 18:54:33 2026 -0600 usb: gadget: f_midi2: fix use-after-free in string attribute show path commit fed0aa7c6eaedc6c0d4e362fc91724aa47be4a7b upstream. f_midi2_opts_str_show() takes the string lock internally, but its callers dereference the opts->info. pointer before calling it, outside the lock. This races with f_midi2_opts_str_store(), which frees the old string under opts->lock when the attribute is written concurrently, the show path can read a pointer that gets freed before the lock inside str_show() is even taken. Change f_midi2_opts_str_show() to take a pointer to the string field, matching the existing pattern in f_midi2_opts_str_store(), and dereference it only after the lock is held. Update all three callers (iface_name, block name, and the EP string option macro) accordingly. Reported-by: syzbot+2280f1cca5e6b0c353e4@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=2280f1cca5e6b0c353e4 Signed-off-by: Ivy Lopez Reviewed-by: Takashi Iwai Link: https://patch.msgid.link/20260816005434.34018-1-skunkolee@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9c3d5091e3568ed48ac4c5b08a78eb06fad0d70a Author: Aleksandr Nogikh Date: Wed Jul 29 09:04:54 2026 +0000 usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs commit f0efaf1872949e96d213c8e910fd9517f7d7c406 upstream. A null-pointer dereference occurs in f_midi2_free_ep_reqs() when attempting to clean up an endpoint that was never initialized. When configuring the MIDI 2.0 gadget via configfs and setting the block direction to SNDRV_UMP_DIR_INPUT, the initialization of the midi1_ep_out endpoint is explicitly skipped during the gadget bind phase (f_midi2_bind()). As a result, the usb_ep->card field remains NULL. Later, when the host sets the alternate setting, f_midi2_set_alt() unconditionally stops both the IN and OUT endpoints by calling f_midi2_stop_eps(), which in turn calls f_midi2_free_ep_reqs() for both endpoints. When f_midi2_free_ep_reqs() is called for the uninitialized midi1_ep_out, it attempts to dereference usb_ep->card to determine the number of requests to free, leading to a crash. Fix this by using usb_ep->num_reqs instead of usb_ep->card->info.num_reqs in f_midi2_free_ep_reqs(). usb_ep->num_reqs is correctly set during f_midi2_init_ep() and remains 0 if the endpoint was never initialized, safely avoiding the loop. For consistency, apply the same change to f_midi2_alloc_ep_reqs(). Oops: general protection fault, probably for non-canonical address 0xdffffc00000000ee: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000770-0x0000000000000777] ... RIP: 0010:f_midi2_free_ep_reqs drivers/usb/gadget/function/f_midi2.c:1166 [inline] RIP: 0010:f_midi2_stop_eps+0x28e/0x4d0 drivers/usb/gadget/function/f_midi2.c:1246 ... Call Trace: f_midi2_set_alt+0x11c/0xf00 drivers/usb/gadget/function/f_midi2.c:1296 composite_setup+0x1ffd/0x3480 drivers/usb/gadget/composite.c:1933 configfs_composite_setup+0xbd/0x100 drivers/usb/gadget/configfs.c:1877 Fixes: 8b645922b223 ("usb: gadget: Add support for USB MIDI 2.0 function driver") Cc: stable Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+bbb6dad313f4aaa8da6b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bbb6dad313f4aaa8da6b Link: https://syzkaller.appspot.com/ai_job?id=8ce30b1a-8cf7-4e38-bcf7-1f69e6f6313f Signed-off-by: Aleksandr Nogikh Reviewed-by: Takashi Iwai Closes: https://syzkaller.appspot.com/bug?extid=01a17afb30637396955e Link: https://patch.msgid.link/cafe65f4-e1bb-46a3-901d-732814b861b2@mail.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 33a81acd2d1d0667d4eff93cb90339fa53e617e8 Author: Jameson Thies Date: Tue Aug 25 23:45:45 2026 +0000 usb: typec: ucsi: displayport: Fix OOB altmode array index commit 04cec690b1fd9d1c4c314b91a10d8c68a3acfe18 upstream. The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array. Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Cc: stable@vger.kernel.org Signed-off-by: Jameson Thies Reviewed-by: Benson Leung Link: https://patch.msgid.link/20260825234545.2076049-1-jthies@google.com Signed-off-by: Greg Kroah-Hartman commit 6be5169e7615d0e96dc36e084f61cb07211f22bc Author: Sven Peter Date: Thu Aug 13 20:16:15 2026 +0200 usb: typec: tipd: Fix Thunderbolt altmode VDOs for cd321x commit e24e3370356bddb65d667985a332b5f8aeeb5f97 upstream. The Intel VID status register is actually 9 bytes long and doesn't contain the raw VDOs but only the upper 16bits for device mode and enter mode. Shift those two fields into place and reconstruct the cable discover mode VDO from the data status register instead since it's not directly accessible. With this fixed now the correct VDOs are forwarded to the PHY and the to-be-submitted Thunderbolt/USB4 native host interface so that the right mode can be negotiated and the link actually comes up. Link: https://www.ti.com/lit/ug/slvubh2b/slvubh2b.pdf Fixes: 0b31c978935f ("usb: typec: tipd: Read USB4, Thunderbolt and DisplayPort status for cd321x") Fixes: 82432bbfb9e8 ("usb: typec: tipd: Handle mode transitions for CD321x") Cc: stable Signed-off-by: Sven Peter Tested-by: Rafay Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260813-b4-tipd-vdo-fix-v1-1-70317f2cd554@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 42828aeb40b4a2099fc91e181850c106031d1d95 Author: Amit Sunil Dhamne Date: Thu Aug 27 21:16:17 2026 +0000 usb: typec: tcpm: constrain TCPM_SOURCING_VBUS event handling commit cd3b9cea675bbfebc223f007dc2f4e79524fa54c upstream. When a sink detach occurs while waiting for TX send status, the old TCPM_SOURCING_VBUS event along with TCPM_VBUS_EVENT and TCPM_CC_EVENT can be queued in port->pd_events. Because TCPM_SOURCING_VBUS is evaluated after TCPM_VBUS_EVENT and TCPM_CC_EVENT in tcpm_pd_event_handler(), a stale TCPM_SOURCING_VBUS event can override the detach handling and incorrectly set port->vbus_source and port->vbus_present to true. Add a state guard to check that the port is either operating as a Source (tcpm_port_is_source(port)) or in a Fast Role Swap (FRS) state up to FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED before processing TCPM_SOURCING_VBUS. Otherwise, discard and log the event. Log snippet for error condition before fix: [72792.204955] state change SRC_ATTACHED -> SRC_STARTUP [rev3 NONE_AMS] [72792.204960] sourcing vbus [72792.204962] VBUS on [72792.204970] AMS POWER_NEGOTIATION start [72792.204974] cc:=4 [72792.205319] state change SRC_STARTUP -> AMS_START [rev3 POWER_NEGOTIATION] [72792.205325] state change AMS_START -> SRC_SEND_CAPABILITIES [rev3 POWER_NEGOTIATION] [72792.205332] PD TX, header: 0x11a1 [72792.216911] PD TX complete, status: 2 [72792.216957] pending state change SRC_SEND_CAPABILITIES -> SRC_SEND_CAPABILITIES @ 150 ms [rev3 POWER_NEGOTIATION] [72792.218005] VBUS off [72792.218013] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION] [72792.218020] VBUS VSAFE0V [72792.218024] state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED [rev3 POWER_NEGOTIATION] [72792.218458] CC1: 2 -> 0, CC2: 0 -> 0 [state SNK_UNATTACHED, polarity 0, disconnected] [72792.218467] VBUS on --> VBUS left on [72792.218980] disable vbus discharge ret:0 [72792.235193] Start toggling After fix: [ 1195.291691] state change SRC_ATTACHED -> SRC_STARTUP [rev3 NONE_AMS] [ 1195.291698] sourcing vbus [ 1195.291700] VBUS on [ 1195.291707] AMS POWER_NEGOTIATION start [ 1195.291710] cc:=4 [ 1195.291758] state change SRC_STARTUP -> AMS_START [rev3 POWER_NEGOTIATION] [ 1195.291794] state change AMS_START -> SRC_SEND_CAPABILITIES [rev3 POWER_NEGOTIATION] [ 1195.291798] PD TX, header: 0x11a1 [ 1195.297056] PD TX complete, status: 2 [ 1195.297092] pending state change SRC_SEND_CAPABILITIES -> SRC_SEND_CAPABILITIES @ 150 ms [rev3 POWER_NEGOTIATION] [ 1195.297177] VBUS off [ 1195.297184] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION] [ 1195.297227] CC1: 2 -> 0, CC2: 0 -> 0 [state SRC_SEND_CAPABILITIES, polarity 0, disconnected] [ 1195.307469] cc:=2 [ 1195.307544] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION] [ 1195.307555] Discarding sourcing vbus! Invalid state SRC_SEND_CAPABILITIES [ 1195.957636] state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED [delayed 650 ms] [ 1195.957732] disable vbus discharge ret:0 [ 1195.970196] Start toggling [ 1195.970468] VBUS off [ 1196.051637] VBUS off [ 1196.051642] VBUS VSAFE0V Fixes: 8dc4bd073663 ("usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)") Cc: stable Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Amit Sunil Dhamne Reviewed-by: Badhri Jagan Sridharan Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260827-sourcing-vbus-v1-1-9be1aca991a0@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit d4e00a1eb39174e25ef759b8fb1111bba8e87b1e Author: Fan Wu Date: Wed Aug 19 16:14:48 2026 +0000 usb: typec: qcom-pmic: cancel reset_work on stop commit 7b0df6efd143f8085bdb68778a013a46f1349913 upstream. pdphy_stop() disables IRQs but leaves reset_work pending. If the IRQ handler schedules it just before disable_irq(), the work runs after remove() frees the struct via devm. Call cancel_work_sync() after disabling IRQs to close the window. This issue was found by an in-house static analysis tool. Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Cc: stable Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Reviewed-by: Konrad Dybcio Reviewed-by: Bryan O'Donoghue Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260819161448.76597-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 1e4f33f99bfb7ee5df2b76fb5445a8c9e24b8fed Author: Fan Wu Date: Thu Aug 20 13:53:07 2026 +0000 usb: typec: qcom-pmic-typec: drain cc_debounce_dwork if port_start() fails commit c9273c83885835dbd1e8835d5665dfb8503d65e0 upstream. cc_debounce_dwork can be queued before port_start() fails: tcpm_register_port() runs first, and its state machine may invoke set_cc() or start_toggling() from the TCPM worker. The error path then calls tcpm_unregister_port(), whose worker flush may queue the delayed work before devres frees pmic_typec_port. Disable and drain the delayed work directly at port_start()'s error exit. Do not use port_stop() for this path: its IRQs use IRQF_NO_AUTOEN and are enabled only after a successful port_start(). This issue was found by an in-house static analysis tool. Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Cc: stable # v6.10+ Suggested-by: Bryan O'Donoghue Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260820135307.153773-3-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit c614d7c44ca7fb78867ba46b233acdb59287e8c8 Author: Fan Wu Date: Thu Aug 20 13:53:06 2026 +0000 usb: typec: qcom-pmic-typec: disable cc_debounce_dwork on stop commit 263f7d61a4201cde16849b2d016251806e7418be upstream. cc_debounce_dwork is queued from the set_cc() and start_toggling() callbacks, which run from TCPM's kthread worker. port_stop() returns before tcpm_unregister_port() destroys that worker. Flushing the worker during unregister may therefore run a callback which queues the delayed work after port_stop() has returned. The delayed work can then run after devres has freed pmic_typec_port. Use disable_delayed_work_sync() in port_stop() to cancel a pending instance and prevent the TCPM callbacks from queueing another one. This issue was found by an in-house static analysis tool. Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Cc: stable # v6.10+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260820135307.153773-2-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 7c4e2f964c65dea4ea22386799d5fb10ef1e3e54 Author: Myeonghun Pak Date: Mon Jul 27 21:34:14 2026 +0900 usb: storage: realtek_cr: fix use-after-free on disconnect commit 4ffee1aebb0c0ffcda9faffd17834ea9b00d42cc upstream. realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free. Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed. Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor. Found by static analysis. Fixes: e931830bb877 ("Realtek cr: Add autosuspend function.") Cc: stable Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260727123414.44700-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0afe5c31612de3d18cc6d16e616da4a48ba1e5a2 Author: Elson Serrao Date: Thu Aug 13 08:14:56 2026 -0700 usb: dwc3: clear forceRM when issuing EndTransfer commit b58e6200450d350314db0ecda7d6d1bde3281e80 upstream. The forceRM bit of the DEPCMD register controls the behavior of the EndTransfer command used to stop an active transfer. Older DWC3 programming guide revisions recommended setting forceRM=1 when issuing EndTransfer. Newer programming guide revisions recommend issuing EndTransfer with forceRM cleared. With forceRM=1 on DWC_usb31 v2.00a and v2.10a controllers, a transfer aborted through the ep_dequeue path was observed to remain active after EndTransfer completion. A subsequent StartTransfer issued on the same endpoint triggered writes associated with the aborted transfer. This resulted in an SMMU fault because the transfer buffer had already been unmapped during EndTransfer command-completion cleanup. Using forceRM=0 eliminates the issue. Although older DWC3 programming guide revisions recommended setting forceRM=1, no issues are known from using forceRM=0. Clear forceRM when issuing EndTransfer to provide consistent EndTransfer behavior and align with newer programming guide recommendations. Fixes: 1e43c86d84fb ("usb: dwc3: core: Add DWC31 version 2.00a controller") Cc: stable Signed-off-by: Elson Serrao Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260813151456.867008-1-elson.serrao@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 62a8b67960637ae1d9dfbe70503e16ac78264ddd Author: Andy Shevchenko Date: Mon Aug 17 18:11:30 2026 +0200 usb: f_mass_storage: Bump local buffer size in fsg_common_create_luns() commit 9f6f095beec82a80daa666a3b2186a5b95841e9a upstream. GCC (Debian 14.2.0-19) is not happy about the buffer size: drivers/usb/gadget/function/f_mass_storage.c:2970:48: error: ‘%d’ directive output may be truncated writing between 1 and 9 bytes into a region of size 5 [-Werror=format-truncation=] Bump the size to get it enough for all possible values. Note, although cfg->nluns is limited to FSG_MAX_LUNS (16), the compiler doesn't realize this and complains about the buffer size. Also note, the existing comment is wrong as size 8 for the whole buffer doesn't cover 100 mil numbers, hence drop it altogether. Fixes: b27c08c953e9 ("usb: gadget: f_mass_storage: create lun creation helpers for use in fsg_common_init") Cc: stable Acked-by: Alan Stern Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20260817161239.1448582-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 1c67f2ba9c5f7c5ab3670671c0d51c6504bcaf74 Author: Liu Qi Date: Fri Aug 21 17:04:16 2026 +0800 usb-storage: ene_ub6250: fix race between scan work and probe commit 445fc368c6bc73eff0aeb3818cf5f355facfbb16 upstream. ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path. Reported-by: syzbot+22ea20ef3afb6785b122@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=22ea20ef3afb6785b122 Assisted-by: Qwen:Qwen3.6 Signed-off-by: Liu Qi Acked-by: Alan Stern Link: https://patch.msgid.link/20260821090416.1247127-1-liuqi@longcheer.com Signed-off-by: Greg Kroah-Hartman commit 7690a86b193271322cd31ab77349a87aa10858e4 Author: Shuangpeng Bai Date: Mon Jul 6 16:24:06 2026 -0400 media: usbtv: keep device alive while ALSA card exists commit fc530fe168bb2b745a93f553ad21fc25fd9cba3d upstream. The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card. Closes: https://lore.kernel.org/r/178144969601.60470.4852887710381872458@gmail.com Fixes: 63ddf68de52e ("[media] usbtv: add audio support") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 296a884cd6feb070492fa9198a03fec3ffd16c69 Author: Stephan Gerhold Date: Mon Jul 6 17:02:12 2026 +0200 clk: qcom: gcc-mdm9607: Increase delay for USB PHY reset commit c99bc8e83848358bd4a0436e4bdae5b7919babb2 upstream. To conform to the specifications of the USB PHY, the reset signal should be asserted for at least 10us. Guarantee that by increasing the delay for the USB2_HS_PHY_ONLY_BCR reset control similar to commit dcc6c9fb7128 ("clk: qcom: gcc-msm8909: Increase delay for USB PHY reset"). Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-5-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 9392a2c346762ffee8edd1ba8bac50d2e24a2ed7 Author: HyeongJun An Date: Tue Sep 1 18:04:09 2026 +0900 ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() commit e4637ce34607f1733a34a57294966d26b263e626 upstream. The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here. Fixes: 030a07e44129 ("ALSA: Add USB US122L driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260901090409.1478573-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 838455cc8bfe1278150d1d776529edea6cd4c1dd Author: Griffin Kroah-Hartman Date: Wed Aug 19 12:04:25 2026 +0200 usb: image: mdc800: change kmalloc() to kzalloc() commit 2430eb81e44111b30eeb5273bbcf8b24ca517ef9 upstream. Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify() Assisted-by: gkh_clanker_t1000 Cc: stable Signed-off-by: Griffin Kroah-Hartman Link: https://patch.msgid.link/20260819-usb_misc_random-v1-1-43a0dcee3a32@kroah.com Signed-off-by: Greg Kroah-Hartman commit 4814f28c45f58a71a80d09b80a60da6a063b539a Author: Hari Mishal Date: Sat Aug 22 16:57:51 2026 +0200 drm/amd/display: fix division by zero in get_estimated_bw() commit f63de9054da858d57054474c32464106f8375e0d upstream. get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. Fixes: 8e5cfe547bf3 ("drm/amd/display: upstream link_dp_dpia_bw.c") Reviewed-by: Alex Hung Assisted-by: gkh_clanker_t1000 Signed-off-by: Hari Mishal Signed-off-by: Alex Deucher (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 12ee39c2b1d3c99e1eda3b04218676960adebb1a Author: Anton Protopopov Date: Sun Oct 19 20:21:29 2025 +0000 bpf: fix the return value of push_stack commit 6ea5fc92a0fc1cde976cb701db2c1dba4dcab7cf upstream. In [1] Eduard mentioned that on push_stack failure verifier code should return -ENOMEM instead of -EFAULT. After checking with the other call sites I've found that code randomly returns either -ENOMEM or -EFAULT. This patch unifies the return values for the push_stack (and similar push_async_cb) functions such that error codes are always assigned properly. [1] https://lore.kernel.org/bpf/20250615085943.3871208-1-a.s.protopopov@gmail.com Signed-off-by: Anton Protopopov Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20251019202145.3944697-2-a.s.protopopov@gmail.com Signed-off-by: Alexei Starovoitov [ Ajay: Modified to apply on v6.18 ] Signed-off-by: Ajay Kaher Signed-off-by: Greg Kroah-Hartman commit c96477e0cabf55bfbdf078078e9de1c8024f8060 Author: Linus Torvalds Date: Thu Aug 20 20:12:39 2026 -0700 drm/xe: Don't hand out the flat CCS storage as usable VRAM commit 818bebeb63dd6bf5f4e07e145f6cdbace520a34c upstream. get_flat_ccs_offset() reads the base of the flat CCS storage from the hardware, scales it by the number of enabled L3 nodes, and rounds the result up to 128K. Everything below that offset is then handed to the VRAM allocator as usable memory. Rounding a limit that means "usable memory ends here" upwards publishes whatever lies between the real base and the rounded one as free memory, and that memory belongs to the compression hardware. The scaled value has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it is not: flat CCS base: raw 0x3fafff800, rounded 0x3fb000000 so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator's pool. Whatever is allocated there gets that tail overwritten by the compression hardware, which needs no page-table entry, no buffer object and no GPU submission to do it, and does it before userspace exists. On this machine a Mesa VM's level-3 page table landed on that page on every cold boot. It lost the entry covering the compositor's batch-buffer heap, so the compositor's first submission faulted fetching its batch and gdm restarted it forever: a black screen on an otherwise working machine. Restarting gdm cleared it because the next VM's page tables were allocated somewhere else. Round down instead, to the page size the allocator works in. On this machine that excludes exactly one page. Reading the reserved page afterwards shows what had been writing it: [369] 0xcccc000000000000 [371] 0xcc77000000000000 [373] 0xcccc000000000000 [375] 0xcc77000000000000 compression metadata, two bytes per sixteen, sitting where the driver used to hand out memory. The assertion that should have caught this compares the offset against GSMBASE - ccs_size for equality. That value is 128K aligned, so it agrees with the rounded-up offset precisely when the base is not aligned - the check cannot fail in the case it exists to catch, and is compiled out unless CONFIG_DRM_XE_DEBUG is set. Replace it with one that can fail: CCS storage must not run into GSM. [ And this was a debug session from hell, enormously helped by an AI doing much of the grunt-work. I'd like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it. I suspect those things have been trained by people who may not be quite as stubborn as I am. But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above. This is basically a one-liner fixing a bogus "round_up()" to a "round_down()", but there were 24 patches adding more and more debug information to this, and 18 kernel boot to finally narrow it down to this. - Linus ] Fixes: 37173392741c ("drm/xe/vram: fix ccs offset calculation") Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a6b088bee95fdbc698eeb2ea6627e4f789f0ed95 Author: Sun Jian Date: Sun Sep 6 12:08:32 2026 +0900 fsnotify: inotify: pass mark connector to fsnotify_recalc_mask() [ Upstream commit 4520b96b8136ba2465a3f4dc5c3fb8bdf3d92e4e ] fsnotify_recalc_mask() expects a plain struct fsnotify_mark_connector *, but inode->i_fsnotify_marks is an __rcu pointer. Use fsn_mark->connector instead to avoid sparse "different address spaces" warnings. Signed-off-by: Sun Jian Link: https://patch.msgid.link/20260214051217.1381363-1-sun.jian.kdev@gmail.com Signed-off-by: Jan Kara (cherry picked from commit 4520b96b8136ba2465a3f4dc5c3fb8bdf3d92e4e) Signed-off-by: Youngjae Kwon Signed-off-by: Sasha Levin commit 0ec897493ff82b256047f5549e779a9dc3baee59 Author: Mario Limonciello Date: Thu Oct 9 15:59:07 2025 -0500 drm/amd: Drop calls to restore power limit and clock from smu_resume() [ Upstream commit 4b6ec94fdae2407d9b8e69e3ec5f879e72ad667e ] User requested power limits and clock settings are already restored as part of smu_restore_dpm_user_profile(). It's unnecessary to call the same restore as part of smu_resume(). Revert the following commits to drop that extra restore: commit ed4efe426a49 ("drm/amd: Restore cached power limit during resume") commit 796ff8a7e01b ("drm/amd: Restore cached manual clock settings during resume") commit f9b80514a722 ("drm/amd: Only restore cached manual clock settings in restore if OD enabled") Suggested-by: Lijo Lazar Reviewed-by: Lijo Lazar Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0b6680e306397097a97767447368221fac753809 Author: Ali Ahmet Memis Date: Sun Sep 6 13:14:57 2026 +0300 mfd: qnap-mcu: keep the reply buffer alive past a command timeout commit 47504742cea7878ebd1bf1491bbed923df6b90b1 upstream. qnap_mcu_exec() publishes an on-stack buffer to the receive path: unsigned char rx[QNAP_MCU_RX_BUFFER_SIZE]; ... reply->data = rx; reply->length = length; and qnap_mcu_receive_buf() writes into it from the serdev receive path, which runs out of flush_to_ldisc() and is not serialized against qnap_mcu_exec() at all. bus_lock cannot cover it, because qnap_mcu_exec() holds that mutex across wait_for_completion_timeout(). On a timeout qnap_mcu_exec() returns with reply->data still pointing at its own frame. A reply that arrives late, or an unsolicited message from the MCU, is then written into a stack frame that has been left, corrupting whatever runs next on that stack. The same applies when qnap_mcu_write() fails, since that path returns without touching the reply state either. Move the receive buffer into struct qnap_mcu. It is 37 bytes and the structure is devm_kzalloc()ed, so it lives as long as the driver, and a late write lands in memory that is still valid and is reinitialized by the next command. bus_lock keeps commands from sharing it. This deliberately does not clear reply->data or reply->length on the timeout path. Doing so races with qnap_mcu_receive_buf(), which reads both after its if (!reply->length) return size; check: clearing reply->data gives a NULL dereference, and clearing reply->length alone removes the reply->received == reply->length exit condition, so the copy loop runs until the uart chunk is consumed and overruns the buffer. Leaving both set keeps the write bounded by reply->length, which qnap_mcu_exec() has already checked against sizeof(mcu->rx). Fixes: 998f70d1806b ("mfd: Add base driver for qnap-mcu devices") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Link: https://lore.kernel.org/all/20260802132012.537B81F000E9@smtp.kernel.org/ Link: https://patch.msgid.link/20260802135307.31380-1-ali@iusegentoo.com Signed-off-by: Lee Jones (cherry picked from commit 47504742cea7878ebd1bf1491bbed923df6b90b1) [ 6.18 lacks qnap_mcu_verify_checksum() and qnap_mcu_reply_is_any_error(), so the checksum check there still open-codes qnap_mcu_csum(); only its rx references were moved to mcu->rx. The fix itself is unchanged. ] Signed-off-by: Ali Ahmet Memiş Signed-off-by: Sasha Levin commit 617b48fc0baf009dccc844378b4d2d58d9b99689 Author: FUJITA Tomonori Date: Tue Dec 23 20:35:38 2025 +0900 objtool/rust: add one more `noreturn` Rust function [ Upstream commit c18f35e4904920db4c51620ba634e4d175b24741 ] Fix the following warning: rust/kernel.o: warning: objtool: _RNvXNtNtCs1ewLyjEZ7Le_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix14from_str_radix() falls through to next function _RNvXNtNtCs1ewLyjEZ7Le_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix16from_u64_negated() The commit 51d9ee90ea90 ("rust: str: add radix prefixed integer parsing functions") introduces u64::from_str_radix(), whose implementation contains a panic path for out-of-range radix values. The panic helper is core::num::from_ascii_radix_panic(). Note that radix is derived from strip_radix() here and is always within the valid range, so kernel never panics. Fixes: 51d9ee90ea90 ("rust: str: add radix prefixed integer parsing functions") Signed-off-by: FUJITA Tomonori Reviewed-by: Alice Ryhl Tested-by: Alice Ryhl Link: https://patch.msgid.link/20251223113538.1016078-1-fujita.tomonori@gmail.com [ Reworded typo. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 947400af98b9e63841929d079a2c3ea0a8ba227b Author: Youngjae Kwon Date: Sat Sep 5 11:48:00 2026 +0900 fsnotify: Fix stale object mask after concurrent mark updates [ Upstream commit e422777fdd4746de1109575c51e65038d4c5c1be ] When a mark gets a new event bit, fanotify and inotify may avoid recalculating the object mask if the cached aggregate already contains that bit. This is racy with a recalculation triggered by a concurrent update to another mark on the same connector. The concurrent scan can read the mark before the new bit is added, while the updater reads the old aggregate before that scan publishes its result. The updater then skips recalculation and the scan publishes a mask without the bit, leaving the object mask stale after both updates complete. This can be reproduced with two fanotify groups watching the same inode: one thread removes FAN_MODIFY from one existing mark while another thread adds FAN_MODIFY to the other mark. After both fanotify_mark() calls return, writes can fail to produce FAN_MODIFY for the group whose mark now contains the bit. This was reproduced on an unmodified v6.12.95 kernel. The equivalent inotify interleaving loses IN_MODIFY events. For normal fanotify additions, recalculate whenever the raw mark mask changes. The normal mask is not cleared asynchronously, so an unchanged addition cannot introduce missing interest. Always recalculate ignore-mask updates because FS_MODIFY handling may clear the ignore mask without taking mark->lock, making snapshot comparisons unreliable. Always recalculate after updating an existing inotify watch. Its replace path temporarily sets mark->mask to zero, so a concurrent scan can observe zero even when the old and final masks are equal. Assigning the replacement mask directly would avoid the transient zero, but existing-watch updates are infrequent, so unconditional recalculation is simpler. Link: https://lore.kernel.org/all/CACwKKmCZdiZDoFuYm6LZhQ=XvHPk0fNKH=X3LmoXMqakYqJaNw@mail.gmail.com/ Fixes: 63c882a05416 ("inotify: reimplement inotify using fsnotify") Fixes: 912ee3946c5e ("fanotify: do not call fanotify_update_object_mask in fanotify_add_mark") Cc: stable@vger.kernel.org # needs adjustments for <= 7.0 Suggested-by: Jan Kara Suggested-by: Amir Goldstein Signed-off-by: Youngjae Kwon Link: https://patch.msgid.link/20260802015801.2426818-1-yjkwon0026@snu.ac.kr Signed-off-by: Jan Kara (cherry picked from commit e422777fdd4746de1109575c51e65038d4c5c1be) [yjkwon0026: Resolve the inotify conflict by retaining the branch-native inode->i_fsnotify_marks argument to fsnotify_recalc_mask(). This tree lacks 4520b96b8136 ("fsnotify: inotify: pass mark connector to fsnotify_recalc_mask()"). The surrounding conditional is deleted by this patch, so that commit is not a prerequisite for this fix.] Signed-off-by: Youngjae Kwon Signed-off-by: Sasha Levin commit 459f33f82864723a7fa366cf1091d9c6c893b6b2 Author: Jinjie Ruan Date: Fri Sep 4 07:35:53 2026 +0200 entry: Fix seccomp bypass after ptrace with TSYNC commit 4a3591287fb7f808e209b4974ed337f609a2006b upstream. Sashiko review pointed out the following issue. If a thread is stopped in syscall_trace_enter() for ptrace, another thread can install a seccomp filter with SECCOMP_FILTER_FLAG_TSYNC (e.g., via seccomp_attach_filter()). This will successfully set SYSCALL_WORK_SECCOMP on the stopped thread, but syscall_trace_enter() evaluates a cached 'work' variable sampled on entry. Consequently, the subsequent check for SYSCALL_WORK_SECCOMP misses the newly assigned flag, and the filter is silently bypassed. This race condition could allow an unprivileged process to execute a prohibited system call (e.g., execve) that the newly installed filter was intended to block, especially since the tracer might have modified the system call number during the ptrace stop. Fix this by re-reading the syscall_work flags after ptrace handling, so that any new SYSCALL_WORK_SECCOMP flag set by another thread via TSYNC during the ptrace stop is observed before the subsequent seccomp check. Fixes: 142781e108b1 ("entry: Provide generic syscall entry functionality") Signed-off-by: Jinjie Ruan Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260629132914.1135C1F000E9@smtp.kernel.org/ Link: https://patch.msgid.link/20260713025712.416366-1-ruanjinjie@huawei.com Signed-off-by: Sasha Levin commit b5a5d389eee653f7076a16169ca4e57fca722e43 Author: Dev Jain Date: Fri Jul 3 11:41:58 2026 +0000 mm/page_vma_mapped: use huge_ptep_get() for hugetlb [ Upstream commit e87df0d5d6962bde50f55f6d02b779daa394f894 ] check_pte() is the final validation step in page_vma_mapped_walk(). It reads pvmw->pte with ptep_get() to decide whether the entry maps the PFN range being walked. For hugetlb VMAs, that pointer refers to a hugetlb entry. On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave. It is not clear whether this has a trivially visible effect to userspace. Use huge_ptep_get() to dereference a huge pte pointer. Link: https://lore.kernel.org/20260703114202.365553-6-dev.jain@arm.com Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()") Signed-off-by: Dev Jain Acked-by: David Hildenbrand (Arm) Reviewed-by: Muchun Song Cc: Alistair Popple Cc: Andi Kleen Cc: Anshuman Khandual Cc: Byungchul Park Cc: Catalin Marinas Cc: Dave Hansen Cc: Gregory Price Cc: Harry Yoo Cc: "Huang, Ying" Cc: Jann Horn Cc: Josh Poimboeuf Cc: Joshua Hahn Cc: Jun'ichi "Nick" Nomura Cc: Kiryl Shutsemau Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Mel Gorman Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Pedro Falcato Cc: Rakie Kim Cc: Ralph Campbell Cc: Rik van Riel Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Will Deacon Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e15407c3a8a005324f633cd46cd8fb58042c1157 Author: Yuqi Xu Date: Fri Sep 4 11:18:22 2026 +0200 openvswitch: Fix CT limit teardown use-after-free [ Upstream commit 403f96c32c9e24600093d7d0c61c17daeedca957 ] Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state. An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down. Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists. Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization. The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace. Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit") Cc: stable@vger.kernel.org Reported-by: Vega Link: https://lore.kernel.org/all/cover.1784711445.git.xuyuqiabc@gmail.com Co-developed-by: Nan Li Signed-off-by: Nan Li Signed-off-by: Yuqi Xu Reviewed-by: Ren Wei Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/288fbd5459d92b9dd0dcc6faf625f04819161ff3.1787280296.git.xuyuqiabc@gmail.com Signed-off-by: Jakub Kicinski [ 7.0+ uses kmalloc_obj[s] while older versions use kmalloc[_array] ] Signed-off-by: Ilya Maximets Signed-off-by: Sasha Levin commit a13b1e80e5015cd732440b475c0ef443dc4a2157 Author: Norbert Szetei Date: Fri Sep 4 10:59:39 2026 +0200 net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() [ Upstream commit 8ece906150128d5ec2462aabcc978c568433eca4 ] skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers. Fixes: 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors") Cc: stable@vger.kernel.org Suggested-by: Ilya Maximets Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/6E3A780D-FB87-421F-9964-B1D457D7D106@doyensec.com Signed-off-by: Paolo Abeni [ 7.2 and earlier do not have the put_page() call on the error path ] Signed-off-by: Ilya Maximets Signed-off-by: Sasha Levin commit 211a65465dd9b5e95b757f5eb002a3f077aca8ff Author: Alexandre Frade Date: Mon Sep 7 19:07:36 2026 +0000 Linux 6.18.50-xanmod1 Signed-off-by: Alexandre Frade commit e8b3291361f106a68e7cd4061a1d1e8eff81fb22 Merge: 8408b39fb74d 7cfc41f8e80f Author: Alexandre Frade Date: Mon Sep 7 19:01:55 2026 +0000 Merge tag 'v6.18.50' into 6.18 This is the 6.18.50 stable release commit 7cfc41f8e80f11ffa8382ed1a505154ceffb79c7 Author: Greg Kroah-Hartman Date: Mon Sep 7 17:23:00 2026 +0200 Linux 6.18.50 Link: https://lore.kernel.org/r/20260904045747.813364717@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Wentao Guan Tested-by: Shuah Khan Tested-by: Miguel Ojeda Link: https://lore.kernel.org/r/20260905115635.269562615@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Ron Economos Tested-by: Peter Schneider Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 8e30f5427f3458d5aca8f063f52e62ee24a81925 Author: Dev Jain Date: Thu Sep 3 19:56:31 2026 -0400 mm/rmap: use huge_ptep_get() in try_to_unmap_one() [ Upstream commit f5407e9b697c940e78b27ff63c6e14d8d171adc3 ] Patch series "Fix incorrect access of hugetlb pte entries", v3. There are various places which use ptep_get() to get the pte entry corresponding to a hugetlb folio. Some arches (like s390) have special handling to compute the pteval, so they provide huge_ptep_get(). Use this helper consistently. Additionally, some code paths may provide huge_ptep_get with an unaligned address. This is a problem on arm64 (I checked other arches and it looks fine for them), which is fixed in patch 1. The fix is made to be backport-friendly: the cleaner fix would be to perhaps pass the hstate to huge_ptep_get() - that is wider churn and we can do that later. This patch (of 5): try_to_unmap_one() handles hugetlb folios when memory failure needs to replace a poisoned hugetlb mapping with a hwpoison entry. In that case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get(). On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave. It is not clear whether this has a trivially visible effect to userspace. Just use huge_ptep_get() for dereferencing a huge pte pointer. Link: https://lore.kernel.org/20260703114202.365553-1-dev.jain@arm.com Link: https://lore.kernel.org/20260703114202.365553-3-dev.jain@arm.com Fixes: c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()") Signed-off-by: Dev Jain Reported-by: David Hildenbrand Reviewed-by: Muchun Song Acked-by: David Hildenbrand (Arm) Cc: Alistair Popple Cc: Andi Kleen Cc: Anshuman Khandual Cc: Byungchul Park Cc: Catalin Marinas Cc: Dave Hansen Cc: Gregory Price Cc: Harry Yoo Cc: "Huang, Ying" Cc: Jann Horn Cc: Josh Poimboeuf Cc: Joshua Hahn Cc: Jun'ichi "Nick" Nomura Cc: Kiryl Shutsemau Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Mel Gorman Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Pedro Falcato Cc: Rakie Kim Cc: Ralph Campbell Cc: Rik van Riel Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Will Deacon Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 381a0a524e967a8bb887372af64433e442e846ad Author: Lorenzo Stoakes Date: Thu Sep 3 19:56:30 2026 -0400 mm: avoid unnecessary use of is_swap_pmd() [ Upstream commit aa62204cb680d8ff32497181fc9e0dac4956f7e5 ] PMD 'non-swap' swap entries are currently used for PMD-level migration entries and device private entries. To add to the confusion in this terminology we use is_swap_pmd() in an inconsistent way similar to how is_swap_pte() was being used - sometimes adopting the convention that !pmd_none(), !pmd_present() implies PMD 'swap' entry, sometimes not. This patch handles the low-hanging fruit of cases where we can simply substitute other predicates for is_swap_pmd(). No functional change intended. Link: https://lkml.kernel.org/r/8a1704b36a009c18032d5bea4cb68e71448fbbe5.1762812360.git.lorenzo.stoakes@oracle.com Signed-off-by: Lorenzo Stoakes Reviewed-by: Vlastimil Babka Cc: Alexander Gordeev Cc: Alistair Popple Cc: Al Viro Cc: Arnd Bergmann Cc: Axel Rasmussen Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Byungchul Park Cc: Chengming Zhou Cc: Chris Li Cc: Christian Borntraeger Cc: Christian Brauner Cc: Claudio Imbrenda Cc: David Hildenbrand Cc: Dev Jain Cc: Gerald Schaefer Cc: Gregory Price Cc: Heiko Carstens Cc: "Huang, Ying" Cc: Hugh Dickins Cc: Jan Kara Cc: Jann Horn Cc: Janosch Frank Cc: Jason Gunthorpe Cc: Joshua Hahn Cc: Kairui Song Cc: Kemeng Shi Cc: Lance Yang Cc: Leon Romanovsky Cc: Liam Howlett Cc: Mathew Brost Cc: Matthew Wilcox (Oracle) Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Naoya Horiguchi Cc: Nhat Pham Cc: Nico Pache Cc: Oscar Salvador Cc: Pasha Tatashin Cc: Peter Xu Cc: Rakie Kim Cc: Rik van Riel Cc: Ryan Roberts Cc: SeongJae Park Cc: Suren Baghdasaryan Cc: Sven Schnelle Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: Wei Xu Cc: xu xin Cc: Yuanchu Xie Cc: Zi Yan Signed-off-by: Andrew Morton Stable-dep-of: f5407e9b697c ("mm/rmap: use huge_ptep_get() in try_to_unmap_one()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6a259dd313043fb99b63f57e9baa9db956b5909d Author: Tzung-Bi Shih Date: Wed Jul 15 02:44:53 2026 +0000 platform/chrome: sensorhub: Fix dropped timestamp events and log spam commit 9a3f43b30373c61477d0d3ab52946c05f9492bf9 upstream. Commit 833740a2333c ("platform/chrome: sensorhub: Bound the EC-reported sensor number") evaluated the `sensor_num` against the bounds limit even for timestamp events. A timestamp event typically has a `sensor_num` of 0xff [1], causing the driver to flag it as invalid and skip to the next event. As a result, we'd see a flooding of "Invalid sensor number 255 from EC" warning logs and these timestamp events were being dropped. Move the bounds-check into cros_ec_sensor_ring_process_event() and evaluate it only after standalone timestamp events have already been processed and returned early. [1] https://crrev.com/219ca6ef82ba266da788b673ee4ad50bd3ea1285/common/motion_sense_fifo.c#427 Fixes: 833740a2333c ("platform/chrome: sensorhub: Bound the EC-reported sensor number") Reviewed-by: Tomasz Figa Link: https://lore.kernel.org/r/20260715024454.4127571-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih Signed-off-by: Greg Kroah-Hartman commit e91d66e5ff6610185f79dcded36d1f1fa45826e5 Author: Injae Ryou Date: Mon Jul 13 18:27:00 2026 +0900 selftests/mm: fix on-fault-limit false failure under sudo-rs commit 98df164036bed307a16e7c124ad023c2c13c4b76 upstream. run_vmtests.sh runs on-fault-limit as the nobody user via "sudo -u nobody ./on-fault-limit", guarded by a check that nobody can access the binary ("sudo -u nobody ls ./on-fault-limit"). The guard resolves the relative path from the inherited working directory, which only requires search permission on the test directory itself. Classic sudo passes the relative path through to execve() the same way, so the two agree. However, sudo-rs (the default sudo implementation since Ubuntu 25.10) canonicalizes the command to an absolute path before executing it, which requires search permission on every ancestor directory. When the kernel tree lives under a private home directory (mode 0750, the Ubuntu default for new users since 21.04), the guard passes but the execution fails with "command not found", and the test is reported as a false FAIL: # running sudo -u nobody ./on-fault-limit sudo: './on-fault-limit': command not found # [FAIL] Wrap the command in "sh -c" so that sudo only resolves the shell binary, and the relative path is resolved by nobody's shell from the inherited working directory, matching what the guard checks. This is the only "sudo -u nobody" invocation in the script; uid, cwd, rlimits (including RLIMIT_MEMLOCK, which this test exercises) and the exit status are unchanged through sh. Verified on Ubuntu 26.04 (sudo-rs 0.2.13): the test now runs and passes instead of failing. Verified on Ubuntu 24.04 (sudo 1.9.15p5): behavior is unchanged. Link: https://lore.kernel.org/20260713092700.464376-1-injaeryou@gmail.com Fixes: 5d2146a3354f ("selftests/mm: skip mlock tests if nobody user can't read it") Signed-off-by: Injae Ryou Cc: Brendan Jackman Cc: Brendan Jackman Cc: David Hildenbrand Cc: Lorenzo Stoakes Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2d6150e5e6aa641e02e0072ac937b09bdc1e73f8 Author: Zhan Xusheng Date: Wed Jul 22 16:24:25 2026 +0800 udf: Fix i_lenExtents truncation on 32-bit kernels commit a5a5ed23b1340ff0f32a14a7ca8585f7c4e9b2e2 upstream. In udf_do_extend_file() the total extent length is rounded up to a block boundary with: iinfo->i_lenExtents = (iinfo->i_lenExtents + sb->s_blocksize - 1) & ~(sb->s_blocksize - 1); i_lenExtents is a __u64, but sb->s_blocksize is unsigned long. On 32-bit kernels unsigned long is 32-bit, so ~(sb->s_blocksize - 1) is a 32-bit value (e.g. 0xfffff800 for a 2 KiB block) that is zero-extended in the AND, clearing the upper 32 bits of i_lenExtents. For UDF files whose total extent length exceeds 4 GiB this truncates i_lenExtents when the file is extended, corrupting the tracked extent length. Cast the block size to 64-bit before forming the mask. 64-bit kernels are unaffected. Fixes: 48d6d8ff7dca ("udf: cache struct udf_inode_info") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Link: https://patch.msgid.link/20260722082425.213311-1-zhanxusheng@xiaomi.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit b7eff3f621ef24624f946e35fe7deb6a36398576 Author: Thomas Gleixner Date: Tue Aug 18 00:14:57 2026 +0200 timer: Keep debugobjects state consistent in migrate_timer_list() commit c793bbfc4a0a9f5a66978fc91559e9681748dbeb upstream. When timers are migrated away from an offline CPU the debugobjects state gets corrupted. The timer is accounted as inactive on deletion, but the enqueue on the alive CPU lacks the activation call. That used to work, but got broken when the trace point and the debug objects call got separated. That change missed to fixup migrate_timer_list(). Add the missing debug_timer_activate() invocation to fix it. Fixes: dc1e7dc5ac62 ("timer: Move trace point to get proper index") Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/87bjb0l7ha.ffs@fw13 Signed-off-by: Greg Kroah-Hartman commit fecf1e37775269ad38c172b468ad4ecc3968aa63 Author: Thomas Weißschuh (Schneider Electric) Date: Fri Jul 31 16:17:43 2026 +0200 timekeeping: Check the return value of tk_get_aux_ts64 in __do_adjtimex() commit 4b61084b11bcecce86d03804ff30f8d7b465593c upstream. If the auxiliary clock is disabled during tk_get_aux_ts64() but is enabled before tks->clock_valid is checked, then uninitialized stackdata will be used in the calculations and indirectly leaked to userspace. The same race window also exists after this change and also for the core timekeeper. But in these cases the only effect would be incorrect adjustments and this is userspace's responsibility to avoid this. Fixes: 4eca49d0b621 ("timekeeping: Prepare do_adtimex() for auxiliary clocks") Signed-off-by: Thomas Weißschuh (Schneider Electric) Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260731-timekeeping-aux-adjtimex-return-v1-1-b7fea4692886@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 6067c39c2cec1ad87c43fa20c0a6636380b67d62 Author: Bradley Morgan Date: Thu Jul 23 21:09:22 2026 +0000 taskstats: fix cpumask parsing cutting off the last character commit 1f58a5335cdd14b3fb5f2a5d3763dee1f5cba1d3 upstream. parse() hands nla_strscpy() len as dstsize, and nla_strscpy() copies at most dstsize - 1 bytes. When the attr payload comes in without a trailing NUL, srclen == len >= dstsize and the last character of the cpumask string gets cut off. Register "0-15" and you are silently listening on "0-1", exit data for the rest never shows up. The bug only bites when the sender doesn't NUL terminate the payload; senders that include the NUL were always fine (srclen gets decremented for the trailing NUL, so srclen < dstsize). Thats probably why this survived 20 years. And the policy is NLA_STRING, not NLA_NUL_STRING, so a payload without the trailing NUL is legit input here. Skip the kmalloc/nla_strscpy dance entirely and use nla_strdup(), which already allocates srclen + 1 and terminates. The nla_len() bounds checks stay as they were. Link: https://lore.kernel.org/EC49FE41-7F5F-41E0-A07A-ABEB8ECA514D@grrlz.net Fixes: f9fd8914c1ac ("[PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks") Signed-off-by: Bradley Morgan Reported-by: Oleg Deomi Closes: https://lore.kernel.org/CAByWkfZ6b1=3H9pwkz-dDQOs9cZaF-HYQ6b9Yb0=Hq2r1Vv_Pw@mail.gmail.com Reviewed-by: Andrew Morton Cc: Balbir Singh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ed64aa505875a3b4defd504ee8e59e1949246a62 Author: Jann Horn Date: Thu Aug 6 21:41:35 2026 +0200 smack: fix cred UAF in smack_file_send_sigiotask() commit fedc88e38ce979a720cd2de042578cb5df3dc8de upstream. When inspecting the credentials of another task, objective credentials (->real_cred, accessed with __task_cred()) must always be used. Accessing ->cred on a non-current task is forbidden unless that task is being created or destroyed; a task is allowed to change its own ->cred pointer with no synchronization, and changing ->cred should only affect the current syscall. smack_file_send_sigiotask() was accessing both sets of credentials: First tsk->cred, then __task_cred(tsk). Fix it, always access the objective credentials here. I have tested that this bug can lead to a KASAN-reported UAF of struct cred in smack_file_send_sigiotask(), and that this fix prevents the race. Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Signed-off-by: Casey Schaufler Signed-off-by: Greg Kroah-Hartman commit a246da20c8e4ae4319511c698b9f26ad0ad1769f Author: Bradley Morgan Date: Mon Jun 22 20:25:08 2026 +0000 signal: avoid shared siginfo namespace rewrites commit d19cdc167e696714509e87d3f7ae765b6e164589 upstream. send_signal_locked() rewrites sender ids for the target namespace. Group sends reuse the same siginfo, so one recipient can affect the next. Copy the siginfo before changing it. Link: https://lore.kernel.org/86a8857d58d43ee26a8b365b837fd24830343494.1782159692.git.include@grrlz.net Fixes: 7a0cf094944e ("signal: Correct namespace fixups of si_pid and si_uid") Signed-off-by: Bradley Morgan Acked-by: Oleg Nesterov Cc: "Eric W. Biederman" Cc: Adrian Huang Cc: Aleksandr Nogikh Cc: Christian Brauner Cc: Marco Elver Cc: "Masami Hiramatsu (Google)" Cc: Mathieu Desnoyers Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 236c8ecaafc63c9551f7def9be02fe86c7c1b5ed Author: Helge Deller Date: Thu Aug 6 17:04:15 2026 +0200 sticon/parisc: Detect default STI graphics card for console output commit de508ece1d37cdbbbfa52f074954310f9b066b13 upstream. If a machine has multiple graphic cards, detect the graphic card which is used to display firmware messages and use that one as the default graphic card for sticon and fbcon. On parisc machines the default graphic card used for BCH (boot console handler, aka BIOS menu) is stored in the stable storage (equivalent to CMOS storage on x86) or in the console path in page zero. Extract that path and store it as default STI path for later comparism. Take care that the graphic card can be a GSC or a PCI card which use different path strings. Increase max string size for default_sti_path to 32 chars as the print_pa_hwpath() function formats a hardware path using unbounded sprintf calls for up to 6 bus converter components and 1 module component (e.g., 255/255/...), which can produce a string up to 28 bytes long. Signed-off-by: Helge Deller Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e8527de7fea191fda704792a56081f9009aeec37 Author: Oleg Nesterov Date: Mon Jul 20 13:13:43 2026 +0200 sysctl: move the "cad_pid" entry from pid_table[] to kern_reboot_table[] commit 7170ca01623b399c97f2ae9d3e228badc1f25ea3 upstream. cad_pid is global, and kill_cad_pid() is only used in the root namespace. However, due to pid_table_root_permissions(), a non-root user can unshare pid/user namespaces and modify it from the child namespace. This makes no sense and is simply wrong. Move it to kern_reboot_table[] where it logically belongs; this ensures that only GLOBAL_ROOT_UID can read/modify this sysctl. Note that this patch doesn't preserve "#ifdef CONFIG_PROC_SYSCTL" around the "cad_pid"; CONFIG_PROC_SYSCTL selects CONFIG_SYSCTL, so it is always set when kern_reboot_table[] is compiled. Cc: stable@vger.kernel.org Fixes: e054bcbe7e7a ("sysctl: move cad_pid into kernel/pid.c") Signed-off-by: Oleg Nesterov Acked-by: Alexey Gladkov Reviewed-by: Bradley Morgan Reviewed-by: Pavel Tikhomirov Signed-off-by: Joel Granados Signed-off-by: Greg Kroah-Hartman commit cde2d927c29e82380851f209222256c607969a1f Author: Myeonghun Pak Date: Fri Jun 26 19:35:52 2026 +0300 tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout commit 705c4ed0643366963547b2616d53165f2519c81f upstream. i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper. Cc: stable@vger.kernel.org # v5.10+ Fixes: 4c336e4b1556 ("tpm: Add support for the Nuvoton NPCT501 I2C TPM") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260626091653.54929-1-mhun512@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit c3c7e87c76b42e640ef1d60c37b81b0e9f5ffd1d Author: Xu Rao Date: Tue Aug 4 10:34:03 2026 +0800 zloop: truncate finished zones to zone capacity commit 72e67c118642634c25465db0c8bcfa54c4ce086c upstream. The size of a sequential zone backing file records the amount of data written and is used to restore the zone state. A backing file whose size is equal to the zone capacity is restored as a full zone, while a file larger than the zone capacity is rejected as invalid. However, zloop_finish_zone() currently truncates the backing file to the zone size. For devices with a reduced zone capacity, finishing a zone therefore creates a backing file larger than the zone capacity. After the device is removed and later re-added, that zone file is rejected instead of being restored as a full zone. Truncate finished sequential zones to the zone capacity, matching the persistent representation accepted by zloop_update_seq_zone() for a full zone. Suggested-by: Damien Le Moal Fixes: eb0570c7df23 ("block: new zoned loop block device driver") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Reviewed-by: Christoph Hellwig Reviewed-by: Damien Le Moal Link: https://patch.msgid.link/B39E5FD81D1A07F4+20260804023403.939767-1-raoxu@uniontech.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f49e55b1c8fe1029476ee762ec3a11c6f51410c8 Author: Zi Yan Date: Tue Aug 4 17:04:28 2026 -0400 xarray: honor XA_FLAGS_ACCOUNT in xas_split_alloc() commit 789763523fb43cdc328de5cb5dcd19240ccf90d8 upstream. XArray operations that allocate xa_nodes, such as xas_nomem() and xas_alloc(), add __GFP_ACCOUNT when the array has XA_FLAGS_ACCOUNT set. This charges the allocated memory and avoids the workingset convergence issue described by commit 7b785645e8f13 ("mm: fix page cache convergence regression"). xas_split_alloc() does not add _GFP_ACCOUNT when XA_FLAGS_ACCOUNT is present. Fix it. Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-2-38cb3ff325c5@nvidia.com Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache") Signed-off-by: Zi Yan Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: Johannes Weiner Cc: Baolin Wang Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Matthew Wilcox (Oracle) Cc: Ryan Roberts Cc: William Kucharski Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ae0c79a8527044e54d81fd5a3b49ce6177633758 Author: Maoyi Xie Date: Mon Jun 29 20:10:43 2026 +0800 w1: ds28e17: reject an oversize length on an I2C block read commit 169ae5e65e5aaf213b6a578f6478a9fd2e523606 upstream. w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the device. The downstream slave puts a length byte in buf[0]. The driver then reads that many bytes into buf[1] with w1_f19_i2c_read(). buf[0] is controlled by the device and can be 0 to 255. w1_f19_i2c_read() only rejects a zero count. The caller buffer is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read run past it, up to about 222 bytes out of bounds. The SMBus core does check buf[0] against I2C_SMBUS_BLOCK_MAX. That check runs after master_xfer returns. By then the write is already done. i2c-algo-bit rejects an oversize length before it copies, and returns -EPROTO. Reject a length above I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites, the same way i2c-algo-bit does. Fixes: ebc4768ac497 ("add w1_ds28e17 driver for the DS28E17 Onewire to I2C master bridge") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Andi Shyti Link: https://patch.msgid.link/20260629121043.199487-1-maoyixie.tju@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 165a330a68b5f299d8735f0194c314cb2e571269 Author: Chengfeng Ye Date: Sun Aug 23 00:45:56 2026 +0800 vsock/virtio: flush works in dependency order commit 728836ebca239810f164262b10211ef59182f811 upstream. virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work. In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it. KASAN reported: BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush. Fixes: 0ea9e1d3a9e3 ("VSOCK: Introduce virtio_transport.ko") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Link: https://patch.msgid.link/20260822164556.3750959-1-nicoyip.dev@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 03b81f015dbb29807ce1ec6d45537d658abdac69 Author: Laxman Acharya Padhya Date: Mon Jul 13 17:39:12 2026 +0545 wifi: mt76: mt7996: validate default EEPROM firmware size commit 653c6e289b13cc6942f3e8f8e3c568e70fa42d1f upstream. The default EEPROM firmware is parsed and copied as a full EEPROM without checking its length. A truncated file can make the driver read beyond the firmware buffer during variant validation or the fallback copy. Reject files shorter than MT7996_EEPROM_SIZE before parsing or copying the firmware. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Cc: stable@vger.kernel.org Signed-off-by: Laxman Acharya Padhya Link: https://patch.msgid.link/20260713115412.67095-1-acharyalaxman8848@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 01f2e0da8548f82d704b65b513026cfedc5f8962 Author: Felix Fietkau Date: Wed Jul 22 08:26:05 2026 +0000 wifi: mt76: mt7996: fix TX DMA mapping leak for AddBA req frames commit deaa2e3656937fbbe312f0ee2616c756c6e2511f upstream. mt7996/mt7992 hand the firmware a HW MAC-TXP for AddBA req action frames (MT_TXD7_MAC_TXD, set in mt7996_mac_write_txwi_80211()), but are otherwise FW-TXP devices. On tx free mt76_connac_txp_skb_unmap() therefore decodes the per-frame txp as a struct mt76_connac_fw_txp. For a MAC-TXP the fw_txp.nbuf byte aliases the AddBA TID word (MT_TXP1_TID_ADDBA), which is always zero, so the unmap loop runs zero times and the skb DMA mapping in buf[1] is never unmapped. buf[1].skip_unmap is set unconditionally, so the generic DMA-ring cleanup skips it as well. Each AddBA req therefore leaks one TX DMA mapping, roughly one per (re)association. With WED enabled these mappings are bounced through the WED swiotlb pool, so under continuous client reconnect churn the pool is exhausted after ~1-2 days, after which DMA mapping fails for WED, the WiFi MCU and other on-SoC consumers. Keep the deferred (token release) unmap that the design relies on, and add an mt7996-specific txp unmap that inspects MT_TXD7_MAC_TXD and unmaps buf[1] from the MAC-TXP layout for those frames, delegating to mt76_connac_txp_skb_unmap() otherwise. Cc: stable@vger.kernel.org Fixes: cb6ebbdffef2 ("wifi: mt76: mt7996: support writing MAC TXD for AddBA Request") Link: https://patch.msgid.link/20260722082610.2699628-13-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 304470333b7f525b23699ea7a7aed3b40ca37ca9 Author: Devin Wittmayer Date: Sat Jun 27 13:29:46 2026 -0700 wifi: mt76: mt7925: cancel mlo_pm_work on stop commit 81faf578320df2dfc682a96baa6e85851dd68b6f upstream. mt7925 queues mlo_pm_work with a 5 second delay during multi-link power-save setup and never cancels it on the stop path. If the device is torn down inside that window, the work outlives the teardown and its timer fires afterwards, trying to queue onto the workqueue that is already gone: workqueue: cannot queue mt7925_mlo_pm_work [mt7925_common] on wq phy0 WARNING: kernel/workqueue.c:2283 at __queue_work+0x59/0xa0, CPU#1: swapper/1/0 call_timer_fn+0x2a/0x140 __run_timers+0x203/0x330 run_timer_softirq+0x86/0xf0 mt7921 already has its own stop callback, so add one for mt7925 that cancels the work before calling mt792x_stop(). mt7925_ops backs both the PCIe and USB drivers, so this covers both. Fixes: 276a56883257 ("wifi: mt76: mt7925: update the power-saving flow") Cc: stable@vger.kernel.org Tested-by: Traockl <281473483+Traockl@users.noreply.github.com> Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260627202946.25598-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 5fdaf7016d7684ef756a229fd5d96b4a140eeb40 Author: Bryam Vargas Date: Thu Jun 25 07:10:26 2026 -0500 wifi: mt76: mt7915: bound the device EEPROM address before the EFUSE copy commit 44b5adfe49499f53002737f5fe81d608c08122fc upstream. mt7915_mcu_get_eeprom() copies a fixed EFUSE block into the driver's dev->mt76.eeprom.data buffer at the offset reported by the MCU response (res->addr, a device-controlled __le32) without checking it against the buffer size. A malicious or malfunctioning device can report an arbitrary address and drive a 16-byte out-of-bounds write past eeprom.data. Reject a response whose address would place the copy outside eeprom.data before deriving the destination pointer. Devices that echo the requested in-bounds offset are unaffected. Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260625-b4-disp-16f99062-v1-1-aee52ecf61b9@proton.me Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 4506e229b2e468b8c64bcf52c50c41a3bf2e633e Author: Runyu Xiao Date: Fri Jun 12 12:13:31 2026 +0800 wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex commit bda8324270b1ac91bfba1df8928e0570e29759e8 upstream. mt7615_suspend() acquired the mt76 mutex and then called cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the same mutex via mt7615_mutex_acquire() at the top of the worker, so if mac_work is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against. Flush scan_work and mac_work before taking the mutex, matching the suspend paths in mt7921 and mt7925. scan_work only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps mac_work from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed. Fixes: c6bf20109a3f ("mt76: mt7615: add WoW support") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260612041331.2596331-1-runyu.xiao@seu.edu.cn Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 34a505071d1ffc5ebf3dc3cd16d2a12b044bcc84 Author: Dawei Feng Date: Wed Jun 17 09:35:02 2026 +0800 wifi: rtw88: pci: fix resource leak on failed NAPI setup commit e779df4806cd29cbcca5c9dc0a1073662c76b889 upstream. rtw_pci_probe() allocates PCI resources through rtw_pci_setup_resource() before it sets up NAPI. If rtw_pci_napi_init() fails, the error path jumps straight to err_pci_declaim and skips rtw_pci_destroy(), leaving the PCI resources allocated by rtw_pci_setup_resource() behind. Add a dedicated cleanup label for the NAPI setup failure path so probe destroys the PCI resources. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing current mainline kernels. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have a suitable rtw88 PCI board to test with, no runtime testing was able to be performed. Fixes: d0bcb10e7b94 ("wifi: rtw88: Un-embed dummy device") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260617013502.114057-1-dawei.feng@seu.edu.cn Signed-off-by: Greg Kroah-Hartman commit 7364713f0931ee45fdf0bea27103b40ccc94979a Author: Abdun Nihaal Date: Mon Jul 27 12:12:22 2026 +0530 wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb() commit 9f2948010764d708bda27369d09ce6f194abe8e3 upstream. The skb passed to the rtw_hci_tx_write() is expected to be freed when the function fails, but the error path in rtw_txq_push_skb() does not free the skb before returning. This can lead to a memory leak in rtw_txq_push() where a dequeued skb is passed to rtw_txq_push_skb(). Fixes: aaab5d0e6737 ("rtw88: kick off TX packets once for higher efficiency") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260727064223.61836-1-nihaal@cse.iitm.ac.in Signed-off-by: Greg Kroah-Hartman commit dc8b0be0ec4d9b0c80f07b27e656e4a94de5a344 Author: Abdun Nihaal Date: Thu Jul 23 17:15:37 2026 +0530 wifi: rtlwifi: rtl8192du: Fix possible memory leak in rtl92du_init_sw_vars() commit 6496ce90845df2d22fb8e8ed235cd2936fad41c8 upstream. The memory allocated inside rtl92du_init_shared_data() is not freed in any of the subsequent error paths in rtl92du_init_sw_vars(). Fix that by adding a call to rtl92du_deinit_shared_data() in the error path. Fixes: b5dc8873b6ff ("wifi: rtlwifi: Add rtl8192du/sw.c") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260723114539.136986-1-nihaal@cse.iitm.ac.in Signed-off-by: Greg Kroah-Hartman commit 0c0b374e12d52af23ca741728db31091677cf9dc Author: Runyu Xiao Date: Sat Jun 20 10:56:32 2026 +0800 wifi: rtlwifi: rtl8192du: check QoS TID before indexing tids commit ed4f05d9f2f42fd866f55108db8123eefcc5fb33 upstream. rtl92du_tx_fill_desc() uses ieee80211_get_tid() to read the QoS TID from the 802.11 header and then uses it as an index into sta_entry->tids[]. ieee80211_get_tid() returns the low 4-bit QoS TID value, so the result can be in the range 0..15. rtlwifi only allocates MAX_TID_COUNT entries for sta_entry->tids[], and MAX_TID_COUNT is 9. A QoS TID greater than 8 therefore indexes past the aggregation state array. Keep the default RTL_AGG_STOP state for out-of-range TIDs, matching rtl92cu_tx_fill_desc(). This issue was detected by our static analysis tool and confirmed by manual audit. UBSAN validation for the same bug pattern reports an array-index-out-of-bounds access with index 10 for type 'rtl_tid_data [9]'. Fixes: 8321424134a4 ("wifi: rtlwifi: Add rtl8192du/trx.{c,h}") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260620025632.46206-1-runyu.xiao@seu.edu.cn Signed-off-by: Greg Kroah-Hartman commit 97a1af5ac131b8715917d869517df32366dea384 Author: Stanislaw Gruszka Date: Thu Jul 23 13:06:40 2026 +0200 wifi: rtl818x: initialize eeprom_93cx6 struct to zero commit 799b5f45cb8194ebd06c9c89e0afdad5bedd2cc5 upstream. Commit 7738a7ab9d12 ("misc: eeprom: eeprom_93cx6: Add quirk for extra read clock cycle") added extra 'quirk' field to struct eeprom_93cx6. Many existing users of eeprom_93cx6, including rtl818x drivers, allocate the structure on the stack without initializing all fields. As a result, the added quirk field has an undefined value and can randomly cause reading wrong data from the EEPROM. Fix by initializing the structures with {}. Fixes: 7738a7ab9d12 ("misc: eeprom: eeprom_93cx6: Add quirk for extra read clock cycle") Cc: stable@kernel.org # v6.13+ Signed-off-by: Stanislaw Gruszka Reviewed-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260723110640.8588-1-stf_xl@wp.pl Signed-off-by: Greg Kroah-Hartman commit b1bbeb8970eeb6c6bf3cd5314138103f7b69446d Author: Fabio Estevam Date: Fri Jul 24 17:33:19 2026 -0300 wifi: mwifiex: Detach sync cmd buffer on interrupted wait commit ef06882c7d8a7400b67d0d003b1008093dd589ed upstream. mwifiex synchronous commands keep the caller-provided data buffer in cmd_node->data_buf. Several callers pass stack-allocated objects there. If wait_event_interruptible_timeout() is interrupted, the caller can return and release that stack object while the firmware command is still the current command. A late firmware response then reaches the normal response handler, which can copy data through cmd_node->data_buf into the stale stack address. This fixes a stack corruption observed during repeated association and disassociation cycles. The panic trace showed the command wait being interrupted immediately before a bad pointer dereference: cmd_wait_q terminated: -512 Unable to handle kernel paging request at virtual address 002c583837384662 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted ... Tainted: [M]=MACHINE_CHECK The fault address decodes as little-endian ASCII: 0x002c583837384662 -> "bF878X,\0" which is a fragment of the VERSION_EXT firmware string exposed as debugfs "verext": w8997o-V4, RF878X, FP92, 16.92.21.p153.7 The same runs also showed corrupted control data containing: 0x2400372e333531 -> "153.7\0$" which is the tail of the same VERSION_EXT string. This points at a late VERSION_EXT response writing through a stale stack-backed data_buf after the interrupted wait returned. After cancelling pending commands on an interrupted or timed-out wait, detach the caller-owned data buffer from the still-current command. This preserves the existing command cancellation behaviour while preventing a late response from writing through a pointer whose lifetime ended with the waiting caller. Tested on an i.MX8MP board using an 88W8997. Cc: stable@vger.kernel.org Fixes: 3d026d09b28d ("mwifiex: cancel pending commands for signal") Signed-off-by: Fabio Estevam Link: https://patch.msgid.link/20260724203320.78793-1-festevam@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 7c257a295e05ceb8f78aa3efecc4e9ce19c3313f Author: Eric Biggers Date: Mon Jun 15 15:41:30 2026 -0700 crypto: sun8i-ss - Remove crypto_rng interface commit a78446ee6fae86ac8733f120e3ffce2e5d9384f5 upstream. Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ss support which is one of the only remaining ones. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. Also, it had a buffer overread bug in the line 'memcpy(ctx->seed, d + dlen, ctx->slen);'. There's no point in fixing these bugs separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable. Fixes: ac2614d721de ("crypto: sun8i-ss - Add support for the PRNG") Cc: stable@vger.kernel.org Cc: Corentin Labbe Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 8e4f9110aba3127024646ef7a8999dcfcc03f516 Author: Eric Biggers Date: Mon Jun 15 15:41:29 2026 -0700 crypto: sun8i-ce - Remove crypto_rng interface commit 011556f71d094da61379ae3672692cae2795304e upstream. Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ce support which is one of the only remaining ones. Note that the sun8i-ce support for hwrng remains in place. That is the interface that actually matters. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. There's no point in fixing this separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable. Fixes: 5eb7e9468884 ("crypto: sun8i-ce - Add support for the PRNG") Cc: stable@vger.kernel.org Cc: Corentin Labbe Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 620acb1e8037b73a457dc8ef20fc23fc7adcb405 Author: Fan Wu Date: Tue Jun 30 03:31:17 2026 +0000 wifi: rtl8xxxu: fix use-after-free from rx_urb_wq on stop commit 6c080026ecc17eecb103f8927c64ea73a74bb818 upstream. rtl8xxxu arms rx_urb_wq from the RX completion path: rtl8xxxu_rx_complete() hands the URB to rtl8xxxu_queue_rx_urb(), which queues it on rx_urb_pending_list and, once the list grows past RTL8XXXU_RX_URB_PENDING_WATER, schedules rx_urb_wq. The worker rtl8xxxu_rx_urb_work() drains rx_urb_pending_list, recovers priv through container_of, and resubmits each URB through rtl8xxxu_submit_rx_urb(), which anchors it on rx_anchor and dereferences priv->udev. rtl8xxxu_stop() cancels the sibling work items (c2hcmd_work, ra_watchdog, update_beacon_work) but never cancels rx_urb_wq, so a worker armed during the last burst of RX traffic can run rtl8xxxu_rx_urb_work() after rtl8xxxu_disconnect() has called ieee80211_free_hw(), which frees priv, producing a use-after-free. The window opens under active RX traffic (pending count above the watermark) followed by a disconnect. There are two teardown races to close: * rtl8xxxu_queue_rx_urb() decided whether to enqueue under rx_urb_lock but called schedule_work() after dropping the lock. A completion that observed shutdown == false and released the lock could then call schedule_work() after rtl8xxxu_stop() had set shutdown and cancel_work_sync() had already returned, arming the worker to run after the teardown. Move schedule_work() under the same !shutdown branch so the arming decision is atomic with the shutdown check. * rtl8xxxu_rx_urb_work() anchors every URB it drained back onto rx_anchor through rtl8xxxu_submit_rx_urb(). A worker still running when usb_kill_anchored_urbs(&priv->rx_anchor) returned would submit a URB that escaped the kill. In rtl8xxxu_stop(), call cancel_work_sync(&priv->rx_urb_wq) before the kill so the worker is drained first. After priv->shutdown is set under rx_urb_lock, completions can no longer queue rx_urb_wq. cancel_work_sync() then drains the last queued or running worker, and the following usb_kill_anchored_urbs() kills the URBs it may have submitted. rtl8xxxu_disconnect() is covered because ieee80211_unregister_hw() guarantees .stop() runs for a live interface before ieee80211_free_hw() frees priv. The probe error path needs no cancel: rx_urb_wq is INIT_WORK()'d there but cannot have been scheduled, since no URB is submitted before ieee80211_register_hw() succeeds. This bug was found by static analysis. Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260630033117.3377-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 84ba017a1e1ea7896ed1e3258c947bdbfc5299c5 Author: Dawei Feng Date: Wed Jun 24 16:44:04 2026 +0800 wifi: iwlwifi: dvm: fix memory leak in iwl_op_mode_dvm_start() commit 67105abd6195a685a84dcb8a5daf54a1f4bfdb60 upstream. In iwl_op_mode_dvm_start(), jumping to out_free_eeprom currently bypasses the out_free_eeprom_blob label. Consequently, error paths triggered after successfully parsing the EEPROM free priv->nvm_data but leak priv->eeprom_blob. Fix this memory leak by reordering the error handling labels so that out_free_eeprom falls through to out_free_eeprom_blob. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc6. An x86_64 allyesconfig build showed no new warnings. As we do not have supported Intel DVM wireless hardware and firmware to test with, no runtime testing was able to be performed. Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng Link: https://patch.msgid.link/20260624084404.570703-1-dawei.feng@seu.edu.cn Signed-off-by: Miri Korenblit Signed-off-by: Greg Kroah-Hartman commit 261d7c7610b4b2f476382c88a2d1ae0cc5e07add Author: Abdun Nihaal Date: Mon Aug 3 11:35:06 2026 +0200 wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() commit 0d10db8e94fcb23a799789aaa696b4d8f937e207 upstream. The memory allocated for buf is not freed in some of the error paths in brcmf_sdio_read_control(). Fix that by adding vfree() calls. Cc: stable@vger.kernel.org Fixes: dd43a01c5cdb ("brcmfmac: use dynamically allocated control frame buffer") Signed-off-by: Abdun Nihaal [arend: rework as suggested by Johannes] Signed-off-by: Arend van Spriel Link: https://patch.msgid.link/20260803093506.1647790-1-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 7ef23317f9976f35fe97ceb8e8406eb47718fd49 Author: Claudiu Beznea Date: Mon Jul 13 16:05:32 2026 +0300 i3c: renesas: Reconfigure the DATBAS register on re-attach commit 1364afd3e2e76e007a2c07ec95704d56980226f0 upstream. During re-attach, the device may change its position in the i3c->addrs[] array. As a result, it may use a different Device Address Table Basic Register (DATBAS), which needs to be reconfigured. Reconfigure the DATBAS register on re-attach. Along with it update software caches. Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Claudiu Beznea Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260713130545.568657-5-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 9382fcf3a8c448aaa98faaba3d52c94b565d9695 Author: Claudiu Beznea Date: Mon Jul 13 16:05:35 2026 +0300 i3c: renesas: Clean DATBAS register on detach commit 797ed83c0cd495be4b345750c59e0363bf4d6207 upstream. The controller uses DATBAS registers on TX/RX logic. Clean the DATBAS register for the detached I3C device to avoid issues. Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Claudiu Beznea Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260713130545.568657-8-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 0093f9fc102ba8b98561fdd2f8559553ef56be59 Author: Claudiu Beznea Date: Mon Jul 13 16:05:29 2026 +0300 i3c: renesas: Check that the transfer is valid before accessing it commit 5f1a76ecfe90544a28d657306c9b3caa66ba0e63 upstream. The Renesas I3C driver uses an asynchronous model to transfer data. It prepares a struct renesas_i3c_xfer, enqueues it, and waits for completion. The interrupt handler dequeues the transfer, updates/uses it, and signals the waiting thread. If the completion times out, the waiting thread dequeues the transfer and free it. If an interrupt fires after that, the handler may access freed memory, leading to crashes. Check that the transfer is still valid before accessing it in the interrupt handler. With it clear any status flags and disable all the interrupts to avoid triggering the same interrupts again. Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea Reviewed-by: Frank Li Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260713130545.568657-2-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 5697d779577e2786ff3348ae9b77020ac0cf0aab Author: Maoyi Xie Date: Wed Jun 24 13:04:33 2026 +0800 i3c: master: svc: bound IBI payload to the requested max_payload_len commit e2bda39d7f9f285ec803e200b5c1f17143d0b483 upstream. svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into the IBI slot. The loop is bounded by the hardware FIFO size (SVC_I3C_FIFO_SIZE), not by the slot size. slot->data points into the IBI pool, which i3c_generic_ibi_alloc_pool() sizes at max_payload_len per slot. svc_i3c_master_request_ibi() only rejects a max_payload_len larger than SVC_I3C_FIFO_SIZE, so a driver can request a smaller one. mctp-i3c requests 1. Each readsb() then copies the controller RXCOUNT bytes (up to 31) with no check against the slot size. A device that sends more bytes than the slot holds writes past slot->data, an out-of-bounds write into the IBI pool. Bound the loop by dev->ibi->max_payload_len and clamp each read to the space left in the slot, the same way dw-i3c does. A device can still send more than the requested payload. Flush the leftover bytes from the RX FIFO so they do not leak into the next transfer. Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver") Cc: stable@vger.kernel.org Co-developed-by: Kaixuan Li Signed-off-by: Kaixuan Li Signed-off-by: Maoyi Xie Reviewed-by: Frank Li Link: https://patch.msgid.link/178227747353.2931373.15868718612134648277@maoyixie.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 94fb9786d67a8f8b899e77381620f86bad94fdf7 Author: Adrian Hunter Date: Thu Jul 23 10:57:47 2026 +0300 i3c: master: Fix info leak and UAF in device unregister path commit d2c743efd2d1ee64e94324664808f623dd865872 upstream. i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During device_unregister(), device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct i3c_device_info, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind. Keep desc valid until device_unregister() has completed. Since device_unregister() drops the device reference and may free the device, take an extra reference with get_device() before unregistering. Clear desc afterwards and release the extra reference with put_device(). This preserves the release-time invariant that desc must be NULL while avoiding both the information leak and a potential use-after-free from writing desc after the device has been released. Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/linux-i3c/20260702190003.8BF741F000E9@smtp.kernel.org/ Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260723075747.34049-1-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit a15a1b95de980362c14f32f519b293b0d12ce86f Author: Runyu Xiao Date: Wed Jun 17 23:01:38 2026 +0800 i3c: master: adi: initialize the lock before enabling interrupts commit 8a53f9102a0d3eeb8784999f925028acf339c276 upstream. adi_i3c_master_probe() requests the IRQ and unmasks REG_IRQ_PENDING_CMDR before the controller's IBI state, transfer queue list and transfer queue lock are initialized. A pending CMDR interrupt can therefore run adi_i3c_master_irq() and take master->xferqueue.lock before the dynamic lock has been initialized. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the probe ordering and the IRQ path adi_i3c_master_probe() -> adi_i3c_master_irq() -> xferqueue.lock, with a pending CMDR interrupt arriving after REG_IRQ_PENDING_CMDR is unmasked. Lockdep reported: INFO: trying to register non-static key. you didn't initialize this object before use? lock_acquire+0xbb/0x290 _raw_spin_lock_irqsave+0x36/0x60 adi_i3c_master_irq+0x32/0x56 [vuln_msv] adi_i3c_master_probe+0x5a/0xf47 [vuln_msv] Initialize the transfer queue and IBI state before requesting and unmasking the IRQ. Fixes: a79ac2cdc91d ("i3c: master: Add driver for Analog Devices I3C Controller IP") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Reviewed-by: Frank Li Link: https://patch.msgid.link/20260617150138.628578-1-runyu.xiao@seu.edu.cn Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 1894fc7a3bab90143dcd26ef8ee27040ef4a7501 Author: Jianyun Gao Date: Mon Jul 20 11:36:32 2026 +0800 dm-pcache: fix use-after-free and invalid seg operations in kset_replay() commit c2e894eac398b258f12fdec73ed6ba081047f7b3 upstream. In kset_replay, when key->seg_gen is stale (key->seg_gen < key->cache_pos.cache_seg->gen), cache_key_put(key) is called but then key->cache_pos.cache_seg is accessed as the argument to cache_seg_get(). This is a use-after-free on the freed key memory. Although mempool recycled memory is not immediately reclaimed or overwritten in practice, this is still a potential UAF bug. Additionally, for expired invalid keys, setting the cache->seg_map bit and calling cache_seg_get() is unreasonable since the corresponding segment data is no longer valid. Fix both issues by moving cache_seg_get() and __set_bit() after the gen check, so they only execute for valid keys, and using continue to skip invalid keys. Cc: stable@vger.kernel.org Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Signed-off-by: Jianyun Gao Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 10acf740c3adbbd86731b24d0bc43ec1010084bc Author: Jianyun Gao Date: Mon Jul 20 17:46:48 2026 +0800 dm-pcache: fix implicit u8 truncation of gc_percent in message handler commit fb9e17287a4ea1cbbcedc77e6866978ecc2a7b55 upstream. When setting gc_percent via message, kstrtoul parses the input into an unsigned long, which is then implicitly truncated to u8 when passed to pcache_cache_set_gc_percent(). For example, value 266 (0x10A) silently truncates to 10 (0x0A), successfully bypassing the > 90 upper bound check in pcache_cache_set_gc_percent(), and setting a different value than the user intended. Use kstrtou8 directly instead of kstrtoul, so that overflow values are properly rejected. Cc: stable@vger.kernel.org Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Signed-off-by: Jianyun Gao Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 83e3116283ed2c6a6a1fa662862a4b4d7d2701a2 Author: Bryam Vargas Date: Fri Jul 17 06:27:04 2026 -0500 dm-pcache: only hand out initialized cache segments commit 2df0fc042e299bae3c0f60ea5cd2af9285658e9f upstream. get_cache_segment() scans the segment map up to cache->n_segs, the physical device segment count, but cache_segs_init() only initializes the first cache_info->n_segs segments. A crafted image with cache_info->n_segs smaller than the device count leaves the remaining pcache_cache_segment structs zeroed (segment.data == NULL), and the allocator can hand one to cache_kset_close(), which writes through the returned segment's data pointer with no NULL check. Bound the allocator's search to cache_info->n_segs so only initialized segments are ever returned. A conforming cache sets n_segs equal to the device segment count, so this rejects nothing legitimate. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 663ee2f3824a505b983162de44134e789f8230da Author: Bryam Vargas Date: Fri Jul 17 06:26:59 2026 -0500 dm-pcache: detect a cycle in the last-kset chain during replay commit 16c3b3a326e70f246a605b3dc27b7f83ba4743e3 upstream. cache_replay() follows the on-media last-kset chain by next_cache_seg_id with no cond_resched(). A forged chain that points back into a segment it has already visited makes the replay loop follow it forever. Cap the last-kset hops at cache->n_segs; a valid chain visits each segment at most once. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 2cd9776fe3f2d88ec22c36d3c8ba09fbf9d5500c Author: Bryam Vargas Date: Fri Jul 17 06:27:01 2026 -0500 dm-pcache: clamp the tail kset read to the segment data region commit becf07e2b0053027495ecd671b1f82fb2e615f68 upstream. The tail-kset read in cache_replay(), the writeback worker and the GC worker bounds its length by PCACHE_SEG_SIZE - seg_off, the raw segment size rather than the data region. A tail near the segment end reads past the segment data into the following control area. Clamp the read to cache_seg_remain(), the data region. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit ffd9a214a94f9928e54856f42b1cc3e33fb10e36 Author: Bryam Vargas Date: Fri Jul 17 06:26:57 2026 -0500 dm-pcache: bound the persisted tail-position offset commit d1898576090a10d2ac2715218a652e78fb65a6b0 upstream. cache_pos_decode() takes the persisted key_tail and dirty_tail seg_off from the cache device and addresses within the segment with it. A seg_off at or past the segment data_size, controllable by whoever supplies the device (CAP_SYS_ADMIN), reads past the segment data. Reject a decoded seg_off that is not below the segment data_size. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 91b93fe5cf4d62d5ecc642a6c8f15a3c11b00e3c Author: Bryam Vargas Date: Fri Jul 17 06:27:02 2026 -0500 dm-pcache: validate on-media seg_num against the cache device size commit 62d92e45abe9e087370f9fc5d876b95673aced34 upstream. seg_num is read from the crc32c-only superblock, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls it. It sizes cache->segments[] and is the value every later on-media segment id is bounded against, yet it is never checked against the device. Because cache_dev->mapping is the direct map of the pmem, CACHE_DEV_SEGMENT() for a segment id past the device resolves to ordinary kernel memory beyond the mapping; a new-cache init reaching such an id has cache_seg_init() -> cache_dev_zero_range() memset() 12 KiB over that memory -- an out-of-bounds write into the kernel heap at table load. A zero seg_num makes the segment allocations ZERO_SIZE_PTR. Reject a seg_num that is zero, larger than the device can hold, or larger than PCACHE_CACHE_SEGS_MAX before it is used. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit d8caf96040a06096276ab72f5e1e8547c014c564 Author: Bryam Vargas Date: Fri Jul 17 06:26:56 2026 -0500 dm-pcache: validate kset key_num and intra-segment bounds commit f11deb032fd84081e7831cffcba895d893054a22 upstream. Two more fields decoded from the cache device go unbounded. The kset key_num drives cache_kset_crc() and the replay loop in cache_replay(), the writeback worker and the GC worker, but only the magic and a fixed-seed CRC are checked first, so a non-last kset whose key_num exceeds the PCACHE_KSET_KEYS_MAX buffer reads past its end before the CRC compare. A key's intra-segment offset and length in cache_key_decode() are taken verbatim, so a key running past its segment is replayed into the cache tree and the data CRC check and every later read hit then copy adjacent persistent memory into the caller's bio -- an out-of-bounds read that leaks to user space. Both fields are controlled by whoever supplies the cache device (CAP_SYS_ADMIN); the CRC seed is public. Add kset_onmedia_valid() to bound key_num before any kset read, and reject a key whose offset plus length, computed in 64 bits, exceeds the segment data_size. Valid metadata is unaffected. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit ab5dcde6fa96bc115b85f3621c60e39c66229a90 Author: Bryam Vargas Date: Fri Jul 17 06:26:55 2026 -0500 dm-pcache: validate geometry fields from on-disk cache_info commit 32d1809da31094ef76fd98dc1f1a8b55ca1295dd upstream. cache_segs_init() iterates cache_info->n_segs times indexing cache->segments[], which is sized to the cache device geometry, and get_seg_id() takes each segment id from the on-media cache_info and the per-segment next_seg link. Both come from cache device metadata that is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls them: an oversized n_segs or an out-of-range id drives an out-of-bounds access of cache->segments[] and a wild CACHE_DEV_SEGMENT() pointer into the device mapping -- an out-of-bounds read and write from on-disk data. Reject an n_segs that exceeds the device segment count and a segment id that is out of range before either is used. Valid metadata is unaffected. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 296efdc110b10665c4f2e48e2540f3507267acf3 Author: Haotian Zhang Date: Sat Jul 11 22:21:55 2026 +0800 dm-switch: use WRITE_ONCE() in switch_region_table_write() commit c7391ebe33162c7962b313caea4d8e6b0bc2a671 upstream. switch_region_table_read() accesses the region table with READ_ONCE() and is called from the lockless switch_map() IO path. However, switch_region_table_write() stores to the same array with a plain assignment. This results in an inconsistent access pattern for a lockless shared variable and may trigger data race reports. Use WRITE_ONCE() to pair with the existing READ_ONCE() in switch_region_table_read(). Cc: stable@vger.kernel.org Fixes: 99eb1908e643 ("dm switch: factor out switch_region_table_read") Signed-off-by: Haotian Zhang Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 74210fa072960a18bb0eead487585452af722e4f Author: Mikulas Patocka Date: Mon Aug 3 23:34:02 2026 +0200 dm-stats: fix a crash if allocation of per-cpu data fails commit cc87e26d9cce22061dc21e51e11afef29dbbc36a upstream. If "dm_kvzalloc(percpu_alloc_size, cpu_to_node(cpu))" fails, the code jumps to the "out" label and calls dm_stat_free. dm_stat_free does "for_each_possible_cpu(cpu) { dm_kvfree(s->stat_percpu[cpu][0].histogram, s->histogram_alloc_size);", which crashes with NULL pointer dereference if s->stat_percpu[cpu] is NULL. This commit fixes the bug by testing s->stat_percpu[cpu] for NULL before using it. Reported-by: Junzhe Yu Signed-off-by: Mikulas Patocka Fixes: fd2ed4d25270 ("dm: add statistics support") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c860cd3f40382cab932126c35d118cd06c70956c Author: Nathan Chancellor Date: Thu Aug 13 20:12:55 2026 -0700 arch_numa: avoid false positive fortify warning in setup_node_to_cpumask_map() commit f2b1cb39d5ccab090d8353788f186f7e7a1fffd4 upstream. When building ARCH=riscv using clang with CONFIG_FORTIFY_SOURCE and CONFIG_UBSAN_BOUNDS enabled, CONFIG_NR_CPUS > 64, and the default value of 2 for CONFIG_NODES_SHIFT, there is a compiletime warning from the fortify routines. In file included from mm/arch_numa.c:11: In file included from include/linux/acpi.h:14: In file included from include/linux/resource_ext.h:11: In file included from include/linux/slab.h:17: In file included from include/linux/gfp.h:7: In file included from include/linux/mmzone.h:8: In file included from include/linux/spinlock.h:60: In file included from include/linux/interrupt_rc.h:17: In file included from include/linux/smp.h:13: In file included from include/linux/cpumask.h:11: In file included from include/linux/bitmap.h:13: In file included from include/linux/string.h:383: include/linux/fortify-string.h:430:4: warning: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribue-warning] 430 | __write_overflow_field(p_size_field, size); | ^ include/linux/fortify-string.h:430:4: note: called by function 'fortify_memset_chk(unsigned long, unsigned long, unsigned long)' include/linux/bitmap.h:248:3: note: inlined by function 'setup_node_to_cpumask_map' 248 | memset(dst, 0, len); | ^ include/linux/fortify-string.h:462:25: note: expanded from macro 'memset' 462 | #define memset(p, c, s) __fortify_memset_chk(p, c, s, \ | ^ include/linux/fortify-string.h:453:2: note: expanded from macro '__fortify_memset_chk' 453 | fortify_memset_chk(__fortify_size, p_size, p_size_field), \ | ^ include/linux/fortify-string.h:430:4: note: use '-gline-directives-only' (implied by '-g1') or higher for more accurate inlining chain locations 430 | __write_overflow_field(p_size_field, size); | ^ 1 warning generated. In this configuration, MAX_NUMNODES is 4. clang unrolls the for loop in setup_node_to_cpumask_map() past this, which triggers the fortify check when accessing node_to_cpumask_map on the theoretical fifth loop iteration because it would be an out of bounds write. Make it clear to clang that nr_node_ids is bounded by MAX_NUMNODES due to the logic in setup_nr_node_ids() by early returning in setup_node_to_cpumask_map() should that condition be violated. Link: https://lore.kernel.org/20260813-arch_numa-avoid-fortify-warning-v2-1-093ad97a78df@kernel.org Signed-off-by: Nathan Chancellor Closes: https://github.com/ClangBuiltLinux/linux/issues/2174 Reviewed-by: Mike Rapoport (Microsoft) Cc: Kees Cook Cc: Bill Wendling Cc: Justin Stitt Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Signed-off-by: Andrew Morton Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit edf30d65e3ac52f886f7d87b1a7449742e79157d Author: Yehyeong Lee Date: Fri Sep 4 01:26:02 2026 +0900 net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry [ Upstream commit 8d3c1ab82c11d4fadebf817a825fd221b3e197ea ] smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() read the part of a v2 message that does not fit into the 44-byte union smc_llc_msg, and both bound themselves by the size of the buffer it landed in, not by what arrived. On a link with a shared v2 receive buffer a 44-byte DELETE_RKEY_V2 declaring 255 rkeys reaches rkey[9..254] in whatever an earlier message left in lgr->wr_rx_buf_v2, and passes each of them to smc_rtoken_delete(). One of those 255 matched a registered rtoken and deleted it. An ADD_LINK on such a link installs up to 255 rtokens from the same bytes. Copy the tail into the queue entry, so its length is the length of the message that arrived, and declare the rkeys that fit inline as a member of the union instead of reaching them through a cast. The same DELETE_RKEY_V2 now processes the 9 rkeys it carries. The copy is limited to the longest tail the two functions can read, so the peer does not pick the size of the entry. The bound the previous patch placed on links without a shared v2 receive buffer is no longer needed. Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1") Cc: stable@vger.kernel.org Suggested-by: D. Wythe Reviewed-by: Sidraya Jayagond Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260819023306.644849-4-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 44dc702be9a9e3ee6f83e72218caceb9ae617336 Author: Miguel Ojeda Date: Thu Sep 3 20:18:37 2026 +0200 rust: rust_is_available: warn for `bindgen` < 0.72.1 && libclang >= 22 [ Upstream commit dc01dfb37b34beeefcfe1c3055364d41a4070c7e ] Starting with LLVM 22, `clang_getTypeDeclaration()` may return a forward declaration instead of the type definition. This made `bindgen` generate opaque types [1][2], which in turn made us fail with e.g. error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param` --> rust/kernel/module_param.rs:78:46 | 78 | let container = unsafe { &*((*param).__bindgen_anon_1.arg.cast::>()) }; | ^^^^^^^^^^^^^^^^ unknown field | = note: available field is: `_address` This was fixed in `bindgen` 0.72.1 [3]. In order to clarify what is going on and avoid confusion [4][5], add a warning to `rust_is_available.sh` about it when the versions match, similar to past warnings like the one removed in: commit ae64324ad5c1 ("rust: rust_is_available: remove warning for `bindgen` < 0.69.5 && libclang >= 19.1") In addition, even if the versions match, check if the issue appears to not reproduce with the given binaries, to avoid a warning in such a case. Finally, include tests. [ Nathan, in parallel, updated the instructions of the LLVM+Rust kernel.org toolchains [6] so that `--version` is not passed to `cargo` for `bindgen`, and thus the latest `bindgen` is installed by default, which should help to avoid some of these situations. Thanks! - Miguel ] Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust-bindgen/issues/3264 [1] Link: https://github.com/Rust-for-Linux/linux/issues/353 [2] # "Missing fields in nested class with LLVM 22." Link: https://github.com/rust-lang/rust-bindgen/pull/3278 [3] Reported-by: Burak Emir Link: https://github.com/Rust-for-Linux/linux/issues/1247 [4] Link: https://lore.kernel.org/rust-for-linux/CABwQupNfMAJOGqRM9ke6tj4f53dCCsBDKU7Vp+zf8mwk7bqt8Q@mail.gmail.com/ [5] Link: https://mirrors.edge.kernel.org/pub/tools/llvm/rust/ [6] Tested-by: Burak Emir Link: https://patch.msgid.link/20260719120514.159914-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit b5fe67111e63a8a81ec31056c4475509076fd266 Author: Ralf Lici Date: Thu Sep 3 16:26:59 2026 +0300 ovpn: run deferred work on a module-owned workqueue commit e9714db8041763f59dde152c812b96b3de05c6d9 upstream. ovpn queues several work items whose callbacks execute module text. These works currently run on the global system workqueues, so module exit has no driver-owned drain point that guarantees the callbacks have fully returned before the module text can be freed. Object references protect the objects used by the callbacks, but they do not prove that a workqueue function has returned. In particular, a worker can drop the final reference that unblocks device teardown while it is still executing ovpn code. Add a module-owned workqueue and queue all ovpn work items on it. During module exit, unregister rtnl and netlink first, flush the workqueue so ordinary ovpn workers finish, run the final RCU barrier, and destroy the workqueue last. This keeps the workqueue available for cleanup work queued from RCU callbacks, while ensuring no ovpn work item can outlive the module text. The per-device delayed keepalive work remains explicitly disabled during netdev teardown (disable_delayed_work_sync in ndo_uninit), since flush_workqueue does not flush delayed work that is still only pending on its timer. Fixes: 3ecfd9349f40 ("ovpn: implement keepalive mechanism") Fixes: 11851cbd60ea ("ovpn: implement TCP transport") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli Signed-off-by: Alexander Martyniuk Signed-off-by: Sasha Levin commit 50f4a793c4ff24826efb0ac700989a5063cc53df Author: Vincent Donnefort Date: Thu Aug 13 14:11:46 2026 +0100 ring-buffer: Fix subbuf resize race with ring buffer readers [ Upstream commit 8a5f63637890f03177146efddaba5ec7a1b4d61f ] trace_buffer subbuf_size is read lockless in ring_buffer_read_page() and ring_buffer_read_start(), while it can simultaneously be resized with ring_buffer_subbuf_order_set(). Instead of trace_buffer::subbuf_size, use bpage::order in ring_buffer_read_start() and ring_buffer_read_page(). In ring_buffer_read_start(), even with resize_disabled, there is still a possibility of a race with a buffer modification. Hold the trace_buffer mutex to synchronise with any pending ring buffer order modification. trace_buffer::subbuf_size is now actually useless, remove it. Also, create accessors rb_subbuf_capacity() and rb_page_capacity() which return the actual size available for storing events, while rb_subbuf_size() returns the actual subbuf page-size. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260813131152.3589632-5-vdonnefort@google.com Fixes: f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260805153225.2096152-1-vdonnefort%40google.com # patch 1 Acked-by: Masami Hiramatsu (Google) Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 22fe01a2e2f7c20be7d29de061ee5256fb39e1f4 Author: Zhang Heng Date: Mon Aug 17 17:47:08 2026 +0800 ALSA: hda/realtek: Fix Lenovo Yoga Slim 7 14AKP10 quirk ordering commit 75dc2eda659f6be4a370734f11baf25df8a9fd80 upstream. The Yoga Slim 7 14AKP10 has a PCI SSID of 17aa:38b4 but a codec SSID of 17aa:391a. The current quirk table contains a PCI quirk for 17aa:38b4 (for the Legion Slim 7 16IRH8) which matches first, so the codec-specific quirk for 17aa:391a is never applied. This results in the wrong fixup being used (CS35L41_I2C_2 instead of the correct bass speaker fixup), leaving the internal speakers misconfigured or silent. Remove the 17aa:391a entry from its PCI-SSID-sorted position and add it as an HDA_CODEC_QUIRK directly before the 17aa:38b4 entry, because it must match on the codec subsystem ID rather than the PCI SSID and it has to win over the colliding PCI quirk for the Legion Slim 7 16IRH8. A comment is added to explain the out-of-order placement, following the same style already used for the 17aa:38bb and 17aa:38f9 codec-SSID overrides. With this change, the correct ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN is applied, restoring speaker output and auto-mute functionality. The original quirk added in commit e6c888202297 ("ALSA: hda/realtek: Add quirk for Lenovo Yoga Slim 7 14AKP10") matched on the PCI SSID 17aa:391a, but this model actually exposes PCI SSID 17aa:38b4 (shared with the Legion Slim 7 16IRH8), so that quirk never matched and the bass speaker remained silent. Fix it by matching on the codec SSID and placing the entry before the colliding 17aa:38b4 PCI quirk. Fixes: e6c888202297 ("ALSA: hda/realtek: Add quirk for Lenovo Yoga Slim 7 14AKP10") Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=221298 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260817094708.222154-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 37c3210c491ac56b4801201edded388ebcdf3a3f Author: Denis Batishchev Date: Mon Aug 10 17:14:41 2026 +0200 ALSA: hda/realtek: Enable micmute LED on HP EliteBook 6 G1a p/n: AD3Q9ET#UUG commit e7da28b820d12927de30abf554c727a319f80359 upstream. The HP EliteBook 6 G1a (SSID 103c:8e0d) uses a Realtek ALC236 codec. Without a quirk no fixup is selected and the mic-mute LED stays off. It needs the same ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk as the already-supported 14" variant (SSID 103c:8dfb), so add it. Signed-off-by: Denis Batishchev Cc: Link: https://patch.msgid.link/20260810151440.2306217-2-ii343hbka@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8acb66d0513dec1ea8dac960bcde308be9e259d4 Author: Eckhart Mohr Date: Fri Aug 21 16:44:34 2026 +0200 ALSA: hda/realtek: Add quirk for TongFang XxAF5xxx commit e72d5659a2606056a0c34af212b46a3275a55bbf upstream. Fix microphone detection on built in headphone jack for some devices Signed-off-by: Eckhart Mohr Cc: stable@vger.kernel.org Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20260821144437.27233-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 40ee4224e2fe24c05b92e4d37476adb6e83f10e9 Author: Takashi Iwai Date: Thu Aug 6 17:32:21 2026 +0200 ALSA: virmidi: Check card index validity at probe commit b65d5182ecd6b7a24a83d980a0d06e809ef876c5 upstream. virmidi driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260806153227.1460166-5-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 7555e83d7738e65dc83921e3c85bbdc081f08f2f Author: Takashi Iwai Date: Thu Aug 6 17:32:20 2026 +0200 ALSA: serial-u16550: Check card index validity at probe commit e0fb960b227fcdebe22e4f26c9486d60943c0424 upstream. serial-u16550 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260806153227.1460166-4-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit d7ef7890e3e35b4ba09e76fc6b72047a1599a5e8 Author: Takashi Iwai Date: Thu Aug 6 17:32:23 2026 +0200 ALSA: portman2x4: Check card index validity at probe commit 3690ef20469d5959378260e2752f2314a2572913 upstream. Although portman2x4 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as "none" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260806153227.1460166-7-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 7ef9ad82d95dd3c74570d80a689a0570fbc7539e Author: Runyu Xiao Date: Tue Aug 18 22:47:17 2026 +0800 ALSA: pcxhr: initialize mutexes before requesting threaded IRQ commit 6c97817e20598e5473094e0e38d1f51f1cf4dfff upstream. pcxhr_probe() requests pcxhr_threaded_irq() before initializing mgr->lock, even though the threaded handler takes that mutex. Initialize the manager locks before request_threaded_irq() so an early interrupt cannot run against uninitialized mutex state during probe. Fixes: 9bef72bdb26e ("ALSA: pcxhr: Use nonatomic PCM ops") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260818144717.2269918-1-runyu.xiao@seu.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a4e774eeb61aec64da5b03d3becffde26f7fe4de Author: Takashi Iwai Date: Thu Aug 6 17:32:22 2026 +0200 ALSA: mts64: Check card index validity at probe commit d18a260720f86a5f8b5fcfefc4ba2e9dd01c10f8 upstream. Although mts64 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as "none" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260806153227.1460166-6-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit cc4215cc2a4b2a9cf8b1952bbe8d5bf925acb3ea Author: Takashi Iwai Date: Thu Aug 6 17:32:19 2026 +0200 ALSA: mpu401: Check card index validity at probe commit f7dcecb92ed192ff5fcf842918fb1aaea84b5bdd upstream. mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260806153227.1460166-3-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 13d61a920435de6cef8ee9bc4e097b6c98e9832e Author: Xu Rao Date: Thu Aug 13 14:55:24 2026 +0800 ALSA: hda/ext: preserve PPLCCTL bits when clearing reset commit 36aa66de481d29edd63cbad9b5c4dc18c340fdf6 upstream. snd_hdac_ext_stream_reset() polls PPLCCTL for STRST by masking the register value with AZX_PPLCCTL_STRST: val = readl(...) & AZX_PPLCCTL_STRST; The same masked value is then used when clearing STRST. Since val contains no bits other than STRST, clearing STRST from it always produces zero. The subsequent writel() therefore writes zero to the entire PPLCCTL register instead of clearing only the reset bit. PPLCCTL contains other stream control fields, including the stream tag in AZX_PPLCCTL_STRM_MASK. Those fields must not be modified as a side effect of clearing stream reset. Use snd_hdac_updatel() to clear STRST, matching the existing set-reset path and preserving all unrelated PPLCCTL bits. Fixes: df203a4e46f4 ("ALSA: hdac_ext: add extended stream capabilities") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Link: https://patch.msgid.link/43BB7930B0F07C09+20260813065524.1955696-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7df3194bdb7479cad9199889655a566a2c0c1d1b Author: Baul Lee Date: Wed Aug 5 10:34:28 2026 +0900 ALSA: bcd2000: clear the URB pointers on disconnect commit 459d3a64766f5ca2f1886daeaf24582831a5f5ab upstream. bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind: usb_kill_urb(bcd2k->midi_out_urb); usb_kill_urb(bcd2k->midi_in_urb); usb_free_urb(bcd2k->midi_out_urb); usb_free_urb(bcd2k->midi_in_urb); The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core: bcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE; ... ret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC); usb_kill_urb() does not stop a later submission either, so a submit that races the disconnect can requeue the URB after it has been reaped. midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits it from the completion handler. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000] Write of size 4 at addr ffff00001827d388 by task bpoc/168 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 Freed by task 168: usb_free_urb bcd2000_disconnect [snd_bcd2000] BUG: KASAN: slab-use-after-free in usb_submit_urb Read of size 8 at addr ffff00001827d3b8 by task bpoc/168 Clear both pointers after freeing and test them on the paths that can still run. Poison the URBs before freeing them: usb_poison_urb() waits for a running completion handler and rejects any later submission, so after it returns the input path is quiesced and only the rawmidi trigger path can still reach bcd2000_midi_send(). No unpoison is needed; the URBs are freed on the next line. Discovered by XBOW, triaged by Baul Lee Fixes: b47a22290d58 ("ALSA: MIDI driver for Behringer BCD2000 USB device") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260805013428.38204-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7b3f9855849363e402bf2141df2b428581cbf31b Author: Takashi Iwai Date: Thu Aug 6 17:32:18 2026 +0200 ALSA: aloop: Check card index validity at probe commit 819b106a9fd2ef3fd8abf898b9a8e4524eca8f48 upstream. aloop driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260806153227.1460166-2-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 2a6f6fba3bd31d2e8c957fefa29156e35e5e75d5 Author: Baul Lee Date: Wed Aug 5 10:34:23 2026 +0900 ALSA: 6fire: bound the MIDI event length from the device commit a478893b59e36cfe7d77a76b352f2db55502e879 upstream. usb6fire_comm_receiver_handler() forwards a MIDI event using a length byte the device supplies, with no bound and no check that the transfer delivered that many bytes: if (!urb->status) { if (rt->receiver_buffer[0] == 0x10) /* midi in event */ if (midi_rt) midi_rt->in_received(midi_rt, rt->receiver_buffer + 2, rt->receiver_buffer[1]); } receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the device chooses, so a device that answers with 0x10 and a length of 0xFF makes snd_rawmidi_receive() read 255 bytes starting two bytes into a 64-byte object. The bytes past the buffer are handed to userspace through the rawmidi read path. urb->actual_length is not consulted either, so a short transfer leaves both the type byte and the length byte at their previous values and the handler acts on stale data. The receiver URB is submitted from usb6fire_comm_init() at probe, so the read happens on plug with no user action; forwarding to userspace also needs a MIDI input substream open, since usb6fire_midi_in_received() only calls snd_rawmidi_receive() when rt->in is set. KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device: BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive Read of size 255 at addr ffff000009f64682 by task bash/183 __asan_memcpy snd_rawmidi_receive usb6fire_midi_in_received [snd_usb_6fire] usb6fire_comm_receiver_handler [snd_usb_6fire] Allocated by task 11: usb6fire_comm_init [snd_usb_6fire] usb6fire_chip_probe [snd_usb_6fire] The buggy address is located 2 bytes inside of allocated 64-byte region [ffff000009f64680, ffff000009f646c0) Reject the event when the length exceeds the bytes that follow the header, and require the transfer to have delivered the header plus that many bytes. The receiver URB is submitted with a 64-byte transfer_buffer_length, so a genuine device cannot deliver an event longer than those 62 bytes and nothing valid is dropped. Discovered by XBOW, triaged by Baul Lee Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260805013423.38175-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 94ca4f040ba489db2d4b66e9d1ee91b4f9a00534 Author: Abdun Nihaal Date: Mon Jul 20 17:08:32 2026 +0530 mfd: sm501: Fix potential memory leaks during remove commit 83feedd9d83c0c5199f98c72df0a6196b4aefb4d upstream. The memory allocated for struct sm501_devdata in sm501_pci_probe() and sm501_plat_probe() is not freed by the corresponding remove functions sm501_pci_remove() and sm501_plat_remove(). Fix that by adding a call to kfree(). Fixes: b6d6454fdb66 ("[PATCH] mfd: SM501 core driver") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20260720113836.73133-1-nihaal@cse.iitm.ac.in Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 5e7fe9c6c8c314d76d72734a0b19f9df6c3beb29 Author: Thomas Richard Date: Mon Jul 13 16:43:43 2026 +0200 mfd: cgbc: Fix teardown ordering in cgbc_remove() commit 2970c2db8ab3d97ea6250c14ca49b1e1731115ab upstream. Release Board Controller session once children are removed by the core. Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/cover.1783507945.git.u.kleine-koenig%40baylibre.com?part=19 Fixes: 6f1067cfbee7 ("mfd: Add Congatec Board Controller driver") Signed-off-by: Thomas Richard Link: https://patch.msgid.link/20260713-cgbc-core-fix-cgbc-remove-v1-1-79274ad62b3a@bootlin.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit efe0ed4c0f4e8243db7b1783ee0e4868948bee47 Author: Can Peng Date: Sat Jul 18 11:29:37 2026 +0800 hwrng: stm32 - Fix runtime PM cleanup on registration failure commit 1163a476a568f6c0f852d469c8e4c5a5f805adac upstream. stm32_rng_probe() enables autosuspend and runtime PM before registering the hwrng. If devm_hwrng_register() fails, probe returns with runtime PM left enabled and autosuspend still selected. The remove callback also only disables runtime PM and does not undo pm_runtime_use_autosuspend(). Use devm_pm_runtime_enable() so runtime PM is unwound automatically on probe failure and driver detach. Since the managed cleanup also disables runtime PM,drop the remove callback. Fixes: c6a97c42e399 ("hwrng: stm32 - add support for STM32 HW RNG") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Reviewed-by: Linus Walleij Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit cfa186a0857a0f831dfca67b16bbc40ecfdf3280 Author: Zhiling Zou Date: Sat Aug 22 16:49:27 2026 +0800 seg6: reset IP6CB after IPv6 decapsulation commit f967455fb2a5a2079b9eb5823e9ccf359174bf9f upstream. decap_and_validate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags. End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet. The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports: BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu ip6_protocol_deliver_rcu+0x1118/0x1450 ip6_input_finish+0x11b/0x240 seg6_local_input_core+0xed/0x2e0 lwtunnel_input+0x1e9/0x4e0 ipv6_rthdr_rcv+0x525f/0x6c50 ip6_protocol_deliver_rcu+0xcb7/0x1450 Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field. Use IP6CB(skb)->iif rather than skb->skb_iif because VRF processing can replace skb_iif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKB_L3SLAVE for the same reason. Fixes: d7a669dd2f8b ("ipv6: sr: add helper functions for seg6local") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Reviewed-by: Andrea Mayer Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 288f9970670841044ab030104fa6b6ed159949d0 Author: Norbert Szetei Date: Sat Aug 22 11:15:08 2026 +0200 net: skbuff: don't touch shared zerocopy state in skb_tx_error() commit f66bdb1cc0fcd227a062378f8be0b5873aa5600a upstream. skb_tx_error() completes the zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone shares, while the caller only owns the reference it is about to drop. Through a clone it tells the producer its pages are free and drops SKBFL_SHARED_FRAG for an skb that is still in flight. Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC: clone_execute() sends a skb_clone() into ovs_dp_process_packet() while do_execute_actions() keeps forwarding the original, and skb_clone() does not privatise the frags here -- skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN. A flow miss on the clone then strips the marker from the packet still being forwarded, and a later local ESP delivery decrypts in place over frags it does not own privately. Skip it for a cloned skb. Nothing is lost: skb_release_data() clears the zerocopy state once the last reference to the shared data goes. Fixes: 25121173f7b1 ("skb: api to report errors for zero copy skbs") Cc: stable@vger.kernel.org Suggested-by: Ilya Maximets Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Tested-by: Jongmin Jang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/CFAB292A-674B-4C14-BB2C-BB8830AD5659@doyensec.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 34ab62c959f5f7296bd3912b75baf0bafbd5f948 Author: Breno Leitao Date: Tue Aug 25 03:50:10 2026 -0700 net: fix spurious TX timeout after dev_activate() commit 82aeed2400786bd3f79d88cb8b8f42e6127e5923 upstream. While debugging another issue today, I found out that my TX queue is reported as stopped for 4294907392 ms (49.7 days), on a machine that had been up for four minutes. bnxt_en 0002:01:00.0 eth0: NETDEV WATCHDOG: CPU: 28: transmit queue 23 timed out 4294907392 ms 4294907392 is not an elapsed time. It is the value of jiffies at that moment: INITIAL_JIFFIES is 4294667296, which leaves jiffies 59 seconds short of wrapping. dev_activate() runs transition_one_qdisc() over every TX queue, which resets trans_start to 0, and then stamps only queue 0 through netif_trans_update(). Stamp jiffies instead. A queue stopped across dev_activate() now gets a full watchdog_timeo of grace, and is still reported if it is stopped that long. Fixes: 9b36627acecd ("net: remove dev->trans_start") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Reviewed-by: Nicolai Buchwitz Reviewed-by: Jason Xing Link: https://patch.msgid.link/20260825-trans_start-v2-1-286b4d6d70cb@debian.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit af0ee8f04bea22cdb331fa3509e17f81b48938ad Author: Zhiling Zou Date: Thu Aug 13 00:22:35 2026 +0800 net: cap advertised IP tunnel headroom commit 6b222adeb9340306e2ff97127c76117abb9b3df8 upstream. IP tunnel devices derive their advertised needed_headroom from lower output devices. A stack of user-created devices can make the derived value larger than the 16-bit skb header offsets can represent. Once IP output reserves it, skb head expansion can wrap those offsets. The runtime transmit path already caps a growing needed_headroom at 512. Apply the same cap when tunnel configuration publishes needed_headroom derived from a lower output device. Capping the advertised value is safe: IP tunnel transmit still expands the skb when a packet needs more headroom. A nonsensical stacked configuration can therefore incur an extra reallocation, but it cannot publish an unbounded reservation to upper layers. Fixes: 1a37e412a022 ("net: Use 16bits for *_headers fields of struct skbuff") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/ba04a1fd6bfae2377607fad5d8f80f7eb80fd4c4.1786542637.git.zhilinz@nebusec.ai Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 5bd8b764a610b6b6bc0c4d3d01652747f6e0b5c3 Author: Bryam Vargas Date: Sat Aug 8 02:21:23 2026 -0500 net/smc: unregister the connection before draining the rx tasklet commit 36cdf5d48ca191dcd71c28cadbe0981b1d25318d upstream. smc_conn_free() calls smc_ism_unset_conn() only while the link group is still on its device list, and never sets conn->killed. smc_lgr_terminate_sched() unlinks the group immediately and defers killing its connections to a work item, so a connection freed in that window keeps its smcd->conn[] slot with both gates in smcd_handle_irq() open, and the device can re-arm the receive tasklet after tasklet_kill() has returned. On the DMB-nocopy path the ghost send buffer is freed right after that drain, so the re-armed tasklet dereferences it. Unregister unconditionally and drain before the detach at both teardown sites, mirroring rmb_desc, which smc_buf_unuse() releases after the drain. Clear conn->sndbuf_desc before freeing it as well, so a reader that samples the pointer cannot get one that is already freed. Fixes: ae2be35cbed2 ("net/smc: {at|de}tach sndbuf to peer DMB if supported") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Sidraya Jayagond Reviewed-by: Tony Lu Link: https://patch.msgid.link/20260808-b4-disp-22f119e6-v2-1-61647601a6f3@proton.me Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 313f79149eb337411c64e2c247234b62ef9a3cb9 Author: Hidayath Khan Date: Thu Aug 20 09:46:41 2026 +0200 net/smc: stop killed, freed and out_of_sync sharing a byte commit db51a8658c11a82432b64999519a269c3aabb447 upstream. The three connection state flags are single-bit bitfields, so they occupy one byte of struct smc_connection and every store to one is a read-modify-write of the other two: u8 killed : 1; u8 freed : 1; u8 out_of_sync : 1; They are not written under a common lock. smc_cdc_msg_validate() sets out_of_sync from the receive tasklet, while smc_conn_kill() sets killed from process context under lock_sock(), and the receive path does not defer to the backlog when the socket is owned -- smc_cdc_msg_recv() takes only bh_lock_sock(). Give each flag its own byte so a store no longer touches its neighbours. All readers test them as booleans and are unchanged. struct smc_connection grows by two bytes. Fixes: b286a0651e44 ("net/smc: handle incoming CDC validation message") Cc: stable@vger.kernel.org Reviewed-by: Mahanta Jambigi Signed-off-by: Hidayath Khan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260820074642.966856-2-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c52a998a223e7e84333306996edec096178d1e95 Author: Yehyeong Lee Date: Wed Aug 19 11:33:04 2026 +0900 net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link() commit a42a459ef0e54cb0c4b3e43e21cb0e658e664f64 upstream. smc_llc_srv_add_link() keeps add_llc pointing into the queue entry: add_llc = &qentry->msg.add_link; smc_llc.c:1482 ... smc_llc_save_add_link_info(link_new, add_llc); smc_llc.c:1494 smc_llc_flow_qentry_del(&lgr->llc_flow_lcl); smc_llc.c:1495 ... u8 *llc_msg = smc_link_shared_v2_rxbuf(link) ? (u8 *)lgr->wr_rx_buf_v2 : (u8 *)add_llc; smc_llc.c:1504 smc_llc_save_add_link_rkeys(link, link_new, llc_msg); smc_llc.c:1506 smc_llc_flow_qentry_del() kfree()s the entry, so on a link without a shared v2 receive buffer the pointer handed to smc_llc_save_add_link_rkeys() is already freed. Before the Fixes: commit that branch always used lgr->wr_rx_buf_v2 and add_llc was not used after the free. Reproduced on an unpatched tree over rxe, with KASAN, kasan_multi_shot and a link forced to max_recv_sge == 1: the entry is freed and read by the same call, and the freeing frame is smc_llc_srv_add_link() itself. [ 2.523161] BUG: KASAN: slab-use-after-free in smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523499] Read of size 2 at addr ffff8880052194de by task kworker/0:1/11 [ 2.523789] [ 2.523862] CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 7.2.0-rc5-p0-g2c9dd296545d #35 PREEMPT(lazy) [ 2.523865] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.523866] Workqueue: smc_hs_wq smc_listen_work [ 2.523869] Call Trace: [ 2.523870] [ 2.523871] dump_stack_lvl+0x53/0x70 [ 2.523872] print_report+0xd0/0x630 [ 2.523874] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 2.523876] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523878] kasan_report+0xce/0x100 [ 2.523879] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523881] smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523883] ? smcr_buf_reg_lgr+0x2a4/0x660 [ 2.523885] smc_llc_srv_add_link+0xaa2/0x1e50 [ 2.523888] ? _printk+0xba/0xf0 [ 2.523897] ? __pfx_smc_llc_srv_add_link+0x10/0x10 [ 2.523899] ? down_write+0xb0/0x130 [ 2.523903] ? __pfx_down_write+0x10/0x10 [ 2.523905] smc_listen_work+0x489e/0x4d00 [ 2.523907] ? kmem_cache_free+0x1c6/0x3a0 [ 2.523911] ? __pfx_smc_listen_work+0x10/0x10 [ 2.523913] ? release_sock+0x148/0x1d0 [ 2.523915] ? smc_tcp_listen_work+0xb4f/0xfc0 [ 2.523917] ? _raw_spin_lock_irq+0x80/0xe0 [ 2.523918] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 2.523920] process_one_work+0x633/0x1030 [ 2.523922] ? assign_work+0x11d/0x370 [ 2.523924] worker_thread+0x45b/0xd10 [ 2.523926] ? __pfx_worker_thread+0x10/0x10 [ 2.523928] ? __pfx_worker_thread+0x10/0x10 [ 2.523929] kthread+0x2c6/0x3b0 [ 2.523931] ? recalc_sigpending+0x15c/0x1e0 [ 2.523934] ? __pfx_kthread+0x10/0x10 [ 2.523935] ret_from_fork+0x36e/0x5a0 [ 2.523937] ? __pfx_ret_from_fork+0x10/0x10 [ 2.523938] ? __switch_to+0x572/0xdd0 [ 2.523943] ? __pfx_kthread+0x10/0x10 [ 2.523944] ret_from_fork_asm+0x1a/0x30 [ 2.523947] [ 2.523948] [ 2.531253] Allocated by task 48: [ 2.531399] kasan_save_stack+0x33/0x60 [ 2.531570] kasan_save_track+0x14/0x30 [ 2.531737] __kasan_kmalloc+0x8f/0xa0 [ 2.531905] __kmalloc_cache_noprof+0x158/0x370 [ 2.532100] smc_llc_enqueue+0x72/0x560 [ 2.532268] smc_wr_rx_tasklet_fn+0x474/0xa80 [ 2.532491] tasklet_action_common+0x20f/0x8a0 [ 2.532714] handle_softirqs+0x18e/0x590 [ 2.532886] do_softirq+0x3b/0x60 [ 2.533036] __local_bh_enable_ip+0x61/0x70 [ 2.533221] __alloc_skb+0x732/0x890 [ 2.533384] rxe_init_packet+0x16b/0x4f0 [ 2.533567] prepare_ack_packet+0xb8/0x830 [ 2.533760] rxe_receiver+0x495/0x96e0 [ 2.533933] do_work+0x144/0x470 [ 2.534078] process_one_work+0x633/0x1030 [ 2.534257] worker_thread+0x45b/0xd10 [ 2.534424] kthread+0x2c6/0x3b0 [ 2.534569] ret_from_fork+0x36e/0x5a0 [ 2.534737] ret_from_fork_asm+0x1a/0x30 [ 2.534907] [ 2.534980] Freed by task 11: [ 2.535112] kasan_save_stack+0x33/0x60 [ 2.535279] kasan_save_track+0x14/0x30 [ 2.535444] kasan_save_free_info+0x3b/0x60 [ 2.535625] __kasan_slab_free+0x43/0x70 [ 2.535798] kfree+0x121/0x380 [ 2.535935] smc_llc_srv_add_link+0x9a8/0x1e50 [ 2.536128] smc_listen_work+0x489e/0x4d00 [ 2.536305] process_one_work+0x633/0x1030 [ 2.536482] worker_thread+0x45b/0xd10 [ 2.536652] kthread+0x2c6/0x3b0 [ 2.536794] ret_from_fork+0x36e/0x5a0 [ 2.536958] ret_from_fork_asm+0x1a/0x30 [ 2.537133] [ 2.537205] The buggy address belongs to the object at ffff888005219480 [ 2.537205] which belongs to the cache kmalloc-96 of size 96 [ 2.537719] The buggy address is located 94 bytes inside of [ 2.537719] freed 96-byte region [ffff888005219480, ffff8880052194e0) [ 2.538216] [ 2.538289] The buggy address belongs to the physical page: [ 2.538524] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5219 [ 2.538857] flags: 0x100000000000000(node=0|zone=1) [ 2.539066] page_type: f5(slab) [ 2.539210] raw: 0100000000000000 ffff888001041280 dead000000000122 0000000000000000 [ 2.539534] raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000 [ 2.539863] page dumped because: kasan: bad access detected [ 2.540098] [ 2.540170] Memory state around the buggy address: [ 2.540379] ffff888005219380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2.540684] ffff888005219400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2.540988] >ffff888005219480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 2.541291] ^ [ 2.541548] ffff888005219500: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.541857] ffff888005219580: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc The offset is past the 72-byte queue entry because the out-of-bounds read fixed by the next patch is on the same line; what this patch removes is the free at smc_llc_srv_add_link+0x9a8 happening before the read at +0xaa2. Detach the entry instead of freeing it there, and free it at the single exit label. The reject path has to detach as well, otherwise it would be freed twice. This changes only the lifetime of the entry. The same read still runs past its end until the next two patches bound it, so a backport wants all three. Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1") Cc: stable@vger.kernel.org Reviewed-by: Sidraya Jayagond Signed-off-by: Yehyeong Lee Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260819023306.644849-2-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0761e49aa78c2f1362511054c6e9670653858837 Author: Hidayath Khan Date: Thu Aug 20 09:46:42 2026 +0200 net/smc: fix use-after-free in smc_rx_pipe_buf_release() commit c924884743e948e25625b7fbf3ee2a9325a204a7 upstream. smc_rx_splice() hands RMB pages to a pipe and takes a socket reference per entry so the smc_sock stays alive until the reader finishes. The connection does not: a concurrent close runs smc_conn_free(), which releases the receive buffer back to the link group pool. smc_rx_pipe_buf_release() tests sk_state before taking the socket lock. The state can change between the test and the lock, and smc_rx_update_cons() then dereferences conn->rmb_desc and walks conn->lgr, which smc_conn_free() has already released. On the is_reg_err path smcr_buf_unuse() frees the descriptor outright, so this is a use-after-free. Take the socket lock first and test conn->freed instead. smc_conn_free() sets that flag before releasing anything, and every caller holds the socket lock. The two paths exclude each other: either the pipe release runs first with everything valid, or it sees the flag and skips the update. Fixes: 9014db202cb7 ("smc: add support for splice()") Cc: stable@vger.kernel.org Reviewed-by: Mahanta Jambigi Signed-off-by: Hidayath Khan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260820074642.966856-3-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d89dc1bd8845c669a700eee58c64ebd3cc1b6d2d Author: Hidayath Khan Date: Thu Aug 20 16:47:29 2026 +0200 net/smc: fix socket refcount leak in smc_switch_conns() commit 719296c4aa8213d4ac8002e77d5956d436bc98d0 upstream. smc_switch_conns() takes a reference on the SMC socket before dropping lgr->conns_lock, so the connection stays alive while the CDC slot is fetched: sock_hold(&smc->sk); read_unlock_bh(&lgr->conns_lock); /* pre-fetch buffer outside of send_lock, might sleep */ rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend); if (rc) goto err_out; The err_out label only drops the wr_tx link reference, so this early exit returns without the matching sock_put(). The second error exit is not affected, because sock_put() has already run by then. A leaked sk_refcnt means the smc_sock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down. smc_cdc_get_free_slot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smc_switch_conns() run in the first place. Restructure so there is a single sock_put() covering both outcomes, instead of adding a second one to the error path. Fixes: 95f7f3e7dc6b ("net/smc: improved fix wait on already cleared link") Cc: stable@vger.kernel.org Reviewed-by: Mahanta Jambigi Reviewed-by: Breno Leitao Signed-off-by: Hidayath Khan Link: https://patch.msgid.link/20260820144729.1019399-1-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f950e1b1f0aad334f9a9ee552c4dd5b794ebdd45 Author: Bryam Vargas Date: Sat Aug 8 02:21:24 2026 -0500 net/smc: do not dereference an unset send buffer on the SMC-D teardown path commit b395dd319cea422239cb45b998fb38d7e373af87 upstream. smc_close_stream_wait() calls smc_tx_prepared_sends() from inside its sk_wait_event() condition, and sk_wait_event() evaluates that condition once with the socket lock released. smcd_buf_detach() clears conn->sndbuf_desc from smc_conn_kill() under lock_sock(), so a link group terminating while a socket waits there leaves the helper dereferencing NULL, faulting out of close(). SIOCOUTQ reads the field by hand, and smc_close_cancel_work() drops the lock across two cancel_*_sync() calls. Sample the pointer once in the helper, report nothing prepared while it is unset, and bound the ioctl the same way. The receive tasklet dereferences the field directly in smc_cdc_msg_recv_action(), not through this helper; 1/2 is what keeps it from running that late. Fixes: ae2be35cbed2 ("net/smc: {at|de}tach sndbuf to peer DMB if supported") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Sidraya Jayagond Reviewed-by: Tony Lu Link: https://patch.msgid.link/20260808-b4-disp-22f119e6-v2-2-61647601a6f3@proton.me Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 486c699a8cde82c1d9b4f443eeab4ddf86358cb0 Author: Yehyeong Lee Date: Wed Aug 19 11:33:05 2026 +0900 net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages commit 2d1e7c5aaa3326e95e2058457f172ca99a9a4577 upstream. On a link whose device has max_recv_sge == 1 there is no shared v2 receive buffer, and smc_llc_save_add_link_rkeys() takes the v2 extension from 44 bytes past the start of the queue entry's inline message: ext = (struct smc_llc_msg_add_link_v2_ext *)(llc_msg + SMC_WR_TX_SIZE); The entry is a 72-byte allocation and the extension starts at offset 68, so ext->num_rkeys at offset 94 is already past it. This happens on every SMC-Rv2 link addition, whatever the peer sends: [ 2.490065] BUG: KASAN: slab-out-of-bounds in smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490431] Read of size 2 at addr ffff8880056406de by task smctest/106 [ 2.490709] [ 2.490792] CPU: 0 UID: 0 PID: 106 Comm: smctest Not tainted 7.2.0-rc5-p1-g77a5d9d9c99f #32 PREEMPT(lazy) [ 2.490795] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.490798] Call Trace: [ 2.490803] [ 2.490805] dump_stack_lvl+0x53/0x70 [ 2.490810] print_report+0xd0/0x630 [ 2.490828] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 2.490832] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490834] kasan_report+0xce/0x100 [ 2.490836] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490837] smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490839] ? smcr_buf_map_lgr+0x1bf/0x2b0 [ 2.490844] smc_llc_cli_add_link+0xca7/0x1e80 [ 2.490848] ? smc_llc_wait+0x355/0x810 [ 2.490850] ? __pfx_smc_llc_wait+0x10/0x10 [ 2.490851] ? __pfx_smc_llc_cli_add_link+0x10/0x10 [ 2.490853] ? __pfx_autoremove_wake_function+0x10/0x10 [ 2.490863] __smc_connect+0x3f5c/0x4980 [ 2.490873] ? __pfx_kernel_connect+0x10/0x10 [ 2.490888] ? __pfx___smc_connect+0x10/0x10 [ 2.490891] ? release_sock+0x148/0x1d0 [ 2.490894] smc_connect+0x42c/0x580 [ 2.490896] __sys_connect+0xfc/0x130 [ 2.490898] ? __pfx___sys_connect+0x10/0x10 [ 2.490900] ? handle_mm_fault+0x1a1/0x430 [ 2.490908] __x64_sys_connect+0x6d/0xb0 [ 2.490909] ? fpregs_assert_state_consistent+0x56/0xe0 [ 2.490917] do_syscall_64+0xf9/0x540 [ 2.490921] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2.490924] RIP: 0033:0x421bb4 [ 2.490927] Code: ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d ad 34 09 00 00 74 13 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 10 89 55 [ 2.490929] RSP: 002b:00007ffd473b01a8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a [ 2.490935] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000421bb4 [ 2.490936] RDX: 0000000000000010 RSI: 00007ffd473b01d0 RDI: 0000000000000003 [ 2.490937] RBP: 0000000000003930 R08: 0000000000000004 R09: 0000000000000000 [ 2.490938] R10: 00007ffd473b0f98 R11: 0000000000000202 R12: 0000000000000006 [ 2.490939] R13: 00007ffd473b0f87 R14: 0000000000000003 R15: 00007ffd473b0f90 [ 2.490940] [ 2.490941] [ 2.499545] Allocated by task 44: [ 2.499693] kasan_save_stack+0x33/0x60 [ 2.499860] kasan_save_track+0x14/0x30 [ 2.500026] __kasan_kmalloc+0x8f/0xa0 [ 2.500190] __kmalloc_cache_noprof+0x158/0x370 [ 2.500393] smc_llc_enqueue+0x72/0x560 [ 2.500559] smc_wr_rx_tasklet_fn+0x474/0xa80 [ 2.500747] tasklet_action_common+0x20f/0x8a0 [ 2.500945] handle_softirqs+0x18e/0x590 [ 2.501115] do_softirq+0x3b/0x60 [ 2.501266] __local_bh_enable_ip+0x61/0x70 [ 2.501446] __alloc_skb+0x732/0x890 [ 2.501604] rxe_init_packet+0x16b/0x4f0 [ 2.501783] prepare_ack_packet+0xb8/0x830 [ 2.501962] rxe_receiver+0x495/0x96e0 [ 2.502125] do_work+0x144/0x470 [ 2.502269] process_one_work+0x633/0x1030 [ 2.502450] worker_thread+0x45b/0xd10 [ 2.502617] kthread+0x2c6/0x3b0 [ 2.502762] ret_from_fork+0x36e/0x5a0 [ 2.502925] ret_from_fork_asm+0x1a/0x30 [ 2.503103] [ 2.503177] The buggy address belongs to the object at ffff888005640680 [ 2.503177] which belongs to the cache kmalloc-96 of size 96 [ 2.503692] The buggy address is located 22 bytes to the right of [ 2.503692] allocated 72-byte region [ffff888005640680, ffff8880056406c8) [ 2.504227] [ 2.504300] The buggy address belongs to the physical page: [ 2.504535] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5640 [ 2.504865] flags: 0x100000000000000(node=0|zone=1) [ 2.505076] page_type: f5(slab) [ 2.505221] raw: 0100000000000000 ffff888001041280 dead000000000122 0000000000000000 [ 2.505544] raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000 [ 2.505867] page dumped because: kasan: bad access detected [ 2.506102] [ 2.506176] Memory state around the buggy address: [ 2.506380] ffff888005640580: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.506683] ffff888005640600: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.506987] >ffff888005640680: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.507291] ^ [ 2.507548] ffff888005640700: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.507850] ffff888005640780: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc Whatever that read finds then bounds the ext->rt[] loop, so a peer that declares 255 rkeys reads much further. smc_llc_rmt_delete_rkey() has the same shape for llcv2->rkey[]. Bound both loops by the buffer they read from, and skip the extension altogether when there is no shared v2 receive buffer. The extension does arrive on the link, but smc_llc_enqueue() copies only sizeof(union smc_llc_msg) into the queue entry, so what that code read past the 44 inline bytes was heap and not peer data. Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1") Cc: stable@vger.kernel.org Reviewed-by: Sidraya Jayagond Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260819023306.644849-3-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b893152a886bb53f28dbe027d2d8e7fdeb23e1c6 Author: Koichiro Den Date: Thu Aug 20 02:25:39 2026 +0900 net: ntb_netdev: Count packets dropped on RX refill failure commit 31ded341c375bb2faac1d77ab0012a732ba3e2a6 upstream. When replacement skb allocation fails, ntb_netdev drops a packet that was received successfully and requeues the original buffer. The drop is counted, but rx_packets and rx_bytes are not. Count every good packet before allocating its replacement. Fixes: d2121faf133a ("NTB: ntb_netdev: Preserve RX queue depth on allocation failure") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260819172539.1450821-3-den@valinux.co.jp Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4fac86e97697545e21e9963ae417e8dabf95cb81 Author: Koichiro Den Date: Thu Aug 20 02:25:38 2026 +0900 net: ntb_netdev: Avoid double-accounting netif_rx() drops commit 82e15be2d8b9efa6fb1750528d9b6f40e6a8eea7 upstream. netif_rx() already accounts packets it drops in the core rx_dropped counter. ntb_netdev counts them again as both errors and drops. Leave netif_rx() drops to the core. Count the packet and bytes unconditionally since it was received successfully by the driver. Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device") Cc: stable@vger.kernel.org Suggested-by: Jakub Kicinski Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260819172539.1450821-2-den@valinux.co.jp Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit dfab7171cd3916e51561a2364a35b7186c40283f Author: Koichiro Den Date: Mon Aug 17 14:35:17 2026 +0900 net: ntb_netdev: Fix TX busy and drop handling commit 8aaa47351db0f93a5c5297fbafdfa8bc75e8ae49 upstream. Currently, ntb_netdev returns NETDEV_TX_BUSY for every enqueue error. It also increments the drop and error counters while leaving the skb owned by the qdisc, and may return BUSY with the subqueue still awake. Retrying a permanent error cannot succeed either. The unconditional BUSY return and premature accounting date back to the initial driver. The error-path queue stop was later removed without changing that return value. The current flow-control code includes a resource check, but ntb_netdev does not honor its result before enqueue. Honor the resource check before enqueue. For -EAGAIN and -EBUSY, stop the subqueue, arm the existing reaper timer, and return BUSY without touching the skb. For other errors, free the skb, increment tx_dropped, and return NETDEV_TX_OK. Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device") Fixes: d723485cb4ca ("ntb_netdev: remove tx timeout") Fixes: e74bfeedad08 ("NTB: Add flow control to the ntb_netdev") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260817053519.4135287-3-den@valinux.co.jp Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6b6bbc6c878d64eacc60877df49fce7b1b6a08d0 Author: Koichiro Den Date: Mon Aug 17 14:35:19 2026 +0900 NTB: ntb_transport: Reject oversized TX buffers commit a4f2387db6f1cc2f03abba7f3a6807ad61e26ff7 upstream. ntb_process_tx() handles an oversized buffer by calling tx_handler() with a NULL data pointer and returning success. ntb_netdev therefore neither frees the skb in its completion callback nor takes its enqueue error path, leaking it. Reject oversized buffers in ntb_transport_tx_enqueue() before acquiring a queue entry and return -EMSGSIZE. The caller retains ownership of the buffer, and the preceding netdev patch frees the skb when enqueue returns this permanent error. Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260817053519.4135287-5-den@valinux.co.jp Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 894e136b432da75c0352c80299807a5c4b04f167 Author: Koichiro Den Date: Mon Aug 17 14:35:18 2026 +0900 NTB: ntb_transport: Fail TX enqueue when the QP link is down commit 873ce713fef5dde0939220f04f3484ec86a16fba upstream. Commit f195a1a6fe41 ("ntb: Drop packets when qp link is down") meant to make ntb_transport_tx_enqueue() drop packets submitted while the QP link is down, but it only returns 0 without consuming the packet. Zero means success by this function's contract, so ntb_netdev reports NETDEV_TX_OK and forgets the skb: nothing queued it, nothing frees it, and it leaks, one skb for every transmit racing a link-down. Return -ENOLINK instead, restoring the contract that a non-zero return leaves the buffer owned by the caller. With the preceding patch, ntb_netdev frees the skb on non-retryable enqueue failures and returns NETDEV_TX_OK, so a packet racing with link-down is dropped without leaking or entering a busy retry loop. Fixes: f195a1a6fe41 ("ntb: Drop packets when qp link is down") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260817053519.4135287-4-den@valinux.co.jp Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0c4aabc90449069596909e2a824dc7ad6e0c4e7c Author: Koichiro Den Date: Mon Aug 17 14:35:16 2026 +0900 NTB: ntb_transport: Recycle TX entries before client callbacks commit 256496397287334a19ed80ec7be92bffcae76b9d upstream. ntb_tx_copy_callback() invokes the client callback before returning the entry to tx_free_q. The callback may wake a stopped client queue, only for the next enqueue to find no local entry and return -EBUSY. The window is narrow, but the retry is unnecessary. Save the callback data and length, then return the entry to tx_free_q before invoking the client. A completion callback then means both the client buffer and transport entry are ready for reuse. Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260817053519.4135287-2-den@valinux.co.jp Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f01e6a35c440b62f060e21f36b385e574a7f308c Author: Fan Ye Date: Tue Aug 11 13:20:50 2026 +0000 net: thunderbolt: Mark the connection down when bringing it up fails commit 3c8b26ebf525ba5960510f48c6e9936a79ebe76f upstream. Every failure path in tbnet_connected_work() undoes its own work and returns without clearing login_sent, so the connection still looks established. The next tbnet_tear_down() therefore takes its main branch and repeats a teardown that already happened: it stops rings that are already stopped, which is a dev_WARN() and fatal under panic_on_warn, and it releases net->remote_transmit_path even on the HopID mismatch path, where this connection never owned that id, silently freeing one that someone else is still using. Clear login_sent on those paths. That is enough for tbnet_tear_down() to leave the unwound state alone, and login_received has to stay set: it records that the peer has logged in and carries the transmit path it gave us, which nothing on this side can make the peer send again. Two things change beyond keeping the teardown out of the way: the logout request in that block is no longer sent, and the peer's next login request now re-queues our login work rather than connected_work, giving the connection a fresh login instead of a retry on stale state. Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Cc: # 5.13+ Signed-off-by: Fan Ye Acked-by: Mika Westerberg Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260811-b4-tbnet-hopid-v3-2-9e75d1b51331@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 61ff3c353e5d2ff4eb9d0b6d8d9e47805b136eea Author: Fan Ye Date: Tue Aug 11 13:20:49 2026 +0000 net: thunderbolt: Release the Rx HopID that was handed out on mismatch commit 2f1463554d0561a2fead81e3888604e5c1125e29 upstream. tb_xdomain_alloc_in_hopid() passes the wanted HopID to ida_alloc_range() as the lower bound, so a taken id is not an error there: the allocator returns the next free one above it. tbnet_connected_work() asks for the peer's transmit path, treats any other id as a failure and returns without releasing what it got, so that allocation stays live for the rest of the XDomain connection with nothing left holding a reference to it. Release the id when it is not the one we asked for, the same way the error unwind at the end of the function releases the expected one. Fixes: 180b0689425c ("thunderbolt: Allow multiple DMA tunnels over a single XDomain connection") Cc: stable@vger.kernel.org Signed-off-by: Fan Ye Acked-by: Mika Westerberg Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260811-b4-tbnet-hopid-v3-1-9e75d1b51331@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 67a82e6f886beed0de8f8da08bb767e68fba952d Author: Xuanqiang Luo Date: Tue Aug 11 18:37:33 2026 +0800 net: ravb: serialize PTP clock teardown commit 1cb9663789c5b7a12fcd419fcca6d6254c398252 upstream. ravb_ptp_interrupt() can race with ravb_ptp_stop() and pass the clock to ptp_clock_event() while ptp_clock_unregister() is freeing it. This can lead to a use-after-free. Use READ_ONCE() and WRITE_ONCE() for lockless access to the clock pointer. Atomically detach it with xchg() before disabling PTP interrupts, then synchronize all IRQs which can invoke ravb_ptp_interrupt() before unregistering the detached clock. A handler which read the old pointer completes before the clock is unregistered, while later handlers read NULL and skip the event. Fixes: a0d2f20650e8 ("Renesas Ethernet AVB PTP clock driver") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260811103733.62599-3-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8d4d06d6e2b501cb8e30ed3b1924c470358e8052 Author: Xuanqiang Luo Date: Tue Aug 11 18:37:32 2026 +0800 net: ravb: avoid dereferencing an invalid PTP clock commit 1f77af0aaf277413ff32f6ff8c2c4282bd64c897 upstream. The PTP clock is unavailable before the first open, so querying its index can dereference a NULL pointer. Registration failures can also leave an error pointer in priv->ptp.clock. Cache the PHC index separately and report -1 while no clock is registered. Normalize registration errors to NULL and preserve the static timestamping capabilities. Fixes: a0d2f20650e8 ("Renesas Ethernet AVB PTP clock driver") Cc: stable@vger.kernel.org Reviewed-by: Vadim Fedorenko Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260811103733.62599-2-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b6b533f83461c3730875cf3ed5ff6362dcb67be9 Author: Christian Marangi Date: Mon Aug 17 23:30:03 2026 +0200 net: phylink: correctly validate returned PCS in phylink_inband_caps commit f2849b1fd059ec9b3281b771e6ac5aad9feee851 upstream. In phylink_inband_caps(), the PCS returned by mac_select_pcs is only checked if NULL but mac_select_pcs can also return an error pointer. This can cause a kernel panic as phylink_pcs_inband_caps() only checks if passed PCS is not NULL and directly dereference ops from the phylink_pcs struct. Use the IS_ERR_OR_NULL macro to address both case where the returned PCS can be NULL or an error pointer and prevent a kernel panic. Cc: stable@vger.kernel.org Fixes: df874f9e52c3 ("net: phylink: add pcs_inband_caps() method") Signed-off-by: Christian Marangi Link: https://patch.msgid.link/20260817213009.13924-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0860af127aa798987c34e3823c86223d92623064 Author: Ruoyu Wang Date: Sat Aug 15 23:17:29 2026 +0800 net: openvswitch: fix nf_connlabels leak in ovs_ct_init commit f9de5db270a4c2641de87ee558c16a9bc6eb4cd8 upstream. ovs_ct_init() acquires a connlabels reference before initializing the conntrack limit state. If ovs_ct_limit_init() fails, its error is returned directly. The pernet core does not invoke the exit callback for the operation whose initialization failed, so ovs_ct_exit() cannot drop the reference. This leaves labels_used elevated when Open vSwitch pernet registration fails for an existing network namespace. Subsequent conntrack entries in that namespace may allocate label extensions even though Open vSwitch failed to register. Drop the connlabels reference before returning a conntrack limit initialization error. ovs_ct_limit_init() already releases its partial state, and the original error remains unchanged. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/20260815151729.3757984-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ac73e3af571da06c1d1cfe3f0f00dc978b851700 Author: Ilya Maximets Date: Sat Aug 15 02:58:56 2026 +0200 net: openvswitch: fix flow mask use-after-free on flow deletion commit 4e30317ff67a2eb12b4d890d39f72fd7e7117d48 upstream. The commit in the Fixes tag below made so flow->mask free is scheduled via RCU right after it is removed from the flow table. The pointer stays in the flow structure and it can be accessible while in the same RCU critical section. This is done to avoid requiring ovs_mutex for the ovs_flow_free(). However, while removing the flow during processing of CMD_DEL, we do not take RCU read lock before the removal, and ovs_flow_cmd_fill_info() uses the flow->mask pointer afterwards. The RCU read lock is taken, but it's already late at that point. The comment on that line acknowledges that the lock is cosmetic and doesn't serve a real purpose. This leads to use-after-free if the RCU grace period passes between removal and the filling. It is a short race window, but it is there and can lead to a real crash in case memory allocation for the info takes a bit longer: BUG: KASAN: slab-use-after-free in __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 BUG: KASAN: slab-use-after-free in ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 Read of size 4 at addr ffff88801ee89970 by task ovs_flow_del_ec/9487 Call Trace: __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c:930 ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c:1467 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Allocated by task 9487: mask_alloc net/openvswitch/flow_table.c:967 flow_mask_insert net/openvswitch/flow_table.c:1012 ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c:1084 ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c:1086 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Freed by task 9485: rcu_free_sheaf+0x1e/0x100 mm/slub.c:5978 rcu_do_batch kernel/rcu/tree.c:2645 rcu_core+0x59c/0x10c0 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9a0 kernel/softirq.c:622 ... instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 ovs_flow_tbl_remove() must be called after the ovs_flow_cmd_fill_info() to avoid this race. This also helps with cleaning up the forced cast and the cosmetic RCU read lock. Before the commit in the Fixes tag the order did not matter as long as the flow object itself was not freed. A wider RCU critical section could be another option, but we have a GFP_KERNEL allocation in the way. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-32042. Fixes: 56c19868e115 ("openvswitch: Make flow mask removal symmetric.") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20260815005915.1097270-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9c340473f4822bb31b151c19afd17448eda5acd1 Author: Zihan Xi Date: Thu Aug 20 18:40:28 2026 +0000 net: l2tp: do not propagate multicast notification errors commit af20e269f7459d2ce69887fdf2fad7caf986c865 upstream. The tunnel create, tunnel modify, session create, and session modify netlink handlers send multicast notifications through helpers that can fail while allocating or encoding a message, or while multicasting it. For tunnel and session create/modify, a notification is sent after the live operation has completed. Returning a best-effort notification error as the command result can therefore report failure for an operation that already committed and can cause callers to retry and accumulate live objects. Keep sending notifications for listener visibility, but do not propagate their best-effort status as the command result. This also keeps the tunnel modify command consistent with the other notification-only paths. Fixes: 33f72e6f0c67 ("l2tp : multicast notification to the registered listeners") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zihan Xi Reviewed-by: Simon Horman Link: https://patch.msgid.link/54f48e812ca0424c47ffdb9a8182180921f7e6b2.1787247008.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 62da38b4b3a0dd74a3e0eecf4992d40385924205 Author: Jorijn van der Graaf Date: Sat Aug 15 06:03:02 2026 +0200 net: ipa: fix stalled modem TX queue after runtime resume commit 3cbfd627ee720f3d2460d2cbe2fe9e4130240db6 upstream. ipa_start_xmit() unconditionally stops the TX queue before calling pm_runtime_get(), relying on the wake scheduled by runtime resume (ipa_modem_wake_queue_work()) to restart it once power is ACTIVE. But that work is queued from within the runtime resume callback, before the device's power state reaches RPM_ACTIVE, so it can run while the device is still RPM_RESUMING. The wake is then consumed too early: the transmit it restarts stops the queue again, pm_runtime_get() returns -EINPROGRESS without arranging any future wake (deferred_resume exists only for RPM_SUSPENDING), and after the resume completes nothing is left to wake the queue. Transmit stalls permanently: packets pile up in the qdisc behind the stopped queue, the device runtime-suspends, and since the netdev registers no ndo_tx_timeout the watchdog never fires. Observed on SM7635 (Fairphone 6) as the cellular data path going permanently deaf within hours, RX included, since nothing resumes the suspended endpoints. Close the window by making the wake work wait for the resume to complete (pm_runtime_get_sync()) before waking the queue. Every queue stop is then guaranteed a later wake that happens while power is ACTIVE; a transmit racing a new suspend/resume cycle re-schedules the work. If the device could not be resumed, wake the queue anyway so pending packets are dropped by the transmit path rather than stranded. The STARTED power flag used to narrow this window: a wake running before the transmit path's stop suppressed that stop, but only once, as the flag was cleared by the first stop it absorbed. Removing the flag made a single transmit during an in-flight resume sufficient to strand the queue, which is the form observed. With an accelerated reproducer (autosuspend delay shortened to 5 ms, ~20 packets/s of TX), an unpatched kernel stalled three times in 230 s / 4380 packets; with this patch the same test ran 3601 s / 70298 packets without a stall. Fixes: 688de12f080f ("net: ipa: kill the STARTED IPA power flag") Cc: stable@vger.kernel.org Signed-off-by: Jorijn van der Graaf Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260815040302.653650-1-jorijnvdgraaf@catcrafts.net Signed-off-by: David S. Miller Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 42a33e679ea051a5f929743c0b47855e3fab5dc4 Author: Runyu Xiao Date: Tue Aug 11 15:08:13 2026 +0800 net: ibm: emac: mal: fix NAPI locking commit 43b0213529c6ae2fd4cbf8dbb9baff87a34c27d7 upstream. Since commit 413f0271f396 ("net: protect NAPI enablement with netdev_lock()"), napi_enable() and napi_disable() take netdev_lock(). mal_register_commac() and mal_unregister_commac() call these helpers while holding mal->lock with interrupts disabled. In the unregister path, napi_disable() may also wait for polling to finish, while the poll completion path takes mal->lock. Take netdev_lock() before mal->lock, use the locked NAPI helpers, and drop mal->lock before napi_disable_locked(). Fixes: 413f0271f396 ("net: protect NAPI enablement with netdev_lock()") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260811070813.377573-1-runyu.xiao@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f71087e7c63aa3e99bf65d7ddf91eb4fd3545778 Author: Ahmad Fatoum Date: Fri Aug 14 13:01:02 2026 +0200 net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO commit fb58b6a696b30bcbfbe0cfc0a91b19c816a955fc upstream. rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from the probe path, which may sleep and is not timing-critical. When the reset GPIO is provided by a sleeping controller such as an I2C I/O expander, gpiod_set_value() warns: WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61 Hardware name: B&O MAP CA33 Rev f (UNKNOWN) (DT) Workqueue: events_unbound deferred_probe_work_func pc : gpiod_set_value+0x44/0x80 lr : rtl83xx_probe+0x1d8/0x3a0 Call trace: gpiod_set_value+0x44/0x80 (P) rtl83xx_probe+0x1d8/0x3a0 realtek_mdio_probe+0x24/0xa0 mdio_probe+0x38/0x78 really_probe+0xc4/0x3e0 __driver_probe_device+0x15c/0x1b8 driver_probe_device+0xb4/0x120 __device_attach_driver+0xb8/0x1a0 bus_for_each_drv+0x88/0xf0 __device_attach+0xa0/0x1d8 device_initial_probe+0x54/0x68 bus_probe_device+0x38/0xa0 deferred_probe_work_func+0xb8/0x120 process_one_work+0x184/0x4e8 worker_thread+0x188/0x308 kthread+0x130/0x150 ret_from_fork+0x10/0x20 Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can be used without triggering the warning. The reset GPIO has been driven with the non-sleeping gpiod_set_value() since the driver was added in v4.19. The call has since been refactored across several files - from realtek-smi.c / realtek-mdio.c into the common rtl83xx.c module and then into the rtl83xx_reset_assert() and rtl83xx_reset_deassert() helpers (both in v6.9). This patch therefore applies as-is only to kernels that carry those helpers (v6.9+); older stable kernels need the same gpiod_set_value_cansleep() conversion at the corresponding open-coded call sites. Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver") Cc: # 6.9.x Signed-off-by: Ahmad Fatoum Co-developed-by: Oleksij Rempel Signed-off-by: Oleksij Rempel Reviewed-by: Alvin Šipraga Reviewed-by: Linus Walleij Reviewed-by: Luiz Angelo Daros de Luca Link: https://patch.msgid.link/20260814110102.2362246-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e098d9cc8859614a7f7baebc96e32a5a16b18ed2 Author: Asim Viladi Oglu Manizada Date: Wed Aug 12 01:21:53 2026 +0000 net: tun: bound receive headroom commit 447c9303942c439a117d9b76ce6d6e2116b38ee7 upstream. tun_get_user() uses tun->align both as skb headroom and when choosing how much packet data to keep linear. OVS can propagate an oversized headroom request from another port to TUN or TAP. When align is larger than the usable space in a one-page skb head, SKB_MAX_HEAD(align) underflows and the result becomes negative when stored in good_linear. That value later wraps when assigned to the size_t linear variable, and tun_alloc_skb() can place skb->data outside the allocated head. Bound the headroom stored by TUN to the one-page skb-head budget and the largest non-sentinel 16-bit skb header offset. Leave one linear byte for raw TUN and a complete Ethernet header for TAP, including NET_IP_ALIGN. Also pull the raw-TUN protocol byte and the TAP Ethernet header before accessing them, so these checks remain safe for nonlinear skbs supplied by other allocation paths. Fixes: eaea34b23c46 ("net/tun: implement ndo_set_rx_headroom") Cc: stable@vger.kernel.org Signed-off-by: Asim Viladi Oglu Manizada Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260812012139.2134643-1-manizada@pm.me Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 32785d75e60df4d4f09989ca7fcdaba3fb17f087 Author: Fabio Porcedda Date: Wed Aug 12 07:49:11 2026 +0200 net: usb: qmi_wwan: add Telit Cinterion FE990D50 composition commit 1056e79fffd0841f43c6a1b25664b196b3caf1c6 upstream. Add the followin Telit Cinterion FE990D50 composition: 0x0991: rmnet + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (AT) + tty (diag) + ADPL + adb T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=03 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=0991 Rev=06.06 S: Manufacturer=Telit Cinterion S: Product=FE990 S: SerialNumber=2aa802d2 C: #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org Signed-off-by: Fabio Porcedda Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260812054911.447887-1-Fabio.Porcedda@telit.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 486577db807891d0f964fdf13c1640c7f54b0ad1 Author: Aleksandr Khromov Date: Mon Aug 24 13:05:47 2026 +0300 slip: fix use-after-free in sl_sync() commit 2c4e7c42d77e78ad595dbb9e4b5886b58b45d89d upstream. slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor. priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop: /* Snapshot list, allow later requests */ list_replace_init(&net_todo_list, &list); __rtnl_unlock(); ... if (dev->priv_destructor) dev->priv_destructor(dev); /* slip_devs[i] = NULL */ if (dev->needs_free_netdev) free_netdev(dev); ... /* Free network device */ kobject_put(&dev->dev.kobj); So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed */ sl = netdev_priv(dev) if (sl->tty || sl->leased) /* use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860 Commit e58c19124189 ("slip: Fix use-after-free Read in slip_open") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it. Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: they run under the same RTNL section, so the slot cannot have been reused in between. This also removes the second symptom of the missing exclusion: a destructor running after sl_alloc() had already handed the slot out to another channel used to clear a live entry, so sl_sync() stopped at that NULL, sl_alloc() returned the same index again, and register_netdevice() failed with -EEXIST because slN was still there. Reproduced on x86_64 with several threads looping over open("/dev/ptmx") + ioctl(TIOCSETD, N_SLIP) + close(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 5342b77c4123 ("slip: Clean up create and destroy") Cc: stable@vger.kernel.org Suggested-by: Jakub Kicinski Signed-off-by: Aleksandr Khromov Link: https://patch.msgid.link/20260824100547.164773-1-haa@amicon.ru Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 15d1f3c0dbe7a740f779337deb39f23cd8d002c8 Author: Weiming Shi Date: Tue Aug 18 23:45:15 2026 +0800 xdp: fix zero-copy frame layout commit 71283aaa6c65b3cec84caf1dc78560985737641f upstream. xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page and advertises PAGE_SIZE as its frame size. It allows the copied frame to occupy the page tail needed by skb_shared_info and records zero headroom even when metadata separates the frame header from packet data. An AF_XDP zero-copy packet redirected through cpumap can therefore make the skb overlap skb_shared_info or place it beyond the allocated page. Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result. BUG: KASAN: slab-out-of-bounds in skb_gro_receive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skb_gro_receive (net/core/gro.c:174) udp_gro_receive (net/ipv4/udp_offload.c:812) inet_gro_receive (net/ipv4/af_inet.c:1539) dev_gro_receive (net/core/gro.c:515) gro_receive_skb (net/core/gro.c:633) cpu_map_kthread_run (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Kernel panic - not syncing: KASAN: panic_on_warn set ... Fixes: b0d1beeff2a9 ("xdp: implement convert_to_xdp_frame for MEM_TYPE_ZERO_COPY") Cc: stable@vger.kernel.org Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260818154516.793517-1-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8e3763f1ccac3fc395f9af2b87114c023ced8a3f Author: Alexandra Winter Date: Fri Aug 21 14:55:01 2026 +0200 net/iucv: filter frames in afiucv_hs_rcv() by ingress device commit 80230a18c164a4b5bbc048fe2768b219ac17bc5a upstream. afiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-byte name fields in the transport header alone. No check is made against the net_device the frame arrived on. This can cause a frame arriving on any netdev to be delivered to an AF_IUCV socket. Three problems follow. First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL. iucv_sock_bind() takes the classic path whenever the requested userid matches iucv_userid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucv_hs_callback_syn() for such a match inherits hs_dev = NULL and transport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable. Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections Third, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() calls sk_alloc(&init_net, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAP_NET_RAW capability valid within that namespace can send a raw ETH_P_AF_IUCV frame on its own lo device and have it matched against init_net sockets. Fix all three by skipping any socket whose hs_dev does not match the ingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hs_dev is always a device in init_net (iucv_sock_bind() scans for_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket. Note that AF_IUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment. Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport") Cc: stable@vger.kernel.org Co-developed-by: Bryam Vargas Signed-off-by: Alexandra Winter Link: https://patch.msgid.link/20260821125501.3718748-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 99692252b348c11377fd0cdd66b6b18f3b22758e Author: Corey Minyard Date: Tue Aug 18 12:49:52 2026 -0500 ipmi:msghandler: Cancel work cleanly on an error commit ae84a2536577057e97f23f75a202e26d0e86cf01 upstream. If an error occurs during startup of an IPMI interface, it may have scheduled work to run. The work needs to be canceled before the interface can be freed. Reported-by: Nilay Shroff Closes: https://sourceforge.net/p/openipmi/mailman/message/59375605/ Fixes: 62cd145453d5 ("ipmi:msghandler: Handle error returns from the SMI sender") Cc: stable@vger.kernel.org # 7.0 Tested-by: Nilay Shroff Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 53af3a8bae0a93c1342e1b5519812203332aca8e Author: Seiji Nishikawa Date: Wed Jul 1 02:43:48 2026 +0900 ipmi: si: Fix NULL pointer dereference after failed registration commit 6d920a75df9a83ab096b3cde7a643b656e4fdfeb upstream. try_smi_init() allocates new_smi->si_sm and later calls ipmi_register_smi_mod(), which maps to ipmi_add_smi(). During ipmi_add_smi(), the upper IPMI message handler obtains the initial BMC device information through __bmc_get_device_id(). This can fail if the BMC does not return a successful response to the Get Device ID command. When the BMC returns a nonzero completion code, the device-id helper retries the command and eventually returns -EIO if the device ID still cannot be fetched. On this failure path, ipmi_add_smi() logs "Unable to get the device id" and goes to out_err_started, where it invokes the lower driver's shutdown callback. try_smi_init() then logs the returned registration failure: ipmi_si IPI0001:00: IPMI message handler: Unable to get the device id: -5 ipmi_si IPI0001:00: Unable to register device: error -5 For ipmi_si, the shutdown callback is shutdown_smi(), which cleans up the SI state machine data, frees smi_info->si_sm, and sets smi_info->si_sm and smi_info->intf to NULL. However, intf->in_shutdown is not set on this failed-registration rollback path. Therefore, the asynchronous redo_bmc_reg work item can still retry BMC device-id probing after the lower driver has already cleared its SI state machine data. In the observed case, that retry path reached start_next_msg(), which passed the NULL smi_info->si_sm pointer to the selected KCS state machine handler: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Workqueue: events redo_bmc_reg [ipmi_msghandler] RIP: start_kcs_transaction+0x2c/0x190 [ipmi_si] Call Trace: start_next_msg+0x50/0x80 [ipmi_si] check_start_timer_thread.part.9+0x3b/0x50 [ipmi_si] sender+0x69/0x80 [ipmi_si] i_ipmi_request+0x2ac/0x9d0 [ipmi_msghandler] __get_device_id.isra.29+0xaa/0x180 [ipmi_msghandler] __bmc_get_device_id+0xef/0x950 [ipmi_msghandler] redo_bmc_reg+0x52/0x60 [ipmi_msghandler] process_one_work+0x1a7/0x360 Set intf->in_shutdown on the out_err_started path before invoking the lower driver's shutdown callback. This prevents later redo_bmc_reg retries from using an interface whose lower driver state has been cleaned up, and applies the same shutdown state to other IPMI interfaces as well. Fixes: 2512e40e48d2 ("ipmi: Rework SMI registration failure") Cc: stable@vger.kernel.org Signed-off-by: Seiji Nishikawa Message-ID: <20260630174348.1483814-1-snishika@redhat.com> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit d46c97eddcbc53ca885e8bb359930c58884616ff Author: Yuho Choi Date: Sun Aug 2 21:55:50 2026 -0400 ipmi: Remove all sysfs files on registration failure commit b6c46ab0bdee90c238e96ea4a74972118c97900d upstream. ipmi_add_smi() creates the nr_users and nr_msgs files before trying to create the maintenance_mode file. If that last creation fails, the error path removes only nr_users before dropping the final reference to the interface. Remove nr_msgs as well so no sysfs attribute embedded in the freed interface remains registered. Fixes: 627118470fcc ("ipmi: Add a maintenance mode sysfs file") Cc: stable@vger.kernel.org # 6.18 Signed-off-by: Yuho Choi Message-ID: <20260803015550.618808-1-dbgh9129@gmail.com> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 5719431ca2b5fa26560bb38f6202f8b97fa3bbb0 Author: Yousef Alhouseen Date: Wed Jun 24 19:53:53 2026 +0200 ipmi: ipmb: validate write message length commit 53637506884dbd5c91a89b1a3547d99d80f8ed2c upstream. ipmb_write() read message fields before validating the length byte. A zero or short write can read uninitialized stack bytes. A length smaller than the SMBus header underflows the block write length. Require a non-empty buffer and the minimum IPMB request length. Also require the length byte plus payload before parsing the message. Fixes: 51bd6f291583 ("Add support for IPMB driver") Cc: stable@vger.kernel.org Signed-off-by: Yousef Alhouseen Message-ID: <20260624175353.8592-1-alhouseenyousef@gmail.com> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit db8147c5d5ad2cfa21c2be566f95981b41b05de6 Author: Kuan-Wei Chiu Date: Thu Apr 16 19:08:40 2026 +0000 interconnect: Fix use after free in icc_get() and of_icc_get_by_index() commit 25c7e242aca084fdc1098248194032317dca625d upstream. In of_icc_get_by_index() and icc_get(), if the dynamic allocation for path->name fails via kasprintf(), the error handling path directly calls kfree(path) to free the path object and returns an error. However, prior to this point, path_find() calls path_init(), which already links the path's requests into the req_list of the respective interconnect nodes via hlist_add_head(). Directly invoking kfree(path) leaves dangling pointers in the hlist. A subsequent call to icc_get() or icc_set_bw() will traverse or modify these corrupted lists, triggering a slab use afterfree. KASAN report showing the vulnerability when reproducing via debugfs: BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0 Fix this by replacing kfree(path) with the proper teardown function, icc_put(path), which safely removes the requests from the req_list using hlist_del() and drops the provider usage references before freeing the memory. Additionally, in icc_get(), ensure that the icc_lock mutex is released prior to calling icc_put(path) to avoid a deadlock, as icc_put() internally acquires the same lock. Fixes: 3791163602f7 ("interconnect: Handle memory allocation errors") Cc: stable@vger.kernel.org Signed-off-by: Kuan-Wei Chiu Link: https://patch.msgid.link/20260416190840.1753468-1-visitorckw@gmail.com Signed-off-by: Georgi Djakov Signed-off-by: Greg Kroah-Hartman commit 417e02f7b6051765b91cf1289071882eebd172e0 Author: Laxman Acharya Padhya Date: Fri Aug 21 16:18:17 2026 +0545 io_uring/query: cap user size passed to copy_struct_to_user commit ba77efee1b95b4ad7559b1cdbe7cd7fa36dca95b upstream. io_handle_query_entry() clamps hdr.size for the inbound copy_from_user() but keeps the original user value as usize. copy_struct_to_user() uses that usize and, when it is larger than the kernel result, clear_user()s the trailing bytes. As hdr.size is a __u32, a query can request nearly 4 GiB of zeroing, including on the error path where res_size stays 0. The interface is reachable without a ring via IORING_REGISTER_QUERY. Reject sizes larger than PAGE_SIZE, as recommended for copy_struct_* interfaces. Fixes: c265ae75f900 ("io_uring: introduce io_uring querying") Cc: stable@vger.kernel.org # 6.18+ Signed-off-by: Laxman Acharya Padhya Reviewed-by: Gabriel Krisman Bertazi Link: https://patch.msgid.link/20260821103317.91437-1-acharyalaxman8848@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0c12a798078bc4749b2f8ca91e1069fc7586423a Author: Muhammad Bilal Date: Thu Jul 9 21:58:59 2026 +0500 platform/x86: hp-bioscfg: warn on element type mismatch instead of failing commit b0e2af3ec94e0431adb59d9f249ebbd3b7285158 upstream. hp_populate_enumeration_elements_from_package() returns -EIO and aborts enumeration of the entire attribute when any single element has an unexpected ACPI type. This is observed on HP EliteBook 840 G2 when the BIOS returns malformed ACPI data following a failed WMI query: ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Index (0x000000032) is beyond end of object (length 0x32) ACPI Error: Aborting method \_SB.WMID.WQBE due to previous error Error expected type 2 for elem 13, but got type 1 instead hp_bioscfg: Returned error 0x3, "Invalid command value/Feature not supported" Aborting immediately discards the attribute entirely. Warn about the unexpected element type, free the temporary string, skip the offending element, and continue parsing the remaining package instead of failing the whole attribute. Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260709165900.30615-5-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit a38127df99ae8b1851560b35b837c9952416143a Author: Muhammad Bilal Date: Thu Jul 9 21:58:56 2026 +0500 platform/x86: hp-bioscfg: pass validated element count to package parsers commit e0ddfd77c0c320b7d12b6c9169303b140b798775 upstream. The per-type package parsers are handed the wrong element count. hp_init_bios_package_attribute() validates obj->package.count and then calls one of the five hp_populate_*_package_data() wrappers (string, integer, enumeration, ordered list, password). Each wrapper forwards a count to its hp_populate_*_elements_from_package() parser, but instead of forwarding the validated obj->package.count it derives the count from elements[0]. elements[0] is the NAME field and is always an ACPI_TYPE_STRING, so reading ->package.count from it in fact reads ->string.length through the union acpi_object. The parsers thus bound themselves against the length of the name string rather than against the real number of elements in the package. This is safe today because hp_init_bios_package_attribute() refuses any package that has fewer than the type's element count, so a parser only ever runs on a full package and never reads past it regardless of the bogus bound. An upcoming change relaxes that check to accept shorter packages. Once a parser can receive fewer elements than its per-type count, a bound taken from the name length no longer reflects the array size, and the "elem < count" loop conditions and "elem + n >= count" sub-loop guards read past the end of elements[] - an out-of-bounds heap read. Forward the validated obj->package.count to every *_package_data() wrapper so the parsers bound themselves against the real package size. This does not change behaviour for the packages that enumerate correctly today and is a prerequisite for accepting shorter packages safely. Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260709165900.30615-2-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 95d2f9b5189d0f86f15598aaa1e4e6587b8b562e Author: Muhammad Bilal Date: Wed Aug 12 16:18:28 2026 +0500 platform/x86: hp-bioscfg: fix ORD_LIST_ELEMENTS never being parsed commit cb6b1b0fb236a9581cae213c2a9182e68cc3ffe5 upstream. The ACPI_TYPE_STRING case explicitly skips the string conversion for elem == ORD_LIST_ELEMENTS: if (elem != PREREQUISITES && elem != ORD_LIST_ELEMENTS) { ret = hp_convert_hexstr_to_str(..., &str_value, &value_len); if (ret) continue; } so by the time the ORD_LIST_ELEMENTS case in the eloc switch runs, str_value is NULL (it was freed and reset to NULL at the end of the previous iteration). That case then does: ret = hp_convert_hexstr_to_str(str_value, value_len, &tmpstr, &tmp_len); hp_convert_hexstr_to_str() rejects a NULL input with -EINVAL, which sends this function to exit_list, and exit_list unconditionally returns 0. The net effect is that any ordered-list attribute with elements present silently ends up with an empty elements list, with no error surfaced anywhere. Fix by converting the current element directly, order_obj[elem], the same way the PREREQUISITES case already handles its own array elements, instead of reusing the unrelated str_value/value_len left over from earlier processing. Fixes: 4b2672ec71a3 ("platform/x86: hp-bioscfg: order-list-attributes") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260812111829.172273-9-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit b15b334fbc3c0c46440f8a892ebf62164fca23d6 Author: Muhammad Bilal Date: Wed Aug 12 16:18:21 2026 +0500 platform/x86: hp-bioscfg: fix off-by-one write in hp_get_string_from_buffer() commit dc03f05e419f3460342fb7564884f244622634b6 upstream. hp_get_string_from_buffer() clamps the converted string length against the destination buffer size with "size > dst_size", so when the converted length is exactly equal to dst_size, conv_dst_size is left at dst_size and the unconditional NUL terminator write dst[conv_dst_size] = 0; lands one byte past the destination buffer. This is the same shape of bug as the previously fixed off-by-one in hp_convert_hexstr_to_str(): the buffer is sized correctly for the content, but the terminator write is never checked against that size. Fix by changing the comparison to ">=" so conv_dst_size is always left with room for the terminator. All fixed-size destinations that reach this function (path[512], current_value[512], current_password/current_value[64], and the per-entry buffers in encodings[][512] and prerequisites[][512]) are affected. Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260812111829.172273-2-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit e3c1c5d1c92302e1d5f4c585b2ecc51a140deebd Author: Muhammad Bilal Date: Wed Aug 12 16:18:27 2026 +0500 platform/x86: hp-bioscfg: fix new_password_store() overwriting current_password commit 2ea12a467a9cb12170417b30784fe26a243a75fe upstream. current_password_store() and new_password_store() both call store_password_instance() with is_current = true: static ssize_t new_password_store(...) { return store_password_instance(kobj, buf, count, true); } so a write to new_password is routed to current_password instead, and the new_password field is never written by either sysfs entry point. Fix by passing false from new_password_store(), matching what the is_current parameter is meant to select. Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260812111829.172273-8-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 0f9aad08424882dd5714b53d29ae044060890752 Author: Muhammad Bilal Date: Wed Aug 12 16:18:23 2026 +0500 platform/x86: hp-bioscfg: fix heap OOB read on empty password write commit 2b2ec354f905c14e3270e8ec3ab50f7d8ad73bab upstream. validate_password_input() computes length = strlen(buf) and then checks buf[length - 1] to strip a trailing newline, without checking that length is nonzero first. Writing an empty string (a bare '\n') to current_password or new_password gives length == 0, and buf[length - 1] reads buf[-1], one byte before the heap allocation holding the copied input. KASAN confirms this directly: BUG: KASAN: slab-out-of-bounds in store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg] Read of size 1 at addr ffff88811bd8da9f by task sh/13740 ... store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg] current_password_store+0x14/0x20 [hp_bioscfg] ... The buggy address is located 23 bytes to the right of allocated 8-byte region [ffff88811bd8da80, ffff88811bd8da88) Reproduced identically via new_password_store. Execution continues past the bad read (the garbage byte only affects whether "length" is decremented by one), so the write completes and returns success; this is a pure information read past the buffer, not a crash, but it is still an out-of-bounds access KASAN correctly flags. Fix by only checking buf[length - 1] when length is nonzero. Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260812111829.172273-4-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 7cd8fe01aba303a2382db0966eb6c8ab41d5f3c2 Author: Muhammad Bilal Date: Wed Aug 12 16:18:22 2026 +0500 platform/x86: hp-bioscfg: fix heap OOB read in sk_store() and kek_store() commit a7508c7959ff8d037327d377ed21a9c0eabe4674 upstream. sk_store() and kek_store() strip a trailing newline from the sysfs write before allocating the key buffer: length = count; if (buf[length - 1] == '\n') length--; bioscfg_drv.spm_data.signing_key = kmemdup(buf, length, GFP_KERNEL); but then pass the original "count" (not "length") as the copy size to hp_wmi_perform_query(), which memcpy()s that many bytes out of the "length"-sized allocation, reading one byte past it whenever the write ends in a newline, the normal case for a shell "echo" into sysfs. KASAN confirms this directly: BUG: KASAN: slab-out-of-bounds in hp_wmi_perform_query+0x1e9/0x460 [hp_bioscfg] Read of size 28 at addr ffff88813c8e2b80 by task python3/16022 ... sk_store+0xa7/0x240 [hp_bioscfg] kernfs_fop_write_iter+0x3e1/0x5d0 ... The buggy address is located 0 bytes inside of allocated 27-byte region [ffff88813c8e2b80, ffff88813c8e2b9b) Reproduced identically for kek_store, and at multiple write sizes (28, 57, 201 bytes), each time reading exactly one byte past a kmemdup() allocation one byte smaller than the write. Fix by passing "length" instead of "count" to hp_wmi_perform_query() in both functions. Fixes: b2715aa2e135 ("platform/x86: hp-bioscfg: spmobj-attributes") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260812111829.172273-3-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit dea1a41160e70892ab9988dc0aa8b3978726e9cc Author: Muhammad Bilal Date: Thu Jul 9 21:58:57 2026 +0500 platform/x86: hp-bioscfg: bound ordered-list parsing by the package count commit 1d143d78299d0eb4536698bf98c1815ec69f22a9 upstream. hp_populate_ordered_list_elements_from_package() differs from the other per-type parsers: its main loop is bounded only by the fixed per-type count and never checks elem against the number of elements actually present in the package, for (elem = 1, eloc = 1; eloc < ORD_ELEM_CNT; elem++, eloc++) whereas the string, integer, enumeration and password parsers bound their main loop with "elem < count" as well. This is safe today because hp_init_bios_package_attribute() rejects any package with fewer than ORD_ELEM_CNT elements before the parser runs. An upcoming change, however, relaxes that check to accept shorter packages. Bound the loop by the validated element count as well, so it stops at whichever comes first, the per-type count or the real package size, for (elem = 1, eloc = 1; eloc < ORD_ELEM_CNT && elem < order_obj_count; elem++, eloc++) order_obj_count is the validated element count, now correctly forwarded from the caller. No functional change for packages that enumerate correctly today. Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260709165900.30615-3-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 0cd1530f84e1c18b12a99a54dbbdb401c27796bf Author: Muhammad Bilal Date: Wed Aug 12 16:18:29 2026 +0500 platform/x86: hp-bioscfg: advance elem past consumed array elements commit 05c808362e808e196f75696b8a64f7aa8b2245ce upstream. The outer parsing loop in each attribute-type parser advances "elem" (the index into the ACPI package element array) by exactly one per iteration, but cases that consume multi-element arrays (PREREQUISITES, ENUM_POSSIBLE_VALUES, PSWD_ENCODINGS) read "size" consecutive elements without adjusting "elem" for the extra entries consumed beyond the first. The next outer iteration then re-reads a leftover element from the array just consumed instead of the next real property, and the type check fails on that stale element, aborting the parse with -EIO. This produces exactly the failure visible in dmesg on the test hardware, on every boot: Error expected type 2 for elem 13, but got type 1 instead hp_bioscfg: Returned error 0x3, "Invalid command value/Feature not supported" Fix by advancing "elem" by (size - 1) after each array-consuming loop, so the outer loop's own "elem++" lands on the correct next element. "eloc" is intentionally left alone: it indexes the logical property schema, not the physical element array, and each array case is still exactly one logical property regardless of how many physical elements it spans. The defect is identical across all five attribute-type parsers (enum, integer, string, ordered-list, password), which were copy-pasted from the same template when the driver was introduced. Fixes: 6b2770bfd6f9 ("platform/x86: hp-bioscfg: enum-attributes") Fixes: 6f2c06d5a467 ("platform/x86: hp-bioscfg: int-attributes") Fixes: e6c7b3e15559 ("platform/x86: hp-bioscfg: string-attributes") Fixes: 4b2672ec71a3 ("platform/x86: hp-bioscfg: order-list-attributes") Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260812111829.172273-10-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 0a14d35ef529a171a88ce00dc01628c0dca336fa Author: Muhammad Bilal Date: Thu Jul 9 21:58:58 2026 +0500 platform/x86: hp-bioscfg: accept reduced ACPI packages from older HP BIOS commit 40e10e6cc8f70c041431a1e30186807e28ec46e0 upstream. hp_init_bios_package_attribute() hard-fails when a WMI ACPI package contains fewer elements than the type-specific expected count (e.g. 11 elements instead of 13 for INTEGER or ENUMERATION attributes). This causes the entire hp_bioscfg driver to skip attribute enumeration on older HP hardware whose BIOS returns shortened packages when optional fields like prerequisites or possible values are absent. Observed on HP EliteBook 840 G2 (BIOS M71 Ver. 01.31): hp_bioscfg: ACPI-package does not have enough elements: 11 < 13 The element layout has two tiers: - Elements 0-9 (SECURITY_LEVEL+1 = 10): common to all attribute types - Elements 10-N: type-specific (bounds, values, encodings, ...) The per-type populate functions (hp_populate_*_elements_from_package) already handle sparse packages correctly via their own elem < count loop guards and inner-loop bounds checks. The only unsafe case is when we lack even the common elements needed to register the attribute. Fix by introducing COMMON_ELEM_CNT to mark the hard minimum (10), and splitting the check into two tiers: - Fewer than COMMON_ELEM_CNT elements: hard fail, can't proceed. - Fewer than expected type-specific elements: warn, but let the populate function parse what is available. Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260709165900.30615-4-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit bc9aa5fe21c3966c80647ed6574b94b863f23c62 Author: Mario Limonciello Date: Tue Jul 21 13:17:55 2026 -0500 platform/x86/amd/pmc: Fix LPS0 and debugfs leaks when STB init fails commit 76f650a76d6a36a4bee79d94db90a0e935a95477 upstream. amd_pmc_probe() registers the LPS0 s2idle handler with acpi_register_lps0_dev() and creates the driver's debugfs directory before calling amd_stb_s2d_init(), which is the last step in probe that can fail. When amd_stb_s2d_init() fails (for example the S2D telemetry region cannot be ioremapped on a long-running system, or the SMU rejects the S2D setup) the error path only calls pci_dev_put() and returns. This leaves amd_pmc_s2idle_dev_ops on the global lps0_s2idle_devops_head list and leaks the debugfs directory, while the devm-managed resources backing the handler are torn down. Reloading the module then walks the corrupted list in acpi_register_lps0_dev() and hits: list_add corruption. next->prev should be prev, but was NULL. kernel BUG at lib/list_debug.c:29! acpi_register_lps0_dev+0x44/0x80 amd_pmc_probe+0x224/0x380 [amd_pmc] platform_probe+0x67/0x90 Even without a reload, the stale registration means the next s2idle transition calls into torn-down driver state. Unwind the debugfs directory and the LPS0 registration on the amd_stb_s2d_init() error path. acpi_unregister_lps0_dev() is safe to call unconditionally here: it is guarded on the same conditions as acpi_register_lps0_dev(), which is exactly what amd_pmc_remove() already relies on. Reported-by: Francis De Brabandere Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221759 Tested-by: Francis De Brabandere Fixes: 83ad6974dd3b ("platform/x86/amd/pmc: Move STB block into amd_pmc_s2d_init()") Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260721181756.143084-6-mario.limonciello@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 8178f59d76570b152d836bde07f5997f15861f04 Author: Mario Limonciello Date: Tue Jul 21 13:17:53 2026 -0500 platform/x86/amd/pmc: Propagate SMU errors and validate S2D address commit 0225c1d637687b03726f00ac65b6def843d2c464 upstream. amd_stb_s2d_init() discards the return value of several S2D SMU commands. When the SMU refuses a command (e.g. "SMU cmd failed. err: 0xff") the failure is only noticed indirectly - if at all - and reported as -EIO, masking the real error. More seriously, the S2D_PHYS_ADDR_LOW/HIGH return values are ignored, so on failure phys_addr_low/hi are left uninitialised and the assembled address is passed straight to devm_ioremap(). When the SMU leaves them at zero this maps physical address 0 and trips the ioremap-on-RAM warning: amd_pmc AMDI000B:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 13 PID: 4592 at arch/x86/mm/ioremap.c:... Check the return value of each SMU command and propagate it, and reject a zero physical address before calling devm_ioremap(). Reported-by: Francis De Brabandere Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221759 Tested-by: Francis De Brabandere Fixes: 3d7d407dfb05 ("platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature") Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260721181756.143084-4-mario.limonciello@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 98d91d5b6a988438cbcb3846212056b2c8e419d8 Author: Mario Limonciello Date: Tue Jul 21 13:17:51 2026 -0500 platform/x86/amd/pmc: Restore msg_port on amd_stb_s2d_init() error paths commit 9cef693bce96bb4c6952f48d855284cf7fa4f367 upstream. dev->msg_port is switched to MSG_PORT_S2D before issuing the S2D SMU commands but is only restored to MSG_PORT_PMC on the success path. The early "return -EIO" and "return -ENOMEM" leave the port stuck on MSG_PORT_S2D, so all subsequent SMU communication - including the s2idle prepare/restore handlers - is directed at the wrong mailbox. Consolidate the exit path through a single label so the message port is always restored. Fixes: 3d7d407dfb05 ("platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature") Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260721181756.143084-2-mario.limonciello@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 5eaf7faa99578ae090030d1e2e6ea3b37a615496 Author: Bryam Vargas Date: Thu Jun 18 00:46:28 2026 -0500 platform/chrome: sensorhub: Bound the EC-reported sensor number commit 833740a2333c2e4db4e02e3d0ffba04e8718a5f3 upstream. Each EC FIFO event carries an 8-bit sensor number (in->sensor_num). cros_ec_sensorhub_ring_handler() validates the FIFO event count, the per-read count and the ring bound, but not the sensor number, which cros_ec_sensor_ring_process_event() then uses unchecked to index sensorhub->batch_state[] - allocated with only sensorhub->sensor_num entries. A sensor number of sensor_num or larger is an out-of-bounds read and write of batch_state[]. Validate the sensor number in the ring handler, where each event is read from the EC, and drop a malformed event before it is used. Fixes: 145d59baff59 ("platform/chrome: cros_ec_sensorhub: Add FIFO support") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://lore.kernel.org/r/20260618-b4-disp-adb3f790-v3-1-3a164ed63cbd@proton.me Signed-off-by: Tzung-Bi Shih Signed-off-by: Greg Kroah-Hartman commit 56dc46094973dbb9b02b2ae1ef587ff3257e52fa Author: Thorsten Blum Date: Tue Aug 18 17:16:35 2026 +0200 platform/x86: think-lmi: Fix current password length check commit 54745d563114b74f6fecebce68cd020d06c1772b upstream. current_password_store() checks the password length before removing the trailing newline, which can reject valid passwords that are exactly ->maxlen bytes long. It also passes ->maxlen to strscpy(), which truncates passwords without a newline. Use strchrnul() to measure the password length up to the newline, then copy that many bytes and add a trailing NUL terminator using strscpy(). Fixes: a40cd7ef22fb ("platform/x86: think-lmi: Add WMI interface support on Lenovo platforms") Cc: stable@vger.kernel.org Reviewed-by: Mark Pearson Signed-off-by: Thorsten Blum Link: https://patch.msgid.link/20260818151635.37094-2-thorsten.blum@linux.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 9c28adde051fe76a7754856d0a414ab89adcaa4d Author: Thorsten Blum Date: Mon Aug 10 22:41:07 2026 +0200 platform/x86: think-lmi: Free system certificate signatures commit abca989604f60fe29d7170431f819e28ec7d868a upstream. Multi-certificate support also allows the system authentication object to store ->signature and ->save_signature, which leak when the driver is removed. Free the signatures to avoid leaking memory. Fixes: 5dcb5ef12590 ("platform/x86: think-lmi: Multi-certificate support") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Reviewed-by: Mark Pearson Link: https://patch.msgid.link/20260810204106.165895-2-thorsten.blum@linux.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 89a076948ed61dcbf555fa5ab93545902e257745 Author: Thorsten Blum Date: Mon Aug 10 14:05:57 2026 +0200 platform/x86: think-lmi: Fix certificate thumbprint sysfs output commit 4f3183f5ae9b8ddfe338d79a96146a05342bbe50 upstream. cert_thumbprint() already returns the accumulated output length, but certificate_thumbprint_show() adds that value to count again, making the next line use the wrong offset. Errors returned by cert_thumbprint() are also ignored and their negative values added to count. Assign the total length to count instead and propagate errors correctly. Fixes: b49f72e7f96d ("platform/x86: think-lmi: Certificate authentication support") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Reviewed-by: Mark Pearson Link: https://patch.msgid.link/20260810120556.149416-2-thorsten.blum@linux.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit d7cd3e4d7603482256710f1afa2668a50c7ec829 Author: Julian Haarmann Date: Sun Jun 14 22:30:26 2026 +0200 platform/x86: lenovo/ymc: Only match lower byte in WMI lid switch query response commit bbc497b5231829d32c3a53b6e66be1add76c0064 upstream. On newer Lenovo Yoga devices like the "Yoga 9 2-in-1 14IPH11 - Type 83SE", the hinge switch WMI query returns extra data in the upper bits (e.g. 0x50001 laptop mode, 0x50002 tablet mode, ect.). The driver previously checked for exact matches (0x01 laptop, 0x02 tablet, ect.) causing newer switches to not work. Mask the WMI query result to only match the lower byte and ignore upper bits. Signed-off-by: Julian Haarmann Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260614203235.235724-1-julian.haarmann@student.kit.edu Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit e1b3f89673bd1486efd793ca488ebe8e2f05e112 Author: Ma Ke Date: Wed Jun 24 09:49:09 2026 +0800 platform/x86: ishtp_eclite: Fix ACPI device reference leak in probe error path commit 62b57396c26a1ce54963709928ea0d01fa522eea upstream. ecl_ishtp_cl_probe() acquires a reference to an ACPI device via acpi_find_eclite_device() but fails to release it in the error path when acpi_opregion_init() fails. This results in a reference count leak, preventing proper cleanup of the ACPI device. Calling path: acpi_find_eclite_device() -> acpi_dev_get_first_match_dev() -> acpi_dev_get_next_match_dev() -> bus_find_device() -> get_device(). Found by code review. Signed-off-by: Ma Ke Acked-by: Srinivas Pandruvada Cc: stable@vger.kernel.org Fixes: 7b6bf51de974 ("platform/x86: Add Intel ishtp eclite driver") Link: https://patch.msgid.link/20260624014910.1226446-1-make_ruc2021@163.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit e07a42bb9c90901a1a91b815f612da1e67847ceb Author: Srinivas Pandruvada Date: Tue Aug 11 15:21:33 2026 -0700 platform/x86: ISST: Return error during profile addition commit f9a647cb8d90c09633a49a1e766e140e78012444 upstream. If sst_add_perf_profiles() fails for memory allocation, it continues to allow SST-CP (core-power) feature. But in practice this is not very useful as to achieve some frequencies via SST-CP, an SST-PP (perf-profile) level change is required. Fixes: 0ab147bb840f ("platform/x86: ISST: Parse SST MMIO and update instance") Cc: HyeongJun An Cc: stable@vger.kernel.org Signed-off-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260811222134.3912626-2-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 62840acc3044f0a4312781affdfc2a507266d6e7 Author: Srinivas Pandruvada Date: Tue Aug 11 15:15:12 2026 -0700 platform/x86: ISST: Validate parameter for frequency and priority commit 574b59bb4b6bfcfd1f639d02f1041b314d43a2e6 upstream. Validate range for frequency and proportional priority while setting CLOS parameters. Fixes: 12a7d2cb811d ("platform/x86: ISST: Add SST-CP support via TPMI") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260811221514.3905817-5-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 93268bc3cd84f2a483ea1743a2dbf6dd1c842d07 Author: Srinivas Pandruvada Date: Tue Aug 11 15:15:11 2026 -0700 platform/x86: ISST: Validate parameter for core power state commit 1700b4f804555467b7eff58dff7acc11d508b3a1 upstream. Allow only 0 or 1 for core_power enable and priority_type parameters. Fixes: 12a7d2cb811d ("platform/x86: ISST: Add SST-CP support via TPMI") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260811221514.3905817-4-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 5b032e1dda486ca41d10536bd195bd8a559af1e2 Author: Srinivas Pandruvada Date: Tue Aug 11 15:15:09 2026 -0700 platform/x86: ISST: Validate logical CPU id and clos id commit 124e2dbabe460c2a6e7440f4ad8af560131295c9 upstream. Validate max CLOS ID and logical CPU ID for core power feature. Reject any clos level or logical CPU number greater than the supported maximum. These are used to calculate MMIO offset. Fixes: 12a7d2cb811d ("platform/x86: ISST: Add SST-CP support via TPMI") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260811221514.3905817-2-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit b14db79d02bd38c16c95869b1676e28e08385e5f Author: Srinivas Pandruvada Date: Tue Aug 11 15:15:13 2026 -0700 platform/x86: ISST: Use PP level enable mask commit 9b9026943b19d06ebf520b1f4786621947cf43c8 upstream. Add check for enabled levels only when reading MMIO. Some levels can be disabled by BIOS. If the level is not enabled, return an error. Reset the enable and allowed level masks if there is a failure to add a perf level. Fixes: ea009e4769fa3 ("platform/x86: ISST: Add SST-PP support via TPMI") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260811221514.3905817-6-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 92c5fffa63ad9c86f982b49ebeb58f27edfae387 Author: Srinivas Pandruvada Date: Tue Aug 11 15:15:14 2026 -0700 platform/x86: ISST: Just allow 2 bits for SST feature enable commit 0f377f2b47646abe6ec3616ae6a8670d9ff7eb86 upstream. Currently only 2 features SST-TF and SST-BF are supported, so only allow bit 0 and bit 1. Fixes: ea009e4769fa3 ("platform/x86: ISST: Add SST-PP support via TPMI") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260811221514.3905817-7-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit c280fcd53b938b70c7dee9ce1a66b32bd6e5ebaa Author: Srinivas Pandruvada Date: Tue Aug 11 15:21:34 2026 -0700 platform/x86: ISST: Add a NULL check for sst_inst[] commit 3de2776e9d7073765c10c2326c2bda5926811ea6 upstream. To be consistent with other places, add a NULL check for failed socket loading by checking isst_common.sst_inst[]. Fixes: d805456c712f ("platform/x86: ISST: Enumerate TPMI SST and create framework") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260811222134.3912626-3-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 2550f89589caad7402d618d7dffc038582c94b6b Author: Fan Wu Date: Thu Jul 23 11:28:41 2026 +0000 mmc: via-sdmmc: stop card-detect handling on probe failure commit 088eaa92fcebaa6b957ccf9635afdf39643a577d upstream. request_irq() registers the SD card-detect interrupt and the probe enables it before mmc_add_host() runs. If mmc_add_host() fails, the error path only unmaps the registers and returns: the interrupt stays registered, so the handler keeps running against the host once it is freed. via_sdc_isr() dereferences sdhost and its MMIO base and schedules carddet_work, which via_sdc_card_detect() also runs against freed memory through its container_of() dereference. Add a probe-error path that disables and frees the interrupt and cancels carddet_work before unmapping. carddet_work can re-enable the device interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it again after cancelling the work. This issue was found by an in-house static analysis tool and confirmed by manual code review. Fixes: e4e46fb61e3b ("mmc: via-sdmmc: fix return value check of mmc_add_host()") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit f7ff3027ef004a331ef911a4886f12bc2e996037 Author: Fan Wu Date: Thu Jul 23 11:28:42 2026 +0000 mmc: via-sdmmc: cancel card-detect work on remove commit 57e5d877f898d5e5c9d672a77bb6bdd24f0d9bf5 upstream. Disabling the device interrupt and freeing the IRQ prevents new card-detect work from being queued, but carddet_work already queued by the handler can still run after via_sd_remove() returns. via_sdc_card_detect() recovers the host through container_of() and dereferences its MMIO base; once remove() returns the host can be freed, so that work would touch freed memory. Cancel carddet_work after freeing the IRQ and before cancelling finish_bh_work, which the card-detect handler can also queue. carddet_work can re-enable the interrupt through via_reset_pcictrl(); mask it again afterwards. This issue was found by an in-house static analysis tool and confirmed by manual code review. Fixes: f0bf7f61b840 ("mmc: Add new via-sdmmc host controller driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 82e707eff9e3b7ef6d96ecc23ea8876d20c7d6ca Author: HyeongJun An Date: Fri Aug 7 23:40:02 2026 +0900 platform/x86: ISST: Validate socket ID in clos_assoc ioctl commit a89f07db0cb95c54dac4a8406c79a04e44a73c3c upstream. isst_if_clos_assoc() validates the user-supplied socket_id with 'socket_id > topology_max_packages()', but isst_common.sst_inst[] is allocated with topology_max_packages() entries, so the valid index range is [0, topology_max_packages()). The '>' comparison lets socket_id == topology_max_packages() pass and index one entry past the array. In addition, isst_common.sst_inst[socket_id] is NULL for an in-range package that has no bound TPMI SST instance, and the pointer is used without a NULL check. Both the out-of-bounds entry and the NULL pointer are then dereferenced by map_partition_power_domain_id() and the following power_domain_info access. Reject socket_id >= topology_max_packages() and a NULL sst_inst, matching the checks already performed by get_instance(). Fixes: 12a7d2cb811d ("platform/x86: ISST: Add SST-CP support via TPMI") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Acked-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260807144003.3498972-2-sammiee5311@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 1889a9156553f0692acd57caf15e877baace1a01 Author: HyeongJun An Date: Fri Aug 7 23:40:03 2026 +0900 platform/x86: ISST: Validate level in perf mask ioctls commit 80e0d353c86a9a168ad6d213f494796294381538 upstream. isst_if_get_perf_level_mask() and isst_if_get_base_freq_mask() use the user-provided level as an index into perf_levels[] via _read_pp_level_info() and _read_bf_level_info(), but neither helper validates it first. The adjacent level-info helpers reject levels above max_level before reading the same per-level register block. Add the same bounds checks to the mask helpers, and reject disabled SST-PP levels in isst_if_get_perf_level_mask() to match isst_if_get_perf_level_info(). This prevents out-of-bounds reads from the per-level offset table on invalid ioctl input. Fixes: ea009e4769fa3 ("platform/x86: ISST: Add SST-PP support via TPMI") Fixes: 06a61df83209 ("platform/x86: ISST: Add SST-BF support via TPMI") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Acked-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260807144003.3498972-3-sammiee5311@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 22222f92b0a5116eb4aac4be81e7b770adfa32ee Author: HyeongJun An Date: Sun Jun 14 13:53:53 2026 +0900 platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer commit 83c80495e45eddf64c6525fb582d8db68f256b71 upstream. set_attribute() populates the security area of the BIOS attribute request buffer with the current admin password via populate_security_buffer(), then dumps the whole request buffer with print_hex_dump_bytes(). This can expose the plaintext admin password in the kernel log. The same issue was fixed for the password attribute path by commit d1a196e0a6dc ("platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data"). Remove the remaining dump from the BIOS attribute path. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260614045353.143500-1-sammiee5311@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit cab2895729516799384d48560e6fca105fb3f927 Author: Peiyang He Date: Tue Aug 11 17:55:51 2026 +0800 iommufd: Fix UAF in selftest IOPF reporting commit 8c07df7cdfcf52f1ff276c588612aabc6c6b8399 upstream. IOMMUFD selftest TRIGGER_IOPF borrows an attach handle from group->pasid_array without synchronizing against PASID detach, then a concurrent iommu_report_device_fault() can dereference that borrowed handle's domain pointer after the detach erases the handle and frees the backing struct iommufd_attach_handle. TRIGGER_IOPF then dereferences the freed handle, causing a UAF. Fix by adding a iopf_rwsem in mock_dev to follow the expected design of a real driver. Hold its read side across the whole iommu_report_device_fault() call, and its write side around every path that attaches, detaches, or replaces a device domain. This can block new reports and drains in-flight reports before an old attach handle or the IOPF fault parameter can be removed. Also take the write side while registering a mock device, since it can invoke the mock driver's default-domain attach callback. Closes: https://lore.kernel.org/all/D5E3AA41600B2056+f4e15662-bd2b-43ea-91cb-518de429e72c@smail.nju.edu.cn/ Fixes: ddee19971081 ("iommufd/selftest: Add IOPF support for mock device") Cc: stable@vger.kernel.org Suggested-by: Jason Gunthorpe Assisted-by: Codex:gpt-5.6-terra Signed-off-by: Peiyang He Link: https://patch.msgid.link/38C8DF0A118B7176+20260811095551.2756745-1-peiyang_he@smail.nju.edu.cn Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 4c33d00ad9a911e87ea222986f732ce072e3aa26 Author: Shuai Xue Date: Sun Jul 26 15:43:31 2026 +0800 iommufd: Release current IOAS on xa_store() failure commit 4ac2ce123824d5f885c868fa1f9f4d463141a2ba upstream. iommufd_take_all_iova_rwsem() takes an object reference and the iova_rwsem write lock before storing the IOAS in the temporary ioas_list xarray. If xa_store() fails, the current IOAS has not been inserted into ioas_list yet. iommufd_release_all_iova_rwsem() only unwinds IOAS objects already present in that xarray, so it cannot release the current IOAS. Release the current IOAS rwsem and object reference before unwinding the previously stored entries. Fixes: 051ae5aa73d7 ("iommufd: Lock all IOAS objects") Cc: stable@vger.kernel.org Assisted-by: Qoder:Qwen-3.8-MAX-Preview Signed-off-by: Shuai Xue Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 436189ee4bb2c7c993b945d68570dd38c3e4349e Author: Shuai Xue Date: Sun Jul 26 15:43:30 2026 +0800 iommufd: Avoid locking internal accesses during unmap commit 0dbcdf4473a614adbd732d567c9b39ac0e040e0c upstream. iommufd_access_notify_unmap() skips internal accesses because they do not have an external unmap callback to invoke. However, the current test calls iommufd_lock_obj() before checking whether the access is internal. If iommufd_lock_obj() succeeds, the loop then sees the internal access and continues, bypassing the matching iommufd_put_object() used by the normal unmap path. This leaks the object reference taken by iommufd_lock_obj(). Check for internal accesses first so skipped entries are never locked. Fixes: 27b77ea5feaa ("iommufd/access: Bypass access->ops->unmap for internal use") Cc: stable@vger.kernel.org Assisted-by: Qoder:Qwen-3.8-MAX-Preview Signed-off-by: Shuai Xue Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 45705a6bfdb283f7b3b509010fd617b72f942537 Author: Kevin Tian Date: Wed Aug 5 07:43:00 2026 +0800 iommu/vt-d: Force requesting ACS when tboot is enabled commit 607432b2618b61df81134be0ef2562b8300c1216 upstream. Currently the conditions of requesting ACS in detect_intel_iommu() don't include tboot, leading to a possible misconfiguration with ACS disabled (e.g. due to user opts) while iommu is later forced on by tboot_force_iommu(). Fix it by checking tboot in detect_intel_iommu(). Fixes: 5d990b627537 ("PCI: add pci_request_acs") Cc: stable@vger.kernel.org Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 364279b5623f75333f89de219e435ce53b45c390 Author: Kevin Tian Date: Wed Aug 5 07:42:59 2026 +0800 iommu/vt-d: Fix no_iommu to disable platform opt-in commit 219cc978d69ce9b538d0d73936c569d4ca5b0a24 upstream. If user explicitly requests to disable iommu (via "iommu=off" or "intel_iommu=off"), there is no reason to force enabling it due to platform opt-in (for external-facing devices). User should be aware of any security implication of doing so. "intel_iommu=off" implements this policy by setting no_platform_optin to skip platform opt-in in platform_optin_force_iommu(). However, "iommu=off" (no_iommu=1) doesn't set no_platform_optin hence is broken in this aspect: - detect_intel_iommu() doesn't request ACS if no_iommu=1 - platform_optin_force_iommu() forces iommu on if external-facing devices exist and no_platform_optin is not set This leads to a bad configuration with ACS disabled while DMA remapping is enabled. Instead of setting no_platform_optin (will soon be removed) for no_iommu=1, directly check no_iommu in platform_optin_force_iommu(). Fixes: 89a6079df791 ("iommu/vt-d: Force IOMMU on for platform opt in hint") Cc: stable@vger.kernel.org Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit f80f3acb69164800051ecdee871b6b006cbc2e66 Author: Peiyang He Date: Sat Jul 11 13:51:19 2026 +0800 iommu: Fix dev_iommu memory leak when device_add fails in iommu_mock_device_add commit b7b0b3851474883d4aba6ed72da87141204b23e5 upstream. iommu_mock_device_add() first calls iommu_fwspec_init(), which on success allocates both dev->iommu (via dev_iommu_get()) and dev->iommu->fwspec. If the subsequent device_add(dev) call fails, the error path only calls iommu_fwspec_free(dev), which frees fwspec but leaves dev->iommu still allocated. This triggers the following kmemleak report when fuzzing with Syzkaller: BUG: memory leak unreferenced object 0xffff888011e0a200 (size 192): comm "syz.1.1695", pid 24885, jiffies 4295222527 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .............N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff ................ backtrace (crc 25df5bb3): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4575 [inline] slab_alloc_node mm/slub.c:4899 [inline] __kmalloc_cache_noprof+0x47a/0x710 mm/slub.c:5415 kmalloc_noprof include/linux/slab.h:950 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] dev_iommu_get+0x10c/0x1a0 drivers/iommu/iommu.c:408 iommu_fwspec_init+0x288/0x4d0 drivers/iommu/iommu.c:3087 iommu_mock_device_add+0x46/0xb0 drivers/iommu/iommu.c:385 mock_dev_create drivers/iommu/iommufd/selftest.c:1025 [inline] iommufd_test_mock_domain drivers/iommu/iommufd/selftest.c:1066 [inline] iommufd_test+0x2f8a/0x6190 drivers/iommu/iommufd/selftest.c:2072 iommufd_fops_ioctl+0x367/0x540 drivers/iommu/iommufd/main.c:533 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by calling dev_iommu_free(dev) instead of iommu_fwspec_free(dev) in the device_add() failure path. dev_iommu_free() frees both fwspec and the outer dev_iommu struct and clears dev->iommu. Link: https://patch.msgid.link/r/76AC62D46B998556+20260711055119.1003477-1-peiyang_he@smail.nju.edu.cn Reported-by: Peiyang He Fixes: 2a918911ed3d ("iommufd: Register iommufd mock devices with fwspec") Cc: stable@vger.kernel.org Signed-off-by: Peiyang He Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 2235eafda9b3df9295efd0593cd4a8977440c3f6 Author: Shameer Kolothum Date: Mon Jun 29 10:41:05 2026 +0100 iommu/arm-smmu-v3: Manage teardown with devm commit 2bd22a0d40503a65d243b011de146603c8ce1cbc upstream. arm_smmu_device_remove() manually frees the IOPF queue, destroys the vmid_map and disables the device, while the IRQs and queues are devm managed. devm unwinds only after remove() returns, so the cleanup runs in the wrong order. The IOPF queue is freed before the event-queue IRQ whose handler uses it. Manage all of it with devm so the unwind order is correct. Free the IOPF queue and vmid_map via devm actions, and disable the device from one registered after arm_smmu_device_reset(). This is also a prerequisite for fixing a Tegra241 CMDQV CMD_SYNC use-after-free in the subsequent patch. Cc: stable@vger.kernel.org Suggested-by: Jason Gunthorpe Reviewed-by: Nicolin Chen Signed-off-by: Shameer Kolothum Reviewed-by: Jason Gunthorpe Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit d903d99ffd22b0180bd745a43f221c21bcdd8d7c Author: Nicolin Chen Date: Tue Jul 14 13:55:04 2026 -0700 iommu/tegra241-cmdqv: Reject a vSID wider than the SID_MATCH field commit 4379610c79bd88ddbea10e7f6c21e16d4b338c6b upstream. tegra241_vintf_init_vsid() programs the guest-provided vSID into SID_MATCH, whose VIRT_SID field spans bits [20:1] with bit 0 as the match-enable flag. The HW therefore matches only a 20-bit Stream ID. The bound check rejects only virt_sid > UINT_MAX, which admits a value far wider than the field. The write "virt_sid << 1 | 0x1" then drops every bit above 20: a virt_sid of 0x80000000 lands as SID_MATCH = 0x1, a valid match on vSID 0, so the entry aliases the wrong Stream ID. Because vdev->virt_id is guest-controlled, a VMM can trigger it. Validate virt_sid against the field width with FIELD_MAX(), and program the register with FIELD_PREP() so the value and the field stay consistent. Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 968e9a1f71140c86dc4092f6b361e997923f3813 Author: Shuai Xue Date: Sun Jul 26 15:43:29 2026 +0800 iommu/sva: Set handle->dev before the SVA handle is visible commit 530f8f9c3546cb3ebee1b135375aaee08a073ebb upstream. iommu_attach_device_pasid() installs the new SVA attach handle in the group PASID lookup before iommu_sva_bind_device() returns. A concurrent bind can therefore find and reuse the same handle after iommu_sva_lock is dropped. handle->dev was initialized after dropping iommu_sva_lock. This leaves a window where a racing bind can return a handle whose dev pointer is still NULL. A subsequent iommu_sva_unbind_device() can then dereference it via handle->dev->iommu_group. Initialize handle->dev before releasing iommu_sva_lock so any visible SVA handle is fully initialized. Fixes: be51b1d6bbff ("iommu/sva: Refactoring iommu_sva_bind/unbind_device()") Cc: stable@vger.kernel.org Assisted-by: Qoder:Qwen-3.8-MAX-Preview Signed-off-by: Shuai Xue Reviewed-by: Lu Baolu Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit f532401be9312ecd166f616bb74a65b0b4c150fa Author: Weimin Xiong Date: Thu Jul 16 09:32:29 2026 +0800 iommu/msm: Unwind probe state on registration failure commit 535a200220ca2c83bc8bf54bd2cbe045d6ee70c4 upstream. msm_iommu_probe() adds its devm-managed IOMMU object to qcom_iommu_devices before adding the IOMMU sysfs device and registering it with the IOMMU core. If iommu_device_sysfs_add() fails, probe returns with the object still on qcom_iommu_devices. The driver core then releases the devm allocation, leaving a dangling list entry that later list walks may dereference. If iommu_device_register() fails, the same dangling list entry remains and the sysfs device is left registered as well. Unwind the sysfs device and global list entry in reverse setup order on the corresponding failure paths. Fixes: 42df43b36163 ("iommu/msm: Make use of iommu_device_register interface") Cc: stable@vger.kernel.org Reviewed-by: Mukesh Ojha Signed-off-by: Weimin Xiong Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit cfc5c1b2caa176dfd40b873a6ff07b11da34cc3e Author: Shuai Xue Date: Mon Jul 27 11:02:12 2026 +0800 iommu/amd: Put PCI device after handling PPR faults commit af3b69b16383fbc8fe5f61b5b0150d2e41ede71f upstream. iommu_call_iopf_notifier() looks up the requester with pci_get_domain_bus_and_slot(), which returns a PCI device with its reference count incremented. Neither the successful iommu_report_device_fault() path nor the abort path drops that reference, so every handled PPR request leaks a PCI device reference. This is the same ownership rule that was fixed for the old iommu_v2 ppr_notifier() path by commit 6cf0981c2233 ("iommu/amd: Fix pci device refcount leak in ppr_notifier()"), but iommu_call_iopf_notifier() was added later as a separate PPR/IOPF notifier path. Drop the PCI device reference after handling the PPR entry. Fixes: 978d626b8f1a ("iommu/amd: Add IO page fault notifier handler") Cc: stable@vger.kernel.org Assisted-by: Qoder:Qwen-3.8-MAX-Preview Signed-off-by: Shuai Xue Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 238e1f7a1463f7e43fff59be5e46e884850846f8 Author: Krzysztof Wilczyński Date: Wed Jul 29 07:54:13 2026 +0000 PCI/proc: Warn on writes to kernel-exclusive config space regions commit 3359e044d597dd5344f17613e4be6b6e12067f60 upstream. Currently, a driver can claim a region of a device's config space as exclusive using pci_request_config_region_exclusive(), after which a write to that region originating from user space is expected to emit a warning and taint the kernel. The check is advisory only, as the write itself is still allowed to proceed. Since commit 278294798ac9 ("PCI: Allow drivers to request exclusive config regions"), the sysfs config space attribute performs this check in pci_write_config(), but the procfs interface was never updated. A write performed through /proc/bus/pci/BB/DD.F therefore bypasses the detection entirely, even though both interfaces offer the same level of access. Add the same resource_is_exclusive() check to proc_bus_pci_write(). Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260729075413.1215821-1-kwilczynski@kernel.org Signed-off-by: Greg Kroah-Hartman commit c2d4174f492458ecdcdef309243624999612d526 Author: Krzysztof Wilczyński Date: Mon Jul 20 20:41:45 2026 +0000 PCI/proc: Use file_ns_capable() when checking config space read access commit f82f53e75eff382fc8f56b73279b54f7cf5a5c65 upstream. proc_bus_pci_read() decides how much of the config space is readable based on capable(CAP_SYS_ADMIN), which checks the credentials of the task calling read(), not the credentials of the process that opened the file. The sysfs equivalent, pci_read_config(), has checked the credentials of the opening process since commit de139a339395 ("pci: check caps from sysfs file open to read device dependent config space"), so a privileged process can open the config space file and pass the file descriptor to an unprivileged process (for example, a process running a KVM guest with an assigned device), which can then read the entire config space. The check was subsequently routed through the LSM framework in commit 47970b1b2aa6 ("pci: use security_capable() when checking capablities during config space read") and converted to the dedicated helper in commit ab0fa82b2df9 ("pci-sysfs: use proper file capability helper function"). Thus, the two interfaces check the same capability against different credentials. Checking the credentials of the task calling read() makes the outcome depend on who reads rather than who opened, so the restriction is bypassed whenever a more privileged process reads through the descriptor. Checking the credentials recorded in file->f_cred settles the decision at open() time and ties it to the file, where it cannot change with the caller. Use file_ns_capable() to check CAP_SYS_ADMIN against the credentials in effect when the file was opened, bringing the procfs interface in line with the sysfs behaviour. As a result, a file descriptor opened by a privileged process and passed to an unprivileged one now allows the entire config space to be read through procfs, matching sysfs. Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260720204145.1500105-1-kwilczynski@kernel.org Signed-off-by: Greg Kroah-Hartman commit 301288f85679aa76f6307d0fe2c0cb31baebc0f6 Author: Krzysztof Wilczyński Date: Wed Jul 29 07:59:09 2026 +0000 PCI/proc: Avoid spurious runtime PM wakeup on config space accesses commit 4ff664a81d729b37f2eb65de80a670abfb61c9a0 upstream. Currently, proc_bus_pci_read() and proc_bus_pci_write() do not return early for zero-length configuration space accesses at valid offsets. Such an access invokes pci_config_pm_runtime_get() and pci_config_pm_runtime_put() around transfer blocks that do nothing. This is a problem because pci_config_pm_runtime_get() synchronously resumes the upstream bridge through pm_runtime_get_sync(), and resumes the device itself through pm_runtime_resume() when it is in D3cold, only for the handler to return zero immediately afterwards. Such a spurious wakeup wastes power and adds needless resume latency. The sysfs core already returns early for in-range zero-length binary attribute accesses before pci_read_config() or pci_write_config() is invoked. In contrast, the VFS forwards zero-length requests to the procfs callbacks, where they continue into runtime PM handling. Return early from proc_bus_pci_read() and proc_bus_pci_write() when nbytes is zero, before any runtime PM involvement. The value returned to userspace at these offsets remains zero, so the change is not visible to userspace. Signed-off-by: Krzysztof Wilczyński [bhelgaas: order tags] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260729075909.1219906-1-kwilczynski@kernel.org Signed-off-by: Greg Kroah-Hartman commit b30713111325eb192415c4aa8968833e5d3c753a Author: Farhan Ali Date: Wed Aug 5 09:55:18 2026 -0700 PCI/MSI: Enable memory decoding before restoring MSI-X messages commit 231c7a57d19304beb0931e6cbe3a4929daf49747 upstream. The current MSI-X restoration path assumes the Command register Memory bit is enabled when writing MSI-X messages. But it's possible the last saved and restored state of a device may not have the Memory bit enabled, even if a device driver later enables Memory bit and MSI-X. Attempting to access Memory space without Memory bit enabled can lead to Unsupported Request (UR) from the device. Fix this by enabling Memory bit and restore it afterwards. Fixes: 41017f0cac92 ("[PATCH] PCI: MSI(X) save/restore for suspend/resume") Signed-off-by: Farhan Ali [bhelgaas: comment] Signed-off-by: Bjorn Helgaas Reviewed-by: Thomas Gleixner Reviewed-by: Niklas Schnelle Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260805165518.794-6-alifm@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 0e59a232aaa04f92367a242174d12ef12a0bf8db Author: Max Lee Date: Tue Jul 7 10:15:27 2026 +0800 PCI/ASPM: Avoid L0s for Realtek RTS525A commit ec3d987fcaf92516d13ee18c305c82281557046d upstream. The Realtek RTS525A PCIe card reader reports an AER Correctable Replay Timer Timeout storm when ASPM L0s is enabled on its link. On an affected HP ZBook Power 16 inch G11, the Root Port received tens of millions of AER interrupts from the RTS525A even when the rtsx_pci driver was blacklisted and the endpoint was not enabled by a driver. For example: pcieport 0000:00:1c.6: AER: Multiple Correctable error message received from 0000:58:00.0 rtsx_pci 0000:58:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID) rtsx_pci 0000:58:00.0: device [10ec:525a] error status/mask=00001000/00006000 rtsx_pci 0000:58:00.0: [12] Timeout pcieport 0000:00:1c.6: AER: Correctable error message received from 0000:58:00.0 Testing with OS-native AER control showed that disabling only L0s on the RTS525A link stops new AER interrupt and counter growth while leaving L1 enabled. Disabling L1, L1 substates, or Clock PM alone did not stop the storm. Prevent the broken L0s configuration by removing L0s from the RTS525A advertised ASPM capability. This avoids enabling the non-working ASPM state instead of masking the resulting AER Replay Timer Timeout reports. Signed-off-by: Max Lee Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Reviewed-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260707021527.639611-1-max.lee@canonical.com Signed-off-by: Greg Kroah-Hartman commit 39c4dc79d77f8754c332a0d4ab4d58c36990d91b Author: Lukas Wunner Date: Fri Jul 24 17:24:01 2026 +0200 PCI/AER: Fix mapping of errors to agent & layer commit 1017599755b8b578a671f8fac175bce56189d01c upstream. PCIe r7.0 sec 6.2.7 documents the agent and layer of each Correctable and Uncorrectable Error. Based on this spec section, the AER driver maps detected errors to an agent and layer using a set of macros and logs them. Most errors listed in sec 6.2.7 map to the "Receiver" agent and "Transaction Layer", so the macros use these as defaults unless an error maps to something else. However the macros have not been amended since their introduction in 2006 with commit 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver"). They are still based on PCIe r1.0 sec 7.2.5 (renumbered to 6.2.7 in PCIe r1.1 and newer). Amend the macros to map errors introduced since then to the appropriate agent and layer. PCIe r2.1 introduced a new "Component" agent and "General" layer for Internal Errors and Header Log Overflow. Add them to the macros. Unsupported Request is currently mapped to the "Requester" agent, even though it is reported by the "Receiver". Fix the incorrect mapping. Sec 6.2.7 neglects to list an agent for Data Link Protocol Error and Surprise Down Error. Map the latter to "Component" because PCIe r7.0 sec 3.2.1 states that the error is "associated with the detecting Port". Map the former to "Receiver" because every occurrence of Data Link Protocol Error in the spec refers to it being logged in the Receiving Port. I have had these errata reported to the PCI-SIG Protocol Working Group. (There's also a layout erratum in the REPLAY_NUM Rollover row wherein columns are shifted to the left, but that's already corrected in the PCIe r7.1 draft as of 2026-04-07.) Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/aec4820a75e949b332585a08cb1808fda7f40ea4.1784905909.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit 4f887d8ed75f8fa4b618e9eaaa0605071c3f776c Author: Lukas Wunner Date: Fri Jul 24 17:24:04 2026 +0200 PCI/AER: Emit TLP Log only for unmasked errors commit a8bf2dd750de7d682fdaa2127f4e3217ce9c4a82 upstream. Per PCIe r7.0 sec 6.2.5, the prefix and header of an offending TLP is only recorded for unmasked Uncorrectable Errors. Yet when the AER driver determines whether a prefix and header has been logged, it does not take the Uncorrectable Error Mask Register into account. Fix it. Fixes: 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver") Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v2.6.19+ Link: https://patch.msgid.link/2e712b96ba5bfc729d78bfc23f7fb7d285aa3d6d.1784905909.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit 6beadccc432cf50cfb16bc061109c03b2dcb2654 Author: Krzysztof Wilczyński Date: Mon Jul 20 20:43:56 2026 +0000 PCI/sysfs: Avoid spurious runtime PM wakeup on config space accesses commit b14b2bab88d7099ab4447560cbe4b40945e5c069 upstream. Currently, the boundary checks in pci_read_config() and pci_write_config() reject only offsets beyond the effective configuration space size. An access at an offset exactly equal to that size passes the check, has its length clamped to zero, and then invokes pci_config_pm_runtime_get() and pci_config_pm_runtime_put() around transfer blocks that do nothing. This is a problem because pci_config_pm_runtime_get() synchronously resumes the upstream bridge through pm_runtime_get_sync() and resumes the device itself through pm_runtime_resume() when it is in D3cold, only for the handler to return zero immediately afterwards. Such a spurious wakeup wastes power and adds needless resume latency. The sysfs core already clamps accesses against the attribute size set through the bin_size() callback, which reports either 256 or 4096 bytes. As such, the affected accesses are reads at offset 64 (or 128 for CardBus devices) through files opened without CAP_SYS_ADMIN, and reads and writes at the exact configuration space size on devices where a quirk sets a non-standard size. Reject accesses at the boundary offset as well, so they return early before any runtime PM involvement, matching the procfs implementations in proc_bus_pci_read() and proc_bus_pci_write(). The value returned to userspace at these offsets remains zero, so the change is not visible to userspace. Signed-off-by: Krzysztof Wilczyński [bhelgaas: tweak commit log, order tags] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260720204356.1501749-1-kwilczynski@kernel.org Signed-off-by: Greg Kroah-Hartman commit 7f4db64f0ba7bd6701440baa1d88d58614d5b72c Author: Krzysztof Wilczyński Date: Tue Jun 16 16:31:31 2026 +0000 PCI/sysfs: Fix read byte order in pci_read_legacy_io() commit 5b95212de6dcd7e0275cea7f894fe7226c7d9f29 upstream. pci_read_legacy_io() passes the sysfs buffer directly to pci_legacy_read(): return pci_legacy_read(bus, off, (u32 *)buf, count); The PowerPC implementation stores the result as a native-endian integer: *((u16 *)val) = in_le16(addr); On big-endian PowerPC this stores the bytes in the wrong order, so a 2-byte read of a device register returns different bytes than two 1-byte reads at the same addresses. The same applies to 4-byte reads. On little-endian the native byte order already matches PCI I/O port byte order, so the conversion is a no-op. Thus, let pci_legacy_read() store into a local u32 variable, then copy the I/O port value to the sysfs buffer using put_unaligned_le16() and put_unaligned_le32() for the 2 and 4 byte cases, converting from the native integer to little-endian byte order matching PCI I/O port space. No changes are needed for the Alpha platform. The legacy_io file is root-only and exists only on Alpha and PowerPC, the two architectures that define HAVE_PCI_LEGACY. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260616163131.2763281-2-kwilczynski@kernel.org Signed-off-by: Krzysztof Wilczyński Signed-off-by: Greg Kroah-Hartman commit 43cf455dd5a9b04625cd93cc25764b2ae9a1f0a7 Author: Tim Harvey Date: Mon Jul 20 14:57:18 2026 -0700 PCI: Add ACS quirk for Pericom PI7C9X2G608 switches [12d8:2608] commit 062fb7f816439da6bf3860386889343482a66bd4 upstream. The Pericom PI7C9X2G608 6-port Gen2 PCIe switch is also affected by the PI7C9X2G errata per the errata document: E2: ACS P2P Request Redirect Is Not Functional Apply the same quirk to this PCI ID as well to apply the workaround required if using ACS. Fixes: acd61ffb2f16 ("PCI: Add ACS quirk for Pericom PI7C9X2G switches") Signed-off-by: Tim Harvey Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260720215718.2139510-1-tharvey@gateworks.com Signed-off-by: Greg Kroah-Hartman commit 4b575052ea65423693726a21826d783cf3f1745e Author: Ali Tariq Date: Thu Jul 23 19:28:24 2026 +0500 PCI: plda: Fix IRQ domain leaks in the error paths of plda_init_interrupts() commit 19a30bbb6477bfd7e3109b7a2943e6597ee9de37 upstream. plda_init_interrupts() initializes IRQ domains and creates IRQ mapping but does not unwind them when later step fails. If platform_get_irq() or either irq_create_mapping() fails in plda_init_interrupts(), the domains are never deinitialized. If irq_create_mapping() fails, port->intx_irq stays initialized. Hence, remove the IRQ domains in the error path by calling plda_pcie_irq_domain_deinit(). Since plda_pcie_irq_domain_deinit() now disposes of the intx_irq and msi_irq mappings itself before removing their domains, the msi_irq mapping failure path can go directly to err_irq_domain_deinit instead of disposing of port->intx_irq separately first. This issue was found by automated review of sashiko-bot Fixes: 4602c370bdf6 ("PCI: microchip: Move IRQ functions to pcie-plda-host.c") Fixes: 76c911396807 ("PCI: plda: Add host init/deinit and map bus functions") Closes: https://lore.kernel.org/linux-pci/20260718120701.DF4111F000E9@smtp.kernel.org/ Signed-off-by: Ali Tariq [mani: commit log] Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260723142824.726655-1-alitariq45892@gmail.com Signed-off-by: Greg Kroah-Hartman commit 01c2f0c66bd1f892db9c6e82976da6b463cc4427 Author: Ali Tariq Date: Thu Jul 23 19:04:33 2026 +0500 PCI: plda: Fix use-after-free of event IRQs during teardown commit 26b73bae01d6eb81a4a38f36101812f20b2639de upstream. plda_pcie_irq_domain_deinit() removes pcie->event_domain via irq_domain_remove(), but the per-event IRQs mapped from that domain are requested with devm_request_irq() in plda_init_interrupts(). The actual free_irq() for a devm-managed IRQ is deferred by devres until after the calling probe()/remove() function returns. This means irq_domain_remove() can free the domain's internal data before the deferred free_irq() for IRQs still mapped into it has run. When devres later processes that deferred cleanup, it can end up dereferencing the already-freed domain. Free each event IRQ explicitly with devm_free_irq() before removing the domain. This triggers the free immediately and removes the IRQ from the devres tracking list, so devres will not attempt to free it a second time later. Also dispose of the event, INTx, and MSI IRQ mappings with irq_dispose_mapping() before their owning domains are removed. Finally, guard the calls to irq_set_chained_handler_and_data() for pcie->irq, pcie->msi_irq, and pcie->intx_irq so they only run when those fields hold a valid (>0) IRQ number. This is a pre-existing issue, flagged by automated review during work on an earlier, unrelated patch to this driver. Build-tested and boot-tested on StarFive VisionFive v1.2A board Fixes: 76c911396807 ("PCI: plda: Add host init/deinit and map bus functions") Closes: https://lore.kernel.org/linux-pci/20260714115343.4D49E1F000E9@smtp.kernel.org/ Signed-off-by: Ali Tariq Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260723140434.675512-2-alitariq45892@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5d4bc470330a61ae21cf75feebd1e3ab0dd710e7 Author: Ronald Claveau Date: Tue Jun 16 09:07:25 2026 +0200 PCI: meson: Fix GPIO state while requesting PERST# commit 40fb390cbcc11797c44c16dabdf763ec87643671 upstream. Meson devicetree defines the PERST# GPIO as 'reset' GPIO. Commit 4d3186a525b3 ("PCI: amlogic: Fix reset assertion via gpio descriptor") inverted the PERST# assertion logic to use proper GPIO descriptor semantics and moved the polarity configuration to the device tree as GPIO_ACTIVE_LOW. However, the initial PERST# GPIO state "GPIOD_OUT_LOW" was not updated accordingly. This results in the enumeration failure of the endpoint devices as PERST# would get deasserted while requesting the GPIO even before power and REFCLK becomes stable. Without this fix: ahci 0000:01:00.0: enabling device (0000 -> 0002) ahci 0000:01:00.0: SSS flag set, parallel bus scan disabled ahci 0000:01:00.0: Controller reset failed (0xffffffff) ahci 0000:01:00.0: probe with driver ahci failed with error -5 With this fix: ahci 0000:01:00.0: enabling device (0000 -> 0002) ahci 0000:01:00.0: AHCI vers 0001.0300, 32 command slots, 6 Gbps, SATA mode ahci 0000:01:00.0: 1/1 ports implemented (port mask 0x1) ahci 0000:01:00.0: flags: 64bit ncq led clo only pio ccc Change the GPIO request flag from GPIOD_OUT_LOW to GPIOD_OUT_HIGH to get the right behaviour. Fixes: 4d3186a525b3 ("PCI: amlogic: Fix reset assertion via gpio descriptor") Signed-off-by: Ronald Claveau [mani: CCed stable and commit log] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Neil Armstrong Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260616-fix-meson-pcie-reset-gpio-v1-1-fca404b4c8be@aliel.fr Signed-off-by: Greg Kroah-Hartman commit 1ad699485385383fb66b711d95469dee57e751ad Author: Mohamad Raizudeen Date: Thu Jul 23 22:42:03 2026 +0530 PCI: Fix 32-bit config write in Intel PCH Root Port MPC ACS quirk commit 23d7eed5974989de56273c964d7e510e4aad91e8 upstream. pci_quirk_enable_intel_rp_mpc_acs() reads a 32-bit DWORD from the MPC register, sets bit 26 (INTEL_MPC_REG_IRBNCE), but it writes it back using pci_write_config_word(). Because bit 26 resides in the upper 16 bits of the 32-bit register, a 16-bit write drops the newly set bit. The quirk logs that it is enabling IRBNCE, but the hardware never actually receives the command. Use pci_write_config_dword() to ensure the full 32-bit value is written back to the hardware. Fixes: d99321b63b1f ("PCI: Enable quirks for PCIe ACS on Intel PCH root ports") Signed-off-by: Mohamad Raizudeen Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260723171203.4892-1-raizudeen.kerneldev@gmail.com Signed-off-by: Greg Kroah-Hartman commit 6053d6eacbfd2aa1aef47e8e6118e78585206f86 Author: Naman Jain Date: Mon Aug 10 09:07:13 2026 +0000 PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip commit 86bdd16e8f390d51bae9e77a4bc4164ca2f580fe upstream. The Hyper-V vPCI MSI irqchip never installs an irq_retrigger() callback. On CPU hot-unplug fixup_irqs() migrates the interrupts which are affine to the outgoing CPU to a new target. If an interrupt still has its pending bit set in the outgoing CPU's IRR at that point, fixup_irqs() resends it on the new target through the irqchip's irq_retrigger() callback. As the Hyper-V PCI/MSI chip does not provide that callback, the pending interrupt is silently dropped, which can result in lost interrupts, stalls and "No irq handler for vector" messages during CPU hotplug. Install irq_chip_retrigger_hierarchy() as the irq_retrigger() callback for the Hyper-V PCI/MSI irqchip, so that a pending interrupt is resent on its new target CPU via the parent x86 vector domain. Fixes: 4daace0d8ce85 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Cc: stable@vger.kernel.org Suggested-by: Long Li Suggested-by: Thomas Gleixner Reviewed-by: Aditya Garg Reviewed-by: Shradha Gupta Signed-off-by: Naman Jain Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit ceafb262475ac6cb3a7d07b1102608be2b216b99 Author: Stefan Haberland Date: Wed Aug 5 13:15:55 2026 +0200 s390/dasd: Propagate partial completion length across ERP recovery commit 6fb5ba2e7e43173a3761e46f091070a8185efa14 upstream. dasd_default_erp_postaction() copies the timing and device state from the finished ERP request back to the original request but drops proc_bytes. A request that was partially completed, an ESE read of a not-yet-allocated track returns fewer bytes than requested, and then recovered through the ERP chain loses its partial-completion length. __dasd_cleanup_cqr() then sees proc_bytes == 0 and completes the whole request instead of requeueing the remainder, silently returning zeroed data for the part that was never read. Carry proc_bytes over to the original request like the other per-request state. Fixes: 5e6bdd37c552 ("s390/dasd: fix data corruption for thin provisioned devices") Cc: stable@vger.kernel.org Reviewed-by: Jan Höppner Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260805111612.1285190-3-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 6452c13646af7c13d7f6668b6690cfb2427e7f7b Author: Stefan Haberland Date: Wed Aug 5 13:15:56 2026 +0200 s390/dasd: Guard sysfs discipline callbacks against unallocated private data commit 2a1780f9fc2493bd34c418a0be6fc58943afcecf upstream. Several sysfs show/store handlers call a discipline callback that dereferences device->private, either directly or through the DASD_DEFINE_ATTR() macro. During dasd_generic_set_online() the discipline is assigned before check_device() allocates device->private, so an unprivileged read of one of these world-readable attributes in that window dereferences a NULL pointer and panics. Guard the dereference inside each callback that actually touches device->private. Fixes: c729696bcf8b ("s390/dasd: Recognise data for ESE volumes") Cc: stable@vger.kernel.org Reviewed-by: Jan Höppner Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260805111612.1285190-4-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 52b331c99baac653ca794bd8487c8ec4de8db203 Author: Stefan Haberland Date: Wed Aug 5 13:15:54 2026 +0200 s390/dasd: Do not complete a failed ESE read as successful commit cddb447c62466f3076938ce120028d7b591f9f37 upstream. dasd_int_handler() completes an NRF read of an unallocated ESE track by calling ese_read() and unconditionally marking the request DASD_CQR_SUCCESS. dasd_eckd_ese_read() can return an error before it has zeroed the destination buffer: a failed sense-data parse or a current track outside the requested range both return early, leaving the destination pages untouched. The request is still completed successfully, so the block layer is handed stale / uninitialized memory instead of zeros. Check the ese_read() return value and fail the request through the normal error path instead of forcing DASD_CQR_SUCCESS. Fixes: 5e6bdd37c552 ("s390/dasd: fix data corruption for thin provisioned devices") Cc: stable@vger.kernel.org Reviewed-by: Jan Höppner Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260805111612.1285190-2-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit dcce7a06ea690d5cf46a705a9b74cf0398ac091f Author: Thomas Richter Date: Tue Aug 11 15:39:01 2026 +0200 s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks commit 337bd95507a16063687cfc286ea90de5cca48c37 upstream. The command 'perf stat -e cycles -- ' crashes the kernel when CPUs are hotplug added during that run. Root cause is the allocation of struct cpu_cf_events at first event initialization. The allocation is dynamic and the first event that has task context creates such a structure for each online CPU. This is not sufficient. CPUs may be offline during event creation and can be set online during the perf run time. For example commands # echo 0 > /sys/devices/system/cpu/cpu1/online # perf stat -e cycles -i -- stress-ng -t10s --matrix X # sleep 1 # echo 1 > /sys/devices/system/cpu/cpu1/online create an event for CPUs 0,2-X. Since the events are created with task-context, the scheduler will eventually schedule the program on CPU1. This CPU has not created and initialized any per CPU event infrastructure as that CPU was not online at the time of the perf invocation. Thus when the scheduler runs stress-ng on CPU1, the function cpumf_pmu_add() refers to a NULL pointer: struct cpu_cf_events *cpuhw = this_cpu_cfhw(); This function call is invoked after the task stress-ng has been made runnable on CPU1. And this_cpu_cfhw() returns NULL. The result is a panic: Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000000000000 TEID: 0000000000000483 .... Krnl PSW : 0404d00180000000 000003ef8291fd0c (cpumf_pmu_add+0x3c/0x80) .... Call Trace: [<000003ef8291fd0c>] cpumf_pmu_add+0x3c/0x80 [<000003ef82bb5e3e>] event_sched_in+0xae/0x190 [<000003ef82bb60d6>] merge_sched_in+0x1b6/0x390 [<000003ef82bb65b8>] visit_groups_merge.constprop.0.isra.0+0x308/0x5b0 [<000003ef82bb689a>] pmu_groups_sched_in+0x3a/0x50 [<000003ef82bb6a30>] ctx_sched_in+0x180/0x260 [<000003ef82bb780c>] perf_event_context_sched_in+0x11c/0x2d0 [<000003ef82bb79ee>] __perf_event_task_sched_in+0x2e/0xc0 [<000003ef82994834>] finish_task_switch.isra.0+0x1a4/0x250 .... Last Breaking-Event-Address: [<000003ef8291f1d8>] this_cpu_cfhw+0x38/0x40 The issue arises only in per-task context when the CPUMF facility is used and the scheduler picks a random CPU for such a process to run on. The scheduler enables the CPUMF infrastructure via PMU callback functions pmu::add() and pmu::del(). Introduce a CPU hotplug prepare/dead callback pair which creates and removes the per CPU counter data while the CPU is offline. Count the users which track every CPU (cpu == -1), that is perf_event_open() events with task context and /dev/hwctr device sessions, in the new counter cpu_cf_root::tskcnt, protected by pmc_reserve_mutex. This ensures the infrastructure is available when new CPU is selected to run the per-task context process. In cpum_cf_free_root() and cpum_cf_free_cpu() ensure the reference pointer to data structures is set to NULL before the data is freed to prevent interrupt handlers to access stale data. [gor@linux.ibm.com: change commit message] Fixes: 9b9cf3c77e7e ("s390/cpum_cf: rework PER_CPU_DEFINE of struct cpu_cf_events") Cc: stable@vger.kernel.org # v6.5+ Suggested-by: Heiko Carstens Suggested-by: Christian Borntraeger Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Thomas Richter Acked-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit aad7247bd35ad44af90a5e8974cdff614235b497 Author: Jianing Li Date: Mon Aug 10 08:47:01 2026 +0800 power: supply: max17040: synchronize work cancellation on suspend commit 86a3a8a926aa5969c329d1df2d3259f189961bbc upstream. max17040_work() requeues itself after every poll. cancel_delayed_work() only cancels a pending instance and does not wait for a callback that is already running. If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns. Use cancel_delayed_work_sync() to ensure polling is quiesced before suspend completes. Fixes: c6f4a42de60b ("Add MAX17040 Fuel Gauge driver") Cc: stable@vger.kernel.org Signed-off-by: Jianing Li Link: https://patch.msgid.link/20260810004701.1683-1-m13940358460@163.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 17d43f64b17e4f4fc5b3a70b587e849869128d9c Author: Jianing Li Date: Fri Jul 31 16:42:59 2026 +0800 power: supply: max17040: drop incorrect I2C functionality check commit 4e4b9f5ce9dfb8ed4b8d1262a504b8043ac09d87 upstream. max17040_probe() rejects adapters that do not advertise I2C_FUNC_SMBUS_BYTE. The driver does not issue SMBus byte transactions, however. Its regmap has 8-bit registers and 16-bit big-endian values, for which regmap-i2c supports either raw I2C transfers or SMBus word-data transactions. Consequently, an adapter providing raw I2C transfers or SMBus word data but not SMBus byte transactions is rejected even though regmap can access the device. Conversely, the current check can pass an adapter that regmap cannot use. Drop the stale check and let devm_regmap_init_i2c() validate and select the supported transfer method. Fixes: 6455a8a84bdfd ("power: supply: max17040: Use regmap i2c") Cc: stable@vger.kernel.org Signed-off-by: Jianing Li Link: https://patch.msgid.link/20260731084259.916-1-m13940358460@163.com [Fixed Fixes tag, so that it points to the regmap introduction instead of the initial driver addition] Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 13fb0477da9b400071b9d518b24d6434c4965263 Author: Jianing Li Date: Mon Jul 27 14:48:25 2026 +0800 power: supply: max17040: propagate register read errors commit 659cc3d8d5ef246263873fce72c8cadeeed073cc upstream. max17040_get_vcell() and max17040_get_soc() ignore errors returned by regmap_read(). When an I2C transfer fails, the uninitialized register value is converted and reported to userspace as a valid voltage or state of charge. The polling worker can also replace the cached state of charge with the bogus value and emit a spurious change event. Propagate read errors through the power supply get_property callback and keep the last valid cached state of charge when polling fails. Fixes: c6f4a42de60b ("Add MAX17040 Fuel Gauge driver") Cc: stable@vger.kernel.org Signed-off-by: Jianing Li Link: https://patch.msgid.link/20260727064825.948-1-m13940358460@163.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 39b60d615dfa1725c235351fb12bc72e5f8a8d32 Author: Fan Wu Date: Sun Aug 2 05:12:49 2026 +0000 power: supply: ucs1002: fix use-after-free on remove commit 609af0ceeaefdfa42cd01dd060b20f2e41f9a232 upstream. ucs1002 has no remove callback, so unbind runs entirely through devm. The alert IRQ handler queues the health_poll delayed work, and the work reschedules itself while the chip reports a bad-health condition. devm frees the alert IRQ, which only synchronizes the handler; it does not cancel the delayed work, which can then run after devm frees the driver data and dereference it. Register health_poll with devm_delayed_work_autocancel() before the alert IRQ is requested. devm then frees the IRQ before cancelling the work, so the handler can no longer queue it and the work is cancelled before the driver data is freed. This issue was found by an in-house static analysis tool. Fixes: 81196e2e57fc ("power: supply: ucs1002: fix some health status issues") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Reviewed-by: Lucas Stach Link: https://patch.msgid.link/20260802051249.424015-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit a4460e89d4088cfec2da5be33e265ef1a8e780e9 Author: Maoyi Xie Date: Sat Jul 25 15:25:40 2026 +0800 power: supply: twl4030_charger: cancel workers via devm commit 6eba34732524067da2aad5ddfdfbc641ded10e9e upstream. bci is devm-allocated. Two workers (bci->work and bci->current_worker) dereference it. twl4030_bci_remove() disables charging and masks interrupts. It cancels neither worker. A worker pending at remove() can run after devm frees bci. The USB transceiver comes from devm_usb_get_phy_by_node(). devm unregisters its notifier only after remove() returns. A cancel_work_sync() in remove() can then race a notifier reschedule. devm_work_autocancel() and devm_delayed_work_autocancel() avoid that. They cancel the workers during devm release, before bci is freed. The current_worker is registered first, since devm will cancel in reverse order and bci->work can reschedule current_worker. Suggested-by: Sebastian Reichel Fixes: d6ccc442b1210 ("twl4030_charger: Make the driver atomic notifier safe") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260702172128.2001753-1-maoyixie.tju@gmail.com Signed-off-by: Maoyi Xie Link: https://patch.msgid.link/20260725072540.3092504-1-maoyixie.tju@gmail.com [Move comment about order into the commit message] Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 1b9978433c61a9b46e48832a1ebceee1cf5c9eb4 Author: Fan Wu Date: Thu Jul 23 22:53:10 2026 +0000 power: supply: rt9455: quiesce delayed work before teardown commit 3e7a1ebc32fad5a558254a478efd401c17a24381 upstream. The threaded IRQ handler can queue pwr_rdy_work, max_charging_time_work and batt_presence_work. pwr_rdy_work and batt_presence_work can also queue max_charging_time_work, while batt_presence_work can requeue itself. rt9455_remove() cancels max_charging_time_work before batt_presence_work. The latter can therefore queue max_charging_time_work after it has already been cancelled: rt9455_remove() workqueue cancel pwr_rdy_work cancel max_charging_time_work batt_presence_work queues max_charging_time_work cancel batt_presence_work return devres frees rt9455_info max_charging_time_work dereferences rt9455_info The IRQ also remains registered until devres cleanup and can queue more work after any of the cancellation calls. If rt9455_hw_init() fails after the IRQ has been requested, probe returns without cancelling work that may already have been queued. A pending callback can then access rt9455_info after it has been freed. Register rt9455_cancel_all_delayed_works() through devm_add_action_or_reset() right after devm_power_supply_register(). devres invokes the action in reverse registration order, after the managed IRQ has been freed and before rt9455_info is released, so the delayed works are drained in both rt9455_remove() and the probe error path. Cancel pwr_rdy_work and batt_presence_work before max_charging_time_work because both can queue the latter. This issue was found by an in-house static analysis tool. Fixes: e86d69dd786e ("power_supply: Add support for Richtek RT9455 battery charger") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260723225310.12663-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit ee053561e21ce1e1741dd64ca5ddcdb92e40edc1 Author: HyeongJun An Date: Mon Jul 27 16:41:19 2026 +0900 power: supply: qcom_battmgr: terminate the strings from firmware commit ab1112df8f4ffa88cb024dd370c432ced80f77d8 upstream. The qcom_battmgr_sc8280xp_strcpy() takes a Pascal-style string when the firmware sends one. Otherwise it copies all BATTMGR_STRING_LEN bytes and leaves the destination without a terminator. Those destinations are model_number, serial_number and oem_info, each BATTMGR_STRING_LEN and declared next to each other. They go out to user space as val->strval, which power_supply_format_property() prints with "%s", so a firmware string that fills the whole field makes that read run into the following members. Use strscpy() so the copy always terminates, the way the SM8350 path already does for the same field. Fixes: 29e8142b5623 ("power: supply: Introduce Qualcomm PMIC GLINK power supply") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260727074119.2585463-1-sammiee5311@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 06618447029c6dddaa02f6e9528efe5dd49fc329 Author: Fan Wu Date: Sat Aug 1 05:19:23 2026 +0000 power: supply: qcom_battmgr: fix use-after-free commit 4e40befedfc8ed86f44e1f81df92d13c149c9f8d upstream. qcom_battmgr_pdr_notify() queues enable_work when the PMIC GLINK service comes up, and the worker recovers battmgr through container_of() to issue firmware requests. The PMIC GLINK client stays on the client list until its devres release action runs, so a PDR notification can keep queueing the work, and a pending or running worker can access battmgr after devres frees it. Make enable_work device-managed with devm_work_autocancel(), registered before the PMIC GLINK client is allocated. The devres cleanup then releases the client first, so no further notification can queue the work, and cancels the work before battmgr is freed. This issue was found by an in-house static analysis tool. Fixes: 29e8142b5623 ("power: supply: Introduce Qualcomm PMIC GLINK power supply") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260731022006.317192-1-fanwu01@zju.edu.cn Link: https://patch.msgid.link/20260801051923.354496-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit b3aa1e9509e1b0a863353356d617fb45d1b6250a Author: Fan Wu Date: Sun Aug 2 03:54:42 2026 +0000 power: supply: lp8788-charger: fix use-after-free on remove commit 831c29a12d560f8a3225f43050b3fbb5dfd79c66 upstream. lp8788_charger_remove() flushes charger_work before unregistering the IRQs. An IRQ thread can queue charger_work after flush_work() has returned. The work can then run after devres frees pchg and dereference it in lp8788_charger_event(). Unregister the IRQs first. free_irq() waits for any running threaded handler, so no handler can queue more work afterwards. Then use cancel_work_sync() to cancel pending work or wait for running work to finish. This issue was found by an in-house static analysis tool. Fixes: 98a276649358 ("power_supply: Add new lp8788 charger driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260802035442.421697-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit ab6b1ad710bed7931540733ce145493fece8ceef Author: Fan Wu Date: Fri Aug 7 03:35:20 2026 +0000 power: supply: lp8727: fix use-after-free in lp8727_release_irq() commit ceb6ac43b0f591722401922ceb958ce2616935e0 upstream. lp8727_isr_func(), the threaded IRQ handler, is the only caller that arms pchg->work via schedule_delayed_work(). lp8727_release_irq() currently cancels the work before freeing the IRQ, so an IRQ delivered in between can re-arm the work through the threaded handler. After .remove returns the devm layer frees pchg while lp8727_delayed_func() may still run and dereference it. Free the IRQ first so the threaded handler is quiesced and can no longer queue work, then cancel the delayed work to drain the final generation. This issue was found by an in-house static analysis tool. Fixes: d71fda016102 ("lp8727_charger: Clean up the interrupt handler") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260807033520.8551-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 4b1f2be1e1b74a50386ba718de3d62bfcf5ee701 Author: Jameson Thies Date: Wed Jul 22 19:50:59 2026 +0000 power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS commit 657cd3a42e937276262c0a8ae6b01a87004309de upstream. Currently the cros_usbpd-charger driver probe iterates based on raw charger port count returned by the embedded controller. The only check is against the number of USB PD ports which the embedded controller also defines. A malicious embedded controller could return an inaccurate port count (up to 255) resulting in an out of bounds write and subsequent memory corruption. Update helper functions in cros_usbpd-charger to limit port counts to EC_USB_PD_MAX_PORTS. Fixes: 3af15cfacd1e ("power: supply: cros: add support for dedicated port") Cc: stable@vger.kernel.org Signed-off-by: Jameson Thies Reviewed-by: Benson Leung Link: https://patch.msgid.link/20260722195059.1420738-1-jthies@google.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 78be8b7403ff7638162438b664a07d19da76059e Author: Bryam Vargas Date: Tue Jun 16 23:59:45 2026 -0500 power: supply: cros_usbpd-charger: bound the EC-reported port count commit 48355ce49359740f52e94d3623f6fc557ce341f0 upstream. cros_usbpd_charger_probe() reads two port counts from the EC and uses one of them, num_charger_ports, as the loop bound when populating a fixed-size array: struct port_data *ports[EC_USB_PD_MAX_PORTS]; /* 8 entries */ ... for (i = 0; i < charger->num_charger_ports; i++) charger->ports[charger->num_registered_psy++] = port; Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports (from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The only validation is a sanity check that compares the two EC-reported values against each other: if (num_charger_ports < num_usbpd_ports || num_charger_ports > num_usbpd_ports + 1) return -EPROTO; It never checks either count against EC_USB_PD_MAX_PORTS, the size of the ports[] array. A malfunctioning, malicious or compromised EC that reports num_usbpd_ports == num_charger_ports == N for any N > 8 (for example both 255) passes this check, and the loop then writes N pointers into the 8-entry ports[] array embedded in the devm_kzalloc()'d charger_data, overflowing it by up to 255 - 8 = 247 entries (~1976 bytes): a slab out-of-bounds write. Reject a port count larger than the ports[] array can hold. Fixes: f68b883e8fad ("power: supply: add cros-ec USBPD charger driver.") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260616-b4-disp-5e197080-v2-1-8aa5bffce945@proton.me Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 86e4fa65368f3bbb506dddba8c9eedc75bd603b2 Author: Fan Wu Date: Tue Jul 28 03:01:23 2026 +0000 power: supply: charger-manager: register regulators before exposing sysfs commit c57cb36f76eb7ced45f57af1a890d8f3a6d76342 upstream. charger_manager_remove() and the err_reg_extcon probe error path free each charger regulator with regulator_put() before tearing down the power_supply sysfs entries (power_supply_unregister()). charger_manager_remove() also calls try_charger_enable(cm, false) after the regulator_put() loop. A concurrent write to a charger's externally_control sysfs attribute that lands between regulator_put() and power_supply_unregister() can run charger_externally_control_store() and call try_charger_enable(), which, when charging is enabled, dereferences the already-freed consumer handle. When charging is enabled, try_charger_enable(cm, false) in .remove() also dereferences the freed handles directly. Both leave use-after-free windows. Symmetrically, probe registers the sysfs entries (power_supply_register) before acquiring the regulators (regulator_get, inside charger_manager_register_extcon), so userspace can reach externally_control before the regulators are available. Split charger_manager_register_extcon() on the sync/async boundary: charger_manager_get_regulators() (regulator_get only, no async producer) now runs before power_supply_register() so sysfs is not live before regulators are available, and charger_manager_register_extcon() keeps only the extcon notifier/work setup, still after power_supply_register() so a power_supply_register() failure cannot reach extcon setup. This keeps the sysfs setup/teardown ordering symmetric without introducing an asynchronous producer on the earlier probe-error path. Move power_supply_unregister() and try_charger_enable(cm, false) ahead of the regulator_put() loop on both teardown paths, and adjust err_reg_extcon (power_supply_unregister() then fall through err_regulator for regulator_put(); get_regulators self-rolls back on its own failure). This does not address the separate extcon-notifier-driven deref of the same handles, which needs its own synchronization design. Found by an in-house static analysis tool. Fixes: 3950c7865cd7 ("charger-manager: Add support sysfs entry for charger") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260728030123.230202-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 238320ad029a3eedabb86286a28cab55bca629b9 Author: Ma Ke Date: Wed Jul 22 12:44:16 2026 +0800 power: supply: bq25890: Fix power_supply reference leak commit 863c32a83e4235eb0cbf6106f2b124e645302156 upstream. bq25890_fw_probe() acquires a reference to a secondary charger using power_supply_get_by_name(), but the reference is not released on later probe failures or on driver detach. In particular, failures after bq25890_fw_probe() returns successfully, such as a failure in bq25890_hw_init(), also leak the reference. Register a device-managed cleanup action immediately after acquiring the secondary charger. This releases the reference on all subsequent probe failures and on driver detach. Found by code review. Signed-off-by: Ma Ke Cc: stable@vger.kernel.org Fixes: d54bf877fd87 ("power: supply: bq25890: Add support for having a secondary charger IC") Link: https://patch.msgid.link/20260722044416.1623621-1-make_ruc2021@163.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 9e1aba34df9a87d53460888e05718717c0f69343 Author: Fan Wu Date: Tue Aug 4 14:55:11 2026 +0000 power: supply: bq256xx: drain usb_work before freeing the charger commit 2dd6cd823777bea6d9a880a12a92a73ec76aee0b upstream. The USB-PHY notifier queues usb_work, whose handler calls power_supply_changed(bq->charger). The reset devm action only unregisters the notifier and was registered before the power supplies, so devm frees bq->charger on unwind before the action runs; a usb_work still queued can then dereference it. Register the reset action after the power supplies, so it unregisters the notifiers and drains usb_work before the supplies are released. Initialize usb_work and obtain the PHY references before registering the notifiers, so the worker cannot run before the supplies exist. Found by static analysis. Fixes: 32e4978bb920 ("power: supply: bq256xx: Introduce the BQ256XX charger driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260804145511.103470-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit f495808cdd6d9576965787cf6d9737d0b0e86b73 Author: Fan Wu Date: Sat Aug 1 05:19:58 2026 +0000 power: supply: bq24257: fix use-after-free on remove commit 9d34c9d660c3d0931d2cc749c46c47cf31f96e48 upstream. The STAT-pin interrupt is devm-managed, so it stays armed until the devm cleanup that runs after remove() returns. remove() cancels bq->iilimit_setup_work while the threaded handler can still fire; that handler reschedules the work and dereferences bq, so the work runs against freed memory once devm frees bq. Make the delayed work device-managed with devm_delayed_work_autocancel(), registered before the interrupt request. The devm cleanup then releases the interrupt first, so the handler can no longer reschedule the work, and cancels the work before bq is freed. The explicit cancel_delayed_work_sync() in remove() is no longer needed and is dropped. Found by static analysis. Fixes: 2219a935963e ("power_supply: Add TI BQ24257 charger driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260731143554.334179-1-fanwu01@zju.edu.cn Link: https://patch.msgid.link/20260801051958.354528-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit d02a5794c3deedcb8476d017fcee2b7aaedab2e1 Author: Jun Yang Date: Mon Aug 24 16:18:20 2026 +0800 sctp: fix stream->outcnt underflow on duplicate RECONF responses commit 3faf13aff243ca9f78d08b1a2956ef5a6fc77b6e upstream. A cached RECONF chunk may contain more than one request parameter. A duplicate response can therefore find and process the same ADD_OUT request again while another parameter is still outstanding, rolling back outcnt twice and possibly underflowing it. Track outstanding request types as bits and clear each bit after its first response. Later responses for the same request are then ignored. Fixes: 11ae76e67a17 ("sctp: implement receiver-side procedures for the Reconf Response Parameter") Cc: stable@kernel.org Reported-by: TencentOS Corvus AI Link: https://lore.kernel.org/netdev/20260730110225.37371-1-juny24602@gmail.com/ Suggested-by: Xin Long Assisted-by: tencentos-corvus-ai:kimi-k3 Signed-off-by: Jun Yang Link: https://patch.msgid.link/20260824081832.98717-3-juny24602@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 7ad8933bca97b8640096a27e8a78b65e65677aae Author: Jun Yang Date: Mon Aug 24 16:18:19 2026 +0800 sctp: distinguish sequence zero from wildcard in reconf lookup commit 63f44178f0a0f86060c9b576d6efab8a3ffa403e upstream. Zero is a valid response sequence after strreset_outseq wraps, but sctp_chunk_lookup_strreset_param() currently treats it as a wildcard. Add match_seq so response lookups match zero exactly while the one type-only lookup can still ignore the sequence. Fixes: 50a41591f110 ("sctp: implement receiver-side procedures for the Add Outgoing Streams Request Parameter") Cc: stable@kernel.org Suggested-by: Simon Horman Acked-by: Xin Long Signed-off-by: Jun Yang Link: https://patch.msgid.link/20260824081832.98717-2-juny24602@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 25419f516ea84b1e7d3d55aae5215ac86ece0c66 Author: Weiming Shi Date: Mon Aug 24 01:28:58 2026 +0800 sctp: fix NULL deref on untransmitted RECONF completion commit 2db9bfa3e27bdea15e05ea70b56bad3d21e570ec upstream. sctp_process_strreset_outreq(), sctp_process_strreset_addstrm_out() and sctp_process_strreset_resp() complete a pending stream reconfiguration request by stopping the reconf timer on the transport it was sent on: t = asoc->strreset_chunk->transport; if (timer_delete(&t->reconf_timer)) sctp_transport_put(t); chunk->transport is assigned by __sctp_packet_append_chunk() when the chunk is appended to an outbound packet, and sctp_outq_flush_ctrl() arms the reconf timer at that same point. A request already published in asoc->strreset_chunk but not yet transmitted has neither, so completing it dereferences NULL. Two ways to get there. sctp_send_asconf_del_ip() sets asoc->src_out_of_asoc_ok without sending anything when the address being removed is the association's last one, and sctp_outq_flush_ctrl() then leaves every non-ASCONF control chunk queued; as only sctp_process_asconf_ack() clears that flag, it persists. An unprivileged process that removes such an address and then asks for a stream reset panics the kernel from softirq. A peer needs neither ASCONF nor local help: sctp_cmd_interpreter() uncorks the outqueue only once the whole packet has been processed, so a reply built while walking a RECONF chunk stays untransmitted for the rest of that walk, and one RECONF chunk carrying [Incoming SSN Reset Request, Outgoing SSN Reset Request, Response] -- or two RECONF chunks in one packet -- reaches the same dereference. KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef] RIP: 0010:timer_delete+0x67/0x110 Call Trace: sctp_process_strreset_addstrm_out (net/sctp/stream.c:832) sctp_sf_do_reconf (net/sctp/sm_statefuns.c:4212) sctp_do_sm (net/sctp/sm_sideeffect.c:1172) sctp_assoc_bh_rcv (net/sctp/associola.c:1044) sctp_rcv (net/sctp/input.c:243) ip_local_deliver (net/ipv4/ip_input.c:262) process_backlog (net/core/dev.c:6680) A response can only acknowledge a request that was actually sent, so do not match asoc->strreset_chunk while chunk->transport is NULL. Guarding the lookup covers all three completion sites. Fixes: 810544764536 ("sctp: implement receiver-side procedures for the Outgoing SSN Reset Request Parameter") Cc: stable@vger.kernel.org Reported-by: Xiang Mei Suggested-by: Xin Long Assisted-by: Claude:claude-opus-5 Signed-off-by: Weiming Shi Acked-by: Xin Long Link: https://patch.msgid.link/20260823172857.896146-2-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 1035bdef1efb9b1076d1a57b81e08c637ff08ecc Author: Hyunwoo Kim Date: Wed Aug 19 10:38:37 2026 +0900 sctp: drop a chunk if its transport was removed commit 03a9d10ecf71f54b2af8020935f2033d4a132be5 upstream. sctp_rcv() resolves the transport once per packet and leaves it in chunk->transport. The lookup reference, or the one sctp_add_backlog() takes if the socket is owned by userspace, keeps it around until the chunk has been processed. An authenticated ASCONF DEL-IP can remove it in the meantime. sctp_assoc_rm_peer() takes the transport out of the association and calls sctp_transport_free(), which tags it dead and drops the reference the association held. There is a window on both paths: the packet can sit on the socket backlog, and on the direct path the lookup completes before bh_lock_sock(). The DATA chunk in that packet puts the removed transport back into asoc->peer.last_data_from. Once the packet is done that reference goes away and the transport is freed by RCU, so the next delayed SACK carries the pointer into the SACK chunk and sctp_outq_select_transport() reads the freed transport's state. Drop the chunk in sctp_inq_push(), next to the existing rcvr->dead check. Both paths reach it with the association's socket lock held. The peer retransmits it. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Acked-by: Xin Long Link: https://patch.msgid.link/aoUJHQmxL0LFIMCw@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fa306a40e716c5abcd967475459ce1ebd56e5115 Author: Hyunwoo Kim Date: Sat Aug 15 07:36:18 2026 +0900 sctp: stop processing a packet once its association is deleted commit 47e15a8d12e366d0d261bcbc394394f44418938d upstream. sctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference. A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(), so the association and its transports are freed. The endpoint loop has no counterpart to the asoc->base.dead check in sctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed transport and is then passed to sctp_do_sm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context. The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctp_inq_free() releases the chunk on the association receive path. sctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Acked-by: Xin Long Link: https://patch.msgid.link/an-YYtoqw1QpTXUL@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8a02ad98798fd01f51f648c1fdd8f3c9d07195d3 Author: Yehyeong Lee Date: Sat Aug 1 17:18:17 2026 +0900 nvme-tcp: reject a read that transferred too few bytes commit 7fa3f73f6c8ddc5f0425b50fb2a626a782ef7d12 upstream. nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above. A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target. Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against. Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 3b3d27670c0c890ba7cf1bc3614cab61bde6d25c Author: Yehyeong Lee Date: Wed Jul 29 14:46:02 2026 +0900 nvme-tcp: fix host memory disclosure on R2T for a read command commit 6efbc52237facda35d2d874fe1765bb4839275d8 upstream. nvme_tcp_handle_r2t() does not check the direction of the request the R2T refers to. A malicious controller can send an R2T for a READ and the host will answer it: nvme_tcp_setup_h2c_data_pdu() builds the H2CData header and nvme_tcp_try_send_data() sends the request's data buffer. That buffer is the READ destination, so its contents go to the controller. The command then completes normally and nothing is logged. Against a test controller that answers every READ with an R2T, a 4096 byte buffered read returned all 4096 bytes, split over two R2Ts. The pages contained stale kernel data, including an array of struct page pointers. Reject an R2T for a request that is not a write. Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 6a01b58263108eaf9869bb6f82f07709240c6589 Author: Yehyeong Lee Date: Sat Aug 1 17:18:18 2026 +0900 nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone commit 3a4aa9e6ad3e35f8e24d5eaf38ee4d437075fb36 upstream. Commit 25e5cb780e62 ("nvme-tcp: fix possible crash in write_zeroes processing") established that blk_rq_payload_bytes() must not be read without first checking blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight, because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now tests the same two. Fixes: 25e5cb780e62 ("nvme-tcp: fix possible crash in write_zeroes processing") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 0d4f317b07d6c06a50fceabcce25dde8d63cc8f6 Author: Myeonghun Pak Date: Wed Jul 15 16:44:59 2026 +0900 nvme-pci: disable controller on admin queue IRQ setup failure commit 08660a5c8d497f43191635d97efd31cd35051f15 upstream. nvme_pci_configure_admin_queue() enables the controller and then requests the admin queue interrupt. If queue_request_irq() fails it returns without disabling the controller, and no caller compensates: nvme_pci_enable() only frees the IRQ vectors and calls pci_disable_device(), after which nvme_dev_disable() treats the controller as dead and skips nvme_disable_ctrl(). The controller is left enabled (CC.EN set) on this error path. Disable it in the failure path, while the PCI device is still enabled so the CC.EN clear handshake completes. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: b60503ba432b ("NVMe: New driver") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 67551d8430df94c827e1830bd3a5fae1f66a5219 Author: Yehyeong Lee Date: Thu Jul 30 20:36:24 2026 +0900 nvme: zero the discard fallback page commit bededeaaeff404978a5a8e2a605a6c3017cddd3e upstream. nvme_setup_discard() always maps sizeof(struct nvme_dsm_range) * NVME_DSM_MAX_RANGES = 4096 bytes as the DSM payload however many ranges the command declares, because some devices ignore the 'Number of Ranges' field - the Fixes: commit records two that read past the declared ranges. A single-range discard fills only the first 16 bytes. Normally the buffer comes from kzalloc() and the other 4080 bytes are zero. When that allocation fails the code falls back to the per-controller ctrl->discard_page, which nvme_init_ctrl() obtains with alloc_page(GFP_KERNEL) and nothing ever zeroes, so those 4080 bytes are whatever the page last held and are handed to the controller. Reaching it requires the kzalloc(GFP_ATOMIC | __GFP_NOWARN) to fail, that is memory pressure; it is not remotely triggerable. Failing the allocation under KMSAN reproduces it, with the leaked tail full of vmemmap struct page pointers. The extent in the report is a partial transfer of the payload, not the whole 4096 bytes; the 16-byte boundary in it is the one declared range: [ 11.991601] BUG: KMSAN: uninit-value in dma_map_phys+0x14c8/0x1900 [ 11.991969] dma_map_phys+0x14c8/0x1900 [ 11.992220] dma_map_page_attrs+0xcf/0x130 [ 11.992485] e1000_xmit_frame+0x4099/0x6d10 [ 11.992768] dev_hard_start_xmit+0x22f/0xa80 [ 11.993068] sch_direct_xmit+0x35c/0xcb0 [ 11.993315] __dev_queue_xmit+0x1ee5/0x5eb0 [ 11.993608] ip_finish_output2+0x1903/0x1c30 [ 11.993881] ip_finish_output+0x288/0x870 [ 11.994125] ip_output+0x15e/0x400 [ 11.994365] __ip_queue_xmit+0x1e85/0x1fb0 [ 11.994639] ip_queue_xmit+0x60/0x80 [ 11.994899] __tcp_transmit_skb+0x4e71/0x5fa0 [ 11.995210] tcp_write_xmit+0x3a36/0x9160 [ 11.995533] __tcp_push_pending_frames+0xc5/0x3c0 [ 11.995854] tcp_push+0x7dc/0x840 [ 11.996076] tcp_sendmsg_locked+0x766c/0x8400 [ 11.996371] tcp_sendmsg+0x4b/0x90 [ 11.996572] inet_sendmsg+0x134/0x2a0 [ 11.996823] __sock_sendmsg+0x265/0x360 [ 11.997076] sock_sendmsg+0x100/0x1e0 [ 11.997293] nvme_tcp_try_send+0x196f/0x6370 [ 11.997605] nvme_tcp_queue_rq+0x1d54/0x20b0 [ 11.997882] blk_mq_dispatch_rq_list+0x5ee/0x2e50 [ 11.998175] __blk_mq_sched_dispatch_requests+0x16dc/0x24a0 [ 11.998539] blk_mq_sched_dispatch_requests+0x11b/0x2c0 [ 11.998865] blk_mq_run_work_fn+0x13b/0x280 [ 11.999146] process_scheduled_works+0x966/0x1ad0 [ 11.999465] worker_thread+0xe44/0x1480 [ 11.999709] kthread+0x53b/0x600 [ 11.999927] ret_from_fork+0x29f/0x7c0 [ 12.000191] ret_from_fork_asm+0x1a/0x30 [ 12.000460] [ 12.000558] Uninit was created at: [ 12.000788] __alloc_frozen_pages_noprof+0x8bf/0xd30 [ 12.001096] alloc_pages_mpol+0x1d0/0x5f0 [ 12.001326] alloc_pages_noprof+0x102/0x290 [ 12.001627] nvme_init_ctrl+0x5a3/0x9f0 [ 12.001891] nvme_tcp_create_ctrl+0xd75/0x19b0 [ 12.002170] nvmf_dev_write+0x4c68/0x4fd0 [ 12.002426] vfs_write+0x587/0x1a10 [ 12.002636] __x64_sys_write+0x207/0x4f0 [ 12.002874] x64_sys_call+0x2ff0/0x3ea0 [ 12.003123] do_syscall_64+0x147/0x3b0 [ 12.003400] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 12.003680] [ 12.003777] Bytes 16-2843 of 2844 are uninitialized [ 12.004068] Memory access of size 2844 starts at ffff888109f82000 [ 12.004412] [ 12.004530] CPU: 0 UID: 0 PID: 101 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMECTL-gf5098b6bae76 #1 PREEMPT(lazy) [ 12.005127] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 12.005762] Workqueue: kblockd blk_mq_run_work_fn [ 12.006073] ===================================================== Allocate the page with __GFP_ZERO. The single allocation site covers every use of it: bytes no discard has written stay zero, and bytes one did write hold that controller's own range list, which it has already been sent. Fixes: 530436c45ef2 ("nvme: Discard workaround for non-conformant devices") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 1e456cc2744ee98e4fdbc80d266288c9247b023e Author: Ewan D. Milne Date: Wed May 13 15:25:51 2026 -0400 nvme: nvme-fc: Fix nvme_fc_create_hw_io_queues() queue deletion in error path commit 22eb631bf86ee3246f47885e4fa94154a46863e4 upstream. nvme_fc_create_hw_io_queues() will call __nvme_fc_delete_hw_queue() for the last queue on which __nvme_fc_create_hw_queue() reported an error when deleting all the io queues if they cannot all be created. This is incorrect since the last queue did not actually get created. The most recent change to this code was commit 17a1ec08ce70 ("nvme/fc: simplify error handling of nvme_fc_create_hw_io_queues") which moved the cleanup to the delete_queues: label and changed the loop bounds, however the code was not correct prior to this change in a different way. The original commit e399441de911 ("nvme-fabrics: Add host support for FC transport") had a different error which called __nvme_fc_delete_hw_queue() on queue index 0 which is used for the admin queue. Fix this by correcting the initial loop index when deleting the io queues. Fixes: 17a1ec08ce70 ("nvme/fc: simplify error handling of nvme_fc_create_hw_io_queues") Fixes: e399441de911 ("nvme-fabrics: Add host support for FC transport") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Maurizio Lombardi Reviewed-by: Laurence Oberman Reviewed-by: Justin Tee Signed-off-by: Ewan D. Milne Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit d662f7fc04fde305a27f304b3cd19b614d366839 Author: Shuangpeng Bai Date: Fri Jul 17 13:28:09 2026 -0400 lockd: fix NULL dereference on lockowner allocation failure commit 4c7fc129db061c7daab841c4f3c342d894832362 upstream. nlmclnt_locks_init_private() installs NLM file lock operations even when nlmclnt_find_lockowner() fails to allocate a lockowner. nlmclnt_proc() then returns -ENOMEM, but the VFS still tears down the partially initialized file_lock and calls locks_release_private(). That invokes nlmclnt_locks_release_private(), which dereferences fl->fl_u.nfs_fl.owner and crashes because the owner was never installed. Clear fl_ops before attempting to initialize the NLM private state, and install the NLM lock operations only after a lockowner has been allocated successfully. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 41f0a6d31615fcae261bf28a0aa50050dc93a401 Author: Michael Bommarito Date: Sun May 24 07:55:27 2026 -0400 lockd: pin next file across nlm_inspect_file lock-drop commit 526c49cff3f72c3ec74752016380c7567040581b upstream. nlm_traverse_files() pins the current file with f_count++ across a mutex_unlock for nlm_inspect_file(), but nothing pins the saved next pointer. A concurrent nlm_release_file() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step. Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock. Always call nlm_file_release() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlm_file_inuse(), which does a live walk of the inode lock list, rather than the cached f_locks field, so skipped files that never ran nlm_inspect_file() are evaluated correctly. Because every file in a hash bucket is now pinned and released, files skipped by the is_failover_file predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table. Fixes: 01df9c5e918a ("LOCKD: Fix a deadlock in nlm_traverse_files()") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260524115527.1734251-1-michael.bommarito@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 3088e41292fecf132f85f79af5ee4d620b9ff1b4 Author: Yifei Gao Date: Tue Aug 25 23:46:29 2026 +0000 ipmi: Fix use-after-free of cmd_rcvr in _ipmi_destroy_user() commit 05ec76cfbce653e07cec19b9b8b20e33449d5d87 upstream. Commit 9e91f8a6c868 ("ipmi:msghandler: Remove srcu for the ipmi_interfaces list") dropped the synchronize_rcu() between unlinking the command receivers from intf->cmd_rcvrs and freeing them, updating only the comment that explains why the barrier is needed. The cmd_rcvrs list is still traversed under plain RCU: find_cmd_rcvr() walks it inside rcu_read_lock(), and handle_ipmb_get_msg_cmd() borrows rcvr->user from that lookup within the same read-side section. Without the grace period, _ipmi_destroy_user() can kfree() a cmd_rcvr while a reader still holds a pointer to it, causing a use-after-free. The rework only made srcu unnecessary for the interfaces list; the cmd_rcvrs list still relies on plain RCU. Restore the synchronize_rcu() before freeing the receivers. Fixes: 9e91f8a6c868 ("ipmi:msghandler: Remove srcu for the ipmi_interfaces list") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yifei Gao Message-ID: <20260825234630.1196170-1-gyf161023@gmail.com> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 6aeff1636b39883229b5122ca8fe29ee25515556 Author: Ruoyu Wang Date: Sat Aug 15 23:17:20 2026 +0800 i2c: mxs: fix DMA channel leak on probe error commit 777979e627115734052b323d2721cdb500e81dcf upstream. mxs_i2c_probe() requests an exclusive DMA channel before resetting the controller and registering the I2C adapter. If either later operation fails, probe returns without releasing the channel because the remove callback is not invoked after a failed probe. Use devm_dma_request_chan() so the device core releases the channel on probe failure and driver detach. Remove the manual release from the remove callback because the channel is now device-managed. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 62885f59a261 ("MXS: Implement DMA support into mxs-i2c") Assisted-by: unnamed:claude-opus-4.8 typestate Signed-off-by: Ruoyu Wang Cc: # v3.7+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260815151720.3757460-1-ruoyuw560@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8d2c120d2d5bfd95c4066cbbe5e188cea86b349f Author: Cong Nguyen Date: Mon Aug 10 11:27:54 2026 +0700 hwmon: (max6621) fix temperature clamp range commit 24fbeb83d9b750a36da42cb835a154d80fd3d495 upstream. MAX6621_TEMP_INPUT_MIN and MAX6621_TEMP_INPUT_MAX are used to clamp the writable offset and critical thresholds. They are defined as -127000 and 128000. The driver decodes the temperature through an s8 and its own comment in max6621_read() documents an 8-bit two's complement value, whose range is -128 to +127 degrees C. The current limits therefore reject the valid -128 degrees C and accept +128 degrees C, which does not fit the 8-bit range. Correct the limits to -128000 and 127000. Fixes: 92b64580f14b ("hwmon: (max6621) Add support for Maxim MAX6621 temperature sensor") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Link: https://lore.kernel.org/r/9d3a4f1895a47794bb359a2a32fb1ccd6a15812c.1786334038.git.congnt264@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 9b38d9a2e46a2906bd48cab9bf60382c1f5e1fe8 Author: Cong Nguyen Date: Mon Aug 10 11:28:39 2026 +0700 hwmon: (max6621) fix negative temperature offset and crit readings commit acc52bd431e2d8698fae8d82a74ac45d79b62e0a upstream. max6621_read() reads the CONFIG2 offset and the critical alert threshold registers into a u32 and scales them without sign extension: /* offset */ *val = (regval >> MAX6621_REG_TEMP_SHIFT) * 1000L; /* crit */ *val = regval * 1000L; Both attributes are writable and their write paths clamp to a negative minimum and encode negative values, so a value written as negative is read back as a large positive number. For example, writing a -10 degrees C offset stores max6621_temp_mc2reg(-10000) = (-10 << 6) = 0xfd80; the read then computes 0xfd80 >> 6 = 1014 -> 1014000 instead of -10000. Cast the register value to s16 before scaling so the read preserves the sign the write path encodes. The temperature input path already uses an s8 intermediate and is left unchanged. Fixes: 92b64580f14b ("hwmon: (max6621) Add support for Maxim MAX6621 temperature sensor") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Link: https://lore.kernel.org/r/ad0baddbd6163cf73545c8e9273258136718585c.1786334038.git.congnt264@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 68c59343ad1a76a055d4ea90a375c23ea09af640 Author: Christopher Tolang Date: Sun Aug 23 19:32:21 2026 +0800 ASoC: amd: yc: Add DMI entry for MSI Thin A15 B7UC commit e2aa5ad3be41accfcdcccc62348f21af7baa3a38 upstream. This model requires an additional detection quirk to enable the internal microphone. Fixes: fa991481b8b2 ("ASoC: amd: add YC machine driver using dmic") Cc: stable@vger.kernel.org Assisted-by: OpenAI Codex Signed-off-by: Christopher Tolang Link: https://patch.msgid.link/20260823113221.19744-1-christophertolang@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f2a1a83487c6c37a72ecce990503a42c81e5cb65 Author: Karl Mehltretter Date: Sun Jul 26 20:22:53 2026 +0200 arm64: proton-pack: Restore the nospectre_bhb command-line option commit 2f6fc0612607c95489c960aaefc8cb5578cdab8c upstream. Commit 7f1635737823 ("arm64: proton-pack: Fix hard lockup due to print in scheduler context") moved the "mitigation disabled" printks into spectre_print_disabled_mitigations(). For spectre-v2 and spectre-v4 only the pr_info_once() calls were removed, but for spectre-bhb the whole branch went with the print: - } else if (cpu_mitigations_off() || __nospectre_bhb) { - pr_info_once("spectre-bhb mitigation disabled ...\n"); spectre_bhb_enable_mitigation() therefore no longer tests __nospectre_bhb or cpu_mitigations_off() and the mitigation is enabled regardless of the command line. The parameter is still parsed and its flag is still checked by spectre_print_disabled_mitigations(), so the kernel prints "spectre-bhb mitigation disabled by command-line option" while /sys/devices/system/cpu/vulnerabilities/spectre_v2 reports "Mitigation: CSV2, BHB" and the vectors are switched to EL1_VECTOR_BHB_LOOP. The only remaining escape is the SPECTRE_VULNERABLE arm at the top of the chain, which a CSV2 core never reaches, so from Cortex-A76 and Neoverse N1 onwards both nospectre_bhb and mitigations=off are ignored. Both are documented in Documentation/admin-guide/kernel-parameters.txt. The identical mistake was made on the neighbouring compile-time-option branch immediately before this regression and fixed shortly afterwards; this command-line branch was missed. build_bhb_mitigation() in arch/arm64/net/bpf_jit_comp.c still tests both flags, so nospectre_bhb currently keeps the exception-vector loop while dropping the cBPF epilogue mitigation. Restore the check, folded into a spectre_bhb_mitigations_off() helper alongside its spectre_v2/v4 counterparts, and use it for the boot-time print in spectre_print_disabled_mitigations() as well. The print itself already lives there and does not need restoring. Tested under QEMU with -cpu neoverse-n1 (CSV2, no ECBHB, no CLRBHB). Before, spectre_v2 read "Mitigation: CSV2, BHB" with and without the option; after, nospectre_bhb and mitigations=off both give "Mitigation: CSV2, but not BHB" and a boot without either is unchanged. Fixes: 7f1635737823 ("arm64: proton-pack: Fix hard lockup due to print in scheduler context") Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Karl Mehltretter Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit e7c9b1d433b0512b50676dedcba376082f158f8f Author: Karl Mehltretter Date: Thu Aug 20 00:27:12 2026 +0200 arm64: compat: Fix decrementing LDM/STM alignment emulation commit f5b8b9037df387394a73aab47c5437bbac975077 upstream. The compat alignment emulator inherited unsigned long data addresses from the 32-bit ARM implementation. In do_alignment_ldmstm(), nr_regs is an unsigned int holding the transfer size. The function uses the same address addition for both transfer directions, negating nr_regs first for a decrementing LDM or STM. The 32-bit negation wraps before the addition, so the handler adds nearly 4 GiB instead of subtracting the transfer size. The resulting address lies outside the compat task's address space, so decrementing LDM/STM emulation fails, while incrementing forms work. For example, a backwards-moving copy routine using decrementing LDM/STM can take an alignment fault when called with unaligned pointers. The compat handler should emulate the transfer, but this bug instead causes SIGBUS. The offset negated in do_alignment_finish_ldst() is offset_union.un, which is already unsigned long and does not have this width mismatch. Make nr_regs unsigned long so its negation and the address arithmetic use the same width. Fixes: 3fc24ef32d3b ("arm64: compat: Implement misalignment fixups for multiword loads") Cc: stable@vger.kernel.org Suggested-by: Arnd Bergmann Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Karl Mehltretter Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 15d1feeae07d059e45d4c6f90d5a0b2991cf1419 Author: HyeongJun An Date: Sat Aug 8 10:45:54 2026 +0900 ALSA: ump: Fix corrupted data bytes at MIDI 1.0 SysEx to UMP conversion commit 8a906c0b4f1ba123a95c166f644d2383bf30a420 upstream. The cvt_legacy_sysex_to_ump() initialises only the first word of the output packet and ORs the data bytes into it. The second word is left alone, and the conversion context is kept across calls, so it still carries the previous packet's bytes. Those stale bits corrupt the new data. Any SysEx longer than six data bytes is affected. A SysEx with the twelve data bytes 01..0c comes out as: 30160102 03040506 30260708 0b0e0f0e The second packet declares six data bytes and four of them are wrong, inside the declared length. The sibling cvt_legacy_cmd_to_ump() already clears the second word. Do the same here. Fixes: 0b5288f5fe63 ("ALSA: ump: Add legacy raw MIDI support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260808014554.3550153-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e41a59fc056f63a7a1f42788913c53cc48d744aa Author: Norbert Szetei Date: Sat Aug 22 11:12:11 2026 +0200 openvswitch: only skb_tx_error() a packet we are about to drop commit 0dbc2398fca3bb33eda963849f865ddb1b3aa05e upstream. queue_userspace_packet() borrows the packet skb -- it only copies it into a private netlink message (user_skb) and does not own it; on return do_execute_actions() keeps forwarding it through the flow's remaining actions. Its error path nevertheless calls skb_tx_error(skb), which via skb_zcopy_clear() does skb_shinfo(skb)->flags &= ~SKBFL_ALL_ZEROCOPY, stripping SKBFL_SHARED_FRAG from that live skb (skb_tx_error()'s kerneldoc says "skb must be freed afterwards"). For a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG is what makes esp_input() skb_cow_data() before in-place AEAD; once it is stripped a later local ESP-in-UDP delivery decrypts in place over pages the sender does not own -- an unprivileged page-cache write (the "Fragnesia" primitive). do_execute_actions() ignores output_userspace()'s return value, so any action after a failed USERSPACE upcall inherits the stripped skb. Move the skb_tx_error() to the flow-miss drop path - the "default" branch of ovs_dp_process_packet()'s switch(error), before kfree_skb(). The call has been here since commit 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors") but was harmless until esp_input() began relying on SKBFL_SHARED_FRAG to gate in-place decrypt; only then did stripping it on a still-forwarded skb become a page-cache write primitive. Fixes: 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors") Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb frags") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Tested-by: Jongmin Jang Link: https://patch.msgid.link/55A52703-7548-4A55-A9CE-2A37145BDCAD@doyensec.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit d64a75369cd0f2ee79afcc9d9ca34a3890989379 Author: Ali Ahmet Memis Date: Fri Aug 21 01:45:27 2026 +0000 openrisc: fix arbitrary kernel memory access via or1k_atomic syscall commit 78004e9a87f240df03e2f73120d291763c32e0a7 upstream. sys_or1k_atomic() (syscall 244 in the "or1k" ABI) takes two user pointers, v1 and v2, and swaps the words they point to in hand-written assembly. l.lwz r29,0(r4) l.lwz r27,0(r5) l.sw 0(r4),r27 l.sw 0(r5),r29 The pointers are not checked with access_ok(). The four memory accesses also have no exception table entries. A caller passes a kernel address as either pointer, and the syscall reads from and writes to it directly. This gives an unprivileged process a kernel read/write primitive. It overwrites kernel data such as the sys_call_table, gaining code execution in kernel context. Check both pointers before entering the critical section. Add fixups for the four memory accesses so faults on valid but unmapped user addresses return -EFAULT. [shorne@gmail.com: fix comment style] Fixes: 9d02a4283e9c ("OpenRISC: Boot code") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Signed-off-by: Stafford Horne Signed-off-by: Greg Kroah-Hartman commit c0c165487a2ea5a37ddcdab4259157b7a527129c Author: Zhan Xusheng Date: Thu Aug 6 10:20:44 2026 +0800 ocfs2: fix readdir position truncation on 32-bit kernels commit a63308ab426f3a3c7e33b02c150ea59054620261 upstream. In ocfs2_dir_foreach_blk_el(), the directory cookie position is rebuilt with ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset; `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask ~(sb->s_blocksize - 1) is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB block size). In the AND expression with the 64-bit `ctx->pos`, that unsigned operand is zero-extended to 64 bits per the usual arithmetic conversions, yielding 0x00000000fffff000. The high 32 bits of `ctx->pos` are silently cleared, even though directory size is allowed to exceed 4 GiB. When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position is reset back into the first 4 GiB block, making the re-validation path re-enumerate already-returned dirents indefinitely. This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken for all non-inline directories, so a directory large enough to cross 4 GiB reaches it. This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix bitwise operation having different size") fixed in exfat, and the fix mirrors the equivalent ext4 fix in this series. Cast the operand to loff_t so the mask is 64-bit before the AND: ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; 64-bit kernels are unaffected. Link: https://lore.kernel.org/20260806022044.167962-3-zhanxusheng@xiaomi.com Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Zhan Xusheng Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Andreas Dilger Cc: Jan Kara Cc: Ojaswin Mujoo Cc: "Ritesh Harjani (IBM)" Cc: Ted Ts'o Cc: "zhangyi (F)" Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 0608018a71f2487f5e3709ef2c0c72e73de18875 Author: Joseph Qi Date: Wed Jul 22 20:49:33 2026 +0800 ocfs2: cluster: fix o2hb_dependent_users leak on pin failure commit 12c2ab42dbe227956c765e2674364bfca5de0533 upstream. In o2hb_region_inc_user(), o2hb_dependent_users is incremented unconditionally before calling o2hb_region_pin(). If the pin fails, the counter is never decremented and any partially-pinned regions are never unpinned, since the caller does not call o2hb_region_dec_user() on error. The leaked counter causes subsequent o2hb_region_inc_user() calls to skip pinning entirely (the > 1 check), leaving heartbeat regions unprotected. Fix by rolling back on failure: call o2hb_region_unpin(NULL) to release any partially-pinned regions and decrement o2hb_dependent_users to restore the pre-increment state. Link: https://lore.kernel.org/20260722124933.430554-4-joseph.qi@linux.alibaba.com Fixes: 58a3158a5d17 ("ocfs2/cluster: Pin/unpin o2hb regions") Signed-off-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 251e38f5af7b2054d12467b2a79a62c2c4b86a6f Author: Joseph Qi Date: Wed Jul 22 20:49:32 2026 +0800 ocfs2: cluster: avoid lock order inversion in o2hb_region_pin() from drop_item commit cd789996db3c87427343f54f509d17810bd7ba7c upstream. o2hb_heartbeat_group_drop_item() is called from configfs rmdir with the parent directory's inode_lock held. It calls o2hb_region_pin() -> o2nm_depend_item() -> configfs_depend_item(), which acquires the configfs root inode_lock. This creates a parent -> root inode_lock nesting that could deadlock against paths taking root -> parent (e.g. subsystem unregistration). Fix this by using configfs_depend_item_unlocked() when o2hb_region_pin() is called from a configfs callback context. This variant skips the root inode_lock when caller and target are in the same subsystem, which is safe because VFS already holds a lock preventing unregistration. Add o2nm_depend_item_unlocked() wrapper and a from_callback parameter to o2hb_region_pin() to select the appropriate variant. Link: https://lore.kernel.org/20260722124933.430554-3-joseph.qi@linux.alibaba.com Fixes: 58a3158a5d17 ("ocfs2/cluster: Pin/unpin o2hb regions") Signed-off-by: Joseph Qi Cc: Changwei Ge Cc: Heming Zhao Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ce035f208d68b812d83e5482980f2b1c88a9cd94 Author: Joseph Qi Date: Wed Jul 22 20:49:31 2026 +0800 ocfs2: cluster: don't sleep while holding o2hb_live_lock in o2hb_region_pin() commit af09df89db9a68a1d76df0f75667998135bc8d65 upstream. Patch series "ocfs2: cluster: o2hb_region_pin() fixes", v2. This series fixes three related issues in o2hb_region_pin(), all are from the original implementation in commit: 58a3158a5d17 ("ocfs2/cluster: Pin/unpin o2hb regions"): 1) It is called with o2hb_live_lock (a spinlock) held, but the underlying configfs_depend_item() sleeps (takes inode rwsem and pins the filesystem). This triggers BUG under CONFIG_DEBUG_ATOMIC_SLEEP. 2) When called from the configfs drop_item callback, it creates a lock order inversion: parent inode_lock -> configfs root inode_lock, which can deadlock against subsystem unregistration paths taking root -> parent. 3) If pinning fails partway through o2hb_region_inc_user(), the o2hb_dependent_users counter is leaked and partially-pinned regions are never released, leaving heartbeat regions unprotected on subsequent mounts. Patch 1 reworks o2hb_region_pin() to drop o2hb_live_lock across each sleeping configfs_depend_item() call, using a config_item reference to keep the region alive while unlocked. Patch 2 adds a from_callback parameter to select configfs_depend_item_unlocked() when called from configfs context, avoiding the inode_lock nesting. Patch 3 fixes the error path in o2hb_region_inc_user() to unpin and decrement the counter on failure. This patch (of 3): o2hb_region_pin() is always called with the o2hb_live_lock spinlock held (from o2hb_region_inc_user() and o2hb_heartbeat_group_drop_item()), but it calls o2nm_depend_item() -> configfs_depend_item(), which sleeps: it pins the configfs filesystem and takes the configfs root inode rwsem. Under CONFIG_DEBUG_ATOMIC_SLEEP this triggers: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c in_atomic(): 1, ... name: mount.ocfs2 down_write configfs_depend_item o2hb_region_pin o2hb_region_inc_user o2hb_register_callback dlm_register_domain_handlers ... ocfs2_dlm_init ocfs2_mount_volume ocfs2_fill_super Rework o2hb_region_pin() to pin one region at a time with the lock dropped across the sleeping call: under o2hb_live_lock find the next eligible region and take a config_item reference to keep it alive, drop the lock, call o2nm_depend_item(), then retake the lock and record the pin. The config_item_put() is done with the lock released as well, since o2hb_region_release() also acquires o2hb_live_lock and can sleep. The region list may change while unlocked, so the scan restarts from the top after each pin. Local heartbeat still pins only the matching region; global heartbeat pins all eligible regions. The unpin path is unaffected: configfs_undepend_item() only takes a spinlock and does not sleep. Link: https://lore.kernel.org/20260722124933.430554-1-joseph.qi@linux.alibaba.com Link: https://lore.kernel.org/20260722124933.430554-2-joseph.qi@linux.alibaba.com Fixes: 58a3158a5d17 ("ocfs2/cluster: Pin/unpin o2hb regions") Signed-off-by: Joseph Qi Cc: Changwei Ge Cc: Heming Zhao Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 0761d2c9494424469a0d30a9da3496ca010b0b2d Author: Ibrahim Hashimov Date: Thu Jul 9 15:26:09 2026 +0200 ocfs2: validate rl_used against rl_count in refcount block validator commit 4ca62df6bc0708947b48da3f6a712ecb8e73929c upstream. ocfs2_find_refcount_rec_in_rl() walks the on-disk refcount record array with: for (; i < le16_to_cpu(rb->rf_records.rl_used); i++) { rec = &rb->rf_records.rl_recs[i]; ... rl_recs[] lives in a single metadata block (4096 bytes on the common configuration), so its real capacity is fixed by ocfs2_refcount_recs_per_rb(sb) (247 records for a 4K block with the 16-byte ocfs2_refcount_rec). rl_used and rl_count are both read directly off disk by ocfs2_validate_refcount_block() and are never checked against that capacity, nor against each other, before any refcount/reflink/CoW operation walks the array. A crafted (or corrupted) refcount block with rl_used == 0xffff makes the loop above walk far past the end of the block, dereferencing rl_recs[i] for i up to 65534. The resulting index is then handed to the sibling ocfs2_insert_refcount_rec(), whose insert-shift does: if (index < le16_to_cpu(rf_list->rl_used)) memmove(&rf_list->rl_recs[index + 1], &rf_list->rl_recs[index], (le16_to_cpu(rf_list->rl_used) - index) * sizeof(struct ocfs2_refcount_rec)); i.e. a memmove() of up to (0xffff - index) * 16 bytes (~1 MiB) from an offset already past the block. This is reachable from an ordinary reflink (FICLONE) against a crafted/corrupted ocfs2 image: attaching an extent whose cpos sorts past every real record in the leaf forces the lookup to run off the end instead of returning early on a match. The attacker model is local: CAP_SYS_ADMIN mounting a crafted or corrupted ocfs2 image, or a raw write to the block device backing an already-mounted ocfs2 filesystem. ocfs2_validate_refcount_block() already validates the block's ECC, signature, rf_blkno and rf_fs_generation, but never rl_count/rl_used against the block's actual on-disk capacity. This is the same class of gap that ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) already closes for the sibling extent-list header, which checks both the record capacity and the "used" bound before any code walks h_list.l_recs[]: if (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) { rc = ocfs2_error(...); goto bail; } if (le16_to_cpu(eb->h_list.l_next_free_rec) > le16_to_cpu(eb->h_list.l_count)) { rc = ocfs2_error(...); goto bail; } Add the equivalent pair of checks to ocfs2_validate_refcount_block(): reject a refcount block whose rl_count does not match the fixed per-block capacity returned by ocfs2_refcount_recs_per_rb(), and reject rl_used > rl_count. Both checks are skipped when OCFS2_REFCOUNT_TREE_FL is set, because in that case the same union bytes hold an ocfs2_extent_list (rf_list), not the refcount record list (rf_records) -- that layout is already validated separately by ocfs2_validate_extent_block() when the referenced extent block is read. This mirrors the existing "!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)" guard used elsewhere in this file (e.g. ocfs2_get_refcount_rec()) to decide whether rf_records or rf_list is the live member of the union. With this in place, a forged rl_used/rl_count is caught at block validation time (ocfs2_error()), consistent with every other corruption check in this function, instead of driving an out-of-bounds read in ocfs2_find_refcount_rec_in_rl() and a subsequent out-of-bounds memmove() in ocfs2_insert_refcount_rec(). Verified against a crafted image on a v6.19 KASAN (KASAN_GENERIC) build: replaying the same reflink (FICLONE) reliably hit a KASAN report in __ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() before this patch, and triggers no report once ocfs2_validate_refcount_block() rejects the forged rl_used/rl_count. Link: https://lore.kernel.org/20260709132609.44233-1-security@auditcode.ai Fixes: f2c870e3b12e ("ocfs2: Add ocfs2_read_refcount_block.") Signed-off-by: Ibrahim Hashimov Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Assisted-by: AuditCode-AI:2026.07 Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 50c4cc9183e11f83427efbf770f54851f4471c02 Author: Bryam Vargas Date: Mon Jun 29 00:01:44 2026 -0500 ocfs2: validate lengths in dlm_mig_lockres_handler commit b54e03d9b3697d25f4a0063cf717d459c5e3ad94 upstream. A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres->ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain. Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres->lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len <= DLM_LOCKID_NAME_MAX, num_locks <= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected. Link: https://lore.kernel.org/20260629-b4-disp-94fb6521-v1-2-6953bcc0421f@proton.me Fixes: 6714d8e86bf4 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Bryam Vargas Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit de10cd3b062a5235af754925fcf49beb5a1109d4 Author: Bryam Vargas Date: Mon Jun 29 00:01:43 2026 -0500 ocfs2: bound namelen in dlm_migrate_request_handler commit ea5b5609305a8437bc955a0834a530c12246d78f upstream. Patch series "ocfs2/dlm: bound peer-controlled lengths in the o2dlm". The o2dlm receive handlers trust u8 length and count fields from the wire without bounding them, so a node in a DLM domain can corrupt or panic any other node with a malformed message. Three defects: - dlm_migrate_request_handler() passes migrate->namelen unchecked to dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an o2dlm_mle slab object: a heap out-of-bounds write of up to ~215 attacker-controlled bytes. - dlm_mig_lockres_handler() passes mres->lockname_len unchecked to dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname slab object: a heap out-of-bounds write of up to ~223 bytes. - the same handler trusts mres->num_locks without checking that the message is large enough to hold that many entries, so dlm_process_recovery_data() walks mres->ml[] past the kmalloc(data_len) copy and trips a BUG_ON (an out-of-bounds read ending in a panic). The other o2dlm receive handlers already reject an oversized name; the migration and recovery handlers have omitted it since the DLM was added (see the Fixes tags). Patch 1 bounds namelen; patch 2 validates lockname_len, num_locks, and the payload size. Conforming recovery and migration traffic is unaffected. o2net authenticates peers only by the DLM domain key, so any node that has joined the domain -- including a compromised or malicious member -- can send these messages. There is no local trigger; the attacker must already be a member of the cluster. Each sink was confirmed under KASAN with an out-of-tree module mirroring it exactly -- a kmem_cache/kmalloc of the real destination size, then the same unclamped memcpy/loop: slab-out-of-bounds Write for the two writes, Read for the recovery walk, and a panic. A userspace AddressSanitizer build faults identically under -m32 and -m64. Scrubbed logs are available on request. I reported this privately to security@kernel.org and the ocfs2 maintainers on 2026-06-20; with no response after the standard embargo period I am posting the fix publicly. I have no embargo requirement. This patch (of 2): A node receiving a DLM_MIGRATE_REQUEST message trusts the peer-supplied name length (migrate->namelen) without bounding it. dlm_init_mle() then copies that many bytes into the fixed DLM_LOCKID_NAME_MAX-byte mname[] array of an o2dlm_mle slab object, so a malformed message from a cluster peer overflows the slab object by up to ~215 bytes: a heap out-of-bounds write of attacker-controlled data, reachable by any node in the domain. Reject an oversized name, the way dlm_master_request_handler() and the other o2dlm receive handlers already do; the migration handler omits the check entirely. Conforming messages are unaffected. Link: https://lore.kernel.org/20260629-b4-disp-94fb6521-v1-0-6953bcc0421f@proton.me Link: https://lore.kernel.org/20260629-b4-disp-94fb6521-v1-1-6953bcc0421f@proton.me Fixes: 6714d8e86bf4 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Bryam Vargas Reviewed-by: Joseph Qi Cc: Changwei Ge Cc: Heming Zhao Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 71f07b7f90b3109c9098d1b9c8efbbeece5deb8a Author: Dmitry Antipov Date: Tue Jul 21 13:28:40 2026 +0300 ocfs2: always run deallocs on copy-on-write completion commit 82ea9d4fc05fb7a387db547c6a7c0aa6a3719616 upstream. Local fuzzing of 6.12.94 has found the following memory leak caused by doing 'copy_file_range()' within the same filesystem: unreferenced object 0xffff88812192c980 (size 32): comm "syz.0.49", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................ c0 c5 92 21 81 88 ff ff 00 02 00 00 00 06 00 00 ...!............ backtrace (crc 7068d63f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] ocfs2_find_per_slot_free_list fs/ocfs2/alloc.c:6618 [inline] ocfs2_cache_block_dealloc+0x155/0x4b0 fs/ocfs2/alloc.c:6786 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:944 [inline] direct_splice_actor+0x232/0x480 fs/splice.c:1167 splice_direct_to_actor+0x4b4/0xb60 fs/splice.c:1111 do_splice_direct_actor fs/splice.c:1210 [inline] do_splice_direct+0x10f/0x1c0 fs/splice.c:1236 do_sendfile+0x430/0xbf0 fs/read_write.c:1388 unreferenced object 0xffff88812192c5c0 (size 32): comm "syz.0.49", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 29 70 00 00 00 00 00 00 19 00 00 00 00 00 00 00 )p.............. backtrace (crc afec850f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ocfs2_cache_block_dealloc+0x25c/0x4b0 fs/ocfs2/alloc.c:6793 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:944 [inline] direct_splice_actor+0x232/0x480 fs/splice.c:1167 splice_direct_to_actor+0x4b4/0xb60 fs/splice.c:1111 do_splice_direct_actor fs/splice.c:1210 [inline] do_splice_direct+0x10f/0x1c0 fs/splice.c:1236 do_sendfile+0x430/0xbf0 fs/read_write.c:1388 This happens when 'ocfs2_cache_block_dealloc()' called from 'ocfs2_cache_extent_block_free()' uses the suballocator to schedule extent removal, so 'ocfs2_run_deallocs()' should be run unconditionally to complete the removal with 'ocfs2_free_cached_blocks()'. An extra semi-automated static analysis [1] suspects that the same scenario looks possible in 'ocfs2_attach_refcount_tree()' and 'ocfs2_reflink_remap_blocks()' as well, but, since 'ocfs2_run_deallocs()' is a safe no-op for an empty dealloc context, 'ocfs2_create_reflink_node()' and 'ocfs2_reflink_xattrs()' may be adjusted in the same way too, thus keeping the code pattern consistent. Link: https://lore.kernel.org/20260721102840.387663-1-dmantipov@yandex.ru Link: https://lore.kernel.org/ocfs2-devel/f1d7e266-4b44-41b9-98c0-5b3868a8d9c3@yandex.ru [1] Fixes: 6f70fa519976 ("ocfs2: Add CoW support.") Signed-off-by: Dmitry Antipov Suggested-by: Joseph Qi Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 116d14f29a0524853c9316f32a2ac06cff5d4bf6 Author: Zhiling Zou Date: Fri Jul 24 02:01:46 2026 +0800 orangefs: skip leading spaces before parsing client debug masks commit d410cd5303ec59c7cf23dd61423752ce8e9ecb59 upstream. orangefs_prepare_cdm_array() sizes each client debug keyword buffer with strcspn(cds_head, " "), but then parses the keyword with %s. The %s conversion skips leading whitespace, while strcspn() does not. If a client debug entry starts with a space, the allocation can be sized for an empty keyword while sscanf() copies the following non-empty token. This can write past the end of the allocated keyword buffer. Skip leading spaces before computing the keyword length so the allocation matches the string parsed by sscanf(). Fixes: f7be4ee07fb7 ("Orangefs: kernel client part 4") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: Codex:gpt-5.4 Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Signed-off-by: Mike Marshall Signed-off-by: Greg Kroah-Hartman commit f796f38a324e89547738f4b70cc33be5be2bc6da Author: Yifei Gao Date: Mon Aug 3 01:07:55 2026 +0000 orangefs: fix double-free of trailer_buf on readdir copy failure commit f574296be7f46eb60beca851240b526df232f480 upstream. On a readdir downcall, orangefs_devreq_write_iter() frees op->downcall.trailer_buf with vfree() when copy_from_iter_full() fails, but does not clear the pointer before goto Efault. The waiter in do_readdir() is then woken with a negative status and frees the same pointer again on its r < 0 path, causing a deterministic double-free. A client holding /dev/pvfs2-req triggers it by sending a readdir downcall whose declared trailer_size exceeds the bytes it supplies. Clear the pointer after freeing so the readdir-side vfree() becomes a no-op. Fixes: 382f4581e67f ("orangefs: rewrite readdir to fix several bugs") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yifei Gao Signed-off-by: Mike Marshall Signed-off-by: Greg Kroah-Hartman commit bc6fdd425fdeb70715e98391273707ec3836baad Author: Shibo Zhu <3499129952@qq.com> Date: Wed Aug 19 00:18:39 2026 +0800 PM: sleep: Unblock runtime PM when device prepare fails commit cb258d651d747a7f7063d40f145418bee562ceaf upstream. device_prepare() blocks runtime PM for a device with runtime PM disabled before invoking its system-sleep ->prepare() callback. For a device that has never enabled runtime PM, this changes dev->power.last_status from RPM_INVALID to RPM_BLOCKED. If the callback returns an error, dpm_prepare() does not move the device to dpm_prepared_list. Consequently, the recovery path through dpm_complete() never calls device_complete() for the failing device. The error path drops the runtime PM usage reference, but does not clear RPM_BLOCKED. A later legitimate pm_runtime_enable() then reports: Attempt to enable runtime PM when it is blocked before clearing the stale state. Call pm_runtime_unblock() on the prepare error path before dropping the runtime PM reference, matching the cleanup performed by device_complete(). The issue was reproduced with a platform test device whose ->prepare() callback returns -EIO while runtime PM has never been enabled. Before the fix, last_status remained RPM_BLOCKED after the failed suspend and the first pm_runtime_enable() produced the warning above. With the fix, last_status is restored to RPM_INVALID and the warning is absent. Fixes: 3e5eee147b7b ("PM: Block enabling of runtime PM during system suspend") Cc: All applicable Signed-off-by: Shibo Zhu <3499129952@qq.com> Link: https://patch.msgid.link/tencent_C5AC0A02FC01F700E764F8C2E3ECE4F41009@qq.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 6fcb0b745a0b80df62eae4a93ce52a2d061f4ac2 Author: Vincent Donnefort Date: Thu Aug 13 14:11:44 2026 +0100 ring-buffer: Hold cpu_buffer::lock when resizing a subbuf commit 24974bd0da1b47fd56c975533ead50abf754e74d upstream. Because, ring_buffer_subbuf_order_set() can clear cpu_buffer->free_page, hold cpu_buffer->lock to prevent races with ring_buffer_alloc_read_page() and ring_buffer_free_read_page(). Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260813131152.3589632-3-vdonnefort@google.com Fixes: 8e7b58c27b3c ("ring-buffer: Just update the subbuffers when changing their allocation order") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260810125633.3344684-1-vdonnefort%40google.com # patch 3 Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 8c1ecdcdea738efe0494af908f12c0ae3a97fffa Author: Vincent Donnefort Date: Thu Aug 13 14:11:43 2026 +0100 ring-buffer: Free cpu_buffer::free_page with subbuf_order commit 234b1a72e9706fe20c08c96f4374ec8e83b934cb upstream. When sub-buffers use an order greater than 0, cpu_buffer->free_page is allocated with subbuf_order. Use the correct order for cpu_buffer->free_page. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260813131152.3589632-2-vdonnefort@google.com Fixes: f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260806211306.3704194-1-vdonnefort%40google.com # patch 3 Signed-off-by: Vincent Donnefort Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 2dc510957fe8fd098ab3c3147ebdf34d00cd2734 Author: Vincent Donnefort Date: Thu Aug 13 14:11:47 2026 +0100 ring-buffer: Fix subbuf resize race with ring_buffer_alloc_read_page() commit e743527c5bfdceda1095bc0a9e596e2aebb6a9c3 upstream. ring_buffer_alloc_read_page() is racy with ring_buffer_subbuf_order_set, it can allocate a reader page with an outdated order. This isn't a big issue, the user can still re-allocate a new reader page and try again. However, what is more problematic is if the value of subbuf_order changes in the middle of ring_buffer_alloc_read_page(). In that case, bpage->order might not match the actual allocated memory. Use bpage->order for the allocation to prevent this race. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260813131152.3589632-6-vdonnefort@google.com Fixes: bce761d75745 ("ring-buffer: Read and write to ring buffers with custom sub buffer size") Reported-by: Sashiko Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 1c3036a81800560b98908cf8267a61ec41a9a238 Author: Kathiravan Thirumoorthy Date: Wed Jun 17 23:08:43 2026 +0530 regulator: qcom-refgen: correct the regulator type to CURRENT commit 05dfeb2d0ccf87a7b92cd149a393b8423a26a04e upstream. As per the REFGEN IP team, this block supplies the reference current to the PHYs in the SoC. So, correct the regulator type to REGULATOR_CURRENT to match with the HW behavior. Fixes: 7cbfbe237960 ("regulator: Introduce Qualcomm REFGEN regulator driver") Cc: stable@vger.kernel.org Reviewed-by: Konrad Dybcio Signed-off-by: Kathiravan Thirumoorthy Link: https://patch.msgid.link/20260617-ipq9650_refgen-v4-1-c505ea6c6661@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 20e5fbb8c1a4c0096ebe42a73d927f0146453223 Author: WenTao Liang Date: Sat Jun 27 00:03:26 2026 +0800 regulator: max8998_pmic_dt_parse_pdata: of_node_put on reg_np after ownership transferred to rdata commit 7c8cc25d8d86f9eb3979255935cfdc7d062ad746 upstream. In max8998_pmic_dt_parse_pdata(), of_get_child_by_name() acquires a reference on reg_np which is then stored in rdata->reg_node, transferring ownership to the regulator data array. The subsequent of_node_put(reg_np) at the end of the function releases the last matched regulator node's reference, leaving rdata->reg_node as a dangling pointer for the last entry. Remove the spurious of_node_put(reg_np) call. Cc: stable@vger.kernel.org Fixes: 156f252857df ("drivers: regulator: add Maxim 8998 driver") Signed-off-by: WenTao Liang Link: https://patch.msgid.link/20260626160326.54457-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 95342d26f9c6b68a46ab57fa48428a3c4a423dd7 Author: WenTao Liang Date: Sat Jun 27 00:01:50 2026 +0800 regulator: as3722_get_regulator_dt_data: fix premature of_node_put leaving dangling of_node pointer commit f9324d670ae0b88cbfb0aa48fcaefa5baeb8da4c upstream. In as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a reference on np, which is then assigned to pdev->dev.of_node. The function immediately calls of_node_put(np), releasing the reference and leaving pdev->dev.of_node as a dangling pointer. Remove the of_node_put(np) call to let the device hold the reference. Cc: stable@vger.kernel.org Fixes: bc407334e9a6 ("regulator: as3722: add regulator driver for AMS AS3722") Signed-off-by: WenTao Liang Link: https://patch.msgid.link/20260626160150.54291-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 71d5c41ac583df09a7c32199bef7d42de7267d07 Author: Jason Gunthorpe Date: Thu Jul 2 13:47:10 2026 -0300 RDMA/uverbs: Add UVERBS_ATTR_UHW to UVERBS_METHOD_REG_MR commit 011199f46f44a9fd93a9e5ab5d7fd1328d80e9bf upstream. The original commit missed that three drivers (mthca, irdma, siw) have UHW data associated with reg_mr that cannot be passed through the ioctl. They also assume that the udata cannot be NULL, so failing to pass a valid udata can trigger a NULL udata crash in those drivers. This never happens in real systems since in rdma-core ibv_cmd_reg_mr_ex() does not accept a udata and those three drivers don't use it, however a malicious userspace could trigger it. Cc: stable@vger.kernel.org Fixes: 5b2e45049dc0 ("IB/core: Add UVERBS_METHOD_REG_MR on the MR object") Reported-by: Jacob Moroni Closes: https://lore.kernel.org/all/CAHYDg1TOGxRGZrS69d4Y--Shj_DZv0nJuM73iHUBwBM70g_t3Q@mail.gmail.com Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 4f8bb11dd2ff365e7cff1c9964ab4607292d364e Author: Norbert Szetei Date: Mon Jul 27 10:06:12 2026 +0200 RDMA/ucma: Lock the handler in ucma_write_cm_event() commit f4cc21c6a8e9d392871477f9fd98d68e5ad80272 upstream. ctx->file may only be changed under the handler lock and the xa_lock, which is what stops uevents being queued for a ctx while ucma_migrate_id() moves it to another file. The CM core takes that lock before invoking ucma_event_handler(), but the write() paths that queue uevents themselves do not. ucma_write_cm_event() re-reads ctx->file for each of its four dereferences, so ucma_migrate_id() can swap it mid-sequence: mutex_lock(&ctx->file->mut); /* file A */ list_add_tail(&uevent->list, &ctx->file->event_list); /* file B */ mutex_unlock(&ctx->file->mut); /* file B */ wake_up_interruptible(&ctx->file->poll_wait); /* file B */ The window is the mutex_lock() itself: the writer sleeps in it while the migration reassigns ctx->file. The list_add_tail() then runs on file B's event_list holding only file A's mutex: list_add corruption. prev->next should be next (ffff888101320f30), but was ffff88814a08c418. (prev=ffff88814a075c18). kernel BUG at lib/list_debug.c:32! Call Trace: ucma_write_cm_event+0x36e/0x5e0 and file A's mut is left held forever, wedging its next writer in D state. The uevent is also stranded on a list ucma_cleanup_ctx_events() will not walk, so it outlives its context. /dev/infiniband/rdma_cm is 0666 and no RDMA device is involved, so an unprivileged user reaches all of this. Take the handler lock, as ucma_cleanup_mc_events() does; ctx->cm_id is pinned by the ucma_get_ctx() reference. Fixes: a3c9d0fcd371 ("RDMA/ucma: Support write an event into a CM") Link: https://patch.msgid.link/r/60544A67-EFD6-4D5D-974C-D983445F1070@doyensec.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 28ac2dd416482d1c763c4af5d61af465b387fb50 Author: Norbert Szetei Date: Mon Jul 27 10:08:36 2026 +0200 RDMA/ucma: Lock the handler in ucma_set_ib_path() commit ecbe7d36dc2de07e5dfbb4a8ff5b315ab43de820 upstream. ucma_set_ib_path() calls ucma_event_handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference: mutex_lock(&ctx->file->mut); /* file A */ list_add_tail(&uevent->list, &ctx->file->event_list); /* file B */ mutex_unlock(&ctx->file->mut); /* file B */ wake_up_interruptible(&ctx->file->poll_wait); /* file B */ A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION caller sleeps in mutex_lock(), so the list_add_tail() lands on file B's event_list while only file A's mutex is held, racing every other user of that list: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0 Read of size 8 at addr ffff888153c6a418 by task poc_corr/486 Call Trace: __list_add_valid_or_report+0x1aa/0x1c0 ucma_event_handler+0x1be/0xc00 ucma_set_ib_path+0x45e/0x710 ucma_set_option+0x32e/0x590 ucma_write+0x1f9/0x330 Allocated by task 505: ucma_write_cm_event+0x1a1/0x660 Freed by task 505: kfree+0x1da/0x4c0 ucma_get_event+0x5d5/0x7e0 The freed object is a ucma_event that another thread dequeued from file B's list under file B's mutex. File A's mut is left held on top of that, wedging its next writer in uninterruptible sleep. This path needs a bound and address-resolved cm_id, so it requires an RDMA device to be present. Take the handler lock around the call. Fixes: 09e328e47a69 ("RDMA/ucma: Fix the locking of ctx->file") Link: https://patch.msgid.link/r/2823D190-92D5-4714-8769-4FB643C64FF3@doyensec.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit a38cd610b24f72c2eb712e276ae30221aaeec74d Author: Brett Creeley Date: Wed Aug 5 11:02:53 2026 +0530 RDMA/ionic: Cap eq_count to the eth driver's interrupt vector budget commit 1d0f877d593438a494ca5b05cc8699150409005a upstream. ionic_fill_lif_cfg() reads eq_count from firmware uncapped, but the eth driver only reserves ionic->neqs_per_lif MSI-X vectors for RDMA event queues. Since ionic_rdma probes via the auxiliary bus before the netdev is brought up, it can exhaust the shared interrupt bitmap, causing ionic_open() to fail with -ENOSPC when allocating rx/tx interrupts. Cap RDMA eq_count to neqs_per_lif, which is populated by ionic_lif_size() at PCI probe before the RDMA aux device registers. Fixes: 8d765af51a09 ("RDMA/ionic: Register auxiliary module for ionic ethernet adapter") Cc: stable@vger.kernel.org Signed-off-by: Brett Creeley Signed-off-by: Abhijit Gangurde Link: https://patch.msgid.link/20260805053254.4023262-1-abhijit.gangurde@amd.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 85f438382a865a4dc4c50e6b884310bb2b60fc4d Author: Fan Wu Date: Thu Aug 6 13:01:27 2026 +0000 RDMA/cxgb4: Cancel reg_work before freeing device on remove commit a7100601aa1a39f799a566acce10db20eaf4b7f2 upstream. c4iw_uld_state_change() queues reg_work to register the RDMA device. c4iw_remove() can free ctx->dev while this work is pending or running, leaving c4iw_register_device() accessing the freed device. Cancel reg_work before removing the device. The registration work can tear down ctx->dev when registration fails, so do not unregister or deallocate it again in that case. This issue was found by an in-house static analysis tool. Fixes: 1c8f1da5d851 ("iw_cxgb4: Fix possible circular dependency locking warning") Link: https://patch.msgid.link/r/20260806130128.465460-1-fanwu01@zju.edu.cn Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 2a952fb1b20d83e83ca852773e6188511f7d2191 Author: Vaibhav Nagare Date: Tue Aug 18 13:03:09 2026 +0530 qede: Fix NULL pointer dereference in TPA fragment processing commit 06aa3d26327f24edd039ff249672fdf6f2ba5695 upstream. Under memory pressure, the qede driver encounters NULL pointer dereferences when processing TPA continuation fragments. Commit 8a8633978b84 ("qede: Add build_skb() support.") accidentally dropped the assignment of tpa_info->buffer.data in qede_tpa_start(). When memory pressure causes an SKB allocation failure in qede_tpa_start(), the driver sets tpa_start_fail = true and attempts to recycle the physical page later in qede_tpa_end() via qede_reuse_page(). However, because buffer.data was left uninitialized (NULL), qede_reuse_page() pushes a "ghost" BD (valid DMA mapping but NULL data pointer) back into the active Rx ring. The next time the hardware uses this ring slot, it passes a NULL page to qede_fill_frag_skb(), causing a kernel panic. Example crash from production system: BUG: unable to handle kernel NULL pointer dereference at 0x8 RIP: qede_fill_frag_skb+0x96/0x430 [qede] Call Trace: qede_rx_int+0xb06/0x1de0 qede_poll+0x2f4/0x6c0 __napi_poll+0x2d/0x130 Fix the root cause by restoring the tpa_info->buffer.data assignment in qede_tpa_start(), ensuring valid pages are correctly tracked and recycled. Additionally, update the stale comment for struct qede_agg_info::buffer to reflect its current usage. Fixes: 8a8633978b84 ("qede: Add build_skb() support.") Cc: stable@vger.kernel.org Signed-off-by: Vaibhav Nagare Link: https://patch.msgid.link/20260818073309.2266072-1-vnagare@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3f5677d2f817355147337f0453174c7bb0f3b66a Author: Abdifatah Suruur Date: Thu Aug 13 20:47:07 2026 +0300 ptp: vmclock: prevent read-only mappings from becoming writable commit a5edadbae57e2298a56cf7a4e774a027905a331f upstream. vmclock_miscdev_mmap() rejects writable mappings of the shared vmclock ABI page with -EROFS, but leaves VM_MAYWRITE set. Userspace can map the page read-only and then upgrade it to writable with mprotect(), after which the guest can corrupt the host-written timekeeping data (sequence counter, UTC time, TSC offset) that the vmclock ABI defines as read-only. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 does for its read-only objects and as fixed in drm/vc4 (CVE-2026-68445) and drm/panthor (CVE-2024-53071). Cc: stable@vger.kernel.org Fixes: 205032724226 ("ptp: Add support for the AMZNC10C 'vmclock' device") Signed-off-by: Abdifatah Suruur Link: https://patch.msgid.link/20260813174707.14809-1-suruurism@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c7e32814a6bf20f792d05f0bc9f94f0606311bc6 Author: Johan Hovold Date: Mon Jul 6 08:56:14 2026 +0200 remoteproc: scp: Fix device reference leak on failed lookup commit 22f9efb3ae07f966a1901d929d16df1388cce65c upstream. Make sure to drop the reference taken to the SCP device when attempting to look up its driver data before the driver has been bound. Note that holding a reference to a device does not prevent its driver data from going away. Fixes: 63c13d61eafe ("remoteproc/mediatek: add SCP support for mt8183") Cc: stable@vger.kernel.org # 5.6 Cc: Erin Lo Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20260706065614.389412-1-johan@kernel.org Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 37797d5013c9e719323e3e23c68cbd1807a6d648 Author: Nam Cao Date: Fri Aug 7 19:24:30 2026 -0600 riscv: unaligned: stop using kthread for check_vector_unaligned_access() commit 34c9cfcde29b938c416924ee6ec3519270bc2238 upstream. A kthread is used to run check_vector_unaligned_access() to optimize boot time, allowing the kernel to continue booting without waiting for the unaligned vector speed probe to finish. However, this asynchronous approach introduces several complications. First, the kthread may not complete before a user reads vDSO data, resulting in incorrect values. This was previously addressed by commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot"), which added complex synchronization between the kthread and vDSO reads. Second, it was discovered that the kthread may not finish before vec_check_unaligned_access_speed_all_cpus() (marked with __init) is freed, triggering a page fault. These issues raise the question of whether the kthread is worth the added complexity. A past boot time regression report was actually unrelated to synchronous probing; it was caused by the probe running serially. Since switching to a parallel probe, no further complaints have been made. Furthermore, the unaligned scalar access speed probe takes the same amount of time, runs synchronously, and has caused no issues. Testing shows no noticeable boot time slowdown when running the vector probe synchronously (0.464474s with kthread vs. 0.457991s without). Remove the kthread usage and run the probe synchronously. This simplifies the boot flow and allows for the revert of commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot") Reported-by: Anirudh Srinivasan Closes: https://lore.kernel.org/linux-riscv/20260612-vec_unaligned_drop_init-v1-1-df969210ae34@oss.tenstorrent.com/ Fixes: e7c9d66e313b ("RISC-V: Report vector unaligned access speed hwprobe") Cc: stable@vger.kernel.org Signed-off-by: Nam Cao Acked-by: Jesse Taube Tested-by: Anirudh Srinivasan Link: https://patch.msgid.link/1c378963f27c5960e8a57c50b8b444d30954cb54.1781666867.git.namcao@linutronix.de [pjw@kernel.org: updated to apply; adjusted Fixes: tag; fixed my own manual patch application error] Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 8f392916a3540506a3377ad421fa9e62c2ff6826 Author: Peixin Xie Date: Fri Aug 7 19:24:32 2026 -0600 riscv: acpi: Handle LPI architectural context loss flags commit 7e4cb63d61a7e0bef20f0d00e831c7fac06e4a1c upstream. Commit 4785aa802853 ("cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer") replaced the generic nonzero check for LPI architectural context loss flags with arch_get_idle_state_flags(). RISC-V does not implement the helper, so it falls back to the stub that returns 0. Consequently, CPUIDLE_FLAG_TIMER_STOP is not set when an LPI state loses the hart timer context, preventing cpuidle from using a broadcast timer for that state. Implement the RISC-V helper and map the hart timer context loss flag to CPUIDLE_FLAG_TIMER_STOP. Fixes: 4785aa802853 ("cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer") Cc: stable@vger.kernel.org Acked-by: Sudeep Holla Reviewed-by: Yixun Lan Reviewed-by: Sunil V L Reviewed-by: Huisong Li Signed-off-by: Peixin Xie Link: https://patch.msgid.link/20260803-riscv-acpi-lpi-timer-v3-1-520fa13732f5@linux.spacemit.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 5343399ed72420ae7f9f45dd82ff99739d57ecfe Author: Fabio Estevam Date: Thu Jul 2 23:56:48 2026 -0300 arm64: dts: rockchip: Fix rk3588s-roc-pc audio description commit b4db45b3ec97a9d0d23446084f45e095b2ba2020 upstream. The rk3588s-roc-pc ES8388 codec is connected to the i2s0_8ch audio interface. Use the matching I2S0 MCLK output for the codec clock instead of I2S1. Using the I2S1 MCLK can leave the ALSA PCM running while the codec has no usable master clock for the active audio path, resulting in silent headphone output. Also make the CPU DAI provide bitclock and frame clock. This matches the active Rockchip I2S controller side and avoids relying on the codec to drive the bus clocks. Route the headphone output to LOUT2 and ROUT2, matching the old 5.10 BSP device tree. LOUT1 and ROUT1 are used for the speaker route there, so using them for the headphone widget can leave the headphone jack silent even while the ALSA path is active. The old BSP also used hp-con-gpio on GPIO1_A4. Model that GPIO as a simple audio amplifier so DAPM enables the headphone connection when the headphone path is active. Cc: stable@vger.kernel.org Fixes: 7f9509791507 ("arm64: dts: rockchip: add DTs for Firefly ROC-RK3588S-PC") Signed-off-by: Fabio Estevam Link: https://patch.msgid.link/20260703025648.180135-1-festevam@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit 8fc4bafabc06586e5e4ce4c3773926cced63a943 Author: Fabio Estevam Date: Thu Jul 16 22:07:34 2026 -0300 arm64: dts: rockchip: Fix rk3399-roc-pc-plus analog audio commit 4f7259ebe1eba4778768a4f5a0bbbe439d10f3f3 upstream. The ES8388 sound card on the rk3399-roc-pc-plus fails to probe because i2s1 cannot claim its MCLK pin: pinctrl: pin gpio4-0 already requested by ff880000.i2s; cannot claim for ff890000.i2s pinctrl: error -EINVAL: pin-128 (ff890000.i2s) pinctrl: error -EINVAL: could not request pin 128 (gpio4-0) from group i2s-8ch-mclk-pin on device rockchip-pinctrl GPIO4_A0 is routed as SCLK_I2S_8CH_OUT and is used by i2s1 as the external MCLK for the ES8388 codec. The board dts already removes GPIO4_A0 from the i2s0_8ch_bus pin group, but i2s0 still claims the same pin through its bclk_off state. Since the i2s driver requests both states, this blocks i2s1 pinctrl setup and leaves the simple-audio-card deferred with a parse error. Override i2s0_8ch_bus_bclk_off as well, matching the existing i2s0_8ch_bus override, so GPIO4_A0 is left for i2s1/ES8388 audio. Cc: stable@vger.kernel.org Fixes: 6d9a7bd6a13c ("arm64: dts: rockchip: add support for Firefly ROC-RK3399-PC-PLUS") Signed-off-by: Fabio Estevam Link: https://patch.msgid.link/20260717010736.578419-1-festevam@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit 650d2d5c0df7e4be6f099430bb596970026070e8 Author: Jakob Unterwurzacher Date: Tue Jun 9 10:17:25 2026 +0200 arm64: dts: rockchip: fix emmc reset polarity on px30-cobra commit 85babf47515e2adf266dcc3be9804e31f752083e upstream. Technically, the reset signal is active low - it's called RST_n after all. But it is ignored completely unless RST_n_FUNCTION=1 (byte 162 in extcsd) is set in the emmc. It is 0 per default. For emmcs that have RST_n_FUNCTION=1 we failed like this: [ 3.074480] mmc1: Failed to initialize a non-removable card With this change they work normally. Cc: stable@vger.kernel.org Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants") Signed-off-by: Jakob Unterwurzacher Tested-by: Quentin Schulz Reviewed-by: Quentin Schulz Link: https://patch.msgid.link/20260609081728.30616-2-jakobunt@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit 5512c23231206fe5177471db89ec605c51e4097c Author: Quentin Schulz Date: Fri Jun 26 16:40:38 2026 +0200 arm64: dts: rockchip: fix eMMC reset polarity on PX30 Ringneck commit dfe078755706ed50651ebbe0442843ecd4ae8389 upstream. According to the Jedec 5.1 specification, the device is held in reset when RST_n is low, therefore the polarity of the line must be that, as specified in the Device Tree binding (mmc/mmc-pwrseq-emmc.yaml). Due to the wrong polarity, eMMC devices with RST_n_FUNCTION[162] bitfield [1:0] set to 0x1 (the default is 0x0) will be held in reset forever. Cc: stable@vger.kernel.org Fixes: c484cf93f61b ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard") Signed-off-by: Quentin Schulz Link: https://patch.msgid.link/20260626-ringneck-emmc-polarity-v1-1-90cefe57b316@cherry.de Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit fe455c13bf01e4d40276f94996774ae32f5bc94a Author: Quentin Schulz Date: Fri Jun 12 18:47:34 2026 +0200 arm64: dts: rockchip: fix eMMC reset polarity on PP-1516 commit 2a08921edcab6a462fa6ddb02c91b90b5ac92429 upstream. According to the Jedec 5.1 specification, the device is held in reset when RST_n is low, therefore the polarity of the line must be that, as specified in the Device Tree binding (mmc/mmc-pwrseq-emmc.yaml). Due to the wrong polarity, eMMC devices with RST_n_FUNCTION[162] bitfield [1:0] set to 0x1 (the default is 0x0) will be held in reset forever. Cc: stable@vger.kernel.org Fixes: 56198acdbf0d ("arm64: dts: rockchip: add px30-pp1516 base dtsi and board variants") Signed-off-by: Quentin Schulz Link: https://patch.msgid.link/20260612-pp1516-emmc-polarity-v1-1-4816c1c909f7@cherry.de Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit b6b3e4d5973bda6ac97486efdbbda4d6d034261e Author: Michael Scott Date: Wed May 20 18:09:34 2026 -0700 arm64: dts: qcom: x1-dell-thena: mark l12b and l15b always-on commit 06c8fc3e132ce8659bc9f0877b5c6daaf41aadbd upstream. The l12b and l15b supplies are used by components that are not (fully) described (and some never will be) and must never be disabled. Mark the regulators as always-on to prevent them from being disabled, for example, when consumers probe defer or suspend. Note that these supplies currently have no consumers described in mainline for dell-thena beyond the audio codec (vdd-buck/vdd-rxtx/ vdd-io on wcd938x), which can release them when the codec goes idle. The board-level gpio-fixed regulators that feed the Type-C retimer's VDDIO and other rails are not described with a vin-supply link, so the kernel cannot keep their parent LDOs alive on its own. This mirrors the same change Johan Hovold applied to every other X1E80100 board in a March 2025 series; commit 63169c07d740 ("arm64: dts: qcom: x1e80100-dell-xps13-9345: mark l12b and l15b always-on") is representative. The dell-thena board file was introduced four months later and did not inherit that change; this patch closes the gap. Fixes: e7733b42111c ("arm64: dts: qcom: Add support for Dell Inspiron 7441 / Latitude 7455") Cc: stable@vger.kernel.org Signed-off-by: Michael Scott Reviewed-by: Konrad Dybcio Acked-by: Val Packett Link: https://lore.kernel.org/r/20260521010935.1333494-4-mike.scott@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 6bb9469c34fff08bebfbf2e6d27a916dd963f0d8 Author: Krzysztof Kozlowski Date: Mon Apr 13 11:05:28 2026 +0200 arm64: dts: qcom: sm6115-pro1x: Correct touchscreen GPIO flags commit 8e73ae5c34e4fbbd25a8324e3c0eb1e845d7f01e upstream. IRQ_TYPE_xxx flags are not correct in the context of GPIO flags. These are simple defines so they could be used in DTS but they will not have the same meaning: IRQ_TYPE_LEVEL_LOW = 8 = GPIO_TRANSITORY. Correct the touchscreen irq-gpios to use proper flags, assuming the author of the code wanted similar logical behavior: IRQ_TYPE_LEVEL_LOW => GPIO_ACTIVE_LOW Fixes: e46b455e67f8 ("arm64: dts: qcom: sm6115-pro1x: Add Goodix Touchscreen") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260413090527.53000-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit ff23eb4823d82adc01174293fd3e8a1610fe9794 Author: Oren Klopfer Date: Fri Jul 3 16:10:10 2026 -0400 Revert "arm64: dts: rockchip: Further describe the WiFi for the Pinephone Pro" commit 5f19535351bf28f28d702f452d11a1216ec2bd28 upstream. This reverts commit 096bd8c679185f898cae9933c6a68650fa26ea4f. Just as with the Pinebook Pro, there are multiple chipset variants for the Pinephone Pro, and multiple firmware binaries for different distributions. The change causes issues with some of these combinations, and reverting it resolves the issues. See the Closes below for the full report. Similarly with the Pinebook Pro adjustment, the original commit only indicates "further description" and not indicative of fixing any existing issues, so reverting should not kick any back up. Fixes: 096bd8c67918 ("arm64: dts: rockchip: Further describe the WiFi for the Pinephone Pro") Cc: Heiko Stuebner Cc: Peter Robinson Cc: Thorsten Leemhuis Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/r/20260607225901.64019-1-oklopfer37@gmail.com/ Signed-off-by: Oren Klopfer Link: https://patch.msgid.link/20260703201010.67311-1-oklopfer37@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit eb57632f9418f34c05394945a931fa3a4a032533 Author: Chunkai Deng Date: Thu Jun 18 00:16:39 2026 -0700 rpmsg: glink: smem: order FIFO read after availability check commit 786439ad58763e04b91bc2ec5f590e463939f197 upstream. glink_smem_rx_peek() reads the RX FIFO payload after the caller has determined data is available via glink_smem_rx_avail(), which reads the remote-updated head index. A control dependency between the head read and the subsequent payload read does not order the two loads, so the CPU may speculatively read the FIFO before observing the head update and consume stale data the remote has not yet published. Add rmb() in glink_smem_rx_peek() before the memcpy_fromio() so the availability (head) read is ordered ahead of the FIFO payload read, matching the consumer pattern in Documentation/core-api/circular-buffers.rst. Fixes: caf989c350e8 ("rpmsg: glink: Introduce glink smem based transport") Cc: stable@vger.kernel.org Signed-off-by: Chunkai Deng Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260618-rpmsg-glink-smem-mb-v1-1-68a026453a69@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit e7143c3f4e5c0a7986733c6f27009274bf6c4264 Author: Petr Vaganov Date: Mon Jun 29 01:52:21 2026 +0700 scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables() commit 626147717bea776b61ed3631d2c26283760c4cc4 upstream. During fuzz testing, the following issue was discovered: BUG: KMSAN: uninit-value in __dma_map_sg_attrs+0x217/0x310 __dma_map_sg_attrs+0x217/0x310 dma_map_sg_attrs+0x4a/0x70 ata_qc_issue+0x9f8/0x1420 __ata_scsi_queuecmd+0x1657/0x1740 ata_scsi_queuecmd+0x79a/0x920 scsi_queue_rq+0x4472/0x4f40 blk_mq_dispatch_rq_list+0x1cca/0x3ee0 __blk_mq_sched_dispatch_requests+0x458/0x630 blk_mq_sched_dispatch_requests+0x15b/0x340 __blk_mq_run_hw_queue+0xe5/0x250 __blk_mq_delay_run_hw_queue+0x138/0x780 blk_mq_run_hw_queue+0x4bb/0x7e0 blk_mq_sched_insert_request+0x2a7/0x4c0 blk_execute_rq+0x497/0x8a0 sg_io+0xbe0/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Uninit was created at: __alloc_pages+0x5c0/0xc80 alloc_pages+0xe0e/0x1050 blk_rq_map_user_iov+0x2b77/0x6100 blk_rq_map_user_io+0x2fa/0x4d0 sg_io+0xad6/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Bytes 14-15 of 16 are uninitialized Memory access of size 16 starts at ffff88800cbdb000 When processing the last unaligned element of the scatterlist, it is supplemented with missing bytes in the amount of pad_len. These bytes remain uninitialized, which leads to a problem. Extend last_sg->length by pad_len first, then use sg_zero_buffer() to zero those pad_len bytes. sg_zero_buffer() uses sg_miter internally, which correctly handles sg entries spanning multiple pages and padding that crosses a page boundary. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 40b01b9bbdf5 ("block: update bio according to DMA alignment padding") Cc: stable@vger.kernel.org Signed-off-by: Petr Vaganov Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260628185229.37957-1-p.vaganov@ideco.ru Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 2a8dd9fd12f3f6b21207cec8f50c92cd428e6b81 Author: Cong Nguyen Date: Thu Jul 30 17:37:54 2026 +0700 media: staging/ipu7: fix async notifier UAF on probe error path commit d7f48aa7d60c65d3e6d5312c27f17d5525a245fb upstream. isys_register_devices() registers the V4L2 async notifier via isys_notifier_init(). If a subsequent probe step such as isys_fw_log_init() fails, isys_probe() jumps to the out_cleanup label which only calls isys_unregister_devices(). That helper tears down the video devices, subdevices, V4L2 device and media device, but never unregisters or cleans up the async notifier. As a result the notifier stays chained in the global notifier_list while the enclosing struct ipu7_isys is freed by devres, leading to list corruption and a use-after-free the next time the list is walked. The remove path already does the right thing by calling isys_notifier_cleanup() before isys_unregister_devices(). Mirror that on the probe error path so the notifier is unregistered and cleaned up before the device is torn down. Fixes: a516d36bdc3d ("media: staging/ipu7: add IPU7 input system device driver") Cc: stable@vger.kernel.org Signed-off-by: Cong Nguyen Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 7f6956b6dcd660a6a67e8eb80bf241ee470ab40d Author: Hao-Qun Huang Date: Tue Jul 7 23:24:25 2026 +0800 staging: media: tegra-video: vi: fix probe failure on skipped last port commit ae15adeed9f7ec54989175fe3c9e0815186821bc upstream. tegra_vi_channels_alloc() iterates over port nodes and skips those whose reg property cannot be read or whose remote endpoint fails v4l2_fwnode_endpoint_parse(), leaving the negative result of the failed call in ret. If that happens on the last port node, the loop ends with ret still negative and tegra_vi_init() fails the whole VI probe. The same defective port earlier in the ports node is skipped silently, so probing succeeds or fails depending on the order of the port nodes. The CSI equivalent, tegra_csi_channels_alloc(), returns 0 unconditionally after its loop and does not have this problem. Use a separate variable for the per-port checks so that only fatal errors end up in ret. Fixes: 1ebaeb09830f ("media: tegra-video: Add support for external sensor capture") Fixes: 2ac4035a78c9 ("media: tegra-video: Add support for x8 captures with gang ports") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Hao-Qun Huang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 656d047dc0c29c0964d840217a0593f16aa9bc5e Author: Hao-Qun Huang Date: Tue Jul 7 23:03:26 2026 +0800 staging: media: tegra-video: fix of_node_put() on VIP parse errors commit 7393372f79db940acff206b43e2905685a0c57ad upstream. tegra_vip_channel_of_parse() initializes np from dev->of_node without taking a reference, but its error paths drop one through the err_node_put label. This underflows the refcount of the VIP device's OF node when endpoint parsing fails on a malformed device tree. The only reference the function takes on np is the success-path of_node_get() stored in vip->chan.of_node, and that one is already released by the tegra_vip_init() error path and by tegra_vip_exit(). Return errors directly instead of jumping to the bogus cleanup label. Fixes: e740d199cf0f ("staging: media: tegra-video: add support for Tegra20 parallel input") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Hao-Qun Huang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5be6d02837d418bc6c805b5cab1b338de6de9ca7 Author: Wentao Guan Date: Tue Jun 30 17:02:18 2026 +0800 wifi: mt76: mt7925: cancel pending mlo_pm_work commit 2889e84282dda147f10b10d94cf0efd90a349c53 upstream. If the device is reset, suspended or unregistered within that window, the pending work can still run and access vif/bss data that may already be freed, or send MCU commands while the firmware is not available. Add cancel_delayed_work_sync(&dev->mlo_pm_work) in all relevant teardown and suspend paths: - mt7925_mac_reset_work() (chip reset recovery) - mt7925e_unregister_device() (PCIe unbind) - mt7925_pci_suspend() (PCIe bus suspend) - mt7925_suspend() (mac80211 suspend) - mt7925u_suspend() (USB bus / runtime suspend) This ensures the work is stopped before the device state becomes invalid. Assisted-by: kimi-cli:kimi-k2.7 code Assisted-by: atomcode:glm-5.2 #Reported-by Fixes: 276a568832577 ("wifi: mt76: mt7925: update the power-saving flow") Cc: stable@vger.kernel.org Signed-off-by: Wentao Guan Link: https://patch.msgid.link/20260630090218.3202029-1-guanwentao@uniontech.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit e1330d719c047c4d8190a16be034b29fc601a815 Author: Doruk Tan Ozturk Date: Mon Jul 13 23:32:51 2026 +0200 wifi: ath6kl: clamp assoc request/response lengths before subtracting IE offsets commit 3bbd05723d15dd06f0560bcd94fbf9a91b5f5613 upstream. ath6kl_cfg80211_connect_event() subtracts fixed IE offsets from assoc_req_len (-= 4) and assoc_resp_len (-= 6), both u8, with no lower bound. The aggregate check recently added to ath6kl_wmi_connect_event_rx() bounds the declared lengths from above (their sum must fit the received event), but an assoc request/response shorter than its fixed offset still underflows here: the u8 wraps to ~250, and cfg80211_connect_result() / cfg80211_roamed() then treat that wrapped value as the IE length and copy that many bytes out of the small assoc_info buffer to user space via nl80211, disclosing adjacent slab memory. Clamp both lengths to their offsets before subtracting. Found by 0sec (https://0sec.ai) using automated source analysis; the missing lower bound is evident from source. Compile-tested. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Cc: stable@vger.kernel.org Assisted-by: 0sec:claude-opus-4-8 Signed-off-by: Doruk Tan Ozturk Link: https://patch.msgid.link/20260713213251.21161-1-doruk@0sec.ai Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit b95c33a4e743874f1b0a45bf2aaa4da553552bd1 Author: David Lee Date: Wed Jul 8 10:17:09 2026 +0000 udf: reject VAT indexes equal to the entry count commit cac0cb07f29ccfb373fd4a36c81e908ef3ce608c upstream. UDF 1.50 virtual partition mapping uses the VAT as an array of physical block mappings. s_num_entries stores the number of entries in that array, not the highest valid index. The valid VAT indexes are therefore below s_num_entries. udf_get_pblock_virt15() currently rejects only indexes greater than s_num_entries. A crafted image can request index s_num_entries, pass the bounds check, and make the kernel read one entry past the allocated VAT table. Change the check to reject block >= s_num_entries, so the count is handled as an exclusive upper bound. A crafted UDF image reproduced this on origin/master commit 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53 with a KASAN slab-out-of-bounds report in udf_get_pblock_virt15(). Trail of Bits has a reproducer that triggers kernel panic demonstrating the bug, and can share it if needed. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: David Lee Assisted-by: Codex:gpt-5.5 Link: https://patch.msgid.link/20260708101712.1706564-1-david.lee@trailofbits.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit f84ec84d8d4bc65f9ae23372570349687f66fa39 Author: Chuck Lever Date: Tue May 26 09:35:55 2026 -0400 svcrdma: Validate Read chunk positions before reconstruction commit 3779b7b9e7d1c8ba4738f9d327de3b0288cefe9b upstream. The RPC/RDMA Read chunk position field is supplied by the remote client and stored verbatim in the parsed chunk list. xdr_count_read_segments() checks only 4-byte alignment; it never compares the position against the received inline body length. In the single-chunk path, svc_rdma_read_complete_one() splits the head and tail kvecs at ch_position. A position past the inline body underflows the tail length, exposing adjacent slab memory to the upper XDR decoder. In the multi-chunk path, svc_rdma_read_multiple_chunks() computes gap lengths between chunks as unsigned subtractions from ch_position. Overlapping Read chunks cause these subtractions to underflow. A final position past the inline body likewise underflows the trailing gap length. svc_rdma_copy_inline_range() then copies past the receive buffer into request pages that are returned to the client through the Reply channel. Bound inline-range copies in svc_rdma_copy_inline_range() against the decoded inline RPC body saved in rc_saved_arg. Reject a single Read chunk positioned beyond that body, and reject multi-chunk lists where accumulated read bytes exceed the next chunk's position. Apply the same position and overlap checks in the call-chunk interleaving path. Fixes: d96962e6d0e2 ("svcrdma: Use the new parsed chunk list when pulling Read chunks") Cc: stable@vger.kernel.org Acked-by: Jeff Layton Link: https://patch.msgid.link/20260526-rpc-kernel-bugs-v1-1-e251306ccca9@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit a798714b58041e88716db3bf8fb03ae13eecd54a Author: Chris Mason Date: Tue May 26 09:35:59 2026 -0400 svcrdma: Reject Write/Reply chunks with segcount 0 commit 9808eb7656666acc7291bae9ab6b987bd16e47e0 upstream. A peer can send a Write or Reply chunk whose segcount field is zero. xdr_check_write_chunk() only rejects segcount > rc_maxpages, so zero passes the range check, and xdr_inline_decode(stream, 0) returns the current (non-NULL) cursor without advancing. The function returns true and pcl_alloc_write() then links a struct svc_rdma_chunk with ch_segcount == 0 onto rc_write_pcl or rc_reply_pcl. An earlier patch in this series made pcl_for_each_segment() safe for ch_segcount == 0, so this no longer drives the memory walk it used to. Rejecting the malformed frame at the decode boundary is still worthwhile as defense in depth: it keeps degenerate zero-segment chunks off the parsed chunk lists entirely, so any future consumer that walks ch_segments directly cannot observe one, and it makes the zero-floor easy to backport to trees where the macro change is more intrusive. RFC 8166 has no meaning for a Write/Reply chunk that describes no remote buffer, so no legitimate client is affected. xdr_check_reply_chunk() funnels Reply chunks through xdr_check_write_chunk() and inherits the same rejection. pcl_alloc_write() also links each chunk onto the parsed chunk list before filling its segment array. If a future change weakens the segcount-0 rejection, an incomplete chunk is visible to consumers during the fill loop. Reorder so that list_add_tail() follows the segment fill loop, ensuring only fully-populated chunks appear on the list. Fixes: 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data structure") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Acked-by: Jeff Layton Link: https://patch.msgid.link/20260526-rpc-kernel-bugs-v1-5-e251306ccca9@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 1949dd1576f7a8aa161b1330c6125df9d53046d5 Author: Chuck Lever Date: Mon Jun 22 21:47:28 2026 -0400 svcrdma: Reject inline replies that overflow the pull-up buffer commit 0fbe20dfe74b783d255bf389a6ea77aa25dc7860 upstream. An RPC-over-RDMA client can request a reply, such as an NFS READ payload, without providing a Write list or a Reply chunk to carry it. When such a reply needs more scatter/gather entries than the device's Send Queue supports, svc_rdma_pull_up_needed() selects pull-up and svc_rdma_pull_up_reply_msg() linearizes the whole reply into sctxt->sc_xprt_buf. That buffer is only sc_max_req_size bytes, while the reply on this path is bounded only by the client's request, so svc_rdma_xb_linearize() copies past the end of the buffer and corrupts adjacent slab memory. The oversized length is then stored in sc_sges[0].length and posted, so the device also reads beyond the mapped region. The SGE-exhaustion branch is the only pull-up path that can exceed the buffer: the threshold branch pulls up only replies smaller than RPCRDMA_PULLUP_THRESH, and replies that fit the device's SGE budget are sent directly without linearization. Make svc_rdma_pull_up_needed() report -E2BIG when the reply it would pull up cannot fit sc_max_req_size, and fail the request with ERR_CHUNK as RFC 8166 Section 4.5.3 directs rather than dropping the connection. The helper no longer answers a simple yes/no question: it now reports pull-up, no pull-up, or -E2BIG for a reply too large to linearize. Rename svc_rdma_pull_up_needed() to svc_rdma_check_pull_up() so its name no longer implies a boolean predicate. Fixes: e248aa7be86e ("svcrdma: Remove max_sge check at connect time") Cc: stable@vger.kernel.org Reported-by: Chris Mason Assisted-by: kres:claude-opus-4-7 Link: https://patch.msgid.link/20260623014728.826032-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 3cf372cec7ab2cd8c6002bf775cc14d90ccb098b Author: Chuck Lever Date: Wed May 27 11:00:14 2026 -0400 svcrdma: Reject connection when transport allocation fails commit 0944462247dcb7de7622cdaaadf5f05c52707dab upstream. handle_connect_req() returns without action when svc_rdma_create_xprt() fails to allocate the new transport. The CM core returns 0 for CONNECT_REQUEST events, so it does not destroy the new rdma_cm_id. Each allocation failure under memory pressure leaks one rdma_cm_id, and a remote peer driving connection attempts can amplify this. Reject the connection by returning a non-zero status from the CM event handler, which tells the CM core to destroy the orphaned cm_id. Fixes: 377f9b2f4529 ("rdma: SVCRDMA Core Transport Services") Cc: stable@vger.kernel.org Acked-by: Jeff Layton Link: https://patch.msgid.link/20260527-rdma-follow-on-v1-4-1b09bd87b6cd@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 5aabe070c00e5bdf4ab150fb5f72ad5f266d6241 Author: Chris Mason Date: Wed May 27 11:00:11 2026 -0400 svcrdma: Fix unmatched rn_unregister on failed accept commit 26190394c64c9429481fc88a4738f70bb92fb352 upstream. When svc_rdma_accept() takes the errout path before rpcrdma_rn_register() has succeeded, the existing cleanup block calls rpcrdma_rn_unregister(dev, &newxprt->sc_rn) unconditionally. svcxprt_rdma is kzalloc'd, so on that path sc_rn.rn_index is 0 and sc_rn.rn_done is NULL; the unregister therefore xa_erase()s another caller's slot 0 and performs an unmatched kref_put() on the rpcrdma_device's rd_kref. The same errout also brackets the cleanup with svc_xprt_get()/ svc_xprt_put() around the kref_init() birth reference. The kref goes 1 -> 2 -> 1 and never reaches 0, so the svcxprt_rdma (and the net/ns_tracker it pinned) is leaked on every failed accept. rpcrdma_rn_register() writes rn->rn_done last, only after xa_alloc() and kref_get() have both succeeded, so rn_done == NULL is a natural "never registered" sentinel. Guard rpcrdma_rn_unregister() with an early return when rn_done is NULL, and clear rn_done before the matching xa_erase() so a repeated unregister is also a no-op. With that guard in place, the accept errout drops the kref_init() birth reference via svc_xprt_put(), which dispatches svc_rdma_free(). Teardown of sc_qp, sc_sq_cq, sc_rq_cq, and sc_pd runs under existing IS_ERR/NULL guards in svc_rdma_free(); sc_rn is covered by the new rn_done sentinel; sc_cm_id is non-NULL on every errout path because svc_rdma_accept() dereferences it above the first goto errout. svc_xprt_free() drops the module reference associated with the freed transport, and svc_handle_xprt() drops its pre-acquired reference when ->xpo_accept() returns NULL. Take a replacement module reference before svc_xprt_put() so the two module_put()s remain balanced. The rn_done guard also covers svc_rdma_free()'s non-listener call to rpcrdma_rn_unregister() for transports whose register attempt failed or never ran. Fixes: 8ac6fcae5dc0 ("svcrdma: Unregister the device if svc_rdma_accept() fails") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Acked-by: Jeff Layton Link: https://patch.msgid.link/20260527-rdma-follow-on-v1-1-1b09bd87b6cd@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit a1c954ca4977a4e6ec73ef92fe48073ec54f9fc8 Author: Chris Mason Date: Tue May 26 09:35:58 2026 -0400 svcrdma: Fix pcl_for_each_segment for empty chunks commit b7713a784c59515d0aba558c8f5df6a0164dd3a9 upstream. When a parsed chunk list contains a chunk whose ch_segcount is zero, pcl_for_each_segment computes its inclusive upper bound as &chunk->ch_segments[ch_segcount - 1]. ch_segcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the ch_segments flex array. The loop body then walks unrelated memory at sizeof(struct svc_rdma_segment) stride until it faults. A zero-segcount chunk is reachable from the wire: xdr_check_write_chunk() only rejects segcount values greater than rc_maxpages, and pcl_alloc_write() links a freshly allocated chunk onto rc_write_pcl/rc_reply_pcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves ch_segcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svc_rdma_get_inv_rkey() iterates all four PCLs with pcl_for_each_segment and dereferences segment->rs_handle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault. xdr_check_write_list / xdr_check_reply_chunk pcl_alloc_write() chunk = pcl_alloc_chunk(...) /* ch_segcount = 0 */ list_add_tail(&chunk->ch_list, &pcl->cl_chunks) /* fill loop iterates zero times for wire segcount 0 */ svc_rdma_get_inv_rkey() pcl_for_each_chunk(rc_write_pcl) pcl_for_each_segment(segment, chunk) pos <= &ch_segments[0u - 1u] /* 0xFFFFFFFF */ segment->rs_handle /* OOB read -> GPF */ Fix by switching the macro to a half-open upper bound that uses ch_segcount directly. For ch_segcount == 0 the loop start equals the loop end and the body is skipped; for ch_segcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and net/sunrpc/xprtrdma/svc_rdma_rw.c remain correct under the new bound, so no caller changes are needed. Fixes: 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data structure") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Acked-by: Jeff Layton Link: https://patch.msgid.link/20260526-rpc-kernel-bugs-v1-4-e251306ccca9@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit a46b35f213c2426f5d6a0458a8f7e873fc59cdfd Author: Chris Mason Date: Tue May 26 09:35:56 2026 -0400 svcrdma: Fix offset arithmetic in read_chunk_range commit 4a44c140cc2f3643a39e258bb0c0ab9d0f494f5e upstream. svc_rdma_read_chunk_range() walks a Read chunk's segment list to build a sub-range starting at byte offset and spanning length bytes for a Position-Zero or Call chunk. Two arithmetic defects in the per-segment loop produce wrong DMA lengths and a u32 underflow: pcl_for_each_segment(segment, chunk) { if (offset > segment->rs_length) { offset -= segment->rs_length; continue; } dummy.rs_handle = segment->rs_handle; dummy.rs_length = min_t(u32, length, segment->rs_length) - offset; dummy.rs_offset = segment->rs_offset + offset; First, the skip predicate uses '>' instead of '>='. When offset equals the segment's full rs_length, the segment is fully consumed and should be skipped, but the loop falls through into the body. The resulting dummy.rs_length is min_t(u32, length, rs_length) - rs_length, which underflows to a near-UINT_MAX u32 when length is smaller than rs_length, or is zero otherwise. Second, the length formula subtracts offset from the min_t() result rather than from segment->rs_length before the cap. For offset > 0 the segment's residual is rs_length - offset, not rs_length, so the cap must be applied to the residual. With the current bracketing, whenever length is smaller than rs_length - offset the per-segment length becomes length - offset instead of length, silently dropping offset bytes from the rebuilt chunk. Combined with the boundary case above it also enables the u32 underflow path, which propagates a huge nr_bvec into svc_rdma_build_read_segment() and a multi-MiB kmalloc_array_node() in svc_rdma_get_rw_ctxt(). Additionally, svc_rdma_read_call_chunk() can invoke this function with length == 0 when the last Read chunk ends exactly at the end of the Call chunk. With the corrected >= predicate, every segment is skipped and the function returns the initial -EINVAL, rejecting a valid request. Return success immediately when length is zero. Also break out of the loop once length is fully consumed to avoid passing zero-length segments to svc_rdma_build_read_segment(). Fix by using '>=' so a fully-consumed segment is skipped, by moving '- offset' inside min_t() so the cap is applied to the segment's residual length, by returning success for zero-length requests, and by stopping iteration when the requested range has been consumed. Fixes: d7cc73972661 ("svcrdma: support multiple Read chunks per RPC") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Acked-by: Jeff Layton Link: https://patch.msgid.link/20260526-rpc-kernel-bugs-v1-2-e251306ccca9@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 1de391e8b94e31b45c19c16dbf315e294810c7de Author: Jérémy Jean Date: Sun Aug 9 17:07:48 2026 +0000 SUNRPC: wait for in-flight client TLS handshake callback commit a89dd597458848b463d284b15e42a8078beeb046 upstream. xs_tls_handshake_sync() gives xs_tls_handshake_done() a reference to the lower transport before submitting the handshake request. On timeout or signal, the synchronous waiter drops that reference after calling tls_handshake_cancel(). handshake_req_cancel() returns false when handshake_complete() has already marked the request complete. In that case the completion callback can still be running, so dropping the callback-owned reference in the waiter can free the lower transport before xs_tls_handshake_done() stores xprt_err or drops its own reference. If cancellation loses to completion, wait until xs_tls_handshake_done() signals handshake_done and let the callback release its reference. This mirrors the server-side handshake lifetime handling and keeps the timeout or signal return value unchanged. Fixes: 75eb6af7acdf ("SUNRPC: Add a TCP-with-TLS RPC transport class") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 1f9856af065b6158271687e9788407b9573fd16f Author: Chuck Lever Date: Thu May 28 15:32:08 2026 -0400 SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field commit ad484748eec0a66eac0f13ab53b3fbedb7333c91 upstream. gss_krb5_unwrap_v2() sets buf->len to a logical length, which can be much smaller than head[0].iov_len (the allocated receive-page capacity). It then calls xdr_buf_trim() with a trim length derived from the 16-bit "extra count" (ec) field in the Kerberos v2 token header. The ec field is authenticated by the post-decrypt memcmp() against the encrypted header copy, so a randomly-mutated value is rejected. However, any peer holding a valid GSS context can legitimately encrypt a token whose ec exceeds the plaintext length. Per RFC 4121, such a token is structurally malformed. Although xdr_buf_trim() now clamps the buf->len subtraction to avoid unsigned underflow, the buffer is still left in a semantically invalid state (zero length, inconsistent iov lengths) when ec is oversized. Reject these tokens before calling xdr_buf_trim(), giving callers a well-defined GSS_S_DEFECTIVE_TOKEN error and keeping the xdr_buf internally consistent. The wrapped blob begins at a nonzero offset -- both callers pass len as offset + opaque_len -- so buf->len still counts the offset bytes that precede the blob. Compare the trim length against the remaining wrapped segment, buf->len - offset, rather than the whole buffer; comparing against buf->len alone leaves an offset-wide window in which an oversized ec passes the test and xdr_buf_trim() cuts into the bytes ahead of the blob. Fixes: cf4c024b9083 ("sunrpc: trim off EC bytes in GSSAPI v2 unwrap") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260528-tier2-v1-1-d026a1415e0b@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 7a1d0501cbb962beba23377035d667bf3c1726ee Author: Chris Mason Date: Thu May 28 15:32:10 2026 -0400 SUNRPC: reject duplicate CREDS_VALUE options commit 2e4ce62385c1b8a887c5370af058ac7b52a8eaf9 upstream. gssx_dec_option_array() walks the wire-supplied option array and, for every entry whose name matches CREDS_VALUE, calls gssx_dec_linux_creds() on the same struct svc_cred. That helper unconditionally installs a fresh groups_alloc() result into creds->cr_group_info without releasing whatever pointer was already there: for (i = 0; i < count; i++) { ... decode name ... if (length == sizeof(CREDS_VALUE) && memcmp(p, CREDS_VALUE, sizeof(CREDS_VALUE)) == 0) { err = gssx_dec_linux_creds(xdr, creds); ... } } A reply that carries two CREDS_VALUE entries therefore overwrites cr_group_info on the second iteration and orphans the group_info allocated by the first call. The earlier free_creds path only releases the last cr_group_info via free_svc_cred(), so the first allocation's refcount stays at one and its kvmalloc-backed storage is leaked. No in-tree caller of gssp_accept_sec_context_upcall() expects more than one CREDS_VALUE per reply. Fix by tracking whether a CREDS_VALUE option has already been decoded and returning -EINVAL on any subsequent match, so the free_creds path releases the single group_info that was installed. Fixes: 1d658336b05f ("SUNRPC: Add RPC based upcall mechanism for RPCGSS auth") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260528-tier2-v1-3-d026a1415e0b@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit edeefb111d6181a4aa278f415b005efe284b9489 Author: Chris Mason Date: Sat May 30 20:42:52 2026 -0400 sunrpc: init gssp_lock before publishing proc entry commit 5ce1ed6159731a41fdd0b03eedbed4e147036a5a upstream. create_use_gss_proxy_proc_entry() publishes /proc/net/rpc/use-gss-proxy via proc_create_data() before init_gssp_clnt() runs mutex_init() on sn->gssp_lock. Once the dentry is linked under proc_subdir_lock it is immediately reachable from userspace, so a write that lands in the window drives set_gssp_clnt() into mutex_lock() on a zero-initialized struct mutex. create_use_gss_proxy_proc_entry(net) proc_create_data("use-gss-proxy", ...) /* dentry live */ init_gssp_clnt(sn) mutex_init(&sn->gssp_lock) /* too late */ write_gssp() set_gssp_clnt(net) mutex_lock(&sn->gssp_lock) /* uninitialized */ gssp_rpc_create(...) sn->gssp_clnt = clnt mutex_unlock(&sn->gssp_lock) The window spans only the two statements between proc_create_data() returning and init_gssp_clnt(), so a writer reaches it only if the registering thread is preempted there while another task is already opening the freshly published file. register_pernet_subsys() runs in preemptible context under pernet_ops_rwsem, so that preemption is possible, and the window widens on auth_rpcgss module load, when the proc entry is created for every live net namespace whose tasks are already running. A writer that wins the race locks a zero-filled struct mutex. On CONFIG_DEBUG_MUTEXES the missing magic value trips a "lock used without init" splat; on a production kernel the fast path acquires the lock via CMPXCHG(owner, 0, current). In the latter case a second writer that arrives before init_gssp_clnt() re-zeroes owner can enter set_gssp_clnt() concurrently, shut down the first writer's clnt while it is still in use, and leak the loser's clnt. Fix by initializing sn->gssp_lock in sunrpc_init_net() so its lifetime matches the sunrpc_net it lives in. sn->gssp_clnt is already NULL from the kzalloc that backs net_generic storage, so the lazy helper is no longer needed; drop init_gssp_clnt(), its prototype, and the call from create_use_gss_proxy_proc_entry(). sunrpc.ko is a build-time dependency of auth_rpcgss.ko, so sunrpc_init_net() has always run on every netns before any auth_gss pernet init can publish the proc entry. Fixes: 030d794bf498 ("SUNRPC: Use gssproxy upcall for server RPCGSS authentication.") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260530-tier2-local-v2-1-5a0fd532db57@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit ebcbd2523a8524c3d24e111cdbed8e271d910269 Author: Chris Mason Date: Sat May 23 21:02:11 2026 -0400 SUNRPC: harden gss_unwrap_resp_priv length checks commit 87831b92112c81db251d46756d65daa4f91af6a2 upstream. gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 ("SUNRPC: svcauth_gss: enforce krb5 token minimum length"). Fixes: 2d2da60c63b6 ("RPCSEC_GSS: client-side privacy support") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260524010213.557424-3-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 806584a4b67a7233870c33e5b8f872e76dd02988 Author: Chris Mason Date: Sat May 23 21:02:13 2026 -0400 SUNRPC: harden gss_krb5_unwrap_v2 against short tokens commit 6959297aaa9572783d620a226d73c3fb94494888 upstream. gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and ptr+6 before validating that the token is at least GSS_KRB5_TOK_HDR_LEN (16) bytes long, and its rotate_left() helper passes buf->len - base to xdr_buf_subsegment() without verifying that base <= buf->len. When a caller hands in a sub-16-byte token, or a token whose declared len leaves base past the end of the buffer, three distinct failures follow: gss_krb5_unwrap_v2(offset, len, buf) ptr = buf->head[0].iov_base + offset ec = *(ptr + 4) /* OOB read on short head */ rrc = *(ptr + 6) /* OOB read on short head */ rotate_left(offset + 16, buf, rrc) xdr_buf_subsegment(buf, &subbuf, base, buf->len - base) /* u32 wrap when base > len */ _rotate_left(&subbuf, shift) shift %= buf->len /* divide-by-zero when base == len */ After decryption, the cleanup arithmetic has the same shape: movelen = min_t(unsigned int, buf->head[0].iov_len, len); movelen -= offset + GSS_KRB5_TOK_HDR_LEN + headskip; BUG_ON(offset + GSS_KRB5_TOK_HDR_LEN + headskip + movelen > buf->head[0].iov_len); The BUG_ON re-adds the value just subtracted, so it reduces to min(A, B) > A and is permanently false; it cannot catch the unsigned underflow of movelen, which then drives a ~UINT_MAX-byte memmove(). Add four defense-in-depth guards inside the unwrap core so it is safe regardless of what its callers validate: - reject tokens with len - offset < GSS_KRB5_TOK_HDR_LEN before touching ptr+4/ptr+6; - bail from rotate_left() when buf->len <= base, covering both the underflow and zero-length cases; - return early from _rotate_left() when buf->len is zero, so the shift %= buf->len modulo cannot fault; - replace the dead BUG_ON with a live check that returns GSS_S_DEFECTIVE_TOKEN before the movelen subtraction. Fixes: de9c17eb4a91 ("gss_krb5: add support for new token formats in rfc4121") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260524010213.557424-5-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit fa46b6aa7a6984fc6139a4d27618d13988296d25 Author: Chris Mason Date: Thu May 28 15:32:11 2026 -0400 SUNRPC: Guard svcauth_gss_release() dispatch on rq_auth_stat commit f8870b9b75afb77986bc65940a231d54068ff2b1 upstream. svcauth_gss_release() reads gc_proc and switches on gc_svc before consulting rq_auth_stat. On the SVC_DENIED path after a failed svcauth_gss_accept(), those fields may hold stale values from a prior request or uninitialized slab residue: svcauth_gss_accept() allocates gss_svc_data with non-zeroing kmalloc and clears only gsd_databody_offset and rsci per request, not clcred. Because RPC_GSS_PROC_DATA is zero, a zeroed or stale-zero gc_proc passes the existing guard and falls through into the gc_svc switch, which can dispatch to svcauth_gss_wrap_integ() or svcauth_gss_wrap_priv(). Both wrap helpers call svcauth_gss_prepare_to_wrap() before any rsci->mechctx dereference, and that helper already returns early when rq_auth_stat is not rpc_auth_ok, so the downstream NULL dereference is blocked. The dispatch itself remains structurally wrong: it reads scalars that the caller has no contract to have initialized after a failed authentication. Mirror the existing rq_auth_stat gate in svcauth_gss_prepare_to_wrap() one frame up, so svcauth_gss_release() skips the clcred dispatch entirely when authentication has not succeeded. The cleanup tail that releases rq_client, rq_gssclient, cr_group_info, and rsci still runs. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260528-tier2-v1-4-d026a1415e0b@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit e769fcde3cc73e847b1eb3acd40c04a291cb0c0c Author: Luxiao Xu Date: Tue Jul 7 13:20:47 2026 +0800 sunrpc: fix use-after-free in __rpc_clnt_handle_event and __rpc_clnt_remove_pipedir commit 932a8cf6abb2b2f8677b79153a823108d8861fe2 upstream. Normal client creation goes through rpc_setup_pipedir(), which records clnt->pipefs_sb, but the mount-event path in __rpc_clnt_handle_event() calls rpc_setup_pipedir_sb() directly and never refreshes that field. The umount path also removes the directory without clearing clnt->pipefs_sb. After a late pipefs mount or any remount, rpc_clnt_remove_pipedir() compares the current superblock against a stale pipefs_sb pointer and skips cleanup, leaving pipefs dentries whose inode private data still points at a freed rpc_clnt, leading to a potential use-after-free during subsequent rpc_info_open() or rpc_show_info() calls. Fix this by properly updating clnt->pipefs_sb upon mount events and clearing it during unmount or failure paths. Fixes: bfca5fb4e97c ("SUNRPC: Fix RPC client cleaned up the freed pipefs dentries") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Xin Liu Reviewed-by: Ren Wei Assisted-by: Codex:gpt-5.4 Signed-off-by: Luxiao Xu Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 08bc49e0541260bf294962cf889a32a2d2713ad6 Author: Jeff Layton Date: Thu Jun 11 16:00:47 2026 -0400 sunrpc: defer rq_argp and rq_resp free until after RCU grace period commit c479bde671cbe2f9e152834a8b0eb7c3c295bbaf upstream. svc_rqst_free() frees rqstp->rq_argp and rqstp->rq_resp synchronously via kfree(), but defers the rqstp struct free via kfree_rcu(). After svc_exit_thread() calls list_del_rcu() and svc_rqst_free(), there is a window where RCU readers that started before list_del_rcu() can still traverse the thread list and find the rqstp. These readers (e.g. nfsd_nl_rpc_status_get_dumpit()) dereference rqstp->rq_argp, which has already been freed — a use-after-free. Fix this by moving the kfree of rq_argp and rq_resp into an explicit call_rcu() callback alongside the struct free. Resources not accessed by RCU readers (bvec, buffer pages, scratch folio, auth_data) remain synchronously freed. Fixes: 812443865c5f ("sunrpc: add a rcu_head to svc_rqst and use kfree_rcu to free it") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-4-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit bd1ef2cfb44d72b7aa6943e87b206eb0e30fbd0c Author: Chuck Lever Date: Sat May 30 20:42:53 2026 -0400 SUNRPC: Check svc pool percpu counter allocation commit 43e11e164704dde975c9edb370de1a06bec67270 upstream. __svc_create() initializes three per-pool percpu_counter stats and ignores every return value. On SMP, percpu_counter_init() fails when __alloc_percpu_gfp() cannot satisfy the allocation, leaving the failed counter with fbc->counters == NULL and its embedded raw_spinlock_t, list_head, and count never initialized. __svc_create() returns the half-constructed svc_serv to nfsd, lockd, or the NFS callback service anyway. Once that service is live, the hot-path increments in svc_xprt_enqueue(), svc_handle_xprt(), and svc_pool_wake_idle_thread() reach a counter whose backing pointer is NULL. The pointer is a per-cpu offset, so the access does not fault: it resolves to offset zero of the current CPU's per-cpu area and silently corrupts whatever variable lives there. A /proc/fs/nfsd/pool_stats read walks the same NULL per-cpu storage and returns garbage, and on CONFIG_DEBUG_SPINLOCK or lockdep it splats on the never-initialized lock. Creating the broken service requires a percpu allocation failure during RPC server startup, so it is reachable only by a local administrator under memory pressure or fault injection; a remote peer cannot induce the bad state on its own. Check each percpu_counter_init() return value in __svc_create() and fail when an allocation fails, unwinding the counters already set up in the current pool and in every pool initialized before it. A discrete percpu_counter_destroy() per counter at teardown frees each per-cpu allocation exactly once. Fixes: ccf08bed6e7a ("SUNRPC: Replace pool stats with per-CPU variables") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260530-tier2-local-v2-2-5a0fd532db57@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 2e861ce2aaa468351a6a47c4cbb4971ebb740c7b Author: Jeff Layton Date: Tue May 26 15:35:06 2026 -0400 SUNRPC: always drain cache_cleaner before destroying a cache_detail commit f42d0fda0c67695db6bc704b04b7c10240805377 upstream. sunrpc_destroy_cache_detail() only cancels the global cache_cleaner delayed_work when cache_list is empty. During per-netns teardown cache_list is never empty because init_net's caches remain registered, so the cancel never fires. After unlink, the caller proceeds to cache_destroy_net() which kfrees the cache_detail while cache_clean() may still hold a dangling pointer to it. The result is a use-after-free: cache_dequeue() takes cd->queue_lock on freed memory, and cache_put() dereferences cd->cache_put as a function pointer from freed slab. Drop the list_empty guard so that cancel_delayed_work_sync() always runs, ensuring any in-flight cache_clean() completes before the cache_detail is freed. Re-arm the cleaner afterwards if other caches are still registered. Fixes: 820f9442e711 ("SUNRPC: split cache creation and PipeFS registration") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260526-cache_cleaner_vs_destroy_no_sync-v1-1-a707a6fcfd32@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 39981133df21cc5d983d0afb9d27b15b4e528e38 Author: Ameer Hamza Date: Wed Jul 22 23:20:11 2026 +0500 SUNRPC: Restore NUMA_NO_NODE for svc thread allocations in global mode commit 0574da29ae12be7714df217c4ce7ff6ba9b0c23b upstream. Commit d57e43b72bf2 ("SUNRPC: Update svcxdr_init_decode() to call xdr_set_scratch_folio()") changed svc_pool_map_get_node() to return numa_mem_id() instead of NUMA_NO_NODE, because __folio_alloc_node() cannot accept NUMA_NO_NODE. That return value is not equivalent: it is evaluated in the context of the task creating the nfsd threads, once per thread created, and it is passed to kthread_create_on_node() and to the per-thread allocations in svc_prepare_thread(). Since commit d1a89197589c ("kthread: Default affine kthread to its preferred NUMA node"), the node argument of kthread_create_on_node() no longer only places the task structure and stack: a kthread created with a real node id normally affines itself to that node's CPUs when it is first woken to run its thread function. All nfsd threads are typically started together, by one task writing to /proc/fs/nfsd/threads, so under the default pool_mode=global each nfsd thread is now affined to the local-memory node of the CPU its creating iteration happened to run on - typically the same node for every thread. The CPUs of the other nodes are then unable to run nfsd at all, and the threads' allocations - svc_rqst structures, page pointer arrays, newly allocated task stacks, and the per-RPC pages allocated at run time - all prefer that one node. Restore the NUMA_NO_NODE behaviour that global mode has had since commit 11fd165c68b7 ("sunrpc: use better NUMA affinities"), and handle NUMA_NO_NODE at the one call site that cannot take it by resolving it to numa_mem_id() there, exactly as alloc_pages_node() did for the scratch page before the conversion. The mapped percpu and pernode branches are unchanged. Unpooled services such as lockd and the NFS client callback service also take this fallback when no percpu or pernode map is active, restoring their thread placement in that case. A bisect of a 2x NFS READ throughput regression between v6.17 and v6.18 converged on d57e43b72bf2. On the affected 4-node server every nfsd thread comes up with its CPU affinity restricted to the CPUs of a single node; with this change the threads are runnable on all CPUs again and the observed regression is resolved. Fixes: d57e43b72bf2 ("SUNRPC: Update svcxdr_init_decode() to call xdr_set_scratch_folio()") Cc: stable@vger.kernel.org Signed-off-by: Ameer Hamza Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260722182012.2063936-1-ameer.hamza@truenas.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 9d04d64ad192439835ed9884d767353061c3ed6f Author: Jeff Layton Date: Mon Jul 6 09:29:21 2026 -0400 sunrpc: route to a populated pool in svc_pool_for_cpu() commit f6310491c4cdb88af73aa551ec9df1f10a90c709 upstream. svc_set_num_threads() spreads the requested threads evenly across the service's pools (base = nrservs / sv_nrpools). When a service runs fewer threads than it has pools -- e.g. an nfsd configured with fewer threads than the host has NUMA nodes while running in "pernode" or "percpu" mode -- the trailing pools are left with no threads at all. svc_xprt_enqueue() selects a pool from the CPU servicing the transport, queues the transport on that pool's sp_xprts, and only wakes a thread from the same pool. Each thread services exclusively its own pool, so a transport that lands on a threadless pool is enqueued on sp_xprts and never picked up: the connection hangs indefinitely. Have svc_pool_for_cpu() skip pools that currently have no threads, falling back to the next populated pool. This trades NUMA locality for a guarantee that the work is actually serviced. sp_nrthreads is only updated under the service mutex; the lockless read here is a best-effort routing hint, so annotate it with data_race(). Fixes: bfd241600a3b ("[PATCH] knfsd: make rpc threads pools numa aware") Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260706-sunrpc-pool-mode-v5-1-6c4ee7cd89aa@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit de942dd8c2c8358bcad04ce44271954c48924423 Author: Chris Mason Date: Sat May 23 21:02:10 2026 -0400 SUNRPC: svcauth_gss: enforce krb5 token minimum length commit a919c5c88769cf8fb3ec071e6078d830bf512489 upstream. svcauth_gss_unwrap_priv() validates only an upper bound on the wire-supplied opaque length before handing the buffer to gss_unwrap(): if (len > xdr_stream_remaining(xdr)) goto unwrap_failed; offset = xdr_stream_pos(xdr); ... maj_stat = gss_unwrap(ctx, offset, offset + len, buf); The wire value `len` flows unchanged as the upper bound into the krb5 unwrap path, so a len in [0, 16] passes this check and is handed to gss_unwrap(). For a krb5 v2 context that lands in gss_krb5_unwrap_v2(), which reads the 16-byte RFC 4121 token header fields at ptr+4 and ptr+6 and then calls rotate_left() before any integrity check. With a sub-header length the header reads run past the token, and _rotate_left()'s `shift %= buf->len` path can divide by zero when buf->len has been driven to zero by the truncated token. A header-only token (len == 16) is equally invalid: with a non-zero RRC field and the opaque blob ending at the XDR buffer boundary, rotate_left() builds a zero-length subbuffer, reaching the same division. Reject the token at the server entry point before it reaches the krb5 unwrap core. A valid sealed RFC 4121 token must contain the 16-byte header plus at least some encrypted payload. Fix by adding a minimum-length check immediately after the existing upper-bound check: if (len <= GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; Fixes: 7c9fdcfb1b64 ("[PATCH] knfsd: svcrpc: gss: server-side implementation of rpcsec_gss privacy") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260524010213.557424-2-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit e0778464049b0238f2915a40007a4154f86cf351 Author: Chris Mason Date: Thu May 28 15:32:12 2026 -0400 SUNRPC: Zero rpc_gss_wire_cred at svcauth_gss_decode_credbody() entry commit 11539e8fcce0b0af062ae5fecf7b3676c2f7aeed upstream. svcauth_gss_decode_credbody() writes the caller's rpc_gss_wire_cred field by field and assigns gc_ctx.len only on the success tail. The caller storage is svcdata->clcred, which lives in the per-svc_rqst gss_svc_data and is reused across requests. Early decode failures leave partially decoded state mixed with residue from the prior request. The trailing body_len tightness check is the sharpest case: xdr_stream_decode_opaque_inline() has already written gc_ctx.data with a borrowed inline pointer into the current request's XDR pages, but gc_ctx.len retains its prior value. Once the request pages are released the pooled clcred carries a dangling pointer paired with a stale length. Zero the caller's rpc_gss_wire_cred at function entry so that every early-return path leaves a deterministic all-zero cred. On the trailing tightness-check path, gc_ctx.len is now zero instead of stale, which neuters length-driven consumers such as gss_svc_searchbyctx() that would otherwise walk the dangling data pointer. Fixes: b0bc53470d1a ("SUNRPC: Convert the svcauth_gss_accept() pre-amble to use xdr_stream") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260528-tier2-v1-5-d026a1415e0b@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit ad0cce80d4af2f74674e8b635d97aa3880e83da8 Author: Chris Mason Date: Sat May 23 21:02:12 2026 -0400 SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow commit 3f491306dcb673ff5e78e1044ba450c58978774e upstream. xdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by walking the tail, pages, and head iovecs. Each per-section step uses min_t() so it never removes more bytes than that section holds, but the final accounting at the fix_len label subtracts the total bytes actually consumed from buf->len without any clamp: fix_len: buf->len -= (len - trim); When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches xdr_buf_trim() in exactly that state: buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip; buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip); xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip); buf->len is a small wire-derived value while the iov_lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder. Fix by clamping the decrement so buf->len bottoms out at zero: buf->len -= min_t(unsigned int, buf->len, len - trim); On the normal path where the iov_lens sum to buf->len, (len - trim) is always <= buf->len and the result is identical to before. No callers change behavior outside the underflow case. Fixes: 4c190e2f913f ("sunrpc: trim off trailing checksum before returning decrypted or integrity authenticated buffer") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260524010213.557424-4-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f1b7b2c7ffa9711d1298f52790b377fe02efc1db Author: Felix Gu Date: Fri Jul 31 16:11:19 2026 +0800 phy: fsl-imx8mq-usb: fix typec switch leak on probe error path commit 87a1805b1c346b092c34f96f3806f207792910e1 upstream. If probe fails after imx95_usb_phy_get_tca() succeeds, the typec switch leaks because the only cleanup path was in .remove(), which never runs on probe failure. Use devm_add_action_or_reset() so the switch is cleaned up on both probe failure and driver removal. The imx95_usb_phy_put_tca() is no longer needed, it will be removed in .remove() too. Fixes: b58f0f86fd61 ("phy: fsl-imx8mq-usb: add tca function driver for imx95") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Reviewed-by: Xu Yang Signed-off-by: Felix Gu Signed-off-by: Xu Yang Link: https://patch.msgid.link/20260731-imx8mp-usb-phy-improvement-v8-1-2ec8d6b3854d@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 704ecd010d4a9b33160e40b74eb402f6b86a18e0 Author: Jiacheng Yu Date: Wed Jul 29 12:32:43 2026 +0000 params: fix charp corruption on allocation failure commit 3dfaae04243cde460d82dfc2a7dd0bb6664d20ae upstream. param_set_charp() stores charp parameters in allocated memory after slab is available, and releases the previous value when the parameter is updated. The previous value is released before the replacement allocation succeeds. If kmalloc_parameter() fails, the setter returns -ENOMEM with the parameter left as NULL. Failing zswap's compressor update before zswap is initialized can later trigger: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strcmp+0x10/0x30 Call Trace: zswap_setup+0x3b1/0x490 zswap_enabled_param_set+0x5b/0xa0 param_attr_store+0x93/0xe0 module_attr_store+0x1c/0x30 kernfs_fop_write_iter+0x116/0x1f0 Allocate and copy the replacement first, then replace the parameter value only after allocation succeeds. Fixes: e180a6b7759a ("param: fix charp parameters set via sysfs") Cc: stable@vger.kernel.org Signed-off-by: Jiacheng Yu Reviewed-by: Petr Pavlu Signed-off-by: Petr Pavlu Signed-off-by: Greg Kroah-Hartman commit ff110e85837d7ecd83f36078107be240ff5ae409 Author: Dave Airlie Date: Fri Jun 12 12:06:58 2026 +1000 nouveau/gem: reserve the bo in the info ioctl around the vma lookup commit 5e17160d41d92823f3379c1982e1369680c5ce4d upstream. In the non-uvmm path, there could be a race between the info lookup finding the vma, and the gem close path closing the vma leading to a use-after-free. Spotted with the help of Opus 4.6. Signed-off-by: Dave Airlie Fixes: e758a3111914 ("drm/nouveau: fixup gem_info ioctl to return client-specific bo virtual") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260612020658.3176270-1-airlied@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 04ab51d4e369abfcc142b145fefa18fa2add7713 Author: Stanislaw Gruszka Date: Fri Mar 27 12:00:04 2026 +0100 module/kallsyms: fix nextval for data symbol lookup commit 0e9f090a4e9bfae5a190ccf89eab3bf14f6b0f96 upstream. The symbol lookup code assumes the queried address resides in either MOD_TEXT or MOD_INIT_TEXT. This breaks for addresses in other module memory regions (e.g. rodata or data), resulting in incorrect upper bounds and wrong symbol size. Select the module memory region the address belongs to instead of hardcoding text sections. Also initialize the lower bound to the start of that region, as searching from address 0 is unnecessary. Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka Reviewed-by: Petr Pavlu Signed-off-by: Petr Pavlu Signed-off-by: Greg Kroah-Hartman commit 51887ccd88791ddaa8755a7c614fda031ecf7982 Author: Harshit Varu Date: Sat Aug 15 17:22:05 2026 +0530 mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction commit b878dfdd12d7a5b8722a78d35e313506140ca3d9 upstream. mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection. Restore subflow_req->local_id from the cookie entry, as done for the other fields. Fixes: 9466a1ccebbe ("mptcp: enable JOIN requests even if cookies are in use") Cc: stable@vger.kernel.org Signed-off-by: Harshit Varu Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260815115205.197151-1-harshitvaru666@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d82b90a38c2ca8a0694428eab0e9551c23f2447d Author: Qing Ming Date: Fri Aug 14 17:54:04 2026 +0800 mpls: reload header after pskb_may_pull() commit 29e63b8d9fc150cc191b1c6eb7e16e1247e1b650 upstream. mpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop when an MPLS route has multiple nexthops. While walking the MPLS label stack, the hash routine caches hdr for the current label. After finding the bottom-of-stack label, it calls pskb_may_pull() before reading the inner IP header. If an skb is constructed with the inner IP header in nonlinear data and insufficient tailroom in the linear head, pskb_may_pull() calls pskb_expand_head() to replace the skb head and free the old one. This leaves hdr pointing to freed memory. The IPv6 path can invalidate hdr again when it performs a second pull for the larger header. The issue was found through static analysis. A reproducer sending a legal Geneve packet through a bareudp/MPLS multipath setup triggered the same KASAN report in 2 of 2 unpatched runs: BUG: KASAN: slab-use-after-free in mpls_select_multipath Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23 Call Trace: mpls_select_multipath mpls_forward __netif_receive_skb_list_core netif_receive_skb_list_internal napi_complete_done gro_cell_poll __napi_poll net_rx_action Freed by task 23: kfree pskb_expand_head __pskb_pull_tail mpls_select_multipath Reload hdr from the current skb head after each successful pull before deriving the inner IPv4 or IPv6 header pointer. Fixes: 9f427a0e474a ("net: mpls: Fix multipath selection for LSR use case") Cc: stable@vger.kernel.org Signed-off-by: Qing Ming Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260814095404.7205-1-a0yami@mailbox.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 50d0aa7d25ba4bc3606f150cd69755068e79f97f Author: Thiébaud Weksteen Date: Wed Jul 8 11:21:07 2026 +1000 module: validate string table section types commit 9a5ff45689329835f874cefe5174e577d141d423 upstream. In elf_validity_cache_sechdrs, section sizes and offsets are validated, unless the section type is SHT_NULL or SHT_NOBITS. Later, elf_validity_cache_secstrings and elf_validity_cache_index_str access the section name table (.shstrtab) and symbol string table (.strtab) headers without first ensuring that their types are SHT_STRTAB. If a section type is SHT_NULL or SHT_NOBITS, sh_offset has not been validated and may reference out-of-bounds memory when dereferenced in elf_validity_cache_secstrings or elf_validity_cache_strtab. Validate that both string section headers are of type SHT_STRTAB before caching them. Cc: stable@vger.kernel.org Signed-off-by: Thiébaud Weksteen Reviewed-by: Aaron Tomlin Reviewed-by: Petr Pavlu Signed-off-by: Petr Pavlu Signed-off-by: Greg Kroah-Hartman commit 3b097416b4cff77285c1f472fc2c4058d8a7554f Author: Coly Li Date: Mon Jul 20 19:14:00 2026 +0800 md: do overflow check for sb->bblog_shift in super_1_load() commit 35d522bd32462afcf1981dab6da8a9256c26c1e0 upstream. In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 } bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c. Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller. This may avoid unnecessary check, make the badblocks API code more simple and elegant. Fixes: 2699b67223ac ("md: load/store badblock list from v1.x metadata") Fixes: 1726c7746783 ("badblocks: improve badblocks_set() for multiple ranges handling") Cc: stable@vger.kernel.org Cc: Ramesh Adhikari Signed-off-by: Coly Li Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260720111400.2120834-1-colyli@fygo.io Signed-off-by: Yu Kuai Signed-off-by: Greg Kroah-Hartman commit 0efabe6229dc683dbf6eeebd0f9fddc7971ed420 Author: Yunye Zhao Date: Thu Jul 23 21:55:33 2026 +0800 md/raid10: fix still_degraded being inverted in raid10_sync_request() commit 47f1441b281decde6954a2fa82b4131637d685ac upstream. Commit fe6a19d40ceb ("md/md-bitmap: merge md_bitmap_start_sync() into bitmap_operations") converted still_degraded from int to bool, but inverted the assignment in the loop that checks whether the array will still be degraded after the current device is recovered: "still_degraded = 1" became "still_degraded = false". As a result, recovering a device while another mirror is still missing calls md_bitmap_start_sync() with degraded == false, which clears bitmap bits that the still-missing device needs. When that device is re-added, its bitmap-based recovery finds the bits already cleared and skips every region written while the array was degraded, so it is marked In_sync while holding stale data: silent corruption. Reproducer (raid10 near=2, 4 disks, internal bitmap): - fail and remove one disk of each mirror pair - write to the degraded array - re-add both disks and let recovery finish - "check" reports mismatch_cnt=262272 after 256 MiB of degraded writes and file contents differ; the second disk's "recovery" completes in milliseconds because everything is skipped The same conversion in raid1 got it right (still_degraded = true). Restore the correct value. Fixes: fe6a19d40ceb ("md/md-bitmap: merge md_bitmap_start_sync() into bitmap_operations") Cc: stable@vger.kernel.org Signed-off-by: Yunye Zhao Reviewed-by: Mykola Marzhan Reviewed-by: Paul Menzel Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260723135535.101995-2-yunye.zhao@linux.alibaba.com Signed-off-by: Yu Kuai Signed-off-by: Greg Kroah-Hartman commit 121d35014e497fe9637336180a051585957c8834 Author: Anup Vishwakarma Date: Wed Aug 5 14:34:07 2026 +0530 mailbox: qcom-ipcc: fix duplicate channel allocation across holes commit 66c7bcad72430a02c860521031350b84b31ad9a8 upstream. The IPCC of_xlate() both scans for a free mailbox channel and checks for duplicate references to the same underlying IPCC channel. When a channel has been shutdown it might have left a hole in the channel list, which would terminate the search without considering duplicates later in the list. Continue the traversal of the channel list to detect and reject duplicates, while keeping track of the first free channel. Fixes: d6fbfdbc1274 ("mailbox: qcom-ipcc: Fix IPCC mbox channel exhaustion") Cc: stable@vger.kernel.org Signed-off-by: Anup Vishwakarma Signed-off-by: Jassi Brar Signed-off-by: Greg Kroah-Hartman commit 09e649117c54b7e1c004f22eaa19efbadd9ac856 Author: Bryam Vargas Date: Wed Jun 24 01:03:45 2026 -0500 libnvdimm/labels: Prevent integer overflow in __nd_label_validate() commit 037770686126155eafc44501312989e2837b9659 upstream. The on-media namespace index field nslot is a u32 read from the DIMM label storage area. __nd_label_validate() bounds it against the config area size, but sizeof_namespace_label() returns unsigned, so the product nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before the comparison. A crafted nslot passes the bound and is then used as the loop trip count in nd_label_data_init(), whose memset() walks off the end of the config_size buffer: an out-of-bounds write. The field is not trusted -- it comes from the medium, or from userspace via ND_CMD_SET_CONFIG_DATA. Evaluate the product in 64-bit so the bound check is exact; conforming labels are unaffected. The check was safe when introduced by commit 4a826c83db4e ("libnvdimm: namespace indices: read and validate"): it multiplied by sizeof(struct nd_namespace_label), a size_t, so on a 64-bit build the product did not wrap. Commit 564e871aa66f ("libnvdimm, label: add v1.2 nvdimm label definitions") narrowed it to 32 bits when the label size became a runtime value read via sizeof_namespace_label(). Fixes: 564e871aa66f ("libnvdimm, label: add v1.2 nvdimm label definitions") Cc: stable@vger.kernel.org Reviewed-by: Alison Schofield Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260624-b4-disp-d8279485-v3-1-cdb6cab28b41@proton.me Signed-off-by: Alison Schofield Signed-off-by: Greg Kroah-Hartman commit 627ce4902df1d737e99306daae5a87c68b876d16 Author: Günther Noack Date: Thu Aug 13 11:31:53 2026 +0200 landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation commit 672fa082d48b21e1fb62cdb184fee41513e53421 upstream. Whiteout objects are used in the upper layer of an OverlayFS to indicate that the file with this name does not exist in the unified view, even if it is present in one of the lower layer file systems. For the userspace implementations of OverlayFS (fuse-overlayfs), whiteout objects can be created from userspace as well: * mknod(2) with S_IFCHR and makedev(0, 0) * renameat2(2) with RENAME_WHITEOUT, creating the whiteout in the old place of the moved file. This commit guards whiteout creation in both of these cases with LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered character devices and are not bound to a driver. LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a whiteout object: creating one is the only S_IFCHR creation that the VFS exempts from CAP_MKNOD, so it is as unprivileged as creating a regular file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that expose a kernel interface [1]. For the mknod(2) case, introduce a Landlock erratum. The creation of whiteout objects through mknod(2) was previously guarded using LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using LANDLOCK_ACCESS_FS_MAKE_REG. For the renameat2(2) case, fix a bug: Before this commit, renameat2(2) with RENAME_WHITEOUT would create a directory entry even when all LANDLOCK_ACCESS_FS_MAKE_* rights were denied. This does not affect normal renames within layered OverlayFS mounts: When doing a regular rename() on a mounted fuse-overlayfs, it is the fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT, and only the Landlock domain of that daemon is checked there. Suggested-by: Christian Brauner Suggested-by: Mickaël Salaün Cc: stable@vger.kernel.org Fixes: cb2c7d1a1776 ("landlock: Support filesystem access-control") Depends-on: 49c9e09d9610 ("landlock: Fix handling of disconnected directories") Depends-on: fe72ce6710cb ("landlock: Add errata documentation section") Signed-off-by: Günther Noack Link: https://patch.msgid.link/20260720.chow9ohYie5b@digikod.net [1] Link: https://patch.msgid.link/20260813093157.1436894-3-gnoack@google.com [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and add link(2) to the user doc] Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit a602cd128d17a793e12888edc8eda85821ede7e1 Author: Yuyang Huang Date: Sat Aug 15 17:46:51 2026 +0900 ipv6: use RCU iterator to dump route exceptions commit 47cdab0d51aaa9bd85f8e4904585bd5bd4df4488 upstream. rt6_nh_dump_exceptions() uses hlist_for_each_entry() to iterate over RCU-protected exception lists. The caller holds rcu_read_lock(), but does not hold rt6_exception_lock, so rt6_insert_exception() can concurrently add an entry with hlist_add_head_rcu(). KCSAN reports this race (irrelevant details omitted): ================================================================== BUG: KCSAN: data-race in rt6_insert_exception / rt6_nh_dump_exceptions write (marked) to 0xffff8a7c44c59620 of 8 bytes by interrupt on cpu 5: rt6_insert_exception+0x3bb/0x760 __ip6_rt_update_pmtu+0x4fe/0x750 ip6_sk_update_pmtu+0x19a/0x3b0 udpv6_err+0x3ff/0x800 icmpv6_notify+0x1e1/0x440 icmpv6_rcv+0x8c0/0xab0 ip6_protocol_deliver_rcu+0x616/0x840 ip6_input_finish+0xb9/0x160 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff8a7c44c59620 of 8 bytes by task 549 on cpu 14: rt6_nh_dump_exceptions+0xb3/0x260 rt6_dump_route+0x53e/0x5f0 fib6_dump_node+0x6d/0xf0 fib6_walk_continue+0x290/0x2d0 fib6_dump_table+0x28d/0x360 inet6_dump_fib+0x37d/0x620 rtnl_dumpit+0x7b/0xd0 netlink_dump+0x3ae/0x7e0 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f 4 locks held by dumper/549: ... #1: (rcu_read_lock){....}-{1:3}, at: inet6_dump_fib+0x88/0x620 #2: (&tb->tb6_lock){+.-.}-{3:3}, at: fib6_dump_table+0x1e9/0x360 #3: (rcu_read_lock){....}-{1:3}, at: rt6_dump_route+0x483/0x5f0 value changed: 0xffff8a7c44e05700 -> 0xffff8a7c45d60100 Reported by Kernel Concurrency Sanitizer on: CPU: 14 UID: 0 PID: 549 Comm: dumper Not tainted 7.2.0-rc7-virtme #38 PREEMPT(lazy) ... Use hlist_for_each_entry_rcu() to safely iterate over the exception list. Fixes: 1e47b4837f3b ("ipv6: Dump route exceptions if requested") Cc: stable@vger.kernel.org Signed-off-by: Yuyang Huang Reviewed-by: Stefano Brivio Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260815084651.69477-1-sigefriedhyy@gmail.com Signed-off-by: David S. Miller Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 63f50e9f90d0287ad66a0955ebfc2d3a9c044a1c Author: Andrea Mayer Date: Mon Aug 17 15:26:44 2026 +0200 ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv() commit f826df95332c07380206dbd54178b6eefb311aba upstream. ipv6_rpl_srh_rcv() dereferences idev from __in6_dev_get() without a NULL check when reading idev->cnf.rpl_seg_enabled. When the device's MTU drops below IPV6_MIN_MTU, addrconf_ifdown() clears dev->ip6_ptr through RCU_INIT_POINTER(). A packet that passed the idev check in ip6_rcv_core() can then reach ipv6_rpl_srh_rcv() with dev->ip6_ptr already NULL. Reproduced by flooding the receiving interface with ping6 traffic while flapping its MTU between 1500 and 1200: BUG: KASAN: null-ptr-deref in ipv6_rpl_srh_rcv+0xb3/0x1070 Read of size 4 at addr 00000000000006b4 by task ping6/394 CPU: 2 UID: 0 PID: 394 Comm: ping6 Not tainted 7.2.0-rc7-micro-vm-dev-00095-g24ef02f934ee #240 PREEMPT(full) Call Trace: kasan_report+0xc6/0x100 ipv6_rpl_srh_rcv+0xb3/0x1070 ip6_protocol_deliver_rcu+0x759/0x9a0 ip6_input_finish+0xa8/0x1b0 ip6_input+0xe1/0x490 ipv6_rcv+0x33d/0x460 __netif_receive_skb_one_core+0xd6/0x130 process_backlog+0x2cc/0xa00 __napi_poll.constprop.0+0x56/0x270 net_rx_action+0x327/0x730 handle_softirqs+0x11e/0x630 do_softirq+0xb3/0xf0 Both ipv6_rpl_srh_rcv() and ipv6_srh_rcv() are called only from ipv6_rthdr_rcv(), which already has an idev lookup. Fix the NULL dereference on the RPL path by checking idev in ipv6_rthdr_rcv(), before it calls either function. The callees take idev as an argument and no longer call __in6_dev_get(), so the packet is now dropped in one place, with SKB_DROP_REASON_IPV6DISABLED on both paths. Fixes: 8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr") Cc: stable@vger.kernel.org Signed-off-by: Andrea Mayer Tested-by: Xiang Mei Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260817132644.2223-1-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b8282668d8fa7c61b80e8e4890729031c291a16c Author: Zhiling Zou Date: Thu Aug 13 00:22:34 2026 +0800 ip6_gre: fix hardware header length for NBMA tunnels commit 505b6d296c486ef7d1274f279d4c43a172f63224 upstream. ip6gre_tnl_link_config_route() accumulates the lower device's hardware header length into dev->hard_header_len whenever header_ops is set. This is incorrect for both users of header_ops. ip6gretap and ip6erspan have a fixed Ethernet hardware header length. For an NBMA ip6gre tunnel, ip6gre_header() creates only the GRE header, the optional FOU or GUE header, and the outer IPv6 header. The lower device header is headroom needed later, not part of the tunnel device's hardware header. Keep the lower device header in needed_headroom. Set hard_header_len to the tunnel header length only for ARPHRD_IP6GRE devices with header_ops, and leave the fixed Ethernet header length unchanged for tap and erspan devices. Fixes: 832ba596494b ("net: ip6_gre: set dev->hard_header_len when using header_ops") Cc: stable@vger.kernel.org Suggested-by: Ido Schimmel Signed-off-by: Zhiling Zou Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/64b46542bbe1701f07702aaa50273e2a87903db5.1786542637.git.zhilinz@nebusec.ai Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit b36dfd6e8cff00cea81c11cc0af88d1564763461 Author: Zhiling Zou Date: Tue Aug 11 21:31:11 2026 +0800 ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit() commit 87f21b59ddc618eff9670c174842964ad65fdade upstream. ip6_tnl_xmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skb_realloc_headroom(), copies skb->sk ownership, consumes the original skb, and then continues processing with the replacement skb kept only in its local variable. That is safe only if the helper cannot fail afterwards. But this helper still has post-reallocation error exits. collect_md tunnels reject non-NONE encap after the replacement, and ip6_tnl_encap() can also fail later. In those cases the helper returns an error to its callers while the caller still only has the original skb pointer. Both ip6_tnl_start_xmit() and the IPv6 GRE paths free the caller skb on error, so they can end up freeing an skb that ip6_tnl_xmit() already consumed. Use skb_cow_head() instead. It provides the required headroom and writability without privately replacing the caller-owned skb, so later error returns cannot leave callers with a stale pointer. The Ethernet users, ip6gretap and ip6erspan, clear IFF_TX_SKB_SHARING and already call skb_cow_head() before entering ip6_tnl_xmit(). They do not rely on the removed skb_shared() reallocation. This also makes the IPv6 tunnel path consistent with ip_tunnel_xmit(). Fixes: 058214a4d1df ("ip6_tun: Add infrastructure for doing encapsulation") Cc: stable@vger.kernel.org Reported-by: Vega Reviewed-by: Ido Schimmel Signed-off-by: Zhiling Zou Link: https://patch.msgid.link/30807a062ccc5c9c8a5ec2c5eb805ef279c50bdd.1786452593.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a8af6fbac895f057c4b8ff8a2e3fb4c5827fe4ce Author: Zhiling Zou Date: Thu Aug 13 00:36:38 2026 +0800 ip: orphan prefetched skbs before multicast forwarding commit e36ce6e78fe3fc3c071a26750783b7ba081ce10d upstream. IPv4 and IPv6 input preserve an skb->sk association installed by bpf_sk_assign() so that local delivery can use the selected socket under RCU. Both address families can also prefetch a socket in UDP early demux. In both paths (BPF and UDP early demux) a reference is not guaranteed to be held on the socket. When a multicast packet is not locally deliverable, IPv6 hands the original skb to ip6_mr_input(). IPv4's ip_mr_input() similarly keeps the original skb when local delivery is not needed. Either path can put the skb on an unresolved multicast route queue or forward it after the receive-side RCU section ends. After the prefetched socket is destroyed, a later skb free invokes sock_pfree() and dereferences the stale skb->sk. Orphan the skb before each non-local multicast forwarding path. Local delivery retains the original skb; the existing skb_clone() calls provide multicast forwarding with a socket-free clone. Fixes: cf7fbe660f2d ("bpf: Add socket assign support") Fixes: 08842c43d016 ("udp: no longer touch sk->sk_refcnt in early demux") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Reported-by: Vega Signed-off-by: Zhiling Zou Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/0c52eb3d7532aaf8bccf37e0f7c922143c639735.1786552223.git.zhilinz@nebusec.ai Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 31e4be21dacee49395013caae28576484a049a4f Author: Anton Danilov Date: Wed Aug 19 13:43:39 2026 +0300 ipip: fix skb leak in collect_md mode when metadata_dst allocation fails commit 6776efe4a52f289a3fc18f8adf19b035a7d8e1bb upstream. In collect_md mode ipip_tunnel_rcv() returns 0 without freeing the skb when ip_tun_rx_dst() fails to allocate the metadata_dst. ipip_rcv() and mplsip_rcv() are registered as xfrm_tunnel handlers, so tunnel4_rcv() and tunnelmpls4_rcv() read the zero return as "the packet has been consumed" and do not free it either. The skb is leaked. The other tunnel drivers all dispose of the packet at this point: ip6_tunnel.c jumps to its drop label, ip_gre.c and ip6_gre.c return PACKET_REJECT, which makes gre_rcv() free the skb. Only ipip returns 0. Jump to the existing drop label instead. It frees the skb and still returns 0, so the packet keeps being reported as consumed, which is what we want here: the outer header has already been pulled, and neither the remaining handlers nor an ICMP unreachable have any use for it. Triggering this needs an ipip or mplsip tunnel in collect_md mode and an atomic allocation failure, which is why it has gone unnoticed. Fixes: cfc7381b3002 ("ip_tunnel: add collect_md mode to IPIP tunnel") Cc: stable@vger.kernel.org Signed-off-by: Anton Danilov Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260819104338.432631-2-littlesmilingcloud@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f9182a85991a0ad5cd2940df6db75f40ad90028c Author: Max Kellermann Date: Mon Jul 13 12:22:28 2026 +0200 jbd2: check need_resched() when skipping busy checkpoint buffers commit f213e12ff5c9590b1034ae8da0e6d09665c772d0 upstream. journal_shrink_one_cp_list() skips busy checkpoint buffers when called with JBD2_SHRINK_BUSY_SKIP. The continue statement on this path also skips the need_resched() check at the end of the loop body. Consequently, when a checkpoint list contains mostly busy buffers, the shrinker can walk the entire list while holding journal->j_list_lock, even when a reschedule has been requested. Large checkpoint lists under memory pressure can therefore cause long lock hold times and leave other CPUs spinning on j_list_lock, resulting in soft lockups or RCU stalls. Route the busy-buffer path through the need_resched() check so that the shrinker can release j_list_lock and reschedule promptly, restoring parity with the clean-buffer path, which already checks need_resched(). This does not change which checkpoint buffers are eligible for removal. Fixes: b98dba273a0e ("jbd2: remove journal_clean_one_cp_list()") Cc: stable@vger.kernel.org Signed-off-by: Max Kellermann Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260713102229.1598812-2-max.kellermann@ionos.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 71c6b872c746465fa4b5def239cb296173ca8216 Author: Max Kellermann Date: Mon Jul 13 12:22:29 2026 +0200 jbd2: bound shrinker scans by examined checkpoint buffers commit 15cb16496446b94e67f7abcb049b8e2c75cd3d02 upstream. The jbd2 shrinker currently accounts only checkpoint buffers that it successfully releases against nr_to_scan. Busy buffers therefore do not consume the scan budget. If a checkpoint transaction contains mostly busy buffers, the shrinker can scan its entire checkpoint list while holding journal->j_list_lock. Large checkpoint lists can result in excessive lock hold times and leave other CPUs spinning on j_list_lock, causing soft lockups or RCU stalls. Pass nr_to_scan into journal_shrink_one_cp_list() and decrement it for every buffer examined, including busy buffers. Pass NULL from checkpoint cleanup paths so their existing full-list behavior is preserved. This restores the scan-budget semantics that existed before journal_shrink_one_cp_list() was changed to always scan a complete checkpoint list. Fixes: b98dba273a0e ("jbd2: remove journal_clean_one_cp_list()") Cc: stable@vger.kernel.org Signed-off-by: Max Kellermann Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260713102229.1598812-3-max.kellermann@ionos.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 30e8cb8598aa41b1b9f8803081d2ae5e5369c0f3 Author: Hui Su Date: Sat Aug 8 11:14:59 2026 +0800 kasan: fix cache shrink race with CPU hotplug commit 8790303cbaac52a11dfed4aab261f8ea60682525 upstream. kasan_quarantine_remove_cache() first invokes per_cpu_remove_cache() on all online CPUs. Each callback moves objects belonging to the cache from cpu_quarantine to the CPU's shrink_qlist, where they can later be freed from task context. kmem_cache_destroy() invokes the quarantine removal path while holding cpus_read_lock(), but kmem_cache_shrink() does not. The latter can therefore race with CPU offlining as follows: kmem_cache_shrink() CPU hotplug ------------------- ----------- on_each_cpu() CPU1 moves objects to CPU1's shrink_qlist on_each_cpu() returns CPU1 goes offline kasan_cpu_offline() drains cpu_quarantine leaves shrink_qlist untouched for_each_online_cpu() skips CPU1 The objects left on CPU1's shrink_qlist are not returned to the slab allocator. This may prevent kmem_cache_shrink() from releasing slabs that would otherwise become empty. If CPU1 remains offline, a later kmem_cache_destroy() also skips the list and can report that the cache still contains objects. An intermittent occurrence was observed with a virtio-9p filesystem. The mount and umount commands both returned 0, but the kernel logged the following during the userspace-triggered teardown: [ 2994.380134][ T111] BUG 9p-fcall-cache-1 (Tainted: G B ): Objects remaining on __kmem_cache_shutdown() [ 2994.381140][ T111] Object 0xff11000004361118 @offset=4376 [ 2994.381607][ T111] Allocated in p9_fcall_init+0x201/0x400 age=19564 cpu=1 pid=104 [ 2994.382591][ T111] p9_fcall_init+0x201/0x400 [ 2994.382810][ T111] p9_tag_alloc+0x12f/0x700 [ 2994.382982][ T111] p9_client_prepare_req+0x102/0x3e0 [ 2994.383165][ T111] p9_client_rpc+0x1ab/0xa50 [ 2994.383334][ T111] p9_client_getattr_dotl+0xb0/0x1a0 [ 2994.383515][ T111] v9fs_vfs_getattr_dotl+0x115/0x360 [ 2994.383719][ T111] vfs_getattr_nosec+0x22c/0x3a0 [ 2994.383910][ T111] vfs_statx+0xd7/0x170 [ 2994.384062][ T111] vfs_fstatat+0x45/0x80 [ 2994.384215][ T111] __do_sys_newfstatat+0x84/0xe0 [ 2994.384386][ T111] do_syscall_64+0x115/0x6a0 [ 2994.384566][ T111] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2994.399720][ T111] WARNING: mm/slub.c:1244 at __kmem_cache_shutdown+0x363/0x500, CPU#0: busybox/111 [ 2994.405655][ T111] Call Trace: [ 2994.406325][ T111] kmem_cache_destroy+0x73/0x1b0 [ 2994.406630][ T111] p9_client_destroy+0x271/0x3c0 [ 2994.407210][ T111] v9fs_session_close+0x3c/0x260 [ 2994.407409][ T111] v9fs_kill_super+0x48/0x90 [ 2994.407584][ T111] deactivate_locked_super+0xa3/0x160 [ 2994.407778][ T111] cleanup_mnt+0x1dd/0x3e0 Thus, a successful umount left objects in the 9p fcall cache and prevented the cache from being destroyed cleanly. Per-CPU shrink_qlist storage exists for every possible CPU, and each list is protected by its own raw spinlock. Iterate over possible CPUs so that a list populated before its CPU went offline is drained as well. for_each_possible_cpu() can do more work than for_each_online_cpu(), but this change only affects CONFIG_KASAN_GENERIC kernels. The extra work is limited to cache shrink and cache destruction paths and does not affect the normal allocation/free fast path. It adds one raw-spinlock-protected scan of each possible CPU's shrink list. These lists are normally empty; a non-empty list is traversed to remove objects belonging to the cache being shrunk or destroyed. Link: https://lore.kernel.org/20260808031459.3032812-1-sh_def@163.com Fixes: 07d067e4f2ce ("kasan: fix sleeping function called from invalid context on RT kernel") Signed-off-by: Hui Su Reviewed-by: Andrey Ryabinin Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Dmitry Vyukov Cc: Vincenzo Frascino Cc: "Zhang, Qiang1" Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 15deb4e33f474fcccd1ad1540a303c5dc9ca486a Author: Ibrahim Abdelkader Date: Tue Aug 11 10:37:29 2026 +0200 Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last request commit cb19774faa57c51efa189d8b8606aeabccebc53b upstream. A synchronous HCI command that never receives a response leaves HCI_CMD_PENDING set: hci_req_cmd_complete() is the only place that clears it, and it only runs when a response matching the last command sent arrives. hci_send_cmd_sync() populates hdev->req_skb only when the flag transitions from clear to set, while hci_dev_open_sync() and hci_dev_close_sync() drop req_skb without clearing the flag. After a timeout followed by either, the two disagree: the flag claims a request is outstanding while req_skb is NULL. Subsequent synchronous commands are then sent with no req_skb, so hci_event_packet() has nothing to match an arriving event against, and the caller times out even though the controller answered. Commands answered by Command Complete recover on their own, since hci_req_cmd_complete() clears the flag as a side effect. Drivers using __hci_cmd_sync_ev() with a custom event do not, because a vendor event never reaches that path. On a WCN3988 (hci_qca over UART) this makes a controller firmware hang unrecoverable: the driver injects a hardware error and re-runs qca_setup(), qca_read_soc_version() waits for HCI_EV_VENDOR, the reply arrives within 4 ms and is discarded, and every retry fails the same way. The adapter is left down until the driver is unbound and rebound, or power is removed. Clear the flag wherever the last request is dropped, restoring the invariant that req_skb is non-NULL exactly when HCI_CMD_PENDING is set. Verified on hardware by forcing a command timeout: without this change setup fails on every attempt, with it setup succeeds on the first. Fixes: 2615fd9a7c25 ("Bluetooth: hci_sync: Fix overwriting request callback") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Abdelkader Signed-off-by: Hans de Goede Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 657054159d83a3bfd73e188e5bf9777c5c52d4fc Author: Guangshuo Li Date: Sat Aug 8 13:30:57 2026 +0800 Bluetooth: hci_intel: fix usage_count leak when autosuspend_delay is negative commit c7e9a8cb6918656884a0757c92465075c7555ffa upstream. intel_set_power() calls pm_runtime_use_autosuspend() when powering on the device, but the power-off path does not call the matching pm_runtime_dont_use_autosuspend() before disabling runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before disabling runtime PM. This issue was found by manual code inspection. Fixes: 74cdad37cd24 ("Bluetooth: hci_intel: Add runtime PM support") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 94d548fc264a2c47ee490c474f816e1276f80b8b Author: Guangshuo Li Date: Sat Aug 8 13:26:54 2026 +0800 Bluetooth: hci_h5: fix usage_count leak when autosuspend_delay is negative commit 853a92b97ca547a7ddd9790ff90651b2fd943498 upstream. h5_btrtl_open() calls pm_runtime_use_autosuspend(), but h5_btrtl_close() does not call the matching pm_runtime_dont_use_autosuspend() when tearing down runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during driver teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before disabling runtime PM. This issue was found by manual code inspection. Fixes: d9dd833cf6d2 ("Bluetooth: hci_h5: Add runtime suspend") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1bad0896cbc06476b14cf0aae2739022e111ffc8 Author: Valentin Kindschi Date: Tue Aug 18 15:29:35 2026 +0200 Bluetooth: hci_event: clear HCI_LE_ADV only on a created connection commit 941929abe5feaed672b9a52e330e547d333240c6 upstream. le_conn_complete_evt() clears HCI_LE_ADV before looking at the event status, on the premise stated in its comment that all controllers stop advertising when a connection is created. That premise only holds when a connection was actually created. On a non-zero status none was, and the controller is still advertising: after the host issues LE Create Connection Cancel the event arrives with Unknown Connection Identifier (0x02), and a connection timeout behaves the same way. Clearing the flag there leaves the host believing advertising is off while the controller has it on. It is also wrong for extended advertising, where several sets can be advertising at once. hci_cc_le_set_ext_adv_enable() is careful about this - on disabling one set it walks hdev->adv_instances and only clears HCI_LE_ADV once no instance is still enabled. The unconditional clear here discards that bookkeeping, so one set connecting drops the flag while the others keep advertising. The direction of the error matters. A flag left set is self-correcting: hci_disable_advertising_sync() sends LE Set Advertising Enable(0) and the command complete puts the state back. A flag left clear is not, because that same function returns early without sending anything while the flag is clear: - LE Set Advertising Parameters is then sent to a controller that is still advertising, and is correctly rejected with Command Disallowed (0x0c); - hci_enable_advertising_sync() returns at that point, before the LE Set Advertising Enable that would set HCI_LE_ADV again. On a controller without LE Extended Advertising that is reachable from here: hci_schedule_adv_instance_sync() re-arms adv_instance_expire every HCI_DEFAULT_ADV_DURATION (2 s) and its "already advertising" shortcut tests HCI_LE_ADV, which can no longer become true, so the parameter write is retried for as long as advertising is configured: Bluetooth: hci0: Opcode 0x2006 failed: -16 Only clear the flag when a connection was established. Note this is not on its own sufficient to stop that retry loop - the redundant enable queued by hci_le_conn_failed() clears HCI_LE_ADV itself and recreates the same mismatch, which patch 1 addresses. This patch fixes the event handler reporting a state the controller is not in. Verified on the affected device (BCM43455, legacy advertising only) with this patch and patch 1 applied. A 221 s btmon capture with an out-of-range peer at -90 dBm contains two outgoing connection attempts that the host cancelled, each producing exactly the event this patch changes: < LE Set Advertising Parameters 0x2006 Success < LE Set Advertising Enable 0x200a Success < LE Create Connection Cancel 0x200e Success > LE Connection Complete Unknown Connection Identifier (0x02), central Nothing follows either one; the next command is an unrelated scan restart 70 ms later. Over the whole capture: 7 LE Set Advertising Parameters sent, all Success; 10 LE Set Advertising Enable, all Success; no Command Disallowed of any opcode, and no 2 s cadence anywhere. Two central connections to other peers completed normally afterwards, with feature exchange and a connection parameter update, so advertising was still live across the cancelled attempts. The extended advertising case above is a code argument, not a measurement: this controller has no LE Extended Advertising, so that path is not exercised by the capture. Fixes: fbd96c151cdc ("Bluetooth: Fix clearing HCI_LE_ADV for LE connections") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 btmon Signed-off-by: Valentin Kindschi Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit d0b28e9655f4b3195210627577f81883dc1d0162 Author: Xin Chen Date: Wed Aug 19 21:53:21 2026 +0800 Bluetooth: hci_core: use skb_get() instead of skb_clone() for req_skb commit f5afdff569a09d1cb8cf19826199d024725576cb upstream. BT enable fails intermittently with -ETIMEDOUT (-110). The kernel log shows the HCI Read Local Version command was sent and the firmware replied with status 0x00 (logged by hci_req_cmd_complete() BT_DBG), but the waiter in __hci_cmd_sync_sk() never woke up and timed out after 10 s: bluetooth hci0: Opcode 0xfc00 // __hci_cmd_sync_sk bluetooth hci0: opcode 0xfc00 plen 1 // hci_cmd_sync_add bluetooth hci0: skb len 4 // hci_cmd_sync_alloc bluetooth hci0: length 1 // hci_req_sync_run Bluetooth: hci0 cmd_cnt 1 cmd queued 1 // hci_cmd_work Bluetooth: hci0 type 1 len 4 // hci_send_frame Bluetooth: opcode 0xfc00 status 0x00 // hci_req_cmd_complete <-- req_skb NULL: req_complete_skb not set, hci_cmd_sync_complete() never called, req_status stays HCI_REQ_PEND --> <-- 10 s later: wait_event_interruptible_timeout expires --> bluetooth hci0: end: err -110 // __hci_cmd_sync_sk The root cause is that hci_send_cmd_sync() clones the sent command into hdev->req_skb so that hci_req_cmd_complete() can locate the registered completion callback. Under memory pressure this skb_clone() fails, leaving hdev->req_skb NULL. The firmware reply is received and processed, but hci_req_cmd_complete() finds NULL req_skb, so hci_cmd_sync_complete() is never called, req_status stays HCI_REQ_PEND, and the waiter times out with -ETIMEDOUT. req_skb is only used to read bt_cb(skb)->hci callbacks and opcode -- it is never modified. Replace skb_clone() with skb_get(), which simply increments the reference count of hdev->sent_cmd without allocating new memory and therefore cannot fail. This issue was first observed as a use-after-free in ttyport_close() when ttyport_open() failed, which was investigated in an earlier patch series [1]. That investigation led to the discovery of the true root cause described above. [1] https://lore.kernel.org/all/20250430111617.1151390-1-quic_cxin@quicinc.com/ Fixes: 2615fd9a7c25 ("Bluetooth: hci_sync: Fix overwriting request callback") Cc: stable@vger.kernel.org Signed-off-by: Xin Chen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 68e7a31abc88bc3d07befb05fd5dc30f8f8ea92a Author: Valentin Kindschi Date: Tue Aug 18 15:29:34 2026 +0200 Bluetooth: hci_conn: re-enable advertising only for peripheral role commit ed5fb41d3b6b6e665e7f97fd54bd1f9531c7477f upstream. hci_le_conn_failed() unconditionally calls hci_enable_advertising(), although its own comment states advertising should be re-enabled only when the failed attempt was made as a peripheral. hci_le_conn_failed() is reached from hci_conn_failed() for every failed LE connection, including outgoing central connections. For a central attempt this enable is redundant: hci_le_create_conn_sync() already restores advertising via hci_resume_advertising_sync() in its done: block. Because hci_enable_advertising() only queues the work on cmd_sync_work, it runs *after* that resume has already succeeded and set HCI_LE_ADV. The resulting HCI sequence, captured on a BCM43455 (no LE Extended Advertising, so legacy advertising is used): LE Create Connection Status Success ... 13.8 s, peer never answers ... LE Set Advertising Parameters (0x2006) Success <- done: resume, LE Set Advertising Enable (0x200a) Success HCI_LE_ADV set LE Create Connection Cancel (0x200e) Success LE Connection Complete Unknown Conn Id LE Set Advertising Parameters (0x2006) Command Disallowed (0x0c) The last command is the queued enable from hci_le_conn_failed() running as a second hci_enable_advertising_sync() pass. It clears HCI_LE_ADV (hci_sync.c, "Clear the HCI_LE_ADV bit temporarily"), then sends LE Set Advertising Parameters while the controller is still advertising, which the controller correctly rejects with Command Disallowed. The disable-first call at the top of hci_enable_advertising_sync() cannot prevent this: hci_disable_advertising_sync() returns early without sending anything when HCI_LE_ADV is clear, so it is a no-op exactly when the flag is wrong. hci_enable_advertising_sync() then returns without sending LE Set Advertising Enable, so HCI_LE_ADV is never set again. The legacy software rotation loop re-arms hci_schedule_adv_instance_sync() every HCI_DEFAULT_ADV_DURATION (2 s), and its "already advertising" shortcut tests HCI_LE_ADV, which can no longer become true. The command is therefore retried every 2 s indefinitely: Bluetooth: hci0: Opcode 0x2006 failed: -16 Observed on a gateway as 5326 occurrences over 3 hours, ending only when bluetoothd was restarted. Connection attempts that succeed do not call hci_le_conn_failed() and never trigger this. Add the role test the comment already describes. Both other hci_enable_advertising() call sites reached from a failed/closed LE connection (hci_cs_disconnect() and hci_disconn_complete_evt()) already guard on conn->role == HCI_ROLE_SLAVE; this one was missed. Reproducing needs legacy advertising (ext_adv_capable() false, so the software rotation loop is used), simultaneous peripheral advertising and outgoing central connects, and a central connect that times out rather than failing fast. The Fixes tag points at the commit that introduced the advertising restart into this path for the directed-advertising (peripheral) case; the role test that the later commit 0b1db38ca26b ("Bluetooth: Fix check for direct advertising") added to the sibling paths was never applied here. Fixes: 3c857757ef6e ("Bluetooth: Add directed advertising support through connect()") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 btmon Signed-off-by: Valentin Kindschi Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 946d76db77ee5f922968ce558629ae47b381e3fc Author: Chengfeng Ye Date: Sun Aug 23 00:43:41 2026 +0800 Bluetooth: RFCOMM: serialize security confirmation handling commit 759c185d0bbdb131357408f50b8735e04ed3caff upstream. rfcomm_security_cfm() looks up a session on session_list and then walks its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown uses rfcomm_mutex, krfcommd can close and free the same session and DLCs concurrently: hci_rx_work krfcommd ----------- --------- rfcomm_session_get() rfcomm_lock() rfcomm_session_close() rfcomm_dlc_unlink() rfcomm_session_del() kfree(s) rfcomm_unlock() walk s->dlcs The callback can then read a freed session list head and touch freed DLCs while updating their flags or timers. Serialize the session lookup and DLC traversal in rfcomm_security_cfm() with rfcomm_mutex. This matches the existing RFCOMM session lifetime rules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink() from tearing the objects down while the callback is using them. KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440 Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89 Workqueue: hci0 hci_rx_work Call Trace: rfcomm_security_cfm+0x41c/0x440 hci_encrypt_cfm+0x139/0x590 hci_encrypt_change_evt+0x37b/0xc40 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 69: rfcomm_session_add+0x9e/0x2f0 rfcomm_run+0x44b/0x41e0 Freed by task 69: kfree+0x131/0x3c0 rfcomm_session_del+0x188/0x220 rfcomm_run+0x1985/0x41e0 Fixes: 08c30aca9e698faddebd34f81e1196295f9dc063 ("Bluetooth: Remove RFCOMM session refcnt") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 49fd7116f76b860b230843700fb7423ab5331e1f Author: Hang Nan <2122295973@qq.com> Date: Wed Aug 19 08:57:58 2026 +0800 Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready commit 560bef609fa5992745929e8d7d458b9d88dd2830 upstream. iso_conn_ready() looks up the BIS listener socket with iso_get_sock(), which takes a reference, and then, without re-checking its state, creates a child socket from it: parent = iso_get_sock(hdev, ...); if (!parent) return; lock_sock(parent); sk = iso_sock_alloc(sock_net(parent), NULL, BTPROTO_ISO, ...); ... iso_chan_add(conn, sk, parent); ... release_sock(parent); sock_put(parent); If the listener socket is closed concurrently, between iso_get_sock() and lock_sock(), the reference taken by iso_get_sock() may be the last one: the close path drops the link-list reference, and once iso_conn_ready() drops its own reference at the end of the function the socket is freed. The child socket, however, is already linked to the freed parent, and a later disconnect of the child runs iso_chan_del() -> bt_accept_unlink(), which dereferences the dangling parent pointer into the freed accept queue (a use-after-free). The same dangling pointer is also dereferenced through parent->***() in iso_chan_del(). Fix it the same way the connected (non-BIS) path was fixed in commit 0d255e63fcf3 ("Bluetooth: ISO: hold sk properly in iso_conn_ready"): after taking the socket lock, re-check that the parent is still a listening, alive socket, and bail out otherwise. Fixes: ccf74f2390d60 ("Bluetooth: Add BTPROTO_ISO socket type") Cc: stable@vger.kernel.org Signed-off-by: Hang Nan <2122295973@qq.com> Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit ec3992e38f777b1c77ebf806c0e0360c54e69cca Author: Gongwei Li Date: Fri Aug 21 10:45:55 2026 +0800 Bluetooth: hci_uart: Fix false success return in hci_uart_setup() commit a9355799343e10014f2acfd4b6844d2335ecafea upstream. When reading the local version information for vendor detection fails, the error is only printed and 0 is returned, which masks the setup failure from the HCI core. Return PTR_ERR(skb) instead. Fixes: fb2ce8d11f039 ("Bluetooth: hci_uart: Add support for vendor detection flag") Fixes: 82f5169bf3d3b ("Bluetooth: hci_uart: add serdev driver support library") Cc: stable@vger.kernel.org Signed-off-by: Gongwei Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 62100186f17711c1a16f2caa06918597a09b7156 Author: Guangshuo Li Date: Sat Aug 8 13:15:32 2026 +0800 Bluetooth: hci_bcm: fix usage_count leak when autosuspend_delay is negative commit dc6b7c771a963e20aedf4a21ffa22543b9837ba8 upstream. bcm_request_irq() calls pm_runtime_use_autosuspend(), but bcm_close() does not call the matching pm_runtime_dont_use_autosuspend() when tearing down runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during driver teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before disabling runtime PM. This issue was found by manual code inspection. Fixes: e88ab30d3669 ("Bluetooth: hci_bcm: Add suspend/resume runtime PM functions") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1ed5982c536994a2640e07b13326e29929aa97c1 Author: Lorenzo Stoakes (ARM) Date: Tue Aug 18 10:49:34 2026 +0100 Bluetooth: hci_bcm4377: Ignore reserved PHY in ext adv reports on BCM4378 commit aec6a8d80e3da0ab5c9303a0281fd06d077f8716 upstream. Commit ed2a2ef16a6b ("Bluetooth: Add quirk to ignore reserved PHY bits in LE Extended Adv Report") added a quirk to handle creative use of the reserved bits in the PHY fields for 4388 controllers in Apple silicon. I observed the same issue with the BCM4378 Bluetooth controller (14e4:5f69, rev 05) on an Apple MacBook Pro (13-inch, M2, 2022): > HCI Event: LE Meta Event (0x3e) plen 51 LE Extended Advertising Report (0x0d) Num reports: 1 Entry 0 Event type: 0x2513 Props: 0x0013 Connectable Scannable Use legacy advertising PDUs Data status: Complete Reserved (0x2500) Legacy PDU Type: Reserved (0x2513) Address type: Random (0x01) Address: EA:C1:82:F0:24:C6 (Static) Primary PHY: Reserved Secondary PHY: No packets SID: no ADI field (0xff) TX power: 127 dBm RSSI: -57 dBm (0xc7) Periodic advertising interval: 0.00 msec (0x0000) Direct address type: Public (0x00) Direct address: 00:00:00:00:00:00 (OUI 00-00-00) Data length: 25 This results in the firmware rejecting connection attempts with "Unsupported Feature or Parameter Value" (0x11). Fix the issue by using the same quirk for BCM4378 devices too. I tested this locally and confirmed that the issue is resolved. This was observed when attempting to connect a Kinesis Advantage 360 keyboard to the MacBook. Assisted-by: Claude:claude-fable-5 Fixes: 2e7ed5f5e69b ("Bluetooth: hci_sync: Use advertised PHYs on hci_le_ext_create_conn_sync") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Sven Peter Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit c674c504bfdd0bba88ae4f143842a267fb76e3a4 Author: Alison Schofield Date: Fri Jul 24 13:37:17 2026 -0700 cxl/pmem: Format the nvdimm serial number as unsigned decimal commit 8a80d3d65cd06ee35b913d8517fb2f2319f8e70c upstream. The CXL NVDIMM security passphrase key description and the nvdimm 'id' sysfs attribute are both derived from the CXL device serial number, but the serial number is not formatted consistently. The key description is formatted in hexadecimal while the 'id' attribute is formatted in decimal. As a result, ndctl stores the key using a decimal description while the kernel later looks it up using a hexadecimal description. For serial numbers of 10 and above, the descriptions no longer match, preventing automatic unlock after reboot. The decimal formatting has a second problem: both the key description and the 'id' attribute use the signed %lld format for a u64 PCIe Device Serial Number. Devices whose vendor OUI sets bit 63, such as Montage CXL devices, appear with negative decimal serial numbers. Format the security key description and 'id' attribute as unsigned decimal, %llu, and document that the 'id' attribute is an unsigned decimal value. The key lookup mismatch was exposed by CXL unit test cxl-security.sh when cxl_test mock serial numbers were extended to 10 and above. A work around is described for ndctl load-key users here: https://github.com/pmem/ndctl/issues/299 Cc: stable@vger.kernel.org Fixes: b5807c80b5bc ("cxl: add dimm_id support for __nvdimm_create()") Acked-by: Dan Williams Signed-off-by: Alison Schofield Link: https://patch.msgid.link/2c673a5ba0a8fa93ad160578e193bd556091fa95.1784924949.git.alison.schofield@intel.com Signed-off-by: Dave Jiang Signed-off-by: Greg Kroah-Hartman commit 14d52c15d5d99477b20a2d61fe36f347080da6cd Author: Zhenhao Wan Date: Sat Jun 20 12:33:15 2026 +0800 cxl/features: bound fwctl command payload to the input buffer commit f687394af983df5660b6afae7e0d06969f3af206 upstream. fwctl_cmd_rpc() copies cmd->in_len bytes into inbuf = kvzalloc(cmd->in_len) and passes inbuf and in_len to ->fw_rpc(). The CXL callback cxlctl_fw_rpc() ignores in_len and never checks the user-controlled op_size against it. cxlctl_set_feature() bounds op_size only from below (op_size <= sizeof(feat_in->hdr)) and then reads op_size - sizeof(hdr) bytes from feat_in->feat_data via cxl_set_feature(). With a small in_len and a large op_size the first memcpy() already reads past the kvzalloc(in_len) buffer; the out-of-bounds bytes are placed in the mailbox payload and sent to the device, and a large enough op_size can walk into unmapped memory and oops the kernel. The Get paths pin op_size to a fixed size but likewise read the input struct without checking in_len. Reject, at the single dispatch point, any request whose fixed header plus op_size does not fit in the copied-in buffer. The lower-bound test guards the subtraction and ensures op_size was copied in before it is read. Fixes: eb5dfcb9e36d ("cxl: Add support to handle user feature commands for set feature") Reported-by: Yuhao Jiang Signed-off-by: Zhenhao Wan Cc: stable@vger.kernel.org Reviewed-by: Jason Gunthorpe Link: https://patch.msgid.link/20260620-cxl-fwctl-oob-v1-1-5758e34d784a@gmail.com Signed-off-by: Dave Jiang Signed-off-by: Greg Kroah-Hartman commit 2924b2e3651481142c9872738b30eab5213d29fb Author: Hui Su Date: Thu Aug 6 22:23:04 2026 +0800 cpufreq: schedutil: Fix rate limit overflow commit 3bff8f8e95fdc6ad19c8a1a8f87029094747e4bf upstream. rate_limit_us is an unsigned int, while NSEC_PER_USEC is defined as 1000L. On 32-bit systems, the multiplication is therefore performed using 32-bit unsigned arithmetic before the result is assigned to freq_update_delay_ns. For example, writing 4294968 to rate_limit_us wraps the delay from 4294968000 ns to 704 ns. This makes schedutil update far more often than configured. Add sugov_update_rate_limit_us() to widen rate_limit_us to s64 before converting it to nanoseconds. Use the helper when updating the tunable through sysfs and when starting the governor, so both paths perform the conversion without overflow. Fixes: 9bdcb44e391d ("cpufreq: schedutil: New governor based on scheduler utilization data") Signed-off-by: Hui Su Reviewed-by: Zhongqiu Han Cc: All applicable Link: https://patch.msgid.link/20260806142304.1761454-1-sh_def@163.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit a807a9ef87ad04ae70f1113586a089f9b32c4290 Author: Kuan-Wei Chiu Date: Tue Dec 2 08:26:13 2025 +0000 coresight: etm3x: Fix cntr_val_show() to match cntr_val_store() behavior commit 41fb4e925528aefa4b7a5f76c7f81db99c0d0f38 upstream. The cntr_val_show() function was intended to print the values of all counters using a loop. However, due to a buffer overwrite issue with sprintf(), it effectively only displayed the value of the last counter. The companion function, cntr_val_store(), allows users to modify a specific counter selected by 'cntr_idx'. To maintain consistency between read and write operations and to align with the ETM4x driver behavior, modify cntr_val_show() to report only the value of the currently selected counter. This change removes the loop and the "counter %d:" prefix, printing only the hexadecimal value. It also adopts sysfs_emit() for standard sysfs output formatting. Fixes: a939fc5a71ad ("coresight-etm: add CoreSight ETM/PTM driver") Cc: stable@vger.kernel.org Signed-off-by: Kuan-Wei Chiu Reviewed-by: James Clark Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20251202082613.3265761-1-visitorckw@gmail.com Signed-off-by: Greg Kroah-Hartman commit ac4a5eb8b002a0742c938fc98b922e243f53573a Author: Bryam Vargas Date: Fri Jul 31 17:54:55 2026 -0500 dm array: reject an array block whose value size is not the caller's commit 4538a287bdf5d0f9a379c678e5262b9f5783f547 upstream. array_block_check() can only compare the header against itself, so a block with value_size 4 and max_entries 1018 is internally consistent and passes. dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and the roots for both live in the superblock. Point the mappings root at a hint block and __load_mappings() walks it through an info whose value size is 8, so element_at() strides 8 bytes over 4-byte entries and reaches offset 8160 of a 4096-byte block. get_ablock() and __shadow_ablock() are the two places that hold the block and the caller at once. Reject there when the two value sizes disagree. Arrays only ever read their own blocks, so this fires on crafted metadata only. Fixes: 6513c29f44f2 ("dm persistent data: add transactional array") Suggested-by: Ming-Hung Tsai Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit b33f76d33aaeacf3baf3370d8d64985169b36600 Author: Bryam Vargas Date: Fri Jul 31 17:54:54 2026 -0500 dm array: validate array block headers on read commit 2965787723084835b18dfe993cd450ebf5bd4540 upstream. array_block_check() validates blocknr and csum and nothing else, while node_check(), next to it, has bounded the structural fields since both were written. dm_array_cursor_next() takes its loop bound from the on-disk nr_entries and element_at() is unguarded pointer arithmetic, so a count larger than the block holds keeps the cursor in one block while the index grows past it and the read walks off the dm-bufio buffer -- dm_cache_load_mappings() drives it once per cache block at activation. Check the header against itself: reject a zero value_size, require max_entries to equal calc_max_entries() for that value_size and block size, and require nr_entries to fit. Equality rather than an upper bound, since a count below the real capacity trips BUG_ON() in fill_ablock() and trim_ablock(). Metadata dm-array writes satisfies all three. Fixes: 6513c29f44f2 ("dm persistent data: add transactional array") Suggested-by: Ming-Hung Tsai Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 644140527ae494cedf3b5c0ecd16287deaea7a66 Author: Ilya Krutskih Date: Sun Jul 19 13:01:03 2026 +0000 dm raid1: reserve space for NUL-terminator in build_constructor_string() commit 73c37fe54cd056d07461b142ab0b8b81e1ef6ad8 upstream. Reserve space for the termination NUL after the maximum 20 decimal digits of a long long value to avoid buffer overflow in sprintf(). Fixes: f5db4af466e2 ("dm raid1: add userspace log") Cc: stable@vger.kernel.org Signed-off-by: Ilya Krutskih Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 36ff918637e3517f732188a3c39dbeae5b9cfb1b Author: liyouhong Date: Fri Jul 31 10:08:49 2026 +0800 dm-era: fix shadowed superblock leak on take-snap failure commit 39c5aa3bd8ec3912d2cd0b3fe092642b0d2b0713 upstream. metadata_take_snap() bumps the live superblock refcount and then dm_tm_shadow_block() allocates a new block for the metadata snapshot. If the subsequent dm_sm_inc_block() of writeset_tree_root or era_array_root fails, the function only unlocks the clone and returns. The newly allocated shadow block is never returned to the metadata space map, so each failed take-snap permanently leaks one metadata block. Free the clone with dm_sm_dec_block() on those error paths, matching the final step of metadata_drop_snap(). Fixes: eec40579d848 ("dm: add era target") Cc: stable@vger.kernel.org Signed-off-by: liyouhong Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 49694a363f7ecd5a52d1ea1a13c287ad6d196c35 Author: Mikulas Patocka Date: Mon Jul 27 23:09:28 2026 +0200 dm-io: report non-retryable errors separatedly commit 47a5e62f39875f371bded6e34ffb9cf15ccd813d upstream. The error codes BLK_STS_NOTSUPP and BLK_STS_INVAL should not cause leg failure on dm-raid1. This patch changes the interface to dm-io, so that it reports two error bitmaps - error_bits and unsup_bits. The unsup_bit bitmap tracks BLK_STS_NOTSUPP or BLK_STS_INVAL errors, the error_bits bitmap tracks all the other errors. dm-raid1 is changed so that it won't fail a leg if it receives an error in the unsup_bits bitmap. This patch (with 62dc37a819a5) fixes misbehavior if the user uses unaligned bio vectors on dm-raid1. Fixes: 7eac33186957 ("iomap: simplify direct io validity check") Fixes: 5ff3f74e145a ("block: simplify direct io validity check") Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 9493ac67623d45b7d4671d2b0b4d0633c2bc2e51 Author: Keith Busch Date: Tue Jun 16 08:05:53 2026 -0700 dm-io: clone the source bio instead of copying its biovec commit 62dc37a819a5a5de5cba989ad9e96ee214b9253e upstream. For DM_IO_BIO requests, do_region() built each destination bio by walking the source bio's biovec and re-adding the pages one at a time, tracking the remaining transfer in sectors. The vector lengths are byte granular and need not be sector aligned (e.g. a misaligned O_DIRECT buffer split across pages), so the sector-based accounting could lose a sub-sector fragment: to_sector() truncated the remainder and the outer loop spun forever submitting empty bios, hanging the I/O. There is no need to rebuild the biovec at all. The destination reads into (or writes from) exactly the same pages as the source bio, so the bio can simply clone the source's biovec with bio_alloc_clone() and remap it to the target device. The clone inherits the source's iterator and alignment, and the block layer splits it to the target's limits on submission, so the whole region maps to a single cloned bio with no manual page copying or sector accounting. This removes the per-page copy path (and its open-coded bvec dpages helpers) for bio-backed I/O and fixes the hang on misaligned direct I/O to a dm-mirror device. Page-list, vma and kmem sources keep the existing copy path. Fixes: 7eac33186957 ("iomap: simplify direct io validity check") Fixes: 5ff3f74e145a ("block: simplify direct io validity check") Cc: stable@vger.kernel.org Reported-by: Dr. David Alan Gilbert Reported-by: Vjaceslavs Klimovs Signed-off-by: Keith Busch Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 272fcb4ba6fab678db0eb966dc81c4c804bef64a Author: Jérémy Jean Date: Wed Aug 5 06:02:28 2026 +0000 bpf: Harden bloom filter sizing and indexing on 32-bit kernels commit 11c1e836710dcba03e50454a4eedfdbaf8d3050e upstream. bloom_map_alloc() has two 32-bit-specific problems when the computed bitmap reaches the U32_MAX fallback case. First, BITS_TO_BYTES(U32_MAX) is evaluated with 32-bit arithmetic. The addition performed by DIV_ROUND_UP wraps, so the map allocates only the fixed-size bloom filter object while keeping bitset_mask == U32_MAX. Subsequent updates can then write past the allocated object. Second, fixing only the allocation size is not sufficient. The bloom hash is a u32, but set_bit() takes a signed long bit number and x86 test_bit() eventually feeds the index to variable_test_bit(long, ...). On 32-bit kernels, hashes in [0x80000000, U32_MAX] therefore become negative bit offsets. x86 bt/bts with a memory operand interpret those offsets relative to the supplied base, so a map with bitset_mask == U32_MAX can read or write before bloom->bitset even after allocating the full 512 MiB bitmap. Keep the U32_MAX fallback, but split each hash into a word pointer and an in-word bit number before calling test_bit() or set_bit(). The bitops argument is then always in [0, BITS_PER_LONG - 1], while BIT_WORD(h) still selects the intended word in the full bitmap. Compute the bitset size from (u64)bitset_mask + 1 before passing the final size to bpf_map_area_alloc(). This fixes the original under-allocation and keeps the allocated storage consistent with the addressable bitset. Exploitation note: local privilege escalation is possible on a 32-bit x86 kernel using the under-allocation bug from a binary with CAP_BPF. Fixes: 9330986c0300 ("bpf: Add bloom filter map implementation") Signed-off-by: Jérémy Jean Signed-off-by: Andrii Nakryiko Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260805060228.2703051-1-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Greg Kroah-Hartman Assisted-by: Codex:gpt-5 commit c9189693db47a891b885b50cfc3035b8ecbbddb6 Author: Jia Zhu Date: Tue Jun 9 11:52:01 2026 +0800 buffer: avoid tail commit walk for uptodate folios commit f10b9cc1eb20637351f4e33372bfb464f89de59b upstream. block_commit_write() always walks every buffer_head attached to the folio. That was cheap for order-0 folios, but large folios can contain hundreds of buffer_heads. For a small buffered overwrite of an already-uptodate large folio, the commit work is therefore proportional to the folio size rather than the copied range. This became visible with ext4 regular-file large folios, where cached small overwrites reach block_commit_write() through block_write_end(). Before ext4 enabled large folios for regular files, this path was only hit with order-0 folios for normal ext4 buffered writes, so the full walk was bounded. The ext4 large-folio commit is therefore the regression point for this generic helper cost. The full walk is still needed when the folio is not uptodate, because block_commit_write() uses per-buffer uptodate state to decide whether the whole folio can be marked uptodate. Keep those folios on the old full-buffer path. For a folio that was already uptodate on entry, the commit no longer needs tail buffers for folio-uptodate discovery. The copied range has already been processed once block_start reaches @to, so stop there and avoid the suffix walk. Fixes: 7ac67301e82f0 ("ext4: enable large folio for regular file") Suggested-by: Matthew Wilcox (Oracle) Cc: stable@vger.kernel.org # v6.16+ Reviewed-by: Jan Kara Signed-off-by: Jia Zhu Link: https://patch.msgid.link/20260609035202.90669-2-zhujia.zj@bytedance.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit dbfecc8a6631c0d3626c14ba1f1a485a4498445a Author: Daniel Borkmann Date: Mon Aug 3 23:01:47 2026 +0200 bpf: Disable preemption in __bpf_get_stack commit b1a47b2708d4e95dbd23aee2ec83752190897b3f upstream. get_perf_callchain() returns a per-CPU perf_callchain_entry buffer and releases its recursion slot via put_callchain_entry() before returning, so nothing keeps the entry reserved while __bpf_get_stack() consumes it below. A preemptible BPF program (e.g. a non-sleepable raw tracepoint program on a PREEMPT kernel, which runs under migrate_disable() but not preempt_disable()) can be scheduled out between obtaining the entry and the copy. Another task scheduled on the same CPU then reuses the same per-CPU buffer and overwrites trace->nr with a larger value. copy_len is then computed from the inflated trace->nr and can exceed the caller's buffer, causing an out-of-bounds write in the memcpy() and in the build_id path. The rcu_read_lock() taken here alone does not prevent this. It is only taken on the may_fault path, and under CONFIG_PREEMPT_RCU it does not disable preemption; it merely keeps perf's callchain buffer array alive (freed via call_rcu()) and does nothing to stop another task from reusing the entry. Disable preemption around obtaining the callchain entry and copying it into the caller's buffer, so the entry cannot be reused underneath us and trace->nr stays bounded by max_depth. Build ID resolution may fault and is therefore deferred until after preemption is re-enabled; by then the instruction pointers have already been copied into buf, so it operates only on that private copy. Note, preempt_disable() also subsumes the buffer-lifetime guarantee the rcu_read_lock() provided, since a preempt-disabled section is an RCU read-side critical section for the callchain buffers' call_rcu() reclaim. Fixes: c195651e565a ("bpf: add bpf_get_stack helper") Reported-by: Tao Chen Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260803210149.296496-11-jolsa@kernel.org Signed-off-by: Greg Kroah-Hartman Closes: https://lore.kernel.org/bpf/20260206090653.1336687-1-chen.dylane@linux.dev/ [ changed Fixes: commit ] commit 6886642414f59f928728802dc2c972a9859e6310 Author: Vineet Gupta Date: Fri Aug 14 15:02:53 2026 -0700 bpf, x86: Fix per-CPU address resolution into an extended register commit 5bbbce02e500d47d8e259a45be5a7be9741d0533 upstream. The destination of the per-CPU address MOV is encoded in ModRM.reg, which is extended by REX.R, but the REX prefix is built with add_1mod(), which sets REX.B. REX.B extends ModRM.rm and SIB.base, and this instruction addresses memory as disp32 with no base, so the bit has no effect at all and the high register bit is simply lost. Every is_ereg() destination therefore resolves to the wrong register, picking whichever one shares the low three bits: R5 -> RAX R7 -> RBP R8 -> RSI R9 -> RDI With BPF_REG_5, whose reg2hex is 0, the emitted 65 49 03 04 25 add %gs:,%rax adds the per-CPU offset to RAX rather than R8. The destination keeps the unadjusted address and RAX is clobbered, so the program goes on to dereference a pointer that was never made per-CPU: BUG: unable to handle page fault for address: 0000607e386a8894 RIP: bpf_prog_707837aafd2aa9ae_update_percpu_data+0x93/0xc9 Call Trace: __bpf_prog_test_run_raw_tp+0x2dc/0x7d0 __flush_smp_call_function_queue+0x1e9/0xc80 Kernel panic - not syncing: Fatal exception in interrupt R5 is the mildest of the four, aliasing a scratch register and faulting at the store. R7 aliases RBP and would corrupt the frame pointer, R8 and R9 alias the argument registers. Use add_2mod() so the register goes through REX.R, matching how add_2reg() places it in ModRM.reg and how emit_priv_frame_ptr() hardcodes 0x4c for the same instruction with R9. Encodings for the non-extended registers are unchanged. Problem showed up when trying to resurrect BPF_GCC CI (selftests built with BPF_GCC). This has gone unnoticed because clang reloads the address into R1 before each per-CPU access, so the destination is never an extended register. GCC keeps several per-CPU addresses live at once, and test_progs-bpf_gcc panics the kernel in global_percpu_data/init, where the address of a .percpu variable ends up in R5. Fixes: 7bdbf7446305 ("bpf: add special internal-only MOV instruction to resolve per-CPU addrs") Signed-off-by: Vineet Gupta Reviewed-by: Eduard Zingerman Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260814220254.3797467-2-vineet.gupta@linux.dev Signed-off-by: Eduard Zingerman Signed-off-by: Greg Kroah-Hartman commit 49dcefa83c8aba51b46fe71428bdd50e843447f8 Author: Joe Damato Date: Tue Aug 25 17:02:33 2026 -0700 bnxt_en: Write doorbell when linearizing skb fails commit 00eeab0c644a881a1dc86fbffb7e6047a6ce8ecd upstream. When the driver is handed a burst of packets, the doorbell is deferred until the end. If the last packet has a huge number of frags, but fails to linearize, the doorbell will not be written adding latency on TX for any packets in the ring and holding their DMA mappings until the next TX. Note that the queue is not stopped, so this issue would delay pending BDs until the next TX. This issue was discovered by Sashiko and reading the code verifies that, while unlikely, it is possible. Fix this by jumping to tx_free, which replicates the same pre-existing logic but also writes the doorbell. Fixes: b91e82129400 ("bnxt_en: Linearize TX SKB if the fragments exceed the max") Cc: stable@vger.kernel.org Signed-off-by: Joe Damato Reviewed-by: Michael Chan Reviewed-by: Andy Gospodarek Link: https://patch.msgid.link/20260826000234.2031564-1-joe@dama.to Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 4d36e38e48340a1ccf92a98c7a22d07a954e5aa3 Author: Jiangshan Yi Date: Sat Aug 15 20:21:49 2026 +0800 bnx2x: fix double free in bnx2x_init_firmware() error path commit d2796ffe38cb4155afe0eab23636295b096c27a5 upstream. bnx2x_init_firmware() frees bp->init_ops, bp->init_data and bp->init_ops_offsets in its error path without setting them to NULL. The cleanup function bnx2x_release_firmware() frees the same three pointers unconditionally, so if init_firmware fails and release_firmware is later called (e.g. from __bnx2x_remove or through the function state machine), all three are freed a second time. Set each pointer to NULL after kfree() in the error path so that the subsequent kfree(NULL) in bnx2x_release_firmware() is a safe no-op. Fixes: 94a78b79cb5f ("bnx2x: Separated FW from the source.") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260815122149.951215-1-yijiangshan@kylinos.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c21fa79301d7d6ac0a4ec6c51e8ba10beaa08c50 Author: HyeongJun An Date: Sat Aug 15 15:24:19 2026 +0900 Bluetooth: eir: Fix OOB read in eir_get_service_data() commit 4beb198bc59b242404a47c21990bc84165052c8a upstream. eir_get_service_data() walks the advertising data for a Service Data field with a matching UUID. On a mismatch it advances: eir += dlen; eir_len -= dlen; eir_get_data() reports dlen as the field's data length, but the field spans dlen + 2 bytes once its length and type bytes count, and more when non-Service-Data fields were skipped to reach it. The pointer lands correctly on the next field. eir_len does not, and the shortfall compounds across fields until eir_get_data() reads the length and type bytes of a "field" past the end of the buffer. For an ISO broadcast sink that buffer is hcon->le_per_adv_data[], filled from the periodic advertising reports of a remote broadcaster. A PA payload packed with mismatching Service Data fields walks off the array into the rest of struct hci_conn. A drifted field that matches the BAA UUID puts those bytes in iso_pi(sk)->base, where user space reads them back with getsockopt(BT_ISO_BASE). Recompute eir_len from the end of the buffer each iteration. Fixes: 8f9ae5b3ae80 ("Bluetooth: eir: Add helpers for managing service data") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit f609eac02d110874317e4c9411e34d135048d734 Author: Junjie Cao Date: Mon Aug 24 13:32:27 2026 +0800 Bluetooth: btusb: limit RTL8761B BROKEN_EXT_SCAN quirk to 0bda:a728 commit ca0583c24661749508a0979189c254388a685559 upstream. Commit 5ead2063611a ("Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan") set HCI_QUIRK_BROKEN_EXT_SCAN for every CHIP_ID_8761B device to cure repeated 0x2042 failures on an 0bda:a728 dongle. The brokenness is per-dongle, not per-chip: on a TP-Link UB500 (2357:0604, RTL8761BU, fw 0xdfc6d922) extended scan works, and the legacy scan path the quirk forces is what is broken -- LE Set Scan Enable (0x200c) times out with -110 about 30 s after firmware load, btusb resets the device, and the adapter re-enumerates in an endless loop (382 firmware reloads in one boot). 7.1.8, which predates the stable backport, runs clean on this unit; 7.1.9 loops. Move the quirk from btrtl's chip-wide switch to a btusb device-table flag on the USB id the original fix was verified against. Other 8761B dongles return to their earlier long-standing behaviour. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2521504 Fixes: 5ead2063611a ("Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan") Cc: stable@vger.kernel.org Signed-off-by: Junjie Cao Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit bce588b4ca081833ed8fc62062291f71d4218278 Author: Christoph Zwerschke Date: Sun Jul 5 11:28:57 2026 +0200 Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU commit 6f0624b4427e38c3bb63a951c536cf8adaee1238 upstream. Add the vendor/product ID (0x0b05, 0x1d70) to the usb_device_id table for the Realtek RTL8761CU-based ASUS USB-BT600 adapter. It binds via the generic Bluetooth class today, so BTUSB_REALTEK is never set and the rtl8761cu firmware is not loaded, leaving the controller non-functional. With the entry the driver loads rtl_bt/rtl8761cu_fw.bin (already shipped by linux-firmware) and the adapter works (tested: A2DP and ASHA). Similar to commit bc597f0cc44f ("Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV"). Device info from /sys/kernel/debug/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 23 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0b05 ProdID=1d70 Rev= 2.00 S: Manufacturer=Realtek S: Product=Bluetooth Controller C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms Cc: stable@vger.kernel.org Signed-off-by: Christoph Zwerschke Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit aa7b93fe98ba726971b7d0c68320ce513e68aac2 Author: Christoph Zwerschke Date: Sun Jul 5 11:28:56 2026 +0200 Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU commit 980084de4d9b25193398d89a1c0430ba3501b683 upstream. Add the vendor/product ID (0x0b05, 0x1bef) to the usb_device_id table for the Realtek RTL8761CU-based ASUS USB-BT540 adapter. It binds via the generic Bluetooth class today, so BTUSB_REALTEK is never set and the rtl8761cu firmware is not loaded, leaving the controller non-functional. With the entry the driver loads rtl_bt/rtl8761cu_fw.bin (already shipped by linux-firmware) and the adapter works (tested: A2DP and ASHA). Similar to commit bc597f0cc44f ("Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV"). Device info from /sys/kernel/debug/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 22 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0b05 ProdID=1bef Rev= 2.00 S: Manufacturer=Realtek S: Product=Bluetooth Controller C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms Cc: stable@vger.kernel.org Signed-off-by: Christoph Zwerschke Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit ce76ca5fb27948ca6e5e219dbce1cafb02ed49a1 Author: 胡连勤 Date: Wed Aug 12 11:59:04 2026 +0000 block: set QUEUE_FLAG_DYING unconditionally in blk_mark_disk_dead() commit 7e9a46004b471eaf69b082c473d865316a4158e0 upstream. Disks created via blk_mq_alloc_disk_for_queue() (e.g. SCSI SD disks) do not have GD_OWNS_QUEUE set. Currently __blk_mark_disk_dead() only sets QUEUE_FLAG_DYING when GD_OWNS_QUEUE is set, so for such disks blk_queue_enter() and __bio_queue_enter() cannot detect the dying state via blk_queue_dying() and remain blocked waiting for I/O that will never complete after surprise removal. blk_mark_disk_dead() is the explicit "surprise removal" API -- the caller has already decided the disk is dead. Setting QUEUE_FLAG_DYING unconditionally here is appropriate: any in-flight I/O from other threads should get -ENODEV immediately from blk_queue_enter() regardless of GD_OWNS_QUEUE ownership. For disks that already have GD_OWNS_QUEUE set, __blk_mark_disk_dead() will set the flag again which is harmless. Fixes: 6f8191fdf41d ("block: simplify disk shutdown") Cc: stable@vger.kernel.org Signed-off-by: Lianqin Hu Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/PUZPR06MB62247E82E66A3ED46CC3E6C7D2DC2@PUZPR06MB6224.apcprd06.prod.outlook.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 84858671842ae5857b9ed1202b62f9045373dcd1 Author: Hongyan Xu Date: Sat Aug 15 18:59:50 2026 +0800 auxdisplay: charlcd: cancel backlight work on registration failure commit e3e3bf40916c1e810df03958cfa7ba6883cdce79 upstream. With CONFIG_CHARLCD_BL_FLASH, charlcd_init() schedules bl_work before charlcd_register() calls misc_register(). If registration fails, the caller frees the charlcd object while delayed work still contains its address. Add charlcd_deinit() to cancel the delayed work and turn the backlight off. Use it for both registration rollback and normal unregistration. Fixes: 39f8ea46724e ("auxdisplay: charlcd: Extract character LCD core from misc/panel") Cc: stable@vger.kernel.org Reviewed-by: Geert Uytterhoeven Signed-off-by: Hongyan Xu Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit c2e3dccd6870659851eaa4c12ab16418b8e3040a Author: Niklas Cassel Date: Thu Jul 2 12:59:58 2026 +0200 ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes commit 79cce911e623c0baa0fde307ce3a434e084b881a upstream. ata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the UNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command. The TRIM descriptor is built by ata_format_dsm_trim_descr() into the 2048-byte ata_scsi_rbuf staging buffer, and the number of bytes copied is compared against the logical sector size by the caller: size = ata_format_dsm_trim_descr(scmd, trmax, block, n_block); if (size != len) /* len == sdp->sector_size */ goto invalid_param_len; ata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE (2048). On a device whose logical sector size exceeds that (e.g. a 4Kn device, where sector_size == 4096) the function can never return more than 2048, while the caller expects it to return sector_size. The comparison therefore always fails, so every TRIM is rejected with "Parameter list length error" and WARN_ON() splats on each attempt. TRIM / discard is thus completely broken on such devices. The descriptor was incorrectly sized from the logical sector size. A DSM TRIM payload is a list of 512-byte pages, each holding up to ATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical sector size. The Block Limits VPD page already advertises a single such page as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical blocks), so the block layer never sends a request that needs more than one page. Emit exactly one 512-byte page, independent of the logical sector size, and transfer only that page (COUNT == 1). For a 512-byte-sector device this is unchanged; devices with larger logical sectors now work instead of failing every TRIM. Reviewed-by: Hannes Reinecke Fixes: ef2d7392c4ec ("libata: SCT Write Same / DSM Trim") Cc: stable@vger.kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit fdc0a5e2cbace80835bf6431c1a62354575bf11d Author: Ethan Nelson-Moore Date: Sun Jun 14 02:45:38 2026 +0100 ARM: 9477/1: Disable broken eBPF JIT on the Risc PC commit 7e8ee82e69fde9d589272ec5e6f702358903be1f upstream. The eBPF JIT unconditionally generates ldrh/strh instructions, which do not function correctly on the Risc PC because its bus is unable to signal half-word accesses. Work around this issue by disabling the eBPF JIT when building for ARMv3 (the Risc PC is the only currently supported machine whose kernel is built for ARMv3). Comments from Ethan Nelson-Moore: From LKML: https://lore.kernel.org/all/CAD++jL=0qYGoygUwGEXQL7C_ROnC7kfpRv8RA+H5tNWwYu+pQA@mail.gmail.com/ The commit message has been updated slightly relative to the version on LKML to clarify that the Risc PC is not actually ARMv3. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Cc: stable@vger.kernel.org Signed-off-by: Ethan Nelson-Moore Reviewed-by: Linus Walleij Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 87d07aa5d38b6d4fd6b755d635683c1629b42b69 Author: Matt Turner Date: Thu May 28 19:05:16 2026 -0400 alpha: marvel: Fix lock ordering in init_io7_irqs() commit 24d68db713d63dfe3660c56b50e887784844baea upstream. Move irq_set_chip_and_handler() and irq_set_status_flags() calls outside the io7->irq_lock raw spinlock. These functions take sparse_irq_lock, which is a mutex, and taking a sleeping lock while holding a raw spinlock is invalid. The raw spinlock only needs to protect the hardware CSR accesses. This fixes the following lockdep splat during boot: [ BUG: Invalid wait context ] swapper/0/0 is trying to lock: sparse_irq_lock{....}-{4:4}, at: irq_mark_irq other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: #0: &io7->irq_lock{....}-{2:2}, at: init_io7_irqs.constprop.0 Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Matt Turner Reviewed-by: Magnus Lindholm Link: https://lore.kernel.org/r/20260528230516.1839694-2-mattst88@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Greg Kroah-Hartman commit 9e1eefc01912c5b69effd3842ad06d6ff3330d66 Author: Matt Turner Date: Thu May 28 19:05:15 2026 -0400 alpha: marvel: Fix irq_set_status_flags to use correct IRQ number commit 3a3ac1f6c6a67b3803f2643584310f78301e58a8 upstream. Pass base + i to irq_set_status_flags() to match the IRQ number used in irq_set_chip_and_handler(). Previously, IRQ_LEVEL was set on the wrong (low-numbered) IRQ descriptors rather than the IO7 IRQs at base + i. Cc: stable@vger.kernel.org Fixes: 08876fe8519c ("alpha: marvel: Convert irq_chip functions") Signed-off-by: Matt Turner Reviewed-by: Magnus Lindholm Link: https://lore.kernel.org/r/20260528230516.1839694-1-mattst88@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Greg Kroah-Hartman commit 2fd984c44e3e405eac1cea4340e24b4d59966e89 Author: Krzysztof Wilczyński Date: Mon Jul 6 17:54:23 2026 +0000 alpha/PCI: Fix I/O port accessor argument order in pci_legacy_write() commit 651fb94aaf245430590216d497fb8b02dd73d5f9 upstream. pci_legacy_write() in arch/alpha/kernel/pci-sysfs.c passes its arguments to outb(), outw() and outl() in the wrong order: outb(port, val); The Alpha I/O accessors in arch/alpha/include/asm/io.h take the value first and the port second: extern void outb(u8 b, unsigned long port); So the port number is written as data to the I/O address taken from the user-supplied value, and the intended write to the requested port never happens. The arguments have been reversed since the file was added, and the function returns the access size regardless, so the caller sees success while the requested port is left untouched. Fixes: 10a0ef39fbd1 ("PCI/alpha: pci sysfs resources") Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Tested-by: Magnus Lindholm Reviewed-by: Magnus Lindholm Acked-by: Magnus Lindholm Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260706175423.98305-1-kwilczynski@kernel.org Signed-off-by: Greg Kroah-Hartman commit 6d4ed2fd022bc862b156e53aae163b61259e1caa Author: Anirudh Prasad Date: Sat Aug 15 01:36:23 2026 +0530 ACPI: pfr_update: fix stack buffer overflow in query_capability() commit ced45be0073a8a31b30b4a7f68cd3a15734515de upstream. query_capability() copies four ACPI buffer objects returned by the firmware _DSM into fixed-size u8[16] fields in struct pfru_update_cap_info using memcpy with the firmware-supplied length: memcpy(&cap_hdr->code_type, elements[CAP_CODE_TYPE_IDX].buffer.pointer, elements[CAP_CODE_TYPE_IDX].buffer.length); The same pattern repeats for drv_type, platform_id, and oem_id. If the firmware returns buffer.length > 16 for any of these fields, memcpy writes past the destination array. struct pfru_update_cap_info is stack-allocated in pfru_ioctl(). Confirmed with KASAN on 7.2-rc6: three stack-out-of-bounds reports are generated when a DSM returns 64-byte buffers, with writes reaching 44 bytes past the end of cap_hdr's [64, 156) frame window into adjacent stack redzones. Introduce a helper pointer to out_obj->package.elements and use it to validate each buffer length against its destination field size before copying, returning -EINVAL if the firmware supplies an oversized buffer. Fixes: 0db89fa243e5 ("ACPI: Introduce Platform Firmware Runtime Update device driver") Cc: All applicable Signed-off-by: Anirudh Prasad Link: https://patch.msgid.link/1a001e1fee9.637da6dc3533246.238498880682901704@a0rg.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 452eb28e03015abec6d4bf6488ee567706ade4e1 Author: TanZheng Date: Thu Aug 6 09:09:44 2026 +0800 ACPI: APEI: GHES: fix ARM section length accounting after header commit 903308ea40adf0577d82eab69882faf8836326ce upstream. In ghes_handle_arm_hw_error(), after skipping the cper_sec_proc_arm header with (err + 1), the remaining length was reduced by sizeof(err) (pointer size) instead of sizeof(*err) (structure size). That overestimates the bytes left for cper_arm_err_info records and can let the parser read past the CPER section when err_info_num is large enough relative to error_data_length. Use sizeof(*err) so the length accounting matches the pointer advance and the earlier sizeof(*err) size check. Fixes: 87880af2d24e ("APEI/GHES: ARM processor Error: don't go past allocated memory") Cc: stable@vger.kernel.org Signed-off-by: TanZheng Reviewed-by: Shuai Xue Link: https://patch.msgid.link/20260806010944.32384-1-kensanya@163.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit b7476b29b69614bb963dafa670aeb80831c36d46 Author: Nirmoy Das Date: Tue Jul 21 11:25:51 2026 -0700 ACPI: APEI: Fix ERST timeout unit conversion commit a685d8eea4a6899dc887e393927c16fa18ff5e9a upstream. The ACPI specification defines bits 63:32 returned by GET_EXECUTE_OPERATION_TIMINGS as the maximum execution time in microseconds. erst_get_timeout() instead multiplies the value by NSEC_PER_MSEC. Use NSEC_PER_USEC to express the firmware-provided microsecond timeout in the nanosecond units expected by erst_timedout(). Fixes: fac475aab70b ("ACPI: APEI: Use ERST timeout for slow devices") Cc: stable@vger.kernel.org Signed-off-by: Nirmoy Das Reviewed-by: Hanjun Guo Link: https://patch.msgid.link/20260721182551.2434933-1-nirmoyd@nvidia.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c735dbce7ad03df708bf22ec964f67e43cbc823a Author: Terry Bowman Date: Mon Aug 3 17:17:59 2026 -0500 acpi/apei/ghes: Use raw_spinlock_t for CXL CPER work locks commit 6625ca499c3131ef63be3215f8f942d7a097ea3a upstream. The CXL CPER work registration and unregistration helpers acquire cxl_cper_work_lock and cxl_cper_prot_err_work_lock with a spinlock guard(), which leaves local interrupts enabled. The corresponding post paths (cxl_cper_post_event(), cxl_cper_post_prot_err()) execute in hard IRQ context (they are called from the GHES error notification path) and acquire the same locks with an irqsave guard(). If a CPU is holding one of these locks via a spinlock guard() when a GHES interrupt arrives on the same CPU, the IRQ handler spins on the held lock waiting for it to release, while the lock holder is preempted by the IRQ. The result is a deadlock. Convert both locks from spinlock_t to raw_spinlock_t and use guard() at all call sites. On PREEMPT_RT kernels spinlock_t is backed by rt_mutex and sleeping from hard IRQ context is not permitted; raw_spinlock_t is safe in both contexts. Add WARN_ONCE to both register functions to surface double-registration bugs at runtime. Restructure both unregister functions to clear the global work pointer under the lock before calling cancel_work_sync(), closing the window where a CPER interrupt could schedule work on a pointer about to be freed. Add kfifo_reset() after cancel_work_sync() so stale entries are not replayed on next module load. Both kfifos are single-consumer: only one work_struct is registered at a time, enforced by the WARN_ONCE guard in the register functions. kfifo_reset() is safe outside the lock because cancel_work_sync() has already quiesced the consumer, and no new consumer can register until the current module exit completes and a fresh module init runs. Remove the redundant cancel_work_sync() call from cxl_ras_exit() and cxl_pci_driver_exit(). The CPER unregister functions now quiesce the work internally. Reported-by: Sashiko Signed-off-by: Terry Bowman Fixes: 5e4a264bf8b5 ("acpi/ghes: Process CXL Component Events") Fixes: 36f257e3b0ba ("acpi/ghes, cxl/pci: Process CXL CPER Protocol Errors") Cc: stable@vger.kernel.org Reviewed-by: Dave Jiang Reviewed-by: Jonathan Cameron Reviewed-by: Tony Luck Link: https://patch.msgid.link/20260803221810.3685703-4-terry.bowman@amd.com Signed-off-by: Dave Jiang Signed-off-by: Greg Kroah-Hartman commit 9ad8821573a36bcd18c84dbca3027802b0ea062f Author: ZhaoJinming Date: Wed Jun 10 15:10:44 2026 +0800 accel/rocket: Fix error path handling in rocket_job_run() commit 9b2dedadf6a91ac3fc9fae268bb556a041222711 upstream. In rocket_job_run(), after taking an extra fence reference for job->done_fence via dma_fence_get(), the error paths have three bugs: - The dma_fence reference held by job->done_fence is never released, causing a reference leak. - pm_runtime_get_sync() increments the usage counter even on failure, but the error path does not decrement it, leaking the runtime PM reference and preventing the NPU from suspending. - A valid but unsignaled fence is returned to the DRM scheduler, which triggers WARN("Fence ... released with pending signals!") when the scheduler drops its reference. Fix by replacing pm_runtime_get_sync() with pm_runtime_resume_and_get() which auto-balances the usage counter on failure, releasing both fence references on error, and returning ERR_PTR(ret) instead of the unsignaled fence. Cc: stable@vger.kernel.org Fixes: 0810d5ad88a1 ("accel/rocket: Add job submission IOCTL") Signed-off-by: ZhaoJinming Link: https://lore.kernel.org/r/20260610071045.3414828-1-zhaojinming@uniontech.com [tomeu: Refactored error paths to use consolidated goto labels] Signed-off-by: Tomeu Vizoso Signed-off-by: Greg Kroah-Hartman commit 3043230296653a609ab50006899e64bbb2d99465 Author: Shuvam Pandey Date: Wed Jul 1 10:15:52 2026 -0700 accel/rocket: initialize job domain before cleanup paths commit 70e6a33d68a9b03335c5426332666e52d07f45d6 upstream. rocket_ioctl_submit_job() releases rjob through rocket_job_put() on allocation error paths. rocket_job_cleanup() unconditionally calls rocket_iommu_domain_put(job->domain), but job->domain is assigned only after task copying and BO lookups. A failure before that assignment can therefore clean up a job with a NULL domain pointer. Take the per-file domain reference before the first error path can release rjob. Also clear rjob->tasks after freeing it in rocket_copy_tasks(), so the common cleanup path cannot free the task array again after a task-copy error. Fixes: 0810d5ad88a1 ("accel/rocket: Add job submission IOCTL") Cc: stable@vger.kernel.org Signed-off-by: Shuvam Pandey Link: https://lore.kernel.org/r/6a454b48.6a8fa39a.27019b.984b@mx.google.com Signed-off-by: Tomeu Vizoso Signed-off-by: Greg Kroah-Hartman commit c1a5bf1b6e1d5944183dcef3844a18c17219af4d Author: Muhammad Bilal Date: Sun May 24 15:57:16 2026 +0000 accel/rocket: fix NULL dereference and integer overflow in rocket_job_push() commit a85402bff218f2b8f0d806e46c16c2f3d49cdda7 upstream. rocket_job_push() allocates a temporary array to hold all input and output GEM object pointers: bos = kvmalloc_array(job->in_bo_count + job->out_bo_count, sizeof(void *), GFP_KERNEL); memcpy(bos, job->in_bos, job->in_bo_count * sizeof(void *)); memcpy(&bos[job->in_bo_count], job->out_bos, ...); Two bugs exist: 1. Missing NULL check: if kvmalloc_array() fails, bos is NULL and the subsequent memcpy() dereferences it, causing a kernel NULL pointer dereference. 2. Integer overflow: in_bo_count and out_bo_count are both u32, set directly from userspace-supplied in_bo_handle_count and out_bo_handle_count with no prior validation. Their sum is computed in u32 arithmetic and can wrap to a smaller value, causing the allocation count passed to kvmalloc_array() to be smaller than intended. Subsequent uses still operate on the original counts when copying and locking objects, which may lead to out-of-bounds accesses on the temporary array. Fix by using check_add_overflow() to detect count overflow before the allocation, and adding a NULL check on the allocation result. Fixes: 0810d5ad88a1 ("accel/rocket: Add job submission IOCTL") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://lore.kernel.org/r/20260524155716.90955-1-meatuni001@gmail.com Signed-off-by: Tomeu Vizoso Signed-off-by: Greg Kroah-Hartman commit a3c65af20cceb7f997847727636b4017326f845d Author: Guillaume Morin Date: Tue Jul 28 21:29:03 2026 +0200 hugetlb: only adjust reservation during unmapping if mapcount is 0 commit 5120b1e048d48596ffaec1a8412012a91adba73b upstream. Since df7a6d1f6405, __unmap_hugepage_range can adjust reservations. In the case of folio mapped in both a parent and a child, if the parent unmaps the range first, the reservation adjustment will result in an underflow of the reserved count. Once the child unmaps the range, the count is restored. Change __unmap_hugepage_range() to check the mapcount before adjusting the reservation. Link: https://lore.kernel.org/all/alEJkwn5VlTTH_ZX@bender.morinfr.org/ Link: https://lore.kernel.org/amkC_1Ya6OiUoiLZ@bender.morinfr.org Fixes: df7a6d1f6405 ("mm/hugetlb: restore the reservation if needed") Signed-off-by: Guillaume Morin Reviewed-by: Breno Leitao Reviewed-by: Rik van Riel Cc: Muchun Song Cc: David Hildenbrand Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4e019e5e247bfe877fdf288f2d6ec1b4c850c7c6 Author: Ivaylo Dimitrov Date: Fri Jul 24 16:05:22 2026 +0300 hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device commit e81250ec6b69248b00d38c523dc6a13efaf38aab upstream. The OMAP SSI driver uses a synthetic HSI controller device allocated via hsi_alloc_controller(), which does not go through the normal OF/platform device initialization path. As a result, the embedded struct device does not have a DMA mask initialized by default. After recent DMA API hardening changes, dma_map_sg() and related helpers now require a valid dma_mask to be present, otherwise the driver may crash or trigger warnings when attempting DMA mapping operations. Fix this by explicitly initializing the DMA mask for the SSI controller device and setting a 32-bit DMA mask, which matches the hardware capabilities. Cc: stable@vger.kernel.org Fixes: f959dcd6ddfd ("dma-direct: Fix potential NULL pointer dereference") Reported-by: Merlijn Wajer Closes: https://lore.kernel.org/linux-omap/4ed95c71-2066-6b4c-ad1b-53ef02d79d53@wizzup.org/ Signed-off-by: Ivaylo Dimitrov Link: https://patch.msgid.link/20260724130522.706480-1-ivo.g.dimitrov.75@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 137c61a6cfd9613d065b5abcfdadc4a5b6d949a2 Author: Tien Sung Ang Date: Mon Jun 29 23:57:19 2026 -0700 fpga: stratix10-soc: Fix SVC mailbox handling during reconfiguration commit c14a8b15c87b49efc3ef898cec8ac7c30336a080 upstream. Fix incorrect stratix10_svc_done() usage during FPGA reconfiguration. Do not call stratix10_svc_done() at the end of write_init() on success, so the SVC session remains active through write() and write_complete(). Call stratix10_svc_done() on failure in write_init() and write() so the shared SVC mailbox is released when reconfiguration aborts, allowing coexistence with other SVC clients such as soc64-hwmon. Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver") Cc: stable@vger.kernel.org # 5.1+ Signed-off-by: Tien Sung Ang Signed-off-by: Tze Yee Ng Reviewed-by: Xu Yilun Link: https://lore.kernel.org/r/8768ce3260489c9febdfce08e27d03f5f5ed9c33.1782801986.git.tze.yee.ng@altera.com Signed-off-by: Xu Yilun Signed-off-by: Greg Kroah-Hartman commit 0c3f4544ff3873594c8af1b907b4ac4e6d5ce005 Author: Marek Czernohous Date: Sat Aug 15 21:54:38 2026 +0200 forcedeth: fix off-by-one when saving/restoring non-PCI config space commit 9393f1d656a79693e0c123ff7bc7c5c0f708046d upstream. nv_suspend() and nv_resume() walk the non-PCI configuration space with for (i = 0; i <= np->register_size/sizeof(u32); i++) which runs one iteration too many. saved_config_space is declared as u32 saved_config_space[NV_PCI_REGSZ_MAX/4]; and NV_PCI_REGSZ_VER3 is equal to NV_PCI_REGSZ_MAX (0x604), so on a VER3 device register_size/sizeof(u32) is exactly the array length and the last iteration addresses one element past the end. The element it lands on is np->name_rx[0..3]: saved_config_space[] is followed immediately by char name_rx[IFNAMSIZ + 3], and char needs no padding. Nothing observable is corrupted by that, because nv_request_irq() rewrites name_rx with sprintf() before it is ever passed to request_irq(). The bug is the out-of-bounds access itself, which UBSAN reports and which CONFIG_UBSAN_TRAP=y turns into a trap that aborts the running kernel code, plus an MMIO read and, on resume, an MMIO writel() to base + 0x604, one dword past the range the driver mapped: np->base = ioremap(addr, np->register_size); VER1 and VER2 devices stay inside the array, but they too get the stray read and the stray write one dword past their own window. Caught by UBSAN on an Apple Macmini3,1 (MCP79) during a deep S3 cycle. The splat below is trimmed: the build path in the file name, the CPU and taint lines, the Workqueue line, the "?" hint frames, and the frames below device_suspend are all cut. The kernel was tainted, with an out-of-tree nouveau and CPU_OUT_OF_SPEC; forcedeth itself was the stock module. UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c:6225:25 index 385 is out of range for type 'u32 [385]' Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... Both loops are hit. UBSAN reports each source location only once per module load (__ubsan_handle_out_of_bounds() calls suppress_report(), which does test_and_set_bit(REPORTED_BIT, ...) on the struct source_location), so the two splats land in the first S3 cycle after the module is loaded and later cycles are silent even though the access still runs off the end every time. In that first cycle line 6225 is reported from pci_pm_suspend and line 6240 from pci_pm_resume. The same off-by-one was fixed in nv_get_regs() by commit ba9aa134287f ("forcedeth: fix buffer overflow") in 2012; these two loops were missed. The suspend and resume side was reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix, but the patch was attached rather than sent inline and the thread ended there. Use < instead of <=, which saves and restores exactly register_size bytes. Fixes: 1a1ca86158ee ("[netdrvr] forcedeth: save/restore device configuration space") Cc: stable@vger.kernel.org Signed-off-by: Marek Czernohous Reviewed-by: Simon Horman Reviewed-by: Zhu Yanjun Link: https://patch.msgid.link/178682367885.3748309.10595890901761762683@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 466a8af0dee2cf745307155e26884e19a37b7e15 Author: Myeonghun Pak Date: Wed Jul 1 20:12:24 2026 +0900 fbdev: uvesafb: unregister connector callback on init failure commit de8db23aa7c337e606fca9faf48b3ba72968597a upstream. uvesafb_init() registers the v86d connector callback before registering the platform driver. If platform_driver_register() fails, the function returns the error directly and leaves the connector callback registered. The later platform-device failure path already unregisters the callback. Add the same cleanup before the final return when platform-driver registration fails. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 8bdb3a2d7df4 ("uvesafb: the driver core") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 3bcab9b21f71d52bd1b2e03b80f29516bb000593 Author: Hui Su Date: Tue Aug 4 02:39:57 2026 +0800 fbdev: ssd1307fb: defer I2C transfers from damage callbacks commit 9ad709afdfa32509ed64938a6d9cd00db3cd54c2 upstream. The fbdev damage callbacks may run from fbcon while printk has disabled preemption. They currently update the display synchronously, which enters the sleeping I2C transfer path from atomic context. A complete report from an RK3566 system follows: [ 258.129004] watchdog: watchdog0: watchdog did not stop! [ 258.129067] BUG: scheduling while atomic: systemd/1/0x00000003 [ 258.129076] Modules linked in: algif_hash algif_skcipher af_alg bnep binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1 ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine v4l2_vp9 snd_pcm v4l2_h264 rockchip_rga snd_timer rk_crypto2 spi_rockchip_sfc videobuf2_dma_contig snd sm3_generic v4l2_mem2mem videobuf2_dma_sg dwmac_rk sm3 soundcore videobuf2_memops videobuf2_v4l2 stmmac_platform dw_hdmi_cec videodev videobuf2_common dw_hdmi_i2s_audio stmmac rk817_charger pcs_xpcs mc cpufreq_dt sch_fq_codel ip_tables x_tables autofs4 [ 258.129215] Preemption disabled at: [ 258.129216] [] vprintk_emit+0x11c/0x340 [ 258.129234] CPU: 0 PID: 1 Comm: systemd Tainted: G C 6.6.0-rc5-rockchip-rk356x #4 [ 258.129239] Hardware name: Rockchip RK3566 OPi 3B (DT) [ 258.129243] Call trace: [ 258.129245] dump_backtrace+0xa0/0x128 [ 258.129252] show_stack+0x20/0x38 [ 258.129256] dump_stack_lvl+0x60/0xb0 [ 258.129265] dump_stack+0x18/0x28 [ 258.129269] __schedule_bug+0xa0/0xc8 [ 258.129274] __schedule+0x9ac/0xd30 [ 258.129279] schedule+0x60/0x100 [ 258.129282] schedule_timeout+0x194/0x338 [ 258.129289] rk3x_i2c_xfer_common.isra.0+0x384/0x498 [ 258.129296] rk3x_i2c_xfer+0x20/0x60 [ 258.129300] __i2c_transfer+0x194/0x648 [ 258.129308] i2c_transfer+0x9c/0x130 [ 258.129313] i2c_transfer_buffer_flags+0x64/0x98 [ 258.129318] ssd1307fb_update_rect+0x42c/0x560 [ssd1307fb] [ 258.129334] ssd1307fb_defio_imageblit+0x34/0x50 [ssd1307fb] [ 258.129343] soft_cursor+0x13c/0x210 [ 258.129350] bit_cursor+0x2dc/0x550 [ 258.129354] fbcon_cursor+0xec/0x108 [ 258.129359] hide_cursor+0x44/0xc8 [ 258.129365] vt_console_print+0x398/0x3b0 [ 258.129370] console_flush_all.isra.0+0x17c/0x410 [ 258.129377] console_unlock+0x4c/0x100 [ 258.129382] vprintk_emit+0x1c8/0x340 [ 258.129386] vprintk_default+0x40/0x58 [ 258.129389] vprintk+0xb8/0xd0 [ 258.129392] _printk+0x68/0x98 [ 258.129398] watchdog_release+0x170/0x230 [ 258.129404] __fput+0xbc/0x288 [ 258.129409] __fput_sync+0x58/0x70 [ 258.129413] __arm64_sys_close+0x40/0x90 [ 258.129419] invoke_syscall+0x4c/0x118 [ 258.129426] el0_svc_common.constprop.0+0x48/0xf0 [ 258.129432] do_el0_svc+0x24/0x38 [ 258.129437] el0_svc+0x48/0x100 [ 258.129443] el0t_64_sync_handler+0xc0/0xc8 [ 258.129448] el0t_64_sync+0x190/0x198 [ 258.573087] ------------[ cut here ]------------ [ 258.573098] DEBUG_LOCKS_WARN_ON(val > preempt_count()) [ 258.573111] WARNING: CPU: 0 PID: 1 at kernel/sched/core.c:5871 preempt_count_sub+0x9c/0x148 [ 258.573130] Modules linked in: algif_hash algif_skcipher af_alg bnep binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1 ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine v4l2_vp9 snd_pcm v4l2_h264 rockchip_rga snd_timer rk_crypto2 spi_rockchip_sfc videobuf2_dma_contig snd sm3_generic v4l2_mem2mem videobuf2_dma_sg dwmac_rk sm3 soundcore videobuf2_memops videobuf2_v4l2 stmmac_platform dw_hdmi_cec videodev videobuf2_common dw_hdmi_i2s_audio stmmac rk817_charger pcs_xpcs mc cpufreq_dt sch_fq_codel ip_tables x_tables autofs4 [ 258.573268] CPU: 0 PID: 1 Comm: systemd Tainted: G WC 6.6.0-rc5-rockchip-rk356x #4 [ 258.573274] Hardware name: Rockchip RK3566 OPi 3B (DT) ** 37 printk messages dropped ** [ 258.574064] Preemption disabled at: ** 42 printk messages dropped ** [ 259.190237] Preemption disabled at: Track damage in the driver's private data under a spinlock and merge multiple updates into a bounding rectangle. Queue the existing deferred-I/O work immediately for damage reported by fbdev drawing and write helpers, so allocation and I2C transfers run from process context without adding the configured mmap refresh delay. Keep full-screen updates for dirty mmap pages, for which no precise rectangle is available. Tested on an RK3566 board with a 128x64 OLED by running five rounds of 250 KERN_EMERG messages in total while issuing framebuffer writes every 15 ms. No atomic-sleep, preemption, or lockdep warning occurred. Kprobe tracing also confirmed that cursor-only damage remained an 8x16 partial update. Fixes: a2ed00da5047 ("drivers/video: add support for the Solomon SSD1307 OLED Controller") Cc: stable@vger.kernel.org Signed-off-by: Hui Su Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 3c1b5809615c36f6c5e2ef955e93a5eed82f3b78 Author: Florian Fuchs Date: Mon Jul 13 12:16:38 2026 +0200 fbdev: pvr2fb: correct user pointer annotation and sentinel initializer commit 5dc2e70dd74b1f03e2e13bfb6922111d9e0adf90 upstream. Add __user annotation to buf, as it is passed as a user pointer in pin_user_pages_fast(). Use an empty initializer for the sentinel board-table entry to avoid initializing a function pointer with an integer literal. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202607131247.fpQ6eTc7-lkp@intel.com/ Cc: stable@vger.kernel.org Signed-off-by: Florian Fuchs Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 76818e81cfcae33b09b739de09162c7d8d89bf0b Author: Runyu Xiao Date: Tue Aug 18 21:53:18 2026 +0800 fbdev: omapfb: panel-dsi-cm: initialize lock before registering display commit f8e43fe0f22b7137ce456e6fe3581d3098174f74 upstream. dsicm_probe() registers the display before initializing ddata->lock. Once omapdss_register_display() publishes the display, another consumer can reach a dsicm callback that takes this mutex while it is still uninitialized. Initialize the mutex before registering the display so the published callbacks always see a valid lock. Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 2f66f8ceefc25ea9b0b9b23e533f4fd4ac06783e Author: Yemu Lu Date: Mon May 25 16:56:49 2026 +0800 fat: restore original value when fat_ent_write failed commit 64d9183203eebe33de6188b70a8c1e91f52885db upstream. fat_ent_write() may have committed the new link to the primary FAT but then failed on the mirror copy, leaving the chain pointing to new_dclus even though the caller will free it. Restore the original value to keep the chain consistent. Link: https://lore.kernel.org/20260525085649.781643-1-n05ec@lzu.edu.cn Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yemu Lu Signed-off-by: Ren Wei Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Acked-by: OGAWA Hirofumi Cc: Christian Brauner Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 66aa9a9e6481bfa512ee5b6380eaaec455a954d2 Author: Chengfeng Ye Date: Fri Jul 31 13:31:45 2026 +0200 fanotify: fix use-after-free of file range info commit d7f1cf5be33ef0175a4e8ed8687aeb98fb00a851 upstream. fsnotify_pre_content() builds its file_range on the triggering task's stack. fanotify_alloc_perm_event() saves a pointer to range.pos in the heap-allocated permission event so copy_range_info_to_user() can report the offset later. The event reader can set the event state to FAN_EVENT_REPORTED and then sleep while preparing the file descriptor. If a signal interrupts the triggering task at that point, fanotify_get_response() changes the state to FAN_EVENT_CANCELED and returns. This unwinds the file_range stack frame while the reader still owns the event. The reader then dereferences pevent->ppos and copies the stale stack value to userspace. KASAN reported: BUG: KASAN: use-after-free in fanotify_read+0x293e/0x2970 Read of size 8 at addr ffff88811434fc50 by task fanotify_inotif/95 Call Trace: fanotify_read+0x293e/0x2970 vfs_read+0x177/0xa20 ksys_read+0xf7/0x1c0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Store the range position directly in the permission event and use FANOTIFY_NO_RANGE when range information is unavailable. The event remains alive until the reader finishes, so the reported offset no longer depends on the triggering task's stack. Fixes: 870499bc1d4d ("fanotify: report file range info with pre-content events") Cc: stable@vger.kernel.org Suggested-by: Jan Kara Signed-off-by: Chengfeng Ye Link: https://patch.msgid.link/20260730134316.2085087-1-nicoyip.dev@gmail.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 92895a14329cc9533e2a74a265214f690ba3851a Author: Ard Biesheuvel Date: Sat Aug 1 17:28:04 2026 +0300 efivarfs: Rate limit statfs() handler commit b2326338dc683e8c1067c0cbf7a47986c4190902 upstream. Ravi reports that statfs() may be called by unprivileged users on the efivarfs mount point, which may result in a flood of calls to the QueryVariableInfo() runtime service. These calls are disproportionately costly on x86 systems where the variable store is backed by SMM, as each SMM entry requires a rendez-vous of all the CPUs. So rate limit the calls to QueryVariableInfo() at twice per second, and return the most recently obtained value for calls that are elided. Cc: Reported-by: Ravi Bangoria Fixes: d86ff3333cb1 ("efivarfs: expose used and total size") Reviewed-by: Anisse Astier Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit ce568f6e025df43df602e011a0e20657eed7bcac Author: Yichong Chen Date: Thu Jul 2 13:29:58 2026 +0800 ecryptfs: show filename encryption options commit 496ec2d0852a02d2e631771b5c439130b9c7dce7 upstream. ecryptfs_show_options() prints most user-visible mount options but omits the filename encryption cipher and key size. Print ecryptfs_fn_cipher and ecryptfs_fn_key_bytes when filename encryption is enabled so that the displayed mount options reflect the active filename encryption settings. Fixes: 87c94c4df014 ("eCryptfs: Filename Encryption: mount option") Cc: Signed-off-by: Yichong Chen Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 9319706316a8e79f374627554386d575a84b637f Author: Yichong Chen Date: Wed Jul 1 13:34:06 2026 +0800 ecryptfs: release message context on send failure commit 219644a3ad5518217b2d62cad6d2c36a2308c949 upstream. ecryptfs_send_message_locked() moves a message context from the free list to the allocated list before sending the request to the userspace daemon. If ecryptfs_send_miscdev() fails, the context is left on the allocated list and cannot be reused. Move it back to the free list on failure and clear the caller's pointer. Fixes: f66e883eb618 ("eCryptfs: integrate eCryptfs device handle into the module.") Cc: Signed-off-by: Yichong Chen Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit b31da1ecf13929a8d7f8d2727843d2fe35396b75 Author: Yichong Chen Date: Wed Jul 15 13:20:06 2026 +0800 ecryptfs: reject too-small tag 70 packets commit e97bbe1b2bd82ec2ae37ad2e4965b4d3e78bbf7f upstream. ecryptfs_parse_tag_70_packet() subtracts fixed metadata fields from the parsed packet body size to derive the encrypted filename size. A malformed packet with a body smaller than those fixed fields can underflow that size calculation. Reject tag 70 packets before the subtraction unless the body contains the signature, cipher code, and at least one byte of encrypted filename data. Fixes: 9c79f34f7ee7 ("eCryptfs: Filename Encryption: Tag 70 packets") Cc: Signed-off-by: Yichong Chen Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 14cb36a500a5a3afbc955dbf69dabc565f1a3b26 Author: HanQuan Date: Tue Jul 14 00:57:03 2026 +0000 ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet commit 5babe9c177c364521e3e682b949c5a8c47f4a441 upstream. parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key() sets decrypted_key_size = encrypted_key_size and performs two out-of-bounds writes: 1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into decrypted_key[64] via scatterlist, overflowing into the parent ecryptfs_auth_tok struct. 2. memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes into crypt_stat->key[64], corrupting root_iv, keysig_list, and mutexes in ecryptfs_crypt_stat. Only AES-192 (cipher code 0x08) enables this because it sets crypt_stat->key_size = 24 independently of encrypted_key_size, allowing crypto_skcipher_setkey() to succeed while encrypted_key_size exceeds ECRYPTFS_MAX_KEY_BYTES. The PKI decryption path (parse_tag_65_packet) already validates decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path omits this check. Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also protects the 512-byte encrypted_key[] buffer, so the former 512-byte check is removed as redundant. Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig") Cc: Signed-off-by: HanQuan [tyhicks: Adjust the code comment to refer to macros representing the buffer sizes rather than mentioning the buffer size values since they may change in the future] Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit e5d254e654f2311a3c4b9c791d7f216554bcd17a Author: Yichong Chen Date: Wed Jul 15 13:20:04 2026 +0800 ecryptfs: pass packet set buffer size to parser commit 2602b79c5b3e2f6fce12e38a670f8e3fda4e46a2 upstream. ecryptfs_parse_packet_set() receives a pointer into the file header, but it calculates the remaining packet buffer size from PAGE_SIZE - 8. For version 1 headers the packet set starts later in the header, so this can overstate the available buffer. Pass the actual packet set buffer length from the caller and calculate per-packet limits from the remaining bytes in that buffer. Recompute the remaining length after consuming a tag 3 packet before parsing the following tag 11 packet. Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig") Cc: Signed-off-by: Yichong Chen Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 0d9636ecba34bd553ecf19049f7705505aea62fd Author: Yichong Chen Date: Sun Jun 28 11:37:25 2026 +0800 ecryptfs: hold msg ctx list lock when cleaning daemon queue commit 779972513c2fa8c7938e54976f686091dafff22f upstream. ecryptfs_exorcise_daemon() drops queued messages from a dying daemon without holding ecryptfs_msg_ctx_lists_mux, but ecryptfs_msg_ctx_alloc_to_free() requires that lock. Take the list lock while moving the queued contexts back to the free list to avoid racing with other global msg ctx list users. Fixes: f66e883eb618 ("eCryptfs: integrate eCryptfs device handle into the module.") Cc: Signed-off-by: Yichong Chen Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit c1bc956a615d038d83a304f36d5e5da970c752dc Author: Yichong Chen Date: Wed Jul 15 13:20:05 2026 +0800 ecryptfs: fix tag 11 packet exact-fit size check commit 8b2ec0f56f55477f547d332526c9ae2a8fabc0a5 upstream. parse_tag_11_packet() rejects a packet when the already-consumed tag and length bytes plus the packet body exceed the caller supplied maximum packet size. The check currently adds one extra byte, even though *packet_size already includes the tag byte before the length is parsed. Remove the extra byte so a tag 11 packet that exactly fits the available buffer is accepted while oversized packets are still rejected. Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig") Cc: Signed-off-by: Yichong Chen Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 98b890563424a6faed1af2916e88a7a01eb1ddc8 Author: Pengpeng Hou Date: Mon Jul 20 19:56:24 2026 +0800 eCryptfs: bound the packet-length peek to the user buffer commit 95540462e630edbc8504e9537d16453d6942d143 upstream. ecryptfs_miscdev_write() accepts the minimum one-byte packet-length encoding, but always copies the maximum two-byte encoding from userspace before parsing it. A six-byte message therefore reads one byte beyond the submitted user buffer. Zero-initialize the peek buffer and copy only the packet-length bytes present. The existing exact packet-size check still rejects truncated two-byte encodings after the parser determines their encoded length. Fixes: 8bf2debd5f7b ("eCryptfs: introduce device handle for userspace daemon communications") Cc: Signed-off-by: Pengpeng Hou Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 7ccb94901f38a062034b56b43c774050b113758f Author: Konstantin Komarov Date: Fri Jul 24 13:42:28 2026 +0200 fs/ntfs3: bound page_lcns[] index by the log record commit 6f7b9dbdc1b7520206abce0049bdd143eb536e75 upstream. The copy_lcns loop and the redo shorten loop index page_lcns[] at j + i, where i runs up to the log record's lcns_follow. That count is checked only against the record's own length, not the target entry, so check_dp_table() (which validates the entry's lcns_follow) does not cover it: the copy_lcns entry may even be freshly allocated after that check, and find_dp() bounds j but not i. A crafted record thus overflows page_lcns[] of an otherwise valid entry. Add dp_range_ok() and reject, before each loop, any record whose run does not fit the entry. These are the only two page_lcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei [almaz.alexandrovich@paragon-software.com: original patch contained changes to the problem already handled, applied partly] Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 376ee45659a4b943df672ad275c63da00655f929 Author: Samuel Page Date: Tue Jun 23 21:00:57 2026 +0200 fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame() commit 35d1ea92c7d946e2ebdbe36cdb2c969c8704bebd upstream. ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target pages and then trusts decompress_lznt()'s return value: unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem, frame_size); if ((ssize_t)unc_size < 0) err = unc_size; else if (!unc_size || unc_size > frame_size) err = -EINVAL; decompress_lznt() stops as soon as the compressed stream is exhausted (e.g. a zero chunk header) and returns the number of bytes it actually wrote, which may be far less than frame_size. The bytes between unc_size and frame_size are never written. The only memset() that follows zeroes the region beyond i_valid; when the frame lies entirely within the file's valid size that memset() does not run, so the gap retains whatever was in the just-vmapped pages. All pages are then marked uptodate and returned to userspace, disclosing uninitialized (recently-freed) kernel page memory. A crafted compressed file whose stream decompresses to only a few bytes leaks the remainder of every frame on a plain read(2), which is enough to recover kernel pointers and defeat KASLR. Zero the [unc_size, frame_size) tail immediately after a successful LZNT decompress so the remainder reads back as zero. Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Cc: stable@vger.kernel.org Assisted-by: Bynario AI Signed-off-by: Samuel Page Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 2d94ffc9d7b5bb3517b129fe63b52d84bcd4ae56 Author: Xiang Mei Date: Wed Jun 17 16:13:42 2026 -0700 fs/ntfs3: validate dirty page table on log replay commit 006cb7713dec10368e699abc4367e5faa334c9a5 upstream. Each DIR_PAGE_ENTRY ends in a page_lcns[] array whose length is the on-disk lcns_follow field. check_rstbl() validates the table bookkeeping but never checks that this array fits in the entry, so a crafted lcns_follow lets the v0->v1 conversion memmove and later replay passes run off the entry. Add check_dp_table() to reject, right after check_rstbl(), any entry larger than its size claims via struct_size() (the same expression used to allocate these entries, so the check is overflow-safe by construction). All consumers can then trust lcns_follow as the real capacity. This covers every page_lcns[] access whose index is bounded by the entry itself (the conversion memmove, the HotFix store via find_dp(), and the self-bounded scan loops). Accesses whose index comes from the log record need a separate bound and are handled in a follow-up patch. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 5333e18e6b425fcc39c7fea89e3949a2a98bc5e4 Author: Deepanshu Kartikey Date: Mon Aug 24 20:16:53 2026 +0530 eventfs: Initialize ei->children and ei->list in init_ei() commit 1704aaaf5d22bc765c168402350d191e24e245bc upstream. eventfs_create_dir() allocates the eventfs_inode and initializes it with init_ei(). But this does not initialize the eventfs_inode list_heads. If the eventfs_create_dir() fails due to memory pressure, it will call free_ei() before it initialized the lists, and that checks to make sure the eventfs_inode has no children. But because the list wasn't initialized, it will give a false warning. Fix it by moving the list initialization into init_ei(). Cc: stable@vger.kernel.org Fixes: 5790b1fb3d67 ("eventfs: Remove eventfs_file and just use eventfs_inode") Reported-by: syzbot+3ef80b4ed02226d04a06@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3ef80b4ed02226d04a06 Link: https://patch.msgid.link/20260824144653.54044-1-kartikey406@gmail.com Signed-off-by: Deepanshu Kartikey [ Rewrote change log ] Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit b2301bdb4b3edbaf19cd1aae7c81b281d4f7498c Author: Guangshuo Li Date: Sat Aug 8 23:17:36 2026 +0800 HID: intel-thc-hid: intel-quickspi: fix autosuspend cleanup during teardown commit 05dffa55fd6dbed4bf2421fae5accc2b857e668d upstream. quickspi_probe() calls pm_runtime_use_autosuspend(), but quickspi_remove() does not call the matching pm_runtime_dont_use_autosuspend() during teardown. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to the driver remove path. This issue was found by manual code inspection. Fixes: 6912aaf3fd24 ("HID: intel-thc-hid: intel-quickspi: Add PM implementation") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Even Xu Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 99f3e197920dfd240db3b230beb443d84bfdc91f Author: Guangshuo Li Date: Sat Aug 8 22:57:48 2026 +0800 HID: intel-thc-hid: intel-quicki2c: fix autosuspend cleanup during teardown commit 42a941e39432ef6766402ef68f1389dcfec4ee37 upstream. quicki2c_probe() calls pm_runtime_use_autosuspend(), but quicki2c_remove() does not call the matching pm_runtime_dont_use_autosuspend() during teardown. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to the driver remove path. This issue was found by manual code inspection. Fixes: 5f420e8215c6 ("HID: intel-thc-hid: intel-quicki2c: Add PM implementation") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Even Xu Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 72706b44b665679d7d60a488d8776a911f1a93f3 Author: HyeongJun An Date: Thu Aug 6 23:56:19 2026 +0900 HID: intel-thc-hid: intel-quickspi: bound GET_REPORT response to the caller buffer commit 035ec4a71cb8020a927c123bbe75c2f88d614986 upstream. quickspi_hid_raw_request() receives the caller's buffer length in len, but quickspi_get_report() never sees it and copies the whole device-supplied response into buf regardless: memcpy(buf, qsdev->report_buf, qsdev->report_len); qsdev->report_len comes from the input report the touch controller returns, while buf is sized to whatever the caller asked hidraw for through HIDIOCGFEATURE or HIDIOCGINPUT. A response larger than that overflows buf with device-controlled content. The intel-quicki2c sibling already passes the caller length down to quicki2c_get_report() and validates the response against it before the copy. Do the same here. Fixes: 4138f21115ae ("HID: intel-thc-hid: intel-quickspi: Complete THC QuickSPI driver") Suggested-by: Sashiko AI Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Reviewed-by: Even Xu Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 6fcefe71aeb524f6e77fe586fe85d873745e917c Author: HyeongJun An Date: Fri Jul 17 18:16:22 2026 +0900 HID: intel-thc-hid: intel-quickspi: validate report size before copy commit a59cf84441f9a17323c89452cec2bf16724c48a9 upstream. write_cmd_to_txdma() builds an output report in qsdev->report_buf, a heap buffer allocated in quickspi_alloc_report_buf() to the device-descriptor derived max_report_len (a few hundred bytes for a touch controller). It copies the caller-supplied report into that buffer: memcpy(write_buf->content, report_buf, report_buf_len); The HID core caps a report at HID_MAX_BUFFER_SIZE (16384) by default, and quickspi_hid_ll_driver does not set max_buffer_size, so the length reaches the driver unbounded. A hidraw SET_REPORT/SET_FEATURE ioctl carrying a report larger than max_report_len therefore overflows report_buf with attacker-controlled length and content. Record the report_buf allocation size and reject reports that do not fit before copying, matching the equivalent guard in the intel-quicki2c sibling (quicki2c_init_write_buf()) and the hid-goodix-spi fix. write_cmd_to_txdma() writes the output report header ahead of the content in the same buffer, so size the allocation to cover the header as well. That keeps the added bound from rejecting a maximum-sized report. Fixes: 9d8d51735a3a ("HID: intel-thc-hid: intel-quickspi: Add HIDSPI protocol implementation") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Reviewed-by: Even Xu Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 127de5919820f88a9d55e8371ad4ac49f625f4c5 Author: Jiangshan Yi Date: Tue Jul 28 21:14:42 2026 +0800 HID: mcp2221: validate report size in mcp2221_raw_event() commit 2c9a6998c19503626c57a2267bf279e204113079 upstream. mcp2221_raw_event() never validates the size of incoming HID reports. In the MCP2221_I2C_GET_DATA path it trusts the device-supplied data[3] as the copy length without checking that 4 + data[3] bytes actually exist in the received report. A malicious or misbehaving USB device can send a short report with a large data[3], causing the memcpy to read past the valid report data in the HID transfer buffer and leak uninitialized kernel memory back to userspace through the I2C/SMBus read path. Add a minimum size check at entry and validate that the source range fits within the received report before the copy. Fixes: 67a95c21463d ("HID: mcp2221: add usb to i2c-smbus host bridge") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit c99ba6c234d4d537c317336376b78c088174034a Author: Jiangshan Yi Date: Tue Jul 28 21:14:40 2026 +0800 HID: mcp2221: stop device IO before hid_hw_stop commit dca151633c0fde90935311c60e7cfc064aa56134 upstream. Quiesce device IO at the start of the devm cleanup callback mcp2221_hid_unregister() so that incoming HID reports cannot race with hardware teardown during probe failure or device removal, addressing a potential use-after-free. Guard the call to hid_device_io_stop() with io_started. On normal removal hid_device_remove() has already cleared io_started before the devres group is released, so an unconditional call would otherwise hit the !io_started path and emit a spurious "io already stopped" warning on every removal. The guard preserves the probe-failure balancing, where io_started is still set after hid_device_io_start(), while staying silent on the normal removal path. Fixes: d4b50ac06ea6 ("HID: mcp2221: Allow IO to start during probe") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 01d9874e84d3ab78fd212ad822412eb3af84497f Author: Baul Lee Date: Wed Jul 29 23:24:32 2026 +0900 HID: universal-pidff: stop the device when force-feedback init fails commit ce08c5555cabcd444d8b77fa69a7cb68bb05f611 upstream. universal_pidff_probe() starts the device with hid_hw_start() and then, if force-feedback initialisation fails, returns the error through a label that only does "return error". The device is left started. The HID core does not unwind on the driver's behalf. __hid_device_probe() releases the devres group, closes the report and clears hdev->driver: if (ret) { devres_release_group(&hdev->dev, hdev->devres_group_id); hid_close_report(hdev); hdev->driver = NULL; } The hidraw character device that hid_hw_start() registered through hid_connect() is allocated with kzalloc() and added with cdev_device_add(), so it is not devres-managed and survives that. With hdev->driver NULL, hid_device_remove() skips hid_hw_stop() as well, because it only unwinds while a driver is still attached. The registration therefore outlives the device on both paths. Opening the surviving /dev/hidrawX writes into freed memory. KASAN reports a use-after-free write from hidraw_open() -> hid_hw_open() -> the transport's open callback, which takes a spinlock inside the freed object. A descriptor that carries a PID usage page and no input reports is enough: hidraw claims the device so hid_hw_start() succeeds, while hid->inputs stays empty so force-feedback init fails. The other failure returns in hid_pidff_init_with_quirks() - no output reports, an allocation failure, pidff_init_fields(), pidff_check_autocenter(), an unusable effect count, input_ff_create() - all reach the same label. Stop the device on that path. hid-dr.c and hid-emsff.c, which start the device with the same HID_CONNECT_DEFAULT & ~HID_CONNECT_FF mask, already do this. The two earlier gotos must keep returning without hid_hw_stop(), since neither has a started device, so give the path that fails after the start its own label. Discovered by XBOW, triaged by Baul Lee Fixes: f06bf8d94fff ("HID: Add hid-universal-pidff driver and supported device ids") Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 114a58640aaf3c2eb97b5b01c75ab5e541d15d9c Author: Doruk Tan Ozturk Date: Fri Jul 24 16:27:03 2026 +0200 HID: sony: fix UAF of ghl_poke_timer / ghl_urb at driver unbind commit a26705bd2e2728833e7a538ce91e58a5eeff496a upstream. For GHL (Guitar Hero Live) dongles, sony_probe() arms a periodic timer: ghl_magic_poke() (the timer callback) submits sc->ghl_urb, and the URB completion ghl_magic_poke_cb() re-arms the timer with mod_timer(). sony_remove() drained the timer with timer_delete_sync() and then freed the URB with usb_free_urb(): timer_delete_sync(&sc->ghl_poke_timer); usb_free_urb(sc->ghl_urb); timer_delete_sync() does not block re-arming, and while the URB is in flight the timer is not pending, so the sync delete is a no-op. A URB completion that runs after the delete re-arms the timer, and usb_free_urb() only drops a reference -- it does not kill an in-flight URB. sc is allocated with devm_kzalloc() and freed once sony_remove() returns, so the re-armed ghl_poke_timer (embedded in sc) then fires on freed memory, a use-after-free from timer softirq. This is a disconnect/rmmod race. Poison the URB first, then shut the timer down, before freeing the URB. usb_poison_urb() kills any in-flight URB and permanently rejects further submissions, so a poke timer that is still pending cannot re-submit the URB from ghl_magic_poke() in the window before timer_shutdown_sync() runs. usb_kill_urb() would not suffice: it only cancels the in-flight URB and leaves it submittable once it returns, so the pending timer could re-submit it and put a fresh URB in flight over the freed sc. timer_shutdown_sync() then drains any last callback and blocks re-arming. The probe error path is unaffected: it is only reached before the timer is armed. Reproduced under KASAN on next-20260710 via dummy_hcd + raw-gadget emulation of the GHL PS4 dongle (VID 0x1430 / PID 0x07bb): hid-sony binds and arms the poke timer, the poke URB is held in flight, the driver is unbound (freeing sc), then the URB is released. The completion re-arms the timer on the freed sc, and the re-armed timer fires ~8 s later: BUG: KASAN: slab-use-after-free in ghl_magic_poke+0x98/0xb0 Read of size 8 at addr ffff88810b02fd50 by task swapper/0/0 ghl_magic_poke+0x98/0xb0 call_timer_fn+0x35/0x2b0 __run_timers+0x69c/0x9a0 run_timer_softirq+0x173/0x2a0 Allocated by task 169: sony_probe Freed by task 338: devres_release_group <- hid_device_remove (sony_remove) Found by 0sec (https://0sec.ai) using automated source analysis. Fixes: cc894ac55360 ("HID: sony: support for ghlive ps3/wii u dongles") Cc: stable@vger.kernel.org Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit f3f37b937a6ea2a00fb5e6189e74f855caa43eb5 Author: Haoxiang Li Date: Tue Jul 7 15:15:45 2026 +0800 HID: sensor: custom: Fix field sysfs group cleanup on failure commit 3789d0802ddb4b3be04062caf4bfadd23496e9a7 upstream. hid_sensor_custom_add_attributes() creates one sysfs group for each custom sensor field. If sysfs_create_group() fails after some groups have already been created, the function returns the error without removing the previously created groups. Add a local unwind path to remove the groups that were already created. With enable_sensor exposed only after the field attributes are ready, this path can free sensor_inst->fields without leaving enable_sensor able to access pointers into that array. Fixes: 4a7de0519df5 ("HID: sensor: Custom and Generic sensor support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit da00eac19feef209c9591e48c860afc2014603be Author: Xu Rao Date: Fri Jul 31 16:49:26 2026 +0800 HID: roccat: free buffered reports when destroying device commit bbff0ccbff360a5498075525005f6a913239a3d7 upstream. roccat_report_event() duplicates each report with kmemdup() and stores the allocation in a circular-buffer slot. The allocation is released only when that slot is reused. The device destruction paths free struct roccat_device without releasing reports still stored in cbuf[]. This makes those allocations unreachable and leaks up to ROCCAT_CBUF_SIZE report buffers per device. Add a small destructor that frees every buffered report before freeing the device, and use it in both paths that can destroy a registered device. Fixes: 206f5f2fcb5f ("HID: roccat: propagate special events of roccat hardware to userspace") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 471f4a939c66d1d44aece2321807abf609fc9098 Author: Ibrahim Hashimov Date: Wed Jul 15 13:53:01 2026 +0200 HID: picolcd: clamp eeprom debugfs read to bytes actually received commit e9c667395ac1f8024f623250b32bae4c7af9caa0 upstream. picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte supplied by the device in its REPORT_EE_DATA reply -- clamped only to the caller's read() count: ret = resp->raw_data[2]; if (ret > s) ret = s; if (copy_to_user(u, resp->raw_data+3, ret)) It never checks resp->raw_size, the number of bytes picolcd_raw_event() actually copied into the 64-byte raw_data[] of the kmalloc'd struct picolcd_pending. A device (or a spoofed picoLCD) returning a length byte of 0xff, read with a count >= 255, makes copy_to_user() read past raw_data[] into adjacent slab memory and return it to userspace through the debugfs "eeprom" file: BUG: KASAN: slab-out-of-bounds in _copy_to_user Read of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd] The debug-dump path in the same file already validates the device length byte against the received size before trusting it; this read does not. The file is created S_IRUSR (root-only) and a crafted device is needed, so it is neither unprivileged- nor remotely-triggerable. Clamp the copy length to resp->raw_size - 3 (the payload actually received, minus the 3-byte header), floored at 0 for short replies. Fixes: 9bbf2b98ba11 ("HID: add experimental access to PicoLCD device's EEPROM and FLASH") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 79465a30050dad62b3c9e7796368db75dac6fa0d Author: Stuart Hayhurst Date: Tue Jun 30 02:06:56 2026 +0100 HID: corsair-void: Check size of status and firmware events before reading them commit 08d8814521885e67b1bdf6a3036ee264e3e58377 upstream. Malformed status and firmware events could cause an out-of-bounds read since the size wasn't being checked. Check the size and warn on unexpected values to avoid this. Fixes: 6ea2a6fd3872 ("HID: corsair-void: Add Corsair Void headset family driver") Cc: stable@vger.kernel.org Signed-off-by: Stuart Hayhurst Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit e78973fe3ef594ef543f2ca963103458fae7bf91 Author: Andre Eikmeyer Date: Sat Jul 18 14:15:26 2026 +0200 HID: apple: preserve keyboard backlight across T2 resume commit 2b5d1495bd101f3d9c13caf3923754f48ee7371a upstream. The T2 virtual USB host controller re-enumerates the internal keyboard after system resume. The butterfly keyboard backlight currently uses LED_CORE_SUSPENDRESUME, so the LED core sends a blocking request to the old HID device while it is disappearing. That request fails with -ENODEV and the newly probed device starts with its backlight off. To fix this, we cache the requested brightness when the old HID device is removed and restore it when the replacement is probed. We let re-enumeration handle restoration instead of issuing a request through the stale device. Fixes: 1f95a6cd5ad7 ("HID: apple: ensure the keyboard backlight is off if suspending") Cc: stable@vger.kernel.org Signed-off-by: Andre Eikmeyer Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 846f0709559b9e27024e126a80bc7afb76516912 Author: Fredric Cover Date: Fri Jul 24 15:01:45 2026 -0700 smb: client: harden DFS cache against invalid target hints commit bf86c08123c6ab8c61cc0be1dad7540db93738ff upstream. Currently, get_tgt_name() returns ERR_PTR(-ENOENT) when ce->tgthint is NULL, and dfs_cache_noreq_update_tgthint() assumes ce->tgthint is always valid. In preparation for clearing ce->tgthint in free_tgts(), harden callers of get_tgt_name() against ERR_PTR results and harden dfs_cache_noreq_update_tgthint() against NULL pointer dereferences. Cc: stable@vger.kernel.org Signed-off-by: Fredric Cover Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 17a1922ada87318113bdb658bbe7d12e91b4d474 Author: Frank Sorenson Date: Thu Aug 20 16:22:10 2026 -0500 smb: client: fix copy-paste error in WSL EA length accounting for $LXDEV commit 5d14030b46af1a958fd104b020fbb93631c98822 upstream. The LXDEV block in cifs_query_path_info() uses SMB2_WSL_XATTR_MODE_SIZE (4) instead of SMB2_WSL_XATTR_DEV_SIZE (8), undercounting eas_len by 4 bytes per $LXDEV EA. eas_len is used only as a zero/non-zero presence flag so there is no current functional impact, but the value is incorrect and misleading. Fixes: 97db41604555 ("smb: client: parse uid, gid, mode and dev from WSL reparse points") Cc: stable@vger.kernel.org Cc: Paulo Alcantara Signed-off-by: Frank Sorenson Acked-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 1f824f61d1df52392eaf0b74dfa5659d724fde30 Author: Frank Sorenson Date: Mon Aug 17 12:16:51 2026 -0500 smb: client: fix ALIGN() overflow in symlink_data() error context loop commit 62656b024efc21c3230eade1a847f25871c3d2bb upstream. The check added by commit 7d9a7f1f96cd ("smb/client: fix possible infinite loop and oob read in symlink_data()") compared the post-ALIGN length against the remaining buffer, but ALIGN() itself can overflow: for ErrorDataLength near UINT32_MAX (e.g. 0xFFFFFFF9), ALIGN(x, 8) wraps to 0, so the subsequent bounds check passes, and the loop advances by zero bytes leaving 'p' pointing into stale data. Fix by checking the raw ErrorDataLength against the remaining space before applying ALIGN(), then checking again after. Since raw_len is bounded by the buffer, raw_len + 7 cannot overflow, so the second check is an exact post-alignment bounds guard. Fixes: 76894f3e2f71 ("cifs: improve symlink handling for smb2+") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 9ab46a13798a61d9d020b01d4e57efdabe6624fa Author: Fredric Cover Date: Fri Jul 24 15:01:46 2026 -0700 smb: client: clear ce->tgthint in free_tgts() commit b1b741cf8e7ce1b91d937e23decd3d3358748700 upstream. When free_tgts() frees all structures in ce->tlist, ce->tgthint is left pointing to one of the freed cache_dfs_tgt structures. If ce->tgthint is not reset before it is used later, it results in a use-after-free. Set ce->tgthint to NULL in free_tgts() after the elements are freed to reflect that no elements remain. Fixes: 54be1f6c1c37 ("cifs: Add DFS cache routines") Cc: stable@vger.kernel.org # depends on: smb: client: harden DFS cache against invalid target hints Signed-off-by: Fredric Cover Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 8b9b10fe5b8b492b27b9f4546742ea541a650213 Author: Frank Sorenson Date: Fri Jul 31 12:12:28 2026 -0500 cifs: use cifs_invalidate_cache() in cifs_do_truncate() for O_TRUNC commit 364b183230586a62660a7280c1eb20138338eeb5 upstream. cifs_do_truncate() is invoked from cifs_open() without i_rwsem, so it cannot use cifs_resize_file_locked() to perform a proper fscache cookie resize. Instead, add cifs_invalidate_cache() after cifs_setsize(). cifs_invalidate_cache() calls fscache_invalidate(), which works without holding i_rwsem: it unconditionally increments inval_counter and sets FSCACHE_COOKIE_NO_DATA_TO_READ, ensuring that stale cached data is not served once the cookie is later activated by fscache_use_cookie(). Truncation to zero leaves no valid cached data, making invalidation the correct semantic here. Fixes: fa724e235cfd ("cifs: add fscache_resize_cookie() to cifs_setsize()") Cc: stable@vger.kernel.org Cc: David Howells Cc: Paulo Alcantara Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit c2a0dcb5a7a1516aa6eb6d5cedca6a8e76527028 Author: Frank Sorenson Date: Sat Aug 22 16:55:17 2026 -0500 cifs: fix loff_t underflow in cifs_remap_file_range() when len == 0 commit 6c322f5cf7476ded7a9a20f7be72462065a03c68 upstream. With len == 0 (clone to EOF), the effective length is computed as: len = src_inode->i_size - off; If off > i_size, this is a negative loff_t, corrupting the ByteCount in the FSCTL_DUPLICATE_EXTENTS_TO_FILE request and inverting the range in filemap_write_and_wait_range(). The existing off >= i_size check fires only after the ioctl has already been sent. Snapshot i_size_read() once for both the bounds check and the length calculation, eliminating the TOCTOU and 32-bit torn-read risk. Reject off > src_size with -EINVAL. Treat off == src_size as a no-op, consistent with __generic_remap_file_range_prep(). Fixes: 04b38d601239 ("vfs: pull btrfs clone API to vfs layer") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 4f18c9e7ee464aaae5cd9fccdb943b3fcb4655d4 Author: Frank Sorenson Date: Thu Aug 6 21:41:56 2026 -0500 cifs: clear tcon after cifsFileInfo_put() in cifs_file_set_size() commit b96db32fed8dfb2478d7c208f89bf383beed1535 upstream. When the else branch of cifs_file_set_size() finds a writable file handle via find_writable_file(), it borrows tcon and server from the handle's tlink, attempts the handle-based set_file_size() RPC, and then releases the handle with cifsFileInfo_put(). If set_file_size() fails, execution falls through to the path-based fallback, which reuses the borrowed tcon and server under the "if (tcon == NULL)" guard. Since tcon is not NULL at that point, the guard is skipped. If cifsFileInfo_put() dropped the last reference on a tlink that was already removed from the tlink tree (TCON_LINK_IN_TREE cleared, as happens during reconnection or session teardown), cifs_put_tlink() will have freed tcon; the subsequent set_path_size() call is then a use-after-free. Setting tcon = NULL after cifsFileInfo_put() causes the existing guard to take the cifs_sb_tlink() path, which acquires a fresh reference for the path-based operation or fails cleanly if the session is gone. Fixes: 110fee6b9bb5 ("smb: client: fix missing timestamp updates with O_TRUNC") Cc: stable@vger.kernel.org Cc: Paulo Alcantara Signed-off-by: Frank Sorenson Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 636a99bab36ba27515363d325866c0273ac83b3e Author: Jérémy Jean Date: Tue Aug 11 22:01:27 2026 +0000 audit: avoid dropping live tree ref on fsnotify rule autoremove commit 783f0f0974c156aca630f4ffff248671082a098d upstream. audit_del_rule() is used for both netlink deletion templates and internal fsnotify autoremove. The former passes a parsed template which owns a temporary tree reference; the latter passes the installed entry itself. The unconditional audit_put_tree() at the end of audit_del_rule() assumes the template case. For mixed AUDIT_DIR plus AUDIT_EXE rules, an fsnotify autoremove event therefore drops the installed rule's live tree reference. Repeating this across rules sharing the same tree can free the tree while another rule still references it, and a later autoremove dereferences the freed pathname while comparing rules. Move the temporary-tree put to audit_rule_change(), the caller that owns deletion templates. Keep it in the AUDIT_DEL_RULE cleanup so both successful deletion and -ENOENT still release the parser-owned tree. Cc: stable@kernel.org Fixes: 34d99af52ad4 ("audit: implement audit by executable") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Ricardo Robaina Tested-by: Ricardo Robaina [PM: dropped unnecessary comment for line length reasons] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 25128202a8df52bce037c48045f97a389c3860d5 Author: Qu Wenruo Date: Tue Jun 9 08:43:34 2026 +0930 btrfs: do not overwrite NODATASUM flag when removing NODATACOW flag commit 15f7c86215e8d5f14b24127fa88af6c79363d50e upstream. [TEST FAILURE] The test case generic/628 will fail if MOUNT_OPTIONS is set to "-o nodatasum": FSTYP -- btrfs PLATFORM -- Linux/x86_64 btrfs-vm 7.1.0-rc4-custom+ #383 SMP PREEMPT_DYNAMIC Sat May 30 07:35:42 ACST 2026 MKFS_OPTIONS -- -O bgt -K /dev/mapper/test-scratch1 MOUNT_OPTIONS -- -o nodatasum /dev/mapper/test-scratch1 /mnt/scratch # generic/628 1s ... - output mismatch (see /home/adam/xfstests/results//generic/628.out.bad) # --- tests/generic/628.out 2022-05-11 11:25:30.816666664 +0930 # +++ /home/adam/xfstests/results//generic/628.out.bad 2026-06-08 18:56:49.878542927 +0930 # @@ -8,8 +8,9 @@ # 310f146ce52077fcd3308dcbe7632bb2 SCRATCH_MNT/a # 310f146ce52077fcd3308dcbe7632bb2 SCRATCH_MNT/d # test reflink flag not set iflag # +XFS_IOC_CLONE: Invalid argument # 310f146ce52077fcd3308dcbe7632bb2 SCRATCH_MNT/a # -310f146ce52077fcd3308dcbe7632bb2 SCRATCH_MNT/b # +d41d8cd98f00b204e9800998ecf8427e SCRATCH_MNT/b # ... [CAUSE] The direct cause is that after "chattr +S", the btrfs inode will lose its NODATASUM flag inherited from the mount option. E.g.: # mkfs.btrfs -f $dev # mount $dev $mnt -o nodatasum # touch $mnt/foobar # sync # btrfs ins dump-tree -t 5 $dev | grep "(257 INODE_ITEM 0) itemoff" -A 3 item 4 key (257 INODE_ITEM 0) itemoff 15879 itemsize 160 generation 9 transid 9 size 0 nbytes 0 block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0 sequence 1 flags 0x1(NODATASUM) ^^^^^^^^^ Proper NODATASUM flag # chattr +S $mnt/foobar # sync # btrfs ins dump-tree -t 5 $dev | grep "(257 INODE_ITEM 0) itemoff" -A 3 item 4 key (257 INODE_ITEM 0) itemoff 15879 itemsize 160 generation 9 transid 10 size 0 nbytes 0 block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0 sequence 2 flags 0x20(SYNC) ^^^^ Only the new SYNC flag This makes the inode drop the old NODATASUM flag, while the new reflink destination will still inherit the NODATASUM flag. The mismatching NODATASUM flags will cause the reflink to fail. The root cause is that, inside btrfs_fileattr_set() if no FS_NOCOW_FL is set, we remove both NODATASUM and NODATACOW flag. However we should not touch NODATASUM flag, as data COW doesn't require checksum. Only NODATACOW implies NODATASUM, but DATACOW doesn't imply DATASUM. The deeper problems are: - Fileattr API is too binary It either clears or sets a flag, there is no "do not change" option. So that why "chattr +S" implies "chattr -C", and is forcing us to change NODATACOW along with NODATASUM flag. - No way to change NODATASUM through fileattr API In fact NODATASUM can only be modified through mount option. The deeper problems are much harder to attack. [FIX] Remove NODATACOW flag when FS_NOCOW_FL is not set, but only remove NODATASUM if "nodatasum" mount option is not set. This allows the existing "chattr +C" then "chattr -C" to remove both NODATACOW and NODATASUM flags on a default mount. But for a mount with "nodatasum" option, the NODATASUM inode flag will persist through either "chattr +C" and "chattr -C". Fixes: 7e97b8daf634 ("btrfs: allow setting NOCOW for a zero sized file via ioctl") Cc: stable@vger.kernel.org Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f42efd634c0ae7ba0ce2fc5e30e291b0803b0ae2 Author: Shuangpeng Bai Date: Sun Jul 5 01:46:35 2026 -0400 btrfs: fix extent map leak in NOCOW direct I/O write commit 3f950867c307c5413d628a153ac44915bd117ffd upstream. btrfs_dio_iomap_begin() calls btrfs_get_extent(), which returns an extent map reference that must be dropped on all exit paths. For direct writes into a NOCOW range, btrfs_get_blocks_direct_write() keeps using that extent map and asks btrfs_create_dio_extent() to allocate the ordered extent. If that fails, for example because btrfs_alloc_ordered_extent() fails, the function returns the error without dropping the input extent map. The PREALLOC path avoided this by dropping the input extent map before replacing it with the newly created one. Check the error from btrfs_create_dio_extent() before replacing the map and drop the input extent map on failure. Fixes: 5f9a8a51d8b9 ("Btrfs: add semaphore to synchronize direct IO writes with fsync") CC: stable@vger.kernel.org Reviewed-by: Qu Wenruo Reviewed-by: Filipe Manana Signed-off-by: Shuangpeng Bai Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 8a64baeb5bbb706b83d2235c1e39f5b77183817f Author: Guanghui Yang <3497809730@qq.com> Date: Sun Jul 12 04:22:32 2026 +0000 btrfs: drop recovered reloc root refs on recovery failure commit 6d8ba4572922e336f0b59a80751b018e1e135164 upstream. During relocation recovery, each fs root gets a reference to its relocation root. If loading or adding a later root fails, or if the first transaction commit fails, btrfs_recover_relocation() jumps to out_unset before merge_reloc_roots() and clean_dirty_subvols(). put_reloc_control() drops the list-owned relocation root references, but it does not clear fs_root->reloc_root or drop the references owned by those pointers. Mount cleanup only drops them when BTRFS_FS_ERROR is set, so an error such as -ENOMEM while processing a later root can leave references behind. Keep temporary references to the fs roots associated during recovery. On failure, clear their reloc_root pointers and drop the corresponding references. Once the first transaction commit succeeds, drop only the temporary fs root references and let the normal merge and cleanup paths handle the relocation roots. Fault injection on a pending-relocation image confirmed the cleanup gap. With an injected first-commit failure, 25 fs roots had reloc_root set with fs_error=0. With this fix, the same failure path drops that count to 0 before mount fails. Fixes: f44deb7442ed ("btrfs: hold a ref on the root->reloc_root") CC: stable@vger.kernel.org Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit ec32015a955c5d326c5e26610edfdcccd52f2314 Author: Matthew Brown Date: Wed Aug 12 18:13:21 2026 +0100 ceph: fix leaked inode reference on writeback abort at umount commit c25aee9c630fb86f98d79eccb75765067079b972 upstream. ceph_dirty_folio() takes a wrbuffer claim on each newly dirtied folio: it bumps i_wrbuffer_ref (taking an ihold() on the 0->1 transition) and attaches the snap_context to folio->private. That claim is released only by ceph_put_wrbuffer_cap_refs(), which for a submitted write runs from writepages_finish(). In ceph_submit_write(), if ceph_inc_osd_stopping_blocker() fails -- which happens during umount -- the request is aborted before submission: the already-collected folios are only redirtied and unlocked, so writepages_finish() never runs and the claim is leaked. redirty_page_for_writepage() -> folio_redirty_for_writepage() -> filemap_dirty_folio() sets PG_dirty directly and does not go through ->dirty_folio, so ceph_dirty_folio() is not re-entered to rebalance it. Because every subsequent writeback also fails the osd_stopping_blocker, i_wrbuffer_ref never returns to 0, the ihold() is never dropped, and the inode cannot be evicted: VFS: Busy inodes after unmount of ceph kernel BUG at fs/super.c:650! Release the orphaned claim in the abort path before redirtying, via ceph_undo_wrbuffer_claim(): detach the snap_context, drop the wrbuffer reference (letting i_wrbuffer_ref reach 0 and iput() the inode), and drop the snap_context reference -- i.e. do what writepages_finish() would have done for these never-submitted folios. Only the locked_pages entries are undone; folios still in the fbatch were never dirty-cleared by this call (folio_clear_dirty_for_io() is the ownership-transfer point, and a successful move NULLs the fbatch slot), so they hold no claim this call owns. Cc: stable@vger.kernel.org Fixes: fd7449d937e7 ("ceph: fix generic/421 test failure") Signed-off-by: Matthew Brown Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 37d6edb2f03b29399a3a337fae78674de51e1695 Author: Max Kellermann Date: Tue Jul 7 23:42:28 2026 +0200 ceph: do not repeat ceph_trim_dentries() if no progress possible commit e7d7aa7b730178278109c41fa1b17b06873065d5 upstream. ceph_cap_reclaim_work() re-queues itself for as long as ceph_trim_dentries() returns -EAGAIN, which happens whenever a lease walk exhausts its `nr_to_scan` budget. This creates a busy loop that consumes CPU without making any progress when there is nothing to reclaim: with no cap pressure (`count==0`) and every scanned lease still valid, each pass runs the full scan budget down to zero and returns `-EAGAIN`, only to be queued again immediately. The dir-lease walk made this worse. When `expire_dir_lease` is `false` (i.e. we have no intention of reclaiming dir leases), __dir_lease_check() returned `TOUCH` for every valid lease. `TOUCH` moves the dentry to the tail of the list and resets `di->time` via __dentry_dir_lease_touch(), so a walk over N valid leases pointlessly rewrote the list, refreshed the timestamps (preventing them from ever aging out) and always drained `nr_to_scan`, guaranteeing the `-EAGAIN` requeue. Fix this in three steps: - Return `KEEP` instead of `TOUCH` when `expire_dir_lease` is `false`. If we are not going to reclaim the lease, leave it in place instead of churning the list and resetting its timestamp; the walk then terminates naturally (or via `STOP` at the first fresh lease). - Only return `-EAGAIN` from the first (dentry-lease) walk when something was actually freed. A full batch that frees nothing means retrying the same list immediately is futile; fall through to the dir-lease walk instead. - After both walks, bail out with success (0) when nothing was freed and there is no cap pressure (`count==0`). There is no reason to keep retrying when we are not over the cap limit and made no progress. Under real cap pressure (`count>0`) the reclaim path is unchanged and still retries via `-EAGAIN`. Without this patch, I saw 500 ceph_trim_dentries() calls per second on our web servers. This is very visible in `/proc/lock_stat` (5 minute capture): class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &mdsc->dentry_list_lock: 126180 128218 0.04 8063.44 15986965.20 124.69 1573354 5296812 0.04 8291.28 74164526.48 14.00 ----------------------- &mdsc->dentry_list_lock 111736 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2631 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 3878 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8 &mdsc->dentry_list_lock 9973 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0 ----------------------- &mdsc->dentry_list_lock 123621 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 1822 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2720 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0 &mdsc->dentry_list_lock 55 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8 With this patch: class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &mdsc->dentry_list_lock: 1203 1215 0.16 408.88 33082.88 27.23 4320501 7357389 0.04 500.64 1961578.00 0.27 ----------------------- &mdsc->dentry_list_lock 1029 [<000000003c9aea8a>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 169 [<000000002038c577>] __dentry_lease_unlist+0x50/0xa0 &mdsc->dentry_list_lock 16 [<00000000c991106d>] __ceph_dentry_lease_touch+0x5c/0xa8 &mdsc->dentry_list_lock 1 [<00000000612fe15f>] __dentry_leases_walk+0x64/0x2c8 ----------------------- &mdsc->dentry_list_lock 158 [<000000002038c577>] __dentry_lease_unlist+0x50/0xa0 &mdsc->dentry_list_lock 858 [<000000003c9aea8a>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 182 [<00000000612fe15f>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 17 [<00000000c991106d>] __ceph_dentry_lease_touch+0x5c/0xa8 __dentry_leases_walk() is almost gone. The total wait time is reduced by a factor of 483. That will give some latency gains to ceph_readdir(). Cc: stable@vger.kernel.org Fixes: 37c4efc1ddf9 ("ceph: periodically trim stale dentries") Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 1dd356310b1660215f9a3626580bf8b363ef981e Author: Michael Bommarito Date: Tue Jul 7 14:05:57 2026 -0400 ceph: bound xattr value length in __build_xattrs() commit 68d541754d6cd3bb98d1fd8314f57e5eb533557d upstream. __build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare "p += len" and no ceph_decode_need() check that "len" bytes remain in the blob. For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob. The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space. Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored. Cc: stable@vger.kernel.org Fixes: 355da1eb7a1f ("ceph: inode operations") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 58c2d3e954c13694ef6e820a5e9456461bb9e7df Author: Michael Bommarito Date: Tue Jul 7 14:05:59 2026 -0400 ceph: bound num_export_targets array for mds info v2/v3 commit a3eb169ee297aa99670ba927c659990bd1e453f3 upstream. ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from each per-mds info record and advances the decode cursor by num_export_targets * sizeof(u32) without first checking that many bytes remain. The only upper-bound check that catches a runaway cursor (*p > info_end) is gated on info_v >= 4, because info_end is left NULL for info_v 2 and 3. When the monitor sends an MDS map whose per-mds info version is 2 or 3 with an oversized num_export_targets, the cursor moves past the message front buffer and the later export-targets loop calls the unchecked ceph_decode_32() on out-of-bounds memory. A kernel client processes CEPH_MSG_MDS_MAP from its monitor session (net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an on-path attacker on an unsigned/unencrypted messenger session, can therefore drive an out-of-bounds read in the client kernel; on x86_64 with KASAN it is reported as a slab-out-of-bounds read in ceph_mdsmap_decode(). The decoded values land in the internal info->export_targets[] array, so the consequence is a kernel out-of-bounds read, not an information leak to the attacker. Impact: a malicious or compromised Ceph monitor sending an MDS map with a per-mds info version of 2 or 3 and an oversized num_export_targets field triggers an out-of-bounds read in the CephFS client kernel. Add a ceph_decode_need() for the export-targets array before advancing the cursor, so the bound is enforced for every info_v >= 2, not only info_v >= 4. This mirrors the count-then-need idiom already used for m_data_pg_pools later in the same function. Compute the export-targets byte count with size_mul() and reuse that checked length when advancing the cursor, so the attacker-controlled num_export_targets multiplication fails closed on overflow rather than relying on the later kcalloc() guard. Cc: stable@vger.kernel.org Fixes: d463a43d69f4 ("ceph: CEPH_FEATURE_MDSENC support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit c37db86d2b5e9b57001ccae7e7a727e95a4f9c02 Author: Michael Bommarito Date: Tue Jul 7 14:05:58 2026 -0400 ceph: bound MDSCapAuth path and fs_name decode in handle_session() commit 77933e22adfe813be2bd10be08d6e950103c3967 upstream. handle_session() decodes the MDSCapAuth records carried by a CEPH_SESSION_OPEN message (msg_version >= 6). For each record the match.path and match.fs_name byte strings are read by first decoding a 32-bit length and then copying that many bytes with the bare ceph_decode_copy(). Unlike the surrounding fields, which all use the _safe decode variants, these two copies are not preceded by a ceph_decode_need() bounds check, and the enclosing MDSCapAuth and MDSCapMatch struct_len fields are skipped rather than enforced as an upper bound. A length larger than the bytes remaining in the message front makes ceph_decode_copy() read past the end of the front buffer. The message front is a dedicated allocation (ceph_msg_new2() -> kvmalloc), so the over-read runs off that object. A malicious or compromised MDS can trigger this with the first post-connect message on mount, with no client-side user interaction; under KASAN it is reported as a slab-out-of-bounds read in handle_session(). Impact: a malicious MDS can force the kernel client to read up to 4 GiB past the message front allocation during session setup, crashing the client (out-of-bounds read). Switch both copies to ceph_decode_copy_safe(), which performs the ceph_decode_need() bounds check before the copy and branches to the existing bad label, matching the rest of the decoder and the error path that frees the partially decoded cap_auths array. Cc: stable@vger.kernel.org Fixes: 1d17de9534cb ("ceph: save cap_auths in MDS client when session is opened") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 06fb5e623cdc2402d6bb29be94d9beb9a826ffec Author: Michael Bommarito Date: Sat Jul 11 11:07:05 2026 -0400 ceph: bound copied dentry name length in NFS export get_name commit eff8013c5a8916613c742ae5a2cc341cb605c0ae upstream. ceph_get_name() copies the MDS-supplied name into the caller's NAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len) and then writes name[rinfo->dname_len] = 0, without checking dname_len against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply with dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies rde->name / rde->name_len the same unchecked way. Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name buffer in a client's NFS-export get_name path, a slab out-of-bounds write reported by KASAN. Reachable when a CephFS mount is re-exported over NFS. Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and __get_snap_name(). Cc: stable@vger.kernel.org Fixes: 19913b4eac4a ("ceph: add get_name() NFS export callback") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 4d298880f82c42383b36946bafde7ccf4d804c9b Author: Jérémy Jean Date: Thu Aug 13 14:00:00 2026 +0200 ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode commit aedc9053d909508a5f56c3f49f885fc030df4730 upstream. MDSMap export_targets entries are monitor controlled. check_new_map() uses each entry as a bit number in a fixed stack bitmap, so a rank outside the protocol namespace can make set_bit() write past the end of the array. Reject ranks outside CEPH_MAX_MDS while decoding the map. Do not validate against possible_max_rank here because maps may legitimately reference ranks beyond a temporarily reduced max_mds. Cc: stable@vger.kernel.org Fixes: d517b3983dd3 ("ceph: reconnect to the export targets on new mdsmaps") Signed-off-by: Jérémy Jean Reviewed-by: Alex Markuze Signed-off-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit fe46746087b5b9c5bb2d022df6c7819218494ced Author: Xiubo Li Date: Tue Jul 14 16:13:43 2026 +0800 ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock commit 7af4c4f01305b0935adf6d4301b1ec407025485d upstream. list_for_each_entry() iterates ci->i_cap_flush_list but drops i_ceph_lock to send cap messages. During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid <= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock. When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next on freed memory. The race timeline: __kick_flushing_caps() handle_cap_flush_ack() ----------------------- ----------------------- holds i_ceph_lock <--- iterates to cf (tid=10) prepares FLUSH message drops i_ceph_lock <--- __send_cap() ── FLUSH(tid=10) MDS sends FLUSH_ACK(tid=10) ---> acquires i_ceph_lock cf->tid(10) <= flush_tid(10), detaches cf from i_cap_flush_list drops i_ceph_lock ceph_free_cap_flush(cf) <- frees it! acquires i_ceph_lock <--- for-loop advances: cf = list_next_entry(cf, i_list) -- UAF on freed cf->i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS may respond with FLUSH_ACK quickly enough that handle_cap_flush_ack() frees cf before __kick_flushing_caps can finish the iteration. Fix by converting to a manual while loop: save the next pointer under i_ceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again. Cc: stable@vger.kernel.org Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 00562ccd4e88d092b9b851df50fad20442bfeb24 Author: Jérémy Jean Date: Sat Aug 15 21:46:37 2026 +0000 libceph: reject buckets with mismatched CRUSH ids commit 3cde4a8302301679937474a5f7a851394cc1bd11 upstream. crush_decode() stores bucket data by array slot, and the mapper later derives the per-bucket workspace index from the decoded bucket id. A malformed map can therefore make one bucket reuse another bucket's workspace by encoding an id different from -1 - slot. For uniform buckets, the second replica selection expands the source bucket's permutation into that aliased workspace buffer. If the source bucket is larger than the aliased bucket, the write runs past the smaller permutation array and can escape the kvmalloc'd CRUSH workspace. KASAN reports a slab OOB write of 4 bytes in bucket_perm_choose(). Reject buckets whose encoded id does not match their array slot. Valid CRUSH maps already use the canonical negative id corresponding to the bucket slot, so this restores the invariant expected by work->work[-1 - in->id] without changing valid map behavior. Cc: stable@vger.kernel.org Fixes: 66a0e2d579db ("crush: remove mutable part of CRUSH map") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 2571b35883268a266554e80d368e67fdfea7fb9d Author: Michael Bommarito Date: Tue Jul 14 07:51:39 2026 -0400 libceph: validate OSD extent maps before cursor advance commit 9ec08b7499a62c6d4afa93d36ab47a43fcad57d1 upstream. net/ceph/osd_client.c:osd_sparse_read() validates that the sparse-read data length matches the summed extent lengths, but it does not validate that each OSD-supplied extent is monotonic and lies inside the original request range. A malformed authenticated OSD reply can advertise a far-forward nonzero extent offset with a matching data length and make the client advance the message-data cursor beyond the request buffer. This reaches the BUG_ON(!*length) assertion in ceph_msg_data_next() from the client receive path. Impact: A malicious or compromised authenticated Ceph OSD peer can crash a kernel Ceph client via a malformed sparse-read reply. Reject sparse extent maps that overflow, move backwards, overlap, or extend outside the original sparse-read request before advancing the cursor. [ idryomov: perform sparse_extent_map_valid() check a bit earlier, in CEPH_SPARSE_READ_DATA_LEN instead of CEPH_SPARSE_READ_DATA_PRE state ] Cc: stable@vger.kernel.org Fixes: f628d7999727 ("libceph: add sparse read support to OSD client") Assisted-by: Codex:gpt-5-5-xhigh Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit b413ec5b23e3445dc9c4f273116078e2d4747626 Author: Chuck Lever Date: Thu Jul 9 13:40:28 2026 -0400 NFSD: Prevent client use-after-free during NFSv4.0 revoked-state cleanup commit 7b4f8a1586c42d3afc3c0ac779af2db7ab1a5c55 upstream. nfs40_clean_admin_revoked() takes a stateid reference under clp->cl_lock, drops nn->client_lock, and calls nfsd4_drop_revoked_stid(), which dereferences the stateid's client through s->sc_client->cl_lock. The stateid reference does not pin the client, so a teardown racing the dropped lock can free the client while nfsd4_drop_revoked_stid() is still using it. This cleanup runs from the laundromat, so a periodic sweep can race force_expire_client() driven by a write to the clients//ctl file. Skip a client that is already expiring and otherwise pin it with cl_rpc_users under client_lock before dropping the lock, matching nfsd4_revoke_states(). Fixes: d688d8585e6b ("nfsd: allow admin-revoked NFSv4.0 state to be freed.") Cc: stable@vger.kernel.org Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-5-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 4804c58f73a80d12df1de323bf97a164f6ee8743 Author: Chuck Lever Date: Thu Jul 9 13:40:24 2026 -0400 NFSD: Prevent lock owner use-after-free during client teardown commit 5e2fa29d223a9a1e6a948e40b109d09081d1decd upstream. __destroy_client() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on cl_ownerstr_hashtbl. client_has_state() does not count a bare owner, so DESTROY_CLIENTID can reach __destroy_client() with such owners present. __destroy_client() then walks the table, calling remove_blocked_locks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flc_owner. The per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently of client state. The two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks(). nfsd4_release_lockowner() holds a reference across the same call; __destroy_client() does not. Hold cl_lock across the walk, taking a reference and unhashing each owner, then drop it before remove_blocked_locks() and nfs4_put_stateowner(), which take blocked_locks_lock and cl_lock. Reported-by: Wolfgang Walter Closes: https://lore.kernel.org/linux-nfs/6eccafaaaa60651ef091257c3439c46b@stwm.de/ Fixes: 68ef3bc31664 ("nfsd: remove blocked locks on client teardown") Cc: stable@vger.kernel.org Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-1-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit b56d2c5f01cddbeca7d11cce81d97db4ec9a464f Author: Jeff Layton Date: Fri Jul 10 10:00:10 2026 -0400 nfsd: revoke copy-notify stateids before dropping their reference commit 3b0c3595db99bb4bebd7c8aa8a36f3c50e411bb7 upstream. Copy-notify stateids live in the s2s_cp_stateids IDR and on their parent stid's sc_cp_list, pinned by a single membership reference. _free_cpntf_state_locked() only unlinks an entry once its refcount reaches zero, so any revoke path that runs while a concurrent find_cpntf_state()/manage_cpntf_state() holder has elevated cs_count drops the reference without unlinking, leaving the entry discoverable with its membership reference already consumed. A second revoke or a laundromat tick then frees it while the reader still holds the pointer -- a KASAN-detectable use-after-free at the reader's nfs4_put_cpntf_state(). This affected all three revoke paths: - The parent-stid drain (nfs4_free_cpntf_statelist()) repeatedly called _free_cpntf_state_locked() on the first list entry; a holder that had bumped cs_count made it return early, so the next iteration re-decremented and burned the holder's reference. - OFFLOAD_CANCEL (manage_cpntf_state()) and laundromat expiry likewise used _free_cpntf_state_locked() and could drop 2->1 without unlinking. Add revoke_cpntf_state_locked(), which unhashes the entry from the IDR and sc_cp_list first (deferring the final free to any holder), and use it from all three revoke paths. The drain now walks with list_for_each_entry_safe() and revokes each entry unconditionally, so it terminates in one pass per entry regardless of cs_count. The unhash is gated on !list_empty(&cps->cp_list); the idr_remove() gate matters because idr_alloc_cyclic() may have recycled the so_id by then. Keep _free_cpntf_state_locked() for the reference-holder put path only, where a concurrent revoke may already have unlinked the entry (its list_del_init() then a no-op). Fixes: 624322f1adc5 ("NFSD add COPY_NOTIFY operation") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260710-nfsd-testing-v3-6-a0ff7db6aa3e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit dbc11a12aa5457a7c39f6414ee46b20043675246 Author: Jeff Layton Date: Thu Jun 11 16:00:57 2026 -0400 nfsd: reject reclaim LOCK after RECLAIM_COMPLETE commit 2327ba1d9546727a35b17888777e991f68a9b305 upstream. nfsd4_lock() only checks the namespace-wide grace flag when deciding whether to accept a reclaim LOCK. It does not check the per-client NFSD4_CLIENT_RECLAIM_COMPLETE bit. An NFSv4.1+ client that has already sent RECLAIM_COMPLETE can submit lk_reclaim=1 while grace is still active (e.g. lockd holds the grace list open), and the server accepts it instead of returning NFS4ERR_NO_GRACE as required by RFC 8881 section 18.51.3. The OPEN path already enforces both tiers: the grace check plus the per-client RECLAIM_COMPLETE check in nfs4_check_open_reclaim(). Add the equivalent per-client check to the LOCK path. Fixes: 3b3e7b72239a ("nfsd: reject reclaim request when client has already sent RECLAIM_COMPLETE") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton [ cel: Correct the RFC citations in the commit message ] Link: https://patch.msgid.link/20260611-nfsd-testing-v2-14-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit ad02d095439f89cbd6629420c7e3ba476457b83b Author: Robbie Ko Date: Tue Jun 16 13:39:58 2026 +0800 nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE commit 26709c8ffe73772eb69e68d553ac71d91228dccc upstream. The NFSv2 sattr decoder converts the wire useconds to nanoseconds in svcxdr_decode_sattr(): iap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC; tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds value such as 4294968 wraps to tv_nsec == 704. The corruption therefore happens during decode, before any proc function can inspect the value, and a later range check on tv_nsec would see an in-range result and accept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply. NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return for a malformed time argument, and the check cannot move to the proc function the way the v3/v4 nsec range checks do. Guard the raw useconds before the multiplication and reject values greater than 1000000. useconds == 1000000 is kept: it is the Sun convention for "set to the current server time", and the in-tree Linux NFSv2 client emits it in both the atime and the mtime field for a plain touch / utimes(file, NULL) (see encode_sattr() and xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000 would turn that common operation into a hard decode failure for both SETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap on ILP32, so the Sun convention value passes through safely. Only genuinely out-of-range values (> 1000000) are rejected. The atime and mtime guards are therefore symmetric. The decoder only applied the Sun convention in the mtime block, which clears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a client puts 1000000 in the atime field but not in the mtime field, the atime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET set, so the bogus value reached the filesystem. Apply the convention in the atime block as well, clearing ATTR_ATIME_SET so the server uses its current time and ignores the value. Only ATTR_ATIME_SET is cleared there. The mtime block keeps its existing behavior, where 1000000 means "set both atime and mtime to now". Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Robbie Ko [ cel: various tweaks, addenda, and clean-ups ] Link: https://patch.msgid.link/20260616054027.2360930-1-robbieko@synology.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 54e02f5e32c52fb395f2ee02986a6c6d5608d22b Author: Robbie Ko Date: Tue Jun 16 13:39:59 2026 +0800 nfsd: reject out-of-range nseconds in NFSv3 SETATTR and create ops commit eb0eca7720662ba5847df1510e73801f7f473094 upstream. A client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD carrying an atime or mtime whose nseconds field is out of range. The value is well-formed on the wire and decodes cleanly into a valid uint32, but it is not a valid timespec64: tv_nsec must be less than NSEC_PER_SEC. Nothing in the setattr path clamps it. notify_change() runs the time through timestamp_truncate(), which does not reduce tv_nsec below NSEC_PER_SEC when the filesystem supports nanosecond granularity (s_time_gran == 1), and the inode atime/mtime setters store it verbatim (only ctime is normalized, via inode_set_ctime_to_ts()). The un-normalized value then corrupts on-disk metadata: ext4's ext4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, which overflows the 32-bit extra field and clobbers the seconds-epoch bits, so the stored seconds (and thus the year) are wrong on read-back. XFS with bigtime mis-stores the timestamp for the same reason. Validate the client-supplied atime/mtime in the proc handlers and return NFS3ERR_INVAL before anything is changed. RFC 1813 lists NFS3ERR_INVAL for SETATTR and describes it as the error for a value the server 'can not store ... in its own representation'; the client maps it to EINVAL. Checking in the proc handlers, rather than in nfsd_setattr(), keeps the rejection in front of object creation. The create operations create the object before nfsd_create_setattr() runs, so a late failure would leave the new object behind and turn a non-idempotent request into a namespace change that reports failure. The check is therefore done up front, for the create operations before the object is created. tv_nsec is a long, so the comparison casts it to unsigned long (the same width) rather than to u32, matching timespec64_valid(). A u32 cast would truncate on 64-bit; the unsigned long cast also rejects a value that became negative when an out-of-range u32 wire nseconds was assigned to a 32-bit long. Only client-supplied times are checked: SET_TO_SERVER_TIME requests carry no client value. The sattrguard3 ctime is deliberately left alone: an out-of-range guard simply never matches the object's ctime and yields NFS3ERR_NOT_SYNC via the existing guardtime comparison, which is the protocol-correct outcome rather than rejecting the request. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Robbie Ko Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260616054027.2360930-2-robbieko@synology.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 4ae5d7490ae6a7b83b3d607f88c499f4f85e753a Author: Jeff Layton Date: Thu Jun 11 16:01:00 2026 -0400 nfsd: move nfsd_debugfs_init() after nfsd4_init_slabs() in init_nfsd() commit 2c390c8a1764d67095fe444401861fac4c049362 upstream. nfsd_debugfs_init() runs before nfsd4_init_slabs() in init_nfsd(). If the slab allocation fails, the bare "return retval" bypasses nfsd_debugfs_exit(), leaving orphan debugfs files with stale fops pointers into the freed module text. Move nfsd_debugfs_init() to after the slab init succeeds, so the early return has no debugfs state to clean up. Since debugfs is now the more recently initialized of the two, also update the unwind paths to match reverse-initialization (LIFO) order: run nfsd_debugfs_exit() before nfsd4_free_slabs() in both the init_nfsd() error path and exit_nfsd(). The nfsd debugfs files only reference module-global state and have no dependency on the slab caches, so that reordering is a cleanup with no functional change. Fixes: 9fe5ea760e64 ("NFSD: Add /sys/kernel/debug/nfsd") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-17-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit b57bd8cb739cb3cf88bdb1a5903a42a707a5c282 Author: Jeff Layton Date: Thu Jun 11 16:01:01 2026 -0400 nfsd: initialize DRC hash table before registering shrinker commit b0c58934f5cc4f05b63ef6605dd10c1d0d489e88 upstream. shrinker_register() precedes the INIT_LIST_HEAD loop and the drc_hashsize store. On weakly-ordered architectures (arm64, ppc), a shrinker scan can observe drc_hashsize before the bucket list heads are initialized, causing a NULL deref in the DRC shrinker callback. Move bucket initialization and the drc_hashsize store before shrinker_register() so the hash table is fully initialized before it becomes visible to the shrinker. Fixes: 8eea99a81c6f ("nfsd: dynamically allocate the nfsd-reply shrinker") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-18-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit a4d7fedcaaf33e60a01e53eafca9041ef966212f Author: Jeff Layton Date: Fri Jul 10 10:00:08 2026 -0400 nfsd: initialize copy-notify stateid before publishing it commit 129643893b79f8a3c6b72045f933fbab5ee424ca upstream. nfsd4_copy_notify() finished initializing the cpntf state after nfs4_alloc_init_cpntf_state() had already linked it into the s2s_cp_stateids IDR and the parent's sc_cp_list, with cs_count == 1 (the membership reference) and none held for the caller. A racing OFFLOAD_CANCEL (crafted cl_id == nn->s2s_cp_cl_id plus the guessable so_id) could reach manage_cpntf_state() and free the entry, turning the caller's subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid writes into use-after-free. The owning clientid was also only recorded after publication, so it could not gate an ownership check in that window. Record cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state() before nfs4_init_cp_state() publishes the entry, and return it with an extra reference. The caller reads the stateid under that reference and drops it with nfs4_put_cpntf_state(); on a late error the laundromat reaps the entry. Fixes: 624322f1adc5 ("NFSD add COPY_NOTIFY operation") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260710-nfsd-testing-v3-4-a0ff7db6aa3e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 763c0bad872368304db718f79af7e93048885c67 Author: Chris Mason Date: Tue Jun 2 12:23:14 2026 -0400 nfsd: hold rcu across localio cmpxchg retry commit 58884694978a3d7d111edb433d7fd6a6c5af2f34 upstream. nfsd_file objects are freed via call_rcu (filecache.c:296), and nfsd_file_slab is created without SLAB_TYPESAFE_BY_RCU (KMEM_CACHE(nfsd_file, 0) at filecache.c:789), so the slab page backing a freed nfsd_file becomes freely reclaimable once the RCU grace period elapses. The again: retry block in nfsd_open_local_fh() loads a pointer with cmpxchg and then calls nfsd_file_get(new) (which is refcount_inc_not_zero) without holding rcu_read_lock. The sole caller nfs_open_local_fh() drops rcu_read_lock before invoking this helper, so no outer reader-side critical section covers the load. CPU 0 (nfsd_open_local_fh) CPU 1 (nfsd_file_put_local) ----- ----- new = cmpxchg(pnf, NULL, ...) nf = xchg(pnf, NULL) nfsd_file_put(nf) last ref -> call_rcu() /* grace period elapses; slab page recycled */ nfsd_file_get(new) refcount_inc_not_zero(&new->nf_ref) /* operates on recycled memory */ A non-zero word at the nf_ref offset of the recycled object makes the refcount bump appear to succeed, and the caller then dereferences new->nf_net and new->nf_file out of freed memory. Fix by taking rcu_read_lock() immediately before the cmpxchg and releasing it on all three exits of the if (new) block: the goto-again retry, the lost-race cleanup path, and the install-succeeded path. nfsd_file_put() and nfsd_net_put() stay outside the RCU section so they remain free to block. Fixes: e6f7e1487ab5 ("nfs_localio: simplify interface to nfsd for getting nfsd_file") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Chris Mason Link: https://patch.msgid.link/20260602-nfsd-testing-v2-2-e4ea62e3cd5c@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit b3bff820d068ea59767d4e91a3258231a879da5f Author: Chris Mason Date: Sat May 30 09:19:21 2026 -0400 nfsd: gate nfs3 setacl by argp->mask commit 453d7198a0ab07a12d46e0575861ac7b932da17e upstream. nfsd3_proc_setacl() calls set_posix_acl() unconditionally for both ACL_TYPE_ACCESS and ACL_TYPE_DEFAULT, passing argp->acl_access and argp->acl_default verbatim. The NFSv3 ACL decoder only populates those pointers when the corresponding mask bit is set: nfs3svc_decode_setaclargs() if (args->mask & NFS_ACL) decode into acl_access if (args->mask & NFS_DFACL) decode into acl_default /* otherwise the pointer stays NULL (pc_argzero) */ nfsd3_proc_setacl() set_posix_acl(.., ACL_TYPE_ACCESS, argp->acl_access) set_posix_acl(.., ACL_TYPE_DEFAULT, argp->acl_default) set_posix_acl(idmap, dentry, type, NULL) is the VFS "remove this ACL type" operation. A NULL pointer that means "the client did not send this arm" is therefore indistinguishable from "the client asked to remove this ACL". A SETACL with mask=NFS_ACL silently drops the directory's default ACL; mask=0 drops both. The sibling nfsd3_proc_getacl() already consults argp->mask before touching each arm; mirror that in setacl. Fix by wrapping each set_posix_acl() call in the matching mask bit check and initializing error to 0 before inode_lock so that a request with neither bit set leaves the on-disk ACLs untouched and returns nfs_ok. The out_drop_lock path and the unconditional posix_acl_release() at out: are preserved; both NULL-tolerate the skipped arms. Fixes: a257cdd0e217 ("[PATCH] NFSD: Add server support for NFSv3 ACLs.") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Reported-by: Chris Mason Signed-off-by: Chris Mason Link: https://patch.msgid.link/20260530-nfsd-fixes-v2-5-f27e8eb4d974@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f951b22dbeec46f2e0fba81cb80d1b0c686b61eb Author: Chuck Lever Date: Sat May 30 16:58:16 2026 -0400 nfsd: gate nfs2 setacl by argp->mask commit a3a7e20ed66d3f04d37883c398da8a113b430769 upstream. The NFSACL v2 SETACL path shares the decoder convention used by its v3 sibling: nfsaclsvc_decode_setaclargs() fills in argp->acl_access only when NFS_ACL is set in the request mask and argp->acl_default only when NFS_DFACL is set, leaving the other pointer NULL because the argument buffer is zeroed up to pc_argzero before decode. nfsacld_proc_setacl() then hands both pointers to set_posix_acl() unconditionally. set_posix_acl(idmap, dentry, type, NULL) is the VFS "remove this ACL type" operation, so an omitted arm is indistinguishable from an explicit request to delete that ACL. A SETACL carrying only NFS_ACL silently strips the directory's default ACL; mask=0 strips both. This is the same defect just fixed in nfsd3_proc_setacl(); apply the same remedy. Gate each set_posix_acl() call on its mask bit and initialize error to 0 so that a request with neither bit set leaves the on-disk ACLs untouched and returns success. The out_drop_lock path and the unconditional posix_acl_release() in nfsaclsvc_release_setacl() already tolerate the skipped arms. Fixes: a257cdd0e217 ("[PATCH] NFSD: Add server support for NFSv3 ACLs.") Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 41ebca28e17f84293650598f86bd69532ec1a8e0 Author: Jeff Layton Date: Wed May 27 14:30:41 2026 -0400 nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo commit 8b989aaec85e1293a871d602590c951fe44b8647 upstream. nfsd4_ff_encode_getdeviceinfo() computes the da_addr_body reservation as 16 + netid_len + addr_len, but the subsequent xdr_encode_opaque() calls emit 8 + round_up(netid_len, 4) + round_up(addr_len, 4) bytes. The mismatch means the declared da_addr_body length exceeds the actual encoded data by 2-8 bytes on every flexfile GETDEVICEINFO reply, leaking stale reply-page content to the client and mis-aligning the subsequent version list decode. Use xdr_align_size() for each string length to match what xdr_encode_opaque() actually writes. Fixes: efcae97fa425 ("NFSD: da_addr_body field missing in some GETDEVICEINFO replies") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260527-pnfs-fixes-v1-1-784f39dc1eca@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 0380129b1373c437eb35401a174671c8888f4b80 Author: Jeff Layton Date: Thu May 28 10:38:15 2026 -0400 nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget commit f9868174af49d207fbaf0c5e055d088a983684af upstream. The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client: - fh_len doesn't account for XDR padding on the file handle data - uid and gid lengths use "8 + len" but xdr_encode_opaque() actually writes "4 + xdr_align_size(len)" bytes - ds_len omits the flags and stats_collect_hint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client. Fix this by breaking out every encoded field explicitly in the ds_len calculation, using xdr_align_size() for all variable-length opaque fields, and correcting the header constants. Fixes: 9b9960a0ca47 ("nfsd: Add a super simple flex file server") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260528-pnfs-fixes-v1-1-8a1255ae2f16@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 4106d7a6aaf1eee322beb3ec7d4177ced1b597e8 Author: Jeff Layton Date: Thu Jun 11 16:00:52 2026 -0400 nfsd: fix version mismatch loops in nfsd_acl_init_request() commit 9bc761051dcd9a4a8b59e64b2b185172d13c716d upstream. The loops that compute the supported version range for PROG_MISMATCH test nfsd_support_acl_version(rqstp->rq_vers) instead of nfsd_support_acl_version(i), so every iteration fails and the function returns rpc_prog_unavail instead of rpc_prog_mismatch. Replace rqstp->rq_vers with the loop variable i, matching the pattern used by the sibling nfsd_init_request() function. Fixes: e333f3bbefe3 ("nfsd: Allow containers to set supported nfs versions") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-9-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 9b4e5e9ba5ae13808b8a6d229d87c54611ba0e7a Author: Jeff Layton Date: Fri Jul 10 10:00:07 2026 -0400 nfsd: fix stale s2s_cp_stateids IDR entry for async COPY commit d0beaee498e11880e72826026db0e9c9890fc114 upstream. For an async COPY, nfsd4_copy() called nfs4_init_copy_state() before dup_copy_fields(), so the s2s_cp_stateids IDR was pointed at &u->copy->cp_stateid -- memory in the per-rqstp COMPOUND buffer that is reused by the next request. dup_copy_fields() copies only the value into async_copy, so the IDR slot dangled at the transient buffer for the whole background copy. Any IDR walker then dereferences reused request memory: the laundromat reads cs_type from it and, if the bytes look like an expired NFS4_COPYNOTIFY_STID, follows into refcount_dec()/idr_remove()/kfree() on garbage; manage_cpntf_state() has the same exposure via idr_find(). Duplicate the fields first, then register the stateid on the stable async_copy. result->cb_stateid is unchanged. Fixes: e0639dc5805a ("NFSD introduce async copy feature") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260710-nfsd-testing-v3-3-a0ff7db6aa3e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 2ebbf4e3e9cf561d90d7fcaf4f4f275d980715a4 Author: Jeff Layton Date: Tue Jun 16 07:59:00 2026 -0400 nfsd: fix reply size estimate for GET_DIR_DELEGATION commit 46f929b907b3bc488593c006f0c97e35baba9ea4 upstream. nfsd4_get_dir_delegation_rsize() returns its estimate in XDR words, but the COMPOUND reply-size machinery works in bytes: every other op's _rsize helper multiplies its word count by sizeof(__be32). Since GET_DIR_DELEGATION is OP_MODIFIES_SOMETHING, this estimate is consulted before the op executes to ensure the reply will fit. The ~4x too-small estimate lets a compound near the session/reply limit pass the check, grant a directory delegation, and then fail to encode the reply with NFS4ERR_RESOURCE/REP_TOO_BIG, leaving the client without the returned stateid. Multiply the estimate by sizeof(__be32) like the other _rsize helpers. Fixes: 33a1e6ea73e5 ("nfsd: trivial GET_DIR_DELEGATION support") Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260616-dir-deleg-v7-17-6cbc7eac0ade@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit cf081015a0d1bc6fd7e753c423ec624d8cc4032f Author: Jeff Layton Date: Tue Jun 2 12:23:18 2026 -0400 nfsd: fix refcount leak in nfsd_file_lru_add on insertion failure commit 30c2df3005c99819e117402dc492db4a2a696c2f upstream. nfsd_file_lru_add() unconditionally increments nf_ref before attempting to insert the nfsd_file into the LRU via list_lru_add_obj(). If the insertion fails (the item is already linked), the incremented reference is never released, permanently inflating the refcount. The LRU shrinker callback (nfsd_file_lru_cb) uses refcount_dec_if_one() to reclaim entries, which requires nf_ref == 1. An inflated refcount therefore blocks eviction of the affected file cache entry for the lifetime of the nfsd instance. While this failure path is currently unreachable -- the sole caller in nfsd_file_do_acquire() operates on freshly-allocated objects that cannot already be on the LRU -- it represents a latent bug that would become exploitable if a future change adds another call site or alters the PENDING protocol. Fix this by: - Adding a compensating refcount_dec() on the failure path. Bare refcount_dec (rather than nfsd_file_put) is correct here because the caller in nfsd_file_do_acquire still holds its own construction reference, so the count goes from 2 back to 1 without risk of reaching zero. - Changing WARN_ON(1) to WARN_ON_ONCE(1) to prevent log flooding if this path is ever hit repeatedly. - Returning early on failure to skip the unnecessary call to nfsd_file_schedule_laundrette(), since no entry was added to the LRU. Fixes: 56221b42d717 ("nfsd: filecache: don't repeatedly add/remove files on the lru list") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260602-nfsd-testing-v2-6-e4ea62e3cd5c@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 3c5119b799a7f57db332b2c31e806de16c869f0f Author: Nikol Kuklev Date: Sat Jun 13 11:24:20 2026 +0300 nfsd: fix null dereference in nfsd4_setattr for deleg timestamp attrs commit fe456c8c0931bb3e8a03d429920e87fd85747fba upstream. When a SETATTR request includes FATTR4_WORD2_TIME_DELEG_ACCESS or FATTR4_WORD2_TIME_DELEG_MODIFY in the attribute bitmap, nfsd4_setattr() sets deleg_attrs=true and calls nfs4_preprocess_stateid_op() to validate the stateid. If the client supplies the NFSv4 "one stateid" (all-0xFF bytes), check_special_stateids() returns nfs_ok without populating the output nfs4_stid pointer, because the special-stateid path in nfs4_preprocess_stateid_op() jumps to done: with s==NULL, and the "if (s)" block that would set *cstid is skipped. The local variable `st` remains NULL. Back in nfsd4_setattr(), the if (deleg_attrs) block then unconditionally dereferences st->sc_type (at offset 4 from NULL), causing a kernel oops. This is remotely triggerable by any NFSv4 client: send COMPOUND [PUTROOTFH, SETATTR(ONE_STATEID, {bmval2=FATTR4_WORD2_TIME_DELEG_ACCESS, ...})]. No authentication, delegation, or prior state is required. Fix by adding a NULL check before the dereference. A special stateid is not a delegation stateid, so the existing nfserr_bad_stateid return value is already correct; we only need to guard the pointer dereference itself. Fixes: 7e13f4f8d27d ("nfsd: handle delegated timestamps in SETATTR") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Nikol Kuklev Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 424d5c95108a4809b832cb0a312c61de4aec0078 Author: Jeff Layton Date: Sun May 31 08:07:00 2026 -0400 nfsd: fix nfsd_file leak on inter-server COPY setup failure commit 88a76145451d703eedd867b5989bf73d17340399 upstream. When nfsd4_setup_inter_ssc() fails, nfsd4_copy() returns nfserr_offload_denied directly, bypassing the out: label where release_copy_files() would drop the nf_dst reference taken by nfs4_preprocess_stateid_op(). Each failed inter-server COPY leaks one nfsd_file, pinning file/inode/dentry/vfsmount. Fix by setting status and jumping to out: instead of returning directly. Fixes: ce0887ac96d3 ("NFSD add nfs4 inter ssc to nfsd4_copy") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260531-nfsd-testing-v1-3-7bfa481b0540@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 360e1b9e3f316545e7990acf8b25ddb953b08354 Author: Jeff Layton Date: Thu Jun 11 16:00:46 2026 -0400 nfsd: fix netlink dumpit error handling for rpc_status_get commit e13d505af73a1e013aa81806652d4378b21cfca2 upstream. nfsd_genl_rpc_status_compose_msg() returns -ENOBUFS on nla_put failure without calling genlmsg_cancel(), leaving a partial message in the skb. The caller then propagates -ENOBUFS directly, which the netlink dump infrastructure treats as a fatal error, aborting the entire dump. The correct netlink dump convention is: - Cancel any partial message with genlmsg_cancel() - If prior messages were added to the skb (skb->len > 0), save the current iterator position and return skb->len to paginate - Only return a negative errno when no messages fit at all Fix compose_msg to cancel the partial message on all nla_put failure paths, and fix the caller to paginate when possible rather than returning a fatal error. A second defect surfaces once pagination actually works: cb->args[1] records the resume index within the pool named by cb->args[0], but the inner loop applied it to every pool from cb->args[0] onward. After a mid-pool pause, a later dump call drains the resume pool and continues into subsequent pools within the same call, where the stale cb->args[1] caused the first N threads of each following pool to be skipped. On per-CPU or per-node pool configurations this silently dropped active requests from the dump. Apply the saved thread index only to the pool matching cb->args[0], and start every subsequent pool from thread 0. Fixes: bd9d6a3efa97 ("NFSD: add rpc_status netlink support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton [ cel: fold in 20/21 to avoid bisect hazard ] Link: https://patch.msgid.link/20260611-nfsd-testing-v2-3-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 65c79d9bb37176ab37ce523a255d6b5c35db621d Author: Jeff Layton Date: Thu Jun 11 16:00:53 2026 -0400 nfsd: fix FL_SLEEP being set unconditionally for all LOCK types commit 246a90a5109bb2857db41f491277882ee2743b26 upstream. The FL_SLEEP guard uses lk_type & (NFS4_READW_LT | NFS4_WRITEW_LT) which computes lk_type & 7, non-zero for all valid lock types including non-blocking ones. This was introduced by commit 7e64c5bc497c ("NLM/NFSD: Fix lock notifications for async-capable filesystems") when refactoring from per-case switch arms. Replace the bitmask test with explicit equality checks. Fixes: 7e64c5bc497c ("NLM/NFSD: Fix lock notifications for async-capable filesystems") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-10-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit c1ae0f973bcba5730871e35976a0ab6878fdac34 Author: Jeff Layton Date: Sun May 31 08:07:01 2026 -0400 nfsd: fix dentry ref leak on V4ROOT export filehandle lookup commit 6247023fbbec1325029f2d5f2a7cdc0f9f9ea15a upstream. nfsd_set_fh_dentry() leaks the dentry reference from exportfs_decode_fh_raw() when the NFS3_FHSIZE or NFS_FHSIZE switch cases detect NFSEXP_V4ROOT and goto out. The out: label calls exp_put() but never dput(dentry), and fhp->fh_dentry was never assigned so fh_put() cannot compensate. A crafted NFSv3 filehandle targeting a V4ROOT export's fsid triggers the leak on every request. Fixes: ef7f6c4904d0 ("nfsd: move V4ROOT version check to nfsd_set_fh_dentry()") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260531-nfsd-testing-v1-4-7bfa481b0540@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit a631a26a8777bb235eabd478bbbaf26a4db750bf Author: Chris Mason Date: Fri Jul 10 10:00:05 2026 -0400 nfsd: fix cpntf publish race in nfs4_init_cp_state commit be3a5c1d857b0dcbc11796cea603ef25834f75b2 upstream. nfs4_alloc_init_cpntf_state() published the new cpntf entry into the s2s_cp_stateids IDR (with cs_type set) in one s2s_cp_lock section, then took the lock again to list_add() it onto p_stid->sc_cp_list. In the gap the entry is reachable by so_id but cp_list is still {NULL,NULL} from kzalloc. A racing OFFLOAD_CANCEL (so_id is echoed to the client as cnr_stateid, so any NFSv4.2 client can drive it) reaches manage_cpntf_state() -> _free_cpntf_state_locked() and does list_del() on the zeroed list_head, oopsing the server. Fold the cs_type assignment and the list_add() into the same critical section as idr_alloc_cyclic(), so a concurrent lookup either misses the entry or sees a fully linked cp_list. INIT_LIST_HEAD() the entry after allocation and switch _free_cpntf_state_locked() to list_del_init() so a stale unlink is a no-op. nfs4_init_copy_state() passes NULL p_stid and skips the list_add, preserving NFS4_COPY_STID semantics. Fixes: 624322f1adc5 ("NFSD add COPY_NOTIFY operation") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Chris Mason Link: https://patch.msgid.link/20260710-nfsd-testing-v3-1-a0ff7db6aa3e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 607a56fea772c1f4f4989d8e255dd4f7192d9604 Author: Jeff Layton Date: Sat May 30 09:19:17 2026 -0400 nfsd: fix BUG_ON in nfsd4_alloc_layout_stateid on racing delegation revoke commit ca94ba36172046be6a694a7986f6931e47ed4d51 upstream. nfsd4_alloc_layout_stateid reads fp->fi_deleg_file without holding fi_lock when the parent stateid is a delegation. A concurrent delegation revoke via the laundromat can clear fi_deleg_file under fi_lock, causing nfsd_file_get() to return NULL and triggering the BUG_ON. This race is client-reachable: two NFS clients can trigger it by having one hold a delegation while another opens the same file to force a recall. When the first client doesn't respond to the recall, the laundromat revokes it. A concurrent LAYOUTGET from any client using the delegation stateid hits the race window. Fix this by taking fi_lock around the fi_deleg_file read in the SC_TYPE_DELEG path, matching the locking discipline of the find_any_file() arm, and replacing the BUG_ON with a graceful error return that cleans up the partially-initialized layout stateid. Fixes: c5c707f96fc9 ("nfsd: implement pNFS layout recalls") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Reported-by: Chris Mason Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260530-nfsd-fixes-v2-1-f27e8eb4d974@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 00843074d9b84824552c9679d423d29500ca5de0 Author: Jeff Layton Date: Thu Jun 11 16:01:04 2026 -0400 nfsd: drop the stateid, not the stateowner, on seqid_op replay retry commit 5e4627d3513e60accfce9d5f4c7fa95251ef93d6 upstream. In nfs4_preprocess_seqid_op() the stateid is obtained from nfsd4_lookup_stateid(), which holds a reference on the nfs4_stid (sc_count) but takes no reference on the stateowner. openlockstateid() merely casts that stid and likewise takes no reference. When nfsd4_cstate_assign_replay() returns -EAGAIN (the replay owner is being torn down, RP_UNHASHED) it has not taken a stateowner reference on that path. The error handling nevertheless called nfs4_put_stateowner(stp->st_stateowner), dropping an so_count reference the function never acquired -- risking a stateowner refcount underflow and use-after-free -- while leaking the sc_count reference held on the stid. The leaked stid reference can also stall a concurrent nfsd4_close_open_stateid() waiting for sc_count to drop. Drop the reference actually held -- the stid -- before retrying. The stateowner stays alive through the reference held by the stid. This mirrors the open path in nfsd4_process_open1(), where the put balances a reference that path explicitly holds on the stateowner. Fixes: eec762080008 ("nfsd: replace rp_mutex to avoid deadlock in move_to_close_lru()") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-21-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 72d40b103bb03f0124d3a3c8f71a30cbafaf6afa Author: Jeff Layton Date: Tue May 26 12:24:48 2026 -0400 nfsd: don't free session slots that are still in use commit f5d22e372f4ac3eb287037a488c29691d52a6330 upstream. nfsd4_sequence() can free the very slot it is currently processing. When the session shrinker has reduced se_target_maxslots below se_fchannel.maxreqs, the shrink path checks three conditions before calling free_session_slots(): 1. se_target_maxslots < maxreqs (shrink was advertised) 2. slot->sl_generation == se_slot_gen (slot is up-to-date) 3. seq->maxslots <= se_target_maxslots (client acknowledges) However, seq->slotid is never checked against se_target_maxslots. A client using a slot in the range [se_target_maxslots, maxreqs) can satisfy all three conditions: its slot has the current generation (set by a prior SEQUENCE), and it sends sa_highest_slotid <= se_target_maxslots to acknowledge the reduction. free_session_slots() then kfrees every slot at index >= se_target_maxslots, including the caller's own slot. The function continues to write sl_seqid, sl_flags, sl_generation, and stores the dangling pointer in cstate->slot. Later, nfsd4_store_cache_entry() copies up to maxresp_cached bytes of the compound reply into the freed sl_data[] array, corrupting whatever slab object now occupies that address. Additionally, a concurrent thread processing SEQUENCE on a different high-numbered slot can have its slot freed out from under it. NFSD4_SLOT_INUSE is set under nn->client_lock before the lock is released, so any concurrent thread past SEQUENCE will have its slot marked. However, free_session_slots() does not check NFSD4_SLOT_INUSE before freeing. Fix both problems by: 1. Checking that the current request's slotid is below the shrink boundary. 2. Scanning slots in the to-be-freed range for NFSD4_SLOT_INUSE and deferring the shrink if any are active. Fixes: fc8738c68d0b ("nfsd: add support for freeing unused session-DRC slots") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260526-nfsd4_sequence_shrink_uaf_on_loaded_slot-v2-1-74a89db0639e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 6703199f4d7e7f37d6a726a849eb358e8fae72fb Author: Jeff Layton Date: Tue Jun 2 12:23:13 2026 -0400 nfsd: defer vfree of compound ops to fix rpc_status UAF commit fca26a3fc19ed02278aa2a150af82d43db0302cb upstream. The rpc_status netlink dumpit walks every in-flight svc_rqst under rcu_read_lock and, for NFSv4 requests, reads opnums out of args->ops[]. But args->ops is a separate vmalloc buffer freed synchronously by vfree() in nfsd4_release_compoundargs() at the end of every compound. The dumpit's rcu_read_lock pins the svc_rqst struct itself (freed via kfree_rcu), but nothing defers the vfree of the ops buffer across the RCU grace period. A concurrent compound completion can therefore free the buffer while the dumpit is reading it — a use-after-free on vmalloc memory. The trailing seqcount recheck (smp_load_acquire of rq_status_counter) cannot undo a load that already retired against freed memory. Fix by replacing vfree(args->ops) with kvfree_rcu_mightsleep(), which defers the free until after an RCU grace period. This makes the existing rcu_read_lock in the dumpit sufficient to protect the read. The tradeoff is that completed compound ops buffers (up to 200 * sizeof(struct nfsd4_op)) persist in memory slightly longer, across one grace period, before being reclaimed. Fixes: bd9d6a3efa97 ("NFSD: add rpc_status netlink support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260602-nfsd-testing-v2-1-e4ea62e3cd5c@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 631b7d5dbbba8c40422f7c1d4158d9c63c751c48 Author: Jeff Layton Date: Tue May 26 12:38:45 2026 -0400 nfsd: defer setting NFSD4_CALLBACK_RUNNING in deleg_reaper commit 108969960dc54de673869814c5f37c22f6cf404a upstream. deleg_reaper() sets NFSD4_CALLBACK_RUNNING before checking the 5-second rate limit and cl_cb_state gates. When either gate fires the loop continues without queuing callback work, so the bit's only clear site in nfsd41_destroy_cb() is never reached and RECALL_ANY dispatch is permanently disabled for the affected client. Move the test_and_set_bit() below both non-queueing gates so the bit is taken only when nfsd4_run_cb() will be called. Fixes: 424dd3df1f99 ("nfsd: eliminate cl_ra_cblist and NFSD4_CLIENT_CB_RECALL_ANY") Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260526-cb_recall_any_callback_running_stuck-v1-1-310011a028f3@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit e879148867bd4c4cac42e063ffaffa187dddc6fe Author: Jeff Layton Date: Thu Jun 11 16:00:44 2026 -0400 nfsd: clear opcnt on compound arg release to prevent OOB read commit ae4c38555e81563b8dc5eae55ffd70f0ea97aa5a upstream. nfsd4_release_compoundargs() resets args->ops to the inline iops[8] array when the dynamically-allocated ops buffer is freed, but leaves args->opcnt at its original value (which can be up to 200 for NFSv4.1+ compounds). If rq_status_counter is stuck at an odd value (which can happen when nfsd_dispatch() hits an error path after setting it odd), the RPC status dumpit handler reads min(opcnt, 16) entries from args->ops[]. Since iops only has 8 elements and is the last field in struct nfsd4_compoundargs, reading indices 8-15 accesses adjacent slab memory and leaks it to userspace via netlink. Zero opcnt unconditionally in nfsd4_release_compoundargs() so stale compound metadata is never exposed through the status interface. Fixes: bd9d6a3efa97 ("NFSD: add rpc_status netlink support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton [ cel: Remove the kvfree_rcu_mightsleep() sleep from the exposure window ] Link: https://patch.msgid.link/20260611-nfsd-testing-v2-1-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit b137930ee52e3ef38915a3511d4c070463b63a32 Author: Jeff Layton Date: Tue May 26 12:38:46 2026 -0400 nfsd: clear CALLBACK_RUNNING on failed delegation recall queue commit b036727d334b1b7cd4c1f1fba3b59ba93a6bbe96 upstream. nfsd_break_one_deleg() sets NFSD4_CALLBACK_RUNNING via test_and_set_bit at entry to serialize recall work, then calls nfsd4_run_cb() to queue the recall. When the queue attempt fails the refcount bump is undone, but the RUNNING bit is left set. The only site that clears the bit is nfsd41_destroy_cb() (fs/nfsd/nfs4callback.c), which runs from the workqueue and is therefore unreachable when nothing was queued. The bit becomes a permanent latch on dp->dl_recall.cb_flags: every subsequent break_lease() on the same delegation hits the early-return guard in nfsd_break_one_deleg() and silently skips the recall, so the delegation is never broken and the conflicting open or lock stalls. Fix by clearing NFSD4_CALLBACK_RUNNING on the !queued branch alongside the refcount_dec. Fixes: 1054e8ffc5c4 ("nfsd: prevent callback tasks running concurrently") Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260526-cb_recall_any_callback_running_stuck-v1-2-310011a028f3@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit b42dc26a14b4ad5d6daaada11ec4c70744141c25 Author: Jeff Layton Date: Fri Jul 10 10:00:09 2026 -0400 nfsd: check client ownership when cancelling a copy-notify stateid commit 6bdbfab96e0cf25e5f57dac5c09dc1749751a4bf upstream. On the OFFLOAD_CANCEL path (clp != NULL), manage_cpntf_state() freed the target cpntf state without checking ownership. The lookup key st->si_opaque.so_id is allocated cyclically (guessable) and the embedded clientid is the fixed per-net nn->s2s_cp_cl_id, so any authenticated NFSv4.2 client could cancel and free another client's copy-notify stateid. Compare the creating clientid recorded in state->cp_p_clid against the requesting client's cl_clientid and return nfserr_bad_stateid on a mismatch instead of freeing the entry. Fixes: ce0887ac96d3 ("NFSD add nfs4 inter ssc to nfsd4_copy") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260710-nfsd-testing-v3-5-a0ff7db6aa3e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 311f7d926630940650447cbd1c932b076b40a6c4 Author: Jeff Layton Date: Wed May 27 10:53:37 2026 -0400 nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref commit c59738a00aa51b16adc1b5ceb7c80877168efb4d upstream. When CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return success with fh_dentry and fh_export both NULL if fh_verify() returns nfserr_stale and putfh->no_verify is true. The NFSD4_FH_FOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserr_nofilehandle check -- it does not prevent subsequent ops from running with a NULL fh_dentry. A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes check_if_stalefh_allowed() to set no_verify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fh_want_write() which dereferences fh_export->ex_path.mnt without calling fh_verify() first, causing a NULL pointer dereference in the nfsd kthread. Fix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set and fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow) and ops with ALLOWED_WITHOUT_FH (which don't need a resolved filehandle) may proceed. All other ops receive nfserr_stale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERR_STALE returned at that point. Fixes: b9e8638e3d9e ("NFSD: allow inter server COPY to have a STALE source server fh") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260527-putfh_foreign_fh_null_deref_consumers-v1-1-1b8a5aa28c59@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 1aea0482b98ecd7d0249204665f2ad4ad517f66b Author: Jeff Layton Date: Thu Jun 11 16:00:45 2026 -0400 nfsd: add missing read barrier to rpc_status_get dumpit seqcount retry commit a71f161a857117e8e0264deb7d14fff5c98adcf5 upstream. The hand-rolled seqcount-like protocol in nfsd_nl_rpc_status_get_dumpit() is missing a read memory barrier (smp_rmb) before its second counter check. The standard kernel read_seqcount_retry() includes smp_rmb() to ensure that all data reads complete before the counter is re-checked. Without this barrier, on weakly-ordered architectures (ARM, POWER), the CPU may reorder field reads past the second counter check, making the retry logic ineffective: it could observe a consistent counter pair while reading fields that have been concurrently modified by the writer. Add smp_rmb() before the second counter check to order the field reads ahead of it, matching the barrier semantics of the standard seqcount read-side. The begin-side smp_load_acquire() already pairs with the smp_store_release() in nfsd_dispatch(); with the smp_rmb() now ordering the field reads, the retry check no longer needs acquire semantics and reads the counter with a plain READ_ONCE(), as read_seqcount_retry() does. Fixes: bd9d6a3efa97 ("NFSD: add rpc_status netlink support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton [ cel: Use READ_ONCE instead of smp_load_acquire() ] Link: https://patch.msgid.link/20260611-nfsd-testing-v2-2-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit bff024551a713d57efacf61391030fd9af0daaa4 Author: Jeff Layton Date: Thu Jun 11 16:00:49 2026 -0400 nfsd: add filehandle match check to nfsd4_delegreturn() commit 04cce9d79f2b1a114f7128e08bf60a473e10f1ec upstream. nfsd4_delegreturn() is the only stateful NFSv4 operation that does not call nfs4_check_fh() to verify the delegation's file matches cstate->current_fh. A client can DELEGRETURN with a mismatched filehandle, destroying the correct delegation but waking the wrong inode's waiters. Add the missing nfs4_check_fh() call after the generation check. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-6-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 533964d420d385e11b08dd4c56c66ef5dcccaf08 Author: Jeff Layton Date: Thu Jun 11 16:00:54 2026 -0400 nfsd: add fh_want_write() for early-verified SETATTR in nfsd_proc_setattr() commit 4e475be769aa9f7a2c1ce55a2b8592cfccacddcc upstream. The BOTH_TIME_SET branch calls fh_verify() early so setattr_prepare() can inspect the dentry. This causes nfsd_setattr() to skip fh_want_write(), so notify_change() runs without a mount write reference. Add the missing fh_want_write() call after the early fh_verify(). Fixes: cc265089ce1b ("nfsd: Disable NFSv2 timestamp workaround for NFSv3+") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-11-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 895a485cd3758031ef9993c0d53cf19ce8fb4ccc Author: Jeff Layton Date: Sat May 30 09:19:25 2026 -0400 nfsd: validate symlink target length in NFSv4 CREATE commit 041f57056e5fb9c80adc088269322d2c61074406 upstream. nfsd4_decode_create() accepts an unbounded cr_datalen from the wire for NF4LNK symlink targets, allowing a client to force a kmalloc of up to the maximum RPC payload size (several MiB) per COMPOUND op that persists until compound teardown. The VFS rejects oversized targets with ENAMETOOLONG, but the allocation has already occurred. Reject cr_datalen == 0 early with nfserr_inval and cr_datalen greater than NFS4_MAXPATHLEN (PATH_MAX) with nfserr_nametoolong to bound the allocation. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Reported-by: Chris Mason Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260530-nfsd-fixes-v2-9-f27e8eb4d974@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 2aca70c18c5f5d06004122861fb151d5fcc57faf Author: Jeff Layton Date: Mon Jun 15 14:31:25 2026 -0400 nfsd: validate sockaddr length per family in listener_set commit bdcc85c2b05a9378d8bd2d65f9fc41440a3cf464 upstream. nfsd_sock_nl_policy declares NFSD_A_SOCK_ADDR as a bare NLA_BINARY attribute with no minimum length. A CAP_NET_ADMIN caller can send a 16-byte NFSD_A_SOCK_ADDR with sa_family=AF_INET6, causing a 12-byte OOB read across three consumers (rpc_cmp_addr_port, svc_find_listener, kernel_bind). nfsd_nl_listener_set_doit() also parsed and validated each listener entry inline in two separate loops, interleaved with mutating the running listener configuration. The validation was duplicated, used an open-coded "nla_len < sizeof(struct sockaddr)" check that was too short for AF_INET6, and handled a malformed entry inconsistently depending on which loop noticed it. Add an nfsd_nl_validate_listeners() helper that walks the entire list once and confirms each entry parses, carries both an address and a transport name, and is long enough for its address family (sizeof(struct sockaddr_in) for AF_INET, sizeof(struct sockaddr_in6) for AF_INET6, -EAFNOSUPPORT otherwise). Call it before taking nfsd_mutex or creating the serv, so a malformed request fails cleanly with no side effects. Since every entry is known valid by the time the two existing loops run, drop the redundant presence and per-family length checks from both, leaving only the nla_parse_nested() call needed to extract the data. Fixes: 16a471177496 ("NFSD: add listener-{set,get} netlink command") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260615-nfsd-testing-v5-1-188d75aedda0@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 7e7b93da7fa2e77f977096251899d1410986adf6 Author: Jeff Layton Date: Thu Jun 11 16:00:50 2026 -0400 nfsd: validate nseconds in TIME_DELEG decode paths commit 0f4a767340fad392bd656115b8752005518c9065 upstream. The xdrgen-based TIME_DELEG_ACCESS and TIME_DELEG_MODIFY decode arms store a raw uint32_t nseconds directly into tv_nsec without enforcing nseconds < NSEC_PER_SEC. The legacy nfsd4_decode_nfstime4 has this check but the TIME_DELEG paths do not. A malformed timespec can propagate through notify_change() to disk. Add range checks in both nfs4xdr.c (SETATTR path) and nfs4callback.c (CB_GETATTR path). Fixes: 6ae30d6eb26b ("nfsd: add support for delegated timestamps") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-7-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 7ff8d6363cffff45654ea85e319f7c0c54226012 Author: Chris Mason Date: Sun May 31 08:06:58 2026 -0400 nfsd: size fh_verify server sockaddr slot by xpt_locallen commit 71d068490098b1d23c63b2345e40675d3a1ca763 upstream. The nfsd_fh_verify and nfsd_fh_verify_err tracepoints declare the server sockaddr slot sized by xpt_remotelen but fill it from xpt_local using xpt_locallen: TP_STRUCT__entry( ... __sockaddr(server, rqstp->rq_xprt->xpt_remotelen) ... ) TP_fast_assign( ... __assign_sockaddr(server, &rqstp->rq_xprt->xpt_local, rqstp->rq_xprt->xpt_locallen); ... ) When xpt_locallen exceeds xpt_remotelen, __assign_sockaddr's memcpy writes past the reserved ring-buffer slot. In the reverse direction (xpt_locallen < xpt_remotelen) the slot is oversized and the unwritten tail leaks prior ring-buffer contents to trace consumers. The write-past-end case is reachable on NFS/UDP. svc_xprt_set_remote() is only called from svc_tcp_accept() (net/sunrpc/svcsock.c) and from the RDMA connect path; svc_create_socket() for UDP calls only svc_xprt_set_local(), so xpt_remotelen stays 0 for the xprt's lifetime. Every fh_verify trace for an NFSv2/v3-over-UDP request then copies 16 or 28 bytes from xpt_local into a zero-byte slot. The other NFSD tracepoints that record the server address (NFSD_TRACE_PROC_CALL_FIELDS, NFSD_TRACE_PROC_RES_FIELDS, SVC_RQST_ENDPOINT_FIELDS) already size the server slot by xpt_locallen; nfsd_fh_verify and nfsd_fh_verify_err were the only exceptions. Fix by sizing the server slot with xpt_locallen so the declared slot matches the copy length. The client slot and its assignment already agree on xpt_remotelen and are left untouched. Fixes: 051382885552 ("NFSD: Instrument fh_verify()") Fixes: 948755efc951 ("NFSD: Replace dprintk() call site in fh_verify()") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Chris Mason Link: https://patch.msgid.link/20260531-nfsd-testing-v1-1-7bfa481b0540@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 1e4795766719ffd74b8cf0f2fde4a1350f8326bf Author: Zhenghang Xiao Date: Tue May 26 18:45:54 2026 +0800 nfsd: set SC_STATUS_FREED in nfsd4_drop_revoked_stid for delegations commit 650d370cfbc66a96dd14d517bd704689b5bda4e5 upstream. nfsd4_drop_revoked_stid() handles FREE_STATEID for admin-revoked delegations but does not set SC_STATUS_FREED before releasing cl_lock. revoke_delegation() uses this flag to detect whether FREE_STATEID has already processed the delegation -- without it, the freed delegation is added to cl_revoked via list_add(), producing a use-after-free when cl_revoked is later traversed in __destroy_client(). The SC_STATUS_REVOKED path in nfsd4_free_stateid() (line 7983) already sets SC_STATUS_FREED correctly. Apply the same pattern to the SC_STATUS_ADMIN_REVOKED path in nfsd4_drop_revoked_stid(). Fixes: 8dd91e8d31fe ("nfsd: fix race between laundromat and free_stateid") Cc: stable@vger.kernel.org Signed-off-by: Zhenghang Xiao Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260526104554.46262-1-kipreyyy@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 8277d4a11ae2cb5495842be558fd946032c24363 Author: Chuck Lever Date: Fri May 22 17:45:58 2026 -0400 nfsd: sample writeback error cursor before async COPY loop commit 20a67a7d18221af736f124770c2c5e859b479046 upstream. _nfsd_copy_file_range() samples dst->f_wb_err into "since" after the copy loop, then uses it to detect writeback errors via filemap_check_wb_err() once vfs_fsync_range() returns. Because the nfsd_file cache reuses a single struct file across requests targeting the same inode, a concurrent COMMIT or stable WRITE on dst advances dst->f_wb_err to the current mapping->wb_err via file_check_and_advance_wb_err() during its own vfs_fsync_range(). If that advancement lands between the writeback error appearing in mapping->wb_err and the COPY worker sampling "since", the worker captures the already-advanced cursor, errseq_check() sees cur == since and returns zero, and NFSD4_COPY_F_COMMITTED is set even though writeback failed. CB_OFFLOAD then encodes wr_stable_how = FILE_SYNC4, the client treats the copied data as durable, and the failure becomes silent data loss. Sample since once at the start of the function. The cursor then reflects state in effect before this COPY issues any writes, and filemap_check_wb_err() detects any error that occurs during the copy regardless of which thread first observes it. This matches the pattern used by nfsd_vfs_write() and nfsd4_clone_file_range(). Closes: https://sashiko.dev/#/patchset/20260522194441.436065-1-cel@kernel.org?part=1 Fixes: 555dbf1a9aac ("nfsd: Replace use of rwsem with errseq_t") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260522214558.460859-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit fc83f30731dd266b64f1bce9657256fa70b15330 Author: Jeff Layton Date: Fri Jul 10 10:00:11 2026 -0400 nfsd: return NFS4ERR_NOTSUPP for unsupported netloc4 types commit 45b06a75086f331f52cbb81223a59421d43f8809 upstream. nfsd4_decode_nl4_server() handled only NL4_NETADDR and returned nfserr_bad_xdr for NL4_NAME and NL4_URL. Those forms are well-formed XDR, so BADXDR is misleading -- the request is unsupported, not malformed. Decode and discard the utf8str_cis for NL4_NAME and NL4_URL to keep the stream consistent, and return nfserr_notsupp. nfsd4_proc_compound() honors a decode-time op->status, so the op fails without executing. Fixes: 84e1b21d5ec4 ("NFSD add ca_source_server<> to COPY") Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260710-nfsd-testing-v3-7-a0ff7db6aa3e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 591134e059e3456180244a826d6917cdc183140b Author: Chuck Lever Date: Fri May 22 16:37:23 2026 -0400 nfsd: Reset write verifier when async COPY writeback fails commit f5cb2276954cb80987a93ef9f9dfbfdbfc0f10b9 upstream. Async COPY captures nn->writeverf at request time and reports it to the client via CB_OFFLOAD after the worker kthread completes. When the post-copy vfs_fsync_range() or filemap_check_wb_err() in _nfsd_copy_file_range() reports an error, the worker correctly leaves NFSD4_COPY_F_COMMITTED clear so that CB_OFFLOAD encodes wr_stable_how as NFS_UNSTABLE, but the server's write verifier is not rotated. A client that receives NFS_UNSTABLE in CB_OFFLOAD follows up with COMMIT to make the copied data durable. With the verifier unchanged, COMMIT returns the same value the client just received via CB_OFFLOAD, and the client concludes the copy is durable -- silently dropping the data whose writeback in fact failed. This violates the UNSTABLE+COMMIT durability contract (RFC 7862 section 15.1, RFC 8881 section 18.32) and matches the bug just fixed in nfsd_vfs_write() and nfsd_commit(). Rotate nn->writeverf at the writeback-failure site. The async COPY worker has no svc_rqst, so commit_reset_write_verifier() is not available here; calling nfsd_reset_write_verifier() directly mirrors the trace-less reset already used by nfsd_file_check_write_error() for the same purpose. Filter out -EAGAIN and -ESTALE, matching commit_reset_write_verifier(), since neither indicates a durable-storage failure. Fixes: eac0b17a77fb ("NFSD add vfs_fsync after async copy is done") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260522203723.446841-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 467d56fd3ff57447a790c6dc3ede2d02a947d224 Author: Chris Mason Date: Sun May 31 08:06:59 2026 -0400 nfsd: release path refs on follow_down() error commit 6cba08dc1922140d260cfeb30bbda4ee1bf869d8 upstream. nfsd_cross_mnt() initializes a local struct path with mntget() and dget() before calling follow_down(). On a negative return the error arm jumps to out without releasing those references: err = follow_down(&path, follow_flags); if (err < 0) goto out; follow_down() never drops the caller's entry-time refs on any error sub-case; for example a pre-cross d_manage() failure leaves path untouched, so the mntget()/dget() taken on entry survive the call. Every other early-exit arm in nfsd_cross_mnt() (other-namespace return, IS_ERR(exp2), and the success tail after the swap) already calls path_put(&path); the err < 0 arm is the lone omission. The leak inflates mnt_count and d_count on each failed cross-mount, blocking umount and pinning dentries against the shrinker, and is reachable by any authenticated NFS client through nfsd_lookup_dentry or the NFSv4 READDIR encode path. Fix by calling path_put(&path) before the goto out in the err < 0 arm so the entry-time refs are released on all follow_down() error returns. Fixes: cc53ce53c869 ("Add a dentry op to allow processes to be held during pathwalk transit") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Chris Mason Link: https://patch.msgid.link/20260531-nfsd-testing-v1-2-7bfa481b0540@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f164eb52b6f3cbf40f07fe379f9f421f88e02f76 Author: Jeff Layton Date: Sat May 30 09:19:18 2026 -0400 nfsd: RCU-protect cl_cb_session to fix use-after-free on session teardown commit 01c5d5f58a5db9b0ee5afba2e49d3157788687b2 upstream. After a DESTROY_SESSION the per-session teardown path can free a session while rpciod still holds an inflight callback rpc_task that dereferences clp->cl_cb_session. nfsd4_probe_callback_sync() flushes cl_callback_wq, but once nfsd4_run_cb_work() has called rpc_call_async() the rpc_task lives on rpciod; flushing the workqueue does not wait for it. rpc_shutdown_client() does drain rpciod tasks, but uses a 1-second wait_event_timeout — tasks stuck in rpc_delay() (e.g. 2-second NFS4ERR_DELAY retries) can outlive the drain. destroy path rpciod ------------ ------ unhash_session(ses) nfsd4_probe_callback_sync(clp) flush_workqueue(cl_callback_wq) /* returns; rpc_task still live */ nfsd4_put_session_locked(ses) free_session(ses) -> kfree(ses) nfsd4_cb_sequence_done() reads cb_clp->cl_cb_session /* freed slab */ A second window exists in nfsd4_process_cb_update(). When __nfsd4_find_backchannel() returns NULL because unhash_session() has already removed the destroyed session from cl_sessions, setup_callback_client() takes the v4.1 early return so clp->cl_cb_session = ses never fires and the field retains a pointer to the about-to-be-freed session. Fix both by converting cl_cb_session to an RCU-protected pointer: - Move the cl_cb_session = ses assignment in setup_callback_client() to after rpc_create() succeeds, so it is only published when a working backchannel exists. Clear cl_cb_session on the error return in nfsd4_process_cb_update(). Both stores use rcu_assign_pointer(). - Annotate cl_cb_session with __rcu. All rpciod-side readers use rcu_read_lock()/rcu_dereference() and check for NULL, bailing to the appropriate error or requeue path: encode_cb_sequence4args(), decode_cb_sequence4resok(), nfsd41_cb_get_slot(), nfsd41_cb_release_slot(), nfsd4_cb_prepare(), and nfsd4_cb_sequence_done(). - Switch __free_session() from kfree() to kfree_rcu() so the session slab is not reclaimed until after an RCU grace period, guaranteeing that rpciod readers inside rcu_read_lock() never dereference freed memory. - Pass the session pointer to the nfsd_cb_seq_status and nfsd_cb_free_slot tracepoints instead of having them re-read cl_cb_session. - nfsd4_cb_prepare() calls rpc_exit() when the session is NULL, routing through the done/release path to requeue the callback. Fixes: dcbeaa68dbbd ("nfsd4: allow backchannel recovery") Cc: stable@vger.kernel.org Reported-by: Chris Mason Signed-off-by: Chris Mason Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260530-nfsd-fixes-v2-2-f27e8eb4d974@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit dc803d46a8b90658788435c2f5dfa25a75123d00 Author: Tim Menninger Date: Wed Aug 19 12:41:21 2026 +0000 pNFS: Fix EBUSY check in pnfs_layout_need_return commit 20358201777496fd0bb7b4336fcb4d3fc13cad28 upstream. Commit 41d0a8ead9720 ("NFSv4/pnfs: Add support for the PNFS_LAYOUT_FILE_BULK_RETURN flag") replaced pnfs_layout_segments_returnable() in pnfs_layout_need_return() with a direct call to pnfs_mark_layout_stateid_return(). The old helper checked the return value against -EBUSY, but the replacement compares against EBUSY. Since pnfs_mark_layout_stateid_return() returns negative errno values, the -EBUSY case is never detected. Fix the comparison in pnfs_layout_need_return() to check against -EBUSY. Fixes: 41d0a8ead9720 ("NFSv4/pnfs: Add support for the PNFS_LAYOUT_FILE_BULK_RETURN flag") Cc: stable@vger.kernel.org Signed-off-by: Tim Menninger Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 36e3f13bf0728f4ce11ee8904cec82a783222f62 Author: Junrui Luo Date: Sun Aug 16 16:01:29 2026 +0800 NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget path commit ee5a386cfe60f3f8286de16a9db8e1a08f0bc124 upstream. When the server returns a new layout stateid while a valid one is still held, pnfs_layout_process() calls pnfs_mark_matching_lsegs_return() on the on-stack free_me list and jumps to out_forget. Segments whose reference count drops to zero are unlinked from lo->plh_segs and moved to free_me by mark_lseg_invalid(); for an idle cached segment the layout header holds the only reference, so this happens on the first decrement. out_forget never drains free_me -- only the success path calls pnfs_free_lseg_list(). Commit 814b84971388 ("pNFS/NFSv4: Fix a layout segment leak in pnfs_layout_process()") added the drain; commit 08bd8dbe8882 ("pNFS/NFSv4: Try to return invalid layout in pnfs_layout_process()") removed it while switching the destination to lo->plh_return_segs, which is drained elsewhere. Commit fb700ef02676 ("NFSv4.1: Simplify layout return in pnfs_layout_process()") switched the destination back to free_me without restoring the drain. Restore the pnfs_free_lseg_list() call. Fixes: fb700ef02676 ("NFSv4.1: Simplify layout return in pnfs_layout_process()") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 59baf45a06435194005fc5fa9a42d89f77a30432 Author: Chris Mason Date: Tue Jun 2 12:23:16 2026 -0400 nfsd: guard nfsd_serv deref in nfsd_file_net_dispose commit 9f1ddfc8cb9076592401a611eb3a44d36186d014 upstream. nfsd_file_net_dispose() is the consumer side of l->freeme: the nfsd service thread loop calls it to drain entries that the filecache garbage collector and shrinker append via nfsd_file_dispose_list_delayed(). During per-net teardown, nn->nfsd_serv is cleared before the filecache laundrette is shut down, so the service thread can still run a dispose pass that finds more than eight entries on l->freeme and dereferences a NULL svc_serv: nfsd service thread loop nfsd_file_net_dispose(nn) if (!list_empty(&l->freeme)) { ... svc_wake_up(nn->nfsd_serv); /* nn->nfsd_serv == NULL */ } The sibling helper nfsd_file_dispose_list_delayed() already documents this ordering and caches nn->nfsd_serv into a local before testing it for NULL. nfsd_file_net_dispose() was introduced with the same raw svc_wake_up(nn->nfsd_serv) call and never picked up the guard. Fix by loading nn->nfsd_serv into a local svc_serv pointer and only calling svc_wake_up() when it is non-NULL, matching the pattern in nfsd_file_dispose_list_delayed(). Fixes: ffb402596147 ("nfsd: Don't leave work of closing files to a work queue") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Chris Mason Link: https://patch.msgid.link/20260602-nfsd-testing-v2-4-e4ea62e3cd5c@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 7ef182a8fe9c12b0d936880b1e504840639aa009 Author: Mike Snitzer Date: Fri Jun 12 15:14:10 2026 -0400 NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check commit aa0cf48a448c5a9fe1a1e880899ecd589ce39e6e upstream. The header for commit e75b23f9e323 ("nfsd: check d_can_lookup in fh_verify of directories") details the assumption that justified adding the WARN_ON_ONCE to nfsd_mode_check(), that assumption is invalid (in the case of NFS reexport). When NFSD exports an NFS filesystem it is very possible for nfsd_mode_check() to encounter a @dentry that doesn't have i_op->lookup (see nfs_fhget()'s NFS_ATTR_FATTR_MOUNTPOINT and NFS_ATTR_FATTR_V4_REFERRAL handling, and d_flags_for_inode()). So remove nfsd_mode_check()'s WARN_ON_ONCE(). The nfserr_notdir return on that branch must stay. It guards the subsequent lookup_one_unlocked() -> __lookup_slow() path, which calls inode->i_op->lookup() with no NULL check, so returning nfserr_notdir is what keeps a client LOOKUP into such a @dentry from dereferencing a NULL method pointer. Fixes: e75b23f9e323 ("nfsd: check d_can_lookup in fh_verify of directories") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Link: https://patch.msgid.link/20260612191410.50177-1-snitzer@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 4ed8d2317aef21cc2a9e5a55d6b59860b4b151a8 Author: Michael Bommarito Date: Sun May 24 09:06:54 2026 -0400 NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock commit 036c1b182f4da65363e79ec0ac276edc6b7296e5 upstream. nfsd4_ssc_expire_umount() walks nn->nfsd_ssc_mount_list with list_for_each_entry_safe(ni, tmp, ...). For each expired entry it sets nsui_busy = true, drops nfsd_ssc_lock to run mntput() on the source vfsmount, then reacquires the lock to list_del + kfree the entry and continue iterating via the macro's saved tmp pointer. The nsui_busy flag protects the current ni from concurrent nfsd4_ssc_setup_dul() finders during the lock-drop window, but it does not pin tmp. Another nfsd RPC thread that fails its source- server mount and reaches nfsd4_ssc_cancel_dul() will, during that same window, take nfsd_ssc_lock, list_del + kfree its own ssc_umount item, and release the lock. If that item is the saved tmp of the expire walk, the next iteration dereferences a freed nfsd4_ssc_umount_item. Restart the walk from the head after the mntput() unlock window so no saved next pointer survives the lock-drop. The list is bounded by the number of active inter-server source mounts (typically small) and the expire delayed-work runs periodically rather than per-IO, so the restart is cheap. Fixes: f4e44b393389 ("NFSD: delay unmount source's export after inter-server copy completed.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260524130654.1924556-1-michael.bommarito@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 75d13317f163a9b38e3b9a3d3c034257fb837b40 Author: Chuck Lever Date: Thu Jul 16 20:12:28 2026 -0400 NFSD: Fix off-by-one in DRC bucket pruning limit commit d0728723c80dcb3432effd67c7e919b596004b1d upstream. nfsd_prune_bucket_locked() evicts an entry before checking the freed count against @max. The check uses "++freed > max", which does not break until freed exceeds max, resulting in max + 1 evictions. Use ">=" so the limit stated in the function comment is honored. Fixes: a9507f6af145 ("NFSD: Replace nfsd_prune_bucket()") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Link: https://patch.msgid.link/20260717001232.438792-2-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit e547b06234f88ea180bb0706e5036a2ea556901e Author: Chuck Lever Date: Sun Jul 12 11:09:11 2026 -0400 NFSD: Encode only the status in NFS-ACL v2 GETACL error replies commit ed4edddad19babf76b56882ad9600f5646b167a0 upstream. The NFSv2 ACL GETACL reply is a union that carries file attributes and ACL data only when the status is NFS_OK. All error cases are void results. However, currently the NFSv2 ACL GETACL result encoder decides whether to append the "OK" body by testing only whether the file handle resolved to a positive dentry, not the actual reply status. A GETACL request that resolves its file handle but then fails for another reason (an unsupported mask value, a getattr failure, or an ACL retrieval error) therefore appends file attributes and ACL data after the error status on the wire. Worse, when the mask is rejected, fh_getattr() hasn't been called at all, so those attributes are serialized from a zero-filled kstat and are junk. The logic before the xdr_stream conversion used the reply status. Revert to that approach (but keep the xdr_stream conversion in place). Fixes: f8cba47344f7 ("NFSD: Update the NFSv2 GETACL result encoder to use struct xdr_stream") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260712150911.48461-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit d8352da196349182e1afd5a93308256cddc0a97d Author: Chuck Lever Date: Sat May 30 09:19:22 2026 -0400 NFSD: check truncate permission under inode lock commit b778e0e0a16759f22a70579c3cf8d254a40d4a7f upstream. nfsd_setattr() checks whether a size update needs NFSD_MAY_TRUNC before it takes inode_lock(). The comparison uses the file size sampled by that unlocked read, but the actual ATTR_SIZE update is applied later under inode_lock() by notify_change(). This leaves a TOCTOU window for append-only files. If a client sends a SETATTR that does not shrink the file at the time of the unlocked sample, a concurrent append can extend the file before nfsd_setattr() takes inode_lock(). notify_change() then applies a real truncation without the NFSD_MAY_TRUNC check that rejects IS_APPEND(inode). The VFS truncate syscall paths perform their own append-only checks before calling notify_change(), so NFSD must make this decision against the locked size it is about to change. Split the write-count acquisition from the truncation permission check. Keep get_write_access() before the locked setattr work, then recheck whether the requested size is below i_size_read(inode) after inode_lock() has been acquired and before notify_change(ATTR_SIZE). This also avoids the plain unlocked inode->i_size load. Fixes: 783112f7401f ("nfsd: special case truncates some more") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Reported-by: Chris Mason Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260530-nfsd-fixes-v2-6-f27e8eb4d974@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f3adf1643517357221422c05986d6de5df7b9913 Author: Nate Prodromou Date: Tue Jul 14 18:58:46 2026 +0000 NFS: fix delegation_hash_table leak when nfs4_server_common_setup() fails commit 2092f5b38f88be306140c77aeeeb43fc1adacacc upstream. nfs4_server_common_setup() allocates server->delegation_hash_table first, but server->destroy - the only path that frees the table via nfs4_destroy_server() - is not assigned until the very end of the function. If any intermediate step fails (the is_ds_only_client() check, nfs4_init_session(), nfs4_get_rootfh(), or nfs_probe_server()), the function returns with server->destroy still NULL, so the caller's nfs_free_server() skips the destroy callback and the hash table is leaked (4 KiB per attempt with the default delegation watermark). This is trivially reachable from userspace: every failed NFSv4 mount leaks one allocation. A client that persistently retries a mount that cannot succeed leaks kernel memory without bound. Observed in production where a Longhorn backup poller retried mount.nfs4 against an NFSv3-only server roughly 10 times per second, leaking ~3.4 GiB of unreclaimable slab (kmalloc-rnd-13-4k) per day; the node accumulated 12 GiB of leaked slab before the source was identified via the kmem:kmalloc tracepoint (call_site=nfs4_delegation_hash_alloc). Reproducer: # server exports NFSv3 only (or export path absent for v4) while :; do mount -t nfs4 :/missing /mnt; done # watch SUnreclaim in /proc/meminfo grow 4 KiB per iteration Free the table on the error paths between the allocation and the assignment of server->destroy. Fixes: f5b3108e6a14 ("NFS: use a hash table for delegation lookup") Cc: stable@vger.kernel.org Signed-off-by: Nate Prodromou Reviewed-by: Christoph Hellwig Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 5215e734bf7cba18237155f8cb2a0accb60ca339 Author: Chris Mason Date: Tue Jun 2 12:23:15 2026 -0400 NFS/localio: fix ref leak on nfs_uuid_add_file failure commit ca018c19e0ba38975e5ddc3ef8117d5b734313aa upstream. When nfs_uuid_add_file() races with nfs_uuid_put() tearing down uuid->net, it returns -ENXIO without publishing nfl->nfs_uuid via rcu_assign_pointer(). nfs_open_local_fh() then enters its error branch and only releases the slot's file ref and its paired net ref plus its own entry-time net ref, while the close path is a no-op: nfs_close_local_fh() nfs_uuid = rcu_dereference(nfl->nfs_uuid); if (!nfs_uuid) { rcu_read_unlock(); return; } /* always */ nfsd_open_local_fh() returns localio holding a caller-owned +1 nfsd_file reference (from nfsd_file_get() after nfsd_file_acquire_local()) and an entry-time nfsd_net reference (from its first nfsd_net_try_get()) embedded as nf->nf_net. Both are leaked on the failure path, pinning one nfsd_file (and the underlying struct file, dentry, inode) and one nfsd_net_ref per occurrence, which blocks nfsd_net and netns teardown. Fix by releasing the caller-owned file ref and its net ref through the existing helper, using a stack-local RCU pointer so the helper can xchg it out, then returning -ENXIO so callers do not dereference a localio whose slot has been cleared: struct nfsd_file __rcu *tmp = RCU_INITIALIZER(localio); nfs_to_nfsd_file_put_local(pnf); nfs_to_nfsd_file_put_local(&tmp); localio = ERR_PTR(-ENXIO); The trailing nfs_to_nfsd_net_put(net) continues to release the outer net ref, so all three nfsd_net_try_get() increments are balanced on the error branch. Fixes: fdd015de7679 ("NFS/localio: nfs_uuid_put() fix races with nfs_open/close_local_fh()") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Chris Mason Link: https://patch.msgid.link/20260602-nfsd-testing-v2-3-e4ea62e3cd5c@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 344ae0e232d4f9089387048ed54870be274aa0a4 Author: Longlong Xia Date: Sun Aug 9 19:55:18 2026 +0800 zsmalloc: account for handle size in class lookup commit f7bf5cd5b5f2b13fe2361860880c4e214c08b440 upstream. zs_lookup_class_index() lets zram recompression decide whether a newly compressed object would use a smaller size class. It currently classifies the payload size directly, while zs_malloc() adds ZS_HANDLE_SIZE before selecting the class. This makes lookup disagree with allocation near size-class boundaries. With 4 KiB pages, CONFIG_ZSMALLOC_CHAIN_SIZE=8, and 64-bit handles, a 1025-to-1024-byte recompression appears to move from class 64 to class 62 although both allocations use class 64. Conversely, a 1049-to-1025-byte recompression appears to stay in class 64 although the allocations move from class 65 to class 64. As a result, zram can accept replacements with no allocation benefit or reject ones that would save memory, potentially marking the object incompressible. Factor size-class selection into lookup_size_class(), account for the handle there, and use the helper for both lookup and allocation. Link: https://lore.kernel.org/20260809115518.3791787-1-xialonglong2025@163.com Fixes: 7c2af309abd2 ("zram: add size class equals check into recompression") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Longlong Xia Reviewed-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 923578d0f0d0703c3db61ab35dc37075ae53b0bd Author: Sergey Senozhatsky Date: Wed Jul 29 13:57:36 2026 +0900 zram: validate deflate params commit ec7607ac4717ff521c9c1e9d8271c26293345513 upstream. We must validate user-supplied deflate winbits before we pass it to zlib_deflate_workspacesize(), which triggers BUG_ON() if winbits value is outside of valid ranges. Link: https://lore.kernel.org/20260729045745.775973-3-senozhatsky@chromium.org Fixes: dc75a0d93bd5 ("zram: support deflate-specific params") Link: https://sashiko.dev/#/patchset/20260728092935.31139-1-haoqinhuang7@gmail.com Signed-off-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Haoqin Huang Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a1dc246f98bb94233effa4fa3ec7bf84700bb7d1 Author: Ibrahim Hashimov Date: Fri Jul 24 09:43:27 2026 +0200 ubifs: fix out-of-bounds read in signature length check commit 95d27c1708bb6e8823c8e7c623f9abc2a91bf4bf upstream. ubifs_sb_verify_signature() bounds the on-disk ubifs_sig_node->len field before handing the signature payload to verify_pkcs7_signature(), but the check has the wrong sign: if (le32_to_cpu(signode->len) > snod->len + sizeof(struct ubifs_sig_node)) The signature bytes start sizeof(struct ubifs_sig_node) (UBIFS_SIG_NODE_SZ, 64 bytes) into the node, so the payload is at most snod->len - sizeof(struct ubifs_sig_node) bytes long. Adding the header size instead of subtracting it accepts a declared length up to 2 * UBIFS_SIG_NODE_SZ larger than the node actually holds -- past the end of c->sbuf, which is vmalloc(c->leb_size). verify_pkcs7_signature() -> pkcs7_parse_message() -> asn1_ber_decoder() is then handed that inflated length and reads beyond the allocation while walking the DER headers. The node length comes straight from the mounted image, so a crafted signed UBIFS image reaches this via ubifs_read_superblock() before the signature is cryptographically checked. snod->len is guaranteed to be >= UBIFS_SIG_NODE_SZ by the node scanner (c->ranges[UBIFS_SIG_NODE].min_len == UBIFS_SIG_NODE_SZ), so the corrected subtraction cannot underflow. Legitimately signed images are unaffected: a correct superblock never declares a signature longer than the node it is embedded in. Fixes: 817aa094842d ("ubifs: support offline signed images") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Reviewed-by: Richard Weinberger Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 14afe18655c0951f4f85898f761bf92264e65ccd Author: Jason Yang Date: Tue Aug 11 16:10:22 2026 +0800 phy: rockchip-samsung-dcphy: fix out-of-range max_register commit 4486e75ba647bd8b98fc1f053101b40caceeed4b upstream. The PHY register block is 64KB, so with a register stride of 4 the last accessible register sits at offset 0xfffc. max_register names 0x10000, one register past the end of the mapping: dumping the registers through the regmap debugfs interface reads beyond the ioremapped region and oopses on the unmapped page. The oops fires with the regmap lock held, so later PHY operations deadlock. Fixes: b2a1a2ae7818 ("phy: rockchip: Add Samsung MIPI D-/C-PHY driver") Cc: stable@vger.kernel.org Signed-off-by: Jason Yang Assisted-by: Claude:claude-opus-5 Reviewed-by: Sebastian Reichel Link: https://patch.msgid.link/20260811-dcphy-maxreg-v1-v1-1-aa63f6a63a64@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit e892f05f1f790d5721cd8e3c561ed76da7e08bae Author: Krzysztof Wilczyński Date: Tue Jun 16 16:31:30 2026 +0000 PCI/sysfs: Fix out-of-bounds read in pci_write_legacy_io() commit dc76258d0132df1d831a5a29758bd448ca9c566e upstream. pci_write_legacy_io() loads 4 bytes from the kernfs write buffer regardless of how many bytes userspace wrote: if (count != 1 && count != 2 && count != 4) return -EINVAL; return pci_legacy_write(bus, off, *(u32 *)buf, count); kernfs_fop_write_iter() allocates the buffer with kmalloc(len + 1), so a 1-byte write to the legacy_io sysfs file allocates 2 bytes and the unconditional u32 load reads up to 2 bytes past the end of the allocation, which KASAN reports as a slab-out-of-bounds read. Similarly, a 2-byte write overreads by 1 byte. Thus, read only the number of bytes requested using get_unaligned_le16() and get_unaligned_le32() for the 2 and 4 byte cases, interpreting the buffer as little-endian to match the byte ordering of PCI I/O port space. The PowerPC implementation previously compensated for the generic code's native-endian 32-bit load by shifting the value into place for the 1 and 2 byte cases. The shifts were only correct on big-endian kernels. On little-endian PowerPC (POWER8 and later), they extracted the wrong bytes, so a 1-byte write wrote an out-of-bounds byte instead of the requested value. On big-endian, the native load also caused out_le16() and out_le32() to reverse the user's bytes on the wire for 2 and 4 byte writes. The little-endian helpers resolve both issues, so the shifts are removed. No changes are needed for the Alpha platform. The legacy_io file is root-only and exists only on Alpha and PowerPC, the two architectures that define HAVE_PCI_LEGACY. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260616163131.2763281-1-kwilczynski@kernel.org Signed-off-by: Krzysztof Wilczyński Signed-off-by: Greg Kroah-Hartman commit 9253cfc5a85be1494ce56b4fc6f2d2b509440910 Author: Abdurrahman Hussain Date: Wed Aug 5 13:31:00 2026 -0700 of: fix out-of-bounds read in of_alias_scan() stem parser commit 5bb01c657ff9fc807c2c592ca18af34c4fc3bc6f upstream. The stem parser tests isdigit(*(end - 1)) before checking end > start and so reads one byte before the property name when the name is empty or all digits. Check the bound first. Fixes: 611cad720148 ("dt: add of_alias_scan and of_alias_get_id") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 [Claude Code] Signed-off-by: Abdurrahman Hussain Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260805-nh-of-alias-overlay-v6-1-74f21d440819@nexthop.ai Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 448636c745a3f3b8582a0b8ce718c890a11c0fa9 Author: Ryusuke Konishi Date: Fri Jul 17 13:39:43 2026 +0900 nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after truncation commit 45662dedb8f272ef7f16e69f13424c4bd0399240 upstream. Shuangpeng Bai reported that KASAN detected a slab-out-of-bounds error in nilfs_direct_propagate() during testing. Analysis revealed that after truncating a file, a node block immediately below the B-tree root was not deleted. Instead, it remained in the B-tree node cache in a dirty state. The log writer subsequently detected this block and incorrectly invoked nilfs_direct_propagate() on it, which is designed to handle only data blocks in direct mapping. B-tree nodes in the cache are managed by virtual block numbers, and their logical keys typically exceed the range expected by direct mapping. Consequently, processing such a node as a direct mapping entry triggers a slab-out-of-bounds access. The root cause is that when a B-tree mapping collapses into a direct mapping during truncation, an intermediate node block pointed to by the root node is left behind as garbage instead of being explicitly deleted. This resolves the issue by adding a nilfs_btree_discard() operation to delete the remaining intermediate node block during the conversion. A 'deform' flag is added to the bop_delete interface to explicitly signal that the deletion is part of a mapping transformation. This allows the B-tree mapping implementation to perform the necessary cleanup and discarding of the residual node structure that would be otherwise be left orphaned after the transition. Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/r/08A3603A-ADB6-484C-9015-9AC1340E6FB8@gmail.com Fixes: 36a580eb489f ("nilfs2: direct block mapping") Cc: stable@vger.kernel.org Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Greg Kroah-Hartman commit 8c14472431e27f13661d0db9d837156eaced0ecb Author: Junrui Luo Date: Tue Jul 14 15:24:37 2026 +0800 media: vicodec: fix out-of-bounds write in FWHT encoder commit cf4500ebf6fb57bf4ab83c3dd349a40257dbe2a9 upstream. vidioc_s_fmt_vid_out() sizes the encoder CAPTURE buffer from the compressed descriptor pixfmt_fwht, whose sizeimage_mult is 3: coded_w * coded_h * 3 + sizeof(struct fwht_cframe_hdr). fwht_encode_frame() encodes one plane per component, and an incompressible plane takes the FWHT_FRAME_UNENCODED path in encode_plane(), copying the plane verbatim. For a 4-component pixel format all four planes are full resolution (width_div == height_div == 1), so a frame that forces every plane through the unencoded fallback writes sizeof(struct fwht_cframe_hdr) + 4 * coded_w * coded_h bytes, overrunning the plane by coded_w * coded_h, which can result in corruption of adjacent kernel heap memory. Bump pixfmt_fwht.sizeimage_mult from 3 to 4, matching the largest components_num among the supported raw formats, so the capture buffer is always large enough for the unencoded fallback. Fixes: 16ecf6dff97c ("media: vicodec: Add support for 4 planes formats") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0c260d3f97e52978a8c769bb095ac0901333a3ac Author: Weigang He Date: Thu Jun 11 23:22:48 2026 +1000 media: cec: stm32: prevent out-of-bounds write on RX overflow commit fb9dda38d4b9e90db07ed9a0ee2d35bf85494035 upstream. stm32_rx_done() appends each received CEC byte to rx_msg.msg[] using rx_msg.len as the write index, incrementing it on every RXBR (receive-byte-ready) interrupt without checking it against the buffer size: cec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF; rx_msg.msg[] is a fixed CEC_MAX_MSG_SIZE (16) byte array in struct cec_msg, and rx_msg.len is only reset on RXACKE/RXOVR or after a completed message (RXEND). The number of bytes received before RXEND is decided by the remote CEC device (it sets EOM), not by the driver. A peer that keeps sending bytes without ending the message drives RXBR repeatedly, pushing rx_msg.len past 16 and writing peer-controlled bytes out of bounds into the surrounding memory. This is reachable in normal operation once the driver has probed and receiving is enabled, from the IRQ thread, without any local privilege. The length check in the CEC core runs on the consumer side, after the byte has been stored, so it does not prevent the overflow. Bound the index in the driver before the store, as the other platform CEC drivers already do (e.g. tegra_cec), dropping the excess bytes of an overlong frame. Found by static analysis tool CodeQL. Fixes: d69ae57453c8 ("[media] cec: add STM32 cec driver") Cc: stable@vger.kernel.org Signed-off-by: Weigang He Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7d658da725ea81c91f73087547b97e7ced82d62b Author: Vincent Mailhol Date: Thu Jul 23 21:40:31 2026 +0200 lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen() commit cec0d03fe785380540dc1b4d07c80f67ae2ffc78 upstream. Patch series "lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()", v2. This series fixes an off-by-one out-of-bounds read in ucs2_strnlen(). The first patch is the real fix, the second patch comes as a bonus and fixes the code indentation. This patch (of 2): ucs2_strnlen() checks the current character before checking whether the caller-provided maximum length has been reached. If the input is not NUL-terminated within that bound, the loop can read one ucs2_char_t past the limit. Test the length before dereferencing to prevent an off-by-one out-of-bounds read. Link: https://lore.kernel.org/20260723-fix-ucs2_strnlen-v2-0-9ea94e32a358@kernel.org Link: https://lore.kernel.org/20260723-fix-ucs2_strnlen-v2-1-9ea94e32a358@kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Vincent Mailhol Cc: Kees Cook Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9f43499ce6458a572b781f6bb46c464ab59fa825 Author: Xingrui Li Date: Wed Aug 5 18:57:53 2026 +0000 HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature commit c92693f3ed099401d0383ef35ca1fe1e6ba033de upstream. sensor_hub_get_feature() clamps its return value to the caller's buffer size, but the copy loop still copies field->report_size / 8 bytes for each report value. A malicious HID descriptor can advertise a large feature field size while an IIO caller supplies a small stack buffer, such as a single s32, causing an out-of-bounds write. HID core stores parsed report values in __s32 slots and clamps extracted values to 32 bits. Reject feature fields that require more than one slot per value, guard the total byte count calculation, and clamp each per-value copy to the remaining caller buffer. Fixes: 5459ada2b3cd69 ("HID: sensor-hub: Fix packing of result buffer for feature report") Cc: stable@kernel.org Assisted-by: OpenAI:GPT-5.5-Cyber Signed-off-by: Xingrui Li Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 827ec385458adeeda651de2b6f3537e386b1a8d9 Author: Daisuke Matsuda Date: Thu Jul 23 08:19:12 2026 +0000 fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write commit 9da70a43b5fea60d758137f7f0ccfe19356cb5bb upstream. The trailing byte path in altera_cvp_send_block() dereferences a u32 pointer even when only 1-3 bytes remain in the input buffer. If the buffer ends at a page or scatterlist boundary, this can read past the valid image data and fault. Copy the remaining bytes into a zero-initialized u32 before writing the final word so only valid bytes are read from the input buffer. Fixes: 34d1dc17ce97 ("fpga manager: Add Altera CvP driver") Cc: stable@vger.kernel.org Signed-off-by: Daisuke Matsuda Reviewed-by: Xu Yilun Link: https://lore.kernel.org/r/20260723081912.74082-1-dskmtsd@gmail.com Signed-off-by: Xu Yilun Signed-off-by: Greg Kroah-Hartman commit 34e88f53614640b59039a46717fb6142e9871022 Author: Neill Kapron Date: Fri Jul 24 20:41:16 2026 +0000 usb: gadget: f_fs: Prevent deadlock during ep0 read loop commit 569dd7e5dcffe1e1c6b26ca2cd3be57eb433e082 upstream. Currently, ffs_ep0_read() holds ffs->mutex when it prepares to go to sleep waiting for an event. When no setup events are pending, it calls wait_event_interruptible_exclusive_locked_irq() with the mutex still held. The wait macro deliberately drops the waitqueue spinlock before sleeping but does not drop the mutex. If a userspace daemon is polling ep0 via read() and the gadget is asynchronously torn down via configfs (e.g., echo "" > UDC), a deadlock can occur: 1. The configfs teardown calls functionfs_unbind(), which queues a FUNCTIONFS_UNBIND event. 2. The daemon wakes up, consumes the event, and drops the mutex. 3. However, if the daemon loops and immediately issues another read() before exiting, it reacquires ffs->mutex and again goes into an interruptible sleep. 4. Meanwhile, functionfs_unbind() continues execution and attempts to acquire ffs->mutex to tear down ep0req. 5. The kernel deadlocks because the configfs thread is stuck in an uninterruptible sleep waiting for the mutex, while the userspace daemon is in an interruptible sleep holding the mutex forever because no more events will arrive. To fix this, we drop both the waitqueue spinlock and ffs->mutex before going to sleep, and use wait_event_interruptible_exclusive() instead. Upon waking up, we jump back to the `retry` label to safely reacquire the mutex and re-evaluate the state machine. By not sleeping with ffs->mutex held, we natively decouple gadget teardowns (which require the mutex) from userspace polling. Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver") Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Neill Kapron Link: https://patch.msgid.link/20260724204117.4036015-1-nkapron@google.com Signed-off-by: Greg Kroah-Hartman commit 9897b7da8c0ad8356c1b8649379fcb5a689462cb Author: Jeffin Philip Date: Thu Aug 13 23:13:11 2026 +0530 usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and uvc_function_unbind() commit bdab5605259ba5d6ff927c1a85cc83eb3ecfdacc upstream. In uvc_function_bind() error path, we use usb_ep_free_request which uses uvc->control_req but does not set it to NULL afterwards. Thus, uvc->control_req is a dangling pointer causing a UAF. Also we do not set the uvc->control_buf pointer to NULL after freeing it, which is another dangling pointer. Fix it by setting uvc->control_req to NULL after we run usb_ep_free_request() and uvc->control_buf to NULL after kfree. Do the same for uvc_function_unbind(). Reported-by: syzbot+de553c19cb054f174a35@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=de553c19cb054f174a35 Fixes: 0f9df9393855 ("usb: gadget: uvc: fix error path in uvc_function_bind()") Fixes: 6d11ed76c45d ("usb: gadget: f_uvc: convert f_uvc to new function interface") Cc: stable@vger.kernel.org Signed-off-by: Jeffin Philip Link: https://patch.msgid.link/20260813174311.130823-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit dbe2762ae8e543b06c57f1ac6512b02fd3fd09b2 Author: Jeffin Philip Date: Tue Aug 4 09:13:38 2026 +0530 usb: gadget: uvc: Fix null pointer dereference in uvcg_video_init() commit 5b1da38592efdc1a263d4c0353298cba19e9d6fc upstream. In uvcg_video_init(), if kthread_run_worker() fails, the error logged uses uvcg_err(), however, the pointer it uses: video->uvc is not assigned at this point, triggering a null pointer dereference. Fix this by directly using uvc->func which is assigned already. Reported-by: syzbot+8dcac923582c28505fd7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8dcac923582c28505fd7 Fixes: f0bbfbd16b3b ("usb: gadget: uvc: rework to enqueue in pump worker from encoded queue") Cc: stable@vger.kernel.org Signed-off-by: Jeffin Philip Reviewed-by: Xu Yang Link: https://patch.msgid.link/20260804034338.7976-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit 6bcd9ee6ad6989d1d85a7459687e45b7ad7568d9 Author: Yun Zhou Date: Fri Jul 31 16:11:51 2026 +0800 usb: gadget: f_tcm: fix deadlock in usbg_make_tpg() commit 9dbf74f4022f80f7669d2b3c22c5deb46c1b5674 upstream. usbg_make_tpg() held dep_lock while calling configfs_depend_item_unlocked(), which acquires the configfs root inode lock when operating across subsystems. This creates a circular lock dependency with configfs_rmdir(): dep_lock -> configfs root inode lock -> su_mutex -> dep_lock In usbg_make_tpg(), dep_lock only serialized the read of opts->ready, which is a monotonic flag that transitions from false to true exactly once (in tcm_set_name()) and never reverts. Remove dep_lock from usbg_make_tpg() entirely and use READ_ONCE/WRITE_ONCE to access opts->ready locklessly instead. Reported-by: syzbot+c9f9d646b08f3b6032fe@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c9f9d646b08f3b6032fe Fixes: 4bb8548df632 ("usb: gadget: f_tcm: add configfs support") Cc: stable@vger.kernel.org Signed-off-by: Yun Zhou Link: https://patch.msgid.link/20260731081151.285599-1-yun.zhou@windriver.com Signed-off-by: Greg Kroah-Hartman commit a15c2acd3083461f91725760e59dff88b33c28f6 Author: Joshua Crofts Date: Thu Jul 30 13:58:11 2026 +0000 usb: gadget: midi2: remove default configfs groups on teardown commit 0f6bffb5008f0cba9cad5ded2caccc64466a6e54 upstream. f_midi2_alloc_inst() creates default configfs child groups for the default endpoint and default block using configfs_add_default_group(), setting their internal refcount to 1. However, during function teardown in f_midi2_free_inst() or EP cleanup in f_midi2_ep_opts_release(), configfs_remove_default_groups() is never called, therefore never dropping the refcount and leaking struct f_midi2_ep_opts and f_midi2_block_opts. Add the missing configfs_remove_default_groups() in the afformentioned functions to free the structs properly. Fixes: 8b645922b223 ("usb: gadget: Add support for USB MIDI 2.0 function driver") Cc: stable@vger.kernel.org Reported-by: syzbot+eaa106d192c9daf37f95@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=eaa106d192c9daf37f95 Tested-by: syzbot+eaa106d192c9daf37f95@syzkaller.appspotmail.com Signed-off-by: Joshua Crofts Link: https://patch.msgid.link/20260730135811.1498-1-joshua.crofts1@gmail.com Signed-off-by: Greg Kroah-Hartman commit 64005cf3e897e278e1b7f5b87de7c7686d9317f1 Author: Myeonghun Pak Date: Tue Aug 4 23:05:10 2026 +0900 usb: gadget: snps_udc_plat: clean up PHY on probe deferral commit 886338ea7d40e4ba5123c58204d7f7e53d825825 upstream. When the referenced extcon device has not registered yet, extcon_get_edev_by_phandle() returns -EPROBE_DEFER after the driver has initialized and powered on the PHY. The direct return bypasses the common cleanup path and leaves both operations unbalanced. Store the lookup error first and route deferred probing through exit_phy, while retaining the existing behavior of suppressing the error message for deferral. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 1b9f35adb0ff ("usb: gadget: udc: Add Synopsys UDC Platform driver") Cc: stable@vger.kernel.org Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260804140510.37639-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 4e747c864a88537e18b1ffc19a1954c9686bb8e1 Author: Sonali Pradhan Date: Mon Aug 10 07:12:37 2026 +0000 usb: gadget: u_audio: Fix use-after-free on sound card disconnect commit 858965947081d10d41d9a1010a540d3d5eea958b upstream. g_audio_cleanup() invokes snd_card_free_when_closed() to initiate sound card teardown and immediately frees the underlying struct snd_uac_chip context. However, snd_card_free_when_closed() returns asynchronously while ALSA control elements (kctls) remain open in userspace. When userspace control applications access or close these open file descriptors, kctl callbacks attempt to dereference kctl->private_data pointing to &uac->c_prm or &uac->p_prm within the freed uac structure, resulting in a use-after-free (UAF) memory corruption. Fix this issue by deferring the destruction of struct snd_uac_chip until all references to the ALSA sound card are released. Register a custom card->private_free callback (u_audio_card_free) during g_audio_setup() that frees uac and its associated playback/capture request and ring buffers only when the sound card reference count drops to zero. Fixes: 6c67ed9ad9b8 ("usb: gadget: u_audio: don't let userspace block driver unbind") Cc: stable@vger.kernel.org Signed-off-by: Sonali Pradhan Link: https://patch.msgid.link/20260810071237.2207680-1-sonalipradhan@google.com Signed-off-by: Greg Kroah-Hartman commit 14fa29f3be0668e51e81faa411fb58b4c4294109 Author: Huang Wei Date: Wed Aug 5 16:57:25 2026 +0800 usb: typec: ucsi: use UCSI_TIMEOUT_MS for sync command completion commit eb4573cf2fd860b20adfae050c3f6ec6ddc3abdb upstream. The synchronous command completion path in ucsi_sync_control_common() hardcodes a 5 second (5 * HZ) timeout when waiting for the PPM to signal command completion via ACPI notification. This value matched UCSI_TIMEOUT_MS when it was still 5000 ms, but it was not updated when that macro was later raised to 10000 ms to fix PPM reset timeouts. As a result, the two PPM communication paths are now inconsistent: the polling path in ucsi_reset_ppm() respects the 10 second timeout, while the event-driven completion path still uses 5 seconds. On machines where the firmware is slow to respond during boot (e.g. some Lenovo ThinkPad models such as the E14 Gen 7), commands sent after the PPM reset, such as SET_NOTIFICATION_ENABLE and GET_CAPABILITY, can exceed 5 seconds and cause UCSI initialization to fail with: ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed Once UCSI init aborts, USB-C PD negotiation never completes, which in turn blocks USB-C dock enumeration since the dock depends on a successful PD contract. Replace the hardcoded 5 * HZ with msecs_to_jiffies(UCSI_TIMEOUT_MS) so that both communication paths share a single, consistent timeout value, and future adjustments to UCSI_TIMEOUT_MS are picked up automatically. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221740 Link: https://bugzilla.kernel.org/show_bug.cgi?id=2183790 Fixes: bf4f9ae1cb08c ("usb: typec: ucsi: increase timeout for PPM reset operations") Cc: stable@vger.kernel.org Signed-off-by: Huang Wei Reviewed-by: Heikki Krogerus Reviewed-by: Fedor Pchelkin Link: https://patch.msgid.link/20260805085725.389761-1-huangwei@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit ebb840d982a612261cfc8a7687735a140c6c7024 Author: Fan Wu Date: Sun Aug 2 01:49:59 2026 +0000 usb: typec: thunderbolt: Disable work before freeing tbt on remove commit 92090f6ff2acc81e9dd99881dcfb4f8c1bdaabd3 upstream. tbt_altmode_remove() drops the plug and cable references without draining tbt->work. The work function dereferences those references, and can also requeue itself in its error path. The VDM callbacks can queue the same work item. Disable and drain tbt->work before dropping the references. This waits for an existing invocation and prevents subsequent schedule_work() calls from queueing it during teardown. This issue was found by an in-house static analysis tool and confirmed by manual code review. Fixes: 100e25738659 ("usb: typec: Add driver for Thunderbolt 3 Alternate Mode") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260802014959.416687-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit d793bd8422e7807a4d663289c2f258c2a2d5ce8a Author: Xu Yang Date: Thu Jul 23 18:46:14 2026 +0800 usb: typec: tcpci: pass correct rx_type to tcpm_pd_receive() commit b691a07c5f644080374ddd24de6a0e05f5d28744 upstream. Previously, tcpci_irq() always passed TCPC_TX_SOP as the receive type to tcpm_pd_receive(), ignoring the actual frame type reported by the TCPC_RX_BUF_FRAME_TYPE register. Cache the TCPC_RX_DETECT register value in rx_type_mask variable. When a PD messageis received, read TCPC_RX_BUF_FRAME_TYPE register and handle the message only if its frame type is enabled in mask. The TCPC_RX_BUF_FRAME_TYPE register records the received message type, which has a 1:1 mapping to enum tcpm_transmit_type. Fixes: fb7ff25ae433 ("usb: typec: tcpm: add discover identity support for SOP'") Cc: stable@vger.kernel.org Signed-off-by: Xu Yang Acked-by: Heikki Krogerus Reviewed-by: Badhri Jagan Sridharan Link: https://patch.msgid.link/20260723104614.3717623-1-xu.yang_2@oss.nxp.com Signed-off-by: Greg Kroah-Hartman commit 12414bbd3e3f3a17bd019f4bdf07c06b79c98ee2 Author: Johan Hovold Date: Fri Jul 17 17:49:57 2026 +0200 USB: phy: fsl-usb: fix missing static keywords commit 80574c40598aedbc1751c528e414d7e224bc6313 upstream. A recent change enabling compile testing of a Freescale dual-role controller indirectly enabled a USB PHY driver to be built. That driver in turn is missing a bunch of static keywords which results in warnings like: drivers/usb/phy/phy-fsl-usb.c:105:5: error: no previous prototype for 'write_ulpi' [-Werror=missing-prototypes] 105 | int write_ulpi(u8 addr, u8 data) | ^~~~~~~~~~ which consequently breaks -Werror builds. Add the missing static keywords. Fixes: 0807c500a1a6 ("USB: add Freescale USB OTG Transceiver driver") Cc: stable@vger.kernel.org # 3.0 Reported-by: Mark Brown Link: https://lore.kernel.org/r/4f9f5ff9-8eaa-4bd5-9331-37119f78e13f@sirena.org.uk Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260717154957.1853976-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 51a311eb97e91ce1aed3005cb71ccb2e30f8cce8 Author: Fan Wu Date: Sun Jul 19 04:28:39 2026 +0000 usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed commit c27d13ce4bab80fbdf6523928071b6c24b37606c upstream. In polled-VBUS mode (board.vbus_pin && board.vbus_polled), probe arms a self-restarting cycle: at91_vbus_timer() schedules vbus_timer_work, and at91_vbus_timer_work() calls at91_vbus_update() and re-arms the timer via mod_timer(). Both recover the same udc through container_of and dereference it on every iteration. Neither teardown path cancels this cycle. udc is devm-allocated, so it is freed after at91udc_remove() returns, and is likewise freed when probe fails and devres runs. A timer callback or work item that is pending or running at either point dereferences the freed udc. Add at91_udc_shutdown_vbus_timer() and call it from at91udc_remove() and from the usb_add_gadget_udc() failure path in probe; the remaining probe error paths fail before the timer is armed. timer_shutdown_sync() waits for a running callback and clears timer->function, which makes the work handler's mod_timer() a permanent no-op; cancel_work_sync() then drains any pending or running work whose re-arm attempt now does nothing. The timer must be shut down first, since cancelling the work alone would let the timer re-queue it. The guard mirrors probe: in IRQ mode the timer and work_struct are never initialized. This does not require a fault; a normal driver unbind can interleave with an already queued work item. This issue was found by an in-house static analysis tool. Fixes: 4037242c4f5f ("ARM: 6209/3: at91_udc: Add vbus polarity and polling mode") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260719042839.3167094-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 448e95c0f3eaa8d99f16ccae92ab94545f14413b Author: Pei Xiao Date: Wed Aug 5 09:40:49 2026 +0800 usb: dwc3: gadget: Fix use-after-free in dwc3_gadget_free_endpoints due to race condition commit 9c855832790cd488d87de1885974f4c37cfe7358 upstream. In dwc3_gadget_init_endpoint, &dep->nostream_work is bound with dwc3_nostream_work, and dwc3_gadget_endpoint_stream_event can queue this delayed work on system_percpu_wq when a DEPEVT_STREAM_NOSTREAM event is received. If we remove the gadget, dwc3_gadget_free_endpoints makes cleanup and the memory allocated for dep with kzalloc() is released by kfree(dep), while the delayed work mentioned above may still be pending or running. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | dwc3_thread_interrupt | dwc3_endpoint_interrupt | dwc3_gadget_endpoint_stream_event | queue_delayed_work(system_percpu_wq, | &dep->nostream_work) dwc3_gadget_free_endpoints | dwc3_free_trb_pool(dep) | list_del(&dep->endpoint.ep_list) | dwc3_debugfs_remove_endpoint_dir(dep) | kfree(dep) | // dep is freed | | dwc3_nostream_work | // use dep (use-after-free) Fix it by canceling the delayed work before kfree(dep) in dwc3_gadget_free_endpoints. Fixes: dcfe437492e2 ("usb: dwc3: gadget: Reinitiate stream for all host NoStream behavior") Assisted-by: Codex:deepseek-v4-flash Acked-by: Thinh Nguyen Cc: stable@vger.kernel.org Signed-off-by: Pei Xiao Reviewed-by: Radhey Shyam Pandey Link: https://patch.msgid.link/331d1d5133496d2b4184e05f8848adb06930a138.1785893865.git.xiaopei01@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 316abfe39dce74dcdb5aa21e44909bed6e33b557 Author: Francesco Lavra Date: Tue Jul 28 17:44:20 2026 +0200 usb: dwc2: gadget: Exit partial power down state when changing USB pull-up commit bf1e90189a98ca4a824fd64b4f3c6043d13c98ea upstream. When a USB host suspends a connected device, the DWC2 USB device controller enters a partial power down state where controller registers are not accessible. If the USB gadget is then disconnected or deactivated (e.g. when a gadget function is unbound from the controller), the `pullup` callback in struct usb_gadget_ops is invoked; if the controller is kept in partial power down, the register write in dwc2_hsotg_core_disconnect() does not take effect; as a result, the USB host keeps seeing the device as connected, even though the device is disabled. Properly exit partial power down state in the pullup callback, so that the USB host detects a device disconnection as intended. Fixes: 97861781daff ("usb: dwc2: Allow entering hibernation from USB_SUSPEND interrupt") Cc: stable@vger.kernel.org Signed-off-by: Francesco Lavra Link: https://patch.msgid.link/20260728154420.2021519-1-flavra@baylibre.com Signed-off-by: Greg Kroah-Hartman commit 78f5c6e6aef9a041fc64f1117766cc2751816b42 Author: Hao-Qun Huang Date: Sat Jul 4 16:16:13 2026 +0800 staging: greybus: hid: fix SET_REPORT return value commit 6d45195a9626d8aaaaed212c55638829a9c624a3 upstream. __gb_hid_output_raw_report() stores the result of gb_hid_set_report() in ret and even adjusts it to account for the report ID byte, but then always returns 0. This hides Greybus transport errors from HID_REQ_SET_REPORT callers, and makes hidraw report zero bytes written to user space on success, although hid_hw_raw_request() is expected to return the number of bytes transferred or a negative errno. The sibling GET_REPORT path, __gb_hid_get_raw_report(), already follows this convention. Return ret like the other HID transport drivers do. Fixes: 96eab779e198 ("greybus: hid: add HID class driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Hao-Qun Huang Link: https://patch.msgid.link/20260704081613.434445-1-alvinhuang0603@gmail.com Signed-off-by: Greg Kroah-Hartman commit 28b932202fcdbeb2ef58d89ce4363f480433c234 Author: Karl Mehltretter Date: Fri Jul 31 20:18:44 2026 +0200 serial: imx: serialize imx_uart_ports[] lifetime commit 8b0b29fdcb47907ae0296b8fe829e918e05e300f upstream. imx_uart_probe() publishes its devm-allocated port in imx_uart_ports[] before uart_add_one_port() because console setup uses the table. The entry is not cleared when adding the port fails or after removal, leaving a dangling pointer. A sibling probe can register the shared console through that stale entry. This was reproduced under KASAN on QEMU mcimx6ul-evk by unbinding a sibling UART, unbinding the console UART and rebinding the sibling. Keep the entry valid through uart_remove_one_port(), then clear it. Protect port addition and removal together with their table updates so sibling operations cannot interleave. Reject an occupied slot rather than clobbering an active port during a duplicate-line probe. Fixes: dbff4e9ea2e8 ("IMX UART: remove statically initialized tables") Fixes: 9f322ad064f9 ("imx: serial: handle initialisation failure correctly") Reported-by: Sashiko Link: https://lore.kernel.org/all/20260719162850.043B41F000E9@smtp.kernel.org Link: https://lore.kernel.org/all/20260719222501.CB4CB1F000E9@smtp.kernel.org Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260731181844.11330-6-kmehltretter@gmail.com Signed-off-by: Greg Kroah-Hartman commit aad08b5f67d2a8116e1a00bce2611c1513b10bce Author: Hans Verkuil Date: Fri Jul 17 15:42:45 2026 +0200 Revert "media: v4l2-dev: fix error handling in __video_register_device()" commit e7600f5cee5de14065f950807931d6e6d40fb2d7 upstream. This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a. The intentions of that patch were good, but it doesn't work. The idea is that if device_register fails, you have to do a put_device to let the ref counter release resources. However, the V4L2 API says that if video_register_device() fails, then you have to call video_device_release(), which kfree()s the video_device struct. But the put_device() will already have freed the struct, so you end up in a double-free scenario. There is not really a good way of fixing this without breaking video_register_device() into two parts, one that initializes everything, and one that does the actual device_register, and then converting all V4L2 drivers to this new model. That is a massive job, and it is very unlikely that device_register will fail. So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust. Reviewed-by: Laurent Pinchart Fixes: 2a934fdb01db ("media: v4l2-dev: fix error handling in __video_register_device()") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-media/20260520090624.1071139-1-lgs201920130244@gmail.com/ Link: https://lore.kernel.org/all/2026042058-charm-storable-4ad8@gregkh/ Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit e6e925cc1f8067c65c7bec3da50a0ead3b3ef4e0 Author: James Kim Date: Fri Jul 24 08:52:20 2026 +0900 rapidio: mport_cdev: fix use-after-free in dma_req_free() commit 5cbef379a94b161726c5f504598bf4791d45cedc upstream. dma_req_free() acquires buf_mutex through req->map, drops the mapping reference with kref_put(), and then dereferences req->map again to unlock the mutex. If kref_put() drops the last reference, mport_release_mapping() frees the mapping, and the subsequent mutex_unlock() dereferences a freed object. This is a use-after-free. Fix this by caching map and md before kref_put(), clearing req->map while holding buf_mutex, and using the cached md for mutex unlocking. The bug is reachable from userspace via the RapidIO mport character device interface. Link: https://lore.kernel.org/20260723235220.588424-1-james010kim@gmail.com Fixes: e8de370188d0 ("rapidio: add mport char device driver") Signed-off-by: James Kim Reviewed-by: Dan Carpenter Cc: Alexandre Bounine Cc: Greg Kroah-Hartman Cc: Matt Porter Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c3d4be91c6fcea68fdafc0f5799ff1bdbe1a5b0a Author: Bartosz Golaszewski Date: Mon Jul 6 14:44:13 2026 +0200 powerpc/powermac: fix OF node refcount commit bd0abfe6b013aeb2a1aebc5fbc7ceeb50355bda3 upstream. Platform devices created with platform_device_alloc() call platform_device_release() when the last reference to the device's kobject is dropped. This function calls of_node_put() unconditionally. This works fine for devices created with platform_device_register_full() but users of the split approach (platform_device_alloc() + platform_device_add()) must bump the reference of the of_node they assign manually. Add the missing call to of_node_get(). Cc: stable@vger.kernel.org Fixes: 81e5d8646ff6 ("i2c/powermac: Register i2c devices from device-tree") Reviewed-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260706-pdev-fwnode-ref-v3-1-1ff028e33779@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 29e634a18957acda11383a15ab98a91c4ae9e294 Author: Bryam Vargas Date: Sat Jun 20 21:42:11 2026 -0500 misc: nsm: bound the device-reported response length commit 808e530654a5354e6df78863a5d61e4d44e67235 upstream. nsm_sendrecv_msg_locked() stores the virtqueue used-ring length reported by the NSM device into msg->resp.len without bounding it to the response buffer. A malicious or buggy backend can report a length larger than the response buffer; parse_resp_raw() then copies that many bytes out of the fixed buffer to user space, disclosing adjacent kernel heap (an out-of-bounds read). The request path already floors its length in fill_req_raw(); the response path lacks the symmetric check. Clamp the stored length to the size of the response buffer. Well-behaved devices report no more than the posted buffer size, so conforming traffic is unaffected. Fixes: b9873755a6c8 ("misc: Add Nitro Secure Module driver") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Alexander Graf Link: https://patch.msgid.link/20260620-b4-disp-a54b7dd6-v1-1-79d1f236a854@proton.me Signed-off-by: Greg Kroah-Hartman commit ba69d892ff4e4a58cc12a2cae106b112db3306cc Author: Xu Yang Date: Thu Jun 11 22:31:06 2026 +0200 device property: fix infinite loop in fwnode_for_each_child_node() commit 1900692555826753adab8799a1a8d50bb1ee200c upstream. When iterate over children of a fwnode that has a secondary fwnode, fwnode_get_next_child_node() can enter an infinite loop if the secondary fwnode has more than one child. Parent Child (Primary fwnode) FWa: {FWa1, FWa2, FWa3} (Secondary fwnode) FWb: {FWb1, FWb2} In this case: ┌─> fwnode_get_next_child_node(FWa, FWa1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa1) returns FWa2 │ │ ... │ │ fwnode_get_next_child_node(FWa, FWa3) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa3) returns NULL │ - fwnode_call_ptr_op(FWb, get_next_child_node, FWa3) returns FWb1 │ │ fwnode_get_next_child_node(FWa, FWb1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWb1) returns FWa1 └────┘ This cause fwnode_for_each_child_node() to loop indefinitely, reapeatedly output {FWa1, FWa2, FWa3, FWb1, FWa1, ...}. The root cause is that when the current child (FWb1) belongs to the secondary fwnode, calling get_next_child_node() on the parimary fwnode incorrectly returns the first child (FWa1) again instead of NULL. Fix this by dynamically checking the parent fwnode of the current child before calling get_next_child_node(). This approach follows the pattern established in commit b5b41ab6b0c1 ("device property: Check fwnode->secondary in fwnode_graph_get_next_endpoint()"). Fixes: 2692c614f8f0 ("device property: Allow secondary lookup in fwnode_get_next_child_node()") Cc: stable@vger.kernel.org Signed-off-by: Xu Yang Tested-by: Andy Shevchenko Signed-off-by: Andy Shevchenko Tested-by: Xu Yang Link: https://patch.msgid.link/20260611203537.1786399-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 4cd24873ab9fdbd730604881a6e8087bc7b99336 Author: Prasanna Kumar T S M Date: Fri Jul 24 02:27:12 2026 -0700 cdx: Fix double free when sysfs file creation fails commit 6f4acc3a3c300e174e3f586b97b04ed8f5948c36 upstream. In cdx_create_res_attr(), if sysfs_create_bin_file() fails, the code frees res_attr but doesn't set cdx_dev->res_attr[num] to NULL. This leaves a dangling pointer in the array. Then cdx_destroy_res_attr() frees the already-freed memory. Fix the double free by initializing cdx_dev->res_attr[num] after sysfs_create_bin_file() completes. Fixes: aeda33ab8160 ("cdx: create sysfs bin files for cdx resources") Cc: stable@vger.kernel.org Signed-off-by: Prasanna Kumar T S M Acked-by: Nikhil Agarwal Acked-by: Nipun Gupta Link: https://patch.msgid.link/20260724092712.2119149-1-ptsm@linux.microsoft.com Signed-off-by: Greg Kroah-Hartman commit b1a49c22de01faf176d44e5caa765e237353a579 Author: Hui Su Date: Sun Aug 16 18:04:29 2026 +0800 tracing: Fix use-after-free with same-name named triggers commit a7318172aa332a161fb9618286e64454c827f8fd upstream. When two hist triggers on different events are registered with the same name=, the second one reuses the first as named_data. Both are added to tr->hist_vars by save_hist_vars() during event_hist_trigger_parse(), because save_hist_vars() is called before event_trigger_register() while the named reuse is only detected later, in hist_register_trigger(). In the named-data branch hist_register_trigger() then frees the second histogram's hist_data via destroy_hist_data(), but never removes its tr->hist_vars list entry, leaving a dangling pointer and leaking the trace_array reference it holds. A later hist trigger that references a variable makes find_var_file() walk tr->hist_vars and dereference the freed hist_data. The bug is reproducible from userspace by writing three hist triggers to tracefs: cd /sys/kernel/tracing echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_switch/trigger echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_process_fork/trigger echo 'hist:keys=common_pid:vals=$x' > events/sched/sched_process_exit/trigger The third write panics the kernel: BUG: KASAN: slab-use-after-free in find_var_file.part.0+0x272/0x290 Read of size 8 at addr ffff888001f8a0e0 by task sh/1 CPU: 1 UID: 0 PID: 1 Comm: sh Tainted: G D N Call Trace: find_var_file.part.0 find_event_var parse_atom parse_expr __create_val_field event_hist_trigger_parse trigger_process_regex event_trigger_write vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe Allocated by task 1: event_hist_trigger_parse Freed by task 1: hist_register_trigger+0x618/0xa30 event_hist_trigger_parse The buggy address belongs to freed 2048-byte region Oops: general protection fault ... RIP: find_var_file.part.0 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Fix by removing the hist_data from tr->hist_vars and releasing the trace_array reference in the named-data branch of hist_register_trigger() before freeing the hist_data. Cc: stable@vger.kernel.org Fixes: 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers list") Link: https://patch.msgid.link/20260816100427.33642-3-sh_def@163.com Signed-off-by: Hui Su Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit ddbe921ed16a0ad2d9e09574c3f3aabec7528325 Author: Deepanshu Kartikey Date: Mon Aug 17 19:36:55 2026 +0530 tracing: Fix use-after-free in trace_pipe read on sub-buffer order change commit 372f8534244d632ad5118e8a87a11291b01712d3 upstream. Writing to buffer_subbuf_size_kb calls ring_buffer_subbuf_order_set(), which frees every sub-buffer of the ring buffer, including the reader page, and replaces them with newly allocated ones. Readers of trace_pipe hold pointers into those pages. ring_buffer_peek() looks up an event under cpu_buffer->reader_lock but returns the event pointer after dropping the lock, and peek_next_entry() then calls ring_buffer_event_length() and ring_buffer_event_data() on it. If the sub-buffer order is changed in that window, the reader dereferences freed memory: BUG: KASAN: use-after-free in ring_buffer_peek+0x3e0/0x430 Read of size 1 at addr ffff88802a4cf010 by task syz-executor989/6002 Freed by: free_buffer_page kernel/trace/ring_buffer.c:398 [inline] ring_buffer_subbuf_order_set+0x1325/0x18e0 kernel/trace/ring_buffer.c:7444 buffer_subbuf_size_write+0x182/0x280 kernel/trace/trace.c:8221 Take trace_access_lock(RING_BUFFER_ALL_CPUS) around the order change. This is the lock trace_pipe readers already hold across their entire peek-and-print loop, so the swap can no longer race with a reader that is dereferencing a peeked event. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260817140655.5694-1-kartikey406@gmail.com Fixes: f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page") Reported-by: syzbot+685955db58555575fdd2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=685955db58555575fdd2 Tested-by: syzbot+685955db58555575fdd2@syzkaller.appspotmail.com Reviewed-by: Bradley Morgan Signed-off-by: Deepanshu Kartikey Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit cdb6fb6cf1a7a2bca2f097b2c8f8f7e47330f9c2 Author: Vincent Donnefort Date: Fri Aug 7 09:54:23 2026 +0100 tracing: Fix logged instance name on creation failure commit a9a01be2834a529cbd490ccbab02643f0c1735f2 upstream. When boot instance creation fails, the kernel incorrectly logs "(null)" as the instance name because strsep() consumes curr_str entirely during parsing. Print the properly parsed name variable instead. And while at it log the error code. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260807085423.4175161-1-vdonnefort@google.com Fixes: cb1f98c5e574 ("tracing: Add creation of instances at boot command line") Acked-by: Masami Hiramatsu (Google) Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit adadf4192f700bca82abfda9fa6d58c0bf37cc04 Author: Hui Su Date: Mon Aug 17 20:06:44 2026 +0800 tracing: Fix crash passing ERR_PTR to kthread_stop() commit 649bc7df3e5d7be6f7996a95084037dbf3cad1e5 upstream. event_test_stuff() calls kthread_run() and unconditionally passes the returned task_struct pointer to kthread_stop(). kthread_run() returns an error pointer such as ERR_PTR(-ENOMEM) when kthread creation fails, for example under memory pressure during the boot-time event self-test. kthread_stop() then dereferences the invalid pointer, crashing the kernel. Check the result of kthread_run() before passing it to kthread_stop(). Use WARN_ON() so that a failure to create the self-test thread does not go unnoticed, matching the ring-buffer self-test fix in commit 91542863abad ("ring-buffer: Fix crash passing ERR_PTR to kthread_stop()"). Cc: stable@vger.kernel.org Fixes: e6187007d6c3 ("tracing/events: add startup tests for events") Link: https://patch.msgid.link/20260817120642.668375-3-sh_def@163.com Signed-off-by: Hui Su Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 25a0758cf6bdbfddac2be71124c9bd0692f4b0b1 Author: Jérémy Jean Date: Thu Aug 27 18:43:22 2026 +0000 tracing/user_events: Clear copied tracing state before fork duplication commit 390f6bd8583d177029d9df4bea6667509e55a765 upstream. dup_task_struct() copies user_event_mm from the parent into the child, without grabbing a reference to it. user_event_mm_dup() should replace it, but it leaves that copied pointer unmodified if user_event_mm_alloc() fails. When the child exits, user_event_mm_remove() decrements a reference the child never owned, which ultimately frees user_event_mm, while the parent still as a stale pointer to it. This creates a UAF, which KASAN reports as: BUG: KASAN: slab-use-after-free in current_user_event_mm+0x51/0x1d0 Write of size 4 at addr ffff888005010d30 by task init/44 Call Trace: kasan_report+0xce/0x100 kasan_check_range+0x10f/0x1e0 current_user_event_mm+0x51/0x1d0 user_events_ioctl+0x82e/0x15c0 __x64_sys_ioctl+0x139/0x1c0 do_syscall_64+0xce/0x450 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 44: __kasan_kmalloc+0x8f/0xa0 __kmalloc_cache_noprof+0x180/0x3a0 user_event_mm_alloc+0x3c/0x1f0 current_user_event_mm+0x88/0x1d0 Freed by task 42: __kasan_slab_free+0x43/0x70 kfree+0x13a/0x390 process_one_work+0x696/0xf90 worker_thread+0x420/0xba0 The fix simply clears the copied pointer before any possible failure. In case of failure, the child then has nothing to free. Cc: stable@vger.kernel.org Fixes: 7235759084a4 ("tracing/user_events: Use remote writes for event enablement") Link: https://patch.msgid.link/20260827184321.2964601-2-Jeremy.Jean@oss.cyber.gouv.fr Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Bradley Morgan Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit b503a61d5d392212caf7025725e34839671e73ff Author: Sanman Pradhan Date: Tue Apr 14 17:25:12 2026 +0000 hwtracing: hisi_ptt: Propagate DMA reset timeout in trace_start() commit 75d42d990335322852ed5f7ce324b701c0949d79 upstream. hisi_ptt_wait_dma_reset_done() discards the return value of readl_poll_timeout_atomic(). If the DMA engine does not complete its reset within the timeout, hisi_ptt_trace_start() proceeds to start tracing regardless. Return a bool from hisi_ptt_wait_dma_reset_done(), consistent with the other wait helpers in this driver. On timeout, log an error, de-assert the reset bit, and return -ETIMEDOUT. Move ctrl->started to the successful path so a failed start does not leave the trace marked as active. Fixes: ff0de066b463 ("hwtracing: hisi_ptt: Add trace function support for HiSilicon PCIe Tune and Trace device") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Reviewed-by: Sizhe Liu Reviewed-by: Yicong Yang Tested-by: Sizhe Liu Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260414172451.14331-2-sanman.pradhan@hpe.com Signed-off-by: Greg Kroah-Hartman commit 9b51dcb4f2305635d870c9dea673712c83b07b4d Author: Kiryl Shutsemau (Meta) Date: Mon Jul 13 14:37:53 2026 +0100 x86/tdx: Fix zero-extension for 32-bit port I/O commit 941370fc93cc3474e26811f4d3b062903eefe2cf upstream. According to x86 architecture rules, 32-bit operations zero-extend the result to 64 bits. The current implementation of handle_in() only masks the lower 32 bits, which preserves the upper 32 bits of RAX when a 32-bit port IN instruction is emulated. Use insn_assign_reg() to write the result back into RAX with proper partial-register-write semantics: 1- and 2-byte forms leave the upper bits untouched, the 4-byte form zero-extends to the full register. Fixes: 03149948832a ("x86/tdx: Port I/O: Add runtime hypercalls") Reported-by: Borys Tsyrulnikov Signed-off-by: Kiryl Shutsemau (Meta) Signed-off-by: Dave Hansen Reviewed-by: Binbin Wu Link: https://lore.kernel.org/all/CAKw_Dz96rfSQc6Rn+9QBcUFHhmkK+9zu+P=bxowfZwxrATCBRg@mail.gmail.com/ Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20260713133753.223947-4-kirill@shutemov.name Signed-off-by: Greg Kroah-Hartman commit c4a22154870813d10aa0b4c734a574c726f9d4b0 Author: Kiryl Shutsemau (Meta) Date: Mon Jul 13 14:37:51 2026 +0100 x86/tdx: Fix off-by-one in port I/O handling commit 0f63e656b1c679d32ac595de29d10c03efca6a25 upstream. handle_in() and handle_out() in arch/x86/coco/tdx/tdx.c use: u64 mask = GENMASK(BITS_PER_BYTE * size, 0); GENMASK(h, l) includes bit h. For size=1 (INB), this produces GENMASK(8, 0) = 0x1FF (9 bits) instead of GENMASK(7, 0) = 0xFF (8 bits). The mask is one bit too wide for all I/O sizes. Fix the mask calculation. Fixes: 03149948832a ("x86/tdx: Port I/O: Add runtime hypercalls") Reported-by: Borys Tsyrulnikov Signed-off-by: Kiryl Shutsemau (Meta) Signed-off-by: Dave Hansen Reviewed-by: Kai Huang Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Binbin Wu Reviewed-by: Rick Edgecombe Link: https://lore.kernel.org/all/CAKw_Dz96rfSQc6Rn+9QBcUFHhmkK+9zu+P=bxowfZwxrATCBRg@mail.gmail.com/ Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20260713133753.223947-2-kirill@shutemov.name Signed-off-by: Greg Kroah-Hartman commit b9ae969e6f1e35a7f7d63f66daf7443d4745f671 Author: Yao Zi Date: Sat Aug 1 18:29:53 2026 +0000 x86/locking: Use sfence for wmb() if SSE is available commit d824ed1307680dd482f607b0e707c575f70668c4 upstream. When adding cc clobber to wmb()'s definition, the alternative() condition to use sfence was incorrectly raised from X86_FEATURE_XMM to X86_FEATURE_XMM2. Restore the correct constraint for potential better performance on machines without SSE2. Fixes: bd922477d935 ("locking/x86: Add cc clobber for ADDL") Signed-off-by: Yao Zi Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260801182953.15069-1-me@ziyao.cc Signed-off-by: Greg Kroah-Hartman commit 08b4cdef3c2efecfc87d7fef5cd85cfacb526d53 Author: Kiryl Shutsemau (Meta) Date: Mon Jul 13 14:37:52 2026 +0100 x86/insn-eval: Move assign_register() out of KVM as insn_assign_reg() commit 1fe104b048d77d6cb25bd938e6a67450fb50e61d upstream. KVM's instruction emulator has a small helper, assign_register(), that writes a value into a register following the x86 rules for writes to general-purpose registers: an 8- or 16-bit write leaves the rest of the register untouched, a 32-bit write zero-extends the result to 64 bits, and a 64-bit write replaces the whole register. The TDX guest #VE handler needs the same logic for port I/O emulation to get 32-bit zero-extension right. Rather than add a third copy of the same switch, move the helper verbatim to , rename it to insn_assign_reg(), and route KVM's callers through it. Add to the header's includes so it builds standalone in callers that have not pulled it in transitively. No functional change. Signed-off-by: Kiryl Shutsemau (Meta) Signed-off-by: Dave Hansen Acked-by: Sean Christopherson Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20260713133753.223947-3-kirill@shutemov.name Signed-off-by: Greg Kroah-Hartman commit 968eea465942095eae58885a2ae6819de394ff7c Author: Joy H.J. Lee Date: Thu Jul 2 05:06:35 2026 +0900 tools/compiler: match glibc 2.42 definition of __attribute_const__ commit 8700a4761beb219873956666cf91776a2c61e698 upstream. glibc 2.42 added __attribute_const__ to sys/cdefs.h: # define __attribute_const__ __attribute__ ((__const__)) GCC 15 warns when a macro is redefined to a different replacement list (-Wbuiltin-macro-redefined). Since host tool Makefiles (resolve_btfids, objtool) pass -Werror, this conflict becomes fatal. The warning is suppressed on standard native builds because GCC treats /usr/include as a system header path (-isystem), and macro-redefinition warnings from system headers are silently suppressed by GCC. It fires when glibc headers are on a regular include path (-I) instead, which is the case in cross-compilation setups such as NixOS, where the sysroot's glibc is passed explicitly via -I rather than -isystem. Per (C11 6.10.3), identical replacement lists are accepted silently. Match the glibc definition exactly, including the space before "((", so the redefinition is accepted without warning regardless of whether glibc headers are treated as system or non-system includes. Link: https://lore.kernel.org/20260701200635.3992767-1-rkr0k0r@gmail.com Signed-off-by: Joy H.J. Lee Cc: Nathan Chancellor Cc: David Laight Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d4bf3a74e2bae6809e8b7fb9f141d6c914ddee59 Author: Ridong Chen Date: Thu Jul 23 11:24:34 2026 +0800 mm: vmscan: fix node reclaim ignoring swappiness parameter commit 8a905195850d383c0465ab5bdd3c91d94269b242 upstream. sc_swappiness() had two separate definitions depending on CONFIG_MEMCG. The !CONFIG_MEMCG variant simply returned vm_swappiness, ignoring the proactive_swappiness value passed through scan_control. This caused the swappiness parameter written to /sys/devices/system/node/nodeX/reclaim to have no effect when CONFIG_MEMCG is disabled. Fix this by consolidating sc_swappiness() into a single definition that checks sc->proactive_swappiness first, then falls back to mem_cgroup_swappiness() which already handles both CONFIG_MEMCG and !CONFIG_MEMCG. Before fix (swappiness=max ignored, mostly file pages reclaimed): # cat /proc/sys/vm/swappiness 60 # cat /proc/vmstat | grep pgsteal pgsteal_kswapd 0 pgsteal_direct 0 pgsteal_khugepaged 0 pgsteal_proactive 1840 pgsteal_anon 25 pgsteal_file 1815 # echo "64M swappiness=max" > /sys/devices/system/node/node0/reclaim # cat /proc/vmstat | grep pgsteal pgsteal_kswapd 0 pgsteal_direct 0 pgsteal_khugepaged 0 pgsteal_proactive 18013 pgsteal_anon 337 pgsteal_file 17676 After fix (swappiness=max honored, anon pages reclaimed as expected): # cat /proc/vmstat | grep pgsteal pgsteal_kswapd 0 pgsteal_direct 0 pgsteal_khugepaged 0 pgsteal_proactive 0 pgsteal_anon 0 pgsteal_file 0 # echo "64M swappiness=max" > /sys/devices/system/node/node0/reclaim # cat /proc/vmstat | grep pgsteal pgsteal_kswapd 0 pgsteal_direct 0 pgsteal_khugepaged 0 pgsteal_proactive 16283 pgsteal_anon 16283 pgsteal_file 0 Link: https://lore.kernel.org/20260723032434.2016749-3-ridong.chen@linux.dev Fixes: b980077899ea ("mm: introduce per-node proactive reclaim interface") Signed-off-by: Ridong Chen Acked-by: Johannes Weiner Reviewed-by: Barry Song Acked-by: Qi Zheng Tested-by: Song Hu Reviewed-by: Song Hu Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: Baoquan He Cc: Chris Li Cc: David Hildenbrand Cc: Davidlohr Bueso Cc: Kairui Song Cc: Kemeng Shi Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Nhat Pham Cc: Roman Gushchin Cc: Wei Xu Cc: Yuanchu Xie Cc: [6.17+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 461d23368f2965c5cea866b84700936e05e9fc2d Author: Johannes Weiner Date: Wed Jul 22 10:56:47 2026 -0400 mm: page_alloc: fix non-movable reclaim storm in defrag_mode commit 7e8756d7ad22655b935c384f123071aa9de07a27 upstream. As we deployed defrag_mode into Meta production, pressure spikes and excessive swapping were observed on some workloads. Tracing confirmed that this is unmovable/reclaimable requests spinning in the allocator and direct reclaim, causing excessive amounts of swap. The initial plan for defrag_mode was to rely on kswapd/kcompactd to produce blocks, and if those are overwhelmed under high pressure, let the allocator fall back (__rmqueue_steal()) after its retry loops. However, that retrying results in more reclaim on some of these workloads than we'd hoped, sometimes excessively so, spurred on by the !costly order conditions in should_reclaim_retry(). The storms are dependent on the request type. Reclaim will inevitably make room in existing movable blocks, since that's where the LRU pages live. So if movable requests retry on reclaim, they make progress. When non-movable requests spin in reclaim that isn't productive. They cannot use the individually freed pages, and the process is unlikely to accidentally free whole blocks to meet the ALLOC_NOFRAGMENT bar. They spin and overreclaim excessively, which tanks performance and triggers userspace guards like swap exhaustion or pressure based OOM. To fix this, send non-movable requests, regardless of order, into pageblock reclaim/compaction. This way, they help move things along to meet the ALLOC_NOFRAGMENT bar. After this patch, the reclaim storms and excess OOM rates are no longer observed in production. The longer-term plan is still to have all requests, including the movable ones, help make blocks to spread the cost of defragmenting more evenly and fairly; combined with proper watermarking to reduce allocation latencies in the common case. However, doing this naively unearths scaling and concurrency limitations in compaction that need to be addressed first. Promoting just non-movables for now is the minimally viable bug fix for the above issue. [brendan.jackman@linux.dev: fix try_to_compact_pages() kerneldoc] Link: https://lore.kernel.org/DK7NM9RPUJOD.11PNJJ5N2OBED@linux.dev Link: https://lore.kernel.org/20260722150006.3848560-5-hannes@cmpxchg.org Fixes: e3aa7df331bc ("mm: page_alloc: defrag_mode") Signed-off-by: Johannes Weiner Signed-off-by: "Brendan Jackman" Reviewed-by: Vlastimil Babka (SUSE) Cc: Brendan Jackman Cc: David Hildenbrand Cc: Gregory Price Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d435ba3c21a0251361f1faa7dd6668dc8d7741ba Author: Vlastimil Babka (SUSE) Date: Wed Jul 22 10:56:46 2026 -0400 mm: page_alloc: move capture_control to the page allocator commit aee220f565cce38f0efcff940ae2b44bdc495408 upstream. The compaction capturing code assumes the allocation request order and compaction target order are the same. That won't be true once defrag_mode promotes sub-block allocations to pageblock-order compaction: compaction targets the larger order, while capture should remain at the original allocation order. Move the capture_control to the page allocator and give it its own copies of what the page freeing path matches against - zone, migratetype and the allocation order - rather than reaching into compaction's live compact_control. __alloc_pages_direct_compact() fills in migratetype and order, and installs and hides current->capture_control around the whole compaction call; try_to_compact_pages() aims capc->zone at each zone while it is being compacted. compact_zone_order() no longer deals with capture at all. Pass the capture_control through try_to_compact_pages() / compact_zone_order() in place of the bare struct page **. No functional change. Link: https://lore.kernel.org/20260722150006.3848560-4-hannes@cmpxchg.org Fixes: e3aa7df331bc ("mm: page_alloc: defrag_mode") Signed-off-by: Vlastimil Babka (SUSE) Co-developed-by: Johannes Weiner Signed-off-by: Johannes Weiner Reviewed-by: Gregory Price Cc: Brendan Jackman Cc: Brendan Jackman Cc: David Hildenbrand Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 0df04778ea14a0f923396c645f16812fc5442871 Author: Johannes Weiner Date: Wed Jul 22 10:56:44 2026 -0400 mm: page_alloc: __GFP_FS lockdep annotation for direct compaction commit 37864d0bf5a4d60da6109b9078cc78ef3fc81216 upstream. Patch series "mm: fix reclaim storms in defrag_mode", v2. As we deployed vm.defrag_mode=1 in Meta production, some workloads regressed with recurring pressure spikes and swap storms (which in turn triggered userspace OOM rules on pressure and swap utilization levels). Tracing pinned this to non-movable requests spinning and reclaiming unproductively when kswapd/kcompactd are overwhelmed. Direct reclaim predominantly frees up pages in movable blocks, but those requests cannot use that space under defrag_mode rules; and it is unlikely to free up whole blocks incidentally for __rmqueue_claim() to work. This series fixes it by making non-movable requests participate in pageblock production in the allocator slowpath - meaning, they will invoke direct reclaim and direct compaction with pageblock_order. That requires some small-ish adjustments up front in the allocator and the compaction code: three prep patches and the fix last. The series has been in production against one of the affected workloads for several weeks and restores the OOM kill rate to !defrag_mode baseline. This patch (of 4): A subsequent patch will have some order-0 allocations participate in compaction under defrag_mode, to stave off extfrag events. Since this is a sprawling expansion of entry points, and compaction can enter filesystem paths, add lockdep annotations that catches __GFP_FS passing errors. Direct reclaim has had this annotation for a while, and since reclaim and compaction are usually used in conjunction, this is unlikely to unearth old bugs. It's more about future proofing and peace of mind. Link: https://lore.kernel.org/20260722150006.3848560-1-hannes@cmpxchg.org Link: https://lore.kernel.org/20260722150006.3848560-2-hannes@cmpxchg.org Fixes: e3aa7df331bc ("mm: page_alloc: defrag_mode") Signed-off-by: Johannes Weiner Reviewed-by: Vlastimil Babka (SUSE) Acked-by: Shakeel Butt Cc: Brendan Jackman Cc: Brendan Jackman Cc: David Hildenbrand Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Zi Yan Cc: Brendan Jackman Cc: Gregory Price Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b3d4b65085ef5d0542810e61d48a6876c91d11f1 Author: Johannes Weiner Date: Mon Jun 29 12:33:37 2026 -0400 mm: mempolicy: fix automatic numa balancing for shmem commit d230991493b521eeff39f32434fddcbcdb109eb0 upstream. Neha reports that mapped shmem aren't considered for NUMA balancing, noting convergence problems and bandwidth bottlenecking for cachelib based workloads on tiered memory systems. Looking at the code and going through the git history, this doesn't actually seem intentional: Commit fc3147245d19 ("mm: numa: Limit NUMA scanning to migrate-on-fault VMAs") added a vma_policy_mof() gate to task_numa_work() so VMAs whose policy lacks MPOL_F_MOF are skipped from NUMA balancing scans. The motivation was a real usecase: Oracle was pinning shared segments with mbind(MPOL_BIND) so trapping faults was both expensive and pointless. The handling of NULL from vm_ops->get_policy, however, treated "user explicitly opted out" the same as "user never specified anything." For VMAs whose shared policy is absent - the common case for shmem - the scan was disabled too. This issue is old. It probably hurts less in conventional NUMA. But it's very noticeable on tiered systems, where entire tmpfs workingsets can get stuck on lower-bandwidth memory. Fix this by having vma_policy_mof() use __get_vma_policy() directly, and thereby handle the fallback to task policy (-> preferred_node_policy() has MPOL_F_MOF per default). Every other consumer of vm_ops->get_policy already handles it this way, the scan-eligibility check was the outlier. This preserves Mel's intended fix: don't scan stuff the user explicitly pinned. But allow default policy vmas to participate in balancing. Link: https://lore.kernel.org/20260629163337.1264881-1-hannes@cmpxchg.org Fixes: fc3147245d19 ("mm: numa: Limit NUMA scanning to migrate-on-fault VMAs") Signed-off-by: Johannes Weiner Reported-by: Neha Gholkar Tested-by: Neha Gholkar Reviewed-by: Gregory Price Acked-by: David Hildenbrand (Arm) Acked-by: Balbir Singh Cc: Alistair Popple Cc: Byungchul Park Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5d866086d5f8dfc44e5e8665940f7d1468ca8b9a Author: Guopeng Zhang Date: Mon Jul 13 16:50:53 2026 +0800 mm: memcontrol: update state_local when flushing NMI stats commit 72f522bbf473f03a77e83547b677dc1505c5d41a upstream. flush_nmi_stats() updates state[] for kmem and slab counters but leaves the corresponding state_local[] counters unchanged. Local kmem and slab statistics therefore miss updates collected through the NMI-safe atomic path. Update state_local[] together with state[]. Link: https://lore.kernel.org/20260713085053.2916813-1-guopeng.zhang@linux.dev Fixes: 940b01fc8dc1 ("memcg: nmi safe memcg stats for specific archs") Signed-off-by: Guopeng Zhang Acked-by: Tao Cui Acked-by: Johannes Weiner Acked-by: Shakeel Butt Cc: Alexandre Ghiti Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 95d87030cae7764805aa7c621c52871139297cb0 Author: Guopeng Zhang Date: Fri Jul 24 10:18:05 2026 +0800 mm: memcg: stop reclaim when a limit update is superseded commit 9477820c63cbf4d97114238f3d1ff10dfd6bee3f upstream. kernfs serializes file operations only per open file, so separate open files can update the same memory.high or memory.max file concurrently. Both handlers store the new limit before synchronous reclaim, but continue to use the writer's local target in the reclaim loop. If another writer raises or removes the limit, the first writer can continue reclaiming toward a stale target. For memory.max, this can leave the writer looping indefinitely once reclaim retries are exhausted. The OOM path sees sufficient margin under the current limit and returns true without killing, while the writer still compares usage against its stale target and records another OOM event. Check the current limit at the start of each reclaim iteration and stop if it no longer matches the writer's target. Reproducer: Populate a cgroup with anonymous memory and disable swapping. Lower memory.max from one open file, then restore it to "max" through another open file after the new limit becomes visible. Without the patch, the first writer remains blocked and repeatedly increments the OOM event counter. With the patch, it returns normally. This was not motivated by a reported production workload. We found it through automated randomized testing for our cgroup observability work and reduced it to the reproducer above. Link: https://lore.kernel.org/20260724021805.1234583-1-guopeng.zhang@linux.dev Fixes: 8c8c383c04f6 ("mm: memcontrol: try harder to set a new memory.high") Fixes: b6e6edcfa405 ("mm: memcontrol: reclaim and OOM kill when shrinking memory.max below usage") Signed-off-by: Guopeng Zhang Acked-by: Tao Cui Acked-by: Johannes Weiner Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 680b93894ddf6cc0f5b8bc5bd57a67a640460e3b Author: Guopeng Zhang Date: Tue Aug 11 11:08:43 2026 +0800 mm: memcg-v1: fix memsw and TCP failcnt accounting commit 92192e9c5ee07efc657d3654bc264081fb0aa01b upstream. Commit 0e2759afcaf9 ("page_counter: track failcnt only for legacy cgroups") made failcnt accounting conditional on track_failcnt. It enabled the flag for memcg->memory, but not for memcg->memsw or memcg->tcpmem. Consequently, memory.memsw.failcnt remains zero when the memory+swap limit is hit. memory.kmem.tcp.limit_in_bytes still sets memcg->tcpmem.max, but TCP charge failures are not reflected in memory.kmem.tcp.failcnt. Enable failcnt accounting for both v1 counters. To reproduce memory.memsw.failcnt: CG=/sys/fs/cgroup/memory/memsw-test LIMIT=33554432 mkdir "$CG" echo "$LIMIT" > "$CG/memory.limit_in_bytes" echo "$LIMIT" > "$CG/memory.memsw.limit_in_bytes" Start a child process in the cgroup and make it allocate and touch 96 MiB of memory, causing a memcg OOM. cat "$CG/memory.memsw.failcnt" Without the patch, memory.memsw.failcnt is 0. With the patch, memory.memsw.failcnt is greater than 0. To reproduce memory.kmem.tcp.failcnt: CG=/sys/fs/cgroup/memory/tcpmem-test LIMIT=65536 mkdir "$CG" echo "$LIMIT" > "$CG/memory.kmem.tcp.limit_in_bytes" Start a child process in the cgroup, create a TCP socket, and reserve 1 MiB of socket memory with SO_RESERVE_MEM. The reservation fails with ENOMEM. cat "$CG/memory.kmem.tcp.failcnt" Without the patch, memory.kmem.tcp.failcnt is 0. With the patch, memory.kmem.tcp.failcnt is greater than 0. Link: https://lore.kernel.org/20260811030843.109104-1-guopeng.zhang@linux.dev Closes: https://sashiko.dev/#/patchset/20260810074247.52747-1-guopeng.zhang@linux.dev?part=1 Fixes: 0e2759afcaf9 ("page_counter: track failcnt only for legacy cgroups") Signed-off-by: Guopeng Zhang Acked-by: Johannes Weiner Acked-by: Michal Hocko Reviewed-by: Tao Cui Acked-by: Shakeel Butt Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d0943afb5ed8b2ff590eb290ad7ecbf091b99af8 Author: Guopeng Zhang Date: Mon Jul 13 16:57:56 2026 +0800 mm: memcg-v1: fix wrong linux-mm list address in deprecation warnings commit 45b1ec4887bdcc58af885540d9fefa8b67d17d57 upstream. The deprecation warnings for memory.oom_control and memory.pressure_level use linux-mm-@kvack.org instead of the linux-mm mailing list address. Remove the extra hyphen. Link: https://lore.kernel.org/20260713085756.2973549-1-guopeng.zhang@linux.dev Signed-off-by: Guopeng Zhang Acked-by: Michal Hocko Acked-by: Johannes Weiner Reviewed-by: Muchun Song Acked-by: Shakeel Butt Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 295f5a61d3aea1ca358de60ab6ad8038d7663206 Author: Johannes Weiner Date: Wed Jul 22 10:56:45 2026 -0400 mm: compaction: support non-movable compaction for pageblock requests commit 1b4b697a5743e624cc259d6c31a8d8716b796305 upstream. While trying to fix a reclaim storm in defrag_mode, I noticed that non-movable direct compaction is extremely inefficient. When searching for space to evacuate, compaction only allows blocks of the same type as the incoming request. This is to prevent migratetype pollution, where a small non-movable request frees space in a movable block and provokes the allocator to fall back and pollute it. This protection is reasonable on one hand, but the downside is that it makes non-movable direct compaction nearly useless: if we get the type annotations right, by definition there aren't any movable pages inside the non-movable blocks it is allowed to scan. With defrag_mode, the goal is the production of whole blocks, which are essentially type neutral: __rmqueue_claim() will convert them wholesale on alloc. This makes type mixing and pollution a non-issue. Fix the pollution gates to take the requested order into account, and allow whole-block requests to scan blocks of other types. The only exception is CMA blocks. That type is sticky and these blocks cannot be claimed to other types. Continue to be strict with them, and allow only explicit ALLOC_CMA requests and kcompactd to evacuate them. Link: https://lore.kernel.org/20260722150006.3848560-3-hannes@cmpxchg.org Fixes: e3aa7df331bc ("mm: page_alloc: defrag_mode") Signed-off-by: Johannes Weiner Reviewed-by: Vlastimil Babka (SUSE) Reviewed-by: Gregory Price Cc: Brendan Jackman Cc: Brendan Jackman Cc: David Hildenbrand Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ef765a2e4f5796bbe29a7a668aa71b4791f5d9d0 Author: Hao Jia Date: Thu Aug 6 15:09:42 2026 +0800 mm/zswap: fix global shrinker when memory cgroup is disabled commit dc8458f43fe964d8ade74c9b0fce54fe71d156de upstream. Patch series "mm/zswap: Fixes and improves the zswap shrink", v4. This series fixes and improves the zswap global shrinker (shrink_worker()): Patch 1: Fix missing global shrinker when memory cgroup is disabled. Patch 2: Extend shrink_memcg() to support batch writeback and thereby improving the writeback efficiency in the shrink_worker() and zswap_store() paths. This patch (of 2): Zswap writeback when the global pool limit is hit fails when memory cgroup is disabled. The pool remains full until it is organically drained by swapins or memory freeing, leading to zswap store failures and pages bypassing getting written directly to the backing swap device, causing LRU inversion (hotter pages with higher fault latency). This happens because mem_cgroup_iter() always returns NULL when memory cgroups are disabled. As a result, the global shrinker shrink_worker() repeatedly takes empty walks. After MAX_RECLAIM_RETRIES failed attempts, the worker gives up without writing back any pages. Therefore, when memory cgroup is disabled, fall through with the !memcg branch and shrink the root memcg directly. With memcg disabled, shrink_memcg() only returns -ENOENT when the root LRU is empty, which means the total pages are already below thr. In the absence of heavy concurrent zswap stores, the loop then safely bails out via the zswap_total_pages() <= thr check; otherwise, it will resume shrinking the memcg after processing the reschedule check. For any other return value from shrink_memcg(), the loop is guaranteed to terminate, either after MAX_RECLAIM_RETRIES failures or once the threshold is met. This is a potential performance regression for people using zswap without memcg that was introduced by the commit in "Fixes". Link: https://lore.kernel.org/20260806070943.95542-1-jiahao.kernel@gmail.com Link: https://lore.kernel.org/20260806070943.95542-2-jiahao.kernel@gmail.com Fixes: a65b0e7607cc ("zswap: make shrinking memcg-aware") Signed-off-by: Hao Jia Suggested-by: Nhat Pham Acked-by: Nhat Pham Acked-by: Yosry Ahmed Reported-by: Yosry Ahmed Cc: Chengming Zhou Cc: Johannes Weiner Cc: Michal Hocko Cc: Michal Koutný Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Tejun Heo Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3fd50239986302cb050d3649351bcec00fa9d5ab Author: Breno Leitao Date: Mon Aug 10 02:57:36 2026 -0700 mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() commit 25f52e81216884a7444bf07a606691feb09a94e3 upstream. I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1] Link: https://lore.kernel.org/20260810-rcu_task_shrink_lruvec-v1-1-4d9f7d5251cb@debian.org Link: https://lore.kernel.org/all/amdWVTs0WKOxguxP@gmail.com/ [1] Signed-off-by: Breno Leitao Reviewed-by: Paul E. McKenney Acked-by: Johannes Weiner Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Wei Xu Cc: Yuanchu Xie Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 895cd4ecbb2e03d7583103c65ee5adaae126ed6d Author: Hyunwoo Kim Date: Wed Aug 12 01:18:57 2026 +0900 mm/pagewalk: fix stale walk->action escaping walk_pmd_range() commit aedf2efd18977e0cef7eb963166e2b1fcc0aa321 upstream. If ->pmd_entry() sets walk->action = ACTION_AGAIN, the pmd_none() check is retried. The PMD entry may be cleared at the point of retry. In this case, if walk->ops->install_pte is not specified, the code continues to the next PMD entry in the range without resetting walk->action to ACTION_SUBTREE. This leaves walk->action erroneously set to ACTION_AGAIN, which is incorrect. This was incorrect but not problematic up until commit 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault") which updated walk_pud_range() to check for walk->action == ACTION_AGAIN upon walk_pmd_range()'s return, causing the PUD walk to be retried. In this case this results in duplicate walk callbacks being invoked, which is erroneous and will break any caller that is not idempotent with respect to this (and waste time for those which are). The result is an out-of-bounds write, triggered by a local fuzzer: [ 2.272695] ================================================================== [ 2.273471] BUG: KASAN: slab-out-of-bounds in __mincore_unmapped_range+0x14f/0x190 [ 2.274302] Write of size 1 at addr ffff888008d9b000 by task poc/106 [ 2.274966] [ 2.275154] CPU: 0 UID: 1000 PID: 106 Comm: poc Not tainted 7.2.0-rc6-00429-ga7c7074b58d2 #55 PREEMPT(lazy) [ 2.275159] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.275164] Call Trace: [ 2.275170] [ 2.275172] dump_stack_lvl+0x53/0x70 [ 2.275200] print_report+0xd0/0x630 [ 2.275210] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 2.275219] ? irqentry_exit+0xd2/0x670 [ 2.275224] ? irqentry_exit+0xd2/0x670 [ 2.275226] ? __virt_addr_valid+0xef/0x1a0 [ 2.275239] ? __mincore_unmapped_range+0x14f/0x190 [ 2.275242] kasan_report+0xce/0x100 [ 2.275245] ? __mincore_unmapped_range+0x14f/0x190 [ 2.275248] __mincore_unmapped_range+0x14f/0x190 [ 2.275252] mincore_unmapped_range+0x45/0x70 [ 2.275254] walk_pgd_range+0xafc/0xfc0 [ 2.275261] ? __pfx_walk_pgd_range+0x10/0x10 [ 2.275264] ? __update_load_avg_se+0x3d1/0x670 [ 2.275275] __walk_page_range+0xc0/0x310 [ 2.275278] ? __pfx_find_vma+0x10/0x10 [ 2.275281] ? finish_task_switch.isra.0+0x16d/0x4f0 [ 2.275290] walk_page_range_mm_unsafe+0x26f/0x3a0 [ 2.275293] ? __pfx_mtree_load+0x10/0x10 [ 2.275298] ? __pfx_walk_page_range_mm_unsafe+0x10/0x10 [ 2.275302] ? __free_frozen_pages+0x54d/0x7e0 [ 2.275308] __do_sys_mincore+0x132/0x380 [ 2.275311] do_syscall_64+0xf9/0x540 [ 2.275316] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2.275322] RIP: 0033:0x422ccd [ 2.275326] Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 [ 2.275329] RSP: 002b:00007fffffffec18 EFLAGS: 00000287 ORIG_RAX: 000000000000001b [ 2.275337] RAX: ffffffffffffffda RBX: 0000000000000066 RCX: 0000000000422ccd [ 2.275339] RDX: 00000000004d0940 RSI: 0000000001000000 RDI: 00007ffff4000000 [ 2.275340] RBP: 00000000004d0940 R08: 0000000000000100 R09: 0000000000000100 [ 2.275342] R10: 0000000000000100 R11: 0000000000000287 R12: 20c49ba5e353f7cf [ 2.275343] R13: 00000000004990d3 R14: 0000000000000000 R15: 0000000000000001 [ 2.275346] [ 2.275347] [ 2.296904] The buggy address belongs to the object at ffff888008d9b000 [ 2.296904] which belongs to the cache sigqueue of size 80 [ 2.298151] The buggy address is located 0 bytes inside of [ 2.298151] allocated 80-byte region [ffff888008d9b000, ffff888008d9b050) [ 2.299408] [ 2.299601] The buggy address belongs to the physical page: [ 2.300191] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8d9b [ 2.301001] flags: 0x100000000000000(node=0|zone=1) [ 2.301535] page_type: f5(slab) [ 2.301884] raw: 0100000000000000 ffff888107e46780 dead000000000122 0000000000000000 [ 2.302687] raw: 0000000000000000 0000000800240024 00000000f5000000 0000000000000000 [ 2.303489] page dumped because: kasan: bad access detected [ 2.304092] [ 2.304276] Memory state around the buggy address: [ 2.304801] ffff888008d9af00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2.305567] ffff888008d9af80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 2.306340] >ffff888008d9b000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2.307115] ^ [ 2.307474] ffff888008d9b080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2.308237] ffff888008d9b100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2.308997] ================================================================== A specific example of this breaking things is mincore which walks an internal cursor data structure a byte at a time on assumption that page table entry callbacks are called only once for each entry. Fix the problem by resetting walk->action to ACTION_SUBTREE prior to the none check. The pattern also exists in walk_pud_range() so fix it there too. This issue was found through AI-based fuzzing. Link: https://lore.kernel.org/20260811161949.3879321-2-imv4bel@gmail.com Fixes: 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault") Assisted-by: Claude:claude-opus-5 Signed-off-by: Hyunwoo Kim Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Max Boone Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 45489d4f95802903ab35799b400b346fa4e13151 Author: Alexander Graf Date: Fri Aug 7 03:12:43 2026 +0000 mm/mm_init: deferred_grow_zone(): fix out-of-range first_deferred_pfn commit 97090500d776c3f6d08e857e3a0a7cf092999094 upstream. With CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled, deferred_grow_zone() initializes struct pages early in boot to satisfy an allocation. With a large CMA reservation in place, the ranges deferred_init_memmap() finds may not add up to the allocation it was asked for, and the function ends up initializing the memory map of the entire zone and still falls short. That is fine in itself: the function accounts for it and leaves the caller to decide whether it now has enough memory. However, the update of pgdat->first_deferred_pfn that tracks where uninitialized memory map starts could overflow. If the node's RAM end is not aligned on PAGES_PER_SECTION boundaries and some deferred struct pages were initialized, pgdat->first_deferred_pfn would point past the end of the node's memory. deferred_init_memmap() later picks up from pgdat->first_deferred_pfn and hits a BUG_ON(), because it expects a pfn within its node. For example, when running a kernel with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y and CONFIG_CMA=y using the following qemu command line qemu-system-x86_64 -enable-kvm -m 8032M -kernel bzImage \ -append "nokaslr cma=4768M@0x100000000" the kernel panics: kernel BUG at mm/mm_init.c:2131! CPU: 3 UID: 0 PID: 36 Comm: pgdatinit0 Not tainted 7.2.0-rc6 #1 RIP: 0010:deferred_init_memmap+0x1b8/0x1c0 RAX: 0000000000236000 R13: 0000000000238000 Call Trace: kthread+0xdf/0x120 ret_from_fork+0x187/0x250 Make sure that the update of pgdta->first_deferred_pfn does not overflow when the entire zone's (and therefore node's) memory map is initialized. Fixes: 3acb913c9d5b ("mm/mm_init: use deferred_init_memmap_chunk() in deferred_grow_zone()") Cc: stable@vger.kernel.org Assisted-by: Kiro:claude-opus-5 Signed-off-by: Alexander Graf Link: https://patch.msgid.link/20260807031243.87904-1-graf@amazon.com [rppt: massaged the changelog] Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Greg Kroah-Hartman commit 5dc0daff0341c6baba19c38f47d299ac831d7e99 Author: Breno Leitao Date: Mon Jul 27 06:50:19 2026 -0700 mm/migrate: report RCU-tasks quiescent states in migrate_pages_batch() commit efe8f86c0916f0f74eea74ae21a3b37f728c6bad upstream. migrate_pages_batch() unmaps each folio before moving it, and every unmap runs the mmu_notifier invalidate callbacks. On KVM hosts try_to_migrate() ends up in kvm_mmu_notifier_invalidate_range_start() -> tdp_mmu_zap_leafs(), which is expensive, so unmapping a large batch keeps the CPU busy for a long time. The loop already calls cond_resched(), but on PREEMPTION kernels that is a no-op, and involuntary preemption is not a Tasks-RCU quiescent state. A long batch therefore never reports a quiescent state, and the migrating task (e.g. kcompactd) becomes a Tasks-RCU holdout, stalling the Tasks-RCU grace period for minutes, which is common at Meta fleet: INFO: rcu_tasks detected stalls on tasks: 0000000055349ecc: .. nvcsw: 1157401/1157401 holdout: 1 idle_cpu: -1/56 task:kcompactd0 state:R running task Call Trace: tdp_mmu_zap_leafs tdp_mmu_next_root gfn_to_pfn_cache_invalidate_start kvm_mmu_notifier_invalidate_range_start __mmu_notifier_invalidate_range_start try_to_migrate_one try_to_migrate migrate_pages_batch migrate_pages compact_zone compact_node kcompactd kthread Use cond_resched_tasks_rcu_qs() so a quiescent state is reported even when cond_resched() does nothing. This has also been discussed at [1] Link: https://lore.kernel.org/20260727-kcompact-v1-1-bdfefddd6874@debian.org Link: https://lore.kernel.org/all/amdWVTs0WKOxguxP@gmail.com/ [1] Signed-off-by: Breno Leitao Acked-by: Zi Yan Reviewed-by: Gregory Price Reviewed-by: Paul E. McKenney Acked-by: David Hildenbrand (Arm) Cc: Alistair Popple Cc: Byungchul Park Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3fc8044251de21555fb02c365fa681bab8b0db55 Author: Breno Leitao Date: Mon Jun 15 10:49:06 2026 -0700 mm/kmemleak: avoid soft lockup when scanning task stacks commit 5d10d4e19e6daa487f0cd0ea6cba472325de92f9 upstream. Patch series "mm/kmemleak: avoid soft lockup when scanning task", v3. kmemleak_scan() scans every task stack under one rcu_read_lock() with no reschedule point, which can trip the soft lockup watchdog on hosts with very many threads. That prints the following message, depending on the workload+host configuration: watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537] scan_block kmemleak_scan kmemleak_scan_thread kthread Patch 1 walks the tasks with find_ge_pid() so the scan reschedules between tasks Patches 2-3 let the scan loops stop early once a scan is interrupted. This patch (of 3): kmemleak_scan() walks every thread and scans its kernel stack under a single rcu_read_lock() with no reschedule point. On a host with very many threads -- amplified by KASAN/lockdep in debug builds -- this loop can hog a CPU long enough to trip the soft lockup watchdog: watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537] scan_block kmemleak_scan kmemleak_scan_thread kthread A cond_resched() cannot be added directly: the loop runs inside an RCU read-side critical section. Walk the tasks one PID at a time with find_ge_pid(), taking the RCU read lock only to look up and pin each task. The stack is then scanned with no lock held, so cond_resched() runs between tasks and the scan stops early on scan_should_stop(). This follows the next_tgid()/task_seq_get_next() iteration pattern and keeps each RCU critical section short. Link: https://lore.kernel.org/20260615-kmemleak-stack-resched-v3-0-acecd7d7fd92@debian.org Link: https://lore.kernel.org/20260615-kmemleak-stack-resched-v3-1-acecd7d7fd92@debian.org Fixes: c4b28963fd79 ("mm/kmemleak: rely on rcu for task stack scanning") Signed-off-by: Breno Leitao Reviewed-by: Catalin Marinas Reviewed-by: Davidlohr Bueso Reviewed-by: Lance Yang Reviewed-by: Oleg Nesterov Cc: Qian Cai Cc: SeongJae Park Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2cfa9ae90813bdc591740d467fdddb62e6e700cc Author: David Hildenbrand (Arm) Date: Fri Jul 31 22:27:53 2026 +0200 mm/gup: fix always draining LRU caches in collect_longterm_unpinnable_folios() commit 078e1a0fc41a42baaf113383b52dab8874c0b967 upstream. folio_may_be_lru_cached() is currently only true for small folios, and for small folios FOLL_PIN adds GUP_PIN_COUNTING_BIAS references instead of 1 in try_grab_folio()/try_grab_folio_fast(). Consequently, our folio_ref_count(folio) != folio_expected_ref_count(folio) + 1 check in collect_longterm_unpinnable_folios() will currently always identify "reference mismatch" and first drain the local LRU cache to then drain the LRU cache on all CPUs, as collect_longterm_unpinnable_folios() is really called after pinning the folios with FOLL_PIN. Add a comment because the current code is not quite intuitive: we used to drain only to make sure the folio_isolate_lru() would succeed. But then we also started draining to make later migration more reliable. We'll refactor that code soon a bit, to also make it usable in other context where we really want to remove any references from LRU caches. Let's add CC stable, because having an easy way for excessive LRU cache draining on all CPUs does not sound right. In common scenarios we don't expect to ever have to drain. Link: https://lore.kernel.org/20260731-check_and_migrate_movable_folios-v1-1-e0002d7b791e@kernel.org Fixes: 98c6d259319e ("mm/gup: check ref_count instead of lru before migration") Fixes: a09a8a1fbb37 ("mm/gup: local lru_add_drain() to avoid lru_add_drain_all()") Signed-off-by: David Hildenbrand (Arm) Acked-by: Hugh Dickins Cc: Ackerley Tng Cc: Jason Gunthorpe Cc: John Hubbard Cc: Kiryl Shutsemau Cc: Peter Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d423737dca23f1c00fa3eb4a0845205a3ab263fe Author: Breno Leitao Date: Tue Aug 18 02:03:40 2026 -0700 mm, swap: ratelimit bad swap entry reports commit f9dc428249ed962a70acf301f01eae8578449161 upstream. A corrupt page table hands the same bogus entry to get_swap_device() on every access to the mapping, and every rejection is logged. One machine logged 6185620 copies of the same line in a few hours. swap_dup_entry_direct() prints the same message from the fork path, once per call: the WARN_ON_ONCE() guarding it warns once, the pr_err() inside does not. Rate limit all three prints. Link: https://lore.kernel.org/20260818-swap_part_one-v1-1-a4fc58119fc0@debian.org Fixes: 23b230ba8ac3 ("mm/swap: print bad swap offset entry in get_swap_device") Signed-off-by: Breno Leitao Reviewed-by: Barry Song Reviewed-by: Nhat Pham Acked-by: Kairui Song Acked-by: David Hildenbrand (Arm) Cc: Baoquan He Cc: Chris Li Cc: Kemeng Shi Cc: Miaohe Lin Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f2c14f4d427d1b70ab2ff5eb410e620a6a404908 Author: Jordan R Abrahams-Whitehead Date: Fri Jul 31 20:15:19 2026 +0000 include/linux/list.h: mark list_add and __list_add as __always_inline commit 2780860eddecba9ffe210bb9436eee3cf22bfcdd upstream. This commit resolves an issue where modpost section verification fails due to section mismatches between list_add and its callers. At present, list_add (and its internal __list_add) are called from both .text and .init code sections. Since inlining can vary per call site, list_add can be 4 different states: list_add in text with arguments to non-.init.data values list_add in init with arguments to static .init.data values list_add in init with arguments to non-.init.data values list_add in text with arguments to static .init.data values It is last instance that ends up causing the section mismatch caused by constant propagation of the address of static libs inside the `dir_add` as seen below (with the dir_list being defined statically in initramfs.c, resting in .init.data). WARNING: modpost: vmlinux.o: section mismatch in reference: __list_add (section: .text.unlikely.) -> dir_list (section: .init.data) Because of these section matching requirements, semantically, __list_add and list_add MUST be inlined. This will then ensure callers inside .init will receive a list_add that exists and refers to only .init data, and list_add code in .text sections will only refer to non-init data. This issue manifests predominently in AutoFDO with clang, which is very hesitant to inline cold functions such as list_add even when marked `inline`. Marking them as `__always_inline` therefore matches the existing semantic constraints imposed by modpost's section mismatch checks. Link: https://lore.kernel.org/20260731-always-inline-list-add-v1-1-d29f54ce5477@google.com Link: https://lore.kernel.org/all/CANn89iJVQe=wedLheJmjZjOTJsWHijT0jZs=iRxKssJZbjAxHw@mail.gmail.com/ Signed-off-by: Jordan R Abrahams-Whitehead Suggested-by: Nathan Chancellor Suggested-by: Eric Dumazet Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Reported-by: Giuliano Procida Reported-by: Yabin Cui Closes: https://github.com/ClangBuiltLinux/linux/issues/2173 Cc: Bill Wendling Cc: Justin Stitt Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 28069434aef66b9d084f0609b7a29c171846815e Author: Hyunwoo Kim Date: Mon Aug 10 18:51:33 2026 +0900 apparmor: fix out-of-bounds write when null terminating a label vec commit 9f1e40193eef7f047e6b77cfb4b4cafdecd7a123 upstream. aa_vec_unique() null terminates at vec[n - dups] when VEC_FLAG_TERMINATE is passed. If the components are all distinct no duplicates are dropped, dups is 0 and the terminator goes to vec[n], so the caller has to provide room for n + 1 entries. aa_label_strn_parse() sets up its vector with vec_setup(profile, vec, len, gfp) and then calls aa_vec_unique(vec, len, VEC_FLAG_TERMINATE), but vec_setup() does not reserve the terminator entry. Up to LOCAL_VEC_ENTRIES it uses the local array of LOCAL_VEC_ENTRIES pointers, above that it allocates exactly len pointers. The terminator therefore lands one entry past the end of the local array when len is LOCAL_VEC_ENTRIES, and one entry past the end of the allocation when len is larger. len comes from the number of "//&" separated components in the label name and label_count_strn_entries() does not bound it. An unprivileged task reaches the parse by writing to /proc/self/attr/apparmor/current or through lsm_set_self_attr(2), both of which go through do_setattr(), and the name is parsed before the change_profile permission is checked. The query_label() path behind the securityfs .access file, which is mode 0666, performs no permission check at all. Every component has to resolve to a loaded profile, so a system with policy loaded is required. The other two VEC_FLAG_TERMINATE users work on a label vec that aa_label_alloc() has already sized with "+ 1 for null terminator entry on vec". Reserve the same entry in vec_setup() and DEFINE_VEC(). Passing len + 1 from the caller instead would move len == LOCAL_VEC_ENTRIES out of the local array and into kzalloc(). Fixes: f1bd904175e8 ("apparmor: add the base fns() for domain labels") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 587a6a92b93ec314c583bbf747413af170d42540 Author: Jann Horn Date: Thu Aug 6 17:55:02 2026 +0200 apparmor: fix cred UAF caused by begin_current_label_crit_section() commit 3f4ae5fab613dca01d6a2a8210dd832e009fcf47 upstream. AppArmor's begin_current_label_crit_section() is a scary function called from lots of LSM hooks (in particular VFS/socket-related ones) that checks if the label referenced by the current creds is marked FLAG_STALE, and if so, attempts to use aa_replace_current_label() to replace the creds with an updated version that uses a new label. The first problem with this is that it would directly lead to UAF of `struct cred` if anything in the kernel takes a pointer to the current creds and accesses these past a security hook invocation that replaces creds, like so: ``` const struct cred *cred = current_cred(); alloc_file_pseudo(...); uid_t uid = cred->euid; ``` I don't know if anything in the kernel actually does this, but I think it is very surprising that this pattern could lead to UAF. The second problem is that things go wrong when aa_replace_current_label() runs with overridden credentials. aa_replace_current_label() bails out if `current_cred() != current_real_cred()` (mirroring the check in proc_pid_attr_write()), but this check can't actually reliably detect overridden credentials because the overridden creds can be the same as the objective creds. So in approximately the following scenario, things go wrong: 1. task begins with (as both objective and subjective creds), with refcount=2 2. task grabs an extra reference on for overriding 3. task calls override_creds(), which returns a pointer to the old subjective creds () 4. task enters AppArmor LSM hook 5. AppArmor checks that objective/subjective creds are equal 6. AppArmor replaces both cred pointers with and drops 2 refs on 7. task leaves AppArmor LSM hook 8. task calls revert_creds() 9. now task->cred is while task->real_cred is , but the task_struct logically holds two references to 10. another task drops the extra reference on that was used for overriding, refcount drops to 0 11. now task->real_cred points to freed creds At this point, any access to current_cred() will be UAF. I have a test case where I run aa-disable on a profile while a process using that profile is blocked on splice() from a FUSE passthrough file into a full pipe; after the profile update, the pipe becomes empty, splice() resumes, the credentials go out of sync, and a subsequent getuid() syscall results in a KASAN UAF splat. To fix this, instead of directly replacing creds, do it via task_work that will run at the end of the current syscall. (The point in time at which the cred replacement happens should have no correctness impact; it is just a performance optimization to avoid unnecessarily touching the refcount of the new label.) Note that AppArmor still performs direct cred replacements in the sb_pivotroot LSM hook after this change, and that direct cred replacements can still happen in VFS ->write() callbacks via proc_pid_attr_write(). There are two options for what to do with aa_dup_task_ctx(): Either explicitly reset new->label_replacement_pending after the entire aa_task_ctx has been copied, or switch to manually copying members over. I am switching to manually copying members over because that should make bugs more obvious. Cc: stable@vger.kernel.org Fixes: c75afcd153f6 ("AppArmor: contexts used in attaching policy to system objects") Signed-off-by: Jann Horn Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 753c978f2400f9783eb524842a975d3ac950d511 Author: Chengfeng Ye Date: Tue Aug 11 02:56:03 2026 +0300 KEYS: trusted: Fix TPM teardown ordering commit 5e2d672280d97d83de43031d93761b12dadd7b8a upstream. trusted_tpm_exit() drops the TPM chip reference and frees the digest array before unregistering the trusted key type. key_type_lookup() holds key_types_sem for reading until the key operation finishes, while unregister_key_type() takes it for writing. It therefore provides the synchronization point that must precede backend teardown. The current order permits this interleaving: CPU 0 CPU 1 trusted_tpm_exit() key_type_lookup("trusted") put_device(&chip->dev) trusted_tpm_seal() kfree(digests) pcrlock() unregister_key_type() tpm_pcr_extend(..., digests) CPU 1 can consequently dereference the freed digest array. The chip can also be released before callbacks stop using it. KASAN reported: BUG: KASAN: slab-use-after-free in tpm_pcr_extend+0x1f0/0x200 Read of size 2 at addr ffff88810872d000 by task poc/89 Call Trace: tpm_pcr_extend+0x1f0/0x200 pcrlock+0x42/0x70 [trusted] trusted_tpm_seal+0x1b6/0x570 [trusted] trusted_instantiate+0x293/0x340 [trusted] __key_instantiate_and_link+0xb2/0x2b0 __key_create_or_update+0x61e/0xb50 __do_sys_add_key+0x1b8/0x310 Allocated by task 88: __kmalloc_noprof+0x1a7/0x490 do_one_initcall+0xa1/0x390 do_init_module+0x2df/0x840 Freed by task 90: kfree+0x131/0x3c0 trusted_tpm_exit+0x59/0xa0 [trusted] __do_sys_delete_module+0x346/0x510 Move unregister_key_type() before releasing either resource. This stops new lookups and waits for in-flight key operations to finish before the backend state is destroyed. Fixes: 0b6cf6b97b7e ("tpm: pass an array of tpm_extend_digest structures to tpm_pcr_extend()") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Link: https://lore.kernel.org/r/20260731140925.2973492-1-nicoyip.dev@gmail.com Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 0a10989de61039fd7534ac257f62319808e31890 Author: Nikolai Grlica Date: Mon Aug 10 15:03:35 2026 +0000 rust: kernel: list: fix incorrect pop_back example comment commit a5c7d35e2fd3e24c411816c91f8f6cc78e652e0c upstream. The example uses pop_back(), but the accompanying comment says pop_front(). Update the comment to match the example. Signed-off-by: Nikolai Grlica Cc: stable@vger.kernel.org Fixes: bf87a41b85d6 ("rust: list: Add an example for `ListLinksSelfPtr` usage") Link: https://patch.msgid.link/20260810150322.61809-1-nikolai@nikolaigrlica.dev Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 138722d631acf5d9a30ffe5895e221267c0aa7af Author: FUJITA Tomonori Date: Sat Aug 8 11:26:08 2026 +0900 rust: bug: skip arch-specific asm in `testlib` builds commit 5d9668f3930609ead91f39b059ef4fe53db04942 upstream. Running `make rusttest` with `ARCH=` set to an architecture other than the host's fails, e.g. `ARCH=arm64` on an x86_64 host: error: invalid instruction mnemonic 'brk' --> rust/kernel/bug.rs:63:17 | 63 | / concat!( 64 | | "/* {size} */", 65 | | include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_warn_asm.rs")), 66 | | include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_reachable_asm.rs"))); | |_______________________________________________________________________________________________________^ | note: instantiated into assembly here --> :1:115 | 1 | /* 8 */.pushsection __bug_table,"aw"; .align 2; 14470: .long 14471f - .;.short 2305;.align 2; .popsection; 14471:brk 0x800 | ^^^ The reason is that `rusttest` builds the `kernel` crate as a host library: it passes the `CONFIG_*` cfgs of the configured architecture, but not `--target`, so code generation happens for the host. `warn_flags!` then selects the arch-specific inline asm arm based on `CONFIG_*`, and the host assembler rejects it. This does not happen with the current `master` because `warn_on!` has no user inside the `kernel` crate itself yet, but it will as soon as one is added. Reported-by: Miguel Ojeda Closes: https://lore.kernel.org/all/CANiq72n4=fz=JNKY0Jdm8BnLa=RmHB2B7s0bO47YTJ7hygqBZg@mail.gmail.com/ Signed-off-by: FUJITA Tomonori Cc: stable@vger.kernel.org Fixes: dff64b072708 ("rust: Add warn_on macro") Link: https://patch.msgid.link/20260808022608.1125174-1-tomo@flapping.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 2bf5e8f7c9bf4ad3be343a9a6e3e50a34264d25e Author: Jérémy Jean Date: Sun Aug 9 19:04:16 2026 +0000 timers/itimer: Zero-init old itimerval before copy to userspace commit 18c7d85864e554adc8fad1e8d2e9d2cb6c3911c8 upstream. On native sparc64, struct __kernel_old_timeval contains a four-byte hole after tv_usec because tv_sec is 64-bit while __kernel_suseconds_t is 32-bit. put_itimerval() fills only the named fields in a stack-allocated __kernel_old_itimerval and copies the entire object to userspace, so getitimer() can expose the two padding holes. Zero-initialize the aggregate before assigning the fields so implicit padding is deterministic before it crosses the user/kernel boundary. Signed-off-by: Jérémy Jean Signed-off-by: Thomas Gleixner Assisted-by: Codex:gpt-5 Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260809190428.1523014-1-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Greg Kroah-Hartman commit e6da8a0f397694f5e97c2bd1b5cb1f0669f8eef0 Author: Gaurav Batra Date: Mon Aug 3 17:40:29 2026 -0500 powerpc/pseries/iommu: switch to Default DMA window during kdump commit 1304643a1c20badbb91b86a5084dd76cb7620c05 upstream. In PowerPC (pseries) a non-virtualized adapter will have 2 DMA windows - 2GB default and a larger Dynamic DMA Window (DDW). DDW is large enough to map total RAM to a device. During normal functioning of OS, since RAM is pre-mapped, 2GB default window is not used. The only scenario it might get used is when buffers in pmemory are mapped to the device for DMA. As of today, during kdump, during early device discovery, pci_dma_find() finds that the device has 2 DMA windows. It selects to use DDW. This is a kdump path and DMA window is needed for IO to the device. Although commit 09a3c1e46142 ("powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV") fixed an issue during kdump with SR-IOV case, but this also made the kdump prefer DDW over the default DMA window when both are present (dedicated adapter case). Since the DDW is fully mapped by the previous kernel, iommu_table_clear() can free only KDUMP_MIN_TCE_ENTRIES (2048) TCEs for use by kdump kernel. This is not enough when the dump device is NVMe over Fibre Channel. Because nvme-fc driver DMA-maps the cmds and resp IUs of every pre-allocated request and each such mapping consumes roughly: 32 (IO queues, one per cpus = nr_cpus) * 64 (queue_depth, blk-mq kdump limit) * 2 (cmd+resp) = 4096 This is already double of what we have without counting admin queues and lpfc driver's own allocations / mapping requirement. Hence this results into iommu_alloc failures like - lpfc 0153:70:00.0: iommu_alloc failed, tbl 0000000034ebcf5e vaddr 00000000d814df0b npages 1 lpfc 0153:70:00.0: FCP Op failed - cmdiu dma mapping failed. lpfc 0153:70:00.0: iommu_alloc failed, tbl 0000000034ebcf5e vaddr 000000009779e4d2 npages 1 lpfc 0153:70:00.0: FCP Op failed - cmdiu dma mapping failed. iommu_map_phys+0x1c4/0x1f0 (unreliable) dma_iommu_map_phys+0x54/0xa0 dma_map_phys+0x3f8/0x590 __nvme_fc_init_request+0x110/0x300 [nvme_fc] nvme_fc_init_request+0x60/0xb8 [nvme_fc] blk_mq_alloc_map_and_rqs+0x388/0x510 blk_mq_alloc_tag_set+0x2a4/0x5f0 nvme_alloc_io_tag_set+0xe0/0x1e0 [nvme_core] nvme_fc_connect_ctrl_work+0x85c/0xdac [nvme_fc] process_one_work+0x1e4/0x5a0 worker_thread+0x1ec/0x3e0 Increasing the number of free TCE entries in iommu_table_clear() will increase the probability of hitting EEH since there could still be some active IOs from the previous life of the kernel. Hence this patch partially reverts the previous fixes commit and switches the kdump's default back to 2GB default DMA window instead of DDW window. This window will mostly be empty. Or, could be slightly used if buffers in pmemory were mapped for IO. Fixes: 09a3c1e46142 ("powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV") Cc: stable@vger.kernel.org Signed-off-by: Gaurav Batra Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260803224029.60538-1-gbatra@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit c03114634d342648bd34910aa8fb88007e92cc3c Author: Baokun Li Date: Tue Aug 4 11:42:04 2026 +0800 fs: fix user path of nested backing files commit f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d upstream. backing_file_open() derives the path to be stored in the new backing file from user_file->f_path. This is incorrect when user_file itself is a backing file, which is the case for nested stacking filesystems, e.g. overlayfs mounts where the lowerdir of one overlayfs is the merged directory of another. Since commit def3ae83da02 ("fs: store real path instead of fake path in backing file f_path") the f_path of a backing file holds the real path of the intermediate layer, not the path that the user opened. Commit 924577e4f6ca ("ovl: Fix nested backing file paths") fixed this for such configurations by passing file_user_path() from ovl_open_realfile(). However, commit 6af36aeb147a ("lsm: add backing_file LSM hooks") changed the first argument of backing_file_open() from the user path back to the user file and derived the path from user_file->f_path again, silently re-introducing the problem. As a result, files mapped through a nested overlayfs show the wrong path in /proc//maps and in perf/ftrace mmap records. For example, with two nested overlayfs mounts: mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested echo hello > /ovl/lower/foo mount -t overlay overlay \ -o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \ /ovl/merged # at least two lowerdirs are needed when upperdir is nonexistent mount -t overlay overlay \ -o lowerdir=/ovl/merged:/ovl/lower /ovl/nested mapping /ovl/nested/foo shows a disconnected path instead of the user path: # readlink /proc/self/fd/3 /ovl/nested/foo # grep foo /proc/self/maps 7f6e2c100000-7f6e2c101000 r--s 00000000 00:24 15813027 /foo The bogus path is derived from the f_path of the intermediate backing file, whose mount is a private clone that d_path() cannot resolve. Fix this by using file_user_path(), which returns the outermost user-visible path for backing files and falls back to &user_file->f_path for regular files. This restores the behavior of commit 924577e4f6ca ("ovl: Fix nested backing file paths") for overlayfs and also fixes the same problem for the other backing_file_open() callers, fuse passthrough and erofs ishare, when their user file is itself a backing file. backing_tmpfile_open() has the same pattern but is not affected: it is only called by ovl_create_tmpfile() for the upper layer, and another overlayfs is rejected as upperdir by the DCACHE_OP_REAL check in ovl_mount_dir_check(), so its user_file can never be a backing file. Fixes: 6af36aeb147a ("lsm: add backing_file LSM hooks") Cc: stable@vger.kernel.org Signed-off-by: Baokun Li Link: https://patch.msgid.link/20260804034204.3487077-1-libaokun@linux.alibaba.com Tested-by: Paul Moore Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit bf38be01d43c4e4ca903aff7236d8486a950a252 Author: Felix Yan Date: Thu Jun 25 06:04:34 2026 +0800 clocksource/drivers/timer-sun4i: Advertise a real minimum delta commit d21808328225ab8cee46885bf9a0dffcefbe630e upstream. sun4i_clkevt_next_event() compensates for the timer stop/start synchronization delay by programming evt - TIMER_SYNC_TICKS into the hardware interval register. The clockevent device currently advertises TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed to call set_next_event() with evt == TIMER_SYNC_TICKS. That programs a zero-tick interval. With oneshot/highres/nohz timer operation this can leave the next event stuck, which was observed as a boot hang on Allwinner D1 after the clockevents core started reusing forced minimum-delta events. Advertise one extra tick instead, so the smallest event accepted by the core still programs at least one hardware tick after the synchronization compensation. Fixes: 12e1480bcb49 ("clocksource: sun4i: Report the minimum tick that we can program") Reported-by: Indrek Kruusa Closes: https://lore.kernel.org/linux-riscv/CA+fTLhgLmTY+exGujKf8OYYQvcEW5X5NJ_5sLq2AYL6zER2c0A@mail.gmail.com/ Assisted-by: Codex:gpt-5.5 Signed-off-by: Felix Yan Signed-off-by: Daniel Lezcano Tested-by: Indrek Kruusa Acked-by: Jernej Skrabec Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-riscv/CA+fTLhgLmTY+exGujKf8OYYQvcEW5X5NJ_5sLq2AYL6zER2c0A@mail.gmail.com/ Link: https://patch.msgid.link/20260624220434.4183732-1-felixonmars@archlinux.org Signed-off-by: Greg Kroah-Hartman commit d53c29a89a15e56a1797f3ef249955e544782e04 Author: WenTao Liang Date: Sun Jun 28 21:07:00 2026 +0800 clocksource/drivers/nxp-pit: Fix IRQ leak on cpuhp_setup_state error path commit 05520e035f8332c8e33f3011b5ca016fde61793d upstream. When cpuhp_setup_state fails after pit_clockevent_per_cpu_init has successfully called request_irq, the error handling jumps directly to out_pit_clocksource_unregister without freeing the registered IRQ. This leaks the IRQ line and, since kfree(pit) follows, leaves a dangling pointer registered as the interrupt handler's dev_id, potentially leading to a use-after-free if the IRQ fires afterwards. Fix it by calling pit_clockevent_per_cpu_exit to properly release the IRQ before falling through to the existing cleanup chain. Suggested-by: Greg KH Fixes: bee33f22d7c3 ("clocksource/drivers/nxp-pit: Add NXP Automotive s32g2 / s32g3 support") Cc: stable@vger.kernel.org Signed-off-by: WenTao Liang Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260628130700.45680-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 312f85fdd029b5519da6d50a7ee36951ad8a75a8 Author: Matt Turner Date: Mon Aug 3 19:40:46 2026 -0400 alpha: don't leak hardware-fabricated FP exception bits to user space commit bcfe3187412e342b4619efb92c945f073855ebc0 upstream. On EV6 and later the hardware records exception status bits in the FPCR before delivering a software completion trap, and those bits can be wrong for the instruction that trapped. Converting a double that is exactly representable as a subnormal float sets FPCR_UNF even though the result is exact, and an underflow trap additionally sets FPCR_INE even when the emulated operation turns out to be exact. alpha_fp_emul() only wrote the FPCR when soft-fp raised an exception, so whenever it determined that the instruction was exact the fabricated bits stayed in the FPCR and were reported to user space by fetestexcept(). Pass the exception summary register down from do_entArith() so the handler can tell which exceptions the hardware attributed to the trapping instruction, and always write the FPCR. Clear the exceptions that the trap reported but that soft-fp did not raise. EXC_SUM reports only the underflow or overflow when the hardware also set INE, so treat INE as a candidate in that case, and treat a trap with no reported exception as a denormal operand trap, for which the hardware can fabricate INE and UNF as well. Bits that software has already confirmed in ieee_state belong to this or an earlier instruction and are never cleared. The imprecise path passes no summary. There the trap was taken somewhere in the trap shadow, so EXC_SUM is not attribution for the instruction being re-executed -- and only EV6, which traps precisely and so never takes that path, has fabricated bits to clear. For the same reason the clearing is guarded by implver(), matching swcr_update_status(). On an UP1500 (EV68) this takes the glibc math testsuite from 831 failures to 28, the remainder being unrelated to exception status. This belongs with the preceding fix to ieee_swcr_to_fpcr(), and should not be backported without it -- nor it without this. That fix stops FPCR_DNOD being set unconditionally, so denormal operand traps start firing again. Those traps very often find an exact result, which is precisely the case where the old code left the FPCR unwritten and the fabricated bits visible. Applied alone it would make spurious exception flags more common, not less. One case cannot be resolved here: an inexact instruction without the software completion suffix never traps, so its INE reaches the FPCR without being recorded anywhere else. Such a bit is indistinguishable from an INE the hardware fabricated for a trapping instruction, and is lost if an underflow or overflow trap with an exact result follows it. The FPCR is the only record of those instructions and it carries no attribution. The bug predates the git history, so there is no commit to reference in a Fixes tag. Cc: stable@vger.kernel.org # 5.15+ Signed-off-by: Matt Turner Reviewed-by: Magnus Lindholm Tested-by: Magnus Lindholm Link: https://lore.kernel.org/r/20260803-alpha-fp-exceptions-v1-2-c99d75608e60@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Greg Kroah-Hartman commit c25b2aa077d5b6fea4ad0395fbef2b600975b125 Author: FUJITA Tomonori Date: Fri Aug 7 22:05:31 2026 +0900 rust: time: fix as_micros_ceil() rounding near i64::MAX commit ec90dfcf05f02206c280bb59af660bbb3ae177d0 upstream. The ceiling adjustment used saturating_add(NSEC_PER_USEC - 1) before dividing. Once the nanosecond value gets within NSEC_PER_USEC - 1 of i64::MAX the addition saturates to i64::MAX, which drops the ceiling bias and can yield a result one microsecond too small. Fixes: fae0cdc12340 ("rust: time: Introduce Delta type") Reported-by: Miguel Ojeda Closes: https://lore.kernel.org/rust-for-linux/CANiq72mtS0ABA2JnT5tpz6J9c_mnxY+vyPvghV_ukngWvN8F2w@mail.gmail.com/ Signed-off-by: FUJITA Tomonori Acked-by: Andreas Hindborg Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260807130531.1056209-1-tomo@flapping.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 7d00a3ff6244ff81fe694014add88dbbc7bb7e4e Author: Matt Turner Date: Mon Aug 3 19:40:45 2026 -0400 alpha: fix ieee_swcr_to_fpcr setting FPCR_DNOD unconditionally commit 49672d026cc4773608e1222b69b29fd70f41336b upstream. ieee_swcr_to_fpcr() converts the software IEEE trap-enable and status bits kept in thread_info.ieee_state into the hardware FPCR format. It contained: fp |= (~sw & IEEE_TRAP_ENABLE_DNO) << 41; FPCR_DNOD (bit 47) disables denormal operand traps: with it set the hardware handles a denormal operand itself, treating it as zero, instead of trapping for software completion. The intent was to set DNOD when the user has not asked for SIGFPE on denormal operands, but IEEE_TRAP_ENABLE_DNO is clear by default, so ieee_swcr_to_fpcr(0) always set DNOD. Instructions built with the software completion suffix therefore never trapped on a denormal operand. The hardware silently substituted zero and produced wrong results, affecting every program compiled with -mieee and default FPU settings, glibc included. Set FPCR_DNOD only when IEEE_MAP_DMZ is requested, which is exactly the case where flushing denormal inputs to zero is what the user asked for. DNOD then encodes MAP_DMZ, which ieee_fpcr_to_swcr() already recovers from FPCR_DNZ, so drop its attempt to recover IEEE_TRAP_ENABLE_DNO from DNOD; the DNO trap enable lives solely in ieee_state. Both functions are in a uapi header, so the encoding change is visible to userspace, but nothing outside the kernel is known to depend on DNOD carrying the DNO trap enable, and the kernel is the only writer of the FPCR. This must not be backported on its own. Re-enabling denormal operand traps exposes a second bug, fixed in the following patch: those traps usually find an exact result, and for an exact result the emulator did not write the FPCR back, leaving hardware-fabricated exception bits visible to user space. Taken alone this change would make spurious exception flags more common. The bug predates the git history, so there is no commit to reference in a Fixes tag. Cc: stable@vger.kernel.org # 5.15+ Signed-off-by: Matt Turner Reviewed-by: Magnus Lindholm Tested-by: Magnus Lindholm Link: https://lore.kernel.org/r/20260803-alpha-fp-exceptions-v1-1-c99d75608e60@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Greg Kroah-Hartman commit 4628e40c9ca79c7ca6d55ee0d5da1839c2d0b4c7 Author: Fangzhi Zuo Date: Tue Sep 1 10:22:19 2026 -0500 drm/amd/display: Prune per-tile Timing from Apple Studio Display Primary Tile [ Upstream commit 7a4dd08c3f921576c6a7524f60e4f0e4601835d2 ] [why] The Apple Studio Display primary tile advertises both the full 5120x2880 mode and the per-tile 2560x2880 timing. With the secondary tile already hidden from userspace, the stray 2560x2880 mode on the primary connector can still be picked by compositors, defeating the single 5K stream goal. [how] Prune the per-tile timing from the primary connector during get_modes: when the sink carries the disable_second_tile quirk and the connector is the primary tile (tile_h_loc == 0 && tile_v_loc == 0), drop any probed mode matching the advertised tile size (tile_h_size x tile_v_size) so userspace only sees the full 5120x2880 mode. Fixes: 49521be4809d ("drm/amd/display: hide Apple Studio Display secondary tile") Reviewed-by: Wayne Lin Signed-off-by: Fangzhi Zuo Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Adjust for lack of movement from amdgpu_dm.c to amdgpu_dm_connector.c Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit 7d860bed133698eefa7f5f808c7dbce1c2738b96 Author: Jerry Zuo Date: Tue Sep 1 10:22:18 2026 -0500 drm/amd/display: hide Apple Studio Display secondary tile [ Upstream commit 49521be4809d63fe3efb6bc68ee11cb1e1ef3d63 ] The Apple Studio Display exposes a 2x1 tiled panel over two SST DP links. The primary tile advertises the full 5120x2880 mode (with DSC on the bandwidth-sufficient link) while the secondary carries a per-tile 2560x2880 timing on a link without sufficient bandwidth. Report the non-primary tile connector as disconnected during detect so compositors only see the primary DP link and configure a single 5K mode instead of driving both tiled streams independently. Drive the behaviour from an EDID quirk: add a disable_second_tile panel patch that apply_edid_quirks() sets for the affected Apple Studio Display panel IDs (0xAE3A, 0xAE42, 0xAE46), and have detect() hide the secondary tile when the sink carries that quirk. Reviewed-by: Mario Limonciello Reviewed-by: Sun peng Li Signed-off-by: Jerry Zuo Signed-off-by: Wayne Lin Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Adjust for lack of movement from amdgpu_dm.c to amdgpu_dm_connector.c Adjust for lack of analog connector support. Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit c6b915f0df31121524253f1410da7b3dd43e92b7 Author: Timur Kristóf Date: Tue Sep 1 10:22:17 2026 -0500 drm/amd/display: Refactor amdgpu_dm_connector_detect (v2) [ Upstream commit 8223a605744bb471f31018eac9075a539415b16f ] Prepare for polling analog connectors. Document the function better. Signed-off-by: Timur Kristóf Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit a1fa3d1197cc2a5d8d55f9cab8bb07c3367431ec Author: Roman Li Date: Tue Sep 1 10:22:16 2026 -0500 drm/amd/display: Skip PHY SSC reduction on some 8K panels [ Upstream commit 144169e7be0831e09958a906d08d1856751aa6c6 ] [Why] Some 8K displays cannot tolerate the reduced phy ssc value at high link utilization and show corruption or black screen. [How] Add an EDID panel-id quirk to utilize existing skip_phy_ssc_reduction flag. To pass the link into the quirk handler, change the signature of apply_edid_quirks() to take link as an argument. The dev local in dm_helpers_parse_edid_caps() becomes unused and is removed. Fixes: 5fa62c87cffd ("drm/amd/display: Add option to disable PHY SSC reduction on transmitter enable") Reviewed-by: Alex Hung Signed-off-by: Roman Li Signed-off-by: Aurabindo Pillai Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Adjust for lack of HDMI 2.1 FRL in 6.18.y Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit d5c9d19b0ff2f7153532ac238a5e96fed2df315c Author: David Howells Date: Tue May 12 13:33:39 2026 +0100 netfs: Fix missing locking around retry adding new subreqs [ Upstream commit cce18c263e9623872327ba3c956012f73c1179cc ] Fix netfs_retry_read_subrequests() and netfs_retry_write_stream() to take the appropriate lock when adding extra subrequests into stream->subrequests. Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item") Fixes: 288ace2f57c9 ("netfs: New writeback implementation") Closes: https://sashiko.dev/#/patchset/20260425125426.3855807-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-3-dhowells@redhat.com cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit ce493f9261cd3f4bffe2f72481d8c3ee01c559a3 Author: Rong Zhang Date: Sun May 10 04:25:31 2026 +0000 platform/x86: lenovo-wmi-helpers: Fix memory leak in lwmi_dev_evaluate_int() [ Upstream commit 0c3887a134f191723b53e2a47e501b534c8723ee ] lwmi_dev_evaluate_int() leaks output.pointer when retval == NULL (found by sashiko.dev [1]). Fix it by moving `ret_obj = output.pointer' outside of the `if (retval)' block so that it is always freed by the __free cleanup callback. No functional change intended. Reviewed-by: Mark Pearson Fixes: e521d16e76cd ("platform/x86: Add lenovo-wmi-helpers") Cc: stable@vger.kernel.org Link: https://sashiko.dev/#/patchset/20260331181208.421552-1-derekjohn.clark%40gmail.com [1] Signed-off-by: Rong Zhang Signed-off-by: Derek J. Clark Link: https://patch.msgid.link/20260510042546.436874-2-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 2ab18de5ebb11c76bfc8087c5a09fbcccd0dea8a Author: Srinivasan Shanmugam Date: Mon Mar 23 13:02:09 2026 +0530 drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths [ Upstream commit 4ae3e16f4b3bf64140f773629b765d605ee079a9 ] In dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace(). Both functions check: if (!dc_dmub_srv || !dc_dmub_srv->dmub) and then call DC_LOG_ERROR() inside that block. DC_LOG_ERROR() uses dc_dmub_srv->ctx internally. So if dc_dmub_srv is NULL, the logging itself can dereference a NULL pointer and cause a crash. Fix this by splitting the checks. First check if dc_dmub_srv is NULL and return immediately. Then check dc_dmub_srv->dmub and log the error only when dc_dmub_srv is valid. Fixes the below: ../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed 'dc_dmub_srv' could be null (see line 961) ../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed 'dc_dmub_srv' could be null (see line 1166) Fixes: 2631ac1ac328 ("drm/amd/display: add DMUB registers to crash dump diagnostic data.") Fixes: 71ba6b577a35 ("drm/amd/display: Add interface to enable DPIA trace") Cc: Roman Li Cc: Alex Hung Cc: Tom Chung Cc: Dan Carpenter Cc: Aurabindo Pillai Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 24ebaf6676ae4f74f4856eb645959b15e62bc1b4 Author: Christian Brauner Date: Thu Feb 26 14:50:10 2026 +0100 nsfs: tighten permission checks for handle opening [ Upstream commit d2324a9317f00013facb0ba00b00440e19d2af5e ] Even privileged services should not necessarily be able to see other privileged service's namespaces so they can't leak information to each other. Use may_see_all_namespaces() helper that centralizes this policy until the nstree adapts. Link: https://patch.msgid.link/20260226-work-visibility-fixes-v1-2-d2c2853313bd@kernel.org Fixes: 5222470b2fbb ("nsfs: support file handles") Reviewed-by: Jeff Layton Cc: stable@kernel.org # v6.18+ Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit ea150ffa9fc9f78c5cf22e1f7b06b6d016b1017c Author: Daniel Borkmann Date: Wed Apr 1 00:20:19 2026 +0200 bpf: Fix incorrect pruning due to atomic fetch precision tracking [ Upstream commit 179ee84a89114b854ac2dd1d293633a7f6c8dac1 ] When backtrack_insn encounters a BPF_STX instruction with BPF_ATOMIC and BPF_FETCH, the src register (or r0 for BPF_CMPXCHG) also acts as a destination, thus receiving the old value from the memory location. The current backtracking logic does not account for this. It treats atomic fetch operations the same as regular stores where the src register is only an input. This leads the backtrack_insn to fail to propagate precision to the stack location, which is then not marked as precise! Later, the verifier's path pruning can incorrectly consider two states equivalent when they differ in terms of stack state. Meaning, two branches can be treated as equivalent and thus get pruned when they should not be seen as such. Fix it as follows: Extend the BPF_LDX handling in backtrack_insn to also cover atomic fetch operations via is_atomic_fetch_insn() helper. When the fetch dst register is being tracked for precision, clear it, and propagate precision over to the stack slot. For non-stack memory, the precision walk stops at the atomic instruction, same as regular BPF_LDX. This covers all fetch variants. Before: 0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs=r2 stack= before 2: (b7) r2 = 0 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit After: 0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs= stack=-8 before 2: (b7) r2 = 0 mark_precise: frame0: regs= stack=-8 before 1: (7b) *(u64 *)(r10 -8) = r1 mark_precise: frame0: regs=r1 stack= before 0: (b7) r1 = 8 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit Fixes: 5ffa25502b5a ("bpf: Add instructions for atomic_[cmp]xchg") Fixes: 5ca419f2864a ("bpf: Add BPF_FETCH field / create atomic_fetch_add instruction") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260331222020.401848-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5d562153b4719234227f99c2fb529f98a6a44d15 Author: Eric Dumazet Date: Wed Mar 11 12:31:10 2026 +0000 ip_tunnel: adapt iptunnel_xmit_stats() to NETDEV_PCPU_STAT_DSTATS [ Upstream commit 8431c602f551549f082bbfa67f3003f2d8e3e132 ] Blamed commits forgot that vxlan/geneve use udp_tunnel[6]_xmit_skb() which call iptunnel_xmit_stats(). iptunnel_xmit_stats() was assuming tunnels were only using NETDEV_PCPU_STAT_TSTATS. @syncp offset in pcpu_sw_netstats and pcpu_dstats is different. 32bit kernels would either have corruptions or freezes if the syncp sequence was overwritten. This patch also moves pcpu_stat_type closer to dev->{t,d}stats to avoid a potential cache line miss since iptunnel_xmit_stats() needs to read it. Fixes: 6fa6de302246 ("geneve: Handle stats using NETDEV_PCPU_STAT_DSTATS.") Fixes: be226352e8dc ("vxlan: Handle stats using NETDEV_PCPU_STAT_DSTATS.") Signed-off-by: Eric Dumazet Reviewed-by: Guillaume Nault Link: https://patch.msgid.link/20260311123110.1471930-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a8bbb2a60513bf322170903c21462f0bf4f62be2 Author: Rochan Avlur Date: Tue Sep 1 19:36:56 2026 -0600 fuse: wait for FR_FINISHED on abort_on_kill to prevent use-after-free [ Upstream commit 64b0b5cacbd2fea88001464cb712c9dfc795b26e ] The abort_on_kill path in request_wait_answer() calls fuse_abort_conn() and returns without waiting for FR_FINISHED. If fuse_dev_do_write() is concurrently processing the same request (FR_LOCKED set), the caller frees req->args while it is still being accessed, causing a use-after-free. Fix this by jumping to the existing wait_event(FR_FINISHED) instead of returning early. The wait will not hang because fuse_abort_conn() ensures all requests are ended. Reported-by: syzbot+d6540a3fa1626e11360d@syzkaller.appspotmail.com Fixes: 204aa22a686b ("fuse: abort on fatal signal during sync init") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Rochan Avlur Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 5fc3d921512d31839227a2d22a2990de02acefeb Author: Zilin Guan Date: Fri Jan 30 08:44:51 2026 +0000 wifi: ath11k: fix memory leaks in beacon template setup [ Upstream commit ff49eba595df500e4ddccc593088c8a4ab5f2c27 ] The functions ath11k_mac_setup_bcn_tmpl_ema() and ath11k_mac_setup_bcn_tmpl_mbssid() allocate memory for beacon templates but fail to free it when parameter setup returns an error. Since beacon templates must be released during normal execution, they must also be released in the error handling paths to prevent memory leaks. Fix this by using unified exit paths with proper cleanup in the respective error paths. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 3a415daa3e8b ("wifi: ath11k: add P2P IE in beacon template") Fixes: 335a92765d30 ("wifi: ath11k: MBSSID beacon support") Suggested-by: Baochen Qiang Signed-off-by: Zilin Guan Reviewed-by: Vasanthakumar Thiagarajan Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260130084451.110768-1-zilin@seu.edu.cn Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 8527ac1bce87aaabde6755e8e6eb2a9f439d1292 Author: Zilin Guan Date: Fri Jan 16 14:49:19 2026 +0000 wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req() [ Upstream commit c41075ce8cf05ed8c0e7b7efef000dce548ffc42 ] mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected to be freed eventually by mt76_mcu_skb_send_msg(). However, currently if an intermediate function fails before sending, the allocated skb is leaked. Specifically, mt76_connac_mcu_sta_wed_update() and mt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memory leak in the error path. Fix this by explicitly freeing the skb in these error paths. Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak on mt7996_mcu_sta_key_tlv error") made a similar change. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: d1369e515efe ("wifi: mt76: connac: introduce mt76_connac_mcu_sta_wed_update utility routine") Fixes: 6683d988089c ("mt76: connac: move mt76_connac_mcu_add_key in connac module") Fixes: 4f831d18d12d ("wifi: mt76: mt7915: enable WED RX support") Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Zilin Guan Link: https://patch.msgid.link/20260116144919.1482558-1-zilin@seu.edu.cn Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c79ef3342632e71ac8612a2a1cc17ac84dd258b4 Author: Zide Chen Date: Fri Mar 13 10:40:49 2026 -0700 perf/x86/intel/uncore: Fix die ID init and look up bugs [ Upstream commit a16d1ec4dd0cdcf689f324adde6067083bce9099 ] In snbep_pci2phy_map_init(), in the nr_node_ids > 8 path, uncore_device_to_die() may return -1 when all CPUs associated with the UBOX device are offline. Remove the WARN_ON_ONCE(die_id == -1) check for two reasons: - The current code breaks out of the loop. This is incorrect because pci_get_device() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan. - Returning -EINVAL is incorrect, since marking offline buses with die_id == -1 is expected and should not be treated as an error. Separately, when NUMA is disabled on a NUMA-capable platform, pcibus_to_node() returns NUMA_NO_NODE, causing uncore_device_to_die() to return -1 for all PCI devices. As a result, spr_update_device_location(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree. Fix this by using uncore_pcibus_to_dieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux. This requires snbep_pci2phy_map_init() to be added in spr_uncore_pci_init(). Keep uncore_device_to_die() only for the nr_node_ids > 8 case, where NUMA is expected to be enabled. Fixes: 9a7832ce3d92 ("perf/x86/intel/uncore: With > 8 nodes, get pci bus die id from NUMA info") Fixes: 65248a9a9ee1 ("perf/x86/uncore: Add a quirk for UPI on SPR") Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Tested-by: Steve Wahl Link: https://patch.msgid.link/20260313174050.171704-4-zide.chen@intel.com Signed-off-by: Sasha Levin