commit cc9de5d4b5ab6459f5774946aa3195ad51236fa8 Author: Greg Kroah-Hartman Date: Wed Oct 21 10:33:40 2026 +0200 Linux 7.2.12 Link: https://lore.kernel.org/r/20261017155059.698368299@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Salvatore Bonaccorso Tested-by: Miguel Ojeda Tested-by: Benjamin Boortz Tested-by: SJ Park Tested-by: Sean Lyon Tested-by: Ron Economos Tested-by: Barry K. Nathan Tested-by: Takeshi Ogasawara Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit e792a9ace39d2812a5b342a1987186c7bc653204 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 4722d06b2907585074252061b1024a696c1cfc23 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 7ce5d94246de897d34f3eec3d8e6de6d9e4399de Author: Richard Fitzgerald Date: Mon Oct 5 16:52:34 2026 +0100 ASoC: cs35l56: Add DAI for SDCA OT25 stream [ Upstream commit 86c8360c97f66fa7830fd930e2dc69374007284b ] Add a DAI for the SDCA OT25 stream on SoundWire DP4. The SDCA-defined OT25 stream is an amp reference feedback, typically used for AEC. The firmware outputs this on DP4. The firmware owns all control registers for this stream so there are no mixer controls or any other configuration options. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20261005155235.1386525-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 40c9216390eb0a07a277bd775fb0599cf699f3ee 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 e2e2fc0663b3850c0239d2c01f82d73d327f9efd Author: Hamza Mahfooz Date: Tue Oct 13 10:49:07 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: called mana_single_rxbuf_per_page_forced() directly to accommodate missing full-page-rx support. ] Signed-off-by: Sasha Levin commit 5c380dfecbf9d340912d5cda7ea692061a252673 Author: Dipayaan Roy Date: Tue Oct 13 10:49:06 2026 -0400 net: mana: refactor mana_get_strings() and mana_get_sset_count() to use switch [ Upstream commit d52f80731055ee43b36bf60088679aca97a484da ] Refactor mana_get_strings() and mana_get_sset_count() from if/else to switch statements in preparation for adding ethtool private flags support which requires handling ETH_SS_PRIV_FLAGS. No functional change. Reviewed-by: Haiyang Zhang Signed-off-by: Dipayaan Roy Link: https://patch.msgid.link/20260729063347.3388035-2-dipayanroy@linux.microsoft.com Signed-off-by: Jakub Kicinski Stable-dep-of: 259c4a519100 ("net: mana: reserve RX buffer headroom to fix forwarding performance") Signed-off-by: Sasha Levin commit 6d30b399ae28e5166d62484f81ccaefde6fe7996 Author: Christian Brauner Date: Tue Oct 13 19:05:01 2026 -0400 readdir: take no inode lock on an immutable directory [ Upstream commit e08f57a7dcb83818c058e415988c23beb6c5a47f ] iterate_dir() takes the directory's i_rwsem shared and holds it across ->iterate_shared(). For a directory that never has an entry and is never removed the lock keeps nothing still, it only orders every reader and every writer of that inode behind each other. For the directory of a nullfs instance that matters. The instance of the initial mount namespace is the root of every empty mount namespace and the private instance is the root of every kernel thread, so one inode is shared across users who have nothing else in common. And a reader can hold the lock for as long as it likes: back the getdents() buffer with a mapping of a file on a FUSE mount of your own, let the copy of "." and ".." fault and let the server wait. Queue an exclusive taker behind it, a mkdir() in that directory goes through start_dirop() before the read-only mount is reported, and from then on every lookup that misses the dcache in that directory, every create and every mount on it waits until the server answers. One user of an empty mount namespace stalls all the others. Add FOP_IMMUTABLE for the file operations of a directory that never changes and is never removed and let iterate_dir() skip the lock for it. The flag never changes for a file, ->f_pos is protected by f_pos_lock since directories are FMODE_ATOMIC_POS, IS_DEADDIR can't be set on such a directory and neither touch_atime() nor fsnotify take i_rwsem. Set it on the nullfs directory. The placeholder directories of libfs never have an entry either but their owners remove them, so they keep the lock. Fixes: 9d4e752a24f7 ("namespace: allow creating empty mount namespaces") Cc: stable@vger.kernel.org # v7.1+ Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-19-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit e58253e87d0a9f9126c4e0a7f76457a3ea629ea9 Author: Christian Brauner Date: Tue Oct 13 19:05:00 2026 -0400 nullfs: refuse file locks [ Upstream commit 31a1fb90624d7e275db775a29a0e00a7f8b3df63 ] Refuse flock() and POSIX locks on nullfs. Its one inode is the root of every kernel thread and the following patches make it the directory that stands in for an unmounted mount, so a lock taken through one such directory would block the locks of every other holder and F_GETLK would tell them the pid of the holder. Give the directory file operations of its own: what libfs gives an empty directory plus ->lock and ->flock that fail with ENOLCK, the way a filesystem without lock support does. Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-17-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: e08f57a7dcb8 ("readdir: take no inode lock on an immutable directory") Signed-off-by: Sasha Levin commit 173ff9d03ec6373c3158b6e630af33a9b36fd216 Author: Tejun Heo Date: Tue Oct 13 11:20:24 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: Omitted rescue-related changes because the rescue machinery is absent. ] Signed-off-by: Sasha Levin commit e9ec5cbbaf4dd3a02ae3d81719f4fcb9b609aa8e Author: Mikulas Patocka Date: Tue Oct 13 09:58:12 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 69ed43ed8a174465fca1ba6bfbde53e4618c8956 Author: Mikulas Patocka Date: Tue Oct 13 09:58:11 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 8e42aeb5b39f721d086ce984b2af2ba2f7b77f94 Author: Lubos Rendek Date: Thu Oct 15 11:53:40 2026 +1100 nfsd: fix all-zero stateid in CB_OFFLOAD for async COPY [ There is no upstream commit: this fixes the 7.2.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 14b978e8d05c ("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 7.2.10 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 7.2.4 and 7.2.9; the affected code in nfsd4_copy() is the same in 7.2.10. Fixes: 14b978e8d05c ("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