commit 1253a6aa5d104312bf0992afacc15220ae35bdf9 Author: Greg Kroah-Hartman Date: Mon Oct 26 16:09:28 2026 +0100 Linux 6.18.59 Link: https://lore.kernel.org/r/20261023163714.201276352@linuxfoundation.org Tested-by: Wentao Guan Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Barry K. Nathan Tested-by: Brett A C Sheffield Tested-by: Miguel Ojeda Tested-by: SJ Park Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman commit 9a5d65b06dc338ed2f68f9096e8d630d4669b34c Author: Paulo Alcantara Date: Fri Sep 25 20:16:09 2026 -0300 smb: client: drain outstanding I/O before truncating on O_TRUNC open commit 3581f843defa0bb30fd7da1e7dba170465e13a95 upstream. cifs_do_truncate() flushes the pagecache with filemap_write_and_wait() before resetting the file size to zero, but that does not wait for direct/async I/O that was already in flight, which can complete after the truncate and reinstate stale data past the new EOF. Drain outstanding netfs I/O with netfs_wait_for_outstanding_io() before resizing the file. Reported-by: Frank Sorenson Fixes: a8603b52b39f ("smb: client: fix data corruption with concurrent writes and O_TRUNC") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a4c584ea79d958ea1cadc9ce056f6df58a363342 Author: Michal Schmidt Date: Mon Feb 2 11:17:54 2026 +0100 ice: fix crash in ethtool offline loopback test commit a9c354e656597aededa027d63d2ff0973f6b033f upstream. Since the conversion of ice to page pool, the ethtool loopback test crashes: BUG: kernel NULL pointer dereference, address: 000000000000000c #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 1100f1067 P4D 0 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 23 UID: 0 PID: 5904 Comm: ethtool Kdump: loaded Not tainted 6.19.0-0.rc7.260128g1f97d9dcf5364.49.eln154.x86_64 #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:ice_alloc_rx_bufs+0x1cd/0x310 [ice] Code: 83 6c 24 30 01 66 41 89 47 08 0f 84 c0 00 00 00 41 0f b7 dc 48 8b 44 24 18 48 c1 e3 04 41 bb 00 10 00 00 48 8d 2c 18 8b 04 24 <89> 45 0c 41 8b 4d 00 49 d3 e3 44 3b 5c 24 24 0f 83 ac fe ff ff 44 RSP: 0018:ff7894738aa1f768 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000700 RDI: 0000000000000000 RBP: 0000000000000000 R08: ff16dcae79880200 R09: 0000000000000019 R10: 0000000000000001 R11: 0000000000001000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ff16dcae6c670000 FS: 00007fcf428850c0(0000) GS:ff16dcb149710000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3: 0000000121227005 CR4: 0000000000773ef0 PKRU: 55555554 Call Trace: ice_vsi_cfg_rxq+0xca/0x460 [ice] ice_vsi_cfg_rxqs+0x54/0x70 [ice] ice_loopback_test+0xa9/0x520 [ice] ice_self_test+0x1b9/0x280 [ice] ethtool_self_test+0xe5/0x200 __dev_ethtool+0x1106/0x1a90 dev_ethtool+0xbe/0x1a0 dev_ioctl+0x258/0x4c0 sock_do_ioctl+0xe3/0x130 __x64_sys_ioctl+0xb9/0x100 do_syscall_64+0x7c/0x700 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] It crashes because we have not initialized libeth for the rx ring. Fix it by treating ICE_VSI_LB VSIs slightly more like normal PF VSIs and letting them have a q_vector. It's just a dummy, because the loopback test does not use interrupts, but it contains a napi struct that can be passed to libeth_rx_fq_create() called from ice_vsi_cfg_rxq() -> ice_rxq_pp_create(). Fixes: 93f53db9f9dc ("ice: switch to Page Pool") Signed-off-by: Michal Schmidt Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 9f158a9b10e1e960eaf3da992b64e43a3487d238 Author: Alexander Lobakin Date: Mon Nov 24 18:07:35 2025 +0100 ice: fix broken Rx on VFs commit 436fa8e7d1a119ec90f39e7c2ce0f3a146652899 upstream. Since the tagged commit, ice stopped respecting Rx buffer length passed from VFs. At that point, the buffer length was hardcoded in ice, so VFs still worked up to some point (until, for example, a VF wanted an MTU larger than its PF). The next commit 93f53db9f9dc ("ice: switch to Page Pool"), broke Rx on VFs completely since ice started accounting per-queue buffer lengths again, but now VF queues always had their length zeroed, as ice was already ignoring what iavf was passing to it. Restore the line that initializes the buffer length on VF queues basing on the virtchnl messages. Fixes: 3a4f419f7509 ("ice: drop page splitting and recycling") Reported-by: Jakub Slepecki Reviewed-by: Tony Nguyen Signed-off-by: Alexander Lobakin Reviewed-by: Aleksandr Loktionov Tested-by: Jakub Slepecki Link: https://patch.msgid.link/20251124170735.3077425-1-aleksander.lobakin@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f4a25618c36835d073caef2745e6bf02ad2723ca Author: Michal Kubiak Date: Thu Sep 25 11:22:53 2025 +0200 ice: switch to Page Pool commit 93f53db9f9dc4a16b40ecd18e6d338ad57e4b670 upstream. This patch completes the transition of the ice driver to use the Page Pool and libeth APIs, following the same direction as commit 5fa4caff59f2 ("iavf: switch to Page Pool"). With the legacy page splitting and recycling logic already removed, the driver is now in a clean state to adopt the modern memory model. The Page Pool integration simplifies buffer management by offloading DMA mapping and recycling to the core infrastructure. This eliminates the need for driver-specific handling of headroom, buffer sizing, and page order. The libeth helper is used for CPU-side processing, while DMA-for-device is handled by the Page Pool core. Additionally, this patch extends the conversion to cover XDP support. The driver now uses libeth_xdp helpers for Rx buffer processing, and optimizes XDP_TX by skipping per-frame DMA mapping. Instead, all buffers are mapped as bi-directional up front, leveraging Page Pool's lifecycle management. This significantly reduces overhead in virtualized environments. Performance observations: - In typical scenarios (netperf, XDP_PASS, XDP_DROP), performance remains on par with the previous implementation. - In XDP_TX mode: * With IOMMU enabled, performance improves dramatically - over 5x increase - due to reduced DMA mapping overhead and better memory reuse. * With IOMMU disabled, performance remains comparable to the previous implementation, with no significant changes observed. - In XDP_DROP mode: * For small MTUs, (where multiple buffers can be allocated on a single memory page), a performance drop of approximately 20% is observed. According to 'perf top' analysis, the bottleneck is caused by atomic reference counter increments in the Page Pool. * For normal MTUs, (where only one buffer can be allocated within a single memory page), performance remains comparable to baseline levels. This change is also a step toward a more modular and unified XDP implementation across Intel Ethernet drivers, aligning with ongoing efforts to consolidate and streamline feature support. Suggested-by: Maciej Fijalkowski Suggested-by: Alexander Lobakin Reviewed-by: Alexander Lobakin Reviewed-by: Jacob Keller Signed-off-by: Michal Kubiak Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 0026267561bc64290390cb2753f28b2fd6bf5f12 Author: Michal Kubiak Date: Thu Sep 25 11:22:52 2025 +0200 ice: drop page splitting and recycling commit 3a4f419f750946181e3d6a339a1ef1942c5b5685 upstream. As part of the transition toward Page Pool integration, remove the legacy page splitting and recycling logic from the ice driver. This mirrors the approach taken in commit 920d86f3c552 ("iavf: drop page splitting and recycling"). The previous model attempted to reuse partially consumed pages by splitting them and tracking their usage across descriptors. While this was once a memory optimization, it introduced significant complexity and overhead in the Rx path, including: - Manual refcount management and page reuse heuristics; - Per-descriptor buffer shuffling, which could involve moving dozens of `ice_rx_buf` structures per NAPI cycle; - Increased branching and cache pressure in the hotpath. This change simplifies the Rx logic by always allocating fresh pages and letting the networking stack handle their lifecycle. Although this may temporarily reduce performance (up to ~98% in some XDP cases), it greatly improves maintainability and paves the way for Page Pool, which will restore and exceed previous performance levels. The `ice_rx_buf` array is retained for now to minimize diffstat and ease future replacement with a shared buffer abstraction. Co-developed-by: Alexander Lobakin Signed-off-by: Alexander Lobakin Reviewed-by: Alexander Lobakin Reviewed-by: Jacob Keller Signed-off-by: Michal Kubiak Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit c8bd04221f6a82780104f4c9fa820a0179b1c3ad Author: Michal Kubiak Date: Thu Sep 25 11:22:51 2025 +0200 ice: remove legacy Rx and construct SKB commit 9e314a3c525c91c1e918546f472585cdbd44fbd1 upstream. The commit 53844673d555 ("iavf: kill 'legacy-rx' for good") removed the legacy Rx path in the iavf driver. This change applies the same rationale to the ice driver. The legacy Rx path relied on manual skb allocation and header copying, which has become increasingly inefficient and difficult to maintain. With the stabilization of build_skb() and the growing adoption of features like XDP, page_pool, and multi-buffer support, the legacy approach is no longer viable. Key drawbacks of the legacy path included: - Higher memory pressure due to direct page allocations and splitting; - Redundant memcpy() operations for packet headers; - CPU overhead from eth_get_headlen() and Flow Dissector usage; - Compatibility issues with XDP, which imposes strict headroom and tailroom requirements. The ice driver, like iavf, does not benefit from the minimal headroom savings that legacy Rx once offered, as it already splits pages into fixed halves. Removing this path simplifies the Rx logic, eliminates unnecessary branches in the hotpath, and prepares the driver for upcoming enhancements. In addition to removing the legacy Rx path, this change also eliminates the custom construct_skb() functions from both the standard and zero-copy (ZC) Rx paths. These are replaced with the build_skb() and standardized xdp_build_skb_from_zc() helpers, aligning the driver with the modern XDP infrastructure and reducing code duplication. This cleanup also reduces code complexity and improves maintainability as we move toward a more unified and modern Rx model across drivers. Co-developed-by: Alexander Lobakin Signed-off-by: Alexander Lobakin Reviewed-by: Alexander Lobakin Reviewed-by: Jacob Keller Signed-off-by: Michal Kubiak Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 4d143608a0445443a85c9b29f4c9f8e63d5dbfc9 Author: Paulo Alcantara Date: Thu Oct 22 18:03:33 2026 -0400 smb: client: fix data corruption with concurrent writes and O_TRUNC [ Upstream commit a8603b52b39f520ea8a34def74c23fba87396d3e ] cifs_do_truncate() flushes dirty pages with filemap_write_and_wait() and truncates the file on the server, but in the old code both operations ran without holding i_rwsem or invalidate_lock. A concurrent buffered write via netfs_perform_write() -- which only needs i_rwsem shared -- could dirty new pages after the flush but before the local truncation, and those pages would be silently discarded by cifs_setsize() -> truncate_pagecache(). Fix by acquiring inode_lock (exclusive i_rwsem) and filemap_invalidate_lock at the top of cifs_do_truncate(), so the entire flush-truncate-resize sequence is atomic with respect to: - buffered writes (blocked by exclusive i_rwsem, since netfs_start_io_write takes i_rwsem shared), - read page faults (blocked by exclusive invalidate_lock, since filemap_fault takes it shared), - writeback collection (blocked by netfs_wb_begin/netfs_wb_end around the server truncate and local resize, since netfs_writepages also acquires the wb lock). Fixes: 110fee6b9bb5 ("smb: client: fix missing timestamp updates with O_TRUNC") Signed-off-by: Paulo Alcantara Reviewed-by: Namjae Jeon Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Replaced netfs_wb_begin()/netfs_wb_end() with direct wb_lock mutex operations. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c027f8b429dbb2157fc1b503df196e272d947c89 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Thu Oct 22 15:09:47 2026 -0400 vsock/vmci: validate packet source for connected sockets [ Upstream commit ad9a7da3fa39c2d616ec0dd3cf6e30531d032fe7 ] vmci_transport_recv_stream_cb() looks up sockets first by the full source and destination tuple, then by destination only in the bound table. The fallback can select a non-listening socket without checking whether the packet came from its stored peer. This was reproduced with two VMCI contexts. A RST from the context not stored in a TCP_SYN_SENT socket reset that socket after it was selected by the destination-only lookup. VMCI can process notification packets in bottom-half context when the socket is not owned by user context, or defer packets to a workqueue. Use vsock_check_source() after taking the socket lock in the bottom-half path, and recheck after lock_sock() in the workqueue path. Listening sockets continue to accept packets from any source. Reply with a RST addressed from the received packet before dropping a source that fails validation. This preserves the existing reset behavior for bound non-listening and concurrently closed sockets without directing the reset to a connected socket's stored peer. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reported-by: Sashiko Closes: https://lore.kernel.org/netdev/20260814121255.6B5001F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Suggested-by: Stefano Garzarella Suggested-by: Paolo Abeni Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Vishnu Dasa Link: https://patch.msgid.link/20260826003929.966160-3-4ncienth@gmail.com Signed-off-by: Jakub Kicinski [ sashal: Replaced two calls to the unavailable vsock_check_source() helper with equivalent inline conditions. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ecd7ead4bf05e221e90f18a29aec570a50fd1592 Author: Ido Schimmel Date: Thu Oct 22 13:22:21 2026 -0400 ipv4: udp: Create exceptions before socket matching [ Upstream commit 4c3499f79f8c7e8561266bcc220a18538cec0458 ] Currently, when ICMP Fragmentation Needed and Redirect Message packets are locally delivered and quote a UDP packet, a FIB nexthop exception (FNHE) is only created if the kernel can match the UDP packet to an existing socket. This behavior allows off-path attackers to conduct a side-channel attack on the FNHE cache in order to discover the ephemeral port used by a connected UDP socket. Commit 6457378fe796 ("ipv4: use siphash instead of Jenkins in fnhe_hashfun()") and commit 67d6d681e15b ("ipv4: make exception cache less predictible") tried to mitigate such attacks by making it harder for attackers to discover hash collisions in the FNHE cache and by randomizing the number of exceptions a hash bucket can hold, respectively. Unfortunately, both of the mitigations can be bypassed. Instead, mitigate such attacks by always creating a FNHE, even before trying to find a matching socket. Do that by calling ipv4_update_pmtu() and ipv4_redirect(), the helpers used when the quoted packet did not originate from a socket. This means that guesses (right or wrong) from an off-path attacker will always result in a FNHE being created or updated in the cache that the attacker can observe. Pass an oif of 0, in a similar fashion to icmp_err(). This is also the oif used by the socket path for sockets that are not bound to a device. Note that this does not allow attackers to create FNHEs that they could not create before, as both helpers can already be reached with little to no validation. For example, by sending an ICMP error that quotes an ICMP Echo Reply or one that quotes a UDP source port that matches a wildcard socket. Also note that in the good case (matched socket) the above scheme comes at the cost of an extra route lookup, as the no socket helpers perform their own lookup before the one performed by ipv4_sk_update_pmtu() / ipv4_sk_redirect(). When the two resolve to different nexthops, it also results in two exceptions being created for the same destination IP. One in the FNHE cache of the nexthop resolved by the no socket helpers and another in the FNHE cache of the nexthop used by the socket. Fixes: 4895c771c7f0 ("ipv4: Add FIB nexthop exceptions.") Cc: stable@vger.kernel.org Reported-by: Amit Klein Reported-by: Noam Caspi Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260828192344.2596928-3-idosch@nvidia.com Signed-off-by: Jakub Kicinski [ sashal: inlined udp_err_update_exception() logic into the existing udp_err() wrapper to accommodate the separate __udp4_lib_err() handler. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6cd829de69efd9ed3a53aa2421004a0396eb2bd7 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Thu Oct 22 12:27:24 2026 -0400 vsock/virtio: validate packet source for connected sockets [ Upstream commit dee44f41f206becb41c492899c1996cfd7f82a1b ] virtio_transport_recv_pkt() looks up sockets first by the full source and destination tuple, then by destination only in the bound table. The fallback is needed for listening and connecting sockets, but sockets remain in the bound table after connect(), so it can also return a non-listening socket. The fallback does not validate the source address. In TCP_SYN_SENT, a RESPONSE from an unrelated source can transition the victim socket to TCP_ESTABLISHED while its stored remote address remains unchanged. Subsequent RW packets from that source are delivered through the same destination-only fallback. This was reproduced with capability-empty processes under different UIDs. The attacker discovered the target tuple through unprivileged AF_VSOCK sock_diag and caused the victim socket to read 16 attacker-chosen bytes; the intended peer-side socket read 0 of those 16 bytes. Add vsock_check_source() to validate the transport, source port and source CID against the peer stored in a non-listening socket. The local transport is the CID exception because its packets are generated internally with VMADDR_CID_LOCAL as their source, including connections using CID aliases. Use the helper after lock_sock() in the virtio receive path. Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko") Closes: https://lore.kernel.org/netdev/20260813121236.2328599-1-4ncienth@gmail.com/ Cc: stable@vger.kernel.org Suggested-by: Stefano Garzarella Reviewed-by: Bobby Eshleman Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Link: https://patch.msgid.link/20260826003929.966160-2-4ncienth@gmail.com Signed-off-by: Jakub Kicinski [ sashal: Adjusted context for existing vsock APIs without network-namespace support. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 569c34a35fbc9552772aa496bc9b7f36fa4f1d7f Author: Bobby Eshleman Date: Thu Oct 22 12:27:23 2026 -0400 virtio: set skb owner of virtio_transport_reset_no_sock() reply [ Upstream commit a6ae12a599e0f16bc01a38bcfe8d0278a26b5ee0 ] Associate reply packets with the sending socket. When vsock must reply with an RST packet and there exists a sending socket (e.g., for loopback), setting the skb owner to the socket correctly handles reference counting between the skb and sk (i.e., the sk stays alive until the skb is freed). This allows the net namespace to be used for socket lookups for the duration of the reply skb's lifetime, preventing race conditions between the namespace lifecycle and vsock socket search using the namespace pointer. Reviewed-by: Stefano Garzarella Signed-off-by: Bobby Eshleman Link: https://patch.msgid.link/20260121-vsock-vmtest-v16-2-2859a7512097@meta.com Acked-by: Michael S. Tsirkin Signed-off-by: Paolo Abeni Stable-dep-of: dee44f41f206 ("vsock/virtio: validate packet source for connected sockets") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f320b85c90fe5fc9d4d06badd450518323a94a7f Author: Yao Kai Date: Thu Oct 22 11:14:15 2026 -0400 workqueue: Fix unbound pool lifetime for pending pwqs [ Upstream commit cf9c8aaea0d47410df8708bec195889f3a85cd3c ] KASAN reports a use-after-free of an unbound worker_pool in node_activate_pending_pwq(): BUG: KASAN: slab-use-after-free in _raw_spin_trylock+0x6d/0x120 Read of size 4 at addr ffff8880089ce000 by task kworker/u22:0/318 CPU: 1 UID: 0 PID: 318 Comm: kworker/u22:0 Not tainted 7.2.0 #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: 0x0 (flush-8:0) Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x610 kasan_report+0xce/0x100 _raw_spin_trylock+0x6d/0x120 pwq_dec_nr_in_flight+0x4b4/0xcb0 process_one_work+0x921/0x11a0 worker_thread+0x4d0/0xd20 kthread+0x2de/0x3c0 ret_from_fork+0x3aa/0x620 ret_from_fork_asm+0x1a/0x30 Allocated by task 311: alloc_pwq+0x439/0xca0 apply_wqattrs_prepare+0x75e/0xd10 apply_workqueue_attrs_locked+0x44/0xa0 wq_nice_store+0x350/0x450 Freed by task 0: kfree+0x127/0x3b0 rcu_core+0x523/0x1780 handle_softirqs+0x1b3/0x610 Last potentially related work creation: put_unbound_pool+0x3f3/0x7d0 pwq_release_workfn+0x494/0x8e0 kthread_worker_fn+0x1ff/0x790 Canceling the last inactive work skips pwq_dec_nr_active(), so an empty pwq can remain on pending_pwqs when its refcnt reaches zero. pwq_release_workfn() currently puts the pool before removing that pwq. If this drops the last pool reference, the pool can be RCU-freed while the pwq remains reachable, and node_activate_pending_pwq() may trylock the freed pool->lock. Remove the pwq from pending_pwqs before putting the pool. Fixes: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues") Cc: stable@vger.kernel.org Signed-off-by: Yao Kai Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 299912bbc6455117b5ab252ac53cceb1866d7d9c Author: Breno Leitao Date: Thu Oct 22 11:14:14 2026 -0400 workqueue: release pwq pools by pool type [ Upstream commit 3180ee71b676845603274c66f6bb5528939cf470 ] Add is_percpu_pool() and test the pool directly for per cpu. Convert the other open-coded pool->cpu checks -- in put_unbound_pool(), pool_allowed_cpus() and the workqueue watchdog -- to the same helper. No functional change. Signed-off-by: Breno Leitao Signed-off-by: Tejun Heo Use a single-evaluation macro for the pool predicate. Keep the existing watchdog timestamp and reporting behavior, converting only its pool-type test; the newer stall-duration accounting is absent. Stable-dep-of: cf9c8aaea0d4 ("workqueue: Fix unbound pool lifetime for pending pwqs") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 94d13387b96e50a4288f7bbdfe401189246a11a1 Author: Cen Zhang (Microsoft Security FORGE Labs) Date: Thu Oct 22 10:30:46 2026 -0400 io_uring/cancel: don't spin on local work the task can't run [ Upstream commit fddcf4c5321b3ea5f72166c3fd36a9d1c34f80c7 ] io_uring_cancel_generic() refuses to sleep while any ring on the exiting task's tctx has local work pending. It assumes the task is that ring's submitter and that the next io_uring_try_cancel_requests() pass will run the work. This does not hold for a ring that was still IORING_SETUP_R_DISABLED when the task got its tctx node from io_uring_create() or io_ringfd_register(). The submitter is set later by IORING_REGISTER_ENABLE_RINGS, possibly from another task, and only the submitter may run local work on an IORING_SETUP_DEFER_TASKRUN ring. To the exiting task the work stays pending forever, the loop never reaches schedule(), and the task trips the WARN_ON_ONCE() once and then spins in do_exit(). An unprivileged user can set this up at will by creating a disabled ring, having a child enable it and stop, posting to the ring with IORING_OP_MSG_RING and exiting with a request in flight that only the child can complete. The exiting thread burns a CPU until the child runs or dies, and with panic_on_warn set the WARN panics the kernel. Fix by skipping the sleep only when io_allowed_defer_tw_run() allows the task to run the work. This is reasonable since work it cannot run cannot complete any of its requests either, so nothing is lost by sleeping. Drop the WARN_ON_ONCE() since handing a disabled ring to another thread is a supported scenario, not a bug state. Fixes: 360cd42c4e95 ("io_uring: optimise io_req_local_work_add") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) Link: https://patch.msgid.link/20261008191602.45101-1-cenzhang@linux.microsoft.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7123c79206e4932cb7bad0e35e716a82f403f6ea Author: Jens Axboe Date: Thu Oct 22 10:30:45 2026 -0400 io_uring/cancel: move cancelation code from io_uring.c to cancel.c [ Upstream commit ffce324364318220acf83e576eac06549cbf9911 ] There's a bunch of code strictly dealing with cancelations, and that code really belongs in cancel.c rather than in the core io_uring.c file. Move the code there. Mostly mechanical, only real oddity here is that struct io_defer_entry now needs to be visible across both io_uring.c and cancel.c. Signed-off-by: Jens Axboe Stable-dep-of: fddcf4c5321b ("io_uring/cancel: don't spin on local work the task can't run") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 76cb14d6f143302321e9264ffeaa8f7df8862e08 Author: Jens Axboe Date: Thu Oct 22 10:30:44 2026 -0400 io_uring/cancel: move __io_uring_cancel() into cancel.c [ Upstream commit 01e019b2a30df41c485f602a5246124ea911071b ] Yet another function that should be in cancel.c, move it over. Signed-off-by: Jens Axboe Stable-dep-of: fddcf4c5321b ("io_uring/cancel: don't spin on local work the task can't run") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 755e88e78beaf2229692152c9cc11a4223e94690 Author: Jens Axboe Date: Thu Oct 22 10:30:43 2026 -0400 io_uring/cancel: move request/task cancelation logic into cancel.c [ Upstream commit 0d677936d67774f1b4ebfb3b26f207320f0fe3c6 ] Move io_match_task_safe() and helpers into cancel.c, where it belongs. Signed-off-by: Jens Axboe Stable-dep-of: fddcf4c5321b ("io_uring/cancel: don't spin on local work the task can't run") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit de477667b890b1feb614391c6c50d51a9c0ac9c8 Author: Frank Sorenson Date: Thu Oct 22 09:43:09 2026 -0400 cifs: add revalidation on FSCTL failure in smb2_duplicate_extents() [ Upstream commit 53676a5e28231186c9f56d87b7998b640699bc15 ] smb2_duplicate_extents() has no handling for FSCTL_DUPLICATE_EXTENTS_TO_FILE failure: when the FSCTL fails, local inode metadata may be stale from the pre-extension or from concurrent remote writes, but is never refreshed. Force revalidation on FSCTL failure and use i_size_read() for the pre-extension check. Fixes: cfc63fc8126a ("smb3: fix cached file size problems in duplicate extents (reflink)") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 242c7b3a71ddf25bbb65c5231becaa57333af464 Author: Huiwen He Date: Thu Oct 22 09:43:08 2026 -0400 smb/client: refresh allocation size after duplicate extents [ Upstream commit 5906d0e82e8e07d756f3ed1abfac8f8cea2c20dc ] FSCTL_DUPLICATE_EXTENTS_TO_FILE changes the target file extents on the server, but the client does not refresh the target AllocationSize/i_blocks. Callers can observe or use the wrong st_blocks value immediately after the clone, before a later attribute revalidation corrects it. For example, create a reflinked file with a leading hole: xfs_io -f -c "pwrite -S 0x61 0 64k" src touch dst chmod 600 dst xfs_io -c "reflink src 0 1m 64k" dst mkswap dst swapon dst The file still has a hole after mkswap: /mnt/scratch/dst: [0..7]: allocated [8..2047]: hole [2048..2175]: allocated The server also reports only the allocated ranges: server dst size=1114112 blocks=144 but the client reported EOF-derived blocks: client dst size=1114112 blocks=2176 and swapon succeeded: swapon_result=success /mnt/scratch/dst 1.1M 0B -1 So EOF-derived i_blocks can let a sparse reflinked file pass the CIFS swapfile hole check. Fix this by querying FILE_ALL_INFORMATION on the target handle after a successful duplicate extents request. Update i_blocks from AllocationSize and keep the refreshed target inode attributes valid so a following stat does not immediately revalidate again. If the query fails, mark the cached inode attributes stale so a later getattr can refresh them. This also fixes the xfstests generic/370 regression introduced by the i_blocks accounting change, as tested on a Samba "vfs objects = btrfs" share. Fixes: 99cd0a6eeb6c ("smb/client: do not account EOF extension as allocation") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Stable-dep-of: 53676a5e2823 ("cifs: add revalidation on FSCTL failure in smb2_duplicate_extents()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8d891c218016b6145993e082e7f732cb69dd0e29 Author: Tejun Heo Date: Thu Oct 22 09:04:41 2026 -0400 sched_ext: Fix stall when a task enqueued with SCX_ENQ_LAST lands back on its CPU's local DSQ [ Upstream commit 7a9df76679633cf26e0fea882a684012c6ec245a ] With SCX_OPS_ENQ_LAST, the last runnable task on a CPU is passed to ops.enqueue() instead of being kept running. Exiting tasks without SCX_OPS_ENQ_EXITING, migration disabled tasks without SCX_OPS_ENQ_MIGRATION_DISABLED and tasks on an offline rq skip ops.enqueue() and go straight to the local DSQ. This happens in put_prev_task_scx() after the pick has settled on idle, so nothing reschedules the CPU, which idles with the task queued until an unrelated wakeup lands on it or the watchdog fires. scx_mitosis, which sets SCX_OPS_ENQ_LAST without SCX_OPS_ENQ_EXITING, hit this during mass cgroup teardown: exiting tasks stuck in exit_mmap() for over 40 seconds. A task put on the local DSQ runs, as anywhere else. If the SCX_ENQ_LAST enqueue left the task on this CPU's local DSQ, set need_resched on the task being switched in, as proxy_resched_idle() does. resched_curr() would flag the task being put instead, and __schedule() clears that right after the pick. Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Cc: stable@vger.kernel.org # v6.12+ Reported-by: Xiangyu Bu Link: https://github.com/sched-ext/scx/pull/3870 Signed-off-by: Tejun Heo Cc: Dan Schatzberg [ sashal: adjusted context for do_enqueue_task() in the existing sched_ext file layout. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6ac46ae5ac561d4fc7d4246ad83d71bed0d9af9a Author: Jesse Zhang Date: Thu Oct 22 08:54:53 2026 -0400 drm/amdgpu: free the userptr ranges when a CS fails after parser_bos [ Upstream commit 1b4da805a0ba354a549ce07459c871c17dd94fe0 ] amdgpu_cs_parser_bos() allocates an HMM range for every userptr entry of the BO list and looks up the user pages. Those ranges are only freed when amdgpu_cs_parser_bos() itself fails or when amdgpu_cs_submit() checks them under the notifier lock. If amdgpu_cs_patch_jobs(), amdgpu_cs_vm_handling(), amdgpu_cs_sync_rings() or the early part of amdgpu_cs_submit() fails, nothing frees them: neither amdgpu_cs_parser_fini() nor amdgpu_bo_list_free() touch e->range. Each such CS then leaks the range, its hmm_pfns array (8 bytes per page of the userptr BO) and the BO reference the range holds. An IB on a ring that patches the CS in place (e.g. VCN) with an unmapped va_start fails in amdgpu_cs_patch_ibs() and takes this path. Free the ranges on those error paths. Ranges amdgpu_cs_submit() already dropped are NULL, so freeing them again is a no-op. Fixes: fec8fdb54e8f ("drm/amdgpu: fix userptr HMM range handling v2") Reviewed-by: Alex Deucher Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit c52a9542ed7cfd527feb938bd0accada2ac8d267) Cc: stable@vger.kernel.org [ sashal: Adapted cleanup to the existing error_backoff path using amdgpu_ttm_tt_get_user_pages_done() before the mutex unlock. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2058a1fe791bb30fd6e4875a7ada3237076c8541 Author: Taeyang Lee <0wn@theori.io> Date: Thu Oct 22 08:54:42 2026 -0400 tracing: Keep the predicate limit separate from program capacity [ Upstream commit 803aa6fc2dbea25ab9d3ed19eca1c96d0ab17445 ] predicate_parse() adds two to nr_preds to reserve the terminal TRUE and FALSE entries. It also uses that increased value as the limit for parsed predicates. If the initial count is smaller than the number actually parsed, the program can fill the allocation and subsequent accesses can go past its end. Keep nr_preds as the predicate limit and use a separate value for the allocation size. This leaves space for both terminal entries and a zeroed entry when parsing stops at the limit. Cc: stable@vger.kernel.org Fixes: 39f7c41c908b ("tracing/filters: Enable filtering a cpumask field by another cpumask") Link: https://patch.msgid.link/atELCd1XjKVhrkFL@Taeyangs-MacBook-Pro.local Signed-off-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Steven Rostedt [ sashal: Adapted the kzalloc_objs() allocation to the existing kcalloc() call. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 07180a910e9d09e019ee18bdc0adc70f52cb92ca Author: Dmitry Kandybka Date: Thu Oct 22 08:54:34 2026 -0400 tracing: Fix ignored return value of resize_buffer_duplicate_size() [ Upstream commit 3110d09bb98e3ac66482a7b257548a1683ec6c1a ] When tr->allocated_snapshot is true, resize_buffer_duplicate_size() is called to update the snapshot buffer size. However, its return value was not checked. In case of a failed resize this could lead next snapshot being incomplete. Add resize_buffer_duplicate_size() result check and return error if resize fails. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260928152634.4354-1-d.kandybka@gmail.com Fixes: 180e4e390978 ("tracing: Add snapshot refcount") Signed-off-by: Dmitry Kandybka Signed-off-by: Steven Rostedt [ sashal: Adapted snapshot_buffer access to max_buffer in the existing snapshot handler. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a425e1c687595e2dd4e7dada8ddbc4a47d74fd1f Author: Hui Su Date: Thu Oct 22 07:34:55 2026 -0400 sched_ext: idle: Respect task affinity in restricted CPU selection [ Upstream commit 6ac4544eff796666ce6fbcc4be8181c81dfccc85 ] The restricted select_cpu kfunc path handles single-CPU and migration-disabled tasks without going through scx_select_cpu_dfl(). It currently uses prev_cpu as the candidate, even though prev_cpu is only a hint and may no longer be usable after an affinity change. With a caller-provided @allowed mask, this can also return an idle CPU outside p->cpus_ptr. Derive the candidate from task state instead: use the sole CPU in p->cpus_ptr for single-CPU tasks and task_cpu(p) for migration-disabled tasks. Validate it against p->cpus_ptr and @allowed before claiming its idle state. Since the derived candidate may be on a different NUMA node from prev_cpu, also preserve SCX_PICK_IDLE_IN_NODE by rejecting cross-node candidates. Perform all checks before scx_idle_test_and_clear_cpu(), as a successful call consumes the CPU's idle bit. Fixes: 683d2d0faba1 ("sched_ext: idle: Introduce scx_bpf_select_cpu_and()") Cc: stable@vger.kernel.org Signed-off-by: Hui Su Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo [ sashal: Adjusted declaration context to retain rq and rf for the existing task_rq_lock() locking. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dfcfe2874e7c16e8460dc86ac1eeb54ea0e7f8aa Author: Dibin Moolakadan Subrahmanian Date: Thu Oct 22 07:34:42 2026 -0400 drm/i915/dmc: Harden DMC firmware payload parsing [ Upstream commit 8bb1858db453cd4250e3b633f5d2d09206024ca6 ] Validate the conversion of the DMC firmware size from dwords to bytes using check_mul_overflow() before calculating the firmware payload size. Reject zero-length payloads and zero MMIO counts in the DMC firmware header so malformed firmware is caught early. Also set dmc_fw_size only after the payload allocation succeeds. Fixes: eb805623d8b1 ("drm/i915/skl: Add support to load SKL CSR firmware.") Cc: stable@vger.kernel.org Assisted-by: Claude-Code:Sonnet-5 Signed-off-by: Dibin Moolakadan Subrahmanian Reviewed-by: Mitul Golani Signed-off-by: Ankit Nautiyal Link: https://patch.msgid.link/20260922133535.3180973-5-dibin.moolakadan.subrahmanian@intel.com (cherry picked from commit efde6601a1f1daedfe3dcc2816c934ddb44e3eef) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c8b1a4840467930e01f1a9374d991d7a8a2896c1 Author: Christian Brauner Date: Wed Oct 21 11:30:33 2026 -0400 ntfs3: free the sbi after a grace period [ Upstream commit c01b091b06412d3b1b53d8c2925f6de586c8a2fc ] If the "nocase" mount option ntfs3 uses custom hash and dentry compare functions. Both access ntfs3 superblock private information in rcu pathwalk. ntfs_put_super() and ntfs3_kill_sb() drop the info without any rcu delay. A lookup that's still inside the filesystem when the last reference to the mount is dropped causes a UAF. With a pathwalk held up in ntfs_d_hash() while the last reference to the mount goes away: BUG: KASAN: slab-use-after-free in ntfs_nls_to_utf16+0x752/0x940 Read of size 8 at addr ff1100010453c850 by task walker/99 Call Trace: ntfs_nls_to_utf16+0x752/0x940 ntfs_d_hash+0x22b/0x500 link_path_walk+0x11ad/0x1d30 path_lookupat+0x63/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 [...] Allocated by task 95: __kmalloc_cache_noprof+0x249/0x560 ntfs_init_fs_context+0x2db/0x5a0 alloc_fs_context+0x52e/0xc70 [...] Freed by task 98: kfree+0x1db/0x5b0 deactivate_locked_super+0x9c/0xf0 cleanup_mnt+0x9f/0x130 task_work_run+0x131/0x250 The bug is currently masked by the grace period in namespace_unlock() for umount(2). Keep the necessary information until the filesystem private info is freed and free it with an rcu delay. ntfs3_free_sbi() now runs from an rcu callback and drops the upcase table via ntfs_put_shared(). So switch s_shared_lock over to spin_lock_bh(). Otherwise the callback can deadlock against a task holding the lock on the same cpu. Fixes: a3a956c78efa ("fs/ntfs3: Add option "nocase"") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-7-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d977b979081ef2585a15453f309a6311c95ede02 Author: Baokun Li Date: Wed Oct 21 11:30:32 2026 -0400 fs/ntfs3: fix ntfs_mount_options leak in ntfs_fill_super() [ Upstream commit f7edab0cee03a1cbe0e55a7bcab8d2d8b6b74278 ] In ntfs_fill_super(), the fc->fs_private pointer is set to NULL without first freeing the memory it points to. This causes the subsequent call to ntfs_fs_free() to skip freeing the ntfs_mount_options structure. This results in a kmemleak report: unreferenced object 0xff1100015378b800 (size 32): comm "mount", pid 582, jiffies 4294890685 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 ed ff ed ff 00 04 00 00 ................ backtrace (crc ed541d8c): __kmalloc_cache_noprof+0x424/0x5a0 __ntfs_init_fs_context+0x47/0x590 alloc_fs_context+0x5d8/0x960 __x64_sys_fsopen+0xb1/0x190 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e This issue can be reproduced using the following commands: fallocate -l 100M test.file mount test.file /tmp/test Since sbi->options is duplicated from fc->fs_private and does not directly use the memory allocated for fs_private, it is unnecessary to set fc->fs_private to NULL. Additionally, this patch simplifies the code by utilizing the helper function put_mount_options() instead of open-coding the cleanup logic. Reported-by: syzbot+23aee7afc440fe803545@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=23aee7afc440fe803545 Fixes: aee4d5a521e9 ("ntfs3: fix double free of sbi->options->nls and clarify ownership of fc->fs_private") Signed-off-by: Baokun Li Signed-off-by: Konstantin Komarov Preserve the existing sbi && sbi->options guard in the failed-mount cleanup while replacing the open-coded frees with put_mount_options(). Keep clearing sbi->options after release so later cleanup cannot free the same options again. Stable-dep-of: c01b091b0641 ("ntfs3: free the sbi after a grace period") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 129b0a64fe9ac5b4138cc123cccbcce7c65afdf4 Author: YangWen Date: Wed Oct 21 11:30:31 2026 -0400 ntfs3: fix double free of sbi->options->nls and clarify ownership of fc->fs_private [ Upstream commit aee4d5a521e94f658e46c904e08a473daa9c8fc0 ] commit 02f312754c87 ("ntfs3: fix use-after-free of sbi->options in cmp_fnames") introduced a use-after-free bug due to improper handling of sbi->options in error paths. This resulted in crashes when superblock cleanup is performed in ntfs_put_super. This patch ensures that the options structure and its subfields are properly freed, preventing the memory corruption and use-after-free errors. Fixes: 02f312754c87 ("ntfs3: fix use-after-free of sbi->options in cmp_fnames") Reported-by: syzbot+cc433e4cd6d54736bf80@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cc433e4cd6d54736bf80 Signed-off-by: YangWen [almaz.alexandrovich@paragon-software.com: added fixes and closes tags] Signed-off-by: Konstantin Komarov Stable-dep-of: c01b091b0641 ("ntfs3: free the sbi after a grace period") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e0ab437276575a344ed60bd0c2502892e250714a Author: YangWen Date: Wed Oct 21 11:30:30 2026 -0400 ntfs3: fix use-after-free of sbi->options in cmp_fnames [ Upstream commit 02f312754c873efe076888a2fdca982e56617929 ] The root cause is that sbi->options points directly to fc->fs_private. If fc->fs_private is freed while sbi still exists, sbi->options becomes a dangling pointer. This patch ensures that sbi->options is a separate copy of fc->fs_private and duplicates nls_name if present. On superblock release or error, sbi->options->nls_name and sbi->options are freed and sbi->options is set to NULL to avoid any dangling pointer. Reported-by: syzbot+d77c546c60db651a389c@syzkaller.appspotmail.com Signed-off-by: YangWen [almaz.alexandrovich@paragon-software.com: remove syzbot logs from description] Signed-off-by: Konstantin Komarov Stable-dep-of: c01b091b0641 ("ntfs3: free the sbi after a grace period") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a1647b653549ff29f0422a63eabf329b842f3822 Author: Laurence Oberman Date: Tue Oct 13 16:25:48 2026 -0400 scsi: st: Fix use-after-free race between st_remove() and st_open() commit 71caf7f84bd62a4bf91cc95abd2de690afb8d15f upstream. st_remove() drops the probe reference on the scsi_tape with kref_put() and only afterwards removes its index from st_index_idr. If that was the last reference, scsi_tape_release() frees the structure while it is still published in the idr. scsi_tape_get(), called from st_open(), looks up the tape in st_index_idr and takes a reference under st_ref_mutex and st_index_lock. remove_cdevs() does not wait for opens that are already past chrdev_open(), so an open that is blocked on st_ref_mutex while st_remove() holds it can take the mutex as soon as st_remove() drops it, find the freed tpnt in the idr and call kref_get() on it: BUG: KASAN: slab-use-after-free in st_open Write of size 4 ... st_open (drivers/scsi/st.c:254 drivers/scsi/st.c:1291) chrdev_open ... Freed by task ...: kfree st_remove (drivers/scsi/st.c:4512) Remove the index from the idr before dropping the reference, all under st_ref_mutex. A concurrent scsi_tape_get() now either runs first and holds a valid reference that keeps the tape alive, or runs afterwards and finds nothing, so st_open() fails with -ENXIO. This restores the ordering st_remove() had before the conversion to st_index_idr, where the tape was unpublished from scsi_tapes[] before the final kref_put(). Fixes: 6c648d95a6af ("[SCSI] st: get rid of scsi_tapes array") Cc: stable@vger.kernel.org Reported-by: Dingisoul Closes: https://lore.kernel.org/linux-scsi/20261007211520.1428497-1-dingiso.kernel@gmail.com/ Tested-by: Dingisoul Signed-off-by: Laurence Oberman Link: https://patch.msgid.link/20261013202548.249628-1-loberman@redhat.com Signed-off-by: Martin K. Petersen (Oracle) [ loberman: st_remove() still returns int in 6.18; context adjusted ] Signed-off-by: Laurence Oberman Signed-off-by: Greg Kroah-Hartman commit d2f591e6c73046edf8fd120ebc1966d0c1b8b24e Author: Paulo Alcantara Date: Mon Aug 24 16:59:12 2026 -0300 smb: client: fix multiuser mount with krb5 commit 69499395867332364ed4ac8b546537eb3bab6ebb upstream. Customer reported that they could no longer mount their SMB shares with multiuser mount option and krb5. Turned out that the client wasn't duplicating username option when creating multiuser connections, therefore failing to retrieve credentials as cifs.upcall(8) couldn't find them in keytab. Fix this by duplicating username option (if set) from original fs context before creating multiuser connections with krb5. Reproducer: ``` $ ktutil ktutil: add_entry -password -p testuser -k 1 -e aes256-cts Password for testuser@ZELDA.TEST: ktutil: write_kt /etc/krb5.keytab ktutil: quit $ klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- ---------------------------------------------------------------- 1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96) $ mount.cifs //w22-root2/scratch /mnt/1 -o \ uid=1000,sec=krb5,username=testuser@ZELDA.TEST,multiuser mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) ``` Reported-by: Jacob Shivers Fixes: 12b4c5d98cd7 ("smb: client: fix krb5 mount with username option") Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit d96f3365ce61c5f39602955af43c8174548dee98 Author: Frank Sorenson Date: Wed Aug 26 21:13:36 2026 -0500 smb: client: fix heap overflow in cifs_do_set_acl() commit 1dac61e2c29d1a71784604b48cf3b1234a65ec29 upstream. cifs_set_acl() validates ACL size using posix_acl_xattr_size(): 4 + (count * 8) // 4-byte header + 8 bytes per ACE cifs_do_set_acl() then calls posix_acl_to_cifs() to write the CIFS wire format into the same buffer: 6 + (count * 10) // 6-byte header + 10 bytes per ACE An ACL that passes the xattr-based check in cifs_set_acl() can overflow the heap when posix_acl_to_cifs() writes the larger CIFS format. Validate the CIFS format size against the remaining buffer space and USHRT_MAX before converting--data_count is __u16, so sizes above USHRT_MAX truncate the on-wire packet length, causing the server to apply a partial ACL. Replace MaxDataCount = 1000 with min(CIFSMaxBufSize, USHRT_MAX). Fixes: dc1af4c4b4721 ("cifs: implement set acl method") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 45e60747a9db2307929260d9aa9c1c6cbb70ee77 Author: Aohan Mei Date: Wed Aug 26 10:51:20 2026 +0800 net/sched: cls_flower: validate mask pointer after nla_next() commit fee10655709c5c597e8e9f722f3035d9ea31ff3a upstream. fl_set_enc_opt() iterates the key's nested tunnel-option attributes with nla_for_each_attr() while advancing a single mask pointer via nla_next() at the bottom of each loop, so the mask cursor is driven by the number of key attributes rather than by the mask's own attributes. The nla_ok() added by commit c96adff956191 ("cls_flower: call nla_ok() before nla_next()") only validates the mask pointer that was just consumed; the pointer produced by nla_next() is used by the next iteration (fl_set_geneve_opt() and siblings) without any validation. The mask's nested attributes are validated with NL_VALIDATE_LIBERAL, which merely warns on trailing bytes that do not form a complete attribute. A mask carrying one valid attribute plus 1-3 residue bytes (or a non-aligned attribute length making msk_depth negative) therefore reaches the next iteration with msk_depth != 0, so neither the !msk_depth check in fl_set_enc_opt() nor the !depth check in the per-type helpers fires. nla_type() then reads past the mask payload and nla_parse_nested_deprecated() iterates with an nla_len taken from those bytes, reading well beyond the mask attribute (KASAN: slab-out-of-bounds read in __nla_validate_parse from fl_change()). Validate the advanced mask pointer as well: when the mask is not legitimately exhausted (msk_depth != 0) and the new pointer fails nla_ok(), reject the filter with -EINVAL. An exactly exhausted mask still skips the check, preserving exact-match behaviour for the remaining key attributes. Fixes: c96adff95619 ("cls_flower: call nla_ok() before nla_next()") Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Signed-off-by: Aohan Mei Link: https://patch.msgid.link/20260826025123.62758-1-ljp1205831794@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 898cb4f2e12a5ddea1b2d821cc642c3100f46da7 Author: Aleksandr Khromov Date: Mon Aug 24 13:22:46 2026 +0300 ksmbd: zero the FS_OBJECT_ID_INFORMATION buffer before filling it in commit 399aa12450a61a5c73dc77e73f069ece9687c95d upstream. smb2_get_info_filesystem() reports 64 bytes for FS_OBJECT_ID_INFORMATION, that is the whole of struct object_id_info, but writes only 46 of them: - objid[] is 16 bytes, and when the volume UUID is not available only sizeof(stfs.f_fsid) (8) bytes are copied into it; - extended_info.version_string[] is STRING_LENGTH (28) bytes, and only strlen("1.1.0") (5) bytes are copied into it. The response buffer is zeroed on allocation (kvzalloc() in smb2_allocate_rsp_buf()), so for a standalone request the remaining 31 bytes are zero. In a compound request they need not be. The offset of the next response is advanced by the length pinned for the previous one, so if a preceding command wrote its reply into the buffer and then failed, smb2_set_err_rsp() pins only the short error response and the next reply lands inside the area that has already been written. Only the header is cleared there: memset((char *)rsp_hdr, 0, sizeof(struct smb2_hdr) + 2); The client then receives up to 31 bytes of a response it was not meant to see, including one that failed with an access denied error. Clear the structure before filling it in. As a side effect version_string is now NUL terminated. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Suggested-by: ChenXiaoSong Cc: stable@vger.kernel.org Signed-off-by: Aleksandr Khromov Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit d8c450ad0d08980b39b08d435efa921086c8b227 Author: Aleksandr Khromov Date: Mon Aug 24 21:23:32 2026 +0900 ksmbd: initialize FileSystemControlFlags in FS_CONTROL_INFORMATION commit c0cd3fc6824122014da2b3b0cb7ddeaa2946ec8e upstream. smb2_get_info_filesystem() reports 48 bytes for FS_CONTROL_INFORMATION, that is the whole of struct smb2_fs_control_info, but never assigns FileSystemControlFlags. Those four bytes go to the client as they are found in the response buffer. The buffer is zeroed on allocation, so a standalone request leaks nothing. A compound request can leak: the offset of the next response is advanced by the length pinned for the previous one, so a reply that was written into the buffer and then dropped in favour of the short error response of smb2_set_err_rsp() stays there, and the next reply is laid over it with only the header cleared. ksmbd does not implement quota tracking, so report no control flags. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Aleksandr Khromov Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit beba2ef6f66a71f20531ac70a1acb0b221e362e9 Author: Aleksandr Khromov Date: Tue Aug 25 10:19:21 2026 +0900 ksmbd: fill in FileSysIdentifier in FS_POSIX_INFORMATION commit db2267b27c054a6c2151ff7fbb67927e784f31d6 upstream. smb2_get_info_filesystem() reports 56 bytes for FS_POSIX_INFORMATION, that is the whole of FILE_SYSTEM_POSIX_INFO, but never assigns FileSysIdentifier. Those eight bytes go to the client as they are found in the response buffer. The buffer is zeroed on allocation, so a standalone request leaks nothing. A compound request can leak: the offset of the next response is advanced by the length pinned for the previous one, so a reply that was written into the buffer and then dropped in favour of the short error response of smb2_set_err_rsp() stays there, and the next reply is laid over it with only the header cleared. Report the file system id statfs() returned, which is what the field is for. FileSysIdentifier is __le64 and f_fsid is a pair of ints, so assemble the value first, val[0] as the low half, and convert it on the way out. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Aleksandr Khromov Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit a9f14ea73e82db743f0acf4219f499d594589288 Author: Norbert Szetei Date: Sat Aug 29 18:56:18 2026 +0200 net: psp: do not inherit the Rx association on clone commit 1d2929d0850fff683b8aff051275945e65f082c8 upstream. sk->psp_assoc sits past sk_dontcopy_end, so sock_copy() copies it into every socket accepted from a listener without taking a reference, while inet_sock_destruct() puts for every inet socket. psp_twsk_init() does refcount_inc() for the timewait socket, so a child closing through TIME_WAIT cancels its own put and leaves the association with one reference and N timewait sockets holding the same pointer. Closing the listener frees it, and the timewait timers then put freed memory. Rejecting the association on a listening socket is not sufficient: a socket can acquire one while established and then be turned back into a listener, because tcp_disconnect() leaves sk->psp_assoc in place. BUG: KASAN: slab-use-after-free in psp_twsk_assoc_free+0x6f/0xf0 Write of size 4 at addr ffff888110f9255c by task swapper/7/0 psp_twsk_assoc_free+0x6f/0xf0 inet_twsk_put+0xda/0x1b0 call_timer_fn+0x53/0x2e0 __run_timers+0x764/0xa80 Freed by task 99: kfree+0x1a7/0x500 process_one_work+0x7ec/0x1100 An association carries a per-connection SPI and key, so a child must not inherit the parent's. Clear it on clone. Fixes: 6b46ca260e22 ("net: psp: add socket security association code") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei Reviewed-by: Daniel Zahka Link: https://patch.msgid.link/BC10EB92-ABB3-41B2-AB16-266BEEBE18C0@doyensec.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 8243d587a081e790ad96e80d48eef44d9f7ef005 Author: Jun Yang Date: Mon Aug 31 19:13:04 2026 +0800 net: bridge: mcast: don't truncate the port group walk on teardown commit 5a3f7a683aee56e1f15c9d53041f3236767eaae7 upstream. __br_multicast_disable_port_ctx() and br_multicast_del_port() walk port->mglist with hlist_for_each_entry_safe(). However, br_multicast_find_del_pg() can also delete other entries from the same list through br_multicast_fwd_src_remove() or __fwd_del_star_excl(). If such an entry is the iterator's saved next node, hlist_del_init() clears its ->next and terminates the walk early. The reproducer triggers this in both teardown walks, leaving port groups in the bridge mdb with a dangling ->key.port after del_nbp() frees the port: BUG: KASAN: slab-use-after-free in __mdb_fill_info+0x1191/0x1320 __mdb_fill_info+0x1191/0x1320 br_mdb_dump+0x594/0xe40 rtnl_mdb_dump+0x1cf/0x5d0 Use hlist_del_init_rcu() to unlink the group while preserving ->next. br_multicast_del_pg() and the teardown walks run under br->multicast_lock. The GC worker must acquire the same lock before detaching the group for destruction, so the node remains alive while the walk uses the preserved pointer. Preserving ->next means a walk can now reach a group that an earlier iteration already deleted as a side effect. That group is off mp->ports, so br_multicast_find_del_pg() would fall through its port scan and hit the trailing WARN_ON(1). Skip such groups at the top of that helper: a port group is put on port->mglist when it is created and only unlinked when it is deleted, so hlist_unhashed() identifies exactly this case. Fixes: b08123684bd5 ("net: bridge: mcast: install S,G entries automatically based on reports") Cc: stable@vger.kernel.org Suggested-by: Nikolay Aleksandrov Reported-by: TencentOS Corvus AI Signed-off-by: Jun Yang Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260831111330.199543-1-junvyyang@tencent.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 80d5db1686b05fad6f384be017714297d828a714 Author: Christian Brauner Date: Wed Oct 21 11:30:06 2026 -0400 ext4: free the sbi after a grace period [ Upstream commit c17b44266a1f9fcb49b894d4611d1254bf1aa313 ] ext4_get_link() follows a symlink that keeps its target in a data block in rcu pathwalk mode with ext4_getblk(EXT4_GET_BLOCKS_CACHED_NOWAIT). That reads s_mount_state in the ASSERT() of ext4_getblk() and again in ext4_es_lookup_extent(), and the lookup bumps the extent status hit or miss counter, all through sb->s_fs_info. ext4_put_super() destroys those counters, clears sb->s_fs_info and frees the sbi without waiting for a grace period. A pathwalk that is still in ext4_get_link() when the last reference to the mount goes away then dereferences a NULL s_fs_info, the freed sbi or the destroyed percpu counters. With a pathwalk held up in ext4_get_link() while the last reference goes away: KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af] RIP: 0010:ext4_getblk+0xf0/0x640 Call Trace: ext4_get_link+0x26c/0x410 pick_link+0xf96/0x1780 step_into_slowpath+0x9b8/0x1250 path_lookupat+0x484/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 vfs_fstatat+0x4d/0x90 __do_sys_newfstatat+0xa0/0x100 do_syscall_64+0x10e/0x5e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f So far that has been hard to hit. umount(2) waits for a grace period in namespace_unlock() before it drops the mount, so only a mount whose last reference goes away elsewhere, like the close of a file or a chdir out of a lazily unmounted directory, can race a walker. Keep sb->s_fs_info and free the sbi together with the extent status counters after a grace period. Split the counters out of ext4_es_unregister_shrinker() for that. The shrinker still gets wasted in ext4_put_super(), the counters go with the sbi. Fixes: 6493792d3299 ("ext4: convert symlink external data block mapping to bdev") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-1-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) [ sashal: Omitted changes tied to absent extent KUnit tests. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cad63a7798d6a6cac1fc68732595f0a3278ff6f0 Author: Peter Ujfalusi Date: Wed Oct 21 11:29:55 2026 -0400 ASoC: SOF: ipc4-topology: Fix shift-out-of-bounds for aggregated ALH capture [ Upstream commit 746de48c3a250f0c264105dcbfcdf0c5001e970b ] When ch_count is smaller than blob->alh_cfg.device_count (e.g. a mono capture stream, such as a SmartMic, aggregated across multiple SDW links), step = ch_count / blob->alh_cfg.device_count truncates to 0. The subsequent GENMASK(step - 1, 0) then underflows step - 1 (u32) to UINT_MAX, causing GENMASK()'s internal shift to use an out-of-bounds exponent: UBSAN: shift-out-of-bounds in sound/soc/sof/ipc4-topology.c:2363:13 shift exponent 18446744069414584384 is too large for 64-bit type 'long unsigned int' Treat ch_count < device_count the same way as the existing "channels equal to output reference channels" case: apply the same ch_mask to every aggregated device instead of trying to split channels that can't be evenly divided. Fixes: 0390a102cc18 ("ASoC: SOF: ipc4-topology: use different channel mask for each sdw amp feedback") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Link: https://patch.msgid.link/20261008090130.15135-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown [ sashal: Added a standalone guard around the mask calculation because the upstream playback conditional is absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c17cc2027773e8e4913c5ab0fe3a489b1ed5bf81 Author: Jann Horn Date: Wed Oct 21 11:48:29 2026 -0400 futex: Fix mm reuse handling for FUT_OFF_MMSHARED [ Upstream commit 3267512ad1c2cc0c7768c5b014dc2cceb398a801 ] A FUT_OFF_MMSHARED futex is a shared futex that refers to an MM. It is possible for a process to wait on a shared futex with a different MM because a FUT_OFF_INODE waiter can be requeued onto a FUT_OFF_MMSHARED futex by another process. This can cause FUT_OFF_MMSHARED waiters on a freed MM to consume wakeups intended for a newly allocated MM at the same address. Fix it by keying FUT_OFF_MMSHARED using a unique 64-bit per-MM ID. Leave private futexes as before to avoid influencing the performance of the hotpath. (Multi-threaded processes typically implicitly use FUT_OFF_MMSHARED by setting clear_child_tid such that it points into anonymous memory, which causes mm_release() in a multi-threaded mm to perform FUTEX_WAKE.) Fixes: 222993395ed3 ("futex: Remove pointless mmgrap() + mmdrop()") Closes: https://lore.kernel.org/r/CAG48ez0dLBpc3QtbAhMMVNHwHL94iHh2G+h-=BVFR4dDuzZr1g@mail.gmail.com/ Signed-off-by: Jann Horn Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260929-futex-mmshared-fix-v1-1-262b1ffeb3d0@google.com Cc: stable@vger.kernel.org [ sashal: adapted mm->futex.unique_id access to mm->futex_unique_id because struct futex_mm_data is absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dce8f7f03a47b1744dccf506268f9229b67fab47 Author: Jesse Zhang Date: Wed Oct 21 17:36:38 2026 -0400 drm/amdgpu: keep the eviction fence until the last handle is closed [ Upstream commit 3c44cbcec5eb370713bbd2c315ed7c34d8ccec2b ] amdgpu_gem_object_close() detaches the user queue eviction fence from the BO before it checks bo_va->ref_count, so closing any handle of a BO removes the fence, even when the file still has another handle to the BO and the bo_va with its GPU mappings stays. The BO can then be evicted without suspending the user queues of the file, which keep accessing it through mappings that are only marked for update. Seen on navi31 with a SDMA user queue: a BO opened twice in the same file (GEM_FLINK + GEM_OPEN) loses its eviction fence when the second handle is closed (traced attach/detach of the fence): attach bo=ffff8c78a6c84c00 GEM_CLOSE handle=7 detach bo=ffff8c78a6c84c00 while handle 6 and the mapping are still in use. Only detach the fence when the last reference to the bo_va goes away, matching amdgpu_gem_object_open(), which attaches it only when the bo_va is created. With this the fence stays until the file is closed. Fixes: 31f7efcdca4d ("drm/amdgpu: enable eviction fence") Signed-off-by: Jesse Zhang Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 8387982f03d4026b7dc11b0b5e3118298eee4d6a) Cc: stable@vger.kernel.org [ sashal: Changed amdgpu_evf_mgr_detach_fence() calls to the older amdgpu_eviction_fence_detach() helper. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0caeefed99b37f03251a00eb1fdb403a1cf2cb68 Author: Paolo Bonzini Date: Wed Oct 21 11:48:15 2026 -0400 KVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes [ Upstream commit e90ab3669181c6469e3647ef2b30ae408275f496 ] When running Hyper-V from Windows 11, KVM is seeing the SS bit set in nested page fault error codes produced for shadowed NPT. The AMD manual is unclear about when SS is set, including whether it can be set when SupervisorShadowStackEn (bit 6) is not set in the MISC_CTL field of the VMCB. Nevertheless, the unexpected SS bit causes out of bounds accesses in permission_fault(), seen as either WARNs or UBSAN reports: kernel: UBSAN: array-index-out-of-bounds in arch/x86/kvm/mmu.h:225:27 kernel: index 34 is out of range for type 'u16 [16]' (in this case, the page fault error code is 34*2=0x44, i.e. SS|U; the report shows SS|U|W happening as well). Fix the handling of unknown error codes by dropping SS and (with a WARN) any bits not among those that permission_fault() expects to receive. At the same time, given the uncertainty about when hardware sets SS, follow the processor's behavior when constructing the fault's error code, and preserve the SS bit as passed to FNAME(walk_addr_generic). While the behavior is surprising, there's a possibility that Hyper-V expects it (Hyper-V does not even enable CET unless it finds MBEC/GMET!), so retain the information when reflecting the fault to L1 instead of unconditionally discarding it. Bisection shows that this started happening with commit 687ee95c1b6d ("KVM: nSVM: enable GMET for guests"), even though SHSTK was available to guests since Linux 6.18. However, this is not because bit 1 of MISC_CTL (GMET) somehow enables reporting the SS bit; rather, it's simply that Hyper-V never uses CET unless GMET is also present. The WARN is reproducible even with gmet=0, with some hacking of kvm-unit-tests's cet.c testcase to ensure that the first access to the shadow stack triggers a page fault. Reported-by: SimonP Fixes: 8db428fd5229 ("KVM: SVM: Enable shadow stack virtualization for SVM") Cc: stable@vger.kernel.org Reviewed-by: Sean Christopherson Closes: https://lore.kernel.org/all/asUqYEisPp9MJ8mQ@rika.bernkas.tel Signed-off-by: Paolo Bonzini [ sashal: Adapted permission checks to use mmu->permissions and mmu->pkru_mask instead of the newer page-walk structures. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7786dde1b50013b88c1437e6f364e62f39d90f20 Author: Hyunwoo Kim Date: Tue Oct 20 19:16:35 2026 -0700 KVM: x86/mmu: Preserve nested TDP shadow page tables if they are used as roots [ Upstream commit 7a2c70e777a00c32ebafd376a6fe31ebb91c5b20 ] kvm_mmu_zap_oldest_mmu_pages() excludes a shadow page whose root_count is non-zero from top-level reclaim, because such a page cannot be freed. The path in mmu_page_zap_pte() that recursively zaps a parentless nested TDP child has no such check. As a result, a shadow page can be zapped even if the page itself can't be freed; as the comment in kvm_mmu_zap_oldest_mmu_pages() notes, zapping it will just force vCPUs to rebuild the page. As in top-level reclaim, do not recursively prepare zapping of a nested TDP child whose root_count is non-zero. Fixes: 2de4085cccea ("KVM: x86/MMU: Recursively zap nested TDP SPs when zapping last/only parent") Signed-off-by: Hyunwoo Kim Signed-off-by: Paolo Bonzini Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit dc29c0478b8564feb9371e715b5a0016eb8903fd Author: Florian Westphal Date: Tue May 12 15:36:14 2026 +0200 netfilter: nft_byteorder: remove multi-register support [ Upstream commit bb061d3de41707415269be75ebf700efb03ec212 ] 64bit byteorder conversion is broken when several registers need to be converted because the source register array advances in steps for 4 bytes instead of 8: for (i = ... src64 = nft_reg_load64(&src[i]); ~~~~~ u32 *src nft_reg_store64(&dst64[i], Remove the multi-register support, it has other issues as well: Pablo points out that commit caf3ef7468f7 ("netfilter: nf_tables: prevent OOB access in nft_byteorder_eval") alters semantics: before the loop operated on registers, i.e. for ( ... ) dst32[i] = htons((u16)src32[i]) .. but after the patch it will operate on bytes, which makes this useless to convert e.g. concatenations, which store each compound in its own register. Multi-convert of u32 has one theoretical application: ct mark . meta mark . tcp dport @intervalset Because ct mark and meta mark are host byte order, use with intervals has to convert the byteorder for ct/meta mark value to network byte order (bigendian). nftables emits this: [ meta load mark => reg 1 ] [ byteorder reg 1 = hton(reg 1, 4, 4) ] [ ct load mark => reg 9 ] [ byteorder reg 9 = hton(reg 9, 4, 4) ] ... I.e. two separate calls. Theoretically it could be changed to do: [ meta load mark => reg 1 ] [ ct load mark => reg 9 ] [ byteorder reg 1 = htonl(reg 1, 4, 8) ] ... But then all it would take to change the set to meta mark . tcp dport . ct mark ... and we'd be back to two "byteorder" calls. IOW, support to convert a range of registers is both dysfunctional and dubious. Simplify this: remove the feature. Pablo Neira Ayuso points out that nftables before 1.1.0 can generate incorrect byteorder conversions, see 9fe58952c45a, "evaluate: skip byteorder conversion for selector smaller than 2 bytes" in nftables.git). Affected rulesets fail to load with this change and old userspace due to 'len != size' check. Fixes: c301f0981fdd ("netfilter: nf_tables: fix pointer math issue in nft_byteorder_eval()") Cc: # may break rule load with old nftables versions Reported-by: Michal Kubecek Link: https://lore.kernel.org/netfilter-devel/20240206104336.ctigqpkunom2ufmn@lion.mk-sys.cz/ Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 61f376654fb9d8c35896f3d5e85b95994513f647 Author: David Rosca Date: Thu Aug 20 16:32:51 2026 +0200 drm/amdgpu: Fix VCE 3 ring align_mask [ Upstream commit 2ee9836545e690c9e66ec203445d7705959fd7a8 ] The largest frame is 20 dwords, so 0xf mask is too small. This was always wrong, but we were lucky with the VCE_CMD_END commands inserted after fence and vm_flush. Fixes: 8897ea8c761b ("drm/amdgpu: Implement insert_end for VCE 3") Cc: stable@vger.kernel.org Acked-by: Alex Deucher Signed-off-by: David Rosca Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d49fa454c2869fb95487e1cb2eb88dfc62a7c5c3 Author: Yosry Ahmed Date: Mon Oct 19 21:46:11 2026 +0000 KVM: SVM: Stop toggling virtual VMSAVE/VMLOAD on intercept recalc [ Upstream commit 55780d8a1dcc93d2c4b33c565ada88df12c9f206 ] Virtual VMSAVE/VMLOAD enablement (i.e. VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK) is set/cleared by svm_recalc_instruction_intercepts() when the intercepts are cleared/set. This is unnecessary because the bit is meaningless when intercepts are set and KVM emulates the instructions. Initialize the bit in vmcb01 base on vls, and keep it unchanged. This is similar-ish to how vGIF is handled. It is enabled in init_vmcb() if vgif=1 and remains unchanged when the STGI intercept is enabled (e.g. for NMI windows). This fixes a bug in svm_recalc_instruction_intercepts(). The intercepts for VMSAVE/VMLOAD are always toggled in vmcb01, but VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK is toggled in the current VMCB, which could be vmcb02 instead of vmcb01 if L2 is active. Virtual VMSAVE/VMLOAD enablement in vmcb02 is separately controlled by nested_vmcb02_prepare_control() based on the vCPU features and VMCB12, and if intercepts are needed they are set by recalc_intercepts(). The bug is benign though. Not toggling the bit for vmcb01 is harmless because it's useless anyway. For vmcb02: - The bit could be incorrectly cleared when intercepts are set in vmcb01. This is harmless because VMSAVE/VMLOAD will be emulated by KVM anyway. - The bit could be incorrectly set when the intercepts are cleared in vmcb01. However, if the bit was originally clear in vmcb02, then recalc_intercepts() will enable in the intercepts in vmcb02 anyway and VMSAVE/VMLOAD will be emulated by KVM. Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260110004821.3411245-3-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson Fixes: 5a1a726e68ff ("KVM: x86: Use KVM_REQ_RECALC_INTERCEPTS to react to CPUID updates") Reported-by: Nikola Ciprich Closes: https://lore.kernel.org/linux-mm/arY1Wq6R9OY20ans@pcnci.linuxbox.cz/ Tested-by: Nikola Ciprich [ yosry: The bug is not benign. Since 5a1a726e68ff, a vCPU restored into L2 (e.g. on live migration) recalculates intercepts with vmcb02 loaded, leaving vmcb01 with neither VMLOAD/VMSAVE intercepts nor virtual VMLOAD/VMSAVE, so L1's VMLOAD/VMSAVE corrupt host memory. ] Signed-off-by: Yosry Ahmed Signed-off-by: Sasha Levin commit 5dac5c7ba8f5f3fb4bf29f2a2c3cb552f5b83c8f Author: Zihan Xi Date: Thu Aug 27 18:25:14 2026 +0000 ipv4: avoid divide by zero in fib_rebalance commit 5046d2880fec7d49ebed2fd2866747ee1d06ad71 upstream. fib_rebalance() computes the total eligible nexthop weight in one pass and programs upper bounds in a second pass. A concurrent change to ignore_routes_with_linkdown can make the first pass return zero while the second pass sees an eligible nexthop, resulting in division by zero. If the first pass reports a zero total, set each nexthop upper bound to -1 and skip the division. This matches the IPv6 fix in commit d2c26c2911dd ("ipv6: avoid divide by zero in rt6_multipath_rebalance") and preserves the lock-free rebalance path. Fixes: 0e884c78ee19 ("ipv4: L3 hash-based multipath") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zihan Xi Reviewed-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260827182514.4667-2-zihanx@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ba5001db9bb23ff7d2ea328c405c287ffb07786f Author: Niklas Schnelle Date: Thu Aug 6 11:43:39 2026 +0200 s390/pci: Fix leak of uninitialized kernel data in SCLP report commit 8ac60ae2a307a50b599bf5d300b448d638f3ba29 upstream. While report_error_write() checks that the provided buffer is at least as large as the header struct, but not that it is large enough to contain the report with the length claimed by report->length. If user-space provides a short buffer, meaning a larger report->length than the actually written payload, up to around 4K of kernel data from past the kmalloc(len + 1) sized buffer allocated in kernfs_fop_write_iter() will leak into the SCLP report. However, as the entity processing the SCLP is privileged and able to access at least the page including the report, this does not leak data that entity could not access but it is still an out of bounds read and a malformed error report that should be rejected. Fixes: 368704a65be8 ("s390/pci: add report_error attribute") Cc: stable@vger.kernel.org Signed-off-by: Niklas Schnelle Reviewed-by: Benjamin Block Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 34fa3607b7604b3052b19cec8b0ad644818cdd2a Author: Aswin Karuvally Date: Thu Aug 27 08:34:08 2026 +0200 s390/ctcm: Prevent XID null dereference commit b264d8422779d69febce914efc47a92a85cc382c upstream. The mpc_validate_xid() function sets grp->saved_xid2->xid2_flag2 to 0x40 to signal XID validation error. If peer XID is NULL or r/w channel pairing mismatch happens, grp->saved_xid2 is never initialized. An attempt to set the flag in such case leads to NULL dereference. Fix this by using the always available priv->xid->xid2_flag2 instead of grp->saved_xid2->xid2_flag2 for validation errors. Fixes: 293d984f0e36 ("ctcm: infrastructure for replaced ctc driver") Cc: stable@vger.kernel.org Signed-off-by: Aswin Karuvally Link: https://patch.msgid.link/20260827063408.2168914-1-aswin@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 813a72beaa5d3f4bb135e0def9b3f07a3511ca0e Author: Florian Schauer Date: Fri Aug 28 08:08:22 2026 +0200 page_pool: keep frag_offset aligned for odd-sized requests commit dc0df5a0c62ccea1d0e08d39a4dc9064de81d411 upstream. page_pool_alloc_frag_netmem() rounds the requested fragment size with size = ALIGN(size, dma_get_cache_alignment()); dma_get_cache_alignment() returns 1 unless the architecture defines ARCH_DMA_MINALIGN, which DMA-coherent architectures such as x86 do not. There the ALIGN() is a no-op and pool->frag_offset advances by the raw, unrounded size. A single caller asking for an odd size then leaves frag_offset misaligned for every fragment carved out of that page afterwards. The pool is shared, so the damage is not confined to the caller that caused it. The per-cpu system_page_pool used by generic XDP hits this. skb_pp_cow_data() allocates its fragments with the raw packet length: size = min_t(u32, len, PAGE_SIZE); truesize = size; page = page_pool_dev_alloc(pool, &page_off, &truesize); leaving frag_offset odd for whatever is carved out of that page next. Its own head allocation is already aligned -- SKB_HEAD_ALIGN(size) plus the XDP_PACKET_HEADROOM its callers pass -- so it is a later user of the shared pool that pays: page_pool_dev_alloc_va() returns a misaligned buffer, napi_build_skb() installs it as skb->head, and skb_shinfo(skb) == skb->head + skb->end is misaligned with it. skb_shinfo()->dataref is a 4-byte atomic_t at offset 0x20, so the atomic_inc() in __skb_clone() straddles a cache line. On x86 with split lock detection -- fatal for kernel split locks by default -- this panics the machine: Oops: Split lock detected RIP: 0010:skb_clone+0x154/0x1e0 Call Trace: raw_local_deliver+0x1ed/0x2c0 ip_protocol_deliver_rcu+0x54/0x1c0 ip_local_deliver_finish+0x85/0x100 ip_local_deliver+0x67/0x100 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 Reproduced by attaching any generic-mode XDP program to loopback and opening a RAW IPPROTO_UDP socket, which makes raw_local_deliver() clone every locally delivered UDP packet; ordinary DNS traffic then triggers it, roughly once per 2500 clones. Observed on 6.12.101 and 7.1.8. Tracing page_pool_alloc_frag_netmem() over one such run shows the amplification -- two odd-sized requests, nine misaligned offsets: requested size & 7: 0: 17035 5: 1 7: 1 frag_offset & 7: 0: 17028 3: 1 4: 1 5: 1 6: 1 7: 5 and skb_pp_cow_data() returning heads that were aligned on entry: head 0xffff8f4c86aeac00 -> 0xffff8f4c53a9a9c4 (&7=4) head 0xffff8f4d6a8a42c0 -> 0xffff8f4c4f7b7a45 (&7=5) Round the fragment size up to at least the alignment struct skb_shared_info requires, so fragments are always suitably aligned for the objects callers build on them. Architectures needing a larger DMA alignment keep it. This also makes the remainder computed in page_pool_alloc_netmem(), *size = max_size - *offset; aligned, since max_size is a power of two -- which fixes the matching misalignment of skb->end. Verified with a controlled A/B under QEMU/KVM: same tree, same config, same compiler, same rootfs and identical traffic, differing only by this patch. A SEC("xdp.frags") XDP_PASS program on lo plus UDP datagrams larger than max_head_size drives skb_pp_cow_data()'s fragment loop, which passes raw packet lengths to the pool. Measured at the return of skb_pp_cow_data(): unpatched patched skb_pp_cow_data calls 40800 40800 misaligned skb->head 1120 0 dataref at line offset >60 80 0 The last row counts the accesses that actually fault: skb_shinfo()->dataref sits at head+end+0x20 and is a 4-byte atomic, so `lock incl` splits a 64-byte cache line only when that address lands at offset 61..63. All 80 occurrences were at offset 61; the panic reported above was at offset 62. Eliminating the misalignment removes every one of them. Same class of bug as commit 3bed3cc4156e ("net: Do not allocate page fragments that are not skb aligned"), which fixed the older netdev_alloc_frag()/napi_alloc_frag() allocators. Fixes: 53e0961da1c7 ("page_pool: add frag page recycling support in page pool") Cc: stable@vger.kernel.org Signed-off-by: Florian Schauer Acked-by: Jesper Dangaard Brouer Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260828060822.2628276-1-florian@schauer.to Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 40507f59f230dcf60ae13cb48d34f8c6e9f40659 Author: Charles Vosburgh Date: Thu Aug 27 17:32:53 2026 -0400 sctp: validate chunk length in the inqueue parser commit 6cfc1b90cb86f4aabc69fb8e30128e07e2cdfa3a upstream. SCTP chunks always include a four-byte generic header, but sctp_inq_pop() currently accepts shorter declared lengths. A zero-length chunk leaves chunk_end at the current header. When ASCONF is covered by the association's SCTP-AUTH policy, sctp_assoc_bh_rcv() can continue before the state machine performs its normal chunk-length check. sctp_inq_pop() then returns the same malformed chunk repeatedly and the receive softirq can lock up. A remote SCTP peer can trigger this after establishing an association on a kernel built with CONFIG_IP_SCTP and configured with net.sctp.addip_enable=1 and net.sctp.auth_enable=1. The reproducer did not require application credentials, a shared SCTP AUTH key, or net.sctp.addip_noauth_enable=1. On commit f967455fb2a5 ("seg6: reset IP6CB after IPv6 decapsulation"), one zero-length ASCONF caused repeated watchdog soft-lockup reports in a two-vCPU KVM guest. All 3 pre-trigger health probes succeeded, while 36 of 37 post-trigger probes failed. With this change, all 37 post-trigger probes succeeded and no equivalent soft-lockup signature appeared. Reject chunks shorter than the generic SCTP header at the shared inqueue parser boundary. Mark the packet for discard before either caller can continue processing it, while preserving the four-byte generic minimum. Declared-length 1 through 4 controls and kernel-generated ASCONF traffic remained healthy. The patched sctp_hello selftest passed for IPv4 and IPv6. The complete private reproducer and validation evidence are available directly to maintainers on request. Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") Cc: stable@vger.kernel.org Signed-off-by: Charles Vosburgh Acked-by: Xin Long Link: https://patch.msgid.link/20260827-sctp-zero-chunk-inqueue-v2-1-2e7669c6a6cb@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b8b7d28dc2b7472ffd1eff3954c38f1976b21a7b Author: Chengfeng Ye Date: Wed Aug 26 03:01:41 2026 +0800 tipc: protect node reset trace dump with node lock commit dddf197f29ba5e47a476dde82bf542ca2e0d5e5e upstream. The tipc_node_reset_links trace event asks tipc_node_dump() to walk the node's link entries. Unlike the other node events that request link data, this event runs without the node lock. This permits bearer teardown to free a link while the trace callback is dumping it: CPU 0 CPU 1 trace_tipc_node_reset_links() tipc_node_dump() l = n->links[0].link tipc_node_write_lock() kfree(l) n->links[0].link = NULL tipc_node_write_unlock() tipc_link_dump(l) tipc_link_dump() then dereferences the stale pointer. KASAN reported: BUG: KASAN: slab-use-after-free in tipc_link_dump Read of size 4 by task poc/115 Call Trace: tipc_link_dump+0x10cb/0x16b0 tipc_node_dump+0x4bb/0x740 trace_event_raw_event_tipc_node_class+0x258/0x360 tipc_node_reset_links+0x14d/0x1a0 tipc_rcv+0x13f5/0x3030 tipc_udp_recv+0x4e3/0x670 Allocated by task 0: tipc_link_create+0x1e1/0x1020 tipc_node_check_dest+0x7d2/0x11a0 tipc_disc_rcv+0xdbf/0x1430 Freed by task 89: kfree+0x131/0x3c0 tipc_node_link_down+0x267/0x4b0 tipc_node_delete_links+0xec/0x160 bearer_disable+0x107/0x260 Take the node write lock around the trace event. This serializes the dump against tipc_node_link_down(delete=true), which frees the link under the same write lock. Fixes: eb18a510b5cd ("tipc: add trace_events for tipc node") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260825190141.242219-1-nicoyip.dev@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f7e82f72b90ce74fdd8245421da96a25b2618f3f Author: Tejun Heo Date: Tue Aug 18 08:47:21 2026 -1000 workqueue: Annotate cb_lock nesting when draining a dead BH pool commit 6eca8f94d84106d3754b9df27f46a14572af9e7f upstream. On PREEMPT_RT, bh_worker() wraps work item execution in pool->cb_lock to provide a handshake for canceling BH work items. When a CPU goes down, drain_dead_softirq_workfn() runs the dead pool's bh_worker() nested inside the local pool's bh_worker(), acquiring the cb_locks of two different pools without a nesting annotation. lockdep reports possible recursive locking: ============================================ WARNING: possible recursive locking detected -------------------------------------------- ktimers/0/16 is trying to acquire lock: ffff8880b873a990 (&pool->cb_lock){+...}-{3:3}, at: bh_worker+0x7d/0x880 but task is already holding lock: ffff8880b863a990 (&pool->cb_lock){+...}-{3:3}, at: bh_worker+0x7d/0x880 Call Trace: bh_worker+0x7d/0x880 kernel/workqueue.c:3688 drain_dead_softirq_workfn+0x95/0x220 kernel/workqueue.c:3763 process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 bh_worker+0x46a/0x880 kernel/workqueue.c:3708 tasklet_action+0xc/0x70 kernel/softirq.c:965 The nesting can't deadlock. A pool's bh_worker() runs nested only while the pool's CPU is dead, entered from a live pool's bh_worker() on the draining CPU, so the ordering is always live to dead. CPU hotplug operations are serialized and the drain is synchronous, so the nesting depth never exceeds two. Annotate the inner acquisition with SINGLE_DEPTH_NESTING. Signed-off-by: Tejun Heo Reported-by: syzbot+1bd20115328f8254ed62@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1bd20115328f8254ed62 Fixes: ad7c7f4b9c6c ("workqueue: Provide a handshake for canceling BH workers") Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Greg Kroah-Hartman commit 6b26b3d39904ca5aaa5de162df689c5493b812c0 Author: Zqiang Date: Thu Jul 16 17:56:37 2026 +0800 workqueue: Use raise_softirq() to trigger softirq in irq_work handler commit 7e2f2a377ac9f50296ad60bd331f0d4def7aee51 upstream. bh_pool_kick_normal() and bh_pool_kick_highpri() are registered via init_irq_work() without the IRQ_WORK_HARD_IRQ flag. On PREEMPT_RT, such irq_work items are processed by the per-CPU irq_workd kthread in preemptible task context with IRQs enabled. However, raise_softirq_irqoff() requires IRQs to be disabled. Calling it from irq_workd trips the lockdep assertion in __raise_softirq_irqoff() and the non-atomic update of the softirq pending mask can lose bits raised by an interrupt on the same CPU. Replace raise_softirq_irqoff() with raise_softirq() in the irq_work handlers. Fixes: 2f34d7337d98 ("workqueue: Fix queue_work_on() with BH workqueues") Cc: stable@vger.kernel.org # v6.9+ Signed-off-by: Zqiang Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit b6a0e5faf0dca9ef74b2421b75c92e82ebe16740 Author: Ilya Maximets Date: Thu Aug 27 00:01:12 2026 +0200 netlink: specs: add missing mask attributes for conntrack dump commit 8b348496cbec0d5ca24a99f668096e2e16e8fbeb upstream. 'mark-mask' and 'status-mask' are defined and supported by the conntrack dump, but missing from the list of arguments. While at it, the order of the arguments should follow the order of their definition in the enum ctattr_type. That appears to be a common convention for other spec files. Fixes: 23fc9311a526 ("netlink: specs: add conntrack dump and stats dump support") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Asbjørn Sloth Tønnesen Link: https://patch.msgid.link/20260826220444.4054714-3-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 62ed32a1d4499865fc2c7f0fbe7e8f78a464c4b7 Author: Ilya Maximets Date: Thu Aug 27 00:01:11 2026 +0200 netlink: specs: fix the conntrack filter type commit 2a004bfb62bdb847f25a8001e104bf33922a2cf4 upstream. The CTA_FILTER doesn't contain nested tuple attributes, instead it contains bit masks that specify which tuple attributes to filter on. The values for filtering are taken from the top-level CTA_TUPLE_ORIG and CTA_TUPLE_REPLY, which are also missing in the attribute list for the dump request. The bits themselves somehow are not in the public headers, so not defining them in the spec either for now. Once they are public in uAPI, they can be added here with enum-as-flags. Fixes: 23fc9311a526 ("netlink: specs: add conntrack dump and stats dump support") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Asbjørn Sloth Tønnesen Link: https://patch.msgid.link/20260826220444.4054714-2-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e20e6b14e3b5cdfa5c09e39fd53444b3e4780564 Author: Christoph Hellwig Date: Tue Aug 11 10:48:39 2026 -0600 xfs: fix zoned write iomap flags assignments commit 4bc67fc800edcaae8a657e4d2fba12e64e856b9f upstream. Don't overwrite IOMAP_F_DIRTY with IOMAP_F_ANON_WRITE, but ensure both flags are set instead. Note that in practice this is harmless as all zoned writes force a metadata transaction anyway, but incorrectly assigned flags are still a landmine that will cause problems at some point. Fixes: 058dd70c65ab ("xfs: implement buffered writes to zoned RT devices") Fixes: 2e2383405824 ("xfs: implement direct writes to zoned RT devices") Cc: stable@vger.kernel.org # v6.15 Signed-off-by: Christoph Hellwig Reviewed-by: Andrey Albershteyn Reviewed-by: Darrick J. Wong Reviewed-by: Hans Holmberg Reviewed-by: Damien Le Moal Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 19a1a22029ad3ae3604c763af6bd1195cb73648f Author: Carlos Maiolino Date: Tue Aug 4 11:45:51 2026 +0200 xfs: fix capability check in xfs commit e2f62a9744ebad3bcb6347a648e615026e9efeff upstream. An user reported a bug where he managed to evade group's quota by changing a file's gid to a different group id the same user belonged to, even though quotas were enforced on both gids and the file's size was big enough to exceed the quota's hardlimit. Commit eba0549bc7d1 replaced a capable() call by a has_capability_noaudit() to prevent unnecessary selinux audit messages. Turns out that both calls have slightly different semantics even though their documentation seems similar. Where in a nutshell: capable() - Tests the task's effective credentials has_ns_capability_noaudit() - Tests the task's real credentials This most of the time has no practical difference but in some cases like changing attrs (specifically group id in this case) through a NFS client this will allow the quota code to use XFS_QMOPT_FORCE_RES, effectively bypassing quota accounting checks. Using instead ns_capable_noaudit() should fix this issue and prevent selinux audit messages. This also fix the remaining calls to has_capability_noaudit() Fixes: eba0549bc7d1 ("xfs: don't generate selinux audit messages for capability testing") Cc: stable@vger.kernel.org # v5.18 Reported-by: Dr. Thomas Orgis Signed-off-by: Carlos Maiolino Reviewed-by: Darrick J. Wong Reviewed-by: Serge Hallyn Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit e5456dec79c71c8ef8f9f9adb77d320f113b34db Author: Yun Zhou Date: Fri Jul 31 11:10:10 2026 +0800 xfs: don't hold buffer locks across sync transaction commit in xfs_sync_sb_buf commit 41a28c865d1d5843f8cb9e0af17a8f4d9e2961ff upstream. xfs_sync_sb_buf() holds sb/rtsb buffer locks across a synchronous xfs_trans_commit(), which flushes the CIL push workqueue internally. If shutdown occurs during the CIL push, xfs_buf_item_unpin() needs to lock these buffers to fail them, causing a deadlock: setlabel: holds buf lock -> flush_workqueue(xfs-cil) CIL push worker: xfs_buf_item_unpin -> xfs_buf_lock(same buf) Remove the xfs_trans_bhold() calls so that commit releases the buffer locks normally. After the sync commit, re-acquire the buffers via mp->m_sb_bp / mp->m_rtsb_bp for the on-disk writeback. Fixes: f7664b31975b ("xfs: implement online get/set fs label") Reported-by: syzbot+837bcd54843dd6262f2f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=837bcd54843dd6262f2f Cc: stable@vger.kernel.org Signed-off-by: Yun Zhou Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 8f2efa742f4cfe7dd756154f8bc07350dbe3ec92 Author: Bryam Vargas Date: Fri Aug 28 14:07:47 2026 -0500 net/iucv: fix the recvmsg window update commit fa5acd038ea657ad5033713d6916214cbd349151 upstream. iucv_sock_recvmsg() sends the HiperSockets-only AF_IUCV_FLAG_WIN without testing the transport, so on a classic z/VM socket iucv_send_ctrl() sizes the skb through a NULL iucv->hs_dev. SO_MSGLIMIT accepts 1, so msglimit / 2 is zero and one recvmsg() on its own socket is enough for an unprivileged process to take a spurious disconnect. It also calls iucv_send_ctrl() under spin_lock_bh(&message_q.lock), which allocates GFP_KERNEL inside a section the code treats as atomic. Sending outside that lock lets two recvmsg() reach afiucv_hs_send() at once, where msg_recv is sampled for the advertised window and subtracted after dev_queue_xmit() -- and sendmsg reaches that counter under lock_sock() while recvmsg holds no socket lock, so both can subtract the same value, the counter goes negative and the credit reaches the peer twice. Test the transport, claim the credit with atomic_xchg() after the last error exit and hand it back if the transmit fails, and send once the lock is dropped. Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport") Fixes: 238965b71b96 ("net/af_iucv: build proper skbs for HiperTransport") Cc: stable@vger.kernel.org Tested-by: Aswin Karuvally Signed-off-by: Bryam Vargas Reviewed-by: Alexandra Winter Link: https://patch.msgid.link/20260828-b4-disp-33fac0ed-v3-1-e6d061880ee0@proton.me Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3cdd8b1abddebbae2582e90294c77b61d5f5aee7 Author: Kaiwen Shi Date: Sun Aug 30 07:05:51 2026 +0800 mac802154: fix data race and NULL deref on local->assoc_dev commit c037915f80c4db47f7d061d68e703ffd551b1a34 upstream. local->assoc_dev is shared between the association path and the association-response worker without common synchronization. mac802154_perform_association() stores the coordinator pointer and waits for a response. Its timeout and error paths clear the pointer and return to mac802154_associate(), which may then free the coordinator object. Meanwhile, mac802154_rx_mac_cmd_worker() may observe the associating bit and enter mac802154_process_association_resp(), which dereferences assoc_dev. The worker's bit test and the handler's pointer dereference are not atomic with respect to cleanup. Cleanup can clear assoc_dev between them, causing a NULL dereference, or free the coordinator while the response handler still uses the pointer. The recorded result is exposed to the same window. assoc_status and assoc_addr are written by the handler but read by the association path while the associating bit is still set, so a second response for the same request - a malicious one, for instance - can replace them between those reads and leave the caller with an incoherent status and address pair. The response handler only needs the coordinator extended address. Replace assoc_dev with a cached address, removing the pointer lifetime dependency. Protect the cached address and the associating bit with a dedicated spinlock. A READ_ONCE()/WRITE_ONCE() pair would not guarantee an atomic __le64 access on all 32-bit architectures. wpan_dev->association_lock cannot be reused here: nl802154_associate() holds it across rdev_associate(), hence for the whole of mac802154_perform_association() including the wait for the response. A response handler taking that lock would only get it once the association has already given up. Reset the completion, publish the cached address, and set the associating bit while holding the lock. The response handler takes the lock, rechecks the bit and the cached address, records the response, clears the bit, and only then completes the waiter. Thus cleanup cannot pass the handler between its state check and completion, and the cached 64-bit value cannot tear. The handler clears the bit before completing, not the woken waiter: otherwise complete() is issued under the lock and a second (e.g. malicious) response can reacquire it before the waiter and replace the result. So a wait that returns success implies the bit is already clear, and the success and negative-response paths return directly. The transmit-error and timeout paths still clear it under assoc_lock, which serializes any racing response against the cleanup while the call returns the error it already selected. Both paths snapshot assoc_status and assoc_addr under the same lock. Both users run in process context, so a plain spinlock is sufficient. The lock is not held while waiting for the completion. Suggested-by: Miquel Raynal Suggested-by: Xuanqiang Luo Fixes: fefd19807fe9 ("mac802154: Handle associating") Cc: stable@vger.kernel.org Signed-off-by: Kaiwen Shi Reviewed-by: Xuanqiang Luo Reviewed-by: Miquel Raynal Link: https://patch.msgid.link/20260829230551.1787432-1-skwkevin@mail.ustc.edu.cn Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit c8922e7afb058d4630a6adfab870c722d585322e Author: Chen Cheng Date: Mon Aug 24 19:34:49 2026 +0800 dm-integrity: require stable writes for internal hash modes commit b2fd92f016e9d692fd3c8c08d0ee014e9212279d upstream. dm-integrity direct, bitmap and inline internal-hash modes compute integrity tags from the pages carried by the write bio. The lower data write also uses those pages, so the tag and the data write depend on the same memory contents staying unchanged while writeback is in flight. Without stable writes, a buffered writer can modify a writeback folio after dm-integrity has submitted the data bio and before the lower device has consumed the data. After a crash, this can leave data from the later contents with a tag calculated from the earlier contents, causing permanent checksum failures on read. Set BLK_FEAT_STABLE_WRITES for internal-hash D, B and I modes so filesystems wait for writeback folios to become stable before modifying them again. Journal mode is left unchanged because it copies data into the journal before computing and persisting the tag. Tested using dm-delay over a virtio-blk test disk, dm-integrity internal_hash:crc32c and no-journal ext4. The D and B reproducers both failed with checksum errors before this change and completed with READ_RC=0 and zero mismatches after it. Fixes: 7eada909bfd7 ("dm: add integrity target") Cc: stable@vger.kernel.org Reported-by: Sun Yangkai Link: https://github.com/chencheng-fnnas/reproducer/blob/main/dm-integrity-writeback-race.py Signed-off-by: Chen Cheng Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit fc512700f1413fed652dac22fa1c4e837210b9c0 Author: Ben Cressey Date: Thu Aug 20 21:44:58 2026 +0000 dm-integrity: fix infinite loop on discard with large tag size commit 18d80c77b4c7dd20699e81cedfbbff4e9d198f28 upstream. When integrity_metadata handles a discard, it fills a buffer with DISCARD_FILLER and writes it over the tags, max_blocks blocks at a time. If the kmalloc fails, the buffer is the on-stack array checksums_onstack and max_size is set to HASH_MAX_DIGESTSIZE. So if the tag size is larger than HASH_MAX_DIGESTSIZE, max_blocks is zero, bi_size is never decremented and the loop never terminates. Fix this by using sizeof(checksums_onstack) as max_size. The array has MAX_TAG_SIZE bytes since commit b93b6643e9b5 ("dm integrity: fix a crash with unusually large tag size"), so max_blocks is at least 1. Fixes: 84597a44a9d8 ("dm integrity: add optional discard support") Cc: stable@vger.kernel.org Reviewed-by: Jose Fernandez (Anthropic) Signed-off-by: Ben Cressey Assisted-by: Claude:unspecified Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 40791f07bad61c297d454599eaa4e1f6edbe8c69 Author: Genjian Zhang Date: Fri Aug 7 23:57:15 2026 +0800 dm-ebs: fix incorrect device offset check in ebs_ctr() commit 7ac81e2d2240f2c57bd073b0733e0b2abca38e82 upstream. is a backing-device sector offset; ti->len is the virtual target length. Comparing them rejects valid tables, e.g.: dmsetup create ebs0 --table "0 1048576 ebs /dev/sda 2097152 1 8" -> ebs: Invalid device offset sector (-EINVAL) Drop the check. Bounds against the backing device are already enforced later by device_area_is_invalid() via ebs_iterate_devices(). Cc: stable@vger.kernel.org Fixes: d3c7b35c20d6 ("dm: add emulated block size target") Signed-off-by: Genjian Zhang Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit ac5d887ab93592fc5e3605fe30c1d8d232d609b3 Author: Ben Cressey Date: Wed Aug 26 00:25:33 2026 +0000 dm-crypt: fix a tiny race condition in crypt_dec_pending commit 148845aa1921d95ef5dc851c76e6a284f6657df6 upstream. crypt_dec_pending reads io->error before calling atomic_dec_and_test. Another context, for example crypt_endio called from an interrupt, may set io->error and drop its reference between the read and the decrement. crypt_dec_pending then drops the last reference and completes the bio with the stale status - so a read that failed and was never decrypted, or a write that failed, is reported as successful. The read was placed before the decrement by commit b35f8caa0890 ("dm crypt: wait for endio to complete before destruction"), because that commit freed dm_crypt_io before calling bio_endio. This is no longer the case, dm_crypt_io lives in the per-bio data now. Read io->error after atomic_dec_and_test instead. atomic_dec_and_test is fully ordered, so no additional barrier is needed. Fixes: b35f8caa0890 ("dm crypt: wait for endio to complete before destruction") Cc: stable@vger.kernel.org Reviewed-by: Jose Fernandez (Anthropic) Signed-off-by: Ben Cressey Assisted-by: Claude:unspecified Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 73df2ff409f3db95029982fe3656329568e3715d Author: Benjamin Marzinski Date: Tue Aug 25 15:22:26 2026 -0400 dm cache: fix issue with background work locking commit bc9781c0247de107876f32929f1637db93a42b34 upstream. dm cache used a rw_semaphore for background_work_lock. Write locks on rw_semaphores have strict owner semantics, but there was no guarantee that the process that locked background_work_lock was the same process that unlocked it. This can be easily seen using a kernel compiled with CONFIG_DEBUG_RWSEMS. Given a dm cache device , run: 'dmsetup suspend && dmsetup resume '. This will trigger a kernel warning: DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)) triggered by cache_resume(). To fix this, switch from a rw_semaphore to a spinlock and a wait queue. dm cache already has a wait queue and associated counter, migration_wait and nr_allocated_migrations, that was getting woken up when background work was getting completed, but wasn't actually used by anything. This is replaced by the background_work queue and counter. Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Marzinski Reviewed-by: Matthew Sakai Reviewed-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit de9e8e587c07b87144883f773580ee9edb43e195 Author: Ming-Hung Tsai Date: Tue Aug 18 18:05:47 2026 +0800 dm cache: fix demotion stats in passthrough mode commit 2ccb8878c149443c6acf628b438c9c942c20abb2 upstream. The demotion counter is incremented per incoming write bio before the invalidation begins, causing the demotion count to exceed the actual number of cached blocks when multiple bios target the same cached block. Additionally, the counter is incremented unconditionally regardless of invalidation failure. Reproduce steps: 1. Create a cache device consisting of 512 cache entries modprobe brd rd_size=262144 dmsetup create cmeta --table "0 8192 linear /dev/ram0 0" dmsetup create cdata --table "0 65536 linear /dev/ram0 8192" dmsetup create corig --table "0 65536 linear /dev/ram0 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 65536 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Populate the cache, and record the number of cached blocks fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --direct=1 --ioengine=libaio --iodepth=32 --io_size=2048m nr_cached=$(dmsetup status cache | awk '{split($7, a, "/"); print a[1]}') 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 65536 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the passthrough cache with multiple jobs to trigger multiple bios hitting the same cached block. fio --filename=/dev/mapper/cache --name=test --rw=write --bs=4k \ --direct=1 --ioengine=libaio --iodepth=32 --numjobs=4 5. Check if demoted matches cached block count. These numbers should match but may differ due to overcounting per bio. nr_demoted=$(dmsetup status cache | awk '{print $12}') echo "$nr_cached, $nr_demoted" Fix by moving the demotion counter increment into invalidate_complete(), gated on the success flag. Reported-by: Ben Marzinski Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Cc: stable@vger.kernel.org Signed-off-by: Ming-Hung Tsai Reviewed-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 04d020b3d0b58a1b7e116900e4095b96a7f4e11a Author: Frank Sorenson Date: Wed Aug 26 20:57:38 2026 -0500 cifs: don't update i_size in cifs_do_truncate without a cached handle commit fe39cd9d48f2346605f3746e0cc19e89d5f373eb upstream. If find_writable_file() returns null, cifs_file_flush will return 0 without issuing set_file_size, and the outer 'if (!rc)' block will set i_size to 0 before telling the server to truncate. If the cifs_open() then fails, the inode will have size 0, while the server file is unchanged. Move the netfs_resize_file() and cifs_setsize() into the 'if (cfile)', so they only run after a successful set_file_size. In the no-handle else branch, evict stale pages with truncate_inode_pages before the O_TRUNC open to dispose of old cache pages, and let the open response set the i_size. Fixes: 110fee6b9bb5 ("smb: client: fix missing timestamp updates with O_TRUNC") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Acked-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 2f9dd8214d4213cac785e4e4441538053cce52fb Author: Etienne Perot Date: Fri Aug 28 21:52:51 2026 +0000 cgroup: fix spurious SIGKILL of CLONE_INTO_CGROUP children commit 8e359920216689b3b79e0fe8961a77fe312a511f upstream. Since commit b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill"), the fork path snapshots the kill_seq of the child's future cgroup into kargs->kill_seq, and cgroup_post_fork() SIGKILLs the child if that cgroup's kill_seq has changed in the meantime, to catch forks racing with a cgroup.kill sweep. For CLONE_INTO_CGROUP, however, the snapshot in cgroup_css_set_fork() is taken before the target cgroup has been resolved: kargs->cgrp is always NULL at this point (it is only set at the end of the function). So the "if (kargs->cgrp)" branch is dead code and the snapshot always records the kill_seq of the parent's cgroup. cgroup_post_fork() then compares it with the kill_seq of the target cgroup, so the child gets SIGKILLed whenever the two cgroups have been killed a different number of times. As a result, once cgroup.kill has been written to a cgroup, every child subsequently cloned into it with clone3(CLONE_INTO_CGROUP) is killed on the spot, for as long as the cgroup exists: kill_seq is not exposed to userspace and never resets. Re-snapshot kill_seq from the target cgroup once it has been resolved, and drop the dead branch at the early snapshot site. This does not reopen the race fixed by b69bb476dee9. For CLONE_INTO_CGROUP, everything from the snapshot to the check in cgroup_post_fork() runs with cgroup_mutex held, and kill_seq is only ever incremented under cgroup_mutex. tj: Updated the comment above kill_seq to reflect the new serialization rules as suggested by Shakeel Butt. Fixes: b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill") Cc: stable@vger.kernel.org Cc: Shakeel Butt Assisted-by: LLM Signed-off-by: Etienne Perot Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 86814e5370068ec2bf0caa6e6d55c3e5bfc6c324 Author: Cen Zhang (Microsoft Security FORGE Labs) Date: Thu Aug 27 19:55:11 2026 -0400 tcp: fix use-after-free in do_tcp_getsockopt(TCP_CC_INFO) commit 385e474086c2e7e29e2dded690be40dc273e20ee upstream. do_tcp_getsockopt() reads icsk->icsk_ca_ops and dereferences the get_info function pointer without rcu_read_lock(). With BPF struct_ops congestion control, ca_ops can point to dynamically allocated memory that is freed concurrently, resulting in a use-after-free when the kernel dereferences or calls through the stale pointer. BUG: KASAN: slab-use-after-free in do_tcp_getsockopt+0x2037/0x23e0 Read of size 8 at addr ffff888013701258 by task exploit/149 do_tcp_getsockopt+0x2037/0x23e0 (net/ipv4/tcp.c:4564) tcp_getsockopt+0x91/0xf0 __sys_getsockopt+0xf7/0x170 Fix this by wrapping the ca_ops load and get_info call within rcu_read_lock()/rcu_read_unlock(), and using READ_ONCE() to load the icsk_ca_ops pointer. Fixes: 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf") Suggested-by: Eric Dumazet Cc: AutonomousCodeSecurity@microsoft.com Cc: stable@vger.kernel.org Reviewed-by: Eric Dumazet Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) Reviewed-by: Jiayuan Chen Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/65fd3816ed5d541d9edd4bf4fcf97104a2cf907a.1787870710.git.blbllhy@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c1804ef016392dd91267d2207ee43b1de34302ca Author: Cen Zhang (Microsoft Security FORGE Labs) Date: Thu Aug 27 19:55:10 2026 -0400 tcp: fix use-after-free in do_tcp_getsockopt(TCP_CONGESTION) commit 5271b79b7ad68dcb222e893773f92bdabf7750f3 upstream. do_tcp_getsockopt() reads icsk->icsk_ca_ops->name without holding rcu_read_lock(). Since commit 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf"), icsk_ca_ops can point to dynamically allocated BPF struct_ops memory that may be freed concurrently via setsockopt(TCP_CONGESTION), leading to a use-after-free. BUG: KASAN: slab-use-after-free in _copy_to_user+0x37/0x60 Read of size 16 at addr ffff888013505260 by task exploit/149 _copy_to_user+0x37/0x60 do_tcp_getsockopt+0x158a/0x2460 (net/ipv4/tcp.c:4585) tcp_getsockopt+0x91/0xf0 __sys_getsockopt+0xf7/0x170 Fix this by holding rcu_read_lock() around the ca_ops->name access, using READ_ONCE() to load icsk_ca_ops, and copying the name to a stack buffer before releasing the lock. Also annotate the relevant icsk_ca_ops stores with WRITE_ONCE() to fix the accompanying KCSAN data-race issue. Fixes: 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf") Suggested-by: Eric Dumazet Reported-by: Xiang Mei (Microsoft) Link: https://lore.kernel.org/all/20260821182449.79785-2-blbllhy@gmail.com/ Cc: AutonomousCodeSecurity@microsoft.com Cc: stable@vger.kernel.org Reviewed-by: Eric Dumazet Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) Reviewed-by: Jiayuan Chen Reviewed-by: Matthieu Baerts (NGI0) Reviewed-by: Breno Leitao Link: https://patch.msgid.link/d3f97f1acbf0010898148be6e6406e4b8b4a5c84.1787870710.git.blbllhy@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f641066b0ddcd1b0cf007c0d04f9c966f6e888ae Author: Heyang Tan Date: Fri Sep 18 16:33:49 2026 +0800 wifi: p54: validate firmware record lengths commit db7b86bd97b380ece8fa39cfdd7502a9fd35e56f upstream. The p54 firmware parser accesses component ID and component version records without checking that their lengths cover the fields being read. A malformed record can therefore make the parser read past the record. Validate the component ID and component version record lengths before accessing their data. The descriptor record is also checked against the shortest descriptor length found in the supported firmware images. Reject descriptor values that underflow the RX offset or produce an empty RX range before updating the driver state. Assisted-by: LLM Codex Signed-off-by: Heyang Tan Tested-by: Christian Lamparter Link: https://patch.msgid.link/20260918083349.891-1-thy15333007817@163.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 09c7cce2e59e6b3b1807520bcb1980c561f15d1e Author: Tengda Wu Date: Tue Sep 29 10:40:15 2026 +0000 tracing: Fix hist trigger timestamps for buffered events commit 9414ca3b99e5a7f1f3bf51c2a01b383e1b355dd0 upstream. Syzkaller triggered a WARN_ON_ONCE(!nest) warning: WARNING: kernel/trace/ring_buffer.c:821 at ring_buffer_event_time_stamp Call trace: ring_buffer_event_time_stamp hist_field_timestamp hist_fn_call event_hist_trigger event_triggers_call __event_trigger_test_discard trace_event_buffer_commit do_trace_event_raw_event_sched_switch trace_event_raw_event_sched_switch The warning is probabilistically reproducible and is related to syzkaller executing the following commands: echo 'prev_pid == 999999' > events/sched/sched_switch/filter echo 'hist:keys=common_timestamp' > events/sched/sched_switch/trigger The specific triggering process is as follows: CPU 0 CPU 1 (context switching) (echo 'hist:keys=common_timestamp' > \ events/sched/sched_switch/trigger) do_trace_event_raw_event_##call trace_event_buffer_lock_reserve if (!tr->no_filter_buffering_ref && trace_file->flags & EVENT_FILE_FL_FILTERED) return entry; // return directly event_hist_trigger_parse hist_register_trigger tracing_set_filter_buffering(file->tr, true); tr->no_filter_buffering_ref++; __trace_buffer_lock_reserve rb_start_commit local_inc(&cpu_buffer->committing); // skipped and not executed trace_event_buffer_commit __event_trigger_test_discard event_triggers_call event_hist_trigger hist_fn_call hist_field_timestamp ring_buffer_event_time_stamp nest = local_read(&cpu_buffer->committing); WARN_ON_ONCE(!nest) // trigger warning The root cause is that when an event file has a filter attached and the hist trigger has not yet been attached, trace_event_buffer_lock_reserve() writes the event into the per-CPU trace_buffered_event temp buffer instead of reserving it in the ring buffer, so cpu_buffer->committing is not incremented. When the event is later processed at commit time by a hist trigger, hist_field_timestamp() -> ring_buffer_event_time_stamp() sees a zero committing count, triggering WARN_ON_ONCE(!nest). tracing_event_time_stamp() was added by commit d8279bfc5e959 ("tracing: Add tracing_event_time_stamp() API") for exactly this case: if the event is the per-CPU trace_buffered_event, it returns the current ring buffer timestamp. But it never gained a caller. Use it in hist_field_timestamp(), so that a hist trigger that races onto a buffered event records the current time, which is only marginally later than when the event was recorded, instead of warning and recording a bogus timestamp. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260929104015.1689921-1-wutengda@huaweicloud.com Fixes: b94bc80df648 ("tracing: Use a no_filter_buffering_ref to stop using the filter buffer") Signed-off-by: Tengda Wu Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 813e18881c6472eb229a63180ff42c808e3e949b Author: Amit Machhiwal Date: Fri Oct 9 22:05:56 2026 +0530 tracing: Do not initialize tracefs work if tracing is disabled commit b3b974008388ab59e44d764ba7a63c988fec2524 upstream. If trace buffer allocation fails during early boot (e.g. in early_trace_init() -> allocate_trace_buffers()), tracing_disabled is left set to 1 and the global trace array events list remains uninitialized. Later during boot, tracer_init_tracefs() (invoked via fs_initcall) queues tracerfs_init_work asynchronously without checking if tracing was disabled. When tracer_init_tracefs_work_func() runs, it calls event_trace_init() and init_tracer_tracefs(&global_trace, NULL) unconditionally. This leads to __find_event_file() dereferencing an uninitialized tr->events list, causing an early boot NULL pointer dereference Oops: BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000485be0 Oops: Kernel access of bad area, sig: 7 [#1] ... NIP [c000000000485be0] __find_event_file+0x70/0x3c0 LR [c000000000448874] init_tracer_tracefs+0x274/0xc80 Call Trace: init_tracer_tracefs+0x274/0xc80 tracer_init_tracefs_work_func+0x50/0x320 process_one_work+0x1e8/0x5c0 worker_thread+0x1dc/0x3d0 kthread+0x194/0x1b0 start_kernel_thread+0x14/0x18 Check tracing_disabled at the beginning of tracer_init_tracefs_work_func() and return immediately if tracing is disabled or failed to initialize, preventing the crash. Cc: stable@vger.kernel.org Fixes: 6621a7004684 ("tracing: make tracer_init_tracefs initcall asynchronous") Link: https://patch.msgid.link/20261009163557.88467-2-amachhiw@linux.ibm.com Reported-by: Michal Suchánek Closes: https://lore.kernel.org/all/arYskzbiaNzBR9MD@kunlun.suse.cz/ Signed-off-by: Amit Machhiwal Tested-by: Michal Suchánek Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit a866a8a753922cdf7710b8eb3f686dc0efc06505 Author: Taeyang Lee <0wn@theori.io> Date: Fri Oct 16 02:19:55 2026 +0900 tracing: Check operator stack capacity before pushing commit c47a7b11bcb3d45e29723afcf6336866476b1d08 upstream. predicate_parse() uses the first operator stack entry before processing any opening parentheses. A push then increments top before writing. The existing check still permits that write when top already points to the last allocated entry, which can access beyond the operator stack. Reject the push when top reaches the last allocated entry. Cc: stable@vger.kernel.org Fixes: 39f7c41c908b ("tracing/filters: Enable filtering a cpumask field by another cpumask") Link: https://patch.msgid.link/atELO9L0I9kg5CpC@Taeyangs-MacBook-Pro.local Signed-off-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 7c0c6d88a232ab2e360aecfdd090073c5c7bf621 Author: David Carlier Date: Mon Sep 14 14:35:04 2026 +0100 tracing: Take trace_types_lock when dropping the buffer_meta reference commit 2afe7575fb24b9d0476ae4a3a9862f7997216aa4 upstream. tracing_buffer_meta_open() drops the trace_array reference with __trace_array_put() when ring_buffer_meta_seq_init() fails, without holding trace_types_lock. Use trace_array_put() like every other open error path. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260914133506.4865-2-devnexen@gmail.com Fixes: 950032ffcee7 ("ring-buffer: Add output of ring buffer meta page") Signed-off-by: David Carlier Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit c4918c28b1bafbd13d502431c612b342521196b7 Author: Donggeun Yoo Date: Wed Sep 16 09:27:35 2026 +0900 tracing: Fix the shift out of bounds in the log2 histogram modifier commit 647c2f97fcb94bc642cefe6db004999974563f06 upstream. The .log2 key modifier files a value under its base-2 order: # echo 'hist:keys=bytes_req.log2' > events/kmem/kmalloc/trigger hist_field_log2() computes that as ilog2(roundup_pow_of_two(val)). The out-of-line form of roundup_pow_of_two() is return 1UL << fls_long(n - 1); which shifts by 64 on a 64-bit kernel both when n is 0, where n - 1 wraps to ULONG_MAX, and when n is above 2^63. Both are ordinary keys, because the field fetch hands every value over as a u64: a syscall argument of 0 reaches the first, and one above 2^63 reaches the second. Keying sys_enter_lseek on offset.log2 and passing 0, 1, 2, 3, 1000, 2^63+1 and U64_MAX gives { offset: ~ 2^1 } hitcount: 1 { offset: ~ 2^10 } hitcount: 1 { offset: ~ 2^2 } hitcount: 1 { offset: ~ 2^0 } hitcount: 4 Keys above 2^63 land in the lowest bucket. With CONFIG_UBSAN_SHIFT=y the shift is also reported: UBSAN: shift-out-of-bounds in include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' __ubsan_handle_shift_out_of_bounds.cold+0xdd/0x1cb hist_fn_call.cold+0x8b/0xd9 event_hist_trigger+0x1cc/0x790 ftrace_syscall_enter+0x197/0x360 do_syscall_64+0x402/0x4b0 Use order_base_2(), which is ilog2(n - 1) + 1 for n > 1 and 0 below that. It returns what the old expression returned on every input the old one was defined for. Where it was not, 0 stays in bucket 0, which is where x86_64 had been putting it, and the keys above 2^63 move into bucket 64. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260916002735.808520-1-donggeunyoo.kernel@gmail.com Fixes: 4b94f5b7b4a5 ("tracing: Add hist trigger 'log2' modifier") Signed-off-by: Donggeun Yoo Assisted-by: Claude:claude-fable-5 Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 3a3c4503ba1b4e0c9443c533bb30ead09dc24082 Author: Thomas Hellström Date: Mon Oct 12 15:26:07 2026 +0200 drm/xe: Bump LRU for external objects on exec and rebind commit d2ce8fcd778ee6d92748c92d23a56d4416c29d86 upstream. The VM's private BOs get their LRU position refreshed in bulk via ttm_lru_bulk_move_tail() on vm->lru_bulk_move, both after a successful non-LR exec and after the LR preempt-fence rebind worker runs. External objects (BOs potentially shared across VMs) are never added to that per-VM bulk move list, so their LRU position is never refreshed by either path. This makes external objects in active use look more evictable than they are. Add xe_vm_bump_lru(), which, under a single lru_lock critical section, performs the bulk move of the VM's private BOs and bumps each external object locked by the drm_exec transaction. Use it from both the non-LR exec path and the LR rebind worker, replacing the open-coded bulk move. Fixes: d490ecf57790 ("drm/xe: Rework xe_exec and the VM rebind worker to use the drm_exec helper") Cc: Matthew Auld Cc: Matthew Brost Cc: # v6.8+ Assisted-by: LLM Signed-off-by: Thomas Hellström Reviewed-by: Matthew Brost Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20261012132607.21387-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 324ba30cca180c2e1d02090743dd78ccb15b9e4a) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit ef82b4d5cb4a3fe77c7f99008d78b8c64709e258 Author: Dibin Moolakadan Subrahmanian Date: Tue Sep 22 19:05:38 2026 +0530 drm/i915/dmc: Add sanity check for DMC load address commit 7dedc5bb11f95e96fe80757c924d8d9aa7327759 upstream. For DMC firmware header version 3, the firmware load address is stored in dmc_info->start_mmioaddr and later used by dmc_load_program(). Unlike the MMIO address table, the firmware load address is not validated. Add a sanity check to ensure it is within the valid range. BSpec: 69671, 68378 Fixes: 3d5928a168a9 ("drm/i915/xelpd: Pipe A DMC plugging") Cc: stable@vger.kernel.org Assisted-by: Claude-Code:Sonnet-5 Signed-off-by: Dibin Moolakadan Subrahmanian Reviewed-by: Mitul Golani Signed-off-by: Ankit Nautiyal Link: https://patch.msgid.link/20260922133535.3180973-6-dibin.moolakadan.subrahmanian@intel.com (cherry picked from commit 5e47ee5c76ca9becde8df4ad5202845b7ffcbc4c) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 22fd3f760845fec2f1060a0ab6dfac683d6d89f6 Author: Dnyaneshwar Bhadane Date: Mon Sep 21 14:32:26 2026 +0530 drm/i915/cx0_phy: Fix ARL-S host bridge detection commit 6a8bf59de3ef47ff51face6ea826395a1098baa0 upstream. Fix is_arrowlake_s_by_host_bridge() which always returned false. The while loop always exits with pdev as NULL, so the return condition was always false, causing the wrong tx_misc value to be used. Check the host bridge ID inside the loop body. Once found early exit from the loop release the pci reference "pdev" and return true. v2: - Update commit message (Chaitanya) Bspec:74165,74491 Suggested-by: Jani Nikula Cc: Fixes: 3630a47b700e ("drm/i915/cx0_phy: Update HDMI TMDS C20 algorithm value") Signed-off-by: Dnyaneshwar Bhadane Reviewed-by: Chaitanya Kumar Borah Signed-off-by: Chaitanya Kumar Borah Link: https://patch.msgid.link/20260921090226.946472-1-dnyaneshwar.bhadane@intel.com (cherry picked from commit 0507cc5a476af0b6d037b19248bdd20dbe27487d) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 96d9996e5dbcfabed052c0d9377a382c95fed607 Author: Christian König Date: Wed Oct 7 14:46:57 2026 +0200 drm/exec: don't immediately add prelocked obj to array of locked objs commit 26401a4999f1596a515b2e704e7066ac09306488 upstream. When a contention is detected the drm_exec object grabs a reference to the contended object, unlocks all other objects and pre-locks the contended one before anything else. The problem is that it is possible that this pre-locked object was about to be destroyed and drm_exec is now holding the last reference to it. So we never actually see this pre-locked object again to be explicitly locked and so also never reserve a slot for a dma_fence object on it. Should the driver now use drm_exec_for_each_locked_object() to add a new fence to all locked objects we eventually see a warning or even a BUG_ON() to prevent random memory corruption. Fix this by keeping the prelocked object out of the array of locked objs until it was explicitly mentioned by the driver again. If the prelocked object is never mentioned again by the driver just unlock and drop the reference at the end of the locking loop. Signed-off-by: Christian König Reported-by: Vitaly Prosyak Reviewed-by: Vitaly Prosyak Tested-by: Vitaly Prosyak Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") CC: stable@vger.kernel.org # v6.6+ Link: https://lore.kernel.org/r/20261007124657.9664-1-christian.koenig@amd.com Signed-off-by: Greg Kroah-Hartman commit 07002a326c7cc03fd11be10e9cbc828aa4587908 Author: Jesse Zhang Date: Mon Oct 12 09:28:33 2026 +0800 drm/amdgpu: report the BO alignment in bytes in GEM_LIST_HANDLES commit d65a459dbc9a6c3b051e22c96f73598e34b31bfc upstream. The uapi documents drm_amdgpu_gem_list_handles_entry.alignment as "physical start_addr alignment in bytes", and GEM_OP GET_GEM_CREATE_INFO returns the same value in bytes, but GEM_LIST_HANDLES returns tbo.page_alignment, which is in pages. For a BO created with a 64 KiB alignment on navi31: GET_GEM_CREATE_INFO: alignment=65536 GEM_LIST_HANDLES: alignment=16 so a user such as CRIU that recreates BOs from this list uses the wrong alignment. Convert it to bytes. Fixes: f9db1fc52ceb ("drm/amdgpu: Add ioctl to get all gem handles for a process") Signed-off-by: Jesse Zhang Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit aa4493ae949c13e79aba0731394dd7a7e431342b) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 652b1f26125fe48aed5f4944698a85b457eef491 Author: Jesse Zhang Date: Fri Oct 9 13:21:33 2026 +0800 drm/amdgpu: don't drop the runtime PM reference twice in amdgpu_gpr commit de9f6bcdb44f0e410031002e2f103826ea6b6259 upstream. amdgpu_debugfs_gpr_read() drops its runtime PM reference right after reading the wave registers. When copying them to userspace fails, it jumps to the err label, which drops the reference a second time. A read into a bad buffer on Navi31 either steals a reference somebody else holds (power/runtime_usage goes from 1 to 0) or underflows the count: amdgpu 0000:03:00.0: Runtime PM usage count underflow! The registers are already in the kernel buffer at that point, so finish the hardware access first and copy the buffer with a single copy_to_user() instead of the put_user() loop with its own error path. Fixes: 9eee152aab56 ("drm/amdgpu/debugfs: fix ref count leak when pm_runtime_get_sync fails") Reviewed-by: Alex Deucher Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit 31035bbd74f7c3e10c163db875b8e67f8b50ee6a) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 05507b9b19f95ce1ca1f5fc5d394ae1f4c5b59e2 Author: Timur Kristóf Date: Wed Oct 7 00:02:52 2026 +0200 drm/amdgpu/sdma3: Work around POLL_REGMEM / FENCE hang commit 752480ad62964edf0254e151110d3e53a7cb37de upstream. SDMA can randomly hang on Polaris 10. Hard to reproduce, but has been occurring sporadically in the Mesa CI on the RADV Polaris 10 job even when Mesa isn't using the SDMA engine. When Mesa actually uses the SDMA on Polaris, the hang becomes more frequent and the reproduction rate goes up significantly in the CI system. We don't know why the hangs occur, but it seems that inserting a single NOP packet before each POLL_REGMEM and FENCE packet works around it. At the moment it's unclear which GPUs are affected, so let's apply this to SDMA 3.x for now. Note that this issue is not documented or acknowledged by AMD. Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit c343a27ed90823d08de125f7c447d96d056b75d9) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6cfc4a25d4f02935977a6a45a60e7a0c966e38c6 Author: Kenneth Feng Date: Thu Oct 8 20:28:09 2026 +0800 drm/amd/pm: add zero fan stop temperature support on smu 14.0.2 commit a2eae9f4fa1b07f8e6e61b48931228da051943f0 upstream. add zero fan stop temperature support on smu 14.0.2 Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5905 Signed-off-by: Kenneth Feng Reviewed-by: Kevin Wang Signed-off-by: Alex Deucher (cherry picked from commit f990c94a2633d0ead477eb1b174e254a6d292e66) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 55a65ef61e2775aeb18fda63bd1959fa8b41f936 Author: Yehyeong Lee Date: Wed Oct 7 10:58:42 2026 +0900 scsi: libiscsi: Validate the task named by a management response commit 11bffcd9cb346732eab2914ef44fe777a3f0b585 upstream. __iscsi_complete_pdu() fetches the task for five response types from one place and checks only that the index resolved: case ISCSI_OP_LOGOUT_RSP: case ISCSI_OP_LOGIN_RSP: case ISCSI_OP_TEXT_RSP: case ISCSI_OP_SCSI_TMFUNC_RSP: case ISCSI_OP_NOOP_IN: task = iscsi_itt_to_task(conn, hdr->itt); if (!task) return ISCSI_ERR_BAD_ITT; iscsi_itt_to_task() bounds the index against cmds_max and looks at nothing else, so a target can name any slot in the pool, including one that has never been used. task->conn is then NULL, and both iscsi_nop_out_rsp() and iscsi_complete_task() dereference it. One unsolicited NOP-In is enough; a Text Response carrying the same ITT crashes in iscsi_complete_task() instead. Require the task to be in flight and not a SCSI command, the way iscsi_itt_to_ctask() does for the command opcodes. [ 6.298634] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI [ 6.298642] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067] [ 6.298652] CPU: 1 UID: 0 PID: 111 Comm: iscsistart Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.298654] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 6.298656] RIP: 0010:iscsi_nop_out_rsp.constprop.0+0x46/0x160 [ 6.298691] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00 [ 6.298698] RSP: 0018:ffff88806c907be8 EFLAGS: 00010206 [ 6.298701] RAX: dffffc0000000000 RBX: ffff888006116800 RCX: 0000000000000020 [ 6.298702] RDX: 000000000000000c RSI: ffff88800525d578 RDI: 0000000000000060 [ 6.298703] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 6.298706] R10: 0000000000000020 R11: 0000000000000000 R12: 0000000000000000 [ 6.298706] R13: 000000000000002e R14: ffff8880056eb440 R15: ffff888006116800 [ 6.298707] FS: 00007fc02d1c2740(0000) GS:ffff8880b29bc000(0000) knlGS:0000000000000000 [ 6.298710] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.298711] CR2: 000055fe3b56ddf8 CR3: 00000000053b9004 CR4: 0000000000770ef0 [ 6.298712] PKRU: 55555554 [ 6.298713] Call Trace: [ 6.298714] [ 6.298714] __iscsi_complete_pdu+0x13a8/0x22a0 [ 6.298758] iscsi_complete_pdu+0x54/0xa0 [ 6.298759] iscsi_tcp_hdr_recv_done+0x870/0x2c80 [ 6.298778] iscsi_tcp_recv_skb+0x31e/0xec0 [ 6.298800] iscsi_sw_tcp_recv+0x12f/0x390 [ 6.298804] __tcp_read_sock+0x1ab/0x810 [ 6.298812] iscsi_sw_tcp_data_ready+0x18b/0x510 [ 6.298814] tcp_rcv_established+0x1f56/0x3a00 [ 6.298842] tcp_v4_do_rcv+0x449/0x960 [ 6.298847] tcp_v4_rcv+0x2245/0x3bc0 Fixes: 7996a778ff8c ("[SCSI] iscsi: add libiscsi") Cc: stable@vger.kernel.org Reviewed-by: Mike Christie Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20261007015842.634893-4-yhlee@isslab.korea.ac.kr Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 7215a69b6456fda79c0935c2959045dff3fcaac8 Author: Yehyeong Lee Date: Wed Oct 7 10:58:41 2026 +0900 scsi: libiscsi: Validate the ITT reflected in a Reject PDU commit c5958c770b2a0ee492414e26b07da9164a0d1f5d upstream. A Reject PDU carries a copy of the header it rejects, and iscsi_handle_reject() takes the ITT out of that copy to find the task to clean up: memcpy(&rejected_pdu, data, sizeof(struct iscsi_hdr)); ... task = iscsi_itt_to_task(conn, rejected_pdu.itt); That value is whatever the target put there. iscsi_itt_to_task() bounds the index against cmds_max and checks nothing else, so any task in the pool can be named, and iscsi_nop_out_rsp() then completes it. An index that has never been used gives a NULL task->conn: the pool is zeroed at session setup and conn is assigned only when a task is allocated. If the task was used and returned, iscsi_complete_task() hits its WARN_ON_ONCE(task->state == ISCSI_TASK_FREE) and the refcount underflows. An in-flight SCSI command is completed as successful - a 1 MiB read returned 1048576 with none of its buffer written and no warning. Validate the reflected ITT the way iscsi_itt_to_ctask() validates a command ITT, and require the task to be in flight and not a SCSI command. [ 6.248477] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI [ 6.249357] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067] [ 6.249951] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.250718] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 6.251616] RIP: 0010:iscsi_nop_out_rsp.constprop.0+0x46/0x160 [ 6.252043] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00 [ 6.252813] RSP: 0018:ffff88806c907b80 EFLAGS: 00010206 [ 6.253042] RAX: dffffc0000000000 RBX: ffff88800607e000 RCX: ffffffff8d571a25 [ 6.253345] RDX: 000000000000000c RSI: ffff88806c907c38 RDI: 0000000000000060 [ 6.253642] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff235a504 [ 6.253947] R10: 0000000000000003 R11: 7463656e6e6f6320 R12: 0000000000000000 [ 6.254251] R13: 0000000000000000 R14: ffff88806c907c38 R15: 0000000000000000 [ 6.254549] FS: 0000000000000000(0000) GS:ffff8880d95bc000(0000) knlGS:0000000000000000 [ 6.254887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.255140] CR2: 00007fc393e8ffc0 CR3: 0000000005252006 CR4: 0000000000770ef0 [ 6.255439] PKRU: 55555554 [ 6.255564] Call Trace: [ 6.255674] [ 6.255768] __iscsi_complete_pdu+0x18bf/0x22a0 [ 6.256733] iscsi_complete_pdu+0x54/0xa0 [ 6.256905] iscsi_tcp_data_recv_done+0xf4/0x250 [ 6.257103] iscsi_tcp_recv_skb+0x31e/0xec0 [ 6.257680] iscsi_sw_tcp_recv+0x12f/0x390 [ 6.258061] __tcp_read_sock+0x1ab/0x810 [ 6.258853] iscsi_sw_tcp_data_ready+0x18b/0x510 [ 6.259808] tcp_data_queue+0x1f13/0x4cd0 [ 6.260567] tcp_rcv_established+0x8a5/0x3a00 [ 6.261931] tcp_v4_do_rcv+0x449/0x960 [ 6.262269] tcp_v4_rcv+0x2245/0x3bc0 Fixes: 8afa1439fcff ("[SCSI] libiscsi: handle immediate command rejections") Cc: stable@vger.kernel.org Reviewed-by: Mike Christie Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20261007015842.634893-3-yhlee@isslab.korea.ac.kr Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 6cadfa6f1f5896632d4223d3b7addb2a29fea74e Author: Yehyeong Lee Date: Wed Oct 7 10:58:40 2026 +0900 scsi: libiscsi: Reject a negative task index from parse_pdu_itt commit 8ee2a09a1dbb257c9e828ad2497f8e4832dfb142 upstream. A transport that implements parse_pdu_itt hands libiscsi an index taken from the PDU, and both lookups bound it from above only: if (i >= session->cmds_max) i and cmds_max are both int, so a negative index passes and session->cmds[i] is read from before the array. be2iscsi produces one. beiscsi_parse_pdu() assigns the raw tag, *index = (int)itt; and beiscsi_complete_pdu() forwards an unsolicited NOP-In from the hardware async ring without replacing its ITT, so the value is the target's. It also reports the session's own age rather than the one in the tag, which leaves the age comparison in iscsi_verify_itt() with nothing to reject. Bound the index from below in both lookups. Fixes: bfead3b2cb46 ("[SCSI] be2iscsi: Adding msix and mcc_rings V3") Cc: stable@vger.kernel.org Reviewed-by: Mike Christie Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20261007015842.634893-2-yhlee@isslab.korea.ac.kr Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 1d91ec793d6c80eca963d426e0da832d40a062df Author: Yehyeong Lee Date: Mon Oct 5 21:35:54 2026 +0900 scsi: xen/scsifront: Check for a NULL shadow entry on a backend response commit 8c8222c255772713eb36cde695777a1fce224917 upstream. scsifront_do_response() validates the rqid in a backend response against VSCSIIF_MAX_REQS before using it to index info->shadow[], but then dereferences the entry to test ->inflight without checking that the slot is populated. Shadow slots are NULL before a command is submitted (the host private area is zeroed at allocation) and are reset to NULL in _scsifront_put_rqid() once a request completes, so an in-range rqid that does not correspond to an outstanding request makes the frontend dereference a NULL pointer. A malicious or buggy backend can thus crash the guest by returning a response whose rqid is in range but not in flight -- for example a spurious response before any command has been issued, or a duplicate of one already completed. The ring has only VSCSIIF_MAX_REQS (16) slots, so before the first command every in-range rqid selects a NULL slot. Reject a response whose shadow slot is not populated. Fixes: 6d1c2f48f3fc ("xen/scsifront: harden driver against malicious backend") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Reviewed-by: Juergen Gross Link: https://patch.msgid.link/20261005123555.253995-1-yhlee@isslab.korea.ac.kr Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 2effbe746452c108188f85a6951f2b0b65653840 Author: Stanley Jhu Date: Tue Oct 13 21:27:08 2026 +0800 scsi: bsg: Pass reply_len to bsg_setup_queue() to fit UFS ARPMB replies commit ec6b083915e8146e147314a5f4f1285d07b57bfc upstream. bsg-lib allocates a 96-byte (SCSI_SENSE_BUFFERSIZE) reply buffer per job, but struct ufs_rpmb_reply is 104 bytes: a 40-byte struct ufs_bsg_reply followed by a 64-byte EHS. When an Advanced RPMB command returns an EHS, ufshcd_advanced_rpmb_req_handler() copies it right after the 40-byte header and writes 8 bytes past the end of the buffer. Let each BSG transport pass its reply buffer size to bsg_setup_queue() and have ufs_bsg request sizeof(struct ufs_rpmb_reply), so the full reply reaches user space. Other transports keep SCSI_SENSE_BUFFERSIZE. Fixes: 6ff265fc5ef6 ("scsi: ufs: core: bsg: Add advanced RPMB support in ufs_bsg") Cc: stable@vger.kernel.org Signed-off-by: Stanley Jhu Link: https://patch.msgid.link/20261013132708.1669415-1-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 029770f5badedc0f0ff85fc45e24785cbbee4a67 Author: Krystian Kaniewski Date: Thu Sep 24 10:49:42 2026 +0200 ring-buffer: Fix false warning in ring_buffer_map_get_reader() commit 89bab1dba8a0167ef0d819e0f55b6bafa038e87f upstream. The mmap reader can warn when it catches up with a writer that is still committing events. rb_get_reader_page() returns NULL in this case, but ring_buffer_map_get_reader() treats that result as an error. The initial rb_per_cpu_empty() check filters out an empty buffer, but it does not guarantee that the next reader page has committed data. Writers do not take reader_lock and can advance commit_page before publishing the committed length on the new page. rb_get_reader_page() can swap to that page, catch up with the writer and return NULL. Handle NULL through the existing no-data exit without warning. Remove the caller's reader_page == commit_page check as well, since the reader-page helper already handles that case. The existing metadata update and return path remain in place. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260924084946.20104-1-krystianmkaniewski@gmail.com Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions") Assisted-by: Gemini:gemini-3.8-flash syzbot Reported-by: syzbot+de3d7f9bcc9212f3fae1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=de3d7f9bcc9212f3fae1 Link: https://syzkaller.appspot.com/ai_job?id=488adc18-a10e-42d2-a205-25327c38837f Signed-off-by: Krystian Kaniewski Reviewed-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 2f1248b728b56d583ea454fedf239550c49f7b18 Author: Donggeun Yoo Date: Fri Sep 18 16:15:07 2026 +0900 ring-buffer: Fix the sub-buffer array base in rb_meta_subbuf_idx() commit 25132363c723afc39aace8b098f547ab4a0ea759 upstream. On a persistent ring buffer, rb_meta_subbuf_idx() can return an index one sub-buffer too high. rb_setup_ids_meta_page() then fills subbuf_ids[] shifted by one and leaves subbuf_ids[0] NULL, which __rb_map_vma() dereferences when userspace maps trace_pipe_raw. rb_update_meta_reader() writes two such indices into meta->buffers[], which rb_cpu_meta_valid() would reject on the next boot, discarding the previous boot's trace. A CPU's sub-buffer array starts after its meta header and the nr_subbufs integers that follow, aligned up to a sub-buffer. rb_meta_subbuf_idx() inverts that calculation but skips only the integers, not the header, so its base is one sub-buffer low whenever the omitted header size crosses the alignment boundary. Invert the calculation with rb_subbufs_from_meta() rather than repeating it. rb_range_buffer() maps an index back to an address through the same helper, so the two directions can no longer disagree. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260918071507.1019251-1-donggeunyoo.kernel@gmail.com Fixes: b14d032973d4 ("ring-buffer: Add ring_buffer_meta data") Signed-off-by: Donggeun Yoo Reviewed-by: Vincent Donnefort Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 8512d0312cc0ea83ca4511b164c29a138bbb0c21 Author: David Carlier Date: Mon Sep 14 14:35:05 2026 +0100 ring-buffer: Do not show buffer_meta for CPUs without a buffer commit 3f23cae09a4677a3f7c163a68388512cb231ff22 upstream. The per_cpu/cpuN/buffer_meta files are created for every possible CPU, but buffer->buffers[cpu] is only allocated once that CPU comes online. Reading the file of a CPU that never came online dereferences a NULL cpu_buffer in rbm_start(). Fail the open with -ENODEV when the CPU has no buffer, as the other per CPU ring buffer interfaces do. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260914133506.4865-3-devnexen@gmail.com Fixes: 950032ffcee7 ("ring-buffer: Add output of ring buffer meta page") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260913134906.6E8A01F000FF@smtp.kernel.org/ Signed-off-by: David Carlier Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 29469305a9390d4a9d3d292fe11a58672fea82ec Author: Antoine Huret Date: Thu Oct 15 14:55:56 2026 +0200 perf: Update cgroup time when rotating multiplexed events commit e4c7c401c6b9174c0c893084fdaa6a84bd2520d7 upstream. Since commit bd2756811766 ("perf: Rewrite core context handling"), perf_rotate_context() only updates the context time before scheduling out the flexible events. It no longer updates the cgroup time, which ctx_sched_out() used to do. Cgroup events take their times from the per-cpu cgroup clock, so between two cgroup switches the rotations see a frozen clock. The events rotated out lose the running time they accumulated, and the next update, usually a read, credits the whole interval to the events that happen to be on the PMU at that moment. As a result, the time_running of multiplexed cgroup events is wrong, and so are their scaled counts, as long as no other cgroup runs on the CPU, e.g. a busy job alone on its CPUs. Counting cycles over one second of a busy loop in a cgroup gives from half to several times the max frequency of the CPU. Update the cgroup time before rotating the CPU context, as was done before the rewrite. Fixes: bd2756811766 ("perf: Rewrite core context handling") Closes: https://lore.kernel.org/r/PR3PR07MB69223331EED5BEBE150375B7849C2@PR3PR07MB6922.eurprd07.prod.outlook.com/ Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Antoine Huret Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261015-perf-cgroup-rotation-time-v1-1-93e177dfee5d@bull.com Signed-off-by: Greg Kroah-Hartman commit b67fb3955b07dc86765155fc308f69e5636bf511 Author: Lorenzo Stoakes (ARM) Date: Sat Oct 3 17:29:07 2026 +0100 perf: Track the perf mlock gift separately commit 78436f3882fb8d848c823bf8cf754988202c5ca5 upstream. The locked_vm field in struct user_struct was originally introduced by commit 789f90fcf6b0 ("perf_counter: per user mlock gift") to provide an mlock-like budget for perf measured against mm->pinned_vm (since 2011). perf grants each user a 'gift' of perf_event_mlock_kb * online CPUs of buffer pages which is charged to user->locked_vm without any RLIMIT_MEMLOCK check. Only pages beyond the gift are checked against RLIMIT_MEMLOCK, per-mm, via mm->pinned_vm, which makes it different from the standard mlock() check, which is per-mm and made against RLIMIT_MEMLOCK. However, since this was introduced, a number of other components have utilised this field where a shared resource needed to be limited against RLIMIT_MEMLOCK. The other users are currently MSG_ZEROCOPY, io_uring, AF_XDP, iommufd, s390 KVM zPCI and most recently, secretmem in commit 97d34aa65c29 ("mm/secretmem: properly account locked pages"). This field is shared between all of these, but because the gift is not checked against RLIMIT_MEMLOCK, user->locked_vm alone can exceed it - 16 CPUs * 516 KiB is already more than the default 8 MiB - after which every other user of the field fails unconditionally. This was reported by a user who saw secretmem failing while running a simultaneous perf record. Resolve the issue by simply giving perf its own field separate from the rest. BPF used user->locked_vm up until commit 80ee81e0403c ("bpf: Eliminate rlimit-based memory accounting infra for bpf maps") which landed in 5.11. Thus also eliminate the now-defunct ifdef for CONFIG_BPF_SYSCALL for user->locked_vm. This issue exists between all of the components which use user->locked_vm and perf, however secretmem is the first user who has caused a report over many years and has been backported, so target the fix at that. Fixes: 97d34aa65c29 ("mm/secretmem: properly account locked pages") Closes: https://lore.kernel.org/20261002175651.811343-1-ameer.hamza@truenas.com Reported-by: Ameer Hamza Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261003-perf-locked-vm-fix-v1-1-d214dcaf0d76@kernel.org Signed-off-by: Greg Kroah-Hartman commit 5d476bb76b7d72d8b7ed04a9c614900b097e3af7 Author: Wentao Liang Date: Wed Sep 16 07:06:31 2026 +0000 i2c: viai2c-wmt: Fix clock leak in wmt_i2c_probe() commit aaabefc79b0ff0018e8e3832169bbe359d0551fc upstream. In wmt_i2c_probe(), i2c->clk is acquired using of_clk_get(). If any subsequent operation fails or when the module is unloaded, the clock reference count is never decremented via clk_put(), leading to a resource leak. Switch to devm_clk_get() so that the clock is automatically managed and released. Fixes: 560746eb79d3 ("i2c: vt8500: Add support for I2C bus on Wondermedia SoCs") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260916070631.1965713-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit d2cb4d7451491d45e4c1445cd1b0d3bc8ee76b30 Author: Loic Poulain Date: Mon Oct 12 14:54:56 2026 +0200 i2c: qcom-cci: Fix HALT_ACK reset request being dropped commit 195f3d74b5de98969dc4fad956393bb00787efd1 upstream. A HALT_ACK interrupt indicates that the corresponding I2C master has entered the halted state and must be reset before further operation. The M0 and M1 HALT_ACK status bits may be asserted simultaneously in a single interrupt. However, the interrupt handler currently overwrites the reset mask when processing each HALT_ACK condition, causing the first reset request to be lost if both events are reported together. Accumulate reset requests instead of overwriting them so that both masters are properly reset when M0 and M1 HALT_ACK events occur in the same interrupt. Fixes: e517526195de4 ("i2c: Add Qualcomm CCI I2C driver") Signed-off-by: Loic Poulain Cc: # v5.8+ Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20261012-cci-fixes-v1-1-8cd4eb1fc5f9@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 1f36e4ddd05d540f363dbaa4c23042549f15b3ef Author: Lee Jones Date: Tue Oct 13 11:24:48 2026 +0000 tracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fields commit a244c241593b5b38a08f0df2cb43c26574efbdcb upstream. In check_synth_field(), when a synthetic event field is a stacktrace (field->is_stack) and the histogram field is not a "long[" stacktrace array, validation falls through to the generic size and signedness comparison. Because parse_synth_field() sets a stacktrace field's type to "__data_loc unsigned long[]", its size is sizeof(u64) and synth_field_signed() marks it as signed. Consequently, any 8-byte signed scalar histogram field passes the fallback check, and its scalar value is subsequently dereferenced as a kernel stacktrace pointer in get_field_size() and trace_stack(). Furthermore, checking strstr(hist_field->type, "long[") is insufficient because tracepoint fields defined with __bitmask() or __rel_bitmask() also have type "__data_loc unsigned long[]" or "__rel_loc unsigned long[]", whilst create_hist_field() treats them as 4-byte scalar values without HIST_FIELD_FL_STACKTRACE. Propagate HIST_FIELD_FL_STACKTRACE to variable references and field variables (whilst excluding variable aliases from per-element stacktrace capture), and reject any mismatch between HIST_FIELD_FL_STACKTRACE and field->is_stack in check_synth_field(). Cc: stable@vger.kernel.org Fixes: 00cf3d672a9d ("tracing: Allow synthetic events to pass around stacktraces") Link: https://patch.msgid.link/20261013112449.1006088-1-lee@kernel.org Signed-off-by: Lee Jones Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 13735c2cf4849cdd40432c06ba6bc326b6e1ee82 Author: Sasha Levin Date: Sun Oct 11 18:33:33 2026 -0400 tools: gpio: fix building from the top level with O= commit 52336337f1a01ad803c7f3ddb23f40222e9ad58d upstream. "make O= tools/gpio" fails: Makefile:27: /tools/build/Makefile.include: No such file or directory tools/Makefile clears srctree, and the gpio Makefile only works it out again when building_out_of_srctree is not set, which the top-level Makefile sets for O= builds. Also work out srctree when it is empty, as tools/bpf/Makefile does since commit a89b2cbf71d64 ("tools, bpf: Fix build for 'make -s tools/bpf O='"). Fixes: 4a6a6f5c4aeed ("tools: gpio: Use !building_out_of_srctree to determine srctree") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Sasha Levin Link: https://patch.msgid.link/20261011223358.2327625-5-sashal@kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 77a63d1b813b08c4e5a948f5e04fbaca6176aa8f Author: Daehyeon Ko <4ncienth@gmail.com> Date: Wed Oct 7 12:57:39 2026 +0900 sctp: revalidate output stream after association connect wait commit b7ad72414c673ce1fa1f463e807cd4f34f8be9bf upstream. When message interleaving is enabled, the first send waits for association establishment before building its data chunks. The wait drops the socket lock, and handshake processing can reduce the output stream count to the peer-advertised inbound stream count. sctp_stream_init() then frees the extension of every removed stream. The sender resumes with the stream that it checked before the wait. If the peer removed that stream, sctp_outq_tail() later dereferences its NULL extension. Fatal-oops policies then panic the host. KASAN: null-ptr-deref in range [0x38-0x3f] RIP: sctp_outq_tail+0x49e/0xaa0 Call Trace: sctp_primitive_SEND sctp_sendmsg_to_asoc sctp_sendmsg A range check alone is insufficient. Stream reconfiguration can grow the output count again while the lock is released without recreating extensions freed by the earlier shrink. The stream can then be in range while its extension remains NULL. The send-buffer wait has the same issue. Factor the range and extension checks into a helper and repeat both after each send-path wait that drops the socket lock. Once the lock is reacquired, the validation remains stable through data creation and queueing. If validation fails after the connect wait, the auto-created association is already established. Return ESRCH so the existing caller path keeps it under state-machine ownership instead of freeing it directly, which would leave protocol, counter and socket state inconsistent. Fixes: 668c9beb9020 ("sctp: implement assign_number for sctp_stream_interleave") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Acked-by: Xin Long Link: https://patch.msgid.link/20261007035739.3472432-1-4ncienth@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 6232e93c3036c0a7c7145f7cc24439366bea21f3 Author: Mario Limonciello Date: Mon Oct 5 13:01:47 2026 -0500 pinctrl: amd: Clear S4 wake bits when firmware has _AEI commit 1cca81a683da7f0ef2fbaf34442376044cbbad22 upstream. Commit ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe") preserves firmware-programmed S4 wake sources because some PCIe devices rely on them for Wake-on-LAN. The system that motivated that change does not expose ACPI GPIO events through _AEI. On a Chuwi CoreBook Plus, firmware exposes _AEI but also leaves the S4/S5 wake bit set for GPIO 24. This causes the machine to power back on immediately after shutdown even though Wake-on-LAN is not enabled. GPIO register dumps show that the only relevant difference is bit 15 on GPIO 24. Clearing that bit makes the machine remain off. GPIO 24 is not itself listed in _AEI, so _AEI is not a per-pin indication of which pins the OS manages; it is a platform level signal of which wake model the firmware follows. Use that signal to decide what to clear. Continue clearing S0i3/S3 bits on every system. Clear S4 bits when firmware exposes _AEI, indicating that the platform hands GPIO events to the OS, but preserve S4 bits when _AEI is absent so that firmware-programmed sources such as PCIe PME that bypass the GPIO IRQ wake API keep working. A platform that exposes _AEI for some pins while routing a wake capable device through a raw GPIO not listed in _AEI would lose that wake source unless firmware re-arms it during the sleep transition. No such system has been reported. Fixes: ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe") Reported-by: Olzhas Marat Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222041 Cc: stable@vger.kernel.org Tested-by: Olzhas Marat Reviewed-by: Shyam Sundar S K Signed-off-by: Mario Limonciello Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 5f23e4e3a31dacfd82a8f56be253adc0910ee84f Author: Aohan Mei Date: Sat Oct 3 09:34:07 2026 -0700 net: rds: fix uninitialized trans dereference in CM event handler commit 492ba6ac1b1ffb8a06ff52db0825c1af2cdb28c8 upstream. rds_rdma_cm_event_handler_cmn() assigns trans only when the RDMA device is an InfiniBand CA (RDMA_NODE_IB_CA). On any other device type, e.g. an iWARP RNIC such as siw, trans stays uninitialized, but the event switch dereferences it: unconditionally in the RDMA_CM_EVENT_CONNECT_REQUEST case via trans->cm_handle_connect(), and (with a connection context) in the ROUTE_RESOLVED and ESTABLISHED cases. An RDS listener on an iWARP device therefore crashes the kernel as soon as a connect request arrives: with CONFIG_INIT_STACK_ALL_ZERO the wild load becomes a NULL dereference at offset 0xa0 (&trans->cm_handle_connect) in the iw_cm_wq workqueue. GCC masks the bug in default builds by folding the uninitialized load into &rds_ib_transport; Clang-built kernels take the real uninitialized path and oops. The active side can land on a non-IB device too: the id that rds_ib_conn_path_connect() creates is not restricted to a node type, so rdma_resolve_addr() binds it to whichever device serves the local address, and an iWARP RNIC on the same netdev qualifies. The crash there is different: resolving a route on an iWARP id never fills in cm_id->route.path_rec, and the ROUTE_RESOLVED case writes path_rec[0].sl before it calls into the transport. The iWARP transport was dropped long ago and IB is the only transport left, so make that explicit: initialize trans to &rds_ib_transport at declaration, drop the conditional assignment, reject a connect request that arrives on a non-IB device, and drop a connection whose address resolved to one instead of resolving a route on it. The rejection is limited to RDMA_CM_EVENT_CONNECT_REQUEST on purpose: a non-zero return from the handler makes rdma_cm destroy the id the event was delivered on, which is right for the request's freshly created id but would free a connection id that RDS still owns for any other event. On the active side the id stays ic->i_cm_id and the connection's shutdown destroys it, so that case returns 0. Fixes: dcdede0406d3 ("RDS: Drop stale iWARP RDMA transport") Reported-by: TencentOS Corvus AI Link: https://lore.kernel.org/netdev/20260824111701.2979194-1-ljp1205831794@gmail.com/ Link: https://lore.kernel.org/netdev/20260825021223.3483044-1-ljp1205831794@gmail.com/ Cc: stable@vger.kernel.org Assisted-by: CodeBuddy:Kimi-K3 Signed-off-by: Aohan Mei [achender: reject only on RDMA_CM_EVENT_CONNECT_REQUEST instead of bailing out for every event on a non-IB device, so that rdma_cm does not destroy connection ids RDS still tracks; drop a connection whose address resolved to a non-IB device before a route is resolved on it; changelog adjusted] Assisted-by: LLM Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20261003163408.250568-2-achender@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 2465d27ef90de9105c2bffb6c35f8ce08918e642 Author: Jérémy Jean Date: Thu Oct 8 18:13:49 2026 +0000 net/sched: fix use-after-free in __tcf_action_put() commit 7b16eb911091aae237a8673da94e4dfb9cd21d54 upstream. __tcf_action_put() decrements the reference count before decrementing the binding count. Another thread can free the action between these operations, causing the binding-count update to access freed memory. KASAN reports it as: BUG: KASAN: slab-use-after-free in __tcf_action_put+0x327/0x340 Write of size 4 at addr ff11000000d46420 by task tc-put-pause/64 Hold the action IDR mutex across both counter updates and IDR removal, keeping cleanup outside the lock. Fixes: 16af6067392c ("net: sched: implement reference counted action release") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Jérémy Jean Reviewed-by: Simon Horman Link: https://patch.msgid.link/20261008181348.527035-2-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 568323cddd54f6886b2add298727e1b51979d099 Author: Eric Biggers Date: Tue Oct 6 10:34:32 2026 +0200 lib/crypto: poly1305: Use memzero_explicit() in poly1305_final() commit da619121a5d271e78ec709a1f9a3c5f99b9e10ad upstream. Use memzero_explicit() instead of a plain struct assignment to guarantee zeroization of the 'struct poly1305_desc_ctx'. Note that dead store elimination was only theoretically possible with link-time optimization here. But it's still worth fixing. Fixes: a1d93064094c ("crypto: poly1305 - expose init/update/final library interface") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/bug/linux-c3a6bd76-f6ab-4203-892a-cd06f7aa0c34 Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20261006083432.16328-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit ae6584eaaa4f195c50f397fe992129f06cfe3754 Author: Jérémy Jean Date: Fri Oct 9 14:53:53 2026 +0200 lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON state commit 24f07e8c07a0c0dd275331cbb41c79a78741eef9 upstream. When poly1305_blocks_neon() resumes from a base 2^26 accumulator and the next update contains an odd number of full 16-byte blocks, it processes one leading block through poly1305_mult() so that the remaining NEON work has an even block count. That requires converting the accumulator to the base 2^64 form used by poly1305_mult(). The final ADC of that conversion stores the carry into d2, but the following accumulation and poly1305_mult() use h2. If the conversion carries across bit 128, the carry is dropped and the emitted tag is wrong. This was introduced by Cryptogams commit 03dc4adf91c8 ("arm/poly1305-armv*.pl: optimize branches."), which removed the reduction that consumed d2 shortly before Linux imported the code. OpenSSL's copy did not take that change. The carry is possible because the NEON code stores the accumulator [h0, h1, h2, h3, h4] in a lazily reduced, redundant base 2^26 form: its final carry chain leaves h0, h2, h3 < 2^26, but h1 and h4 may slightly exceed 2^26 - 1. For example, the reachable state h0 = 4 h1 = 2^26 h2 = 2^26 - 1 h3 = 2^26 - 1 h4 = 2^24 - 1 represents 4 + 2^26*2^26 + (2^26-1)*2^52 + (2^26-1)*2^78 + (2^24-1)*2^104 = 2^128 + 4, despite the bit representing the 2^128 term (bit 24 of h4) not being set; the extra comes from the h1 limb being above the normal base 2^26 range. When this value is converted into the non-redundant base 2^64 form, a carry into the new 2^128 bit (in bit 0 of h2) is necessary to preserve the value. Given the above bounds, a carry into bit 128 happens exactly when h1 >= 2^26, h2 = h3 = 2^26 - 1, and h4 mod 2^24 = 2^24 - 1. Store the carry into h2, matching the other base 2^26 to base 2^64 conversions in poly1305_blocks() and poly1305_emit(). This bug causes an incorrect tag to be emitted. However, this is unlikely to happen in practice where Poly1305 is used with a random key, since the random key tends to distribute the accumulator values throughout their valid range. There isn't an obvious way for an attacker without knowledge of the r_key to cause [h0, h1, h2, h3, h4] to land on the precise values where this bug occurs. [EB: Rewrote the commit message to more clearly describe the bug and its impact, and simplified explanation about why there's a carry bit.] Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Jason A. Donenfeld Signed-off-by: Jérémy Jean Link: https://patch.msgid.link/20261009125354.315476-2-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 492c10662177f8cd5930bb1ac517948df603ae5f Author: Christian Brauner Date: Mon Oct 12 14:57:04 2026 +0200 namei: test for a negative dentry the way traverse_mounts() does commit 98b6cf102b35b2bb48d1fd74d5f664eb66fe83eb upstream. lookup_fast_for_open() only hands an O_CREAT open a cached dentry if it's positive. Otherwise the open goes on to lookup_open(), which takes the directory lock and creates the file. It tests for that with !dentry->d_inode, but traverse_mounts() later decides with the type in d_flags. And when a dentry is instantiated __d_set_inode_and_type() stores ->d_inode first and only then releases the type into ->d_flags. So a refwalk that took its reference to a negative dentry right before another task instantiates it can find ->d_inode already set in lookup_fast_for_open(), go on to step_into(), and still find the negative type in traverse_mounts(). The open then fails with -ENOENT, which an O_CREAT open must never do. rcuwalk doesn't get that far, the d_seq check in step_into() catches the instantiation. Use d_is_negative() so both look at the type. While the type is still negative the open takes lookup_open() and waits for the directory lock like any other O_CREAT open of a negative dentry. On its own the window is a couple of instructions in the creating task, so it takes an interrupt or a preempted vcpu in exactly the right spot. I haven't caught it without help in about 600 million racing O_CREAT opens. The debug patch below stalls the creating task between the two stores for names starting with "ocrace", the way an interrupt landing there would. The reproducer below opens "ocrace" with O_CREAT through symlinks on a strictatime tmpfs: following them updates their atime, which drops the walk out of rcuwalk, so the name is always looked up in refwalk. With echo 20 > /proc/sys/fs/ocrace_instantiate_us ./ocreat_enoent -t 60 on a KASAN kernel open() failed with -ENOENT 43 times in 4.9 million calls. With this patch it never failed in 4.8 million calls. Tracing step_into_slowpath() during such a run, each of the 98 -ENOENTs it returned came right after the same task had entered it with a dentry that was still typed negative. // SPDX-License-Identifier: GPL-2.0 /* * ocreat_enoent: open(O_CREAT) racing the creation of the same name. * * Writers unlink "ocrace" and create it again. Readers open it with * O_CREAT through a symlink of their own on a strictatime tmpfs. * Following the symlink updates its atime, which drops the walk out of * rcu mode, so the name is always looked up in refwalk. An O_CREAT open * must never fail with ENOENT. * * -p arms a cpu-clock perf timer with that period in ns on every writer, * so that interrupts land at random points in it. * * usage: ocreat_enoent [-t secs] [-w writers] [-r readers] [-p ns] */ #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include #include #include #define DIR "/tmp/oc" static atomic_int stop; static atomic_long opens, creates, enoent, other; static long period; static void die(const char *what) { fprintf(stderr, "FATAL %s: %s\n", what, strerror(errno)); exit(2); } static void *writer(void *arg) { (void)arg; if (period) { struct perf_event_attr attr = { .type = PERF_TYPE_SOFTWARE, .size = sizeof(attr), .config = PERF_COUNT_SW_CPU_CLOCK, .sample_period = period, }; if (syscall(SYS_perf_event_open, &attr, 0, -1, -1, 0) < 0) die("perf_event_open"); } while (!atomic_load(&stop)) { int fd; unlink(DIR "/ocrace"); fd = open(DIR "/ocrace", O_CREAT | O_RDWR | O_CLOEXEC, 0644); if (fd >= 0) close(fd); atomic_fetch_add(&creates, 1); } return NULL; } static void *reader(void *arg) { char lnk[64]; snprintf(lnk, sizeof(lnk), DIR "/lnk.%ld", (long)arg); while (!atomic_load(&stop)) { int fd = open(lnk, O_CREAT | O_RDWR | O_CLOEXEC, 0644); if (fd >= 0) close(fd); else if (errno == ENOENT) atomic_fetch_add(&enoent, 1); else atomic_fetch_add(&other, 1); atomic_fetch_add(&opens, 1); } return NULL; } int main(int argc, char **argv) { int secs = 60, nw = 4, nr = 12, c, n = 0; pthread_t t[256]; while ((c = getopt(argc, argv, "t:w:r:p:")) != -1) { switch (c) { case 't': secs = atoi(optarg); break; case 'w': nw = atoi(optarg); break; case 'r': nr = atoi(optarg); break; case 'p': period = atol(optarg); break; default: return 2; } } if (nw + nr > 256) return 2; mkdir(DIR, 0755); if (mount("oc", DIR, "tmpfs", MS_STRICTATIME, "mode=0755")) die("tmpfs"); for (long i = 0; i < nr; i++) { char lnk[64]; snprintf(lnk, sizeof(lnk), DIR "/lnk.%ld", i); if (symlink("ocrace", lnk)) die("symlink"); } for (long i = 0; i < nw; i++) if (pthread_create(&t[n++], NULL, writer, NULL)) die("writer"); for (long i = 0; i < nr; i++) if (pthread_create(&t[n++], NULL, reader, (void *)i)) die("reader"); sleep(secs); atomic_store(&stop, 1); for (int i = 0; i < n; i++) pthread_join(t[i], NULL); printf("%ds: %ld opens, %ld creates, ENOENT %ld, other errors %ld\n", secs, atomic_load(&opens), atomic_load(&creates), atomic_load(&enoent), atomic_load(&other)); umount2(DIR, MNT_DETACH); return atomic_load(&enoent) ? 1 : 0; } # diff --git a/fs/dcache.c b/fs/dcache.c # --- a/fs/dcache.c # +++ b/fs/dcache.c # @@ -32,9 +32,13 @@ # #include # #include # #include # +#include # #include "internal.h" # #include "mount.h" # # +/* debug: stall "ocrace*" names between ->d_inode and the type */ # +static int sysctl_ocrace_instantiate_us; # + # #include # # /* # @@ -200,6 +204,13 @@ # } # # static const struct ctl_table fs_dcache_sysctls[] = { # + { # + .procname = "ocrace_instantiate_us", # + .data = &sysctl_ocrace_instantiate_us, # + .maxlen = sizeof(int), # + .mode = 0644, # + .proc_handler = proc_dointvec, # + }, # { # .procname = "dentry-state", # .data = &dentry_stat, # @@ -405,6 +416,10 @@ # unsigned flags; # # dentry->d_inode = inode; # + /* debug: an interrupt landing right here */ # + if (unlikely(READ_ONCE(sysctl_ocrace_instantiate_us)) && # + !strncmp(dentry->d_name.name, "ocrace", 6)) # + udelay(READ_ONCE(sysctl_ocrace_instantiate_us)); # flags = READ_ONCE(dentry->d_flags); # flags &= ~DCACHE_ENTRY_TYPE; # flags |= type_flags; Fixes: e747e15156b7 ("fs: try an opportunistic lookup for O_CREAT opens too") Cc: stable@vger.kernel.org # v6.12+ Link: https://patch.msgid.link/20261012-work-namei-ocreate-v1-1-c7883b17ee28@kernel.org Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 4586ef24ce390e8becb9f3e5852d5d3978b01c33 Author: Christian Brauner Date: Fri Oct 9 23:51:54 2026 +0200 eventfs: Free the eventfs_inode after an rcu grace period too commit 2cd88c498ecff8e22bf4c397b8eb226db70ac343 upstream. tracefs_d_revalidate() reads ->is_freed of the eventfs_inode that dentry->d_fsdata points to, and ->d_revalidate() is called in rcu pathwalk mode with nothing but rcu_read_lock() held. The dentry itself stays around for such a walker, but tracefs_d_release() drops its reference to the eventfs_inode when the dentry is killed, and release_ei() then frees it after a grace period of eventfs_srcu. An SRCU grace period doesn't wait for rcu_read_lock() sections, so the walker can read an eventfs_inode that is already gone. With a pathwalk held up in tracefs_d_revalidate() while the dentry goes away: BUG: KASAN: slab-use-after-free in tracefs_d_revalidate+0x76/0x90 Read of size 1 at addr ff1100010152d8d0 by task walker/97 Call Trace: tracefs_d_revalidate+0x76/0x90 lookup_fast+0x320/0x640 path_lookupat+0x160/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 vfs_fstatat+0x4d/0x90 __do_sys_newfstatat+0xa0/0x100 do_syscall_64+0x10e/0x5e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [...] Allocated by task 1: __kmalloc_cache_noprof+0x249/0x560 eventfs_create_dir+0x7a/0x590 event_create_dir+0x2fb/0xcf0 trace_add_event_call+0xbf/0x150 [...] Freed by task 11: kfree+0x1db/0x5b0 srcu_invoke_callbacks+0x3a3/0x620 process_one_work+0x937/0x1810 worker_thread+0x4f1/0xd60 Before commit 8e556432477e ("eventfs: Use SRCU for freeing eventfs_inodes") release_ei() used call_rcu(), which covered the walker, while eventfs_iterate() needs the SRCU grace period. Wait for both and chain call_rcu() from the SRCU callback. Cc: stable@vger.kernel.org Fixes: 8e556432477e ("eventfs: Use SRCU for freeing eventfs_inodes") Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-4-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 2e10b8a74f55b5aae33db105d3e2d3ae759c865a Author: Aviv Vaknin Date: Fri Oct 2 23:28:20 2026 +0300 pid_namespace: make zap_pid_ns_processes() freezable commit 81933038f5e273d17ed22792f906889393b204c5 upstream. When the init of a pid namespace exits, zap_pid_ns_processes() waits until all other pids in the namespace are freed. A tracer outside the namespace that does not reap its traced zombies keeps those pids allocated, so this wait has no upper bound, and while it lasts every suspend attempt fails: Freezing user space processes failed after 20.006 seconds (2 tasks refusing to freeze, wq_busy=0): Neither wait is freezable. The first loop sleeps in do_wait(), which returns -ERESTARTSYS on the freezer's fake signal; the loop then clears TIF_SIGPENDING and waits again without ever freezing. The final loop sleeps in TASK_INTERRUPTIBLE, and since nothing clears TIF_SIGPENDING there, schedule() returns immediately after the first freeze attempt and the task spins until the wait ends. Sleep in TASK_INTERRUPTIBLE | TASK_FREEZABLE in do_wait(), so that the freezer can freeze tasks waiting there directly, and in TASK_IDLE | TASK_FREEZABLE in the final loop, like coredump_task_exit() does. This was hit with Chromium-based browsers: crashpad ptrace-attaches the threads of a crashed renderer, which is a pid namespace init, and does not reap those killed during the dump. Fixes: 3eb07c8c8adb ("pid namespaces: destroy pid namespace on init's death") Fixes: b9a985db9896 ("pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes") Cc: stable@vger.kernel.org # 6.1+ Suggested-by: Oleg Nesterov Signed-off-by: Aviv Vaknin Link: https://patch.msgid.link/20261002202820.3433318-1-vaknins33@gmail.com Acked-by: Oleg Nesterov Reviewed-by: Bradley Morgan Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 952501bfc6e5e654ac4a17ec9d90c1ec614bd9f1 Author: Kyle Zeng Date: Fri Oct 2 05:59:02 2026 +0000 fsnotify: prevent mark additions during connector teardown commit 36ebddca56b9d8993d6dc984fdecc748ee1f5e06 upstream. fsnotify_destroy_marks() keeps a reference to its current mark while it drops conn->lock to destroy the mark. This stabilizes the forward-walk cursor, but does not prevent a new mark from being inserted before it. For example, an inotify watch re-added after IN_IGNORED sorts before the old, detached mark for the same group. The walk can miss the replacement and then detach the entire connector from the object. The replacement is still on its group's marks_list and, for inotify, in the watch IDR. The group mutex no longer protects the connector's object from disappearing. An unprivileged fdinfo read racing the final detach can consequently call igrab(NULL): BUG: KASAN: null-ptr-deref in igrab+0x24/0x100 Write of size 4 at addr 0000000000000148 Call Trace: igrab+0x24/0x100 inotify_show_fdinfo+0x1dc/0x5e0 seq_show+0x397/0x690 Set a DESTROYING flag under conn->lock before starting the walk, and reject new marks on that connector with -ENOENT. The existing add-mark error paths undo the temporary group-list entry and the backend's watch allocation. Do not wait for teardown while holding the group mutex, which the destroyer needs. Once the old connector is detached, an add can install a fresh connector as before. This closes the insertion race for all object types using the common connector teardown, without changing the mark reference or SRCU lifetime rules. Fixes: 6b3f05d24d35 ("fsnotify: Detach mark from object list when last reference is dropped") Cc: stable@vger.kernel.org Signed-off-by: Kyle Zeng Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit d00d5f534a8238674755e59826a6c7d3c8efb870 Author: Amirmohammad Eftekhar Date: Thu Oct 1 14:43:54 2026 -0700 KVM: nVMX: Reset MMU back to the root MMU if loading L2 state fails for !VM-Entry commit c8f4cfe1cf93bce924e27f2abead7a4c4a487505 upstream. Reset the vCPU's MMU pointer back to the root MMU if loading L2 state fails in the "not from VM-Entry" case, i.e. when emulating RSM or handling KVM_SET_NESTED_STATE. Failure to unwind the MMU pointer results in KVM trying to run L1 with a nested MMU, and is especially problematic if the vCPU manages to free its nested state before the VM crashes. Constructing the root for a nested EPT MMU goes through vmcs12, which is dynamically allocated/freed when nVMX is enabled/disabled. And so if the nested state is freed with the MMU still pointing at the nested MMU, KVM will hit a NULL pointer deref when attempting to get L1=>L2 EPTP. BUG: kernel NULL pointer dereference, address: 0000000000000078 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 114a2d067 P4D 111743067 PUD 11141f067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 20 UID: 1000 PID: 1272 Comm: nested_tdp_faul Not tainted 7.3.0-rc4-8c89f11d1a99b-sink-vm #1914 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel] Call Trace: kvm_mmu_load+0xcd/0x870 [kvm] kvm_arch_vcpu_ioctl_run+0x18f5/0x1f80 [kvm] kvm_vcpu_ioctl+0x2c7/0x970 [kvm] __x64_sys_ioctl+0x90/0xd0 do_syscall_64+0x9c/0x4d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47491b Modules linked in: kvm_intel kvm irqbypass CR2: 0000000000000078 ---[ end trace 0000000000000000 ]--- RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel] Cc: David Woodhouse Fixes: 72e9cbdb4338 ("KVM: nVMX: fix SMI injection in guest mode") Fixes: 8fcc4b5923af ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE") Cc: stable@vger.kernel.org Signed-off-by: Amirmohammad Eftekhar [sean: write changelog] Signed-off-by: Sean Christopherson Link: https://patch.msgid.link/20261001214356.3825100-2-seanjc@google.com Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b77e9622bbade9812e2090c66d25c372f515e921 Author: EJ Campbell Date: Tue Sep 29 11:12:32 2026 -0700 x86/kvm: Don't consume async #PF flags on a kernel #PF in NMI context commit 81d99abe2bd81379abfb595e403bbbee6fbfc624 upstream. An async #PF "page not present" event arrives through the #PF vector, and its reason sits in the per-CPU apf_reason.flags until __kvm_handle_async_pf() reads and clears it. If an NMI arrives after the event is injected and before the #PF handler reads the flags, and the NMI handler itself takes a #PF, that fault reads and clears the flags belonging to the #PF it interrupted. It then finds interrupts disabled in the NMI context it interrupted, and panics: Kernel panic - not syncing: Host injected async #PF in interrupt disabled region Call Trace: panic+0x52/0x60 __kvm_handle_async_pf+0xb0/0xb0 exc_page_fault+0x71/0xb0 asm_exc_page_fault+0x27/0x30 RIP: 0010:__get_user_nocheck_8+0x6/0x20 perf_callchain_user+0x147/0x1a0 get_perf_callchain+0x12d/0x1c0 ... perf_event_nmi_handler+0x26/0x50 exc_nmi+0xe8/0x110 RIP: 0010:asm_exc_page_fault+0x0/0x30 The last RIP line shows the NMI landing on the first instruction of the #PF entry. perf with user call chains takes such a fault: the sampling NMI walks the user stack with __get_user(), which faults when a saved frame pointer is not a valid user address or the walk runs off the top of the stack. The same window exists when KVM, running as an L1 hypervisor with DELIVERY_AS_PF_VMEXIT, reads the flags itself after a #PF VM-exit. The NMI entry code saves and restores CR2 for this nesting, but not the async #PF reason. Andy Lutomirski described the race, with perf as the example, when async #PF delivery was reworked in 2020 [1]. Saving and clearing the flags across the NMI, next to CR2, was discussed there but not merged. Since that rework, Linux has stopped setting KVM_ASYNC_PF_SEND_ALWAYS, so the host delivers "page not present" only for user mode faults and a kernel-mode fault in NMI context (including kernel-mode #MC and #DB) cannot be an async page fault. In that case, return without touching the flags so that the interrupted handler finds them intact. Tested on v7.3-rc5 in a 4-vCPU, 2 GiB guest restored from a snapshot whose memory is served on demand through userfaultfd, so that reading it back takes async #PFs, while every thread samples hardware cycles with user call chains and points its frame pointer at an unmapped page. Without this patch the guest panicked as above in 3 of 3 runs. With it, the guest survived 3 of 3 runs of 60 seconds, and the host counted 148,441 to 153,334 kvm_async_pf_not_present events in the first 20 seconds of each. On 6.18.50 the results were the same: the guest panicked without the patch and survived with it. Link: https://lore.kernel.org/all/ed71d0967113a35f670a9625a058b8e6e0b2f104.1583547991.git.luto@kernel.org/ [1] Link: https://lore.kernel.org/all/20211126123145.2772-1-jiangshanlai@gmail.com/ [2] Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: EJ Campbell Link: https://patch.msgid.link/CADkxfh-uQTca_6jB1JPDq1MsKffF_UKGQR339oQSJNcoV75GNQ@mail.gmail.com Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 811fb6d0b07605e8e8d93bde8748be4b3028809a Author: Cen Zhang (Microsoft) Date: Fri Oct 9 18:47:15 2026 -0400 watch_queue: Fix note pool publication race in watch_queue_set_size() commit 5e531d62f1f8834faf7a4eed0d41105cf6570a8f upstream. There is a race between watch_queue_set_size() and post_one_notification(). watch_queue_set_size() publishes wqueue->notes, notes_bitmap, nr_pages and nr_notes with plain stores, and post_one_notification() reads them with plain loads under a different lock, so nothing orders the four stores against the poster's loads: depending on the build, notes can be stored last (gcc 14 on x86-64 does this). Since keyctl_watch_key() lets a watch attach to a queue before it is sized, post_one_notification() can already be running on another CPU at that moment: it reads nr_notes > 0, passes its bounds check, and then reads notes while it is still NULL, dereferencing notes[0]. An unprivileged user triggers this reliably by watching one of its own keys through a notification pipe and racing ioctl(IOC_WATCH_QUEUE_SET_SIZE) on that pipe against keyctl(KEYCTL_SETPERM) on the key from another CPU, triggering: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:post_one_notification.isra.0+0xa2/0x1e0 Call Trace: __post_watch_notification+0x148/0x180 keyctl_setperm_key+0x119/0x130 do_syscall_64+0x108/0x4c0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception in interrupt Fix this by publishing nr_notes last with smp_store_release(), and by reading it once with smp_load_acquire() in post_one_notification() before the bitmap and the page array are touched. A poster that observes a non-zero nr_notes then also observes the pool behind it; one that observes zero drops the notification as before. Fixes: c73be61cede5 ("pipe: Add general notification queue support") Reported-by: Dae R. Jeong Closes: https://lore.kernel.org/all/ZT-S8Q7tyutcvu_q@dragonet/ Reported-by: AutonomousCodeSecurity@microsoft.com Suggested-by: Dae R. Jeong Signed-off-by: Cen Zhang (Microsoft) Link: https://patch.msgid.link/20261009224715.46121-1-cenzhang@linux.microsoft.com Reviewed-by: Bradley Morgan Cc: Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 2b54d3c971a1e5df3c9b0bcc10311ae6c29e79d8 Author: Christian Brauner Date: Fri Oct 9 23:51:56 2026 +0200 unicode: free the map after a grace period commit a96c5299bd7305eb984377681eb3222a57376405 upstream. generic_ci_d_hash() and generic_ci_d_compare() read sb->s_encoding and dereference the unicode map while a pathwalk in rcu mode holds nothing but rcu_read_lock(). The filesystems that use them, ext4, f2fs and tmpfs, drop the map with utf8_unload() from ->put_super(), which runs when the last reference to the mount goes away. A lookup that is still inside such a filesystem at that point reads a freed map. With a pathwalk held up in utf8_casefold_hash() while the last reference to a casefolded tmpfs goes away: BUG: KASAN: slab-use-after-free in utf8nlookup+0x74c/0x950 Read of size 8 at addr ff110001030fe658 by task walker/98 Call Trace: utf8nlookup+0x74c/0x950 utf8byte+0x160/0x1560 utf8_casefold_hash+0x167/0x230 generic_ci_d_hash+0xdd/0x1c0 link_path_walk+0x11ad/0x1d30 path_lookupat+0x63/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 [...] Allocated by task 94: __kmalloc_cache_noprof+0x249/0x560 utf8_load+0x4e/0x570 shmem_parse_opt_casefold.isra.0+0x92/0x270 [...] Freed by task 97: kfree+0x1db/0x5b0 shmem_put_super+0x72/0x170 generic_shutdown_super+0x14c/0x530 kill_anon_super+0x3a/0x60 deactivate_locked_super+0x9c/0xf0 cleanup_mnt+0x9f/0x130 So far that has been hard to hit. umount(2) waits for a grace period in namespace_unlock() before it drops the mount, so only a mount whose last reference goes away elsewhere, like the close of a file or a chdir out of a lazily unmounted directory, can race a walker. So it is reachable. Delay the free until a grace period has passed. The map and the data table it holds a reference to then outlive any pathwalk that found the superblock before the mount went away. The reference on the data table module is dropped from the rcu callback as well. utf8-core is built in whenever CONFIG_UNICODE is set, so there is no module exit that would have to wait for the callbacks. Overlayfs points the s_encoding of an overlay at the map of its first layer without taking a reference of its own. That stays correct. The layer is held by the overlay, so its map is dropped only after the overlay is gone. Fixes: b886ee3e778e ("ext4: Support case-insensitive file name lookups") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-6-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit d518fc5cced100e55d03cee17378754025f62825 Author: Sasha Levin Date: Sun Oct 11 18:33:41 2026 -0400 bootconfig: give the footer size static_assert a message commit a1ddc2721467fb68241372db77657fd0dcf6cda5 upstream. static_assert() without a message is a C23 feature, so clang warns: main.c:498:56: warning: '_Static_assert' with no message is a C23 extension [-Wc23-extensions] Add a message. Link: http://lkml.kernel.org/r/20261011223358.2327625-13-sashal@kernel.org Fixes: 6ed5e20466c79 ("bootconfig: Fix unaligned access when building footer") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Sasha Levin Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 1a177064f501ed4b67873a43aae5d5bdb18b3704 Author: Sung Byeongchan Date: Thu Oct 8 02:35:42 2026 +0900 autofs: ignore notification errors from a replaced pipe commit 65676cd4203c0e41a94caf54080a7f0a95434bda upstream. autofs_notify_daemon() takes a reference to the current notification pipe under wq_mutex, then drops the mutex before writing the request. The write can block while the daemon enters catatonic mode and installs a replacement pipe. If the old pipe's reader is then closed, the delayed write returns -EPIPE and the generic error path enters catatonic mode again. That transition acts on the current superblock state, closes the replacement pipe, and releases the new daemon generation's wait queues. Only enter catatonic mode when the pipe which failed is still the current pipe. Factor the already-locked transition so the identity check and state change are atomic with respect to another replacement. This was reproduced on v7.3-rc5-337-gff47652a4b66c in a local QEMU guest. An unprivileged UID 65534 lookup filled the old packet pipe before a normal CATATONIC/SETPIPEFD restart. On the unmodified kernel, the new pipe received HUP and both a pending victim lookup and a later lookup failed with ENOENT in two out of two fresh-mount runs. With this change, the new pipe remained active, received an intact 304-byte request, and both victim lookups completed in two out of two runs. Normal lookup and restart-without-a-blocked-writer controls passed. No KASAN, oops, refcount, or lock diagnostic was observed. A source reproducer and complete local logs are available privately on request. The demonstrated impact is limited to denial of a shared autofs service during a legitimate daemon restart. No memory corruption, information leak, privilege escalation, or code execution primitive was observed. Fixes: 8d7b48e0bc5fa ("autofs4: add miscellaneous device for ioctls") Cc: stable@vger.kernel.org Signed-off-by: Sung Byeongchan Link: https://patch.msgid.link/20261007173542.593624-1-tjdqudcks0424@naver.com Acked-by: Ian Kent Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit debb0f36bfe3d1de607ed6b08febd83747eb9829 Author: Christian Brauner Date: Fri Oct 9 23:51:52 2026 +0200 afs: free the super info after a grace period commit 59e483739f2fd14327ece3f60c4995d060ca46b7 upstream. afs_atcell_get_link() resolves the @cell and .@cell symlinks of a dynamic root in rcu pathwalk mode. Before it looks at the dentry it gets the afs_net through afs_i2net(), which reads ->net_ns from the afs_super_info in sb->s_fs_info. The @cell dentries are kept around when unused and the dynamic root has no ->d_revalidate(), so a lookup that finds @cell in the dcache gets to ->get_link() in rcu mode. afs_kill_super() frees the afs_super_info with a plain kfree() in afs_destroy_sbi(). Right now a pathwalk can't still be in afs_atcell_get_link() at that point, but only by accident. umount(2) waits for a grace period in namespace_unlock() before it drops the mount. And a mount whose last reference goes away elsewhere, like the chdir out of a lazily unmounted directory, still gets a grace period from bdi_unregister(). afs_fill_super() sets up a private bdi, so generic_shutdown_super() unregisters it from kill_anon_super() and bdi_remove_from_list() waits in synchronize_rcu_expedited() before afs_destroy_sbi() runs. That grace period protects the rcu readers of bdi_list in the writeback code. It has nothing to do with pathwalk. Don't rely on it and free the afs_super_info after a grace period. Fixes: 30bca65bbbae ("afs: Make /afs/@cell and /afs/.@cell symlinks") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-2-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 5078c91f5c84bb383d0a10ed39856f98575e39cf Author: Igor Paunovic Date: Fri Sep 4 14:59:36 2026 +0200 accel/rocket: search every core slot when a core is removed commit 6eff1d69dae808a1518aee5a58d0853a8db3f1be upstream. rocket_remove() decrements rdev->num_cores for each core it removes, while find_core_for_dev() searches slots 0 to num_cores - 1. Unbinding the cores in the order they were bound therefore loses the last one: by the time it is removed the search range has already shrunk past its slot, so find_core_for_dev() returns -1 and rocket_remove() gives up without doing anything. num_cores never reaches zero, rocket_device_fini() never runs, and the file-scoped rdev keeps pointing at a device that is going away. Binding the cores again starts from that stale count, because rocket_probe() takes rdev->num_cores as the slot to fill. On an RK3588, which describes three cores, the second round lands on slots 1, 2 and 3 while rdev->cores was allocated with room for three: rocket fdab0000.npu: Rockchip NPU core 1 version: 1179210309 rocket fdac0000.npu: Rockchip NPU core 2 version: 1179210309 rocket fdad0000.npu: Rockchip NPU core 3 version: 1179210309 The write to rdev->cores[3] is past the end of the array. Nothing in tree reads the core array often enough to notice, so the overrun is silent today. It turned up while testing a devfreq series on top of this, where a worker walks every core a few times a second, and UBSAN caught the first bool it read out of the overrun entry: UBSAN: invalid-load in drivers/accel/rocket/rocket_devfreq.c:47:10 load of value 5 is not a valid value for type '_Bool' Workqueue: devfreq_wq devfreq_monitor Record how many slots were allocated and search all of them. Every core is then found on removal, num_cores reaches zero, the device is torn down and a later bind starts from a clean rdev. This does not make unbinding a single core out of several work. probe still takes num_cores as the slot to fill, so rebinding one core while its siblings stay bound would write over a slot that is already in use, and rocket_open() still reaches for cores[0] whether or not anything is there. Both of those want more thought than a fix should carry. Found by unbinding and rebinding all three cores on an Orange Pi 5 Plus. With this applied, 25 unbind/rebind rounds and 5 module unload/reload rounds run clean there: the cores land in slots 0, 1 and 2 every time, whichever order they are bound in, and the shared supply goes back to a single user after each round. Fixes: ed98261b4168 ("accel/rocket: Add a new driver for Rockchip's NPU") Cc: stable@vger.kernel.org Signed-off-by: Igor Paunovic Assisted-by: LLM sparse checkpatch Tested-by: Jiaxing Hu # RK3576, two cores Tested-by: Sidong Yang # RK3588, 3 cores Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260904125936.26234-1-royalnet026@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7249a442ab261ceffcfc45d29c9bbb33a284e40d Author: Alexander Gruhlke Date: Sun Oct 11 21:01:45 2026 +0200 PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV [ Upstream commit e8df1d194c39b7a5159d570798941851f70a8668 ] With RRS Software Visibility, pci_dev_wait() considers a device ready as soon as reading the Vendor ID doesn't return the RRS value. Devices aren't required to respond with RRS while they aren't ready, so the read may return ~0 and pci_dev_wait() stops waiting too early. This was seen with Intel [8086:0a54] and Samsung [144d:a80c] NVMe SSDs. Also wait while the Vendor ID reads ~0. A VF's Vendor ID always reads ~0, so check its Command register instead, as is done without RRS SV. Fixes: d591f6804e7e ("PCI: Wait for device readiness with Configuration RRS") Link: https://lore.kernel.org/r/20250611101442.387378-1-hui.wang@canonical.com Suggested-by: Lukas Wunner Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Alexander Gruhlke Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Link: https://patch.msgid.link/20261011190145.23621-3-gruhlke@mailbox.org Signed-off-by: Sasha Levin commit 7595bacee48bc30b5021eccf199d704d4e5e5374 Author: John Ogness Date: Fri Oct 16 11:00:34 2026 +0206 printk: Postpone kthread startup [ Upstream commit 5f339c46f153184570f16c8e789c9709b14cbe8b ] There have been various bug reports related to SMP systems hanging on boot. The reports vary but seem to have some overlap with regard to missed IPI's during SMP setup. The reports also show that reverting NBCON console usage allows the bugs to disappear. The NBCON kthreads for console printing are started very early during boot using early_initcall(). Since these kthreads are asynchronously enabling/disabling interrupts during early boot, they may be interfering with early SMP setup on some hardware platforms. Starting the console printing kthreads later has shown to avoid the hanging on systems that could previously reproduce the issue. Postpone kthread starting until after all arch initcalls have completed. Reported-by: Derek Barbosa Closes: https://lore.kernel.org/linux-rt-users/arPmYPbFLf2EldIl@debarbos-thinkpadt14gen5.rmtusma.csb Fixes: 76f258bf3f2a ("printk: nbcon: Introduce printer kthreads") Signed-off-by: John Ogness Tested-by: Derek Barbosa Link: https://patch.msgid.link/20261016085441.857695-1-john.ogness@linutronix.de Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 3eb08f09bfb364051f51316da873c3bd51a839ef Author: Haris Okanovic Date: Tue Oct 13 13:56:00 2026 -0500 perf: Fix perf_pmu_migrate_context() leaving events behind [ Upstream commit e76b36b4be7160eaa14b416681e548b125702395 ] __perf_pmu_remove() walks the group leaders of a CPU and PMU with perf_event_groups_for_cpu_pmu(), removing each one as it goes. perf_remove_from_context() takes the leader out of the groups rbtree, after which rb_next() on that node returns NULL, prematurely ending the walk. Other groups stay behind in the source context. On CPU hotplug, they are then torn down with the dying CPU. They keep running until teardown, while the PMU's interrupt and migrated events are on a new CPU, which drivers rely on never happening. Walk ctx->event_list instead and pick out the PMU's events by their pmu_ctx. Fixes: bd2756811766 ("perf: Rewrite core context handling") Signed-off-by: Haris Okanovic Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20261013185603.1347265-2-harisokn@amazon.com Signed-off-by: Sasha Levin commit d0ffb0dc01166473d8868e6d112a06c2ffb04c50 Author: Peng Fan Date: Tue Oct 13 14:01:12 2026 +0800 gpio: mxc: fix race between gpiochip registration and IRQ domain setup [ Upstream commit 205cccd06e545694754e1bf8d626ea96e742cd8a ] devm_gpiochip_add_data() makes the GPIO chip visible to consumers immediately. Since the chip sets .to_irq = mxc_gpio_to_irq, which calls irq_find_mapping(port->domain, offset), any to_irq() call between gpiochip registration and IRQ domain creation will operate on a NULL domain. Fix by moving devm_gpiochip_add_data() after the IRQ domain and generic irq chip are fully initialized, ensuring port->domain and the irq chip handlers are ready before the chip becomes visible to consumers. Fixes: d37a65bb4663 ("gpio/mxc: Move Freescale MXC gpio driver to drivers/gpio") Signed-off-by: Peng Fan Reviewed-by: Linus Walleij Reviewed-by: Frank Li Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20261013-gpio-mxc-cleanup-v7-4-c4d769587d3e@nxp.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 238f93bd1d0638690b4bfa7edc95612de4f1d534 Author: Peng Fan Date: Tue Oct 13 14:01:11 2026 +0800 gpio: mxc: fix wakeup_pads bit operations [ Upstream commit 170aeff46fb54f41545c85a72aec525aebc79d44 ] gpio_set_wake_irq() can be called concurrently for different pins on the same port. The writer-vs-writer race is the concern: two concurrent gpio_set_wake_irq() calls for different pins on the same port both do a non-atomic read-modify-write on the same wakeup_pads word. The old |= and &= compile to separate load/modify/store instructions that can interleave, losing one CPU's update. assign_bit() uses an atomic RMW instruction, so concurrent writers to different bits in the same word are safe. The reader side (for_each_set_bit in noirq_suspend, wakeup_pads > 0) runs in noirq context where no concurrent writer can execute, so reader atomicity is not needed. wakeup_pads is a u32, while assign_bit() operates on unsigned long pointers. On 64-bit platforms, this causes an 8-byte read-modify-write on a 4-byte field, corrupting the adjacent is_pad_wakeup. So change wakeup_pads to unsigned long and reorder to avoid wasting words. And fix the enable/disable path unconditionally sets/clears the wakeup_pads bit even when enable_irq_wake()/disable_irq_wake() fails. Only update the bit on success. Fixes: f60c9eac54af ("gpio: mxc: enable pad wakeup on i.MX8x platforms") Assisted-by: LLM Reviewed-by: Frank Li Signed-off-by: Peng Fan Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20261013-gpio-mxc-cleanup-v7-3-c4d769587d3e@nxp.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit dab5c228a846887edcc4bcb551d43213720970cd Author: Alexander Stein Date: Tue May 26 08:35:02 2026 +0200 gpio: mxc: use BIT() macro [ Upstream commit 9de94681ee48770ec7e2062451a572b557bf9298 ] Replace the open-code with the BIT() macro. Signed-off-by: Alexander Stein Reviewed-by: Frank Li Link: https://patch.msgid.link/20260526063504.25916-2-alexander.stein@ew.tq-group.com Signed-off-by: Bartosz Golaszewski Stable-dep-of: 170aeff46fb5 ("gpio: mxc: fix wakeup_pads bit operations") Signed-off-by: Sasha Levin commit 911f606dd05d7fcc46f4a3ed2983e489e20e7bf2 Author: Peng Fan Date: Tue Oct 13 14:01:10 2026 +0800 gpio: mxc: fix both_edges bit operations [ Upstream commit b7719c575dec69146f6d537fd616b27083c0cf45 ] gpio_set_irq_type() can be called concurrently for different pins on the same port. The IRQ core serializes per irq descriptor, but different pins have different descriptors, so on SMP systems two concurrent gpio_set_irq_type() calls for pins on the same port run without mutual exclusion. The read-modify-write of port->both_edges is performed outside the port-wide scoped_guard(gpio_generic_lock_irqsave) section, so concurrent updates for different pins can overwrite each other, causing missed interrupts or stuck IRQ lines on dual-edge triggered pins. The original uniprocessor MXC SoCs were not affected; the race became reachable on multi-core i.MX7 and i.MX8 SoCs that reuse this driver. Convert both_edges from u32 to unsigned long and use set_bit(), clear_bit(), and test_bit() to make the modifications atomic. Fixes: 910862ec092c ("mxc: emulate GPIO interrupt on both-edges") Reviewed-by: Frank Li Signed-off-by: Peng Fan Reviewed-by: Linus Walleij Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20261013-gpio-mxc-cleanup-v7-2-c4d769587d3e@nxp.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 261802c14e1a3281987ea8f106701e5ed9652f68 Author: Peng Fan Date: Tue Oct 13 14:01:09 2026 +0800 gpio: mxc: fix race between chained IRQ handler install and probe completion [ Upstream commit 38d44f78f041ffe60c8e2443b99434a199e7541d ] mxc_update_irq_chained_handler() is called before the IRQ domain, the generic IRQ chip, and the port list entry are set up. If an interrupt arrives in that window: - mx3_gpio_irq_handler() calls generic_handle_domain_irq() with port->domain still NULL. - mx2_gpio_irq_handler() walks mxc_gpio_ports, but the port has not been added to the list yet. Additionally, if any of the subsequent probe steps (gpio_generic_chip_init(), devm_gpiochip_add_data(), irq_domain_create_legacy(), or mxc_gpio_init_gc()) fail, the error paths never unregister the chained handler, leaving a dangling handler that points at freed memory. Move the handler installation after all its dependencies are ready and after list_add_tail(), so the handler is never live while the data structures it touches are incomplete, and is never installed if probe fails. Fixes: 5f6d1998adeb ("gpio: mxc: release the parent IRQ in runtime suspend") Assisted-by: LLM Reviewed-by: Frank Li Signed-off-by: Peng Fan Reviewed-by: Linus Walleij Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20261013-gpio-mxc-cleanup-v7-1-c4d769587d3e@nxp.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 78189c0e35abbcdab3b8ab0b764d578c02900734 Author: Kent Gibson Date: Thu Oct 15 10:57:49 2026 +0800 gpiolib: fix memory leak in gpiod_set_array_value_complex() on error paths [ Upstream commit c28846ca1ac6134881114d272314623c8433e372 ] A drive-by review by Sashiko reports that, after a failed call to gpiochip_set_multiple(), gpiod_set_array_value() returns abruptly, bypassing the freeing of possibly alloced bitmaps, potentially leaking memory. It is an unlikely error path, but is possible. Defer the return code check until after the bitmap_free() block. Fixes: 9b407312755f ("gpiolib: rework the wrapper around gpio_chip::set_multiple()") Reported-by: Sashiko Link: https://lore.kernel.org/linux-gpio/sashiko-outbox-168233@kernel.org/ Signed-off-by: Kent Gibson Link: https://patch.msgid.link/20261015025749.47039-1-warthog618@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 1c9fcfca51e3c5cd46dd72a4da74d56eff183513 Author: Joas Antonio dos Santos Date: Fri Oct 9 12:59:19 2026 -0300 calipso: keep BIG TCP payload_len in calipso_skbuff_setattr() [ Upstream commit 8070ed578b6b9134e045627fb745c887a806d46e ] calipso_skbuff_setattr() adjusts payload_len by the length of the option it inserts or resizes: payload = ntohs(ip6_hdr->payload_len); ip6_hdr->payload_len = htons(payload + len_delta); GRO can build BIG TCP packets larger than IPV6_MAXPLEN, and stores payload_len == 0 for them; ipv6_payload_len() then falls back to skb->len. For such a packet forwarded to a destination mapped to CALIPSO, the code above writes len_delta (or 65536 + len_delta when shrinking) into payload_len, and ipv6_payload_len() no longer falls back to skb->len. nf_tables, conntrack and sch_cake rely on it. The same arithmetic also wraps when a packet grows past IPV6_MAXPLEN, and a BIG TCP packet that shrinks below IPV6_MAXPLEN should get its real length back. Set payload_len from the skb length with ipv6_set_payload_len(), which stores 0 above IPV6_MAXPLEN and the real length otherwise, as ipv6_gro_complete() does. The network header was just reset to skb->data, so skb->len - sizeof(*ip6_hdr) is the payload length. Tested on one kernel (arm64, QEMU) with SELinux permissive, a minimal mdp-generated policy (network_peer_controls=1), "netlabelctl calipso add pass doi:16" and a NetLabel mapping of fd00:2::/64 to CALIPSO DOI 16. calipso_skbuff_setattr() was called through netlbl_skbuff_setattr() from a test-only debugfs hook (not part of this patch) adding a level-only label; payload_len after the call: case before fix after fix real length 1000, unlabeled 1016 1016 1016 70000 GSO, payload_len 0 16 0 70016 65530 GSO, grows past MAXPLEN 10 0 65546 65540 GSO with a 24 byte hop header, shrinks below MAXPLEN 65528 65532 65532 1000 with a 24 byte hop header 992 992 992 (0 means ipv6_payload_len() returns the real length.) On the forward path, with a client injecting unlabeled UDP through a router to a server, the router adds the CALIPSO option and the server delivers all datagrams (Udp6InDatagrams 5, Ip6InTruncatedPkts 0) with this patch. Fixes: 81fbc812132c ("ipv6/gro: insert temporary HBH/jumbo header") Suggested-by: Eric Dumazet Suggested-by: Wang Zhan Signed-off-by: Joas Antonio dos Santos Assisted-by: Claude:claude-opus-5-5 Reviewed-by: Wang Zhan Acked-by: Paul Moore Link: https://patch.msgid.link/179156155963.36253.400481753322266658@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e221a7d6f7c91eeb08f49eeb6661f144a732edda Author: Alice Mikityanska Date: Thu Feb 5 15:39:14 2026 +0200 net/ipv6: Introduce payload_len helpers [ Upstream commit b2936b4fd56294e49d6c8e9152ea6c4982757c7d ] The next commits will transition away from using the hop-by-hop extension header to encode packet length for BIG TCP. Add wrappers around ip6->payload_len that return the actual value if it's non-zero, and calculate it from skb->len if payload_len is set to zero (and a symmetrical setter). The new helpers are used wherever the surrounding code supports the hop-by-hop jumbo header for BIG TCP IPv6, or the corresponding IPv4 code uses skb_ip_totlen (e.g., in include/net/netfilter/nf_tables_ipv6.h). No behavioral change in this commit. Signed-off-by: Alice Mikityanska Acked-by: Paolo Abeni Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260205133925.526371-2-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski Stable-dep-of: 8070ed578b6b ("calipso: keep BIG TCP payload_len in calipso_skbuff_setattr()") Signed-off-by: Sasha Levin commit 40c04abcbc34e3afe338f41dae851ecbd72852ac Author: Nicolai Buchwitz Date: Fri Oct 9 12:10:41 2026 +0200 net: bcmgenet: unshare the skb before writing the control block [ Upstream commit 89771ce4f8f67dcffae561b2ccac95c0f6e3aa01 ] bcmgenet stores first_cb, last_cb and bytes_sent in the skb control block and reads them back on completion to free the skb and credit BQL. ether_setup() leaves IFF_TX_SKB_SHARING set, so the stack can resubmit a shared skb that is still in the ring. The next transmit overwrites last_cb, so the earlier slots complete without crediting their bytes and BQL stalls the queue until the watchdog resets it. Unshare the skb before writing the control block. Reproduce with pktgen in clone_skb mode, which hands the driver the same skb while earlier copies are still in the ring: modprobe pktgen pg=/proc/net/pktgen echo "add_device eth0" > $pg/kpktgend_0 echo "dst_mac AA:BB:CC:DD:EE:FF" > $pg/eth0 echo "dst 192.0.2.1" > $pg/eth0 echo "clone_skb 8" > $pg/eth0 echo "count 0" > $pg/eth0 echo start > $pg/pgctrl & sleep 5 echo stop > $pg/pgctrl wait cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight inflight stays nonzero on the now idle queue. clone_skb 0 leaves it at zero. Fixes: f48bed16a756 ("net: bcmgenet: Free skb after last Tx frag") Signed-off-by: Nicolai Buchwitz Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20261009-nb-genet-shared-skb-net-v1-1-c6d0a841977d@tipi-net.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bdd55b8a8acbf6b4840ab420eb6a63774bf4593b Author: Kyle Zeng Date: Wed Oct 7 18:14:00 2026 -0700 netlink: avoid hashing the network namespace pointer [ Upstream commit f88bb3606e4bd11ee035b682cddc2999e604609a ] The netlink rhashtable key includes a raw struct net pointer and a user-controlled port ID. Both /proc/net/netlink and socket diagnostics expose the table's bucket order. By binding and rebinding chosen NETLINK_USERSOCK port IDs, an unprivileged reader can distinguish equal buckets and recover the low bits of the Jenkins hash. Its 32-bit seed and the limited set of kernel-image slides can then be searched offline to recover the address of init_net. Use the namespace's unique, non-address net_cookie in the comparison key instead. It is assigned before the per-net initializers run and remains unchanged for the namespace's lifetime. The lookup key and object hash are still built by netlink_compare_arg_init(), keeping lookup, insertion, removal and rehashing consistent while preserving namespace separation. Neither public table walker needs to change. Reading the socket's namespace cookie in netlink_compare() is safe under RCU, including during namespace teardown. netlink_release() removes the socket from the hash table and defers its final put with call_rcu(). cleanup_net() runs the per-net exit methods and waits for outstanding RCU callbacks with rcu_barrier() before freeing namespace storage. Unlike ns.ns_id, net_cookie is also available and initialized during setup_net() in older stable kernels, making the change straightforward to backport to v5.15 and later. Fixes: c428ecd1a21f ("netlink: Move namespace into hash key") Assisted-by: LLM Signed-off-by: Kyle Zeng Reviewed-by: Simon Horman Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20261008011359.63727-2-kylebot@openai.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c9fb89246d9922ac0a45d504adb03e0bb971310c Author: Xingui Yang Date: Mon Sep 28 12:02:34 2026 +0800 scsi: libsas: Fix SMP IO deadlock during HA resume [ Upstream commit 81e097a064b28b4a1f6ca1a8b433e659c1bd64c0 ] smp_execute_task_sg() calls pm_runtime_get_sync() on the host before issuing an SMP command. When that command is itself issued from the HA resume path, the get_sync() deadlocks: it waits for the ongoing resume (the device is RPM_RESUMING), while the resume is blocked in sas_drain_work() waiting for that same SMP IO to complete. The deadlock needs an expander-attached SATA disk. During sas_resume_ha() -> sas_drain_work(), DISCE_RESUME -> sas_resume_sata() -> ata_sas_port_resume() requests ATA_EH_RESET, and the hard reset for such a disk is done via SMP PHY CONTROL (sas_ata_hard_reset() -> sas_phy_reset() -> sas_smp_phy_control() -> smp_execute_task_sg()). Direct-attached SATA resets through lldd_control_phy() and SSP devices use TMFs, so neither hits this. Replace the get_sync()/put_sync() pair with pm_runtime_get_noresume()/pm_runtime_put(). smp_execute_task_sg() only needs to hold off autosuspend while the SMP is in flight, and it must not try to resume the host: a sync resume issued from the HA resume path itself is what deadlocks, and by the time sas_resume_ha() runs, hw_init has already reinitialized the hardware, so the device is accessible without one. The usage reference is still required. Discovery work normally runs inside an event worker's PM reference, taken at sas_notify_port_event() notify time and held until the handler has flushed the disco queue. sas_rediscover_ex_phy() however requeues DISCE_REVALIDATE_DOMAIN from within the revalidation worker itself, and flush_workqueue() does not wait for work items queued during execution, so that chained revalidation runs with no outer PM reference - without the get_noresume(), its SMP could race autosuspend. For the BSG path, sas_smp_handler() is the only caller which may find the host autosuspended: expander SMP requests do not go through any SCSI device request queue, so nothing else in that path holds the host awake. Resume it there with pm_runtime_resume_and_get() and check the result. Fixes: 3dbbbf656b850 ("scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race") Signed-off-by: Xingui Yang Reviewed-by: John Garry Link: https://patch.msgid.link/20260928040234.992912-1-yangxingui@huawei.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit fbb5a6f0b06fb2abc7ddfcb1d7ffdaaca44313ed Author: Martin Kaiser Date: Wed Oct 14 10:37:40 2026 +0200 tracing: probes: error if BTF is required but unavailable [ Upstream commit 66c658033d842bb75f81f20aaa4a378fe47be1a1 ] traceprobe_expand_meta_args expands probe arguments based on BTF info. Return an error if we have arguments that need expanding but BTF is not supported. The params variable is now unused, it can be removed. Link: https://lore.kernel.org/all/20261014083838.31020-1-martin@kaiser.cx/ Fixes: d157d7694460 ("tracing/probes: Support BTF field access from $retval") Signed-off-by: Martin Kaiser Reviewed-by: Steven Rostedt Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 4c42ce499ce4b1c787e61082e3b13df4f30c4eaa Author: Kyle Zeng Date: Fri Oct 2 06:17:05 2026 +0000 pipe: preserve existing fasync readers on writer setup failure [ Upstream commit 40bb03d3ea6f6a915218508819ecc4d7a7fa260d ] F_SETFL and FIOASYNC decide whether to invoke ->fasync() before pipe_fasync() takes pipe->mutex. Two enables of one O_RDWR FIFO can therefore both enter the callback. fasync_helper() allocates before checking for an existing entry. If the first enable installs both entries, a second enable can update the reader entry and then fail the allocation for the writer entry. The error path removes the pre-existing reader entry, clearing FASYNC while the writer entry remains registered. __fput() then skips ->fasync(), so a later pipe notification can dereference the freed file or its f_owner. An unprivileged memory-pressure reproducer triggers a KASAN slab-use-after-free in send_sigio() through this path. Keep the reader helper's result and undo the registration only if this call added it. The pipe mutex serializes changes to both lists, so a failed new registration still removes its reader, while a failed duplicate preserves the existing registrations and FASYNC. Successful duplicate enables continue to update fa_fd as before. Fixes: 76398425bb06 ("Move FASYNC bit handling to f_op->fasync()") Signed-off-by: Kyle Zeng Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 7780f9e828da0aa2e457f41592d6c6614d2e995c Author: Sasha Levin Date: Sun Oct 11 18:33:42 2026 -0400 samples: pidfd: fix userprogs typo [ Upstream commit f1365f97fb7498d805981102eee22d362ae643f2 ] The Makefile adds pidfd-metadata to "usertprogs-always-y", which kbuild does not know, so the sample has not been built since the conversion to userprogs, even with CONFIG_SAMPLE_PIDFD=y. Fix the variable name. pidfd-metadata.c builds without warnings with gcc and clang for x86_64 and arm64. Fixes: 60fb0b1239719 ("samples: pidfd: build sample program for target architecture") Signed-off-by: Sasha Levin Link: https://patch.msgid.link/20261011223358.2327625-14-sashal@kernel.org Reviewed-by: Christian Brauner Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 04d4571c00db61a9664f387752fa05cb3c08a537 Author: Cen Zhang Date: Sun Oct 11 23:35:06 2026 +0800 ocfs2/dlm: Protect the recovery list during debugfs reads [ Upstream commit 4c435828932bf46f29860e4a0375bcae101b778a ] Recovery participant records must remain alive while debug_state_print() walks reco.node_data and formats their fields. The formatter holds dlm->spinlock, but the recovery participant list is protected by dlm_reco_state_lock. In particular, dlm_destroy_recovery_area() detaches the list under dlm_reco_state_lock and frees the detached records after releasing it. A concurrent debugfs open can therefore read freed memory. Protect the participant traversal and field reads in debug_state_print() with dlm_reco_state_lock, matching the existing list writers. This also serializes the traversal against list_add_tail() during recovery-area initialization. Make the existing lock available to the debug code through dlmcommon.h; the lock remains internal to the OCFS2 DLM module. Release dlm->spinlock after formatting the other domain state and before acquiring dlm_reco_state_lock, so the debug reader does not nest the two locks. Leave recovery list insertion, detachment and freeing unchanged. KASAN report as below: BUG: KASAN: slab-use-after-free in debug_state_open+0x1169/0x12d0 Read of size 4 at addr ffff88810662ef80 by task dlm-state-stres/896 CPU: 1 UID: 0 PID: 896 Comm: dlm-state-stres Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? debug_state_open+0x1169/0x12d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? debug_state_open+0x1169/0x12d0 kasan_report+0xe0/0x110 ? debug_state_open+0x1169/0x12d0 debug_state_open+0x1169/0x12d0 ? __pfx_debug_state_open+0x10/0x10 full_proxy_open_regular+0x193/0x310 do_dentry_open+0x595/0x12d0 ? __pfx_full_proxy_open_regular+0x10/0x10 vfs_open_consume+0xd1/0x400 ? srso_alias_return_thunk+0x5/0xfbef5 path_openat+0x18d0/0x2020 ? __pfx_path_openat+0x10/0x10 do_file_open+0x21e/0x470 ? __pfx_do_file_open+0x10/0x10 ? _raw_spin_unlock+0x23/0x40 ? srso_alias_return_thunk+0x5/0xfbef5 ? alloc_fd+0x3a6/0x6b0 do_sys_openat2+0xf4/0x1b0 ? __pfx_do_sys_openat2+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __fput+0x5b5/0xa60 __x64_sys_openat+0x136/0x1e0 ? __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Register dump omitted.] Allocated by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x28d/0x610 dlm_remaster_locks+0x147/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 Freed by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x308/0x580 dlm_destroy_recovery_area+0x285/0x460 dlm_remaster_locks+0x17c4/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff88810662ef80 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 0 bytes inside of freed 32-byte region [ffff88810662ef80, ffff88810662efa0) [Page and memory-state dumps omitted.] Fixes: 007dce53a29c ("ocfs2/dlm: Dump the dlm state in a debugfs file") Signed-off-by: Cen Zhang Link: https://patch.msgid.link/pm-ocfs2-objects-candidate-0049-v3-184e46c47f5283f06191@gmail.com Reviewed-by: Joseph Qi Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit de3923caf0772f88d89aca3df40d6554146017a4 Author: Erik Faye-Lund Date: Wed Oct 14 09:09:01 2026 +0200 drm/panthor: fix immortalis condition [ Upstream commit c347fef5f8f8927985bd67835331ce4cf7ff43a4 ] Exactly 10 cores is also valid for an Immortalis configuration, according to the public documentation: https://support.arm.com/compute-ip/immortalis-g715 So let's report this G715 with 10 cores as Immortalis as well, as long as it supports the ray-intersection feature. This matches what we do for more recent GPUs as well. Fixes: 3b1dc21d6d80 ("drm/panthor: Add support for Mali-Gx15 family of GPUs") Signed-off-by: Erik Faye-Lund Reviewed-by: Liviu Dudau Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patch.msgid.link/20261014070902.169273-1-erik.faye-lund@arm.com Signed-off-by: Steven Price Signed-off-by: Sasha Levin commit 9b07828b133b326cb4fb59f144ca37f8db535999 Author: Linfeng Sun Date: Tue Aug 11 20:48:43 2026 +0800 scsi: target: iscsi: Fix race in discovery auth updates [ Upstream commit e15b81f602edbdee39c335546f25486a1747f3f0 ] Separate configfs opens can concurrently update the discovery AuthMethod parameter. Both callers may free the same value in iscsi_update_param_value(), causing a double-free. Protect the lookup and replacement with the discovery TPG access lock, as used by the other TPG configfs parameter updates. Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Signed-off-by: Linfeng Sun Reviewed-by: Mike Christie Link: https://patch.msgid.link/20260811124843.6817-1-linfeng.sun.dev@gmail.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 71e12d43ef37ea08842174eda997355cab830809 Author: Laurence Oberman Date: Tue Oct 6 12:42:50 2026 -0400 scsi: st: Save the visited block for the partition the drive is in [ Upstream commit c9e9f024dd4f61f0f6636c9f2ed0830f87060e11 ] set_location() saves the current tape location before switching partitions, so that switch_partition() can return to it later. It reads the location with READ POSITION but stores it in the st_partstat of STp->partition, ignoring the partition the drive reports. The two differ after a device reset. When the reset is recovered with MTREW, MTSEEK or MTEOM, st_ioctl() sets STp->partition = 0 and calls switch_partition() to return to STp->new_partition. A drive that was in partition 1 is still there, so set_location() files the partition 1 position under partition 0. The next switch to partition 0 locates to that block: if partition 0 holds less data, MTSETPART fails with EIO (BLANK CHECK), otherwise the tape is silently positioned at the wrong block. IBM ULTRIUM-TD5 (LTO-5), LU reset in partition 1 at block 1025: st 12:0:0:0: [st0] Visited block 1025 for partition 0 saved. ... st 12:0:0:0: [st0] Setting block to 1025 and partition to 0. st 12:0:0:0: [st0] Error: 402, cmd: 2b 2 0 0 0 4 st 12:0:0:0: [st0] Sense Key : Blank Check [current] st 12:0:0:0: [st0] Add. Sense: End-of-data detected Store the location in the st_partstat of the partition reported by READ POSITION. With the fix: st 12:0:0:0: [st0] Visited block 1025 for partition 1 saved. This is a pre-existing issue. It was not caught when testing the recent st reset series because the partition test was only run on scsi_debug: on the LTO drive it was skipped, since can-partitions is off in the test harness's stinit.conf, as is normal for LTO. scsi_debug hides the problem because its emulated tape returns to the beginning of partition 0 on an LU reset. It was found while validating a backport of that series to RHEL 9.8, when the partition tests were run on real hardware with can-partitions enabled. The same failure then reproduced on unmodified RHEL 9.8 and on upstream, and the fix makes the test pass on v7.3-rc3 and RHEL 9.8 with an LTO-5. The harness (https://gitlab.com/loberman/tapetest, test X03) now refuses to silently skip the partition tests on hardware. Fixes: 7081dc75df79 ("scsi: st: Restore some drive settings after reset") Assisted-by: Claude Signed-off-by: Laurence Oberman Link: https://patch.msgid.link/20261006164250.773840-1-loberman@redhat.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit e3bf250a2fda6e2bc1fb6d96b136a07a682b1479 Author: Keith Busch Date: Tue Sep 22 08:34:16 2026 -0700 nios2: fix __wsum type degradation in csum_fold() [ Upstream commit b963f2345fa20417401c51a69dedb6a58eea33a9 ] csum_fold() shifts a bitwise __wsum type, which sparse reports as "restricted __wsum degrades to integer". Sparse only checks the body of a static inline once something instantiates it, so this went unnoticed until a recent block layer change added the first csum_fold() caller to a file built on this architecture. Force cast to a __u32 for the shift, as the other architectures do. Fixes: eea9507a69d6 ("nios2: Library functions") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609222053.5gjiJjtb-lkp@intel.com/ Signed-off-by: Keith Busch Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit e4d45c651d19f1a88976a75c73c52654eb654328 Author: Carlos Jones Jr Date: Fri Oct 2 16:55:40 2026 +0800 spi: tegra114: assert CS GPIO for every transfer in a message [ Upstream commit 8980bc573ae2d2b9d86d76aeb86c76e1597070bf ] The driver provides its own transfer_one_message() and therefore drives the chip-select GPIO itself rather than through the SPI core. The GPIO is asserted only in the is_first_of_msg path of tegra_spi_setup_transfer_one(), but tegra_spi_transfer_end() deasserts it whenever a transfer has cs_change set. For a multi-transfer message whose earlier transfers request cs_change -- for example a register read that sends the address in one transfer and clocks the data back in the next -- the CS GPIO is released after the first transfer and never re-asserted, so the remaining transfers are clocked with chip-select inactive and the peripheral never drives the bus. This was observed with an ADIS16470 IMU (adis16475 driver), whose register read is a two-transfer, cs_change-framed exchange: a logic analyzer showed the data frame clocked with CS high, and the driver read 0 while the device drove 0x4056 on the wire. Re-assert the CS GPIO for every transfer so that multi-transfer messages keep chip-select active across the whole message. gpiod_set_value() is idempotent and polarity-aware, so this is a no-op for the first transfer and for messages that keep CS asserted throughout. Fixes: 63c1440596ff ("spi: tegra114: add support for gpio based CS") Signed-off-by: Carlos Jones Jr Link: https://patch.msgid.link/20261002085540.1625-1-carlosjr.jones@analog.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 21f41b6daf0dbe2cdaaf9f54af6e23fd3c9190b9 Author: Bommu Krishnaiah Date: Tue Oct 6 07:33:14 2026 +0530 drm/xe/oa: Zero OA buffer at allocation [ Upstream commit fd8662823caa114a63f07222d2aa448f6ac5e864 ] ttm_bo_type_kernel BOs are not guaranteed to be zeroed on allocation and may contain data from previously freed pages. Since the OA buffer is mmap'able by userspace, this can expose stale kernel memory contents. Streams opened with DRM_XE_OA_PROPERTY_OA_DISABLED allocate the OA buffer without calling xe_oa_init_oa_buffer(). Zero the buffer at allocation to prevent information disclosure through mmap. The existing zeroing in xe_oa_init_oa_buffer() remains necessary for zero report-id/timestamp detection on enable/re-enable. Fixes: 392bf22238ff ("drm/xe/oa/uapi: OA buffer mmap") Assisted-by: LLM Cc: Umesh Nerlige Ramappa Cc: Ghimiray, Himal Prasad Signed-off-by: Bommu Krishnaiah Reviewed-by: Himal Prasad Ghimiray Reviewed-by: Umesh Nerlige Ramappa Reviewed-by: Tejas Upadhyay Link: https://patch.msgid.link/20261006020314.2711762-1-krishnaiah.bommu@intel.com Signed-off-by: Tejas Upadhyay (cherry picked from commit 126c4c5388f9311a390b9b254a835b0cf0f55331) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 6046bb9cb2859e3d9bf939e4d6527f3827e1096f Author: Niranjana Vishwanathapura Date: Mon Oct 12 14:50:14 2026 -0700 drm/xe: skip eviction of a BO with no resource [ Upstream commit 448e76cbdc6652ccd3ba337b7a6e1f028859f2ed ] xe_evict_flags() switches on tbo->resource->mem_type to choose an eviction placement. An xe BO can reach eviction with no ttm.resource, e.g. an imported dma-buf BO whose resource was freed during teardown while its attachment is still live: the exporter then invalidates it via xe_dma_buf_move_notify() -> xe_bo_evict(), and the switch dereferences a NULL resource and faults. A BO with no resource has nothing placed or mapped, so there is nothing to evict. Return an empty placement (num_placement = 0), mirroring the handling already used for non-xe scatter-gather BOs just above; ttm_bo_validate() then takes the pipeline-gutting path and returns 0. Without the fix the xe_dma_buf@xe_test_dmabuf_move_notify_no_resource dynamic live selftest will fail with below stack. BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:xe_evict_flags+0xf4/0x140 [xe] Call Trace: xe_bo_evict+0x40/0xa0 [xe] ? ttm_bo_pipeline_gutting+0x71/0x180 [ttm] xe_test_dmabuf_move_notify_no_resource+0x182/0x440 [xe] xe_dma_buf_kunit+0x387/0x580 [xe] v2: Add Fixes tag and failure info in commit text (Matt Brost) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Assisted-by: GitHub-Copilot:claude-opus-4.8 Signed-off-by: Niranjana Vishwanathapura Reviewed-by: Tejas Upadhyay Link: https://patch.msgid.link/20261012215014.1495677-5-niranjana.vishwanathapura@intel.com (cherry picked from commit dbcfaac6331f1fcb0c2fe3ad3e9adb1e5d43ec0c) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 8d15821aa2de1cc6b16b3b03a4f6a61217fdf7a8 Author: Mario Limonciello Date: Tue Oct 13 07:54:23 2026 -0500 ASoC: amd: yc: disable MSI on resume [ Upstream commit 2a31b5378c6db9c4a8d399e5d10d32cd4b732bef ] BIOS/firmware may re-enable MSI in PCI config space during system resume even though this driver only uses legacy INTx interrupts. If MSI is left enabled with stale address and data registers, the device can write interrupts to a bogus address and cause an IOMMU IO_PAGE_FAULT. Clear the MSI Enable bit before reinitializing ACP hardware on system resume. Keep runtime resume separate because firmware does not restore PCI configuration on that path. Fixes: c8212df7bc0f ("ASoC: amd: add acp6x pci driver pm ops") Reported-by: Marek Borůvka Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222119 Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20261013125425.3541206-1-mario.limonciello@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit efe1393e783f29b4a676011fba4b8f444b58a659 Author: Alexandre Cassen Date: Wed Oct 7 16:38:23 2026 +0200 net/mlx5: HWS, fix flow meter offset within its bulk [ Upstream commit 1b0aad53ad715b15ccbad8c65d15c149c925f00a ] The flow meter action is bound to the first ASO object of the bulk but the rule offset only indexes the meter within its own object. A rule past the first object runs on the wrong meter. Fixes: 82d3639ef7dc ("net/mlx5: fs, add support for flow meters HWS action") Signed-off-by: Alexandre Cassen Reviewed-by: Moshe Shemesh Acked-by: Tariq Toukan Link: https://patch.msgid.link/20261007143830.1733583-3-acassen@corp.free.fr Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a3516f0704b968b6fe89d8f71c020d60124e2367 Author: Alexandre Cassen Date: Wed Oct 7 16:38:22 2026 +0200 net/mlx5: HWS, release L2 to L3 tunnel reformats to their own pool [ Upstream commit 39e02ddf74bbe9c9080555232ba8100462cba2ad ] L2 to L3 tunnel reformats are now released to the el2tol3tnl pools. Fixes: aecd9d1020e3 ("net/mlx5: fs, add HWS packet reformat API function") Signed-off-by: Alexandre Cassen Reviewed-by: Yevgeny Kliteynik Acked-by: Tariq Toukan Link: https://patch.msgid.link/20261007143830.1733583-2-acassen@corp.free.fr Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 79071b67182e1b352d51a3917729b8d424710b49 Author: Guangshuo Li Date: Wed Jul 8 14:28:45 2026 +0800 accel/rocket: clear rdev on device init failure [ Upstream commit 4ac852419f0d317c7bd8db5b8acb3cc78be7fe33 ] rocket_probe() stores the return value from rocket_device_init() in the file-scoped rdev pointer before checking whether it is an error pointer. If rocket_device_init() fails, rdev is left as an ERR_PTR. The rdev pointer is also used as the marker for whether the shared rocket device has already been initialized. A later core probe can therefore see a non-NULL rdev, skip rocket_device_init(), and dereference the error pointer when reading rdev->num_cores. Save the error code and clear rdev before returning from the rocket_device_init() failure path. Fixes: ed98261b4168 ("accel/rocket: Add a new driver for Rockchip's NPU") Signed-off-by: Guangshuo Li Reviewed-by: Igor Paunovic Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260708062845.716487-1-lgs201920130244@gmail.com Signed-off-by: Sasha Levin commit 06791594274f87c29f1a9f1961d700272716a49d Author: Kyle Zeng Date: Tue Oct 6 15:42:32 2026 -0700 netlink: reset skb headers before unicast and multicast filtering [ Upstream commit 8bf659bd54e1f00e34cf5244b1d289c506fa47c0 ] Socket filters can use SKF_NET_OFF and SKF_LL_OFF to read relative to an skb's network and MAC headers. Netlink producers may reserve headroom without resetting those headers, allowing a receiving socket's filter to read data before the initialized message. For example, IWPM HELLO replies are allocated with dev_alloc_skb(), which reserves NET_SKB_PAD bytes. An unprivileged NETLINK_RDMA user can attach a classic socket filter and disclose this headroom through the length of the delivered reply. The resets in netlink_dump() do not help because IWPM sends a separately allocated skb through netlink_unicast(). Reset both headers before running the receiver's filter in unicast and broadcast delivery, as is already done for dump skbs. This also covers other netlink producers that reserve headroom without changing their allocation or message-building code. Fixes: b1153f29ee07 ("netlink: make socket filters work on netlink") Assisted-by: LLM Signed-off-by: Kyle Zeng Link: https://patch.msgid.link/20261006224232.50724-1-kylebot@openai.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4a9fb8122a19de04fdfb4cf568331b69dac00645 Author: Michael Reeves Date: Tue Oct 6 18:03:16 2026 +1100 regmap: Drop map lock during cache init and exit [ Upstream commit abff0a48b110fe52d43999b4cb7c793a510a6bf1 ] On systems with CONFIG_PROVE_RAW_LOCK_NESTING enabled, Apple GPIO probe triggers an "Invalid wait context" lockdep warning. The driver uses a regmap with a raw spinlock and REGCACHE_FLAT. During regcache_init(), regcache_flat_init() allocates memory while holding the raw spinlock. The memory allocator can acquire a non-raw spinlock, which causes an invalid raw-to-non-raw lock nesting error. The abbreviated call chain is: apple_gpio_pinctrl_probe regcache_init regcache_flat_init __kmalloc_noprof __pcs_replace_empty_main refill_objects _raw_spin_lock_irqsave Cache allocation occurs before the regmap is published, cache destruction occurs after users have stopped accessing it, and regmap_reinit_cache() requires callers to prevent concurrent access. Remove the outer map lock from cache initialization and destruction. Keep it for cache population and normal register access. The Maple cache still uses its internal spinlock during teardown. That lock can also be acquired from hard IRQ context during register access. Add Maple-state irqsave helpers and use them during teardown to preserve the lock's IRQ-safe lockdep state. Fixes: fd4ebc07b4df ("regmap: Hold the regmap lock when allocating and freeing the cache") Suggested-by: Mark Brown Suggested-by: Liam R. Howlett Signed-off-by: Michael Reeves Reviewed-by: Peng Fan Link: https://patch.msgid.link/20261006-regcache-lifecycle-submit-v3-2-37bdd82fd47c@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bae057687f61580dd897411cd749da22a7740647 Author: Francesco Lavra Date: Tue Jun 16 13:44:29 2026 +0200 regcache: Do not overwrite error code when finalizing cache after error [ Upstream commit 9108f7fa493b4c88cbc09503e0c164244456bad5 ] During regcache initialization, if an error occurs in the cache_ops->populate callback, and if cache operations include an exit callback, the error code from populate() is overwritten with the return value from exit(). This hides the error condition from the caller of regcache_init(), and can cause NULL pointer dereferences when the regcache is later accessed. Fixes: 94a3a95f0315 ("regcache: Add ->populate() callback to separate from ->init()") Signed-off-by: Francesco Lavra Link: https://patch.msgid.link/20260616114429.1852456-1-flavra@baylibre.com Signed-off-by: Mark Brown Stable-dep-of: abff0a48b110 ("regmap: Drop map lock during cache init and exit") Signed-off-by: Sasha Levin commit b498b70a8174bcb4e801d4d794a49f2d143c5c9f Author: Andy Shevchenko Date: Fri Oct 31 09:03:16 2025 +0100 regcache: Add ->populate() callback to separate from ->init() [ Upstream commit 94a3a95f03154d8d4c6206950a7f6ef9a30baec6 ] In the future changes we would like to change the flow of the cache handling. Add ->populate() callback in order to prepare for that. Signed-off-by: Andy Shevchenko Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20251031080540.3970776-2-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown Stable-dep-of: abff0a48b110 ("regmap: Drop map lock during cache init and exit") Signed-off-by: Sasha Levin commit 0a9a172d4cbfcf201a58b5e2e1d8dd66c64576eb Author: HyeongJun An Date: Thu Oct 8 22:09:52 2026 +0900 ASoC: nau8822: Fix the 128x oversampling switch bits [ Upstream commit 4db45fc1da3d62d0fa6e8f1e457ae92e8741ed07 ] The DAC and ADC 128x Oversampling Switches use bit 5 of R10 and R14. The NAU8822 datasheet register map puts DACOS and ADCOS at bit 3 of those registers. In R14, bit 5 is inside HPF[6:4], which the High Pass Cut Off control owns. So turning on ADC oversampling changes the high pass cut-off, and the oversampling bit cannot be set. In R10, bit 5 is reserved, so the DAC switch has no effect. Use bit 3 for both. Fixes: 1e3cb6c321be ("ASoC: nau8822: new codec driver") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20261008130953.2446692-7-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9a87917b8f3d517f5361bfaca5d1e2f72a1a0593 Author: HyeongJun An Date: Thu Oct 8 22:09:51 2026 +0900 ASoC: wm8978: Fix the 128x oversampling switch bits [ Upstream commit d0567ca9a2faa33efbe5ae84ef7b86423a93bffd ] The DAC and ADC 128x Oversampling Switches use bit 5 of R10 and R14. Table 66 of the WM8978 datasheet puts DACOSR128 and ADCOSR128 at bit 3 of those registers. In R14, bit 5 is inside HPFCUT[6:4], which the High Pass Cut Off control owns. So turning on ADC oversampling changes the high pass cut-off, and the oversampling bit cannot be set. In R10, bit 5 is reserved, so the DAC switch has no effect. Use bit 3 for both. Fixes: 823dba519122 ("ASoC: Fix broken bitfield definitions in WM8978") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20261008130953.2446692-6-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9b1a72628f1251c10d10474aab0e985750b15661 Author: HyeongJun An Date: Thu Oct 8 22:09:50 2026 +0900 ASoC: max98371: Fix the Speaker DHT Min Volume bits [ Upstream commit f7934340c56a84fc1b246ebf6b2e806d775f3b54 ] Register 0x31 holds two 4-bit fields. The datasheet puts SPK_GAIN_MIN at bits 7:4 and DHT_VROT_PNT at bits 3:0. The Speaker DHT Min Volume and Speaker DHT Rotation Volume controls both use bits 3:0. So setting the minimum speaker gain changes the DHT rotation point, and SPK_GAIN_MIN cannot be set. Move Speaker DHT Min Volume to bits 7:4. Fixes: ca2cd6bc6663 ("ASoC: Add max98371 codec driver") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20261008130953.2446692-5-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 384e00dd8908b7563eb4485072c056062909c8ec Author: HyeongJun An Date: Thu Oct 8 22:09:49 2026 +0900 ASoC: pcm3168a: Fix the DAC zero flag polarity bit [ Upstream commit b26edc925c1cfa0184cd270ed81d4833db045ce0 ] The DAC Zero Flag Polarity enum uses PCM3168A_DAC_ATSPDA_SHIFT, which is bit 6 of register 70. That bit is ATSPDA, the attenuation speed, which the DAC Volume Rate Multiplier enum already owns. The datasheet puts ZREV, the zero flag polarity, at bit 0. The header defines PCM3168A_DAC_ZREV_SHIFT for it, but nothing uses it. So changing the zero flag polarity changes the attenuation speed, and ZREV cannot be set. Use PCM3168A_DAC_ZREV_SHIFT. Fixes: a9b17a638af5 ("ASoC: pcm3168a: Add driver for pcm3168a codec") Link: https://www.ti.com/lit/ds/symlink/pcm3168a.pdf Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An Reviewed-by: Cezary Rojewski Link: https://patch.msgid.link/20261008130953.2446692-4-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit db3a7a70cc214a73f2e85434dada947f0bab51e0 Author: HyeongJun An Date: Thu Oct 8 22:09:48 2026 +0900 ASoC: cs42l52: Fix the NG Type Switch bit [ Upstream commit 8b08b98796d2da103f2432550c14a7c687e72080 ] The NG Type Switch enum selects between "Apply Specific" and "Apply All", which is the NGALL bit. The datasheet puts NGALL at bit 7 of the Noise Gate Control register. The enum uses bit 6, which is NG, the noise gate enable owned by the NG Enable Switch. cs42l52.h names it CS42L52_NG_ENABLE_SHIFT. cs42l56 has the same Noise Gate register and puts its NG All Switch at bit 7. So changing the noise gate type turns the noise gate on or off, and NGALL cannot be set. Use bit 7. Fixes: dfe0f98b8d2e ("ASoC: Add support for CS42L52 Codec") Link: https://statics.cirrus.com/pubs/proDatasheet/CS42L52_F2.pdf Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20261008130953.2446692-3-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 856ecf3c600af749fe69b9a37e4934ebcc3c2ec5 Author: HyeongJun An Date: Thu Oct 8 22:09:47 2026 +0900 ASoC: cs42l56: Put the Limiter Cushion control on the limiter register [ Upstream commit 203436d2aeb7093290459e344e1912a418a6ebfd ] The Limiter Cushion control writes bits 4:2 of the ALC Thresholds register. Those bits are ALCMIN, which the ALC MIN control owns. The datasheet puts CUSH at bits 4:2 of the Limit Thresholds Control register, next to LMAX, which the Limiter MAX control already uses. So setting the limiter cushion changes the ALC minimum threshold, and the cushion itself cannot be set. Use CS42L56_LIM_THRESHOLD_CTL. Fixes: 272b5edd3b8f ("ASoC: Add support for CS42L56 CODEC") Link: https://statics.cirrus.com/pubs/proDatasheet/CS42L56_F2.pdf Assisted-by: Claude:claude-opus-5-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20261008130953.2446692-2-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4528f8d38d893ea74b530850190b6bdfafa10fed Author: Avi Weiss Date: Sun Oct 11 06:54:59 2026 +0300 ASoC: stm32: spdifrx: fix synchronization state check [ Upstream commit 0936bbd35a247665c64886135835faa3c3f4f29f ] The interrupt handler uses a logical AND to check whether SPDIFRX was in the SYNC state before clearing errors. Since both SYNC (1) and ENABLE (3) are nonzero, this also treats ENABLE as SYNC (and any other non-zero value that might be added). The logical && basically just converts this to check for != 0. So errors occurring while SPDIFRX is enabled cause the driver to retry synch instead of disconnecting the PCM stream. Fix is to change the logical && to equality (==) and only retry when exactly in sync state. Fixes: 0c93c291321f2 ("ASoC: stm32: spdifrx: retry synchronization in sync state") Signed-off-by: Avi Weiss Reviewed-by: Olivier Moysan Link: https://patch.msgid.link/20261011035459.2289403-1-thnkslprpt@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d3239b8f4fc46dec5175049cf2ddea43fab23212 Author: Sergey Tiraspolsky Date: Sat Oct 10 03:37:53 2026 -0700 ASoC: Intel: avs: Reset the stream unless it is already prepared [ Upstream commit f6be9f558a83fe30a03bd3adae461c821a0cef8c ] Commit cfca1637bc2b ("ASoC: Intel: avs: Unprepare a stream when XRUN occurs") resets the HDA stream when ->prepare() is called in the XRUN state. User space does not always recover that way. PipeWire's ALSA backend recovers from an underrun with snd_pcm_drop(), snd_pcm_prepare() and a new start, so ->prepare() runs in the SETUP state, hdac_stream->prepared is still set and the reset is skipped. Every recovery attempt then fails the same way: spa.alsa: hw:avsmax98927,1p: snd_pcm_avail after recover: Broken pipe On a Google Pixelbook (Kaby Lake, max98927 speakers) this happens after an occasional underrun during normal playback and silences the speakers for one to four minutes, until the PCM is closed. It can be provoked by stopping PipeWire with SIGSTOP for 0.5 s during playback: in one run that single underrun led to 1297 failed recoveries over two minutes, until the sink was suspended. A plain alsa-lib program that recovers with snd_pcm_drop() and snd_pcm_prepare() hits the same loop, while snd_pcm_prepare() straight from XRUN recovers at once. Skip the reset only when the stream is already PREPARED, the repeated ->prepare() case the check exists for, and reset it otherwise. With this change both kinds of recovery succeed with a single restart. Fixes: cfca1637bc2b ("ASoC: Intel: avs: Unprepare a stream when XRUN occurs") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Sergey Tiraspolsky Acked-by: Cezary Rojewski Link: https://patch.msgid.link/20261010103753.16969-1-stiraspo@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a7c7d0ff876377fea7ae876a28d6df8d9349df57 Author: Allison Henderson Date: Sat Oct 3 09:34:08 2026 -0700 net/rds: don't let the rdma_cm destroy an id RDS still owns on route failure [ Upstream commit 98d446b7c013254a8a7b49720557676a3a851fde ] rds_rdma_cm_event_handler_cmn() hands the return value of rdma_resolve_route() straight back to the rdma_cm on RDMA_CM_EVENT_ADDR_RESOLVED. A synchronous failure there - -ENOMEM from the route work allocation, an SA query that cannot be set up, a RoCE route with no usable device - makes addr_handler() destroy the id the event was delivered on. That id is ic->i_cm_id, and nothing clears the pointer: the connection sits in RDS_CONN_CONNECTING with a freed id until its shutdown calls rdma_disconnect() and rdma_destroy_id() on it. The ROUTE_RESOLVED case already avoids this: rds_ib_cm_initiate_connect() forces a zero return while ic->i_cm_id == cm_id, as the comment there explains. Do the same here - drop the connection and return 0 - so the id stays RDS's to destroy from the shutdown, and the reconnect gets a fresh one. Fixes: 55b7ed0b582f ("RDS: Common RDMA transport code") Assisted-by: LLM Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20261003163408.250568-3-achender@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c2c5359ef2c33684fa3f3652fd761a483db8d1e7 Author: Michal Luczaj Date: Mon Oct 5 02:26:22 2026 +0200 vsock: treat TCP_CLOSING as once-established [ Upstream commit 4f6ac74fa594a918d41255c941256e1d51592d3b ] Handle the TCP_ESTABLISHED -> TCP_CLOSING transition on OP_RST, which can race with the connect loop. Immediately break and return 0 on ESTABLISHED/CLOSING. The return value of connect() should reflect what happened up to the point the connection was established or failed. Events that occur afterwards must not affect it. E.g. even if OP_RW has already set sk_err, connect() should still return 0, not ENOBUFS because of it. Adapt the inaccurate comment above signal_pending(). Resetting a socket that is still present in connected_table can lead to memory corruption. The reporter noted lost transports for in-flight skbs, and I have reproduced crashes caused by re-insertion into connected_table. list_add double add: new=, prev=, next=. kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:__list_add_valid_or_report+0x11f/0x130 Call Trace: vsock_insert_connected.cold+0xe/0x13 virtio_transport_recv_pkt+0x10e9/0x1460 vsock_loopback_work+0x305/0x480 process_one_work+0xe4c/0x1560 worker_thread+0x4f1/0xd60 kthread+0x36e/0x470 ret_from_fork+0x47b/0x6b0 ret_from_fork_asm+0x1a/0x30 This fix is supplementary to commit 002541ef650b ("vsock: Ignore signal/timeout on connect() if already established"). Details under Link. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reported-by: Hyunwoo Kim Link: https://lore.kernel.org/netdev/anzT1fREOSyHT99k@v4bel/ Signed-off-by: Michal Luczaj Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20261005-vsock-connect-reset-closing-v4-1-15d41cfda3ed@rbox.co Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit fb5fb74fb4fff8de3a7020117b4f947a16358b0c Author: Ming Yu Date: Wed Oct 7 17:20:50 2026 +0800 gpio: nct6694: Mark the GPIO controller as sleeping [ Upstream commit fcbc48dc650d2f58bfe19c4486830de0e9cad62e ] The GPIO callbacks take a mutex and issue USB transfers, so this GPIO chip must not be used in atomic context. Change the can_sleep switch in struct gpio_chip to true. Fixes: 611a995e8ae1 ("gpio: Add Nuvoton NCT6694 GPIO support") Signed-off-by: Ming Yu Link: https://patch.msgid.link/20261007092102.3768818-2-a0282524688@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 6b03e354526f6bad60ed3a7f08fec8b7d29d2f27 Author: Dave Stevenson Date: Fri Oct 2 10:36:43 2026 -0300 drm/vc4: hdmi: Move packet RAM enable to PM runtime [ Upstream commit 3f57b34485dc01e5a2db60a89a6ae5439a897e53 ] Audio can be triggered by the HPD handler and start up before video has been restored, calling vc4_hdmi_write_infoframe() for the audio infoframe. vc4_hdmi_write_infoframe() needs Packet RAM to be on to store the infoframe, however, if the video hasn't been enabled, vc4_hdmi_encoder_post_crtc_enable() hasn't been called and therefore, the Packet RAM can be disabled by the time vc4_hdmi_write_infoframe() executes, causing the following splat: [ 201.570266] ------------[ cut here ]------------ [ 201.570293] Packet RAM has to be on to store the packet. [ 201.570367] WARNING: drivers/gpu/drm/vc4/vc4_hdmi.c:683 at vc4_hdmi_write_infoframe+0x404/0x494 [vc4], CPU#0: wireplumber/1606 [...] [ 201.658650] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 201.758499] Call trace: [ 201.760967] vc4_hdmi_write_infoframe+0x404/0x494 [vc4] (P) [ 201.766607] vc4_hdmi_write_audio_infoframe+0x1c/0x28 [vc4] [ 201.772247] write_infoframe+0xbc/0x140 [drm_display_helper] [ 201.777975] drm_atomic_helper_connector_hdmi_update_audio_infoframe+0x80/0xdc [drm_display_helper] [ 201.787140] vc4_hdmi_audio_prepare+0x4ac/0x570 [vc4] [ 201.792252] drm_connector_hdmi_audio_prepare+0x24/0x30 [drm_display_helper] [ 201.799390] hdmi_codec_prepare+0x100/0x160 [snd_soc_hdmi_codec] [ 201.805471] snd_soc_pcm_dai_prepare+0xd4/0x100 [snd_soc_core] [ 201.811375] __soc_pcm_prepare+0x60/0x12c [snd_soc_core] [ 201.816752] soc_pcm_prepare+0x34/0x58 [snd_soc_core] [ 201.821863] snd_pcm_do_prepare+0x70/0x8c [snd_pcm] [ 201.826798] snd_pcm_action_nonatomic+0xe4/0x174 [snd_pcm] [ 201.832350] snd_pcm_prepare+0xc8/0xd8 [snd_pcm] [ 201.837021] snd_pcm_common_ioctl+0x458/0x614 [snd_pcm] [ 201.842308] snd_pcm_ioctl+0x30/0x48 [snd_pcm] [ 201.846802] __arm64_sys_ioctl+0x88/0xd8 [ 201.850769] invoke_syscall+0x48/0xf4 [ 201.854470] el0_svc_common+0x80/0xd8 [ 201.858171] do_el0_svc+0x1c/0x28 [ 201.861520] el0_svc+0x3c/0xb0 [ 201.864605] el0t_64_sync_handler+0x68/0xdc [ 201.868834] el0t_64_sync+0x198/0x19c [ 201.872536] ---[ end trace 0000000000000000 ]--- Considering that Packet RAM enable is essentially a power management configuration, move its enabling/disabling to the Runtime PM hooks. Note that post_crtc_disable() still stops all infoframes, but keeps Packet RAM enabled, leaving it to be disabled by runtime suspend. Link: https://github.com/raspberrypi/linux/issues/7069 Fixes: b47a72f30768 ("drm/vc4: hdmi: Switch to HDMI connector") Signed-off-by: Dave Stevenson Acked-by: Maxime Ripard Link: https://patch.msgid.link/20261002-vc4-hdmi-packet-ram-fix-v1-1-3d73148096c9@igalia.com Reviewed-by: Maíra Canal Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 47b725c17dcb249fb7435fccdb5412f4930dbd1d Author: Pablo Mazzini Date: Wed Oct 7 07:01:07 2026 +0100 pinctrl: sunxi: dt: do not accumulate npins across probe attempts [ Upstream commit c5895eadf287116434b7b01d67b92e8146f7ff61 ] init_pins_table() adds to npins in the driver's static descriptor, so after a probe deferral the count doubles and the next probe fails with "pin 0 already registered". Reset it first. Signed-off-by: Pablo Mazzini Fixes: f5e2cd34b12f ("pinctrl: sunxi: allow reading mux values from DT") Reviewed-by: Andre Przywara Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 9d0508bcf674348f062887e8360f4f518052109a Author: Adriel Santos Date: Fri Oct 2 13:09:58 2026 -0300 pinctrl: qcom: ipq5018: replace gcc_plltest with pwm2 on gpio12 [ Upstream commit 709ba1c547eaf37da36ded2ecf3ea4e304cdfa9a ] The pingroup table has gcc_plltest at function 5 of gpio12 and does not offer pwm2 on that pin, so the pinmux core rejects a request for pwm2 on gpio12 as an invalid group. On the hardware, function 5 of gpio12 carries the PWM2 output: the Xiaomi AX3000T v2 drives its blue status LED from PWM2 on gpio12. The vendor kernel shipped on that router (Linux 4.4, stock firmware 2.0.28) has pwm2 in this slot. Its pingroup table, as read from the firmware image, lists these functions for gpio12: gpio, blsp0_spi, blsp0_i2c, blsp1_uart0, _, pwm2, qdss_tracedata_a, _, _, _ and has pwm3 at function 4 of gpio13, matching commit c6c159fcdb4e ("pinctrl: qcom: ipq5018: add missing pwm3 function on gpio13"). Measured on the board: with gpio12 set to each of the 16 function values in turn, and PWM2 held at 0% and then at 100% duty, the pad level read back from GPIO_IN follows PWM2 only at function 5. There it does not follow PWM channels 0, 1 or 3, and the LED switches with PWM2. Functions 4 and 7, which the table leaves empty, do not carry PWM2. Put pwm2 in function 5 of gpio12 and list gpio12 in pwm2_groups. Drop gpio12 from gcc_plltest_groups: none of its functions is gcc_plltest any more, and selecting it would trigger the WARN_ON() in msm_pinmux_set_mux(). Fixes: 725d1c891658 ("pinctrl: qcom: Add IPQ5018 pinctrl driver") Assisted-by: LLM Signed-off-by: Adriel Santos Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20261002160958.908424-1-adriel@adriel.eu Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 2ac0256a28e15c4888fa394d1fe66cf7b1d58090 Author: Alexey Charkov Date: Thu Sep 10 18:32:58 2026 +0400 power: supply: core: prevent unregistering a power supply while a callback runs [ Upstream commit 5b4bd13e0552926648a46c2c9a12a24dfaee3715 ] Once a power supply is registered, its callbacks can immediately start firing from other contexts, such as external_power_changed() triggered by the TCPM stack. If a power supply is unregistered while the callback is still running, the driver data can already be freed when the callback tries to access it, leading to a use-after-free. This happens e.g. when the hardware bus carrying the power supply device malfunctions (e.g. I2C is hogged down by another malfunctioning device) immediately after the power supply is registered, and thus the core is still processing the callbacks which were queued up when the driver starts the removal, leading in some cases to a kernel crash, e.g.: [ 11.645942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000005 [ 11.646751] Mem abort info: [ 11.647006] ESR = 0x0000000096000004 [ 11.647338] EC = 0x25: DABT (current EL), IL = 32 bits [ 11.647806] SET = 0, FnV = 0 [ 11.648077] EA = 0, S1PTW = 0 [ 11.648356] FSC = 0x04: level 0 translation fault [ 11.648785] Data abort info: [ 11.649041] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 11.649524] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 11.649981] GCS = 0, Overlay = 0, DirtyBit = 0 [ 11.650390] [0000000000000005] user address but active_mm is swapper [ 11.650955] Internal error: Oops: 0000000096000004 [#1] SMP [ 11.651460] Modules linked in: [ 11.651742] CPU: 1 UID: 0 PID: 144 Comm: kworker/1:2 Not tainted 7.2.0-rc6-g62a9297af2cd #1 PREEMPT [ 11.652553] Hardware name: Flipper One rev. F0B1C2 (DT) [ 11.653024] Workqueue: events power_supply_changed_work [ 11.653511] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 11.654135] pc : __power_supply_is_supplied_by+0x18/0x100 [ 11.654624] lr : __power_supply_am_i_supplied+0x40/0xb8 [ 11.655098] sp : ffff80008192bb30 [ 11.655399] x29: ffff80008192bb30 x28: 0000000000000000 x27: 0000000000000000 [ 11.656049] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 11.656695] x23: ffff0000c19f4200 x22: ffffdb2232ba4ea8 x21: ffff80008192bc28 [ 11.657344] x20: ffff0000c1eef000 x19: ffff80008192bc18 x18: 00000000a0886e62 [ 11.657991] x17: 000000040044ffff x16: 04500072b5503510 x15: 0000000000000000 [ 11.658639] x14: 0000000000000000 x13: 0000000000000220 x12: 0000000000000000 [ 11.659286] x11: 0000000000000000 x10: ffff0000c1fdb2b0 x9 : ffffdb2232ba5590 [ 11.659934] x8 : 00000000e5b906e6 x7 : ffff0000c2502778 x6 : ffffdb22339793d0 [ 11.660581] x5 : ffff80008192bc18 x4 : ffff0000c19cbca0 x3 : 0000000000000000 [ 11.661228] x2 : ffff0000c1fdaf40 x1 : ffffffffffffffed x0 : ffff0000c1eef000 [ 11.661878] Call trace: [ 11.662103] __power_supply_is_supplied_by+0x18/0x100 (P) [ 11.662596] __power_supply_am_i_supplied+0x40/0xb8 [ 11.663040] psy_for_each_psy_cb+0x20/0x40 [ 11.663416] class_for_each_device+0x110/0x150 [ 11.663825] power_supply_am_i_supplied+0x68/0x100 [ 11.664262] bq257xx_external_power_changed+0x58/0x140 [ 11.664733] __power_supply_changed_work+0x60/0x80 [ 11.665170] psy_for_each_psy_cb+0x20/0x40 [ 11.665545] class_for_each_device+0x110/0x150 [ 11.665953] power_supply_changed_work+0x98/0x1b8 [ 11.666382] process_one_work+0x164/0x4c0 [ 11.666758] worker_thread+0x19c/0x320 [ 11.667104] kthread+0x138/0x150 [ 11.667408] ret_from_fork+0x10/0x20 [ 11.667744] Code: d503233f a9bd7bfd 910003fd a90153f3 (f9400c34) [ 11.668294] ---[ end trace 0000000000000000 ]--- Add a read-write semaphore between external_power_changed() and power_supply_unregister() to prevent the latter from returning (and thus the driver from freeing its data) while the callback is still running. Fixes: bc1540561c9e ("power_supply: Add API for safe access of power supply function attrs") Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260910-bq257xx-init-v3-1-4e219a1a04a5@flipper.net Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit dda0df37aabd84b1d230fe67b1b90777cf932e30 Author: Svyatoslav Ryhel Date: Sat Sep 26 17:29:05 2026 +0300 power: supply: generic-adc-battery: Fix temperature IIO channel conversion [ Upstream commit 6bca94e64255053ab2aa56f2588fda73d399b790 ] Temperature IIO channel data is provided in milli-degrees, while POWER_SUPPLY_PROP_TEMP is expected to be in deci-degrees. Adjust the existing logic to reflect this conversion properly. Fixes: 33088c0513818 ("power: supply: generic-adc-battery: add temperature support") Signed-off-by: Svyatoslav Ryhel Link: https://patch.msgid.link/20260926142905.206215-2-clamor95@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 06e3e6dc2688f6dabc331a405fb1dcb648834219 Author: Len Brown Date: Sun May 3 14:17:54 2026 -0400 tools/power turbostat: Fix add_counter issue if > 24 counters. [ Upstream commit 154b96dab83fd953b9b82c8bcfa041cd6a9d74d3 ] We allocate space for added counters ahead of time, and we arbitrarily chose 24 added counters of each type. If a future code flow hits this limit and continues, and then removes counters, we do a phantom increment and lose track of the number of added counters. Increment the count only if there is no error. Fixes: 388e9c8134be ("tools/power turbostat: Make extensible via the --add parameter") Assisted-by: Claude: Claude Sonnet 4.6 Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit f573d257aad5a1ae2c8a3edbf15b02a0e162678a Author: Len Brown Date: Sun May 3 15:23:25 2026 -0400 tools/power turbostat: Fix PMT error path fd handling [ Upstream commit 11741cc90f9176746b8595beab4fec8d736ebd18 ] It is possible to leak a file descriptor if a diretory open succeeds, but the scan fails. Close the fd on error. Also, on cleanup, check for NULL fd. Assisted-by: Claude: Claude Sonnet 4.6 Fixes: 4265a86582ea ("tools/power turbostat: Add PMT directory iterator helper") Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit b2af180dbc5f59a528e8584bcb629a346c2234fb Author: Len Brown Date: Thu Apr 30 21:40:36 2026 -0400 tools/power turbostat: Fix CWF PMT off-by-one [ Upstream commit 5e940dd96bef6ca03b3b1b4740351237e5ec17e3 ] Fix off-by-one error causing last CPU on CWF to never get a pmt counter allocated. Fixes: 5ce1e9bbb2a1 ("tools/power turbostat: Add CPU%c1e BIC for CWF") Assisted-by: GitHub Copilot (claude-sonnet-4.6) Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit e2c86984ccc0bb7fec6134183a23ed4b7cdb5483 Author: Len Brown Date: Thu Apr 30 21:28:19 2026 -0400 tools/power turbostat: Fix fd_perf leak on reset [ Upstream commit 767c64414c4c5fffd6cbc3a1cf1fb8138b28645b ] When turbostat notices a topology change, it frees perf file descriptors for each CPU to prepare to re-initialize. Fix an off-by-one error in that per-cpu loop that resulted in a file descriptor leak of the file for the highest numbered CPU in the system. Fixes: 67bab430f4e7 ("tools/power turbostat: Group SMI counter with APERF and MPERF") Assisted-by: GitHub Copilot (claude-sonnet-4.6) Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit e76e6284de2ba2c0da9aa21ab4e17a885186a4b2 Author: Gilberto Conde Date: Mon Sep 21 10:34:19 2026 +0100 pinctrl: qcom: ipq5018: add missing pwm3 function on gpio13 [ Upstream commit c6c159fcdb4e9a678eda0831f971e4a3a488ec47 ] GPIO13 supports the PWM3 function at mux select value 4, but the pingroup table leaves that slot empty and gpio13 is not listed in pwm3_groups. Selecting pwm3 on gpio13 is therefore rejected by the pinmux core: ipq5018-tlmm: invalid group "gpio13" for function "pwm3" The GL.iNet GL-X2000 drives its fan from PWM3 on this pin, and the vendor firmware muxes it with select value 4: gpio13 : out low func4 8mA no pull Add pwm3 to the fourth function slot of gpio13 and list gpio13 in pwm3_groups. With this the pin muxes as expected: pin 13 (GPIO_13): device 1941010.pwm function pwm3 group gpio13 Fixes: 725d1c891658 ("pinctrl: qcom: Add IPQ5018 pinctrl driver") Signed-off-by: Gilberto Conde Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260921093419.2870168-1-gilbertorconde@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 54e54a690bf13e0f0e0aa9ce25a2d9d8311db2b0 Author: Konrad Dybcio Date: Thu Sep 17 11:03:27 2026 +0200 pinctrl: qcom: qcs8300: Fix intr_target_width [ Upstream commit dcb5df182b37587d5ad6bb4388751bf5180957ac ] The default width of the interrupt target field doesn't match the actual register layout. Fix it. Fixes: 0c4cd2cc87c8 ("pinctrl: qcom: add the tlmm driver for QCS8300 platforms") Assisted-by: LLM Signed-off-by: Konrad Dybcio Reviewed-by: Shawn Guo Link: https://patch.msgid.link/20260917-topic-tlmm_intr_width_fixes-v1-3-3bc1d056aa6b@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit f47ce27af80b87cc684d5c12b65506af498ac7e5 Author: Michael Kelley Date: Mon Aug 31 20:45:14 2026 -0700 Drivers: hv: Don't reset VMBus connection state on error/exit paths [ Upstream commit ec31dc39e835ccde0930daccece8c492d28282fc ] In two places, current code forces vmbus_connection.conn_state to DISCONNECTED prior to calling vmbus_disconnect(). But vmbus_disconnect() calls vmbus_initiate_unload(), which unloads the VMBus connection only if the conn_state is CONNECTED. Consequently, the connection remains and the Hyper-V host might continue to send messages or post VMBus interrupts. The problem was introduced in commit 74347a99e73ae ("x86/Hyper-V: Unload vmbus channel in hv panic callback"), in that vmbus_initiate_unload() started checking the current connection state before doing the unload. This commit removed some occurrences where conn_state was forced to DISCONNECTED, but these two remained, apparently due to an oversight at the time. Fix this by not forcing conn_state to DISCONNECTED during VMBus exit, or if a failure occurs when establishing the connection in the first place. Whatever value conn_state has at the time is then read by vmbus_initiate_unload() to determine if there is a connection to be unloaded. Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hyperv/20260805205806.B5AC31F000E9@smtp.kernel.org/ Fixes: 74347a99e73ae ("x86/Hyper-V: Unload vmbus channel in hv panic callback") Signed-off-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 2b561786c9076a892ef8b8f416c9828bc87ed44f Author: Michael Kelley Date: Tue Sep 1 20:01:27 2026 -0700 x86/hyperv: Avoid using per-cpu output page in hv_apicid_to_vp_index() [ Upstream commit 7b74c117e2aac78e0f723e1c9c3644451c56b0d9 ] hv_apicid_to_vp_index() currently uses the per-cpu hypercall input and output pages. This function is called when running in VTL2 and when running in an SEV-SNP CoCo VM with no paravisor. In the former case, the output page is allocated, but in the latter case it is not, so the hypervisor stores the output VP index in memory that has not been allocated by the guest. Fix this by using the input page for both input and output. The hypercall has very small input and output, so sharing the same page for both is straightforward. An alternative fix is to allocate the per-cpu output page when running in an SEV-SNP CoCo guest, but this uses significantly more memory, particularly with larger vCPUs counts. Fixes: 86c48271e0d6 ("x86/hyperv: Fix APIC ID and VP index confusion in hv_snp_boot_ap()") Signed-off-by: Michael Kelley Reviewed-by: Tianyu Lan Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 7141331f2d245efc07175802a6bf76badec871ed Author: Waiman Long Date: Sun Aug 30 19:41:24 2026 -0400 Drivers: hv: Avoid infinite retry loop in init_vp_index() [ Upstream commit 32ea0a33e3a0fb7c10c601b43e1b2f6c06a3f5fd ] There is a retry loop in init_vp_index() where the CPUs from a certain node are stripped out if they have already been in the allocated cpumask or not in HK_TYPE_MANAGED_IRQ housekeeping cpumask. If there is no CPU left, the allocated cpumask is ignored and the process is retried again. However, if the HK_TYPE_MANAGED_IRQ housekeeping cpumask turns out not to contain any CPU in that particular node, that will become an infinite retry loop. This particular problem was reported by sashiko [1]. This should rarely happen, but we still need to guard against this. Fix this infinite loop problem by also skipping NUMA node that has no housekeeping CPU in the inner while loop of init_vp_index(). Also update the early abort check to check for the absence of online housekeeping CPUs instead of just the emptiness of the cpumask. As the outer for loop will only be reached if the housekeeping cpumask has at least one online CPU, a NUMA node with housekeeping CPUs will eventually be found. Link: https://sashiko.dev/#/message/20260422030903.E1BFCC2BCB0%40smtp.kernel.org [1] Fixes: 6640b5df1a38 ("Drivers: hv: vmbus: Don't assign VMbus channel interrupts to isolated CPUs") Signed-off-by: Waiman Long Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit c3e5854b2e8b6ef64cccb5f37dac6bd8155bd86b Author: Xueqin Luo Date: Tue Sep 1 15:29:54 2026 +0800 power: supply: ds2780: Fix ds2780_get_capacity() returning raw value [ Upstream commit a58cbc8b36ec0cd00d2ba3de7d003de818a27523 ] ds2780_get_capacity() returns the raw register value instead of 0 on success. The capacity is already stored in *capacity, so the function should return 0 to indicate success. Fixes: 275ac74629c4 ("w1: add Maxim/Dallas DS2780 Stand-Alone Fuel Gauge IC support") Signed-off-by: Xueqin Luo Link: https://patch.msgid.link/20260901072954.1953121-1-luoxueqin@kylinos.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 7de3a5a49410a3a50f6c06e78fdd1b75c62779e0 Author: Karl Mehltretter Date: Wed Sep 9 08:46:23 2026 +0200 power: supply: Fix maintenance charge table kernel-doc [ Upstream commit 45d4af4e80a25881b6b75e8e34872c555c43a41d ] struct power_supply_maintenance_charge_table contains charge_safety_timer_minutes, but its kernel-doc describes safety_timer_minutes. This leaves the real member undescribed and adds a nonexistent member to the generated documentation. Use the member's actual name. Fixes: d72ce7d32478 ("power: supply: ab8500: Standardize maintenance charging") Assisted-by: LLM Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260909064623.90737-1-kmehltretter@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit ea9c08c33d57ccb52924f9ca1d325fd1d6899385 Author: David Oberhollenzer Date: Thu Jul 16 13:39:47 2026 +0200 ARM: dts: ti/omap: dra7: fix PCIe PHY clock divider definition [ Upstream commit 2fabd2f406d0cf787be47b3bbeea99b30004033d ] Commit d0bdd8bb7f35 ("ARM: dts: ti/omap: dra7: fix redundant clock divider definition") removes the clock divider definition from optfclk_pciephy_div, reasoning that the table is redundant, as it contains the values 1 and 2, while also setting ti,max-div to 2 while ti,min-div is implicitly initialized to 1. What that commit missed was the fact that the values in the table are in reverse order, i.e. first 2, then 1. As is clearly described in the documentation, the ordering is signifficant, the actual values for the register setting are derived from the index. If no table is specified, the driver assumes that the register value is divider - 1 (see also `_get_val` in `drivers/clk/ti/divider.c`). What is in fact redundant is the value of ti,max-div that is derived from the table if none is specified. To satisfy device tree semantic linters, it is removed instead. Fixes: d0bdd8bb7f35 ("ARM: dts: ti/omap: dra7: fix redundant clock divider definition") Signed-off-by: David Oberhollenzer Link: https://patch.msgid.link/20260716113947.92513-1-david.oberhollenzer@sigma-star.at Signed-off-by: Kevin Hilman (TI) Signed-off-by: Sasha Levin commit 0992d03e55e5a9cfb9c5c97696765f51ddb2eb8f Author: Jinhui Guo Date: Tue Aug 4 20:19:10 2026 +0800 soc/tegra: fuse: Add missing newline to APBMISC error message [ Upstream commit 2f4a0fb66d313f03832f061bc3ec25b33c8198c9 ] The error message printed by tegra_acpi_init_apbmisc() when failing to get APBMISC memory resources is missing a trailing newline. This can cause the message to be merged with the following kernel log line, making the log harder to read. Add the missing newline to keep the error output properly formatted. Fixes: 7b0c505eb341 ("soc/tegra: fuse: Add tegra_acpi_init_apbmisc()") Signed-off-by: Jinhui Guo Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 07fa8baa78d6480f36b84efea303059183c0df04 Author: Federico Parola Date: Thu Oct 15 14:45:29 2026 +0000 kho: free phys_bits bitmaps using free_page() in __kho_abort() Commit fa759cd75bce ("kho: allocate metadata directly from the buddy allocator") switched the allocation of preserved memory bitmaps to get_zeroed_page(), but __kho_abort() still releases them with kfree(). kfree() on a buddy page that is not a large kmalloc allocation hits the WARN_ON_ONCE() in free_large_kmalloc() and returns without freeing it, so every aborted finalization leaks all bitmap pages. Free the bitmaps with free_page() instead. This is a stable-only patch. Upstream fixed it as a side effect of commit 99cd2ffac697 ("kho: don't unpreserve memory during abort"), which removes the tracking teardown from __kho_abort() altogether. That change builds on commit 36f8f7ef7fd2 ("kho: add interfaces to unpreserve folios, page ranges, and vmalloc") and commit 70f9133096c8 ("kho: drop notifiers"). In 6.18.y, KHO users still preserve memory from the KEXEC_KHO_FINALIZE notifier and have no interface to unpreserve it, so the teardown on abort is the only way their preservations get dropped. Backporting that commit would make preservations outlive every abort, so keep the teardown and fix only the mismatched free. Fixes: fa759cd75bce ("kho: allocate metadata directly from the buddy allocator") Signed-off-by: Federico Parola Signed-off-by: Sasha Levin commit 96d2abaa2e3284fb5939485e9e0372c5d40bd70d Author: Abel Vesa Date: Mon Sep 28 16:58:47 2026 +0300 i2c: qcom-geni: Restore the source-clock selection policy [ Upstream commit 8cb5c17be3a2fadc41075d04ce1c24c831546aaf ] Currently, the source clock lookup prefers 32 MHz whenever that rate is available, regardless of the rate configured by the platform. Before the switch to looking up the clock index, the driver used the 32 MHz timing table only if the current source clock rate was 32 MHz, and the 19.2 MHz table otherwise. On X1E80100 CRD, this results in switching the source clock from 19.2 MHz to 32 MHz, which causes intermittent failures when probing the I2C HID keyboard. These range from corrupted HID descriptors to failed resets and transfer timeouts, which also affect the touchpad on the same bus. Restore the original selection policy: use 32 MHz if already selected, otherwise request 19.2 MHz. Look up the index for the selected rate and keep the check that rejects higher-frequency multiples. This retains the dynamic clock index lookup without preferring 32 MHz on platforms that previously used 19.2 MHz. Report the requested rate if the lookup fails. Fixes: cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in SE_GENI_CLK_SEL") Assisted-by: LLM Signed-off-by: Abel Vesa Tested-by: Hasty Heat Tested-by: Mitchell Augustin Reviewed-by: Mitchell Augustin Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260928-b4-i2c-qcom-geni-preserve-source-clock-v1-1-9aded7552a76@oss.qualcomm.com Signed-off-by: Sasha Levin commit cd3c05651d04b4e1d76112396a88d7c5a9f3bf02 Author: Bernard Pidoux Date: Fri Sep 18 15:38:21 2026 +0200 rose: purge rose_neigh->queue on final teardown rose_transmit_link() queues an outgoing frame on rose_neigh->queue instead of sending it immediately whenever the neighbour isn't "restarted" yet (link not up) -- notably the CLEAR_REQUEST built by rose_write_internal() when a socket is released (e.g. its owning process is killed) while the underlying AX.25 link to that neighbour is still coming up. rose_neigh_put() already tears down both timers and drops the ax25/ digipeat references before freeing the neighbour, but never empties this queue. kfree(rose_neigh) only frees the rose_neigh struct itself (the sk_buff_head embedded in it is just three next/prev/len words), not the skbs still linked into it -- every frame still queued here at that point leaks for good. rose_remove_neigh() (rose_route.c) already purges this same queue, but it is only one of about two dozen call sites that can drop the last reference and trigger the real kfree() in rose_neigh_put() -- every socket releasing its own rose->neighbour reference (af_rose.c, rose_in.c, rose_timer.c) can just as well be the one that does. Doing the purge once, centrally, in rose_neigh_put() itself covers all of them regardless of which call site happens to be last, rather than relying on whichever caller happened to remember it. Matches a leak pattern observed and documented back in May 2026 (mailbbs killed -> rose_release() -> rose_write_internal() -> rose_transmit_link() queues the CLEAR_REQUEST -> skb never freed), never root-caused until now. Deployed and running since 2026-09-13/15 on three independent nodes (f6bvp-12, f6bvp-8, f6bvp-10 -- three different kernel bases, 6.12.94/6.18.46/6.18.34), no regression observed. Signed-off-by: Bernard Pidoux (cherry picked from commit e59e4523182e4f58f4f29b5e4bce44c1ef152d70) Signed-off-by: Sasha Levin commit 6b450cf6dd4192888625eb0e2d4c4e78a84fa853 Author: Bernard Pidoux Date: Sun Sep 13 11:47:43 2026 +0200 ax25: bound REJ-driven fast retransmits with the existing N2 counter REJ deliberately bypasses the T1/N2 backoff to trigger an immediate go-back-N retransmit -- that is the whole point of REJ, fast recovery from a single lost or out-of-order frame. But unlike every other recovery path in this same state machine (T1 timeout, state 4 enquiry/DM, state 1/2 SABM retries), the REJ case in ax25_std_state3_machine() never touches n2count, so it has no bound. If something keeps corrupting or reordering every retransmitted burst -- lossy RF, or packet reordering over a UDP-based transport such as axudp -- each attempt draws an immediate fresh REJ and the link retransmits at wire/CPU speed indefinitely, a "machine-gun" storm that never reaches the N2 give-up already relied on everywhere else in this file. Reported independently twice: Chris Maness (KQ6UP) on a plain AX.25 link with no ROSE involved at all, and observed live on a ROSE/FPAC White Pages link (f6bvp-8<->f6bvp-10, same LAN, so plain network reordering over the Internet is not the trigger there -- likely lossy retransmission of the same PDU) reaching ~5900 pkt/s. Both hit the same code path since ax25_std_in.c is shared regardless of what rides on top of AX.25. Count consecutive REJ-driven fast retransmits the same way a T1 timeout already does in this state, and once N2 of them have failed to get an in-sequence frame through, fall back to the paced state 4 enquiry -- which will genuinely disconnect after N2 further tries if the link stays bad, exactly like every other recovery path already does. A single frame accepted in sequence resets the counter, so an isolated REJ during otherwise healthy traffic never gets close to N2. Deployed on three Raspberry Pi nodes (f6bvp-12, f6bvp-8, f6bvp-10) since 2026-09-13, running live production AX.25/ROSE/NET-ROM traffic since, with no recurrence of the machine-gun storm and no other AX.25 regression observed. Signed-off-by: Bernard Pidoux (cherry picked from commit a3aa611e37d4345ebcc98c847dedaf4bcf23c7ee) Signed-off-by: Sasha Levin commit c7bdc88b27cc6be31be5adc22a9c9b4fcdf64c76 Author: Harin Lee Date: Wed Apr 1 18:01:58 2026 +0900 ALSA: ctxfi: Use correct DAIO type for da_desc [ Upstream commit 07b116b44e52d78af40c2d39a8e1e34ef1283d0d ] Skip the unused DAIO type per model (SPDIFIO on CTSB073X, SPDIFI_BAY on all others) and use the correct DAIO type directly as da_desc type. This removes the mismatch and misleading between the actual DAIO resource and the da_desc type like SPDIFI_BAY (formerly SPDIFI1). Update related functions accordingly, and drop the unreachable SPDIFI_BAY case from the hw20k2 daio_device_index(). Signed-off-by: Harin Lee Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260401090159.2404387-3-me@harin.net Signed-off-by: Sasha Levin commit fb5e2dd6565a9af5b4d5c3f53717d1a2a59cf1db Author: Harin Lee Date: Wed Apr 1 18:01:57 2026 +0900 ALSA: ctxfi: Rename SPDIFI1 to SPDIFI_BAY [ Upstream commit c6cd83cceec5f2a1e2dd319d98640b1f0007d668 ] Rename the SPDIFI1 enum value to SPDIFI_BAY to better reflect its purpose as the S/PDIF input on the internal drive bay, as opposed to the S/PDIF input via Flexijack or optical (SPDIFIO; not SPDIFI-zero). Signed-off-by: Harin Lee Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260401090159.2404387-2-me@harin.net Signed-off-by: Sasha Levin commit 7fca3600e79e9f8bac1ebc10af9ff20a35d6cccb Author: Takashi Iwai Date: Tue Mar 31 10:12:17 2026 +0200 ALSA: ctxfi: Don't enumerate SPDIF1 at DAIO initialization [ Upstream commit 75dc1980cf48826287e43dc7a49e310c6691f97e ] The recent refactoring of xfi driver changed the assignment of atc->daios[] at atc_get_resources(); now it loops over all enum DAIOTYP entries while it looped formerly only a part of them. The problem is that the last entry, SPDIF1, is a special type that is used only for hw20k1 CTSB073X model (as a replacement of SPDIFIO), and there is no corresponding definition for hw20k2. Due to the lack of the info, it caused a kernel crash on hw20k2, which was already worked around by the commit b045ab3dff97 ("ALSA: ctxfi: Fix missing SPDIFI1 index handling"). This patch addresses the root cause of the regression above properly, simply by skipping the incorrect SPDIF1 type in the parser loop. For making the change clearer, the code is slightly arranged, too. Fixes: a2dbaeb5c61e ("ALSA: ctxfi: Refactor resource alloc for sparse mappings") Cc: Link: https://bugzilla.suse.com/show_bug.cgi?id=1259925 Link: https://patch.msgid.link/20260331081227.216134-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b48ebe399b4e72baa323462580fdd83ebda561e1 Author: Vadim Nikitushkin Date: Tue Sep 22 18:33:34 2026 +0300 drm/ttm: fix swapped-out resources never leaving their bulk_move range commit 3db7d7d583419f7b1f2e141e36418802dbb25cf8 upstream. ttm_tt_swapout() returns the number of pages swapped out on success and a negative error code on failure; for a populated ttm it never returns zero. Commit b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") moved the bulk_move bookkeeping in ttm_bo_swapout_cb() under "if (!ret)", so the ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail() pair is now skipped on every successful swapout. The equivalent change for the shrinker in commit 1d59f36e95f7 ("drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure") tests "lret > 0", which is what was intended here as well. Before b2ed01e7ad3d the resource was taken off the bulk_move before the swapout; since then a swapped-out resource stays inside its BO's bulk_move range (and on the manager LRU) although it is unevictable. When it is later freed or the BO leaves the bulk_move (ttm_resource_free(), ttm_bo_set_bulk_move() via amdgpu_vm_bo_del()), ttm_resource_del_bulk_move() skips it because of its !ttm_resource_unevictable() guard, so a range endpoint in pos->first / pos->last is left pointing at freed memory. The next ttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() on that cursor is a use-after-free, seen as the resv WARN in ttm_lru_bulk_move_add(), "list_del corruption" in ttm_resource_move_to_lru_tail() or a NULL dereference in ttm_resource_manager_next() -- minutes to hours after a hibernation, or at process exit / reboot following one. Samuel Ainsworth's analysis of drm/amd issue 5387 (see Link) identified the dangling cursor; the missing removal at swapout time is the reason it dangles. Testing the condition for success restores the removal. On an AMD Phoenix APU (ASUS UM3406GA, gfx1103) running suspend-then-hibernate on a 7.0.y stable kernel carrying the backport (Ubuntu 7.0.0-31) the bug crashed 5 of 18 hibernation cycles; a function profile of one hibernation showed 336 ttm_tt_swapout() calls and zero ttm_resource_del_bulk_move_unevictable() calls. With this change the removal happens for every swapped-out resource and 12 further cycles were clean. Fixes: b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") Cc: stable@vger.kernel.org # v7.1+ Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5387 Link: https://lore.kernel.org/dri-devel/CAHYiNPa6aVacJoLOje-qZ1GyYx-9p0tN4NuP8D_eSL+UJeevXw@mail.gmail.com/ Signed-off-by: Vadim Nikitushkin Reviewed-by: Thomas Hellström Reviewed-by: Christian König Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260909205028.13799-1-bub4z0r@gmail.com [ Squashed with commit fcfe64715b425262af1b36f498f9197f3537ceed ("drm/ttm: apply the swapout bulk_move fix to the intended condition"): upstream 3db7d7d58341 was applied to the "if (ret)" after ttm_resource_try_charge() in ttm_bo_alloc_at_place() instead of the "if (!ret)" after ttm_tt_swapout() in ttm_bo_swapout_cb(), and fcfe64715b42 restored the former and changed the latter. 7.2.y has no ttm_resource_try_charge() (dmem cgroup charging is 7.3 material), so neither commit applies on its own; the net effect of the two is the single hunk below, which is the change the changelog describes. ] Signed-off-by: Sasha Levin