commit 2926d88bb7fc4608fd942453d929c39e4e5ec006 Author: Greg Kroah-Hartman Date: Wed Oct 21 10:32:29 2026 +0200 Linux 6.18.58 Link: https://lore.kernel.org/r/20261017155104.830766652@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Wentao Guan Tested-by: Miguel Ojeda Tested-by: SJ Park Tested-by: Sean Lyon Tested-by: Ron Economos Tested-by: Barry K. Nathan Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit 2566780c684c9c21241d409d790087c73070f312 Author: Jinu Kim Date: Fri Aug 7 20:28:18 2026 +0900 KVM: x86: Use active memslots for the per-vCPU MMIO cache commit b3e6212dea2e4328a841ceb37f377583176dc735 upstream. KVM tags the per-vCPU MMIO cache with a memslot generation so that a memslot update invalidates cached MMIO information. Both the fill and validation paths use kvm_memslots(), which unconditionally selects address space 0, even when the vCPU is running in SMM and using address space 1. Commit 56f17dd3fbc4 ("kvm: x86: fix stale mmio cache bug") added the memslot generation to the cache key so that a memslot update could not leave a stale entry valid. When commit 699023e23965 ("KVM: x86: add SMM to the MMU role, support SMRAM address space") added the SMM address space, these helpers were not converted to use the active memslots. Consequently, an update to the SMM memslots can leave an entry from the old SMM address space apparently valid after the vCPU returns to the normal address space. A guest can then cause an access to valid RAM at the same GFN to be returned to userspace as KVM_EXIT_MMIO. Completing that exit through the VMM's RAM address space writes the backing page without going through KVM's write-tracking path. If the page backs a nested EPT table, KVM can continue using shadow translations derived from the old contents. The WARN_ON_ONCE() in kvm_mmu_write_protect_fault() catches this invalid cache and memslot combination. Use the vCPU's active memslots when caching and validating the entry. Memslot generations are unique across address spaces, so the generation also distinguishes the normal and SMM views. This matches the MMIO SPTE cache, which already uses kvm_vcpu_memslots(). On an unpatched current-mainline kernel, a regression test that fills the cache in SMM and updates only the SMM memslots fails the intended RAM write and triggers the kvm_mmu_write_protect_fault() warning. With this change, the same test completes the RAM write without a warning. The x86/smm_test, set_memory_region_test, and memslot_modification_stress_test selftests also pass. Fixes: 699023e23965 ("KVM: x86: add SMM to the MMU role, support SMRAM address space") Cc: stable@vger.kernel.org Signed-off-by: Jinu Kim Link: https://patch.msgid.link/20260807112818.958190-1-kimjw04271234@gmail.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 517404e157395d0f8da125ca956c566895dfcd06 Author: Ilan Dudnik Date: Fri Aug 7 12:03:31 2026 +0300 ksmbd: fix heap out-of-bounds write in krb5_authenticate() commit 23a0be6a84a38ac169eeab49017934e8e27c65f0 upstream. In krb5_authenticate(), out_len is calculated to determine available headroom in response_buf for the incoming Kerberos AP-REP token. However, when SMB2_SESSION_SETUP is processed as a non-first element of a compounded SMB2 request, the calculation omits work->next_smb2_rsp_hdr_off. This causes out_len to overstate remaining buffer headroom by the cumulative size of prior responses in the compound chain. Consequently, the length check in ksmbd_krb5_authenticate() (*out_len <= resp->spnego_blob_len) passes erroneously, allowing memcpy() to write the AP-REP blob past the end of response_buf into adjacent kernel heap memory. Fix this by subtracting work->next_smb2_rsp_hdr_off when computing out_len, ensuring it accurately reflects physical remaining buffer space. Signed-off-by: Ilan Dudnik Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 88c7c3aa8d0ffcb33ef81e4e9e0b40b594a49f9a Author: Toke Høiland-Jørgensen Date: Fri Oct 16 10:50:11 2026 +0200 wifi: atk9k: Revert "wifi: ath9k: reject short WMI command responses" [ Upstream commit 90201351a862182bdabfc1ad1c97b1e1b6ed5931 ] This reverts commit 93ce8ea70451e800601bc9444aa33043de15d67b. Mehmet reported that the offending commit breaks his AR9271 USB adapter which uses zero-length replies to commands that don't return a value. Revert the whole thing to restore the functionality. Cc: stable@vger.kernel.org # the offending commit is in 6.12.113 Reported-by: Mehmet Fide Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5c0940abe76c99484ed6d70a809fc653f59f0991 Author: Mattia Meleleo Date: Wed Jul 8 18:55:00 2026 +0200 bpf, sockmap: Account for receive queue in FIONREAD without a verdict program [ Upstream commit 04af4efde58a4a4ef4feab7360c46af9ec0b83a0 ] tcp_bpf_ioctl() answers SIOCINQ from psock->msg_tot_len, which only counts bytes in ingress_msg. Without a stream/skb verdict program nothing is diverted there: data stays in sk_receive_queue, so FIONREAD returns 0 even though read() returns data. Add tcp_inq() to the reported value when the psock has no verdict program. The two queues are disjoint, so bytes redirected into ingress_msg from other sockets stay correctly accounted through msg_tot_len. Remove unused sk_psock_msg_inq(). Fixes: 929e30f93125 ("bpf, sockmap: Fix FIONREAD for sockmap") Signed-off-by: Mattia Meleleo Reviewed-by: Jiayuan Chen Reviewed-by: Emil Tsalapatis Reviewed-by: John Fastabend Link: https://lore.kernel.org/bpf/20260708-fionread-no-verdict-v3-1-b4ee31b3af53@coralogix.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 8b7748e9904f80fb597f4a00aa1d2322889e6f5a Author: Pratyush Yadav Date: Thu Oct 15 14:45:28 2026 +0000 kho: free chunks using free_page() instead of kfree() [ Upstream commit b15515155af735a86e5bcd67ed739162f0de27f5 ] Before commit fa759cd75bce5 ("kho: allocate metadata directly from the buddy allocator"), the chunks were allocated from the slab allocator using kzalloc(). Those were rightly freed using kfree(). When the commit switched to using the buddy allocator directly, it missed updating kho_mem_ser_free() to use free_page() instead of kfree(). Link: https://lkml.kernel.org/r/20251118182218.63044-1-pratyush@kernel.org Fixes: fa759cd75bce5 ("kho: allocate metadata directly from the buddy allocator") Signed-off-by: Pratyush Yadav Reviewed-by: Pasha Tatashin Reviewed-by: Mike Rapoport (Microsoft) Cc: Alexander Graf Cc: David Matlack Signed-off-by: Andrew Morton Signed-off-by: Federico Parola Signed-off-by: Sasha Levin commit a6d84b420a84843d837f729c298d98d8b070d314 Author: Jens Axboe Date: Thu Oct 8 13:07:38 2026 -0600 io_uring/kbuf: don't charge provided buffer rings to RLIMIT_MEMLOCK commit cde56daf4b93f474dc256dbcc5205035223ae6f5 upstream. Just like with the SQ and CQ rings, the provided buffer rings were also not charged against the memlock limit prior to the below mentioned commit. Restore that behavior. Fixes: ef62de3c4ad5 ("io_uring/kbuf: use region api for pbuf rings") Reported-by: Hengyu Liang Cc: stable@vger.kernel.org Tested-by: Hengyu Liang [axboe: 6.18 uses io_create_region_mmap_safe() for the pbuf ring] Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e46794d1936caadd3316ccfca194165af615191a Author: Hengyu Liang Date: Tue Oct 6 08:57:32 2026 -0400 io_uring: do not charge the SQ/CQ rings to RLIMIT_MEMLOCK commit b59cabf9b4acb65f3f9968087ca0e18010d85076 upstream. Commit 8078486e1d53 ("io_uring: use region api for SQ") and commit 81a4058e0cd0 ("io_uring: use region api for CQ") made io_uring_setup() allocate the rings with io_create_region(). However, io_create_region() charges the memory to RLIMIT_MEMLOCK, and the rings had been exempt from that limit since commit 26bfa89e25f4 ("io_uring: place ring SQ/CQ arrays under memcg memory limits"). As of now, a user without CAP_IPC_LOCK gets ENOMEM from io_uring_setup() when their rings exceed the limit, which is 8 MiB by default. PostgreSQL developers have already hit this in their io_uring tests [1]. The issue can be reproduced with a simple liburing program, run as an unprivileged user: #include #include int main(void) { static struct io_uring ring[64]; int i; for (i = 0; i < 64; i++) if (io_uring_queue_init(4096, &ring[i], 0) < 0) break; printf("%d rings\n", i); return 0; } Before those commits (v6.13), it prints "64 rings". After those commits (v6.14), it prints "21 rings". This patch makes io_create_region() take the user to charge, and passes no user for the SQ/CQ rings. Link: https://www.postgresql.org/message-id/flat/667f7dcf-404b-4898-a426-57ca6e0617f6@gmail.com [1] Fixes: 8078486e1d53 ("io_uring: use region api for SQ") Fixes: 81a4058e0cd0 ("io_uring: use region api for CQ") Cc: stable@vger.kernel.org Signed-off-by: Hengyu Liang Link: https://lore.kernel.org/io-uring/20261006125732.3425762-1-hengyul@cs.unc.edu/ [axboe: 6.18 still has the ctx based region API. Convert io_create_region() and io_free_region() to take the user_struct, and add a user argument to io_create_region_mmap_safe()] Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 314b72d5e82736d8ef5427db857363b4f2e33c87 Author: Bernard Pidoux Date: Sat Sep 26 12:38:40 2026 +0200 rose: hold a reference on incoming sockets queued for accept() commit 6b0223a4795f5db52dee038a7a29e9906122b0f7 upstream. rose_rx_call_request() creates the socket for an incoming call and queues the call's skb on the listening socket with skb->sk pointing at it, without taking a reference. If the caller clears the call before it is accepted, rose_disconnect() leaves that socket in STATE_0 with SOCK_DEAD set, and since commit "rose: release netdev ref and destroy orphaned incoming sockets" rose_heartbeat_expiry() reaps such orphaned sockets and frees them. The skb stays on the listener's queue, so: - closing the listener makes rose_destroy_socket() walk its queue and set flags and restart the heartbeat on the freed socket; - accept() can hand the freed socket to user space. On a live node running a KASAN kernel, stopping the FPAC daemons shortly after a local (loopback) call had been set up and dropped gave: BUG: KASAN: slab-use-after-free in rose_destroy_socket+0x24a/0x570 [rose] Write of size 8 ... by task fpacwpd rose_destroy_socket rose_release Allocated by task 0: ... rose_rx_call_request <- rose_loopback_timer Freed by task ...: ... sk_free <- rose_heartbeat_expiry refcount_t: addition on 0; use-after-free. rose_start_heartbeat <- rose_destroy_socket <- rose_release followed a few seconds later by a page fault in the re-armed heartbeat and a kernel panic. Make the listener's queue own a reference on each pending socket, taken when the call is queued and dropped by rose_accept() or by the listener's rose_destroy_socket() once the skb is off the queue. Have the heartbeat set SOCK_DESTROY under the socket lock before reaping a dead socket, as the other reaping paths already do, and make both consumers check it under the child's lock: rose_accept() skips a reaped socket and waits for the next call, and rose_destroy_socket() no longer re-arms the heartbeat of a socket that is gone. Fixes: df12be096302 ("rose: release netdev ref and destroy orphaned incoming sockets") Signed-off-by: Bernard Pidoux Signed-off-by: Sasha Levin commit 30ec3025b771511625375fb3fb959aea3b45fb0d Author: Johan Hovold Date: Mon Jun 22 17:26:09 2026 +0200 USB: iowarrior: fix use-after-free on disconnect race [ Upstream commit c602254ba4c10f60a73cd99d147874f86a3f485c ] mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic") [2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked") Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.") Cc: stable Reported-by: Yue Sun Link: https://lore.kernel.org/r/20260618080204.38322-1-samsun1006219@gmail.com Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260622152612.116422-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e8ed9a1dfc74fc85b3a203ab6317110d537981c8 Author: Oliver Neukum Date: Thu Mar 12 10:45:27 2026 +0100 usb: iowarrior: remove inherent race with minor number [ Upstream commit 56dd29088c9d9510c48a8ebad2465248fde36551 ] The driver saves the minor number it gets upon registration in its descriptor for debugging purposes. However, there is inevitably a window between registration and saving the correct minor in a descriptor. During this window the debugging output will be wrong. As wrong debug output is worse than no debug output, just remove it. Signed-off-by: Oliver Neukum Link: https://patch.msgid.link/20260312094619.1590556-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: c602254ba4c1 ("USB: iowarrior: fix use-after-free on disconnect race") Signed-off-by: Sasha Levin commit c24d2e190b955baf3a95e05d34b192f61bd201b3 Author: Stephen Smalley Date: Tue May 5 10:06:38 2026 -0400 selinux: allow multiple opens of /sys/fs/selinux/policy [ Upstream commit a02cd6805562305f936e807da83e253b719dd965 ] Currently there can only be a single open of /sys/fs/selinux/policy at any time. This allows any process to block any other process from reading the kernel policy. The original motivation seems to have been a mix of preventing an inconsistent view of the policy size and preventing userspace from allocating kernel memory without bound, but this is arguably equally bad. Eliminate the policy_opened flag and shrink the critical section that the policy mutex is held. While we are making changes here, drop a couple of extraneous BUG_ONs. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/selinux/20100726193414.19538.64028.stgit@paris.rdu.redhat.com/ Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 93a7f297362deac614ce3dbbba73ff2ba31aaca3 Author: SJ Park Date: Fri Mar 27 16:33:15 2026 -0700 mm/damon/core: fix damos_walk() vs kdamond_fn() exit race [ Upstream commit 33c3f6c2b48cd84b441dba1ee3e62290e53930f4 ] When kdamond_fn() main loop is finished, the function cancels remaining damos_walk() request and unset the damon_ctx->kdamond so that API callers and API functions themselves can show the context is terminated. damos_walk() adds the caller's request to the queue first. After that, it shows if the kdamond of the damon_ctx is still running (damon_ctx->kdamond is set). Only if the kdamond is running, damos_walk() starts waiting for the kdamond's handling of the newly added request. The damos_walk() requests registration and damon_ctx->kdamond unset are protected by different mutexes, though. Hence, damos_walk() could race with damon_ctx->kdamond unset, and result in deadlocks. For example, let's suppose kdamond successfully finished the damow_walk() request cancelling. Right after that, damos_walk() is called for the context. It registers the new request, and shows the context is still running, because damon_ctx->kdamond unset is not yet done. Hence the damos_walk() caller starts waiting for the handling of the request. However, the kdamond is already on the termination steps, so it never handles the new request. As a result, the damos_walk() caller thread infinitely waits. Fix this by introducing another damon_ctx field, namely walk_control_obsolete. It is protected by the damon_ctx->walk_control_lock, which protects damos_walk() request registration. Initialize (unset) it in kdamond_fn() before letting damon_start() returns and set it just before the cancelling of the remaining damos_walk() request is executed. damos_walk() reads the obsolete field under the lock and avoids adding a new request. After this change, only requests that are guaranteed to be handled or cancelled are registered. Hence the after-registration DAMON context termination check is no longer needed. Remove it together. The issue is found by sashiko [1]. Link: https://lore.kernel.org/20260327233319.3528-3-sj@kernel.org Link: https://lore.kernel.org/20260325141956.87144-1-sj@kernel.org [1] Fixes: bf0eaba0ff9c ("mm/damon/core: implement damos_walk()") Signed-off-by: SeongJae Park Cc: # 6.14.x Signed-off-by: Andrew Morton and API functions themselves can show the context is terminated. damos_walk() adds the caller's request to the queue first. After that, it shows if the kdamond of the damon_ctx is still running (damon_ctx->kdamond is set). Only if the kdamond is running, damos_walk() starts waiting for the kdamond's handling of the newly added request. The damos_walk() requests registration and damon_ctx->kdamond unset are protected by different mutexes, though. Hence, damos_walk() could race with damon_ctx->kdamond unset, and result in deadlocks. For example, let's suppose kdamond successfully finished the damow_walk() request cancelling. Right after that, damos_walk() is called for the context. It registers the new request, and shows the context is still running, because damon_ctx->kdamond unset is not yet done. Hence the damos_walk() caller starts waiting for the handling of the request. Signed-off-by: Sasha Levin commit 7e54ed8a780c8151350c073f3a91ca1da52c11b0 Author: SJ Park Date: Sat Jan 17 09:52:50 2026 -0800 mm/damon/core: cancel damos_walk() before damon_ctx->kdamond reset [ Upstream commit 69714a74c19f5ae8b21e25558d62d893d48a3f18 ] damos_walk() request is canceled after damon_ctx->kdamond is reset. This can make weird situations where damon_is_running() returns false but the DAMON context has the damos_walk() request linked. There was a similar situation for damon_call() requests handling [1], which _was_ able to cause a racy use-after-free bug. Unlike the case of damon_call(), because damos_walk() is always synchronously handled and allows only single request at time, there is no such problematic race cases. But, keeping it as is could stem another subtle race condition bug in future. Avoid that by cancelling the requests before the ->kdamond reset. Note that this change also makes all damon_ctx dependent resource cleanups consistently done before the damon_ctx->kdamond reset. Link: https://lkml.kernel.org/r/20260117175256.82826-4-sj@kernel.org Link: https://lore.kernel.org/20251230014532.47563-1-sj@kernel.org [1] Signed-off-by: SeongJae Park Signed-off-by: Andrew Morton Stable-dep-of: 33c3f6c2b48c ("mm/damon/core: fix damos_walk() vs kdamond_fn() exit race") Signed-off-by: Sasha Levin commit 7ea3850b9ce005e70f502b308edb2d99ca074ed3 Author: Long Li Date: Tue Mar 17 09:51:55 2026 +0800 xfs: close crash window in attr dabtree inactivation [ Upstream commit b854e1c4eff3473b6d3a9ae74129ac5c48bc0b61 ] When inactivating an inode with node-format extended attributes, xfs_attr3_node_inactive() invalidates all child leaf/node blocks via xfs_trans_binval(), but intentionally does not remove the corresponding entries from their parent node blocks. The implicit assumption is that xfs_attr_inactive() will truncate the entire attr fork to zero extents afterwards, so log recovery will never reach the root node and follow those stale pointers. However, if a log shutdown occurs after the leaf/node block cancellations commit but before the attr bmap truncation commits, this assumption breaks. Recovery replays the attr bmap intact (the inode still has attr fork extents), but suppresses replay of all cancelled leaf/node blocks, maybe leaving them as stale data on disk. On the next mount, xlog_recover_process_iunlinks() retries inactivation and attempts to read the root node via the attr bmap. If the root node was not replayed, reading the unreplayed root block triggers a metadata verification failure immediately; if it was replayed, following its child pointers to unreplayed child blocks triggers the same failure: XFS (pmem0): Metadata corruption detected at xfs_da3_node_read_verify+0x53/0x220, xfs_da3_node block 0x78 XFS (pmem0): Unmount and run xfs_repair XFS (pmem0): First 128 bytes of corrupted metadata buffer: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ XFS (pmem0): metadata I/O error in "xfs_da_read_buf+0x104/0x190" at daddr 0x78 len 8 error 117 Fix this in two places: In xfs_attr3_node_inactive(), after calling xfs_trans_binval() on a child block, immediately remove the entry that references it from the parent node in the same transaction. This eliminates the window where the parent holds a pointer to a cancelled block. Once all children are removed, the now-empty root node is converted to a leaf block within the same transaction. This node-to-leaf conversion is necessary for crash safety. If the system shutdown after the empty node is written to the log but before the second-phase bmap truncation commits, log recovery will attempt to verify the root block on disk. xfs_da3_node_verify() does not permit a node block with count == 0; such a block will fail verification and trigger a metadata corruption shutdown. on the other hand, leaf blocks are allowed to have this transient state. In xfs_attr_inactive(), split the attr fork truncation into two explicit phases. First, truncate all extents beyond the root block (the child extents whose parent references have already been removed above). Second, invalidate the root block and truncate the attr bmap to zero in a single transaction. The two operations in the second phase must be atomic: as long as the attr bmap has any non-zero length, recovery can follow it to the root block, so the root block invalidation must commit together with the bmap-to-zero truncation. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Long Li Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit 4b963fddf470fc55838349bdca5e86e816e68df0 Author: Long Li Date: Tue Mar 17 09:51:54 2026 +0800 xfs: factor out xfs_attr3_leaf_init [ Upstream commit e65bb55d7f8c2041c8fdb73cd29b0b4cad4ed847 ] Factor out wrapper xfs_attr3_leaf_init function, which exported for external use. Reviewed-by: Darrick J. Wong Signed-off-by: Long Li Signed-off-by: Carlos Maiolino Stable-dep-of: b854e1c4eff3 ("xfs: close crash window in attr dabtree inactivation") Signed-off-by: Sasha Levin commit 50144efd23ad9f939aed83ecbc83d4a12c8b9a79 Author: Long Li Date: Tue Mar 17 09:51:53 2026 +0800 xfs: factor out xfs_attr3_node_entry_remove [ Upstream commit ce4e789cf3561c9fac73cc24445bfed9ea0c514b ] Factor out wrapper xfs_attr3_node_entry_remove function, which exported for external use. Reviewed-by: Darrick J. Wong Signed-off-by: Long Li Signed-off-by: Carlos Maiolino Stable-dep-of: b854e1c4eff3 ("xfs: close crash window in attr dabtree inactivation") Signed-off-by: Sasha Levin commit 0f39d936a34933ebfbdc13a04f0aba814d3b9709 Author: Chris J Arges Date: Sat Dec 27 21:18:54 2025 -0600 ima: Fix stack-out-of-bounds in is_bprm_creds_for_exec() [ Upstream commit 377cae9851e8559e9d8b82a78c1ac0abeb18839c ] KASAN reported a stack-out-of-bounds access in ima_appraise_measurement from is_bprm_creds_for_exec: BUG: KASAN: stack-out-of-bounds in ima_appraise_measurement+0x12dc/0x16a0 Read of size 1 at addr ffffc9000160f940 by task sudo/550 The buggy address belongs to stack of task sudo/550 and is located at offset 24 in frame: ima_appraise_measurement+0x0/0x16a0 This frame has 2 objects: [48, 56) 'file' [80, 148) 'hash' This is caused by using container_of on the *file pointer. This offset calculation is what triggers the stack-out-of-bounds error. In order to fix this, pass in a bprm_is_check boolean which can be set depending on how process_measurement is called. If the caller has a linux_binprm pointer and the function is BPRM_CHECK we can determine is_check and set it then. Otherwise set it to false. Fixes: 95b3cdafd7cb7 ("ima: instantiate the bprm_creds_for_exec() hook") Signed-off-by: Chris J Arges Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 265ca3f6524be05039099582818521fb218c5917 Author: Coiby Xu Date: Wed Nov 19 22:03:25 2025 +0800 ima: Access decompressed kernel module to verify appended signature [ Upstream commit c200892b46ba3df3dd210b7117a463ec283600c3 ] Currently, when in-kernel module decompression (CONFIG_MODULE_DECOMPRESS) is enabled, IMA has no way to verify the appended module signature as it can't decompress the module. Define a new kernel_read_file_id enumerate READING_MODULE_COMPRESSED so IMA can calculate the compressed kernel module data hash on READING_MODULE_COMPRESSED and defer appraising/measuring it until on READING_MODULE when the module has been decompressed. Before enabling in-kernel module decompression, a kernel module in initramfs can still be loaded with ima_policy=secure_boot. So adjust the kernel module rule in secure_boot policy to allow either an IMA signature OR an appended signature i.e. to use "appraise func=MODULE_CHECK appraise_type=imasig|modsig". Reported-by: Karel Srot Suggested-by: Mimi Zohar Suggested-by: Paul Moore Signed-off-by: Coiby Xu Signed-off-by: Mimi Zohar Stable-dep-of: 377cae9851e8 ("ima: Fix stack-out-of-bounds in is_bprm_creds_for_exec()") Signed-off-by: Sasha Levin commit 7d6fd507464821220a40a0e55f53cda862cc15bb Author: Matteo Croce Date: Tue Jun 16 18:33:46 2026 +0200 fat: stop reading directory entries past the end-of-directory marker commit 6a2875517c778ac1111b6920e94cbab91cda8724 upstream. The FAT specification[1] (FAT Directory Structure -> "DIR_Name[0]") states: If DIR_Name[0] == 0x00, then the directory entry is free (same as for 0xE5), and there are no allocated directory entries after this one (all of the DIR_Name[0] bytes in all of the entries after this one are also set to 0). The special 0 value, rather than the 0xE5 value, indicates to FAT file system driver code that the rest of the entries in this directory do not need to be examined because they are all free. Linux did not honour this. fat_get_entry() kept advancing past the 0x00 terminator; if the trailing on-disk slots were not zero-filled (buggy formatters, read-only media written by other operating systems, on-disk corruption) the driver surfaced arbitrary bytes as real directory entries. On a typical affected image, `ls /mnt` returns ~150 bogus entries with random binary names, multi-gigabyte sizes, dates ranging from 1980 to 2106, and a flood of -EIO from stat(). Earlier attempts (v1..v3, see [2][3][4]) added `de->name[0] == 0` guards at each call site. As Hirofumi pointed out on v3, those guards reject the entry but fat_get_entry() has already advanced *pos past it; the next readdir() resumes after the marker and walks straight back into the garbage. His suggestion was to centralise the check. This patch: * Adds fat_get_entry_eod(), a small wrapper around fat_get_entry() that returns -1 when name[0] == 0 and seeks *pos to dir->i_size. Per spec every slot after the 0x00 marker is also zero, so jumping to the end of the directory is correct: subsequent reads return -1 from fat_bmap() without re-fetching trailing zero slots, and callers persisting *pos across invocations (notably readdir's ctx->pos) keep reporting end-of-directory on re-entry. * Converts the read/search paths to use the new wrapper: fat_parse_long(), fat_search_long(), __fat_readdir(), and fat_get_short_entry() -- the last covers fat_get_dotdot_entry(), fat_dir_empty(), fat_subdirs(), fat_scan(), and fat_scan_logstart() transitively. * Leaves fat_add_entries() and __fat_remove_entries() on raw fat_get_entry(): the write paths legitimately need to operate on free/zero slots. fat_add_entries() additionally detects an allocated entry past a 0x00 marker (the spec violation that produces the garbage) and treats it as filesystem corruption: fat_fs_error_ratelimit() is called -- which honours the configured errors= mount option (panic / remount-ro / continue) -- and the operation returns -EIO so we don't write fresh entries into an already-corrupt directory. [1] https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc [2] https://lore.kernel.org/lkml/20181207013410.7050-1-mcroce@redhat.com/ [3] https://lore.kernel.org/lkml/20181216231510.26854-1-mcroce@redhat.com/ [4] https://lore.kernel.org/lkml/20190201001408.7453-1-mcroce@redhat.com/ Reported-by: Timothy Redaelli Suggested-by: OGAWA Hirofumi Signed-off-by: Matteo Croce Link: https://patch.msgid.link/20260616163346.32603-1-technoboy85@gmail.com Acked-by: OGAWA Hirofumi Signed-off-by: Christian Brauner (Amutable) Cc: Nicolai Buchwitz Signed-off-by: Greg Kroah-Hartman commit f6c1e709a4f9184577201a3087b1488f248a800f Author: Frank Sorenson Date: Tue Oct 13 15:12:53 2026 -0400 cifs: fix time_last_write stamp placement in setattr/truncate paths [ Upstream commit ecababf08905958ba8c125979c4e39fc2f1a8a05 ] cifs_file_set_size() calls cifs_setsize() on success, which calls i_size_write(), updating i_size to the new value. The subsequent check attrs->ia_size != i_size_read() in both cifs_setattr_unix() and cifs_setattr_nounix() therefore always evaluates false after a successful cifs_file_set_size(), making the smp_store_release() of time_last_write dead code. The truncate path was unprotected against stale readdir size updates. Move the stamp to before the cifs_file_set_size() RPC call, guarded by attrs->ia_size != i_size_read() to exclude no-op same-size ftruncate(2) calls from stamping time_last_write unnecessarily. On the error path the stamp remains rather than being restored: restoring a stale snapshot (prev_tlw) could silently erase a concurrent _cifsFileInfo_put() close stamp if that close arrived between the READ_ONCE and the smp_store_release. readdir is suppressed until the stamp expires, which extends beyond one acregmax if the caller retries failed truncations. stat() is unaffected: the cifs_revalidate_dentry_attr() path calls cifs_fattr_to_inode() with from_readdir=false, which bypasses the time_last_write check in is_size_safe_to_change() entirely and always writes the authoritative QUERY_INFO result to i_size. Remove the now-unreachable stamp from the dead block in both functions. Fixes: e8a8d54c2d50 ("cifs: prevent readdir from changing file size due to stale directory metadata") Signed-off-by: Frank Sorenson Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French [ sashal: removed the timestamp write from cifs_file_set_size() because the original size-update blocks were already deleted ] Signed-off-by: Sasha Levin commit 2efa187fd4c9b8d7edcae0c1acf46739ce39fd01 Author: Fan Wu Date: Tue Oct 13 13:28:12 2026 -0400 drm/xe/i2c: cancel the client work on remove [ Upstream commit 611857adc9e7b0ee1239a0baf38498922ca5a12e ] xe_i2c_notifier() stores the DesignWare adapter in i2c->adapter and schedules i2c->work when the adapter is registered under the xe I2C platform device, and xe_i2c_client_work() then instantiates the AMC client device on that adapter. xe_i2c_remove() tears down the AMC, unregisters the client devices, the bus notifier and the adapter platform device, but it never drains i2c->work. A work item that is still queued or running when the adapter is unregistered dereferences i2c->adapter in i2c_new_client_device() after platform_device_unregister() has released the adapter. The work item is also embedded in the devm-allocated struct xe_i2c, so a work item still queued after the drm device devm unwind frees that allocation runs its callback on freed memory. The bus notifier is the only thing that schedules this work, and it is unregistered after the client devices. An instance that is still queued when the teardown runs can therefore write i2c->client[XE_I2C_CLIENT_AMC] while the loop is unregistering and clearing the same array, and an AMC client it instantiates late is only cleaned up by the adapter's own child sweep in i2c_del_adapter(). Move bus_unregister_notifier() in front of the client teardown loop and cancel the work right after it, so no new instance can be scheduled and a queued instance is drained before the client array is touched. A running instance still finds a live adapter, since the adapter is unregistered later. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Link: https://lore.kernel.org/intel-xe/20260912085932.101598-1-fanwu01@zju.edu.cn/ Cc: stable@vger.kernel.org Assisted-by: LLM, in-house static analysis tool Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260928013030.612592-1-fanwu01@zju.edu.cn Link: https://patch.msgid.link/20261006000413.318561-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit a23f27d5ec11c3f418c5e5531eea34ccda2b5b20) Signed-off-by: Rodrigo Vivi [ sashal: Adjusted xe_i2c_remove() context for the older teardown implementation. ] Signed-off-by: Sasha Levin commit 97e736000731f134cf75f4b4fc920e47bc6a0790 Author: Stanley Jhu Date: Tue Oct 13 11:31:26 2026 -0400 scsi: ufs: core: Avoid unsafe MMIO reads in ufshcd_mcq_compl_all_cqes_lock() [ Upstream commit 375f3a5691dd46b5d05b90a8968872ec8b2248c5 ] During MCQ host reset, ufshcd_host_reset_and_restore() stops the host controller via ufshcd_hba_stop() (HCE = 0) before calling ufshcd_complete_requests(hba, true) -> ufshcd_mcq_compl_pending_transfer(hba, true) -> ufshcd_mcq_force_compl_one() -> ufshcd_mcq_compl_all_cqes_lock(). Because ufshcd_mcq_force_compl_one() is its sole caller, ufshcd_mcq_compl_all_cqes_lock() always runs with HCE = 0. Despite the comment above ufshcd_mcq_compl_all_cqes_lock() stating that reading CQTPy may not be safe with the controller disabled, the function still calls ufshcd_mcq_update_cq_tail_slot() at the end of its sweep: 1. Unsafe CQTPy MMIO read: Calling ufshcd_mcq_update_cq_tail_slot() at the end of the sweep reads CQTPy over MMIO while HCE = 0, directly contradicting the function's documented contract (commit 1373df88d535 ("scsi: ufs: core: Add a comment block above ufshcd_mcq_compl_all_cqes_lock()")) that reading CQTPy may not be safe with the controller disabled. 2. Spurious error logs on empty slots: Sweeping all max_entries slots visits empty entries where command_desc_base_addr is 0, causing ufshcd_mcq_process_cqe() to log unguarded dev_err(hba->dev, "Abnormal CQ entry!\n") messages. Fix both issues in ufshcd_mcq_compl_all_cqes_lock(): - Remove the ufshcd_mcq_update_cq_tail_slot() call and the redundant hwq->cq_head_slot = hwq->cq_tail_slot assignment without replacement. The two indices are already equal after the sweep: they are equal when the sweep starts, since ufshcd_mcq_poll_cqe_lock() consumes entries until cq_head_slot reaches cq_tail_slot, and the sweep advances cq_head_slot by exactly one full ring. Both indices are also reinitialized before the queue is reused. - Extract ufshcd_mcq_compl_cqe() and invoke it only on non-empty slots during full-ring sweeps, keeping "Abnormal CQ entry!" logging strictly for unexpected empty entries in ufshcd_mcq_poll_cqe_lock(). Fixes: ab248643d3d6 ("scsi: ufs: core: Add error handling for MCQ mode") Cc: stable@vger.kernel.org Reviewed-by: Peter Wang Signed-off-by: Stanley Jhu Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260928035816.1294326-2-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit ee01d48f0f086fbaa254a69e78dafa244f72642c Author: Bart Van Assche Date: Tue Oct 13 11:31:25 2026 -0400 scsi: ufs: core: Add a comment block above ufshcd_mcq_compl_all_cqes_lock() [ Upstream commit 1373df88d53594a32534fd8960c51d1d09be8ecb ] Document the aspects of ufshcd_mcq_compl_all_cqes_lock() that are nontrivial in a comment block above this function. Signed-off-by: Bart Van Assche Reviewed-by: Peter Wang Link: https://patch.msgid.link/20260401202506.1445324-2-bvanassche@acm.org Signed-off-by: Martin K. Petersen Stable-dep-of: 375f3a5691dd ("scsi: ufs: core: Avoid unsafe MMIO reads in ufshcd_mcq_compl_all_cqes_lock()") Signed-off-by: Sasha Levin commit e36bac5923a3bd50b2ad3932d1e1fefa4855f61b Author: Peter Wang Date: Tue Oct 13 11:31:24 2026 -0400 scsi: ufs: core: Add debug log for MCQ command timeout [ Upstream commit 3abe4113e784b4a1135fe0e89828afecbfebf862 ] It is difficult to debug situations where an MCQ command timeout occurs, the corresponding CQ tag response is received, but the request is not completed. Add a one-line log to indicate when the CQ entry is abnormal. Signed-off-by: Peter Wang Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260210070837.1820710-3-peter.wang@mediatek.com Signed-off-by: Martin K. Petersen Stable-dep-of: 375f3a5691dd ("scsi: ufs: core: Avoid unsafe MMIO reads in ufshcd_mcq_compl_all_cqes_lock()") Signed-off-by: Sasha Levin commit d12c834b97c36e89fdfc0684a869c802c620a076 Author: Bart Van Assche Date: Tue Oct 13 11:31:23 2026 -0400 scsi: ufs: core: Move an assignment in ufshcd_mcq_process_cqe() [ Upstream commit dd4299af9b049c0dcb28699327ebc1386aab4b2a ] Since 'tag' is only used inside the if-statement, move the 'tag' assignment into the if-statement. This patch prepares for introducing a WARN_ON_ONCE() call in ufshcd_mcq_get_tag() if the tag lookup fails. Reviewed-by: Avri Altman Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/20251031204029.2883185-9-bvanassche@acm.org Signed-off-by: Martin K. Petersen Stable-dep-of: 375f3a5691dd ("scsi: ufs: core: Avoid unsafe MMIO reads in ufshcd_mcq_compl_all_cqes_lock()") Signed-off-by: Sasha Levin commit a34a230ccea1b8b667ae59dca11295a2c8f81738 Author: Ahmed Abdelhaleem Ahmed Date: Tue Oct 13 11:30:48 2026 -0400 scsi: ch: Do not keep references to data transfer element devices [ Upstream commit 27c0f718d3b3c99e6d315308e95d987d0382a8a8 ] ch_readconfig() looks up the scsi_device of every data transfer element whose SCSI id the changer reports in READ ELEMENT STATUS, and stores it in ch->dt[]. scsi_device_lookup() takes a reference, and nothing ever drops it: ch_destroy() frees the array with kfree(). ch->dt[] is read nowhere else - it only supplies the vendor, model and revision printed in the same loop. Once such a drive is removed, its scsi_device can never be released. It stays on the host's device list at its address, so a new device there is refused by anything that walks the list - target_core_pscsi reports "scsi_device_get() failed for H:C:T:L" - and the low-level driver's module can no longer be unloaded. Only a reboot recovers. It shows with any changer that reports its drives' ids; with the mhvtl virtual library (IBM 3573-TL personality), each create and remove of a library with four drives leaves four references behind, counted by the module's use count in lsmod. With ch not bound the count is unchanged, and with this patch applied it is unchanged too. Drop the reference as soon as the name has been printed, and remove the now unused dt[] array. That also removes the array leaked when ch_probe() fails after ch_readconfig(). The same leak was reported with an RFC patch in 2022, which was not merged. Fixes: daa6eda65a53 ("[SCSI] add scsi changer driver") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-scsi/20220719075442.6215-1-yanghao_ht@163.com/ Signed-off-by: Ahmed Abdelhaleem Ahmed Reviewed-by: Laurence Oberman Fixes: daa6eda65a53 ("[SCSI] add scsi changer driver") Link: https://patch.msgid.link/20260929-ch-dt-leak-v2-1-ddda8d635dca@gmail.com Signed-off-by: Martin K. Petersen (Oracle) [ sashal: Adapted allocation removal from kzalloc_objs() to the existing two-line kcalloc() call. ] Signed-off-by: Sasha Levin commit 8176ec7e369873cb11573779a264d0c8b183f218 Author: Stanley Jhu Date: Tue Oct 13 11:30:38 2026 -0400 scsi: ufs: core: Decouple CQ sweep from request iterator in MCQ [ Upstream commit 469fa055664bfd8717b087a80d59c03055789c17 ] In MCQ mode, ufshcd_mcq_compl_pending_transfer() uses blk_mq_tagset_busy_iter() to iterate over busy requests during error recovery and host reset. However, both iterator callbacks perform whole-queue operations redundantly for each visited request: - force_compl == true: ufshcd_mcq_force_compl_one() calls ufshcd_mcq_compl_all_cqes_lock() on every busy request, sweeping the entire completion ring (hwq->max_entries slots) once per active request under spin_lock_irqsave even though the first sweep already cleared all completion entries. - force_compl == false: ufshcd_mcq_compl_one() acquires cq_lock and polls CQTPy over MMIO via ufshcd_mcq_poll_cqe_lock() for every busy request without doing any per-request work. Sweep or poll each hardware queue (hba->uhq[i]) once at the start of ufshcd_mcq_compl_pending_transfer(). When force_compl is true, run blk_mq_tagset_busy_iter() afterward to complete residual in-flight requests with DID_REQUEUE, and remove the now-unused ufshcd_mcq_compl_one() callback. Fixes: ab248643d3d6 ("scsi: ufs: core: Add error handling for MCQ mode") Cc: stable@vger.kernel.org Reviewed-by: Bart Van Assche Signed-off-by: Stanley Jhu Reviewed-by: Peter Wang Link: https://patch.msgid.link/20260928035816.1294326-3-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 9e8fc7972b398e9dc2415ece283d8f64edac3858 Author: Wei-Jie Hung Date: Tue Oct 13 11:12:41 2026 -0400 riscv: patch: fix handling of bpf-jit execmem addresses [ Upstream commit a510e1ae8c9030750c2edf7b0bc9b186cd8c7a06 ] Commit 8718e5a3090b ("riscv: patch: skip fixmap mapping when kernel text is already writable") gated the core_kernel_text() branch of patch_map() on CONFIG_STRICT_KERNEL_RWX, and explicitly left the vmalloc branch unchanged. That branch has a separate problem. That branch only creates a temporary writable fixmap alias when CONFIG_STRICT_MODULE_RWX is enabled, and otherwise assumes the target is directly writable and returns the address unchanged. That assumption no longer holds: bpf_prog_pack_alloc calls set_memory_rox() on every pack unconditionally in alloc_new_pack(), independently of any CONFIG_STRICT_*_RWX option, so BPF text in the vmalloc area is read-only regardless of what CONFIG_STRICT_MODULE_RWX says. With CONFIG_STRICT_MODULE_RWX=n, patch_map() returns the read-only address directly, the subsequent copy_to_kernel_nofault() takes a page fault and returns -EFAULT. bpf_arch_text_copy() turns that into -EINVAL, which propagates through bpf_jit_binary_pack_finalize() to the WARN_ON() in bpf_int_jit_compile() and leaves the program un-JITed. Note that BPF cannot be fixed the way kprobes was in commit bdc46e507b59 ("riscv: mm: make EXECMEM_KPROBES writable without CONFIG_STRICT_MODULE_RWX"). EXECMEM_BPF is already PAGE_KERNEL, i.e. writable at allocation time; the read-only mapping is established afterwards by generic code in alloc_new_pack(), which arch code cannot influence. The only place this can be handled is patch_map(). This is the same problem that was fixed on arm64 by commit b1480ed230ac ("arm64: patching: fix handling of execmem addresses"), and the fix is the same: CONFIG_EXECMEM is what actually tracks whether the vmalloc area can hold executable memory that needs a temporary alias to be written. CONFIG_BPF_JIT, CONFIG_KPROBES and CONFIG_MODULES all select it. Note that this is not limited to CONFIG_MODULES=n. Unlike arm64, riscv selects CONFIG_ARCH_OPTIONAL_KERNEL_RWX, so CONFIG_STRICT_MODULE_RWX can be disabled with CONFIG_MODULES=y as well, and the bug is reachable in that configuration too. The !CONFIG_MMU build is unaffected: it has its own __patch_insn_set() and __patch_insn_write() implementations and never calls patch_map(). Fixes: 2c9e5d4a0082 ("bpf: remove CONFIG_BPF_JIT dependency on CONFIG_MODULES of") Signed-off-by: Wei-Jie Hung Reviewed-by: Pu Lehui Tested-by: Pu Lehui Link: https://patch.msgid.link/20260914115607.350097-1-imbigking12@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 420bf39a22a73d4f06fd66de5b06c2b4639b06a9 Author: Vivian Wang Date: Tue Oct 13 11:12:40 2026 -0400 riscv: patch: Avoid early phys_to_page() [ Upstream commit 6b60a128c2f43180664a614830f3c529497e0394 ] Similarly to commit 8d09e2d569f6 ("arm64: patching: avoid early page_to_phys()"), avoid using phys_to_page() for the kernel address case in patch_map(). Since this is called from apply_boot_alternatives() in setup_arch(), and commit 4267739cabb8 ("arch, mm: consolidate initialization of SPARSE memory model") has moved sparse_init() to after setup_arch(), phys_to_page() is not available there yet, and it panics on boot with SPARSEMEM on RV32, which does not use SPARSEMEM_VMEMMAP. Reported-by: Thomas Weißschuh Closes: https://lore.kernel.org/r/20260223144108-dcace0b9-02e8-4b67-a7ce-f263bed36f26@linutronix.de/ Fixes: 4267739cabb8 ("arch, mm: consolidate initialization of SPARSE memory model") Suggested-by: Mike Rapoport Signed-off-by: Vivian Wang Acked-by: Mike Rapoport (Microsoft) Tested-by: Thomas Weißschuh Link: https://patch.msgid.link/20260310-riscv-sparsemem-alternatives-fix-v1-1-659d5dd257e2@iscas.ac.cn [pjw@kernel.org: fix the subject line to align with the patch description] Signed-off-by: Paul Walmsley Stable-dep-of: a510e1ae8c90 ("riscv: patch: fix handling of bpf-jit execmem addresses") Signed-off-by: Sasha Levin commit 08275dcfbfc3b2ce2977b45171028ad92e256c94 Author: Hamza Mahfooz Date: Tue Oct 13 11:24:47 2026 -0400 net: mana: reserve RX buffer headroom to fix forwarding performance [ Upstream commit 259c4a519100e9182f264f8009ee212b32774277 ] Commit 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") started handing out RX buffers with zero headroom so that two buffers fit into one page at the default MTU. The MANA TX path, however, stores the per scatter-gather entry DMA mappings in `struct mana_skb_head` at skb->head, and mana_start_xmit() therefore calls skb_cow_head(skb, MANA_HEADROOM). The port advertises this requirement as ndev->needed_headroom = MANA_HEADROOM. As a result every packet that is received and then forwarded out of a MANA port fails the skb_cow() in ip_forward() and gets reallocated and copied by pskb_expand_head(). This is invisible to a plain RX or TX workload, but it puts a full skb reallocation plus memcpy on the hot path of every single forwarded packet, which is exactly what a router/NVA workload does. Restore the headroom. Note that reserving MANA_HEADROOM (232) is not enough: ip_forward() asks for LL_RESERVED_SPACE(dev), which rounds hard_header_len + needed_headroom up to HH_DATA_MOD and is 256 bytes on ethernet. Use LL_RESERVED_SPACE() directly so the value keeps tracking both constants. Also, since LL_RESERVED_SPACE() tracks MANA_HEADROOM, it grows with MAX_SKB_FRAGS and for MAX_SKB_FRAGS >= 19 it is greater than 256, so we have to account for that by using the headroom the RX queue actually uses (instead of assuming XDP_PACKET_HEADROOM) and turning MANA_XDP_MTU_MAX into MANA_XDP_MTU_MAX(ndev) (note that at the default CONFIG_MAX_SKB_FRAGS=17 they are equivalent). At the default MTU on a 4K page this means a buffer no longer fits twice into a page (SKB_DATA_ALIGN(1500 + MANA_RXBUF_PAD + 256) = 2112), so the frag-vs-single decision is now made by computing the real buffer size instead of comparing the MTU against PAGE_SIZE / 2. The page_pool fragment path is still used wherever at least two buffers genuinely fit, e.g. on 16K and 64K page sizes. Measured on an Azure VM with a MANA NIC acting as a forwarding NVA (UDP, 1400 byte payload, 4 streams, 8 Gbps offered, only the forwarding node's kernel differs), 8 runs each, median: forwarded pps throughput before 272,830 3.06 Gbps after 390,560 4.37 Gbps (+43%) perf on the forwarding node, same workload: memset_orig __pi_memcpy pskb_expand_head before 10.07% 3.96% present after 0.94% 0.64% gone Cc: stable@vger.kernel.org Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") Signed-off-by: Hamza Mahfooz Reviewed-by: Simon Horman Link: https://patch.msgid.link/20261003013647.2051416-1-hamzamahfooz@linux.microsoft.com Signed-off-by: Jakub Kicinski [ sashal: Kept headroom and buffer-sizing calculations in mana_get_rxbuf_cfg() because full-page RX flag support is absent. ] Signed-off-by: Sasha Levin commit eececf7c3a679d9c08175ad6bacbc8c31848f5af Author: Suraj Gupta Date: Tue Oct 13 10:39:31 2026 -0400 net: xilinx: axienet: Free outstanding DMA buffers on dmaengine stop [ Upstream commit bcf2573a68a808a5b54cadafa72b6672e662c2bf ] In the dmaengine path the driver pre-submits RX buffers and holds in-flight TX buffers whose SKBs are DMA-mapped by the driver and freed only in the completion callbacks. On ndo_stop() dmaengine_terminate_sync() aborts these descriptors without running their callbacks, and the driver then frees only the ring shells, leaking every SKB still owned by the engine and its DMA mapping on each ifdown. With 128 RX buffers pre-posted per channel, the mapping leak can eventually exhaust a limited IOMMU aperture. Clear the slot's skb in the TX and RX callbacks so a non-NULL skb marks a slot that still owns a live, DMA-mapped buffer, and on stop unmap and free every such buffer. axienet_dma_rx_cb() runs from the DMA tasklet and re-arms the RX ring on each completion, so it can race axienet_stop(): a completion may submit a fresh buffer after dmaengine_terminate_sync() has returned, leaving the channel armed with a buffer the teardown then frees while the engine may still write into it (dma_release_channel() does not stop it either). Add a lock that axienet_dma_rx_cb() holds across the @stopping check and the resubmit, and axienet_stop() holds to set @stopping before terminating. Once @stopping is set no callback can arm a new buffer, and any armed just before is aborted by the terminate, so teardown only frees buffers the engine no longer owns. Fixes: 6a91b846af85 ("net: axienet: Introduce dmaengine support") Cc: stable@vger.kernel.org Signed-off-by: Suraj Gupta Link: https://patch.msgid.link/20260928184207.2361931-1-suraj.gupta2@amd.com Signed-off-by: Jakub Kicinski [ sashal: Adjusted context to retain kcalloc() instead of upstream’s kzalloc_objs(). ] Signed-off-by: Sasha Levin commit cc7732b8549ecb6f02457edeb8db1f6d255e381c Author: Mikhail Gavrilov Date: Tue Oct 13 11:53:48 2026 -0400 Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex [ Upstream commit ac022970e9fb0a5f7e7d1f6c8e104c1ed924dd1c ] An RFCOMM connect() issued while a BR/EDR link is being authenticated makes lockdep report a circular dependency, and the reported cycle is a real AB/BA between rfcomm_mutex and hdev->lock. rfcomm_security_cfm() is called from the HCI event path, which already holds hdev->lock: hci_rx_work() hci_event_packet() hci_cc_read_enc_key_size() [hdev->lock] hci_encrypt_cfm() [hci_cb_list_lock] rfcomm_security_cfm() [rfcomm_mutex] while an RFCOMM connect() from userspace takes the same two locks the other way round: rfcomm_sock_connect() rfcomm_dlc_open() [rfcomm_mutex] __rfcomm_dlc_open() rfcomm_session_create() kernel_connect() l2cap_sock_connect() l2cap_chan_connect() [hdev->lock] WARNING: possible circular locking dependency detected kworker/u131:1/1128 is trying to acquire lock: rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm] but task is already holding lock: hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0 Chain exists of: rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock hci_auth_complete_evt() and hci_encrypt_change_evt() reach the callback the same way. Both orders have to be seen in the same boot, which is why a BR/EDR connection alone is not enough to show it: a session set up by the remote side is created by rfcomm_accept_connection() in krfcommd, which calls kernel_accept() and never takes hdev->lock under rfcomm_mutex. Connecting a device that authenticates and encrypts the link and then calling connect() on an RFCOMM socket towards any address - the connect does not have to succeed, the order is recorded before the page timeout - reports it every time. Only the session socket has to be connected with the lock held, and it does not: nothing else can see the socket before it is put on the session list. So connect it first and take rfcomm_mutex afterwards, which removes the rfcomm_mutex -> hdev->lock order for good, rather than keeping the HCI event path out of rfcomm_mutex. rfcomm_session_create() becomes rfcomm_session_connect(), which returns the connected socket without touching the session list, and rfcomm_dlc_open() adds the session once it holds the lock again. If another opener added a session for the same pair while this socket was connecting, that session is used and this socket is dropped. __rfcomm_dlc_open() now takes the session it should use, and its state check runs after the lock is re-acquired, so a DLC that was opened or closed in the meantime is still handled. Over an existing ACL link the connection can complete before the session reaches the list, and the wakeup from the socket callback is then lost, so krfcommd is woken once the session is visible. Connecting without the lock opens a window in which the socket can be closed. The DLC is not on a session yet, so rfcomm_dlc_close() finds nothing to do and returns without touching it, and rfcomm_dlc_open() would then attach a DLC whose owner is gone. rfcomm_dlc_close() now marks such a DLC with RFCOMM_CLOSED, and rfcomm_dlc_open() checks the mark once it holds rfcomm_mutex again and drops the socket instead of attaching the DLC. The mark is cleared when an open starts, so a DLC that is reused is not affected. This covers both callers of rfcomm_dlc_open(), the socket and the tty layer. Fixes: 759c185d0bbd ("Bluetooth: RFCOMM: serialize security confirmation handling") Suggested-by: Pauli Virtanen Reported-by: Pauli Virtanen Closes: https://lore.kernel.org/linux-bluetooth/5e76a95e934e451e7006db28827c2d64af5a88be.camel@iki.fi/ Reported-by: syzbot+74071deb72339c215b2e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-bluetooth/6a92fadc.08e933ee.dbf97.008f.GAE@google.com/ Reported-by: Jiaming Zhang Closes: https://lore.kernel.org/all/CANypQFabseTuRiyz2pGkc_Qj0moGDnY7KEp1qdTOqkw6gAL3hw@mail.gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Mikhail Gavrilov Tested-by: syzbot+74071deb72339c215b2e@syzkaller.appspotmail.com Signed-off-by: Luiz Augusto von Dentz [ sashal: Retained the struct sockaddr * cast instead of struct sockaddr_unsized * to match kernel_connect()’s API. ] Signed-off-by: Sasha Levin commit 638ee6bca19750934ea13f9c325f46fd8ae60064 Author: Tejun Heo Date: Tue Oct 13 11:35:51 2026 -0400 sched_ext: Fix CPU hotplug hang when a dying CPU's tasks sit in the BPF scheduler [ Upstream commit d35a535d3e3e71f92a051d94e415f43612c4edfc ] A CPU going down has to empty its own rq. Its hotplug thread waits in sched_cpu_wait_empty() until nothing else is left, and the only thing that wakes it is balance_push(), which runs from __schedule() on the dying CPU and pushes off the migratable tasks the CPU picks. sched_ext breaks this. A task sitting on a user DSQ or held by the BPF scheduler is still counted on its rq, but an inactive CPU no longer calls ops.dispatch() and can't pull the task back. The dying CPU goes idle with the task still counted, and one of two things happens: - Another CPU consumes the task. The rq empties without a __schedule() on the dying CPU, so the hotplug thread is never woken and cpu_down() hangs holding cpu_hotplug_lock. - The task is affine only to the dying CPU. Nothing can move it, and the offline stalls until the watchdog ejects the BPF scheduler. When the rq goes offline, re-enqueue every task on it that isn't already on the local DSQ. An enqueue on an offline rq lands on the local DSQ, so the dying CPU itself picks the tasks and balance_push() pushes them off, the same as for the other sched classes. From then on no sched_ext path on another CPU can pull a task off the rq. ops.dispatch() currently stops as soon as the CPU goes inactive, and CPU hotplug then waits for an RCU grace period before taking the rq offline. A BPF-held task affine only to the dying CPU and preempted inside an RCU read-side critical section would block that grace period, and the rq would never go offline. Test SCX_RQ_ONLINE directly so that ops.dispatch() keeps running until the rq goes offline. Only the dying CPU's own hotplug thread clears the flag during teardown, and task_can_run_on_remote_rq() still keeps other rqs' tasks off the CPU. Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Fixes: 991ef53a4832 ("sched_ext: Make scx_rq_online() also test cpu_active() in addition to SCX_RQ_ONLINE") Cc: stable@vger.kernel.org # v6.12+ Reported-by: Alap Mohan Reported-by: Joonwoo Park Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi [ sashal: adapted scx_dispatch_sched() changes to balance_one() in the unsplit sched_ext implementation. ] Signed-off-by: Sasha Levin commit 454b67fcc28c18502e47dfb9f067b04c28628ada Author: Mikulas Patocka Date: Tue Oct 13 10:39:48 2026 -0400 dm-integrity: validate the superblock on resume [ Upstream commit fc79aeb86a2c244c1f1894e2d8f2966fe2b60fa2 ] dm_integrity_resume() re-reads the superblock from the device so that it picks up the flags and the recalculate position. It performs no validation on the result, while the constructor validates the superblock it reads and sizes all the in-memory structures according to it. The user may modify the superblock on the underlying device while the dm-integrity device is suspended, so that the two no longer agree. In particular, access_journal_data() shifts the journal entry index by ic->sb->log2_sectors_per_block, while ic->journal_section_sectors and the journal page list were computed with the value that was present at constructor time. Increasing log2_sectors_per_block makes the index run past the end of the journal, and dm-integrity then writes 512 bytes through lowmem_page_address(NULL). Snapshot the validated superblock in the constructor and refuse to resume if any of the fields that describe the on-disk geometry changed. Reported-by: syzbot+675c91651049ad042c5f@syzkaller.appspotmail.com Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Fixes: 118ba36e446c ("dm-integrity: fix recalculation in bitmap mode") Assisted-by: Claude:claude-opus-5 Signed-off-by: Sasha Levin commit 2e25842f0e4423e0efb243f56153d842ed6b933f Author: Mikulas Patocka Date: Tue Oct 13 10:39:47 2026 -0400 dm-integrity: fix NULL pointer dereference when the 'R' flag is used [ Upstream commit 7d4d4f3b668d708d94f62ecdd33ac330a6fd8a84 ] If the dm-integrity device has the SB_FLAG_DIRTY_BITMAP flag set and the user activates the device in the 'R' mode, a crash in dm_integrity_resume happens because the function attempts to read the journal containing the bitmap. This patch makes dm-integrity skip any writes to the device in dm_integrity_resume if the device is activated in the 'R' mode. Signed-off-by: Mikulas Patocka Fixes: 468dfca38b1a ("dm integrity: add a bitmap mode") Cc: stable@vger.kernel.org Stable-dep-of: fc79aeb86a2c ("dm-integrity: validate the superblock on resume") Signed-off-by: Sasha Levin commit 0c9d4f9c66ca71a210916e9acdc461c0151e7d37 Author: Sean Wang Date: Sat Apr 25 14:50:02 2026 -0500 wifi: mt76: connac: tolerate inactive BSS deactivation [ Upstream commit 04222f980301561edd77917edac570b1393ec45d ] Firmware may return wlan_failure when deactivating a BSS that is already inactive. This is a valid teardown case and should not fail the remove path. Keep activation failures unchanged since they still indicate that firmware failed to create or activate the BSS state. Signed-off-by: Sean Wang Link: https://patch.msgid.link/20260425195011.790265-13-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 22732b0f290ac06b938b60941b12874b341354b1 Author: Lubos Rendek Date: Thu Oct 15 11:57:25 2026 +1100 nfsd: fix all-zero stateid in CB_OFFLOAD for async COPY [ There is no upstream commit: this fixes the 6.18.y backport of d0beaee498e1. Mainline fixed the problem as part of the async COPY rework in commit f307b4f7ed17 ("nfsd: split nfsd4_copy into transient and durable async copy objects"), which is too risky to backport. ] Since commit 9b4e5e9ba5ae ("nfsd: fix stale s2s_cp_stateids IDR entry for async COPY"), nfsd4_copy() calls dup_copy_fields() before the copy stateid is created and then writes the new stateid only into the COPY result. The async copy's own cp_res.cb_stateid stays zero, so nfsd4_send_cb_offload() sends CB_OFFLOAD with an all-zero stateid. The client cannot match it to its pending COPY and waits forever in nfs42_proc_copy(). Also copy the new stateid into async_copy->cp_res.cb_stateid. Calling dup_copy_fields() after nfs4_init_copy_state() instead is not an option, because dup_copy_fields() also copies cp_stateid and would overwrite the stateid that the backport moved to the async copy. Tested on 6.18.56 with an NFSv4.2 server-side COPY between two exports: with this change the copy completes and CB_OFFLOAD carries the same stateid as the COPY reply. Without it, cp(1) hangs on 6.18.55; the affected code in nfsd4_copy() is the same in 6.18.56. Fixes: 9b4e5e9ba5ae ("nfsd: fix stale s2s_cp_stateids IDR entry for async COPY") Closes: https://lore.kernel.org/stable/7cc824c4-632d-49df-ae5e-cfcbb5bf76ad@proxmox.com/ Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Lubos Rendek Signed-off-by: Sasha Levin commit 0c5595cba722477babc8eb30d984d6085067edfa Author: Lorenzo Stoakes (ARM) Date: Mon Oct 12 17:34:42 2026 -0400 mm/mremap: fix locked_vm leak from MREMAP_DONTUNMAP self-merge [ Upstream commit 838bb60dc21553e32df90f2f3bac5b905376e7aa ] Patch series "mm/mremap: fix two issues with MREMAP_DONTUNMAP", v2. The MREMAP_DONTUNMAP feature is highly unusual in that it permits mremap() operations that keep the original VMA in place. Historically this has led to a lot of bugs where non-obvious interactions occur between existing mremap() operations and the original VMA. Commit 397432cab17b ("mm/mremap: account mm->locked_vm correctly for MREMAP_DONTUNMAP") fixed an accidentally introduced bug around mm->locked_vm accounting, but this wasn't the only issue. And thus history repeats itself, as it turns out that mm->locked_vm accounting is broken by MREMAP_DONTUNMAP yet again by two further cases, and has been broken ever since the feature was introduced. Both relate to the fact that VMA_LOCKED_BIT is cleared on the source VMA (it has to be as all page tables are moved): 1. If an unfaulted VMA_LOCKONFAULT_BIT anonymous VMA self-merges it clears the VMA_LOCKED_BIT flag and permanently leaks mm->locked_vm pages. 2. If a partial mremap() is performed on a locked VMA there is a leak equal to the number of pages not copied. (Both for MREMAP_DONTUNMAP operations only) Both issues can be fixed by treating the source range as distinct from the destination range, which is the definition of what MREMAP_DONTUNMAP does so is appropriate. In case 1, simply disallow the self-merge, keeping adjacent source and destination VMAs distinct. In case 2, split the source range ahead of time if the VMA is mlock()'d, so accounting is always correct. Both changes were tested locally and confirmed to fix the issues. For the purposes of a backport, the fixes are kept distinct, a follow-up series can add self-tests. This patch (of 2): The MREMAP_DONTUNMAP feature is highly unusual in that it permits mremap() operations that keep the original VMA in place. Historically this has led to a lot of bugs where non-obvious interactions occur between existing mremap() operations and the original VMA. Fix another of these - self-merge. Self-merge occurs when a VMA is moved in front of or behind itself and the attributes of the VMA permit such a merge. Practically this can only happen for unfaulted anonymous VMAs due to the page offset equality requirement for merge: |------------| | | | v |...........||-----------||...........| | || unfaulted || | |...........||-----------||...........| ^ | | | |------------| This becomes problematic if the VMA is configured by the user to mlock-on-fault, i.e. the VMA_LOCKED_BIT, VMA_LOCKONFAULT_BIT VMA flags are set. MREMAP_DONTUNMAP clears mlock flags for the source VMA and maintains them for the destination VMA. Self-merge makes this impossible (there is only one VMA) and incorrectly clears the destination VMA's mlock flags. This causes a leak in mm->locked_vm as clearing this flag does not decrement the counter and the VMA no longer has VMA_LOCKED_BIT set so it is not decremented on unmap. Resolve this by simply disallowing a self-merge in this case - the source and destination VMAs are kept distinct and then are able to have distinct mlock() flags. Update dontunmap_complete() to make the now-redundant self-merge check a VM_WARN_ON_ONCE() instead to guard against future regressions. Also update the VMA userland tests to reflect the change. Link: https://lore.kernel.org/20260930-fix-dontunmap-partial-self-merge-v2-0-f388985a0f0a@kernel.org Link: https://lore.kernel.org/20260930-fix-dontunmap-partial-self-merge-v2-1-f388985a0f0a@kernel.org Fixes: e346b3813067 ("mm/mremap: add MREMAP_DONTUNMAP to mremap()") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Reviewed-by: Pedro Falcato Acked-by: Kiryl Shutsemau (Meta) Reviewed-by: Jose A. Perez de Azpillaga Tested-by: Anirudh Srinivasan Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Brian Geffon Cc: Minchan Kim Cc: [ sashal: Translated can_self_merge logic to the inverse faulted_in_anon_vma flag. ] Signed-off-by: Sasha Levin commit 5720bf6b91295688048f0ad8c0ce595be549ebe2 Author: Lorenzo Stoakes (ARM) Date: Mon Oct 12 12:27:20 2026 -0400 mm/mremap: fix locked_vm leak by splitting VMA for MREMAP_DONTUNMAP [ Upstream commit 597e4b9ab48a3f841080f627722064853d3f650e ] The MREMAP_DONTUNMAP feature is highly unusual in that it permits mremap() operations that keep the original VMA in place. Historically this has led to a lot of bugs where non-obvious interactions occur between existing mremap() operations and the original VMA. Fix another of these - partial copies. The long-standing mremap() partial VMA logic has the baked-in assumption that the originating VMA is unmapped and thus moved. However MREMAP_DONTUNMAP defeats this by performing a partial copy instead since it keeps the source VMA around. An mremap(..., MREMAP_DONTUNMAP) operation disallows resizing of the VMA, but the operation can be performed partially: |-----------------| | | | v <------> <------> .new_sz. new_sz |--.------.--| |------| | .source. | | dest | |--.------.--| |------| <------------> old_sz The page tables in the specified range are moved, but the original VMA is kept intact. This interacts poorly with mlock()'d VMAs, as the VMA_LOCKED_BIT flag is cleared for the entire source VMA and set for the entire destination VMA. This results in an mm->locked_vm leak as the change is therefore not accounted correctly. The clear solution here is to make the portion of the source VMA which is mremap()'d distinct from the rest of it, a.k.a. split it. Therefore resolve this issue by splitting it ahead of the rest of the mremap() operation if the VMA is mlock()'d. This is valid, as the source VMA will lose its VMA_LOCKED_BIT flag, so if a partial remap it will become distinct from the rest of the VMA. In order to make this change re-expose split_vma() in vma.h for CONFIG_MMU (nommu doesn't compile mremap.c and uses a static helper instead). Finally, update the sys_map_count check to account for this case. Note that the early check does not use needs_pre_split() - this is because the VMA has not been looked up by this point, so be conservative and assume that the VMA is mlock()'d in this case for the purposes of the sys_map_count check. Link: https://lore.kernel.org/20260930-fix-dontunmap-partial-self-merge-v2-2-f388985a0f0a@kernel.org Fixes: e346b3813067 ("mm/mremap: add MREMAP_DONTUNMAP to mremap()") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Reviewed-by: Pedro Falcato Acked-by: Kiryl Shutsemau (Meta) Reviewed-by: Jose A. Perez de Azpillaga Tested-by: Anirudh Srinivasan Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Brian Geffon Cc: Minchan Kim Cc: [ sashal: adapted newer VMA and map-count helpers to direct flag access and existing map-count checks. ] Signed-off-by: Sasha Levin commit fdf4f011c600416935a002650cc3bad3df8a127d Author: Jose Ignacio Tornos Martinez Date: Mon Oct 12 11:35:28 2026 -0400 iavf: send MAC change request synchronously [ Upstream commit 436729a56dd4dac611d10b569c5359d2cf705b19 ] After commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations"), iavf_set_mac() is called with the netdev instance lock already held. The function queues a MAC address change request via iavf_replace_primary_mac() and then waits for completion. However, in the current flow, the actual virtchnl message is sent by the watchdog task, which also needs to acquire the netdev lock to run. Additionally, the adminq_task which processes virtchnl responses also needs the netdev lock. This creates a deadlock scenario: 1. iavf_set_mac() holds netdev lock and waits for MAC change 2. Watchdog needs netdev lock to send the request -> blocked 3. Even if request is sent, adminq_task needs netdev lock to process PF response -> blocked 4. MAC change times out after 2.5 seconds 5. iavf_set_mac() returns -EAGAIN This particularly affects VFs during bonding setup when multiple VFs are enslaved in quick succession. Fix by implementing a synchronous MAC change operation similar to the approach used in commit fdadbf6e84c4 ("iavf: fix incorrect reset handling in callbacks"). The solution: 1. Send the virtchnl ADD_ETH_ADDR message directly (not via watchdog) 2. Poll the admin queue hardware directly for responses 3. Process all received messages (including non-MAC messages) 4. Return when MAC change completes or times out A new generic function iavf_poll_virtchnl_response() is introduced that can be reused for any future synchronous virtchnl operations. It takes a callback to check completion, allowing flexible condition checking. This allows the operation to complete synchronously while holding netdev_lock, without relying on watchdog or adminq_task. The function can sleep for up to 2.5 seconds polling hardware, but this is acceptable since netdev_lock is per-device and only serializes operations on the same interface. To support this, change iavf_add_ether_addrs() to return an error code instead of void, allowing callers to detect failures. Additionally, export iavf_mac_add_reject() to enable proper rollback on local failures (timeouts, send errors) - PF rejections are already handled automatically by iavf_virtchnl_completion(). Remove vc_waitqueue entirely because iavf_set_mac was the only waiter on this waitqueue and after the changes it is not needed. Fixes: ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations") cc: stable@vger.kernel.org Signed-off-by: Jose Ignacio Tornos Martinez Reviewed-by: Przemek Kitszel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 5aa9efb5591745d617c2b77d1ac4e2ef685dc0e0 Author: Corinna Vinschen Date: Mon Oct 12 11:35:27 2026 -0400 iavf: iavf_virtchnl_completion: drop duplicate ether_addr_equal() test [ Upstream commit 8538aaea10e141457bcb13d51b0d278c697c422a ] This is just a simple cleanup fix. Commit 35a2443d0910f ("iavf: Add waiting for response from PF in set mac") introduced a duplicate ether_addr_equal() check, so the current code tests the new MAC twice against the former MAC. Remove the outer ether_addr_equal() test, remnant of commit c5c922b3e09b ("iavf: fix MAC address setting for VFs when filter is rejected") Signed-off-by: Corinna Vinschen Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260609213559.178657-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Stable-dep-of: 436729a56dd4 ("iavf: send MAC change request synchronously") Signed-off-by: Sasha Levin commit b030fde644501d0ed5e604fc01719d1daa9cd472 Author: Mario Limonciello Date: Mon Jul 13 14:53:13 2026 -0500 drm/amd: Create a device link between APU display and XHCI devices [ Upstream commit 75c8746b9d0a0317d8a58aa0efa2ff2f7359908b ] Some AMD APU multi-function devices expose an integrated USB xHCI controller. In some circumstances (such as larger VRAM), the PM core can resume can fail when the xHCI controller is resuming in parallel with the GPU/display function. On affected systems, the xHCI controller can complete pci_pm_resume and start resuming USB devices while the GPU is still in its much longer resume path. This race condition leads to USB device resume failures followed by: xhci_hcd ...: xHCI host not responding to stop endpoint command xhci_hcd ...: HC died; cleaning up Create a device link from any xHCI controller sharing the same PCIe root port as the APU display function. The link uses DL_FLAG_STATELESS and DL_FLAG_PM_RUNTIME to ensure the GPU completes its resume before the xHCI controller begins resuming USB devices. This device link is done specifically in amdgpu so that if the platform firmware has been modified such that this issue doesn't happen the version can be detected and the workaround skipped. Suggested-by: Aaron Ma Reported-by: mrh@frame.work Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221073 Acked-by: Alex Deucher Tested-by: Mark Pearson Tested-by: Alexander F Tested-by: Francis DB Link: https://patch.msgid.link/20260713195313.1739762-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 07c93d7eeb0d990bc1b8e3b1eafa464bc9feee97) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 2d06cb25a497d3a7034ef9d172626c2d6620a0f1 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Mon Oct 12 11:51:58 2026 -0400 ip6_gre: remove obsolete ERSPAN PMTU update [ Upstream commit 8bc60db48e8cba35488bbd6e1f94aa990afa275a ] A tc tunnel_key action can attach a METADATA_IP_TUNNEL dst to an skb, and mirred can redirect it to a native ip6erspan device. The legacy PMTU update in ip6erspan_tunnel_xmit() treats that metadata dst as a route. Since it has no output device, dst_dev(dst)->mtu dereferences NULL. On v7.2 with KASAN, an initial UID/GID 65534 process with CapEff 0 used self-created user and network namespaces to trigger: KASAN: null-ptr-deref RIP: ip6erspan_tunnel_xmit+0x10fc/0x2cc0 Kernel panic - not syncing: Fatal exception in interrupt The update is obsolete. Commit fe1a4ca0a2b7 ("ip6_gre: process toobig in a better way") changed IPv6 GRE Too Big handling to update the underlay route and removed the equivalent block from __gre6_xmit(). ip6_tnl_xmit() then propagates the underlay PMTU to the overlay route. Remove the stale ERSPAN copy and its now-unused dst variable. This eliminates the metadata-dst dereference and keeps ERSPAN aligned with IPv6 GRE PMTU handling. Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support") Cc: stable@vger.kernel.org Suggested-by: Ido Schimmel Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20261002033058.358137-1-4ncienth@gmail.com Signed-off-by: Jakub Kicinski [ sashal: Adjusted the deletion to match dst6_mtu() instead of dst_mtu(). ] Signed-off-by: Sasha Levin commit 903a2ab8325a26d362247776521c1be3223c6622 Author: Manivannan Sadhasivam Date: Tue Jan 20 23:17:41 2026 +0530 PCI: dwc: Return -EIO from dw_pcie_wait_for_link() if device is not active [ Upstream commit 01d16b8afb7afcc17f999f8b4a9b9cfe6c6fae71 ] There are cases where the PCIe device would be physically connected to the bus, but the device firmware might not be active. So the LTSSM will get stuck in POLL.{Active/Compliance} states. This behavior is common with endpoint devices controlled by the PCI Endpoint framework, where the device will wait for the user to start its operation through configfs. For those cases, print the relevant log and return -EIO to indicate that the device is present, but not active. This will allow the callers to skip the failure as the device might become active in the future. Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260120-pci-dwc-suspend-rework-v4-2-2f32d5082549@oss.qualcomm.com Signed-off-by: Sasha Levin commit adc0d81b4d415efa3acec7deb326c0b3c6e74752 Author: Manivannan Sadhasivam Date: Tue Jan 20 23:17:40 2026 +0530 PCI: dwc: Return -ENODEV from dw_pcie_wait_for_link() if device is not found [ Upstream commit 1bcf245c837bc66fdaddea222bab9eb5c978a9d7 ] The dw_pcie_wait_for_link() function waits up to 1 second for the PCIe link to come up and returns -ETIMEDOUT for all failures without distinguishing cases where no device is present on the bus. But the callers may want to just skip the failure if the device is not found on the bus and handle failure for other reasons. So after timeout, if the LTSSM is in Detect.Quiet or Detect.Active state, return -ENODEV to indicate the callers that the device is not found on the bus and return -ETIMEDOUT otherwise. Also add kernel doc to document the parameter and return values. Signed-off-by: Manivannan Sadhasivam Tested-by: Richard Zhu Tested-by: Vincent Guittot Reviewed-by: Shawn Lin Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260120-pci-dwc-suspend-rework-v4-1-2f32d5082549@oss.qualcomm.com Signed-off-by: Sasha Levin commit e32aa1d85126e6d5ef6efd594ced3f75178886ce Author: Cheng Xu Date: Fri Aug 28 11:03:44 2026 +0800 RDMA/erdma: Use IRQ-safe XArray helpers for QP and CQ tables [ Upstream commit 00baeade709fb66da647e8327e8398bb532e30f7 ] Locked QP and CQ lookups from EQ interrupts can deadlock with create-path XArray updates. If an interrupt arrives while the create path holds the plain xa_lock, the lookup spins forever trying to acquire the same lock. Use IRQ-safe XArray helpers for all QP and CQ create-path updates, including the GSI QP store and error paths. Initialize both arrays with XA_FLAGS_LOCK_IRQ so sleeping allocations preserve interrupt state. Fixes: 98df2aee1459 ("RDMA/erdma: Hold CQ references when processing EQ events") Fixes: a52eeff32024 ("RDMA/erdma: Hold QP references for AE and CM processing") Signed-off-by: Cheng Xu Link: https://patch.msgid.link/20260828030344.88021-1-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 3c03f6f7c6f2d476f202bc3399359e2c27d7f99e Author: Ethan Tidmore Date: Thu Apr 2 13:00:08 2026 -0500 usb: gadget: f_hid: Add missing error code [ Upstream commit 2c863dbbeac7b919d4634ad886978a6731916de3 ] Currently in cdev_alloc() error path no error code is assigned. Assign error code '-ENOMEM'. Detected by Smatch: drivers/usb/gadget/function/f_hid.c:1291 hidg_bind() warn: missing error code 'status' Fixes: 81ebd43cc0d6d ("usb: gadget: f_hid: don't call cdev_init while cdev in use") Signed-off-by: Ethan Tidmore Acked-by: Peter Korsgaard Reviewed-by: Michael Zimmermann Link: https://patch.msgid.link/20260402180008.64233-1-ethantidmore06@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7820bca8cb2073811c851abc37d303afeb15c3c4 Author: Johan Hovold Date: Thu Apr 23 09:58:01 2026 +0200 spi: mpc52xx: clean up interrupt handling [ Upstream commit 76645c1fd682c9df746c3f7c149b868ceff914fb ] The driver is relying on the assumption that the invalid interrupt 0 can be freed without any side effects, but that is not the case on architectures like x86 where it would trigger a warning about freeing an already free interrupt. This should not cause any trouble on powerpc where this driver is used, but make the code more portable (and obviously correct) by making sure that the interrupts have been requested before freeing them. Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260423075801.2252318-1-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin