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