commit dc6160265ffc795a1832bc1424f58291d152c7bb Author: Greg Kroah-Hartman Date: Sun Aug 23 14:20:07 2026 +0200 Linux 6.6.153 Link: https://lore.kernel.org/r/20260820145211.194104353@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Francesco Dolcini Tested-by: Barry K. Nathan Tested-by: Shuah Khan Tested-by: Wentao Guan Link: https://lore.kernel.org/r/20260821142844.249995408@linuxfoundation.org Tested-by: Miguel Ojeda Tested-by: Ron Economos Tested-by: Pavel Machek (CIP) Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Signed-off-by: Greg Kroah-Hartman commit 22709117d9ae95e52673685f98caac7c356a8227 Author: Tengda Wu Date: Mon Aug 3 00:56:39 2026 +0000 ring-buffer: Use current_context for safe per-CPU buffer swap [ Upstream commit f27bdc43077e4fcb5557dfc315ee8d91e741f483 ] The ring_buffer_swap_cpu() function currently checks the per-CPU committing counter to determine if a buffer is actively being written to before performing the swap. However, there exists a race window where this check can be bypassed: ring_buffer_lock_reserve cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_a rb_reserve_next_event rb_start_commit // inc committing if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) {...} __rb_reserve_next rb_move_tail rb_end_commit(cpu_buffer); // dec committing => 0 /* interrupt hits here, successfully swaps! */ local_inc(&cpu_buffer->committing); ring_buffer_unlock_commit cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_b rb_commit rb_end_commit RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing)) // triggers warning The committing counter can temporarily drop to 0 during a single write operation (within rb_move_tail), creating a window where swap can succeed even though the write is still in progress. This leads to inconsistent buffer state and triggers the RB_WARN_ON in rb_commit(). Replace the committing counter check with current_context checks, which are set at the entry of ring_buffer_lock_reserve() and remain valid throughout the entire write operation, providing a reliable indicator of buffer busy state during swap. Cc: stable@vger.kernel.org Fixes: 4239c38fe0b3 ("ring-buffer: Process commits whenever moving to a new page.") Link: https://patch.msgid.link/20260803005640.2445666-2-wutengda@huaweicloud.com Signed-off-by: Tengda Wu Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit cf0bc75d1ca9dfe2cf4f551e5937fbbff291a747 Author: Steven Rostedt Date: Tue May 27 14:57:53 2025 -0400 ring-buffer: Remove jump to out label in ring_buffer_swap_cpu() [ Upstream commit f115d2b70bff2665f67fa8e8dc5ed9452b696c44 ] The function ring_buffer_swap_cpu() has a bunch of jumps to the label out that simply returns "ret". There's no reason to jump to a label that simply returns a value. Just return directly from there. This goes back to almost the beginning when commit 8aabee573dff ("ring-buffer: remove unneeded get_online_cpus") was introduced. That commit removed a put_online_cpus() from that label, but never updated all the jumps to it that now no longer needed to do anything but return a value. Cc: Mathieu Desnoyers Link: https://lore.kernel.org/20250527145753.6b45d840@gandalf.local.home Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Stable-dep-of: f27bdc43077e ("ring-buffer: Use current_context for safe per-CPU buffer swap") Signed-off-by: Sasha Levin commit 171f95d6628633c2e11111f88c9db6f401901ffa Author: Paolo Abeni Date: Sat Feb 1 19:02:51 2025 +0100 net: harmonize tstats and dstats commit d3ed6dee73c560fad0a8e152c8e233b3fb3a2e44 upstream. After the blamed commits below, some UDP tunnel use dstats for accounting. On the xmit path, all the UDP-base tunnels ends up using iptunnel_xmit_stats() for stats accounting, and the latter assumes the relevant (tunnel) network device uses tstats. The end result is some 'funny' stat report for the mentioned UDP tunnel, e.g. when no packet is actually dropped and a bunch of packets are transmitted: gnv2: mtu 1450 qdisc noqueue \ state UNKNOWN mode DEFAULT group default qlen 1000 link/ether ee:7d:09:87:90:ea brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 14916 23 0 15 0 0 TX: bytes packets errors dropped carrier collsns 0 1566 0 0 0 0 Address the issue ensuring the same binary layout for the overlapping fields of dstats and tstats. While this solution is a bit hackish, is smaller and with no performance pitfall compared to other alternatives i.e. supporting both dstat and tstat in iptunnel_xmit_stats() or reverting the blamed commit. With time we should possibly move all the IP-based tunnel (and virtual devices) to dstats. Fixes: c77200c07491 ("bareudp: Handle stats using NETDEV_PCPU_STAT_DSTATS.") Fixes: 6fa6de302246 ("geneve: Handle stats using NETDEV_PCPU_STAT_DSTATS.") Fixes: be226352e8dc ("vxlan: Handle stats using NETDEV_PCPU_STAT_DSTATS.") Signed-off-by: Paolo Abeni Reviewed-by: Guillaume Nault Link: https://patch.msgid.link/2e1c444cf0f63ae472baff29862c4c869be17031.1738432804.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2fdf8b07bee5ef99ec77773a6be05fbb8ee5cdb9 Author: Christian Brauner Date: Fri Jul 10 11:33:03 2026 +0200 binfmt_misc: use exe_file_deny_write_access() for the interpreter clone commit fa5990ca8fd917003e526036bcc50413edb9722c upstream. For MISC_FMT_OPEN_FILE entries load_misc_binary() clones the registered interpreter file and denies write access to the clone via plain deny_write_access(). The clone is installed as bprm->interpreter and later released by the exec machinery through exe_file_allow_write_access() which skips the i_writecount increment for files with FMODE_FSNOTIFY_HSM set. The deny and allow side can therefore come to different conclusions when pre-content watches are in play: if a pre-content watch is added to the interpreter after registration every subsequent exec through that entry takes a write denial on the clone that is never paired with a write allowance, driving the interpreter inode's i_writecount further down with each exec and leaving the interpreter unwritable even after the entry and all its users are gone. Take the write denial via exe_file_deny_write_access() so both sides of the pairing base their decision on the same file mode, and propagate failure instead of silently ignoring it: an interpreter that is concurrently open for writing now fails the exec with ETXTBSY, exactly like an interpreter freshly opened via open_exec() would. Link: https://patch.msgid.link/20260710-work-binfmt_misc-locking-v3-2-a162f7cb58d6@kernel.org Fixes: 0357ef03c94e ("fs: don't block write during exec on pre-content watched files") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 1fc9f6d2c7c9fdb341bfe8ca449c990632299ea6 Author: Baul Lee Date: Mon Jul 27 07:03:42 2026 +0900 net/x25: fix use-after-free of the socket by its timers commit 2195424c3da2ef1829a63b807e3a900a90e57d85 upstream. The x25 timers are armed with mod_timer() and cancelled with timer_delete(), so a pending timer holds no reference on the socket and a cancel does not wait for a callback already running on another CPU. x25_heartbeat_expiry() also rearms unconditionally, so it can reinstall sk->sk_timer after __x25_destroy_socket() has passed its cancel point. The following __sock_put() frees the socket while the timer is still queued, and the next expiry uses freed memory. KASAN reports a slab-use-after-free on the kmalloc-2k object freed by close(). timer_delete_sync() cannot be used here: x25_heartbeat_expiry() and x25_timer_expiry() both reach the cancels from inside the timer they would wait on, through __x25_destroy_socket() and x25_disconnect(). Arm the timers with sk_reset_timer() and cancel them with sk_stop_timer() so that an armed timer owns a reference, and release it in both expiry handlers. Rearm the heartbeat only while sk_hashed(sk) is still true, since __x25_destroy_socket() unlinks the socket before dropping it. Arm the deferred destroy timer the same way and drop its reference in x25_destroy_timer(). Reproduced on net with KASAN, with the heartbeat period shortened so the window recurs. With this patch the reproducer no longer triggers a report and /proc/net/x25 drains. Discovered by XBOW, triaged by Baul Lee Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260726220342.47245-1-baul.lee@xbow.com Signed-off-by: Jakub Kicinski [ adjusted context due to `del_timer()` not yet renamed to `timer_delete()` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 74365aef5bf226259608093c318cb4029c026329 Author: Gao Xiang Date: Wed Aug 12 21:11:43 2026 +0800 erofs: fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms [ Upstream commit a64d500b0078e16e9abb25baca4dee1dbc9054fc ] CONFIG_NR_CPUS doesn't define on some UP platforms (e.g. arm), so this can cause make oldconfig to loop indefinitely when CONFIG_SMP=n: $ make ARCH=arm allmodconfig $ sed -i "/CONFIG_SMP=y/d" .config $ sed -i "/CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS.*/d" .config EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW) EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW) ... Let's guard NR_CPUS with SMP instead of using a hardcoded arbitrary CPU uplimit here, similar to commit a3344078101c ("mm: make SPLIT_PTE_PTLOCKS depend on SMP"). The initial report from SJ Park was for m68k [1] (m68k is the only arch without NR_CPUS in Kconfig), and that got fixed in commit 1fd495ef09ee ("m68k: Define NR_CPUS to 1") Reported-by: SJ Park Link: https://lore.kernel.org/all/anuyFHLUGDjZWY4K@XiangdeMacBook-Pro.local/T/#u [1] Closes: https://lore.kernel.org/r/20260728065447.91511-1-sj@kernel.org Reported-by: Guenter Roeck Closes: https://lore.kernel.org/r/87853c96-cc8f-49e6-81b1-02bfe409e372@roeck-us.net Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size") Signed-off-by: Gao Xiang Tested-by: SJ Park Tested-by: Geert Uytterhoeven Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ec5a552f4b2d841c6c021752450716e1a9676661 Author: Jamal Hadi Salim Date: Sun Aug 9 05:44:18 2026 -0400 net/sched: cls_bpf: reject dev-bound programs bound to a different device [ Upstream commit 120977e2c096deea4e866e4273be9220b957c29e ] cls_bpf_prog_from_efd() obtained a SCHED_CLS program via bpf_prog_get_type_dev() but never verified that a device-bound (offloaded) program's bound netdev matches the TC netdev the classifier is being attached to. This let a program loaded with prog_ifindex for device A be attached via cls_bpf + skip_sw to device B; deleting device A then destroyed the program's offload state while it was still attached to device B, triggering a netdevsim WARN (panic with panic_on_warn=1). Mirror the XDP attach path (net/core/dev.c) and reject the attach with -EINVAL when a dev-bound program's bound device does not match the target device. Fixes: 2b3486bc2d23 ("bpf: Introduce device-bound XDP programs") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Acked-by: Daniel Borkmann Link: https://patch.msgid.link/20260809094418.901607-1-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 551688b410d3fb0dae7739724422f268cd9446d6 Author: Siddharth Vadapalli Date: Fri Aug 7 16:47:37 2026 +0530 net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG [ Upstream commit 36a05d2820077bb3955acb8111e1041d39148037 ] On the packet reception path, the ID of the MAC Port on which the packet was received, is embedded in the RX DMA Descriptor's metadata. The ID is extracted using the helper function cppi5_desc_get_tags_ids() which fills in the 16-bit Source Tag into the 'port_id' variable. However, it is only the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID, while the upper 8-bits are Hardware-Reserved and carry an arbitrary value. With the existing logic, sporadic kernel crash is observed due to the subsequent driver code accessing out-of-bound memory because of an invalid port_id. Hence, fix the port_id extraction logic to use only the lower 8-bits of the Source Tag as the MAC Port ID. Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver") Signed-off-by: Siddharth Vadapalli Reviewed-by: Chintan Vankar Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260807111738.2055900-1-s-vadapalli@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f60c71deb17ea5ab4c97294c7abb8dc5b513b57b Author: Uwe Kleine-König Date: Fri Jul 31 11:49:49 2026 +0200 m68k: Define NR_CPUS to 1 [ Upstream commit 1fd495ef09eef96169a379a749c24b5e69974bb8 ] This fixes a Kconfig warning fs/erofs/Kconfig:137:warning: range is invalid which originates from EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS using NR_CPUS which up to now didn't exist for ARCH=m68k. All other architectures define this symbol, so fix the outlier. [geert] This also fixes: - CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS being set to the literal NR_CPUS instead of a number by automatic configs like "make allmodconfig" or "make olddefconfig", - An infinite loop in manual configs like "make oldconfig" when CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS is not present or has an invalid value in your existing .config. Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size") Signed-off-by: Uwe Kleine-König Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260731094950.1988084-2-ukleinek@kernel.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 2930f1b49133ec7fd8e7ec867449e7ea42e5c5e7 Author: Christoph Hellwig Date: Tue Oct 17 16:04:42 2023 +0200 m68k: use the coherent DMA code for coldfire without data cache [ Upstream commit 9e28bf8bdf2177a88bd6648fc741bc0280e08af8 ] Coldfire cores configured without a data cache are DMA coherent and should thus simply use the simple coherent version of dma-direct. Introduce a new COLDFIRE_COHERENT_DMA Kconfig symbol as a convenient short hand for such configurations, and a M68K_NONCOHERENT_DMA symbol for all cases where we need to build non-coherent DMA infrastructure to simplify the Kconfig and code conditionals. Not building the non-coherent DMA code slightly reduces the code size for such configurations. Numers for m5249evb_defconfig below: text data bss dec hex filename 2896158 401052 65392 3362602 334f2a vmlinux.before 2895166 400988 65392 3361546 334b0a vmlinux.after Signed-off-by: Christoph Hellwig Reviewed-by: Greg Ungerer Acked-by: Geert Uytterhoeven Tested-by: Greg Ungerer Stable-dep-of: 1fd495ef09ee ("m68k: Define NR_CPUS to 1") Signed-off-by: Sasha Levin commit 5904c758e0e95506d458931e69bc59fb8c901560 Author: Christoph Hellwig Date: Thu Oct 5 09:05:36 2023 +0200 dma-direct: add a CONFIG_ARCH_HAS_DMA_ALLOC symbol [ Upstream commit 2c8ed1b960fb97c82ede5afc974329bfdb457f5f ] Instead of using arch_dma_alloc if none of the generic coherent allocators are used, require the architectures to explicitly opt into providing it. This will used to deal with the case of m68knommu and coldfire where we can't do any coherent allocations whatsoever, and also makes it clear that arch_dma_alloc is a last resort. Signed-off-by: Christoph Hellwig Reviewed-by: Robin Murphy Reviewed-by: Greg Ungerer Tested-by: Greg Ungerer Stable-dep-of: 1fd495ef09ee ("m68k: Define NR_CPUS to 1") Signed-off-by: Sasha Levin commit 19d114b93c94bdef70496f26685c2a6b242f41b3 Author: Zhang Changzhong Date: Fri Aug 7 15:50:38 2026 +0800 net/sched: cls_u32: skip hash tables in u32_bind_class() [ Upstream commit 6d3724e616faf952c3adcf8414fc21a828ef3709 ] u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode through the walker callback. u32_bind_class() unconditionally casts the passed fh to tc_u_knode and accesses &n->res, so when fh is actually a tc_u_hnode, which has no tcf_result member, this results in a slab-out-of-bounds read of res->classid in tc_cls_bind_class(). The issue can be reproduced with the following commands: tc qdisc add dev lo root handle 1: hfsc tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit Fix this by skipping hash tables via the TC_U32_KEY(handle) check. Fixes: 07d79fc7d94e ("net_sched: add reverse binding for tc class") Signed-off-by: Zhang Changzhong Acked-by: Jamal Hadi Salim Link: https://patch.msgid.link/1786089038-36366-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 91d55fd1fdb85c8371ca8793c788ea7d5192383a Author: Jamal Hadi Salim Date: Sun Aug 9 05:09:28 2026 -0400 net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain [ Upstream commit f60b396ee174206fe08ebf997d16cd3801b77b22 ] tcf_action_exec() handles TC_ACT_GOTO_CHAIN by first checking rcu_access_pointer(a->goto_chain) and then calling tcf_action_goto_chain_exec(), which does a second, independent rcu_dereference_bh(a->goto_chain) read and immediately dereferences chain->filter_chain. A concurrent tcf_action_set_ctrlact() (e.g. the gact replace path) can clear a->goto_chain between the two reads, so the second read returns NULL and tcf_action_goto_chain_exec() dereferences NULL. Fix the race by doing a single rcu_dereference_bh() read of a->goto_chain in tcf_action_exec(), checking it once for NULL, and passing the resulting chain pointer into tcf_action_goto_chain_exec(). This turns the split check/use into a single check/use on one value. Fixes: ee3bbfe806cd ("net/sched: let actions use RCU to access 'goto_chain'") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Davide Caratti Link: https://patch.msgid.link/20260809090928.868186-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a857e3408be07aa1e388cac331a263704b5200c8 Author: Victor Nogueira Date: Sat Dec 16 17:44:36 2023 -0300 net: sched: Add initial TC error skb drop reasons [ Upstream commit 4cf24dc8934074725042c0bd10b91f4d4b5269bb ] Continue expanding Daniel's patch by adding new skb drop reasons that are idiosyncratic to TC. More specifically: - SKB_DROP_REASON_TC_COOKIE_ERROR: An error occurred whilst processing a tc ext cookie. - SKB_DROP_REASON_TC_CHAIN_NOTFOUND: tc chain lookup failed. - SKB_DROP_REASON_TC_RECLASSIFY_LOOP: tc exceeded max reclassify loop iterations Signed-off-by: Victor Nogueira Reviewed-by: Simon Horman Signed-off-by: David S. Miller Stable-dep-of: f60b396ee174 ("net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain") Signed-off-by: Sasha Levin commit d54e7ec85166484e50efffa741f3b540ad28907b Author: Victor Nogueira Date: Sat Dec 16 17:44:34 2023 -0300 net: sched: Move drop_reason to struct tc_skb_cb [ Upstream commit fb2780721ca5e9f78bbe4544b819b929a982df9c ] Move drop_reason from struct tcf_result to skb cb - more specifically to struct tc_skb_cb. With that, we'll be able to also set the drop reason for the remaining qdiscs (aside from clsact) that do not have access to tcf_result when time comes to set the skb drop reason. Signed-off-by: Victor Nogueira Acked-by: Daniel Borkmann Reviewed-by: Simon Horman Signed-off-by: David S. Miller Stable-dep-of: f60b396ee174 ("net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain") Signed-off-by: Sasha Levin commit 14f679a8d2ddc7835cdfb77edd2e8a0eb62f81c7 Author: Yan Zhai Date: Mon Dec 4 11:33:28 2023 -0800 packet: add a generic drop reason for receive [ Upstream commit 2f57dd94bdef083855366138646b26b05f410d99 ] Commit da37845fdce2 ("packet: uses kfree_skb() for errors.") switches from consume_skb to kfree_skb to improve error handling. However, this could bring a lot of noises when we monitor real packet drops in kfree_skb[1], because in tpacket_rcv or packet_rcv only packet clones can be freed, not actual packets. Adding a generic drop reason to allow distinguish these "clone drops". [1]: https://lore.kernel.org/netdev/CABWYdi00L+O30Q=Zah28QwZ_5RU-xcxLFUK2Zj08A8MrLk9jzg@mail.gmail.com/ Fixes: da37845fdce2 ("packet: uses kfree_skb() for errors.") Suggested-by: Eric Dumazet Suggested-by: Willem de Bruijn Signed-off-by: Yan Zhai Reviewed-by: Eric Dumazet Reviewed-by: Willem de Bruijn Link: https://lore.kernel.org/r/ZW4piNbx3IenYnuw@debian.debian Signed-off-by: Jakub Kicinski Stable-dep-of: f60b396ee174 ("net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain") Signed-off-by: Sasha Levin commit b72e44dc038f25779926f26d8826a97345032b14 Author: Jamal Hadi Salim Date: Sat Oct 28 13:16:10 2023 -0400 net, sched: Fix SKB_NOT_DROPPED_YET splat under debug config [ Upstream commit 40cb2fdfed342e7e578d551a073687789f698d89 ] Getting the following splat [1] with CONFIG_DEBUG_NET=y and this reproducer [2]. Problem seems to be that classifiers clear 'struct tcf_result::drop_reason', thereby triggering the warning in __kfree_skb_reason() due to reason being 'SKB_NOT_DROPPED_YET' (0). Fixed by disambiguating a legit error from a verdict with a bogus drop_reason [1] WARNING: CPU: 0 PID: 181 at net/core/skbuff.c:1082 kfree_skb_reason+0x38/0x130 Modules linked in: CPU: 0 PID: 181 Comm: mausezahn Not tainted 6.6.0-rc6-custom-ge43e6d9582e0 #682 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014 RIP: 0010:kfree_skb_reason+0x38/0x130 [...] Call Trace: __netif_receive_skb_core.constprop.0+0x837/0xdb0 __netif_receive_skb_one_core+0x3c/0x70 process_backlog+0x95/0x130 __napi_poll+0x25/0x1b0 net_rx_action+0x29b/0x310 __do_softirq+0xc0/0x29b do_softirq+0x43/0x60 [2] ip link add name veth0 type veth peer name veth1 ip link set dev veth0 up ip link set dev veth1 up tc qdisc add dev veth1 clsact tc filter add dev veth1 ingress pref 1 proto all flower dst_mac 00:11:22:33:44:55 action drop mausezahn veth0 -a own -b 00:11:22:33:44:55 -q -c 1 Ido reported: [...] getting the following splat [1] with CONFIG_DEBUG_NET=y and this reproducer [2]. Problem seems to be that classifiers clear 'struct tcf_result::drop_reason', thereby triggering the warning in __kfree_skb_reason() due to reason being 'SKB_NOT_DROPPED_YET' (0). [...] [1] WARNING: CPU: 0 PID: 181 at net/core/skbuff.c:1082 kfree_skb_reason+0x38/0x130 Modules linked in: CPU: 0 PID: 181 Comm: mausezahn Not tainted 6.6.0-rc6-custom-ge43e6d9582e0 #682 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014 RIP: 0010:kfree_skb_reason+0x38/0x130 [...] Call Trace: __netif_receive_skb_core.constprop.0+0x837/0xdb0 __netif_receive_skb_one_core+0x3c/0x70 process_backlog+0x95/0x130 __napi_poll+0x25/0x1b0 net_rx_action+0x29b/0x310 __do_softirq+0xc0/0x29b do_softirq+0x43/0x60 [2] #!/bin/bash ip link add name veth0 type veth peer name veth1 ip link set dev veth0 up ip link set dev veth1 up tc qdisc add dev veth1 clsact tc filter add dev veth1 ingress pref 1 proto all flower dst_mac 00:11:22:33:44:55 action drop mausezahn veth0 -a own -b 00:11:22:33:44:55 -q -c 1 What happens is that inside most classifiers the tcf_result is copied over from a filter template e.g. *res = f->res which then implicitly overrides the prior SKB_DROP_REASON_TC_{INGRESS,EGRESS} default drop code which was set via sch_handle_{ingress,egress}() for kfree_skb_reason(). Commit text above copied verbatim from Daniel. The general idea of the patch is not very different from what Ido originally posted but instead done at the cls_api codepath. Fixes: 54a59aed395c ("net, sched: Make tc-related drop reason more flexible") Reported-by: Ido Schimmel Signed-off-by: Jamal Hadi Salim Link: https://lore.kernel.org/netdev/ZTjY959R+AFXf3Xy@shredder Reviewed-by: Simon Horman Signed-off-by: David S. Miller Stable-dep-of: f60b396ee174 ("net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain") Signed-off-by: Sasha Levin commit 69c66cf557906354a4d4b1f6103790a850b84120 Author: Daniel Borkmann Date: Mon Oct 9 11:26:55 2023 +0200 net, sched: Add tcf_set_drop_reason for {__,}tcf_classify [ Upstream commit 39d08b91646d83e87f7cbcd846b3ef33b1a53b79 ] Add an initial user for the newly added tcf_set_drop_reason() helper to set the drop reason for internal errors leading to TC_ACT_SHOT inside {__,}tcf_classify(). Right now this only adds a very basic SKB_DROP_REASON_TC_ERROR as a generic fallback indicator to mark drop locations. Where needed, such locations can be converted to more specific codes, for example, when hitting the reclassification limit, etc. Signed-off-by: Daniel Borkmann Cc: Jamal Hadi Salim Cc: Victor Nogueira Link: https://lore.kernel.org/r/20231009092655.22025-2-daniel@iogearbox.net Signed-off-by: Jakub Kicinski Stable-dep-of: f60b396ee174 ("net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain") Signed-off-by: Sasha Levin commit 5599966042e05567ea299ec9c78a09952bb5283b Author: Daniel Borkmann Date: Mon Oct 9 11:26:54 2023 +0200 net, sched: Make tc-related drop reason more flexible [ Upstream commit 54a59aed395ce0f4177b5212e5746a6462de3ad9 ] Currently, the kfree_skb_reason() in sch_handle_{ingress,egress}() can only express a basic SKB_DROP_REASON_TC_INGRESS or SKB_DROP_REASON_TC_EGRESS reason. Victor kicked-off an initial proposal to make this more flexible by disambiguating verdict from return code by moving the verdict into struct tcf_result and letting tcf_classify() return a negative error. If hit, then two new drop reasons were added in the proposal, that is SKB_DROP_REASON_TC_INGRESS_ERROR as well as SKB_DROP_REASON_TC_EGRESS_ERROR. Further analysis of the actual error codes would have required to attach to tcf_classify via kprobe/kretprobe to more deeply debug skb and the returned error. In order to make the kfree_skb_reason() in sch_handle_{ingress,egress}() more extensible, it can be addressed in a more straight forward way, that is: Instead of placing the verdict into struct tcf_result, we can just put the drop reason in there, which does not require changes throughout various classful schedulers given the existing verdict logic can stay as is. Then, SKB_DROP_REASON_TC_ERROR{,_*} can be added to the enum skb_drop_reason to disambiguate between an error or an intentional drop. New drop reason error codes can be added successively to the tc code base. For internal error locations which have not yet been annotated with a SKB_DROP_REASON_TC_ERROR{,_*}, the fallback is SKB_DROP_REASON_TC_INGRESS and SKB_DROP_REASON_TC_EGRESS, respectively. Generic errors could be marked with a SKB_DROP_REASON_TC_ERROR code until they are converted to more specific ones if it is found that they would be useful for troubleshooting. While drop reasons have infrastructure for subsystem specific error codes which are currently used by mac80211 and ovs, Jakub mentioned that it is preferred for tc to use the enum skb_drop_reason core codes given it is a better fit and currently the tooling support is better, too. With regards to the latter: [...] I think Alastair (bpftrace) is working on auto-prettifying enums when bpftrace outputs maps. So we can do something like: $ bpftrace -e 'tracepoint:skb:kfree_skb { @[args->reason] = count(); }' Attaching 1 probe... ^C @[SKB_DROP_REASON_TC_INGRESS]: 2 @[SKB_CONSUMED]: 34 ^^^^^^^^^^^^ names!! Auto-magically. [...] Add a small helper tcf_set_drop_reason() which can be used to set the drop reason into the tcf_result. Signed-off-by: Daniel Borkmann Cc: Jamal Hadi Salim Cc: Victor Nogueira Link: https://lore.kernel.org/netdev/20231006063233.74345d36@kernel.org Reviewed-by: Jakub Kicinski Link: https://lore.kernel.org/r/20231009092655.22025-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski Stable-dep-of: f60b396ee174 ("net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain") Signed-off-by: Sasha Levin commit 1fc70b3d513bafb16b17540178870ef46e81c0bb Author: Eric Dumazet Date: Mon Aug 10 15:04:47 2026 +0000 af_packet: Don't send zero-byte data in tpacket_snd(). [ Upstream commit 6bcd76c134c55c697148acb5c0194e9666abdf84 ] syzbot reported a WARNING in __dev_queue_xmit() triggered via tpacket_snd(): skb_assert_len WARNING: at include/linux/skbuff.h:2753 skb_assert_len WARNING: at __dev_queue_xmit+0x21bc/0x4970 net/core/dev.c:4781 Call Trace: dev_queue_xmit include/linux/netdevice.h:3448 [inline] packet_xmit+0x243/0x310 net/packet/af_packet.c:276 tpacket_snd net/packet/af_packet.c:2907 [inline] packet_sendmsg+0x28d6/0x4eb0 net/packet/af_packet.c:3134 When sending 0-byte packets via TPACKET ring buffer on devices with no hard header (e.g. dev->hard_header_len == 0), tpacket_fill_skb() populates an skb with skb->len == 0 and returns 0. tpacket_snd() then forwards this empty skb to packet_xmit(), causing __dev_queue_xmit() to hit skb_assert_len(skb). Similar checks exist in packet_snd() via commit dc633700f00f ("net/af_packet: check len when min_header_len equals to 0") and in packet_sendmsg_spkt() via commit 6a341729fb31 ("af_packet: Don't send zero-byte data in packet_sendmsg_spkt()."). Return -EINVAL in tpacket_fill_skb() when skb->len is zero to reject zero-length packets in tpacket_snd(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+30b93b6845b19cc38581@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a79e807.01d0871a.3a0d52.00ac.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Willem de Bruijn Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260810150447.1220864-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b4ef887bee4d3c177adac5d1eab8b2de31b08ac3 Author: Rosen Penev Date: Thu Aug 6 16:32:31 2026 -0700 ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers [ Upstream commit f12afefb7b01f94d6d66d397f323a9914edbf70e ] The irq handlers take a struct device pointer and call dev_get_drvdata() to obtain the driver data. However, the driver data is only set at the end of probe, after devm_request_irq(), so an interrupt taken in between causes the handlers to pass a NULL pointer to readl() and crash. Pass the private data directly as the devm_request_irq() argument instead of the device pointer, matching what the handlers expect. 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/20260806233231.30631-1-rosenp@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 06c2a53604fa1dc4820063828d7dadb3675b7af8 Author: Chuck Lever Date: Thu Aug 6 20:44:07 2026 -0400 net/tls: Fail tls_sw_splice_read() after a failed async decrypt [ Upstream commit 976df67f463db1fddaf2a32fb04f57ad2891a23d ] When an async decrypt fails, tls_decrypt_done() records the error in ctx->async_wait.err and calls tls_err_abort(), which stores it in sk_err. tls_sw_recvmsg() and tls_sw_read_sock() each read async_wait.err once they hold the reader lock and fail the call: a record that did not authenticate breaks the connection. tls_sw_splice_read() has no such check, and sk_err does not stand in for one. tls_rx_rec_wait() tests sk_err only inside the loop it skips whenever a record is already parsed, and the first reader to reach sock_error() clears it, while async_wait.err persists. A splice therefore keeps delivering records on a connection that recvmsg() and read_sock() refuse to read. Read async_wait.err in tls_sw_splice_read() as the other two readers do. Fixes: f314bfee81b1 ("tls: rx: return the already-copied data on crypto error") Reviewed-by: Jakub Kicinski Signed-off-by: Chuck Lever Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260806-tls-splice-crypto-fix-v1-1-a2624005a286@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e451e20adb869a983a21dda158625f024142e61f Author: Wei Fang Date: Fri Aug 7 14:34:04 2026 +0800 net: packet: fix wrong transport_header when sending VLAN-tagged frame [ Upstream commit 01fdecc0480d916c799dbee584833a4a37e94d06 ] In packet_parse_headers(), when processing a VLAN-tagged frame, skb_set_network_header() is called to advance network_header past the VLAN tag to the inner protocol header. skb_probe_transport_header() is then called with skb->protocol still set to the outer VLAN EtherType (e.g. ETH_P_8021Q), while nhoff (derived from skb_network_offset()) already points past the VLAN tag to the inner protocol header. In __skb_flow_dissect(), proto is initialized to ETH_P_8021Q and nhoff points past the VLAN tag. When the dissector hits case ETH_P_8021Q, it reads a struct vlan_hdr at nhoff via __skb_header_pointer(), but that offset contains the inner protocol header (e.g. an IP header). The bytes are misinterpreted as a VLAN header, yielding a garbage encapsulated EtherType that matches no known protocol. The dissector returns false, so skb_probe_transport_header() never calls skb_set_transport_header(), leaving transport_header at its uninitialized sentinel value (~0U). Move skb_probe_transport_header() to before skb_set_network_header(). At the time skb_probe_transport_header() is called, network_header still points to the VLAN header, so nhoff correctly points to the VLAN header. The flow dissector can then parse the VLAN header, extract the inner EtherType, and advance nhoff to the inner protocol header, allowing transport_header to be set correctly. Fixes: dfed913e8b55 ("net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO") Assisted-by: WChat:claude-opus-4-8 Signed-off-by: Wei Fang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260807063405.688780-2-wei.fang@oss.nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 28afc87bd8da0b3348bbbd834c8a89e83712cf5e Author: Eric Dumazet Date: Thu Aug 6 14:19:38 2026 +0000 macvlan: inherit needed_headroom and needed_tailroom from lowerdev [ Upstream commit cef51860becd9700217c81732ca1eb1ea6ed6fe1 ] macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events. Fixes: b863ceb7ddce ("[NET]: Add macvlan driver") Reported-by: Tangxin Xie Closes: https://lore.kernel.org/netdev/CANn89i+1EW-sFNK8xoq98gMbPCeLS7e=+rs9gHfLg5Wj+4x0sw@mail.gmail.com/T/#m16adf0ff972cbfd8066c3a8e656e75eaeb12d021 Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260806141938.287660-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f3c17ff65f54781cde696e16a6c577615ed735aa Author: Eric Dumazet Date: Thu Aug 6 10:38:57 2026 +0000 ipvlan: inherit needed_headroom and needed_tailroom from phy_dev [ Upstream commit e16e960d55a40d36bd7c2494cc005e757dc9a1ef ] ipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying phy_dev (or stacked lower device) requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events. Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Reported-by: syzbot+1f9fd0f4b601cf88d6e6@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a720a21.40259c87.584f4.04bb.GAE@google.com/T/#u Reported-by: Tangxin Xie Closes: https://lore.kernel.org/netdev/CANn89i+1EW-sFNK8xoq98gMbPCeLS7e=+rs9gHfLg5Wj+4x0sw@mail.gmail.com/T/#mcc6307f115e500df23ea2980d5669fe95f20b6b4 Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260806103857.115541-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ccc33e1b2edb4d4b57211f6e8c8e40387f6a7f3b Author: Florian Westphal Date: Thu Aug 6 16:17:50 2026 +0200 netfilter: ipset: let destroy callbacks adjust ext mem size [ Upstream commit 490937b88cb592cc0c5367758edd700fd5abd15c ] For bitmap this change makes no difference, because destructors are called synchronously. List type however calls them via call_rcu() so accounting decrement can happen after list_set_flush() set ext_size to 0. 'set->elements = 0' can be removed for the same reason in the list type case, it calls 'set->elements--' for each element. Fixes: 9e41f26a505c ("netfilter: ipset: Count non-static extension memory for userspace") Suggested-by: Jozsef Kadlecsik Signed-off-by: Florian Westphal Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit eada630d0ae3e9a5370b5468e389da6fe2081337 Author: Florian Westphal Date: Thu Aug 6 15:53:41 2026 +0200 netfilter: ipset: fix list type element drift bug [ Upstream commit 4cbd69766b35a089664cadb1f613bb85f7ef77a9 ] If list_set_uadd() calls list_set_replace() to swap an expired entry, the element count remains the same, therefore the increment must be elided. Fixes: 702b71e7c666 ("netfilter: ipset: Add element count to all set types header") Link: https://sashiko.dev/#/patchset/20260806101947.2802-1-fw%40strlen.de Signed-off-by: Florian Westphal Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d37917e7bebe078f3c17e47fd6fc1c9f6e8497b2 Author: Jérémy Jean Date: Sat Aug 8 12:40:02 2026 +0000 netfilter: flowtable: publish GC-visible tuple last [ Upstream commit 2014ac62df9d45bb9a004a043e85df7be09ed780 ] nf_flow_table_iterate() only treats original-direction tuple nodes as owning entries. Publishing the original node first lets GC observe and free a flow while flow_offload_add() is still inserting the reply node. Publish the reply node first and the original node last so GC never sees a partially installed flow. KASAN can trigger slab-use-after-free read and write reports in the flowtable/rhashtable path (rht_deferred_worker, jhash, flow_offload_del, flow_offload_lookup, etc.). Fixes: ac2a66665e23 ("netfilter: add generic flow table infrastructure") Signed-off-by: Jérémy Jean Assisted-by: Codex:gpt-5 Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 17c132e18ca5d1641ddbaed8d0e6ecfd1d38fa0b Author: Alexey Velichayshiy Date: Thu Aug 6 19:11:38 2026 +0300 netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort path [ Upstream commit d02f592064347e0c1e0d84f24941ad338838cc48 ] In nft_flow_rule_offload_abort(), WARN_ON_ONCE(err) is triggered on every error during rollback, including -ENOMEM. Memory allocation failures are expected under low-memory conditions and do not indicate a kernel bug. Trace for example: nft_flow_offload_chain() // FLOW_BLOCK_BIND nft_flow_block_chain() nft_chain_offload_cmd() nft_block_offload_cmd() ->ndo_setup_tc() nsim_setup_tc() flow_block_cb_setup_simple() flow_block_cb_alloc() // fails to -ENOMEM The warning was reproduced on the 5.10 stable kernel under memory pressure via fault injection, but the underlying bug exists in mainline as well, as demonstrated by the ENOMEM trace above. The following splat was triggered during nf_tables transaction processing: WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Modules linked in: CPU: 0 PID: 8567 Comm: syz-executor.0 Not tainted 5.10.260-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] RIP: 0010:nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Call Trace: nf_tables_commit+0x3bd/0x4bd0 net/netfilter/nf_tables_api.c:8604 nfnetlink_rcv_batch+0xb1e/0x1f20 net/netfilter/nfnetlink.c:509 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:579 [inline] nfnetlink_rcv+0x3b3/0x420 net/netfilter/nfnetlink.c:597 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x6cd/0xa00 net/netfilter/af_netlink.c:1340 netlink_sendmsg+0x906/0xe10 net/netfilter/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x155/0x190 net/socket.c:663 ____sys_sendmsg+0x705/0x870 net/socket.c:2379 ___sys_sendmsg+0x100/0x170 net/socket.c:2433 __sys_sendmsg+0xe9/0x1c0 net/socket.c:2462 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Change the condition to WARN_ON_ONCE(err && err != -ENOMEM) so that warnings are only emitted for unexpected errors. This aligns with the common kernel practice of not warning on -ENOMEM. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 63b48c73ff56 ("netfilter: nf_tables_offload: undo updates if transaction fails") Signed-off-by: Alexey Velichayshiy Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit b891e7a6bb06e0f6560e5932665ac660acd12225 Author: Xiang Mei (Microsoft) Date: Wed Jul 22 22:38:32 2026 +0000 netfilter: ipset: fix refcount race between list:set GC and swap [ Upstream commit 0c88868271653537ed443272dd8e7d13634d214b ] __ip_set_put_byindex() resolved the index to a set pointer under RCU, then took ip_set_ref_lock in __ip_set_put() to decrement set->ref. ip_set_swap() holds that same lock while swapping both the ip_set_list slots and the two sets' ref counters, so it can interleave between the dereference and the lock acquisition, leaving the caller to decrement a set whose reference already moved to the other index and hit BUG_ON(set->ref == 0). list_set_gc() reaches this from timer softirq, which the nfnl mutex does not serialize against swap: an expiring list:set member calls list_set_del() -> ip_set_put_byindex() while IPSET_CMD_SWAP runs on the referenced sets. Resolve the index and decrement under ip_set_ref_lock, as ip_set_swap() already does, keeping the refcount tied to the index rather than to a stale set pointer. kernel BUG at net/netfilter/ipset/ip_set_core.c:685! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ip_set_put_byindex (net/netfilter/ipset/ip_set_core.c:870) Call Trace: list_set_del (net/netfilter/ipset/ip_set_list_set.c:159) set_cleanup_entries (net/netfilter/ipset/ip_set_list_set.c:181) list_set_gc (net/netfilter/ipset/ip_set_list_set.c:578) call_timer_fn (kernel/time/timer.c:1748) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2374) run_timer_softirq (kernel/time/timer.c:2405) Kernel panic - not syncing: Fatal exception in interrupt Fixes: 9076aea76538 ("netfilter: ipset: Increase the number of maximal sets automatically") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9f4a626420c71f1dab31e75b0f03c48321fa2485 Author: Herbert Xu Date: Mon Jul 20 11:34:21 2026 +1000 crypto: ccm - Set rfc4309 maxauthsize from child [ Upstream commit 438f4896f78f69ec73d5f32d2c024193f1223569 ] Set the maxauthsize of rfc4309 using that of the child algorithm. Fixes: 4a49b499dfa0 ("[CRYPTO] ccm: Added CCM mode") Reported-by: Seohyeon Maeng Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4f1dde17b1222f5c9c208c454c0283210c938c54 Author: Jon Hunter Date: Tue Jul 28 16:50:59 2026 +0100 arm64: tegra: Add EL2 virtual timer interrupt for Tegra194 [ Upstream commit a7c28483fd57dd0e1487024af70622315320774b ] Commit d87773de9efe ("clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE") updated the ARM arch timer driver to use the virtual timer by default if the CPU is running at EL2 with VHE enabled. If the CPU is running at EL2 with VHE enabled but there is no interrupt provided for the virtual timer, then the following warning is displayed: arch_timer: [Firmware Bug]: VHE-capable CPU without EL2 virtual timer interrupt This warning is observed on Tegra194 platforms. Tegra194 SoC includes NVIDIA Carmel ARM v8.2 CPUs and support an EL2 virtual timer. Fix the above warning by adding the PPI for the EL2 virtual timer interrupt for Tegra194. Fixes: 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit f3a874a903053c53fb53ba287ea9eacda69c68e8 Author: Lorenzo Stoakes (ARM) Date: Thu Jul 30 11:55:47 2026 +0100 mm/huge_memory: fix huge_zero_pfn race commit 33192a26cddea7a7e4ca66e5c3eebd36fa8be2bb upstream. Patch series "mm/huge_memory: fix huge_zero_pfn race", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and huge_zero_refcount writes. * Be set non-zero only AFTER huge_zero_[pfn, folio] are set to valid values so installation of the huge zero folio on read page fault ensures concurrent is_huge_zero_*() calls correctly identify the huge zero folio. * Be set zero only BEFORE huge_zero_[pfn, folio] are set to NULL and ~0UL respectively, and atomically. Establish these by: * Only setting huge_zero_refcount to zero or an absolute value in the huge_zero_lock critical section in get_huge_zero_folio() and shrink_huge_zero_folio_scan(), and always updating atomically there and elsewhere. * Using atomic_set_release(&huge_zero_refcount) in get_huge_zero_folio() after huge_zero_[pfn, folio] are set. This is paired with atomic_inc_not_zero() to ensure atomic_inc_not_zero() only observes a non-zero value if huge_zero_[pfn, folio] are set. * Using atomic_cmpxchg() in shrink_huge_zero_folio_scan() (as before) to ensure that it is set zero only when equal to 1 and set atomically. * atomic_cmpxchg() being fully ordered ensures this is done prior to huge_zero_[folio, pfn] being set to NULL and ~0UL respectively. Eliminate the retry loop in get_huge_zero_folio() as the atomic_cmpxchg() in shrink_huge_zero_folio_scan() is now performed under the lock, and replace with an equally locked atomic_inc() to set the reference count should the caller be raced on huge zero folio installation. folio_put() naturally implies a full memory barrier so its ordering is maintained correctly. The huge zero folio also cannot be released except when the shrinker does so as it is non-LRU and non-rmappable. Note that only the huge zero shrinker (via shrink_huge_zero_folio_scan()) can actually set huge_zero_refcount to zero, which is the count of mm's which have at least one huge zero folio installed plus one shrinker pin. Additionally convert a BUG_ON() to a VM_WARN_ON_ONCE(). Link: https://lore.kernel.org/20260730-fix-refcounted-huge-zero-v2-0-c5d8a41b317f@kernel.org Link: https://lore.kernel.org/20260730-fix-refcounted-huge-zero-v2-1-c5d8a41b317f@kernel.org Fixes: 3b77e8c8cde5 ("mm/thp: make is_huge_zero_pmd() safe and quicker") Signed-off-by: Lorenzo Stoakes (ARM) Reported-by: Hengbin Zhang Closes: https://lore.kernel.org/linux-mm/20260727154001.4102341-1-uqbarz@gmail.com/ Suggested-by: David Hildenbrand (Arm) Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Hannes Reinecke Cc: Hugh Dickins Cc: Kiryl Shutsemau Cc: Lance Yang Cc: Liam R. Howlett Cc: Nico Pache Cc: Pankaj Raghav Cc: Ryan Roberts Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton [ adapted folio API (`huge_zero_folio`, `folio_pfn`, `folio_put`) to pre-6.11 page naming (`huge_zero_page`, `page_to_pfn`, `__free_pages`) ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 28afde1edbd8b20058cbf4d75fb57876471ec334 Author: Paolo Bonzini Date: Wed Aug 19 10:55:56 2026 -0400 KVM: SVM: Serialize accesses to the owner and mirror list with separate lock [ Upstream commit 1d78d33275ef2a16c6d080910b291d0a97a0e613 ] Interaction between KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM and KVM_CAP_VM_COPY_ENC_CONTEXT_FROM can cause two separate issues: - in sev_migrate_from(), when the destination KVM is a mirror, the mirror entry is moved from the source's list to the owner's mirror_vms list, without holding the owner's lock unlike other writers of the owner's mirror list (sev_vm_copy_enc_context_from(), sev_vm_destroy()). A concurrent COPY or destroy can race with sev_migrate_from() and corrupt the list. - In sev_vm_destroy(), the *owner* is still active and could receive concurrently a KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM that causes sev->enc_context_owner to change. In this case the incorrect VM receives kvm_put_kvm(). The second issue needs particular care because the owner could disappear altogether (even though the race window is impossibly small) between reading it and locking it. There is thus no way to perform the checks under the owner lock without putting struct kvm under SLAB_TYPESAFE_BY_RCU (which would allow kvm_get_kvm_safe() under RCU critical section). It is much simpler to just use a global lock, since the critical sections are so small and the new lock is always a leaf lock. Fixes: b2125513dfc0 ("KVM: SEV: Allow SEV intra-host migration of VM with mirrors") Cc: stable@vger.kernel.org Reported-by: Shen Yongchao Link: https://lore.kernel.org/kvm/tencent_625C0F42824E542C72B34733392AF2C49709@qq.com/ Link: https://lore.kernel.org/kvm/tencent_DDC4E4352EC91CAC05A9A8F4E55E8C96730A@qq.com/ Signed-off-by: Paolo Bonzini [ Replaced `to_kvm_sev_info(src->enc_context_owner)` with `&to_kvm_svm(src->enc_context_owner)->sev_info` since that helper doesn't exist, and adjusted context for absent `vmsa_features`/`ghcb_version` fields. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 76df4edf7d61ecb711bc517ff4c20a5e85c4e9f7 Author: Lorenzo Stoakes (ARM) Date: Wed Aug 19 07:14:04 2026 -0400 mm/ptdump: always stabilise against page table freeing using init_mm [ Upstream commit 27c32e5538344b13c1505a08861e04620c125d47 ] Previous commits have established the invariant that kernel page table freeing is performed while an mmap read lock on init_mm is held, which fixes races between ptdump and kernel page table freeing over init_mm. However, x86 and arm64 can perform a ptdump over an mm other than init_mm via ptdump_walk_pgd() and since kernel memory ranges are shared across non-kernel mm's, this means that the race still exists for these cases. Fix this by acquiring a nested mmap write lock for init_mm in ptdump_walk_pgd(). This is safe as we take this after mmap write locking the mm, and nothing acquires the init_mm lock first before locking an arbitrary mm, so no deadlock is possible. Also update walk_page_range_debug() to assert that init_mm is write locked, add a comment explaining why and remove some redundant code, and eliminate the unnecessary and confusing invocation of walk_kernel_page_table_range(). We can safely remove the non-NULL check for walk.mm, as the mmap lock asserts would NULL pointer deref if it was (and of course no callers do this). The first point at which ptdump can race kernel page table freeing is commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table"), so we target this in the Fixes tag. Link: https://lore.kernel.org/20260723-series-vmap-race-fix-v6-4-8cc77dcc0018@kernel.org Fixes: b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table") Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Mike Rapoport (Microsoft) Acked-by: David Hildenbrand (Arm) Reviewed-by: Kiryl Shutsemau Cc: Andy Lutomirski Cc: "Borah, Chaitanya Kumar" Cc: "Borislav Petkov (AMD)" Cc: Catalin Marinas Cc: Dave Hansen Cc: David Carlier Cc: Dev Jain Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Liam R. Howlett Cc: Michal Hocko Cc: Peter Zijlstra Cc: Ryan Roberts Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Toshi Kani Cc: "Uladzislau Rezki (Sony)" Cc: Vlastimil Babka Cc: Will Deacon Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8d7f560f4b0482d469de962fbe4b59c37561052e Author: Lorenzo Stoakes (ARM) Date: Fri Aug 14 22:30:16 2026 -0400 mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF [ Upstream commit 26444eb71465c9934d9d418ef69c43f61185329b ] Patch series "mm: fix UAF caused by race between ptdump and vmap pgtable freeing", v6. Kernel page table walkers fall into two broad categories - those ranges where no exclusion is required via walk_kernel_page_table_range_lockless() and those where exclusion is required via walk_kernel_page_table_range() or walk_page_range_debug(). The former category is used only by arm64 arch code operating on ranges it both wholly owns and does not concurrently write. The latter category consists of kernel page table walkers operating on ranges that are wholly owned (but which need exclusion against concurrent writers). The lock used for exclusion is the mmap lock, and for kernel ranges this is the mmap lock on init_mm. ptdump is a special case being both the only user of walk_page_range_debug(), and the only case in which it walks ranges it does not own. This presents a problem, as page tables may be freed under ptdump. And indeed there is a use-after-free bug in the kernel as a result, which this series addresses. vmap promotes page tables to huge leaf entries where possible, freeing the lower page table when it does. It does this with no meaningful locks held against concurrent ptdump walks. As a result, use-after-free can currently occur. This series addresses the issue by having the vmap huge promotion logic acquire the mmap read lock while both setting the huge page table entry and freeing the prior leaf page table. The ptdump code already acquires the mmap write lock, so by doing so we ensure that the ptdump walker only ever observes either the huge page table entry or the existing page table entry, and nothing is freed underneath it. A mitigation for this issue was already applied for arm64 in commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), which this series has to deal with carefully. This mitigation resolves the issue by acquiring the mmap read lock on init_mm on vmap page table free if a ptdump is in progress. However the fix in this series would cause a deadlock if we were to simply apply it for arm64 without also reverting the change. This is because vmap may acquire the read lock before ptdump attempts to acquire the write lock, which then gets queued, and rwsem starvation rules mean that the (unacknowledged) nested mmap read lock in the arm64 code would also block, meaning the original read lock is never released and thus deadlock. This series works around this by #ifndef CONFIG_ARM64'ing the mmap read lock in vmap logic, then partially reverting commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), keeping the enablement of huge vmap support, and removing the ifdeffery with the partial revert patch. There are related issues that are also addressed in this series: * x86 page attribute logic, specifically Change Page Attributes (CPA), implements a feature whereby huge ranges can be collapsed into huge leaf entries. This can similarly cause a UAF when done in parallel with a ptdump walk, so similarly acquire the init_mm mmap lock to avoid this. * The CPA logic allows concurrent page table manipulation and CPA collapse, meaning the former risks accessing a page table the latter frees. Fix this by acquiring mmap write lock on init_mm across the whole CPA collapse operation and read lock on the page table manipulation. * x86 and arm64 permit walks of non-kernel mm's (both allowing efi mm walks, and in x86's case arbitrary mm's), so we ensure kernel mappings remain stable by locking the init_mm as well as the mm being walked. The ordering of patches is established for both strict dependencies (the arm64 partial revert in particular has to be done after the vmap changes) and logical ones (the non-kernel mm fix only makes sense once the vmap/CPA fixes are in place). This patch (of 3): Currently there is a nasty race between ptdump and vmap when attempting to map a huge P4D, PUD or PMD entry: * ptdump walks kernel page table ranges it doesn't own. * When vmap maps ranges it tries to promotes existing ones to huge page tables in vmap_try_huge_[p4d,pud,pmd]() at P4D, PUD and PMD level, freeing the lower page table in [p4d,pud,pmd]_free_[pud,pmd,pte]_page() when it succeeds. Both of these things can happen at the same time and as a result ptdump can access a freed page table, resulting in a use-after-free and memory corruption. This is possible because while ptdump_walk_pgd() holds both the mem hotplug lock and the mmap write lock before invoking walk_page_range_debug(), vmap takes no relevant locks at all. Fix this by holding the mmap read lock in vmap_try_huge_*() when freeing page tables. The read lock is sufficient: ptdump is the only walker that must be excluded and it holds the mmap write lock. Other holders of the read lock may run concurrently, but each exclusively owns the range it operates on and cannot reach the page tables freed here. We also hold the lock while assigning the huge page table entry, which means page table walkers observe only the huge or non-huge page table entry. We use a trylock to prevent ptdump from blocking vmap making forward progress. This is fine because it's an optimisation in any case, and thus the vmap can safely proceed regardless. All other kernel page table walkers that touch vmalloc ranges either exclusively own the memory walked or acquire the mmap lock, so this correctly excludes those walkers. One wrinkle here is commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), which addresses the issue for arm64 only by explicitly acquiring the mmap read lock on kernel page table freeing should a concurrent ptdump be in progress. This is problematic as vmap may acquire the mmap read lock prior to ptdump attempting to acquire an mmap write lock, leading to a deadlock when the mmap read lock is slept upon on page table freeing due to rwsem anti-starvation. We work around this by predicating the mmap lock being taken on !CONFIG_ARM64 for the time being. With this patch applied, a follow up will partially revert commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump") and at that stage remove the arm64 ifdeffery. We also update walk_page_range_debug() to assert the mmap write lock unconditionally and update the comment here to reflect this change. The issue has existed as long as ptdump was available and vmap freed page tables when promoting to a huge leaf entry, that is, since commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table") for huge ioremap, and commit 121e6f3258fe ("mm/vmalloc: hugepage vmalloc mappings") for huge vmalloc. Since the former is the earlier of the two we choose that for our Fixes tag. We also define a guard class for mmap_read_trylock() so we can use cleanup.h to make the scope handling cleaner in the implementation. This patch is based on work by David Carlier (linked), with gratitude! Link: https://lore.kernel.org/20260723-series-vmap-race-fix-v6-0-8cc77dcc0018@kernel.org Link: https://lore.kernel.org/20260723-series-vmap-race-fix-v6-1-8cc77dcc0018@kernel.org Fixes: b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table") Signed-off-by: Lorenzo Stoakes (ARM) Reported-by: syzbot+fd95a72470f5a44e464c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a287988.39669fcc.33b062.00a0.GAE@google.com/T/ Link: https://lore.kernel.org/linux-mm/20260706203128.162335-1-devnexen@gmail.com/ Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: Dev Jain Acked-by: David Hildenbrand (Arm) Reviewed-by: Kiryl Shutsemau Cc: Cc: Andy Lutomirski Cc: "Borah, Chaitanya Kumar" Cc: "Borislav Petkov (AMD)" Cc: Catalin Marinas Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Liam R. Howlett Cc: Michal Hocko Cc: Peter Zijlstra Cc: Ryan Roberts Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Toshi Kani Cc: "Uladzislau Rezki (Sony)" Cc: Vlastimil Babka Cc: Will Deacon Signed-off-by: Andrew Morton [ added the missing `DEFINE_GUARD(mmap_read_lock, ...)` base class and dropped the `page_owner.h` include context absent from this tree ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 56a45fdbe5b254d952bdfd9891be3330b831ff0d Author: Lorenzo Stoakes Date: Fri Aug 14 22:30:15 2026 -0400 mm/pagewalk: split walk_page_range_novma() into kernel/user parts [ Upstream commit 96d81e4766f9e88b66a0502b5a7f34a4c20ac754 ] walk_page_range_novma() is rather confusing - it supports two modes, one used often, the other used only for debugging. The first mode is the common case of traversal of kernel page tables, which is what nearly all callers use this for. Secondly it provides an unusual debugging interface that allows for the traversal of page tables in a userland range of memory even for that memory which is not described by a VMA. It is far from certain that such page tables should even exist, but perhaps this is precisely why it is useful as a debugging mechanism. As a result, this is utilised by ptdump only. Historically, things were reversed - ptdump was the only user, and other parts of the kernel evolved to use the kernel page table walking here. Since we have some complicated and confusing locking rules for the novma case, it makes sense to separate the two usages into their own functions. Doing this also provide self-documentation as to the intent of the caller - are they doing something rather unusual or are they simply doing a standard kernel page table walk? We therefore establish two separate functions - walk_page_range_debug() for this single usage, and walk_kernel_page_table_range() for general kernel page table walking. The walk_page_range_debug() function is currently used to traverse both userland and kernel mappings, so we maintain this and in the case of kernel mappings being traversed, we have walk_page_range_debug() invoke walk_kernel_page_table_range() internally. We additionally make walk_page_range_debug() internal to mm. Link: https://lkml.kernel.org/r/20250605135104.90720-1-lorenzo.stoakes@oracle.com Signed-off-by: Lorenzo Stoakes Acked-by: Mike Rapoport (Microsoft) Acked-by: Qi Zheng Reviewed-by: Oscar Salvador Reviewed-by: Suren Baghdasaryan Reviewed-by: Vlastimil Babka Acked-by: David Hildenbrand Cc: Albert Ou Cc: Alexandre Ghiti Cc: Barry Song Cc: Huacai Chen Cc: Jann Horn Cc: Jonas Bonn Cc: Liam Howlett Cc: Michal Hocko Cc: Muchun Song Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Stafford Horne Cc: Stefan Kristiansson Cc: WANG Xuerui Signed-off-by: Andrew Morton Stable-dep-of: 26444eb71465 ("mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 898a44d811cf0ddc34b0f59e286da439a57e166c Author: Pierre-Eric Pelloux-Prayer Date: Fri Aug 14 14:42:05 2026 -0400 drm/amdgpu: move debug_vm handling to amdgpu_cs_parser_fini [ Upstream commit d8726ef11512754a68c0ab53c57634a569b8feff ] The commit referenced below restarts the CS if the validation is still in progress. When debug_vm is enabled, all BOs from the CS are invalidated so we will hit an infinite loop. To avoid that, defer BO invalidation to amdgpu_cs_parser_fini. Fixes: 59720bfd8c6d ("drm/amdgpu: restart the CS if some parts of the VM are still invalidated") Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 8c990ee9daa295462df24982ce6878db997a380a) Cc: stable@vger.kernel.org [ adjusted `adev->debug_vm` back to the global `amdgpu_vm_debug` param and restored the `adev` argument to `amdgpu_vm_bo_invalidate()` calls ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9efc767335234cf7a892e46d45cd453b711421e7 Author: Yang Wang Date: Wed Aug 12 18:16:25 2026 -0400 drm/amd/pm: fix pptable use-after-free [ Upstream commit bb493058c35c8676e48269ab6732688ea733d23c ] amdgpu_dpm_get_pp_table() returns a pointer to a driver-owned power table after dropping adev->pm.mutex. The sysfs path then copies from that pointer. A concurrent pp_table write can replace and free the allocation during the copy, causing a use-after-free. Change the DPM interface to copy into caller-provided storage while the mutex is held. Keep the size-only query for attribute discovery without exposing the driver-owned pointer. Fixes: 1684d3ba4885 ("drm/amd/amdgpu: change pptable output format from ASCII to binary") Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit f6eed7acfd30099ef7baeb6ba45bb59daad80631) Cc: stable@vger.kernel.org [ kept 6.18's existing `if (!pp_funcs->get_pp_table) return 0;` guard instead of upstream's SR-IOV/SCPM `-EOPNOTSUPP` guard and dropped the `default_attr_update()` hunk whose `pp_table` branch doesn't exist yet ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 50cfece0b1c02010bdd69d1a19993c016d253c0f Author: Yang Wang Date: Wed Aug 12 17:54:08 2026 -0400 drm/amd/pm: fix torn gpu metrics reads [ Upstream commit 048f4541b71fb19645fb79d6e62e6e4da23a4035 ] amdgpu_dpm_get_gpu_metrics() returns a pointer to the shared metrics cache after dropping adev->pm.mutex. The sysfs path then copies from that pointer. Another reader can refresh the cache in place during the copy and return a snapshot containing data from two generations. Pass caller-provided storage through the DPM interface and copy the metrics while the mutex is held. This keeps the cache pointer private and makes each sysfs read observe one complete sample. Fixes: 25c933b1c4fc ("drm/amd/powerplay: add new sysfs interface for retrieving gpu metrics(V2)") Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit 862333bb48693ecafcae25af0c9d9ec31015ac77) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 584a5d96b6ebf93dceaa78daa037e5f2e84cdf2d Author: Tu Nguyen Date: Wed Aug 12 11:50:58 2026 -0400 can: rcar_canfd: change the initializing flow for clocks and resets [ Upstream commit bef9004c5b91debfceaea2841855a4ebe81ff2b3 ] Testing CANFD on RZ/G3E shows that many registers do not reset to their initial values with the current flow of deasserting resets first and then enabling clocks. Based on the HW manual, clocks should be supplied first and the resets deasserted afterward. section 7.4.3 Procedure for Activating Modules: RZ/G2L section 4.4.9.3 Procedure for Starting up Units: RZ/G3E So, update the order of the initializing flow for resets and clocks to match the hardware manual, resetting all CANFD registers to their initial values. Also update rcar_canfd_global_deinit() to assert resets before disabling clocks, so the teardown path mirrors the new init ordering. Fixes: 76e9353a80e9 ("can: rcar_canfd: Add support for RZ/G2L family") Signed-off-by: Tu Nguyen Signed-off-by: Biju Das Tested-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/20260625135216.130450-1-biju.das.jz@bp.renesas.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 441e9c33284c17949ae1d968ba5a0b235c8b7999 Author: Jonas Gorski Date: Wed Aug 12 05:50:53 2026 -0400 i2c: iproc: reset bus after timeout if START_BUSY is stuck [ Upstream commit 98f2e9e6d6f91a6abb43f166b244b428ba85fa2b ] If a transaction times out, the START_BUSY signal can stay up, and subsequent transactaction attempts will fail as the bus is still considered busy. I can easily trigger this by attempting to read from an address with no device, e.g. when running i2cdetect. After the first read times out, all subsequent read attempts return busy. To get to a working state again, the controller needs to be reset to clear the START_BUSY signal. So check for START_BUSY still asserted on a timeout, and do reset in case it is, This is also done by the original non-upstream iproc-smbus driver implementation [1]. Works around situations like: bcm-iproc-2c 1803b000.i2c: transaction timed out bcm-iproc-2c 1803b000.i2c: bus is busy bcm-iproc-2c 1803b000.i2c: bus is busy bcm-iproc-2c 1803b000.i2c: bus is busy bcm-iproc-2c 1803b000.i2c: bus is busy bcm-iproc-2c 1803b000.i2c: bus is busy ... where the bus never recovers after a timeout. [1] https://github.com/opencomputeproject/onie/blob/master/patches/kernel/3.2.69/driver-iproc-smbus.patch Fixes: e6e5dd3566e0 ("i2c: iproc: Add Broadcom iProc I2C Driver") Signed-off-by: Jonas Gorski Cc: # v4.0+ Acked-by: Ray Jui Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260717085507.34209-1-jonas.gorski@bisdn.de Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b95dd3225eea59febef5333d3ebc9aa57b1987c0 Author: Wolfram Sang Date: Wed Aug 12 05:50:52 2026 -0400 i2c: bcm-iproc: remove printout on handled timeouts [ Upstream commit 796e2c260187e32530cf343546ba1cdf2e2f5491 ] I2C and SMBus timeouts are not something the user needs to be informed about on controller level. The client driver may know if that really is a problem and give more detailed information to the user. The controller should just pass this information upwards. Remove the printout. Signed-off-by: Wolfram Sang Signed-off-by: Andi Shyti Stable-dep-of: 98f2e9e6d6f9 ("i2c: iproc: reset bus after timeout if START_BUSY is stuck") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bb01c51950c3ff3c76acdd54b85ab38ccc2a8bb4 Author: Eric Dumazet Date: Wed Aug 12 05:11:27 2026 -0400 vxlan: use pskb_network_may_pull() for transmit path header pulls [ Upstream commit b9553558b48db54ac9273e6b98d7263ef5c1a329 ] In vxlan_xmit(), arp_reduce(), and vxlan_mdb_entry_skb_get(), pskb_may_pull() was being called to verify the availability of network layer headers (ARP, IPv6/ND, IP/IPv6 MDB keys). However, during transmit skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, len) only checks len bytes from skb->data rather than skb_network_offset(skb) + len, which can leave part of the network header in non-linear frags. Replace these remaining pskb_may_pull() calls with pskb_network_may_pull() to properly account for the MAC header offset. Fixes: e4f67addf158 ("add DOVE extensions for VXLAN") Fixes: f564f45c4518 ("vxlan: add ipv6 proxy support") Fixes: 0f83e69f44bf ("vxlan: Add MDB data path support") Signed-off-by: Eric Dumazet Cc: stable@vger.kernel.org Reviewed-by: Vadim Fedorenko Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260723144249.759100-6-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1db9041e91ac574f1cecc0e98e69ac35832e8088 Author: Guillaume Nault Date: Wed Aug 12 05:11:26 2026 -0400 vxlan: Handle stats using NETDEV_PCPU_STAT_DSTATS. [ Upstream commit be226352e8dc77d3313c096b2d8e7f69bf6980fc ] VXLAN uses the TSTATS infrastructure (dev_sw_netstats_*()) for RX and TX packet counters. It also uses the device core stats (dev_core_stats_*()) for RX and TX drops. Let's consolidate that using the DSTATS infrastructure, which can handle both packet counters and packet drops. Statistics that don't fit DSTATS are still updated atomically with DEV_STATS_INC(). While there, convert the "len" variable of vxlan_encap_bypass() to unsigned int, to respect the types of skb->len and dev_dstats_[rt]x_add(). Signed-off-by: Guillaume Nault Link: https://patch.msgid.link/145558b184b3cda77911ca5682b6eb83c3ffed8e.1733313925.git.gnault@redhat.com Signed-off-by: Jakub Kicinski Stable-dep-of: b9553558b48d ("vxlan: use pskb_network_may_pull() for transmit path header pulls") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 72496cf871aa212f500321f9c6c1d9539064a07c Author: Guillaume Nault Date: Wed Aug 12 05:11:25 2026 -0400 vrf: Make pcpu_dstats update functions available to other modules. [ Upstream commit 18eabadd73ae60023ab05e376246bd725fb0c113 ] Currently vrf is the only module that uses NETDEV_PCPU_STAT_DSTATS. In order to make this kind of statistics available to other modules, we need to define the update functions in netdevice.h. Therefore, let's define dev_dstats_*() functions for RX and TX packet updates (packets, bytes and drops). Use these new functions in vrf.c instead of vrf_rx_stats() and the other manual counter updates. While there, update the type of the "len" variables to "unsigned int", so that there're aligned with both skb->len and the new dstats update functions. Signed-off-by: Guillaume Nault Link: https://patch.msgid.link/d7a552ee382c79f4854e7fcc224cf176cd21150d.1733313925.git.gnault@redhat.com Signed-off-by: Jakub Kicinski Stable-dep-of: b9553558b48d ("vxlan: use pskb_network_may_pull() for transmit path header pulls") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7806ff0e8a4d99a6846a805923416bb8c253f21b Author: Jeremy Kerr Date: Wed Aug 12 05:11:24 2026 -0400 net: core,vrf: Change pcpu_dstat fields to u64_stats_t [ Upstream commit fa59dc2f6fc616fde3941f62ccd4adcaa21ccd47 ] The pcpu_sw_netstats and pcpu_lstats structs both contain a set of u64_stats_t fields for individual stats, but pcpu_dstats uses u64s instead. Make this consistent by using u64_stats_t across all stats types. The per-cpu dstats are only used by the vrf driver at present, so update that driver as part of this change. Signed-off-by: Jeremy Kerr Reviewed-by: Simon Horman Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20240607-dstats-v3-1-cc781fe116f7@codeconstruct.com.au Signed-off-by: Jakub Kicinski Stable-dep-of: b9553558b48d ("vxlan: use pskb_network_may_pull() for transmit path header pulls") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 73e7998c3361c247aa76114d63ece5d6986f6931 Author: Breno Leitao Date: Wed Aug 12 05:11:23 2026 -0400 vxlan: Do not alloc tstats manually [ Upstream commit e28c5efc31397af17bc5a7d55b963f59bcde0166 ] With commit 34d21de99cea9 ("net: Move {l,t,d}stats allocation to core and convert veth & vrf"), stats allocation could be done on net core instead of in this driver. With this new approach, the driver doesn't have to bother with error handling (allocation failure checking, making sure free happens in the right spot, etc). This is core responsibility now. Remove the allocation in the vxlan driver and leverage the network core allocation instead. Signed-off-by: Breno Leitao Reviewed-by: Subbaraya Sundeep Link: https://lore.kernel.org/r/20240311112437.3813987-1-leitao@debian.org Signed-off-by: Jakub Kicinski Stable-dep-of: b9553558b48d ("vxlan: use pskb_network_may_pull() for transmit path header pulls") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bbd63ba7961c6a78558eae9ec8b3e77ccf06aa9b Author: Dawid Osuchowski Date: Tue Aug 11 20:15:39 2026 -0400 ice: fix VF interrupts cleanup [ Upstream commit fb096882095e5a8d6b5159e43793d4a38a0c5b1f ] When a virtual function sends an IRQ map command, the PF will set up interrupts according to that request. However, because these interrupts are never reset, the next time Virtual Function initializes, the interrupts are still enabled for a given VF, which leads to performance degradation in certain cases due to interrupts being unexpectedly enabled and thus causing interrupt floods. Cc: stable@vger.kernel.org Fixes: 1071a8358a28 ("ice: Implement virtchnl commands for AVF support") Suggested-by: Vladimir Medvedkin Reviewed-by: Aleksandr Loktionov Signed-off-by: Dawid Osuchowski Reviewed-by: Simon Horman Tested-by: Patryk Holda Signed-off-by: Tony Nguyen [ changed the file path for the `ice_vf_ena_rxq_interrupt` hunk from `ice/virt/queues.c` to `ice_virtchnl.c`, which predates the upstream directory split ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dd9ba32169e73a3c3ba595cf1de1f4c69ceafb3c Author: Christian Brauner Date: Tue Aug 11 20:09:47 2026 -0400 binfmt_misc: restore write access when removing an entry [ Upstream commit db1856ea9196cf6e015d12199a34c0b9313c7bfa ] Registering an entry with the MISC_FMT_OPEN_FILE flag opens the interpreter via open_exec() which denies write access to it for as long as the entry exists. Removing the entry closes the interpreter file via filp_close() but never restores write access, leaving the inode's i_writecount permanently negative. Opening the interpreter for writing keeps failing with ETXTBSY long after the entry is gone until the inode is evicted from the inode cache. Commit 90f601b497d7 ("binfmt_misc: restore write access before closing files opened by open_exec()") fixed the same imbalance in the error path of bm_register_write() but the actual removal path has been leaking the write denial since the introduction of the flag. Restore write access in put_binfmt_handler() before closing the interpreter file. Link: https://patch.msgid.link/20260710-work-binfmt_misc-locking-v3-1-a162f7cb58d6@kernel.org Fixes: 948b701a607f ("binfmt_misc: add persistent opened binary handler for containers") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bf5ed2ef5cdb7b47ce606e3d48ea6eb803b31503 Author: Amir Goldstein Date: Tue Aug 11 20:09:46 2026 -0400 fs: don't block write during exec on pre-content watched files [ Upstream commit 0357ef03c94ef835bd44a0658b8edb672a9dbf51 ] Commit 2a010c412853 ("fs: don't block i_writecount during exec") removed the legacy behavior of getting ETXTBSY on attempt to open and executable file for write while it is being executed. This commit was reverted because an application that depends on this legacy behavior was broken by the change. We need to allow HSM writing into executable files while executed to fill their content on-the-fly. To that end, disable the ETXTBSY legacy behavior for files that are watched by pre-content events. This change is not expected to cause regressions with existing systems which do not have any pre-content event listeners. Signed-off-by: Amir Goldstein Acked-by: Christian Brauner Signed-off-by: Jan Kara Link: https://patch.msgid.link/20241128142532.465176-1-amir73il@gmail.com Stable-dep-of: db1856ea9196 ("binfmt_misc: restore write access when removing an entry") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 04958dba44dc795dc79ce2fcbc117821bbbd6542 Author: Matt Fleming Date: Tue Aug 11 14:56:26 2026 -0400 veth: convert frag_list skbs before running XDP [ Upstream commit d0d6415963040c401e7a7e4e482a698ba52448cb ] A frag_list skb can reach veth with data_len set but nr_frags zero. veth_convert_skb_to_xdp_buff() only converts skbs that are shared, locked, have frags[], or do not have enough headroom. It later uses skb_is_nonlinear() to decide whether to set XDP_FLAGS_HAS_FRAGS and xdp_frags_size. That exposes frag_list data to XDP as if it were stored in frags[], but frags[] is empty. AF_XDP copy mode can then trust the bogus XDP fragment metadata, walk an empty fragment entry, and crash in memcpy() from __xsk_rcv(). Route non-linear skbs through skb_pp_cow_data() before exposing them to XDP, and only advertise XDP frags when the resulting skb has frags[]. skb_copy_bits() already handles frag_list input, and skb_pp_cow_data() builds frags[] output with skb_add_rx_frag(), which is the representation XDP multi-buffer expects. Fixes: 718a18a0c8a6 ("veth: Rework veth_xdp_rcv_skb in order to accept non-linear skb") Cc: stable@vger.kernel.org Signed-off-by: Matt Fleming Reviewed-by: Toke Høiland-Jørgensen Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260722191925.2192070-1-matt@readmodwrite.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 577443530cb592d5782a1f79847411a9363a65c8 Author: Chengfeng Ye Date: Tue Aug 11 08:15:26 2026 -0400 net: pktgen: fix proc entry use-after-free [ Upstream commit 817ff6efdb7f484ea547218e11e17d8e43daa3b4 ] pktgen_change_name() replaces pkt_dev->entry while holding t->if_lock. pktgen_remove_device() removes the same entry before _rem_dev_from_if_list() takes that lock. This allows the following interleaving: CPU 0 (NETDEV_CHANGENAME) CPU 1 (kpktgend) if_lock(t) proc_remove(pkt_dev->entry) proc_remove(pkt_dev->entry) pkt_dev->entry = proc_create_data(...) if_unlock(t) The kthread can pass the stale proc_dir_entry to proc_remove() after the rename path has freed it. A reproducer with a widened race window reports: BUG: KASAN: slab-use-after-free in proc_remove+0x78/0x80 Read of size 8 at addr ffff8881478fea70 by task kpktgend_0/67 Call Trace: proc_remove+0x78/0x80 pktgen_remove_device.isra.0+0x11c/0x4c0 pktgen_thread_worker+0x1214/0x6bc0 kthread+0x2c6/0x3b0 Allocated by task 95: __proc_create+0x204/0x790 proc_create_data+0x72/0xe0 pktgen_thread_write+0xd61/0x1510 Freed by task 28: kmem_cache_free+0xcb/0x3d0 proc_free_inode+0x5b/0x80 rcu_core+0x50a/0x1850 The buggy address belongs to the object at ffff8881478fea00 which belongs to the cache proc_dir_entry of size 192 Move proc_remove() into the if_lock-protected list removal helper. Keep it before list_del_rcu() to preserve the ordering required by add_device(). The rename path must then finish replacing the entry before removal, or it observes that the device is no longer on the list. Fixes: 39df232f1a9b ("[PKTGEN]: fix device name handling") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260719145740.2888967-1-nicoyip.dev@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b0a3d6d582ec2aab390a3da5b256860471e002a0 Author: Peter Seiderer Date: Tue Aug 11 08:15:25 2026 -0400 net: pktgen: fix code style (WARNING: Block comments) [ Upstream commit 870b856cb478bc02fffe4d89897e62c692efb09a ] Fix checkpatch code style warnings: WARNING: Block comments use a trailing */ on a separate line + * removal by worker thread */ WARNING: Block comments use * on subsequent lines + __u8 tos; /* six MSB of (former) IPv4 TOS + are for dscp codepoint */ WARNING: Block comments use a trailing */ on a separate line + are for dscp codepoint */ WARNING: Block comments use * on subsequent lines + __u8 traffic_class; /* ditto for the (former) Traffic Class in IPv6 + (see RFC 3260, sec. 4) */ WARNING: Block comments use a trailing */ on a separate line + (see RFC 3260, sec. 4) */ WARNING: Block comments use * on subsequent lines + /* = { + 0x00, 0x80, 0xC8, 0x79, 0xB3, 0xCB, WARNING: Block comments use * on subsequent lines + /* Field for thread to receive "posted" events terminate, + stop ifs etc. */ WARNING: Block comments use a trailing */ on a separate line + stop ifs etc. */ WARNING: Block comments should align the * on each line + * we go look for it ... +*/ WARNING: Block comments use a trailing */ on a separate line + * we resolve the dst issue */ WARNING: Block comments use a trailing */ on a separate line + * with proc_create_data() */ Signed-off-by: Peter Seiderer Reviewed-by: Toke Høiland-Jørgensen Signed-off-by: Jakub Kicinski Stable-dep-of: 817ff6efdb7f ("net: pktgen: fix proc entry use-after-free") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 81e21cb7bd1479bb5238e0004a7e0110452c610b Author: Namjae Jeon Date: Tue Aug 11 08:15:22 2026 -0400 ksmbd: reject repeated SMB2 NEGOTIATE requests [ Upstream commit cb469993b3a61a72653770856d37af616d72d05f ] Unauthenticated client can send multiple successful SMB2 NEGOTIATE requests on one connection before SESSION_SETUP. While the connection is in KSMBD_SESS_NEED_SETUP, smb2_handle_negotiate() accepts another SMB3.1.1 NEGOTIATE and overwrites conn->preauth_info with a new allocation. Only the final allocation is freed when the connection is released, leaking one object for every additional successful request. A repeated SMB2 NEGOTIATE after a dialect has been selected is a protocol violation. MS-SMB2 section 3.3.5.4 requires the server to disconnect without replying in this case. Set the connection exiting when rejecting the request, in addition to suppressing the response. Reject SMB2 NEGOTIATE unless the connection is new or is waiting for the SMB2 NEGOTIATE that follows an SMB1 multi-protocol negotiate. Serialize both SMB1 and SMB2 negotiation paths under conn->srv_mutex, since they update connection-wide dialect and negotiation state. Move the locking contract to ksmbd_smb_negotiate_common(), where the state and dialect are selected, and add ksmbd_conn_new() for consistent state access. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Reported-by: Runa Takemoto Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5964d1f35402fce961fed3e3be80ca49a7a5cf20 Author: Namjae Jeon Date: Tue Aug 11 08:15:21 2026 -0400 ksmbd: conn lock to serialize smb2 negotiate [ Upstream commit fe4ed2f09b492e3507615a053814daa8fafdecb1 ] If client send parallel smb2 negotiate request on same connection, ksmbd_conn can be racy. smb2 negotiate handling that are not performance-related can be serialized with conn lock. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cb469993b3a6 ("ksmbd: reject repeated SMB2 NEGOTIATE requests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a0f16c337691813f8d8f014c01fff5a368e08898 Author: David Carlier Date: Tue Aug 11 08:15:19 2026 -0400 igc: remove napi_synchronize() in igc_down() [ Upstream commit 5ffab5b9589c50e4cfc0cf36ffd76c89422d4019 ] When an AF_XDP zero-copy application is killed abruptly, the XSK pool is torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the full budget on every poll, so napi_complete_done() never clears NAPI_STATE_SCHED. igc_down() calls napi_synchronize() before napi_disable(), so it spins forever waiting for that bit and the interface never goes down. Drop the napi_synchronize() and let napi_disable() do the job -- it sets NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after polling has stopped, matching the recent igb fix b1e067240379. Fixes: fc9df2a0b520 ("igc: Enable RX via AF_XDP zero-copy") Suggested-by: Maciej Fijalkowski Cc: stable@vger.kernel.org Signed-off-by: David Carlier Reviewed-by: Maciej Fijalkowski Reviewed-by: Dima Ruinskiy Tested-by: Moriya Kadosh Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1f389ecd0c35e9e281036e44c121df904f3164c1 Author: Mark Brown Date: Mon Aug 10 22:15:54 2026 -0400 ASoC: tas2562: Validate values for volume writes [ Upstream commit 8fb41964f7e4e4207c8999af2056894caa7a252a ] tas2562_volume_control_put() does not do any validation of the control value written by userspace, it uses it to look up a value in a fixed size array which can easily be overflowed and then writes whatever value it gets back to the device. Add validation that we are loading a value we have in the array. Cc: stable@vger.kernel.org Reviewed-by: Cezary Rojewski Link: https://patch.msgid.link/20260715-asoc-tas2562-put-retval-v1-1-97bf467c924e@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5b948706f11a950bc73c5304630d0a7eafc40daf Author: Kefeng Wang Date: Sun Aug 9 11:21:10 2026 -0400 mm: migrate_device: fix pte_pfn/pte_dirty called on non-present PTE [ Upstream commit 63867c82d0c0c2d182016a32b1cc0103116b0ea5 ] pte_pfn() and pte_dirty() have undefined behaviour when called on a non-present PTE. In migrate_vma_collect_pmd(), these functions may be invoked on non-present entries (e.g., device-private entries), leading to potential crashes from pte_pfn() or incorrect dirty folio accounting from pte_dirty(). Fix both by guarding with pte_present() checks. Link: https://lore.kernel.org/20260708003955.4024340-1-wangkefeng.wang@huawei.com Link: https://lore.kernel.org/20260706111958.3649651-1-wangkefeng.wang@huawei.com Fixes: fd35ca3d12cc ("mm/migrate_device.c: copy pte dirty bit to page") Fixes: 6c287605fd56 ("mm: remember exclusively mapped anonymous pages with PG_anon_exclusive") Signed-off-by: Kefeng Wang Reviewed-by: Balbir Singh Acked-by: Zi Yan Cc: Alistair Popple Cc: Byungchul Park Cc: David Hildenbrand Cc: Gregory Price Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: Ying Huang Cc: Signed-off-by: Andrew Morton [ adapted `folio_test_anon(folio)`/`folio_mark_dirty(folio)` context lines to 6.6's `PageAnon(page)`/`folio_mark_dirty(page_folio(page))` spelling since the `folio` local doesn't exist ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 94a15b8a8f5a944ab398b1d5ffbc7e13434aacb5 Author: Guanghui Yang <3497809730@qq.com> Date: Sun Aug 9 11:03:56 2026 -0400 btrfs: zoned: fix missing chunk metadata reservation [ Upstream commit 8bc4d7209611e8aa9d5409b6a4a86a9eb91b69a3 ] reserve_chunk_space() stores the return value of btrfs_zoned_activate_one_bg() in ret. The helper can return 1 after successfully activating a block group, but ret is later used to decide whether to reserve metadata for chunk tree updates. As a result, successful activation skips btrfs_block_rsv_add() and leaves trans->chunk_bytes_reserved unchanged. Use a separate variable for the activation result so positive success does not affect the later reservation. Keep activation failures in ret instead of returning early so the function uses the common tail path. Fixes: b6a98021e401 ("btrfs: zoned: activate necessary block group") CC: stable@vger.kernel.org Reviewed-by: Johannes Thumshirn Signed-off-by: Guanghui Yang <3497809730@qq.com> Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2c3bd3b6ba701b9de1e5342032985d1fb17f96cf Author: Filipe Manana Date: Sun Aug 9 11:03:55 2026 -0400 btrfs: remove fs_info argument from btrfs_zoned_activate_one_bg() [ Upstream commit a232ff90d14657c8637c6e94b606bb5d700a2ecb ] We don't need it since we can grab fs_info from the given space_info. So remove the fs_info argument. Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 8bc4d7209611 ("btrfs: zoned: fix missing chunk metadata reservation") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 76f70daebe75770c805e19109143dfdb0b7ae074 Author: Naohiro Aota Date: Sun Aug 9 11:03:54 2026 -0400 btrfs: add space_info argument to btrfs_chunk_alloc() [ Upstream commit 098a442d5b6d440602604dc1a88706a2a91bce4e ] Take a btrfs_space_info argument in btrfs_chunk_alloc(). New block group will belong to that space_info. Signed-off-by: Naohiro Aota Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 8bc4d7209611 ("btrfs: zoned: fix missing chunk metadata reservation") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 17fe8f41c8c21f9fee30c6f84c5c68e1dbc6862c Author: David Sterba Date: Sun Aug 9 11:03:53 2026 -0400 btrfs: add debug build only WARN [ Upstream commit 3db15c6ca6feb2c5000a1cbb39c33866e0349abd ] Add conditional WARN() wrapper that's enabled only in debug build. It should be used for unexpected conditions that should be noisy. Use it instead of ASSERT(0). As it will not lead to BUG() make sure that continuing is still possible, e.g. the error is handled anyway. Reviewed-by: Josef Bacik Signed-off-by: David Sterba Stable-dep-of: 8bc4d7209611 ("btrfs: zoned: fix missing chunk metadata reservation") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8b0a3a094f4cae2fb92e4d08d4eef7246a9d9c49 Author: Yuxiang Yang Date: Sun Aug 9 09:54:45 2026 -0400 tcp: challenge ACK for non-exact RST in SYN-RECEIVED [ Upstream commit a28c4fcbf774e23b4779cae468e3497a5ad1f4a1 ] The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response. Reported-by: Yuxiang Yang Reported-by: Yizhou Zhao Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Fixes: 282f23c6ee34 ("tcp: implement RFC 5961 3.2") Cc: stable@vger.kernel.org Signed-off-by: Yuxiang Yang Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260717081443.809393-2-yangyx22@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6eb6b1d1726594c1dfdbf1dcbb38c3f37c3ce7cc Author: Ilpo Järvinen Date: Sun Aug 9 09:54:44 2026 -0400 tcp: fast path functions later [ Upstream commit 61b2f7baa9779b12a7bf1b9800a3f2a2549a1315 ] The following patch will use tcp_ecn_mode_accecn(), TCP_ACCECN_CEP_INIT_OFFSET, TCP_ACCECN_CEP_ACE_MASK in __tcp_fast_path_on() to make new flag for AccECN. No functional changes. Signed-off-by: Ilpo Järvinen Signed-off-by: Chia-Yu Chang Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20250911110642.87529-3-chia-yu.chang@nokia-bell-labs.com Signed-off-by: Jakub Kicinski Stable-dep-of: a28c4fcbf774 ("tcp: challenge ACK for non-exact RST in SYN-RECEIVED") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6ad63d36f6c5fd6e174e9c14c9dd868e26b28b91 Author: Ilpo Järvinen Date: Sun Aug 9 09:54:43 2026 -0400 tcp: Pass flags to __tcp_send_ack [ Upstream commit 9866884ce8ef25338c5b33cbb97c2b5d92088528 ] Accurate ECN needs to send custom flags to handle IP-ECN field reflection during handshake. Signed-off-by: Ilpo Järvinen Signed-off-by: Chia-Yu Chang Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Stable-dep-of: a28c4fcbf774 ("tcp: challenge ACK for non-exact RST in SYN-RECEIVED") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d8e5c5672724b8f3c4c099d2cf60239c996e5424 Author: Namjae Jeon Date: Sat Aug 8 21:21:58 2026 -0400 ksmbd: validate minimum PDU size for transform requests [ Upstream commit cfc0b8e5080aec87700774e8568765eaa4b7b92b ] The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation. Fixes: 368ba06881c3 ("ksmbd: check the validation of pdu_size in ksmbd_conn_handler_loop") Cc: stable@vger.kernel.org Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-31063 Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b9e4b3b9aadbb8890919531de700c5255e37fd12 Author: ChenXiaoSong Date: Sat Aug 8 21:21:57 2026 -0400 smb/server: fix minimum SMB2 PDU size [ Upstream commit 4c7d8eb9a79ae5400eac19c4f6f0815bff674452 ] The minimum SMB2 PDU size should be updated to the size of `struct smb2_pdu` (that is, the size of `struct smb2_hdr` + 2). Suggested-by: David Howells Suggested-by: Namjae Jeon Signed-off-by: ChenXiaoSong Reviewed-by: David Howells Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cfc0b8e5080a ("ksmbd: validate minimum PDU size for transform requests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ecb45f5c8b0db6e468182a139ce0feb7ed52cdbd Author: ChenXiaoSong Date: Sat Aug 8 21:21:56 2026 -0400 smb/server: fix minimum SMB1 PDU size [ Upstream commit 3b9c30eb8f5aaad4a54cdfa470b74c0467cc71e8 ] Since the RFC1002 header has been removed from `struct smb_hdr`, the minimum SMB1 PDU size should be updated as well. Fixes: 83bfbd0bb902 ("cifs: Remove the RFC1002 header from smb_hdr") Suggested-by: David Howells Suggested-by: Namjae Jeon Signed-off-by: ChenXiaoSong Reviewed-by: David Howells Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cfc0b8e5080a ("ksmbd: validate minimum PDU size for transform requests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 618af5277dcb5ed556d8bc3c0e1d360a274d6af6 Author: Namjae Jeon Date: Sat Aug 8 21:21:55 2026 -0400 ksmbd: rename smb2_get_msg to smb_get_msg [ Upstream commit 0b444cfd8b74ebce421ccd96eac9c495e536c92e ] With the removal of the RFC1002 length field from the SMB header, smb2_get_msg is now used to get the smb1 request from the request buffer. Since this function is no longer exclusive to smb2 and now supports smb1 as well, This patch rename it to smb_get_msg to better reflect its usage. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cfc0b8e5080a ("ksmbd: validate minimum PDU size for transform requests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 45e3e87561b4a70845e07a14fe20584678f74620 Author: ChenXiaoSong Date: Sat Aug 8 21:21:54 2026 -0400 smb/server: rename include guard in smb_common.h [ Upstream commit 01ab0d1640e379f0a0d6602250b33ff2b45e9560 ] Make the include guard more descriptive to avoid conflicts with include guards that may be used in the future. Signed-off-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cfc0b8e5080a ("ksmbd: validate minimum PDU size for transform requests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7964b9ab3baf962b2f9c8aee25455381ac5a7175 Author: ZhangGuoDong Date: Sat Aug 8 21:21:53 2026 -0400 smb: move get_rfc1002_len() to common/smbglob.h [ Upstream commit 36c31540cf5279262bfd148d8537cd04866499f2 ] Rename get_rfc1002_length() to get_rfc1002_len(), then move duplicate definitions to common header file. Co-developed-by: ChenXiaoSong Signed-off-by: ChenXiaoSong Signed-off-by: ZhangGuoDong Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cfc0b8e5080a ("ksmbd: validate minimum PDU size for transform requests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bc73642ccd637c823be45422abf282793c23fb1f Author: ZhangGuoDong Date: Sat Aug 8 21:21:52 2026 -0400 smb: move smb_version_values to common/smbglob.h [ Upstream commit 34cf191bb6a349dc88ec2c4f6355fe006ac669e0 ] Merge the struct members of the server and the client: - req_capabilities: from client - header_preamble_size: from client - cap_unicode: from client - capabilities: from server, rename to req_capabilities - max_read_size: from server - max_write_size: from server - max_trans_size: from server - max_credits: from server - create_durable_size: from server - create_durable_v2_size: from server - create_mxac_size: from server - create_disk_id_size: from server - create_posix_size: from server Then move duplicate definitions to common header file. Co-developed-by: ChenXiaoSong Signed-off-by: ChenXiaoSong Signed-off-by: ZhangGuoDong Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: cfc0b8e5080a ("ksmbd: validate minimum PDU size for transform requests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 05536cad35f27b520d4b6f0e57c8cc5bfb6b0502 Author: Christian Brauner Date: Sat Aug 8 20:48:01 2026 -0400 super: fix emergency thaw deadlock on frozen block devices [ Upstream commit 749d7aa0377aae32af8c0a4ad43371e7bf830ab5 ] do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback(). Fixes: 08fdc8a0138a ("buffer.c: call thaw_super during emergency thaw") [1] Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260723-work-super-emergency_thaw-v1-1-7c315c600245@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4131dd0b6f67acddd616ed7c244e1d3eedd46e7b Author: Aldo Ariel Panzardo Date: Sat Aug 8 10:09:51 2026 -0400 net/sched: serialize qdisc_rtab_list against concurrent get/put [ Upstream commit f43ee0c0730d6191629b5ee1ceae27b1ebfdc047 ] qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock. Fixes: 470502de5bdb ("net: sched: unlock rules update API") Suggested-by: Eric Dumazet Signed-off-by: Aldo Ariel Panzardo Cc: stable@vger.kernel.org Acked-by: Jamal Hadi Salim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260715114114.446841-1-qwe.aldo@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit db3e82da616f52e2b27e25e7be3fde2f2a5e54d6 Author: Shiming Cheng Date: Sat Aug 8 08:29:05 2026 -0400 net: gro: fix double aggregation of flush-marked skbs [ Upstream commit e751256486d0ded20f5a9f9863467f1dce65142f ] Commit 0ab03f353d36 ("net-gro: Fix GRO flush when receiving a GSO packet.") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive(). Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.") Cc: stable@vger.kernel.org Signed-off-by: Shiming Cheng Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260709014704.3625-1-shiming.cheng@mediatek.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2cb6c8b12bda512d785458201e3af039f1932e31 Author: Felix Fietkau Date: Sat Aug 8 08:29:04 2026 -0400 net: move skb_gro_receive_list from udp to core [ Upstream commit 8928756d53d5b99dcd18073dc7738b8ebdbe7d96 ] This helper function will be used for TCP fraglist GRO support Acked-by: Paolo Abeni Reviewed-by: Eric Dumazet Signed-off-by: Felix Fietkau Reviewed-by: David Ahern Reviewed-by: Willem de Bruijn Signed-off-by: Paolo Abeni Stable-dep-of: e751256486d0 ("net: gro: fix double aggregation of flush-marked skbs") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 02430f6f729b297e803d0605871f0a670b4eafd6 Author: Pavitra Jha Date: Sat Aug 8 07:25:31 2026 -0400 libceph: fix two unsafe bare decodes in decode_lockers() [ Upstream commit a109a556115271ca7896dcda7b4b7e45e156c227 ] decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ] Cc: stable@vger.kernel.org Fixes: d4ed4a530562 ("libceph: support for lock.lock_info") Signed-off-by: Pavitra Jha Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d974b4b786214883bd8e56bda10b454c80fd6205 Author: Mike Rapoport (Microsoft) Date: Sat Aug 8 07:12:50 2026 -0400 userfaultfd: prevent registration of special VMAs [ Upstream commit 3c58f641e813c3c71039f8fd4d4e2a3aab713288 ] Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL. Link: https://lore.kernel.org/20260618095017.2553004-1-rppt@kernel.org Fixes: 54007f818206 ("mm: Introduce VM_SHADOW_STACK for shadow stack memory") Signed-off-by: Mike Rapoport (Microsoft) Reported-by: vova tokarev Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes Cc: Al Viro Cc: Christian Brauner Cc: Jan Kara Cc: Linus Torvalds Cc: Mike Rapoport Cc: Oleg Nesterov Cc: Peter Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d97b01e78ce310a852751094776b24daa9ef36b8 Author: Mike Rapoport (Microsoft) Date: Sat Aug 8 07:12:49 2026 -0400 userfaultfd: move vma_can_userfault out of line [ Upstream commit a5bb8669872b6b8463b8777a7a259a8305060016 ] vma_can_userfault() has grown pretty big and it's not called on performance critical path. Move it out of line. No functional changes. Link: https://lore.kernel.org/20260402041156.1377214-7-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Reviewed-by: David Hildenbrand (Red Hat) Reviewed-by: Liam R. Howlett Cc: Andrea Arcangeli Cc: Andrei Vagin Cc: Axel Rasmussen Cc: Baolin Wang Cc: Harry Yoo Cc: Harry Yoo (Oracle) Cc: Hugh Dickins Cc: James Houghton Cc: Lorenzo Stoakes (Oracle) Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Muchun Song Cc: Nikita Kalyazin Cc: Oscar Salvador Cc: Paolo Bonzini Cc: Peter Xu Cc: Sean Christopherson Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: David Carlier Signed-off-by: Andrew Morton Stable-dep-of: 3c58f641e813 ("userfaultfd: prevent registration of special VMAs") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 896e8884fc2cc25cdc13589c0b47663b968dc08d Author: Chunyan Zhang Date: Sat Aug 8 07:12:48 2026 -0400 mm: userfaultfd: add pgtable_supports_uffd_wp() [ Upstream commit f59c0924d61aa2a2bb85936a593140f327112787 ] Some platforms can customize the PTE/PMD entry uffd-wp bit making it unavailable even if the architecture provides the resource. This patch adds a macro API pgtable_supports_uffd_wp() that allows architectures to define their specific implementations to check if the uffd-wp bit is available on which device the kernel is running. Also this patch is removing "ifdef CONFIG_HAVE_ARCH_USERFAULTFD_WP" and "ifdef CONFIG_PTE_MARKER_UFFD_WP" in favor of pgtable_supports_uffd_wp() and uffd_supports_wp_marker() checks respectively that default to IS_ENABLED(CONFIG_HAVE_ARCH_USERFAULTFD_WP) and "IS_ENABLED(CONFIG_HAVE_ARCH_USERFAULTFD_WP) && IS_ENABLED(CONFIG_PTE_MARKER_UFFD_WP)" if not overridden by the architecture, no change in behavior is expected. Link: https://lkml.kernel.org/r/20251113072806.795029-3-zhangchunyan@iscas.ac.cn Signed-off-by: Chunyan Zhang Acked-by: David Hildenbrand Cc: Albert Ou Cc: Alexandre Ghiti Cc: Alexandre Ghiti Cc: Al Viro Cc: Andrew Jones Cc: Arnd Bergmann Cc: Axel Rasmussen Cc: Christian Brauner Cc: Conor Dooley Cc: Conor Dooley Cc: Deepak Gupta Cc: Jan Kara Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Peter Xu Cc: Rob Herring Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Yuanchu Xie Signed-off-by: Andrew Morton Stable-dep-of: 3c58f641e813 ("userfaultfd: prevent registration of special VMAs") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 48829622212f6b8f49155889aecc818ba28ba680 Author: Zhang Yi Date: Sat Aug 8 07:12:33 2026 -0400 iomap: fix out-of-bounds bitmap_set() with zero-length range [ Upstream commit 9c7d8f7c8994c790fca501dc45ce66e7356cbe05 ] ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op. Fixes: 4ce02c679722 ("iomap: Add per-block dirty state tracking to improve performance") Cc: stable@vger.kernel.org # v6.6 Signed-off-by: Zhang Yi Link: https://patch.msgid.link/20260714082325.325163-5-yi.zhang@huaweicloud.com Reviewed-by: Joanne Koong Reviewed-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7439dc31f67810d0f4adabdb8b88cfd8576f881f Author: Matthew Wilcox (Oracle) Date: Sat Aug 8 07:12:32 2026 -0400 iomap: hold state_lock over call to ifs_set_range_uptodate() [ Upstream commit 279d5fc3227f04ef2c6125e5c440e7952173a89a ] Patch series "Add folio_end_read", v2. The core of this patchset is the new folio_end_read() call which filesystems can use when finishing a page cache read instead of separate calls to mark the folio uptodate and unlock it. As an illustration of its use, I converted ext4, iomap & mpage; more can be converted. I think that's useful by itself, but the interesting optimisation is that we can implement that with a single XOR instruction that sets the uptodate bit, clears the lock bit, tests the waiter bit and provides a write memory barrier. That removes one memory barrier and one atomic instruction from each page read, which seems worth doing. That's in patch 15. The last two patches could be a separate series, but basically we can do the same thing with the writeback flag that we do with the unlock flag; clear it and test the waiters bit at the same time. This patch (of 17): This is really preparation for the next patch, but it lets us call folio_mark_uptodate() in just one place instead of two. Link: https://lkml.kernel.org/r/20231004165317.1061855-1-willy@infradead.org Link: https://lkml.kernel.org/r/20231004165317.1061855-2-willy@infradead.org Signed-off-by: Matthew Wilcox (Oracle) Cc: Matthew Wilcox (Oracle) Cc: Nicholas Piggin Cc: "Theodore Ts'o" Cc: Andreas Dilger Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Cc: Thomas Bogendoerfer Cc: Michael Ellerman Cc: Christophe Leroy Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Alexander Gordeev Cc: Christian Borntraeger Cc: Sven Schnelle Cc: Geert Uytterhoeven Signed-off-by: Andrew Morton Stable-dep-of: 9c7d8f7c8994 ("iomap: fix out-of-bounds bitmap_set() with zero-length range") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a155aa7a52c6ff25d34ff16d3433a6af30360ea9 Author: Chancel Liu Date: Fri Aug 7 22:52:16 2026 -0400 ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP [ Upstream commit d091132889c1378dd0944a72f86eae3e4da1e4fa ] When the BCLK divider ratio is 1:1, fsl_sai_set_bclk() enables bypass mode by setting BYP, but never clears the bit. The BYP=1 value remains in the regcache, and is restored by regcache_sync() on the next runtime resume. Since BYP=1 combined with BCD=1 immediately outputs the ungated MCLK as BCLK without waiting for BCE/TE/RE to be enabled, the clock is driven prematurely before the stream is fully configured, causing noise on some codecs. Fix this by clearing BYP and BCI in fsl_sai_hw_free() taking into account sync mode and the opposite stream's state, so that the regcache holds BYP=0 before runtime suspend and regcache_sync() on resume will not restore bypass mode prematurely. Fixes: a50b7926d015 ("ASoC: fsl_sai: implement 1:1 bclk:mclk ratio support") Cc: stable@vger.kernel.org Signed-off-by: Chancel Liu Reviewed-by: Shengjiu Wang Link: https://patch.msgid.link/20260710070835.3749817-1-chancel.liu@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 42bc06c67d94d5f2a6b33294b0c4b07d8a47c515 Author: Xiang Mei Date: Fri Aug 7 18:25:41 2026 -0400 libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE [ Upstream commit 9f00f9cf2be293efe899db67dc5272e3a9c62717 ] __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ] Cc: stable@vger.kernel.org Fixes: a303bb0e5834 ("libceph: introduce and switch to decode_pg_mapping()") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7cd7b483893b67c545084b9e102787cb9b5521d3 Author: Andy Shevchenko Date: Fri Aug 7 18:25:40 2026 -0400 libceph: Amend checking to fix `make W=1` build breakage [ Upstream commit 04d8712b079327409b09dee628378f9583e2e035 ] In a few cases the code compares 32-bit value to a SIZE_MAX derived constant which is much higher than that value on 64-bit platforms, Clang, in particular, is not happy about this net/ceph/osdmap.c:1441:10: error: result of comparison of constant 4611686018427387891 with expression of type 'u32' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 1441 | if (len > (SIZE_MAX - sizeof(*pg)) / sizeof(u32)) | ~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ net/ceph/osdmap.c:1624:10: error: result of comparison of constant 2305843009213693945 with expression of type 'u32' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 1624 | if (len > (SIZE_MAX - sizeof(*pg)) / (2 * sizeof(u32))) | ~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix this by casting to size_t. Note, that possible replacement of SIZE_MAX by U32_MAX may lead to the behaviour changes on the corner cases. Signed-off-by: Andy Shevchenko Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Stable-dep-of: 9f00f9cf2be2 ("libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 34bb4c61948dab219706135a907176f1b3a58c26 Author: Matthew Wilcox (Oracle) Date: Fri Aug 7 18:10:05 2026 -0400 ceph: Use a folio in ceph_page_mkwrite() [ Upstream commit 88a59bda3f3786107694a3f5fd7f9df421752c21 ] Convert the passed page to a folio and use it throughout ceph_page_mkwrite(). Removes the last call to page_mkwrite_check_truncate(), the last call to offset_in_thp() and one of the last calls to thp_size(). Saves a few calls to compound_head(). Signed-off-by: "Matthew Wilcox (Oracle)" Link: https://lore.kernel.org/r/20250217185119.430193-3-willy@infradead.org Tested-by: Viacheslav Dubeyko Reviewed-by: Viacheslav Dubeyko Signed-off-by: Christian Brauner Stable-dep-of: cbf59617cd71 ("ceph: fix writeback_count leak in write_folio_nounlock()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e05c315b4da0c16ea800ee4b2cb6c617f586d1b5 Author: Max Kellermann Date: Fri Aug 7 18:10:04 2026 -0400 ceph: fix hanging __ceph_get_caps() with stale mds_wanted [ Upstream commit 50958bb928bad3bdba9e5d1b7ff4bbadcf6951e6 ] A reader can hang forever in __ceph_get_caps() when the client no longer holds `FILE_RD`, but local cap state still says that the capability is already wanted (via `mds_wanted`). One way to trigger this is through MDS cap revocation. If another client performs a conflicting operation, the MDS can revoke `FILE_RD` from the reader; the next read then has to reacquire `FILE_RD`. If the cap update that should request `FILE_RD` never reaches the MDS after `cap->mds_wanted` was raised, the reader is left holding only non-file caps while local `mds_wanted` still includes the file read caps. In that state, try_get_cap_refs() sees `need <= mds_wanted` and returns 0, so __ceph_get_caps() just waits on `i_cap_wq`. If the cap update that was supposed to request `FILE_RD never reaches the MDS after `cap->mds_wanted was` raised, no further request is sent and the waiter can sleep indefinitely until unrelated cap traffic happens to wake it up. The ordering issue is that `cap->mds_wanted` is updated in __prep_cap() before the `CEPH_MSG_CLIENT_CAPS message` is actually queued for send. That makes one field serve two different meanings at once: what this client wants, and what the client believes the MDS already knows it wants. A proper fix would be to split those states and track whether a cap update is actually in flight or has been observed by the MDS. However, simply moving the `cap->mds_wanted assignment` later would not be sufficient: queueing the message in the messenger does not guarantee that the MDS processed that specific wanted set, and reconnect or message loss can still invalidate that assumption. Fixing that properly would require a larger rework of the cap state machine. To allow simpler backports to stable kernels, this patch implements a simpler workaround: - stop waiting forever in __ceph_get_caps(); after a bounded wait, fall back to the renew path - make ceph_renew_caps() issue a synchronous `OPEN` request whenever the inode still does not actually hold the wanted caps, instead of only calling ceph_check_caps() The extra issued-vs-wanted check in ceph_renew_caps() is necessary because the previous test only checked whether the inode still had any real caps at all. That is not enough after revocation: the client can still hold something like `pLs` and yet be missing `FILE_RD` completely. In that case, falling back to ceph_check_caps() is not sufficient, because it still trusts `cap->mds_wanted` and may resend nothing. By requiring `(issued & wanted) == wanted` before taking the asynchronous path, the code only uses ceph_check_caps() when the `wanted caps` are already actually issued. Otherwise, it sends the synchronous `OPEN` renew. This preserves the existing asynchronous fast path when the wanted caps are already issued, avoids changing cap-state semantics, and fixes the hang by guaranteeing that a stalled waiter eventually retries through a path that does not rely on the stale `mds_wanted` state. [ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to mds_client.h, formatting ] Cc: stable@vger.kernel.org Fixes: 0a454bdd501a ("ceph: reorganize __send_cap for less spinlock abuse") Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 78af6441b89668779774a3439970338399a0c004 Author: Matthew Wilcox (Oracle) Date: Fri Aug 7 18:10:04 2026 -0400 ceph: Remove ceph_writepage() [ Upstream commit 19a288110435408fcf2cb274823f2a17d03caf9b ] Ceph already has a writepages operation which is preferred over writepage in all situations except for page migration. By adding a migrate_folio operation, there will be no situations in which ->writepage should be called. filemap_migrate_folio() is an appropriate operation to use because the ceph data stored in folio->private does not contain any reference to the memory address of the folio. Signed-off-by: "Matthew Wilcox (Oracle)" Link: https://lore.kernel.org/r/20250217185119.430193-2-willy@infradead.org Tested-by: Viacheslav Dubeyko Reviewed-by: Viacheslav Dubeyko Signed-off-by: Christian Brauner Stable-dep-of: cbf59617cd71 ("ceph: fix writeback_count leak in write_folio_nounlock()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c8a21660c3b90864c391164eea5622e7b5b2897c Author: Max Kellermann Date: Fri Aug 7 18:10:00 2026 -0400 ceph: avoid fs reclaim while using current->journal_info [ Upstream commit 5b602344a49e039e792ce5a8923bcc61412ee134 ] handle_reply() stores a `ceph_mds_request` pointer in `current->journal_info` while filling the inode and dentry cache from an MDS reply. An allocation in this section can enter direct reclaim and prune dentries from another filesystem. If this dirties an ext4 inode, ext4 starts a JBD2 transaction. JBD2 interprets the Ceph request in `current->journal_info` as a journal handle and dereferences the request's `r_tid` as `h_transaction`, causing a kernel crash, e.g.: Unable to handle kernel paging request at virtual address 00000000077b4818 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 6 UID: 0 PID: 2699135 Comm: kworker/6:3 Tainted: G W 6.18.38-i3 #1113 NONE [...] Workqueue: ceph-msgr ceph_con_workfn pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : jbd2__journal_start+0x2c/0x208 lr : __ext4_journal_start_sb+0x100/0x178 [...] Call trace: jbd2__journal_start+0x2c/0x208 (P) __ext4_journal_start_sb+0x100/0x178 ext4_dirty_inode+0x3c/0x90 __mark_inode_dirty+0x58/0x400 iput.part.0+0x2b0/0x370 iput+0x18/0x30 dentry_unlink_inode+0xc0/0x158 __dentry_kill+0x80/0x250 shrink_dentry_list+0x90/0x130 prune_dcache_sb+0x60/0x98 super_cache_scan+0xe8/0x190 do_shrink_slab+0x174/0x388 shrink_slab+0xd8/0x4c0 shrink_node+0x31c/0x908 do_try_to_free_pages+0xd0/0x508 try_to_free_pages+0x11c/0x238 __alloc_frozen_pages_noprof+0x4d0/0xdd0 __folio_alloc_noprof+0x18/0x70 __filemap_get_folio+0x248/0x440 ceph_readdir_prepopulate+0x570/0x9e8 mds_dispatch+0x1424/0x1ba0 ceph_con_process_message+0x74/0xa0 ceph_con_v1_try_read+0x3a0/0x1510 ceph_con_workfn+0x260/0x460 Enter a scoped NOFS allocation context and leave it after clearing `journal_info`. This prevents filesystem reclaim from recursing into another filesystem while the field contains Ceph-private data. Cc: stable@vger.kernel.org Fixes: 315f24088048 ("ceph: fix security xattr deadlock") Signed-off-by: Max Kellermann Reviewed-by: Viacheslav Dubeyko Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dbb90d8b21b947a9cb1ce52bd010648fe8dc1c49 Author: Palmer Dabbelt Date: Tue Aug 29 21:39:19 2023 -0700 RISC-V: Provide pgtable_l5_enabled on rv32 commit 10128f8b1663a8bce27df051c750d116bb8cd737 upstream. A few of the other page table level helpers are defined on rv32, but not pgtable_l5_enabled. This adds the definition as a constant and converts pgtable_l4_enabled to a constant as well. Link: https://lore.kernel.org/r/20230830044129.11481-2-palmer@rivosinc.com Signed-off-by: Palmer Dabbelt [ Ben: Applies unchanged; needed by both 6.1.y and 6.6.y. Both trees took commit e59e5e2754bf ("riscv: correct pt_level name via pgtable_l5/4_enabled") -- 6.1.y as of v6.1.64 -- without this prerequisite from the same series, so arch/riscv/mm/ptdump.c fails to build on rv32 whenever CONFIG_PTDUMP_CORE is enabled: arch/riscv/mm/ptdump.c: In function 'ptdump_init': arch/riscv/mm/ptdump.c:387:28: error: 'pgtable_l5_enabled' undeclared (first use in this function); did you mean 'pgtable_l4_enabled'? Only pgtable_l5_enabled fails because pgtable_l4_enabled still has an unconditional extern in asm/pgtable.h; this patch removes that and provides both as constants for rv32. The only assignments to them, in disable_pgtable_l4/l5(), are already inside #if defined(CONFIG_64BIT) && !defined(CONFIG_XIP_KERNEL), so making them const on rv32 is safe. v6.12 and later are unaffected. ] Signed-off-by: Ben Zong-You Xie Signed-off-by: Greg Kroah-Hartman commit 48552988925d9e5f94fe1f700b9d3084832e175b Author: Christoph Hellwig Date: Wed Jul 29 15:00:58 2026 +0200 xfs: check v5 superblock features early commit eb6b2cc1fc8ad566d746d128a559989ff0bba5cc upstream. When working on a new features that reuses the existing pad in the superblock, I noticed that mounting such a file system on an old kernel logs a rather confusing warning: XFS (vdc): Metadir superblock padding fields must be zero. This is because we only validate the various feature fields in v5 superblocks after the common superblock validation helper is called. Fix this by calling the feature validation first. Fixes: eca383fcd63b ("xfs: refactor superblock verifiers") Cc: # v4.19 Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 5b756fbb60b5d26063f46a11a3c7daa7eb616d79 Author: Long Li Date: Mon Jul 27 10:38:49 2026 +0800 xfs: don't swallow dquot recovery verification errors commit e2b4a856085e9bd939bde2dee0d08b1d41babde9 upstream. xlog_recover_dquot_commit_pass2() validates the recovered dquot with xfs_dqblk_verify() and, on failure, sets error = -EFSCORRUPTED and jumps to out_release. But out_release unconditionally returns 0, so the corruption error is discarded: the caller xlog_recover_items_pass2() sees success, log recovery proceeds as if the dquot were valid, and the corrupt quota buffer can be written back to disk. Fixes: 9c235dfc3d3f ("xfs: dquot recovery does not validate the recovered dquot") Cc: stable@vger.kernel.org # v6.8 Signed-off-by: Long Li Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit ed8bfb43de71213cfdbbe833b2c2817250e18b1a Author: Long Li Date: Mon Jul 27 10:38:48 2026 +0800 xfs: fix ilock leak on error in xfs_dq_get_next_id commit 63320a0f70f66f311f4bccff3af0719c2119f46c upstream. xfs_dq_get_next_id() takes the quota inode ILOCK before calling xfs_iread_extents(). If xfs_iread_extents() fails, the function returns immediately without releasing the lock, leaking the quota inode ILOCK. This can leave the quota inode locked and cause subsequent quota operations to hang. Fix this by jumping to a common unlock path on error instead of returning directly. Fixes: bda250dbaf39f ("xfs: rewrite xfs_dq_get_next_id using xfs_iext_lookup_extent") Cc: stable@vger.kernel.org # v4.12 Signed-off-by: Long Li Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 472cfa4ba2433ec958b83fdc850e95bda2712fb9 Author: Darrick J. Wong Date: Sun Jul 26 22:22:59 2026 -0700 xfs: only check mergeability of bnobt records commit 97efed1091a50e4dbf31307015138b43a972d2e4 upstream. In the cntbt (free space by block count) btree, records are not supposed to be in startblock order. Hence the mergeability check is pointless. Remove it, since it does nothing, as LOLLM points out. Cc: stable@vger.kernel.org # v6.4 Fixes: d5784ae82778d9 ("xfs: flag free space btree records that could be merged") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 070229262ede37d17c4ea596650deb6e5eb5d106 Author: Junrui Luo Date: Thu Aug 6 12:45:24 2026 +0800 drm/amdgpu: disallow multiple FENCE chunks in one submit commit 931cd1d1baeae68e8eb2c23bc1f3d8934dca6241 upstream. amdgpu_cs_pass1() dispatches on chunk_id once per chunk without rejecting repeated ids. p->uf_bo is a single-slot field, so a submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs amdgpu_cs_p1_user_fence() twice, and the second run overwrites p->uf_bo with a freshly referenced BO without dropping the reference taken by the first. amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE chunk but the last leaks a BO reference. The leaked BO outlives handle close and process exit. Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc ("drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit") did for p->bo_list. Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Reviewed-by: Christian König Signed-off-by: Junrui Luo Signed-off-by: Alex Deucher (cherry picked from commit 665b1fc2a1845206408f9a2c6da67101789edb82) Signed-off-by: Greg Kroah-Hartman commit 60539d517e8439621532d8c01091ac049c596b4b Author: David Rosca Date: Thu Jul 30 18:01:51 2026 +0200 drm/amdgpu: Fix UVD decode image min size calculation commit b8bb9ba3f101a1b0011f785a577a4a0a38371174 upstream. This needs to use pitch instead of width. Also reject pitch over 4096 to avoid overflow. Signed-off-by: David Rosca Acked-by: Leo Liu Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit b41c8cb12e202b220353332ab87dc01a11f69304) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fa96c24485942e277483cc70d9551d9e0111d7c5 Author: David Rosca Date: Thu Jul 30 17:56:17 2026 +0200 drm/amdgpu: Fix UVD dpb min size calculation for H264 commit 21a8084cd76223a13493237e04d45f5226d7cee6 upstream. This should use actual number of references from the decode message, instead of maximum derived from level. Signed-off-by: David Rosca Acked-by: Leo Liu Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit 64b525edb7e7bdfcdc77883c5e413804e2396856) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7cff5d7870a110e35a3f6c1c00272c9269001c8f Author: David Rosca Date: Thu Jul 30 18:05:52 2026 +0200 drm/amdgpu: Fix UVD min buffer sizes commit 18727670b44753865b81c56a9338c0d7bd102c54 upstream. Use correct size for message buffer = sizeof(struct ruvd_msg). Add ITSCALING_TABLE_BUFFER size. Signed-off-by: David Rosca Acked-by: Leo Liu Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit 37519d007e4261febbcf35b3045f8344f3145497) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f0f5048d58dec6f7c39284c5f7c6a71eb38cb383 Author: David Rosca Date: Mon Aug 10 11:11:35 2026 +0200 drm/amdgpu: Implement insert_end for VCE 3 commit d5ab4c6a64efef2d143a96df5357f59703cd703d upstream. After a recent change VCE now hangs when VCE_CMD_END is emitted after a pipeline sync without VM flush. Implement insert_end to correctly insert only one VCE_CMD_END per job. Fixes: bc639a9eadc7 ("drm/amdgpu: always emit the job vm fence") Signed-off-by: David Rosca Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 8897ea8c761b856f02061848a7908040a1fe5e68) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8435d41afcf2bc31ecee213ef651c12bd1a16d38 Author: David Rosca Date: Thu Jul 30 17:37:44 2026 +0200 drm/amdgpu: Reject UVD message with dimensions above 4096 commit 8c9aebcdd9f46f7a14b98d6ab18574b7a48fbb08 upstream. Fixes potential overflow in DPB size calculations. Signed-off-by: David Rosca Acked-by: Leo Liu Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit 05e1387d151f71569fbe122d2c89f9db0c21dc10) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ce5da474c3ddf7cccec5dce6aa4296297dd7caff Author: Candice Li Date: Mon Jul 27 11:51:37 2026 +0800 drm/amdgpu: validate GEM_CREATE domain combinations commit 5e9d136ad74df4edec67e502ce267597064d8f86 upstream. AMDGPU_GEM_CREATE checked domain bits against AMDGPU_GEM_DOMAIN_MASK, but did not validate domain combinations. Userspace could combine CPU|GTT|VRAM with DOORBELL, GDS, GWS, or OA, making amdgpu_bo_placement_from_domain() exceed AMDGPU_BO_MAX_PLACEMENTS and hit BUG_ON(). Allow combinations only within CPU/GTT/VRAM, and require non-CPU/GTT/ VRAM domains to be specified one at a time. Return -EINVAL for invalid combinations in amdgpu_gem_create_ioctl(). v2: Rename helper from amdgpu_gem_domain_valid() to amdgpu_gem_are_domains_valid() (Christian) Signed-off-by: Candice Li Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit db39852d0c39843cb02048dfb47e4b8c703e9080) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a930c54cb67200de8bc0de87480d09ece7dcd85d Author: David Rosca Date: Tue Aug 11 11:03:10 2026 +0200 drm/amdgpu: Reject UVD message with invalid number of h265 refs commit 9fca434208f1f9ab977feac62df8ebb1cc7ce893 upstream. Same change as for h264, avoids overflow later when calculating min dpb size. Signed-off-by: David Rosca Reviewed-by: Leo Liu Signed-off-by: Alex Deucher (cherry picked from commit a4b0720e4f1601f97f59a2be9c1b4b94fa6527d5) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f72a51810d49411bd8cad0c2df8592320a2fe5cc Author: Eric Farman Date: Tue Jul 28 05:30:21 2026 +0200 s390/vfio_ccw: Selectively expand io_mutex commit 34f4feff3e90bd09308fad0974e97113b23b812a upstream. The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself. Fixes: 4f76617378ee ("vfio-ccw: protect the I/O region") Cc: stable@vger.kernel.org Signed-off-by: Eric Farman Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit f98a9890ca42f4223d2d4c50e0660af3e012fcb4 Author: Eric Farman Date: Tue Jul 28 05:30:20 2026 +0200 s390/vfio_ccw: Move cp cleanup out of not operational commit 0c11f61a876ed6fcca53d442ed3f33ea8362a0f9 upstream. The fsm_notoper() routine is called when the device has been lost, and is (by definition) no longer operational. Since this can happen asynchronously from the normal behavior of the driver, the cleanup may happen when holding other locks in the calling sequence (notably, the cio subchannel lock). Push the cleanup of the private->cp resources to a workqueue, where it can be done out from under that lock sequence and a future patch can safely manage the locking requirements. Fixes: 204b394a23ad ("vfio/ccw: Move FSM open/close to MDEV open/close") Cc: stable@vger.kernel.org Signed-off-by: Eric Farman Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit af3f80ca4c8b17f20f9e588def076288fdb49e65 Author: Eric Farman Date: Tue Jul 28 05:30:15 2026 +0200 s390/vfio_ccw: Fix out of bounds check on CCW array commit a005b7f1a491ffda61bff0fd0f6548f8986fb977 upstream. The routine ccwchain_calc_length() counts the number of channel command words (CCWs) that are chained together in a single channel program, and rejects anything larger than CCWCHAIN_LEN_MAX (256) CCWs. The loop itself is "do..while (count < 257)", and while the logic in is_cpa_within_range() correctly adjusts between the 0-index array of CCWs and the count of CCWs starting at 1, this means it would look at a possible 257th CCW before ending the loop and (correctly) returning an error. Fix this by restructuring the loop to break as soon as 256 CCWs (thus indexes 0-255) are examined, without looking at memory outside the range. Fixes: 0a19e61e6d4c ("vfio: ccw: introduce channel program interfaces") Cc: stable@vger.kernel.org Reviewed-by: Matthew Rosato Signed-off-by: Eric Farman Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 79ea5e0c4c8a9842ae85f45062d947b3297dfc07 Author: Eric Farman Date: Tue Jul 28 05:30:18 2026 +0200 s390/vfio_ccw: Ensure index for read/write regions are within range commit 9f5f9a78fedc45bc29d6a0a64e3a3472361afae5 upstream. The introduction of the capability chain rightly clamped the region indexes to the range of the capabilities itself, but neglected to do so for the existing read/write regions which should also be enforced. Fixes: db8e5d17ac03 ("vfio-ccw: add capabilities chain") Cc: stable@vger.kernel.org Cc: Cornelia Huck Reviewed-by: Matthew Rosato Signed-off-by: Eric Farman Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit e868ea8be0bc88c6982f48ecf3259d98afd884ae Author: Eric Farman Date: Tue Jul 28 05:30:19 2026 +0200 s390/vfio_ccw: Cancel existing workqueues commit 79c60b2c61105368dcc8444eb45847e21734f7c4 upstream. The initialization of the io_work and crw_work workqueues begs the question of whether they should be un-initialized. Add the corresponding cleanup tags in _release_dev to ensure work isn't dispatched after the private struct is free'd. Suggested-by: Matthew Rosato Fixes: e5f84dbaea59 ("vfio: ccw: return I/O results asynchronously") Fixes: 3f02cb2fd9d2 ("vfio-ccw: Wire up the CRW irq and CRW region") Cc: stable@vger.kernel.org Reviewed-by: Matthew Rosato Signed-off-by: Eric Farman Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 15fb4559a7fdf0b8725e433a71cfd03a1313a48b Author: Eric Farman Date: Tue Jul 28 05:30:14 2026 +0200 s390/vfio_ccw: Limit the number of channel program segments commit 5405c90d6a47b3014e74ee0618a162449abbbc93 upstream. The processing of channel programs, and the CCWs within them, is done recursively. As such, there is an arbitrary (but not architectural) limit to the number of CCWs that can exist in a single channel program. The vfio-ccw logic breaks these channel programs into segments whenever it encounters a Transfer-In-Channel (TIC) CCW, and the combined number of segments count towards the global limit. Impose an equivalent limit to the number of segments until such logic can be made non-recursive. Fixes: 0a19e61e6d4c ("vfio: ccw: introduce channel program interfaces") Cc: stable@vger.kernel.org Reviewed-by: Matthew Rosato Signed-off-by: Eric Farman Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 2acbeace14672101280295f05c2740d406d2edaa Author: Guangshuo Li Date: Sat Aug 8 21:59:42 2026 +0800 drm/radeon: fix autosuspend cleanup during teardown commit 587be7a17358ef8c0106775fcedae5a7bef50735 upstream. radeon_driver_load_kms() calls pm_runtime_use_autosuspend() for PX devices, but radeon_driver_unload_kms() does not call the matching pm_runtime_dont_use_autosuspend() during teardown. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to the driver unload path. This issue was found by manual code inspection. Fixes: 10ebc0bc0934 ("drm/radeon: add runtime PM support (v2)") Signed-off-by: Guangshuo Li Signed-off-by: Alex Deucher (cherry picked from commit 0fdc1ff82ea14844c22795e9e0813c3ca03235e1) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 38d60f808b3410364498e8f86953e0344a1bc235 Author: Haibo Chen Date: Mon Jul 27 18:38:49 2026 +0800 mmc: sdhci: make tuning_err a signed int commit ae31bcc92bb42502bb7c9029e6dc7a824cf6cd14 upstream. Coverity report INTEGER_OVERFLOW for host->tuning_err. The tuning_err field in struct sdhci_host is used to store an error code for re-tuning, but it was declared as unsigned int. Several call sites store negative error codes into it and later compare against negative values: - sdhci.c, sdhci-of-dwcmshc.c and sdhci-pci-gli.c assign it the return value of __sdhci_execute_tuning()/__sdhci_execute_tuning_9750(), both of which return a signed int (possibly a negative errno); - sdhci-of-esdhc.c assigns host->tuning_err = -EAGAIN and later does "ret = host->tuning_err; if (ret == -EAGAIN ...)"; - sdhci-of-dwcmshc.c prints it with the %d (signed) conversion. Storing a negative errno in an unsigned int and reading it back as a signed int only happens to work because of two's-complement, same-width integer conversions. It is misleading and triggers sign-conversion warnings. All users treat the value either as a signed error code or as a boolean (zero / non-zero), so changing the type to a signed int is safe and makes the intent explicit. Fixes: 7d8bb1f46e13 ("mmc: sdhci: add tuning error codes") Assisted-by: Cline:claude-sonnet [read_file, search_files, git] Signed-off-by: Haibo Chen Reviewed-by: Frank Li Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit fc90985bd5d7ecacfd5ccca59600f51870f7c11b Author: Myeonghun Pak Date: Mon Jul 27 23:03:22 2026 +0900 mmc: sdhci: unmap the bounce buffer before device release commit 9e9f561269dff35e6f84ed21776ec37fd6360b03 upstream. sdhci_allocate_bounce_buffer() allocates its buffer with devm_kmalloc() but maps it with dma_map_single(). The buffer is therefore released by devres without the streaming DMA mapping being unmapped. Register a managed action after dma_map_single() succeeds so the mapping is removed before devres releases the buffer. The action is registered only for buffers allocated and mapped by the SDHCI core, leaving buffers provided by host drivers under their existing ownership. Fixes: bd9b902798ab ("mmc: sdhci: Implement an SDHCI-specific bounce buffer") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Linus Walleij Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2d481fc84b5895d16065285f7804272e85d05af2 Author: Zhan Xusheng Date: Tue Aug 4 10:25:00 2026 +0800 mmc: omap_hsmmc: fix busy_timeout overflow in ns conversion on 32-bit commit f64ea900e4bda3055ef24a2c906f8d049cf1c3bd upstream. omap_hsmmc_prepare_data() converts the command busy timeout to nanoseconds with: timeout = req->cmd->busy_timeout * NSEC_PER_MSEC; busy_timeout is an unsigned int (milliseconds) and timeout is a u64, but NSEC_PER_MSEC is 1000000L. On 32-bit builds the multiplication is performed in 32-bit arithmetic and wraps for busy_timeout values above ~4294 ms, before the result is assigned to the u64. The driver does not set mmc->max_busy_timeout, so the core does not cap the busy timeout, and commands such as erase or SANITIZE (MMC_SANITIZE_TIMEOUT_MS is 240000 ms) can pass a busy_timeout far larger than 4294 ms. The wrapped, much smaller ns value is then programmed via set_data_timeout(), so the data timeout is set too short and the operation can time out prematurely. Cast busy_timeout to u64 before the multiplication so the conversion is done in 64-bit arithmetic. Fixes: 8cc9a3e73de1 ("mmc: host: omap_hsmmc: use generic_cmd6_time to program timeout value for CMD6") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 762be85fadd973b013ca3db192731a35f4d09867 Author: Kefu Chai Date: Thu Jun 11 19:32:51 2026 +0800 libceph: tolerate addrvecs with multiple entries of the same type commit 5a87925539acecfe88229bad76ab81bd75a7e3f5 upstream. ceph_decode_entity_addrvec() rejects any addrvec containing more than one entry that matches the requested msgr type (LEGACY or MSGR2), logging "another match of type N in addrvec" and returning -EINVAL. Some admin tooling (e.g. pveceph mon create from Proxmox VE) generates addrvecs with multiple same-type entries when public_network lists more than one CIDR: it picks one local IP per subnet and emits both a v2 and a v1 entry for each IP. Monmaps shaped this way cause: libceph: mon0 (1)10.10.10.15:6789 session established libceph: another match of type 1 in addrvec libceph: problem decoding monmap, -22 No Ceph code uses the extra entries: since Nautilus, the userspace messenger (AsyncMessenger) unconditionally picks the first address of the requested type and ignores any subsequent matches. Match that behavior: use the first matching entry and silently skip any subsequent ones. This is a compatibility fix for existing deployments and does not enable dual-stack or multi-subnet address selection. [ idryomov: tweak ceph_decode_entity_addrvec() comment ] Cc: stable@vger.kernel.org Fixes: a5cbd5fc22d5 ("libceph, ceph: get and handle cluster maps with addrvecs") Link: https://bugzilla.proxmox.com/show_bug.cgi?id=7518 Signed-off-by: Kefu Chai Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 54aff77ed44ac502cc9392769381d43cae8d7385 Author: Yiming Zhu Date: Fri Jul 24 18:49:20 2026 +0800 ceph: fix MDS random selection readiness predicate commit 2c11c4bfdb7bd2808b3b3ac228e1f2d9bcf25457 upstream. CEPH_MDS_IS_READY() is parsed so that the ternary expression can return true for an MDS entry with state 0 when it is not laggy. This allows the random selector to choose a down/DNE rank. Group the ternary expression under the state check so zero-state ranks are not treated as ready. Cc: stable@vger.kernel.org Fixes: b38c9eb4757d ("ceph: add possible_max_rank and make the code more readable") Link: https://tracker.ceph.com/issues/78648 Signed-off-by: Yiming Zhu Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit e2ffeec85201b2bb748e99e12539ee1b92f62796 Author: Raphael Zimmer Date: Tue Jul 28 10:43:40 2026 +0200 libceph: Avoid using invalid osd indices from primary_temp commit 3660b98d1204b419f6a77e9a295f148dcf38d042 upstream. A corrupted osdmap received from a Ceph monitor or OSD may contain osd indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts that don't exist, i.e., that are greater than max_osd or smaller than CEPH_HOMELESS_OSD (-1). These indices are used to create the up and acting set in ceph_pg_to_up_acting_osds(), called from calc_target(). While most of these osd indices are checked, the one from primary_temp is not. Subsequently, this may lead to calc_target() returning this (potentially invalid) index as target osd for a (linger) request. Because the osd_state, osd_weight, and osd_addr arrays only contain max_osd entries (with indices 0 to max_osd -1), this leads to out-of-bounds accesses when trying to read values from these arrays. This patch fixes the issue by adding a check to get_temp_osds(), so that only valid osd indices from primary_temp are used, and it falls back to using the primary from pg_temp or the up set if it is invalid. [ idryomov: changelog ] Cc: stable@vger.kernel.org Fixes: 5e8d4d36bf23 ("libceph: add support for primary_temp mappings") Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 28d9cd72827becc817f5091a68de661b8bd82dc9 Author: Dmitry Torokhov Date: Mon Jun 15 22:12:30 2026 -0700 Input: sur40 - fix V4L error path cleanup commit 062dc4693e2c10d77de06f61e6f3faf37c0a8383 upstream. In sur40_probe(), if video_register_device() fails, the error path jumps to err_unreg_video. This incorrectly attempts to unregister a video device that was never successfully registered, and fails to free the V4L2 control handler (v4l2_ctrl_handler_free) that was initialized immediately prior. Fix this by introducing an err_free_ctrl label to properly free the V4L2 control handler and bypass video_unregister_device() when video device registration fails. Reported-by: sashiko-bot@kernel.org Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260616051235.1549517-2-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 3e8ed76a4f3572e637653f0654cccdf617903231 Author: Dmitry Torokhov Date: Mon Jun 15 22:12:29 2026 -0700 Input: sur40 - fix input device registration ordering commit 9da976eb649c9e2f588a4499410e4d8af687925f upstream. In sur40_probe(), input_register_device() was previously called early before the V4L2 video device and vb2_queue components were fully initialized. If userspace opened the input device immediately upon registration, sur40_open() would trigger and start the sur40_poll() worker thread. This worker thread invokes sur40_process_video() and accesses the uninitialized vb2_queue structure, leading to a data race and potential system crash. Furthermore, if V4L2 or video registration failed after input_register_device() succeeded, the error path fell through to calling input_free_device() on a successfully registered device instead of input_unregister_device(), corrupting input core state. Move input_register_device() to the very end of sur40_probe(). This ensures the V4L2 and video queue structures are fully initialized before polling can start, and naturally resolves the error path bug since input_free_device() is now only called when input registration has not yet occurred. To maintain strict LIFO (Last-In, First-Out) teardown ordering, also move input_unregister_device() to the very beginning of sur40_disconnect(). This guarantees that the input polling worker thread is stopped before V4L2 video components or control handlers are unregistered. Reported-by: sashiko-bot@kernel.org Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260616051235.1549517-1-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit b4d73c3848bae9084fa8b9b2aa76d99a7d8eb17d Author: Ali Ahmet Memis Date: Fri Aug 7 23:42:30 2026 +0000 openrisc: signal: do not restore privileged SR bits on sigreturn commit 32ef1b30ad736519f7a207bcc2986f3d4129d972 upstream. restore_sigcontext() copies the whole supervision register (SR) from the signal frame and only clears SPR_SR_SM before the value is reloaded into the hardware SR (through ESR and l.rfe) on the return to user space. All other SR bits are left under user control. An unprivileged task can thus return from a signal handler through a crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the CPU performs no translation or protection on data accesses, so the task gains read and write access to arbitrary physical memory, a local privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH and the cache-enable bits are exposed the same way. The ptrace GPR regset already refuses any change to SR for exactly this reason. Restore only the arithmetic flag bits (F, CY, OV) from the signal frame and take every privileged control bit from the SR the kernel saved on signal entry. Verified with qemu-system-or1k -M or1k-sim: before this change an unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the same PoC receives SIGSEGV and physical memory is unchanged. Fixes: ac689eb7f9d4 ("OpenRISC: Signal handling") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Signed-off-by: Stafford Horne Signed-off-by: Greg Kroah-Hartman commit 82f4f07f3f040ddfcb6e8a5cf96a342f1335e7dd Author: Josh Poimboeuf Date: Wed Aug 5 21:56:46 2026 -0700 ftrace: Fix off-by-one fentry site disable in ftrace_free_mem() commit 8b8292d6487c81bd57c2605a9b404b1cf8f1edfb upstream. When a module's init text is freed, do_init_module() calls ftrace_free_mem() with a half-open [start, end) range. However the ftrace_cmp_recs() comparator treats the upper bound as inclusive, as all its other users do, passing 'ip + size - 1'. So ftrace_free_mem() can delete a record sitting exactly at 'end', which is outside the freed range. For a kernel without CFI or IBT, the first record of a function is at the function start, which for the first function in a module is also the base of its text allocation. As the module allocator packs its regions, that address is often the 'end' passed by a neighboring module's do_init_module(), causing the first function's ftrace location to get disabled, preventing an attempt to livepatch it: livepatch: failed to find location for function 'pcspkr_probe' Convert the exclusive end to the inclusive 'end - 1' the comparator expects, and return early for an empty range to avoid the subtraction from underflowing when the init text size is zero. Cc: stable@vger.kernel.org Fixes: 42c269c88dc1 ("ftrace: Allow for function tracing to record init functions on boot up") Link: https://patch.msgid.link/1b5ccfa8095bdb1277f84af1c2c2e2205aca03ae.1785992188.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 8c6ee5351b264e5b7733f0199bdafd50b759b400 Author: Leon Hwang Date: Thu Jul 30 23:04:08 2026 +0800 ftrace: Protect direct_functions in ftrace_find_rec_direct commit 63444b7617c09aeed36282e061c3f80818f2b600 upstream. Fix accessing the __rcu pointer direct_functions with RCU protection. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260730150411.88667-2-leon.hwang@linux.dev Fixes: d05cb470663a ("ftrace: Fix modification of direct_function hash while in use") Acked-by: Jiri Olsa Suggested-by: Steven Rostedt Signed-off-by: Leon Hwang Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit fa4aa86fff0c56799c2e3f51a88879053285f4a9 Author: Pavitra Jha Date: Tue Jun 2 01:02:19 2026 -0400 libceph: fix multiple unsafe decodes in decode_locker() commit 437b6551cfcc235eea1d735a874f9d421f555e17 upstream. decode_locker() in cls_lock_client.c contains three unsafe decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_copy() at the locker_id_t name field has no preceding bounds check. With p == end after ceph_start_decoding() accepts struct_len=0, this reads sizeof(ceph_entity_name) = 9 bytes past the validated buffer boundary. 2. *p += sizeof(struct ceph_timespec) after the locker_info_t header is an unchecked pointer advance. A malicious OSD can position p past end, causing all subsequent _safe checks to pass against a bogus boundary. 3. len = ceph_decode_32(p) has no preceding bounds check, and the immediately following *p += len is uncapped. A malicious OSD can send len=0xffffffff, advancing p gigabytes past end and escaping the decode window entirely. Fix all three by replacing bare operations with their safe variants: ceph_decode_copy -> ceph_decode_copy_safe *p += sizeof(...) -> ceph_decode_skip_n ceph_decode_32(p) -> ceph_decode_32_safe *p += len -> ceph_decode_skip_n A new label is added to return -EINVAL on any bounds violation. -EINVAL is appropriate here: the data received from the OSD is structurally malformed, which is an invalid argument to the decode contract regardless of whether the caller or the wire is at fault. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition) without any further privileges beyond OSD session establishment. [ idryomov: use ceph_decode_skip_string() to skip description, trim changelog ] Cc: stable@vger.kernel.org Fixes: d4ed4a530562 ("libceph: support for lock.lock_info") Signed-off-by: Pavitra Jha Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit de52c713d21806b93b00a6074056b57aec4f8919 Author: Thorsten Blum Date: Fri Jul 24 10:15:38 2026 +0200 crypto: qce - fix error path in devm_qce_register_algs commit 9c75402286409f5e1a75e4a445555c84066f89db upstream. If ops->register_algs() fails, the error path repeatedly calls the same ops->unregister_algs() from the failed registration. Use the loop index to unregister the previously registered algorithms instead. Fixes: e80cf84b6087 ("crypto: qce - unregister previously registered algos in error path") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Reviewed-by: Bartosz Golaszewski Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ec61ca4e310665816a639cb2e46cd9b3af0a9bee Author: Jianing Li Date: Mon Aug 3 21:18:52 2026 -0700 Input: hynitron_cstxxx - validate touch count and finger IDs commit 27f380ef0e1d3de3cde114e02d33f9320ce3a5a6 upstream. The driver allocates max_touch_num input slots, which are indexed from zero through max_touch_num - 1. The current check allows a finger ID equal to max_touch_num to reach cst3xx_report_contact(). While the input core ignores out-of-range slot indices, reporting touch data without a valid slot change corrupts the touch state of the previously active slot. The touch count is read from the controller's report and is used to index the fixed-size report buffer without first checking its range. Reject counts larger than the supported number of touch slots before checking the trailing byte or parsing touch data. Reject finger IDs equal to or greater than max_touch_num, and return immediately when an invalid finger ID is encountered so that corrupt touch frames are discarded instead of reporting partial contact state. The V821 Avaota F1 board configures the vendor driver with one touch slot, so finger ID 1 is already invalid on that device. Fixes: 66603243f528 ("Input: add driver for Hynitron cstxxx touchscreens") Signed-off-by: Jianing Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260804031339.2379-1-m13940358460@163.com Assisted-by: Antigravity:gemini-3.6-flash Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 2b0403fb7e28f65883cd03814b62c9aa9bc7f04d Author: Dmitry Torokhov Date: Thu Jun 25 22:17:55 2026 -0700 Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue commit 8786d74bf50e6797b6f655eb381ef6b25451161f upstream. Previously, rmi_f54_buffer_queue() waited for the worker thread to finish but ignored whether it succeeded. If the worker failed (e.g., due to a timeout or register read failure), the queue thread would silently return success, delivering stale or uninitialized memory to userspace. Add a 'report_error' field to struct f54_data to store the worker's exit status. Check this field in rmi_f54_buffer_queue() after the worker finishes, and mark the buffer as VB2_BUF_STATE_ERROR if an error occurred. Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics") Reported-by: sashiko-bot@kernel.org Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260626051802.4033172-6-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 1d718f1461766e9f00a8dbeb4f13f1b1c19d90ac Author: Dmitry Torokhov Date: Thu Jun 25 22:17:54 2026 -0700 Input: synaptics-rmi4 - block s_input when F54 queue is busy commit fbfd76746adc16d64be29ff113f673b70bc3f5c2 upstream. Changing the input (diagnostic report type) mid-stream changes the report size. Since V4L2 buffers are allocated based on the size at stream start, changing the input while streaming could lead to a heap buffer overflow if the new size is larger than the allocated buffers. Prevent this by blocking VIDIOC_S_INPUT with -EBUSY if the V4L2 queue is busy (streaming). Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics") Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Reviewed-by: Hans Verkuil Link: https://patch.msgid.link/20260626051802.4033172-5-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 12be3c6ca9589afd6ade41a59c761866e526634d Author: Bryam Vargas Date: Thu Jun 25 22:17:52 2026 -0700 Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer commit 49c5adc2b7d6e43c5cf033e1c86fdb9c16ababb1 upstream. rmi_f54_work() reads a diagnostics report from the device into f54->report_data, sizing the transfer with rmi_f54_get_report_size(): report_size = rmi_f54_get_report_size(f54); ... for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) { int size = min(F54_REPORT_DATA_SIZE, report_size - i); ... rmi_read_block(.., f54->report_data + i, size); } report_data is allocated once at probe from F54's own electrode counts (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))), but rmi_f54_get_report_size() computes the size from drv_data->num_*_electrodes when those are set, i.e. from the F55 function's electrode counts. Both counts come straight from device queries (F54 and F55 each report up to 255 electrodes) and nothing constrains the F55 counts to the F54 ones. A malicious or malfunctioning RMI4 device that reports larger F55 electrode counts than its F54 counts makes report_size exceed the allocation, so the read loop writes past report_data (and the V4L2 dequeue memcpy() then reads past it). On conforming hardware the F55 configured electrodes are a subset of the F54 physical electrodes, so report_size never exceeds the buffer and well-behaved devices are unaffected. Record the allocation size and reject a report that does not fit, mirroring the existing zero-size check. Fixes: c762cc68b6a1 ("Input: synaptics-rmi4 - propagate correct number of rx and tx electrodes to F54") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260626051802.4033172-3-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 77749685e55da19b187df215b5da4080842ca5c7 Author: Dmitry Torokhov Date: Thu Jun 25 22:17:51 2026 -0700 Input: synaptics-rmi4 - zero report size on F54 work error commit dc76c3c8e8ad09362b8c1561f3928288c15cba2e upstream. In rmi_f54_work(), if an error occurs during report request or command verification, the code jumped directly to the 'error' label, bypassing the 'abort' label where f54->report_size was normally zeroed out. This left f54->report_size containing its previous successful payload size. If a user then altered the V4L2 format to a smaller size, and a subsequent run failed, rmi_f54_buffer_queue() would copy the stale, larger payload size into the shrunken V4L2 buffer, causing a heap buffer overflow. Fix this by merging the 'abort' and 'error' labels into a single 'out' exit path, and ensuring that f54->report_size is always set to 0 on failure by checking for error and zeroing the local report_size first. Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics") Cc: stable@vger.kernel.org Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260626051802.4033172-2-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 8e3e0f23f8fd4bf62c410954cc7c544315e6919c Author: George Wilson Date: Fri Aug 7 11:59:00 2026 -0500 powerpc/pseries: lparcfg - fix kbuf[] underflow commit fb442a6673ff1046bf67754957d95880fdb394b5 upstream. In lparcfg_write(), a count of 0 results in kbuf[] being indexed at -1. Check for count == 0 in the existing check for count > sizeof(kbuf) and return -EINVAL if true. Fixes: 74422e2b1939 ("powerpc/pseries: Remove VLA from lparcfg_write()") Acked-by: Nayna Jain Tested-by: R Nageswara Sastry Cc: stable@vger.kernel.org # 4.20 Signed-off-by: George Wilson Signed-off-by: Madhavan Srinivasan Signed-off-by: Greg Kroah-Hartman commit 5232529eaf57f08fe37484e301579a1915b93d14 Author: Pengpeng Hou Date: Fri Jul 24 20:46:27 2026 -0700 Input: iforce - validate input packet lengths commit 5751c781d3c97ab6ce0e2a966156ed882152c415 upstream. iforce_process_packet() reads fixed fields from joystick, wheel and status packets without first checking their lengths. In particular, the shared hats-and-buttons helper unconditionally reads data[6]. The status tail is a sequence of 16-bit effect addresses, but an incomplete final address is also consumed. A successful zero-length USB URB additionally reads the packet ID before the common parser is called. Reject the zero-length USB transfer, require the seven-byte joystick and wheel prefixes and the two-byte status prefix, and consume only complete status-tail addresses. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260720115018.75045-1-pengpeng@iscas.ac.cn Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 9094997f073e941da187382b28905177f9ff80f9 Author: Zhefu Zhang Date: Sun Aug 2 15:36:54 2026 -0700 Input: atkbd - skip deactivate for Xiaomi Book Pro 14's internal keyboard commit 3a046db33bb9f28b43a951a7a090db771dc0f8b3 upstream. The internal keyboard of the Xiaomi Book Pro 14 does not work unless atkbd skips deactivating it at the end of atkbd_probe(). Using 'i8042.dumbkbd=1' also makes the keyboard work, but then the driver never writes to the keyboard at all, so the Caps Lock LED is lost. The atkbd_deactivate_fixup quirk fixes both without a boot parameter. DMI: XIAOMI Xiaomi Book Pro 14/TM2424, BIOS XMAPT4B0P0909 05/06/2026 Signed-off-by: Zhefu Zhang Reviewed-by: Andrew Zhou Link: https://patch.msgid.link/20260802031559.19701-1-a723356@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit da6b8b05db0cf43e0cc198431fa8ee9739b3b817 Author: Linmao Li Date: Fri Jul 24 18:42:06 2026 -0700 Input: psxpad-spi - set driver data before use commit 732f38c36059e68ba3b4b89c56911d777fd3185c upstream. psxpad_spi_suspend() retrieves the controller state with spi_get_drvdata(), but probe never stores it, so suspend dereferences a NULL pointer. Store it during probe. Fixes: 8be193c7b1f4 ("Input: add support for PlayStation 1/2 joypads connected via SPI") Signed-off-by: Linmao Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260721055551.1714965-1-lilinmao@kylinos.cn Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 81b07470cb2937ceb74b00be88151582a322433b Author: Richard Davies Date: Sun Aug 2 17:53:10 2026 -0700 Input: focaltech - fix array out-of-bounds in focaltech_process_rel_packet commit 296736076b3fd078742651c719555a488624023a upstream. Make finger2 (and also finger1) unsigned, so that if the finger index in the packet is 0 then subtracting 1 creates an array index which overflows above the existing check for FOC_MAX_FINGERS, as the existing comment says it should, instead of writing to state->fingers[-1]. Fixes: 05be1d079ec0 ("Input: psmouse - support for the FocalTech PS/2 protocol extensions") Signed-off-by: Richard Davies Link: https://patch.msgid.link/20260701190932.14960-1-richard@arachsys.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 0739c65e799d4a93fe573ed23255a71fcfcc5438 Author: Dmitry Torokhov Date: Thu Jun 25 22:17:50 2026 -0700 Input: synaptics-rmi4 - fix F55 transmitter electrode count typo commit 6058f0fea10f3caf63a435677358d1b8e9325114 upstream. During F55 sensor detection, the transmitter (TX) electrode count was incorrectly assigned the value of the receiver (RX) electrode count due to copy-paste typos. This incorrect value was then propagated to the driver data and used by F54 to determine the diagnostics report size. On devices with more RX than TX electrodes, this inflated the perceived TX count, leading to incorrect report size calculations and potential out-of-bounds buffer accesses. Fix the typos by correctly assigning the TX electrode counts. Fixes: 6adba43fd222 ("Input: synaptics-rmi4 - add support for F55 sensor tuning") Fixes: c762cc68b6a1 ("Input: synaptics-rmi4 - propagate correct number of rx and tx electrodes to F54") Reported-by: sashiko-bot@kernel.org Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260626051802.4033172-1-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit e19b45d5e031a253c0aa4d12f68ad071dfd1317f Author: George Wilson Date: Fri Aug 7 11:58:36 2026 -0500 powerpc/pseries: pci - logic bug commit 649c10bff5cb7a514bf299094833ec8c9190aac3 upstream. The checks on num_vfs in pseries_pci_sriov_enable() are ANDed where OR was apparently intended. Change it to OR. Fixes: 9a7f6b438664 ("powerpc/pseries/pci: Associate PEs to VFs in configure SR-IOV") Acked-by: Nayna Jain Tested-by: R Nageswara Sastry Cc: stable@vger.kernel.org # 4.16 Signed-off-by: George Wilson Signed-off-by: Madhavan Srinivasan Signed-off-by: Greg Kroah-Hartman commit 142346822c7001d36d8f7d6034a51c2dc8ffced8 Author: Kyohei Kadota Date: Thu Jul 23 19:55:57 2026 +0900 Input: xpad - add support for ZENAIM LEVERLESS commit 7d971337ebfad0b173cb46097c709db174ac3557 upstream. Add the VID/PID for the ZENAIM LEVERLESS controller to xpad_device and the VID to xpad_table. Signed-off-by: KADOTA, Kyohei Link: https://patch.msgid.link/CAFMepckDUuOHiDDVVhUYc-UqJMeCqrWSfCuxbJ2x2sGgdDD4nw@mail.gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit e5cb281913621fcb6b8d6f822afcf550cac56e0d Author: Asad Kamal Date: Thu Jul 30 15:00:00 2026 +0800 drm/amdgpu: fix aperture iounmap skipped on device removal commit f9e5f51549000e2665e3b5e02ff876b9e09cfe95 upstream. amdgpu_pci_remove() calls drm_dev_unplug() before invoking the fini routines. After drm_dev_unplug() the drm_dev_enter() guard in amdgpu_ttm_fini() always returns false, so iounmap() for aper_base_kaddr is silently skipped. On connected_to_cpu hardware ioremap_cache() maps the aperture as WB; when iounmap() is skipped the stale WB PAT entry persists. On reload IP discovery's memremap(MEMREMAP_WC) on the same aperture range hits a WB/WC conflict, producing an ioremap error and failing re-probe. Remove the drm_dev_enter() guard and call iounmap() unconditionally. The aperture mapping is plain MMIO and does not require device-presence protection. Surprise-removal cleanup of aper_base_kaddr is already handled unconditionally by amdgpu_device_unmap_mmio(). Fixes: 62d5f9f7110a ("drm/amdgpu: Unmap MMIO mappings when device is not unplugged") Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher (cherry picked from commit fb3f68af9f6fce9343a2bd13b4d68a1c02d283df) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 42bc07b4e5a3c8a02a433388f562a8f46d093e11 Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Tue Jul 21 16:19:42 2026 +0800 fbdev: core: Fix pointer desynchronization in fb_io_read() commit 81cc73be40c6f028f1ee3f438ace46afe666dbae upstream. In fb_io_read(), if copy_to_user() performs a partial copy (e.g., due to a faulty user buffer), the loop adjusts the chunk size 'c' and updates the remaining 'count'. However, the hardware 'src' pointer has already been eagerly advanced by the original chunk size. If the loop is allowed to continue, the read will resume from an incorrect, over-advanced offset. Since the remaining 'count' was only decremented by the successful bytes, this desynchronization causes the next iterations to execute more hardware reads than originally bounded, eventually leading to out-of-bounds I/O reads. Fix this by breaking out of the loop immediately upon a partial copy_to_user(). A partial copy indicates a faulty user buffer, making subsequent read attempts futile. Breaking out ensures we return the number of successfully read bytes without risking out-of-bounds hardware accesses in subsequent mismatched iterations. Fixes: 6121cd9ef911 ("fbdev: Move I/O read and write code into helper functions") Cc: stable@vger.kernel.org Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 891129df5de79cd533ae335c6eab24df2ff2b0fd Author: Dawid Wróbel Date: Thu Jul 30 12:58:13 2026 +0200 ASoC: codecs: lpass-wsa-macro: Fix enum kcontrol accesses commit 56f24311fd5607588a47e44675195a9efb200f29 upstream. EAR SPKR PA Gain" and the four "WSA RX* Mux" controls are enumerated, but their get and put callbacks access the value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 ("ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type") and commit 0ea5eff7c606 ("ASoC: codecs: va-macro: fix accessing array out of bounds for enum type"), but wsa-macro was missed. On 64-bit kernels with CONFIG_SND_CTL_DEBUG this trips the elem value sanity check and every read of these controls fails with -EINVAL. Fixes: 809bcbcecebf ("ASoC: codecs: lpass-wsa-macro: Add support to WSA Macro") Fixes: 2c4066e5d428 ("ASoC: codecs: lpass-wsa-macro: add dapm widgets and route") Assisted-by: Claude:claude-fable-5 Cc: stable@vger.kernel.org Signed-off-by: Dawid Wróbel Reviewed-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260730-worktree-lpass-tx-macro-enum-fix-v2-2-6d091c736116@dawidwrobel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ad8b255006580793b52aabae78cd084f52d69d85 Author: Peter Ujfalusi Date: Wed Aug 5 11:24:11 2026 +0300 ASoC: cs35l41: sort the register default table commit d74aac116cfb2058b15df53996d23232b310f7ff upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). cs35l41_reg[] lists CS35L41_BSTCVRT_PEAK_CUR (0x3808) after CS35L41_BSTCVRT_COEFF (0x3810) and CS35L41_BSTCVRT_SLOPE_LBST (0x3814), so the binary search does not find those two entries. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 5f2f539901b0 ("ASoC: cs35l41: Correct handling of some registers in the cache") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Charles Keepax Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20260805082413.26174-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 673348de844718f237567c461ea5cd7c4a5652a9 Author: Peter Ujfalusi Date: Wed Aug 5 11:24:12 2026 +0300 ASoC: cs35l45: sort the register default table commit f39a68ed08bb6eef0ae711b41d645ee5e9448c09 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). cs35l45_defaults[] lists the DSP1_RX*_RATE and DSP1_TX*_RATE registers (0x02b80080 - 0x02b802b8) in the middle of the table, ahead of entries with much lower addresses, so the binary search does not find 36 of its 73 entries. regcache_reg_needs_sync() then cannot compare those against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 74b14e2850a3 ("ASoC: cs35l45: DSP Support") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Charles Keepax Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20260805082413.26174-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c18fe394ddcce714543e744c8b89d7383a91aa13 Author: Peter Ujfalusi Date: Wed Aug 5 11:24:13 2026 +0300 ASoC: cs4265: sort the register default table commit e4fe3e046524e5de3c04c6eef3743780cbdc231c upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). cs4265_reg_defaults[] lists CS4265_INT_MASK (0x0e), CS4265_STATUS_MODE_MSB (0x0f) and CS4265_STATUS_MODE_LSB (0x10) after CS4265_SPDIF_CTL1 (0x11) and CS4265_SPDIF_CTL2 (0x12), so the binary search does not find those three entries. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: fb6f806967f6 ("ASoC: Add support for the CS4265 CODEC") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Charles Keepax Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20260805082413.26174-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b270ed327380428581bbcbd85707f62e942428d7 Author: Peter Ujfalusi Date: Thu Jul 30 11:59:14 2026 +0300 ASoC: SOF: sof-audio: Fix error path in sof_widget_setup_unlocked() commit e780e4917d43683224812400fe3dc4816fceba75 upstream. If either tplg_ops->dai_config or widget_kcontrol_setup fail during widget setup we would double decrement the use_count of the widget because the sof_widget_free_unlocked() would be called twice, similarly the core_put would be invoked twice as well. Since the use_count and core_put() is handled within the widget_free function we need to return without falling through the pipe_widget_free label. The fixes tag is picked to the last change around this part of the code which is adequately old enough for backporting purposes. Link: https://github.com/thesofproject/sof/issues/10826 Fixes: 31ed8da1c8e5 ("ASoC: SOF: sof-audio: Modify logic for enabling/disabling topology cores") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260730085914.27546-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cc423f4105fe145b33e1d7cad34245a798358f73 Author: Hidayath Khan Date: Thu Jul 30 16:22:16 2026 +0200 s390/qeth: validate user buffer length in SNMP and ARP query ioctls commit d141f087b1af656f055d7c5793a3e87817ba0bbe upstream. qeth_snmp_command() and qeth_l3_arp_query() allocate a buffer sized by a user-supplied length (udata_len) without checking a lower bound, then set udata_offset to a fixed non-zero value and pass both to a reply callback. The callback bounds-checks the copy with if ((udata_len - udata_offset) < len) Both fields are u32, so a udata_len smaller than udata_offset makes the subtraction wrap and the check pass, and the following memcpy() writes past the allocation. A udata_len of 0 also yields ZERO_SIZE_PTR from kzalloc(), which the existing NULL check does not catch. Reject buffers smaller than udata_offset before allocating, so the callback subtraction can no longer underflow. Fixes: 4a71df50047f ("qeth: new qeth device driver") Cc: stable@vger.kernel.org Reviewed-by: Alexandra Winter Signed-off-by: Hidayath Khan Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260730142216.218309-1-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f75f174edc865738522e514d042cf5627f084859 Author: Wyatt Feng Date: Mon Aug 3 18:16:39 2026 +0200 mptcp: fastopen: only mark MPTFO subflows with SYN data commit e00b63056fb4f261455b3e5df5268a1f8ce47a87 upstream. Passive TCP Fast Open accepts a valid-cookie SYN even when it carries no data. In that case the child socket's receive queue is intentionally left empty. mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking for queued SYN data. That made data-less TFO SYNs hit a WARN and, if the warning was non-fatal, left stale MPTFO state behind. The stale flag could later trigger a state-confusion bug in check_fully_established(). Only mark the subflow as MPTFO after confirming that an SKB was queued. Return quietly when the receive queue is empty. Note that mptcp_subflow_context's is_mptfo field is now not just about subflows where the TFO was present, but about MPTFO subflow that consumed SYN data. Only having a valid cookie but not carrying data is not really "doing TFO". Fixes: 36b122baf6a8 ("mptcp: add subflow_v(4,6)_send_synack()") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-7-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 26dac5c9ffb20812b475fdf253eb04fab99cff3b Author: Matthieu Baerts (NGI0) Date: Mon Aug 3 18:16:33 2026 +0200 mptcp: options: reset DSS fields in case of unexpected size commit 35772b4981f38ba8059372cde8753e8e477e98ec upstream. A remote peer could send a malformed DSS with a wrong size, followed by another DSS or MPC + Data. In this case, the first suboption will be ignored, but leaving some fields written, which could lead to inconsistency or access uninitialized data. Explicitly reset the fields that could have been modified in case of unexpected size. Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d%40kernel.org?part=1 Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path") Cc: stable@vger.kernel.org Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-1-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit dc1d8d3eb345c616fbe922a010fa391c72c54d52 Author: Matthieu Baerts (NGI0) Date: Mon Aug 3 18:16:34 2026 +0200 mptcp: avoid combining some incoming suboptions commit b6ee361524641f57b2e2363f7737f20e17f67827 upstream. Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN. Fixes: eda7acddf808 ("mptcp: Handle MPTCP TCP options") Cc: stable@vger.kernel.org Link: https://www.rfc-editor.org/rfc/rfc8684.html#section-3.5-5.1 [1] Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-2-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6e46970fc0001a5b58a27c8e5615224555eede05 Author: Gang Yan Date: Mon Aug 3 18:16:37 2026 +0200 selftests: mptcp: join: mark tests with data corruption as failed commit ca318e7bbb7723f57bcd9e69a2873b5884435552 upstream. check_transfer() compares the input and output files byte-by-byte using `cmp -l "$in" "$out" | while read ...`. Because the while-loop body runs in a subshell (the script sets neither lastpipe nor pipefail), the fail_test call inside it -- which sets the global ret/last_test_failed -- and the `return 1` both act on the subshell, not on check_transfer(). check_transfer() thus always falls through to `return 0`, and any data corruption affecting only the payload (leaving the subflow/PM counters untouched) is silently reported as PASS. Fixes: 8117dac3e7c3 ("selftests: mptcp: add invert check in check_transfer") Cc: stable@vger.kernel.org Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-5-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e0285bb152211c00900136b66d4b420c14a59094 Author: Bryam Vargas Date: Fri Jul 31 12:44:11 2026 -0500 selinux: reject an unclaimed class value in security_get_classes() commit 22b05fec62c0fe9864cfceb52f7d0f3a34d9b1dd upstream. security_get_classes() sizes an array by p_classes.nprim and fills it at value - 1, so a class value the policy never defines leaves a NULL. sel_make_classes() passes every entry to sel_make_dir(), reaching the same d_alloc_name() dereference as the permission array. The class symbol table is allowed to be sparse (policydb_class_isvalid() exists to absorb that), but this getter builds its own array straight from the hash table and has no such predicate. Fail the lookup when a value went unclaimed instead of handing out the NULL. Conforming policies define every class they declare and are unaffected. Cc: stable@vger.kernel.org Fixes: 55fcf09b3fe4 ("selinux: add support for querying object classes and permissions from the running policy") Signed-off-by: Bryam Vargas Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 1acc317d67a755a45e32419a15d70e403fa43f0e Author: Bryam Vargas Date: Fri Jul 31 12:44:09 2026 -0500 selinux: do not cancel a policy conversion that never started commit e5c0235a3c4e9eb047a16cd02323fe4ecf2f570e upstream. sel_write_load() calls selinux_policy_cancel() when sel_make_policy_nodes() fails, and that helper dereferences the outgoing policy to cancel its sidtab conversion. On the first policy load there is no outgoing policy: security_load_policy() returns early for that case, before it converts anything, and state->policy is still NULL. A first load that fails while building the selinuxfs tree therefore takes a NULL dereference in selinux_policy_cancel(), reached from a write(2) to /sys/fs/selinux/load. Skip the cancel when there is no old policy, mirroring the check security_load_policy() already makes before it converts. Cc: stable@vger.kernel.org Fixes: 02a52c5c8c3b ("selinux: move policy commit after updating selinuxfs") Signed-off-by: Bryam Vargas Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 2b7ffd7921fcbfe408fb7b372e47454e45b1e6a7 Author: Bryam Vargas Date: Mon Jul 27 20:30:59 2026 -0500 selinux: reject a class permission count below its inherited common commit 9a82dcd98b6e6e11cfd162410967951f12152528 upstream. security_get_permissions() maps an inherited common's permissions into an array sized by the class's own permissions.nprim, but class_read() takes that nprim verbatim from the policy image and never checks that it covers the common. A class that inherits a common of N permissions while declaring a smaller nprim is accepted, and on load the common's permissions are written past the class-sized array -- an out-of-bounds heap write. Reject a class whose permission count is below its inherited common's. Well-formed policies, where the class count already includes the inherited permissions, are unaffected. Cc: stable@vger.kernel.org Fixes: 55fcf09b3fe4 ("selinux: add support for querying object classes and permissions from the running policy") Signed-off-by: Bryam Vargas Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 3161daa3f1e3ca68f8b2b8fa01720b5a8dcc6b40 Author: Bryam Vargas Date: Fri Jul 31 12:44:12 2026 -0500 selinux: require every boolean value to be defined commit a93d37a09b863810653f93d371fb197457d59deb upstream. p_bools.nprim comes from the policy image independently of how many booleans follow it, and cond_index_bool() fills bool_val_to_struct[] at value - 1, so a count larger than the values present leaves NULL entries. Every user of that array then walks it by index and dereferences each entry: cond_evaluate_expr() on the access-vector path, security_get_bools() and security_get_bool_value() behind selinuxfs, and security_set_bools(). A sparse class value is absorbed by policydb_class_isvalid() and its siblings; booleans have no such predicate, and no consumer that could use one. Reject a boolean value that no boolean defines, once, where the array is built. Conforming policies define every boolean they declare and are unaffected. Cc: stable@vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bryam Vargas Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 6515053335d9fb836279232afcedb36ff72e5394 Author: Erni Sri Satya Vennela Date: Tue Aug 18 19:25:31 2026 -0400 net: mana: Fix EQ leak in mana_remove on NULL port [ Upstream commit 65267c9c4f28199985505977bc2c628c82fc50ef ] In mana_remove(), when a NULL port is encountered in the port iteration loop, 'goto out' skips the mana_destroy_eq(ac) call, leaking the event queues allocated earlier by mana_create_eq(). This can happen when mana_probe_port() fails for port 0, leaving ac->ports[0] as NULL. On driver unload or error cleanup, mana_remove() hits the NULL entry and jumps past mana_destroy_eq(). Change 'goto out' to 'break' so the for-loop exits normally and mana_destroy_eq() is always reached. Remove the now-unreferenced out: label. Fixes: 1e2d0824a9c3 ("net: mana: Add support for EQ sharing") Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260420124741.1056179-6-ernis@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni [ hmahfooz: resolve conflict in mana_remove() due to missing commit 3b194343c250 ("net: mana: Implement ndo_tx_timeout and serialize queue resets per port.") ] Signed-off-by: Hamza Mahfooz Signed-off-by: Sasha Levin commit 3e9d5f325e9ce0c9f546a54526a04465b038d0b2 Author: Yizhou Zhao Date: Tue Aug 18 23:16:38 2026 +0300 ipvs: separate destination availability state commit cdcc4e46180df8161f4d2f3c6fd6beaf6990133d upstream. IPVS configuration paths update destination availability while connection accounting updates destination overload state. The two independent states share dest->flags, so their read-modify-write updates can race and lose one another. Keep OVERLOAD in flags, where the preceding patch serializes its updates with dst_lock, and move AVAILABLE to cflags. This keeps configuration- controlled availability out of the scheduler hot cacheline until a scheduler needs to check it. It also prevents availability updates from clobbering overload state. The destination status bits are not exposed through the IPVS sockopt or netlink interfaces, so keep their definitions in the internal IPVS header. Readers can still observe stale destination state; this does not provide a cross-field snapshot. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Link: https://lore.kernel.org/all/8913381c-1e02-35c7-0ec4-61de5a12fd35@ssi.bg/ Assisted-by: Claude-Code:GLM-5.2 Suggested-by: Julian Anastasov Signed-off-by: Yizhou Zhao Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso (cherry picked from commit cdcc4e46180df8161f4d2f3c6fd6beaf6990133d) [ Julian: Backport by removing the hunks from ip_vs_xmit.c ] Signed-off-by: Julian Anastasov Signed-off-by: Sasha Levin commit 68e094232dfe5027c4fd2dcded93d2d6800bae04 Author: Chao Yu Date: Tue Aug 18 19:28:34 2026 +0800 f2fs: fix UAF issue in f2fs_merge_page_bio() commit edf7e9040fc52c922db947f9c6c36f07377c52ea upstream. As JY reported in bugzilla [1], Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 pc : [0xffffffe51d249484] f2fs_is_cp_guaranteed+0x70/0x98 lr : [0xffffffe51d24adbc] f2fs_merge_page_bio+0x520/0x6d4 CPU: 3 UID: 0 PID: 6790 Comm: kworker/u16:3 Tainted: P B W OE 6.12.30-android16-5-maybe-dirty-4k #1 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5 Tainted: [P]=PROPRIETARY_MODULE, [B]=BAD_PAGE, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Workqueue: writeback wb_workfn (flush-254:49) Call trace: f2fs_is_cp_guaranteed+0x70/0x98 f2fs_inplace_write_data+0x174/0x2f4 f2fs_do_write_data_page+0x214/0x81c f2fs_write_single_data_page+0x28c/0x764 f2fs_write_data_pages+0x78c/0xce4 do_writepages+0xe8/0x2fc __writeback_single_inode+0x4c/0x4b4 writeback_sb_inodes+0x314/0x540 __writeback_inodes_wb+0xa4/0xf4 wb_writeback+0x160/0x448 wb_workfn+0x2f0/0x5dc process_scheduled_works+0x1c8/0x458 worker_thread+0x334/0x3f0 kthread+0x118/0x1ac ret_from_fork+0x10/0x20 [1] https://bugzilla.kernel.org/show_bug.cgi?id=220575 The panic was caused by UAF issue w/ below race condition: kworker - writepages - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_merge_page_bio - add_inu_page : cache page #1 into bio & cache bio in io->bio_list - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_merge_page_bio - add_inu_page : cache page #2 into bio which is linked in io->bio_list write - f2fs_write_begin : write page #1 - f2fs_folio_wait_writeback - f2fs_submit_merged_ipu_write - f2fs_submit_write_bio : submit bio which inclues page #1 and #2 software IRQ - f2fs_write_end_io - fscrypt_free_bounce_page : freed bounced page which belongs to page #2 - inc_page_count( , WB_DATA_TYPE(data_folio), false) : data_folio points to fio->encrypted_page the bounced page can be freed before accessing it in f2fs_is_cp_guarantee() It can reproduce w/ below testcase: Run below script in shell #1: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \ -c "pwrite 0 32k" -c "fdatasync" Run below script in shell #2: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \ -c "pwrite 0 32k" -c "fdatasync" So, in f2fs_merge_page_bio(), let's avoid using fio->encrypted_page after commit page into internal ipu cache. Fixes: 0b20fcec8651 ("f2fs: cache global IPU bio") Reported-by: JY Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim [Jiucheng Xu: backport to 6.6.y] Signed-off-by: Jiucheng Xu Signed-off-by: Sasha Levin commit 6f06dbe5012c160e0dba418a5a9cb16c456ad46a Author: Chao Shi Date: Mon Jul 27 16:12:57 2026 -0400 block: stop the timeout timer when releasing a never added disk [ Upstream commit 26cb8ebbfaf713c82e142d08828d4d765057633b ] disk_release() undoes blk_mq_init_allocated_queue() for a disk whose probe failed before add_disk(), but it only calls blk_mq_exit_queue(). Nothing there stops q->timeout, and that timer rolls forward: it stays pending until it next expires, not until the last request completes. So if the driver issued any I/O before adding the disk, the request_queue is freed while still linked into a timer wheel bucket. Commit 6f8191fdf41d ("block: simplify disk shutdown") dropped the blk_cleanup_queue() call that used to stop it. __del_gendisk() and blk_mq_destroy_queue() still do; only the probe failure path lost it. nvme gets there because nvme_update_ns_info() submits Report Zones or FDP io-mgmt-recv on ns->queue before the disk is added, so a later failure - a concurrent reset setting NVME_CTRL_FROZEN, or device_add_disk() failing - lands in put_disk() with the timer armed: BUG: KASAN: slab-use-after-free in detach_if_pending+0x30c/0x340 Write of size 8 at addr ffff888004d71310 by task kworker/u8:2/37 __timer_delete_sync+0x156/0x240 kernel/time/timer.c:1621 blk_sync_queue+0x22/0x40 block/blk-core.c:222 nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c:5362 nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c:3264 Allocated by task 34: __blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c:4462 nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c:4146 Freed by task 0: blk_free_queue_rcu+0x3a/0x50 block/blk-core.c:254 rcu_core+0xc10/0x1730 kernel/rcu/tree.c:2857 The queue being synced there is ctrl->admin_q, only a victim sharing a timer wheel bucket with the freed queue's dangling entry; other runs tripped in enqueue_timer(), __run_timers() or blk_mq_timeout_work(). Failing nvme_alloc_ns() with a debug patch makes it deterministic: one leaked timer trips KASAN within seconds, while 1987 patched releases produced no splat. Stop the timer and the queue work items before blk_mq_exit_queue(), like blk_mq_destroy_queue() does. Found by FuzzNvme. Fixes: 6f8191fdf41d ("block: simplify disk shutdown") Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260727201257.211635-1-coshi036@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin