Author: Richard Fitzgerald <[email protected]> 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 <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> 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 <[email protected]> Fixes: 468dfca38b1a ("dm integrity: add a bitmap mode") Cc: [email protected] Stable-dep-of: fc79aeb86a2c ("dm-integrity: validate the superblock on resume") Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> 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: [email protected] Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Fixes: 118ba36e446c ("dm-integrity: fix recalculation in bitmap mode") Assisted-by: Claude:claude-opus-5 Signed-off-by: Sasha Levin <[email protected]>
Author: Ilan Dudnik <[email protected]> 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 <[email protected]> Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jinu Kim <[email protected]> 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: [email protected] Signed-off-by: Jinu Kim <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Wed Oct 21 10:33:40 2026 +0200 Linux 7.2.12 Link: https://lore.kernel.org/r/[email protected] Tested-by: Ronald Warsow <[email protected]> Tested-by: Brett A C Sheffield <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Salvatore Bonaccorso <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Tested-by: Benjamin Boortz <[email protected]> Tested-by: SJ Park <[email protected]> Tested-by: Sean Lyon <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Barry K. Nathan <[email protected]> Tested-by: Takeshi Ogasawara <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Shuah Khan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dipayaan Roy <[email protected]> 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 <[email protected]> Signed-off-by: Dipayaan Roy <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 259c4a519100 ("net: mana: reserve RX buffer headroom to fix forwarding performance") Signed-off-by: Sasha Levin <[email protected]>
Author: Hamza Mahfooz <[email protected]> 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: [email protected] Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") Signed-off-by: Hamza Mahfooz <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> [ sashal: called mana_single_rxbuf_per_page_forced() directly to accommodate missing full-page-rx support. ] Signed-off-by: Sasha Levin <[email protected]>
Author: Lubos Rendek <[email protected]> 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/[email protected]/ Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Lubos Rendek <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Brauner <[email protected]> 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/[email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> Stable-dep-of: e08f57a7dcb8 ("readdir: take no inode lock on an immutable directory") Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Brauner <[email protected]> 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: [email protected] # v7.1+ Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tejun Heo <[email protected]> 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: [email protected] # v6.12+ Reported-by: Alap Mohan <[email protected]> Reported-by: Joonwoo Park <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Reviewed-by: Andrea Righi <[email protected]> [ sashal: Omitted rescue-related changes because the rescue machinery is absent. ] Signed-off-by: Sasha Levin <[email protected]>
Author: Toke Høiland-Jørgensen <[email protected]> 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: [email protected] # the offending commit is in 6.12.113 Reported-by: Mehmet Fide <[email protected]> Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Sasha Levin <[email protected]>