commit d3417611a3b40b7f04a29e558cebac2bf69889d7 Author: Greg Kroah-Hartman Date: Tue Nov 10 13:05:09 2026 -0500 Linux 6.12.117 Link: https://lore.kernel.org/r/20261107134957.653319350@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Salvatore Bonaccorso Tested-by: Miguel Ojeda Tested-by: Barry K. Nathan Tested-by: Ron Economos Tested-by: Florian Fainelli Tested-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit 87fd475dc4e354088f6534285388e7b061f54b35 Author: Tu Dinh Date: Sat Nov 7 12:35:51 2026 +0100 xen-netback: Zero out sring pointers on unmap commit f96f16592a32430a0582309d73a873b6d3ee2bdb upstream. If xenvif_map_frontend_data_rings() fails when a ring is already mapped, it unmaps them via xenvif_unmap_frontend_data_rings() which keeps the ring pointers unchanged. xenvif_connect_data()'s cleanup path calls xenvif_disconnect_queue() which in turn calls xenvif_unmap_frontend_data_rings() again, which will attempt to unmap the pointers a second time. Zero out the ring pointers after they are unmapped to avoid this issue. This is XSA-532 Fixes: 2ac061ce97f4 ("xen/netback: cleanup init and deinit code") Signed-off-by: Tu Dinh Reviewed-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit ade3082dcdee17c5767069883936d64ff83f6c9f Author: Tu Dinh Date: Mon Nov 9 17:03:55 2026 +0100 xen-netback: Fix XenBus connection failure cleanup commit dc6d814562b65813556933dbda1015cef61dabf8 upstream. xenvif_get_stats and xenvif_get_ethtool_stats capture vif->num_queues under rcu_read_lock. We need to unpublish vif->num_queues before synchronize_net to ensure that readers that come afterwards will not read a non-zero vif->num_queues and attempt to access invalid queues. This is the same cleanup algorithm as used in backend_disconnect and added in commit b17075d5c198 ("xen-netback: fix race condition on XenBus disconnect"). This is XSA-531 Fixes: 5fb756f1bbec ("xen-netback: Fix UAF when reading statistics data") Signed-off-by: Tu Dinh Signed-off-by: Greg Kroah-Hartman commit 2a3f486bed45e031abea575783fdf326fa2f658b Author: Borislav Petkov (AMD) Date: Wed Nov 5 20:16:52 2025 +0100 x86/bugs: Mitigate TSA on AMD Zen5 Commit cf27412f19c9cc5909b9107cd1b3f4ab7608e362 upstream. Zen5 is affected by TSA too, along with a third variant called TSA_FILL. Detect the vuln there and mitigate it. For Zen5, a table of microcode revisions is not needed because appropriate microcode sets the VERW_CLEAR CPUID bit, which simplifies mitigation detection considerably. Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Greg Kroah-Hartman commit 3df57b335a27cc9e3093e10473172c7d378a682d Author: John Johansen Date: Thu Oct 29 08:13:55 2026 -0700 apparmor: on failed load ensure profile files are removed before parent [ Upstream commit 97ba44a2aa4c7ab011a93ce94cb595200fe4ea4f ] The load interface does not guarantee the order profiles are loaded. When a parent is loaded after its child, and the load fails, the current code will issue a warning, and leak a dentry. For the loaded set of profiles, ensure that on failure list is ordered is traversed in reverse so any children processed after their parent is freed first. We do not need to deal with the cases where the children are processed before their parent, because either a parent outside the list already exists or a dummy parent outside of the list is created, and the list walk will not put those parents before their children. Fixes: 6ec46f8f1977d ("apparmor: remove fs entries created by a failed policy load") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 78a8b852849b90b9f60d609ed1072c7ac5623607 Author: Joseph Qi Date: Sat Oct 24 23:10:07 2026 +0800 ocfs2: read the xattr entry hash before defragmenting the bucket [ Upstream commit f48151da595e74efdc23d83d8d6d142207b8c731 ] Patch series "ocfs2: fix stale xattr entry pointers and empty header reads", v1. Five defects in the ocfs2 extended attribute code, plus one robustness measure that belongs with them, all on the paths that move entries between a block, a bucket and an index tree. They fall into two groups. Stale entry pointers (patches 1 to 3) ocfs2_xa_set() writes through a pointer into xh_entries[] that two of its callers invalidate first. Defragmenting a bucket ends in a sort() on xe_name_hash, and lib/sort.c is an unstable heapsort, so entries that share a hash can trade slots. Copying a block into a bucket changes the order outright, since a block holds its entries in insertion order while a bucket holds them by hash, yet ocfs2_xattr_update_xattr_search() relocates the search by the index the entry had in the block. Neither path compares the entry's name with the one being set, so setxattr() can replace a neighbouring attribute's value and still report success, or trip ocfs2_xa_reuse_entry()'s BUG_ON. Patch 1 takes the hash before the sort; patches 2 and 3 look the entry up again afterwards. Reads of an empty entry array (patches 4 to 6) A block and a bucket may both hold no entries: ocfs2_xa_remove_entry() keeps the last slot when it removes the only one, so an empty bucket still carries the hash it is keyed by. Three sites index xh_entries[] without checking xh_count and so read xh_entries[-1], which lands on the header and comes back as xh_count | xh_free_start << 16. Nothing faults, but the value is acted on: the collision check reports no collision for an empty bucket, the divide commits a sentinel hash that hides part of the key space from ocfs2_xattr_bucket_find(), and the block to bucket copy claims storage the bucket does not hold. Patches 4 to 6 guard each site and keep the one read of xh_entries[0] that ocfs2_xa_remove_entry() documents as intentional. This patch (of 6): ocfs2_xattr_set_entry_index_block() takes the hash a bucket split has to work with out of xs->here, but only after ocfs2_xattr_set_entry_bucket() has tried and failed to fit the entry. That call defragments the bucket when it runs out of room, and ocfs2_defrag_xattr_bucket() finishes by sorting the entry array by name hash. lib/sort.c is not stable, so two entries sharing a hash may trade slots and xs->here is left naming an entry other than the one the search found. The hash value itself survives the permutation -- the array is already sorted, so a slot can only exchange with an equal-hash neighbour -- but there is no reason to depend on that. Pick the hash up before the set, where xs->here is unambiguously the entry the search landed on. No functional change intended. Link: https://lore.kernel.org/20261024151012.1059683-1-joseph.qi@linux.alibaba.com Link: https://lore.kernel.org/20261024151012.1059683-2-joseph.qi@linux.alibaba.com Fixes: e39baff18b85 ("ocfs2: use the stored hash when checking xattr bucket collision") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Cc: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Signed-off-by: Sasha Levin commit a648e216d1fb45247610c0dd511c73011b8fc39f Author: Scott Gauche Date: Mon Oct 5 11:40:17 2026 -0400 ALSA: hda/realtek: Fix audio after Windows reboot on ASUS Q423SA [ Upstream commit 8acd6469f42784f38872ad83b14c41152d986b63 ] The ASUS Vivobook S 14 Q423SA-U5512 (DMI family S5406SA) with the ALC294 codec has working analog audio when booted directly after a full shutdown. After a warm reboot from Windows 11, audio works briefly during Linux startup, then both the internal speakers and headphones become silent. PCM playback continues without errors. Coefficient 0x1b is 0x4e4b on a direct cold boot, but 0x4a4b after the Windows warm reboot. Restoring bit 10 changes it back to 0x4e4b and immediately enables both analog outputs. Speaker playback, headphone playback, jack switching, cold boot, and suspend/resume were tested successfully. The same 0x4a4b state and immediate recovery with 0x4e4b were independently confirmed on another S5406SA with subsystem 1043:10c4. The same coefficient write is already used by ALC294_FIXUP_ASUS_COEF_1B for the ASUS UX431DA. That fixup cannot be reused here because it chains to ALC289_FIXUP_ASUS_GA401 and applies unrelated DAC routing and microphone pin configuration. Add a model-specific fixup for subsystem 1043:10c4 and chain it to the existing ALC2XX_FIXUP_HEADSET_MIC fixup instead. Link: https://github.com/thesofproject/sof/issues/11051 Fixes: f2d08f3651fb ("ALSA: hda/realtek: Fix headset mic on ASUS Vivobook S14 S5406SA") Signed-off-by: Scott Gauche Link: https://patch.msgid.link/20261005154017.1164657-1-scott-dev@scottgauche.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 073ff5c8292ebc3e64dcbb7cbec4cba1132266b0 Author: Jason Perlow Date: Wed Oct 21 22:52:38 2026 +0530 wifi: brcmfmac: map msgbuf RX packet IDs bidirectional [ Upstream commit 7ed5dce55fa8393972b1bf2bf5af1c818c5e7dc2 ] Commit f0ba5fd51ff2 ("wifi: brcmfmac: Set DMA direction for msgbuf packet IDs") maps the RX packet ID buffers DMA_FROM_DEVICE. The BCM4364 firmware also reads posted RX buffers, so with VT-d translation enabled every such read faults ("PTE Read access is not set") and the firmware crashes and resets in a loop. Map the RX pool DMA_BIDIRECTIONAL again, as before that commit. TX keeps DMA_TO_DEVICE. Fixes: f0ba5fd51ff2 ("wifi: brcmfmac: Set DMA direction for msgbuf packet IDs") Cc: stable@vger.kernel.org Signed-off-by: Jason Perlow Signed-off-by: Aditya Garg Acked-by: Arend van Spriel Link: https://patch.msgid.link/20261021172238.10004-1-aditya.garg@linux.dev Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 85f166ee39a09a23eeb1db6f5a7f28a826c5934b Author: Avi Weiss Date: Tue Oct 27 09:37:20 2026 +0200 init/bootconfig: pass init arguments in documented order [ Upstream commit 278b2abf660a3e0991eb9f16f11bd9e9514a286d ] start_kernel() appends command-line init arguments before bootconfig init arguments, while setup_command_line() places them in the opposite order. As a result, the arguments passed to init do not match the saved command line, reversing the intended precedence of options. Parse extra_init_args before after_dashes so command-line init arguments are passed last. Link: https://lore.kernel.org/all/20261027073719.4010659-2-thnkslprpt@gmail.com/ Fixes: b66fbbe8d482 ("init/bootconfig: Reorder init parameter from bootconfig and cmdline") Signed-off-by: Avi Weiss Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 954b6f622830bca5339c330041f8130ba36d9650 Author: Amir Goldstein Date: Fri Oct 30 16:55:52 2026 +0100 fs: don't fail __d_obtain_alias() for unlinked inodes [ Upstream commit a522dd871024a0f065bfa7638afdb929607f58fc ] Commit 669bb5af15d4 ("fs: make sure to call fsnotify_inoderemove() only once when inode is dead") did two things. It made dentry_unlink_inode() call fsnotify_inoderemove() only once the inode has neither links nor aliases left. And it made __d_obtain_alias() fail with -ESTALE for an inode in that state so that open_by_handle_at() can't create a new alias after FS_DELETE_SELF has been reported and the inode marks are gone. The second part is wrong for network filesystems. __d_obtain_alias() backs d_obtain_alias() and d_obtain_root(). Those are what the ->fh_to_dentry() and ->get_parent() methods use to turn the inode they looked up into a dentry for exportfs_decode_fh_raw(), i.e., for open_by_handle_at() and for nfsd file handle decoding. For a local filesystem an in-core inode without links and aliases is an orphan that goes away on the final iput(). For a network filesystem that's not true. i_nlink is just the link count the server last reported and whether the object is still reachable through its file handle is up to the server. If a file is unlinked while it is still open elsewhere, e.g., by another NFSv4 client or by a process on the server, the server keeps the object alive and its file handle stays valid. nfs_fh_to_dentry() fetches the attributes for such a handle, nfs_fhget() sets i_nlink to 0 from them, the new inode has no aliases yet and so __d_obtain_alias() now fails with -ESTALE. The same applies to fuse_get_dentry() which takes i_nlink from the fuse server. Filesystems that care about unlinked inodes already make that decision themselves in ->fh_to_dentry(), e.g., ceph's __fh_to_dentry() fetches the link count with CEPH_CAP_LINK_SHARED and only refuses an unlinked inode if it isn't open. Note that on a network filesystem i_nlink drops to zero through attribute updates when another client unlinks the file. So the inode might never have gone through dentry_unlink_inode() with i_nlink == 0, i.e., fsnotify_inoderemove() might never have been called for it and there's nothing for the -ESTALE to protect. So drop the two checks from __d_obtain_alias() again and go back to the unconditional alias lookup. While at it, update the comment above inode_notify_dead() since it no longer blocks new aliases. Amir sent this as v3 to replace 669bb5af15d4 but that commit was already in mainline by then. So do it as a fix on top. The resulting code is identical to v3. This means open_by_handle_at() can again create a new alias for an unlinked inode after FS_DELETE_SELF has been reported. Closing that file reports a second FS_DELETE_SELF and the file has none of the inode marks that were torn down. That's what Daehyeon's open_by_handle_at() LTP test checks so it is expected to fail again. This needs to be handled separately. A mark that is added through such a file while fsnotify_destroy_marks() is still running is rejected with -ENOENT since 36ebddca56b9 ("fsnotify: prevent mark additions during connector teardown") so it can't end up on a detached connector. Christian Brauner says: Amir's v3 replaced 669bb5af15d4 as a whole. I turned it into an incremental fix on top of mainline and wrote a new commit message. Jan's Reviewed-by was given on v3 and the resulting code is identical. Fixes: 669bb5af15d4 ("fs: make sure to call fsnotify_inoderemove() only once when inode is dead") Cc: stable@vger.kernel.org Reported-by: Daehyeon Ko <4ncienth@gmail.com> Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/CAOQ4uxg7Qt436SiKhKEJKOjtCjeB_XyTjazYF7HMyQAGGcgx2A@mail.gmail.com Reviewed-by: Jan Kara Link: https://patch.msgid.link/20261030-work-dcache-obtain_alias-v1-1-a1f7e44536d2@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 5f202d9b9a03a5d0a5af378ee8ddf9492643d427 Author: Hungyu Lin Date: Mon Oct 26 01:57:38 2026 +0000 fs: skip copy_file_range write limits when there is no data [ Upstream commit 81dfa035891f0502674332ee97db348a16486de0 ] generic_copy_file_checks() reduces count to zero for a source offset at or beyond EOF, but still checks the destination write limits. If pos_out is at RLIMIT_FSIZE, this sends SIGXFSZ and returns -EFBIG even though there is no data to write. For example, GNU cat copying a 1024-byte regular file to another regular file with RLIMIT_FSIZE=1024 copies all bytes and is then killed by its next copy_file_range() call at EOF. A zero-length request can fail in the same way. Check write limits only when count is nonzero, as the ordinary write checks already do. Keep the other copy validation in place. Fixes: 96e6e8f4a68d ("vfs: add missing checks to copy_file_range") Cc: stable@vger.kernel.org Signed-off-by: Hungyu Lin Link: https://patch.msgid.link/20261026015738.46230-1-dennylin0707@gmail.com Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 3a2d1aa0e395b5f190fc1a89bbe41f857b20ce60 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Sun Oct 18 14:17:08 2026 +0900 splice: avoid stale f_pos writeback on error [ Upstream commit 79b496ebe382866e3a05090b7dc9ae95e85e65b2 ] do_splice() snapshots an implicit file position before calling the splice helper. Since splice does not take f_pos_lock, another operation on the same open file description can update f_pos while the helper is blocked. If the helper then fails, the unconditional writeback restores the stale snapshot. For a directory without ->splice_read, a file-to-pipe splice fails with -EINVAL. A concurrent directory mutation and getdents() call can advance f_pos and refresh the filesystem's revalidation cookie before that failure restores only the old position. The next ext2 readdir can then trust an offset inside a directory entry and copy data from the adjacent page to userspace. Only update an implicit file position when splice returns a non-negative result, matching read and write. Keep explicit offset updates unchanged. Fixes: 7995bd287134 ("splice: don't pass the address of ->f_pos to methods") Cc: stable@vger.kernel.org Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Link: https://patch.msgid.link/20261018051708.2422394-1-4ncienth@gmail.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 423c58fad30cc18742f8a1891e37b07120b508db Author: Chris Mason Date: Thu Oct 29 15:00:20 2026 +0100 aio: fix NULL deref when a fault races ring truncation [ Upstream commit d53b5aa5cfae27e4d236fc0ab9581085d27f7d33 ] The aio ring lives in a file on the aio pseudo filesystem and the ring VMA uses filemap_fault(). aio_ctx_aops doesn't have a ->read_folio because aio_setup_ring() puts all folios of the ring into the page cache. So a fault on the ring only works as long as it finds its folio in the page cache. If it doesn't, filemap_fault() calls ->read_folio without checking and we jump to NULL. We already fixed this twice this year. A forked child could inherit the ring mapping, fixed by commit c03ce4173c7b ("fs: aio: set VMA_DONTCOPY_BIT in mmap to fix NULL-pointer-dereference error"). And a partial mremap() could leave part of the ring mapped, fixed by commit 3adf7ae18bf4 ("fs: aio: reject partial mremap to avoid Null-pointer-dereference error"). Both times a VMA outlived the ring and the ring file was truncated under it. There's a third way to get there. kill_ioctx() and the error path of ioctx_alloc() unmap the ring with vm_munmap() and ignore the return value. If vm_munmap() has to wait for mmap_lock and a fatal signal is pending it returns -EINTR and the VMA stays. free_ioctx() then calls put_aio_ring_file() which truncates the ring file to zero. A fault that passed the i_size check in filemap_fault() before that doesn't find its folio anymore, allocates a new one and calls ->read_folio: fault on the ring io_destroy() with SIGKILL pending ================= ================================= vm_munmap() returns -EINTR filemap_fault() i_size check passes free_ioctx() put_aio_ring_file() truncate_setsize(inode, 0) no folio, allocate a new one filemap_read_folio() ->read_folio == NULL All that's needed is a second process that shares the mm. If a CLONE_VM child calls io_destroy() and gets SIGKILLed while it waits for mmap_lock the ring stays mapped for the threads of the parent. Any user can do that. Instead of plugging the routes one by one give the ring a ->read_folio that unlocks the folio and returns -EIO. All folios of a live ring are in the page cache so a fault can only end up there if the ring was truncated. The fault now gets SIGBUS. Nothing else reads the ring file and the aio filesystem uses noop_backing_dev_info so there's no readahead either. Making vm_munmap() unkillable in those two places would only close this one route and bring back what commit ae7987835643 ("mm: make vm_munmap killable") fixed. Fixes: 36bc08cc0170 ("fs/aio: Add support to aio ring pages migration") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Link: https://patch.msgid.link/20261029-work-fs-ai-fixes-v1-1-88f22792f6f7@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 619e86e1cbba6fd72afa8c338b52f23356f3e8a1 Author: Georgia Garcia Date: Wed Oct 14 19:08:20 2026 -0300 apparmor: remove fs entries created by a failed policy load [ Upstream commit 6ec46f8f1977d218bf2494ce276152b2d01424af ] aa_replace_profiles() creates the raw_data/ directory for the loaddata and the profile directories for new profiles before the last checks that can fail. When one of those checks fails, the fail path releases the ns lock without removing what this load created. The raw_data directory is named after the current ns revision, and the revision is only bumped by a successful load. The stale directory is only removed once the loaddata's last profile reference is dropped, from a workqueue. Until then, every load fails to create raw_data/ with -EEXIST. If the new profiles are never freed, which is the case when their dents are left behind pinning the proxy, that never happens and no policy can be loaded until reboot. While still holding the ns lock in the fail path, remove the profile directories of the new profiles and, if this load created it, the raw_data directory. Fixes: 5d5182cae401 ("apparmor: move to per loaddata files, instead of replicating in profiles") Cc: stable@vger.kernel.org Signed-off-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 064d2878185f9f4e86c59baa98f14281a78ea1fd Author: Kyle Zeng Date: Wed Oct 28 17:02:26 2026 +0100 tcp: fix reordering addition overflow in MTU probing [ Upstream commit c1df9c0c0536393de43310f84ca4f8b217271a00 ] Commit efb8763d7bbb ("net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes") widened size_needed and the MSS multiplication, but tp->reordering + 1 is still evaluated as u32. RTAX_REORDERING accepts an unrestricted u32, and tcp_init_metrics() can install U32_MAX. In that case the extra-data requirement becomes zero. A write queue with probe_size - 1 data bytes and a FIN satisfies the sequence-space check. The coalescing walk can pass the queue head to tcp_skb_can_collapse(), and tcp_clone_payload() can produce an skb whose advertised payload exceeds the data in its fragments. Local delivery followed by TCP_ZEROCOPY_RECEIVE can then walk beyond the fragment array. KASAN reports a slab-out-of-bounds read in can_map_frag(). Cast reordering before incrementing it so the arithmetic handles the entire u32 metric range. For U32_MAX, the required size exceeds the 32-bit queue and window limits, so the existing checks skip the probe. The calculation is unchanged for all other reordering values. Fixes: efb8763d7bbb ("net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes") Cc: stable@vger.kernel.org Cc: Wyatt Feng Cc: Ren Wei Signed-off-by: Kyle Zeng Signed-off-by: Eric Dumazet Reviewed-by: Neal Cardwell Reviewed-by: Kuniyuki Iwashima Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20261028160226.2170244-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3e3fb4bc8db7e59bf06b31df26dfbca56fdfa8d2 Author: Kyle Zeng Date: Wed Oct 28 19:14:50 2026 +0100 net/packet: check TX_RING fragments before memory accounting [ Upstream commit dc4dd12f80e499dc034710cd8195489abcf0b059 ] tpacket_fill_skb() adds the full non-linear payload length to skb->truesize and sk_wmem_alloc before checking MAX_SKB_FRAGS. With PACKET_VNET_HDR, userspace can submit a ring-sized frame even when it greatly exceeds the device MTU. A near-INT_MAX frame can saturate sk_wmem_alloc before the fragment loop rejects it. A subsequent refcount_add(0x40000001) can temporarily turn REFCOUNT_SATURATED into 1. A concurrent TX completion can then drop that apparent last reference and free the still-live packet socket before refcount_warn_saturate() restores the counter. Check that the remaining payload fits in MAX_SKB_FRAGS pages before accounting it. Include the initial page offset in the calculation, and move the existing -EFAULT handling out of the fragment loop. This preserves the accepted packet sizes and error code while preventing an invalid frame from injecting an oversized byte charge. Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap") Cc: stable@vger.kernel.org Cc: Willem de Bruijn Signed-off-by: Kyle Zeng [edumazet: use net_warn_ratelimited() instead of pr_err(), add a Fixes: tag] Signed-off-by: Eric Dumazet Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20261028181450.2221013-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e89a7966686b80e9a0e4b49c6040b6a18c6c98aa Author: John Johansen Date: Tue Oct 20 16:00:30 2026 -0700 apparmor: fix refcount leak in aa_get_newest_profile() [ Upstream commit 33ed50716251d5b2875706c40d0c8082d46be0b1 ] The labels_profile() macro is evaluating its argument twice #define labels_profile(X) ((X)->vec[(X)->size - 1]) unfortunately aa_get_newest_profile() passes aa_get_newest_label(&p->label) so every call to aa_get_newest_profile results in 2 refcounts being taken with one being leaked. There is no need for labels_profile() to be a macro. Convert it to an inline fn, which ensures all uses are passing the correct struct and removes the double evaluation. Fixes: 637f688dc3dc ("apparmor: switch from profiles to using labels on contexts") Cc: stable@vger.kernel.org Reported-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit b559449e3fda9fa5b5e7c6c8eccc8df0dec88c7f Author: Zhiling Zou Date: Tue Oct 27 12:46:49 2026 +0800 tcp: check congestion control restriction first [ Upstream commit dda51b73721684637ab8e9bd97c78228b99c4bd2 ] tcp_set_default_congestion_control() takes a reference to an algorithm before checking whether a non-init network namespace may select it. A rejected request returns -EPERM without dropping the reference. This affects module-backed algorithms too; BPF is not required. For example, after root loads tcp_bbr, a user with CAP_NET_ADMIN in a non-init network namespace can repeatedly request it as the default although it is not in tcp_allowed_congestion_control. Each rejected write leaks a module reference. Since module->refcnt is an atomic_t, 2^31 such writes can make it negative; later module_put() calls warn, and rmmod can hit the BUG_ON() in try_release_module_ref(). Check the namespace restriction before acquiring the reference, as tcp_set_congestion_control() already does. Fixes: 8d432592f30f ("net: Only allow init netns to set default tcp cong to a restricted algo") Cc: stable@vger.kernel.org Reported-by: Vega Suggested-by: Eric Dumazet Signed-off-by: Zhiling Zou Reviewed-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/71c142b2d45af6a2fe7fc6cd4a5ca52c53afbe23.1793075984.git.zhilinz@nebusec.ai Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit eaf8b5f9cd5222f9ae02b43fd968e331aa8195cb Author: Kunhai Dai Date: Mon Oct 19 08:54:11 2026 -0400 blk-iocost: abort weight transfer on invalid donation weights [ Upstream commit c810ee88cdab27f443c32270dc7c0eaad2cca3f8 ] transfer_surpluses() warns and then keeps going when the donation calculation produced invalid weights. The following propagation can then divide by a zero hweight_inuse, so the warning is immediately followed by a divide error. When the check trips, abandon this period's donation transfer and release the walk lists. This trades one period without donation for not crashing; the invalid state is not expected on the normal path. Developed with assistance from Claude Code (Anthropic): the assistant analysed the failure path, drafted the change and ran the checks listed below. The author reviewed the result and remains responsible for it. Fixes: e08d02aa5fc9 ("blk-iocost: implement Andy's method for donation weight updates") Cc: stable@vger.kernel.org Signed-off-by: Kunhai Dai Tested-by: Tao Cui Reviewed-by: Tao Cui Acked-by: Tejun Heo Link: https://patch.msgid.link/20261019125412.3123895-2-daikunhai@didiglobal.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b41c74168f4b1ffe0823992e40caf69f8d68f16a Author: Josef Bacik Date: Thu Oct 8 09:33:33 2026 +0000 mount: refuse setns() with a shared fs_struct again [ Upstream commit 948e604aca8af30490accf7d46d44814ffa26f80 ] mntns_install() refuses to switch the mount namespace of a task that shares its fs_struct, since root and cwd of the others would move to a namespace they are not in. It looks at nsset->fs for that. If more than the mount namespace is asked for, that is a private copy made by prepare_nsset(), which has one user by definition; commit_nsset() then writes root and cwd of the copy to the fs_struct of the task. A thread of a process with two threads, pidfd of a task in another mount namespace: setns(pidfd, CLONE_NEWNS) -EINVAL setns(pidfd, CLONE_NEWNS | CLONE_NEWUTS) 0 and after the second call the other thread, still in the old mount namespace, has lost its cwd (/tmp became /) and sees the mounts of the other namespace under /. Look at the fs_struct that is going to be changed. The second call then fails with -EINVAL like the first one. Fixes: 303cc571d107 ("nsproxy: attach to namespaces via pidfds") Cc: stable@vger.kernel.org # v5.8+ Signed-off-by: Josef Bacik Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit eec404a3ad8f8d5ccbba38355fd9b50b6bcb2f01 Author: Avi Weiss Date: Sun Oct 25 14:20:58 2026 +0200 irqchip/irq-msi-lib: Free wired MSI descriptors [ Upstream commit 1c16bc2b1122f78f9d51c5785f7a78b36d44972b ] msi_device_domain_alloc_wired() allocates a descriptor for each interrupt, but wired MSI domains do not set MSI_FLAG_FREE_MSI_DESCS. msi_device_domain_free_wired() releases the IRQ without freeing its descriptor, eventually exhausting the domain. Failed allocations also leave descriptors behind. Set MSI_FLAG_FREE_MSI_DESCS for wired MSI domains so both paths release the descriptors. Fixes: 64a855324311 ("irqchip/irq-msi-lib: Prepare for DOMAIN_BUS_WIRED_TO_MSI") Signed-off-by: Avi Weiss Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261025122058.2180685-1-thnkslprpt@gmail.com Signed-off-by: Sasha Levin commit 29a3394308fef36ae7a1f276546c4ad863124be8 Author: Avi Weiss Date: Mon Oct 26 14:26:42 2026 +0200 irqchip/riscv-imsic: Report successful hardware retrigger [ Upstream commit a2f482407d33ebe7f12e30d6cf383ffb1c7d709d ] imsic_irq_retrigger() writes to the IMSIC MSI register to retrigger an interrupt, but returns 0. The IRQ core treats zero as failure and may schedule a software resend despite the hardware retrigger. Return 1 after the MSI write to report successful hardware retriggering and prevent the unnecessary software resend. Fixes: 027e125acdba ("irqchip/riscv-imsic: Add device MSI domain support for platform devices") Signed-off-by: Avi Weiss Signed-off-by: Thomas Gleixner Reviewed-by: Björn Töpel Reviewed-by: Anup Patel Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261026122641.3292904-2-thnkslprpt@gmail.com Signed-off-by: Sasha Levin commit b57d467dab580b9b28387dbfb3d97299b0c372a5 Author: Eric Biggers Date: Sun Oct 25 13:38:31 2026 -0700 fsverity: Be more careful with return value of ->get_verity_descriptor() [ Upstream commit 8f8faec82aa902b1997ae578c46bcc84afbad811 ] If fsverity_operations::get_verity_descriptor() returns that the verity descriptor has 0 size, then a zero-size buffer is allocated to hold it, and it's called again with bufsize=0. But bufsize=0 is a special case that says to return the actual size. If in the meantime the filesystem has decided that the size is some actually valid size, it will return that size, and then validate_fsverity_descriptor() will read from ZERO_SIZE_PTR and crash. Of course, for the filesystem to misbehave in that strange way, it generally would require direct writes to the block device. Regardless, fsverity_get_descriptor() might as well guard against it. Make it do so. Specifically, validate that the first call to ->get_verity_descriptor() returns at least the minimum descriptor size, and validate that the second call returns the same size as the first. Fixes: fd2d1acfcadf ("fs-verity: add the hook for file ->open()") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261025203831.120095-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit 77f35ee4cf4e5981c3bd0fe403cc2b1db332aa4b Author: Fang Xieyan Date: Wed Sep 16 23:17:53 2026 +0800 kgdb: Fix buffer overflow in the qRcmd packet handler [ Upstream commit 9ca9e8c857b55a081d5a1f8039b27cbb4d646b49 ] gdb_cmd_query() decodes the hex payload of a qRcmd packet (the GDB "monitor" command passthrough to kdb) into remcom_out_buffer and hands it to kdb_parse(). It sizes the decode with strlen() of the payload: int len = strlen(remcom_in_buffer + 6); ... kgdb_hex2mem(remcom_in_buffer + 6, remcom_out_buffer, len); len = len / 2; kgdb_hex2mem() takes count as the number of bytes to produce and decodes them in place at buf, reading and writing 2 * count bytes there. len here is the hex character count, twice the decoded size, so the decode runs over 2 * len bytes at remcom_in_buffer + 6, off the end of the buffer. On x86 BUFMAX is 1024, so a 256-byte monitor command (512 hex characters) overruns remcom_in_buffer during the in-place decode: BUG: KASAN: global-out-of-bounds in kgdb_hex2mem+0x131/0x160 Read of size 1 at addr ffffffff8765ef05 by task sh/1 ... kgdb_hex2mem+0x131/0x160 gdb_serial_stub+0x16d4/0x3170 kgdb_cpu_enter+0xb68/0x1520 ... The buggy address belongs to the variable: remcom_in_buffer+0x405/0x420 Halve len before the call so kgdb_hex2mem() gets the decoded byte count. It then reads the len hex characters already in remcom_in_buffer and writes len / 2 bytes, all inside the buffer, and remcom_out_buffer holds the same command as before. Fixes: a0de055cf613 ("kgdb: gdb "monitor" -> kdb passthrough") Cc: stable@vger.kernel.org Suggested-by: Douglas Anderson Link: https://lore.kernel.org/all/CAD=FV=V1-gNZ8yTsC+D8inePWv=A+9H09hWJojQf5NRpcNvK+Q@mail.gmail.com/ Assisted-by: Qoder:Qwen3.8-Max Signed-off-by: Fang Xieyan Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20260916151753.6722-1-fangxy@xiaopeng.com Signed-off-by: Daniel Thompson Signed-off-by: Sasha Levin commit 9f6d3f0eb685569448f965129a4faf0f236438b7 Author: Fang Xieyan Date: Tue Sep 22 23:49:07 2026 +0800 kgdb: Fix buffer overflow in the 'M' and 'X' packet handlers [ Upstream commit 13962ef7021ef2531a4f6650eca87c363e6c9c32 ] write_mem_msg() passes the length claimed by an 'M' or 'X' packet directly to kgdb_hex2mem() or kgdb_ebin2mem(). A malformed packet can claim more data than was actually received, causing the decoders to read past remcom_in_buffer. Record the received payload length in get_packet() and use it to bound the decoders. 'M' carries two hex characters per byte, while 'X' carries one byte per output byte except that a 0x7d escape consumes an additional input byte. Pass the packet end to kgdb_ebin2mem() so both reads are checked against the received data. Keep zero-length 'X' packets valid, as GDB uses them to probe binary download support. Fixes: dc7d55270521 ("kgdb: core") Cc: stable@vger.kernel.org Assisted-by: Hawkeye:GLM-5.3-flash Assisted-by: Qoder:Qwen3.8-Max Signed-off-by: Fang Xieyan Link: https://lore.kernel.org/r/20260922154907.90535-1-fangxy@xiaopeng.com Signed-off-by: Daniel Thompson Signed-off-by: Sasha Levin commit 1397005178f69365f94457f1a402835f5e498008 Author: Fang Xieyan Date: Tue Sep 15 02:03:44 2026 +0800 kgdb: Fix buffer overflow in the 'm' packet handler [ Upstream commit ac0159129e2cb99a70c4b80cfbf58d03e092dc7b ] gdb_cmd_memread() passes the length of the 'm' packet straight to kgdb_mem2hex(), which hex-encodes the reply into remcom_out_buffer[BUFMAX] without checking that the reply fits. A client on the KGDB I/O console can ask for a read of any size, and the hex encoding runs off the end of the buffer. kgdb_mem2hex() takes that length as an int count, so 2^31 truncates to a negative value and copy_from_kernel_nofault() is handed buf + count as its destination. On x86 BUFMAX is 1024, so a read of 512 bytes overruns by the single byte that terminates the hex string: BUG: KASAN: global-out-of-bounds in kgdb_mem2hex+0x1dd/0x230 Write of size 1 at addr ffffffff87651780 by task sh/1 ... The buggy address belongs to the variable: remcom_out_buffer+0x400/0x420 Bounds check the length before the hex encoding: if (length > (BUFMAX - 1) / 2) { error_packet(remcom_out_buffer, -EINVAL); return; } gdbstub_msg_write() already bounds the count it hex-encodes against BUFMAX. Reads over the limit never returned valid data, so an error reply loses nothing. Fixes: dc7d55270521 ("kgdb: core") Cc: stable@vger.kernel.org Assisted-by: Hawkeye:GLM-5.3-flash Assisted-by: Qoder:Qwen3.8-Max Signed-off-by: Fang Xieyan Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20260914180344.15485-1-fangxy@xiaopeng.com Signed-off-by: Daniel Thompson Signed-off-by: Sasha Levin commit 8a264652e015a8ed96e666ab8d8cf21a0c71b3f5 Author: Guixin Liu Date: Wed Oct 28 16:55:51 2026 +0800 nvmet: Free the old negotiation state when restarting authentication [ Upstream commit 5c279fcabb0ea7ba61881c13027b15d8054b8abd ] Restarting a DH-HMAC-CHAP negotiation with SEND(NEGOTIATE) resets sq->dhchap_step but does not release the previous c1/c2/skey, which are only freed in nvmet_auth_sq_free() at teardown. The next CHALLENGE/REPLY exchange then overwrites those pointers with fresh allocations. An unauthenticated host can repeat the negotiate message endlessly, leaking a few dozen bytes per round and slowly exhausting target memory. Clear the old negotiation state with nvmet_auth_sq_free() before setting up the new one. Also reset dhchap_skey_len to zero: if a DH session key was already established, a following round with dhvlen=0 would otherwise pass a NULL skey with a stale non-zero length to the HMAC code and dereference it. Fixes: db1312dd95488 ("nvmet: implement basic In-Band Authentication") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit ec6dadd81a16e41cf08c3d376517b46c587373a4 Author: Guixin Liu Date: Wed Oct 28 14:44:36 2026 +0800 nvmet: Finish the blk plug when integrity allocation fails [ Upstream commit 18fc5f6f1ca945630dae5404265de55d65194e22 ] nvmet_bdev_execute_rw() starts a plug before building the bios, but the two error exits taken when nvmet_bdev_alloc_bip() fails return without calling blk_finish_plug(). current->plug is left pointing at the stack frame of the returned function, so the next blk_flush_plug() walks a stale list. Route both failures through a common exit that finishes the plug. Fixes: c6e3f13398123 ("nvmet: add metadata support for block devices") Cc: stable@vger.kernel.org Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Nilay Shroff Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit adf43758f1eb1f5c00f64146265ea5b20cbeb1ea Author: Martin Belanger Date: Tue Oct 27 06:38:52 2026 -0400 nvme-tcp: start error recovery when read_sock fails [ Upstream commit 288cfa187208cc9d0809eb8e1508658151a444dd ] nvme_tcp_recv_skb() disables the queue and starts error recovery for errors it detects itself. An error returned by the transport reaches nvme_tcp_try_recv() without either action. nvme_tcp_io_work() returns on a negative result and does not requeue itself, so the queue stops receiving and remains stalled until a command times out. Report the error and start error recovery when the queue is still enabled, which indicates that the error was not handled by the actor. Do this under the socket lock, as nvme_tcp_recv_skb() does. Fixes: be8e82caa685 ("nvme-tcp: enable TLS handshake upcall") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Signed-off-by: Martin Belanger Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 1754fc977a3d4674a6bb875cfcfb4d0ff9009b54 Author: Guixin Liu Date: Mon Oct 26 18:44:56 2026 +0800 nvmet-fc: Tear down the association when the admin queue allocation fails [ Upstream commit 11db8ab55e1a7533e9cfe57687ab142ba67d3c84 ] When the initial admin queue allocation fails after a new association was created, nvmet_fc_ls_create_association() only drops the association reference, which frees the association. By then the association is already on the target port's assoc_list, though, and removal from that list only happens in nvmet_fc_delete_target_assoc(), which this error path never calls. The freed association stays on the list, where later lookups and the port teardown can access it, and the target port reference taken at allocation time leaks. A remote host can trigger this reliably with a Create Association LS requesting a queue too large to allocate. Schedule the regular association teardown instead of dropping the reference directly. The teardown removes the association from the list and releases the target port reference before the final reference drop frees it. Fixes: 0cab4404874f ("nvme-fc: fix a missing queue put in nvmet_fc_ls_create_association") Cc: stable@vger.kernel.org Reviewed-by: Daniel Wagner Signed-off-by: Guixin Liu Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 5412a13adaa3ba016cc7bcd48332485fef0c74f1 Author: Shao Mingyin Date: Mon Oct 26 16:45:26 2026 +0800 nvmet-auth: fix error handling on CHALLENGE failure [ Upstream commit 96da408bb4a24bf87b366b13f41c2687d3c05671 ] In nvmet_execute_auth_receive(), when nvmet_auth_challenge() fails (for example when the initiator-supplied allocation length is shorter than the DH-HMAC-CHAP challenge response, or the challenge nonce allocation fails), the error path sets status = NVME_SC_INTERNAL and breaks out of the switch. The unconditional status = nvmet_copy_to_sgl(req, 0, d, al); after the switch then overwrites the error status (nvmet_copy_to_sgl() returns 0 on success), so the AUTH_RECEIVE command incorrectly completes with SUCCESS and the initiator proceeds with a truncated/empty challenge. Fix this by freeing the buffer and jumping to the common done: label on CHALLENGE failure, skipping the copy_to_sgl() entirely and preserving the NVME_SC_INTERNAL status. Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Cc: stable@vger.kernel.org Signed-off-by: Shao Mingyin Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit e39568fd4d9cd33cfd55deca89272f9a6506a26d Author: Andrea Parri Date: Thu Oct 22 15:29:30 2026 +0200 nvmet-fc: only send read data for successful commands [ Upstream commit 94f93c61b1a5dd08d011be58172ce4392b849008 ] When a read command completes with an error, __nvmet_fc_fcp_nvme_cmd_done() still pushes the whole data buffer to the host before the response. nvmet_fc_alloc_tgt_pgs() allocates that buffer with sgl_alloc() and no __GFP_ZERO, and a command rejected by nvmet_check_transfer_len() leaves it untouched, so the host receives stale target memory. The buffer is as large as the data length in the command IU, so the amount of stale memory returned is up to the host. The tcp and rdma targets send data only when cqe->status is zero (see nvmet_tcp_need_data_out() and nvmet_rdma_need_data_out()), so no nvmet command can rely on returning data with an error status. Do the same for fc. The ERSP then reports a transferred length of fod->offset, which is 0, matching what nvme_fc_fcpio_done() checks on the host. Tested over nvme-fcloop: a failed read command no longer transfers data and still completes with its error status, and successful reads are unaffected. Fixes: c53432030d86 ("nvme-fabrics: Add target support for FC transport") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Andrea Parri Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 22d0eb8d7aa4e45d22491d7cc1327010f19c86b9 Author: Weiming Shi Date: Fri Oct 16 10:23:38 2026 -0700 nvmet-rdma: reject short connection requests [ Upstream commit 635e760169a87abf03874cd4636cd91b580cb427 ] nvmet_rdma_parse_cm_connect_req() treats RDMA-CM private data as a struct nvme_rdma_cm_req but accepts any nonzero private_data_len. The iWARP path allocates exactly the peer-provided length, so a six-byte MPA request reaches the parser and the hsqsize load reads two bytes past the allocation. Require the complete request structure before reading any of its fields. The decoded KASAN report is: BUG: KASAN: slab-out-of-bounds in nvmet_rdma_cm_handler (drivers/nvme/target/rdma.c:1427 drivers/nvme/target/rdma.c:1475 drivers/nvme/target/rdma.c:1614 drivers/nvme/target/rdma.c:1814) Read of size 2 at addr ff1100010459d366 by task kworker/u16:1/41 Workqueue: iw_cm_wq cm_work_handler Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) nvmet_rdma_cm_handler (drivers/nvme/target/rdma.c:1427 drivers/nvme/target/rdma.c:1475 drivers/nvme/target/rdma.c:1614 drivers/nvme/target/rdma.c:1814) cma_cm_event_handler (drivers/infiniband/core/cma.c:2181) iw_conn_req_handler (drivers/infiniband/core/cma.c:2640) cm_work_handler (drivers/infiniband/core/cm.c:2502 drivers/infiniband/core/cm.c:3858) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 12: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kmalloc_node_track_caller_noprof (mm/slub.c:5414 mm/slub.c:5545) kmemdup_noprof (mm/util.c:138) cm_event_handler (drivers/infiniband/core/iwcm.c:194 drivers/infiniband/core/iwcm.c:1076) siw_cm_upcall (drivers/infiniband/sw/siw/siw_cm.c:408) siw_proc_mpareq (drivers/infiniband/sw/siw/siw_cm.c:750) siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1086) The buggy address is located 0 bytes to the right of allocated 6-byte region [ff1100010459d360, ff1100010459d366) Cc: stable@vger.kernel.org Fixes: 8f000cac6e7a ("nvmet-rdma: add a NVMe over Fabrics RDMA target driver") Reported-by: Assisted-by: LLM Reviewed-by: Christoph Hellwig Signed-off-by: Weiming Shi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit e698cc94716650faafaccb51b2b42c853beb1686 Author: Tristan Madani Date: Fri Oct 23 19:53:09 2026 +0000 ppp: fix stale pointer access after pskb_may_pull in ppp_ccp_peek [ Upstream commit 1e860f42f41c6fbf3304f6a52be38245b9394982 ] ppp_ccp_peek() caches a pointer to skb->data in dp after the first pskb_may_pull(), then uses dp after a second pskb_may_pull(skb, len + 2) in the CCP_CONFACK handler. If the second pull triggers pskb_expand_head() due to a cloned skb or frag linearization, skb->head is freed and reallocated, leaving dp stale. The stale dp is subsequently used in CCP_OPT_LENGTH() and passed to decomp_init()/comp_init() which read from the freed memory. Re-derive dp from skb->data after the second pskb_may_pull. Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Signed-off-by: Dave Miller Signed-off-by: Sasha Levin commit bee679d92e6664baa0c9ec118feaa47d992311eb Author: Peter Ujfalusi Date: Tue Oct 27 16:46:55 2026 +0200 ASoC: hdac_hda: Keep runtime PM state in sync across codec remove/probe [ Upstream commit 99203e8d8968def973e82bb712ea959c6a46c16e ] After the codec has been removed, its runtime PM status is RPM_SUSPENDED while hdac_hda_codec_probe() powers the codec up via snd_hda_codec_device_new(). The pm_runtime_put()/snd_hda_power_down() calls on probe and registration then see an already suspended device, the codec suspend callback is not called and the codec, its HDA link and the codec_powered bit stay set, preventing the controller from runtime suspending. The remove has a similar problem with the codec link accounting: hdac_hda_codec_remove() drops the link reference taken in probe without looking at the runtime PM state of the codec. If the codec was already runtime suspended, the link reference has been dropped by the codec suspend callback and the remove drops it a second time. Resume the codec in hdac_hda_codec_remove() before disabling runtime PM so that the link reference and the codec_powered bit are always in the same state as after the probe, and mark the device active on probe once the codec has been powered up. Finally mark the codec device suspended at the end of the remove. Its runtime PM is disabled at this point and if only the ASoC card is unbound (e.g. by unbinding the machine driver), a following system suspend would otherwise call the runtime suspend callback on the already cleaned up codec via pm_runtime_force_suspend(). This is a followup patch to address Sashiko reports. Link: https://lore.kernel.org/linux-sound/20261027083840.28813-4-peter.ujfalusi@linux.intel.com/ Fixes: c3ec8ac82105 ("ASoC: hdac_hda: fix memleak on module unload") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20261027144655.31988-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 94cb218a43b1a60c2e51ee3e26d10ab64f3f6ae3 Author: Hongling Zeng Date: Wed Aug 5 14:45:59 2026 +0800 ntfs3: fix mapping pairs bounds check for alignment [ Upstream commit f517cae6333121783043d9ba5142b50f5d1cf75b ] In the UpdateMappingPairs action, the expansion check compares the unaligned new attribute size with the available record space. The new size is aligned to an 8-byte boundary before the mapping pairs are updated, so the check can underestimate the required space by up to seven bytes. Use the aligned size in the expansion check to ensure that the subsequent update cannot exceed the available record space. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit e558ee689f40b4d4e8d46d7a76c1c4e439f11200 Author: Hyeontae Lee Date: Mon Aug 3 14:21:45 2026 +0900 fs/ntfs3: bound DeleteAttribute asize against rec->used in do_action [ Upstream commit 408216b66afd9ddadaba2dce56fd4af6793e95a2 ] In do_action()'s DeleteAttribute case (fslog.c:3316), attr is Add2Ptr(rec, roff) with roff taken from the on-disk lrh->record_off, and asize = le32_to_cpu(attr->size) is read straight out of the MFT record: asize = le32_to_cpu(attr->size); used = le32_to_cpu(rec->used); if (!check_if_attr(rec, lrh)) goto dirty_vol; ... memmove(attr, Add2Ptr(attr, asize), used - asize - roff); check_if_attr() (fslog.c:2869) walks the attribute chain from rec->attr_off and returns o == ro. Its loop breaks on ATTR_END, so ro may legitimately equal the offset of the ATTR_END marker; that is exactly how CreateAttribute appends to a record. But check_file_record()'s walk (fslog.c:2831) also stops at ATTR_END, so check_attr() never inspects the bytes there. When roff is the ATTR_END offset, those never-validated bytes are what gets read as attr->size, and used - asize - roff underflows. The read itself is also unbounded: roff is a u16 and attr->size is dereferenced at fslog.c:3317, before check_if_attr() has constrained roff at all, so it can be up to ~64K past a record_size-sized object. Commit 0ca0485e4b2e ("fs/ntfs3: validate rec->used in journal-replay file record check") added at fslog.c:2844 if (used < PtrOffset(rec, attr) + sizeof(attr->type)) return false; and its changelog names this very memmove. It bounds rec->used against the ATTR_END offset; it does not bound asize. With record_size 0x400, attr_off 0x38, a valid three-attribute chain ending in ATTR_END at 0x158 and used 0x160, a record whose four bytes at 0x15c read 0x100 gives used - asize - roff = 0x160 - 0x100 - 0x158 = 0xffffff08 i.e. a ~4 GiB memmove whose source and destination both run off the end of rec, a kmalloc(sbi->record_size) object (record.c:105). The equivalent non-replay path already refuses this. mi_remove_attr() performs the same removal and starts with (record.c:548): if (aoff + asize > used) return false; Apply the same bound, spelled as a subtraction to match the neighbouring cases, and move the attr->size read after check_if_attr() so that the header is known to lie inside the record before it is dereferenced. Requiring roff + SIZEOF_RESIDENT <= used rejects the ATTR_END offset without rejecting any real attribute: for an attribute the walk validated, roff + asize <= off(ATTR_END) <= used - 4, and any attribute a DeleteAttribute record can legitimately name carries a full resident header, so roff + SIZEOF_RESIDENT <= roff + asize <= used - 4. check_attr() itself imposes no lower bound on asize, so a crafted sub-header asize can still pass the first test; the second test then bounds it and the memmove stays inside the record. Reproduced by mounting a crafted image on v7.2-rc5, which already contains 0ca0485e4b2e, under KASAN. The image is an ordinary mkfs.ntfs volume with four bytes of one MFT record changed and a crafted $LogFile: BUG: KASAN: slab-out-of-bounds in do_action.isra.0+0x3211/0x83c0 Read of size 4294967048 at addr ffff888002423258 by task mount/66 CPU: 1 UID: 0 PID: 66 Comm: mount Not tainted 7.2.0-rc5 #3 Call Trace: kasan_report+0xce/0x100 kasan_check_range+0x105/0x1b0 __asan_memmove+0x23/0x60 do_action.isra.0+0x3211/0x83c0 log_replay+0x920a/0xd300 ntfs_loadlog_and_replay+0x3ef/0x510 ntfs_fill_super+0x1d23/0x4550 get_tree_bdev_flags+0x2ef/0x550 vfs_get_tree+0x82/0x2f0 fc_mount+0x10/0x1b0 path_mount+0x517/0x1df0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 66: __kasan_kmalloc+0x8f/0xa0 __kmalloc_noprof+0x1b4/0x460 mi_init+0x81/0x110 mi_get+0x6a/0x220 do_action.isra.0+0x1dbf/0x83c0 log_replay+0x920a/0xd300 ntfs_loadlog_and_replay+0x3ef/0x510 ntfs_fill_super+0x1d23/0x4550 The buggy address belongs to the object at ffff888002423000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 600 bytes inside of allocated 1024-byte region [ffff888002423000, ffff888002423400) KASAN reports the source side because __asan_memmove() (mm/kasan/shadow.c:94) validates src before dest and returns without copying. Both ends are out of bounds, and on a kernel built without KASAN the copy is performed. rec->used is also left at used - asize by fslog.c:3323 before the memmove, so the record stays inconsistent even when the copy is suppressed; the same mount goes on to report "ino=1a, mi_enum_attr" and marks the volume dirty. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Hyeontae Lee Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 0ea0755124dba3c9682a87adcee8b4b3ab57902f Author: Hyeontae Lee Date: Fri Jul 31 23:14:40 2026 +0900 fs/ntfs3: bound CreateAttribute asize against record_size in do_action [ Upstream commit fb0f0ef7b5a6bc761b372ce00764d4b6e0b91a47 ] In do_action()'s CreateAttribute case (fslog.c:3286), attr2 points into the on-disk log record and asize = le32_to_cpu(attr2->size) is therefore attacker-controlled on mount. The guard bounds asize only against the log record itself, Add2Ptr(attr2, asize) > Add2Ptr(lrh, rec_len) where rec_len is the client data length, and separately bounds dlen against the MFT record. Nothing bounds asize against record_size, but all three writes that follow are into rec, a kmalloc(sbi->record_size) buffer allocated by mi_init() (record.c:105): memmove(Add2Ptr(attr, asize), attr, used - roff); memcpy(attr, attr2, asize); rec->used = cpu_to_le32(used + asize); With record_size 0x400, roff 0x38, used 0x160 and asize 0x800 the memcpy writes 2048 bytes at rec + 0x38, 0x438 bytes past the allocation, and rec->used is left at 0x960. dlen is 0x18 here, so the existing dlen check passes: dlen bounds nothing about the size of the copy. The equivalent non-replay path already refuses this. mi_insert_attr() performs the same insert and starts with (record.c:488): if (used + asize > sbi->record_size) return NULL; Apply the same bound, spelled as a subtraction to match the neighbouring clause. used <= record_size holds here because check_file_record() validates it (fslog.c:2826) and is called on this record at fslog.c:3172; roff <= used - 4 follows from check_if_attr() together with the ATTR_END check at fslog.c:2844, so bounding used + asize bounds both copies. The sibling WriteEndOfFileRecordSegment case does the equivalent check against record_size at fslog.c:3277. Reproduced by mounting a crafted image on v7.2-rc5 under KASAN: BUG: KASAN: slab-out-of-bounds in do_action.isra.0+0x41f6/0x83a0 Write of size 2048 at addr ffff888005c74838 by task mount/69 CPU: 0 UID: 0 PID: 69 Comm: mount Not tainted 7.2.0-rc5-00300-g8ba098e6b6ff #2 Call Trace: kasan_report+0xce/0x100 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 do_action.isra.0+0x41f6/0x83a0 log_replay+0x920a/0xd300 ntfs_loadlog_and_replay+0x3ef/0x510 ntfs_fill_super+0x1d23/0x4550 get_tree_bdev_flags+0x2ef/0x550 vfs_get_tree+0x82/0x2f0 fc_mount+0x10/0x1b0 path_mount+0x517/0x1df0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 69: __kasan_kmalloc+0x8f/0xa0 __kmalloc_noprof+0x1b4/0x460 mi_init+0x81/0x110 mi_get+0x6a/0x220 do_action.isra.0+0x1db4/0x83a0 log_replay+0x920a/0xd300 ntfs_loadlog_and_replay+0x3ef/0x510 ntfs_fill_super+0x1d23/0x4550 The buggy address belongs to the object at ffff888005c74800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 56 bytes inside of allocated 1024-byte region [ffff888005c74800, ffff888005c74c00) Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Hyeontae Lee Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 650e0bbf510ad4a445d85780e7daf49954191905 Author: David Yang Date: Mon Oct 26 02:20:18 2026 +0800 net: hisilicon: hisi_femac: Stop the receiver before releasing the RX ring [ Upstream commit d54b21d824302af52d06574870817fbe14774dab ] hisi_femac_net_close() frees the receive ring while the RX address queue still holds every address that was pushed to IQ_ADDR. A port that keeps receiving then DMAs arrived frames into buffers that other slab caches have already taken back; on an EC6108V9C (hi3798mv100) the queue still held all 52 armed addresses right after the interface was closed, and had dropped to 43 after 15 s of broadcast traffic. Reset the port before the buffers are released, so that the receiver no longer holds any of their addresses. Fixes: 542ae60af24f ("net: hisilicon: Add Fast Ethernet MAC driver") Cc: stable@vger.kernel.org Signed-off-by: David Yang Link: https://patch.msgid.link/20261025182022.2959333-1-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9660398c59dea26abdb6eba6b93fd3466a9a7172 Author: Xia Yan Date: Thu Oct 22 17:08:09 2026 +0800 macvlan: fix passthru promiscuity accounting while down [ Upstream commit b6743653d134c9ef8436e2db1be1ad4c1e0d0091 ] macvlan_changelink() adjusts the lower device's promiscuity count when NOPROMISC changes, even if the passthru macvlan is down. The reference is acquired in macvlan_open() and released in macvlan_stop(), so a down interface has no reference to change. Clearing NOPROMISC while down leaves an extra reference after the next open/stop cycle. Setting it while down can remove a reference held by another user of the lower device. Guard the count adjustment with netif_running(dev). Keep storing the requested flags while down so the next open uses the new setting. Comparing changelink with open/stop exposed the unmatched count changes; the same issue was also described in earlier macvlan reviews. A netlink test on UML reproduced both DOWN cases before the fix and verified the expected counts afterwards. Repeated flag updates, two open/stop cycles, deletion and bidirectional small-frame delivery were also checked. Full x86_64 builds completed with WERROR disabled for allmodconfig, and WERROR and KASAN disabled for allyesconfig, including the resulting dependency changes. Neither comparison showed new diagnostics. Fixes: df8ef8f3aaa6 ("macvlan: add FDB bridge ops and macvlan flags") Link: https://lore.kernel.org/netdev/179170088566.434549.4699134797461783473@kernel.org/ Link: https://lore.kernel.org/netdev/20261016003009.2692872-1-kuba@kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Xia Yan Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20261022090809.12019-1-yanxia@cmss.chinamobile.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 87bce6c6efbdfad973b780975e27511ba17fd44b Author: Jesse Zhang Date: Mon Oct 12 12:19:15 2026 +0800 drm/amdkfd: evict the queues only once for CRIU PROCESS_INFO [ Upstream commit 8f3ecda0ab42fb5ba7310fe848013d3eff31b416 ] criu_process_info() evicts the queues of the process on every call, and each kfd_process_evict_queues() increments qpd->evicted, but CRIU UNPAUSE restores them only once. After PROCESS_INFO twice and UNPAUSE the queues stay evicted for good. On navi31, a barrier-AND packet on an HSA queue completes after PROCESS_INFO + UNPAUSE, but times out after PROCESS_INFO, PROCESS_INFO, UNPAUSE. The error path has a related problem: when kfd_process_evict_queues() itself fails, it has already rolled back its partial eviction, and the kfd_process_restore_queues() in the error path restores once more. Evict only when the queues are not paused yet, and on errors only undo an eviction done by this call. The barrier now completes after any number of PROCESS_INFO calls followed by UNPAUSE. Fixes: cd9f79103003 ("drm/amdkfd: CRIU Implement KFD unpause operation") Reviewed-by: Felix Kuehling Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit 4d79c9e3c32c677fcadf5ca10ab81ee0a4b81f99) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 8f654fea546a16d794c46afd81cdca2ccb4e6cf9 Author: Jiale Yao Date: Fri Oct 16 22:15:04 2026 +0800 drm/amdkfd: validate SRAT subtables before parsing [ Upstream commit 9866cb13ba4d39aa8fed34b765d4aecabe04f02e ] The KFD SRAT walker reads the first subtable length without checking that a header is present and trusts subsequent lengths when accessing CPU and generic affinity records. Invalid firmware lengths can therefore cause out-of-bounds reads. Validate the table header, every generic subtable range, and each supported typed record before reading its fields. Fixes: ddec8d3be0f8 ("drm/amdkfd: add ACPI SRAT parsing for topology") Reviewed-by: Alex Deucher Signed-off-by: Jiale Yao Signed-off-by: Alex Deucher (cherry picked from commit d76b655c98e8cc9e791b31502ad274f47dee2aae) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d85687dfbb72f739ae49e4a205f43530f7efeaab Author: Avi Weiss Date: Sun Oct 11 10:45:10 2026 +0300 drm/amd/display: Initialize missing TD-LUT programming inputs [ Upstream commit 167df3b94680b8670c4cacc08af232e3bfcab5ff ] dml_core_mode_programming() memsets (clears) its scratch structure before calculating TD-LUT settings, but does not initialize tdlut_mpc_width_flag or is_gfx11. Both inputs therefore remain false regardless of the plane configuration which can result in incorrect calculations. Initialize both fields using the same sources as the mode support path (now both paths are aligned). Fixes: 70839da63605 ("drm/amd/display: Add new DCN401 sources") Signed-off-by: Avi Weiss Signed-off-by: Ray Wu Reviewed-by: Harry Wentland Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit ad8d216e7d9fc050cdf39278e5fae17f61c36931) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 179bf8516d1276eda573245bbca6dc95f370aacb Author: Jesse Zhang Date: Tue Oct 13 13:17:53 2026 +0800 drm/amdkfd: split vram_pages of SVM ranges prefetched without a GPU mapping [ Upstream commit 52957e813f2f025c86e4aa6e86cb4963ef94fd00 ] When an SVM range is split, svm_range_split_pages() gives the new range the number of VRAM pages counted in its part of the dma_addr arrays and subtracts it from the old range. Pages migrated to VRAM by a prefetch have no dma_addr entries until the range is mapped on a GPU, e.g. with no ACCESS attribute, or with XNACK off before the delayed restore worker mapped it, so the new range gets 0 and the old one keeps the count for both. Migrating the parts back to system memory then gets the accounting wrong: the old part keeps a VRAM page count after all its pages are gone, so its svm_bo is never freed, and the new part underflows. On navi31, as an unprivileged process: prefetch 4 MiB to the GPU, prefetch the upper 2 MiB and then the lower 2 MiB back to system memory: Recorded vram pages(0x0) should not be less than migration pages(0x200). WARNING: ../amdkfd/kfd_migrate.c:922 at svm_migrate_vram_to_ram+0xbdc/0xcd0 [amdgpu] and /sys/class/kfd/kfd/proc//vram_ stays at 4194304 until the process exits. Without dma_addr arrays, the split is still exact when the old range is completely in VRAM, which is what a prefetch of the whole range leaves. Give the new range all its pages in that case. The warning is gone and the VRAM usage drops back to 0. This doesn't cover a range that is only partly in VRAM without dma_addr arrays, e.g. after a partial migration, since svm_migrate_ram_to_vram() only counts the pages it actually migrated. That would need VRAM residency to be tracked per page independently of dma_addr. v2: - Rename counted to has_dma_addr and compare against old->npages (Philip) - Mention the XNACK off case and the partial migration limitation (Philip) Fixes: 006ad514a50c ("drm/amdkfd: Use partial hmm page walk during buffer validation in SVM") Reviewed-by: Philip Yang Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit 7ca6f3359b557a267c7b07a2fd748b1473395e10) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 4be3d15d3b2f6e596c11ee3c0b287477dc2a8b41 Author: Luigi Lauro Date: Fri Oct 16 05:16:36 2026 +0200 drm/amd/display: take a runtime PM reference only when a CRTC turns on [ Upstream commit b456f591f925fbd6b33770d0eec1b51c2f9d41c1 ] amdgpu_dm_commit_streams() takes a runtime PM reference for every active CRTC that needs a modeset and has a new stream, but amdgpu_dm_atomic_commit_tail() drops one only for each CRTC that goes from active to inactive. A modeset of a CRTC that is already active (a mode change, or anything else that needs a full modeset) therefore leaks one reference. Once that has happened, the usage count no longer returns to zero with every CRTC off, and the device cannot runtime suspend again until reboot. The two also disagree the other way when a CRTC turns on without a stream ("Failed to create new stream"): no reference is taken, but one is dropped when it turns off. Take the reference in the loop that counts the disabled CRTCs, on the mirror condition: when the CRTC goes from inactive to active, which is what the commit that added it intended ("every time we enable a previously disabled CRTC"). Each active CRTC then holds exactly one reference. Tested on an RX 9070 XT (Navi 48) over OCuLink, with the change backported to 7.2.9: an unplugged connector forced on, then mode A on a CRTC, mode B on the same active CRTC, and the CRTC off, three rounds in a row. The usage count rose by 3 with the stock module, by 0 with this patch, and by 3 again after reloading the stock module. Fixes: 97028037a38a ("drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail()") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5951 Assisted-by: Claude:claude-opus-5-5 Reviewed-by: Alex Deucher Signed-off-by: Luigi Lauro Signed-off-by: Alex Deucher (cherry picked from commit 59ef9a435499777b8e1c4e0eff52f813c64fb920) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit af074bdcbb54807612a07b497d99008d2e4745fb Author: Olivier Kaloudoff Date: Tue Oct 13 20:53:12 2026 +0200 drm/amdkfd: stop restore retries on device unplug [ Upstream commit 3254ed0b15f2fe656c9cb36ccb59b92422440bf8 ] amdgpu_amdkfd_restore_userptr_worker() and svm_range_restore_work() reschedule themselves when validation fails with evicted objects pending. After a surprise removal the restore paths fail with -ENODEV permanently, so rescheduling just spins the worker uselessly until cancel_delayed_work_sync() in fini finally stops it - which can take a while, since process teardown itself is delayed by the dead device. Treat -ENODEV as terminal in both workers. Cc: Xiaogang Chen Signed-off-by: Olivier Kaloudoff Signed-off-by: Felix Kuehling Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit 266fab83139600e58db7e900e930c722e619b78c) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 4dedc1a5554ab3163cb97a9446bddf8e357c98a1 Author: Zhao Gongyi Date: Fri Oct 23 20:12:33 2026 +0800 arm64/mm: restrict transparent contpte mappings to valid PTEs [ Upstream commit 486d396b19e93f6e56e0a0ba96c14a9ccc1a5977 ] The transparent contpte layer treats PTE_CONT as software grouping state. When a valid PTE has PTE_CONT set, the contpte helpers may align an operation to a CONT_PTE_SIZE block and operate on the whole block. The current single-PTE helpers use pte_valid_cont() to identify such groups; this is a helper contract, not an architectural restriction on using PTE_CONT with present-invalid descriptors. Explicit users such as hugetlb manage their contiguous encodings separately. contpte_set_ptes() currently sets PTE_CONT from alignment alone. Batched set_ptes() users can therefore install present-invalid PTEs with PTE_CONT set, for example mprotect(PROT_NONE), NUMA hinting through modify_prot_commit_ptes(), fork() copying a PROT_NONE large folio, or a PMD split installing PAGE_NONE PTEs. This is not a hardware programming problem: invalid descriptors are not translated, so the hardware ignores descriptor bits such as PTE_CONT. It is a software-state problem. Some arm64 fast paths, such as test_and_clear_young_ptes(), test pte_cont() directly instead of pte_valid_cont(). In the observed failure, mprotect(PROT_NONE) installed a full CONT_PTE_SIZE range of present-invalid PTEs with PTE_CONT set. MADV_GUARD_INSTALL then zapped one PTE. The nr == 1 clear_full_ptes() path only unfolds pte_valid_cont() entries, so the neighbouring present-invalid entries kept PTE_CONT while the target entry became a guard marker. clear_refs_pte_range() then reached the marker through: ptep_test_and_clear_young() test_and_clear_young_ptes() contpte_test_and_clear_young_ptes() contpte_align_addr_ptep() __ptep_test_and_clear_young() The marker changed from old_pte=0x00000000000047c0 to new_pte=0x00000000000043c0 by clearing PTE_AF. For swap PTEs, bit 10 is part of the swap type field, bits 6-10: 0x47c0 is SWP_PTE_MARKER with offset 4, while 0x43c0 has type 15 and is decoded as an ordinary swap entry. Zap later warned in swap_put_entries_direct() with a bad swap entry. Present-invalid PTEs could retain PTE_CONT as software grouping state, but their single-PTE modification paths would then need to recognize and unfold those groups consistently. Since current helpers mostly use pte_valid_cont() for membership, avoid creating present-invalid transparent contpte groups in contpte_set_ptes(). They bring no hardware benefit while invalid, and eligible valid ranges can be grouped again when they are installed. The public set_ptes() wrapper already clears PTE_CONT before calling contpte_set_ptes(). Return invalid PTEs through __set_ptes() directly, and warn if a future direct caller unexpectedly passes an invalid PTE with PTE_CONT set. This is triggerable by a user process against its own address space. On systems running with panic_on_warn, the warning becomes a denial of service. Fixes: 4602e5757bcc ("arm64/mm: wire up PTE_CONT for user mappings") Cc: stable@vger.kernel.org Reviewed-by: Baolin Wang Tested-by: Lance Yang Signed-off-by: Zhao Gongyi Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 778a4553b1c6ef05dd356503a2a227c4fb449072 Author: Zhongqiu Han Date: Tue Oct 27 21:33:31 2026 +0800 cpufreq: stats: Fix potential out-of-bounds access in deferred reset [ Upstream commit 8a702989677216489e471a6f27599da53f753567 ] cpufreq_stats_create_table() sets stats->last_index to -1 if policy->cur is not in the frequency table. It then stays at -1, because cpufreq_stats_record_transition() returns early on old_index == -1 before it gets to update last_index. Commit 46a310b80bc2 ("[CPUFREQ] Don't set stat->last_index to -1 if the pol->cur has incorrect value.") added that check. However, since commit 40c3bd4cfa6f ("cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()"), the stats reset is deferred to the beginning of cpufreq_stats_record_transition(), before that check, and cpufreq_stats_reset_table() ends with an unconditional cpufreq_stats_update(). So if the "reset" attribute is written while last_index is -1, the next frequency transition accesses time_in_state[-1]. Fix it by also returning early on last_index == -1 in cpufreq_stats_reset_table(). Fixes: 40c3bd4cfa6f ("cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()") Cc: 5.10+ # 5.10+ Signed-off-by: Zhongqiu Han Link: https://patch.msgid.link/20261027133332.377546-1-zhongqiu.han@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f3996cc5c2816401a394e7d4cad9f7b2144c4adc Author: Tiezhu Yang Date: Tue Oct 27 22:51:35 2026 +0800 LoongArch: Fix perf hardware breakpoint failure via installation [ Upstream commit f5c0f8427469e703465c719c4304ce91282a32eb ] In hw_breakpoint_control(), the logic to enable CSR_PRMD_PWE (global watchpoint enable) incorrectly relies on TIF_LOAD_WATCH. This thread flag is only set during ptrace operations, meaning that the standard hardware breakpoints created via perf_event_open() will never have this flag set. As a result, the CSR_PRMD_PWE switch is skipped, leaving the hardware breakpoint completely inactive in perf usage. Fix this by decoupling the CSR_PRMD_PWE from the ptrace specific flag TIF_LOAD_WATCH, which ensures that CSR_PRMD_PWE is enabled whenever a hardware breakpoint is installed. Here is a user-space reproducer to demonstrate the issue: (1) Test program (test_perf_install.c): #include #include #include #include #include #include static int var = 0; int main(void) { size_t count = 0; struct perf_event_attr attr = { .type = PERF_TYPE_BREAKPOINT, .size = sizeof(attr), .bp_type = HW_BREAKPOINT_W, .bp_addr = (unsigned long)&var, .bp_len = HW_BREAKPOINT_LEN_1, .exclude_kernel = 1, }; int fd = syscall(__NR_perf_event_open, &attr, 0, -1, -1, 0); ioctl(fd, PERF_EVENT_IOC_ENABLE, 0); asm volatile("st.b %1, %0" : "=m"(var) : "r"(11) : "memory"); ioctl(fd, PERF_EVENT_IOC_DISABLE, 0); read(fd, &count, sizeof(size_t)); printf("Watchpoint counts: expected = 1, actual = %zu\n", count); close(fd); return 0; } (2) Test steps: $ gcc test_perf_install.c -o test_perf_install $ ./test_perf_install (3) Test results: Without this patch: Watchpoint counts: expected = 1, actual = 0 With this patch: Watchpoint counts: expected = 1, actual = 1 Cc: stable@vger.kernel.org Fixes: 3892b11eac5a ("LoongArch: Check TIF_LOAD_WATCH to enable user space watchpoint") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 7e56651033584f16c019ff2a223c0f9417230f39 Author: Tiezhu Yang Date: Tue Oct 27 22:51:35 2026 +0800 LoongArch: Only send SIGTRAP signal if necessary in do_watch() [ Upstream commit f087903018e35d38b8932e18b010ee2e8699d1a1 ] In do_watch(), the kernel unconditionally forces a SIGTRAP signal at the end of the handler via force_sig(SIGTRAP). This is essential for ptrace operations, but it severely disrupts standard perf_event usage. Under normal perf usage, it is not necessary to force a SIGTRAP signal on every hit. Forcing it unnecessarily aborts the target process if no user-space signal handler is registered, which violates performance monitoring behaviors and injects context switch overheads. However, a conditional check using only 'current->ptrace' would block legitimate user-requested signals when a perf_event is configured with 'attr.sigtrap = 1' for asynchronous user-space tracking. Fix this by refactoring breakpoint_handler() and watchpoint_handler() to return a boolean status indicating whether any triggered breakpoint explicitly requires a signal notification. Update do_watch() to enforce the SIGTRAP signal only when the process is actively being debugged via ptrace, or when the underlying perf_event infrastructure specifically demands it via 'attr.sigtrap'. Cc: stable@vger.kernel.org Fixes: 424421a7f34c ("LoongArch: ptrace: Add hardware single step support") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 1c03f498292ae85756b955ba6ed2213f299cc71c Author: Tiezhu Yang Date: Tue Oct 27 22:51:35 2026 +0800 LoongArch: Fix architectural naming typo for CSR_FWPS_SKIP [ Upstream commit f322ebfdfda2bce91fb1d3fb0072c735051fed85 ] According to the LoongArch Reference Manual, the single-step 'Skip' bit resides in the instruction breakpoint status register (CSR.FWPS), rather than the configuration register (CSR.FWPC). Furthermore, the kernel code comments also explicitly document it as "CSR.FWPS.Skip", yet the macro was erroneously defined as CSR_FWPC_SKIP and used as such in traps.c and hw_breakpoint.c. This mismatch creates architectural naming confusion. Fix this by renaming the macro from CSR_FWPC_SKIP to CSR_FWPS_SKIP to precisely match the manual and comments. Also, update all call sites to align with the rectified definition. Cc: stable@vger.kernel.org Fixes: 424421a7f34c ("LoongArch: ptrace: Add hardware single step support") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit b121d8852e8cedd0a3bd96eeaffc1e1c8f6ff9b3 Author: Tiezhu Yang Date: Tue Oct 27 22:51:34 2026 +0800 LoongArch: Fix bitmask corruption in update_bp_registers() [ Upstream commit 30c52672bf456decf675c11f3c65acd73a6bcca8 ] In update_bp_registers(), when disabling a LOAD or STORE watchpoint, the code attempts to clear the bit of LoadEn or StoreEn by using the standard bit-clearing pattern. However, due to the omission of parentheses, the bitwise NOT operator '~' takes higher precedence than the left shift operator '<<'. Then: (1) ~0x1 << MWPnCFG3_LoadEn evaluates to "(~0x1) << 8 = 0xFFFFFE00", (2) ~0x1 << MWPnCFG3_StoreEn evaluates to "(~0x1) << 9 = 0xFFFFFC00", that incorrectly clears all configuration fields in the lower 8 bits. These fields in the lower 8 bits contain critical configurations such as DSOnly (bit 0), PLV0-PLV3 privilege levels (bits 1-4), and LCL (bit 7). Writing back these corrupted values severely breaks configuration isolation and ruins the hardware watchpoint states. Add parentheses to ensure the correct evaluation order, so that only the targeted LoadEn/StoreEn bit is cleared while preserving the other crucial configuration bits in the lower 8 bits. Cc: stable@vger.kernel.org Fixes: edffa33c7bb5 ("LoongArch: Add hardware breakpoints/watchpoints support") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 6cb32a6bf99c5c84d9eb6fdd1056fce203c27dbc Author: Tiezhu Yang Date: Tue Oct 27 22:51:24 2026 +0800 LoongArch: Remove redundant call in update_bp_registers() [ Upstream commit 23534c6efeb718e8a4d9107fa7d6707b5b1f5859 ] In update_bp_registers(), there is a duplicate call to write_wb_reg() when enabling an execute breakpoint: write_wb_reg(CSR_CFG_CTRL, i, 0, CTRL_PLV_ENABLE); write_wb_reg(CSR_CFG_CTRL, i, 0, CTRL_PLV_ENABLE); The two lines are completely identical. Remove the redundant call to clean up the code and eliminate unnecessary register writes. Cc: stable@vger.kernel.org Fixes: edffa33c7bb5 ("LoongArch: Add hardware breakpoints/watchpoints support") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 7a83149ed9c25fe4f2f0f59de61ea11ea24f542b Author: Tiezhu Yang Date: Tue Oct 27 22:51:23 2026 +0800 LoongArch: Remove arch-specific __smp_mb__{before,after}_atomic() [ Upstream commit 85cebdfee765e92e748e71b9b91889eef5988282 ] When running BPF selftest "test_progs -t timer_lockup" on a LoongArch machine, the kernel intermittently experiences soft lockups and panics in hrtimer_cancel(). The root cause is that the bpf_timer_cancel() implementation relies on smp_mb__after_atomic() to provide a full data barrier after a relaxed atomic_inc() to ensure the proper store-load ordering before performing lockless dependency checks on weakly-ordered architectures, such as on LoongArch, but the current definition of smp_mb__after_atomic() is just a plain compiler barrier. This allows a subsequent read to bypass the prior write due to store- load reordering, enabling concurrent CPUs to simultaneously bypass the software deadlock detection, enter hrtimer_cancel(), and then trigger a severe ABBA deadlock in the hrtimer core. Moreover, there are hundreds of smp_mb__after_atomic() call sites across the core kernel (kernel/, drivers/, mm/, net/, fs/) that currently lack necessary full data barriers on LoongArch, which have potential risks. To comply with the LKMM specification, fix this by removing the arch- specific definition of __smp_mb__after_atomic(), so that this macro can automatically fall back to the generic definition in asm-generic that maps to __smp_mb() and emits the required hardware DBAR instruction. While at it, do the same thing for __smp_mb__before_atomic(). With this patch the BPF timer_lockup selftest was stressed for millions consecutive loops on a physical LoongArch machine, without encountering any further lockups. Cc: stable@vger.kernel.org # 6.7+ Fixes: affef66b65889a0e ("LoongArch: Relax memory ordering for atomic operations") Closes: https://lore.kernel.org/loongarch/CAK3+h2xOSEZUHhou7N2cRL-aGrZCNSm45g+P7thObMe+fpgYCA@mail.gmail.com/ Reported-by: Vincent Li Reviewed-by: Xi Ruoyao Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 8c25c70236a418fea6c5082431e65e3bdf22bde9 Author: Huacai Chen Date: Tue Oct 27 22:51:23 2026 +0800 LoongArch: Use pa_to_nid()/nid_to_addrbase() rather than hard-code [ Upstream commit 244eb26bbd152896f976db6415550993cd60b46d ] NODE_ADDRSPACE_SHIFT is 44 now but may be changed in future, so use pa_to_nid()/nid_to_addrbase() rather than hard-code. Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit c364adf6752b147225f691dbe596a5d80b8c33d1 Author: Peter Ujfalusi Date: Tue Oct 27 10:38:40 2026 +0200 ASoC: hdac_hda: Balance the runtime PM disable in codec remove [ Upstream commit f26c0d5f91d918bb66cbbc8916f41836adb38346 ] hdac_hda_codec_remove() disables runtime PM of the codec device before releasing the HDA link and calling the codec driver's remove callback, so that no runtime resume can race with the teardown and access the link or the already freed codec driver data. snd_hda_codec_cleanup_for_unbind() then disables runtime PM again. On the next probe snd_hda_codec_register() enables runtime PM only once, leaving it disabled after the ASoC card or the codec driver has been unbound and bound again: the codec stays powered and runtime_status reads 'unsupported'. Re-enable runtime PM at the end of hdac_hda_codec_remove() to balance its own disable. The codec remains disabled until it is registered again. Fixes: c3ec8ac82105 ("ASoC: hdac_hda: fix memleak on module unload") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20261027083840.28813-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c45688be8415a9a5dff050a81a3edea35cf7718f Author: Eric Dumazet Date: Mon Oct 26 09:20:35 2026 +0100 ixgbe: reserve TX timestamp after skb preparation [ Upstream commit f75062536e2d45ee182828f0e47e0124be2fdc8d ] ixgbe_xmit_frame_ring() takes an extra skb reference with skb_get() for the pending TX timestamp before preparing the skb for transmit. Several of the following steps may need to reallocate the skb head: - ixgbe_tso() calls skb_cow_head(), which reaches pskb_expand_head() when the header is cloned (e.g. a packet tap holds a clone). - ixgbe_tx_csum() falls back to skb_checksum_help() for unsupported checksum offsets, which can call pskb_expand_head() through skb_ensure_writable(). - With DCB and a software VLAN tag, skb_cow_head() is called to rewrite the VLAN priority. pskb_expand_head() used to BUG() on shared skbs. Since commit c7d8bc3dd511 ("net: skbuff: don't BUG() on bad arguments to pskb_expand_head()") it returns -EINVAL instead, so these packets are dropped (TSO, DCB) or sent with an unfinished checksum (skb_checksum_help() errors are ignored by ixgbe_tx_csum()). Reserve the TX timestamp right before ixgbe_tx_map(), after all skb preparation, as i40e and ice already do. The timestamp request remains covered on the FCoE path, and the cleanup on ixgbe_tx_map() failure is unchanged. Fixes: 891dc0821d20 ("ixgbe: Add ptp work item to poll for the Tx timestamp") Cc: stable@vger.kernel.org Signed-off-by: Eric Dumazet Reviewed-by: Maciej Fijalkowski Link: https://patch.msgid.link/20261026082035.335770-1-edumazet@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 151957c54443a1b7d4e9e03e7fd65c852ea43b9c Author: Peter Ujfalusi Date: Tue Oct 27 09:28:35 2026 +0200 ALSA: hda: Reject codec reset on ASoC (ext_ops) buses [ Upstream commit a4311e9447bbb219044db38897f95be112f46a8a ] Writing to the reconfig or clear sysfs nodes of a codec handled by ASoC (SOF via hdac_hda, AVS via codecs/hda) hangs the writer. snd_hda_codec_reset() sets card->shutdown and calls device_release_driver(). With ext_ops the driver unbind unregisters the ASoC component, which unbinds and frees the whole ASoC card: - snd_card_disconnect() returns early as card->shutdown is already set, so the card's child devices are not removed and snd_card_free() waits for the card release forever. - Even without that, freeing the card removes the codec's hwdep device, which owns the sysfs node the reset was issued from, deadlocking in kernfs while waiting for the active write to finish. The legacy HDA driver keeps the card across a driver rebind, ASoC does not, so the reset cannot be supported there. Return -EOPNOTSUPP and skip the misleading "codec is being used" messages in the callers. Fixes: 6bae5ea94989 ("ASoC: hdac_hda: add asoc extension for legacy HDA codec drivers") Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222182 Signed-off-by: Peter Ujfalusi Reviewed-by: Cezary Rojewski Link: https://patch.msgid.link/20261027072835.4796-1-peter.ujfalusi@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0a49ac3e05864a0a2758b621d97ff44e94cf45dc Author: Dominik Maier Date: Sun Oct 25 21:07:40 2026 +0100 loop: check for read-write open mode on LOOP_SET_STATUS in lo_compat_ioctl() [ Upstream commit 87409eedc543d288cdd49c2174f7d61eca7b8db5 ] lo_ioctl() checks for (mode & BLK_OPEN_WRITE) || capable(CAP_SYS_ADMIN) before allowing LOOP_SET_STATUS or LOOP_SET_STATUS64, but not lo_compat_ioctl(), the handler used by 32-bit user space on 64-bit kernels. As a result, on 64-bit kernels with CONFIG_COMPAT=y, a 32-bit unprivileged user-space process holding a read-only (O_RDONLY) file descriptor to an active /dev/loopN device can issue a compat LOOP_SET_STATUS ioctl to modify lo_offset, clear lo_sizelimit to 0 (exposing backing-file data past the configured limit), or alter lo_flags. Enforce the same (mode & BLK_OPEN_WRITE) || capable(CAP_SYS_ADMIN) check on LOOP_SET_STATUS in lo_compat_ioctl(). Cc: stable@vger.kernel.org Assisted-by: ARTIST LLM Signed-off-by: Dominik Maier Reviewed-by: Bart Van Assche bvanassche@acm.org Link: https://patch.msgid.link/20261025200740.2064379-1-dmnk@google.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c0346288dcc97ddb1739f56dc35703258caaa9ea Author: Paul Moses Date: Wed Oct 21 22:47:33 2026 +0000 xsk: restore UMEM flags after failed pool assignment [ Upstream commit b88b826ec54a06f48a42580c609ba81293ebec8e ] xp_assign_dev() sets XDP_UMEM_SG_FLAG before checking whether the device supports multibuffer zero-copy. If assignment fails, xsk_bind() destroys the pool but retains the registered UMEM. A subsequent bind without XDP_USE_SG inherits the stale flag. The flag also changes RX buffer sizing after DMA mapping. On igc, a failed SG bind followed by a non-SG retry with 4096-byte chunks and 1792 bytes of headroom passes admission with 2048 bytes, but programs a 1024-byte RX buffer. On I225-V hardware, an ordinary 1514-byte frame is truncated to 1024 bytes or 1008 with RX timestamps enabled. Restoring the original flags eliminates the truncation in both cases. Save the UMEM flags before assignment and restore them on failure. Discovered during development of AF_XDP changes for igc. Fixes: d609f3d228a8 ("xsk: add multi-buffer support for sockets sharing umem") Cc: stable@vger.kernel.org Signed-off-by: Paul Moses Acked-by: Maciej Fijalkowski Link: https://patch.msgid.link/20261021224705.2078753-1-p@1g4.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d6f53958447d3eb63ee5e5a9438d7b693fa23ebd Author: Yingjie Wang <1075151112@qq.com> Date: Fri Oct 23 22:40:36 2026 +0800 tcp: limit tcp_tso_rtt_log to a valid shift count [ Upstream commit 850a7225bc61cdfaf0c4b02ff341ae7cb54902f5 ] tcp_tso_autosize() right-shifts the u32 returned by tcp_min_rtt() by sysctl_tcp_tso_rtt_log. The sysctl uses proc_dou8vec_minmax() without an upper bound, so it accepts values through 255. Values above 31 make the shift undefined. A process with CAP_NET_ADMIN in the target network namespace can set the per-netns sysctl. With CONFIG_UBSAN_SHIFT=y, setting it to 32 and sending TCP data over loopback triggers: UBSAN: shift-out-of-bounds in net/ipv4/tcp_output.c:2264:30 shift exponent 32 is too large for 32-bit type 'unsigned int' Call Trace: __ubsan_handle_shift_out_of_bounds tcp_tso_segs tcp_write_xmit __tcp_push_pending_frames tcp_push tcp_sendmsg_locked Limit the sysctl to 31, the largest valid shift count for a u32, and document the accepted range. Writes of larger values now fail with -EINVAL. On a UBSAN/KASAN build of the net tree, values 0 and 31 remained accepted, values 32 and 255 returned -EINVAL, and TCP traffic with the valid boundary values produced no sanitizer diagnostics. Fixes: 65466904b015 ("tcp: adjust TSO packet sizes based on min_rtt") Cc: stable@vger.kernel.org Signed-off-by: Yingjie Wang <1075151112@qq.com> Reviewed-by: Jiayuan Chen Reviewed-by: Neal Cardwell Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/tencent_31D2FFCCE76C50A695A1270151F825E90906@qq.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b2d2abab10c0c64c39b468a75d69845ffdcaba79 Author: Miquel Raynal Date: Wed Sep 30 19:24:48 2026 +0200 dt-bindings: clock: ma35d1: Document the missing crystal inputs [ Upstream commit ea1f41802312e77b58113146a060fb0546b2234d ] The MA35D1 clock controller takes two crystal oscillator inputs from the board: - HXT, a high-speed 24 MHz crystal for most of the system - LXT, a low-speed 32.768 kHz crytal for the RTC and low power modes So far the binding was expecting a single crystal. The example named it HXT, but no real definition for it was given. LXT was not even described. In order to remain backward compatible, we will continue to allow either one (HXT) or two (HXT then LXT) input clocks. I propose to give those phandles a name to clarify what these entries expect, but I'm not listing the clock-names property in the required block, for backward compatibility. The rates are fixed by the TRM, so even if the second oscillator is not described, the OS can make an educated guess. Fixes: 2f8b5eb589cb ("dt-bindings: clock: nuvoton: add binding for ma35d1 clock controller") Cc: stable@vger.kernel.org Reviewed-by: Krzysztof Kozlowski Signed-off-by: Miquel Raynal Link: https://patch.msgid.link/20260930-perso-ma35d1-upstream-clk-v6-2-48937ee6c9bb@bootlin.com Signed-off-by: Jerome Brunet Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 5b2fc8e445c37c1b391413b90192aab25e391cda Author: Ido Schimmel Date: Sun Oct 25 09:17:28 2026 +0200 ipmr: fully initialize the synthetic IP header in ipmr_get_route() [ Upstream commit 134351edc28e083c61012b6c69e8e54dd7fa5bcc ] For an unresolved multicast route query, ipmr_get_route() builds a synthetic IP header in the headroom obtained from skb_realloc_headroom(), which does not zero the memory it allocates. Only a few fields are initialized, leaving others as stale heap contents. ipmr_cache_report() copies this header into the IGMPMSG_NOCACHE report that is queued to the mroute socket, so a recvmsg() on that socket leaks the uninitialized bytes to user space: the 'tos' field [1] and the 'id' and 'frag_off' fields [2]. Fix by zeroing the IP header before filling in the few fields that are used, so that the entire header is initialized, as in ip6mr_get_route(). [1] BUG: KMSAN: kernel-infoleak in _copy_to_iter raw_recvmsg Uninit was stored to memory at: ipmr_cache_report ipmr_cache_unresolved ipmr_get_route Uninit was created at: pskb_expand_head skb_realloc_headroom ipmr_get_route Byte 1 of 28 is uninitialized [2] BUG: KMSAN: kernel-infoleak in _copy_to_iter raw_recvmsg Uninit was stored to memory at: ipmr_cache_report ipmr_cache_unresolved ipmr_get_route Uninit was created at: pskb_expand_head skb_realloc_headroom ipmr_get_route Bytes 4-7 of 28 are uninitialized Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/0545f0c83f5ee2f6696210f87268e811ef655715.1792476357.git.zhilinz%40nebusec.ai Signed-off-by: Ido Schimmel Reviewed-by: Hangbin Liu Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20261025071729.34967-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 727bda272a2f5d5db5f2bf2247938ab58a516233 Author: Jiayuan Chen Date: Fri Oct 23 18:45:27 2026 +0800 bonding: fix out-of-bounds read of arp_ip_target [ Upstream commit a81513bf5bdf29cf00c0a11f56be515c1ec260f4 ] arp_ip_target is a module parameter array with BOND_MAX_ARP_TARGETS entries. In the loop parsing it in bond_check_params(), arp_ip_count is the number of accepted targets, while i is the index into arp_ip_target. Invalid and duplicate entries are skipped without bumping arp_ip_count, so bounding the loop with arp_ip_count lets i run past the end of arp_ip_target, e.g. 16 targets with one duplicate: BUG: KASAN: global-out-of-bounds in bond_check_params.constprop.0+0x1148/0x1440 Read of size 8 at addr ffffffff96e9ee00 by task swapper/0/1 Call Trace: dump_stack_lvl+0x91/0xf0 print_report+0xd1/0x630 kasan_report+0xf3/0x130 __asan_report_load8_noabort+0x14/0x30 bond_check_params.constprop.0+0x1148/0x1440 bonding_init+0x13/0xe0 do_one_initcall+0xe7/0x5b0 kernel_init_freeable+0xa91/0x1120 kernel_init+0x24/0x220 ret_from_fork+0x5b3/0x820 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the variable: arp_ip_target+0x80/0xa0 Bound the loop with i instead. arp_ip_count never exceeds i, so it stays within BOND_MAX_ARP_TARGETS too. Fixes: 5a5c5fd48e3b ("bonding: arp_ip_count and arp_targets can be wrong") Cc: stable@vger.kernel.org Signed-off-by: Jiayuan Chen Reviewed-by: Fernando Fernandez Mancera Reviewed-by: Nikolay Aleksandrov Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20261023104528.232427-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8c0f5e2babfa63b13c2bf0b9624ce519fd1d2207 Author: Wei Jie Law Date: Wed Oct 21 10:03:10 2026 +0800 net: usb: pegasus: check rx pkt_len against the received length [ Upstream commit efee699f6de06611234ef9b0abd52db1340e5452 ] read_bulk_callback() takes the frame length from the device, from the receive header on the 0x8513 and from the trailing status bytes on the other chips, and only checks it against PEGASUS_MTU before passing that many bytes up the stack. In two cases the stack then uses bytes that the device did not send: - A device that sends a short transfer but claims a long frame gets the stale or uninitialized remainder of the receive skb delivered as packet data. - A device that claims a frame shorter than an Ethernet header gets past the check as well. eth_type_trans() takes pkt_type from h_dest and the protocol from h_proto without checking skb->len. If the transfer is also short, those come from bytes left in the skb by an earlier transfer, or from uninitialized memory. Drop frames shorter than ETH_HLEN, and frames whose claimed length, plus the 0x8513 header, does not fit in the bytes actually received, and count them as length errors. urb->actual_length never exceeds the PEGASUS_MTU sized transfer buffer, so this also covers the existing PEGASUS_MTU check. Valid Ethernet frames are at least 60 bytes long without the FCS, so they are not affected. Found by code review with LLM assistance. With an emulated USB device, a 101-byte transfer claiming a 1500-byte frame was passed up as a 1500-byte packet before this change and is dropped after it, and frames claiming 0, 4 and 13 bytes were passed up and are now dropped and counted in rx_length_errors. The extra bytes happened to be zero in the first test, so disclosure of actual kernel data was not demonstrated. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Wei Jie Law Reviewed-by: Simon Horman Link: https://patch.msgid.link/20261021020310.34045-3-law.wei.jie@gt.tech.gov.sg Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c647d22a85e11940062f8ae6f1ec18b1823b8b77 Author: Srinivas Kandagatla Date: Fri Oct 23 18:13:11 2026 +0100 ASoC: codecs: wsa884x: Accept temperatures across the full trim range [ Upstream commit 00535515e3c14fbee20de4a1aa61cfb3390f0f50 ] wsa884x_get_temp() rejects any reading outside 5..45 degC with -EAGAIN. A speaker that has been playing, or sits in a warm laptop, easily runs above 45 degC, so its temperature becomes unreadable when it matters. The check only needs to drop bogus conversions, such as the all-zero reading before the PA is first enabled. Bound it by the -10..150 degC two-point trim range instead. Fixes: 6b99dc62d940 ("ASoC: codecs: wsa884x: Implement temperature reading and hwmon") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20261023171316.819857-3-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 520bb647f67e5a2535e981837606dee9b0da97fe Author: Val Packett Date: Fri Oct 16 03:29:17 2026 -0300 ASoC: qcom: qdsp6: q6afe: fix clk vote response type mismatch [ Upstream commit f3c7bee984aa0ba2b48a44e16a6f3ec2c27f851e ] The response sent by the firmware when requesting a clock vote (opcode AFE_CMD_RSP_REMOTE_LPASS_CORE_HW_VOTE_REQUEST) does not actually have the same opcode + status payload as APR_BASIC_RSP_RESULT. Rather, it returns one single u32 which is the client_handle that must be used in future unvote requests for the same clock. As a result of this type confusion, the status returned by the callback to q6afe_vote_lpass_core_hw was actually an out-of-bounds read. It was only interpreted as success (0) most of the time due to luck, but there are some reports of random errors such as: [ 20.961100] qcom-q6afe aprsvc:service:4:4: AFE failed to vote (3) [ 20.961131] Failed to prepare clk 'core': -110 Fix by correctly interpreting the response as a single u32, and actually store it as the client_handle to ensure unvote would work correctly. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/5976946.DvuYhMxLoT@antlia/ Fixes: 55e07531d922 ("ASoC: q6dsp: q6afe: add lpass hw voting support") Reviewed-by: Srinivas Kandagatla Signed-off-by: Val Packett Link: https://patch.msgid.link/20261016063536.598610-1-val@packett.cool Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 87f72492245bcc04a9145315dd44f0493988b9a9 Author: Alex Markuze Date: Tue Oct 20 08:47:30 2026 +0000 ceph: fix uninitialized err in ceph_netfs_issue_read() [ Upstream commit 823d21c78453fcdf58dbd8ecefbb41f4f3eb6540 ] ceph_netfs_issue_read() declares err without an initializer. On the unencrypted, non-sparse success path nothing assigns it, then the out: label does if (err) netfs_read_subreq_terminated(subreq). With CONFIG_INIT_STACK_ALL_PATTERN, err is 0xaaaaaaaa (nonzero), so the subrequest is terminated while the OSD READ is still in flight. netfs then frees the rolling buffer that the OSD iterator still points at, causing a KASAN UAF / oops, and finish_netfs_read() terminates the same subrequest a second time. CONFIG_INIT_STACK_ALL_ZERO hides it because err happens to be 0. Restore the err = 0 initializer so a successful submit leaves completion to finish_netfs_read() only. Cc: stable@vger.kernel.org Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Reported-by: Karl Mehltretter Signed-off-by: Alex Markuze Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 082e1416aab544c25fbb8e2aee95e332f6e00c43 Author: sung byeongchan Date: Thu Oct 8 15:07:38 2026 +0900 ceph: validate encoded xattr name lengths [ Upstream commit 166375898d29fea050a9abec855da6075050d5c9 ] __build_xattrs() advances over an MDS-provided name length before checking that the name remains in the encoded xattr blob. On 32-bit clients, UINT_MAX wraps the cursor and is stored as a negative internal name length. A later ordinary listxattr() converts it back to a UINT_MAX memcpy size and corrupts kernel memory. Check the name range before advancing and reject name, value, or aggregate sizes that overflow the signed internal accounting. The malformed blob corrupted kernel state in two baseline boots. It was rejected cleanly twice with this change, while normal and length-only controls remained safe. Cc: stable@vger.kernel.org Fixes: 355da1eb7a1f ("ceph: inode operations") Assisted-by: LLM Signed-off-by: sung byeongchan Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 8a64b6406171f2fa65f0d89c59300916ec698ee8 Author: sung byeongchan Date: Thu Oct 8 15:07:25 2026 +0900 ceph: validate MDS reply fragtree split array length [ Upstream commit 8cab7e7461f81ea1e0fd45082b50bb3c04c0bb10 ] parse_reply_info_in() advances over the fragtree split array using an unchecked count multiplication. On a 32-bit client, nsplits=0x20000000 wraps the byte length to zero, so the reply is accepted and ceph_fill_fragtree() sorts far beyond the message front. Compute the split length with size_mul() and require the complete array to remain in the inode record before advancing the cursor. The malformed reply faulted in frag_tree_split_cmp() twice on the tested i386 baseline. It was rejected without a fault twice after this change, while a normal reply and a one-split control remained functional. Cc: stable@vger.kernel.org Fixes: 2f2dc053404f ("ceph: MDS client") Assisted-by: LLM Signed-off-by: sung byeongchan Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 59779874bf7618798e083b5adcc8b96082a9c294 Author: sung byeongchan Date: Thu Oct 8 15:07:14 2026 +0900 ceph: bound name skips in ceph_mdsmap_decode() by the message end [ Upstream commit 7f702e1703c9648fcb02a217d66c880d00417150 ] ceph_mdsmap_decode() reads two remote u32 name lengths and advances its parser cursor without checking that either string remains in the message. On a 32-bit client, a sufficiently large length can wrap the cursor below `end`. The following numerical bounds check then succeeds and dereferences the wrapped address. Use ceph_decode_skip_n() for both names so the remaining bytes are checked before the cursor advances. The issue produced a page fault in ceph_mdsmap_decode twice on the tested i386 baseline. The same frame was rejected without a fault twice after this change, while a normal MDSMap continued to be accepted. Cc: stable@vger.kernel.org Fixes: 2f2dc053404f ("ceph: MDS client") Assisted-by: LLM Signed-off-by: sung byeongchan Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 301185fe9caaf6623122759608025815c7ce8630 Author: sung byeongchan Date: Thu Oct 8 15:06:46 2026 +0900 ceph: validate fscrypt auth blob length [ Upstream commit bc418e234e5be14b97dec90e84a680e615b4134e ] ceph_crypt_get_context() trusts cfa_blob_len after checking only that the inode-owned fscrypt_auth allocation contains the fixed header and one byte. An MDS can therefore place a larger inner length in a shorter outer object, causing memcpy() to read beyond the allocation when a caller requests the encryption nonce. Require the complete blob to fit in the inode-owned allocation before using the inner length. On the tested baseline, the malformed reply produced the same KASAN slab-out-of-bounds read twice. An ordinary UID obtained sixteen wire-absent SLUB redzone bytes in two non-KASAN production-path runs. The input was rejected twice after this change, while a complete context still worked. Cc: stable@vger.kernel.org Fixes: 2d332d5bc424 ("ceph: fscrypt_auth handling for ceph") Assisted-by: LLM Signed-off-by: sung byeongchan Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit ea9c0a53283b8affa2def53131d1b2e701ecc43c Author: Venky Shankar Date: Wed Oct 7 14:25:59 2026 +0530 ceph: don't fail write_begin with -EAGAIN after flushing old snapc [ Upstream commit 6ff7920ca78f6edcabc26c63d20f681d938027c7 ] When ceph_netfs_check_write_begin() finds the folio dirty in an older snap context, it drops the folio, waits for that snap context to be flushed and then returns -EAGAIN so that the write is retried. However, since commit fac47b43c760 ("netfs: do not unlock and put the folio twice"), netfs_write_begin() retries only when ->check_write_begin() returns 0 with *foliop cleared -- every error, -EAGAIN included, is returned as is. The -EAGAIN thus propagates up to write(2), which fails with "Resource temporarily unavailable" once the dirty data has been flushed, rather than being retried. This is easily hit by buffered writers rewriting dirty pages while snapshots are being taken, e.g. a kernel build linking vmlinux into a directory under a snapshot schedule: ld: final link failed: Resource temporarily unavailable Return the wait_event_killable() result as is so that netfs re-gets the folio and retries on success. Cc: stable@vger.kernel.org Fixes: fac47b43c760 ("netfs: do not unlock and put the folio twice") Link: https://tracker.ceph.com/issues/57656 Signed-off-by: Venky Shankar Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 1456fa7445322e5f1924e02aeb61ebc6ea08d696 Author: Yuanfu Xie Date: Sat Sep 26 19:56:51 2026 +0800 ceph: clamp MDS reply result code to the errno range [ Upstream commit ec8d583469ed64b4973192a21b5a41c33219721f ] ceph_mdsc_wait_request() returns the reply head result code of the MDS request to its callers as a plain int errno. The value is a server-controlled u32 and nothing checks that it actually is an errno; several callers pass it straight to ERR_PTR(), e.g. ceph_finish_lookup() on the atomic open path: err = ceph_mdsc_wait_request(...) /* e.g. +0x50fc00 */ ... if (err) dentry = ERR_PTR(err); IS_ERR() only recognizes the [-MAX_ERRNO, -1] window, so an out-of-range value is not caught anywhere and survives as a "struct dentry *". On the open path the positive error travels ceph_finish_lookup() -> ceph_atomic_open() -> ERR_PTR() in fs/namei.c's atomic_open() wrapper -> step_into(), which dereferences it as a dentry and oopses (mainline 7.3-rc3-135-g4982d3552a3b, the value in R12 is the server-supplied result): BUG: KASAN: probably user-memory-access in range [0x000000000050fc00-0x000000000050fc07] RIP: 0010:step_into_slowpath+0x3e3/0xe60 R12: 000000000050fc00 Call Trace: ? __pfx_ceph_atomic_open+0x10/0x10 path_openat+0xf41/0x2440 do_file_open+0x228/0x480 do_sys_openat2+0x103/0x1d0 __x64_sys_openat+0x141/0x200 do_syscall_64+0xe8/0x4f0 entry_SYSCALL_64_after_hwframe+0x77/0x79 (0xdffffc00000a1f80 in the full report is the KASAN shadow of 0x50fc00; without KASAN the raw value is read.) Values with the top bit set fare no better: 0xd8000000 sign-extends through the int conversion into the kernel address range and takes a page fault instead. Clamp the result at the single read and return -EIO for anything outside the errno range, which is what a malformed reply means there. net/9p does the same to server errno values with safe_errno(). This is the path the reported crash takes; the other readers of head->result, including the ceph_async_create_cb() and ceph_async_unlink_cb() callbacks, are not covered by this patch. Each of the six crashing opens was run on a build of 7.3-rc3-135-g4982d3552a3bf with only this change applied: it crashes the unpatched kernel on the first openat() (verified on the same tree without the patch), and with the patch the open fails cleanly without an oops. A few hundred normal file operations on the patched kernel also completed without a crash; valid errno values pass through unchanged. Cc: stable@vger.kernel.org Fixes: 2f2dc053404febedc9c273452d9d518fb31fde72 ("ceph: MDS client") Signed-off-by: Yuanfu Xie Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 367803db119e3f1aadb59869c43dbb2002d206c6 Author: Jérémy Jean Date: Wed Sep 23 08:07:21 2026 +0000 libceph: fix out-of-bounds reads from repeated CRUSH bucket entries [ Upstream commit 569a9bb1e5615c2b88b8d76f03a4ab82e65a673e ] decode_choose_arg() assumes that its destination is zero-initialized. Although decode_choose_args() zeroes the argument array, it does not reject a repeated bucket_index and can decode into an already populated entry. Repeating a bucket with weight_set_size=0 preserves its existing weight_set pointer but clears the count. Placement then reads weight_set[-1].weights and dereferences the resulting pointer. A malformed monitor OSDMap triggers this during RBD placement: BUG: KASAN: slab-out-of-bounds in crush_bucket_choose+0xdd1/0xf90 Read of size 8 at addr ffff88800290df70 by task init/75 Reject populated arguments before decoding another entry, so the error path can free their original allocations. Cc: stable@vger.kernel.org Fixes: c7ed1a4bf4b4 ("crush: assume weight_set != null imples weight_set_size > 0") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 238c0053d5ba919e414fc26bdd91b2079e819d86 Author: Jérémy Jean Date: Wed Sep 23 20:25:34 2026 +0000 ceph: fix 32-bit overflow in readdir reply count check [ Upstream commit 52913831ba56efceaafd80b501d68fa00f79bde6 ] parse_reply_info_readdir() checks how many entries are in a readdir reply by computing the end pointer of the decoded array. That pointer addition can wrap on 32-bit kernels and let an oversized count pass the check. For example, a count of 0x40000000 with 156-byte entries wraps to a zero offset, so the decoder can write past the preallocated buffer. Check the count against the number of entries that fit in the allocation before publishing dir_nr. Reject oversized replies through the existing error path. Cc: stable@vger.kernel.org Fixes: 54008399dc0c ("ceph: preallocate buffer for readdir reply") Assisted-by: LLM Signed-off-by: Jérémy Jean Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit e104c02ad1c898fee1c39b8538689f17e0276a29 Author: Wentao Liang Date: Thu Sep 17 16:28:07 2026 +0000 ceph: Fix mds session leak in __open_export_target_session() [ Upstream commit 6c80207392fdb86107d7acbdbf4c86cac38da1af ] __open_export_target_session() holds a reference on the target session, either from __ceph_lookup_mds_session() or from register_session(), which the caller is expected to drop. When __open_session() fails, the helper returns ERR_PTR(ret) without dropping that reference, leaking one session reference on every open failure. Drop the session reference before returning the error. Cc: stable@vger.kernel.org Fixes: b682c6d41bc2 ("ceph: switch to WARN_ON_ONCE in encode_supported_features()") Signed-off-by: Wentao Liang Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 0ef457d642a492d1e8ec62ed168de1f9e2534b05 Author: Wentao Liang Date: Thu Sep 17 16:27:04 2026 +0000 ceph: Fix xattr buffer leak in __send_cap() [ Upstream commit e51cf76e7275d1bb5ad2d529bb00feade632dadc ] __prep_cap() takes a reference on the xattr blob via ceph_buffer_get() and also grabs a reference to the old xattr blob returned by __ceph_build_xattrs_blob(). These references are normally dropped in __send_cap() after the cap message has been sent, but when ceph_msg_new() fails, __send_cap() requeues the cap and returns early without dropping them, leaking both buffers on every allocation failure. Release arg->old_xattr_buf and arg->xattr_buf on the ceph_msg_new() failure path before returning. Cc: stable@vger.kernel.org Fixes: 16d68903f56a ("ceph: break up send_cap_msg") Signed-off-by: Wentao Liang Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit bf8f13872959af1d87e36b7d27096a09fdcf6e47 Author: Xiang Mei Date: Tue Sep 15 14:40:27 2026 -0700 ceph: fix integer overflow in the snap trace bounds check [ Upstream commit b3bf89767e3ca9506f1c7167cac97c41ec254d42 ] ceph_update_snap_trace() bounds the two encoded snapid arrays that follow a struct ceph_mds_snap_realm with sizeof(u64) * (num_snaps + num_prior_parent_snaps). Both counts come straight off the wire as __le32, so the addition is evaluated in unsigned int and wraps before sizeof(u64) promotes it to size_t: an MDS sending num_snaps = 1 and num_prior_parent_snaps = 0xffffffff makes the sum zero and the check degenerates to ceph_decode_need(&p, e, 0, bad), which always passes. dup_array() then reads num_snaps * 8 bytes past the end of the message front, which ceph_msg_new2() allocates at exactly front_len bytes. An unsolicited CEPH_MSG_CLIENT_SNAP reaches this from a malicious or compromised MDS with no client-side action, as do the snaptraces carried in an MDS reply and in a cap import. Compute the length with size_add()/size_mul() so it saturates at SIZE_MAX instead of wrapping, in the style fs/ceph/mdsmap.c already uses for num_export_targets. BUG: KASAN: slab-out-of-bounds in dup_array (include/linux/unaligned.h:28 fs/ceph/snap.c:500) Read of size 8 at addr ffff8880102a16c8 by task kworker/1:2/129 Workqueue: ceph-msgr ceph_con_workfn Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) dup_array (include/linux/unaligned.h:28 fs/ceph/snap.c:500) ceph_update_snap_trace (fs/ceph/snap.c:836) ceph_handle_snap (fs/ceph/snap.c:1155) mds_dispatch (fs/ceph/mds_client.c:7234) ceph_con_process_message (net/ceph/messenger.c:1424) ceph_con_v1_try_read (net/ceph/messenger_v1.c:1430) ceph_con_workfn (net/ceph/messenger.c:1576) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... The buggy address is located 0 bytes to the right of allocated 72-byte region [ffff8880102a1680, ffff8880102a16c8) Cc: stable@vger.kernel.org Fixes: 963b61eb041e ("ceph: snapshot management") Reported-by: co+ecaada42f806f629@bugs.sh Assisted-by: LLM Signed-off-by: Xiang Mei Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit b585bb63aaa24a302dc7095263d6853ca1953f21 Author: Yogesh Gaur Date: Fri Sep 11 19:01:09 2026 +0530 libceph: reject an initial monmap with no monitors [ Upstream commit 94dbce2ae4fdb57bdb53ffa3456da777a5cfb981 ] build_initial_monmap() takes the monitor count straight from ceph_options::num_mon and builds a monmap with that many entries without checking that there is at least one. ceph_parse_ips() writes *count only after it has parsed an address successfully, so a ceph_options that went through a failed parse still has num_mon == 0 and the resulting monmap has no monitors in it at all. The first thing the client does with that monmap is open a session, and pick_new_mon() asserts the invariant that it is non-empty: kernel BUG at net/ceph/mon_client.c:211! RIP: 0010:pick_new_mon net/ceph/mon_client.c:211 [inline] RIP: 0010:__open_session+0x60f/0x740 net/ceph/mon_client.c:245 Call Trace: ceph_monc_open_session+0x46/0x60 net/ceph/mon_client.c:534 __ceph_open_session+0x135/0x590 net/ceph/ceph_common.c:798 ceph_real_mount fs/ceph/super.c:1173 [inline] ceph_get_tree+0xd98/0x1fd0 fs/ceph/super.c:1362 vfs_get_tree+0x92/0x320 fs/super.c:1947 vfs_cmd_create+0xd7/0x2a0 fs/fsopen.c:231 __do_sys_fsconfig+0x55a/0xcb0 fs/fsopen.c:463 The reproducer gets there through the new device syntax: an fsconfig() mon_addr= that does not resolve ("libceph: resolve '127.0.0.' (ret=-3): failed") leaves fsopt->mon_addr set but num_mon at 0, so the "No monitor address" check in ceph_get_tree() passes and the mount proceeds with an empty monmap. The next patch stops that string from being kept, but the assertion should not be reachable from a mount option in the first place. Commit 40480eee361e ("libceph: Reject monmaps advertising zero monitors") made the same BUG_ON() unreachable from the wire by rejecting num_mon == 0 in ceph_monmap_decode(). Apply the same rule to the initial monmap, which is the only other way one gets built, and fail the mount with -EINVAL rather than assert afterwards. Cc: stable@vger.kernel.org Fixes: 7b19b4db5add ("ceph: new device mount syntax") Reported-by: syzbot+1dbed5969931c19d3eb5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1dbed5969931c19d3eb5 Assisted-by: Cursor Signed-off-by: Yogesh Gaur Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit d14b7eb4a3b07289ca614050921c5c27521cb5cd Author: Felix Hoffmann Date: Thu Sep 10 13:39:36 2026 +0200 libceph: reject mismatched CRUSH weight-set sizes [ Upstream commit d8fc89b5bfe4cb3aebe4c8a818247d11291b841c ] A CEPH_MSG_OSD_MAP message can contain CRUSH choose args with replacement weight vectors for straw2 buckets. decode_choose_args() validates the optional IDs vector against the referenced bucket, but does not validate the size of any replacement-weight vector. The CRUSH mapper assumes that each replacement vector has exactly as many entries as the bucket. A zero-length vector for a nonempty bucket makes bucket_straw2_choose() dereference NULL, while a shorter nonzero vector causes an out-of-bounds read. An authenticated monitor or OSD can deliver such a map and crash a kernel client when it performs placement for an ordinary request. Reject a nonempty collection of weight sets for an absent bucket and require every replacement-weight vector to match its bucket size. Cc: stable@vger.kernel.org Fixes: 5cf9c4a9959b ("libceph, crush: per-pool crush_choose_arg_map for crush_do_rule()") Assisted-by: Codex:gpt-5 Signed-off-by: Felix Hoffmann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 60e0f0fa93f5ebd68b3cd9f061ddeb6eab9bc498 Author: Raphael Zimmer Date: Wed Sep 9 17:03:53 2026 +0200 libceph: Fix multiple unsafe decodes in ceph_oloc_decode() [ Upstream commit 10655007b9b679e46a9e383202c7bb791e5d1d13 ] ceph_oloc_decode handles unchecked data received over the network from an OSD. Currently, there are multiple decode operations that aren't covered by any bounds check. Decoding these fields can therefore result in out-of-bounds reads if a corrupted message is received. This patch fixes the issue by adding bounds checks covering all previously uncovered decode operations. [ idryomov: use ceph_decode_64_safe() for hash ] Cc: stable@vger.kernel.org Fixes: 205ee1187a67 ("libceph: follow redirect replies from osds") Assisted-by: Cursor Signed-off-by: Raphael Zimmer Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 0e6985d7662f782dbceef0c24a28cbed902e78e2 Author: Raphael Zimmer Date: Wed Sep 9 16:59:13 2026 +0200 libceph: Fix unsafe decode in ceph_redirect_decode() [ Upstream commit 0405670e50f213594366ab7eddc07002bd7f84c0 ] ceph_redirect_decode handles unchecked data received over the network from an OSD. Currently, there is only a bounds check covering the first three decode operations. After decoding the first len field from the message, the only remaining check ensures there is enough buffer space to hold len bytes. However, there is no guarantee that this value is large enough to hold the subsequently decoded fields. The decoding of the second len field is missing an explicit bounds check. Consequently, a corrupted message can trigger an out-of-bounds read. This patch fixes the issue by switching the decoding from ceph_decode_32() to the bounds-checked version ceph_decode_32_safe(). Cc: stable@vger.kernel.org Fixes: 205ee1187a67 ("libceph: follow redirect replies from osds") Assisted-by: Cursor Signed-off-by: Raphael Zimmer Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 75df34515bfdfba49c6aefb012fe86d4ea3868db Author: Xiubo Li Date: Thu Sep 3 18:48:36 2026 -0700 libceph: only set read_from_replica on read requests [ Upstream commit d6c7a5fcd08873c45a2dcd645a0690fd1443af50 ] ceph_osdc_alloc_request() ORs the mount option's read_from_replica flag into r_flags for every request, writes included. The flag is meant for reads: calc_target() skips the replica choice for any request that has CEPH_OSD_FLAG_WRITE, and the OSDs only know BALANCE_READS on read ops. Sending it on writes is at best ignored; with read_from_replica=balance a buffered write that fell back to ceph_sync_write() after losing BUFFER to a revoke failed with -EIO, while the same run without the option works fine. Gate the flag on CEPH_OSD_FLAG_READ. Cc: stable@vger.kernel.org Fixes: 22d2cfdffa5b ("libceph: move away from global osd_req_flags") Assisted-by: Cursor Signed-off-by: Xiubo Li Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 380bc69a0dbc50549cb196da40409aed69c84cfc Author: Xiang Mei Date: Mon Sep 14 19:17:10 2026 -0700 ceph: require the dentry lease record to cover struct ceph_mds_reply_lease [ Upstream commit 7286b2ffe04d4b39b4e9884f714792589d94f316 ] parse_reply_info_lease() reads a 32-bit struct_len off the wire and only checks that many bytes are present, without requiring struct_len to cover sizeof(struct ceph_mds_reply_lease) (10 bytes). A malicious MDS can declare a shorter record and still get the pointer published: the following *p += sizeof(**lease) overshoot is undone by *p = lend, so nothing downstream rejects the reply. ceph_fill_trace() -> update_dentry_lease() then reads 10 bytes through that pointer on any lookup on a mounted CephFS, running past the end of the message front. Require the record to cover the structure, matching the sibling parse_reply_info_dir(). A conforming MDS always encodes the full 10 bytes. BUG: KASAN: slab-out-of-bounds in __update_dentry_lease.constprop.0 (fs/ceph/inode.c:1459) Read of size 4 at addr ffff888026c63d65 by task kworker/0:3/2366 Workqueue: ceph-msgr ceph_con_workfn Call Trace: __update_dentry_lease.constprop.0 (fs/ceph/inode.c:1459) ceph_fill_trace (fs/ceph/inode.c:1474 fs/ceph/inode.c:1823) mds_dispatch (fs/ceph/mds_client.c:4229 fs/ceph/mds_client.c:7225) ceph_con_process_message (net/ceph/messenger.c:1424) ceph_con_v1_try_read (net/ceph/messenger_v1.c:1430) ceph_con_workfn (net/ceph/messenger.c:1576) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) The buggy address is located 357 bytes inside of allocated 360-byte region [ffff888026c63c00, ffff888026c63d68) Cc: stable@vger.kernel.org Fixes: 4ac4c23eaa38 ("ceph: decode alternate_name in lease info") Reported-by: co+f92fbe44e3c6df69@bugs.sh Assisted-by: LLM Signed-off-by: Xiang Mei Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 7931e6798f419bda9ac8cf0c095323eff90a7f52 Author: Xiang Mei Date: Mon Sep 14 22:19:24 2026 -0700 ceph: reject mdsmaps that claim more than CEPH_MAX_MDS ranks [ Upstream commit c1742590d2b2fc5fb217e1a9b520108f1fe282e5 ] check_new_map() sizes its export-target bitmap from CEPH_MAX_MDS but walks it with newmap->possible_max_rank, which comes straight off the wire: ceph_mdsmap_decode() sets it to max(m_num_active_mds, m_max_mds), then overwrites it with the size of the "in" set. Neither is bounded by CEPH_MAX_MDS, only by m_info allocating, so a monitor announcing more ranks than the bitmap holds makes test_bit() read past the end of targets[]. The clear_bit() loop above indexes the same bitmap, though it is additionally bounded by mdsc->max_sessions. The map arrives on the monitor connection, which is unauthenticated in legacy msgr mode. CEPH_MAX_MDS is a protocol constant from src/mds/mdstypes.h, and the reserved inode ranges in super.h are laid out one rank apart over that span, so a map claiming more ranks is corrupt. Reject it where the rank space is established rather than letting the count reach check_new_map(). BUG: KASAN: stack-out-of-bounds in check_new_map (fs/ceph/mds_client.c:5968) Read of size 8 at addr ffffc90000ac7798 by task kworker/1:2/127 Workqueue: ceph-msgr ceph_con_workfn Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) kasan_check_range (mm/kasan/generic.c:186 mm/kasan/generic.c:200) check_new_map (fs/ceph/mds_client.c:5968) ceph_mdsc_handle_mdsmap (fs/ceph/mds_client.c:7060) extra_mon_dispatch (fs/ceph/super.c:802) mon_dispatch (net/ceph/mon_client.c:1483) ceph_con_process_message (net/ceph/messenger.c:1424) ceph_con_v1_try_read (net/ceph/messenger_v1.c:1430) ceph_con_workfn (net/ceph/messenger.c:1576) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) The buggy address belongs to stack of task kworker/1:2/127 and is located at offset 288 in frame: check_new_map (fs/ceph/mds_client.c:5846) This frame has 1 object: [32, 288) 'targets' Cc: stable@vger.kernel.org Fixes: d517b3983dd3 ("ceph: reconnect to the export targets on new mdsmaps") Reported-by: co+f8e3e01d8dda8689@bugs.sh Assisted-by: LLM Signed-off-by: Xiang Mei Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit a7582512fad8b6bfc89c653906067a92169ffcd0 Author: Guanglei Zhu Date: Thu Sep 10 11:00:36 2026 +0800 ceph: fix out-of-bounds read in ceph_netfs_issue_op_inline() [ Upstream commit cdbb60f00f87297a9db2652847dfc0eaaf3c45aa ] The read offset is validated against i_size but never against inline_len, and the two fields come from the MDS independently. When a read starts past the end of the inline data, the subtraction len = min_t(size_t, iinfo->inline_len - subreq->start, subreq->len); underflows and min_t() ends up with subreq->len, so copy_to_iter() reads past the end of the inline buffer straight into the user buffer. A malicious or buggy MDS reporting a short inline payload together with an inflated i_size can thus leak kernel heap memory to userspace. Bail out with -ENODATA when the offset is not within the inline data. Cc: stable@vger.kernel.org Fixes: 5b19f1eba459 ("ceph: make ceph_netfs_issue_op() handle inlined data") Signed-off-by: Guanglei Zhu Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit eafaf78e96f044434df92d27db088a860610c0e3 Author: Max Kellermann Date: Fri Sep 4 12:33:51 2026 +0200 ceph: avoid pending truncate during nonblocking cap acquire [ Upstream commit 979b7ed4457a04c5a41c36f86052ecc6b76c67d9 ] Readahead acquires caps while the folios are locked. This can deadlock when processing a pending truncate; truncate_pagecache() can then attempt to a folio that is already locked. Return -EAGAIN instead when `NON_BLOCKING` is set, causing the readahead to be abandoned. Cc: stable@vger.kernel.org Fixes: 49870056005c ("ceph: convert ceph_readpages to ceph_readahead") Signed-off-by: Max Kellermann Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 8df4d080f6cd60154f4f82b2b47d91c1438cb5b2 Author: Hungyu Lin Date: Tue Oct 20 23:34:33 2026 +0000 time/namespace: Fix overflow when converting absolute deadlines [ Upstream commit d69cfd33b5a8d176124c564513b9ceb933595d93 ] do_timens_ktime_to_host() subtracts the namespace offset from an absolute deadline and clamps the result to [0, KTIME_MAX]. A negative offset can make a large deadline overflow to a negative value. Since ktime_t is signed and KTIME_MAX is its maximum value, the subsequent comparison against KTIME_MAX can never detect this overflow. For example, with a -1 second boottime offset, an absolute CLOCK_BOOTTIME timerfd deadline of KTIME_MAX can expire immediately. An absolute clock_nanosleep() using the same clock and deadline can also return immediately instead of waiting. The earlier tim < offset check already handles the lower bound. A negative subtraction result in the remaining branch therefore indicates overflow. Detect that result and clamp it to KTIME_MAX. Fixes: 89dd8eecfe961 ("time: Add do_timens_ktime_to_host() helper") Signed-off-by: Hungyu Lin Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261020233433.20997-1-dennylin0707@gmail.com Signed-off-by: Sasha Levin commit ae67f3f8639c848905c329537c4a91cb62fbfd5e Author: Hungyu Lin Date: Tue Oct 20 22:39:57 2026 +0000 timers/itimer: Keep a nonzero value at CPU timer expiry [ Upstream commit ef60f61208a30eb5b941b707debdf04517271b4f ] get_cpu_itimer() returns a zero remaining time when the sampled CPU time is exactly equal to the nonzero expiry. This makes an armed ITIMER_VIRTUAL or ITIMER_PROF timer appear disarmed. The cputime cleanup replaced cputime_le(), which implements <=, with <. Restore the inclusive comparison so the equality case returns TICK_NSEC, like the overdue case and set_process_cpu_timer(). Fixes: 648616343cdb ("[S390] cputime: add sparse checking and cleanup") Signed-off-by: Hungyu Lin Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261020223957.87842-1-dennylin0707@gmail.com Signed-off-by: Sasha Levin commit b6be9e72b4af008677c513ea91f859b9b9c9d751 Author: Wang Haoran Date: Fri Oct 23 15:56:11 2026 +0800 fbdev: atmel_lcdfb: fix list_first_entry() on possibly empty modelist in probe [ Upstream commit 01d1204582f16e8b7bfce29648e5cf77a585d962 ] list_first_entry() does not return NULL on an empty list; it returns a bogus pointer computed by container_of() from the list head. atmel_lcdfb_probe() initializes info->modelist with INIT_LIST_HEAD() and later takes its first entry with list_first_entry(), assuming atmel_lcdfb_of_init() populated it. However, atmel_lcdfb_of_init() drops the return value of fb_add_videomode() — unlike every other fallible call in the same function — so if fb_add_videomode() fails (its internal kmalloc can return -ENOMEM under memory pressure or fault injection), the list stays empty while of_init() reports success. The probe path then dereferences the bogus pointer in fb_videomode_to_var(&info->var, &modelist->mode). Because the bogus pointer lands inside the contiguous fb_info allocation, this may not fault immediately; instead it silently reads adjacent memory as a struct fb_videomode and programs garbage timing parameters into the LCD controller. This was found by code audit; we do not have Atmel hardware to reproduce it. Fix this on two levels: check the return value of fb_add_videomode() in atmel_lcdfb_of_init() so the failure is propagated (root cause), and use list_first_entry_or_null() in atmel_lcdfb_probe() with a NULL check that fails probe gracefully with -EINVAL (defense in depth), consistent with the surrounding error handling which bails out to stop_clk. Reported-by: Wang Haoran Reported-by: Li Ximo Cc: stable@vger.kernel.org Signed-off-by: Wang Haoran Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit bed2155d85a86568b4b867546f8fa60175c154af Author: Baokun Li Date: Sat Oct 24 18:43:50 2026 +0800 fscrypt: Fix missing barrier in fscrypt_find_mode_key() [ Upstream commit cf66375465b9ca531f5c294f468db1df293c178c ] fscrypt_find_mode_key() walks an RCU list and hands out a per-mode key without an acquire: setup task ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ setup_per_mode_enc_key() ├─ fscrypt_prepare_key() │ └─ fscrypt_prepare_inline_crypt_key() │ └─ blk_crypto_start_using_key() │ └─ blk_crypto_fallback_start_using_mode() │ ├─ init profile, keyslots, tfms[] │ └─ smp_store_release(tfms_inited[mode]) # init order └─ list_add_tail_rcu(&new_node->link, ...) # release -> finder finding task (later submits the I/O itself) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fscrypt_find_mode_key() ├─ list_for_each_entry_rcu(node, ...) └─ return &node->key # no acquire, chain breaks ... blk_crypto_fallback_bio_prep() # WRITE path ├─ tfms_inited[mode] # addr-dep, reads true ├─ blk_crypto_fallback_profile # no dependency ├─ blk_crypto_keyslots # no dependency └─ slotp->tfms[mode] # no dependency RCU publishes the node and the key reachable from it, so tfms_inited[mode] reads true through the address dependency. The independent fallback globals are not covered by it and can be read as uninitialized. On a weakly ordered machine, a WRITE bio can crash in blk_crypto_get_keyslot() or crypto_sync_skcipher_setkey(). Other tasks reach the key through fscrypt_inode_info's cmpxchg_release()/smp_load_acquire(), which is already ordered after the list walk; only the finding task's own later I/O was not. Fix this by upgrading the control dependency to an acquire with smp_acquire__after_ctrl_dep() once a matching entry has been found. Fixes: dd015b566d50 ("fscrypt: Fix key setup in edge case with multiple data unit sizes") Cc: stable@vger.kernel.org Suggested-by: Eric Biggers Link: https://lore.kernel.org/r/20261014161153.GC322435@quark Signed-off-by: Baokun Li Link: https://patch.msgid.link/20261024104350.2257313-1-libaokun@linux.alibaba.com Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit 13bd3aff7abfb3434dbd1592ebab6716acb02a35 Author: Siddharth Chintamaneni Date: Sat Oct 17 05:09:27 2026 +0000 mm: multi-gen LRU: fix NULL lruvec->pgdat deref with memcg disabled on cmdline [ Upstream commit 183895979c441e52dbd651b388553b09eaa35cfa ] When CONFIG_MEMCG=y, lruvec_pgdat() returns lruvec->pgdat, which for the per-node pgdat->__lruvec is left NULL by lruvec_init() and only filled in lazily by mem_cgroup_lruvec(). Normally that happens early, e.g. on the first folio_add_lru(). With cgroup_disable=memory, lru_gen_shrink_node() passes &pgdat->__lruvec directly to shrink_one(). If direct reclaim runs before anything has called mem_cgroup_lruvec() for the node, which can happen during early boot under memory pressure (e.g. a kdump kernel), get_swappiness() ends up dereferencing a NULL pgdat: Unable to handle kernel NULL pointer dereference at virtual address 0000000000005040 pc : get_swappiness+0x68/0xb0 lr : try_to_shrink_lruvec+0x54/0x2c0 Call trace: get_swappiness+0x68/0xb0 (P) try_to_shrink_lruvec+0x54/0x2c0 shrink_one+0x8c/0x240 shrink_node+0xc6c/0xe08 do_try_to_free_pages+0xdc/0x570 try_to_free_pages+0x124/0x278 __alloc_frozen_pages_noprof+0x6e8/0xf78 alloc_pages_mpol+0xc4/0x1c0 alloc_frozen_pages_noprof+0x54/0xe8 alloc_pages_noprof+0x1c/0x40 atomic_pool_expand+0x98/0x300 __dma_atomic_pool_init+0x58/0xd8 dma_atomic_pool_init+0x154/0x170 do_one_initcall+0x64/0x350 kernel_init_freeable+0x214/0x430 kernel_init+0x2c/0x208 ret_from_fork+0x10/0x20 The classic LRU path and MGLRU before per-node lru_gen_folio lists obtained the lruvec through mem_cgroup_lruvec(), which sets lruvec->pgdat. The above was hit on an arm64 kdump kernel (6.18-based) booted with cgroup_disable=memory nr_cpus=4. It also reproduces on mainline on an arm64 VM with CONFIG_ARM64_64K_PAGES=y, CONFIG_MEMCG=y, CONFIG_LRU_GEN_ENABLED=y and: mem=160M nr_cpus=4 coherent_pool=512M cgroup_disable=memory These options only serve to force direct reclaim early in boot; with 160M the boot eventually ends in OOM regardless. On mainline the first LRU reclaim happens while unpacking the initramfs, and faults the same way: Unable to handle kernel NULL pointer dereference at virtual address 0000000000005040 pc : get_swappiness+0xd4/0x150 Call trace: get_swappiness+0xd4/0x150 (P) try_to_shrink_lruvec+0x44/0x2b8 shrink_one+0x80/0x1a0 shrink_node+0xd98/0xea8 do_try_to_free_pages+0xf4/0x4b0 try_to_free_pages+0x110/0x360 __alloc_frozen_pages_noprof+0x8b0/0x1718 ... __filemap_get_folio_mpol+0x2ac/0x548 simple_write_begin+0x44/0xf8 page_symlink+0x178/0x198 ... do_populate_rootfs+0x13c/0x200 Link: https://lore.kernel.org/20261017050928.128582-1-sidchintamaneni@gmail.com Fixes: e4dde56cd208 ("mm: multi-gen LRU: per-node lru_gen_folio lists") Signed-off-by: Siddharth Chintamaneni Signed-off-by: Hardik Garg Signed-off-by: Andrew Morton Reviewed-by: Barry Song Reviewed-by: Baolin Wang Assisted-by: LLM Cc: Johannes Weiner Cc: David Hildenbrand Cc: Michal Hocko Cc: Qi Zheng Cc: Shakeel Butt Cc: Lorenzo Stoakes Cc: Kairui Song Cc: Axel Rasmussen Cc: Yuanchu Xie Cc: Wei Xu Cc: Baoquan He Cc: Yu Zhao Cc: Cc: Cc: # 6.3+ Signed-off-by: Sasha Levin commit 24df68281795de4b8ee11b71ccc5b9ba746127bd Author: Yunhui Cui Date: Sat May 23 12:20:52 2026 +0800 riscv: mm: exclude invalid THP PMDs from page table check [ Upstream commit bdda2887cbf3937c2d0f56589c2124c4167324e1 ] RISC-V THP splitting uses a temporary invalid PMD state where pmd_mkinvalid() clears _PAGE_PRESENT and _PAGE_PROT_NONE but leaves _PAGE_LEAF set so the MM code can still recognize the PMD as a THP split in-progress entry. That temporary state no longer describes a user-accessible mapping, but page_table_check currently treats it as one because the RISC-V PMD user-accessibility test only checks whether the PMD is a leaf and has user permissions. As a result, when a PMD-sized anonymous THP is split during a COW fault, page_table_check can account the invalid intermediate PMD as a live PMD mapping, and then account the replacement PTE mappings again when the split installs the PTE table. This leaves stale PMD accounting behind and later triggers page_table_check failures such as a non-zero anon_map_count when the folio is freed. Fix this by tightening pmd_user_accessible_page() so PMD page-table-check accounting only considers leaf PMDs that still carry either _PAGE_PRESENT or _PAGE_PROT_NONE. This preserves the THP split semantics required by the MM code while preventing page_table_check from treating invalid split PMDs as live user mappings. With CONFIG_PAGE_TABLE_CHECK=y and CONFIG_PAGE_TABLE_CHECK_ENFORCED=y, tools/testing/selftests/mm/cow completes successfully on RISC-V after this change. Link: https://lore.kernel.org/20260523042052.35476-1-cuiyunhui@bytedance.com Fixes: 3fee229a8eb9 ("riscv/mm: enable ARCH_SUPPORTS_PAGE_TABLE_CHECK") Signed-off-by: Yunhui Cui Signed-off-by: Andrew Morton Cc: Albert Ou Cc: Palmer Dabbelt Cc: Pasha Tatashin Cc: Paul Walmsley Cc: tongtiangen Cc: Alexandre Ghiti Cc: David Hildenbrand (Arm) Cc: Vivian Wang Cc: Yaxing Guo Cc: Signed-off-by: Sasha Levin commit 28198a1591fd543bc477b5ba8e648ae5198a3d77 Author: Gregory Price (Meta) Date: Sat Oct 17 22:33:49 2026 -0400 mm/mempolicy: apply bind policies against the scoped allocation zone [ Upstream commit d4ea410ce4b8aa46a316476ea2624a357bf31fa9 ] QEMU fails to start a guest with a VFIO device when guest RAM comes from a memory backend bound to a movable-only node: vfio_container_dma_map(0x55b1b1317800, 0x0, 0x10000000, 0x7f39a2200000) = -12 (Cannot allocate memory) VFIO pins guest RAM when the device is realized, and the pin faults the pages in. io_uring fixed buffers fail the same way. Faulting the range in before pinning lets the same pin succeed, since resident pages are migrated off the node instead. A long-term pin faults under memalloc_pin_save(). PF_MEMALLOC_PIN makes current_gfp_context() clear __GFP_MOVABLE, but policy_nodemask() tests apply_policy_zone() against the caller's gfp. The bind keeps its movable-only nodemask, and the allocation finds no usable zone: page allocation failure: order:0, mode:0x140dc2(GFP_HIGHUSER|__GFP_ZERO|__GFP_COMP), nodemask=1,cpuset=/,mems_allowed=0-1 Call Trace: warn_alloc+0x136/0x150 __alloc_frozen_pages_noprof+0xed8/0x1720 alloc_pages_mpol+0xaa/0x170 vma_alloc_folio_noprof+0x65/0xd0 __handle_mm_fault+0x137b/0x1ac0 handle_mm_fault+0xa0/0x270 __get_user_pages+0x250/0xfd0 __gup_longterm_locked+0x116/0x870 gup_fast_fallback+0xcfc/0xdf0 pin_user_pages_fast+0x47/0x60 io_pin_pages+0x9a/0x110 Base page faults fail with -ENOMEM. hugetlb faults fail with -EFAULT. Check the policy zone against current_gfp_context(gfp), so a pin-scoped fault falls back off the movable-only nodemask, like any other non-movable allocation under the same bind. Tested in qemu with a dax/kmem movable-only node 1. io_uring and VFIO pins of unfaulted base pages and 2MB hugetlb pages now succeed and land on node 0 (correct). QEMU now starts with the same backend binding. Link: https://lore.kernel.org/20261018023349.1697434-1-gourry@gourry.net Fixes: 8e3560d963d2 ("mm: honor PF_MEMALLOC_PIN for all movable pages") Signed-off-by: Gregory Price (Meta) Signed-off-by: Andrew Morton Reviewed-by: Joshua Hahn Cc: David Hildenbrand Cc: Zi Yan Cc: Rakie Kim Cc: Ying Huang Cc: Pasha Tatashin Cc: Michal Hocko Cc: Signed-off-by: Sasha Levin commit 37684c84ff17689721b26f1479ccc578026c5063 Author: Rik van Riel Date: Fri Oct 16 12:23:04 2026 -0400 mm/page_alloc: count guard pages as free again when their buddy merges [ Upstream commit 1503710b3b0cec02b531978129c6c1eb70a7c490 ] With debug_guardpage_minorder set, expand() turns the unused halves of a split into guard pages, which page_del_and_expand() leaves out of the free counts. Freeing the allocated half credits only that half, and __free_one_page() then merges the guard buddy with clear_page_guard(), which no longer touches the counters. The merged block goes on a free list with the guard pages never counted, so NR_FREE_PAGES falls behind the free lists by every guard that merges. Before commit e0932b6c1f94 ("mm: page_alloc: consolidate free page accounting"), __set_page_guard() and __clear_page_guard() adjusted the counts themselves; that commit dropped both adjustments but kept the subtraction implicit in expand(). Count the guard pages under the merged block's migratetype when the buddy is cleared. account_freepages() skips an isolated block as it does for every other free page, and moving the block off the isolated list counts it then. Booting a 16GB VM with debug_pagealloc=on debug_guardpage_minorder=1, check the difference in free pages reported between /proc/vmstat and /proc/buddyinfo. At three points (idle, after a read and file-creation load, after a second load), check the difference between nr_free_pages and the buddyinfo numbers in the normal zone, as a number of pages: idle after load after second load unpatched -130 79205 99121 patched -16 45 0 The small remaining difference seems to be due to the numbers not being read at exactly the same time, and is also seen without guard pages. Link: https://lore.kernel.org/20261016122304.5b1eba8e@fangorn Fixes: e0932b6c1f94 ("mm: page_alloc: consolidate free page accounting") Signed-off-by: Rik van Riel Signed-off-by: Andrew Morton Reviewed-by: Zi Yan Reviewed-by: Johannes Weiner Reviewed-by: Dev Jain Reviewed-by: Vlastimil Babka (SUSE) Assisted-by: LLM Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Brendan Jackman Cc: Kairui Song Cc: Qi Zheng Cc: Shakeel Butt Cc: Baoquan He Cc: David Hildenbrand Cc: Lorenzo Stoakes Cc: Frank van der Linden Cc: Signed-off-by: Sasha Levin commit afebe2299f0f672aa5bebc2319c5245c97ed34b4 Author: Weilin Tong Date: Wed Oct 14 16:22:18 2026 +0800 ipc/shm: fix RSS accounting for hugetlb shared memory [ Upstream commit e387ebe5cd31720b1e0281fd045be4eef36fadb3 ] Commit a08c7193e4f1 ("mm/filemap: remove hugetlb special casing in filemap.c") changed mapping->nrpages to count base pages for hugetlb folios. However, shm_add_rss_swap() still multiplies it by pages_per_huge_page(), overcounting RSS in both SHM_INFO and /proc/sysvipc/shm. Use mapping->nrpages for RSS accounting across all backing types, and account swap only for non-hugetlb shmem. Use READ_ONCE() for both counters instead of info->lock, which does not protect nrpages and cannot provide a consistent snapshot. Link: https://lore.kernel.org/20261014082218.2236088-1-tongweilin@linux.alibaba.com Fixes: a08c7193e4f1 ("mm/filemap: remove hugetlb special casing in filemap.c") Signed-off-by: Weilin Tong Signed-off-by: Andrew Morton Suggested-by: Muchun Song Acked-by: Muchun Song Cc: Oscar Salvador Cc: David Hildenbrand Cc: Sidhartha Kumar Cc: Lorenzo Stoakes Cc: Dan Carpenter Cc: Baolin Wang Cc: Signed-off-by: Sasha Levin commit 866940b1ccbf8061528986484eac73e44f8a1c52 Author: Pedro Falcato Date: Tue Oct 13 20:17:19 2026 +0100 mm/madvise: atomically clear the young bit on THP MADV_COLD [ Upstream commit 246c8cc33438a71c28f9b86baa492d9a0a130316 ] As-is, madvise_cold_or_pageout_pte_range() discards the hardware young bit by invalidating the PMD, doing pmd_mkold() and subsequently writing to the pmd again. However, it does so in a racy manner, looking at a possibly-stale snapshot. It's entirely possible that a write elsewhere set the hardware D bit, which this logic now loses. Fix it by using pmdp_test_and_clear_young(). This is an atomic modification of the PMD entry, and thus safe against any possible racing writes. As a (nice) side-effect, this elides one non-required TLB flush in pmdp_invalidate(). This bug can interact with the swapping system in complicated ways, leading to data loss. For instance, if a folio is marked lazyfree, but was later read from, and then MADV_COLD'd while racing a write to that same THP, dropping the dirty bit may lead to data loss as reclaim/MADV_PAGEOUT drops the "clean" anon folio: T0 T1 ================================================================ MADV_FREE(thp) | folio marked lazyfree | read(thp) | PMD marked young by hardware | | MADV_COLD(thp) write(thp) | if (pmd_young(pmd)) { PMD marked dirty by hardware | set(pmdp, pmd_mkold(pmd)); MADV_PAGEOUT/reclaim | dirty bit may or may not be | set | reclaim/pageout may drop | the folio | Link: https://lore.kernel.org/20261013191719.95502-1-pfalcato@suse.de Fixes: 9c276cc65a58 ("mm: introduce MADV_COLD") Signed-off-by: Pedro Falcato Signed-off-by: Andrew Morton Reported-by: Samarth Narang Closes: https://lore.kernel.org/linux-mm/20261011132227.413217-1-samarth.colleges@gmail.com/ Reviewed-by: Gregory Price (Meta) Acked-by: Zi Yan Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Reviewed-by: SJ Park Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Minchan Kim Cc: Michal Hocko Cc: Johannes Weiner Cc: Signed-off-by: Sasha Levin commit 8d1d006fe3ac2f21407ef99c338d8a172b797e27 Author: Harry Yoo (Meta) Date: Tue Oct 13 20:34:39 2026 +0100 mm/percpu: account full object size for percpu memory allocations [ Upstream commit c7a467fbcbbc31e57a5077bfc9456d9f29cb1571 ] When memory allocation profiling is enabled, the pages backing percpu memory chunks are attributed to func:pcpu_alloc_pages. However, the accounting of individual percpu memory allocations via alloc_percpu() and friends record only the size of a single object rather than its full size across all CPUs. As a result, it is often not straightforward to identify which kernel code is actually responsible for percpu memory, because the size is under-accounted by a factor of num_possible_cpus(). Account full object size with pcpu_obj_full_size(size) instead, which multiplies the object size by num_possible_cpus() and adds the objcg pointer overhead. This is consistent with what memcg already does for charging percpu allocations. Verified with 64-CPU VM by spawning 400 processes in a memory cgroup and measuring mm_init()'s rss_stat counters. Delta of kernel/fork.c:1142 func:mm_init in /proc/allocinfo: bytes calls per allocation unpatched 6320 395 16 patched 418176 396 1056 'percpu' field in memory.stat: 422400 (1056 bytes per process) Memory allocation profiling now accounts the same amount of memory as what memcg charges. Link: https://lore.kernel.org/20261013-fix-alloc-percpu-accounting-v1-1-03e788a1e41f@kernel.org Fixes: 60fa4a9e2323 ("mm: percpu: add codetag reference into pcpuobj_ext") Signed-off-by: Harry Yoo (Meta) Signed-off-by: Andrew Morton Reviewed-by: Joshua Hahn Assisted-by: LLM # Verification Cc: Dennis Zhou Cc: Tejun Heo Cc: Christoph Lameter Cc: Suren Baghdasaryan Cc: Hao Ge Cc: Signed-off-by: Sasha Levin commit a65767efb08a8ea6cc721258526c9aea752896ca Author: Nickolai Zeldovich Date: Wed Oct 14 09:13:58 2026 -0400 mm/mlock: use a long for the page count in mlock_fixup() [ Upstream commit 3ae91e3079b1504ef162b2884454d5f1421f4eb9 ] mlock_fixup() adjusts mm->locked_vm, an unsigned long, by the number of pages whose VM_LOCKED state it changes, but computes that number in an int: int nr_pages; ... nr_pages = (end - start) >> PAGE_SHIFT; ... mm->locked_vm += nr_pages; When a single VMA range of 2^31 pages (8 TiB with 4 KiB pages) or more is locked or unlocked, the count is truncated to 32 bits and then sign-extended, so locked_vm is changed by the wrong amount, while munmap(), mremap() and the other paths that maintain locked_vm use the full unsigned long page count. Such a range is reachable on 64-bit architectures with a 47-bit or larger user address space (x86_64, arm64 with 48-bit VA, riscv64 Sv48) by a task with CAP_IPC_LOCK or a raised RLIMIT_MEMLOCK, which do_mlock() checks against the full untruncated length. It costs nothing with MAP_NORESERVE and MLOCK_ONFAULT/MCL_ONFAULT, since then no page is populated. On x86_64, after p = mmap(NULL, 8UL << 40, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1, 0); mlock2(p, 8UL << 40, MLOCK_ONFAULT); VmLck in /proc/self/status reads 18446744065119617024 kB instead of 8589934592 kB; munmap() of the region then subtracts the true size and leaves VmLck at 18446744056529682432 kB instead of 0. With 16 TiB, locked_vm is not changed at all, VmLck stays 0 kB, and after the task drops CAP_IPC_LOCK or lowers RLIMIT_MEMLOCK, mlock(), mmap(MAP_LOCKED) and the other mlock_future_ok() and account_locked_vm() users enforce RLIMIT_MEMLOCK against that count, so they let the task lock memory beyond its limit (or, in the 8 TiB case, refuse every further lock). The error persists for the life of the mm; unlocking the range in pieces skews it further. The wrong count is per-mm accounting only: it does not change which pages are locked. The int has been there since before git history (the variable was named "pages" until it was renamed in 2.6.28); every other updater of locked_vm uses an unsigned long or long count. Make nr_pages a long, which holds the page count of any user range and its negation, so the existing sign handling is unchanged. Found by formal verification of mm/mlock.c against the kernel binary. Link: https://lore.kernel.org/20261014131358.780240-1-nickolai@csail.mit.edu Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Nickolai Zeldovich Signed-off-by: Andrew Morton Reviewed-by: Pedro Falcato Assisted-by: LLM Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Vlastimil Babka Cc: Jann Horn Cc: Signed-off-by: Sasha Levin commit 3ab27ef1675e42a03b68c83bb251872811a44845 Author: Wei Yang Date: Sat Oct 10 10:40:42 2026 +0800 mm/madvise: add cond_resched() in THP branch of madvise_cold_or_pageout_pte_range() [ Upstream commit f5cfc8e3b20ad71949a1e5623ff45882c063a71b ] During stress testing with stress-ng on a 256-CPU system, a softlockup was observed when madvise(MADV_COLD) was called on a 31GB memory region backed by transparent hugepages. The region contains 15935 THP PMD entries, and the softlockup was triggered after 14485 of them had been processed. The THP branch of madvise_cold_or_pageout_pte_range() has no scheduling point. walk_pmd_range() invokes it once per 2MB PMD entry with no cond_resched() anywhere in the loop. Each iteration calls pmdp_invalidate() which issues a synchronous TLB shootdown (dsb ish) waiting for all CPUs to acknowledge. This operation can be time-consuming under heavy system load, causing the accumulated time across all PMD entries to exceed the softlockup threshold (20s) and panic when softlockup_panic=1. On a CONFIG_PREEMPT_NONE=y kernel, there is no other opportunity to reschedule during this entire traversal. The regular PTE path already has an unconditional cond_resched() at the function tail (introduced by commit 9c276cc65a58 ("mm: introduce MADV_COLD") and commit 1a4e58cce84e ("mm: introduce MADV_PAGEOUT") when MADV_COLD and MADV_PAGEOUT were first introduced) and a conditional one inside the loop (commit b2f557a21bc8 ("mm/madvise: add cond_resched() in madvise_cold_or_pageout_pte_range()")). The THP branch never received equivalent treatment. Fix by adding cond_resched() at the huge_unlock exit path after spin_unlock(ptl) and reclaim_pages(), which is the single exit point for all goto paths in the THP branch. Crash log: watchdog: BUG: soft lockup - CPU#63 stuck for 23s! [stress-ng-vm:1665914] ... Call trace: pmdp_invalidate+0x48/0x68 madvise_cold_or_pageout_pte_range+0x84c/0xb00 walk_pmd_range.isra.0+0x1ac/0x3b0 walk_pud_range+0x120/0x190 walk_pgd_range+0x170/0x1b8 __walk_page_range+0x184/0x198 walk_page_range_vma+0x94/0x128 madvise_cold+0xd8/0x198 madvise_vma_behavior+0x234/0x638 madvise_walk_vmas.constprop.0+0xdc/0x210 madvise_do_behavior+0xa8/0x328 do_madvise+0xd8/0x140 __arm64_sys_madvise+0x2c/0xe0 Link: https://lore.kernel.org/20261010024042.4070048-1-albin_yang@163.com Signed-off-by: Wei Yang Signed-off-by: Andrew Morton Reviewed-by: Gregory Price (Meta) Acked-by: David Hildenbrand (Arm) Acked-by: Lorenzo Stoakes (ARM) Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Signed-off-by: Sasha Levin commit 5cbc38393b3c7f3c33cac18ed24d5a2213902db7 Author: Cen Zhang Date: Tue Oct 20 21:12:50 2026 +0800 ocfs2/cluster: remove zero-address nodes from IP tree on teardown [ Upstream commit 5dd57e77eff4ba3e85b3df126a55417c88245708 ] o2nm_node_ipv4_address_store() accepts 0.0.0.0. It sets O2NM_NODE_ATTR_ADDRESS and links nd_ip_node into cl_node_ip_tree under cl_nodes_lock, but o2nm_node_group_drop_item() uses nd_ipv4_address as a membership test. A zero address therefore leaves the rbtree node linked when config_item_put() releases and frees struct o2nm_node. A later address store or IP lookup can then walk the stale node and dereference freed memory. During teardown, drop_item takes cl_nodes_lock, skips rb_erase() for the zero key, and then calls config_item_put(). A later o2nm_node_ipv4_address_store() duplicate check or o2nm_get_node_by_ip() lookup takes the same lock and walks the stale cl_node_ip_tree entry. Use O2NM_NODE_ATTR_ADDRESS for teardown so every published nd_ip_node is erased before configfs can release the node, without rejecting 0.0.0.0 or changing lookup semantics. Link: https://lore.kernel.org/pm-ocfs2-node-ip-rbtree-zero-address-uaf-v5-e7f64be16b7c3b0988d1@gmail.com Fixes: 0c83ed8eeb28 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Sasha Levin commit 555efe1e9881a2d5d92de6768daa486b09de2f91 Author: Cen Zhang Date: Thu Oct 22 17:08:42 2026 +0800 ocfs2: snapshot the dentry name while tracing file release [ Upstream commit 5898987d4a92b70ae73fd8355cc3a388b4dfa4e6 ] ocfs2_file_release() passes the live dentry name and length to a trace event while holding oi->ip_lock. This lock protects the open count and delays RCU reclamation of external names, but it does not serialize name changes during rename. The dentry can switch between inline and external names, and a separately loaded length can describe a different name. The ocfs2__file_ops event sizes and copies its __string separately. A concurrently rewritten inline name need not remain consistent between those operations. External names can also be selected at this call site; the existing spinlock critical section protects their allocation lifetime, while a snapshot additionally pairs a stable name with its length. Take a name snapshot before acquiring oi->ip_lock and release it after dropping the lock. Keep the trace call and open-count argument inside the original critical section. Cache the event-enabled check so the snapshot stays paired even if tracing is toggled meanwhile. Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0088-v7-6324344256f0c3b1c3d8-2@gmail.com Fixes: 468eedde23d6 ("ocfs2: Remove mlog(0) from fs/ocfs2/file.c") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Sasha Levin commit 53178f663f50866c6d45402802c06e5560f3541a Author: Hungyu Lin Date: Tue Oct 20 21:01:57 2026 +0000 compat: avoid double rounding in times() [ Upstream commit 6b30c39a5e333cfb1475acf0f73de6ef954eea8a ] do_sys_times() already converts CPU time to USER_HZ ticks. The compat path converts each value back to jiffies before converting it to COMPAT_USER_HZ. This round trip can lose precision even when the two userspace rates match. With HZ=250 and USER_HZ=COMPAT_USER_HZ=100, one user tick becomes two jiffies and then zero compat ticks. Every odd tick count loses one tick, so any of the four tms fields can underreport CPU time by an additional 10 ms. Return the value directly when the native and compat units match. Keep the existing conversion for differing rates. Link: https://lore.kernel.org/20261020210157.52057-1-dennylin0707@gmail.com Fixes: f06febc96ba8 ("timers: fix itimer/many thread hang") Signed-off-by: Hungyu Lin Signed-off-by: Andrew Morton Reviewed-by: Andrew Morton Cc: Arnd Bergmann Cc: Thomas Gleixner Cc: Signed-off-by: Sasha Levin commit 7ac52a09bf8902b2a18998c652454227c3d3a9b9 Author: Stanley Jhu Date: Thu Oct 22 11:44:42 2026 +0800 scsi: ufs: core: Remove completed-without-interrupt path in ufshcd_abort() [ Upstream commit 7cfdfdd6557906fd09cf0a9a564a07012e7fb0c1 ] In SDB mode, a command that times out right as the controller finishes it can be completed twice: 1. The command times out and scsi_timeout() schedules ufshcd_abort(). 2. The controller finishes the command and clears its doorbell bit in REG_UTP_TRANSFER_REQ_DOOR_BELL, while the completion handler has not yet cleared BIT(tag) in hba->outstanding_reqs. 3. ufshcd_abort() sees the doorbell bit clear and calls __ufshcd_transfer_req_compl() without clearing BIT(tag) in hba->outstanding_reqs. 4. The normal completion handler or the logical unit reset that follows sees BIT(tag) still set in hba->outstanding_reqs and completes the same command a second time. This branch only exists for a rare corner case, a completion interrupt that is lost or arrives late. Remove it to simplify the abort path and leave such a command to the SCSI error handler, like any other command that cannot be aborted. The cost is a slower recovery in this corner case, which is acceptable since it only happens after a timeout. Fixes: 169f5eb28869 ("scsi: ufs: Optimize SCSI command processing") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/fdb5c391-01ef-4a23-94c2-4f3853909348@acm.org Signed-off-by: Stanley Jhu Reviewed-by: Peter Wang Reviewed-by: Bean Huo Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20261022034443.3034432-6-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 78de0d275957c29f0cb8cd06a656121a334de9e5 Author: Stanley Jhu Date: Thu Oct 22 11:44:38 2026 +0800 scsi: ufs: core: Remove an always-false WARN_ONCE() [ Upstream commit cd37a69c367b6a5f685db0ac7d01f08545081a30 ] The WARN_ONCE() in ufshcd_poll() can never fire. completed_reqs is set to ~tr_doorbell & hba->outstanding_reqs on the line above, and hba->outstanding_reqs cannot change in between because ufshcd_poll() holds hba->outstanding_lock. So completed_reqs & ~hba->outstanding_reqs is always zero. Remove it. No functional change. Cc: stable@vger.kernel.org Reviewed-by: Bean Huo Reviewed-by: Peter Wang Reviewed-by: Bart Van Assche Signed-off-by: Stanley Jhu Link: https://patch.msgid.link/20261022034443.3034432-2-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit ca70c19c0b25e56f7c2566d979189d2cdccb95dc Author: Ratnaker Gautam Date: Mon Oct 19 21:30:33 2026 +0000 scsi: libiscsi_tcp: Prevent R2T range check overflow [ Upstream commit eb7aa7fd673fdc1582223cd133bcc5f54e7af19f ] An iSCSI target controls the R2T data offset and length as 32-bit values. Adding them before comparing the result with the SCSI data buffer length can wrap. An R2T with offset 1 and length U32_MAX then passes the check for a 4096-byte write. The transmit path treats the wrapped range as valid, exhausts the command scatterlist, and dereferences the NULL next entry in iscsi_tcp_segment_done(). Check the offset first, then compare the length with the remaining bytes in the data buffer. Fixes: a081c13e39b5 ("[SCSI] iscsi_tcp: split module into lib and lld") Cc: stable@vger.kernel.org Signed-off-by: Ratnaker Gautam Acked-by: Chris Leech Link: https://patch.msgid.link/DB5PR08MB100629CD3750FBF71475B5224FD982@DB5PR08MB10062.eurprd08.prod.outlook.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit d1e7118d2d30355055ae484b3bd3aca11efefbcb Author: Stanley Jhu Date: Thu Oct 15 08:18:55 2026 +0800 scsi: ufs: core: Clear stale UIC result byte before peer DME retries [ Upstream commit e4a9b7640914b248eb7537d4507aa42db080586a ] Peer DME get and set retry a failed attempt with the same struct uic_command. UIC completion ORs the ConfigResultCode into argument2[7:0], and nothing clears it before the next attempt. Once an attempt fails, every retry keeps reporting that error code, even when the device returns success, so a transient failure becomes a hard failure after three retries. Each such retry also triggers the WARN_ON_ONCE() in ufshcd_dispatch_uic_cmd(). In ufshcd_dme_set_attr(), ufshcd_uic_cmd_compl() also overwrites argument3 with the register readback before the next attempt. Clear the result byte and restore argument3 in ufshcd_dme_set_attr() when an attempt fails. Fixes: 64238fbd15ea ("scsi: ufs: add retries to dme_peer get and set attribute") Cc: stable@vger.kernel.org Reviewed-by: Bean Huo Signed-off-by: Stanley Jhu Reviewed-by: Peter Wang Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20261015001855.3450573-6-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 061264243d07092cbaccd067ffe78c9d76ac8c1b Author: Stanley Jhu Date: Thu Oct 15 08:18:52 2026 +0800 scsi: ufs: bsg: Clear the reply buffer before use [ Upstream commit 2e63ac76cc08ea376ba61fef52f7b7849e35024d ] The reply buffer is allocated once per tag and reused. Requests that complete with a positive status do not fill all of it, so user space receives bytes from an earlier request on the same tag. Clear the whole reply buffer on entry to ufs_bsg_request(). Fixes: 95e34bf930ea ("scsi: ufs-bsg: Add support for raw upiu in ufs_bsg_request()") Cc: stable@vger.kernel.org Signed-off-by: Stanley Jhu Reviewed-by: Bean Huo Reviewed-by: Peter Wang Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20261015001855.3450573-3-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit faba6b1b3c26e45873aa73a98b17b0f23dc25ba9 Author: Stanley Jhu Date: Thu Oct 15 08:18:51 2026 +0800 scsi: ufs: bsg: Complete the job on error [ Upstream commit cc0ce3fe8fac073ecded4f32c8ee5b89da1397e8 ] When ufs_bsg_request() fails, it returns a non-zero status without calling bsg_job_done(). bsg_queue_rq() then ends the request with BLK_STS_IOERR without running bsg_complete(), leaking the job's device reference and mapped scatterlists. Always complete the job via bsg_job_done() and return 0, matching other BSG transports. Requests failing with a negative errno now return it from SG_IO with the 4-byte result in the reply, while positive status codes still return 0 from SG_IO with the reply header. Fixes: b13a3539eb2a ("scsi: ufs-bsg: complete ufs-bsg job only if no error") Cc: stable@vger.kernel.org Signed-off-by: Stanley Jhu Reviewed-by: Bean Huo Reviewed-by: Peter Wang Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20261015001855.3450573-2-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit d318e88b4f4c5f9baef76e5c14f3dab72873c831 Author: yanxia Date: Tue Oct 20 10:01:47 2026 +0800 veth: fix stale peer max_mtu on XDP program replacement [ Upstream commit c955325db639e9503941227e14e1f1ccc99442a1 ] veth_xdp_set() calculates the peer MTU limit from the incoming program's XDP fragment capability, but only stores it when no program was attached. Replacing a program with one having a different fragment capability therefore leaves the peer's max_mtu stale. Replacing a regular program with an xdp.frags program keeps rejecting otherwise valid jumbo MTUs. The opposite replacement leaves a larger limit in place and permits MTUs which a fresh attachment of the regular program would reject. Update peer->max_mtu after every successful attachment or replacement. Keep the GSO feature update conditional on the first attachment. Found during review of the XDP replacement path and confirmed with native XDP on an isolated veth pair. Before the fix, direct replacement rejects MTU 9000 after switching to xdp.frags, and accepts it after switching back to a regular program. Detaching and attaching instead produces the expected results in both directions. UML tests on net reproduce the problem before this change and match the detach/attach controls afterwards, with both devices up or down and with either endpoint receiving XDP. Failed replacements preserve the previous state; same-type replacements and detach also behave as expected. Small-frame traffic passes in the devices-up cases. Fixes: 7cda76d858a4 ("veth: Allow jumbo frames in xdp mode") Cc: stable@vger.kernel.org Signed-off-by: yanxia Link: https://patch.msgid.link/20261020020147.790274-1-yanxia@cmss.chinamobile.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4f869e480eda62fcdbafd841a49c2e5b04bb2cd3 Author: Aamir Ahmed Date: Tue Oct 20 23:33:46 2026 +0100 gve: fix out-of-bounds read in gve_get_flow_rule_entry() [ Upstream commit 45e0a63f9c86a558afc70d79b6df38f8ec7f502a ] gve_get_flow_rule_entry() checks the requested location against the first and last cached rules, but rules_cache_num can be 0 while rules_cache_synced is true: GVE_FLOW_RULE_QUERY_RULES returns the rules from the requested location onwards, so a request past the last installed rule - or any request when no rules are installed - returns zero rules, which the driver accepts and marks as synced. The next query evaluates rules_cache[*cache_num - 1] with *cache_num == 0. The zero-initialised cache does not trip the earlier comparison, *cache_num - 1 wraps to 0xFFFFFFFF in u32, and the read faults about 352 GiB past the cache. ETHTOOL_GRXCLSRULE needs no capability, so an unprivileged user can trigger it: BUG: unable to handle page fault for address: ff240996c4c64fa8 #PF: supervisor read access in kernel mode RIP: gve_get_flow_rule_entry+0xd4/0x110 [gve] Treat an empty cache as a cache miss and re-query. Fixes: 6f3bc487565d ("gve: Add flow steering ethtool support") Cc: stable@vger.kernel.org Signed-off-by: Aamir Ahmed Reviewed-by: Eugene Lee Reviewed-by: Harshitha Ramamurthy Link: https://patch.msgid.link/AS8P251MB0001135AF3233180DC42DCD1C8672@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 96f567feabb177deb57631754dc7402e063610f5 Author: Sasha Levin Date: Fri Oct 23 15:46:23 2026 -0400 cgroup: don't kill migrated processes through their exiting threads [ Upstream commit 5f4a3f743acc96987ae5c2e966947942c34ba56c ] Since commit da13e0e72a73 ("cgroup: fix cgroup.kill for exited thread group leader"), __cgroup_kill() visits every thread in the cgroup and sends SIGKILL with PIDTYPE_TGID, so each visited thread takes down its whole thread group. A thread that has started exiting can stay in a cgroup after its process has been moved out of it. cgroup_migrate_add_task() skips PF_EXITING tasks, and the thread is only unlinked by cgroup_task_dead() after its final context switch. mm_release() clears the thread's clear_child_tid word and wakes the joiner well before that, so pthread_join() can return while the thread is still in the old cgroup. If cgroup.kill is written in that window, __cgroup_kill() finds the exiting thread and complete_signal() passes the group-wide SIGKILL on to a live thread, killing a process that already left the cgroup. The cgroup selftest test_stress.sh runs into this: test_cgcore_proc_migration() joins its threads, moves itself back to the root cgroup, and cg_destroy() falls back to cgroup.kill on the old cgroup when rmdir() fails with EBUSY, so test_core kills itself. KernelCI has been reporting "with_stress.sh: line 94: ... Killed" on several arm64 boards since the commit reached linux-next. Keep visiting every thread, but go back to sending SIGKILL to the thread that was found. A SIGKILL sent to a live thread still kills its whole thread group, so both cases fixed by that commit stay fixed, and task_can_queue_signal() drops one sent to a thread that is already exiting. Fixes: da13e0e72a73 ("cgroup: fix cgroup.kill for exited thread group leader") Cc: stable@vger.kernel.org # v5.14+ Link: https://lore.kernel.org/all/179272264722.329188.4773475583351189022@6e52bff8000c/ Signed-off-by: Sasha Levin Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 6e66b01db883a9e343128c4ddb7b0c74443ea257 Author: Thomas Weißschuh (Schneider Electric) Date: Fri Oct 23 13:49:17 2026 +0200 timekeeping: Update offsets on sequence counter retry in ktime_get_update_offsets_now() [ Upstream commit 6541fbc942f3b63bb8bd44e34eee6223e0abe719 ] The sequence counter of the cwsseq target is modified during the sequence counter loop. If the loop retries, cwsseq will now match but the offsets contain the values from the previous loop iteration. These are not guaranteed to be consistent in themselves or with the current loops "now. Save the target's original sequence counter value so that the update also happens on loop retries. Fixes: 868a3e915f7f ("hrtimer: Make offset update smarter") Signed-off-by: Thomas Weißschuh (Schneider Electric) Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261023-timekeeping-clock_was_set_seq-v1-1-61c4c53d031c@linutronix.de Signed-off-by: Sasha Levin commit 221d4fc53dc6403ace5487e6d18b757766131108 Author: Cen Zhang (Microsoft) Date: Mon Oct 12 19:51:49 2026 -0400 posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() signal path [ Upstream commit 8ccd731b63a0183ca2b0e18f3ca15864b3f37eda ] do_cpu_nanosleep() sleeps on a temporary k_itimer whose reference on the target's struct pid is taken by posix_cpu_timer_create() and dropped by posix_cpu_timer_del(). When a signal ends the sleep, the timer is disarmed with posix_cpu_timer_set(), but posix_cpu_timer_del() is only called for a result of 0 or TIMER_RETRY. If the target thread or process has exited in the meantime, timer_lock_sighand() finds no task, posix_cpu_timer_set() returns -ESRCH and the pid reference is leaked. An unprivileged user can trigger this: sleep on the CPU clock of a thread, let that thread exit, then signal the sleeper. Each round leaks one struct pid. Repeating it exhausts unreclaimable slab memory within minutes: Out of memory: Killed process 150 (poc) total-vm:789292kB, anon-rss:484kB Kernel panic - not syncing: System is deadlocked on memory Fix this by also calling posix_cpu_timer_del() on -ESRCH. With the target gone, the deletion is safe. It finds no task either and only drops the pid reference. Fixes: e26d70d271ee ("posix-timers: Cleanup reaped target handling") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft) Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261012235149.66531-1-cenzhang@linux.microsoft.com Signed-off-by: Sasha Levin commit e44de06357d836046cc1186e7e9795fb9a3bfa3a Author: Pufan Jin Date: Fri Oct 16 21:08:12 2026 +0800 spi: zynq-qspi: fix address buffer corruption and support 4-byte address [ Upstream commit dc5ca34f5e8dc10c566ef39aa3b1a201a17ca734 ] In zynq_qspi_exec_mem_op(), when transmitting address bytes, the driver iterates over op->addr.nbytes and populates xqspi->txbuf[i]. However, xqspi->txbuf is never re-assigned before populating the address, meaning it still points to (u8 *)&op->cmd.opcode from the command phase. This causes two severe issues: 1. Memory corruption: Writing into xqspi->txbuf writes past the opcode buffer on the stack (which was passed as const struct spi_mem_op *). If opcode is zero, xqspi->txbuf is uninitialized. 2. In zynq_qspi_supports_op(), operations with op->addr.nbytes > 3 are rejected. When paired with SPI NOR flashes larger than 16MB (such as Winbond W25Q256), spi_nor_spimem_check_read_pp_op() tests 4-byte address support, which fails and causes spi_nor_select_read() to drop all read capabilities, failing probe with -EINVAL (-22). The Zynq-7000 QSPI controller hardware in manual I/O mode natively supports transmitting 1 to 4 address bytes via its TXD FIFO registers (ZYNQ_QSPI_TXD_00_00_OFFSET). Fix this by introducing a local opaddr[4] buffer in zynq_qspi_exec_mem_op() and explicitly setting xqspi->txbuf = opaddr before populating address bytes. Also allow up to 4 address bytes in zynq_qspi_supports_op(). Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI controller") Cc: stable@vger.kernel.org Signed-off-by: Pufan Jin Link: https://patch.msgid.link/20261016130812.282624-1-cyan2254650260@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8b6dd64e6557910c84bcaa78e275fe75ce9596ed Author: Christian Marangi Date: Thu Oct 22 21:38:51 2026 +0200 i2c: mt7621: fix copying uninitialized kernel stack with reduced page_len [ Upstream commit b7fd977fec0d3f2bdd4f13bb59949c817a365652 ] When a page_len is less than 5 bytes in mtk_i2c_xfer, uninitialized kernel stack data is copied and written to REG_SM0D1_REG. Equally on the read part, an unnecessary read is done. Guard these extra copy/write and read for the page_len to fix leaking uninitialized stack memory. Fixes: d04913ec5f89 ("i2c: mt7621: Add MediaTek MT7621/7628/7688 I2C driver") Signed-off-by: Christian Marangi Cc: # v5.3+ Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20261022193853.670625-1-ansuelsmth@gmail.com Signed-off-by: Sasha Levin commit eb2ce3e13f344b6916ab0e26100012453bc5f2d3 Author: Alex Kazinsky Date: Fri Oct 23 17:08:52 2026 +0400 ASoC: tlv320aic32x4: Prevent division by zero in divider callbacks [ Upstream commit 8cf9607d2d855629260fc78e6b54ea7a98525708 ] A zero rate requested through clk_set_rate() or clk_round_rate() reaches clk_aic32x4_div_determine_rate() when the minimum rate is zero. Clamping the requested rate to the allowed range leaves it unchanged, causing division by zero when calculating the divisor. A zero parent rate can also cause division by zero in determine_rate(). For example, if reading a parent divider's register fails, clk_aic32x4_div_recalc_rate() returns zero, which the clock framework caches as the parent's rate. A subsequent rate request for a child divider receives this value in best_parent_rate. With a nonzero requested rate, the calculated divisor is zero. It passes the existing upper-bound check and causes division by zero in the resulting rate calculation. The set_rate callback can receive a zero rate when an ancestor's rate changes. clk_calc_subtree() calculates descendant rates through recalc_rate() without calling their determine_rate callbacks. If reading a descendant divider's register fails, clk_aic32x4_div_recalc_rate() returns zero. This becomes the descendant's new_rate, which clk_change_rate() passes to clk_aic32x4_div_set_rate(), causing division by zero. Reject zero rates in both callbacks and reject a zero divisor in clk_aic32x4_div_determine_rate(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a51b50062091 ("ASoC: tlv320aic32x4: Model DAC/ADC dividers in CCF") Cc: stable@vger.kernel.org Signed-off-by: Alex Kazinsky Link: https://patch.msgid.link/20261023130854.93639-1-a.kazinsky@ideco.ru Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2ea8c5695c98d2bd3e20ad71bbd9dba22cf05584 Author: Jean Delu Date: Sat Aug 8 16:00:00 2026 +0200 parisc: eisa_enumerator: Fix out-of-bounds reads of the EEPROM buffer [ Upstream commit c0a3e153804f0c14f4159ddbd2b73483c9cb3577 ] eisa_enumerator() trusts the contents of the EISA EEPROM.  The number of slots is read from the EEPROM header and used to access the slot records at HPEE_SLOT_INFO(i) = 20 + 48*i within the fixed-size eeprom_buf (HPEE_MAX_LENGTH, 8192 bytes) without any bound check.  As struct eeprom_eisa_slot_info is 48 bytes, only 170 records fit into the buffer, but num_slots is a u8 and may be up to 255, so a corrupted EEPROM makes the code read up to about 4 kB past the end of the buffer (e.g. record 254 is accessed at offset 20 + 48*254 = 12212). parse_slot_config() has the same kind of problem: it clamps config_data_length against HPEE_MAX_LENGTH but does not take config_data_offset into account, so the parser can walk past the end of the buffer even when the offset itself is valid. Clamp the number of slots so that all slot records fit into the buffer, and hand the number of bytes actually available to parse_slot_config() and bound the parse by it. Signed-off-by: Jean Delu Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 32eb5deaba546813b1aa59484e5150e7b44b0775 Author: Adrian Ambrozewicz Date: Thu Oct 22 11:33:44 2026 +0300 gpiolib: don't report -ENOMEM for a requested line without a label [ Upstream commit dae739137441667d67fbfcc4d303a0ecc6618662 ] gpiod_request_commit() sets GPIOD_FLAG_REQUESTED, calls ->request() and only then sets the label. A line in between has no label, so gpiochip_dup_line_label() passes NULL to kstrdup() and returns ERR_PTR(-ENOMEM), which for_each_hwgpio() then passes to kfree(): BUG: unable to handle page fault for address: ffcc73074355ffc8 Call Trace: gpio_sim_dbg_show gpiolib_seq_show seq_read_iter Return NULL for such a line, as for an unrequested one. Reproduced with gpio-sim: reading /sys/kernel/debug/gpio in a loop while lines are requested and released oopses within seconds; with this change, 100000 cycles pass. Fixes: 35b545332b80 ("gpio: remove gpio_lock") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20261020-gpiolib-chip-removal-v3-0-aambrozewicz@nvidia.com?part=2 Assisted-by: LLM Signed-off-by: Adrian Ambrozewicz Link: https://patch.msgid.link/20261022083343.3905973-3-aambrozewicz@nvidia.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 12031b61890f483153135ebd7e2ee7011dbb72f9 Author: Pei Xiao Date: Sat Oct 3 16:27:54 2026 +0800 tpm: fix zero-length read discarding the pending response [ Upstream commit 6fc1b05077b8ac7c3193616f0bc419f6185988c6 ] POSIX requires that a read() with a count of zero returns zero and has no other effects. tpm_common_read() treats such a call as a consumed response: it marks the pending response as read and drops it, so the response can never be retrieved; subsequent reads return zero and the next write() is allowed to overwrite the response buffer, silently breaking the command/response pairing of the TPM character devices. Return early when the caller passes a zero count, leaving any pending response untouched for the next read. A zero-length read will not report a deferred asynchronous error; POSIX permits read() to skip error detection for a zero count. Cc: stable@vger.kernel.org Fixes: 9488585b21be ("tpm: add support for partial reads") Assisted-by: GLM-5.3 Signed-off-by: Pei Xiao Link: https://lore.kernel.org/r/3f15140ab3c26e98b49d6aceaaa826585d56960b.1791015549.git.xiaopei01@kylinos.cn Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 9729fafb8354dea035b8a412800885e754294dba Author: Pei Xiao Date: Sat Oct 3 16:27:53 2026 +0800 tpm: tpm_nsc: stop using the cleanup callback as dev.release [ Upstream commit df0ef271087623439a1e900f323ed2a57204706d ] tpm_nsc_remove() is called explicitly from cleanup_nsc() and also runs as the platform device release callback on the final platform_device_put(), so the cleanup executes twice on module exit; the second invocation operates on a chip that has already been freed by the devm cleanup, and the I/O region is released twice. Overwriting the release callback installed by platform_device_alloc() also keeps platform_device_release() from running, leaking the platform object allocation. Leave the default release callback in place; the explicit call in cleanup_nsc() remains the single cleanup point. Cc: stable@vger.kernel.org Fixes: 570302a31149 ("[PATCH] tpm: move nsc driver off pci_dev") Assisted-by: GLM-5.3 Signed-off-by: Pei Xiao Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/a6155310e6772f708b47291cc959e02c05b90eb7.1791015549.git.xiaopei01@kylinos.cn Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 6f63c062c93852f384ba240a17f2f0f2041715a3 Author: Pei Xiao Date: Sat Oct 3 16:27:52 2026 +0800 tpm: tpm_nsc: fix NULL pointer dereference on init failure [ Upstream commit 1900449684cf71427a51e0bb1d7914c0c8b39152 ] tpm_nsc_remove() is used as the release callback of the hand-created platform device and dereferences the chip drvdata unconditionally. If init fails before tpmm_chip_alloc() (e.g. request_region() cannot claim the ports), the error path drops the last device reference and the release callback runs with chip == NULL, crashing module init. Return early when the chip has not been created yet. Cc: stable@vger.kernel.org Fixes: afb5abc262e9 ("tpm: two-phase chip management functions") Assisted-by: GLM-5.3 Signed-off-by: Pei Xiao Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/d5f0b38d6d6c17c01519c879d26448dbae388b0e.1791015549.git.xiaopei01@kylinos.cn Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit e73b545330ef7420f7e6269e9d8bcf7c88df29c7 Author: Navon John Lukose Date: Mon Sep 21 04:30:17 2026 +0530 i2c: designware: queue only one read command for block reads [ Upstream commit 73dae605cad7921800677d982bfaeb81cc930dec ] i2c_dw_xfer_msg() pre-queues up to rx_fifo_depth read commands based on the initial msg.len. For I2C_M_RECV_LEN transfers the real length is unknown until the first byte arrives and i2c_dw_recv_len() runs. When a large initial length is passed, the surplus pre-queued reads leave rx_outstanding non-zero after i2c_dw_recv_len() adjusts msg.len, so the completion condition is never met and the transfer times out. In a loop, this repeatedly times out the controller and disrupts unrelated driver-bound devices on the same adapter. Queue only one read command while I2C_M_RECV_LEN is pending. i2c_dw_recv_len() re-enables TX_EMPTY, and the rest are queued once the device-reported length is known. Fixes: c3ae106050b9 ("i2c: designware: Implement support for SMBus block read and write") Signed-off-by: Navon John Lukose Cc: # v4.10+ Acked-by: Mika Westerberg Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin commit ef2fbc34566643f3846f9ca77a408e867f9055e3 Author: Ma Ke Date: Mon Oct 12 09:34:21 2026 +0800 i2c: acpi: Fix adapter reference leak in i2c_acpi_new_device_by_fwnode() [ Upstream commit a65917d0a22f9b10694853b725f9cd399fc3ef4d ] i2c_acpi_new_device_by_fwnode() obtains an i2c_adapter through i2c_acpi_find_adapter_by_handle(). That helper uses bus_find_device() internally, so it returns the adapter with a reference held: adapter = i2c_verify_adapter(dev); if (!adapter) put_device(dev); return adapter; The reference is only put on the failure path inside that helper. The caller owns it otherwise. i2c_acpi_new_device_by_fwnode() never drops it, neither on the -EPROBE_DEFER path nor after i2c_new_client_device(), so every call leaks one reference on the adapter and the adapter can never be released. i2c_new_client_device() does not consume that reference. It registers the new client with the adapter as its parent, and device_add() takes its own reference on the parent, which device_del() releases when the client goes away. The reference obtained by the lookup is a separate one and has to be dropped here. i2c_acpi_notify() in the same file already does exactly this. It takes the adapter from the same helper, registers the client through i2c_acpi_register_device(), which calls i2c_new_client_device(), and then puts the reference. i2c_new_client_device() gives the client its own reference on the adapter, so ours can be dropped unconditionally. Found by code review. Fixes: 605f8fc22442 ("i2c: core: Add new i2c_acpi_new_device helper function") Signed-off-by: Ma Ke Cc: # v4.12+ Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20261012013421.3597430-1-make_ruc2021@163.com Signed-off-by: Sasha Levin commit 63fccaaff5ab770a57274a5bea254a7399565ace Author: Tristan Madani Date: Mon Oct 19 22:26:35 2026 +0000 cpufreq: intel_pstate: cancel HWP notify work in driver cleanup [ Upstream commit 0ffc7534a210105ba973167a5b86d5ab39d4031f ] intel_pstate_driver_cleanup() frees per-CPU data without cancelling the pending HWP notify delayed work. If hwp_notify_work is still scheduled or running when the struct is freed, the work function accesses freed memory via container_of(). Call intel_pstate_disable_hwp_interrupt() before kfree() to disable the interrupt source and cancel the pending work, matching the pattern used in intel_pstate_suspend() and intel_pstate_hwp_offline(). Fixes: d845cd901b28 ("cpufreq: intel_pstate: Support highest performance change interrupt") Cc: All applicable Signed-off-by: Tristan Madani [ rjw: Fixed the Fixes: tag ] Link: https://patch.msgid.link/20261019222635.1741146-1-tristmd@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b505e2bf49547930fa89f7ffeaed7ccb6737a93b Author: Nickolai Zeldovich Date: Mon Oct 19 14:59:13 2026 -0400 ucount: take the rlimit reference before checking the limit [ Upstream commit b14fcabd34e02c40f72d3cd1e9bd4fd18df40ff1 ] inc_rlimit_get_ucounts() takes the reference that pins a ucounts level while its rlimit count is non-zero only in the walk whose increment is the 0 -> 1 transition, and only after that walk passed the limit check. A walk that raises the count from zero and then fails the limit backs out without the reference, while a concurrent walk that raised it past one keeps its increment and never takes one either: CPU0 (obeys the limit) CPU1 (overrides it) new = add_return(1) -> 1 new = add_return(1) -> 2 new != 1, no get_ucounts() new > max -> dec_unwind sub_return(1) -> 1 (no put) The count is 1 with no reference held. When CPU1 drops its charge, dec_rlimit_put_ucounts() takes the count to 0 and puts a reference nobody took, which frees the live struct ucounts, and the user_namespace it pins, with kfree_rcu(). The mirror interleaving leaks the reference instead. An unprivileged user reaches this on a kernel with CONFIG_USER_NS=y: in a user namespace with RLIMIT_SIGPENDING 0, one process taking synchronous SIGSEGVs (forced, so override_rlimit is set) races a second process in the same namespace and uid that queues real-time signals, which obey the limit. The two hold different sighand->siglock but charge the same per-namespace SIGPENDING ucounts. Unpatched, with rcuref debugging: rcuref - imbalanced put() WARNING: lib/rcuref.c:266 at rcuref_put_slowpath+0xf4/0x120 put_ucounts+0x5a/0x180 do_dec_rlimit_put_ucounts+0x70/0x90 __sigqueue_free+0x33/0xc0 get_signal+0x56f/0xd20 arch_do_signal_or_restart+0x87/0x380 irqentry_exit+0x243/0x650 asm_exc_page_fault+0x26/0x30 Take the reference on the 0 -> 1 transition before the limit is checked, so the walk that raises the count from zero owns that level's reference even when its request is rejected, and unwind a rejected level through do_dec_rlimit_put_ucounts(), which releases the reference when the count returns to 0. The get_ucounts() failure path is unchanged. With the patch the same interleaving, forced some 80000 times in a KASAN build, produces no warning and no KASAN report. Fixes: 15bc01effefe ("ucounts: Fix signal ucount refcounting") Cc: stable@vger.kernel.org Signed-off-by: Nickolai Zeldovich Link: https://patch.msgid.link/20261019185913.805378-1-nickolai@csail.mit.edu Acked-by: Alexey Gladkov Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 812b0ae2933d468dc5b8c930ec33ee277ad671ec Author: Christian Brauner Date: Wed Oct 21 13:46:56 2026 +0200 listmount: don't wrap around with a U64_MAX cursor [ Upstream commit 95a5412022e437691f4eb1924ff249d9044f5ed1 ] do_listmount() takes the last mount id the caller saw and looks up the first mount after it by searching for last_mnt_id + 1. With U64_MAX that wraps around to zero and the search finds the first mount in the namespace. So a cursor at the largest possible id restarts the listing from the beginning instead of ending it. A cursor of U64_MAX - 1 correctly returns nothing. No mount will ever have that id. Mount ids come from a counter that starts at MNT_UNIQUE_ID_OFFSET + 1 and a caller that only feeds back ids it got from us can't hit this. It's still wrong. Nothing can come after the largest possible id so return no entries for it, just like for any other cursor past the last mount. The reverse direction isn't affected. A cursor of zero is special-cased and anything else is larger than MNT_UNIQUE_ID_OFFSET so last_mnt_id - 1 can't underflow. Reproducer, unprivileged: #define _GNU_SOURCE #include #include #include #include #include #define LSMT_ROOT 0xffffffffffffffffULL struct mnt_id_req { uint32_t size, mnt_ns_fd; uint64_t mnt_id, param, mnt_ns_id; }; static void list(uint64_t cursor) { struct mnt_id_req req = { .size = sizeof(req), .mnt_id = LSMT_ROOT, .param = cursor, }; uint64_t ids[8]; long ret; errno = 0; ret = syscall(__NR_listmount, &req, ids, 8, 0); printf("cursor %llu: ret %ld errno %d", (unsigned long long)cursor, ret, errno); for (long i = 0; i < ret && i < 1; i++) printf("%s%llu", i ? "," : " ids ", (unsigned long long)ids[i]); printf("%s\n", ret > 1 ? ",..." : ""); } int main(void) { list(0); list(UINT64_MAX - 1); list(UINT64_MAX); return 0; } Before, on 7.3.0-rc7-00252-g4e3259b08c54 (vfs.fixes) in a VM: cursor 0: ret 5 errno 0 ids 2147483651,... cursor 18446744073709551614: ret 0 errno 0 cursor 18446744073709551615: ret 5 errno 0 ids 2147483651,... After: cursor 0: ret 5 errno 0 ids 2147483651,... cursor 18446744073709551614: ret 0 errno 0 cursor 18446744073709551615: ret 0 errno 0 Reported-by: shaos Link: https://lore.kernel.org/r/20261020110732.959552-1-shawnq1@163.com Fixes: b4c2bea8ceaa ("add listmount(2) syscall") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261021-work-mount-statmount_listns_fixes-v1-3-8917a4c1bd14@kernel.org Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit adbd15a2d4a92eeff7eacee40c378460d0ea0c6f Author: Christian Brauner Date: Wed Oct 21 13:46:54 2026 +0200 statmount: don't copy the reserved empty string past the buffer [ Upstream commit 11eef75006819f4e71d04ca2b9a1fb1580854a55 ] statmount_string() reserves an empty string at the start of the seq buffer before it calls the handler for the requested string. That's what the offsets of unset strings point to since commit e52e97f09fb6 ("statmount: let unset strings be empty"). If the handler emits nothing the early return from commit 75ead69a7173 ("fs: don't let statmount return empty strings") skips the size check against the caller's buffer. Back then an empty emission meant an empty seq buffer and there was nothing to copy. Now the reserved NUL byte is there and copy_statmount_to_user() copies it to buf + sizeof(struct statmount) no matter how small bufsize is. So request a string that may turn out empty with a buffer that's smaller than struct statmount and the kernel writes one zero byte past the caller's buffer and reports a size that's larger than the buffer. STATMOUNT_MNT_UIDMAP or STATMOUNT_MNT_GIDMAP on a mount that isn't idmapped will do, so will STATMOUNT_FS_SUBTYPE on anything but fuse or STATMOUNT_OPT_ARRAY on a filesystem without ->show_options(). None of this needs privileges. The byte only lands in the caller's own address space but that's still not ok. prepare_kstatmount() already refuses a buffer of exactly sizeof(struct statmount) for string requests. A smaller buffer can't hold a string either and it can't even hold the reserved empty string. So refuse any buffer that isn't larger than the fixed part. That's also what the uapi header says: string requests need space after the fixed part of the structure. Reproducer, unprivileged, on any mount that isn't idmapped: #define _GNU_SOURCE #include #include #include #include #include #include #include #include #define STATMOUNT_FS_SUBTYPE 0x00000100U #define STATMOUNT_MNT_UIDMAP 0x00002000U #define STATX_MNT_ID_UNIQUE 0x00004000U #define SM_SIZE 512 /* sizeof(struct statmount) */ struct mnt_id_req { uint32_t size, mnt_ns_fd; uint64_t mnt_id, param, mnt_ns_id; }; static uint64_t root_mnt_id(void) { unsigned char stx[256]; /* struct statx, stx_mnt_id at offset 144 */ uint64_t id; if (syscall(__NR_statx, AT_FDCWD, "/", 0, STATX_MNT_ID_UNIQUE, stx)) _exit(1); memcpy(&id, stx + 144, sizeof(id)); return id; } static void probe(uint64_t mnt_id, uint64_t mask, int guard) { struct mnt_id_req req = { .size = sizeof(req), .mnt_id = mnt_id, .param = mask, }; long page = sysconf(_SC_PAGESIZE); unsigned char *map, *buf; uint32_t size; long ret; map = mmap(NULL, 2 * page, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); memset(map, 0xaa, 2 * page); /* 100 byte buffer ending right at the page boundary */ buf = map + page - 100; if (guard) mprotect(map + page, page, PROT_NONE); errno = 0; ret = syscall(__NR_statmount, &req, buf, 100, 0); printf("mask 0x%04llx%s: ret %ld errno %d", (unsigned long long)mask, guard ? " guard page" : "", ret, errno); if (!guard) { memcpy(&size, buf, sizeof(size)); printf(", size 0x%x, byte[%d] 0x%02x", size, SM_SIZE, buf[SM_SIZE]); } printf("\n"); munmap(map, 2 * page); } int main(void) { uint64_t id = root_mnt_id(); probe(id, STATMOUNT_MNT_UIDMAP, 0); probe(id, STATMOUNT_FS_SUBTYPE, 0); probe(id, STATMOUNT_MNT_UIDMAP, 1); return 0; } Before, on 7.3.0-rc7-00252-g4e3259b08c54 (vfs.fixes) in a VM, the same on a distro 7.1.13: mask 0x2000: ret 0 errno 0, size 0x65, byte[512] 0x00 mask 0x0100: ret 0 errno 0, size 0x65, byte[512] 0x00 mask 0x2000 guard page: ret -1 errno 14 After: mask 0x2000: ret -1 errno 75, size 0xaaaaaaaa, byte[512] 0xaa mask 0x0100: ret -1 errno 75, size 0xaaaaaaaa, byte[512] 0xaa mask 0x2000 guard page: ret -1 errno 75 Reported-by: shaos Link: https://lore.kernel.org/r/20261020110747.959829-1-shawnq1@163.com Fixes: e52e97f09fb6 ("statmount: let unset strings be empty") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261021-work-mount-statmount_listns_fixes-v1-1-8917a4c1bd14@kernel.org Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 580d7a5542f94b5c88b71c06bda99da3cad5d5bf Author: Chuck Lever Date: Thu Oct 8 10:09:03 2026 -0400 exportfs: Release the get_name() directory file synchronously [ Upstream commit 49184daab01674ca400cbef58ee101dba6dbbb9d ] get_name() opens the parent directory with dentry_open() and releases it with fput(). From a kernel thread, fput() defers the final __fput() to the delayed_fput work item. NFSD threads are kernel threads, and NFSD reaches get_name() through exportfs_decode_fh() whenever a file handle's dentry is not connected to the root. On a filesystem with more directories than the dcache retains, nearly every READDIRPLUS needs a reconnect. The deferred releases arrive faster than the work item retires them, and each pending file pins the directory's readdir state. On ext4 that state is the htree fname cache for the last leaf block read. A 64-thread NFSv3 server under a parallel tree walk showed unreclaimable slab growing by about 90 MB per second, and the same workload on a 5.15 kernel ended in a global OOM. Commit 5ff318f645eb ("nfsd: use __fput_sync() to avoid delayed closing of files.") stopped NFSD's own closes from feeding the delayed_fput queue but did not cover the exportfs reconnect path. Release the file with __fput_sync(). get_name() opened the file itself, read-only, on a directory, so __fput() involves nothing that could wait on the caller. Note for LTS backports: Kernels before v6.6 need the __fput_sync() call guarded by current->flags & PF_KTHREAD, with a plain fput() otherwise. Fixes: 4a9d4b024a31 ("switch fput to task_work_add") Cc: stable@vger.kernel.org # see above, needs adjustments for < v6.2 Reported-by: Danny Pidutti Closes: https://lore.kernel.org/linux-fsdevel/DS4PR04MB9846BA3C16BC5ACED8B589228D952@DS4PR04MB9846.namprd04.prod.outlook.com/ Tested-by: Danny Pidutti Reviewed-by: Benjamin Coddington Signed-off-by: Chuck Lever Link: https://patch.msgid.link/20261008140903.2784-1-cel@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit cb524d331c23234679c957de3fdee638b909b9f4 Author: Henry Martin Date: Mon Oct 19 19:58:59 2026 +0800 tipc: fix broadcast sender hang on last acker departure [ Upstream commit f4377bf85887f57b59abb5479f7660a81ffe4449 ] TIPC group broadcast senders are blocked while a replicast still has outstanding member acks: tipc_group_bc_cong() returns true as long as grp->bc_ackers is non-zero, and clears *grp->open, which is what tipc_poll() uses to report EPOLLOUT (via tsk->group_is_open). When the last outstanding acker departs before acking, tipc_group_delete_member() decrements grp->bc_ackers to zero but never restores *grp->open. As a result poll(EPOLLOUT) never fires again. A writer blocked in sendmsg() is only released if some other wakeup happens after the deletion: with TIPC_GROUP_MEMBER_EVTS the leave event delivery calls sk_data_ready() and wakes it, but without member events nothing does and it sleeps indefinitely, since the default send timeout is MAX_SCHEDULE_TIMEOUT. Commit 99cc2a62e07a ("tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers underflow") already calls this out in its changelog as a pre-existing issue. Restore the open state exactly on the 1->0 transition in the delete path, mirroring the GRP_ACK_MSG completion path, and invoke sk->sk_write_space() from tipc_sk_filter_rcv() when the group just became writable again. Also make the ack accounting precise. The delete path used to test less(m->bc_acked, grp->bc_snd_nxt - 1), which also matches members that were never counted for the current replicast (JOINING/LEAVING members keep a stale bc_acked), and the GRP_ACK_MSG handler accepted an ack from any member whose bc_acked differed from the expected value. Either could zero bc_ackers on behalf of a member that owes nothing and silently void an ack still owed by a real acker. Track whether a member owes an ack for the current replicast in a new per-member bc_pending flag, set when the member is counted and cleared when its ack arrives, and use it both to accept an ack and to decide on deletion. bc_acked has no remaining user and is removed. Suggested by Tung Quang Nguyen. This issue was discovered by Tencent CodeBuddy Security. Cc: stable@vger.kernel.org Fixes: 2f487712b893 ("tipc: guarantee that group broadcast doesn't bypass group unicast") Signed-off-by: Henry Martin Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20261019115859.3471295-1-bsdhenrymartin@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e2730951db372af27810e7506121b3715459910f Author: Liu Chao Date: Tue Oct 20 17:42:49 2026 +0800 net: wwan: iosm: validate msg_head before indexing msg_ring [ Upstream commit 46cbf85155e5451b6682ea0c17bc62ec564aec36 ] ipc_protocol_free_msg_get() reads msg_head from shared memory and uses it directly as an index into msg_ring[]. If the head is out of range, the subsequent memset() writes beyond the message ring. Validate head against IPC_MEM_MSG_ENTRIES before using it as an index. The ring is a circular buffer, so a value outside the valid range indicates a corrupted head pointer; report the error and fail the allocation instead of writing out of bounds. Fixes: 64516f633bfd ("net: iosm: protocol operations") Cc: stable@vger.kernel.org Reviewed-by: Fang Xieyan Signed-off-by: Liu Chao Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20261020094254.4017726-1-liuc63@xiaopeng.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 123b86359529bc983d81fdd31a1de6f6d3f1bd63 Author: Yu Zhang Date: Tue Oct 20 12:50:47 2026 +1000 nvmet: take subsys->lock while force-reconnecting in nvmet_subsys_attr_qid_max_store() [ Upstream commit 9f426f14051181e251590783e68ce589a63e2b1c ] nvmet_subsys_attr_qid_max_store() sets subsys->max_qid and then walks subsys->ctrls to force every controller to reconnect, but it holds only nvmet_config_sem (for write). subsys->ctrls is protected by subsys->lock: nvmet_alloc_ctrl() adds an entry under subsys->lock, and nvmet_ctrl_free() removes it under subsys->lock with list_del() + kfree() (not kfree_rcu). The free path takes no nvmet_config_sem, so the two locks are independent. A controller teardown (host disconnect, keep-alive timeout or fatal error -> nvmet_sq_destroy() -> nvmet_ctrl_put() -> nvmet_ctrl_free()) can therefore list_del() an entry while qid_max_store() is iterating the list, corrupting the walk. KASAN, concurrent "echo 128 > .../subsystems//attr_qid_max" racing nvme-loop controllers connecting and disconnecting, panics in seconds: BUG: KASAN: null-ptr-deref in nvmet_subsys_attr_qid_max_store+0x10d/0x1b0 Read of size 8 at addr 0000000000000090 Call Trace: nvmet_subsys_attr_qid_max_store+0x10d/0x1b0 configfs_write_iter+0x1a7/0x250 vfs_write+0x5df/0x940 ksys_write+0xfd/0x1e0 (also seen as a general-protection fault dereferencing a LIST_POISON pointer at the same instruction.) Take subsys->lock around the list_for_each_entry() loop, matching every other subsys->ctrls accessor. ->delete_ctrl() only queues asynchronous controller teardown, so it does not re-enter subsys->lock under the loop. Fixes: 3e980f5995e0 ("nvmet: expose max queues to configfs") Cc: stable@vger.kernel.org Reviewed-by: Maurizio Lombardi Signed-off-by: Yu Zhang Tested-by: Yu Zhang Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 4f468f2e7c2692d41094a404864e766c19a79672 Author: Runyu Xiao Date: Fri Oct 9 12:02:48 2026 +0800 sh: maple: Use the matching IRQ cookie when invoking free_irq() [ Upstream commit e3ef44e77b40e3cecfb34757ff3c15ecceea0309 ] The Maple DMA and VBLANK handlers are registered with &maple_unsupported_device as their dev_id. Passing NULL to free_irq() cannot find either action, so the handlers remain registered and the IRQ core warns. Use the same cookie when freeing both handlers on the error paths. Fixes: b3c69e248176 ("maple: more robust device detection.") Signed-off-by: Runyu Xiao Assisted-by: LLM Cc: stable@vger.kernel.org Tested-by: Florian Fuchs Reviewed-By: Florian Fuchs Reviewed-by: John Paul Adrian Glaubitz Signed-off-by: John Paul Adrian Glaubitz Signed-off-by: Sasha Levin commit 15e797bedb7f04ac40147d0a1a45672df019f831 Author: Henrik Enquist Date: Wed Oct 21 09:46:45 2026 +0200 ALSA: aloop: Update the PCM Slave controls for a matching playback [ Upstream commit c3bde2beacbcb40790f0e3c3f909f9e16bbced9c ] The "PCM Slave" format, rate, channels and access controls report the parameters of the playback side of a cable. loopback_check_format() updates them when a playback starts, but returns early when a capture is open and its parameters match. The controls then keep the module defaults, or the parameters of an earlier stream. A playback that joins an open capture with the same parameters is the normal case without notify, where it is constrained to the capture's parameters, and also with notify whenever the player happens to use them. An application that reads the controls to find the playback's parameters, for example to reopen the capture side at the right rate after a restart, then gets the wrong values. Only skip the capture stop when the parameters match, and update the controls in every case. A value event is still sent only for a control whose value changes. Reproducer: arecord -D hw:Loopback,1,0 -r 44100 -f S16_LE -c 2 /dev/null & aplay -D hw:Loopback,0,0 -t raw -r 44100 -f S16_LE -c 2 /dev/zero & amixer -c Loopback cget "iface=PCM,name='PCM Slave Rate',device=1" Before: the control reports 48000, the module default. After: it reports 44100. Fixes: 597603d615d2 ("ALSA: introduce the snd-aloop module for the PCM loopback") Cc: stable@vger.kernel.org Signed-off-by: Henrik Enquist Link: https://patch.msgid.link/20261021-aloop-slave-controls-v1-1-62297727177f@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bda6505703a3c197d19415de93ddc2efe0a493e6 Author: Julian Sun Date: Fri Oct 16 19:52:30 2026 +0800 writeback: clear old wb dirty state after inode switches [ Upstream commit a396fe9f74ea367ae3fab2dcb70b24e83db9f0cb ] Switching an inode to another wb updates the target wb's dirty-I/O state, but no longer checks whether the source wb's dirty-I/O lists became empty. The check was lost when inode_io_list_del_locked(inode, old_wb) was removed to support tracking clean attached inodes. If the last dirty inode is moved, WB_has_dirty_io remains set on the old wb and its bandwidth contribution remains in bdi->tot_write_bandwidth. This can keep an empty wb scheduled for periodic writeback and overstate the total bandwidth used to distribute writeback work. Call wb_io_lists_depopulated() on the old wb after the batch of inode switches, while its list_lock is still held. This clears the flag and removes the bandwidth contribution if its dirty-I/O lists are empty. Fixes: f3b6a6df38aa ("writeback, cgroup: keep list of inodes attached to bdi_writeback") Cc: stable@vger.kernel.org Signed-off-by: Julian Sun Link: https://patch.msgid.link/20261016115230.3640770-3-sunjunchao@bytedance.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 96f8492696a6afda56bd634c61d37d949fa0cd5d Author: Julian Sun Date: Fri Oct 16 19:52:29 2026 +0800 writeback: reset dirtied_when when switching wbs [ Upstream commit 13b9a606dd0a6cf9bac12894c97b9546d22a7425 ] When switching a dirty inode to another wb, inode_do_switch_wbs() puts it at the newest end of the target b_dirty list instead of searching for its sorted position. This requires updating dirtied_when, which move_expired_inodes() uses to decide where to stop scanning. However, the switch updates dirtied_time_when instead. This leaves b_dirty out of order and can make the scan stop before reaching older inodes. It also resets the lazytime expiration timestamp, potentially delaying timestamp writeback. Update dirtied_when instead, preserving both the constant-time insertion and the lazytime expiration timestamp. Correct the field name in the comment and document the distinction between the two inode timestamps. Fixes: 9a6ebbdbd412 ("writeback: Avoid excessively long inode switching times") Cc: stable@vger.kernel.org Signed-off-by: Julian Sun Link: https://patch.msgid.link/20261016115230.3640770-2-sunjunchao@bytedance.com Acked-by: Tejun Heo Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit b12b766b93d7f0c99269a9c81b56bcdb702315ec Author: Bartu Alev Date: Sat Oct 10 13:15:58 2026 +0300 platform/x86: asus-wmi: fix TUF keyboard power state shutdown naming [ Upstream commit 3d9a175707eeb15a2d577af1e669b98e0236719b ] The fourth state flag of kbd_rgb_state_index is named "keyboard" and has long been treated as having no effect. In hardware the flag, BIT(7) of the payload sent to the TUF RGB state device, gates whether the keyboard backlight stays lit while the machine powers off: with the bit set the keyboard lights up white during the ACPI S5 sequence, with the bit clear the machine powers off dark. Verified by A/B testing both values on a TUF Gaming A15 (FA507NV). Rename the fourth field and its index entry from "keyboard" to "shutdown". The write format is unchanged, the value is still positional, and the diff is two variable names and one string, so it backports cleanly. Fixes: 61f64515299e ("platform/x86: asus-wmi: Implement TUF laptop keyboard power states") Cc: stable@vger.kernel.org Signed-off-by: Bartu Alev Link: https://patch.msgid.link/20261010101601.888709-3-bartualev@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 2088b171b781d91b6f2d365c0e6b0f5dc7608aa2 Author: Michael Kelley Date: Mon Oct 12 18:43:54 2026 -0700 Documentation: hyperv: Update documentation for sending VMBus packets [ Upstream commit 6a3d77a0a8cf69cf3d234305e6711729eb5d10c4 ] The functions for sending VMBus packets have changed. vmbus_sendpacket_mpb_desc() can target multiple ranges, and vmbus_sendpacket_pagebuffer() has been removed. vmbus_sendpacket_getid() has been added. Update the documentation accordingly. Fixes: 45a442fe369e ("Drivers: hv: vmbus: Remove vmbus_sendpacket_pagebuffer()") Cc: stable@vger.kernel.org Signed-off-by: Michael Kelley Reviewed-by: Naman Jain Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit e9e88ecb1a17a6632de8b9d0237fa3102155fa59 Author: Cen Zhang Date: Fri Oct 16 00:58:38 2026 +0800 ocfs2/cluster: initialize heartbeat regions before publishing them [ Upstream commit c5b7a30a5172317e1e3cba61d8c9f9c588c497bb ] A region on o2hb_all_regions must have an initialized config item and name. o2hb_heartbeat_group_make_item() currently links the zeroed region under o2hb_live_lock, drops the lock, and only then initializes hr_item. The lock therefore protects the list without protecting initialization from readers of the published item. With global heartbeat enabled, a DLM_QUERY_REGION from the current joining node can pass the existing-domain and protocol checks while a configfs mkdir creates another region. The DLM locks are not taken by the constructor, and the network worker does not take the configfs subsystem mutex. The following ordering is possible: Configfs mkdir O2net receive worker -------------- -------------------- Allocate reg Lock o2hb_live_lock Link into o2hb_all_regions Unlock o2hb_live_lock dlm_query_region_handler() dlm_match_regions() o2hb_get_all_regions() Lock o2hb_live_lock Copy 32 bytes from NULL name Unlock o2hb_live_lock config_item_init_type_name() The query thus dereferences NULL. Initialize hr_item before linking the region so the existing list lock also orders name initialization before any reader. Reject a failed name allocation, since the initialization helper does not propagate that error. Use config_item_put() on initialized constructor failures to release the name and respect references retained by o2hb_region_pin(). Initialize the list heads, mutex and delayed works needed by o2hb_region_release() before any such put, and leave the list node self-linked after rollback. Keep the existing handler drain before removing a failed published item. KASAN report as below: ================================================================== BUG: KASAN: null-ptr-deref in o2hb_get_all_regions+0xbb/0x1f0 Read of size 32 at addr 0000000000000000 by task kworker/u16:1/14 CPU: 2 UID: 0 PID: 14 Comm: kworker/u16:1 Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: o2net o2net_rx_until_empty Call Trace: dump_stack_lvl+0x93/0xd0 kasan_report+0xe0/0x110 ? o2hb_get_all_regions+0xbb/0x1f0 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 o2hb_get_all_regions+0xbb/0x1f0 dlm_query_region_handler+0x4c2/0xc20 ? __pfx_dlm_query_region_handler+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? kvm_clock_get_cycles+0x31/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_dlm_query_region_handler+0x10/0x10 o2net_rx_until_empty+0x1a50/0x3200 ? reacquire_held_locks+0xdd/0x200 ? __pfx_o2net_rx_until_empty+0x10/0x10 ? lock_acquire+0x190/0x300 ? process_one_work+0x935/0x1b40 ? process_one_work+0x834/0x1b40 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 process_one_work+0x9a8/0x1b40 ? __pfx_process_one_work+0x10/0x10 ? lock_acquire+0x190/0x300 ? lock_is_held_type+0x8f/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x65c/0xe40 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kthread_parkme+0x177/0x220 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_worker_thread+0x10/0x10 kthread+0x351/0x460 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x659/0x940 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x74f/0xf70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ================================================================== Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0079-v5-f931a29339cadc0a2a70@gmail.com Fixes: 536f0741f324 ("ocfs2/cluster: Track number of global heartbeat regions") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Yufan Chen Cc: Christophe JAILLET Cc: Kees Cook Cc: Karl Mehltretter Cc: Sunil Mushran Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Sasha Levin commit c5f1d0ba08f8511beed03aae739fca18c64eb6e3 Author: Joseph Qi Date: Fri Oct 9 16:30:02 2026 +0800 ocfs2: deal with legacy signed xattr name hash values [ Upstream commit 824d26d11448b4d4f19677bce27c7fe5e962f4c6 ] Commit 3bc753c06dd0 ("kbuild: treat char as always unsigned") set -funsigned-char globally, which changed the result of the naked 'char' load in ocfs2_xattr_name_hash(): hash = (hash << OCFS2_HASH_SHIFT) ^ (hash >> (8*sizeof(hash) - OCFS2_HASH_SHIFT)) ^ *name++; A name byte >= 0x80 used to sign-extend and now zero-extends, so the hash no longer matches the xe_name_hash an older kernel stored. An indexed xattr tree is searched by that hash alone, and both the bucket binary search and the entry scan within it stop as soon as the wanted hash falls below an entry's, so the entry is never reached: getxattr, setxattr and removexattr return -ENODATA for a name that listxattr still lists. Search with the current unsigned hash and, on a miss, retry with the legacy signed one, as ext4 does in commit f3bbac32475b2 ("ext4: deal with legacy signed xattr name hash values"). New entries are always stored under the unsigned hash. Skip the retry when the two hashes are equal, so that a miss on an ASCII name does not walk the tree twice. A miss is not empty handed: ocfs2_xattr_bucket_find() leaves xs->bucket holding the bucket a new entry would go into. So after a double miss drop it and search once more with the unsigned hash, otherwise a new entry would be placed by its legacy hash and stored under its unsigned one, breaking the ordering the search relies on. Only indexed trees are affected; inline xattrs and non-indexed xattr blocks compare names with memcmp and never look at the hash. Also spell out the signedness instead of leaving the current hash to -funsigned-char, as commit 854f0912f813 ("ext4: make xattr char unsignedness in hash explicit") did, so that both variants stay correct if this is backported to a kernel without the flag. Link: https://lore.kernel.org/20261009083002.2621201-4-joseph.qi@linux.alibaba.com Fixes: 3bc753c06dd0 ("kbuild: treat char as always unsigned") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Reviewed-by: Heming Zhao Cc: Anderson Ferneda Cc: Mark Fasheh Cc: Joel Becker Cc: # 6.2+ Signed-off-by: Sasha Levin commit 374d7cfabd620935b39786120dda6a88ff1a808d Author: Joseph Qi Date: Fri Oct 9 16:30:01 2026 +0800 ocfs2: use the stored hash when checking xattr bucket collision [ Upstream commit e39baff18b85cf8956aee138d7944b6581e8ba36 ] ocfs2_check_xattr_bucket_collision() decides whether splitting a full bucket can make room for the entry being set by recomputing the hash of the name: u32 name_hash = ocfs2_xattr_name_hash(inode, name, strlen(name)); if (name_hash != le32_to_cpu(xh->xh_entries[0].xe_name_hash)) return 0; For a new entry that is the hash it will be stored under, so comparing it is correct. An existing entry keeps the hash it already has: an update never rewrites xe_name_hash, since ocfs2_xa_add_entry() is the only writer of that field for a real entry and ocfs2_xa_prepare_entry() calls it only when loc->xl_entry is NULL. An entry stored by a kernel that sign-extended the name bytes when hashing can still be updated, because ocfs2_xattr_find_entry() searches a non-indexed xattr block by memcmp on the name and never looks at xe_name_hash. Growing it past the space left in the block converts the block into a tree, ocfs2_cp_xattr_block_to_bucket() fills the bucket in stored hash order, and the update runs out of room in the bucket too. The collision check then compares the unsigned hash against the legacy hashes in the bucket and reports no collision. ocfs2_xattr_set_entry_index_block() goes on to allocate a bucket that ocfs2_divide_xattr_bucket() cannot fill: a bucket whose entries all share one hash has no divide position, so all it does is append an empty bucket with a sentinel hash one above the last entry's. The re-search that follows depends on where the unsigned hash sorts. Below the legacy ones, it comes back to the full bucket and the set fails with -ENOSPC, having grown the tree for nothing. Above them, it lands on the new empty bucket, which ocfs2_xattr_bucket_find() handles explicitly and ocfs2_find_xe_in_bucket() scans zero times, so the set stores a second copy of the entry under the unsigned hash and returns success. The original stays in the full bucket, listxattr reports the name twice and getxattr returns the new copy. Pass the hash the entry is stored under instead: the stored one for an existing entry, the unsigned one for a new entry. A tree whose entries are all stored under the unsigned hash sees no change, since there the two are the same value. Link: https://lore.kernel.org/20261009083002.2621201-3-joseph.qi@linux.alibaba.com Fixes: 3bc753c06dd0 ("kbuild: treat char as always unsigned") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Reviewed-by: Heming Zhao Cc: Anderson Ferneda Cc: Mark Fasheh Cc: Joel Becker Cc: # 6.2+ Signed-off-by: Sasha Levin commit e96ffa8f70e346cfd69a8919129d579710e78993 Author: Joseph Qi Date: Fri Oct 9 16:30:00 2026 +0800 ocfs2: deal with legacy signed dir index name hash values [ Upstream commit d1b49d5ea1bf43cce2b0e249a7f7a30dde133907 ] Patch series "ocfs2: deal with legacy signed name hash values", v2. Commit 3bc753c06dd0 ("kbuild: treat char as always unsigned") turned on -funsigned-char globally, which changed the result of two naked 'char' loads in ocfs2 hashing code: str2hashbuf() val = msg[i] + (val << 8); ocfs2_xattr_name_hash() hash = (hash << 5) ^ (hash >> 27) ^ *name++; A name byte >= 0x80 used to sign-extend and now zero-extends. Both results are written to disk, the first into the dx leaf when a directory entry is indexed and the second into xe_name_hash when an xattr is stored, so anything written by a pre-6.2 kernel is looked up under a different hash and is no longer found. readdir and listxattr still list those names because neither of them hashes, which makes this look like the filesystem losing entries rather than like a lookup bug. Anderson Ferneda reported it that way for directories with non-ASCII names [1]. Patches 1 and 3 do what ext4 did in commit f3bbac32475b2 ("ext4: deal with legacy signed xattr name hash values"): look up with the current unsigned hash, retry with the legacy signed one on a miss, and always store new entries under the unsigned hash. The retry is skipped when the two hashes come out equal, so an ASCII name does not walk the index twice. Both hash functions now spell out the signedness instead of leaving it to -funsigned-char, as commit 854f0912f813 ("ext4: make xattr char unsignedness in hash explicit") did, so a backport to a kernel without the flag still computes both variants correctly. Patch 2 is a separate fix, placed before patch 3 so that every commit in the series is correct on its own. ocfs2_check_xattr_bucket_collision() recomputes the hash of the name to decide whether splitting a full bucket can make room for the entry being set. That is right for a new entry and wrong for one that already exists, since an update leaves xe_name_hash alone. Against a bucket holding legacy hashes the comparison does not match, so the split goes ahead and cannot help: a bucket whose entries all share one hash has no divide position. How that ends depends on where the unsigned hash sorts. Below the legacy ones, the set fails with -ENOSPC after growing the tree for nothing. Above them, it lands in the empty bucket the split just appended and stores a second copy of the entry there while the original stays behind, so listxattr reports the name twice. Using the stored hash closes both. Nothing retires a legacy hash at runtime. Deleting or updating an entry does not rewrite it, and the only code that rehashes existing dirents is ocfs2_expand_inline_dir() on the inline to extent conversion, so the retry stays for as long as the legacy entries do. Rebuilding the index offline is what removes it for good. This patch (of 3): Commit 3bc753c06dd0 ("kbuild: treat char as always unsigned") set -funsigned-char globally, which changed the result of the naked 'char' load in str2hashbuf(): val = msg[i] + (val << 8); A name byte >= 0x80 used to sign-extend and now zero-extends, so ocfs2_dx_dir_name_hash() computes a different hash pair for every name containing one. The pair is written into the dx leaf when the entry is created, so an index built by an older kernel no longer matches and ocfs2_dx_dir_search() returns -ENOENT for a name that readdir still lists. Search with the current unsigned hash and, on a miss, retry with the legacy signed one, as ext4 does in commit f3bbac32475b2 ("ext4: deal with legacy signed xattr name hash values"). New entries are always indexed under the unsigned hash. Skip the retry when the two hashes are equal, so that a miss on an ASCII name does not walk the index twice. The retry costs a second walk of the dx tree, so a negative lookup of a name containing a byte >= 0x80 does twice the work. That is bounded and worth it, and directories whose dx root is still inline pay nothing extra, since there the retry only rescans the root block that is already loaded. Nothing retires it at runtime: a legacy entry keeps its legacy hash, because neither deleting nor updating an entry rewrites the dx hash, and the only code that rehashes existing dirents is ocfs2_expand_inline_dir() on the inline to extent conversion. Rebuilding the index offline is what removes the cost for good. Also spell out the signedness in str2hashbuf() instead of leaving the current hash to -funsigned-char, as commit 854f0912f813 ("ext4: make xattr char unsignedness in hash explicit") did, so that both variants stay correct if this is backported to a kernel without the flag. Link: https://lore.kernel.org/20261009083002.2621201-1-joseph.qi@linux.alibaba.com Link: https://lore.kernel.org/20261009083002.2621201-2-joseph.qi@linux.alibaba.com Fixes: 3bc753c06dd0 ("kbuild: treat char as always unsigned") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Reported-by: Anderson Ferneda Closes: https://lore.kernel.org/ocfs2-devel/CP5P284MB2780AC2C3C2AB2CF2B6CB7AFBE942@CP5P284MB2780.BRAP284.PROD.OUTLOOK.COM/ Reviewed-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: # 6.2+ Signed-off-by: Sasha Levin commit fa93db51c6b9de54770ed6715a0cb5d20934ffca Author: Joseph Qi Date: Sat Oct 10 19:34:53 2026 +0800 ocfs2: reserve value tree metadata when moving an xattr into the inode [ Upstream commit f5aee8ae5f85f8dfa78160e5c4963494319cdd64 ] ocfs2_calc_xattr_set_need() charges no metadata for the case where an xattr living in an xattr block or bucket moves back into the inode: if (old_in_xb) { if (ocfs2_xattr_can_be_in_inode(inode, xi, xis)) { clusters_add += new_clusters; credits += ...; if (!ocfs2_xattr_is_local(xe)) credits += ocfs2_calc_extend_credits(...); goto out; } } The credits for extending a value tree are there but the matching blocks are not, so meta_add stays 0, ocfs2_init_xattr_set_ctxt() skips ocfs2_reserve_new_metadata_blocks() and ctxt->meta_ac is left NULL. This is the shape commit 0cdc7dde00ec ("ocfs2: fix missing metadata reservation for large xattrs") fixed for the xattr block case, and it is reached the same way: namevalue_size() charges a value larger than OCFS2_XATTR_INLINE_SIZE as only OCFS2_XATTR_ROOT_SIZE, so ocfs2_xattr_can_be_in_inode() accepts a new value that will be stored outside. ocfs2_xa_prepare_entry() installs a value root from def_xv and grows it, and once the cluster allocator is fragmented enough to need a second extent ocfs2_add_clusters_in_btree() finds the root full with no meta_ac at all and answers RESTART_META. ocfs2_xattr_extend_allocation() turns that into -ENOSPC, or into a BUG_ON() without that commit, and ocfs2_xa_cleanup_value_truncate() takes its !orig_clusters arm, dropping the entry and leaking the clusters already handed out until fsck.ocfs2 reclaims them. Reserve for the value tree here too. The entry moves back into the inode rather than into a new xattr block, so unlike the create side of meta_guess this needs no block of its own. Link: https://lore.kernel.org/20261010113454.1420939-3-joseph.qi@linux.alibaba.com Fixes: 78f30c314a74 ("ocfs2/xattr: Reserve meta/data at the beginning of ocfs2_xattr_set.") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Cc: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Signed-off-by: Sasha Levin commit cdba7a2e76c4a5742b831601d7cfa511ac418426 Author: Joseph Qi Date: Sat Oct 10 19:34:52 2026 +0800 ocfs2: reserve metadata for a new xattr block and its value tree [ Upstream commit 8ad5fa0c11246d260d7b12c9672e604b1f431b2e ] Patch series "ocfs2: fix metadata reservation for xattr value trees". ocfs2_calc_xattr_set_need() reserves too little metadata for a new xattr value's extent tree on three paths. The reservation cannot be topped up once the transaction has started, so ocfs2_add_clusters_in_btree() gives up with RESTART_META when the value root fills and nothing is left. ocfs2_xattr_extend_allocation() turns that into -ENOSPC, after ocfs2_xa_cleanup_value_truncate() has dropped the entry and leaked the clusters already handed out; before commit 0cdc7dde00ec ("ocfs2: fix missing metadata reservation for large xattrs") it was a BUG_ON() instead. It takes a fragmented cluster allocator to get there, since the first extent always fits in the root. Patch 1 fixes the create side of meta_guess: commit 3ed2be719eb9 ("ocfs2: allow for more than one data extent when creating xattr") replaced the block reserved for the new xattr block with the two the value tree needs instead of adding them together. Patch 2 fixes the arm that moves an xattr back into the inode, which charges credits for a value tree but no metadata for one. Patch 3 drops a second copy of the same reservation on the path that falls through to meta_guess. That one is cleanup rather than a fix and is not for stable, and it must not be backported without patch 1: the duplicate it removes is what currently covers the shortfall patch 1 fixes. This patch (of 3): The create side of meta_guess in ocfs2_calc_xattr_set_need() reserves metadata for the new value's extent tree and nothing for the xattr block that will hold it: } else { credits += OCFS2_XATTR_BLOCK_CREATE_CREDITS; if (xi->xi_value_len > OCFS2_XATTR_INLINE_SIZE) { struct ocfs2_extent_list *el = &def_xv.xv.xr_list; meta_add += ocfs2_extend_meta_needed(el); ... Commit 3ed2be719eb9 ("ocfs2: allow for more than one data extent when creating xattr") meant to add that tree on top of the meta_add += 1 the branch already had, but it moved the 1 into the else arm instead, so the external-value case lost it. The 1 is not optional: it is what ocfs2_create_xattr_block() takes from meta_ac through ocfs2_claim_metadata(), and it is spent before the value tree exists. ocfs2_extend_meta_needed() on the empty def_xv list returns 2, so the branch reserves 2 where 3 are needed. The xattr block consumes one, and when the cluster allocator is fragmented enough that the value needs more than one extent, ocfs2_add_clusters_in_btree() comes back around with a full value root and ocfs2_alloc_context_bits_left() of 1 against a threshold of 2. It answers RESTART_META, which ocfs2_xattr_extend_allocation() turns into a BUG_ON(). Commit 0cdc7dde00ec ("ocfs2: fix missing metadata reservation for large xattrs") downgraded that to -ENOSPC, at the cost of leaking the clusters already handed out: ocfs2_xa_cleanup_value_truncate() takes its !orig_clusters arm, drops the entry and leaves the clusters for fsck.ocfs2 to reclaim. Reserve for the block and the tree separately. Link: https://lore.kernel.org/20261010113454.1420939-1-joseph.qi@linux.alibaba.com Link: https://lore.kernel.org/20261010113454.1420939-2-joseph.qi@linux.alibaba.com Fixes: 3ed2be719eb9 ("ocfs2: allow for more than one data extent when creating xattr") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Cc: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Signed-off-by: Sasha Levin commit b235898d9919b6a94acf261c30c6182f2a9b692c Author: Matt Turner Date: Mon Aug 3 15:42:26 2026 -0400 alpha: determine tininess after rounding in the FP emulation [ Upstream commit b74843b38da8f1186fd7d447646c835b47096a15 ] IEEE 754 lets an architecture determine tininess of a floating-point result either before or after rounding, but requires the same choice for every operation. Alpha determines it after rounding, and stdlib's tst-tininess confirms the hardware does so for the results it produces itself. The soft-fp emulation has no notion of the distinction and always determines tininess before rounding, so a result that the hardware would not consider tiny is reported as underflowing whenever the instruction happens to trap for software completion. The two paths then disagree on the same machine. A multiply of the largest subnormal double by 1 + 2^-52 rounds up to the smallest normal and raises no underflow when the operands are normal, but raises it when an operand is subnormal and the instruction traps: glibc math testsuite, test-float32x-float64-mul: Failure: mul_double (0x3.ffffffffffffcp-1024, 0x1.0000000000001p+0): Exception "Underflow" set Add _FP_TININESS_AFTER_ROUNDING, as glibc's copy of soft-fp has, and set it for alpha. It determines tininess by rounding a copy of the result as if the exponent range were unbounded, which is what the definition asks for. A plain check of whether the rounded result came out normal is not equivalent: it differs for values that are still tiny once rounded with an unbounded exponent range but reach the smallest normal on the coarser subnormal grid. That plain check is what the hardware itself does (it decides tininess from the delivered result), and it is why a divide such as -0x4p-128 / 0x1.000002p+0 in FE_DOWNWARD delivers -0x1p-126 and raises nothing although the result is tiny after rounding. Such cases do not trap, so the emulation never sees them; where it does get control, it follows the definition rather than reproducing that deviation, which is what glibc's soft-fp does as well. The macro defaults to zero, so powerpc, sh and sparc keep determining tininess before rounding as they do now. Cc: stable@vger.kernel.org # 5.15+ Reviewed-by: Magnus Lindholm Tested-by: Magnus Lindholm Link: https://lore.kernel.org/r/20260803-alpha-fp-exceptions-v1-3-c99d75608e60@gmail.com Signed-off-by: Matt Turner Signed-off-by: Sasha Levin commit 18ceb639d3a5e9ce96db2e393595f9e8b836192a Author: Bryam Vargas Date: Tue Oct 13 15:45:01 2026 -0500 net/smc: queue the copied chunk when smc_tx_sendmsg() faults [ Upstream commit c0703534b223a5c6993e0f000fd1c3abe621fb65 ] When a send wraps the end of the send buffer, smc_tx_sendmsg() copies the data in two chunks. If memcpy_from_msg() faults on the second one, smc_tx_sendmsg() returns send_done, which already counts the first chunk, but leaves tx_curs_prep and sndbuf_space as they were. send() reports bytes the peer never receives, and the next send() overwrites them. Any caller can hit this on its own stream with a buffer whose tail is unreadable. On a fault in the second chunk, queue the first one. The next pass retries the rest and returns send_done if it faults again, so send() reports only what it queued, as TCP does. Fixes: e6727f39004b ("smc: send data (through RDMA)") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20261013-b4-disp-872a3689-v1-1-2a4c63b04761@proton.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 94dcfccdb0fadf159c96bf37f6536eddde3b84c2 Author: Yingjie Wang <1075151112@qq.com> Date: Fri Oct 16 11:02:58 2026 +0800 net: unix: reject negative max_dgram_qlen values [ Upstream commit 1a4e7bc6e3457ad95515a9d2c042452c3161bb2c ] net.unix.max_dgram_qlen is parsed as a signed int and copied to the u32 sock::sk_max_ack_backlog when an AF_UNIX socket is created. Consequently, a negative value such as -1 is accepted and converted to UINT_MAX. Since the receive queue length is also u32, its fullness check cannot become true for that limit. max_dgram_qlen has no documented negative sentinel. Its existing signed interface represents nonnegative values only through INT_MAX; negative bit patterns are not a supported encoding for the upper half of the u32 consumer range. Switch to proc_dointvec_minmax and make the established 0..INT_MAX input range explicit. This rejects negative values without adding new accepted values or changing the default and zero-value behavior. Very large valid values can still make the queue limit impractical to reach; this change corrects the input domain rather than imposing a new resource ceiling. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Yingjie Wang <1075151112@qq.com> Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/tencent_A643419B56079E9A448D97922763FF069F08@qq.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9a99127122a216e79073259baa32681f299f5b2f Author: Nguyen Ngoc Thang Date: Fri Oct 16 23:15:25 2026 +0700 net/rds: ib: don't enable IRQs in rds_ib_conn_free() [ Upstream commit f6fa1d60ec3ceb7e6c26aa91eadfef34f94014e1 ] __rds_conn_create() calls trans->conn_free() with rds_conn_lock held and IRQs disabled when it loses the race to insert a connection. rds_ib_conn_free() takes the device list lock with spin_lock_irq() and releases it with spin_unlock_irq(), so IRQs are turned on while rds_conn_lock is still held: raw_local_irq_restore() called with IRQs enabled WARNING: kernel/locking/irqflag-debug.c:10 at warn_bogus_irq_restore+0xc/0x20 _raw_spin_unlock_irqrestore+0x67/0x80 __rds_conn_create+0x1de5/0x2290 rds_conn_create_outgoing+0x43/0x60 rds_sendmsg+0xfca/0x20e0 __sys_sendto+0x408/0x5a0 It needs an RDS socket bound to an address on an RDMA device (e.g. rxe) and two concurrent sendto() calls to the same new destination. The TCP and loopback ->conn_free() callbacks already use irqsave, so do the same here. Fixes: 745cbccac3fe ("RDS: Rewrite connection cleanup, fixing oops on rmmod") Reported-by: syzbot+c3741bb338b5c6d6a4aa@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c3741bb338b5c6d6a4aa Cc: stable@vger.kernel.org Signed-off-by: Nguyen Ngoc Thang Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3465674aa848041cc9240e236e2fdf589eea386d Author: Guangshuo Li Date: Wed Sep 16 17:01:26 2026 +0800 PCI: qcom-ep: Deinitialize endpoint on remove [ Upstream commit ed1d71e41c7b2e755e0ef8e9af9cab9b6b185c4b ] qcom_pcie_ep_probe() initializes the DesignWare PCIe endpoint with dw_pcie_ep_init(). The probe failure paths call dw_pcie_ep_deinit() to release the corresponding endpoint resources, but the remove path does not perform the matching teardown after a successful probe. As a result, resources initialized by the DesignWare endpoint core can remain allocated when the endpoint controller is removed. Notify endpoint functions about EPC deinitialization and call dw_pcie_ep_deinit() before disabling the controller resources. Keep the existing early return when the link is already disabled since Qualcomm endpoint controllers depend on the host refclk for hardware cleanup. This issue was found by manual code inspection. Fixes: f55fee56a631 ("PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driver") Signed-off-by: Guangshuo Li Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260916090126.2963064-1-lgs201920130244@gmail.com Signed-off-by: Sasha Levin commit 968eddcb895ec318e0c8ffe017d0357cb3beb898 Author: Tingjie Zhong Date: Tue Oct 20 10:46:57 2026 -0600 fbdev: bitblit: Fix glyph clipping when fbcon pans [ Upstream commit 06fccf840640d8f6b0e08a1756f8d2f0435b4cbe ] Commit 3637d34b35b2 ("fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds") made bit_putcs() clip glyphs to var.yres. When fbcon scrolls by panning, it draws text rows up to var.yres_virtual, so after the first pan most new text is not drawn until the next full redraw. This affects fbdev drivers that set FBINFO_HWACCEL_YPAN or FBINFO_HWACCEL_YWRAP, such as vesafb with the ypan option, when CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION=y. Clip to GETVYRES() instead, which fbcon_ud.c and fbcon_ccw.c already use as the drawing area height. When fbcon does not pan, GETVYRES() returns var.yres, keeping the existing bound. When fbcon pans, it returns var.yres_virtual, which the framebuffer memory must cover anyway for panning to work. Fixes: 3637d34b35b2 ("fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds") Reported-by: Thomas Zimmermann Closes: https://lore.kernel.org/linux-fbdev/b8b52ffd-ecec-4fba-b432-ba32135c2f99@suse.de/ Tested-by: Thomas Zimmermann Cc: stable@vger.kernel.org Signed-off-by: Tingjie Zhong Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit c53a94f7d103f996b7d8f25ed525cb19a9ec7d09 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Thu Oct 15 14:06:51 2026 +0900 ipv6: do not restart DAD for a dead ifaddr [ Upstream commit ffb668669ce4144347973d8b2fad449e9be0563d ] addrconf_dad_failure() can create a stable-privacy replacement without RTNL. After ipv6_add_addr() publishes it, addrconf_ifdown() can mark the new ifaddr DEAD, clear its route, and unlink it before the recovery path takes ifp2->lock. The recovery path then unconditionally changes the state back to PREDAD and queues delayed DAD work. The MTU teardown path can leave IF_READY set. For an optimistic address, addrconf_dad_begin() can consequently pass the cleared NULL route to ip6_ins_rt(). This follow-on was found by source review and was not separately triggered at runtime. The new ifaddr is already initialized in PREDAD. Under ifp2->lock, record the retry and queue DAD only if teardown has not changed the state to DEAD. If teardown wins after this check, the work observes DEAD and exits without reviving the address. This complements the existing lock_errdad check that preserves the original ifaddr's DEAD state after the same function reacquires its lock. Fixes: 5f40ef77adb2 ("ipv6: do retries on stable privacy addresses") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/r/179161099408.434549.14449036924552933828@kernel.org Link: https://lore.kernel.org/r/20260513025509.3776405-1-lilinmao@kylinos.cn Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20261015050651.1841557-5-4ncienth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4bd95b046e1ce34f14c8cc915d4497dd480e5e45 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Thu Oct 15 14:06:50 2026 +0900 ipv6: initialize temporary ifaddr before publication [ Upstream commit ed7f278812e540db507f683e5bf9b6d0a1f5bc1e ] ipv6_create_tempaddr() holds a reference to the public ifaddr, publishes the new temporary address through ipv6_add_addr(), and only then stores the reference and final timestamps. addrconf_ifdown() can remove the temporary address before ifpub is stored, leaking the public ifaddr reference. Publishing ifpub alone is insufficient: manage_tempaddrs() can then find the object before cstamp and tstamp are final, update its lifetimes, and have the constructor overwrite its timestamp with an older value. This follow-on was found by source review and was not separately triggered at runtime. Pass the public ifaddr and both timestamps in ifa6_config. Initialize all three fields before adding the temporary address to either the hash or per-device lists. On success the existing public-ifaddr reference transfers to the temporary object. On error it remains owned and released by ipv6_create_tempaddr(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/r/179122559913.434549.12720841717630168470@kernel.org Link: https://lore.kernel.org/r/179161099665.434549.5858601179492551889@kernel.org Link: https://lore.kernel.org/r/20261007164548.GA1153540@shredder Link: https://lore.kernel.org/r/20261012145240.GA779501@shredder Suggested-by: Ido Schimmel Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20261015050651.1841557-4-4ncienth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 72e3cb0eef4b10404a440dcbd063d3e8b3936f63 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Thu Oct 15 14:06:49 2026 +0900 ipv6: serialize address publication with device teardown [ Upstream commit 06227034e2d93942119b922cf05f2de9da0ad848 ] ipv6_add_addr() checks idev state before allocating an ifaddr, but publishes the object later. addrconf_ifdown() can mark and detach the idev between the check and publication. This happens when a non-loopback device MTU falls below IPV6_MIN_MTU. A forced interleaving published an address on a dead idev, and ipv6_get_ifaddr() still returned it after teardown. Later device deletion remained blocked with: unregister_netdevice: waiting for ac0 to become free. Usage count = 3 Protect the dead indication with idev->lock and keep that lock across both hash and device-list publication. Recheck dead before publishing; if teardown wins the lock, reject the unpublished object. Non-unregister teardown does not set dead. The preceding change covers an add that misses the initial hash scan but reaches the per-device list snapshot. Both changes are required when backporting this fix. Fixes: 8814c4b53381 ("[IPV6] ADDRCONF: Convert addrconf_lock to RCU.") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/179161099408.434549.14449036924552933828@kernel.org Link: https://lore.kernel.org/r/20261012145306.GB779501@shredder Suggested-by: Ido Schimmel Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20261015050651.1841557-3-4ncienth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c21e4316f584691e234fe121aec5479ae27d1cdd Author: Daehyeon Ko <4ncienth@gmail.com> Date: Thu Oct 15 14:06:48 2026 +0900 ipv6: remove ifaddr from hash during ifdown list cleanup [ Upstream commit 6ace56ed7b13a9c6d4cb7ef0d82d3a3d53324a63 ] addrconf_ifdown() clears the address hash before snapshotting the per-device address list. A concurrent ipv6_add_addr() can publish an address after the hash scan and before the list snapshot. The ifdown path then removes the address from the device list and drops the list-owned reference while it is still linked in the hash. Once the remaining references are released, inet6_ifa_finish_destroy() warns, but a DEAD address continues to kfree_rcu(). The hash therefore points to freed memory that later RCU walkers can dereference. This follow-on was found by source review and was not separately triggered at runtime. Remove each non-kept address from the hash immediately before removing it from the per-device list. Keeping it hashed through the delete notification blocks same-address publication until NETDEV_DOWN has been delivered. hlist_del_init_rcu() is safe when the earlier hash scan already removed the address. This handles a late publisher captured by the list snapshot. The next change serializes publication with teardown so an add cannot miss both observations. Both changes are required when backporting the complete fix. Fixes: 73a8bd74e261 ("ipv6: Revert 'administrative down' address handling changes.") Cc: stable@vger.kernel.org Reported-by: Ido Schimmel Link: https://lore.kernel.org/r/20261004135117.GA206930@shredder Link: https://lore.kernel.org/r/179161099539.434549.2238120015372268173@kernel.org Suggested-by: Ido Schimmel Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20261015050651.1841557-2-4ncienth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f917af6f91c12f5e3943e110cb9a2b5ca42909d1 Author: William Palacek Date: Fri Oct 16 10:44:50 2026 -0400 drm/amdkfd: wait for a GPU reset before freeing a BO [ Upstream commit 47d799a718439764432d8ef3a0952af45f025f76 ] When a GPU reset takes the reset domain, KFD eviction cannot unmap user queues: execute_queues_cpsch() fails its trylock with -EIO, so the queues keep running until the ASIC is reset. The TLB flush is also skipped while the reset is in progress. If the process unmaps and frees a BO in that window, its pages are released while a queue can still access them through stale translations. On MI300X, munmap() then crashes in free_swap_cache() on a small bogus page pointer in its mmu_gather batch page: BUG: unable to handle page fault for address: 0000000000002900 RIP: 0010:free_swap_cache+0x5/0xb0 Call Trace: free_pages_and_swap_cache+0x3a/0x60 tlb_batch_pages_flush+0x43/0x80 tlb_flush_mmu+0x3d/0x110 zap_pte_range+0x80d/0xcd0 ... do_vmi_align_munmap+0x3e8/0x5b0 do_vmi_munmap+0xdf/0x190 __vm_munmap+0xad/0x180 __x64_sys_munmap+0x1b/0x30 In a traced crash the bogus pointer was the read pointer value of an SDMA queue the process had just destroyed, at the read pointer's page offset: the queue's writeback landed in its freed rptr page after the page was reused as the batch page. commit f0b4440cdc18 ("drm/amdkfd: Fix mode1 reset crash issue") fixed this race on process exit by waiting for the reset to complete before freeing the process's BOs. Free through the ioctl has the same race. Wait for the reset there too, using the same helper. Fixes: 9c33e5fd4fb6 ("drm/amdgpu: fix locking scope when flushing tlb") Reviewed-by: Felix Kuehling Signed-off-by: William Palacek Signed-off-by: Alex Deucher (cherry picked from commit 06ff8ce77726b15a98fcc285dd6005cb3f48558b) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d8d6ee04a3098a639f3a4f58a08750676c80a194 Author: Keita Morisaki Date: Wed Sep 23 11:24:51 2026 +0900 drm/amd/display: Fix swap in median3() for DSC rate control [ Upstream commit 7b23bf82ccbdb4cf0752f2b8686e7319a7ce497f ] median3() is meant to return the median of three values, but its last compare-and-swap step swaps b and c instead of a and b. When c is smaller than both a and b, it returns max(a, b) instead of min(a, b). For example, median3(2, 3, 1) returns 3 instead of 2. _do_calc_rc_params() always passes 0 as the first argument, and the second argument is never below 12. So whenever the third argument is negative, first_line_bpg_offset (and second_line_bpg_offset for 4:2:0) is set to the second argument instead of 0. Fix this by swapping a and b in the last step, as intended. Note that this change does not affect valid DSC configurations. The third argument is negative only when bits per pixel exceeds the uncompressed rate of the colour format: - 3 * bpc for 4:4:4, 3 * bpc + 2 for RGB - 2 * bpc for 4:2:2 - 1.5 * bpc for 4:2:0 Fixes: 97bda0322b8a ("drm/amd/display: Add DSC support for Navi (v2)") Signed-off-by: Keita Morisaki Tested-by: Dan Wheeler Reviewed-by: Roman Li Signed-off-by: Alex Deucher (cherry picked from commit 1ddc4bc97a62fc89d9d3681413d9f977e1fa1a83) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 25ee77d64ae14e1f4c3035fd867364537a0f3690 Author: Jesse Zhang Date: Sun Oct 11 20:15:34 2026 +0800 drm/amdkfd: don't drop an SVM CWSR reference that was never taken [ Upstream commit 030d47cc6720e0f07b502876cdbd266e309f9461 ] When kfd_queue_acquire_buffers() fails, its error path calls kfd_queue_release_buffers(), which also drops a queue_refcount on the SVM range at ctx_save_restore_area_address. The SVM range is the last buffer acquired, and kfd_queue_buffer_svm_get() takes no reference when it fails, so on every error path this reference was never taken. If another queue of the process uses that CWSR range, its reference is dropped instead, and unmapping the range no longer evicts that queue while its CWSR area is unmapped from the GPU. On navi31, with queue A using an SVM CWSR range: munmap() of the range logs Freeing queue vital buffer 0x..., queue evicted but after a CREATE_QUEUE that reuses A's CWSR address with an unmapped write pointer (-EINVAL), the same munmap() leaves A running without the message. Only put the BOs on the acquire error path. The warning and the eviction are back after the failed CREATE_QUEUE. Fixes: b049504e211e ("drm/amdkfd: Validate user queue svm memory residency") Signed-off-by: Jesse Zhang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit 9a08122e6361ef73f4b512d5db9596d561305519) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 1cb2661b41b9ef5e453a94e5443d2510d7ef595e Author: Jesse Zhang Date: Tue Oct 13 21:37:07 2026 +0800 drm/amdgpu: reject ANONONLY userptrs that span multiple VMAs [ Upstream commit d577b68a854d0f590f480777249b041507d0708c ] For AMDGPU_GEM_USERPTR_ANONONLY, amdgpu_ttm_tt_get_user_pages() only checks the VMA at the start of the range for a backing file, and amdgpu_hmm_range_get_pages() then faults in the whole range, across any other VMAs. The check used to reject ranges ending beyond the first VMA (vma->vm_end < end), which got lost when the code moved to HMM. An ANONONLY userptr over one page of file-backed memory is rejected with -EPERM, but one over an anonymous page followed by the same file-backed page is accepted. Restore the check and reject ANONONLY userptrs that cross more than one VMA. The second userptr is now rejected too. v2: reject ranges spanning multiple VMAs instead of walking every VMA (Christian) v3: cast num_pages to u64 to avoid an overflow (Christian) Fixes: 6826cb3b92a3 ("drm/amdgpu: support userptr cross VMAs case with HMM") Cc: Christian König Cc: Philip Yang Cc: Felix Kuehling Signed-off-by: Jesse Zhang Reviewed-by: Christian König Acked-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit 75d753ed4704d5efc72164d9e546b2a282e42ae2) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit df504bf02c92d3cdaee88aeac6d7c0eb0c0d6b15 Author: Mario Limonciello Date: Sat Sep 26 17:32:21 2026 -0500 drm/amd/display: don't WARN when removing an unallocated MST payload [ Upstream commit b18a7c6d75bcc883b39497863cc88c9ef4c6c85f ] [Why] On an MST teardown that runs through the reset path (dcn31_reset_hw_ctx_wrap -> link_set_dpms_off -> deallocate_mst_payload), fill_dc_mst_payload_table_from_drm() is asked to remove a payload whose vcpi is not present in link->mst_stream_alloc_table and trips: WARNING: .../amdgpu_dm_helpers.c:275 fill_dc_mst_payload_table_from_drm This is a legitimate case, not an error: deallocate_mst_payload() can be called for a stream whose MST payload was never programmed into DC's HW-maintained table (a new stream created for a modeset whose enable never completed, as already documented in deallocate_mst_payload()). There is simply nothing to remove. [How] Drop the ASSERT and fall through to the fill loop, which rebuilds the allocation table from the remaining entries. The table ends up unchanged, which is correct: the payload being removed was never in it. Note the loop must not early-return here - the caller passes a zeroed proposed_table, so returning early would zero the whole link's table and drop the other MST streams sharing the link. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5875 Reviewed-by: Wayne Lin Signed-off-by: Mario Limonciello Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 88a27f624dc0ebc14a7ab274a84d977ce8513cb6) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 8b1cb368bce3a3a670e36b82372aa0033ffe3d85 Author: Henry Martin Date: Sat Oct 10 11:02:30 2026 +0800 drm/amdkfd: fix doorbell allocation race creating duplicate allocations [ Upstream commit bebad45050945a3d668d6701fb77ae2571c5d44b ] The check-and-allocate sequence on pdd->qpd.proc_doorbells is lockless at every call site of kfd_alloc_process_doorbells(): kfd_get_process_doorbells() (mmap of /dev/kfd), kfd_ioctl_create_queue() and the CRIU restore path each test the pointer under different locking (or none), so two racing threads can both observe NULL and each allocate a doorbell BO and bitmap, orphaning one allocation and handing the two mappings different backing pages. Move the serialization into kfd_alloc_process_doorbells() itself, using a new per-process-device mutex so all three call sites are covered regardless of their own locking. The device-global kfd->doorbell_mutex is not suitable here: it is acquired under dqm->lock on the kernel-doorbell path (start_cpsch() -> pm_init() -> kq_initialize() -> kfd_get_kernel_doorbell()), so holding it across the sleeping allocations above would create a lock-ordering inversion with dqm->lock via TTM eviction, and it would also serialize doorbell setup of unrelated processes behind a device-wide lock for per-process state. This issue was discovered by Tencent CodeBuddy Security. v3 (Felix Kuehling): - Removed unlocked check in kfd_get_process_doorbell flagged as problematic by Sashiko Bot. Fall back to the locked check inside kfd_alloc_process_doorbells - Added missing mutex_destroy v4 (Felix Kuehling): - Removed unlocked checks around other kfd_alloc_process_doorbells calls Fixes: 16f0013157bf ("drm/amdkfd: Allocate doorbells only when needed") Signed-off-by: Henry Martin Signed-off-by: Felix Kuehling Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit 4e27ba5ad5f76932d4f6cbacd25c81c2dd40ec4a) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 4846628448aa1fab0f8e76409fbca2eda17c8bae Author: Maciej Kucharek Date: Thu Oct 15 11:57:13 2026 +0200 drm/amdgpu: reset VI ASIC on Apple boards with VRAM at 0 [ Upstream commit 92a5184787b81e67f7b831ad860ca9b053505cf8 ] On MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. A later post (S3 resume, GPU reset) moves VRAM back to the VBIOS default. gmc_v8_0 reads MC_VM_FB_LOCATION once at init and reprograms it only on SR-IOV. On bare metal, the driver then keeps using the old layout. vi_reset_quirks[] handles this for the MacBookPro14,3 by PCI ID: commit b6b1d9721851 ("drm/amdgpu: reset VI ASIC on MacBookPro14,3") Add the test that SI and CIK use: an Apple subsystem vendor and VRAM at 0. Other Polaris MacBookPros then get the same reset at load, for example the MacBookPro13,3 if its firmware leaves VRAM at 0. These boards are not tested. Keep vi_reset_quirks[]. Its MacBookPro15,1 entries fix a different failure, a module reload after S3: commit a5be7ad8f5f0 ("drm/amdgpu: reset VI ASIC on MacBookPro15,1") VRAM is not at 0 at that point, so the new test may not cover it. After the reset, FB_BASE is not 0, so the new test does not fire again on a module reload. Only compile-tested. Suggested-by: Alex Deucher Assisted-by: Claude:claude-opus-5-5 Reviewed-by: Alex Deucher Signed-off-by: Maciej Kucharek Signed-off-by: Alex Deucher (cherry picked from commit c2335b685b1e1e387f2fea1c67f56b5b8a8b6dc6) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 7adc817a8d6beb53958d63ebeb53fa5d75beb3a8 Author: Maciej Kucharek Date: Thu Oct 15 11:57:12 2026 +0200 drm/amdgpu: reset CIK ASIC on Apple boards with VRAM at 0 [ Upstream commit 095f634ea0aa5b9da19495520b5fc1a155b2c137 ] On MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. A later post (S3 resume, GPU reset) moves VRAM back to the VBIOS default. The SI fix resets and posts the ASIC at load, so the driver uses the VBIOS layout from the start: "drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0" No MacBookPro has a CIK GPU, and no affected CIK board is known. Add the same test to cik_need_reset_on_init(), so that SI, CIK and VI handle this firmware layout in the same way. gmc_v7_0 reads MC_VM_FB_LOCATION once at init and does not reprogram it. A CIK board with VRAM at 0 therefore has the same problem as the SI boards. After the reset, FB_BASE is not 0, so the new test does not fire again on a module reload. Only compile-tested. Suggested-by: Alex Deucher Assisted-by: Claude:claude-opus-5-5 Reviewed-by: Alex Deucher Signed-off-by: Maciej Kucharek Signed-off-by: Alex Deucher (cherry picked from commit 6bb4b79d6a6c461b40750fd67cb4e2a070e20b67) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 46d0a61389b84f3db14bd4b34e048b94f38680c9 Author: Luigi Lauro Date: Wed Oct 14 15:33:56 2026 +0200 drm/amdgpu: require _PR3 for BOCO [ Upstream commit 28f3d169f162ca7e803c5a1f7e1bb55bdc915d1c ] amdgpu_device_supports_boco() returns true for an AMD_IS_PX device on a system with a hybrid ATPX method even when the device has no ACPI power resource (_PR3). On an APU mini PC with a discrete GPU attached over OCuLink, the iGPU's ATPX method reports hybrid graphics, the dGPU is flagged AMD_IS_PX, and runtime PM in auto mode picks BOCO: amdgpu: ATPX Hybrid Graphics amdgpu 0000:c6:00.0: Using BOCO for runtime pm In BOCO mode the driver leaves powering the device off to the PCI core, which can only do it through _PR3 on the upstream bridge. No device on this dGPU's path has _PR3, so when it runtime suspends the card stays powered, with its fans at about 700 rpm. Require has_pr3 for BOCO, as the function's description ("dGPU with ACPI power resources") says. The same card then picks BACO, which powers it down: amdgpu 0000:c6:00.0: Using BACO for runtime pm This only changes systems with a hybrid ATPX method and no _PR3 on the dGPU's upstream bridge, where BOCO cannot cut the power today. Tested on one such system only, an RX 9070 XT (Navi 48) over OCuLink with a Ryzen AI 9 HX 470, with the change backported to 7.2.9: the stock module logs "Using BOCO", the patched one "Using BACO"; BACO runtime suspend powers the card off and it resumes cleanly. Not tested on a hybrid laptop or a Thunderbolt eGPU. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5980 Assisted-by: Claude:claude-opus-5-5 Reviewed-by: Alex Deucher Signed-off-by: Luigi Lauro Signed-off-by: Alex Deucher (cherry picked from commit 1a039805354a44aab7abb2a6e685212d48b17a5e) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit e129272c096f2dedfa47c6ba242882da01579eac Author: Nirmoy Das Date: Tue Oct 20 05:51:29 2026 -0700 blk-mq: clear stale inactive flag on hctx reuse [ Upstream commit afc1de47a7ab607ae6403c4bfda36b0bf3cd342f ] When the last CPU mapped to an hctx goes offline, blk_mq_hctx_notify_offline() sets BLK_MQ_S_INACTIVE. Updating the number of hardware queues exits every hctx and parks it on q->unused_hctx_list. A later update can reuse a parked hctx through blk_mq_alloc_and_init_hctx(), at any queue index, and nothing clears the flag. If the reused hctx is mapped to an online CPU, blk_mq_get_tag() keeps returning BLK_MQ_NO_TAG for it. __blk_mq_alloc_requests() sleeps and retries, expecting CPU hotplug to move the task to another CPU, so a task that stays on that CPU never gets a tag. Onlining the original CPU doesn't recover it either, because blk_mq_hctx_notify_online() only clears the flag on the hctx that CPU now maps to. Clear BLK_MQ_S_INACTIVE in blk_mq_init_hctx() so a reused hctx starts like a freshly allocated one. A reused hctx has no cpuhp instances at that point, so the offline callback can't set the flag again before blk_mq_add_hw_queues_cpuhp() registers it. Clearing the flag in blk_mq_exit_hctx() is not enough, because a parked hctx keeps its cpuhp instances until blk_mq_remove_hw_queues_cpuhp(). Preserve the other hctx state flags. Reproduced with null_blk on v7.3 in a four-vCPU arm64 QEMU/KVM guest: modprobe null_blk nr_devices=0 mkdir /sys/kernel/config/nullb/nullb0 cd /sys/kernel/config/nullb/nullb0 echo 4 > submit_queues; echo 1 > memory_backed; echo 16 > size echo 1 > power echo 0 > /sys/devices/system/cpu/cpu3/online echo 2 > submit_queues echo 4 > submit_queues Offlining CPU3 marks hctx3 inactive. After the two updates it comes back as hctx1 and is mapped to CPU0: # cat /sys/block/nullb0/mq/1/cpu_list 0 # cat /sys/kernel/debug/block/nullb0/hctx1/state INACTIVE A 4K O_DIRECT read pinned to CPU0 hangs in D state, while the same read on CPU1 and CPU2 completes. Onlining CPU3 again leaves hctx1 inactive and the CPU0 read still hangs. With this change hctx1 state is empty and the reads on CPU0, CPU1 and CPU2 complete, before and after onlining CPU3. Fixes: bf0beec0607d ("blk-mq: drain I/O when all CPUs in a hctx are offline") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Nirmoy Das Link: https://patch.msgid.link/20261020125129.430600-1-nirmoyd@nvidia.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 570c0fa0bb8ea3c1bcc594859a1f767f1f6a0d37 Author: Sahaj Chaudhari Date: Sun Oct 18 22:20:03 2026 +0530 gpio: pca953x: Handle direction register read errors in IRQ paths [ Upstream commit a0fe269293509acdd93b9cfb3f46636f7b91b33a ] Three IRQ paths ignore the result of reading the direction registers and then use the destination bitmap. pca953x_read_regs() does not populate that bitmap when regmap_bulk_read() fails, leaving the callers to use uninitialized stack data. This can select incorrect GPIOs for direction changes during IRQ bus synchronization, corrupt the saved input state during IRQ setup, or produce incorrect pending interrupt decisions. Check the read result at all three sites. Release irq_lock without changing GPIO directions on failure, leave the IRQ history untouched when pending detection fails, and propagate the error from IRQ setup. The read helper already logs the error. Fixes: 0f25fda840a9 ("gpio: pca953x: Zap ad-hoc reg_direction cache") Cc: stable@vger.kernel.org Signed-off-by: Sahaj Chaudhari Link: https://patch.msgid.link/20261018165003.3372368-1-sahaj123.sc@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit d3629327283a8694249e23a01a3021cbd19ad1fc Author: Sahaj Chaudhari Date: Sun Oct 18 22:36:22 2026 +0530 gpio: davinci: Clear interrupt status in every bank on suspend [ Upstream commit 800d7627f552bbf602a1736b638aee0ada3fbf87 ] davinci_gpio_save_context() saves the registers of each 32-GPIO register bank, but clears interrupt status only after the loop. At that point g refers to the last bank, so pending status in all preceding banks is left uncleared. Move the interrupt-status write into the per-bank loop so that the existing suspend-time clearing covers every register bank. Single-bank controllers retain the same behavior. Fixes: 0651a730924b ("gpio: davinci: Add support for system suspend/resume PM") Cc: stable@vger.kernel.org Signed-off-by: Sahaj Chaudhari Link: https://patch.msgid.link/20261018170622.3406158-1-sahaj123.sc@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 3f81b2472c606695780b47b04525fecdd9ebe50a Author: Baek Kyu, Kim Date: Sun Oct 18 13:44:56 2026 +0900 gpiolib: Free chip resources when allocating the label fails [ Upstream commit 8381e1f15e27087fcb6f07046a526ac8b9b9b2b9 ] If desc_set_label() fails after the chip's request callback succeeds, gpiod_request_commit() clears GPIOD_FLAG_REQUESTED without calling the free callback. The caller receives an error and has no GPIO to release, leaving resources acquired by the request callback held. Call the chip's free callback, if present, before clearing the requested bit on label allocation failure. Leave request callback errors on the existing path to avoid freeing a failed request. Cc: stable@vger.kernel.org Fixes: 1f2bcb8c8ccd ("gpio: protect the descriptor label with SRCU") Signed-off-by: Baek Kyu, Kim Link: https://patch.msgid.link/20261018044456.1259250-1-pocj8ur4in@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 52a5c2159c57340395743af58ffd79d9d9decbeb Author: Takashi Iwai Date: Tue Oct 20 12:16:21 2026 +0200 ALSA: emux: Stop voices before freeing zones in all cases [ Upstream commit 8a5d87c2ba30e8de31cfbe888fd4d95f43c63db9 ] The emux voice caches the soundfont zone pointer in vp->zone, which is referred to later, e.g. in snd_emux_send_effect(). For avoiding dangling pointers, the soundfont code calls the sample_reset callback to stop all voices before freeing zones. However, in a few cases (e.g. emu10k1's missing sample_reset or the call path via remove_info()), the sample reset isn't called properly, leaving the playing voices. Fix it by always registering the sample_reset callback, falling back to snd_emux_terminate_all() when the driver has no own ops, and by calling sample_reset in remove_info() before freeing the zones. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261020101624.205638-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit dcd8192545110a25192b4b853c211ef7390bbd6a Author: Peter Ujfalusi Date: Mon Oct 19 17:45:32 2026 +0300 ALSA: compress: add missing OPEN-state gate to SET_METADATA [ Upstream commit 931f5714b7921290cd1a4742e185aeeae7270ee6 ] snd_compr_set_metadata() calls stream->ops->set_metadata() straight after copy_from_user(), without ever checking runtime->state, even though the function's own comment says a parameter change should only be allowed once the stream has left the OPEN state. Every other metadata/param entry point in this file (SET_PARAMS, WRITE, ...) enforces that gate. A codec driver's set_metadata callback can assume SET_PARAMS has already run and initialised its private state; calling it while the stream is still OPEN can operate on that uninitialised state. Add the OPEN-state check the existing comment already documents. Fixes: 9727b490e543 ("ALSA: compress: add support for gapless playback") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Acked-by: Vinod Koul Link: https://patch.msgid.link/20261019144533.30665-4-peter.ujfalusi@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 04bb6a7e76313046a3f5bd05862f9ab4ac2b503e Author: Peter Ujfalusi Date: Mon Oct 19 17:45:31 2026 +0300 ALSA: compress: reject buffer geometry change on gapless next_track [ Upstream commit 82da1acad6fd60b6072dd5f3383e6a55efdd2ac7 ] snd_compr_set_params() is invoked from the gapless next_track re-entry path, which calls snd_compr_allocate_buffer() again and lets buffer_size change while total_bytes_available and total_bytes_transferred still hold values computed for the previous buffer. snd_compr_calc_avail() then derives an avail/count value from those stale counters against the new buffer_size, and snd_compr_write_data() copy_from_user()s that many bytes into the new, potentially smaller buffer, overflowing it with user-controlled length and content. The buffer is set up once, with the initial SET_PARAMS, and neither the core nor the DSP expects it to change for a gapless track transition. Do not call snd_compr_allocate_buffer() on the next_track path and reject a request that changes the buffer geometry, so that the codec parameters that the driver receives match the buffer in use. Fixes: 9727b490e543 ("ALSA: compress: add support for gapless playback") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20261019144533.30665-3-peter.ujfalusi@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9f5112e2936e734b9a236f3e2e76369062223a00 Author: Peter Ujfalusi Date: Mon Oct 19 17:45:30 2026 +0300 ALSA: compress: fix buffer leak on failed SET_PARAMS [ Upstream commit fbc74ca9fbf7e0b8f6872ccac62f9f4a1f3b5e53 ] When the driver has neither ops->copy nor a preallocated dma_buffer_p, snd_compr_allocate_buffer() kmallocs runtime->buffer. If ops->set_params() then rejects the parameters, SET_PARAMS fails, the stream stays in the OPEN state and keeps the buffer. The next SET_PARAMS allocates a new buffer and overwrites the pointer, so repeated SET_PARAMS calls with parameters that the driver rejects leak one buffer per call. Release the framework-owned buffer when ops->set_params() fails on an OPEN stream, so that a failed SET_PARAMS leaves no buffer behind and the buffer is allocated only once per successful setup. Use the same ownership check as snd_compr_free(). Fixes: b21c60a4edd2 ("ALSA: core: add support for compress_offload") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20261019144533.30665-2-peter.ujfalusi@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4463a1e19c7f12fde46e5570ed4c016701001565 Author: Sorah Fukumori Date: Tue Oct 13 22:02:48 2026 +0900 net: gro: don't chain linear parts larger than gso_size into frag_list [ Upstream commit 679f6929a66db9f5a6611dad37545fbd705962d5 ] skb_gro_receive() chains an skb into the frag_list of the held packet when its payload cannot be attached as page frags: when its head is not a page fragment and still holds payload, or when its head and frags would overflow the frags[] array of the last packet. Since commit 5eddb24901ee ("gro: add support of (hw)gro packets to gro stack"), that skb may itself be a GSO packet whose linear part holds several gso_size segments. skb_segment() cannot split the linear part of a frag_list member across segments, so segmenting the aggregate in software, e.g. when forwarding it to a device without NETIF_F_FRAGLIST, hits BUG_ON(skb_headlen(list_skb) > len); Fully linear GSO packets come from generic XDP. When the program does not support frags, netif_skb_check_for_xdp() linearizes any nonlinear skb with pskb_expand_head() and skb_linearize() and keeps its GSO metadata. GRO on the device runs before generic XDP, so each aggregate passed by the program carries all of its payload in a kmalloc'ed head. A tunnel that decapsulates these packets and runs GRO again through gro_cells then builds the bad frag_list. This was first seen on a router that forwards TCP received over VXLAN, with a non-frags XDP program attached in SKB mode to the underlying bond because one slave lacks native XDP: kernel BUG at net/core/skbuff.c:4917! RIP: 0010:skb_segment+0xbb6/0xf40 Call Trace: tcp_gso_segment ipv6_gso_segment skb_mac_gso_segment __skb_gso_segment validate_xmit_skb __dev_queue_xmit ip6_output ip6_sublist_rcv_finish ipv6_list_rcv netif_receive_skb_list_internal gro_complete dev_gro_receive gro_receive_skb gro_cell_poll __napi_poll net_rx_action It reproduces with three network namespaces: TCP sent over VXLAN on an IPv6 veth link to a router namespace that has an XDP_PASS program without frags support attached to the underlay veth in generic mode and GRO enabled on its VXLAN device, and forwards to a veth with tx-scatter-gather-fraglist disabled. A program with frags support in generic mode gives similar packets. skb_pp_cow_data() rebuilds the skb with up to about a page of linear data in a page_pool head_frag and keeps the GSO metadata, so once frags[] is full the next such packet is chained through frag_list with more than gso_size bytes in its head as well. Refuse the merge when the linear part to be chained exceeds the held packet's gso_size. tcp_gro_receive() then flushes the held packet and the skb starts a new GRO packet as its head, whose linear length skb_segment() handles. Fixes: 5eddb24901ee ("gro: add support of (hw)gro packets to gro stack") Cc: stable@vger.kernel.org Assisted-by: claude-opus-5-5 Signed-off-by: Sorah Fukumori Tested-by: Chase Hiltz Reviewed-by: Eric Dumazet Reviewed-by: Jason Xing Link: https://patch.msgid.link/20261013130250.3643916-1-her@sorah.jp Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 16ec59a2a59a1beda422c24f33bba5b09ac1a36c Author: Jamal Hadi Salim Date: Sat Oct 10 17:02:48 2026 -0400 netdevsim: reject cls_bpf programs bound to another device [ Upstream commit 5820ca58b409402505b9e904d1ded4908e0b6b81 ] The issue: nsim_bpf_setup_tc_block_cb() installs any device-bound SCHED_CLS program without checking that its offload device matches the target netdev. The core cls_bpf attach path rejects a mismatching program, but a netdev that joins a shared block later is replayed the stored filter by cls_bpf_reoffload() before it is inserted into block->ports, so the attach-time check cannot see it. The driver callback is the authoritative per-device acceptance boundary and must enforce the match itself, as nfp already does in nfp_net_bpf_offload(). Without the check, replaying a device-bound program onto a different bpf_offload_dev installs it into that device's netdevsim state, which trips the WARN in nsim_bpf_uninit() (ns->bpf_offloaded set on a foreign device) and can dereference a NULL prog->aux->offload in nsim_prog_set_loaded(). The Fix: Reject a device-bound program whose offload device does not match the target netdev, with -EINVAL and an extack so the rejected replay is not silent. The check is intentionally narrower than nfp's: it fires only for a dev-bound program, so nsim's bpf_tc_non_bound_accept mode (which admits an unbound program onto the device) is unaffected. Teardown is never blocked: the guard is on the program being installed and an unbind passes cls_bpf.prog = NULL. Conditions to recreate the bug: - CONFIG_NETDEVSIM=y, CONFIG_NET_CLS_BPF=y - load and pin a dev-bound SCHED_CLS program for netdevsim device B - install the program on a shared block owned by B - add an independently backed netdevsim device C to that block; the bind replays the filter to C's callback, and C's ports/0/bpf_offloaded_id takes the B-bound program id. The reported Sashiko review is at https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260809094418.901607-1-jhs@mojatatu.com Fixes: 31d3ad832948 ("netdevsim: add bpf offload support") Reported-by: Sashiko (nipa) Link: https://lore.kernel.org/netdev/20260809094418.901607-1-jhs@mojatatu.com/ Link: https://lore.kernel.org/netdev/QDISC-PYC7.v1.20261003103747@mojatatu.com/ Cc: stable@vger.kernel.org Reviewed-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-PYC7.v2.20261010165947-2@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a5d11d0fd70ec90c8a45e447099331b1f26bf043 Author: Kir Kolyshkin Date: Sun Oct 18 15:04:39 2026 -0700 cgroup: fix cgroup.kill for exited thread group leader [ Upstream commit da13e0e72a7329c95642c44b2d03d194ab071e04 ] cgroup.kill does not work in case a process' thread group leader is gone but other threads are still running. This is because __cgroup_kill() only walks the thread group leaders and sends SIGKILL to each of them with send_sig(), which uses PIDTYPE_PID: 1. The exited leader is still listed by CSS_TASK_ITER_PROCS as long as the process has live threads, but a signal directed at a single exiting task never takes effect: complete_signal() does not look for another thread to deliver it to, and __send_signal_locked() now drops it altogether. The process keeps running. 2. The live threads of such a process can be migrated to another cgroup by writing any of their IDs to cgroup.procs, while the exited leader stays behind. The destination cgroup has no thread group leader to iterate, so writing to its cgroup.kill does nothing at all. In both cases the cgroup stays populated after cgroup.kill, and a process inside a container can use this to survive the container being killed. This also works with a private PID namespace when the init of the container is the process, as the PID namespace is not torn down while init has live threads. Case 1 can be fixed by using do_send_sig_info(..., PIDTYPE_TGID) instead of send_sig(), so that the signal is taken by a live thread even if the task found by the iterator is exiting. Note it was pointed out by Eric in [1] while reviewing v2 of cgroup.kill patchset, and v3 was meant to switch to it, but the change was only made in cgroup_post_fork(), leaving __cgroup_kill() with send_sig(). Case 2 can only be fixed by iterating over all threads, so this is what the fix also does. Once a thread group is being killed, its other threads are skipped since they already have a fatal signal pending. I ran some performance checks and the added cost is ~60 ns per every thread on my laptop (and less than a millisecond for 10K threads), which seems low. The time to "populated 0" seems unchanged. The issue was found in crun by Anthropic's OSS Scanner, and crun is getting a workaround for it [2] (which does what we needed to do before cgroup.kill was added). [1] https://lore.kernel.org/all/m1v97x6niq.fsf@fess.ebiederm.org/ [2] https://github.com/containers/crun/pull/2351 Fixes: 661ee6280931 ("cgroup: introduce cgroup.kill") Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Kir Kolyshkin Acked-by: Oleg Nesterov Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 9c94c89c6b5aee4c769235f754a788fc6c6b57ee Author: Alexander Kochetkov Date: Fri Oct 2 13:09:35 2026 +0300 Revert "Input: matrix_keypad - force switch rows to input mode" [ Upstream commit 1527451f87dfe368b8ddeeb501c24ac9bde6b589 ] This reverts commit 01c84b03d80aab9f04c4e3e1f9085f4202ff7c29. The commit makes every scan call gpiod_direction_input() on the row GPIOs. On pin controllers where GPIO input and interrupt are separate pinmux functions this switches the row pins out of interrupt mode, and enable_row_irqs() does not switch them back: it only unmasks the interrupts. Row interrupts then never arrive and the keypad stops working. Seen with a matrix keypad on an Allwinner A64 board (PINE A64-LTS); it works again with the commit reverted. The workaround is not needed on Ingenic either: the author of the reverted commit re-tested all available JZ47xx SoCs and they all report the live pin state in interrupt mode, see the thread in Link. Fixes: 01c84b03d80a ("Input: matrix_keypad - force switch rows to input mode") Link: https://lore.kernel.org/all/4130C026-2A83-408B-836A-ECA044491C47@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Alexander Kochetkov Acked-by: Siarhei Volkau Acked-by: Paul Cercueil Link: https://patch.msgid.link/20261002100935.449473-1-al.kochet@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 0cf674a048d68b03d3682d704795dc0741cc1edc Author: Baek Kyu, Kim Date: Tue Oct 20 00:47:18 2026 +0900 hwmon: (sht3x) Return the consumed count for heater writes [ Upstream commit 817ac527100c8e20684211eb919ffd6d875adc7a ] heater_enable_store() returns the result of i2c_master_send(), which is the two-byte command length on success rather than the sysfs input count. This can report more bytes than were supplied, or a partial write for a fully processed input. For example, writing "on\n" returns two instead of three, so a caller retrying the remaining newline gets -EINVAL even though the heater command succeeded. Retrying the remainder of "off\n" can also send the heater-off command twice. Return count after a complete command transfer. Preserve negative I2C errors and return -EIO for nonnegative incomplete transfers, so a zero-message transfer is not reported as a successful zero-byte write. Keep the existing boolean parsing, command selection and locking. Fixes: 50c22cd154e5 ("hwmon: (sht3x) add humidity heater element control") Cc: stable@vger.kernel.org Signed-off-by: Baek Kyu, Kim Link: https://patch.msgid.link/20261019154718.2328055-1-pocj8ur4in@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit bde310304368a1c78d6e3d10085ff95be3ea5ea8 Author: Ma Ke Date: Sun Oct 11 20:17:58 2026 +0800 platform/x86/amd/pmc: Fix RTC reference leak in amd_pmc_verify_czn_rtc() [ Upstream commit 22b9306f1fcf86f80b55f05f08d10a9951ba970a ] amd_pmc_verify_czn_rtc() opens the RTC with rtc_class_open(), which takes both a device reference and a module reference on the RTC driver. The matching release is rtc_class_close(), and it is never called. Every return path after the device has been opened, the ones that return 0 as well as the ones that report an error, leaves both references behind, so each S0i3 suspend leaks them. Release the reference with a __free() cleanup on the declaration, which covers every return path without adding labels. rtc_class_close() does not accept a NULL argument, so the cleanup helper has to guard against one: rtc_class_open() may fail and the declaration still has to be cleaned up. Found by code review. Fixes: 59348401ebed ("platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeup") Cc: stable@vger.kernel.org Signed-off-by: Ma Ke Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20261011121759.3267678-1-make_ruc2021@163.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit dc071de528aa5eeed1217448ff1959d683c6fb5a Author: Gregory Price Date: Thu Oct 15 13:30:28 2026 -0400 rtc: cmos: Disable ACPI RTC event before handling it [ Upstream commit 3f67038df8b5cba07254d1cff60d73e988b49ab7 ] Users of RTC_UIE_ON can stop receiving update interrupts when rtc-cmos handles alarms through ACPI. In one 50-run test, 40 runs passed and 10 timed out after receiving between one and four of five expected events. The ACPI ff_rt_clk counter stopped at 218, exactly matching the number of events delivered to userspace, and reported: 218 STS disabled unmasked rtc_handler() runs in the threaded ACPI SCI handler and calls cmos_interrupt(), which schedules rtc->irqwork. The work can run before rtc_handler() returns: ACPI SCI thread rtc->irqwork cmos_interrupt() schedule_work() __rtc_set_alarm() rtc_wake_on() acpi_clear_event() acpi_disable_event() The SCI thread then disables the event that the worker enabled for the next alarm. That alarm sets its status while delivery remains disabled, so no update interrupt reaches userspace. Clear and disable the current ACPI RTC event before cmos_interrupt() schedules the work. The worker can then enable the next event without the handler undoing it. With this ordering, 150 runs delivered all 750 events without a stall. Fixes: 311ee9c151ad ("rtc: cmos: allow using ACPI for RTC alarm instead of HPET") Cc: stable@vger.kernel.org Signed-off-by: Gregory Price (Meta) Link: https://patch.msgid.link/20261015173029.3091872-2-gourry@gourry.net Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 7d504bbb058409ff6320667b82291700e6dfd34d Author: Seongjae Jeong Date: Wed Oct 14 11:26:29 2026 +0000 f2fs: fix submit accounting for IPU writeback [ Upstream commit 6d1f622b9c069378cdb83088be2b15a9b480b8a3 ] f2fs_write_cache_pages() uses the submitted count, which is set to fio.submitted in f2fs_write_single_data_page(), to update nwritten and decrement wbc->nr_to_write. In the OPU path, f2fs_submit_page_write() sets fio->submitted to 1. However, in the IPU path, fio->submitted is never set and remains zero. As a result, successful IPU writes are not accounted for. This can cause asynchronous writeback to continue beyond its budget. Set fio->submitted in f2fs_inplace_write_data() after a page is successfully merged into a bio or submitted, so that successful IPU writes are included in the writeback accounting. Cc: stable@kernel.org Fixes: d68f735b3bc9 ("f2fs: check io submission more precisely") Signed-off-by: Seongjae Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 5beff8567fdb1a3ff6e1c34c07901e0a52464ed3 Author: Wenjie Qi Date: Fri Oct 16 13:44:05 2026 +0800 f2fs: flush SIT journal during filesystem resize [ Upstream commit a6ede405455106bf42164ec96fd84008c5aabdd9 ] During a filesystem resize, SBI_IS_RESIZEFS prevents new SIT entries from being added to the journal and forces existing entries to the SIT area. However, f2fs_flush_sit_entries() returns early when there are no new dirty sentries, leaving existing journal entries behind. After the main area shrinks, a later checkpoint can access a journal entry whose segment number is outside the new geometry and trigger f2fs_bug_on(). Only take the zero-dirty fast path when entries may be written back to the journal. This lets resize drain existing entries through remove_sits_in_journal() even when there are no new dirty sentries. Cc: stable@kernel.org Fixes: 04f0b2eaa3b3 ("f2fs: ioctl for removing a range from F2FS") Signed-off-by: Wenjie Qi Reviewed-by: Daeho Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 5d66830abd770fde5a5a7c2a75d1b1230c8d8793 Author: Jiale Yao Date: Sun Sep 27 16:49:59 2026 +0800 hwmon: (gigabyte_waterforce) reject short input reports [ Upstream commit 400be69515c327ced60082b27ede902a8d93cbdb ] The HID raw_event callback runs before HID core validates the received report length. waterforce_raw_event() reads command bytes and then accesses fixed offsets for firmware or status data without any length checks. A truncated report can therefore cause out-of-bounds reads and update hwmon state with unrelated data. Require every report to contain the firmware response fields, which also covers both command bytes. After identifying a status response, require the byte at the highest status offset before accessing its payload. Fixes: 42ac68e3d4ba ("hwmon: Add driver for Gigabyte AORUS Waterforce AIO coolers") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Link: https://patch.msgid.link/20260927084959.893708-1-yaojiale02@163.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit cae2d36ad91f702330ca4295383e010101d84d7a Author: Ximing Zhang Date: Fri Oct 16 12:36:37 2026 +0400 hwmon: (coretemp) Fix handling of isolated SMT siblings [ Upstream commit 37c1974a0ec4ec4624a270291a179c53f8f4fbca ] Commit 0f8b916bc5b5 ("hwmon: (coretemp) avoid RDMSR interrupts to isolated CPUs") prevents create_core_data() from creating temperature data for an isolated CPU. coretemp_cpu_online(), however, still adds that CPU to pdata->cpumask. When an isolated SMT thread is processed before a housekeeping sibling, the mask makes coretemp_cpu_online() believe that the core is already represented. The housekeeping sibling then gets no temperature attributes. Package attributes are similarly not retried when the first CPU processed in a die is isolated. The mask is also used to select a replacement CPU when a sensor target goes offline. Including isolated CPUs permits the driver to retarget a sensor to one, causing subsequent sysfs reads to send an RDMSR IPI to an isolated CPU. Keep isolated CPUs out of pdata->cpumask by moving the housekeeping check to coretemp_cpu_online(). Sensor creation is then deferred to an eligible CPU, and hotplug replacement targets remain on housekeeping CPUs. Tested on an Intel Core i7-10510U running 6.18.50-3-cachyos-lts, with nohz_full=1 on CPU 1 and its housekeeping SMT sibling on CPU 5. The stock driver omitted Core 1 after module load and retained its readable sensor after CPU 5 was offlined. The patched driver exposed Core 1, removed it when CPU 5 went offline, and restored it when CPU 5 returned. Fixes: 0f8b916bc5b5 ("hwmon: (coretemp) avoid RDMSR interrupts to isolated CPUs") Cc: stable@vger.kernel.org Cc: Marcelo Tosatti Signed-off-by: Ximing Zhang Tested-by: Asaf Nuri Bertizlioğlu Link: https://patch.msgid.link/20261016-codex-coretemp-housekeeping-v1-1-96618c5676b2@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit a042722d9f6a3c21599cba1e5d7a24e61a90439b Author: Kyle Zeng Date: Wed Oct 7 23:01:00 2026 +0200 netfilter: nf_reject: initialize IPCB at inet ingress [ Upstream commit 73a73d442f9986353fe284bd1b504d0313d0f153 ] The inet ingress hook runs before ip_rcv_core() and ip6_rcv_core(), so neither IPCB nor IP6CB has been initialized when nft_reject_inet passes a packet to nf_send_unreach() or nf_send_unreach6(). skb->cb can therefore retain metadata from an earlier protocol layer. For IPv4, icmp_send() treats IPCB(skb)->opt as parsed IPv4 options. Stale option offsets can make __ip_options_echo() copy an attacker-controlled length into its 40-byte reply option buffer and overflow the stack. On an unpatched v7.2-rc5 kernel, the IPv4 reproducer produced: BUG: KASAN: stack-out-of-bounds in __ip_options_echo() Write of size 255 For IPv6, icmpv6_send() consumes IP6CB(skb) as parsed IPv6 metadata. It always uses iif for source selection and, when MIP6 is enabled, uses dsthao as an extension-header offset. These fields must not be stale. For NF_INET_INGRESS, clear the address-family-specific control block and restore its input interface before constructing the ICMP error. This matches similar initialization normally performed by ip_rcv_core() and ip6_rcv_core(). Fixes: 117ca1f8920c ("netfilter: nft_reject_inet: allow to use reject from inet ingress") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber Signed-off-by: Kyle Zeng Co-developed-by: David Lee Signed-off-by: David Lee Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3e385811176cd7968b0ad687a4118e90632018f4 Author: Nickolai Zeldovich Date: Sat Oct 17 20:07:57 2026 -0400 lib/buildid: reject file offsets that do not fit in pgoff_t [ Upstream commit 0007654a7bf13ef2a19afd398bbc6507087f19fd ] On a 32-bit kernel, parsing the build ID of a crafted ELF file can copy far more than the intended bytes into a 64-byte on-stack buffer in __build_id_parse(), corrupting the stack of whatever context fetches the build ID. This might be reachable without privilege: perf records a build ID for PERF_RECORD_MMAP2 on the no-fault path when a process mmaps its own file (build_id_parse_nofault() from perf_event_mmap()), and BPF build-id stack maps do the same. freader_get_folio() turns a 64-bit file offset into a page cache index with file_off >> PAGE_SHIFT and passes it to filemap_get_folio(). pgoff_t is unsigned long, 32-bit on a 32-bit kernel, so an ELF64 e_phoff of 2^44 + k * PAGE_SIZE truncates to index k. filemap_get_folio() returns the cached folio at index k, whose folio_pos() is far below the requested file_off. In freader_fetch() the folio does not contain file_off, so the "crossing folio boundaries" path computes part_sz = folio_off + folio_sz - file_off as a large u64 (file_off is much larger), and the following memcpy() truncates it to size_t and copies a page into the 64-byte buffer. On a 64-bit kernel the index is not truncated, the folio is not cached and the fetch returns -EFAULT, so only 32-bit kernels are affected. Reject a file offset that cannot be represented as a page cache index before the lookup, so such a file fails the build ID parse cleanly as it already does on 64-bit. Reproduced on i386 under QEMU with CONFIG_STACKPROTECTOR_STRONG: mmapping a crafted ELF (ELFCLASS64, e_phoff = 2^44) while a perf event with attr.build_id is open panics with "stack-protector: Kernel stack is corrupted in: __build_id_parse"; with this patch the parse returns -EFAULT and the mmap completes cleanly. Built for i386 with W=1, no new warnings. Fixes: de3ec364c3c3 ("lib/buildid: add single folio-based file reader abstraction") Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Nickolai Zeldovich Signed-off-by: Andrii Nakryiko Signed-off-by: Sasha Levin commit c20e2c5505e8c39e889f6a9c34fd4a97a6851d7c Author: Sanan Hasanov Date: Thu Oct 8 16:52:45 2026 -0400 hwmon: (corsair-cpro) Make wait_input_report_lock IRQ safe [ Upstream commit e4fdc82f55cf0e3d5df5c88278da5baa76a109d1 ] ccp_raw_event() is the HID ->raw_event() callback and takes wait_input_report_lock with a plain spin_lock(). This callback can run in very different contexts depending on the transport: from process context (e.g. uhid, via a write() to /dev/uhid) with softirqs and interrupts enabled, and from URB completion, which is softirq context for HCDs using HCD_BH and hard interrupt context for HCDs that do not (e.g. OHCI, UHCI). Taking the lock from process context with softirqs enabled while the same lock is also taken from softirq context can deadlock if the softirq interrupts the lock holder on the same CPU. Lockdep reports: WARNING: inconsistent lock state inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ... spin_lock include/linux/spinlock.h:347 [inline] ccp_raw_event+0x51/0x110 drivers/hwmon/corsair-cpro.c:161 __hid_input_report+0x41c/0x580 drivers/hid/hid-core.c:2175 hid_irq_in+0x492/0x710 drivers/hid/usbhid/hid-core.c:287 __usb_hcd_giveback_urb+0x378/0x540 drivers/usb/core/hcd.c:1657 dummy_timer+0xa91/0x4cc0 drivers/usb/gadget/udc/dummy_hcd.c:2023 For the same reason, the spin_lock_bh() in send_usb_cmd() is not sufficient when ccp_raw_event() is called from hard interrupt context. Use spin_lock_irqsave() in ccp_raw_event(), since it may be called with interrupts already disabled, and spin_lock_irq() in send_usb_cmd(), which always runs in process context. Fixes: d02abd57e794 ("hwmon: (corsair-cpro) Protect ccp->wait_input_report with a spinlock") Reported-by: syzbot+0f98b0c0bdeaab2dc2fd@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0f98b0c0bdeaab2dc2fd Cc: stable@vger.kernel.org Signed-off-by: Sanan Hasanov Link: https://patch.msgid.link/20261008205310.30832-1-sanan.hasanou@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 2481f9585c843728cffe5d75d0104552e834f0d1 Author: Weibin Liu Date: Tue Oct 13 13:43:39 2026 +0800 spi: ch341: handle transfers without a TX or RX buffer [ Upstream commit 84182c48999f856c3865e4a537c244f9569c9f6c ] ch341_transfer_one() unconditionally copies from trans->tx_buf into the TX packet and hands trans->rx_buf to usb_bulk_msg() for the readback. The SPI core allows half-duplex transfers where either of the buffers is NULL, so a transfer without TX data crashes the kernel on the memcpy and a transfer without RX data makes usb_bulk_msg() store the received data at address 0. The CH341A clocks data in both directions on every transfer; there is no mode to disable a direction. Set SPI_CONTROLLER_MUST_TX and SPI_CONTROLLER_MUST_RX so the SPI core fills in dummy buffers for half-duplex transfers. Fixes: 8846739f52af ("spi: add ch341a usb2spi driver") Cc: stable@vger.kernel.org # 6.11+ Signed-off-by: Weibin Liu Link: https://patch.msgid.link/20261013054339.77477-1-liuwb@xiaopeng.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 016d1fbbb9a665122025458bb4bf0fe63cf292b8 Author: Vasiliy Kovalev Date: Sat Oct 17 13:12:57 2026 +0300 ALSA: hda/via: Apply runtime PM workaround for ASUS X55A [ Upstream commit f6e8d5ebde5ceb7d3c0eef6e9e4d82862b503ade ] ASUS X55A requires the same workaround like other machines with VT1802, otherwise it loses the codec power on a few nodes and the sound stays silent. Link: https://bugzilla.altlinux.org/45606 Cc: Tested-by: Nikita Maksimov Signed-off-by: Vasiliy Kovalev Link: https://patch.msgid.link/20261017101257.215166-1-kovalev@altlinux.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 398aee3dd326d709801c8b530c30cbe6ee7dafb9 Author: Magnus Lindholm Date: Sat Oct 10 16:33:11 2026 +0200 alpha: do not skip TLB shootdown IPIs for kthread-borrowed mms [ Upstream commit fe221b7b2d3ecd042dd391f74ff6a6fdeb7c2038 ] flush_tlb_mm(), flush_tlb_page() and flush_icache_user_page() skip the shootdown IPI when mm_users <= 1, on the assumption that no other CPU can be running the mm. A task that borrows an mm through kthread_use_mm() takes mmgrab() rather than mmget(), so it never appears in mm_users, and kthread_use_mm() may be handed an mm that is already the caller's active_mm and loaded on that CPU. Such a CPU was not only left without an IPI, its mm->context[cpu] was cleared from under it. mm->context[cpu] is already the record of which CPUs hold an ASN for the mm. Test it rather than clearing it: take the shortcut only when no other CPU has one, and otherwise fall through to the IPI, which invalidates those CPUs properly. A CPU that merely ran the mm in the past also holds a context and now costs an IPI, which errs in the safe direction. Change ipi_flush_tlb_mm(), ipi_flush_icache_page() and the migration callback ipi_flush_mm_and_page() to test current->mm, like ipi_flush_tlb_page(). A CPU that only retains the mm lazily then clears its own slot through flush_tlb_other(), rather than publishing a new ASN on every IPI or migration rendezvous. The migration callback still does its per-VA tbi() afterwards. Returning to the mm allocates a fresh ASN through ev5_switch_mm(), or through the direct-load path when kthread_use_mm() switches current's mm. Once these historical slots are gone, the shortcut is available again if mm_users remains at most one and no other CPU has taken or kept a context. An explicit kthread_use_mm() borrower has current->mm set and still receives the invalidate it needs. The caller-side tests in flush_tlb_mm() and flush_icache_user_page() remain current->active_mm. A kernel thread that flushes its lazily held mm can therefore publish its own context slot. Those branches also perform the shortcut check, which excludes the calling CPU's slot, so leave them unchanged. This is distinct from a remote lazy CPU keeping its slot populated through repeated callbacks. Together with the preceding patch, dropping these clearing loops leaves every runtime write to mm->context[] targeting the writing CPU's own slot, so the array becomes a lockless publication of which CPUs may be using the mm, with a single writer per slot. Mark the two stores that are now observed from other CPUs; flush_tlb_other() already uses WRITE_ONCE(). The uniprocessor flush_icache_user_page() is left alone, as nothing reads another CPU's slot there, and init_new_context() runs before the mm is shared. Order the slot reads after the page-table changes with smp_mb(). On the publishing CPU, the store in ev5_switch_mm() precedes the mb() in Alpha's arch_spin_unlock(), when finish_lock_switch() drops the rq lock. This relies on Alpha's unlock implementation, not a generic scheduler promise of a full barrier on unlock; document that reliance at the store. Also issue smp_mb() after publishing in __load_new_mm_context(), before loading and using the mm. This covers every caller, including check_mmu_context(), which can publish a replacement after finish_lock_switch() has already run. This requires the preceding removal of remote slot clearing from migrate_flush_tlb_page(). It also requires the stale-TLB series to set need_new_asn on both the reused and newly allocated ASN paths. Otherwise an IPI between finish_lock_switch() and check_mmu_context() can zero a new slot while asn_lock is set, and the task can return to user space with a live ASN that the shortcut cannot see. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: # 53ab52cfe5ce: alpha: load the MMU context when switch_mm() switches the current task Cc: # 01df8f401888: alpha: run check_mmu_context() from finish_arch_post_lock_switch() Cc: # ef43cfc28c42: alpha: only use a targeted tbi() when the target mm is really current Cc: # 738cf8f7a78f: alpha: invalidate the local context in flush_tlb_page() Cc: # 62c92086f30e: alpha: fix the local TLB invalidate in flush_tlb_page() Cc: # 3faee097b939: alpha: fix the local TLB invalidate in the UP flush_tlb_page() Cc: # b2c3b654bb64: alpha: invalidate the local context in flush_tlb_mm() Cc: # f19ae6f51a38: alpha: invalidate the local context in flush_icache_user_page() Cc: # 471e7f9c890b: alpha: do not clear remote MMU contexts in migrate_flush_tlb_page() Cc: stable@vger.kernel.org Reviewed-by: Matt Turner Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20261010144621.974850-3-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit dbd8090f5d0308b8f44752d8ea6f6626c4c4b65b Author: Magnus Lindholm Date: Sat Oct 10 16:33:10 2026 +0200 alpha: do not clear remote MMU contexts in migrate_flush_tlb_page() [ Upstream commit 16266d50c51eb5eb98f1c345c5aa9ff359a305aa ] After the on_each_cpu() rendezvous, migrate_flush_tlb_page() walks the other CPUs and zeroes their mm->context[cpu] when mm_users is at most one, described as mimicking flush_tlb_mm()'s mm_users<=1 optimization. It is not one. flush_tlb_mm() tests mm_users before deciding whether to send the IPIs; here every CPU has already been visited and waited for, so nothing is saved. The callback has also just set each CPU's own slot correctly, so the loop only overwrites it, and does so while that CPU may still be running in the address space. Remove it. The shootdown shortcuts in flush_tlb_mm(), flush_tlb_page() and flush_icache_user_page() clear remote slots too; once the next patch removes those as well, every runtime update of mm->context[cpu] is made by CPU cpu itself. That patch relies on the invariant when it reads those slots to decide whether a shootdown can be skipped, so this one is tagged for stable as its prerequisite. Fixes: dd5712f3379c ("alpha: fix user-space corruption during memory compaction") Cc: stable@vger.kernel.org Reviewed-by: Matt Turner Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20261010144621.974850-2-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit ec0a71d8820df8452a48fb8d550bc43a9e6fa2e9 Author: Magnus Lindholm Date: Sat Oct 10 16:24:34 2026 +0200 alpha: invalidate the local context in flush_icache_user_page() [ Upstream commit 4244c555ac440a445cc168f860b2677099d761f9 ] flush_icache_user_page() has the same caller-CPU omission that the previous patch fixed in flush_tlb_mm(): when the target mm is not the calling CPU's active_mm nothing happens locally, and smp_call_function() handles only the other CPUs, so this CPU may later reuse the old ASN together with the translations it still holds. This matters here in particular because the function exists for operating on another process's mappings: the comment above it describes setting breakpoints through ptrace, and access_remote_vm() reaches it through copy_to_user_page(). The calling CPU is therefore often running something other than the target mm. As in flush_tlb_mm(), the uniprocessor implementation in asm/cacheflush.h already has the missing case. No imb() is needed, here or in ipi_flush_icache_page(). Alpha's user-space I-cache flush works by allocating a new ASN rather than by invalidating the I-cache: the entries stay, but they are tagged with the old ASN and can no longer match. An imb() is only required when the ASN space wraps and numbers are reused, and __get_new_mm_context() already does one in that case. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Matt Turner Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20261010142533.974797-9-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit c25050f8e22e1f65e244970c0f641d4413287991 Author: Magnus Lindholm Date: Sat Oct 10 16:24:33 2026 +0200 alpha: invalidate the local context in flush_tlb_mm() [ Upstream commit 721bb7a129771f0ff9cef1dd5abfc106ef65feba ] flush_tlb_mm() has the same caller-CPU omission that was fixed in flush_tlb_page(): when the target mm is not the calling CPU's active_mm nothing happens locally, and smp_call_function() handles only the other CPUs, so this CPU may later reuse the old ASN together with the translations it still holds. The active_mm test itself is left alone here. That path calls flush_tlb_current(), which loads a fresh context through __load_new_mm_context() rather than issuing a targeted tbi() against whatever ASN happens to be loaded, so it does not depend on which context is current. The uniprocessor implementation in asm/tlbflush.h already has the missing branch. Counted over a fork-heavy run, flush_tlb_mm() was entered with the mm not this CPU's active_mm 2934 times, and 632 times while otherwise idle. The proposed Alpha hugetlb support routes hugetlb invalidations through flush_tlb_range(), which calls this function. Unmapping or migrating a hugetlb folio from another context will also need this local invalidate. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Matt Turner Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20261010142533.974797-8-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit c127e7860409390f4d8fc923eec4c3538b80466d Author: Magnus Lindholm Date: Sat Oct 10 16:24:32 2026 +0200 alpha: fix the local TLB invalidate in the UP flush_tlb_page() [ Upstream commit c825bf802a7a43fd302c879ef25c975e067a2e94 ] The uniprocessor flush_tlb_page() in asm/tlbflush.h has the same wrong test as the SMP one: a targeted tbi() is only guaranteed to invalidate the intended translations when the target mm's context is loaded, but the gate is current->active_mm, which a lazily borrowed mm also satisfies. Test current->mm instead. The else branch it falls to already exists here, so unlike the SMP side this is the whole fix. arch/alpha/kernel/smp.c is not built with CONFIG_SMP=n, so this is how the same defect reaches a uniprocessor, where the flusher kworker necessarily shares the only CPU with the writer. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Matt Turner Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20261010142533.974797-7-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit 3d6546c65188befd9ee3cf65ce7dcf08b5e08610 Author: Magnus Lindholm Date: Sat Oct 10 16:24:31 2026 +0200 alpha: fix the local TLB invalidate in flush_tlb_page() [ Upstream commit 32f4dd420d626f96128fcfeea2ab24760b4f21a6 ] flush_tlb_page() invalidates the calling CPU itself before asking the others, and gates that on current->active_mm. For a non-executable vma that means a targeted tbi(2, addr), which acts on the context currently loaded and is only guaranteed to invalidate the intended translations when the target mm's context is the loaded one. A lazy active_mm does not establish that, so as in ipi_flush_tlb_page() the target mm's stale translations can survive, and nothing forces the old ASN to be retired afterwards. Test current->mm instead. A lazy caller then takes the flush_tlb_other() branch added by the previous patch, retiring its local context. Adding that branch first preserves the local invalidate at every step, including on EV7 where a targeted tbi() against a foreign ASN appeared to work. Which callers reach here with a foreign mm depends on the configuration. folio_mkclean(), from the writeback flusher kworker that has no mm of its own, accounted for about half the calls during writeback of a shared mapping and none at all on anonymous memory. Those counts were measured with CONFIG_COMPACTION=n: with COMPACTION=y, asm/pgtable.h overrides ptep_clear_flush() to call migrate_flush_tlb_page(), which rendezvouses with every CPU and handles the context itself, so folio_mkclean() does not reach this function. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Matt Turner Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20261010142533.974797-6-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit d67bdaa88078da5ffa8d7b26a42f0d7e9e534934 Author: Magnus Lindholm Date: Sat Oct 10 16:24:30 2026 +0200 alpha: invalidate the local context in flush_tlb_page() [ Upstream commit c0db730bf05eb3c10c1fae64b19f6913dce129fc ] When the target mm is not the calling CPU's active_mm, flush_tlb_page() does nothing locally, and smp_call_function() reaches only the other CPUs. This CPU may still hold translations for the mm and can later reuse the old ASN together with them. Add the missing else branch. flush_tlb_other() clears mm->context[cpu] so a fresh ASN is taken at the next switch. Add this before changing the current->active_mm test to current->mm: that change will also send lazy callers here, so their local invalidate must already be in place. The uniprocessor implementations of flush_tlb_mm() and flush_icache_user_page() in asm/tlbflush.h and asm/cacheflush.h already contain exactly this branch. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Matt Turner Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20261010142533.974797-5-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit f04da607615b457b6e797f2139fbf05de8f50a56 Author: Magnus Lindholm Date: Sat Oct 10 16:24:29 2026 +0200 alpha: only use a targeted tbi() when the target mm is really current [ Upstream commit 0d92845ac5dbc79e4ac4810b33c673f4c1c227e3 ] ipi_flush_tlb_page() gates a targeted tbi() on current->active_mm. tbi() acts on the address space context currently loaded on the CPU, so it is only guaranteed to reach an mm's translations when a thread of that mm is running there. current->active_mm is not sufficient: under lazy TLB an idle or kernel task keeps an mm as its active_mm while a different ASN is loaded, so the invalidate is issued against the wrong context and the stale entry can survive. Nothing retires the old ASN afterwards either, mm->context[cpu] still being valid, so the resuming thread can reuse it. Test current->mm instead and otherwise fall back to flush_tlb_other(), which clears mm->context[cpu] and forces a fresh ASN at the next switch whatever is loaded now. For an mm borrowed through kthread_use_mm(), patch 1 of this series installs the context before the task can take a shootdown IPI. The current->mm test therefore covers that case as well. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Matt Turner Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20261010142533.974797-4-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit e47f875879259e16a0a16ded3236687b372efbe1 Author: Magnus Lindholm Date: Sat Oct 10 16:24:28 2026 +0200 alpha: run check_mmu_context() from finish_arch_post_lock_switch() [ Upstream commit 020d2e70b7538b66eee3c3480d2b8921fb182f0c ] check_mmu_context() clears asn_lock and acts on need_new_asn, but it runs only as the tail of switch_to(), after alpha_switch_to() returns. A newly forked user task never gets there: its first context switch resumes at ret_from_fork and reaches schedule_tail() without returning to the code following alpha_switch_to(). asn_lock is left set on that CPU, so the new user task can run with interrupts enabled while shootdown IPIs keep taking the deferred path. The handshake meant to complete those invalidations never runs. New kernel threads also reach schedule_tail(), but context_switch() does not call switch_mm() for a task without an mm. They therefore do not set asn_lock in the first place and are not affected by this bug. Move check_mmu_context() to finish_arch_post_lock_switch(), which is called by finish_task_switch() for both existing and newly created tasks. Drop the now redundant call from switch_to(). The hook runs after finish_lock_switch() releases the rq lock and enables interrupts. An IPI arriving before asn_lock is cleared retires the slot through flush_tlb_other(); an IPI arriving afterwards can flush directly, since PAL_swpctx has already installed the incoming context. Set need_new_asn whether ev5_switch_mm() reuses or allocates an ASN. An IPI in that interval can zero either slot. Without this, the allocated case can return to user space with a live ASN but a zero context slot, which a later context-based shootdown shortcut could mistake for an inactive CPU. check_mmu_context() reloads only when the slot is zero. Call the hook unconditionally. Alpha selects ARCH_NO_PREEMPT, and neither kthread_use_mm() nor sched_force_init_mm() sleeps between the direct switch and this hook. RCU_STRICT_GRACE_PERIOD can enable PREEMPT_COUNT, but cannot make those callers migrate there. Testing preemptible() would only leave asn_lock set in that configuration. This requires the preceding direct-switch fix, "alpha: load the MMU context when switch_mm() switches the current task". It installs the borrowed context before kthread_use_mm() reaches this hook, so clearing asn_lock cannot expose a targeted invalidate against the wrong context. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Matt Turner Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20261010142533.974797-3-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit e4223344d89d70ad289494a0e92eef3ef58ccaa1 Author: Magnus Lindholm Date: Sat Oct 10 16:24:27 2026 +0200 alpha: load the MMU context when switch_mm() switches the current task [ Upstream commit 9b8be19d5dc9525a408942e2e8012873199e7455 ] ev5_switch_mm() only prepares the incoming PCB. The context is installed by PAL_swpctx, which alpha_switch_to() issues against that PCB on the way out of the scheduler. Direct callers reach switch_mm() without going through alpha_switch_to(): kthread_use_mm(), which borrows an mm for the current kernel thread, sched_force_init_mm() on the CPU-hotplug teardown path, and do_shoot_lazy_tlb(), which switches to init_mm from an IPI. None explicitly loads the context, so the task can carry on running under whatever was loaded before. For kthread_use_mm(), current->mm then names the borrowed mm even though its context has not been loaded. The other two callers change active_mm while leaving current->mm NULL. The stale page-table root need not be swapper_pg_dir; it may belong to a user process that ran on the CPU earlier, and the kthread's user accesses can then read and write that process's memory wherever the stale mappings allow. Translations taken that way can also end up tagged with the borrowed mm's ASN: ev5_switch_mm() writes that ASN into the PCB, which the next PAL_swpctx installs against the stale ptbr. An address the stale tables do not map faults instead, and since do_page_fault() resolves faults against current->mm without reloading the context, the same access can fault again on return. sched_force_init_mm() needs CONFIG_HOTPLUG_CPU and do_shoot_lazy_tlb() needs CONFIG_MMU_LAZY_TLB_SHOOTDOWN. Alpha selects neither, so only kthread_use_mm() is reachable in practice. Test the caller's identity rather than special-casing individual callers. The scheduler passes the incoming task, which is not current until alpha_switch_to() runs; all three direct callers pass current. Test for that and load the context the way activate_mm() does. All three run with interrupts disabled across the switch, so this completes before any shootdown can be taken and needs no asn_lock handshake. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Tested-by: Matt Turner Reviewed-by: Matt Turner Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20261010142533.974797-2-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit c2ba5464ab93186f62128a6b77e0570f50253b7d Author: Matt Turner Date: Wed Oct 7 23:24:05 2026 -0400 alpha: handle VM_FAULT_HWPOISON in do_page_fault() [ Upstream commit 4bef20bbb9e02568a009efa4d404ce2621289be5 ] do_page_fault() handles VM_FAULT_OOM, VM_FAULT_SIGSEGV and VM_FAULT_SIGBUS and then falls into BUG() for anything else in VM_FAULT_ERROR. VM_FAULT_HWPOISON and VM_FAULT_HWPOISON_LARGE are in that set, so a fault on a poisoned page takes down the kernel instead of delivering a signal. Alpha does not select ARCH_SUPPORTS_MEMORY_FAILURE, so the machine check paths cannot produce these. UFFDIO_POISON can: it installs a poison PTE marker without any memory failure support, and a subsequent access returns VM_FAULT_HWPOISON. Registering an anonymous range with userfaultfd, poisoning it and reading it back reliably hits the BUG(): Kernel bug at arch/alpha/mm/fault.c:188 poison(50809): Kernel Bug 1 pc is at do_page_fault+0x4e8/0x550 ra is at do_page_fault+0xfc/0x550 The BUG() fires with mmap_read_lock() still held, so the faulting task is left unkillable in D state holding the lock, and shutdown stalls behind it. A UFFD_USER_MODE_ONLY userfaultfd is always allowed, so any local user can do this. Deliver SIGBUS with BUS_MCEERR_AR instead, reporting the size of the poisoned area, as the other architectures do. That is the huge page size for VM_FAULT_HWPOISON_LARGE, which becomes reachable once alpha implements huge pages. Tested on an UP1500 (EV68AL): the reproducer above now takes a SIGBUS and the kernel logs poison[373]: hardware memory error at 0000020000030000 pc 00000200010007ec with no oops, no wedged task and no taint. A backport needs the show_signal_msg() call dropped, since alpha only has it since commit 9ca6af1aac40 ("alpha: select SYSCTL_EXCEPTION_TRACE"). Fixes: fc71884a5f59 ("mm: userfaultfd: add new UFFDIO_POISON ioctl") Cc: stable@vger.kernel.org # 6.6+ Reviewed-by: Magnus Lindholm Tested-by: Magnus Lindholm Signed-off-by: Matt Turner Link: https://lore.kernel.org/r/20261007-alpha-hugepages-v2-2-8e108af2d961@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit 1df2637311b1064ff629d2909411bd858a5309c1 Author: Tim Douglas Date: Mon Oct 12 22:21:53 2026 -0400 power: supply: generic-adc-battery: fix status with no supplier [ Upstream commit 8ae5a3f40045ff486826ed6b6a83e39a0f380073 ] power_supply_am_i_supplied() returns -ENODEV when no registered power supply supplies the battery. generic-adc-battery's gab_work() tests this return value as a boolean, so -ENODEV takes the supplied branch and reports CHARGING, or NOT_CHARGING if the charge-finished GPIO is asserted, instead of DISCHARGING. This was noticed while bringing up an out-of-tree Linux port to the WikiReader: the driver reported CHARGING on a device powered by two AAA batteries with no charging hardware. Only a positive return value indicates an online supplier, so treat zero and negative returns as discharging. Fixes: 46cecd130d55 ("power: supply: Fix power_supply_am_i_supplied to return -ENODEV when apropriate") Cc: stable@vger.kernel.org Signed-off-by: Tim Douglas Link: https://patch.msgid.link/20261013022153.6707-1-me@timdoug.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit c1b7156ebbe4c147d0825105811cb62e7231df19 Author: Luis Gerardo Lopez Hernandez Date: Fri Oct 16 18:50:39 2026 -0600 ALSA: hda/realtek: Fix internal speakers on Acer Aspire AL16-31P [ Upstream commit d933955c456e0573b40eae4f72a3af37ab1c15c3 ] The Acer Aspire AL16-31P (Intel Alder Lake-N, Realtek ALC269VC, PCI/codec SSID 2782:1718) has its internal speakers wired to pin 0x1b, but the BIOS marks that pin as not connected (0x411111f0) and only exposes pin 0x14 as the speaker. As a result the internal speakers are silent while headphones, HDMI and Bluetooth work. This is the same layout as the Infinix Y4 Max and MEDION E15433, which share the 0x2782 subsystem vendor. Reuse their fixup, which configures pin 0x1b as an internal speaker and limits the internal mic boost. Tested by booting with snd-hda-intel model=2782:1705: the fixup is picked, pin 0x1b is used as a speaker output, the internal speakers work, and they are muted when headphones are plugged in. Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Luis Gerardo Lopez Hernandez Link: https://patch.msgid.link/20261017005039.9139-1-gamaerry@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 00b7c7d7a6168ccece7a5bd84331326987ead645 Author: Takashi Iwai Date: Fri Oct 16 18:19:29 2026 +0200 ALSA: seq: oss: Skip events until fully initialized [ Upstream commit 68d4a6ea6cc6091a05836f783bc17d525d266d0b ] When an OSS sequencer device is opened, it creates a sequencer port, then further initializes the internal states like a timer instance, etc. Since the sequencer port is published, an event can be already delivered, and this may hit unexpected event handling, which can eventually cause a NULL dereference (like the timer start/stop event triggered before the timer initialization). For avoiding such a race, introduce a simple guard and skips the event processing until the port is fully initialized. At releasing the device, in turn, clear this guard, so that any input events will be discarded during the teardown. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Sashiko Cc: Link: https://patch.msgid.link/20261016161930.482309-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d47337f3cb2156c674934c22a5ebce38aeecad2a Author: Quanye Yang Date: Tue Oct 13 16:29:19 2026 +0200 mptcp: reset msk state on early connect failure [ Upstream commit 29afe67082b2d33ab2e90c56c337235d725f023f ] mptcp_connect() can fall back before the subflow SYN is sent, for example when the netns is in an MPTCP blackhole, token allocation fails, or MD5SIG is in use. If the subsequent subflow connect() fails immediately (EAFNOSUPPORT, ENETUNREACH, ...), __inet_stream_connect() returns while the socket is still SS_UNCONNECTED and never calls ->disconnect(). This was reported by Clashiko [1]. The error path only dropped the token and moved the msk back to TCP_CLOSE. MPTCP_FALLBACK_DONE, allow_subflows and request_mptcp were left as after early fallback, so a later connect() on the same fd stayed TCP-only. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/633 [1] Fixes: 0235d075a592 ("mptcp: mark as fallback even early ones") Cc: stable@vger.kernel.org Signed-off-by: Quanye Yang Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20261013-net-mptcp-misc-fixes-7-3-rc8-v1-1-932c9b182fc7@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9635007b7231d656f5e0b5a047a5575b64307864 Author: Kees Cook Date: Tue Oct 13 22:23:43 2026 -0700 ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again [ Upstream commit c57fbbe42e907fa26c5ffada52d913d4ca5fa66e ] Since commit 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for alloc_msg()"), alloc_msg() allocates with GFP_KERNEL, and a msg_msg is accounted only through SLAB_ACCOUNT on its bucket caches. With CONFIG_SLAB_BUCKETS=n, kmem_buckets_create() creates no caches and kmem_buckets_alloc() is a GFP_KERNEL kmalloc() from the general caches, which do not account it; the same happens when kmem_buckets_create() fails. Either way, the allocation is not charged to the sender's memory cgroup. Allocate with GFP_KERNEL_ACCOUNT again, as before that commit, so the allocation is charged whichever cache serves it. Build tested ARCH=x86_64 defconfig with GCC 16.2.0, with CONFIG_SLAB_BUCKETS as y and n. Fixes: 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for alloc_msg()") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Link: https://patch.msgid.link/20261014052344.384723-2-kees@kernel.org Signed-off-by: Vlastimil Babka (SUSE) Reviewed-by: Harry Yoo (Meta) Reviewed-by: Pedro Falcato Signed-off-by: Harry Yoo (Meta) Signed-off-by: Sasha Levin commit 30543ce5ebcf55c037c6508abc3715b5d4708246 Author: Fan Wu Date: Tue Sep 22 08:13:18 2026 +0000 virtio_fs: read the vring size under virtio_fs_mutex in ->get_tree [ Upstream commit e7ccc777a040343b80f95f4cc5c12ce1df3187f4 ] The vring size was read after virtio_fs_find_instance() had dropped virtio_fs_mutex, so a concurrent virtio_fs_remove() could free the virtqueue first. The reference from the lookup keeps the virtio_fs alive, but not its virtqueues. Hold the mutex across the lookup and the read. This issue was found by an in-house static analysis tool. Fixes: a7f0d7aab0b4 ("virtiofs: split requests that exceed virtqueue size") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 192ae75ed958e143f5d5102cee1049d4f622c127 Author: Huacai Chen Date: Fri Aug 28 11:12:01 2026 +0800 cpufreq: loongson3: Replace IOCSR read/write with MMIO ones [ Upstream commit 81792daacfb41ca07b04bd3956ea9e672080cc98 ] Our server productions (e.g. Loongson-3D6000/3E6000) can have multiple nodes in one package and SMC mailboxes are also per-node. However, IOCSR read/write can only perform on the current node, while sometimes we want to perform on other nodes (e.g. when switch governor, the get and target callbacks are not run on target core). So replace IOCSR read/write with MMIO ones. Cc: stable@vger.kernel.org Fixes: ccf51454145b ("cpufreq: Add Loongson-3 CPUFreq driver support") Tested-by: Xi Ruoyao Signed-off-by: Huacai Chen Reviewed-by: Zhongqiu Han Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit b525827bbbb0d70b70fe15e84b01a532f805f524 Author: Huacai Chen Date: Fri Aug 28 11:12:00 2026 +0800 cpufreq: loongson3: Use global physical CPU ID in get/target callbacks [ Upstream commit e38360d7c62c8fa530b58905f99a4557d4d6b352 ] Our server productions (e.g. Loongson-3D6000/3E6000) can have discrete global physical CPU IDs while the core ID inside the packages are always continuous. In these cases we should use global physical CPU IDs to get and set frequencies. Cc: stable@vger.kernel.org Fixes: ccf51454145b ("cpufreq: Add Loongson-3 CPUFreq driver support") Signed-off-by: Hongliang Wang Signed-off-by: Huacai Chen Reviewed-by: Zhongqiu Han Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit e676ba28caf70b789d5ad0bfcea41f125a06c8f9 Author: Huacai Chen Date: Fri Aug 28 11:11:59 2026 +0800 cpufreq: loongson3: Replace per-package mutex with per-node [ Upstream commit 5d7802ada30b3101f408706b7399b0e170d2febd ] Our server productions (e.g. Loongson-3D6000/3E6000) can have multiple nodes in one package and SMC mailboxes are also per-node. So replace the per-package mutex with per-node one. Cc: stable@vger.kernel.org Fixes: ccf51454145b ("cpufreq: Add Loongson-3 CPUFreq driver support") Signed-off-by: Hongliang Wang Signed-off-by: Huacai Chen Reviewed-by: Zhongqiu Han Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit f482713d0fa5320882711ff3c3506f1edee6dfee Author: Huacai Chen Date: Fri Aug 28 11:11:58 2026 +0800 cpufreq: loongson3: Adjust the width of id and val in smc_message [ Upstream commit 290814d3c22b300eb36b74dc76ad36bd7fdc1220 ] The id field of smc_message is usually stand for the CPU ID. In the past this driver was only tested for desktop and laptop productions so 4-bits are enough. But now we have servers that can have as many as 256 cores, so we need 8-bits CPU ID. On the other hand, the val field is usually stand for CPU frequency so 12-bits are enough to represent 4GHz, and for higher frequencies there is an extra bit to extend (enough for 8GHz). In theory, this is a incompatible change, but fortunately the old SMC firmwares are not widely shipped and can be updated on the air, thus we can safely adjust the widths. Cc: stable@vger.kernel.org Fixes: ccf51454145b ("cpufreq: Add Loongson-3 CPUFreq driver support") Signed-off-by: Hongliang Wang Signed-off-by: Huacai Chen Reviewed-by: Zhongqiu Han Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 68648d2b314e9c2b5520ade2dbb04937fdeb0a9b Author: Huacai Chen Date: Fri Aug 28 11:11:57 2026 +0800 cpufreq: loongson3: Make this driver depend on MACH_LOONGSON64 [ Upstream commit 48a82a3f44576a1b227f964fdb150e1cae7455bf ] 32BIT Loongson machines don't have SMC and FreqCtrl registers, so make this driver depend on MACH_LOONGSON64 (only for LoongArch based 64bit machines currently). Cc: stable@vger.kernel.org Fixes: ccf51454145b ("cpufreq: Add Loongson-3 CPUFreq driver support") Signed-off-by: Huacai Chen Reviewed-by: Zhongqiu Han Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit a677ab813e65019351c45641f6cafbee6e9cb491 Author: Shubham Antil Date: Tue Oct 13 08:27:29 2026 +0530 RDS/IB: validate receive fragment completions [ Upstream commit 65cf6863606b0507a7c3bd1711317e4f5d6b8b7e ] rds_ib_process_recv() accounts every receive fragment as contributing min(i_recv_data_rem, RDS_FRAG_SIZE) bytes, regardless of the completion length. When a completion is shorter than the header-declared amount, receive accounting can advance beyond the payload supplied by the completion. Only an IB_WC_RECV completion has the buffer layout expected by this receive path. Other successful completion opcodes must not be interpreted as ordinary receive completions. Reject successful completions with any other opcode before processing their length. For ordinary receive completions, require enough payload to cover the amount accounted to the fragment before linking its page into the incoming message. This is compatible with the current transmit paths. MSG_ZEROCOPY is restricted to RDS/TCP, while RDS/IB copied and page-vector messages use full-sized non-final scatterlist entries. Found during an LLM-assisted source audit and validated under KMSAN with a malformed short receive completion. Reported-by: sungbyeongchan Closes: https://lore.kernel.org/netdev/20261006205204.1322102-1-tjdqudcks0424@naver.com/ Reported-by: Giovanni Vignone Link: https://lore.kernel.org/netdev/8a6ee1d5336ae65b8ffdc8c40a1135657207e204.camel@kernel.org/ Reported-by: Robert van Eijk Link: https://lore.kernel.org/netdev/8a6ee1d5336ae65b8ffdc8c40a1135657207e204.camel@kernel.org/ Reported-by: Paolo Gentry Link: https://lore.kernel.org/netdev/8a6ee1d5336ae65b8ffdc8c40a1135657207e204.camel@kernel.org/ Fixes: 1e23b3ee0e94 ("RDS/IB: Receive datagrams via IB") Cc: stable@vger.kernel.org Signed-off-by: Shubham Antil Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20261013025729.40815-1-shubham@octane.security Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 166ae81eddb346ed7864e4c3265cd047ff66f5f5 Author: Seung Min Shin Date: Sun Oct 11 16:27:50 2026 +0000 sctp: hold transport reference across connect wait [ Upstream commit 5bef8649bb9ac4b2a014bcc227202ebd2df824be ] sctp_sendmsg_to_asoc() selects a transport before waiting for a new interleaved association to become established. sctp_wait_for_connect() drops the socket lock while sleeping. While the lock is dropped, backlog processing can handle a COOKIE ACK and an ASCONF DEL-IP that removes the selected transport. sctp_assoc_rm_peer() then marks the transport dead and drops its association-owned reference. The transport can be freed through RCU before the send path resumes. After the wait, the stale pointer is assigned to newly created DATA or I-DATA chunks and later dereferenced by sctp_outq_select_transport(). Hold a reference to the selected transport across sctp_wait_for_connect(). After the socket lock is reacquired, abort the send if the transport was marked dead. Callers without a selected transport pass NULL and retain their existing behavior. Cc: stable@vger.kernel.org Fixes: 668c9beb9020 ("sctp: implement assign_number for sctp_stream_interleave") Acked-by: Xin Long Signed-off-by: Seung Min Shin Link: https://patch.msgid.link/20261011162750.1529631-1-guncraft2000@naver.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 81a43a0e3057804a032e5b7b64e21e742645b788 Author: Zixuan Chai Date: Fri Oct 9 00:52:31 2026 +0800 ipv6: defrag: orphan skb before queuing [ Upstream commit 5dfa91a5ec53cfbf907a1fca095ac3ac7a4e94c9 ] IPv4 and nf_conntrack fragment queues orphan skbs before returning -EINPROGRESS, but ip6_frag_queue() leaves the socket association intact. Commit 18685451fc4e ("inet: inet_defrag: prevent sk release while still in use") moved skb_orphan() into ip_frag_queue() and nf_ct_frag6_queue(), but missed ip6_frag_queue(). Without orphaning, inet_frag_reasm_finish() clears fp->sk on frag_list skbs but leaves fp->destructor set to sock_pfree. Freeing the reassembled skb then calls sock_pfree() with a NULL socket. A socket using SOCK_RCU_FREE may also be released while its fragment is queued, leaving a stale socket pointer; this is a second consequence of the same missing orphan. Orphan the skb before returning -EINPROGRESS so the queued fragment no longer retains the socket association or destructor. Fixes: cf7fbe660f2d ("bpf: Add socket assign support") Cc: stable@vger.kernel.org Reported-by: Vega Reviewed-by: Eric Dumazet Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Zixuan Chai Signed-off-by: Ren Wei Link: https://patch.msgid.link/5c396b7011168cd98b9812df4d6bbd00a96048e7.1791008591.git.petalzu987@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 77ef7f1d47d50501f4730075ede2bad23ca84d03 Author: Josef Bacik Date: Wed Oct 7 17:36:04 2026 +0000 net: skbuff: don't BUG() on a bad csum_start in skb_copy_and_csum_dev() [ Upstream commit 56453199d28f0072a8196fba14b2d702632e2219 ] skb_copy_and_csum_dev() copies everything up to the checksum start out of the linear area, and BUG()s if the checksum start is past the end of the linear area. It misses the other direction: a CHECKSUM_PARTIAL skb that has been pulled past its csum_start gives a negative offset, which gets past the check and becomes a ~4GB copy. It also trusts csum_offset when it stores the folded checksum. So far skb_copy_and_csum_bits() BUG()ing on a short skb has covered for that, but once it returns instead, a bad csum_offset would write past the end of the caller's buffer. The function returns void and its callers are drivers copying a frame into a bounce buffer just before handing it to the hardware. There's nothing for them to back out of, so check both ends of csum_start and that the checksum field fits in the frame, and if not, copy the whole frame with skb_copy_bits() without filling in the checksum, with a DEBUG_NET_WARN_ON_ONCE() for debug kernels. The frame goes out with a bad checksum and is dropped by the receiver. If even that copy fails, zero the buffer so the driver doesn't send stale bytes. Signed-off-by: Josef Bacik Cc: stable? The trailers only have Assisted-by: and Signed-off-by:. No Link: https://patch.msgid.link/20261007-b4-skbuff-bug-on-v2-5-b9a5f732895b@toxicpanda.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c5890b947a711f3b47de4bde9919d254e97507b4 Author: Jianyun Gao Date: Sun Oct 11 14:48:39 2026 +0800 dax: fix dax_range_compare_iter() to use correct size and address offset [ Upstream commit a4bfbfb4e98a62b589ac7ca9e73e9612bfe8cab7 ] dax_range_compare_iter() has two bugs in how it calls dax_iomap_direct_access() and uses the returned addresses: 1. The size argument passed to dax_iomap_direct_access() is ALIGN(pos + len, PAGE_SIZE), which is an absolute file offset rather than a length. This causes the underlying dax_direct_access() to request a massively inflated nr_pages via PHYS_PFN(size). 2. The addresses returned by dax_iomap_direct_access() are page-aligned starting addresses, but memcmp() compares from saddr/daddr directly without adding the page-in-page offset of pos1/pos2. When pos1/pos2 are not page-aligned, this compares the wrong data. Fix the size by computing ALIGN(len + offset_in_page(pos), PAGE_SIZE), matching the pattern used in dax_iomap_copy_around(). Fix the address by adding offset_in_page(pos1)/offset_in_page(pos2) to saddr/daddr in the memcmp() call. Fixes: 6f7db3894ae2 ("fsdax: dedup file range to use a compare function") Cc: stable@vger.kernel.org Signed-off-by: Jianyun Gao Reviewed-by: Jan Kara Link: https://patch.msgid.link/20261011064840.1296-1-jianyungao89@gmail.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit d11e3dc0ea241ad2564444b76c585885fa5636e1 Author: Jianyun Gao Date: Mon Oct 12 23:18:57 2026 +0800 dax: Return errors from dax_core_init() [ Upstream commit 4da700e2cadf84a6e858391d5be51d64dcba080f ] dax_core_init() returns success when either the character device number allocation or DAX bus registration fails, even though the error paths have already released the initialized resources. For modular DAX, this allows the module to remain loaded despite failed initialization, leaving subsequent users and module removal to access resources that have already been released. Return the error code from the failed operation so that module loading fails rather than reporting successful initialization after the resources have been released. Fixes: 9567da0b408a ("device-dax: Introduce bus + driver model") Cc: stable@vger.kernel.org Signed-off-by: Jianyun Gao Reviewed-by: Gregory Price (Meta) Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20261012151857.22534-1-jianyungao89@gmail.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit 0677adb0db3cae7489db0ca6b7556d97a7ac1bfa Author: David Carlier Date: Wed Sep 16 20:26:28 2026 +0100 ring-buffer: Take cpus_read_lock() when changing the subbuf order [ Upstream commit 453d0f47b174cac387af48d303c503b84f82212e ] A CPU coming online for the first time gets its per CPU buffer allocated by trace_rb_cpu_prepare(), which then adds it to buffer->cpumask. If that happens while ring_buffer_subbuf_order_set() is running, the CPU shows up after the allocation loop and the install loop walks it with an empty new_pages list, corrupting the buffer. Take cpus_read_lock() as ring_buffer_resize() does. Cc: stable@vger.kernel.org Fixes: f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page") Link: https://patch.msgid.link/20260916192628.274136-1-devnexen@gmail.com Signed-off-by: David Carlier Reviewed-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 448c31ccbdd6096e2773d5d90996d82a7610a8d2 Author: Gyokhan Kochmarla Date: Tue Oct 13 11:48:52 2026 +0000 erofs: use on-disk blkszbits for lz4 max pcluster bound [ Upstream commit 90b7e4a7a16443d9f6807b5c1dde52074d9f74c0 ] z_erofs_load_lz4_config() rejects a valid LZ4 image when the kernel's page size differs from the image's block size. It bounds the on-disk max_pclusterblks with erofs_blknr(sb, Z_EROFS_PCLUSTER_MAX_SIZE), which expands to Z_EROFS_PCLUSTER_MAX_SIZE >> sb->s_blocksize_bits. At the point this runs, sb->s_blocksize_bits still holds PAGE_SHIFT: erofs_fc_fill_super() seeds s_blocksize_bits to PAGE_SHIFT before reading the superblock, and only corrects it down to the on-disk blkszbits after erofs_read_superblock() returns. The LZ4 config is parsed inside erofs_read_superblock(), before that correction, so the bound is computed with the wrong shift. On a 64K-page kernel mounting a 4K-block image (e.g. one built with mkfs.erofs -C 262144 on a 4K-page host), the bound evaluates to 1 MiB >> 16 = 16 blocks instead of the correct 1 MiB >> 12 = 256 blocks. The image's legitimate max_pclusterblks of 64 then fails the check, mount returns -EINVAL, and booting from such an image as the root filesystem panics: erofs (device dm-0): too large lz4 pclusterblks 64 Kernel panic - not syncing: VFS: Unable to mount root fs sbi->blkszbits already holds the on-disk block size at this point, so compute the bound from it directly. This makes the check independent of the host page size and of superblock-parse ordering. commit 3acea5fc3354 ("erofs: avoid hardcoded blocksize for subpage block support") already handled the same ordering hazard for the superblock checksum path by using sbi->blkszbits in erofs_superblock_csum_verify(); the lz4 config path was missed. Fixes: 3acea5fc3354 ("erofs: avoid hardcoded blocksize for subpage block support") Cc: stable@vger.kernel.org Assisted-by: Kirocrew:gpt-5.6-sol Signed-off-by: Gyokhan Kochmarla Reviewed-by: Gao Xiang Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 68c83fb42580b6bbc8dd1abd47c043fc07dbd504 Author: Weibin Liu Date: Tue Oct 27 10:13:40 2026 +0800 spi: amd: validate FIFO usage before executing message [ Upstream commit aed0c7475d6af333fb9b37848ed5e4f92a808ffa ] The RX FIFO bound is checked in the drain loop, after amd_spi_execute_opcode(). A message whose cumulative RX length exceeds AMD_SPI_FIFO_SIZE can therefore issue an SPI transaction before being rejected. Check tx_len + rx_len while walking the message and drop the drain-loop check. This validates the complete message before executing the command. Tested with a user-space replica covering TX, RX and mixed messages at the 70/71-byte boundary. Oversized split-RX messages are now rejected without executing the command. No AMD SPI hardware was available. Assisted-by: LLM Suggested-by: Krishnamoorthi M Fixes: e2f4edfc061e ("spi: amd: fix len==0 underflow and FIFO overflow") Reviewed-by: Guanglei Zhu Signed-off-by: Weibin Liu Link: https://patch.msgid.link/20261027021340.914399-1-liuwb@xiaopeng.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 51faeca5d332e0cf8b930b760c3536aadd171425 Author: Weibin Liu Date: Wed Oct 14 20:39:13 2026 +0800 spi: amd: fix len==0 underflow and FIFO overflow [ Upstream commit e2f4edfc061e493fddde16c4bbe1c4f230f41e4a ] amd_spi_fifo_xfer() unconditionally decrements xfer->len when a tx_buf is present. The SPI core does not reject zero-length transfers, so a transfer submitted through the SPI_IOC_MESSAGE ioctl with len == 0 and a tx_buf makes the u32 len wrap to 0xFFFFFFFF, and the following per-byte loop writes far past the FIFO window. The driver also never checks the cumulative FIFO offset against AMD_SPI_FIFO_SIZE. The core splits each transfer down to the controller's max transfer size but does not bound the total message length, so a message of several transfers whose total exceeds the FIFO overflows it with out-of-bounds MMIO writes (tx) and reads (rx). Skip zero-length transfers and reject any transfer that would run past the end of the FIFO window. Tested with a user-space replica of the fifo_xfer length arithmetic (ASAN build): a zero-length transfer with tx_buf makes len-- wrap to 0xffffffff, and skipping zero-length transfers avoids the wrap. No AMD SPI hardware was available, so the FIFO bound check was verified by inspection against AMD_SPI_FIFO_SIZE. Fixes: bbb336f39efc ("spi: spi-amd: Add AMD SPI controller driver support") Cc: stable@vger.kernel.org # 5.8+ Reviewed-by: Guanglei Zhu Signed-off-by: Weibin Liu Link: https://patch.msgid.link/20261014-spi-amd-fifo-fix-v1-1-9fec9ab753e8@xiaopeng.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7fdfd92092179b3670c401c9083660d308e7d717 Author: Weibin Liu Date: Thu Oct 15 10:16:12 2026 +0800 spi: bcm-qspi: reject oversized dummy bytes in mspi exec_mem_op [ Upstream commit 9e44f0df3fff215d9033089e85980048c3ac132a ] bcm_qspi_mspi_exec_mem_op() builds a local command buffer cmd[6] holding one opcode byte, up to four address bytes and one spare byte, and sets t[0].len = op->addr.nbytes + op->dummy.nbytes + 1. bcm_qspi_exec_mem_op() only validates op->addr.nbytes <= 4 and never bounds op->dummy.nbytes, which spi_mem_check_op() also leaves unrestricted. With addr.nbytes = 4 and dummy.nbytes >= 2 the length becomes 7 or more, so write_to_hw() reads past cmd[] on the kernel stack and pushes the leaked bytes into the hardware TXRAM. Reject operations whose dummy phase does not fit the remaining byte of cmd[] by requiring op->dummy.nbytes <= 1, so such transfers fall back to the generic SPI path instead of overrunning the buffer. Reviewed-by: Guanglei Zhu Fixes: 5f195ee7d830c ("spi: bcm-qspi: Implement the spi_mem interface") Cc: stable@vger.kernel.org # 4.18+ Signed-off-by: Weibin Liu Link: https://patch.msgid.link/20261015-bcm-qspi-dummy-bytes-v1-1-c319da3c2497@xiaopeng.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0e61b9d6aacd4f87b81c1d8a5a982400e5543bc9 Author: Vladyslav Tymoshchuk Date: Wed Oct 14 19:27:01 2026 +0300 ASoC: qcom: q6apm: reset the hw pointer with the fragment queue [ Upstream commit 0337b8129cf676b8eb767b2a1f312955760a5460 ] On every prepare in queue mode, q6apm_dai_prepare() frees and allocates the fragments again, and q6apm_alloc_fragments() resets dsp_buf, so the first buffer queued after it is the first one of the ring. The hw pointer that q6apm_dai_pointer() reports is left as it was. q6apm-dai used to keep its own position and cleared it in prepare. Since commit a93dad6f4e6a ("ASoC: q6apm-dai: make use of q6apm_get_hw_pointer") the position comes from the hw pointer, so a stream that is prepared again, e.g. to recover from an xrun, reports the position of the previous run until the DSP returns its first buffer, while ALSA has reset its own pointer to 0. Reset the hw pointer together with dsp_buf. Fixes: a93dad6f4e6a ("ASoC: q6apm-dai: make use of q6apm_get_hw_pointer") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Vladyslav Tymoshchuk Reviewed-by: Srinivas Kandagatla Tested-by: Srinivas Kandagatla Link: https://patch.msgid.link/20261014162703.10172-3-tvlad744@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cf662773b6bc3dd0c2807630d153e0b9332fa21e Author: Radiy Zhambakiev Date: Fri Oct 2 11:36:54 2026 +0000 mfd: tps65217: Use devres for IRQ domain and wake teardown [ Upstream commit cffd44d2d89524e2dda6adc7b0dd59363be1c8e6 ] Removing the parent device used to tear the IRQ domain down in tps65217_remove() before the MFD children are unbound: the i2c core only releases the parent's devres after the remove callback returns, whereas devm_mfd_add_devices() registered its own devres action which unbinds the children. Children that requested interrupts from the domain (e.g. tps65217-charger) therefore call free_irq() on virtual IRQs whose descriptors have already been disposed. With CONFIG_SPARSE_IRQ free_irq() then returns early without stopping the threaded handler, leaking the irqaction, the IRQ kthread and a module reference. Register the domain teardown as a devres action right after the domain is created instead. Devres actions are released in reverse order of registration, so the MFD children release their IRQs first, then the parent interrupt is freed and its thread stopped, and only then is the domain torn down. The same ordering covers probe failure, which no longer needs manual cleanup, and the remove callback can be dropped entirely. Balance the enable_irq_wake() in tps65217_irq_init() by registering disable_irq_wake() as a devres action as well. Only do so when enabling actually succeeded, since the parent chip may not support setting wake-up. Fixes: 6556bdacf646fcaa ("mfd: tps65217: Add support for IRQs") Cc: stable@vger.kernel.org Signed-off-by: Radiy Zhambakiev Link: https://patch.msgid.link/20261002113624.178588-4-r.zhambakiev@prosoftsystems.ru Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 55f3155a2d63916817c282437489b44502696433 Author: Radiy Zhambakiev Date: Fri Oct 2 11:36:53 2026 +0000 mfd: tps65217: Check return value when masking interrupt sources [ Upstream commit 66ed12c1e5a986bee1dc63f9bd9c7f068138a69a ] tps65217_irq_init() ignores the error returned by tps65217_set_bits() when masking all interrupt sources. A failed register write leaves the driver's software mask out of sync with the hardware and may result in spurious interrupts. Check the return value and propagate the error to the caller. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 6556bdacf646fcaa ("mfd: tps65217: Add support for IRQs") Cc: stable@vger.kernel.org Signed-off-by: Radiy Zhambakiev Link: https://patch.msgid.link/20261002113624.178588-3-r.zhambakiev@prosoftsystems.ru Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit d7de4e8da81f6185e45bd318aa20fa0037debba4 Author: Radiy Zhambakiev Date: Fri Oct 2 11:36:52 2026 +0000 mfd: tps65217: Fix NULL pointer dereference on IRQ init failure [ Upstream commit 0473a5b0663663b75573bf284beb77459e07c461 ] tps65217_probe() ignores the return value of tps65217_irq_init(), so when the irq domain creation fails the probe still completes and the driver ends up bound with a NULL tps->irq_domain. Unloading the module then makes tps65217_remove() call irq_domain_remove() on the NULL pointer and oops the kernel. On top of that, irq_find_mapping() may fall back to the default irq domain and dispose of mappings that belong to other interrupt controllers. Check the return value and abort the probe on failure so the error is reported and no inconsistent state is left for removal. Fixes: 6556bdacf646fcaa ("mfd: tps65217: Add support for IRQs") Cc: stable@vger.kernel.org Signed-off-by: Radiy Zhambakiev Reviewed-by: Andreas Kemnade Link: https://patch.msgid.link/20261002113624.178588-2-r.zhambakiev@prosoftsystems.ru Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 5475d9ec0ad89d69356a7084dad612c4d61480be Author: Weibin Liu Date: Thu Oct 15 10:10:12 2026 +0800 spi: npcm-fiu: limit UMA data_size to the 16-byte staging buffer [ Upstream commit f0be928a41384ea93c876364f360779f70359249 ] npcm_fiu_uma_read() and npcm_fiu_uma_write() use a 16-byte on-stack staging buffer (u32 data_reg[4]) and move data_size bytes to or from it. data_size comes straight from op->data.nbytes, which is supplied by the SPI MEM operation and is not bounded by the driver: npcm_fiu_exec_op() only validates op->addr.nbytes, and no adjust_op_size callback truncates the transfer to the controller FIFO size. A SPI MEM operation with addr.nbytes == 0 and data.nbytes > 16 therefore overflows data_reg[] on the kernel stack (write path) or reads past it (read path), corrupting the stack. Reject data_size larger than the staging buffer in both UMA helpers by returning -EOPNOTSUPP, so spi_mem falls back to the generic SPI message path. The chunked path in npcm_fiu_manualwrite() always passes at most CHUNK_SIZE bytes, so it is unaffected. Fixes: ace55c411b11 ("spi: npcm-fiu: add NPCM FIU controller driver") Cc: stable@vger.kernel.org # 5.4+ Reviewed-by: Guanglei Zhu Signed-off-by: Weibin Liu Link: https://patch.msgid.link/20261015-npcm-fiu-uma-datasize-v1-1-7dee91cadee6@xiaopeng.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 872d4852c71bd605bcaf1c38501485777419ef92 Author: Marc Zyngier Date: Thu Oct 15 11:05:36 2026 +0100 KVM: arm64: Turn vcpu->arch.pause into a counter [ Upstream commit e64309198eda29415a95113def92aa40196cd422 ] We have situations where we can call kvm_arm_halt_guest() without holding config_lock, which means that halt and resume can overlap in funny ways when called from separate contexts, and result in situations where a vcpu is resumed while other parts of KVM assume it is halted. Consequences are left to the imagination of the reader. Fix this sorry situation by turning kvm_vcpu_arch::pause into an atomic counter, which makes the races described above harmless. Fixes: 3b92830ad41b2 ("KVM: arm/arm64: implement kvm_arm_[halt,resume]_guest") Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261015100539.1011760-5-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 6a01c65cdde47fe5a1906e3b7868a478cb823199 Author: Marc Zyngier Date: Thu Oct 15 11:05:34 2026 +0100 KVM: arm64: Move OUTSIDE_GUEST_MODE publication past context being saved [ Upstream commit 1d4ce2901f1e25b06d447c0b02d105d6dd3550d8 ] OUTSIDE_GUEST_MODE indicates to the rest of KVM that the vcpu has exited. So far, this is set as soon as we return from the notional hypervisor (which with VHE is just a function call away). However, code that uses OUTSIDE_GUEST_MODE as a synchronisation point relies on the vcpu state to have been written back to the in-memory structures. Clearly, this is not what is happening. Move the publication of OUTSIDE_GUEST_MODE to the point where the state is actually written, and give this write release semantics to ensure the correct ordering. Cc: stable@vger.kernel.org Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Link: https://patch.msgid.link/20261015100539.1011760-3-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 6f04cc84de965f48c98cea3eb159fa67d2e58389 Author: Ard Biesheuvel Date: Mon Oct 12 14:06:12 2026 +0200 efi/libstub: Don't replace an existing LINUX_EFI_MEMRESERVE table [ Upstream commit aaf3ed0f46298e18ec8bc477cf0a37478e41f2ea ] The LINUX_EFI_MEMRESERVE table is the root of a linked list of memory reservations that need to persist across kexec, such as the GICv3 LPI pending and property tables, which cannot be moved once the redistributors have been enabled. Each kernel adds its own reservations to the list that it finds via the EFI configuration table, and honours the ones made by its predecessors. The EFI stub installs a new, empty table unconditionally, replacing any existing one. This is fine on a cold boot, but not if the stub is being executed by a loader that passes on the configuration tables of an earlier kernel, e.g., a kexec loader that runs the incoming kernel's EFI stub, as the reservations made by earlier kernels would be lost. So leave an existing table in place, and only install a new one if none exists yet. Cc: Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit fd745ddad8f94cc9b28c4ac3a86ec9b803ec2996 Author: Weibin Liu Date: Wed Oct 14 22:18:50 2026 +0800 spi: jcore: fix divide-by-zero when speed_hz is zero [ Upstream commit 7db773075501248893c22b11bedc6745d6d0be45 ] jcore_spi_baudrate() computes hw->clock_freq / 2 / speed without validating speed. The SPI core fills transfer.speed_hz from spi->max_speed_hz when it is zero, and jcore_spi_probe() never sets host->max_speed_hz, so the clamp in __spi_setup() is skipped. A spi_device created via the sysfs new_device interface (or a DT node without spi-max-frequency) therefore has max_speed_hz == 0, and any SPI_IOC_MESSAGE transfer reaches jcore_spi_baudrate() with speed == 0, causing a division by zero and a kernel panic. Clamp speed to a minimum of 1 Hz before the division so the divisor is never zero. The computed divider then truncates to the register field width and the transfer simply runs at the slowest supported rate. Verified by inspection of the __spi_setup() clamp and __spi_validate()'s speed_hz handling; the division-by-zero path requires the J-Core controller, which was not available. Reviewed-by: Guanglei Zhu Fixes: 2cb1b3b3ac0a ("spi: add driver for J-Core SPI controller") Cc: stable@vger.kernel.org # 4.9+ Signed-off-by: Weibin Liu Link: https://patch.msgid.link/20261014-spi-jcore-divzero-v1-1-a8205d30f2d1@xiaopeng.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a92d000749f47f2ff334236c37f1d7364819df52 Author: Tal Zussman Date: Wed Oct 14 20:36:43 2026 -0400 gfs2: fix the escaped block copy in gfs2_before_commit() [ Upstream commit 1a4aeb6d6a08af1a2e2c52c84170561625819377 ] Commit d68d0c6c3fc7 ("gfs2: Use memcpy_{from,to}_page where appropriate") made the escaped buffer copy read from the mempool page it had just allocated instead of from the buffer, so the block written to the log is whatever the pool page last held. If the journal is replayed after a crash, the block is restored from that and the file's data is corrupted. Only escaped buffers are affected: jdata blocks whose first four bytes match GFS2_MAGIC. Copy from the buffer's folio instead. Fixes: d68d0c6c3fc7 ("gfs2: Use memcpy_{from,to}_page where appropriate") Cc: stable@vger.kernel.org Signed-off-by: Tal Zussman Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit e0a801fef4a65e18fd7afd53832577e9814df3eb Author: Takashi Iwai Date: Thu Oct 15 09:54:38 2026 +0200 ALSA: ump: Correct return size of fill_rpn() [ Upstream commit 85e8c5f933ee3dbc9d061e121237797e9fa05315 ] The RPN/NRPN conversion in fill_rpn() is supposed to return the number of bytes of the resultant UMP packet, but it returns boolean values. This would result in the incorrect ump_bytes in the converter, which will confuse stream processing. Correct to the right value 8 as a MIDI 2.0 UMP packet. Fixes: e6ce8a28c768 ("ALSA: ump: Transmit RPN/NRPN message at each MSB/LSB data reception") Cc: Link: https://patch.msgid.link/20261015075439.50088-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit cd91bf98ceb0daf9ed8ddb45af1ad66f6a50f9c7 Author: Wentao Liang Date: Wed Sep 16 19:03:49 2026 +0000 irqchip/mchp-eic: Fix clock reference leak in mchp_eic_probe() [ Upstream commit af9c707eb065a7d48eb92dc15acdb4346acf5db0 ] of_clk_get_by_name() returns the clock with an elevated reference count that mchp_eic_probe() keeps for the lifetime of the driver, but none of the probe error paths drops it, so the reference is leaked whenever probe fails after the clock has been obtained. Put the reference in the error cleanup. The clk_prepare_enable() failure path must jump there directly as it cannot call clk_disable_unprepare() on a clock that was never enabled. Fixes: 00fa3461c86d ("irqchip/mchp-eic: Add support for the Microchip EIC") Signed-off-by: Wentao Liang Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260916190349.2094401-1-vulab@iscas.ac.cn Signed-off-by: Sasha Levin commit 75695e69abea933d2590cbf6d914233f2516e62f Author: Guangshuo Li Date: Mon Sep 14 21:42:11 2026 +0800 irqchip/imx-intmux: Fix runtime PM teardown on remove [ Upstream commit b167c1a30e9e020e4c5e102c7a555943742c024b ] imx_intmux_probe() enables the IPG clock and then drops its runtime PM reference with pm_runtime_put(). With CONFIG_PM enabled, the runtime suspend callback disables the IPG clock. With CONFIG_PM disabled, the clock remains enabled after probe. imx_intmux_remove() accesses the CHANIER registers without first making sure that the device is runtime active. The device may therefore be runtime suspended with the IPG clock disabled when these registers are accessed. In addition, the remove path only calls pm_runtime_disable() and does not balance the clock enable when CONFIG_PM is disabled. Resume the device and acquire a runtime PM reference before accessing the registers. If resume fails, skip the register accesses but still tear down the chained handlers and IRQ domains. Disable runtime PM afterwards, drop the acquired reference without triggering another runtime suspend, and explicitly disable the IPG clock. This keeps the clock enabled while the hardware registers are accessed and balances the clk_prepare_enable() performed during probe for both CONFIG_PM configurations. This issue was found by manual code inspection. Fixes: bb403111e017 ("irqchip/imx-intmux: Implement intmux runtime power management") Signed-off-by: Guangshuo Li Signed-off-by: Thomas Gleixner Reviewed-by: Frank Li Reviewed-by: Radu Rendec Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260914134211.1734163-1-lgs201920130244@gmail.com Signed-off-by: Sasha Levin commit 95312e7299fa1bc472014c0dcacd965e1d7da411 Author: Fuad Tabba Date: Tue Sep 8 15:26:31 2026 +0100 irqchip/gic-v3-its: Don't clamp nvecs to zero when id_bits is 32 [ Upstream commit 5a9d62555e7164ec79a5fe70153d79cf1fdfd614 ] GITS_TYPER_IDBITS is five bits, so id_bits reaches 32 and min_t(unsigned int, ...) truncates BIT(32) to 0. nvecs becomes 0, its_lpi_alloc() rejects that, and its_msi_prepare() returns -ENOMEM. On 32-bit ARM the shift is undefined instead. The clamp is correct for every value below the maximum, so only that one value is affected. Fixes: ce9e40a9a5e5c ("irqchip/gic-v3-its: Limit number of per-device MSIs to the range the ITS supports") Signed-off-by: Fuad Tabba Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Reviewed-by: Zenghui Yu (Huawei) Reviewed-by: Radu Rendec Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260908142632.2795308-3-fuad.tabba@linux.dev Signed-off-by: Sasha Levin commit 3377a6a9ebb921829767524bf801b720c822b51d Author: Ahsan Atta Date: Tue Oct 6 16:06:48 2026 +0100 crypto: qat - fix use of destroyed vf2pf_lock on VF restart [ Upstream commit 4921634ac0a9a65aaa5e41308aabda3d3f562ee3 ] adf_dev_stop_async() sends the RESTARTING_COMPLETE message after adf_dev_down() has returned, but adf_dev_down() already destroyed the lock that message takes. Both run in sequence in the same worker, so every PF restart locks a destroyed mutex. With CONFIG_DEBUG_MUTEXES on a dh895xcc with 32 host-bound VFs this trips on the first PF reset: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: kernel/locking/mutex.c:159 at mutex_lock+0x171/0x1c0 Workqueue: adf_vf_stop_wq adf_dev_stop_async [intel_qat] Call Trace: adf_gen2_pfvf_send+0x210/0x530 [intel_qat] adf_vf2pf_notify_restart_complete+0x55/0x80 [intel_qat] adf_dev_stop_async+0xdb/0x140 [intel_qat] The notification cannot move before adf_dev_down(): the PF waits for it before its own reset and the VF must tear down its rings first. vf2pf_lock protects the VF2PF CSR and is unrelated to the PF2VF bottom half it is initialised alongside. Tie its lifetime to the accel device, next to state_lock in adf_devmgr_add_dev()/adf_devmgr_rm_dev(), so it stays valid for messages sent outside the device up/down cycle. It is only touched for VFs, which set is_vf before adf_devmgr_add_dev() and keep it set until adf_devmgr_rm_dev(). Fixes: 6f1b5236348f ("crypto: qat - fix recovery flow for VFs") Cc: stable@vger.kernel.org Signed-off-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c8bb6220a64bc19451412190f48da637f8000562 Author: Ahsan Atta Date: Tue Oct 6 16:06:47 2026 +0100 crypto: qat - initialise state_lock on every path in adf_devmgr_add_dev() [ Upstream commit 4ad7c1bd5f3dcd3fd6efbb068d6ee2a68dddfece ] state_lock is initialised at the end of adf_devmgr_add_dev(), but the VF on host path whose id mapping already exists returns earlier via 'goto unlock'. That mapping outlives the VF, so this path is taken every time a VF is recreated on a BDF that already hosted one, e.g.: echo 0 > sriov_numvfs echo 32 > sriov_numvfs accel_dev is freshly allocated on each probe, so state_lock is left zeroed and adf_dev_up() takes an uninitialised mutex. With CONFIG_DEBUG_MUTEXES this is reported on a dh895xcc with 32 host-bound VFs: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: kernel/locking/mutex.c:159 at mutex_lock+0x171/0x1c0 Call Trace: adf_dev_up+0x27/0xe0 [intel_qat] adf_probe+0x700/0xa80 [qat_dh895xccvf] local_pci_probe+0xd5/0x190 The same happens on teardown when adf_dev_down() locks it again. Initialise the lock next to the other per-device state, before the tables are updated, so it is done on every path. Fixes: 1bdc85550a2b ("crypto: qat - fix concurrency issue when device state changes") Cc: stable@vger.kernel.org Signed-off-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c5c57c35e91cef1bf131c7187975ee2bee192a70 Author: Andrea Parri Date: Fri Sep 25 18:11:39 2026 +0200 iommufd: Reject a zero-length dirty bitmap request [ Upstream commit f6b3fd8f573e801066c21b2aec3d2e949e61e48e ] iommufd_check_iova_range() subtracts one from bitmap->length before it checks the length, so a zero-length request wraps to SIZE_MAX. With iova = 0 the wrapped value passes the overflow and alignment checks, and the request reaches iova_bitmap_alloc() with length 0. iova_bitmap_alloc() then sizes the bitmap from a length - 1 of SIZE_MAX, so mapped_total_index is effectively unbounded. The scan uses last_iova = ULONG_MAX, which spans the whole IOAS when an area is mapped at IOVA 0. Reject a zero length before the subtraction. Fixes: b9a60d6f850e ("iommufd: Add IOMMU_HWPT_GET_DIRTY_BITMAP") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Andrea Parri Link: https://patch.msgid.link/20260925161142.189813-4-parri.andrea@gmail.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 329b869bc4d4e003fd558d27be2ee58744ccd187 Author: Wentao Liang Date: Thu Sep 17 13:24:59 2026 +0000 PCI: xilinx-xdma: Fix device node reference leak in xilinx_pl_dma_pcie_init_irq_domain() [ Upstream commit 73d3d81832708137ba6332fc011663feaf97deee ] xilinx_pl_dma_pcie_init_irq_domain() takes a reference to the PCIe interrupt-controller child node with of_get_child_by_name(), but the error paths after the two irq_domain_create_linear() calls and after xilinx_pl_dma_pcie_init_msi_irq_domain() return directly without dropping it. irq_domain_create_linear() gets its own reference on the fwnode, so the domains do not consume the caller's one. Add an err_put_node label that drops the reference before returning. Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver") Signed-off-by: Wentao Liang Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260917132459.2153240-1-vulab@iscas.ac.cn Signed-off-by: Sasha Levin commit 2bd4d21066ef2c3daff713b36e3c57b10ebc6e43 Author: Hui Su Date: Tue Oct 13 12:42:35 2026 +0900 cpufreq: schedutil: Serialize sugov_start() against rate limit updates [ Upstream commit ce390caf5541c493c9061e7a2d98a463e66b736a ] The current value of sg_policy->tunables->rate_limit_us is used in sugov_start() without locking to update sg_policy->freq_update_delay_ns, so if rate_limit_us_store() runs in parallel with it, the rate limit update may go unnoticed and the new freq_update_delay_ns value may be stale until the rate limit is updated again. To avoid that, acquire the update_lock mutex of the rate limit sysfs attribute, that is held by rate_limit_us_store() during rate limit updates, around the freq_update_delay_ns in sugov_start(). Fixes: 9bdcb44e391d ("cpufreq: schedutil: New governor based on scheduler utilization data") Reviewed-by: Zhongqiu Han Signed-off-by: Hui Su Cc: All applicable [ rjw: Subject adjustment, new changelog, edits of the new comment ] [ rjw: Add empty code line after guard()() ] Link: https://patch.msgid.link/20261013034235.2678177-1-sh_def@163.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit abf86216bdc04cf2917c516ef15532510252a25b Author: Siwei Zhang Date: Tue Oct 13 11:36:36 2026 -0400 Bluetooth: L2CAP: Use default TxWindow for zero socket option [ Upstream commit 226fa3b676cbf2236f803bccd347462433ffc2c8 ] L2CAP_OPTIONS accepts a txwin_size of zero and stores it in tx_win. The zero is then sent to the peer in our configuration request, and if the channel ends up in ERTM mode it is passed to l2cap_seq_list_init(). Use the default TxWindow instead, as the mode can still be changed to ERTM during configuration. Fixes: 14b5aa71ec50 ("Bluetooth: Add sockopt configuration for txWindow on L2CAP") Cc: stable@vger.kernel.org Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 774badce7fd0afd8897ba1631b5aa7a259443fbf Author: Siwei Zhang Date: Tue Oct 13 11:36:35 2026 -0400 Bluetooth: L2CAP: Reject invalid TxWindow in configuration requests [ Upstream commit c5ebb0245fe927cf5fa33510a9cb2799c4a2dd01 ] A peer can send an ERTM RFC option with a TxWindow of zero, which is out of spec. It is stored in remote_tx_win unchanged and later passed to l2cap_seq_list_init(), where roundup_pow_of_two(0) is undefined. On some architectures this results in a ZERO_SIZE_PTR list and a remote kernel oops. A TxWindow above 63 is out of spec as well. With 6-bit sequence numbers we would then send more unacknowledged frames than the sequence space can tell apart. Reply with L2CAP_CONF_UNACCEPT and propose the default TxWindow instead of accepting the value, so remote_tx_win always stays within 1 to 63. Keep the parameters of an earlier request then, and do not treat the request as done because an earlier one was. Also refuse a zero size in l2cap_seq_list_init(), so any other path that reaches it with a zero TxWindow fails the channel instead of the kernel. Fixes: f2fcfcd67025 ("Bluetooth: Add configuration support for ERTM and Streaming mode") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 5ffc623798d65fa972d3bdde24845421e5ece957 Author: Siwei Zhang Date: Tue Oct 13 11:36:33 2026 -0400 Bluetooth: L2CAP: Reject mode changes on connected channels [ Upstream commit c1398cf11b31a94c27ed810ba69515e0df5ce379 ] A peer can send a configuration response with an RFC option for another mode to a connected channel, for example to switch it from Streaming to ERTM mode. l2cap_parse_conf_rsp() then changes chan->mode, but l2cap_ertm_init() is not called again, so the ERTM sequence lists are never allocated. The next out-of-sequence I-frame makes l2cap_seq_list_clear() write through the NULL srej_list.list. Refuse the channel when a response tries to change the mode of a connected channel. Fixes: f2fcfcd67025 ("Bluetooth: Add configuration support for ERTM and Streaming mode") Cc: stable@vger.kernel.org Closes: https://sashiko.dev/#/patchset/20261007144717.3832330-1-oss%40fourdim.xyz Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 31e1225c136fbc3606230732926c48b67680b270 Author: Bui Viet Dung Date: Thu Oct 8 12:01:40 2026 +0700 Bluetooth: hci_debugfs: Pin module for debugfs file operations [ Upstream commit 2a3e2287877b1ee40ffb80b7d769b633866533f3 ] An open debugfs file retains its file_operations pointer in the debugfs proxy state. However, the file_operations defined in hci_debugfs.c (use_debug_keys_fops, sc_only_mode_fops, ssp_debug_mode_fops, force_bredr_smp_fops, force_static_address_fops, force_no_mitm_fops, dut_mode_fops, vendor_diag_fops, and the DEFINE_QUIRK_ATTRIBUTE macro) have no .owner set to THIS_MODULE. As a result, full_proxy_open_regular() calls fops_get() which succeeds without taking a reference to the bluetooth module. When a userspace process opens any of these debugfs files, a subsequent controller removal and module unload (rmmod bluetooth) can succeed while the file descriptor remains open. When the userspace process subsequently closes the descriptor, full_proxy_release() accesses the already unmapped file_operations structure, triggering a kernel oops in full_proxy_release(): BUG: unable to handle page fault for address: fffffbfff8056f03 #PF: supervisor read access in kernel mode Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:full_proxy_release+0x8e/0x140 Call Trace: __fput+0x39f/0xa60 fput_close_sync+0xff/0x200 __x64_sys_close+0x8c/0xf0 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The issue was discovered via manual code audit of net/bluetooth/hci_debugfs.c and verified on a Linux 7.3-rc6 test VM with CONFIG_BT=m. Set .owner = THIS_MODULE on all debugfs file_operations tables in hci_debugfs.c so that debugfs keeps the module loaded until close has finished. Fixes: 0886aea6acd2 ("Bluetooth: Expose debug keys usage setting via debugfs") Cc: stable@vger.kernel.org Signed-off-by: Bui Viet Dung Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 616281cd2343b3b90a6c2466d88d7b7bbe91a155 Author: Bui Viet Dung Date: Thu Oct 8 12:11:29 2026 +0700 Bluetooth: 6lowpan: Pin module for 6lowpan_control debugfs file [ Upstream commit 8368f0c2cde48c09ed70644059f24172b0c59f52 ] An open debugfs file retains lowpan_control_fops in the debugfs proxy state. However, lowpan_control_fops has no .owner set to THIS_MODULE. As a result, full_proxy_open_regular() calls fops_get() which succeeds without taking a reference to the bluetooth_6lowpan module. With CONFIG_BT_6LOWPAN=m, a userspace process can keep the debugfs file descriptor for 6lowpan_control open across module unload (delete_module / rmmod bluetooth_6lowpan). When the process subsequently closes the file descriptor, full_proxy_release() accesses the already freed and unmapped lowpan_control_fops table, causing a kernel page fault or oops. The issue was discovered via manual code audit of net/bluetooth/6lowpan.c. Set .owner = THIS_MODULE on lowpan_control_fops so that debugfs pins the module until all open file descriptors have finished. Fixes: 6b8d4a6a0314 ("Bluetooth: 6LoWPAN: Use connected oriented channel instead of fixed one") Cc: stable@vger.kernel.org Signed-off-by: Bui Viet Dung Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a31a0764d6a049a6f1a59c329e6f8cfb84900f17 Author: Nikolaj Klitlund Børty Date: Sat Sep 5 14:05:12 2026 +0200 Bluetooth: btusb: Add device ID for Realtek RTL8761BUE (StarTech AV53C1) [ Upstream commit 1430308fc9d47a801a305700cd444b1a0051d14a ] Add the USB ID 0x14b0:0x047a for the StarTech AV53C1-USB-BLUETOOTH adapter, a Realtek RTL8761BUE based Bluetooth 5.3 dongle. Without this entry btusb treats the device as a generic Bluetooth adapter and never loads the Realtek firmware, leaving the controller on its ROM firmware. In that state it advertises and scans actively, but never reports advertisements during passive scanning. LE connections initiated by the kernel wait for a passive-scan report before issuing LE Create Connection, so connecting and pairing from BlueZ time out without any error from the controller. The same product is also sold with the ID 0x2c0a:0x8761, which is already supported. lsusb -v output for the device: Bus 001 Device 010: ID 14b0:047a StarTech.com Ltd. Bluetooth Radio Device Descriptor: bcdUSB 1.10 bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 1 Bluetooth idVendor 0x14b0 StarTech.com Ltd. idProduct 0x047a bcdDevice 2.00 iManufacturer 1 Realtek iProduct 2 Bluetooth Radio iSerial 3 00E04C239987 bNumInterfaces 2 Interface Descriptor: bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth Cc: stable@vger.kernel.org Signed-off-by: Nikolaj Klitlund Børty Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 21d11290049549ab8f0fe93124d2067627d1069d Author: Stian Halseth Date: Wed Oct 7 15:13:04 2026 +0200 PCI: Set supported_speeds in set_pcie_port_type() [ Upstream commit 926767a9be8866d26cc27ca46c46c03d921e2193 ] sparc64 and powerpc create PCI devices from the device tree in of_create_pci_dev(), which calls set_pcie_port_type() but not pci_setup_device(). Since d2bd39c0456b, supported_speeds is only set in pci_setup_device(), so it stays 0 for these devices. pcie_get_speed_cap() then returns PCI_SPEED_UNKNOWN, the sysfs 'max_link_speed' attribute reads "Unknown", and the failed link retraining quirk passes PCI_SPEED_UNKNOWN to pcie_set_target_speed(), which warns on a SPARC T7-1: WARNING: drivers/pci/pcie/bwctrl.c:125 at pcie_set_target_speed+0x284/0x2e0 Set supported_speeds in set_pcie_port_type(), which all three paths call. Fixes: d2bd39c0456b ("PCI: Store all PCIe Supported Link Speeds") Closes: https://github.com/sparclinux/issues/issues/109 Signed-off-by: Stian Halseth Signed-off-by: Bjorn Helgaas Tested-by: Tony Rodriguez Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261007131304.309511-1-stian@itx.no Signed-off-by: Sasha Levin commit 5928e61bc92140d235fe531b5d9554397b90bd84 Author: Karl Mehltretter Date: Thu Aug 13 04:02:36 2026 +0100 ARM: 9491/1: alignment: restore uaccess state on emulation fault [ Upstream commit 80dafbcb705cead6d25cb821cf29c47da8860c8c ] The alignment handlers enable access to user memory while emulating unaligned instructions. If a checked access faults, its exception table fixup jumps to the handler's fault label and bypasses uaccess_restore(). This leaves DOMAIN_USER as DOMAIN_CLIENT with SW domain PAN, or leaves TTBR0 page table walks enabled with TTBR0 PAN, while the fault is handled. An ARM926 QEMU test using LDMIA across an unmapped page boundary reports DOMAIN_USER=1 at TYPE_FAULT before this change and DOMAIN_USER=0 after it. SW domain PAN is the default on ARMv5, ARMv6, and non-LPAE ARMv7 builds. Keep the saved uaccess state at function scope and track whether it was saved. Restore it at the fault label only when needed. Paths that did not enable user access continue to skip the restore. Assisted-by: Codex:gpt-5.6-sol Fixes: 274e91b81ed2 ("ARM: alignment: fix alignment handling for uaccess changes") Cc: stable@vger.kernel.org Reviewed-by: Linus Walleij Signed-off-by: Karl Mehltretter Signed-off-by: Russell King Signed-off-by: Sasha Levin commit a900239c6dd187f838c81549f0b47d659846cd9e Author: Karl Mehltretter Date: Sat Aug 8 22:08:26 2026 +0100 ARM: 9488/1: smp: set current pointer in assembly before jumping into C [ Upstream commit f6e551e7d515579b952422c93415470fb672d848 ] With CONFIG_KCOV_INSTRUMENT_ALL=y, secondary CPUs fail to come online on ARMv6K/ARMv7 SMP: CPU1: failed to boot: -38 The compiler inserts a call to __sanitizer_cov_trace_pc() at the entry of secondary_start_kernel(), before set_current(task). The KCOV hook dereferences current while TPIDRURO is still uninitialized, causing a data abort before cpu_init() has installed the exception stacks. The secondary CPU consequently never completes startup. Initialize current in the secondary assembly handoff, as __mmap_switched already does for the boot CPU. With current set in assembly, the set_current() call in secondary_start_kernel() is redundant. Drop it together with the function and the task argument. The hotplug resuscitate path in arch_cpu_idle_dead() needs no hand-off either, as smp_ops.cpu_die() can only return if the CPU kept its register state, TPIDRURO included. Assisted-by: Claude:claude-fable-5 Fixes: 50596b7559bf ("ARM: smp: Store current pointer in TPIDRURO register if available") Cc: stable@vger.kernel.org Signed-off-by: Karl Mehltretter Reviewed-by: Ard Biesheuvel Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 8e19b4b77d279d7b9e3a0c543b6f54a03ce4521a Author: Weibin Liu Date: Tue Sep 29 16:11:45 2026 +0800 spi: cadence-xspi: fix stack buffer overflow in the Marvell b0 path [ Upstream commit ef9690269999ddf9b204731baca1bd6b7aea1aa7 ] transfer_one_message_b0() falls back to a 10-byte stack buffer for transfers which carry no TX data and points both in_buffer and out_buffer into it. With a transfer longer than 10 bytes the SDMA branch of the loop moves up to MRVL_XFER_QWORD_COUNT * MRVL_XFER_QWORD_BYTECOUNT (256) bytes through those pointers and then advances them by the same amount, so both directions overflow the scratch buffer: a read transaction copies SDMA data past the end of the buffer, a write transaction sends stack contents from beyond it to the SPI bus. Size the scratch buffer for the largest chunk the loop can request, keep the buffer pointers pinned to it when the message does not carry the corresponding TX or RX data, and only advance the pointers which reference real transfer buffers. Also zero-initialize the scratch buffer so that padding bytes sent for TX-less transfers no longer leak uninitialized stack contents. Fixes: 5cb7651f78e1 ("Marvell HW overlay support for Cadence xSPI") Cc: stable@vger.kernel.org # 6.11+ Signed-off-by: Weibin Liu Link: https://patch.msgid.link/20260929081146.41041-3-liuwb@xiaopeng.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7b889c448fa5777bdc10f2bcf72a4b1d6caa3ed9 Author: Martin Belanger Date: Wed Oct 14 08:02:57 2026 -0400 nvme: make the DH-HMAC-CHAP secret attributes readable by root only [ Upstream commit bbca7c312ab25efd0024eb87545c51a76ab2ea39 ] The dhchap_secret and dhchap_ctrl_secret sysfs attributes have mode 0644. Their show functions return the secret, so any local user can read the DH-HMAC-CHAP secrets of a connected controller. Define them with DEVICE_ATTR_ADMIN_RW(), which sets mode 0600. The macro takes the show and store functions from the attribute name, so rename them. Writing the attributes was already limited to root and is not changed. Fixes: f50fff73d620 ("nvme: implement In-Band authentication") Cc: stable@vger.kernel.org Reviewed-by: Daniel Wagner Assisted-by: LLM Signed-off-by: Martin Belanger Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 0f92b55955aaac10ac327f613bc804876d17bcb8 Author: Tim Douglas Date: Mon Oct 12 21:35:40 2026 -0400 serial: pmac_zilog: push received data to the port that received it [ Upstream commit f3dc727da3af64abc12b625bbf1eb68d55d882cc ] pmz_interrupt() drains both channels but, since commit 2e124b4a390c ("TTY: switch tty_flip_buffer_push"), pushes the flip buffer of the port whose handler is running rather than the port that was drained. With both ports open, data received on the other port can be left in its flip buffer until something else pushes it, so its reader may not see it. Fixes: 2e124b4a390c ("TTY: switch tty_flip_buffer_push") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tim Douglas Link: https://patch.msgid.link/20261013013541.4535-2-me@timdoug.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d247965b75b55d4853ee632296c1a5778426919a Author: Jiri Slaby (SUSE) Date: Tue Oct 13 08:48:49 2026 +0200 serial: 8250_lpss: do not touch uninitialized line in ehl_serial_exit() [ Upstream commit 3e3ae95a3d84a6028f37a07ab7ad78bb14689f2e ] lpss8250_probe() calls lpss->board->exit() on its error path. For the EHL board, that is ehl_serial_exit() and it does: serial8250_get_port(lpss->data.line)->dma = NULL; But when lpss8250_dma_setup() or serial8250_register_8250_port() fails, lpss->data.line was never assigned. As lpss is kzalloc()ed, line is 0 and ehl_serial_exit() clears the dma pointer of an unrelated port -- serial8250_ports[0], i.e. ttyS0, which is often the console. Initialize lpss->data.line to -1 in probe and skip the clearing in ehl_serial_exit() if no port was registered. Fixes: 5318f70da7e8 ("serial: 8250_lpss: Balance reference count for PCI DMA device") Signed-off-by: Jiri Slaby (SUSE) Assisted-by: LLM Cc: "Ilpo Järvinen" Cc: stable@kernel.org Cc: Andy Shevchenko Cc: linux-serial@vger.kernel.org Link: https://patch.msgid.link/f389df34aaa538270313ebd4cea75c2baaf46b95.1791873876.git.jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a270d509427b20af6ae959b971ff135a19611546 Author: Muhammad Bilal Date: Wed Oct 7 18:47:10 2026 +0500 platform/x86: hp-bioscfg: NUL-terminate the SPM auth token [ Upstream commit f2769668959f6411ac69e83080a240f8a8785e05 ] auth_token_store() copies the token with kmemdup(), which does not NUL terminate it, but hp_calculate_security_buffer() and hp_populate_security_buffer() use it as a C string and read past the allocation. A lone newline (echo > auth_token) is worse: kmemdup() of 0 bytes returns ZERO_SIZE_PTR, which passes the NULL checks, so a later attribute write passes it to strlen(). A userspace replica of the two helpers under ASan reports a heap buffer overflow in hp_calculate_security_buffer() for the unterminated token and a fault at address 0x10 for the lone newline, and is clean with this change. The token is a string, so copy it with kstrndup(), which always NUL terminates and allocates at least one byte. Fixes: b2715aa2e135 ("platform/x86: hp-bioscfg: spmobj-attributes") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20261007134711.473857-9-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 9c3fb85342a83b373d644cbb91a6b85e79f91235 Author: Muhammad Bilal Date: Wed Oct 7 18:47:06 2026 +0500 platform/x86: hp-bioscfg: allow clearing current_password [ Upstream commit acada379d5c4dd3a86d48fc69802e769eff29f7e ] The ABI documents echo "" > current_password as the way to end a session, but validate_password_input() rejects an empty string when min_password_length is nonzero, so the password stays cached. Skip the length check for an empty current_password so the write clears it. Compile tested only. Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://lore.kernel.org/all/20261007134711.473857-1-meatuni001@gmail.com/ Link: https://patch.msgid.link/20261007134711.473857-5-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit c32eca7c52da00efa37721809cf4da0755a0366d Author: Muhammad Bilal Date: Wed Oct 7 18:47:05 2026 +0500 platform/x86: hp-bioscfg: return -E2BIG from validate_password_input() [ Upstream commit a4f19c589b21e18567d3c0ac7b9294f81e29b1de ] validate_password_input() returns the positive INVALID_BIOS_AUTH on rejection. store_password_instance() skips the store on nonzero ret, but its final "return ret < 0 ? ret : count" treats the positive value as success, so userspace sees count instead of an error. Return -E2BIG for an invalid password length. Tested on HP EliteBook 840 G2 (Fedora 44, Linux 7.2.7): writing 999 bytes to current_password returned 999 before this change. Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://lore.kernel.org/all/20261007134711.473857-1-meatuni001@gmail.com/ Link: https://patch.msgid.link/20261007134711.473857-4-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit b50cd6fe3a6e457d8f60e5a70c60947976d76f6f Author: Muhammad Bilal Date: Wed Oct 7 18:47:04 2026 +0500 platform/x86: hp-bioscfg: fix non-ASCII truncation in hp_get_string_from_buffer() [ Upstream commit 6b8d2374b32c35efa2a431b3cd2fe346f8917dcc ] utf16s_to_utf8s() writes into dst, but the loop that follows overwrites dst from the raw UTF-16 code units with truncating casts, so any character above U+007F is mangled. For example, U+00E9 is stored as 0xe9 instead of 0xc3 0xa9. Convert into a scratch buffer first, then escape '\\', '\r', '\n' and '\t' into dst with string_escape_mem(). Quotes are not escaped, so the existing strreplace() still handles them. Tested on HP EliteBook 840 G2 (Fedora 44, Linux 7.2.7). Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg") Cc: stable@vger.kernel.org Suggested-by: Ilpo Järvinen Signed-off-by: Muhammad Bilal Link: https://lore.kernel.org/all/20261007134711.473857-1-meatuni001@gmail.com/ Link: https://patch.msgid.link/20261007134711.473857-3-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit f3236f00b8fbdef61c2fa482e06c8fcc6599002d Author: Muhammad Bilal Date: Wed Oct 7 18:47:03 2026 +0500 platform/x86: hp-bioscfg: fix OOB reads in hp_get_string_from_buffer() [ Upstream commit 176b38b84ae5e075850b3ebb25f906d66f95a46d ] The escape prescan loop uses 'size' as both its bound and its accumulator, so each escape character found extends the loop and reads past the end of src[]. Use the original u16 count as the loop bound. Also include the 2-byte length prefix in the bounds check, pass the u16 count instead of the byte count to utf16s_to_utf8s(), and advance the buffer by the bytes actually consumed instead of the escape-inflated count. Tested on HP EliteBook 840 G2 (Fedora 44, Linux 7.2.7). Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20261007134711.473857-2-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 183cc1c1c47d095513d1ab43aacba9771d8ab5e6 Author: Denis Arefev Date: Wed Oct 14 13:26:18 2026 +0300 ALSA: cs46xx: fix unit mismatch in DSP code area bounds check [ Upstream commit fd65108f5001ffb416dc9bd37ec1893f55cff24a ] ins->code.offset and code->size are measured in 32-bit words, while DSP_CODE_BYTE_SIZE is the size of the DSP code area in bytes. The check ins->code.offset + code->size > DSP_CODE_BYTE_SIZE in cs46xx_dsp_load_module() therefore allowed up to four times more code than the code area can hold. The shadow buffer ins->code.data is allocated with kmalloc(DSP_CODE_BYTE_SIZE), i.e. it holds DSP_CODE_BYTE_SIZE/4 words. A firmware file with a code segment larger than DSP_CODE_BYTE_SIZE/4 words (28 KiB) passed the check and caused an out-of-bounds write in shadow_and_reallocate_code() and an out-of-bounds read in snd_cs46xx_download(). Compare the sum in words against DSP_CODE_BYTE_SIZE/4 and cast it to u64 so that the sum cannot wrap for large code->size values. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Denis Arefev Link: https://patch.msgid.link/20261014102619.16415-1-arefev@swemel.ru Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 62d46d12a632f354c829da8b1f6718d662597ae0 Author: Aamir Ahmed Date: Wed Sep 16 09:53:51 2026 +0100 lib: decompress_bunzip2: fix integer overflow in run-length decoding [ Upstream commit b822ad8d702df0be9fe3f24f71caeb0522d72319 ] The RUNA/RUNB decoder in get_next_block() accumulates a run length into the signed int t with no bound. runPos doubles per symbol, so t grows as at least 2^n-1 and reaches INT_MAX after 31 RUNA symbols. The guard that follows, dbufCount+t >= dbufSize, is itself a signed addition, and as the kernel builds with -fno-strict-overflow it wraps negative once dbufCount is nonzero, so the guard is skipped. while (t--) dbuf[dbufCount++] = uc then writes INT_MAX entries into a buffer holding at most 900000. One literal symbol ahead of the run is enough to make dbufCount nonzero. Bound t to the block size as it is accumulated. t only grows within a run, so the value tested never exceeds the final run length; any stream that decodes today satisfies dbufCount+t < dbufSize at the flush, hence t < dbufSize throughout, and no such stream is rejected. Because t grows as at least 2^n-1 the bound trips by the 20th symbol, leaving runPos at most 2^19, so the following runPos <<= 1 cannot overflow either. Link: https://lore.kernel.org/AS8P251MB00010FE5E38D253CF98A652AC8B92@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Fixes: bc22c17e12c1 ("bzip2/lzma: library support for gzip, bzip2 and lzma decompression") Signed-off-by: Aamir Ahmed Signed-off-by: Andrew Morton Assisted-by: LLM Cc: Alain Knaff Cc: "H. Peter Anvin" Cc: Signed-off-by: Sasha Levin commit be4810c5f1be011190a706fbf31965939758cc45 Author: Matt Turner Date: Sat Sep 12 14:17:35 2026 -0400 lib/decompress_bunzip2: fix off-by-one in run-length bounds check [ Upstream commit 69919be2b93ef3922f646729ff42b4bd9a30846b ] The run-length path rejects a block when dbufCount+t equals dbufSize, but the loop that follows writes exactly t bytes starting at dbufCount, so a block that fills the buffer exactly is legal. bzip2 allows it too: its decompressor bounds a block at 100000 * blockSize100k and checks that limit per byte appended. Use > instead of >=. bzip2's encoder stops filling a block 19 bytes early, so nothing it produces ever reaches the limit and the bug stays hidden. Compressors that use the full block size do reach it: an lbzip2 -9 image whose block ends on a run fails to decode, and a self-extracting kernel built that way does not boot. This code came from busybox, which fixed the same line in 2013 in commit 932e233a491b ("bunzip2: fix off-by-one check"). I ran into this because my system uses lbzip2 as /bin/bzip2 -- a common thing on Gentoo I believe. As far as I can tell, anyone using lbzip2 as their system bzip2 would run into this and it's only because it's very uncommon these days to compress a kernel with bzip2 that no one has noticed. I only noticed because I was adding support for various compression formats on alpha. Link: https://lore.kernel.org/20260912-b4-bunzip2-blocksize-fix-v1-1-c7384bbfc954@gmail.com Fixes: bc22c17e12c1 ("bzip2/lzma: library support for gzip, bzip2 and lzma decompression") Signed-off-by: Matt Turner Signed-off-by: Andrew Morton Cc: Alain Knaff Cc: "H. Peter Anvin" Cc: Signed-off-by: Sasha Levin commit 7744a9a70dba590bf6317c47837b6f86d8cbfee7 Author: Ma Ke Date: Sun Oct 11 14:17:22 2026 +0800 pinctrl: stm32: Fix fwnode reference leak in stm32_gpiolib_register_bank() [ Upstream commit 54c66b5e47a9b10cbf4a1efe9b01301b7ffee205 ] stm32_gpiolib_register_bank() walks the "gpio-ranges" property with fwnode_property_get_reference_args(). As documented in drivers/base/property.c: * The caller is responsible for calling fwnode_handle_put() on the * returned @args->fwnode pointer. The returned reference is never put. The function calls the helper twice, once directly and then repeatedly in a while loop, and each call overwrites args, so only the last reference is even reachable and all the earlier ones are leaked for good. Put the reference as soon as args.args[] has been consumed, both for the initial call and for every iteration of the loop. Found by code review. Cc: stable@vger.kernel.org Fixes: bb949ed9b16b ("pinctrl: stm32: Switch to use for_each_gpiochip_node() helper") Signed-off-by: Ma Ke Reviewed-by: Antonio Borneo Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5ea772c2b570378db7e397629c4067ed62379156 Author: Arpith Alexander Date: Tue Nov 3 18:44:35 2026 +0530 spi: ljca: Don't require data in write replies [ Upstream commit 5072a9fae45a043cad80f74f4f19fc98803630ab ] Commit 0fe4573c822c ("spi: ljca: validate the response length before copying the data") made ljca_spi_read_write() reject any response whose payload, as announced by r_packet->len, is not contained in the data received. That is right for reads, but the adapter acknowledges a write with only the packet header: r_packet->len holds the number of bytes written and no payload follows. The reply is 2 bytes long, so "ret < sizeof(*r_packet) + r_packet->len" is true and every write fails with -EIO. Where the Intel Visual Sensing Controller (IVSC) is connected through the LJCA, as on the Dell XPS 13 9340, its initialisation fails and the camera behind it is lost: spi_ljca usb_ljca.ljca-spi.0: transfer failed len: 256 vsc-tp spi-INTC10D0:00: SPI transfer failed: -5 intel_vsc intel_vsc: error -ENODEV: init hw failed Only require the payload to be present when there is a receive buffer to copy it into. Write acks are still checked for a non-zero length that does not exceed the request. Fixes: 0fe4573c822c ("spi: ljca: validate the response length before copying the data") Cc: stable@vger.kernel.org # 6.8+ Signed-off-by: Arpith Alexander Reviewed-by: Weibin Liu Acked-by: Sakari Ailus Link: https://patch.msgid.link/20261103131435.21838-1-arpith99@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 35dfe02e19f3b30c2c2711bedd59cdf6046bae0a Author: Weibin Liu Date: Tue Oct 13 11:17:17 2026 +0800 spi: ljca: validate the response length before copying the data [ Upstream commit 0fe4573c822c4c9152e2fd5269ab85410c9e458f ] ljca_spi_read_write() only checks that the response from the adapter carries the packet header and a non-zero payload length before copying r_packet->len bytes from the response into the transfer buffer. The payload length is taken from the packet the device sent back and is neither bounded by the number of bytes actually received nor by the size of the requested transfer: a misbehaving adapter can announce a payload larger than what it actually sent, and the memcpy then reads past the end of the 60-byte input buffer and writes past the end of the caller's transfer buffer. Check that the response carries the full header before reading r_packet->len, then reject responses whose payload is not contained in the data received or is longer than the requested transfer. Fixes: caee8e38da67 ("spi: Add support for Intel LJCA USB SPI driver") Cc: stable@vger.kernel.org # 6.8+ Signed-off-by: Weibin Liu Link: https://patch.msgid.link/20261013031717.3933277-1-liuwb@xiaopeng.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8dca8bd7f58137b11d7b6b64b44f7c1cd5ed8817 Author: Daeho Jeong Date: Sat Oct 10 02:41:33 2026 +0000 f2fs: disallow mmap write and data-modifying fallocate on atomic files [ Upstream commit 06dfe4a7eb696d868b196c2a49873142f19bd862 ] Stores through a shared writable mapping and fallocate with FALLOC_FL_PUNCH_HOLE, FALLOC_FL_ZERO_RANGE, FALLOC_FL_COLLAPSE_RANGE or FALLOC_FL_INSERT_RANGE do not go through ->write_begin, so they bypass the COW inode and modify the original inode directly. Reject them while the file is in atomic write mode, as fallocate already does for pinned and compressed files. A write fault gets SIGBUS and fallocate gets -EOPNOTSUPP. fallocate without these flags only preallocates blocks and stays allowed. f2fs_vm_page_mkwrite() cannot take inode_lock, so check the flag under invalidate_lock, and hold invalidate_lock in f2fs_ioc_start_atomic_write() from the flush until the flag is set. Otherwise a fault could check the flag, then start_atomic_write could flush and set the flag, and the fault would dirty the folio afterwards. Cc: stable@kernel.org Fixes: 3db1de0e582c ("f2fs: change the current atomic write way") Signed-off-by: Daeho Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 55e004e52af96801577b6c3c4d52a578f369f4b5 Author: Zhan Xusheng Date: Mon Oct 5 23:49:54 2026 +0800 f2fs: fix defragment writeback range truncation on 32-bit [ Upstream commit 92154fe28c3701bebf75176dc5522bec62519a8f ] f2fs_defragment_range() flushes the range it is about to defragment: filemap_write_and_wait_range(inode->i_mapping, pg_start << PAGE_SHIFT, (pg_end << PAGE_SHIFT) - 1); pg_start and pg_end are pgoff_t, 32 bits on 32-bit kernels, so both shifts are evaluated in 32 bits and truncated before they are widened to the loff_t parameters. pg_end is only capped by the file's page count, so for a file larger than 4 GiB the shift wraps. For a 5 GiB file pg_end is 1310720 and the range collapses from [0, 5 GiB) to [0, 1 GiB), leaving the rest of the dirty pages unwritten before the blocks are moved. For 8 GiB the shift yields 0, the minus one makes it (loff_t)-1, and the range becomes [0, LLONG_MAX]. The matching call in f2fs_collapse_range() already casts: filemap_write_and_wait_range(inode->i_mapping, (loff_t)index << PAGE_SHIFT, ((loff_t)pg_end << PAGE_SHIFT) - 1); Do the same here. On i386 the shift changes from "shl $0xc,%ecx" to "shld", i.e. from a 32-bit shift to a double-precision one. Cc: stable@kernel.org Fixes: d323d005ac4a ("f2fs: support file defragment") Signed-off-by: Zhan Xusheng Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 7d671f85cb844645d65f43283b019f4bbecdde46 Author: Kaixuan Li Date: Sat Sep 19 00:55:07 2026 +0800 f2fs: check every cur_*_segno[] entry on readonly images [ Upstream commit 9c4ee79190c8c23a9fb5c07d3bc87eaac514b2bb ] sanity_check_ckpt() bounds-checks cur_node_segno[] and cur_data_segno[] against main_segs, but on an image with the RO feature the goto that skips the duplicate-segno cross-checks also leaves the enclosing loop, so only index 0 of each array is ever checked. An unchecked index reaches __set_sit_entry_type() through build_curseg() -> reset_curseg(), which writes se->type through &sit_i->sentries[segno]. With segment_count_main 120 and cur_data_segno[1] set to 200, KASAN reports three out-of-bounds writes during mount and the mount then succeeds. Use continue so every index is bounds-checked, and skip the node-vs-data cross-check explicitly, which is the other thing the old goto skipped. Cc: stable@kernel.org Fixes: a7d9fe3c3388 ("f2fs: support RO feature") Signed-off-by: Kaixuan Li Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit d9a6000b1ad6e84a50d9914ebf9c2dfa01e7ff1e Author: Nanzhe Zhao Date: Tue Oct 13 18:56:28 2026 +0800 f2fs: read i_size once in f2fs_vm_page_mkwrite [ Upstream commit c04f209773ecb31e592cababce0d6658ee0b8d58 ] f2fs_vm_page_mkwrite() reads i_size twice: once to check whether the folio is partially beyond EOF, and once to calculate the offset for folio_zero_segment(). But a concurrent buffered write can extend isize and cause the following race condition to corrupt data: buffered write writes [0,3500) CPU0 (write fault) CPU1 (buffered write) ---- ---- f2fs_vm_page_mkwrite() folio_lock(folio) if (((loff_t)(folio->index + 1) << PAGE_SHIFT) > i_size_read(inode)) /* i_size_read() = 3500 */ write(fd, buf, 200, 4096) /* writes into page1, does not wait for folio lock */ i_size_write(inode, 4296) offset = i_size_read(inode) & ~PAGE_MASK /* i_size_read() = 4296, offset = 200 */ folio_zero_segment(folio, offset, folio_size(folio)) /* valid data [200, 3500) is zeroed */ Fix this by reading i_size once and using the same value for both the EOF check and the zeroing offset. Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20261012030315.978375-1-zhaonanzhe%40xiaomi.com Fixes: fbfa2cc58d53 ("f2fs: add file operations") Cc: stable@vger.kernel.org Signed-off-by: Nanzhe Zhao Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit c9ce592435314401e9f6e9d5298883aec8da05ec Author: Joanne Chang Date: Fri Oct 9 09:53:31 2026 +0000 f2fs: allow pinning empty compressed files [ Upstream commit 2eebc31ae5f53e1066bb6238c8087c23b688ad17 ] Commit a64a3fec11e7 ("f2fs: force out-place update for all writes on compressed file") updated f2fs_should_update_outplace() to always return true for compressed files. However, this function is also called during f2fs_ioc_set_pin_file() validation, so pinning an empty file with compression enabled now fails with -EINVAL before the compression flag can be stripped. Fix this by guarding the f2fs_compressed_file(inode) check with fio in f2fs_should_update_outplace(). This preserves forced OPU for actual compressed writes (fio != NULL), while allowing f2fs_ioc_set_pin_file() (fio == NULL) to proceed to f2fs_disable_compressed_file(inode). Cc: stable@kernel.org Fixes: a64a3fec11e7 ("f2fs: force out-place update for all writes on compressed file") Assisted-by: LLM Signed-off-by: Joanne Chang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 4b5e0313560025761693f4880d65a90df833585e Author: Nanzhe Zhao Date: Mon Oct 12 11:03:15 2026 +0800 f2fs: remove mappedtodisk flag usage in mmap write path [ Upstream commit b3c9843589257631bac18f30655e82d88970688a ] PG_mappedtodisk was inherited from the nobh/buffer-head era. However, f2fs has no buffer heads and the flag is no longer meaningful. The only user of the flag is the "no holes" shortcut in f2fs_vm_page_mkwrite(), which makes mmap write faults skip marking the folio dirty. Moreover, it causes the following race condition with filesystem freezing: CPU0 (write fault) CPU1 (freeze_super) ---- ---- f2fs_vm_page_mkwrite() sb_start_pagefault() /* shortcut: no dirty */ sb_end_pagefault() sb_wait_write(SB_FREEZE_PAGEFAULT) /* no waiter, passes */ sync_filesystem() /* folio not dirty, skipped */ finish_fault() /* PTE writable */ fault_dirty_shared_page() folio_mark_dirty() /* dirty folio on a frozen fs */ It will also skip APP_MAPPED_IO iostat/REQ_TIME updates and post-EOF folio zeroing. Remove this shortcut in f2fs_vm_page_mkwrite() and stop setting it in f2fs_read_single_page(). Reported-by: Chao Yu Link: https://lore.kernel.org/linux-f2fs-devel/496b913c-eb81-4fa8-be72-c6a06a10aba2@kernel.org/ Reviewed-by: Chao Yu Reviewed-by: Barry Song Fixes: fbfa2cc58d53 ("f2fs: add file operations") Cc: stable@vger.kernel.org Signed-off-by: Nanzhe Zhao Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 32f64839b58d2b0e846204eca3934f9d9719116a Author: Karl Mehltretter Date: Sun Sep 27 21:13:59 2026 +0200 sh: intc: Sort the prio and sense lists after filling them [ Upstream commit 94a219eda3b5fb1d1753a5ecf28b171c8f308a27 ] register_intc_controller() sorts d->prio and d->sense right after allocating them, with hw->nr_prio_regs and hw->nr_sense_regs as the element count. The lists hold hw->nr_vectors entries and are only filled later, by intc_register_irq(). On SH7785, sh7785-irq0123 and sh7785-irq4567 have four vectors but the SoC's eleven priority registers, so sort() swaps 88 bytes in a 32 byte kmalloc object at boot. slub_debug=FZPU reports "Right Redzone overwritten" in kmalloc-32, and v6.5 and v6.6 panic in __kmem_cache_alloc_node() while registering sh7785-irq0123. Found with a custom QEMU model of the SH7785LCR. On it, v6.4 sh7785lcr_defconfig boots with SLAB, the defconfig default before v6.5, and hangs before the console is up when built with SLUB. Sort the lists once all vectors are registered, with the number of entries that were added. Fixes: b59f9f9775e6 ("sh: intc: optimize intc IRQ lookup") Signed-off-by: Karl Mehltretter Assisted-by: LLM Cc: stable@vger.kernel.org Tested-by: John Paul Adrian Glaubitz Reviewed-by: John Paul Adrian Glaubitz Reviewed-by: Geert Uytterhoeven Signed-off-by: John Paul Adrian Glaubitz Signed-off-by: Sasha Levin commit 1aaca3a5fa91304c0243b8ebe8181ed57173ec02 Author: Geraldo Nascimento Date: Tue Jun 16 12:25:45 2026 -0300 PCI: rockchip-host: Do not attempt 5.0 GT/s retraining [ Upstream commit 2a1e6c382fb7567679c07bd6a7060fefc7a5edc9 ] Drop the 5.0 GT/s Link Speed retraining from Rockchip PCIe Root Complex Mode Operation, so-called host driver. The reason is that Shawn Lin from Rockchip has reiterated that there may be danger of "catastrophic failure" in using their PCIe with 5.0GT/s speeds. While Rockchip has done so informally without issuing a proper errata, and the particulars are thus unknown, this may cause data loss or worse. This change is corroborated by RK3399 official datasheet [1], which states maximum link speed for this platform is 2.5 GT/s. [1] https://opensource.rock-chips.com/images/d/d7/Rockchip_RK3399_Datasheet_V2.1-20200323.pdf Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support") Reported-by: Dragan Simic Reported-by: Shawn Lin Link: https://lore.kernel.org/all/ffd05070-9879-4468-94e3-b88968b4c21b@rock-chips.com/ Signed-off-by: Geraldo Nascimento Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Dragan Simic Reviewed-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/68f6353e3a2ea4914de36c42b6906e41282adad3.1781622998.git.geraldogabriel@gmail.com Signed-off-by: Sasha Levin commit aeeb55044b0af2168c4f5dcd91289f73031efbbd Author: Daeho Jeong Date: Sun Oct 4 17:04:56 2026 +0000 f2fs: convert inline quota files when turning quota on [ Upstream commit a85e09bd6cc80059b9e0ef5cd1467719aa3129a8 ] With a block size larger than 4KB, the inline data area is large enough to hold a freshly created quota file (quotacheck writes 6KB), so aquota.user/aquota.group stay inline after quotaon. f2fs does not expect quota files to be inline, and this causes two problems: 1. Quota file corruption. f2fs_write_single_data_page() sends quota inodes straight to f2fs_do_write_data_page(), which sees NULL_ADDR for index 0, treats the folio as truncated and drops it. Updates to the quota file are lost once the folio is reclaimed, so the quota tree reads stale data: chown/chgrp fail with EIO and quota entries of users disappear. For example, the kernel log shows: find_free_dqentry: Data block full but it shouldn't qtree_write_dquot: Error -5 occurred while creating quota 2. Deadlock. Writing a quota file past MAX_INLINE_DATA converts it from f2fs_write_begin() under f2fs_lock_op(). dquot_transfer() is called from f2fs_setattr() with f2fs_lock_op() already held, so chown/chgrp take cp_rwsem for read twice and hang, together with the checkpoint and every other writer, once a checkpoint waits for cp_rwsem in between (seen with generic/232). Quota files only grow and there are at most MAXQUOTAS of them, so there is no point in keeping them inline. Convert them in f2fs_quota_on() and after dquot_quota_on_mount(), which keeps every block size on the same path as 4KB blocks, where quota files never fit inline. Quota sysfiles are created by mkfs with real blocks and are not affected. Cc: stable@kernel.org Fixes: d7e9a9037de2 ("f2fs: Support Block Size == Page Size") Signed-off-by: Daeho Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit e169946cd8d553ff4ac691b2b8e435b0d3b0bf49 Author: Andrea Parri Date: Mon Oct 12 16:12:29 2026 +0200 nvmet: zns: don't leak stale memory in zone management receive [ Upstream commit 31b8a6af19b73e6167c4b655cd5e86681bac1c41 ] A Zone Management Receive report returns the full buffer the host asked for, but nvmet_bdev_zone_zmgmt_recv_work() writes only the 8-byte Number of Zones field and one 64-byte descriptor for each matching zone that fits. The 56 reserved header bytes and every descriptor slot past the last match keep whatever the buffer held before. A 4096-byte report covering a single zone leaves 4024 bytes unwritten. The tcp, rdma and fc transports allocate that buffer with sgl_alloc() and pci-epf with kmalloc(), none with __GFP_ZERO, and on success each sends the whole buffer to the host (nvmet_setup_c2h_data_pdu() for tcp), so the host receives old kernel memory from the target. nvmet_bdev_execute_zone_mgmt_recv() also never checks the transport data length against NUMD, so on transports where the host sets that length, the buffer sent back can be much larger than the report NUMD describes. pci-epf derives its data length from NUMD, so the length check below does not apply there, but the zeroing still covers the report. Reject a data length that does not match NUMD with nvmet_check_transfer_len(), as nvmet_bdev_execute_zone_append() does, and zero the report with nvmet_zero_sgl() before filling it. Zeroing NUMD bytes is only enough because of the length check, so the two go together. Allocating with __GFP_ZERO in the transports would also close the leak, but it adds a memset to every read command to fix one handler, so the transports are left alone. Tested over the loop, tcp, rdma and fc transports with a zoned null_blk namespace: before this patch, zone reports carried stale bytes and a data length larger than NUMD was accepted; with it, reports are fully initialized and such a length fails with Data SGL Length Invalid. Fixes: aaf2e048af27 ("nvmet: add ZBD over ZNS backend support") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Christoph Hellwig Signed-off-by: Andrea Parri Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 1cfc0f64b3fbbfca2169213f63f7811447240a96 Author: Jérémy Jean Date: Wed Oct 7 19:27:46 2026 +0000 nvmet: free the bvec on file namespace range errors [ Upstream commit 9d820d55b3cb4859c7cf42a74dc78f6154f97398 ] nvmet_file_execute_rw() allocates the bvec before nvmet_file_execute_io() checks whether the request fits in the backing file. If the request extends beyond the file, nvmet_file_execute_io() calls nvmet_req_complete() to return an error. This skips nvmet_file_io_done(), so the allocated memory is never freed. Repeated requests can exhaust memory. Use nvmet_file_io_done() to free the bvec before returning the range error to the client. Fixes: 50a909db36f2 ("nvmet: use IOCB_NOWAIT for file-ns buffered I/O") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Christoph Hellwig Signed-off-by: Jérémy Jean Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit d066d556d1ccb12b07acd4b72537d1a6e9551a43 Author: Yehyeong Lee Date: Tue Oct 6 22:48:05 2026 +0900 nvme-auth: fail when the controller does not authenticate itself [ Upstream commit f9e43d924bc74feeb56197de82b2845de2a4b85a ] nvme_auth_process_dhchap_success1() returns success as soon as the controller clears the rvalid flag in its DH-HMAC-CHAP success1 message, without looking at whether the host had asked the controller to authenticate. A host configured with a controller secret sends a challenge in its reply, computes the expected controller response, and sets chap->bi_directional; if the controller then answers with rvalid = 0 the response is never compared, the host still sends success2, and the queue is marked as authenticated. A malicious or man-in-the-middle controller therefore only has to clear one flag to turn the configured bidirectional authentication into a one-way one, without holding any secret of its own. The target side already treats the mirror image of this as fatal: when the host supplied a challenge but no controller key is configured, nvmet_auth_success1() fails the authentication rather than answering with rvalid = 0. Refuse the connection if the controller returns no response although bidirectional authentication was requested. chap->bi_directional is the right condition rather than ctrl->ctrl_key, because secure concatenation sends a challenge only to derive the PSK and deliberately clears bi_directional; a one-way setup without a controller secret keeps returning success as before. Fixes: f50fff73d620 ("nvme: implement In-Band authentication") Cc: stable@vger.kernel.org Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 5c8032e3c7baa7820b524fda81dd5a683136a442 Author: Yehyeong Lee Date: Tue Sep 29 00:38:11 2026 +0900 nvme-rdma: don't complete a request after a bogus remote invalidation [ Upstream commit 909307cea08aff4e486cdb7491de5c76a2c31341 ] When a remote invalidation names an rkey that is not the one we handed out for this request, nvme_rdma_process_nvme_rsp() logs and schedules error recovery, then falls through to nvme_rdma_end_request(). The request is completed with req->mr never invalidated, and nvme_rdma_unmap_data() hands it back with ib_mr_pool_put(), which only puts it on a list. The rkey stays valid and still maps the pages the completed read filled, so a controller that sent the bogus invalidation can write into those pages after pread() has returned. Return instead, the way the local invalidation path below already does, and leave the request for error recovery to cancel. Fixes: 3ef0279bb0031 ("nvme-rdma: Check remotely invalidated rkey matches our expected rkey") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 512d832beec8d2487e058befb90258e2bce89319 Author: Andrea Parri Date: Mon Sep 28 10:48:08 2026 +0200 iomap: don't lose a fiemap iteration error when emitting the last extent [ Upstream commit 0d0104adc2c8316433b660cdf6d182a09881864f ] iomap_fiemap() emits extents one behind: iomap_fiemap_iter() flushes the previous extent and remembers the current one, and the remembered extent is written with FIEMAP_EXTENT_LAST after the iteration loop. That final flush overwrites ret, so when ->iomap_begin() fails partway through the iteration the error is replaced by the result of iomap_to_fiemap() (zero on success) and iomap_fiemap() returns success with a truncated extent list whose last entry is wrongly marked as the last extent in the file. The pre-iomap_iter code returned the error from inside the loop, before flushing the pending extent. Check for the iteration error before flushing the pending extent, so that real errors are propagated and only a successful iteration emits the final FIEMAP_EXTENT_LAST extent. -ENOENT (no mapping) is still not an error, and the pending extent is still emitted in that case. Fixes: 7892386d3571 ("iomap: switch iomap_fiemap to use iomap_iter") Cc: stable@vger.kernel.org # v5.15 Reviewed-by: Brian Foster Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Andrea Parri Link: https://patch.msgid.link/250226e33b3b23c6b1714a45dc3c465c2a45cdc0.1790342457.git.parri.andrea@gmail.com Reviewed-by: "Darrick J. Wong" Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 2dffd513ea9e393990699746d37feb84a1fa4943 Author: Kathiravan Thirumoorthy Date: Mon Sep 21 11:49:35 2026 +0530 clk: qcom: ipq5332: add 24MHz rate for USB UTMI clock [ Upstream commit 19b62f31e15ef70dc927aab91b1576ea6c37f992 ] The USB UTMI reference clock must operate at 24 MHz, as recommended by the hardware team, for reliable USB operation. Validation showed that USB 3.2 hub enumeration with USB 2.0 devices fails when the UTMI reference clock is not configured to the required 24 MHz rate. Configuring the UTMI reference clock to 24 MHz to resolve the enumeration failure and ensure successful device detection. Cc: stable@vger.kernel.org Fixes: 3d89d52970fd ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5332 SoC") Signed-off-by: Kathiravan Thirumoorthy Reviewed-by: Abel Vesa Link: https://patch.msgid.link/20260921-ipq_clk_changes-v1-2-d242e3d49648@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit eec3b5bdc6173b17d73c8ab732bfb2326d9c539c Author: Kathiravan Thirumoorthy Date: Mon Sep 21 11:49:34 2026 +0530 clk: qcom: ipq5018: add 24MHz rate for USB UTMI clock [ Upstream commit 75e893169fc5c9ec28d5f9dffde40ce29b59a5de ] The USB UTMI reference clock must operate at 24 MHz, as recommended by the hardware team, for reliable USB operation. Validation showed that USB 3.2 hub enumeration with USB 2.0 devices fails when the UTMI reference clock is not configured to the required 24 MHz rate. Configuring the UTMI reference clock to 24 MHz to resolve the enumeration failure and ensure successful device detection. Cc: stable@vger.kernel.org Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018") Signed-off-by: Kathiravan Thirumoorthy Reviewed-by: Abel Vesa Link: https://patch.msgid.link/20260921-ipq_clk_changes-v1-1-d242e3d49648@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0400bff986064836dd9e7adb4e1c19b0bf639af0 Author: Samuel Thibault Date: Sat Aug 29 18:49:45 2026 +0200 speakup: Fix NULL pointer dereference on VT switch + selection [ Upstream commit e1301ab8a8411fccc7effe0711fc09939a94953c ] When selecting/pasting very quickly after VT switch, the tty is not set yet, leading to a NULL dereference. We can just abort the operation. Reported-by: co+e5693071d903b832@bugs.sh Signed-off-by: Samuel Thibault Cc: stable@kernel.org Tested-by: Weiming Shi Link: https://patch.msgid.link/20260829164945.2691317-3-samuel.thibault@ens-lyon.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8a20eba11c10197c89b097817fa882fd1c19be61 Author: Wentao Guan Date: Tue Oct 6 10:38:00 2026 +0300 mei: vsc: Fix packet CRC computed over pointer size [ Upstream commit 1d2a50533aac7046488da78b0d25f69673cbb028 ] vsc_tp_xfer() computes the packet CRC over sizeof(pkt) + olen bytes, but pkt is a pointer, so sizeof(pkt) evaluates to the pointer size instead of the size of struct vsc_tp_packet_hdr. The value correctly match the 8-byte header on 64-bit builds. Use sizeof(pkt->hdr), consistent with the header size used everywhere else in the driver, e.g. in VSC_TP_PACKET_SIZE(). Cc: stable@kernel.org Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") Reviewed-by: Sakari Ailus Signed-off-by: Wentao Guan Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20261006-vcs_fix_crc-v1-1-b7b149f13c1d@intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 39b68ff5c4d487753244578ba776e6d3068d970f Author: Mikulas Patocka Date: Mon Oct 12 16:09:52 2026 +0200 dm-bufio: fix a race leading to an unsigned integer underflow [ Upstream commit 005d2ec5723cd4ac740de678274623f1fadd6a6e ] The function __scan tests "count - freed <= retain_target" and then sets "atomic_long_set(&c->need_shrink, 0);" It exits with the condition "if (!atomic_long_read(&c->need_shrink)) break;" It may be possible that between these two statements, another thread sets &c->need_shrink to a non-zero value. In this case, the function __scan continues and it may possibly the "freed" variable is larger than the "count" variable. The expression "count - freed" underflows and the function __scan will continue to free all the buffers, even those that are below retain_target. Fix this bug by immediatelly exiting if we set "atomic_long_set(&c->need_shrink, 0)"; and don't attempt to re-read c->need_shrink afterwards. Fixes: 450e8dee51aa ("dm bufio: improve concurrent IO performance") Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-5 Signed-off-by: Sasha Levin commit c16555815d4b7aae2b2b2aa2ea320c714d0fee6d Author: Jiri Slaby (SUSE) Date: Tue Oct 13 08:48:48 2026 +0200 serial: 8250_exar: store the GPIO platform device in struct exar8250 [ Upstream commit 33d337816e00994daaf670243186d9e537ee090d ] The GPIO platform device is registered via platform->register_gpio() when port 0 is being set up. It is stored to port->port.private_data of the on-stack uart template (and from there it is copied into every registered port). pci_xr17v35x_exit() then fetches it back by serial8250_get_port(priv->line[0]). But port 0 does not have to exist at that point. If serial8250_register_8250_port() fails for port 0, priv->line[0] holds a negative error code. The probe still succeeds (it only breaks the loop), so on unbind, priv->line[0] (a negative value) is passed to serial8250_get_port(). The GPIO device is never unregistered and a bogus port is accessed. The same problem would also occur after the planned conversion of serial8250_register_8250_port() to return a uart port instead of a line. As Sashiko pointed out in that case: If board->setup() fails for the first port (i=0) in exar_pci_probe(), priv->uport[0] remains NULL. If serial8250_register_8250_port() fails, it returns an ERR_PTR. In either case, the loop breaks and probe returns success. When the device is later unbound, pci_xr17v35x_exit() unconditionally passes priv->uport[0] to platform->unregister_gpio(), which will dereference it without checking for validity. The GPIO device belongs to the PCI device, not to any particular port. So store it in a new struct exar8250::gpio member. Pass priv to both ->register_gpio() and ->unregister_gpio(), so that pci_xr17v35x_exit() does not need to look up any port at all. Signed-off-by: Jiri Slaby (SUSE) Fixes: d0aeaa83f0b0 ("serial: exar: split out the exar code from 8250_pci") Link: https://lore.kernel.org/all/sashiko-outbox-166269@kernel.org/ Assisted-by: LLM Cc: stable@vger.kernel.org Link: https://patch.msgid.link/03a8b5c71614fc672fef1e55c083bda6c73b5bf3.1791873876.git.jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4a9ad942a4b32138ca9167de22c6df02b02f8b09 Author: Lorenzo Stoakes (ARM) Date: Sat Sep 26 14:17:04 2026 +0100 fbdev: sh_mobile_lcdc: check for fb_deferred_io_init() error [ Upstream commit 5192201aaac2a923ff98306e3ccda58718ee395f ] fb_deferred_io_init() allocates deferred I/O state, populating info->fbdefio_state, or leaving it NULL if an error occurs. Currently sh_mobile_lcdc_start() ignores its return value. Therefore if an error arises in fb_deferred_io_init() (for instance, due to an allocation failure) info->fbdefio_state is left NULL. When the file is subsequently opened, fb_open() will dereference a NULL pointer (calling fb_deferred_io_open()). Fix this by checking for the error. Also clear info->fbdefio in that case, so that sh_mobile_lcdc_stop() does not attempt to clean up deferred I/O state that was never initialised. Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 78e9ae9d0ff757e6f3d4477111f8d96d5ad028be Author: Lorenzo Stoakes (ARM) Date: Sat Sep 26 14:17:03 2026 +0100 fbdev: smscufx: check for fb_deferred_io_init() error [ Upstream commit 8ea6c6e77ccf887f3e68c64f4c261071a345da1e ] fb_deferred_io_init() allocates deferred I/O state, populating info->fbdefio_state, or leaving it NULL if an error occurs. Currently ufx_ops_open() ignores its return value. Therefore if an error arises in fb_deferred_io_init() (for instance, due to an allocation failure) info->fbdefio_state is left NULL. fb_open() will then dereference a NULL pointer (calling fb_deferred_io_open()) as soon as ufx_ops_open() returns. Additionally, if the allocation of info->fbdefio itself fails, ufx_ops_open() sets info->fbdefio to NULL and invokes fb_deferred_io_init() regardless, hitting BUG_ON(!fbdefio). Fix this by only invoking fb_deferred_io_init() if the allocation succeeded, and checking for the error. The driver already supports operating without deferred I/O, so in either case fall back to that by setting info->fbdefio to NULL. The ignored return value was introduced in commit 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct"). However, the BUG_ON() issue originates from the earlier commit 3c8a63e22a08 ("Add support for SMSC UFX6000/7000 USB display adapters"), so target that for the fix. Fixes: 3c8a63e22a08 ("Add support for SMSC UFX6000/7000 USB display adapters") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 33763f4ec91602db6bc21633b18e563ae1b1b44e Author: Lorenzo Stoakes (ARM) Date: Sat Sep 26 14:17:02 2026 +0100 fbdev: udlfb: check for fb_deferred_io_init() error [ Upstream commit eae055f33e41e1d3e1a7e905bdcb1e9f196ed31d ] fb_deferred_io_init() allocates deferred I/O state, populating info->fbdefio_state, or leaving it NULL if an error occurs. Currently dlfb_ops_open() ignores its return value. Therefore if an error arises in fb_deferred_io_init() (for instance, due to an allocation failure) info->fbdefio_state is left NULL. fb_open() will then dereference a NULL pointer (calling fb_deferred_io_open()) as soon as dlfb_ops_open() returns. Additionally, if the allocation of info->fbdefio itself fails, dlfb_ops_open() sets info->fbdefio to NULL and invokes fb_deferred_io_init() regardless, hitting BUG_ON(!fbdefio). Fix this by only invoking fb_deferred_io_init() if the allocation succeeded, and checking for the error. The driver already supports operating without deferred I/O, so in either case fall back to that by setting info->fbdefio to NULL. The ignored return value was introduced in commit 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct"). However, the BUG_ON() issue originates from the earlier commit 5bea1fbf9423 ("staging: udlfb: fix incorrect fb_defio implementation for multiple framebuffers"), so target that for the fix. Fixes: 5bea1fbf9423 ("staging: udlfb: fix incorrect fb_defio implementation for multiple framebuffers") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 6699431359c8d6dd50b94eeb31f29ed2219ff03c Author: Lorenzo Stoakes (ARM) Date: Sat Sep 26 14:17:00 2026 +0100 fbdev: xen-fbfront: check for fb_deferred_io_init() error [ Upstream commit 5b234b0dd29d79207c059c7b40851dd1e934fa3a ] fb_deferred_io_init() allocates deferred I/O state, populating info->fbdefio_state, or leaving it NULL if an error occurs. Currently xenfb_probe() ignores its return value. Therefore if an error arises in fb_deferred_io_init() (for instance, due to an allocation failure) info->fbdefio_state is left NULL. When the file is subsequently opened, fb_open() will dereference a NULL pointer (calling fb_deferred_io_open()). Fix this by checking for the error. Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 50511d21a6c539f517fcbe061782632a0bb47118 Author: Lorenzo Stoakes (ARM) Date: Sat Sep 26 14:16:59 2026 +0100 fbdev: ssd1307fb: check for fb_deferred_io_init() error [ Upstream commit 81ae1f9a6c850efab3e5dec6b7c9aa5c587f92b7 ] fb_deferred_io_init() allocates deferred I/O state, populating info->fbdefio_state, or leaving it NULL if an error occurs. Currently ssd1307fb_probe() ignores its return value. Therefore if an error arises in fb_deferred_io_init() (for instance, due to an allocation failure) info->fbdefio_state is left NULL. When the file is subsequently opened, fb_open() will dereference a NULL pointer (calling fb_deferred_io_open()). Fix this by checking for the error. Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 2798436421f7adcc08561f8944602b4d8ca4629a Author: Guixiong Wei Date: Wed Sep 30 00:31:34 2026 +0800 platform/x86/intel-uncore-freq: Continue restoring limits on resume [ Upstream commit 38998529f45c02edcf96b0a3ddd3c83de6d11bbe ] The PM notifier iterates over every uncore frequency instance to restore user-configured MSR_UNCORE_RATIO_LIMIT values after resume. Entries that have never been configured legitimately have stored_uncore_data set to zero. The refactoring that split common and enumeration code changed the iteration from active control CPUs to all allocated instances. It also changed the skip for an invalid or unconfigured entry from continue to return, causing that entry to terminate the entire restore operation. On a multi-package or multi-die system, configuring only a later instance therefore leaves its limit unrestored after suspend, hibernation, or restore if an earlier entry is invalid or unconfigured. Use continue to skip only the current entry and restore all remaining configured instances. Fixes: dbce412a7733 ("platform/x86/intel-uncore-freq: Split common and enumeration part") Cc: stable@vger.kernel.org Tested-by: Yijia Wang Signed-off-by: Guixiong Wei Acked-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260929163133.14326-2-weiguixiong@bytedance.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 2a15a7847060ef4a113cdefe62e7fe532ffea508 Author: Guangshuo Li Date: Thu Sep 24 19:56:17 2026 +0800 platform/x86: simatic-ipc: fix platform device leak on registration failure [ Upstream commit 9523698252fd583d6987582b9c34ec6500d10986 ] register_platform_devices() registers the battery, LED, and watchdog platform devices in sequence. If LED registration fails, the battery device remains registered. If watchdog registration fails, the LED and battery devices remain registered. These failure paths leave successful platform_device_register_data() calls without the matching platform_device_unregister() calls. Add an unwind ladder to unregister previously registered platform devices in reverse order before returning the registration error. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: dd123e62bded ("platform/x86: simatic-ipc: add main driver for Siemens devices") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260924115617.1578309-1-lgs201920130244@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit f883de7f96c5748bd6f834c4afdedb7142315574 Author: Jack Boykin Date: Wed Sep 2 16:02:12 2026 -0500 platform/x86/amd/pmf: Fix power_supply refcount leak in amd_pmf_get_battery_prop() [ Upstream commit 9f3eebbbd1033de0abcc2694ba4b455d30fe33f9 ] power_supply_get_by_name() takes a reference that is only dropped on the error path. On success it leaks, five times per policy evaluation. Unregistering the battery later trips the use_cnt WARN_ON in power_supply_unregister() and never frees it. While here, return -ENODEV instead of an uninitialised 'value' when no battery matches, and stop at the first supply found rather than letting the last one in the table win. Found by reading the code. Fix and changelog drafted with Claude Code (Fable 5.1) and reviewed by hand. Compile-tested only (allmodconfig, W=1, sparse); not run on Smart PC hardware. Fixes: f4627dfd0e19 ("platform/x86/amd/pmf: Add support to get inputs from other subsystems") Cc: stable@vger.kernel.org Assisted-by: LLM sparse Signed-off-by: Jack Boykin Link: https://patch.msgid.link/20260902210217.69483-1-jtboykin.jb@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 56b4fa4d435e1ec52257692289cef9bff1bc79ce Author: Muhammad Bilal Date: Wed Aug 26 15:30:12 2026 +0500 platform/x86: hp-wmi: fix heap OOB read and memory corruption in hp_wmi_perform_query() [ Upstream commit 6dea092b261f04d632411c2be52d13190f5f67b1 ] hp_wmi_perform_query() evaluates an ACPI WMI method and expects a struct bios_return header in the returned buffer. However, it only checks that the ACPI object type is ACPI_TYPE_BUFFER without verifying that obj->buffer.length is at least sizeof(*bios_return) (8 bytes). If the firmware or ACPI method returns a buffer shorter than 8 bytes: 1. bios_return->return_code at offset 4 reads out of bounds from the allocated ACPI buffer slab. 2. If return_code evaluates to 0 and outsize is non-zero, (int)(obj->buffer.length - sizeof(*bios_return)) evaluates to a negative integer (e.g. -8 for a 0-length buffer). actual_outsize is set to this negative value and passed to memcpy(buffer, ..., actual_outsize), where the signed negative value is cast to size_t (e.g. 0xfffffffffffffff8), attempting to copy ~18 Exabytes and triggering an immediate kernel crash. Additionally, memset(buffer + actual_outsize, ...) performs an out-of-bounds write before buffer. Fix this by ensuring obj->buffer.length is at least sizeof(*bios_return) before accessing the return code, and compute actual_outsize safely using min_t(u32, ...), which is sound specifically because the guard above already rules out obj->buffer.length being smaller than sizeof(*bios_return) by the time that subtraction runs. Fixes: c3021ea1beee ("hp-wmi: allow setting input and output buffer sizes separately") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260826103012.240453-1-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit db227d32b6362aee017d8884887e3c93a5d33572 Author: Muhammad Bilal Date: Sat Sep 19 11:00:37 2026 +0500 platform/x86: hp-bioscfg: fix 16-byte heap overflow for empty auth token [ Upstream commit 540b8ae192afb5566c1b13b6884aee87107a26b9 ] hp_calculate_security_buffer() special-cases an empty authentication string and returns a fixed 4 bytes (sizeof(u16) * 2). But hp_populate_security_buffer() does not special-case that same input: for any authentication string that does not start with BEAM_PREFIX, including the empty string, it always builds "UTF_PREFIX + authentication" and converts the result to UTF-16, writing a 2-byte length header plus 2 bytes per character of "" (9 characters), 20 bytes total, regardless of how long "authentication" itself is. The caller, hp_set_attribute(), sizes its kmalloc() buffer using hp_calculate_security_buffer()'s return value, so for an empty authentication token it allocates 4 bytes for the security area but hp_populate_security_buffer() then writes 20 bytes into it, causing a 16-byte heap buffer overflow. The authentication token used here is the current admin/setup password, which is an empty string by default until one is configured. Any write to a writable BIOS attribute while no admin password has been set reaches this path. Fix by removing the special-case early return for an empty string in hp_calculate_security_buffer(). The generic calculation that follows already accounts for the UTF_PREFIX correctly, which naturally yields the same 20 bytes that hp_populate_security_buffer() writes for an empty string, avoiding duplicate logic for special cases. Fixes: b2715aa2e135 ("platform/x86: hp-bioscfg: spmobj-attributes") Reported-by: Josh Snyder Closes: https://lore.kernel.org/platform-driver-x86/20260402-hp-bioscfg-overflow-v1-1-6985f8c9e67c@code406.com/ Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260919060037.84602-1-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit ac378128b9ec10428eb8d3de26aa45c7bf1c9874 Author: Denis Benato Date: Wed Sep 16 14:38:26 2026 +0000 platform/x86: asus-wmi: fix screenpad power state detection [ Upstream commit f9a1cd14b392a82fdc73474894bf8b198757dfb2 ] On some models, e.g. the UX5400EA, the screenpad power state cannot be read back: DSTS(ASUS_WMI_DEVID_SCREENPAD_POWER) never sets ASUS_WMI_DSTS_STATUS_BIT, so asus_wmi_get_devstate_simple() reports the panel as powered off regardless of its real state. The DSDT shows DSTS 0x00050031 (POWER) and DSTS 0x00050032 (LIGHT) both read the same two-byte EC register, each returning a different byte: byte 0 is a raw EC status byte, which is 0xa0 when the panel is powered and 0x00 when it is off, and byte 1 is the brightness. Read the power state from the low byte instead of ASUS_WMI_DSTS_STATUS_BIT: firmware reporting the power through the status bit is covered too, since ASUS_WMI_DSTS_STATUS_BIT lies inside ASUS_WMI_DSTS_BRIGHTNESS_MASK. Reuse read_screenpad_backlight_power() in asus_screenpad_init() in place of the raw devstate read. This makes the brightness read reachable on models like the UX5400EA, so mask the SCREENPAD_LIGHT value with ASUS_WMI_DSTS_BRIGHTNESS_MASK before storing it: the unmasked devstate (0x0001ffa0 when the panel is on) would otherwise be exposed to userspace as an out-of-range brightness (max_brightness is 255) which systemd-backlight then persists. While at it, pass asus_wmi_get_devstate() the u32 it expects. Fixes: 130d29c5627c ("platform/x86: asus-wmi: adjust screenpad power/brightness handling") Reported-by: Hugo Baigue Closes: https://lore.kernel.org/all/CAO84+x+P2_xyHP89+nGVSMV6bL+dy0P9=vyEEfZGnFhv0hBNWw@mail.gmail.com/ Suggested-by: Hugo Baigue Tested-by: Hugo Baigue Cc: stable@vger.kernel.org Assisted-by: zcode:glm-5.3-flash Signed-off-by: Denis Benato Link: https://patch.msgid.link/20260916143838.170950-3-denis.benato@linux.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit efaf4db84041e1f9512ff7454fc958e3aac3ff12 Author: Denis Benato Date: Wed Sep 16 14:38:25 2026 +0000 platform/x86: asus-wmi: fix unclear usage of bd->props.power [ Upstream commit fd83d81ddf058d487e6d6489b18094f068e66a59 ] The bd->props.power is checked in parts of the driver correctly comparing with BACKLIGHT_POWER_ON, while in others with a raw usage of bd->props.power and !bd->props.power, moreover in certain checks the logic has been inverted due to BACKLIGHT_POWER_ON being defined as 0: fix both the wrong usage and the inconsistencies by using proper comparisons. Fixes: 130d29c5627c ("platform/x86: asus-wmi: adjust screenpad power/brightness handling") Closes: https://lore.kernel.org/all/178362762638.911488.8564892548331679884@eldamar.lan/ Closes: https://lore.kernel.org/all/ea9c63d1-4776-49d5-9dc4-6c09498f99c9@linux.dev/ Tested-by: Hugo Baigue Tested-by: Ponali Cc: stable@vger.kernel.org Assisted-by: zcode:glm-5.3-flash Signed-off-by: Denis Benato Link: https://patch.msgid.link/20260916143838.170950-2-denis.benato@linux.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit ea8565604e89a0637ea233af3d97e62c746c97c8 Author: Mario Limonciello Date: Thu Sep 3 13:29:26 2026 -0500 platform/x86/amd/pmf: Validate the APTS state index [ Upstream commit 192dddd5aa45166450820cef16521bdf23976a73 ] The static slider APTS state index is supplied by the BIOS as an 8-bit value, but apts_config_store contains only APTS_MAX_STATES entries. An invalid firmware value can therefore cause amd_pmf_update_slider_v2() to read beyond the end of the array. Validate the selected index before applying the slider values and return an error when it is out of range. Fixes: 8362e862fb87 ("platform/x86/amd/pmf: Update sps power thermals according to the platform-profiles") Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260903182927.3556274-1-mario.limonciello@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 71ebbaa8b1dafce50deed6c58d361cfe82036bac Author: Donggeun Yoo Date: Mon Sep 21 08:24:41 2026 -0700 mm/damon/core: charge only the part of a region the filter left [ Upstream commit 4ff3b4a54a32142497fb44b79d0920aa6ba3393d ] Patch series "mm/damon/core: fix the size charged for a filter-trimmed region", v2. An address range DAMOS filter that partially overlaps a monitoring region splits it, so the scheme action reaches only one side of the boundary. damos_apply_scheme() reads the region size before that split and never re-reads it, so the quota charge and schemes//stats/sz_tried account for the whole original region. Patch 1 re-reads the size after the core filters have run. Patch 2 adds KUnit coverage for what the function charges and reports, for the trimmed cases and for the cases that must not change. This patch (of 2): An address range DAMOS filter that partially overlaps a monitoring region splits the region at the filter boundary, so the scheme action is applied to only one side of it. damos_apply_scheme() reads the region size once on entry, before damos_core_filter_out() performs that split. The quota charge and the statistics update therefore account for the region as it was before the trim. schemes//stats/sz_tried counts memory the filter excluded, which Documentation/mm/damon/design.rst says is not counted as tried, and with quotas/bytes set the excluded part is charged against the budget, throttling the scheme to a fraction of what was configured. User impact is that DAMOS could unexpectedly slowly run, due to over-charged quota. DAMOS stat could also be confusing. No critical events such as crashes or leask happen. Re-read the region size after the core filters have run. Link: https://lore.kernel.org/20260921152443.80132-1-sj@kernel.org Link: https://lore.kernel.org/20260921152443.80132-2-sj@kernel.org Fixes: ab9bda001b68 ("mm/damon/core: introduce address range type damos filter") Signed-off-by: Donggeun Yoo Signed-off-by: SJ Park Signed-off-by: Andrew Morton Reviewed-by: SJ Park Cc: Brendan Higgins Cc: David Gow Cc: Signed-off-by: Sasha Levin commit 2edb293e97e7f64a75919e28075763c6241c489b Author: Breno Leitao Date: Fri Sep 18 04:24:37 2026 -0700 mm/shmem: report RCU-tasks quiescent states while undoing a range [ Upstream commit ebd1a08c192109c83a87ddf42793ed6283180faf ] This shows up in the Meta fleet on ftruncate() of large tmpfs files: INFO: rcu_tasks detected stalls on tasks: 00000000752fd185: .. nvcsw: 59455/59455 holdout: 1 idle_cpu: -1/0 task:rocksdb:bottom state:R running task __folio_split find_get_entry find_get_entries truncate_inode_partial_folio shmem_undo_range shmem_setattr notify_change do_ftruncate __x64_sys_ftruncate do_syscall_64 shmem_undo_range() walks the whole of the requested range in folio_batch sized steps, twice, and its two cond_resched() calls are the only reschedule points in that walk. cond_resched() is not an RCU-tasks quiescent state. Use cond_resched_tasks_rcu_qs() at both points so the walk reports an RCU-tasks quiescent state as it proceeds. Link: https://lore.kernel.org/20260918-shmem-tasks-rcu-v1-1-79acf91a2569@debian.org Fixes: 8315f42295d2 ("rcu: Add call_rcu_tasks()") Signed-off-by: Breno Leitao Signed-off-by: Andrew Morton Reviewed-by: SJ Park Cc: Baolin Wang Cc: Hugh Dickins Cc: "Paul E . McKenney" Cc: Signed-off-by: Sasha Levin commit bdbd9fb511b29fa1a26850942396cba39a615d71 Author: Hongfu Li Date: Fri Sep 18 10:56:11 2026 +0800 mm/hugetlb_cgroup: move per-node usage on cgroup reparenting [ Upstream commit 23fac055c21176f66ed453394b533bdfc00f7fba ] hugetlb_cgroup_css_offline() hands the folios of a dying cgroup over to its parent with hugetlb_cgroup_move_parent(), which moves the page_counter charges and the hugetlb_cgroup pointer of the folio but not its per-node usage. The parent's hugetlb..numa_stat is short by that usage while they are charged, and underflows once they are freed, exposing incorrect per-node usage values to userspace. Move the per-node usage to the parent as well. The folios keep their node here, so only the cgroup which holds the usage changes. Link: https://lore.kernel.org/20260918-for-hugetlb-charge-v2-2-2b6d8c2bdc36@kylinos.cn Fixes: f47761999052 ("hugetlb: add hugetlb.*.numa_stat file") Signed-off-by: Hongfu Li Signed-off-by: Andrew Morton Acked-by: Muchun Song Cc: Colin Ian King Cc: David Hildenbrand Cc: Kees Cook Cc: Mina Almasry Cc: Oscar Salvador Cc: Shakeel Butt Cc: Signed-off-by: Sasha Levin commit cdeda97e70caf18a9aa132708c227956b5c1d2be Author: Hongfu Li Date: Fri Sep 18 10:56:10 2026 +0800 mm/hugetlb_cgroup: move per-node usage on cross node migration [ Upstream commit fe0ba1909c59660f078560f5130e7af7c6004f12 ] Patch series "mm/hugetlb_cgroup: move the per-node usage along with the folio", v2. The per-node usage reported by hugetlb..numa_stat is accounted against folio_nid() in __hugetlb_cgroup_commit_charge() and __hugetlb_cgroup_uncharge_folio(), so it is only correct while a folio stays charged on the same node and in the same hugetlb_cgroup. Two paths move a folio which stays charged, and neither moves the usage with it. hugetlb_cgroup_migrate() only moves the hugetlb_cgroup pointers of a folio migrated to another node, and hugetlb_cgroup_move_parent() only moves the page_counter charges and the hugetlb_cgroup pointer of the folios of a dying cgroup. In both cases the node (or cgroup) which was charged keeps a usage which never goes away, while the node (or cgroup) which ends up uncharging the folio underflows as soon as the folio is freed. Patch 1/2 moves the usage along with the folio on cross node migration, patch 2/2 does the same for the folios a dying cgroup reparents. This patch (of 2): hugetlb..numa_stat uses folio_nid() to account usage in __hugetlb_cgroup_commit_charge() and __hugetlb_cgroup_uncharge_folio(). hugetlb_cgroup_migrate() only moves hugetlb_cgroup pointers, leaving per-node usage behind on the source node during cross-node migration. When the migrated folio gets uncharged, we subtract usage from the destination node counter. This creates stale usage on the source node and unsigned long counter underflow on the destination node. The hugetlb..numa_stat interface exposes these incorrect per-node usage values to userspace. Add a hugetlb_cgroup_move_usage() helper which moves the usage from the old node to the new node, and call it from hugetlb_cgroup_migrate(). Link: https://lore.kernel.org/20260918-for-hugetlb-charge-v2-0-2b6d8c2bdc36@kylinos.cn Link: https://lore.kernel.org/20260918-for-hugetlb-charge-v2-1-2b6d8c2bdc36@kylinos.cn Fixes: f47761999052 ("hugetlb: add hugetlb.*.numa_stat file") Signed-off-by: Hongfu Li Signed-off-by: Andrew Morton Acked-by: Muchun Song Cc: Colin Ian King Cc: David Hildenbrand Cc: Kees Cook Cc: Mina Almasry Cc: Oscar Salvador Cc: Shakeel Butt Cc: Signed-off-by: Sasha Levin commit 85e7adb356a697ab6acc4b267672a18876ef3b3e Author: Yuanhe Shu Date: Wed Sep 16 19:25:45 2026 +0800 mm/page_alloc: do not boost watermarks in kdump capture kernels [ Upstream commit 331f94007d79b3c02d3098eea469a92aea3efc2c ] A watermark boost is not confined to one watermark: wmark_pages() adds it to min, low and high alike, so every watermark check sees it, including should_reclaim_retry() and the last ditch ALLOC_WMARK_HIGH attempt in __alloc_pages_may_oom(). Once the boost exceeds the memory still free the allocator gives up and invokes the OOM killer, and a capture kernel that is still booting has nothing to kill: the boot panics and the vmcore is lost. Seen on an arm64 machine with 64K pages, CONFIG_PAGE_BLOCK_MAX_ORDER=10 (pageblock = 64M) and crashkernel=512M, running a distribution kernel based on 7.0.14. A high order UNMOVABLE allocation fell back to a MOVABLE pageblock while the capture kernel was still in do_initcalls(): Node 0 DMA free:68096kB boost:65536kB min:68160kB low:68800kB high:69440kB managed:479168kB Out of memory and no killable processes... Kernel panic - not syncing: System is deadlocked on memory The zone was not short of memory. Subtracting the boost gives min:2624kB low:3264kB high:3904kB, so the 68096kB still free sat 17 times above the high watermark and the allocator would not even have entered its slow path. The boost supplied 65536kB of the 68160kB min and by itself put the zone 64kB under water. It is that large because boost_watermark() clamps it with max(pageblock_nr_pages, max_boost); watermark_boost_factor alone would have allowed 5824kB. Commit 14f69140ff9c ("mm: limit boost_watermark on small zones") already tried to protect capture kernels, but it infers them from the zone size and skips the boost only below four pageblocks. arm64 64K pageblocks were 512M then, so the guard reached zones up to 2G; CONFIG_PAGE_BLOCK_MAX_ORDER can cap them at 64M, which shrinks the guard to zones under 256M and lets this 468M zone through. kdump is a property of the kernel, not of the zone, so test for it directly. A capture kernel exits within seconds and never uses the fragmentation avoidance the boost buys. Normal kernels are unaffected: the size based check still covers their genuinely tiny zones. Passing sysctl.vm.watermark_boost_factor=0 to the capture kernel does not cover this window: sysctl.* parameters are written through procfs by do_sysctl_args(), which runs after do_initcalls() where the panic above happened, and watermark_boost_factor has no early_param of its own. Link: https://lore.kernel.org/20260916112545.3707893-1-xiangzao@linux.alibaba.com Fixes: 1c30844d2dfe ("mm: reclaim small amounts of memory when an external fragmentation event occurs") Signed-off-by: Yuanhe Shu Signed-off-by: Andrew Morton Reviewed-by: Vlastimil Babka (SUSE) Reviewed-by: Johannes Weiner Cc: Henry Willard Cc: Brendan Jackman Cc: David Hildenbrand Cc: Mel Gorman Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Zi Yan Cc: # v5.0 Signed-off-by: Sasha Levin commit 70e3668311516cac7c116fb561b9557158a01c49 Author: Gregory Price Date: Sat Sep 12 07:05:40 2026 -0400 mm/madvise: use folio_trylock() in the cold/pageout PMD split [ Upstream commit 5a6c9cf117fca3c38a98fb2a2d5549795c8b0b73 ] MADV_COLD or MADV_PAGEOUT over part of a PMD splits the THP in madvise_cold_or_pageout_pte_range(). Two threads doing that to the same THP create spurious failures. CPU0 CPU1 ---- ---- folio_get() spin_unlock(ptl) folio_lock() folio_get() spin_unlock(ptl) folio_lock() <- blocks, keeps its ref split_folio() folio_expected_ref_count(folio) != folio_ref_count(folio) - 1 -EAGAIN CPU1 cannot drop its reference until it gets the lock CPU0 holds, so CPU0's split always fails. folio_trylock() makes CPU1 leave without ever taking a reference. The PTE branch of this same function already does this, as do madvise_free_pte_range() and madvise_free_huge_pmd(). Reproducer: 400 rounds of eight threads calling MADV_COLD on half of each of eight THPs, re-formed with MADV_COLLAPSE between rounds. From /proc/vmstat: thp_split_page thp_split_page_failed before 3186 860 after 3200 0 The short before count is rounds where every thread failed and the advice was dropped for that THP entirely. On failure the walker returns 0 and nothing retries. The PMD path becomes best effort when the folio lock is held elsewhere - same as the PTE path. Link: https://lore.kernel.org/20260912110540.3203010-1-gourry@gourry.net Signed-off-by: Gregory Price (Meta) Signed-off-by: Andrew Morton Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260817220810.1175596-1-gourry%40gourry.net Acked-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Assisted-by: LLM Cc: Jann Horn Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Signed-off-by: Sasha Levin commit 52202745c8b3835119f4f6d00060df416e49b329 Author: Gregory Price Date: Sat Sep 12 07:08:32 2026 -0400 mm/madvise: reclaim isolated folios if PTE restart fails [ Upstream commit 5445a6359d717354dd76d509b8e693f13403ec61 ] MADV_PAGEOUT collects isolated folios on a local list before reclaiming them after the PTE walk. The reschedule path drops the PTE lock and then restarts the mapping with pte_offset_map_lock(). A concurrent operation can remove or replace the PTE table while the lock is dropped, causing pte_offset_map_lock() to return NULL. Returning directly in that case bypasses reclaim_pages(), leaving the collected folios off the LRU with elevated references. This results in a permanent memory leak. nr_isolated_anon increases reliably and does not decrease when the process dies. Route the failure through the existing cleanup path so any isolated folios are reclaimed or put back. Simplest userland pseudo-code reproducer: p = mmap(PMD_SIZE, ANONYMOUS); touch_every_page(p, PMD_SIZE); parallel { while (1) madvise(p, PMD_SIZE, MADV_PAGEOUT); while (1) { madvise(p, PMD_SIZE, MADV_DONTNEED); touch_every_page(p, PMD_SIZE); } } Reproduced in qemu trivially with some explicit widening of the race window. Link: https://lore.kernel.org/20260912110832.3203902-1-gourry@gourry.net Fixes: b2f557a21bc8 ("mm/madvise: add cond_resched() in madvise_cold_or_pageout_pte_range()") Signed-off-by: Gregory Price (Meta) Signed-off-by: Andrew Morton Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260821150912.183976-1-gourry@gourry.net Reviewed-by: Lorenzo Stoakes (ARM) Assisted-by: LLM Cc: David Hildenbrand Cc: Jann Horn Cc: Jiexun Wang Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Signed-off-by: Sasha Levin commit 7f611d9a146b23880573ae4c5e1c01170ffafa53 Author: SJ Park Date: Mon Sep 14 07:23:18 2026 -0700 mm/damon/sysfs-schemes: read sysfs_filter->addr_range only once [ Upstream commit 60e58be27d5e16d35e0728298f994dcae9f208a5 ] Patch series "mm/damon: move damos filter range arguments validation to core". DAMOS filter range arguments are being validated in the DAMON sysfs interface. Some of those have minor time-of-check to time-of-use (TOCTOU) bugs. In future, other callers might have duplicated validations with similar bugs. Fix the bugs and further refactor the code to move the validation to the core layer. Also add kunit test cases for the validations. Patches 1 and 2 fix the existing TOCTOU bugs. Patches 3 and 4 adds the validation in the core layer. Patch 5 drops the replicated validation in DAMON sysfs interface. Patch 6 further cleanup the code. Patches 7 and 8 extends kunit tests to test the validation. This patch (of 8): DAMON sysfs interface reads the user-provided address range arguments for addr type DAMOS filter twice. Once for validation, and once again for assignments to the variable that will be passed to the core layer. If the user updates the argument in parallel, an invalid address range could be passed to the core layer. Avoid it by doing the assignments first, and then validating the assigned variables before passing those to the core layer. User impact of the bug should be trivial. From the core layer's perspective, the invalid address range is not really invalid. It just works as having a weird address range. No critical issues such as a crash or a leak could happen. And sane users ain't do such parallel arguments update anyway. If they do, such racy behavior is arguably somewhat expected and deserved. That said, there is no reason to keep such races. Link: https://lore.kernel.org/20260914142327.92510-1-sj@kernel.org Link: https://lore.kernel.org/20260914142327.92510-2-sj@kernel.org Fixes: 2f1abcfccd86 ("mm/damon/sysfs-schemes: support address range type DAMOS filter") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: Brendan Higgins Cc: David Gow Cc: Usama Arif Cc: Signed-off-by: Sasha Levin commit d50a7e98388df9459ec20bfba784527551605d81 Author: Imre Kaloz Date: Sun Sep 27 12:56:09 2026 +0200 PCI: Avoid D3 on PLX PEX 8532/8533/8548 downstream ports [ Upstream commit 8e923e51892c7da91687dd5b8081ddb1f0fb395a ] Runtime PM suspends an idle downstream port of a PLX/Broadcom PEX 8532/8533/8548 switch to D3hot, but that takes the whole switch down with it: any device behind another port of the same switch then faults with a fatal bus error on its next access, e.g. mptsas probe on a Sun Ultra 45. This surfaced on sparc64 once commit a5fb3ff63287 ("PCI: Allow PCI bridges to go to D3Hot on all non-x86") let bridges enter D3hot. Keep these downstream ports out of D3 by setting PCI_DEV_FLAGS_NO_D3. Fixes: a5fb3ff63287 ("PCI: Allow PCI bridges to go to D3Hot on all non-x86") Signed-off-by: Imre Kaloz Signed-off-by: Bjorn Helgaas Tested-by: Magnus Lindholm Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260927105609.8813-1-kaloz@kernel.org Signed-off-by: Sasha Levin commit eb731fe0e4ddc2085a6f468add36574f85e1f80f Author: Yongjian Mu Date: Mon Oct 12 17:06:19 2026 +0000 xprtrdma: trim head iovec when the payload arrives via a Write chunk [ Upstream commit 9ee534a75912361308b1f956bc3e7895a082a422 ] The upper layer sets rq_rcv_buf.head[0].iov_len from its estimate of the reply header size. For RPCSEC_GSS that estimate includes auth->au_ralign, which gss_create_new() initializes to GSS_VERF_SLACK >> 2 (25 XDR words, or 100 bytes) and which is corrected to the real verifier size only after the first reply on that rpc_auth has been unwrapped. In this case, the krb5 MIC verifier is 36 bytes, so every request encoded before the first reply completes has a head that is 64 bytes too long. On TCP this is harmless: xdr_realign_pages() moves the excess head bytes, which are genuine reply data, into the page list. With RPC-over-RDMA and a Write chunk (sec=krb5, i.e. RPC_GSS_SVC_NONE, where DDP is allowed), the payload has already been placed directly into the page list, and the receive buffer holds only the inline part of the reply. rpcrdma_inline_fixup() clamps its local copy of the head length to the inline length but leaves head.iov_len untouched, so xdr_realign_pages() still sees iov_len > cur and shifts whatever lies past the inline reply in the receive buffer into the front of the directly-placed payload: rpc_xdr_recvfrom: head=[...,196] page=524288 tail=[...,64] rpc_xdr_alignment: nfsv4 READ offset=132 copied=64 The first 64 bytes returned by each such READ are incorrect (zeroed, or shifted right by 64 bytes depending on the kernel's xdr_shrink_bufhead() implementation). This is readily hit with pNFS flexfiles over RDMA and sec=krb5: the per-DS rpc_clnt gets a fresh rpc_auth whose first RPC is a large READ. Reads following the first completed reply return the expected data. Commit cb0ae1fbb2f5 ("xprtrdma: Do not update {head, tail}.iov_len in rpcrdma_inline_fixup()") removed the head-length correction while fixing the handling of pure-inline krb5p replies. When a Write chunk conveyed the payload, trim head.iov_len (in both rq_rcv_buf and rq_private_buf, which call_decode() expects to match) to the inline length actually received so that the XDR layer does not realign the page list. These READ replies have no trailing inline fields, and the payload is already in the page list, so the upper layer's head estimate can be safely reduced. Reduce buflen by the same amount to avoid treating unused head capacity as additional tail capacity. Pure inline replies and Reply chunk replies are unchanged. Tested on Linux 6.8.0 and 7.3-rc4 with NFSv4.1 pNFS flexfiles over RPC/RDMA and sec=krb5. Fixes: cb0ae1fbb2f5 ("xprtrdma: Do not update {head, tail}.iov_len in rpcrdma_inline_fixup()") Cc: stable@vger.kernel.org Signed-off-by: Yongjian Mu Reviewed-by: Chuck Lever Signed-off-by: Tim Menninger Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit c010721c156d825034331f4df643340f94dadbcf Author: Tim Menninger Date: Thu Sep 24 20:34:40 2026 +0000 xprtrdma: prevent disconnect feedback during endpoint teardown [ Upstream commit 0b5bb4e586f7b0a449f4d90a524f76a3be5db355 ] xprt_autoclose() clears XPRT_CLOSE_WAIT before invoking the transport's ->close() operation. For RPC/RDMA, ->close() calls rpcrdma_xprt_disconnect(), which disconnects the RDMA CM endpoint and drains its QP. Since commit 31e62d25b5b8 ("xprtrdma: Simplify RPC wake-ups on connect"), RDMA_CM_EVENT_DISCONNECTED requests a SUNRPC transport disconnect. Today that path, along with failed completion handling, reaches xprt_force_disconnect() through rpcrdma_force_disconnect(). Commit c487eb7d8e41 ("xprtrdma: Clean up disconnect") later added re_force_disconnect to ensure that multiple failure indications request only one SUNRPC disconnect. However, the gate remains open when SUNRPC itself begins endpoint teardown. If re_force_disconnect is still clear, either a CM disconnect event or a completion error can set XPRT_CLOSE_WAIT again while the current close is in progress. When the transport send lock is subsequently released, xprt_clear_locked() observes XPRT_CLOSE_WAIT and queues another autoclose. Requesting a disconnect this way is necessary when a connection is lost unexpectedly, but not when the event was generated by rpcrdma_xprt_disconnect() itself. In that case SUNRPC is already committed to closing the transport. Mark re_force_disconnect before initiating local endpoint teardown so that CM events and completion errors caused by that teardown cannot request another close. An unexpected error that wins the race before local endpoint teardown begins can still request a disconnect normally. Use a fully ordered exchange so that the gate is globally closed before rdma_disconnect() can transition the QP to error and generate the callbacks that the gate suppresses. In 30-second traces of a sustained recovery loop, without this change there were 7,693 xprt_force_disconnect() calls, 6,267 SUNRPC autocloses, and 172,892 receive-side IB_WC_WR_FLUSH_ERR completions. With this change, the same tracepoints recorded 3,512 xprt_force_disconnect() calls, 3,212 autocloses, and 131,287 receive-side flush completions. Thus QP teardown continues to produce flushed completions, but closing the disconnect gate before teardown substantially reduces their feedback into the SUNRPC close path. Fixes: 31e62d25b5b8 ("xprtrdma: Simplify RPC wake-ups on connect") Cc: stable@vger.kernel.org Signed-off-by: Tim Menninger Reviewed-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 8045b31d9e94814d475452817742c911a1dae9d5 Author: Weigang He Date: Sat Sep 26 14:28:53 2026 +1000 mtd: parsers: qcom: fix offset/size overflow on large partitions [ Upstream commit 2f7fa8d90694d21dce68ceabd8383252b111cfea ] In parse_qcomsmem_part() the partition offset and size are computed as parts[j].offset = le32_to_cpu(pentry->offset) * mtd->erasesize; parts[j].size = le32_to_cpu(pentry->length) * mtd->erasesize; Both le32_to_cpu() and mtd->erasesize are 32-bit (u32). The multiply is therefore evaluated in 32-bit arithmetic and the product is truncated to 32 bits before being widened and stored into the 64-bit (u64) parts[j].offset / parts[j].size fields, so the 64-bit destinations are never used at their full width. The SMEM partition table is firmware-provided and the per-entry offset and length are not bounds-checked against the device geometry (only numparts is capped). On a sufficiently large flash, a partition whose (offset|length) * erasesize is >= 2^32 gets a silently truncated offset/size and is mapped to the wrong region of the master MTD, which can overlap or extend into an unintended area. Cast one operand to u64 so the multiplication is performed in 64-bit and the result fits the 64-bit fields without truncation. Found by static analysis tool CodeQL. Fixes: 803eb124e1a6 ("mtd: parsers: Add Qcom SMEM parser") Cc: stable@vger.kernel.org Assisted-by: LLM codeql Signed-off-by: Weigang He Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 0eda671011be0cfbbe6b9f9caf02a6e2de394482 Author: Hengyu Liang Date: Fri Oct 9 13:33:59 2026 -0400 btrfs: return -ENOTTY for unknown ioctls on the control device [ Upstream commit 9985f1643ac3f8595862e2f82108f0ccae4cf959 ] Commit 5ab2b180884c ("btrfs: factor out validation of btrfs_ioctl_vol_args::name") made btrfs_control_ioctl() store the result of btrfs_check_ioctl_vol_args_path() in ret before it looks at the command. However, ret is initialized to -ENOTTY and the switch has no default case, so this initial value was what an unknown command returned. As of now, every unknown ioctl on /dev/btrfs-control returns 0. A tool that tries a control ioctl which the running kernel does not have is told that the ioctl succeeded. The issue can be reproduced with a simple C program, run as root: #include #include #include int main(void) { static char buf[4096]; int fd = open("/dev/btrfs-control", O_RDWR); if (ioctl(fd, TCGETS, buf) < 0) perror("ioctl"); else printf("ioctl succeeded\n"); return 0; } Before commit 5ab2b180884c ("btrfs: factor out validation of btrfs_ioctl_vol_args::name"), the result is: ioctl: Inappropriate ioctl for device After that commit, the result is: ioctl succeeded This patch will add a default case that returns -ENOTTY. Fixes: 5ab2b180884c ("btrfs: factor out validation of btrfs_ioctl_vol_args::name") CC: stable@vger.kernel.org Reviewed-by: Qu Wenruo Signed-off-by: Hengyu Liang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit d13bb0e4b79b4ef48f904c07979c1e536b030010 Author: Wentao Liang Date: Wed Sep 16 17:17:16 2026 +0000 btrfs: zoned: fix block group reference leak in btrfs_repair_one_zone() [ Upstream commit 886f1aa6e6b30a02901aa7f140149d466e10a873 ] btrfs_repair_one_zone() hands the block group reference taken by btrfs_lookup_block_group() over to relocating_repair_kthread(), which drops it. However the return value of kthread_run() is not checked, so when the kernel thread fails to spawn, nothing executes the put and the block group reference is leaked. Check kthread_run() and drop the reference if the thread failed to start. Fixes: f7ef5287a63d ("btrfs: zoned: relocate block group to repair IO failure in zoned filesystems") CC: stable@vger.kernel.org Reviewed-by: Boris Burkov Signed-off-by: Wentao Liang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit d83c9682c2e04f4cd35ee94e5b3c8c519278bb40 Author: Ard Biesheuvel Date: Fri Oct 9 17:16:01 2026 +0200 arm64/efi: Clear PTE_WRITE when applying EFI_MEMORY_RO [ Upstream commit 215d7b6622733603751f546b9faf9b84b0c281d4 ] set_permissions() sets PTE_RDONLY for regions that the Memory Attributes Table describes as read-only, but leaves PTE_WRITE set. PTE_WRITE is the DBM bit, so when hardware dirty state management is enabled (TCR_EL1.HD), such a descriptor is writable-clean rather than read-only, and a write by the firmware will be permitted by the hardware (which marks the entry dirty) instead of faulting. Clear PTE_WRITE as well, as pte_wrprotect() does. Cc: stable@vger.kernel.org Signed-off-by: Ard Biesheuvel Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 202187569441cf41663f5352288bc338839c8307 Author: Mikulas Patocka Date: Fri Oct 9 18:14:45 2026 +0200 dm-snapshot: fix crash if dm_io_client_create fails [ Upstream commit 829c4d21148a205eca864429e06530319e1f92d5 ] If dm_io_client_create() fails, it stores error into the ps->io_client variable. The code would try to free it later with dm_io_client_destroy(ps->io_client), causing an invalid pointer dereference. Fix this by setting ps->io_client = NULL. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9fbb7228e438ee12fc9676135895ac9bdeac1f7c Author: Johan Hovold Date: Fri Oct 9 14:33:59 2026 +0200 USB: serial: sierra: fix urb leak on write completion [ Upstream commit e7daa54802c566ed3f22e81513f84c8c9197c5d1 ] Make sure to drop the reference taken by usb_anchor_urb() also on successful submission of delayed write URBs during runtime resume to prevent them from leaking on completion. Fixes: e6929a9020ac ("USB: support for autosuspend in sierra while online") Reported-by: Wentao Liang Link: https://lore.kernel.org/20260916165352.2085480-1-vulab@iscas.ac.cn Cc: stable@vger.kernel.org # 2.6.32 Cc: Oliver Neukum Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 55b841a90509a1dbc61cf8fc6f72aba3e51c4d84 Author: Anup Vishwakarma Date: Wed Sep 16 15:26:53 2026 +0530 mailbox: qcom-ipcc: Guard against NULL con_priv in send_data() [ Upstream commit 7b3cc361b5942ac600f38e5dff7aed009be34964 ] qcom_ipcc_mbox_shutdown() clears chan->con_priv with no locking. qcom_ipcc_mbox_send_data() dereferences the same field without checking for NULL first, so a send racing a concurrent shutdown can crash: mchan = chan->con_priv; ... hwirq = qcom_ipcc_get_hwirq(mchan->client_id, mchan->signal_id); Add the same NULL guard mbox_send_message() already uses for chan->cl, and bail out before dereferencing a cleared con_priv. To close the remaining race where send_data() reads con_priv a moment before a concurrent shutdown clears it, acquire the spinlock in qcom_ipcc_mbox_shutdown() using the modern guard(spinlock_irqsave) primitive before setting con_priv to NULL. Fixes: d6fbfdbc1274 ("mailbox: qcom-ipcc: Fix IPCC mbox channel exhaustion") Cc: stable@vger.kernel.org Signed-off-by: Anup Vishwakarma Reviewed-by: Konrad Dybcio Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 429b2ad4a81710e2c9d9544c3de897db18ecf5e0 Author: Wentao Liang Date: Thu Sep 17 09:39:23 2026 +0000 mailbox: mtk-cmdq: Fix runtime PM leak in cmdq_mbox_flush() [ Upstream commit 18e3e979826795b62e8916743bec4de660e7cb22 ] pm_runtime_get_sync() leaves the runtime PM usage counter incremented even when it fails, but cmdq_mbox_flush() returns the error without dropping it. The same happens when the GCE thread does not drain in time and the function bails out with -EFAULT. Undo the reference on both error paths. Fixes: b0524f7c9635 ("mailbox: mediatek: implement flush function") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit b5eeacb9138ff57e41a9b0219050f90b91aa82c3 Author: Wayne Chang Date: Wed Sep 16 14:18:58 2026 +0800 usb: typec: ucsi_ccg: Add retry mechanism in ccg_read [ Upstream commit bbf6b99a57b2479bf51c3c8ad0946f4b8c33ed69 ] CCG4 firmware occasionally fails to respond to I2C read requests, especially when reading cci and intr_reg from the ISR path. In these cases, i2c_transfer() returns -EREMOTEIO. The CCG4 is EOL, and Infineon no longer supports firmware updates, so a software workaround is necessary. Attempt the read up to CCG_READ_MAX_RETRIES (4) times in total when -EREMOTEIO is returned, sleeping ~1 ms via fsleep() between attempts. This allows recovery from transient I2C failures without affecting other error paths. The sleep is safe because ccg_read() is called both from process context and from ccg_irq_handler(), which runs in threaded IRQ context (registered via request_threaded_irq() with a NULL hard-IRQ handler), so sleeping is allowed in both cases. Fixes: 247c554a14aa ("usb: typec: ucsi: add support for Cypress CCGx") Cc: stable Signed-off-by: Wayne Chang Reviewed-by: Jon Hunter Tested-by: Jon Hunter Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260916061858.1471606-1-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5379c93c88c12ba1eda6d8dfaa8b74aced472c57 Author: Drobyshev Vladimir Date: Tue Sep 29 20:38:33 2026 +0300 USB: cdc-acm: add VeriFone VX820 device ID [ Upstream commit ddbddee6592ecf6cf6c24d888780f9ad45a3e30b ] Add USB ID 11ca:0219 for the VeriFone VX820 to the cdc-acm device table and apply the SINGLE_RX_URB quirk. Signed-off-by: Drobyshev Vladimir Link: https://patch.msgid.link/20260929173833.105208-1-enigma_137@icloud.com Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3771e229d5e4a49246abfe9d14d7c81ca4244213 Author: Koichiro Den Date: Fri Oct 9 13:54:52 2026 +0900 cxl/acpi: Convert QTG _DSM latencies to picoseconds [ Upstream commit 2658c66a5efb5f30f5ced708a5de831845b43f6d ] The QTG _DSM expects read and write latencies in picoseconds, as specified in CXL 3.0, Table 9-30. The code base originally kept the latencies passed to the QTG _DSM in picoseconds in effect. Commit 51293c565cf4 ("cxl: Fix incorrect region perf data calculation") normalized CDAT and host bridge latencies to nanoseconds, but did not add a conversion back to picoseconds when constructing the _DSM input. Firmware can therefore select QTG IDs using understated latencies. Convert the latencies to picoseconds when constructing the _DSM input package. Multiply in 64 bits and reject latencies that cannot fit in the DWORD inputs defined by the specification. Fixes: 51293c565cf4 ("cxl: Fix incorrect region perf data calculation") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Alison Schofield Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20261009045452.1107921-4-den@valinux.co.jp Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 55100d888db016a361b35bf73663ff6d412765d8 Author: Koichiro Den Date: Fri Oct 9 13:54:51 2026 +0900 cxl: Account for link width in latency calculation [ Upstream commit db4503d4575cdd2fad7e8a13a8a8ffcbc86d152d ] cxl_pci_get_latency() derives bandwidth from the per-lane speed returned by pcie_link_speed_mbps(), ignoring the negotiated link width. This overestimates the FlitLatency contribution for multi-lane links. Sections 2.11.3 and 2.11.4 of the Intel CXL Memory Device Software Guide describe the link bandwidth as the product of the negotiated speed and width. Replace pcie_link_speed_mbps() with pcie_link_bandwidth_mbps() and migrate both CXL callers (the only users of the API). The new helper obtains speed and width from a single Link Status read. The CXL bandwidth calculation no longer needs a separate width read and multiplication. While at it, make error handling more robust by converting PCI config read errors to negative errno values and checking for zero bandwidth before calculating latency. Fixes: 4d07a05397c8 ("cxl: Calculate and store PCI link latency for the downstream ports") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Alison Schofield Acked-by: Bjorn Helgaas # pci/pci.c Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20261009045452.1107921-3-den@valinux.co.jp Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 03702f7e1bc08aa470dadc8e0bac5bba82c987b8 Author: Koichiro Den Date: Fri Oct 9 13:54:50 2026 +0900 cxl/port: Convert PCIe link latency to nanoseconds [ Upstream commit 16440d6e4bf1175cda83438d9f9a8ae84bfcf0ee ] Commit 51293c565cf4 ("cxl: Fix incorrect region perf data calculation") converted CDAT latencies to nanoseconds and removed the conversion in cxl_region_perf_data_calculate(), but left PCIe link latencies in picoseconds. This inflates the FlitLatency contribution to region and node latencies by a factor of 1000, exposing incorrect values in sysfs. The resulting abstract distances can incorrectly reverse the memory tier ordering of nodes. Convert the FlitLatency contribution to nanoseconds before adding it to the access coordinates, rounding up as cdat_normalize() does. Fixes: 51293c565cf4 ("cxl: Fix incorrect region perf data calculation") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Alison Schofield Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20261009045452.1107921-2-den@valinux.co.jp Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 82e475e6f6743a92a25629a49e766ec2e3f0db03 Author: Seongjun Hong Date: Mon Oct 5 16:16:29 2026 +0000 vfio/mlx5: Fix boundary check in set_report_output() [ Upstream commit 37b2ee6747b7857920ebc71eabc25208a39164a4 ] Use > instead of >= on boundary check of recv_buf to avoid the bug which the full message in the last slot of recv_buf is ignored even though the received data size does not overflow the recv_buf. Fixes: 9c7c5430bca3 ("vfio/mlx5: Align the page tracking max message size with the device capability") Cc: stable@vger.kernel.org Reviewed-by: Yishai Hadas Signed-off-by: Seongjun Hong Link: https://lore.kernel.org/r/20261005-vfio-mlx5-fix-boundary-check-v2-1-75599d2f4497@snu.ac.kr Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit a2c1a0040b943e3ea9031d5227abefcd48167ddc Author: Xiaofeng Yuan Date: Thu Sep 17 20:20:12 2026 +0800 RISC-V: KVM: Fix IPI delivery for out-of-order vcpu_id [ Upstream commit c367d3bf721f2bc391d6cfb47f6884e99d563df0 ] The SBI IPI handler walks vCPUs with kvm_for_each_vcpu(), which iterates by vcpu_idx (creation order) rather than vcpu_id order. Since vcpu_id can be assigned out of order by userspace, a vCPU whose hart_bit falls outside the XLEN-bit hart_mask range may be reached before vCPUs the mask actually targets. In that case the handler jumps to "done" and stops sending IPIs, leaving valid target vCPUs without an interrupt. Replace the early "goto done" with "continue" so vCPUs outside the hart_mask range are skipped without aborting the loop. Reproduced with a minimal userspace VMM driving KVM inside a QEMU (RISC-V virt) guest: three vCPUs are created with ids 100, 0, 1 (in creation order) and sbi_send_ipi(hart_mask=bit0, hbase=0) is called from vcpu_id 1. Before this change the IPI is dropped and the ecall returns SBI_ERR_INVALID_PARAM; with this change the IPI is delivered and the ecall returns SBI_SUCCESS. Fixes: 0611f78f83c9 ("riscv: KVM: Fix SBI IPI error generation") Cc: stable@vger.kernel.org Suggested-by: Andrew Jones Signed-off-by: Xiaofeng Yuan Reviewed-by: Nutty Liu Reviewed-by: Troy Mitchell Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260917122012.2577-1-yuanxiaofeng@eswincomputing.com Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit 07fc8d43742a0e5a6f114c39999112ea165bfa51 Author: Ross Lagerwall Date: Tue Oct 6 17:34:07 2026 +0100 xen-blkfront: Fix IO race during unplug [ Upstream commit 61b6d1df1d6234c38a6ea7e4f58e7da035ef6ab4 ] During unplug, blkfront stops the hw queues and marks the disk as dead, then later during removal calls del_gendisk(). However, IO issued after the hw queues are stopped but before the call to del_gendisk() will be queued but never handled. This causes del_gendisk() to hang forever waiting for the queue refcount to drop to zero. This can be reproduced by issuing IO during an artificial delay after stopping the hw queues. Fix this by simply not stopping the hw queues directly. Marking the disk as dead already freezes the queue which prevents new requests being added and it synchronously runs the hw queues to clear anything pending. If the hw queues are stopped when calling blk_mark_disk_dead(), running the hw queues is a no-op and can leave queued requests unprocessed. Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Ross Lagerwall Acked-by: Roger Pau Monné Signed-off-by: Juergen Gross Message-ID: <20261006163411.2583538-1-ross.lagerwall@citrix.com> Signed-off-by: Sasha Levin commit 6575ea340c78380552d9bf62d12cf08d110ccbf9 Author: Zongmin Zhou Date: Fri Oct 2 11:14:48 2026 +0100 slimbus: messaging: fix leaked PM vote on tid allocation failure [ Upstream commit c26cc979e28f5193310e4379e14aa6417375c565 ] In slim_do_transfer(), when a transaction needs a tid and slim_alloc_txn_tid() fails, the function returns directly instead of jumping to slim_xfer_err. The runtime PM vote taken earlier with pm_runtime_get_sync() is then never released, leaving the controller permanently powered up. As txn->tid is still 0 at that point, jumping to slim_xfer_err drops the vote exactly like it is done for other failed transactions. Fixes: d3062a2109309 ("slimbus: messaging: add slim_alloc/free_txn_tid()") Cc: stable@vger.kernel.org Signed-off-by: Zongmin Zhou Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20261002101448.1084691-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b45f578dcff422fff12e31fb23d311445a09f63b Author: Johan Hovold Date: Fri Oct 9 14:32:42 2026 +0200 USB: serial: usb_wwan: fix urb leak on disconnect [ Upstream commit c78dd373b5c56a5a02da591b583c6b48d0d62954 ] Make sure to drop the reference taken by usb_anchor_urb() when removing URBs from the delayed URB anchor to prevent them from leaking when the device is later disconnected. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Reported-by: Wentao Liang Link: https://lore.kernel.org/20260916165608.2085613-1-vulab@iscas.ac.cn Cc: stable@vger.kernel.org # 2.6.32 Cc: Oliver Neukum Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit ba843e090aba07d0e407312ce53bb0a2532c48c0 Author: Michael Wyraz Date: Sun Oct 4 11:43:21 2026 +0200 USB: serial: option: add support for ASR 1286:4e3c modem [ Upstream commit 87c56085bcdfec305f5c350fe1c58a62a7f65843 ] The ASR modem used in the Tuoshi LT22M exposes an RNDIS function on interfaces 0 and 1, a diagnostic port on interface 2, and AT ports on interfaces 3 and 4. Match only the vendor-specific serial interfaces so option does not bind to the RNDIS function. Link: https://lore.kernel.org/all/d12635f9-9706-4dbd-8adb-d673c6a77202@wyraz.de/ Signed-off-by: Michael Wyraz Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 9ae43b66326f38a90617e2d7b1f2e92fbd88894b Author: Reinhard Speyerer Date: Fri Sep 25 14:56:52 2026 +0200 USB: serial: option: add Rolling Wireless RN947R [ Upstream commit 931aad81f3f2d26276fff6b7bda6793267a65725 ] Add Rolling Wireless RN947R 0x9300 compositions: Standard mode: DIAG + ADB + NMEA + MODEM + RMNET + QDSS + ADPL T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=9300 Rev= 0.00 S: Manufacturer=Rolling Wireless S: Product=RN947R S: SerialNumber=xxxxxxxxxxx C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#=21 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#=22 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms QDL mode: T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 12 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=9300 Rev= 0.00 S: Manufacturer=Rolling Wireless S: Product=RN947R S: SerialNumber=xxxxxxxxxxx C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 2mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=10 Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Reinhard Speyerer Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit c762a9171a22ba67fb821bba95cc28c4383ae9c4 Author: Johan Hovold Date: Fri Oct 9 14:29:34 2026 +0200 USB: cdc-acm: fix urb leak on disconnect [ Upstream commit 648b08aa37c1b24a61662ad78964f2bca659ca26 ] Make sure to drop the reference taken by usb_anchor_urb() when removing URBs from the delayed URB anchor to prevent them from leaking when the device is later disconnected. Fixes: 140cb81ac8c6 ("USB: cdc-acm: fix broken runtime suspend") Reported-by: Wentao Liang Link: https://lore.kernel.org/20260917161217.2161883-1-vulab@iscas.ac.cn/ Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20261009122934.464142-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e3652a5d4cd7726fa4805c2d7890643cd22be2a9 Author: Jesse Zhang Date: Fri Oct 9 18:33:39 2026 +0800 drm/ttm: return an error when kmapping a BO without pages [ Upstream commit fd485d47437ba1700dd47205a63b9f389a00aa36 ] ttm_tt objects for imported sg tables (ttm_bo_type_sg, set up by ttm_sg_tt_init() with TTM_TT_FLAG_EXTERNAL) only have DMA addresses and no pages array. ttm_bo_kmap() and ttm_bo_vmap() still dereference ttm->pages for them, so a driver that tries to CPU map such a BO oopses instead of getting an error: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ttm_bo_kmap+0x26c/0x300 [ttm] Call Trace: amdgpu_bo_kmap+0x89/0xb0 [amdgpu] amdgpu_userq_fence_read_wptr+0x116/0x170 [amdgpu] amdgpu_userq_signal_ioctl+0x3fe/0xbb0 [amdgpu] Return -EINVAL in that case, like ttm_bo_kmap_try_from_panic() already checks for a missing pages array. Fixes: 75a57669cbc8 ("drm/ttm: add ttm_sg_tt_init") Cc: stable@vger.kernel.org Suggested-by: Christian König Reviewed-by: Christian König Signed-off-by: Jesse Zhang Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20261009103419.4122940-1-Jesse.Zhang@amd.com Signed-off-by: Sasha Levin commit 5b5fc4c1bf4745e208d113cafd3a00d2a3772889 Author: Krzysztof Karas Date: Fri Oct 2 05:33:20 2026 +0000 iommu/dma: Catch scatterlist length overflows [ Upstream commit 1c8f6308e557f32412e9d4678b3f029f47f6d9aa ] It is possible, when a very large mapping uses only one scatterlist, that padding overflows scatterlist's length field. This results in: 1) silently wrapping the value 2) smaller than desired mappings produced by iommu_map_sg 3) leaving mapped bytes in memory (no iommu_unmap) Address this issue by adding overflow detection for scatterlist length field. Fixes: 809eac54cdd6 ("iommu/dma: Implement scatterlist segment merging") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Krzysztof Karas Reviewed-by: Robin Murphy Reviewed-by: Sebastian Brzezinka Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit af2942d92a3201e1c36121155377503423753471 Author: Wentao Liang Date: Wed Sep 16 17:11:41 2026 +0000 xen-pciback: Fix pcistub_device ref leak in pcistub_get_gsi_from_sbdf() [ Upstream commit cfaf31becde901f7a2376d36db628f8be0bc7283 ] pcistub_get_gsi_from_sbdf() obtains the stub device with pcistub_device_find(), which returns it with its kref incremented, and returns psdev->gsi without dropping that reference again. The caller cannot release it either, so every lookup leaks one reference to the stub device. Release the reference after reading gsi. Fixes: 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Juergen Gross Reviewed-by: Jiqian Chen Signed-off-by: Juergen Gross Message-ID: <20260916171141.2086627-1-vulab@iscas.ac.cn> Signed-off-by: Sasha Levin commit a2d3398e3a67d0bab64e16fc72b4ee460c275f92 Author: Yehyeong Lee Date: Tue Oct 6 11:34:43 2026 +0900 xen/pcifront: check that an AER callback exists before calling it [ Upstream commit 3b4854b69ee70fffb2fa7acac09e715a7efcbae1 ] pcifront_common_process() handles an AER request from the backend by dispatching on aer_op.cmd to the bound driver's PCI error handler. It only checks that err_handler and err_handler->error_detected are present, then for the mmio_enabled, slot_reset and resume commands it calls the corresponding callback unconditionally. Those three callbacks are optional -- the PCI core NULL-checks each of them individually before use -- and many drivers (for example igb, igc, ice and ixgbevf) install error_detected without all of them. aer_op.cmd comes from the shared ring, so a malicious or buggy backend can send XEN_PCI_OP_aer_mmio (or _slotreset/_resume) for a device whose driver leaves that callback NULL and make the frontend call through a NULL pointer, crashing the guest. Check each callback before calling it. When mmio_enabled or slot_reset is absent, return PCI_ERS_RESULT_RECOVERED so recovery proceeds, as the PCI core does for a missing callback; returning PCI_ERS_RESULT_NONE would instead make xen-pciback tear the guest domain down. Fixes: 956a9202cd12 ("xen-pcifront: Xen PCI frontend driver.") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Reviewed-by: Juergen Gross Acked-by: Bjorn Helgaas Signed-off-by: Juergen Gross Message-ID: <20261006023443.338194-1-yhlee@isslab.korea.ac.kr> Signed-off-by: Sasha Levin commit 79ec674264e29993162394b8d2fcdbcab6be1e44 Author: Koichiro Den Date: Fri Aug 21 17:41:12 2026 +0900 xen/privcmd: Only claim ioreqs matching an ioeventfd [ Upstream commit 908019e5999161ca89da310c05ddbf7fc89c129e ] The ioeventfd handler shares its event channel with the userspace device model. It must only claim requests that match a registered ioeventfd. Other requests are left for userspace. ioeventfd_interrupt() currently marks every MMIO write INPROCESS before looking for a match. For an unmatched request it drops the lock and restores READY. Userspace may see INPROCESS and skip it. Restoring READY does not send another notification. If userspace handles the request at the same time, the READY store may overwrite its state. Find a matching ioeventfd before changing the request state. The lock now protects only the ioeventfd list. Use explicit virt_*mb() barriers for the ioreq shared with Xen. Fixes: f0d7db7b3324 ("xen: privcmd: Add support for ioeventfd") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260821084112.2374949-1-den@valinux.co.jp> Signed-off-by: Sasha Levin commit af6c94650761ee506f069e5a9150cae7c6f4d1cc Author: Myeonghun Pak Date: Fri Oct 2 15:48:02 2026 -0400 soc: fsl: dpio: Free the IRQ before releasing the I/O object [ Upstream commit a7831c657c90e8f9165f6bbe0cc56262fee075e8 ] The DPIO interrupt handler accesses priv->io, but dpaa2_dpio_remove() releases that object before tearing down the interrupts. The IRQ was requested with devm_request_irq(), and unregister_dpio_irq_handlers() only clears its affinity hint. fsl_mc_free_irqs() returns IRQ resources to the MC resource pool without freeing the handler. An interrupt can therefore access the freed I/O object before devres releases the IRQ. Explicitly free the managed IRQ in unregister_dpio_irq_handlers() before returning its resource to the pool, and perform IRQ teardown before releasing the I/O object. This also waits for an in-flight handler while the object is still valid. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 993fec7e11ca ("bus: fsl-mc: dpio: add the DPAA2 DPIO object driver") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Ioana Ciornei Link: https://lore.kernel.org/r/20261002194802.375497-3-mhun512@gmail.com Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit 227c101eb5fe1ed1c2df5a6812f1150997c909e1 Author: Myeonghun Pak Date: Fri Oct 2 15:48:01 2026 -0400 soc: fsl: dpio: Fix cleanup on IRQ registration failure [ Upstream commit 45ecea8c55521d424513178fb612cefffb09a9f5 ] IRQ registration happens after dpaa2_io_create(), but its failure path only releases the IRQ resources and the MC portal. The I/O object stays allocated and published in the service list and per-CPU lookup table, while devres unmaps its portal registers after probe fails. Call dpaa2_io_down() on IRQ registration failure to remove the object from those lookup structures and free it. Reorder the error labels so that a failed dpaa2_io_create() still skips this cleanup. Remove unregister_dpio_irq_handlers() from the probe error path, since no IRQ handler or affinity hint has been installed when registration fails. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: fe8fe7723a3a ("soc: fsl: dpio: register dpio irq handlers after dpio create") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Ioana Ciornei Link: https://lore.kernel.org/r/20261002194802.375497-2-mhun512@gmail.com Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit bc9b557bff30d005cc92de4ba58425c461890ebc Author: Wentao Liang Date: Thu Sep 17 15:27:19 2026 +0000 soc: fsl: cpm1: tsa: Fix clock leak in tsa_of_parse_tdms() [ Upstream commit 46201d760c48e771fa2febfcb0787f22c3b71387 ] The error cleanup loop puts l1rsync_clk and l1rclk_clk a second time and never puts l1tsync_clk or l1tclk_clk, because the branches that guard the transmit clocks use the receive clock field names. Use the matching field in each branch so every clock acquired by tsa_of_parse_tdms() is released exactly once. Fixes: 1d4ba0b81c1c ("soc: fsl: cpm1: Add support for TSA") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Herve Codina Link: https://lore.kernel.org/r/20260917152719.2160395-1-vulab@iscas.ac.cn [chleroy: Fixed the same in tsa_remove()] Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit 021d9c95a79b55cd21ae085a8e919b251a329b3d Author: Abdifatah Suruur Date: Wed Aug 19 11:42:17 2026 +0300 xen/gntdev: prevent private mappings from becoming writable [ Upstream commit 2176dea8d8c19cb43a9b3651bfa1cb21eab1b31a ] gntdev_mmap() rejects writable private (non-shared) mappings of foreign grant pages, because a private writable mapping takes the COW path on pages that have no proper struct-page backing. However, VM_MAYWRITE is left set, so userspace can map the grant read-only and then upgrade the mapping to writable with mprotect(), hitting the same COW path the check was written to prevent. Clear VM_MAYWRITE for private mappings, as i915 does for its read-only objects and as fixed in drm/vc4 (CVE-2026-68445) and drm/panthor (CVE-2024-53071) and ptp: vmclock (commit a5edadbae57e2298a56cf7a4e774a027905a331f). Fixes: ab31523c2fcac ("xen/gntdev: allow usermode to map granted pages") Cc: stable@vger.kernel.org Signed-off-by: Abdifatah Suruur Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260819084217.1577-1-suruurism@gmail.com> Signed-off-by: Sasha Levin commit 73b6bb619fec82244d04e789c23820e4e6bf28e1 Author: Wentao Liang Date: Tue Sep 15 05:56:31 2026 +0000 clk: imx: Fix clock reference leak in imx_obtain_fixed_clock_hw() [ Upstream commit 52d4d1b26a5bc64de95099d0a3dd8b90dba1f3a3 ] imx_obtain_fixed_clock_hw() obtains the clock through imx_obtain_fixed_clock_from_dt(), which creates a consumer reference via of_clk_get_from_provider(). The reference is discarded right after __clk_get_hw() returns the hardware pointer, leaking it. Keep the imx_clk_fixed() fallback unchanged and drop the DT-obtained consumer reference with clk_put() once the hardware pointer has been extracted. Fixes: a4a4069f4523 ("clk: imx: Add imx_obtain_fixed_clock clk_hw based variant") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260915055631.1730231-1-vulab@iscas.ac.cn Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 6dccb760c44c141ecaa74fdcb4cb3e71d1cb9b15 Author: Wentao Liang Date: Tue Sep 15 05:55:15 2026 +0000 clk: imx: Fix clock reference leak in imx_get_clk_hw_by_name() [ Upstream commit 8e177ca735761a1f03e1dedffd7ab00d6d0540ae ] imx_get_clk_hw_by_name() obtains a consumer clock with of_clk_get_by_name(), extracts the hardware pointer with __clk_get_hw() and returns it without ever calling clk_put(), leaking the consumer reference on both return paths. Extract the hardware pointer first and drop the clock reference with clk_put() before returning. Fixes: 3b315214e091 ("clk: imx: implement new clk_hw based APIs") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260915055515.1730145-1-vulab@iscas.ac.cn Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 1799ae79881c239a8fbb795e833b7c6529a43058 Author: Longlong Xia Date: Sun Sep 6 21:59:38 2026 +0800 mm/zswap: enable zswap_ever_enabled in zswap_pool_create() [ Upstream commit 91b4edb993e1549afdc3c2495216734b9f13f00e ] If zswap is enabled by default at boot and pool creation fails, then a pool is later created by updating the compressor, data written to zswap is corrupted on swapin. Enable the static key in zswap_pool_create(), covering boot-time and runtime pool creation with a single site. Verified with fault injection on a stock kernel (compressor builtin, CONFIG_ZSWAP_DEFAULT_ON=n): 1. Boot with zswap.enabled=1; pool creation fails, init completes pool-less (static key off). 2. Echo an available compressor name to zswap.compressor. 3. Enable zswap. 4. madvise(MADV_PAGEOUT) a pattern-verified 512 MiB region, then fault it back in and verify. Step 4 reads back 131072/131072 zeroed pages (zswpin=0, zswpout=131072) without this patch; all pages intact (zswpin=131072) with it. Link: https://lore.kernel.org/20260906135938.3568108-1-xialonglong2025@163.com Fixes: 2d4d2b1cfb85 ("mm: zswap: add zswap_never_enabled()") Signed-off-by: Longlong Xia Signed-off-by: Andrew Morton Suggested-by: Yosry Ahmed Acked-by: Yosry Ahmed Assisted-by: Zcode:GLM-5.3 Cc: Chengming Zhou Cc: Johannes Weiner Cc: Nhat Pham Cc: Signed-off-by: Sasha Levin commit c732ac8f5a772319586e25b33739b55ace82db64 Author: Anastasios Papagiannis Date: Wed Sep 9 09:42:31 2026 +0300 mm/nommu: reject wrapping ranges in access_remote_vm() [ Upstream commit 51a8de81fd2edbf87d8046e352060329bb216fad ] The NOMMU implementation of access_process_vm() rejects address ranges whose end wraps around, but access_remote_vm() bypasses this check even though both functions delegate to __access_remote_vm(). Move the wraparound check into __access_remote_vm() so it applies to both entry points. This is originally reported in [1]. Link: https://lore.kernel.org/20260909064231.18693-1-tasos.papagiannnis@gmail.com Fixes: f55f199b7d76 ("NOMMU: implement access_remote_vm") Signed-off-by: Anastasios Papagiannis Signed-off-by: Andrew Morton Closes: https://lore.kernel.org/bpf/4ef240a5bea36ff84df9589671367832860795159386a4c8fba546a0fa8b786f@mail.kernel.org/ [1] Reviewed-by: Lorenzo Stoakes (ARM) Cc: Liam R. Howlett Cc: Hajime Tazaki Cc: Signed-off-by: Sasha Levin commit 8b4800ff31c956d4f4bd45b371e5b9e733a95401 Author: Yogesh Gaur Date: Tue Oct 6 17:59:04 2026 +0530 md: don't hand out the array before md_alloc() has added mddev->kobj [ Upstream commit d1472ca2ca5de8ecd2b358411eb14c031404ecf0 ] md_alloc() publishes the gendisk before it is done setting the mddev up: disk->private_data = mddev; ... error = add_disk(disk); if (error) goto out_put_disk; kobject_init(&mddev->kobj, &md_ktype); error = kobject_add(&mddev->kobj, &disk_to_dev(disk)->kobj, "%s", "md"); add_disk() makes /dev/mdN openable. mddev comes from mddev_alloc() and is zeroed, so anything that gets in between add_disk() and kobject_add() sees an mddev->kobj that has never been through kobject_init() - no ktype, no kref, state_initialized clear. syzbot opens the array in that window and issues ADD_NEW_DISK: kobject: '(null)' (ffff8880120640f0): is not initialized, yet kobject_get() is being called. WARNING: lib/kobject.c:642 at kobject_add_internal+0xea/0xcd0 lib/kobject.c:225 kobject_add_varg lib/kobject.c:374 [inline] kobject_add+0x163/0x240 lib/kobject.c:426 bind_rdev_to_array+0x80c/0xdd0 drivers/md/md.c:2621 md_add_new_disk+0xe3b/0x1850 drivers/md/md.c:7684 md_ioctl+0x200a/0x2610 drivers/md/md.c:8499 bind_rdev_to_array() is not the only way in. md_run() calls sysfs_create_group(&mddev->kobj, &md_redundancy_group), and internal_create_group() has its own WARN_ON(!kobj->sd), so RUN_ARRAY in the same window warns too. Every ioctl that can reach mddev->kobj runs under reconfig_mutex, so hold it across add_disk() and kobject_add(). An ioctl issued in the window now waits for md_alloc() to finish instead of seeing a half-built mddev, and opening the array still succeeds. The ioctls md_ioctl() serves without the mutex only read array state and return -ENODEV on an array with no disks. Hoisting kobject_init() above add_disk() is not an option: commit ca39f7502425 ("md: fix mddev->kobj lifetime") moved it below add_disk() so that md_alloc()'s error paths, which free the mddev directly, never see an initialised kobject. Fixes: ca39f7502425 ("md: fix mddev->kobj lifetime") Reported-by: syzbot+95eeb4ada2349a2170ea@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6aaf3284.514bccd6.255447.0003.GAE@google.com/ Suggested-by: Yu Kuai Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Yogesh Gaur Link: https://patch.msgid.link/20261006122904.1538-1-yogeshgaur.83@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit dc171da15e46871abac4c05b389730883c15f680 Author: Jake Labelle Date: Thu Oct 8 20:52:48 2026 +0900 nilfs2: validate directory position after llseek in readdir [ Upstream commit de7f49c12566cc5c7437a2f26c6c754b9d4d5648 ] nilfs_readdir() uses ctx->pos, which userspace can set to an arbitrary value via llseek, as an offset into the directory folio and parses whatever bytes sit there as a directory entry. A position pointing into the middle of an entry -- or at unused bytes of a corrupted image that the page validator never inspected -- makes dir_emit() copy up to 255 (name_len) bytes from a bogus entry, possibly reading past the end of the folio and returning unrelated memory contents to userspace. Snap unaligned positions onto a valid entry boundary by walking the rec_len chain from the chunk start before parsing, as ext2 does in ext2_validate_entry(). [ryusuke: fixed offset wrap-around in nilfs_validate_entry() and conformed AI tag to guidelines] Fixes: 2ba466d74ed7 ("nilfs2: directory entry operations") Assisted-by: Claude:claude-mythos-5 Signed-off-by: Jake Labelle Cc: stable@vger.kernel.org Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit cd24b217717f152195de4abf8272ea1ef2a7c4be Author: Jinjie Ruan Date: Wed Sep 2 15:48:04 2026 +0800 ext4: fix out-of-bounds read in ext4_get_group_info() [ Upstream commit b067d3c1f90b536e9aa9f48b19580475a0b34f0f ] A plain read of s_groups_count in ext4_get_group_info() allows CPU load-load reordering. On weak memory models, speculative prefetch of s_group_info prior to the boundary check could lead to an out-of-bounds read if a concurrent online resize expands the array and increments s_groups_count. The data race occurs between the ioctl configuration path (holding the resize lock via ext4_resize_begin) and the lockless metadata lookup path: CPU 0 (Writer, Resize Lock) CPU 1 (Reader, Lockless) --------------------------- ------------------------ ext4_ioctl() [EXT4_IOC_GROUP_ADD] ext4_ioctl_group_add() ext4_resize_begin() // Takes lock ext4_group_add() ext4_mb_alloc_groupinfo() // Publishes expanded array via RCU rcu_assign_pointer(s_group_info, ...) ext4_flex_group_add() ext4_update_super() ext4_get_group_info() // Speculative / out-of-order read [Loads old/smaller s_group_info pointer] [Plain C store / smp_wmb()] sbi->s_groups_count += ...; // Reads new s_groups_count, // boundary check passes if (group >= s_groups_count) // Out-of-bounds array access! sbi_array_rcu_deref(..., s_group_info) Fix this by using ext4_get_groups_count() to enforce acquire semantics. Cc: stable@vger.kernel.org Cc: "Theodore Ts'o" Cc: Andreas Dilger Cc: Baokun Li Cc: Jan Kara Cc: Ojaswin Mujoo Cc: "Ritesh Harjani (IBM)" Cc: Zhang Yi Fixes: 5354b2af3406 ("ext4: allow ext4_get_group_info() to fail") Link: https://sashiko.dev/#/patchset/20260825095422.3166067-1-ruanjinjie%40huawei.com Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Signed-off-by: Jinjie Ruan Link: https://patch.msgid.link/20260902074805.398540-8-ruanjinjie@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit e1e121346bc897f00254b0d6fb9e75faa9af5484 Author: Sergey Senozhatsky Date: Thu Aug 27 21:50:20 2026 +0900 ext4: fix ABBA deadlock in ext4_rmdir() [ Upstream commit 19e16597f9baf1b5719a3a6c710486446f6808fd ] We observe the following ABBA deadlock (casefolding enabled): INFO: task jbd2/dm-13-8:447 blocked for more than 720 seconds. task:jbd2/dm-13-8 state:D stack:0 pid:447 tgid:447 ppid:2 Call Trace: __schedule+0xc2c/0xe60 schedule+0x40/0xe0 jbd2_journal_wait_updates+0x8f/0xf0 jbd2_journal_commit_transaction+0x321/0x1850 kjournald2+0xa9/0x230 kthread+0x226/0x2a0 ret_from_fork+0x101/0x1e0 ret_from_fork_asm+0x1a/0x30 INFO: task Thread-10:4161 blocked for more than 720 seconds. task:Thread-10 state:D stack:0 pid:4161 tgid:3848 ppid:540 Call Trace: __schedule+0xc2c/0xe60 schedule+0x40/0xe0 wait_transaction_locked+0x8c/0xd0 start_this_handle+0x252/0x870 jbd2__journal_start+0x120/0x280 __ext4_journal_start_sb+0x11a/0x250 ext4_evict_inode+0x208/0x760 iput+0x222/0x5c0 dput+0x293/0x690 ____fput+0x145/0x2b0 task_work_run+0x7a/0xb0 exit_to_user_mode_loop+0xc0/0xd0 do_syscall_64+0x14b/0xf10 entry_SYSCALL_64_after_hwframe+0x76/0x7e NMI backtrace for cpu 0 CPU: 0 UID: 1010216 PID: 4160 Comm: Thread-7 RIP: 0010:d_walk+0x0/0x290 [..] Call Trace: shrink_dcache_parent+0xb2/0x100 d_invalidate+0x50/0x110 ext4_rmdir+0x3a2/0x3d0 vfs_rmdir+0x9d/0x1d0 do_rmdir+0xf0/0x330 __x64_sys_unlinkat+0x34/0x50 do_syscall_64+0x61/0xf10 The problem is that ext4_rmdir() calls d_invalidate() before stopping the jbd2 transaction handle. Because d_invalidate() traverses child dentries it can encounter dying or in-use dentries. If a concurrent thread executing __dentry_kill() on a child dentry invokes ext4_evict_inode(), it requests a new transaction handle via ext4_journal_start(), which waits for all running handles to close. However, the thread executing ext4_rmdir() still holds its active transaction handle while looping in shrink_dcache_parent() waiting for the dying child dentry to complete eviction. Stop transaction handle in ext4_rmdir() before calling d_invalidate(). Cc: stable@kernel.org Fixes: b886ee3e778e ("ext4: Support case-insensitive file name lookups") Co-developed-by: Sarthak Kukreti Signed-off-by: Sarthak Kukreti Signed-off-by: Sergey Senozhatsky Reviewed-by: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20260827125158.4030598-1-senozhatsky@chromium.org Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 6b0df768ac5e3442b6f019bc239ddfac8e98f70a Author: Daejun Park Date: Thu Aug 27 17:48:29 2026 +0900 ext4: don't report delalloc data as a hole on indirect-mapped inodes [ Upstream commit aed43f47e1edeee1454eea86006a8c09480e5ed3 ] When a plain lookup finds no block, ext4_ind_map_blocks() sizes the hole it reports by counting the empty subtrees under 'partial' in the on-disk indirect tree. That count knows nothing about delayed allocation, so a range holding delalloc data that has not been written back yet is reported as a plain hole. The extent-mapped path does not have this problem: it trims the hole it found at the first delayed extent before returning it. ext4_map_blocks() consults the extent status tree before it calls into the mapping layer, so a query that starts exactly on the delayed block still finds it. A query that starts earlier does not, because the hole reported for the earlier block already spans the delayed one. On a 4k-block filesystem, lseek(SEEK_DATA) from offset 0 on a file whose only data block is at logical block N and is still dirty returns: N = 0..11 direct blocks N << 12 N = 12 first single-indirect block N << 12 N = 13..1035 inside that indirect block -1 ENXIO N = 1036 first double-indirect block N << 12 Blocks 12 and 1036 survive because the query lands on the delayed block itself. Blocks 13..1035 are swallowed by the 1024-block hole reported for block 12. fiemap loses the same data for the same reason. An ext3 filesystem mounted as ext4 hits this during ordinary use: ext3 inodes stay indirect mapped, while mount -t ext4 turns on delayed allocation even though mounting ext3 with -o delalloc is explicitly rejected. install(1) from coreutils uses SEEK_DATA to locate data in its source file, so installing a sparse file that has not been written back silently produces a destination of the right size holding none of the data: truncate -s 1G img && mkfs.ext3 -F img && mount -t ext4 img mnt echo | dd of=mnt/src bs=1 count=1 seek=64K install mnt/src mnt/dst cmp mnt/src mnt/dst # differ: char 65537 Reconciling a hole with the extent status tree does not depend on how the hole was found, so instead of open coding it a second time, split the delalloc handling out of ext4_ext_determine_insert_hole() into ext4_determine_insert_hole(), which takes the hole the caller located, and call that from ext4_ind_map_blocks() as well. All the special cases and the comments explaining them stay in one place. Two things change for indirect-mapped inodes. They now cache the holes they report, as the extent-mapped path already does: ext4_punch_hole() already puts EXTENT_STATUS_HOLE on such inodes, ext4_map_blocks() and ext4_da_map_blocks() already handle a cached hole, the latter by replacing it with the delayed extent, and consecutive hole entries merge, so the tree does not grow with the length of a scan. And when a delayed extent covers the queried block itself - a race, since ext4_map_blocks() found nothing in the tree just before - the hole is now reported only up to the end of that extent instead of in full. The indirect path passes hole_start == lblk, so the "delalloc extent in front of the queried range" case cannot be reached there: __es_tree_search() never returns an extent ending before the block it was searched for. With this the sweep above returns N << 12 for every N, while the nodelalloc and extent-mapped controls are unchanged. generic/225, generic/285, generic/448 and generic/490 pass on ext4 made both with and without the extent feature. generic/286 and generic/436 pass on extent-mapped ext4 and are skipped without it, since they need fallocate. Fixes: facab4d9711e ("ext4: return hole from ext4_map_blocks()") Reported-by: Alexander Monakov Closes: https://lore.kernel.org/linux-ext4/594c17d9-c00f-e485-96fb-cedf27ce3aa3@ispras.ru/ Suggested-by: Jan Kara Cc: stable@vger.kernel.org Signed-off-by: Daejun Park Reviewed-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20260827084829epcms2p6ecc0c39a71d0c3eebf9cb1ade77314f6@epcms2p6 Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 6d9c2843d61183c4a9573f77d675ccbf8eba3e1e Author: Hemanth Selam Date: Mon Aug 24 15:15:12 2026 +0530 ext4: skip extra isize expansion while unmounting [ Upstream commit 418adcde99032194416248168df810535a1a93f9 ] syzbot reports a WARN from ext4_xattr_inode_create() reached through the unmount path: EXT4-fs warning (device loop0): ext4_xattr_inode_create:1485: refuse to create EA inode when umounting WARNING: fs/ext4/xattr.c:1486 at ext4_xattr_inode_lookup_create ext4_xattr_block_set ext4_expand_extra_isize_ea __ext4_expand_extra_isize __ext4_mark_inode_dirty ext4_dirty_inode __mark_inode_dirty sync_lazytime iput dentry_kill shrink_dentry_list shrink_dcache_for_umount generic_shutdown_super kill_block_super ext4_kill_sb shrink_dcache_for_umount() clears s_root before generic_shutdown_super() clears SB_ACTIVE, so during the dcache shrink the last iput() of a lazytime inode still redirties it and reaches the isize expansion. The expansion can move xattrs out to a block, and creating the EA inode for them needs s_root, which ext4_xattr_inode_create() refuses without. ext4_try_to_expand_extra_isize() already declines to expand when the superblock is not active, but that test does not cover this window. Decline while s_root is gone as well. The expansion is best effort and __ext4_mark_inode_dirty() ignores its return value, so nothing else changes; the inode can be expanded on a later mount. Running the syzbot reproducer for 60 seconds produced 3583 splats before this change and none after it, with the same number of mount cycles. Cc: stable@kernel.org Reported-by: syzbot+4b03894b6ec5753ddf24@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4b03894b6ec5753ddf24 Fixes: f31173c19901 ("ext4: refuse to create ea block when umounted") Signed-off-by: Hemanth Selam Reviewed-by: Jan Kara Reviewed-by: Jun Nie Link: https://patch.msgid.link/20260824094512.2436628-1-hemanth.selam@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 65185848035e2c6b8561c8afeb8ef0098fb18c21 Author: Daejun Park Date: Wed Aug 19 15:09:39 2026 +0900 jbd2: don't advance j_fc_off before the buffer is recorded [ Upstream commit 9f359c031885bb50add7d23c7a5a0e9755b134c9 ] jbd2_fc_get_buf() increments journal->j_fc_off before jbd2_journal_bmap() and __getblk() have had a chance to fail. When either does, the slot j_fc_wbuf[fc_off] is never assigned, but j_fc_off already counts it. ext4 then fails the fast commit and falls back, and the fallback path reaches jbd2_fc_release_bufs() via ext4_fc_commit -> jbd2_fc_end_commit_fallback -> __jbd2_fc_end_commit -> ext4_fc_cleanup. That walks down from j_fc_off - 1 and put_bh()es every slot until it sees NULL, so it also touches the slot that was never written. j_fc_wbuf comes from a plain kmalloc() and is never zeroed, so a slot used for the first time holds uninitialised heap data. Advance j_fc_off only after the buffer head has been stored. That restores the invariant that j_fc_off covers exactly the filled slots, which is what jbd2_fc_release_bufs() relies on: the live buffers of the current fast commit sit above the NULLs the previous one released, so stopping at the first NULL is correct. Reproduced on a KASAN kernel with an ext4 fast_commit filesystem on a loop device, truncating the backing file under the live mount so that only the journal's fast-commit region falls past the end of the device. __getblk() then fails for the first fast-commit block while the rest of the journal is still addressable, so the journal is not aborted and the fast commit reaches the fallback path. j_fc_wbuf was poisoned to make the read of the never-written slot visible: BUG: KASAN: wild-memory-access in jbd2_fc_release_bufs+0x6b/0xd0 Write of size 4 at addr 5a5a5a5a5a5a5ab2 by task sync/961 jbd2_fc_release_bufs+0x6b/0xd0 ext4_fc_cleanup+0x97/0x830 __jbd2_fc_end_commit+0x37/0xc0 ext4_fc_commit+0x524/0x560 ext4_sync_file+0x3c4/0x4b0 __x64_sys_fsync+0x20/0x30 With this patch the same run leaves j_fc_off at 0 across repeated __getblk() failures and completes cleanly. Fixes: ff780b91efe9 ("jbd2: add fast commit machinery") Cc: stable@kernel.org Reported-by: Yu Junzhe Closes: https://lore.kernel.org/linux-ext4/7e4b109d-64c3-444f-a5dc-93c2ca4576cc@gmail.com/ Signed-off-by: Daejun Park Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260819060939epcms2p37bb8589b2f8a52a2b14bef38fadcf69d@epcms2p3 Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 0772df264e36c86e4e293d2daef7cac1b7fc549b Author: Hsiu-Hsien Lee Date: Wed Aug 12 12:43:53 2026 +0800 ext4: fix fast commit replay failing on a read-only mount [ Upstream commit e1a881ea4674876721cab97680d1d8308f90e9a4 ] A filesystem with fast_commit that needs recovery cannot be mounted read-only: EXT4-fs (dm-0): INFO: recovery required on readonly filesystem EXT4-fs (dm-0): write access will be enabled during recovery WARNING: CPU: 22 PID: 5544 at fs/ext4/ext4_jbd2.c:73 ext4_journal_check_start __ext4_journal_start_sb __ext4_unlink ext4_fc_replay do_one_pass jbd2_journal_recover jbd2_journal_load __ext4_fill_super JBD2: journal recovery failed EXT4-fs (dm-0): error loading journal Fast commit replay runs ext4 metadata operations instead of writing blocks through the buffer cache: ext4_fc_replay_{unlink,link,create}() reach __ext4_unlink() and __ext4_link(), which start a handle. ext4_journal_check_start() returns -EROFS on a read-only sb, and as that is not -ENOENT it propagates out of jbd2_journal_recover() and kills the whole recovery. The EXT4_FC_REPLAY check that would hand out a no-journal handle sits after the sb_rdonly() test, so replay can never complete read-only. ext4_load_journal() has already promised that write access will be enabled during recovery, so make that true for the superblock as well: clear SB_RDONLY across jbd2_journal_load() when recovery is needed on a read-only mount and the devices are writable, as ext4_orphan_cleanup() does. Unlike ext4_handle_error(), which avoids SB_RDONLY because it would need s_umount, the sb here is still inside ext4_fill_super() and not published, so nothing can observe it. The failure is not clean either: the replay handlers passing a NULL handle (ext4_fc_replay_inode(), _add_range(), _del_range()) never hit ext4_journal_check_start() and do write, leaving a partially applied fast commit behind. Reproducer, where the unlink only ever reaches the fast commit area: mke2fs -q -F -t ext4 -O fast_commit -b 4096 /dev/sdb3 262144 mount /dev/sdb3 /mnt dd if=/dev/zero of=/mnt/victim bs=4k count=1 conv=fsync sync # victim now in a full commit rm /mnt/victim dd if=/dev/zero of=/mnt/trigger bs=4k count=1 conv=fsync mount -o ro /dev/sdb3 /mnt Without this patch that mount fails; with it recovery completes and victim is gone, i.e. the UNLINK record was really replayed. Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Cc: stable@vger.kernel.org Signed-off-by: Hsiu-Hsien Lee Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260812044353.1018268-1-swinds24@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 460792f7ecbcecc94e4d938063d76c555a73c2bb Author: Matthias Goergens Date: Sat Sep 26 10:08:51 2026 +0800 fanotify: report names longer than NAME_MAX [ Upstream commit ff05910cb1b77c2b229c5e6e260c6173a17b579b ] fanotify keeps the length of a reported name in a u8, so it drops any name longer than NAME_MAX and warns: WARNING: fs/notify/fanotify/fanotify.h:217 at fanotify_handle_event+0x2e82/0x39f0 Such names are legitimate on some filesystems. vfat mounted with utf8 takes up to 255 UTF-16 characters, which are up to 765 bytes of UTF-8, and FUSE accepts names up to PATH_MAX - 1. readdir() and inotify report them in full. fanotify sends the event without the name, and for FAN_RENAME it trips a second warning in copy_fid_info_to_user(), after which read() fails with EFAULT and the event is lost. When syzbot hit this, Jan suggested accommodating names up to PATH_MAX [1], the limit readdir() already applies to a name (verify_dirent_name()). Store the name lengths as u16, which keeps struct fanotify_info at 8 bytes, and drop without a warning only names of PATH_MAX bytes or more, which no path can refer to. An event with such a name can exceed a page, so allocate name events with kvmalloc(), as Jan also suggested. Names up to NAME_MAX are reported exactly as before, and the record format is unchanged: an event with a long name is just longer. Link: https://lore.kernel.org/all/20241112115059.ecvomkalee5m4i4i@quack3/ [1] Fixes: 2d9374f09513 ("fanotify: use macros to get the offset to fanotify_info buffer") Cc: stable@vger.kernel.org Signed-off-by: Matthias Goergens Link: https://patch.msgid.link/20260926020851.2938961-1-matthias.goergens@gmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit b4526c0966888aafecead8956910de7318969d48 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Sun Oct 4 14:09:46 2026 +0900 crypto: algif_skcipher - rewind rounded output bytes [ Upstream commit 2f90facc7b94934653eb7ebfadcc25d503b89196 ] af_alg_get_rsgl() advances the receive iterator by the unrounded RX scatterlist length. For a continuing skcipher request, _skcipher_recvmsg() then rounds its local length down to a whole chunksize without restoring the iterator. A later chunk starts after bytes which the provider never wrote, while the syscall returns only the processed length. When copy_splice_read() supplies non-zeroed pages and publishes that return as a dense prefix, the gap exposes stale bytes from a previous page lifetime. With unprivileged xts(aes), a 31-byte MSG_MORE request followed by one final byte advances a 47-byte destination while returning 32 bytes. A hardened v7.2-rc5 image retained all 15 seeded stale bytes in 4,829 of 4,829 records. With init_on_alloc enabled, all 72,345 gap bytes observed were zero. Rewind the iterator by the tail excluded during rounding, before rejecting a zero processed length. The crypto request uses only the rounded length; af_alg_free_resources() releases the entire RX list before another receive iteration. The fixed target-like kernel returned byte-identical dense 48-byte output in 4,771 of 4,771 rounds. The unmodified kernel returned the vulnerable 32-byte short record in 2,409 of 2,409 rounds. Fixes: e870456d8e7c ("crypto: algif_skcipher - overhaul memory management") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 30a328d8a1a0f4ec508343b5fb917b193e24982d Author: Tristan Madani Date: Wed Oct 7 16:17:21 2026 +0000 wifi: rtw89: fix IE length passed to cfg80211_find_ie() in WoW AKM [ Upstream commit 6c17c57d45ef1652d80f79a9834597b25412fd26 ] __rtw89_wow_parse_akm() computes a pointer to the IE area from an association request frame: ies = mgmt->u.assoc_req.variable; but then passes skb->len as the IE data length to cfg80211_find_ie(). Since skb->len covers the entire frame including the 28-byte management header and fixed fields, cfg80211_find_ie() may read past the end of the actual IE data. Fix by computing the correct IE data length as skb->len minus the header offset, and validating the minimum frame length before parsing. Fixes: 92790c4e50d2 ("wifi: rtw89: wow: parsing Auth Key Management from associate request") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20261007161721.261452-3-tristmd@gmail.com Signed-off-by: Sasha Levin commit 2e3cab69425d17e8024d6c45f79c8abd56fd0fd8 Author: Krzysztof Wilczyński Date: Fri Aug 14 07:05:22 2026 +0000 PCI/sysfs: Pass the device name length in UTF-16 code units [ Upstream commit af5ca2d75147bf283239e8ef0fbf6e5e0488ca91 ] Currently, dsm_label_utf16s_to_utf8s() passes the ACPI buffer length to utf16s_to_utf8s() unchanged. The Device Name _DSM may return the device name as a buffer holding a UTF-16 string, and the ACPI length counts bytes while the converter counts wchar_t elements. The converter therefore receives a count twice the number of code units the buffer holds, and that count is its only bound on the input. A NUL code unit ends the conversion early, so a name that carries one is converted correctly and the error stays hidden. ACPICA zeroes the entire result allocation, and the padding placed after the buffer supplies that NUL for most lengths. Lengths that leave no padding, or a single byte of it, do not, and the conversion then runs up to its own length in bytes past the end of the allocation. The bytes beyond the allocation are decoded into the "label" attribute, which is world readable. Divide the buffer length by the size of wchar_t so that the converter receives a count of code units. The division truncates, so the converter is never told to read more bytes than the buffer holds, including for an odd length. Reaching the out of bounds read needs firmware that returns the name as a buffer and omits the terminator. Fixes: 6058989bad05 ("PCI: Export ACPI _DSM provided firmware instance number and string name to sysfs") Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260814070522.2327975-5-kwilczynski@kernel.org Signed-off-by: Sasha Levin commit b625937a77b0e1e3d430f13251adfa60ba7e8a7b Author: Josef Bacik Date: Wed Oct 7 17:52:29 2026 +0000 aoe: pull in the headers each received packet type reads [ Upstream commit e1274a6bc40a4618f6fbaebbdc51cca865d51bed ] aoenet_rcv() only pulls the AoE and ATA headers into the skb head when the packet is long enough to hold both. A shorter packet goes through unpulled, and aoenet_rcv() reads the AoE header from it anyway. CFG responses go on to aoecmd_cfg_rsp(), which reads the config header after it, and ATA responses get queued for ktiocomplete(), which skb_pull()s both headers. Ethernet pads frames to 60 bytes, so this mostly takes a virtual link, but nothing stops a short frame from getting here. Pull the AoE header up front and drop the packet if it isn't there, then pull the ATA or config header in the switch arm that hands the packet on, so each path gets the headers it reads. This also replaces the open-coded __pskb_pull_tail() with pskb_may_pull(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261007-b4-aoe-short-packets-v1-1-db5155f7bb9c@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 93606b4dbd3718dc021ba804710dccefbb74120d Author: Wentao Liang Date: Tue Sep 15 04:52:42 2026 +0000 clocksource/drivers/digicolor: Fix clk reference leak on request_irq failure [ Upstream commit 9cc2e18b32f12d26ae6729c62a03640423956b17 ] digicolor_timer_init() obtains the timer clock with of_clk_get() and enables it, but the request_irq() failure path returns without releasing the clock reference, leaking both the enable/prepare state and the reference itself. Disable and put the clock before returning on the request_irq() failure path. The success path keeps the clock enabled for the lifetime of the timer and is left untouched. Fixes: 9b8bb7736b78 ("clocksource: Driver for Conexant Digicolor SoC timer") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Daniel Lezcano Acked-by: Baruch Siach Link: https://patch.msgid.link/20260915045242.1726702-1-vulab@iscas.ac.cn Signed-off-by: Sasha Levin commit 3961a3e1962304a0c62f6392fc5b5c7525038965 Author: Wentao Liang Date: Tue Sep 15 04:54:26 2026 +0000 clocksource/drivers/fttmr010: Fix clk reference leak in error paths [ Upstream commit 277e5657237a92e279ee28da2f5c07902cc6aa0b ] fttmr010_common_init() obtains the PCLK reference with of_clk_get_by_name() but never calls clk_put(). If clk_prepare_enable() fails the reference is leaked directly, and every error path that jumps to out_disable_clock only calls clk_disable_unprepare(), which releases the prepare/enable state but not the reference obtained from of_clk_get_by_name(). Add clk_put() to the clk_prepare_enable() failure path and to the out_disable_clock label so the clock reference is no longer leaked. The success path keeps PCLK enabled for the lifetime of the timer and is left untouched. Fixes: dd98442e17a6 ("clocksource/drivers/fttmr010: Drop Gemini specifics") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Daniel Lezcano Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260915045426.1726805-1-vulab@iscas.ac.cn Signed-off-by: Sasha Levin commit 6ad3d0170c3e475cc617805b93cb4904f42df109 Author: Wentao Liang Date: Thu Sep 17 12:19:44 2026 +0000 wifi: mt76: Fix of_node reference leak in mt76_get_rate_power_limits() [ Upstream commit 8d604c899f7bd1a76a2eb21c0b706c02878abd36 ] mt76_find_power_limits_node() and mt76_find_channel_node() return nodes with the reference held, but mt76_get_rate_power_limits() overwrites the "txpower-" node reference and never releases the channel node reference, leaking both. Drop the intermediate and the channel node reference on every exit path, and take a reference on the fallback node returned by mt76_find_power_limits_node() so the caller's of_node_put() is balanced. Fixes: 22b980badc0f ("mt76: add functions for parsing rate power limits from DT") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917121944.2150737-1-vulab@iscas.ac.cn Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ad3650b9dae6ea86420122c76c5012a685e66c02 Author: Jiale Yao Date: Sun Sep 27 18:10:40 2026 +0800 wifi: mt76: mt7615: cancel reset work during unregister [ Upstream commit 5b779c63fb1e20e6729d3241b78be7502759296d ] The MCU error interrupt handler queues reset_work on the device workqueue. Device removal can reach mt76_unregister_device() while that work is still pending, since the workqueue is not destroyed until mt76_free_device(). If reset_work runs in this window, it operates on an unregistered hw and can requeue mac_work after ieee80211_unregister_hw() has torn the device down. Cancel it before unregistering the device so it cannot outlive the registered hw. Fixes: 61c4fa721968 ("mt76: mt7615: implement hardware reset support") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Link: https://patch.msgid.link/20260927101041.957362-1-yaojiale02@163.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 659cbdd83fb937cf7452412787ffd49970c55d60 Author: Myeonghun Pak Date: Thu Sep 10 17:54:41 2026 -0400 wifi: mt76: mt7615: restore DBDC state after ext PHY failure [ Upstream commit 7907d5270dc5c13b6a95754c08a77d5b06bbc786 ] mt7615_register_ext_phy() limits the primary PHY to DBDC capabilities before allocating and registering the secondary PHY. If allocation, EEPROM override, or PHY registration fails, it returns without restoring the primary PHY capabilities. The EEPROM override failure also leaks the newly allocated ieee80211_hw. Route all failures through common labels that free the secondary hardware when it was allocated and restore the primary PHY capabilities. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 0f2173f093b3 ("mt76: mt7615: add support for registering a second wiphy via debugfs") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260910215441.76683-1-mhun512@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5bbfc1573665571ea59a193d40543885cc28619c Author: Eason Lai Date: Mon Sep 14 10:19:20 2026 +0800 wifi: mt76: fix memory leak in USB TX path [ Upstream commit 82856da2d3b6a30011f4db6ea5f34c13484e0ef8 ] When errors occur in mt76u_tx_queue_skb(), the skb is not properly freed, leading to memory leaks. This happens when: - The queue is full - tx_prepare_skb() drops zero-length frames (such as WMM NULL frames) to prevent hardware TX hangs - Buffer setup fails Fix by properly releasing the skb with ieee80211_tx_status_ext() when the queue is full or tx_prepare_skb() fails, and using mt76_tx_complete_skb() when mt76u_tx_setup_buffers() fails (since tx_prepare_skb() has already succeeded and may have allocated resources that need cleanup) Fixes: b40b15e1521f ("mt76: add usb support to mt76 layer") Cc: stable@vger.kernel.org Tested-by: Devin Wittmayer Closes: https://github.com/morrownr/mt76/issues/83 Signed-off-by: Eason Lai Tested-by: Hans Buchheim Reported-by: Sergei Melnichenko Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260914021920.32246-3-eason.lai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0d35a2922d2cb2a78038d3923a3e18cef97c01f7 Author: Eason Lai Date: Mon Sep 14 10:19:19 2026 +0800 wifi: mt76: mt792x: fix UAF in SDIO TX path when out of memory [ Upstream commit f5dd4833463ed45794027e33928539b3c532f82d ] Using __skb_pad() instead of skb_pad() in mt76_skb_adjust_pad() to prevent double-free, as the caller handles cleanup. Free the MCU message skb in __mt76x02u_mcu_send_msg() as well, which relied on skb_pad() to release it. Fixes: 808f2767d421 ("wifi: mt76: mt792x: Fix memory leak in SDIO TX path") Cc: stable@vger.kernel.org Closes: https://github.com/morrownr/mt76/issues/83 Co-developed-by: Devin Wittmayer Signed-off-by: Devin Wittmayer Signed-off-by: Eason Lai Link: https://patch.msgid.link/20260914021920.32246-2-eason.lai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a2c0f86b61f0c7a0fca9d2568744839e8f01d2b3 Author: Mark Anthony Agarro Date: Thu Aug 13 08:20:59 2026 -0700 wifi: mt76: mt7615: do not tear down BSS/STA state for monitor vifs [ Upstream commit f7517b3d8b7f1008e07edcb8bb692c6ca53ef23b ] Tearing down a monitor interface oopses: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:mt76_connac_mcu_uni_add_bss+0x144/0x370 [mt76_connac_lib] Call Trace: mt7615_remove_interface+0x6a/0x200 [mt7615_common] drv_remove_interface+0x60/0x140 [mac80211] ieee80211_del_virtual_monitor+0x8f/0xc0 [mac80211] ieee80211_do_open+0x550/0x7d0 [mac80211] ieee80211_open+0xaa/0xb0 [mac80211] __dev_open+0x11b/0x280 mt7615_remove_interface() tears down BSS and STA state for every vif type. On MT7663 with offload firmware that reaches mt76_connac_mcu_uni_add_bss(), which has no monitor case in its iftype switch. It takes WARN_ON(1), then copies ETH_ALEN from vif->bss_conf.bssid, which is NULL for a monitor vif. mt76_connac_mcu_bss_basic_tlv() in the same file handles this. It has an NL80211_IFTYPE_MONITOR case and it copies phy->macaddr in place of the bssid. The uni variant has neither. There is nothing to tear down. mt7615_add_interface() only calls mt7615_mcu_add_dev_info(). The BSS and STA state comes from beacon enable in mt7615_bss_info_changed(), from mt7615_set_key() and from mt7615_mac_sta_add(), so a monitor vif never has any. Reported on mt7615e going from monitor back to managed, and on mt7663u on an "ip link set down", both through ieee80211_del_virtual_monitor(). Fixes: d9852ab2f362 ("mt76: mt7615: keep mcu_add_bss_info enabled till interface removal") Cc: stable@vger.kernel.org Reported-by: Orly Orge Closes: https://lore.kernel.org/linux-wireless/CANj5C4mTOHs6riyWee=dFdkE5p=714J8xs-x3hq3ewQ+r6O_Nw@mail.gmail.com/ Reported-by: Inanix Closes: https://github.com/morrownr/mt76/issues/79 Tested-by: Inanix Signed-off-by: Mark Anthony Agarro Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260813152059.15747-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2d8a354ab5c200a8e3ef50859eb3a22e2f0a9399 Author: Mark Anthony Agarro Date: Wed Aug 26 05:27:55 2026 -0400 wifi: mt76: mt76x02: validate TX-status rate index before mac80211 handoff [ Upstream commit fbd12e8dabc8a9d2e81f427906749b4cff85d641 ] mt76x02_mac_process_tx_rate() extracts the rate index straight from the hardware's raw TX-status word with no bounds check for the HT/HT_GF/VHT cases, and mt76x02_mac_fill_tx_status() ignores its return value. A stale or corrupt hardware index reaches mac80211's minstrel_ht rate control, whose per-group rate array is a fixed 10 entries (MCS_GROUP_RATES), causing an out-of-bounds write. Validate the index in mt76x02_mac_process_tx_rate() (HT: 0-31, VHT: MCS nibble 0-9) and have mt76x02_mac_fill_tx_status() bail out cleanly on failure instead of passing an invalid index through. Fixes: 7c1f88812690 ("mt76: unify send_tx_status and related helpers") Cc: stable@vger.kernel.org Tested-by: Devin Wittmayer Signed-off-by: Mark Anthony Agarro Link: https://patch.msgid.link/20260826092755.480190-1-markanthonyagarro@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e3925a389195a597ee1fd6c3d22581ad3462cf4e Author: Joseph Qi Date: Thu Sep 3 18:47:44 2026 +0800 ocfs2: skip uninitialized lockres in ocfs2_mark_lockres_freeing() [ Upstream commit 6a3ed6b290513859bd27d9fcb67739347d6315fa ] A hard readonly mount skips ocfs2_dlm_init(), so the per-osb lock resources are never initialized and osb->cconn stays NULL. Before commit 550842cc60987 ("ocfs2: fix freeing uninitialized resource on ocfs2_dlm_shutdown") ocfs2_dismount_volume() only called ocfs2_dlm_shutdown() when osb->cconn was set. It now calls it unconditionally, so unmounting a hard readonly mount drops the osb locks and takes the never initialized l_lock in ocfs2_mark_lockres_freeing(). With lockdep enabled this triggers: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. ocfs2_drop_lock() and ocfs2_lock_res_free() already skip lock resources without OCFS2_LOCK_INITIALIZED. Add the same check to ocfs2_mark_lockres_freeing(), which is reachable before them through ocfs2_simple_drop_lockres(), so an uninitialized lockres is never touched. Link: https://lore.kernel.org/20260903104744.2164235-1-joseph.qi@linux.alibaba.com Fixes: 550842cc6098 ("ocfs2: fix freeing uninitialized resource on ocfs2_dlm_shutdown") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Reported-by: ZW Tang Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Sasha Levin commit 5130e8f40c07ad0ff2c013894780b0e669135aed Author: Konstantin Khorenko Date: Fri Aug 14 18:57:09 2026 +0200 selftests/core: fix unshare_test with large fs.nr_open [ Upstream commit df0b7e0ea59c43708cff8c7e34da5e2f8d430e5e ] The test assumes fs.nr_open is close to the default 1048576, but some systems set it much higher (e.g. 1073741816). This is systemd's doing: since systemd v240 (2018), PID 1 bumps fs.nr_open and fs.file-max to their largest possible values on boot, as file descriptors are already accounted for by memcg [1]. In that case, dup2() to nr_open + 64 requires the kernel to allocate a file descriptor table with ~1 billion entries, which fails with ENOMEM. On a kernel that already carries 04a2c4b4511d1, dup2() no longer fails with ENOMEM. The allocation is now rejected up front and the caller gets EMFILE instead, without the WARNING, but the test still fails. Cap the nr_open value used for the test's own arithmetic to a known reasonable base value (1048576) and restore the true original value once the test has completed. Link: https://lore.kernel.org/20260814165709.513263-1-khorenko@virtuozzo.com Link: https://github.com/systemd/systemd/commit/a8b627aaed409a15260c25988970c795bf963812 [1] Signed-off-by: Konstantin Khorenko Signed-off-by: Eva Kurchatova Signed-off-by: Andrew Morton Cc: Shuah Khan Cc: Wei Yang Cc: Signed-off-by: Sasha Levin commit 7edfee4c087cb1e10a52572ac2d402060661c174 Author: Joseph Qi Date: Fri Aug 28 19:28:24 2026 +0800 ocfs2: free replay slots in ocfs2_recovery_exit() [ Upstream commit 1ddadc6d41c1a29fd8fad1891bdcd2956e08b7f0 ] Commit ce2fcf1516d6 ("ocfs2: fix memory leak in ocfs2_mount_volume()") added ocfs2_free_replay_slots() calls to the mount error paths out_dismount and out_check_volume to fix a leak of osb->replay_map. However these calls are unlocked while the bail path of the recovery thread, which is woken up by out_dismount right before the call, also frees the replay slots under osb->recovery_lock. Both sides can thus observe a non-NULL osb->replay_map and trigger a double free. Fix this by moving ocfs2_free_replay_slots() into ocfs2_recovery_exit() after ocfs2_recovery_disable(), which waits for a running recovery thread to exit under osb->recovery_lock, and drop the unlocked call sites. Both ocfs2_dismount_volume() and the out_super path of ocfs2_fill_super() call ocfs2_recovery_exit(), so the replay slots are freed on every path. Since super.c no longer references it, make ocfs2_free_replay_slots() static again. Link: https://lore.kernel.org/20260828112825.666097-2-joseph.qi@linux.alibaba.com Fixes: ce2fcf1516d6 ("ocfs2: fix memory leak in ocfs2_mount_volume()") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Reviewed-by: Heming Zhao Cc: Changwei Ge Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Signed-off-by: Sasha Levin commit 70d85322ef7ea9151edac53b8d1c9b8d55ebaef4 Author: Joseph Qi Date: Fri Aug 28 19:28:23 2026 +0800 ocfs2: exit recovery thread on mount error path [ Upstream commit 6163a859649e9432e9c79c541f36dbf3bba9172f ] When a mount fails after the cluster connection has been established, e.g. in ocfs2_mount_volume(), ocfs2_fill_super() unwinds via out_debugfs/out_super and frees the osb without disabling recovery. A node failure event can concurrently launch the recovery thread, which blocks in __ocfs2_wait_on_mount() waiting for the volume state to become VOLUME_MOUNTED or VOLUME_DISABLED. As the mount error path neither sets VOLUME_DISABLED nor wakes osb_mount_event, the thread can never make progress: the kthread leaks and stays blocked on the wait queue embedded in the freed osb, which may then be accessed as freed memory. Fix it by setting VOLUME_DISABLED and waking osb_mount_event on this path so the thread bails out, and replace the plain kfree(osb->recovery_map) with ocfs2_recovery_exit(), which waits for a running recovery thread to exit before the recovery map is freed. Link: https://lore.kernel.org/20260828112825.666097-1-joseph.qi@linux.alibaba.com Fixes: f1e75d128b46 ("ocfs2: rewrite error handling of ocfs2_fill_super") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Reviewed-by: Heming Zhao Cc: Changwei Ge Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Signed-off-by: Sasha Levin commit 86c6f9543665bf5fcbe4f16bae47239720a5b7d1 Author: Thorsten Blum Date: Wed Aug 26 12:09:03 2026 +0200 init: fix early boot crash with bare hostname parameter [ Upstream commit b6bec5b63a5b812145e53aaad1e63661c7214f93 ] When a bare hostname parameter is specified on the kernel command line without the '=' separator, early parameter parsing passes NULL to early_hostname(), which dereferences it in strscpy() and can crash the system during early boot. Reject NULL values in early_hostname() and return -EINVAL instead. Link: https://lore.kernel.org/20260826100904.296151-2-blum@kernel.org Fixes: 5a704629f2c1 ("init: add "hostname" kernel parameter") Signed-off-by: Thorsten Blum Signed-off-by: Andrew Morton Cc: Dan Moulding Cc: Signed-off-by: Sasha Levin commit 04b4bf0d8fe3431ac64629e35f6bfe294bb37160 Author: Zi Yan Date: Thu Aug 20 09:19:12 2026 -0400 USB: gadgetfs: do not WARN about excessively large memory allocations [ Upstream commit a156148976eac47bee7210097afbb609cafe88b6 ] GadgetFS passes an excessively large user input len to kmalloc and kmalloc gives a WARN (see below for details). Suppress it by passing __GFP_NOWARN to kmalloc used by both ep_write_iter() and ep_read_iter(). Follow the same method as commit 4f2629ea67e72 ("USB: usbfs: Don't WARN about excessively large memory allocations"). kmalloc is used to allocate physically contiguous memory for kernel allocations. For requests larger than KMALLOC_MAX_CACHE_SIZE, kmalloc uses the page allocator and can only support up to KMALLOC_MAX_SIZE. For request sizes bigger than KMALLOC_MAX_SIZE, the page allocator can emit a WARN because kmalloc allocates an order greater than MAX_PAGE_ORDER. Link: https://lore.kernel.org/DKTTMAS94IMH.2C6ERY0ZIVWVZ@nvidia.com Fixes: b3c466ce5129 ("page allocator: do not sanity check order in the fast path") Signed-off-by: Zi Yan Signed-off-by: Andrew Morton Reported-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/ Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com Acked-by: Alan Stern Acked-by: Vlastimil Babka (SUSE) Cc: Greg Kroah-Hartman Cc: Signed-off-by: Sasha Levin commit e172a797d4cfeabed1068437720dc54174c7ac33 Author: Michael Liang Date: Fri Aug 21 12:15:27 2026 -0600 fault-inject: fix dentry leak [ Upstream commit ceb43516a9aae0d969a4ec5ab40d45bd09e64229 ] fault_create_debugfs_attr() has always taken an extra dentry reference on the created directory (attr->dname = dget(dir)) so that fail_dump() could print the name via %pd from any context. Nothing anywhere in the tree ever calls dput() on attr->dname. For callers with a matching teardown, that unmatched reference causes one dentry plus its attached inode to leak per fault_create_debugfs_attr / debugfs_remove_recursive cycle. simple_recursive_removal() drops debugfs's own +1 ref on the child dentry, but the dget()'d ref keeps its refcount at 1: the dentry ends up unhashed but pinned, and its inode is never freed. Boot-once callers (mm/failslab, block/blk-core, etc.) leak exactly once at init and never destroy the tree, so the impact there is bounded. But per-lifecycle callers (drivers/nvme, drivers/infiniband/hw/hfi1, drivers/mmc, drivers/iommu/iommufd, drivers/media, drivers/misc, drivers/gpu/drm/msm, drivers/crypto, net/sunrpc) leak on every create/destroy cycle. We observed this in production: an NVMe/RDMA host repeatedly reconnecting to a target that rejected the CRTO Property Get went through ~50 nvme controller create/destroy cycles per second, and dentry and inode_cache grew by ~13k pinned objects per 240 s -- unrecoverable through drop_caches. Byte math matched a per-cycle 1-dentry / 1-inode leak from the "fault_inject" directory dentry. Fix this by not holding any external reference in fault_attr. Embed the directory name as a fixed-size char array (FAULT_ATTR_DNAME_LEN, 64 bytes) inside struct fault_attr, copied by strscpy() at fault_create_debugfs_attr() time. fail_dump() prints it via %s. Advantages of an embedded array over kstrdup() + kfree() paired with a new destroy API: - Zero API footprint. No new export and no caller changes required: callers already own their fault_attr's memory and free it when they are done, and now that suffices. - No allocation on the create path. - fault_create_debugfs_attr() cannot fail from the name-copy step. - No lifetime coupling between attr->dname and debugfs; the string is valid for exactly as long as the containing struct. The 64-byte length accommodates every in-tree caller with generous headroom (the longest current name is "fail_dma_array_full", 19 chars). The user-visible fail_dump() format changes from "name %pd" to "name %s", but the printed content is identical -- %pd on the created directory renders the same string that was passed in as @name. drivers/infiniband/hw/hfi1/fault.c drops a now-invalid "attr.dname = NULL" statement; the surrounding kzalloc() already zero-initialises the array. Link: https://lore.kernel.org/20260821181527.3271414-1-mliang@purestorage.com Fixes: 6adc4a22f20b ("fault-inject: add ratelimit option") Signed-off-by: Michael Liang Signed-off-by: Andrew Morton Reviewed-by: Andrew Morton Cc: Akinbou Mita Cc: Dennis Dalessandro Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Vlastimil Babka Cc: Signed-off-by: Sasha Levin commit bcb81f854f68b99037aa050a3553a7aeb79523ac Author: OGAWA Hirofumi Date: Tue Aug 25 21:11:32 2026 +0900 fat: fix fat_ent_write() for reverting the value [ Upstream commit 63c4b67ee163b2a67a7561314bf2106d6c79c53c ] commit 64d9183203ee ("fat: restore original value when fat_ent_write failed") try to revert the fatent value to old value when got the error on mirror FAT. However it didn't work if the error is when writing the fatent bh. In that case, the bh is cleared the uptodate flag, so reuse bh is invalid. Fix this by reverting the fatent only if got the error on mirror FAT. Link: https://lore.kernel.org/87ik4yz9fv.fsf_-_@mail.parknet.co.jp Fixes: 64d9183203ee ("fat: restore original value when fat_ent_write failed") Signed-off-by: OGAWA Hirofumi Signed-off-by: Andrew Morton Reported-by: syzbot+e64c6472a3d96a75172a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e64c6472a3d96a75172a Reported-by: syzbot+26461e903494e689c24f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=26461e903494e689c24f Cc: Yemu Lu Cc: Ren Wei Cc: Yuan Tan Cc: Yifan Wu Cc: Juefei Pu Cc: Xin Liu Cc: Signed-off-by: Sasha Levin commit 415179d0ef2515a9541dd9f70536f89a1c454125 Author: DAI RENJIE Date: Fri Aug 21 14:08:17 2026 +0000 resource: fix lost wakeup when waiting for a muxed region [ Upstream commit 405c00e43a9c72a0b9b318cc2d2e298386ffb58e ] A task waiting for a muxed region can sleep forever in TASK_UNINTERRUPTIBLE even though the region it waits for is already free. __request_region_locked() queues itself on muxed_resource_wait and drops resource_lock before setting TASK_UNINTERRUPTIBLE, while __release_region() wakes the queue after dropping the same lock. A wakeup landing in between finds TASK_RUNNING, does not match TASK_NORMAL and is discarded; callers hold a muxed region only across a bounded transaction, so no further release is coming. The task is unkillable and its caller never returns. The window is one store wide, but an interrupt is enough to hold the waiter in it, and the machine this was seen on runs PREEMPT_DYNAMIC in its voluntary default. Since v6.11 spd5118 exports the DDR5 sensors of AMD boards through i2c-piix4, which takes a muxed region per SMBus transaction; a third of the in-tree users of request_muxed_region() are hwmon drivers, so reading a world-readable attribute is all an unprivileged user needs to drive the contention. The blocked task sleeps holding the i2c adapter bus lock, and 27 more piled up behind it. Reproduced by building a kernel with the two orderings selectable at runtime and a 2ms delay inside the window. Switching only that knob, a two-thread barriered reproducer loses the wakeup 200 times out of 200 before the fix and 0 out of 200 after it; without the delay it goes 20000 times through the wait path and loses none. Fix it by setting the task state before dropping resource_lock, as prepare_to_wait() does: the releasing side needs resource_lock to unlink the resource, so it cannot reach the wakeup before the state is published. Link: https://lore.kernel.org/20260821-b4-resource-muxed-lost-wakeup-v1-1-37eb6473a76c@gmail.com Fixes: 8b6d043b7ee2 ("resource: shared I/O region support") Signed-off-by: DAI RENJIE Signed-off-by: Andrew Morton Reviewed-by: Bradley Morgan Reviewed-by: Andrew Morton Assisted-by: Claude:claude-opus-5 Cc: Mark Brown Cc: Kees Cook Cc: Bjorn Helgaas Cc: Signed-off-by: Sasha Levin commit ad7b8f3cfdf63a9a0d74850ff7c9b035d93968ba Author: Gregory Price Date: Fri Aug 28 15:31:11 2026 -0400 mm/mempolicy: take a cpuset cookie for the interleave node count [ Upstream commit bbeeb4a29dc4ca6ac18ab3bafa3728bc984a4cde ] alloc_pages_bulk_interleave() counts pol->nodes without a cpuset cookie: nodes = nodes_weight(pol->nodes); nr_pages_per_node = nr_pages / nodes; nodemask_t spans several words once MAX_NUMNODES exceeds BITS_PER_LONG, so a concurrent cpuset rebind can tear that read and yield an empty mask even though neither version of it was empty. The call then allocates nothing and returns 0. Some compilers will hoist the loop entry test above the division, because nr_pages_per_node is dead when the loop does not run. 682e: call ... <- nodes_weight() 6838: test %eax,%eax 683a: jle 692d <- nodes <= 0 skips the loop 684a: div %rcx So in most deployments, this div/0 is unreachable - but nothing in the source guarantees that, it's just not easily exercised. Take the cookie around the count and bail if the mask really is empty. Only the count needs it, interleave_nodes() takes the cookie itself so so a torn read there is already retried. A rebind landing mid-loop can still leave the count disagreeing with the mask, so the loop may revisit a node or skip one - but a rebind where nodes change causes migration, so a handful of misplaced pages isn't catastrophic in any sense. Measured on a 72 node VM (NODES_SHIFT=10) with a cgroup v2 cpuset flipping cpuset.mems between a word 0 and a word 1 node set, and the two word read artificially widened: 330 zero counts in 130414 calls without the cookie, and 401 retries with it. Link: https://lore.kernel.org/20260828193111.1023497-1-gourry@gourry.net Fixes: c00b6b961099 ("mm/vmalloc: introduce alloc_pages_bulk_array_mempolicy to accelerate memory allocation") Signed-off-by: Gregory Price (Meta) Signed-off-by: Andrew Morton Reported-by: Chelsy Ratnawat Closes: https://lore.kernel.org/all/20250907160829.91628-1-chelsyratnawat2001@gmail.com/ Reviewed-by: Huang Ying Assisted-by: Claude:claude-opus-5 Cc: Alistair Popple Cc: Byungchul Park Cc: Chenwandun Cc: David Hildenbrand Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: "Uladzislau Rezki (Sony)" Cc: Zi Yan Cc: Signed-off-by: Sasha Levin commit 22b8a59c87f8be7068df5c28ac63d793e44f5e22 Author: Nathan Chancellor Date: Mon Oct 5 12:32:59 2026 +0200 wifi: brcmsmac: Adjust txpwrindex value in nphy_ipa_rxcal_gaintbl_2GHz [ Upstream commit f7463a9c99a506b3308a852f9aaaf2a26b659e95 ] After a recent change in clang to warn on signed char conversions within array initializers [1], there is a warning (or error with CONFIG_WERROR=y / W=e) from nphy_ipa_rxcal_gaintbl_2GHz: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:224:18: error: implicit conversion from 'int' to 's8' (aka 'signed char') changes value from 128 to -128 [-Werror,-Wconstant-conversion] 224 | {0, 0, 0, 0, 0, 128}, | ~ ^~~ 1 error generated. This value was introduced in the original staging merge of brcmsmac in commit a9533e7ea3c4 ("Staging: Add initial release of brcm80211 - Broadcom 802.11n wireless LAN driver.") and it is the same in the proprietary driver [2]. Presumably it is correct since there have been no reported issues, so update the value to '-128' to be type correct and clear up the warning. Cc: stable@vger.kernel.org Fixes: a9533e7ea3c4 ("Staging: Add initial release of brcm80211 - Broadcom 802.11n wireless LAN driver.") Link: https://github.com/llvm/llvm-project/commit/a5ef934a8d295dc03be3960f2b3744ec2e53238e [1] Link: https://lore.kernel.org/1a107e21b08.2873.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com/ [2] Signed-off-by: Nathan Chancellor Acked-by: Arend van Spriel Link: https://patch.msgid.link/20261005-brcmsmac-clang-24-constant-conversion-v1-1-a30c5692d582@kernel.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit cc656db016a1ee48f392aa9ed64f5936e028ca62 Author: Priyank Rathod Date: Mon Sep 28 17:40:12 2026 +0000 PCI/AER: Fix memory leak in aer_recover_queue() on kfifo buffer overflow [ Upstream commit 07938f8a3cbf3e9cc27553b8982e2d56c15b354a ] When ACPI APEI/GHES processes PCIe AER error records, it allocates memory for aer_capability_regs (aer_regs) from ghes_estatus_pool and passes it to aer_recover_queue() to be enqueued into aer_recover_ring. If kfifo_in_spinlocked() fails due to a buffer overflow, aer_recover_queue() logged an error message but returned without freeing aer_regs. Because the entry was rejected and never inserted into the queue, aer_recover_work_func() could never dequeue or free it, leaking the allocated ghes_estatus_pool memory. aer_recover_queue() returns void, so the caller ghes_handle_aer() cannot free the buffer itself: ownership is transferred to the AER code, which until now only released it on the success path. Free aer_regs via ghes_estatus_pool_region_free() when kfifo_in_spinlocked() fails on buffer overflow. Fixes: e2abc47a5a1a ("ACPI: APEI: Fix AER info corruption when error status data has multiple sections") Signed-off-by: Priyank Rathod Signed-off-by: Bjorn Helgaas Reviewed-by: Kuppuswamy Sathyanarayanan Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260928-b4-fix-aer-memleaks-v5-1-ba6b94c9c9a6@google.com Signed-off-by: Sasha Levin commit 1055d6b187e660ed587c81c624a47e8816f2b281 Author: Eric Dumazet Date: Tue Sep 29 07:17:35 2026 +0000 dlm: fix send buffer backpressure handling [ Upstream commit e234d7625598b2eaded84fa99f53c8062650828f ] lowcomms.c tests and clears SOCKWQ_ASYNC_NOSPACE in con->sock->flags, but this bit has not been stored there for ten years. Commit 9cd3e072b0be ("net: rename SOCK_ASYNC_NOSPACE and SOCK_ASYNC_WAITDATA") mechanically renamed the two dlm users, then commit ceb5d58b2170 ("net: fix sock_wake_async() rcu protection") moved the bit from socket->flags to the RCU protected socket_wq->flags, where it is reachable only through sk_set_bit() and sk_clear_bit(), and is only maintained for sockets having SOCK_FASYNC set. dlm uses kernel sockets, which never have SOCK_FASYNC set, and never sets the bit itself, so the test in send_to_sock() has been false ever since. The consequence is that when sock_sendmsg() returns -EAGAIN because the socket send buffer is full, dlm no longer sets CF_APP_LIMITED, does not increment sk_write_pending, and does not return DLM_IO_END to wait for lowcomms_write_space(). It returns DLM_IO_RESCHED instead, and process_send_sockets() immediately requeues the send work. A connection to a peer that is slow to drain thus keeps cycling through sock_sendmsg() and -EAGAIN, burning CPU, instead of sleeping until TCP reports that space is available again. Test SOCK_NOSPACE instead. This is the bit that lives in socket->flags, that TCP sets whenever sendmsg() returns -EAGAIN for lack of send buffer space (tcp_sendmsg_locked() and sk_stream_wait_memory()), and that lowcomms_write_space() already clears. This restores the semantics dlm had before the bit moved. Also remove the clear_bit() of SOCKWQ_ASYNC_NOSPACE from lowcomms_write_space(), for the same reason. SCTP connections are deliberately left as they are. SCTP does not set SOCK_NOSPACE, and it never calls sk->sk_write_space(): sctp_wfree() ends up in sctp_wake_up_waiters(), which calls sctp_write_space() directly. lowcomms_write_space() is thus never invoked for an SCTP connection, and the test added here stays false, so send_to_sock() keeps returning DLM_IO_RESCHED as it does today. This is the only safe behavior, as returning DLM_IO_END would wait for a callback that never comes. Fixes: ceb5d58b2170 ("net: fix sock_wake_async() rcu protection") Cc: stable@vger.kernel.org Cc: David Teigland Acked-by: Alexander Aring Reviewed-by: Kuniyuki Iwashima Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260929071743.23624-2-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4ea5d94557c7807a433d9c9a956c9dd1b6cbf41c Author: Denis Efremov (Oracle) Date: Thu Sep 24 15:28:25 2026 +0400 floppy: return the drive state flags from the 32-bit FDGETDRVSTAT [ Upstream commit bb38473f1bcb287567f2fa7980e483a778092504 ] compat_getdrvstat() copies every field of the drive state to a 32-bit caller except ->flags, which stays zero. 32-bit FDGETDRVSTAT and FDPOLLDRVSTAT therefore never report FD_DISK_WRITABLE, FD_DISK_CHANGED or FD_VERIFY: i386 fdutils (floppycontrol -P, fdmount), and other 32-bit users see every disk as write-protected and never see a disk change. The compat code in block/compat_ioctl.c copied the field; it was lost when that code moved into floppy.c Also declare the field as compat_ulong_t: the 32-bit struct floppy_drive_struct starts with an unsigned long, and a signed char at offset 0 only lines up with its low byte on little-endian machines. The size and offsets of the compat structure, and so FDGETDRVSTAT32, do not change. Cc: stable@vger.kernel.org Fixes: 229b53c9bf4e ("take floppy compat ioctls to sodding floppy.c") Link: https://patch.msgid.link/20260924112825.3525931-1-efremov@linux.com Signed-off-by: Denis Efremov (Oracle) Signed-off-by: Sasha Levin commit 619eaa2a3050c4ff5b645f091087823831f2a317 Author: Denis Efremov (Oracle) Date: Thu Sep 24 13:48:39 2026 +0400 floppy: don't store a stack buffer in timeout_message [ Upstream commit 66be62ee5d64b6ad1285978644798d8611add931 ] request_done() formats "request done %d" into a buffer on its stack and passes it to reschedule_timeout(), which keeps the pointer in timeout_message. show_floppy() prints timeout_message long after request_done() has returned, e.g. from result() in the interrupt handler, and reads a dead stack frame: BUG: KASAN: stack-out-of-bounds in string+0x39c/0x3d0 lib/vsprintf.c:720 Read of size 1 at addr ffffc900003cfc70 by task swapper/3/0 Call Trace: ... show_floppy+0xb1/0x45f drivers/block/floppy.c:1838 result.cold+0x2b/0x30 drivers/block/floppy.c:1183 floppy_interrupt+0x191/0x340 drivers/block/floppy.c:1755 floppy_hardint+0x1a7/0x200 arch/x86/include/asm/floppy.h:66 uptodate is either 0 or 1, so pass one of two string literals instead. Cc: stable@vger.kernel.org Fixes: 73507e6cd8dc ("drivers/block/floppy.c: remove unnecessary argument from [__]reschedule_timeout") Reported-by: syzbot+874c2707f97fac24b090@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=874c2707f97fac24b090 Link: https://patch.msgid.link/20260924094839.3239569-1-efremov@linux.com Signed-off-by: Denis Efremov (Oracle) Signed-off-by: Sasha Levin commit 9e374b805d4baa843d4fddf7fb638da1149b9bbe Author: Myeonghun Pak Date: Sat Oct 3 00:10:45 2026 -0400 ASoC: codecs: rt5682s: disable jack detection work on shutdown [ Upstream commit ca552e3140e736ed6704fe5d47439d8f2d40b42e ] The jack detection and button check works can queue each other. The shutdown path cancels jack_detect_work first, but jd_check_work can queue it again after that cancellation returns. Canceling jd_check_work then leaves jack_detect_work pending or running while the device is reset and, on removal, its managed resources are released. Disable and drain both delayed works so neither callback can revive the other after its cancellation. The I2C remove callback uses the same shutdown path. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: c07ac3ee76e5 ("ASoC: rt5682s: Fix the wrong jack type detected") Cc: stable@vger.kernel.org # 6.10+ Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20261003041045.650207-1-mhun512@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f1021189a2f325f184d0e3a79f18dcaadd326a0a Author: Chuck Lever Date: Fri Aug 28 09:50:34 2026 -0400 svcrdma: Grant credits from the clamped sc_max_requests [ Upstream commit b7037e5da3fb81abcd6309daecb112f1d5926760 ] svc_rdma_accept() computes sc_fc_credits from sc_max_requests before the Receive Queue depth is checked against the device's max_qp_wr. When that check lowers sc_max_requests, the credit grant keeps the original value, so the server advertises more credits than it has Receives posted. A client that uses the full grant overruns the Receive Queue, and the connection is lost with an RNR error. Set sc_fc_credits after the clamp so the grant matches the number of Receives the server posts. Fixes: fc2e69db82c1 ("svcrdma: Clean up comment in svc_rdma_accept()") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260828135036.796842-2-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 83e147ec8d157df646ab7d10b0e5fb2701fd1bad Author: Runyu Xiao Date: Wed Sep 2 15:22:41 2026 +0800 perf: xgene: initialize lock before requesting IRQ [ Upstream commit d4b7b0c77142b3bc535192fa65130474a129c487 ] xgene_pmu_probe() requests the PMU IRQ before initializing xgene_pmu->lock. request_irq() enables IRQ handling before it returns, so xgene_pmu_isr() can run in this window and acquire the uninitialized raw spinlock. Initialize the lock before requesting the IRQ so the handler always sees a valid lock. Fixes: 832c927d119b ("perf: xgene: Add APM X-Gene SoC Performance Monitoring Unit driver") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ff6fa5575169a39cc61565e2c3baf7464be48691 Author: Linus Walleij Date: Wed Sep 16 08:49:24 2026 +0200 power: supply: ab8500_fg: Report sub-percent charge changes [ Upstream commit 4d40dba1815d46c6ef9019ed80e3b998b0fc443d ] The fuel gauge updates bat_cap.mah from the coulomb counter but exposes bat_cap.prev_mah through CHARGE_NOW and ENERGY_NOW. It only refreshes prev_mah when the rounded integer capacity percentage changes, making the momentary properties appear frozen between percentage steps. Refresh prev_mah and notify userspace whenever the new charge remains within the currently accepted percentage. If a discharge estimate tries to cross upward into a higher percentage, the existing rejection still leaves both the reported percentage and charge unchanged. The AB8500 fuel-gauge implementations in the Samsung-GT-I8160-Codina, Samsung-GT-I8160_HD-Codina, Samsung-GT-I8530-Gavini, Samsung-GT-S7710-Skomer, Samsung-SGH-I407-Kyle and Samsung-SGH-T599-Codina-TMO product trees retain the same percentage-gated prev_mah update and contain no finer-grained reporting workaround. Fixes: 13151631b5bd ("ab8500-fg: A8500 fuel gauge driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260916-ab8500-charging-v1-2-e986ed321cc6@kernel.org Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 83ee39d12dd78fb260795c49f9bc64b559e47b47 Author: Linus Walleij Date: Wed Sep 16 08:49:23 2026 +0200 power: supply: ab8500_fg: Accept status from supplied power [ Upstream commit 16f506a13b58a55308449bbcbec89c817d619ca2 ] Commit dc77721ea4aa ("power: supply: ab8500: Set typing and props") changed the charging algorithm power supply type from battery to unknown so userspace would not mistake it for a second battery. The fuel gauge, however, processes status changes only from battery-type supplies. It therefore never learns that charging started and keeps running its discharge state machine. The power supply relationship already limits the callback to supplies naming the fuel gauge in supplied_to. Accept status from any such supply while retaining the battery type checks for battery-specific properties. The Samsung-GT-I8160-Codina and Samsung-GT-I8160_HD-Codina product trees keep the charging algorithm typed as a battery. The Samsung-GT-I8530-Gavini, Samsung-GT-S7710-Skomer, Samsung-SGH-I407-Kyle and Samsung-SGH-T599-Codina-TMO alternative fuel-gauge drivers instead pass cable state directly. Both approaches preserve the charging state handoff that was lost in mainline. Fixes: dc77721ea4aa ("power: supply: ab8500: Set typing and props") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260916-ab8500-charging-v1-1-e986ed321cc6@kernel.org Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit e47bfc7e40758e275b77a678325f835b3296fe67 Author: Andrey Albershteyn Date: Sat Oct 3 00:36:47 2026 +0200 fsverity: hoist statx reporting of fs-verity flag [ Upstream commit f9e450420da2624c93ce9585deebfabb87932774 ] All filesystems, supporting fsverity, report this status by checking inode flag. Also, BTRFS was missing stat->attributes_mask, which is fixed now. Fixes: 146054090b08 ("btrfs: initial fsverity support") Cc: stable@vger.kernel.org Signed-off-by: Andrey Albershteyn Acked-by: Eric Biggers Reviewed-by: Christoph Hellwig Reviewed-by: "Darrick J. Wong" Link: https://patch.msgid.link/20261002223705.2175542-7-aalbersh@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit 94689cf56fe676a1989adb0bdc8405cbd6b74f66 Author: Tharit Tangkijwanichakul Date: Wed Jul 22 16:08:19 2026 +0000 media: hantro: disable runtime PM before hardware teardown [ Upstream commit 8e26d4c20ed218db6c3123480a4a4e2545680566 ] Removing the Hantro driver may trigger an SError on RK3588: SError Interrupt on CPU6, code 0x00000000be000011 -- SError ... do_serror+0x5c/0x74 el1h_64_error_handler+0x34/0x50 el1h_64_error+0x6c/0x70 regmap_mmio_read32le+0x10/0x20 (P) _regmap_bus_reg_read+0x6c/0xb4 _regmap_read+0x60/0xdc regmap_read+0x4c/0x80 rockchip_pd_power+0xe4/0x600 rockchip_pd_power_off+0x1c/0x60 _genpd_power_off+0x98/0x198 genpd_power_off.part.0+0x178/0x288 genpd_runtime_suspend+0x210/0x300 __rpm_callback+0x48/0x1e0 rpm_callback+0x74/0x80 rpm_suspend+0x10c/0x580 rpm_idle+0x134/0x1b8 update_autosuspend+0x30/0xc4 __pm_runtime_use_autosuspend+0x48/0x64 hantro_remove+0x8c/0xa8 [hantro_vpu] ... hantro_remove() currently asserts the device resets before disabling runtime PM. Calling pm_runtime_dont_use_autosuspend() causes an idle device to be runtime-suspended immediately. At that point the Hantro hardware has already been torn down, while the generic power-domain genpd code still performs the power-off sequence. genpd regmap_mmio_read causes panic subsequently because the reset lines were asserted. Disable runtime PM before asserting the reset lines so that no runtime-PM transition can race with hardware teardown. Apply the same ordering to the probe error paths as well. Fixes: ea71631b7129 ("media: hantro: add support for reset lines") Cc: stable@vger.kernel.org Signed-off-by: Tharit Tangkijwanichakul Reviewed-by: Benjamin Gaignard Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f1026f72e18e461b39ca67082794c609a679342b Author: Jiawen Liu <1298662399@qq.com> Date: Sun Jul 26 10:35:39 2026 +0400 media: amphion: fix runtime PM imbalance on probe failure [ Upstream commit 0cabf27cf1e6f7ee5f3c5893c0f1930814d949af ] vpu_core_probe() enables runtime PM before calling pm_runtime_resume_and_get(). If pm_runtime_resume_and_get() fails, it has already dropped the runtime PM usage counter that it acquired before trying to resume the device. Calling pm_runtime_put_noidle() again on this error path drops the counter one extra time. Remove the extra put and keep the existing cleanup that marks the device suspended before disabling runtime PM. Fixes: 9f599f351e86ac ("media: amphion: add vpu core driver") Cc: stable@vger.kernel.org Signed-off-by: Jiawen Liu <1298662399@qq.com> Reviewed-by: Ming Qian Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 86a720e8ea1eecc2be8202643b856472ffcea39c Author: Tharit Tangkijwanichakul Date: Fri Jul 31 14:07:51 2026 +0000 media: hantro: Harden MPEG-2 control access against NULL [ Upstream commit 2b685dba4226792933f45b1cbf8991e89ccd21ce ] The MPEG-2 sequence and picture controls are validated before a job is queued, so hantro_get_ctrl() is not expected to return NULL in hantro_g1_mpeg2_dec_run(). The controls are nonetheless dereferenced unconditionally. Harden the invariant by checking the sequence and picture controls with WARN_ON(). Found by code inspection. Fixes: f329e21e9dad ("media: uapi: mpeg2: Split sequence and picture parameters") Cc: stable@vger.kernel.org Signed-off-by: Tharit Tangkijwanichakul Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 563dfdc969c1bf63e4ace17a53aaaedd59595a01 Author: Junrui Luo Date: Mon Aug 3 15:29:36 2026 +0800 media: vicodec: fix NULL deref on oversized frame [ Upstream commit c657eb609197e289b054bc2c4e86a0fc32dd7ebe ] job_ready() only honours the is_header_valid() verdict when ctx->comp_has_frame is set, and comp_has_frame is only set once comp_size reaches the full frame size. Since the copy is clamped to ctx->comp_max_size, a header advertising a larger size leaves comp_size stuck at comp_max_size, so comp_has_frame stays false and the failed validation is discarded. Control then falls into the resolution change branch, which calls update_capture_data_from_header(). That function re-derives info via info_from_header(), assigns it to q_dst->info and dereferences it as q_dst->info->sizeimage_mult, with no NULL check of its own. is_header_valid() does check that same info_from_header() result -- if (!info) return false which is precisely the false verdict job_ready() discarded above. info_from_header() returns NULL whenever the header flags resolve to no supported pixel format. Drop the comp_has_frame conjunct so an invalid header always bails out. The resolution change path is unaffected, as it is entered with a valid header. Oversized frames are then rejected by device_process(), which already returns -EINVAL when comp_frame_size exceeds comp_max_size. Fixes: 3b15f68e19c2 ("media: vicodec: Add support for resolution change event.") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 654e88baba85d5065b4747da2047c6018edffa67 Author: Pengpeng Hou Date: Sat Aug 15 21:49:49 2026 +0800 media: mediatek: jpeg: retry HW selection after successful wait [ Upstream commit eb0bbd0ad679bf363387e3b8be8892cfbedabb72 ] wait_event_interruptible_timeout() returns a positive value when its condition becomes true before the timeout. mtk_jpegdec_worker() treats every nonzero result as a failure, so a normal decoder wakeup finishes the mem2mem job as though no hardware became available. Handle interrupted waits and exhausted timeout retries separately, and retry hardware selection after a successful wakeup. Increment the retry count only for actual timeouts. The encoder uses wait_event_interruptible(), whose successful return is zero, so its existing check is correct; leave that separate no-timeout policy unchanged. Fixes: dedc21500334 ("media: mtk-jpegdec: add jpeg decode worker interface") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a8a3184bc0e2aedb5b28683f11550f340f78d3d4 Author: Michail Tatas Date: Wed Aug 19 12:28:12 2026 +0300 media: verisilicon: rockchip: Fix leaks in init [ Upstream commit 96f6b5e2295996a9e2dd1e2382d3872f98cbb554 ] If one of the dma_alloc_coherent in the init function fails then the previously allocated ones leak. Fix by freeing them in the error path. Fixes: 727a400686a2 ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Signed-off-by: Michail Tatas Reviewed-by: Frank Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 530027d205c0ebab0c0a1d388f522adeec629edf Author: Guangshuo Li Date: Tue Sep 15 20:10:25 2026 +0800 media: mediatek: vpu: release reserved memory on remove [ Upstream commit 8af0e2bdd9791848d9caf3761825ac51a67c2b9c ] mtk_vpu_probe() may assign a reserved memory region to the VPU device with of_reserved_mem_device_init(). The probe failure path releases the assignment with of_reserved_mem_device_release(), but the normal remove path does not perform the corresponding cleanup. As a result, removing the VPU driver after a successful probe can leave the reserved memory assignment associated with the device after its lifetime has ended. Release the reserved memory assignment after freeing the VPU external firmware memory, matching the cleanup performed by the probe failure path. This issue was found by manual code inspection. Fixes: 3003a180ef6b ("[media] VPU: mediatek: support Mediatek VPU") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 58bb8bcaed349674642d567f70c49ca71e46f32c Author: Guangshuo Li Date: Tue Sep 15 19:57:53 2026 +0800 media: mediatek: vcodec: destroy core workqueue on remove [ Upstream commit ceb6e96122e1013550f378c738e621a6e82d246b ] The decoder probe allocates core_workqueue for architectures with a LAT processor. The probe failure paths destroy the workqueues, but the remove() function only destroys decode_workqueue. As a result, removing a decoder on LAT architectures leaves core_workqueue allocated after the device lifetime has ended. Destroy core_workqueue during remove for latency-based decoder architectures, matching the cleanup performed by the probe failure paths. This issue was found by manual code inspection. Fixes: 365e4ba01df4 ("media: mtk-vcodec: Add work queue for core hardware decode") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 54f1f31ed577200f33ba6cb88af4e74fd21c2288 Author: Wentao Liang Date: Thu Sep 17 10:04:37 2026 +0000 media: mtk-jpeg: Fix runtime PM leak in mtk_jpegenc_worker() [ Upstream commit 7ec8fd17f3a8059dcf94101065a35d0136031794 ] pm_runtime_get_sync() leaves the device's runtime PM usage count incremented even when it fails, and a failed clk_prepare_enable() drops the reference as well. mtk_jpegenc_worker() jumps to enc_end in both cases, which does not call pm_runtime_put(), so the reference taken by the successful resume is leaked. Use pm_runtime_resume_and_get() for the resume failure and release the reference explicitly when the clock cannot be enabled, as mtk_jpegdec_worker() already does. Fixes: 5fb1c2361e56 ("mtk-jpegenc: add jpeg encode worker interface") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 82d35074100024399798c4d47d8cd78b6a92af37 Author: Wentao Liang Date: Thu Sep 17 10:02:47 2026 +0000 media: mtk-jpeg: Fix runtime PM leak in mtk_jpegdec_worker() [ Upstream commit befd4506174addc5e85641b4ef304c9247b48c55 ] pm_runtime_get_sync() leaves the device's runtime PM usage count incremented even when it fails. mtk_jpegdec_worker() jumps to dec_end on that failure, which does not call pm_runtime_put(), so the reference taken by the failed resume is leaked. Use pm_runtime_resume_and_get() instead, which drops the reference again when resuming the device fails. Fixes: dedc21500334 ("media: mtk-jpegdec: add jpeg decode worker interface") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 79e9098bf08fdd743e4eacdb5dba9ad4bdf7304e Author: Wentao Liang Date: Thu Sep 17 10:07:21 2026 +0000 media: platform: mtk-mdp3: Fix device reference leak in mdp_comp_init() [ Upstream commit ff3308afa9c9da0ef9113cb80803588adabef902 ] mdp_comp_init() takes a reference to the component platform device with of_find_device_by_node(), but the error path taken when the clock array cannot be allocated and the one taken for a component without a GCE EOF event return without dropping it. The caller frees the mdp_comp in those cases, so the reference is leaked. Release the reference on both error paths. Fixes: c4320f9721fd ("media: platform: mtk-mdp3: dynamically allocate component clocks") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2590068009d684c3f7f3511b98a2d20ac688e730 Author: Fan Wu Date: Wed Sep 23 08:59:21 2026 +0000 media: mediatek: vpu: free IRQ before destroying watchdog workqueue [ Upstream commit 2c50b58d4105f6dbaa36d6306087954b9100e9ae ] mtk_vpu_remove() destroys the watchdog workqueue while the interrupt handler requested with devm_request_irq() is still registered: the devres core frees the interrupt only after remove() has returned. If the VPU watchdog fires in that window, vpu_irq_handler() queues vpu->wdt.ws on the already destroyed vpu->wdt.wq. Fix this by calling devm_free_irq() before destroy_workqueue(), which releases the interrupt and waits for a running handler, so no new work can be queued while the workqueue is drained and freed. This issue was found by an in-house static analysis tool. Fixes: 3003a180ef6b ("[media] VPU: mediatek: support Mediatek VPU") Cc: stable@vger.kernel.org Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2433cdd2ff18b143e26d4e4f3399dbad68544fd9 Author: Myeonghun Pak Date: Fri Sep 25 15:17:06 2026 -0400 media: amphion: prevent unbind while video instances are open [ Upstream commit 96ea6bc6835f1b18b75303d536a7f9a3829c9bc1 ] An open video instance holds a plain pointer to its devm-allocated core. Unbinding the core or its parent through sysfs can release that memory while the instance remains open. A later ioctl or close then uses the stale pointer. The video file operations pin the module, but sysfs unbind bypasses that protection. Suppress manual bind and unbind for both platform drivers, and warn if core removal ever encounters a live instance. Fixes: 9f599f351e86 ("media: amphion: add vpu core driver") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Ming Qian Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit da18ffe1cd0a45fbb854be4bf9555f511747c8b3 Author: Myeonghun Pak Date: Fri Sep 25 15:17:05 2026 -0400 media: amphion: drain message work before releasing core state [ Upstream commit ec95ae226f240ed657834fe4114abb7067e1af2d ] vpu_core_unregister() frees core->msg_buffer before cancelling the message workers, although core->msg_fifo still uses the buffer as its backing storage. A queued worker can read it after it has been freed. Drain the core and instance message work first, then release core->vpu and the FIFO buffer. This follows the ordering in vpu_core_suspend(). Fixes: 9f599f351e86 ("media: amphion: add vpu core driver") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Ming Qian Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 10a7475bc6d1cef7d5c1e7f27c8de4a011ebbbed Author: Michael Freidkin Date: Mon Sep 28 19:50:45 2026 +0300 media: meson: vdec: size capture planes from the aligned canvas [ Upstream commit b3a805dd5a83ba8c85e2085d3411eb9975e0aea4 ] The decoder writes a whole canvas of ALIGN(width, 32) x ALIGN(height, 32) (amvdec_set_canvases()) and reports bytesperline = ALIGN(width, 32), but get_output_size() derives sizeimage from the raw width x height. When the width is not a multiple of 32 the planes are too small for the advertised stride: for 720x360 NV12M the luma plane is 262144 bytes while 736 * 360 = 264960 are needed (282624 for the canvas the firmware fills). The decoder writes past the buffer, and importing the capture dma-buf into DRM fails: drmModeAddFB2() returns -EINVAL, so e.g. Kodi plays the sound over a black screen. 1280x720 and 1920x1080 are not affected. Size the planes from the aligned canvas the hardware actually uses. Tested on an S905X (GXL p212) board with LibreELEC 12 (6.16.0-rc3): 720x360 and 1920x1080 H.264 play through V4L2 m2m + DRM PRIME with no AddFB2 errors. Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver") Cc: stable@vger.kernel.org Signed-off-by: Michael Freidkin Reviewed-by: Dan Carpenter Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a496b466f6a5abed4ad11d6189592db9ae6f89f2 Author: Runyu Xiao Date: Wed Jul 1 23:06:10 2026 +0800 media: sti: delta: use unaligned accessors for MJPEG SOF fields [ Upstream commit fdc5bf02aeaef04e7d13895db9b6eaf8083953f9 ] delta_mjpeg_read_header() scans a compressed MJPEG access unit byte by byte and passes the bytes after an SOF marker to delta_mjpeg_read_sof(). The SOF parser then reads 16-bit big-endian fields directly from that byte stream. The SOF payload is not an aligned object. The marker scan can find the payload at any byte position, and the SOF layout also puts frame_height and frame_width after a one-byte sample_precision field. Those fields therefore sit at odd offsets within the payload even when the payload base happens to be 2-byte aligned. Avoid casting the byte stream to __be16 pointers and use get_unaligned_be16() for the SOF length, height, and width fields. This issue was detected by our static analysis tool and confirmed by manual audit. A focused UBSAN alignment validation of the same typed load shape reported a misaligned __be16 access in delta_mjpeg_read_sof(). Fixes: 433ff5b4a29b ("[media] st-delta: add mjpeg support") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 95f99bdd3cb4ce2b31fc99cc2395ca7ca40823a4 Author: Nas Chung Date: Fri Sep 4 15:46:27 2026 +0900 media: v4l2-common: Fix P010 format info [ Upstream commit 8761a87aff8259eab0add8a9428cee2c280fb6eb ] V4L2_PIX_FMT_P010 is a 10-bit 4:2:0 semi-planar format, but its v4l2_format_info() entry described a 4:2:2 layout with a half-width chroma plane. Correct bpp and vdiv to match P010's real layout, consistent with the other semi-planar formats. Cc: stable@vger.kernel.org Fixes: 5374d8fb75f3 ("media: Add P010 video format") Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f16a8bb6da0d0d39d505a923348338b585405859 Author: Thorsten Blum Date: Mon Jan 26 10:49:27 2026 +0100 media: imagination: Fix value clamping in calculate_qp_tables [ Upstream commit c8454a41da59d51fbcc5743f8c71a03b096a770f ] The local variable 'val' was never clamped to 1 or 255 because the return value of clamp() was not used. Fix this by assigning the clamped value back to 'val'. Cc: stable@vger.kernel.org Fixes: a1e294045885 ("media: imagination: Add E5010 JPEG Encoder driver") Signed-off-by: Thorsten Blum Reviewed-by: Jai Luthra Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 35df1f0857c802836f4d25660e719089cc83869e Author: Karl Mehltretter Date: Mon Aug 31 10:10:02 2026 +0200 KVM: arm64: vgic-v3: Roll back assignments from the new region [ Upstream commit a32c01324eb494dda811912eb847b0e907cd7270 ] A failed REDIST_REGION write unregisters the redistributor iodevs of every vCPU processed before the failure. This includes vCPUs assigned to older regions. Their assignments remain cached, so a retry does not register the iodevs again. The vCPU whose registration fails has no assignment to roll back. For vCPUs processed earlier, limit rollback to those assigned to the new region. The region is removed on failure, so its free_index does not need restoring. Resetting assignments from older regions is unsafe because a vCPU can own one before kvm_for_each_vcpu() can see it. Rollback could then move free_index behind that live assignment. kvm_vgic_addr() holds slots_lock across the REDIST_REGION write. vCPU creation takes the same lock before assigning a redistributor. A concurrent vCPU cannot acquire an assignment from the new region before rollback completes. The lock also keeps rdreg valid across the config_lock drop required by MMIO-bus registration. Fixes: c011f4ea106b ("KVM: arm/arm64: Check vcpu redist base before registering an iodev") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260831081005.41346-3-kmehltretter@gmail.com [maz: moved helper into the sole caller] Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit fdff9616b0923b0d4a3eeee215a7ed41c80fe8b4 Author: Karl Mehltretter Date: Mon Aug 31 10:10:01 2026 +0200 KVM: arm64: vgic-v3: Undo assignment on iodev registration failure [ Upstream commit 8a88a46b86ca3dbbd24522760d29edfb3f24ac2a ] vgic_register_redist_iodev() assigns a redistributor region and base address to the vCPU before adding its iodev to the MMIO bus. However, the region's free_index is advanced only after registration succeeds. If kvm_io_bus_register_dev() fails, the vCPU retains the assignment while free_index still identifies the same slot as free. A later registration can therefore reuse a slot that remains assigned to the vCPU. Reserve the slot before registering its iodev. The caller holds slots_lock, so a registration failure cannot race with a later assignment. Undo the reservation and clear the cached assignment on failure. Fixes: dbd9733ab674 ("KVM: arm/arm64: Replace the single rdist region by a list") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Karl Mehltretter Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Link: https://patch.msgid.link/20260831081005.41346-2-kmehltretter@gmail.com [maz: moved helper into the sole caller] Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 51f478985b6466952635c9c6fd7531ebbfde8b54 Author: Aldo Ariel Panzardo Date: Fri Sep 25 14:58:39 2026 -0300 crypto: nx - validate 'ignore' before subtracting in decompress [ Upstream commit b5c2df42977390a71f1940def5be9bd5c69ac2e0 ] The decompress() function subtracts the header-supplied `ignore` value (a u16 from the compressed stream) from `dlen` (the number of bytes produced by the decompressor) without checking that ignore <= dlen. If a caller decompresses a crafted buffer where `hdr->ignore` exceeds the actual decompressed length, the subtraction wraps around to a near-UINT_MAX value. The subsequent memcpy() then copies gigabytes of data past the destination buffer, causing an out-of-bounds kernel write. Add a bounds check before the subtraction and return -EINVAL if the value is inconsistent. Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4c70179be02411ec4eff1fcb89bf2df05bd1debc Author: Thorsten Blum Date: Thu Sep 24 23:21:13 2026 +0200 hwrng: core - reject unknown RNG names [ Upstream commit 7e7be8815143751c20260f80cb4e7fe14dd24b74 ] In rng_current_store(), err is 0 after successfully locking rng_mutex, and if the requested RNG name cannot be found, the function reports success even though the current RNG was not changed. Set err = -ENODEV before searching the RNG list to reject unknown names. Fixes: 142a27f0a731 ("hwrng: core - Reset user selected rng by writing "" to rng_current") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Reviewed-by: Andy Shevchenko Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a22f19c4abb96768963ae22ec4daad39c9d5f673 Author: Thorsten Blum Date: Thu Sep 24 11:33:59 2026 +0200 hwrng: ba431 - fix reported byte count [ Upstream commit 7e638679883ceff5b6e7b6dcad09c21a105e941f ] Use the size of the buffer element instead of the pointer size to report the number of bytes read. Since data is a u32 pointer and sizeof(data) is 8 bytes on 64-bit systems, using the pointer size reports twice the number of bytes actually read. Fixes: 0289e9be5dc2 ("hwrng: ba431 - add support for BA431 hwrng") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0428e5dc4cab655e744d20b479bc0eddd8ad707d Author: Thorsten Blum Date: Wed Sep 23 22:12:58 2026 +0200 hwrng: amd - report partial reads in non-blocking mode [ Upstream commit e7f5ce911efb2017381f28bbedb6243a74a9c285 ] amd_rng_read() returns 0 if no more data is available, even if some data was already copied to the output buffer. Return the number of copied bytes instead. Fixes: 85962d2248fa ("hwrng: amd - Convert to new hwrng read() API") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e7a5cea8804f1210fe45c3a0281b11943c58553f Author: ZhaoJinming Date: Wed Sep 23 18:14:57 2026 +0800 crypto: caam - fix double-free in caam_rsa_set_priv_key_form() [ Upstream commit a91d9346a70b68f77884cba9d9ec3b70f96bf9d2 ] caam_rsa_set_priv_key_form() frees the partially allocated key components (p, q, tmp1, tmp2, dp, dq) with kfree_sensitive() on its error path, but does not set those pointers to NULL afterward. When the function returns an error, caam_rsa_set_priv_key() jumps to its err label and calls caam_rsa_free_key(), which frees all of those same pointers again, resulting in a double-free. This is reachable when the allocation of q, tmp1, tmp2, dp, dq or qinv fails, e.g. under memory pressure, or for a malformed key whose CRT members decode to zero length and make caam_read_rsa_crt() return NULL. Set each pointer to NULL right after freeing it so that the subsequent caam_rsa_free_key() call becomes a no-op for the already-freed fields. Fixes: 52e26d77b8b3 ("crypto: caam - add support for RSA key form 2") Cc: stable@vger.kernel.org Signed-off-by: ZhaoJinming Reviewed-by: Sahil Malhotra Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4bb37004309e7d372d371af110fa8cd993162bdd Author: Wei Jie Law <98lawweijie@gmail.com> Date: Mon Sep 7 20:18:43 2026 +0800 media: uvcvideo: Fix NULL deref on events for uninitialized controls [ Upstream commit daa379e2b74d6c10ba4e3b56eeca5aa8c8704fca ] A null-ptr-deref exists in v6.12.105 and upstream. KASAN crash log: KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087] Workqueue: events uvc_ctrl_status_event_work RIP: 0010:uvc_ctrl_status_event+0x105/0x280 uvc_ctrl_status_event_work+0x82/0x240 process_one_work+0x66f/0x10b0 XU controls are initialized lazily, on the first UVCIOC_CTRL_MAP or UVCIOC_CTRL_QUERY. Until then ctrl->info is all zeroes, so info.mappings is not a valid list head, list_empty() returns false, and uvc_ctrl_status_event() walks it from a NULL next pointer. Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control Change interrupt arrives") Cc: stable@vger.kernel.org Signed-off-by: Wei Jie Law <98lawweijie@gmail.com> Assisted-by: LLM Reviewed-by: Ricardo Ribalda Link: https://patch.msgid.link/20260907121844.2592492-1-98lawweijie@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a61ef6e77cf61d994dac020afee31ad815344f84 Author: Imre Kaloz Date: Wed Sep 30 21:10:58 2026 +0200 PCI: Disable MSI for ULi M1575 EHCI controller [ Upstream commit 5f30217ec296fb5742f6fd306586dbca5b81b4eb ] With MSI, the ULi M1575 EHCI controller (10b9:5239) intermittently stops executing its asynchronous schedule. Control transfers time out ("device not accepting address", "device descriptor read/64"), the port is handed to the companion OHCI controller, and the device ends up at full speed. On a configured hub the stall shows up as hub descriptor and status read failures. Only re-initializing the controller recovers it. On a Sun Ultra 45, 65 of 800 controller initializations stalled with MSI and none of 200 with INTx. Each initialization is an unbind and bind of ehci-pci on the EHCI function, with MSI or INTx selected through its msi_bus attribute; with this quirk, 0 of 100 cycles of the same loop stalled. The stall reproduces on a kernel that already contains commit 0b60557230ad ("usb: ehci: Prevent missed ehci interrupts with edge-triggered MSI"). The OHCI functions (10b9:5237) keep MSI. They showed no stall, and the hub enumerated through them on MSI during the EHCI failures, so only the EHCI function is quirked. The illumos EHCI driver also disables MSI on this chip, in ehci_register_intrs_and_init_mutex() in usr/src/uts/common/io/usb/hcd/ehci/ehci_util.c. Until USB HCDs started trying MSI first in v5.9, the controller always used INTx. Disable MSI so it uses INTx again on this chipset. Fixes: 306c54d0edb6 ("usb: hcd: Try MSI interrupts on PCI devices") Signed-off-by: Imre Kaloz Signed-off-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260930191100.6127-1-kaloz@kernel.org Signed-off-by: Sasha Levin commit e9f54712f588b2ea86bb6bcbf4fa52f594d6fd10 Author: Vasileios Almpanis Date: Wed Sep 30 14:32:26 2026 +0000 block: drop the cached plug time when blk_add_rq_to_plug() flushes [ Upstream commit e0f2224433b15a57125d6ac5d46182f99c6c9d08 ] blk_time_get_ns() caches the current time in the task's plug. The idea is that the cache lives for one plug and is dropped when the plug is flushed. __blk_flush_plug() and finish_task_switch() do that. blk_add_rq_to_plug() also flushes, when the plug has too many requests or the last request is at least BLK_PLUG_FLUSH_SIZE. But it calls blk_mq_flush_plug_list() directly and never drops the cached time. So a task that keeps submitting without sleeping stamps every request after that with the time first cached in the plug. start_time_ns and io_start_time_ns are stale and the disk stats charge each request for the whole time since the plug began. Drop the cached time after the flush, same as __blk_flush_plug() does. Fixes: da4c8c3d0975 ("block: cache current nsec time in struct blk_plug") Cc: stable@vger.kernel.org Signed-off-by: Vasileios Almpanis Link: https://patch.msgid.link/20260930-blk-plug-ts-flush-v1-1-bf8ca7bc5cd6@virtuozzo.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d57833edee5838ab869241a6f6f404d88ef97dde Author: Mikulas Patocka Date: Wed Sep 30 21:43:26 2026 +0200 dm-writecache: fix REQ_FUA processing [ Upstream commit c0df022cb0fa2bbee74bd9b90c66790bcd4e3050 ] REQ_FUA did not flush metadata in SSD mode, this commit fixes it. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Fixes: c1005322ff02 ("dm writecache: handle REQ_FUA") Assisted-by: Claude:claude-opus-5 Assisted-by: Codex:gpt-6-sol Signed-off-by: Sasha Levin commit 14bd0affefe005774c3fe7d56ca89098d1dfc36c Author: Mikulas Patocka Date: Wed Sep 30 21:42:03 2026 +0200 dm-writecache: fix uncommitted_blocks underflow [ Upstream commit 8a0cc5f3446a324b13f62020eeddb32d6ba1c2db ] Revert the commit 39495b12ef1cf602e6abd350dce2ef4199906531 writecache_bio_copy_ssd sets wc->uncommitted_blocks = 0; and then queues the flush work: queue_work(wc->writeback_wq, &wc->flush_work); It may be possible that discard is dispatched in this window, and the discard would decrement wc->uncommitted_blocks to -1U. Note that this bug is benign - wc->uncommitted_blocks is only used to trigged autocommit, so decrementing it to -1U will trigger a spurious autocommit, but won't cause any data corruption. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-5 Fixes: 39495b12ef1c ("dm writecache: correct uncommitted_block when discarding uncommitted entry") Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit f7c1a697958786d7d3b8a23ab5849e275f6bbda4 Author: Mikulas Patocka Date: Wed Sep 30 21:41:11 2026 +0200 dm-writecache: fix a crash if we attempt to use non-dax device [ Upstream commit b15dc73f60ebf02410bc7014ce34fb7fd1040045 ] If we specify a non-DAX device as a cache device in the 'P' mode, dm-writecache crashes on NULL pointer dereference inside dax_synchronous. Note that this is not a security bug because only root can trigger it. Signed-off-by: Mikulas Patocka Fixes: a46624580376 ("dm writecache: reject asynchronous pmem devices") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Sasha Levin commit 6a95560d96bad010670901a69d55ccae5986b62c Author: Mikulas Patocka Date: Wed Sep 30 21:39:44 2026 +0200 dm-writecache: fix a quirk in statistics [ Upstream commit c1ab80af0d99a906b60b769f2e692c37d2db1323 ] writecache_bio_copy_ssd() unconditionally adds the number of extra blocks in the merged bio to stats.writes_allocate. That is only correct when the entries were taken off the freelist. When the function is called with search_used == true -- i.e. from the write_hits_uncommitted / write_hits_committed paths in writecache_map_write() -- the first entry was found in the rbtree and every following entry is picked up with rb_next(), so nothing is allocated at all. Accordingly the writes_allocate++ that accompanies a successful writecache_pop_from_freelist() is skipped for that case, but the batch accounting below still adds n - 1. An in-place overwrite of n contiguous cached blocks therefore reports n - 1 allocations that never happened. Only the dmsetup status output is affected; there is no functional change. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Fixes: b2676e1482af ("dm writecache: count number of blocks written, not number of write bios") Signed-off-by: Sasha Levin commit e4fffe43c7052f2131236c6f3d75656452e1ab8c Author: Mikulas Patocka Date: Wed Sep 30 21:38:25 2026 +0200 dm-writecache: report I/O error if flush failed [ Upstream commit 78a6afc2999d26e5a30a56db77db34c22b88f5d5 ] There was a bug that if writecache_flush fails due to I/O error, the error is not reported in the FUA bio. This commit fixes it. Signed-off-by: Mikulas Patocka Assisted-by: opencode:big-pickle Cc: stable@vger.kernel.org Fixes: 48debafe4f2f ("dm: add writecache target") Signed-off-by: Sasha Levin commit ae3cf25c6fbed9ad71d5cdb5409d0f5f9bdd9d51 Author: Mikulas Patocka Date: Wed Sep 30 21:35:31 2026 +0200 dm: fix a bug in dm_accept_partial_bio [ Upstream commit a279804752e6c767b7f9ecbb32a15bdfd2b80aea ] dm-writecache doesn't work in pmem mode - mkfs.ext4 and the following fsck.ext4 fail with data corruption reported. The commit 7dd76d1feec7 ("dm: improve bio splitting and associated IO accounting") introduced a latent bug in dm_accept_partial_bio - it set tio->io->sectors = n_sectors;. This is incorrect, according to the diagram in the source code at dm_accept_partial_bio, it should be the size of regions 1+2, not the region 2 alone. The latent bug become real bug with the commit 8b211aaccb91 ("dm: add two stage requeue mechanism"). dm-writecache in pmem mode is the only target that actually advances bio with bio_advance and then calls dm_accept_partial_bio (so, the region 1 is non-empty). All the other targets call dm_accept_partial_bio with region 1 empty, so bug went unnoticed for so long. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Fixes: 8b211aaccb91 ("dm: add two stage requeue mechanism") Signed-off-by: Sasha Levin commit 9bc203322dbc8c2fe608555e387d4b493c4da2ef Author: Kaho Jiang Date: Mon Sep 28 20:19:04 2026 -0400 media: em28xx: fix double free in em28xx_alloc_urbs [ Upstream commit fd427b8adae437cac78a2332241a03cac56e95c2 ] When allocation of usb_bufs->buf[i] fails, em28xx_alloc_urbs() explicitly frees all items within usb_bufs->buf before calling em28xx_uninit_usb_xfer(), which also frees these items, causing them to be freed twice. BUG: KASAN: double-free in usb_free_urb.part.0 (drivers/usb/core/urb.c:25 ./include/linux/kref.h:65 drivers/usb/core/urb.c:96) Free of addr ffff88802fd37c00 by task kworker/1:2/1182 Workqueue: events request_module_async Call Trace: kasan_report_invalid_free (mm/kasan/report.c:557) check_slab_allocation (mm/kasan/common.c:235) kfree (./include/linux/kasan.h:199 (discriminator 1) mm/slub.c:2693 (discriminator 1) mm/slub.c:6508 (discriminator 1) mm/slub.c:6801 (discriminator 1)) usb_free_urb.part.0 (drivers/usb/core/urb.c:25 ./include/linux/kref.h:65 drivers/usb/core/urb.c:96) usb_free_urb (drivers/usb/core/urb.c:95) em28xx_uninit_usb_xfer (drivers/media/usb/em28xx/em28xx-core.c:964) em28xx_alloc_urbs (drivers/media/usb/em28xx/em28xx-core.c:1076) em28xx_dvb_init (drivers/media/usb/em28xx/em28xx-dvb.c:1734 drivers/media/usb/em28xx/em28xx-dvb.c:1698) em28xx_init_extension (drivers/media/usb/em28xx/em28xx-core.c:1248) request_module_async (drivers/media/usb/em28xx/em28xx-cards.c:3685) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 1182: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kmalloc_noprof (./include/linux/kasan.h:263 mm/slub.c:5414 mm/slub.c:5439) em28xx_alloc_urbs (./include/linux/slab.h:995 ./include/linux/slab.h:1312 drivers/media/usb/em28xx/em28xx-core.c:1081) em28xx_dvb_init (drivers/media/usb/em28xx/em28xx-dvb.c:1734 drivers/media/usb/em28xx/em28xx-dvb.c:1698) em28xx_init_extension (drivers/media/usb/em28xx/em28xx-core.c:1248) request_module_async (drivers/media/usb/em28xx/em28xx-cards.c:3685) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Freed by task 1182: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2748 mm/slub.c:6508 mm/slub.c:6801) em28xx_alloc_urbs (drivers/media/usb/em28xx/em28xx-core.c:1084) em28xx_dvb_init (drivers/media/usb/em28xx/em28xx-dvb.c:1734 drivers/media/usb/em28xx/em28xx-dvb.c:1698) em28xx_init_extension (drivers/media/usb/em28xx/em28xx-core.c:1248) request_module_async (drivers/media/usb/em28xx/em28xx-cards.c:3685) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Remove the explicit cleanup loop and let em28xx_uninit_usb_xfer() handle the cleanup. Fixes: d571b592c6206 ("media: em28xx: don't use coherent buffer for DMA transfers") Cc: stable@vger.kernel.org Reported-by: co+6a04efcebe0fc0ce@bugs.sh Assisted-by: LLM Signed-off-by: Kaho Jiang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 50caebd59e85f617a2719e684b31b2b3b5d49715 Author: Ginger Li Date: Mon Sep 28 09:47:44 2026 +0200 media: exynos4-is: Fix a race between s_stream(0) and the interrupt handler [ Upstream commit c65eb69f8170975802ddbede84420553eb681d62 ] fimc_lite_subdev_s_stream(on = 0) sets ST_FLITE_OFF outside of the fimc->slock protected region, and only then stops the capture in the hardware. flite_irq_handler() runs under fimc->slock and clears ST_FLITE_OFF, so an interrupt can be handled in between: the handler finds ST_FLITE_OFF already set, clears it and wakes up fimc->irq_queue before the capture has actually been stopped. The wait_event_timeout() right after it then returns immediately and the driver continues as if the capture had stopped. Set ST_FLITE_OFF in the same critical section that stops the capture, as fimc_lite_stop_capture() already does. Fixes: 6319d6a002be ("[media] fimc-lite: Add ISP FIFO output support") Cc: stable@vger.kernel.org Signed-off-by: Ginger Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 65939ff0f95451078879bfafaff83266ed4c5095 Author: Guangshuo Li Date: Thu Sep 24 21:55:14 2026 +0800 media: rtl28xxu: fix SDR platform device leak [ Upstream commit 083a92996598a5080965f1baa84175082e14a45b ] rtl2832u_tuner_attach() registers an rtl2832_sdr platform device, but does not unregister it if no driver is bound. It also does not take a reference on the bound driver module. Unregister the platform device when no driver is bound or the module reference cannot be acquired. Drop the module reference in rtl28xxu_tuner_detach() before unregistering the device. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: a2f7f220df5e ("[media] rtl28xxu: switch SDR module to platform driver") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3bb216f4eef1037d437425d7ab56d62e4e432b9d Author: Wentao Liang Date: Thu Sep 17 10:09:24 2026 +0000 media: pvrusb2: Fix USB parent device leak in class_dev_create() [ Upstream commit 02421d7278e4a62c3daf37ad6c45d4af96ee4252 ] class_dev_create() stores a reference to the USB device obtained with get_device() in class_dev->parent, which class_dev_destroy() releases. When device_register() fails the function only drops class_dev, so the reference to the USB parent device is never released. Drop the parent reference on the failure path as well. Fixes: 28c4a5e6d324 ("V4L/DVB: pvrusb2: Fix USB parent device reference count") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 75e716e458f3093ee5cf5d38383b08c43821f435 Author: Guangshuo Li Date: Tue Sep 15 19:08:58 2026 +0800 media: tw686x: fix V4L2 device lifetime on probe failure [ Upstream commit ce6c6dd632b3b4a2c2bfc9efd8f656f4d2137dbd ] tw686x_video_init() registers the V4L2 device, which initializes its reference count. Successfully registered video devices take additional references to the V4L2 device as well. The probe failure paths currently tear down the PCI resources and then free the channel arrays and the tw686x device directly. This bypasses the V4L2 device reference count and the tw686x_dev_release() callback. If a video device still holds a reference, its eventual release will drop a reference to the already freed V4L2 device. Even when no extra references remain, directly freeing the device bypasses the lifetime management established by v4l2_device_register(). After cleaning up the PCI resources, check whether the V4L2 device was registered. If so, mark the hardware unavailable and drop the driver's V4L2 device reference, letting tw686x_dev_release() free the backing objects when the final reference is released. Keep the existing direct free path for failures that occur before V4L2 device registration. This issue was found by manual code inspection. Fixes: 704a84ccdbf1 ("[media] media: Support Intersil/Techwell TW686x-based video capture cards") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5ce411b4b92ff923fbb956f63052665cf1b3d7ef Author: Tianchu Chen Date: Fri Sep 11 11:10:42 2026 +0000 staging: rtl8723bs: fix RX buffer OOB write from device-reported length [ Upstream commit c52929073fccbc149267a2fd7458626a7e9abcfc ] sd_recv_rxfifo() trusts the device-reported RX0_REQ_LEN value (hal->SdioRxFIFOSize, a u16 read from the card via CMD52) as the size of the next RX packet and passes it to sdio_read_port(), which copies that many bytes into the recvbuf skb whose data area is only MAX_RECVBUF_SZ (10240) bytes. A bogus device on SDIO can report up to 65535 bytes, causing a heap overflow of up to ~55KB past the skb buffer. Bail out when the RX0_REQ_LEN exceeds MAX_RECVBUF_SZ. This is expected to keep behavior unchanged on normal devices. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/8114c3adc1acaea78523cc0fb4d4b25f7665cee9@linux.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9ebdbaea9f5d9f109b564e46aeac3a99a25c5ba9 Author: Johan Hovold Date: Mon Sep 7 11:53:05 2026 +0200 staging: greybus: uart: fix racy TIOCMIWAIT implementation [ Upstream commit e94cda6551d4716b17353fc458baa9e85ddea9ff ] Check the wakeup condition after adding the task to the waitqueue and updating the task state to avoid missing a racing modem status update or disconnect. Store the old icount on entry and do not update it in the completion handler to avoid missing events or reporting spurious ones (due to modem status changes before TIOCMIWAIT was called). Fixes: e68453ed28c5 ("greybus: uart-gb: now builds, more framework added") Cc: stable@kernel.org # 4.9 Cc: Greg Kroah-Hartman Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260907095305.130762-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 75242ebb72ebbb2f99e82d11227f48e123431f33 Author: Krzysztof Kozlowski Date: Fri Sep 11 12:29:36 2026 +0200 drm/msm/hdmi_bridge: Correct poweroff/audio cleanup order in post_disable [ Upstream commit 0499f0576e4442d67c164119f9d7f75d3cc945e7 ] Turning off the power in msm_hdmi_bridge_atomic_post_disable() should follow reverse order of powering up, not only because it is logical, but also because msm_hdmi_audio_update() accesses registers thus block should still be powered on. Depending on specific timing, existing code could have accesses to MMIO of powered off block. Cc: stable@vger.kernel.org Fixes: c0c0d9eeeb8d ("drm/msm: hdmi audio support") Reviewed-by: Konrad Dybcio Signed-off-by: Krzysztof Kozlowski Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/752655/ Link: https://lore.kernel.org/r/20260911-drm-msm-hdmi-fixes-before-eliza-v4-3-87bdb9f1987f@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 9c864a4d5d40a29c299ad92b1388b47077892afe Author: Krzysztof Kozlowski Date: Fri Sep 11 12:29:34 2026 +0200 drm/msm/hdmi_phy: Cleanup after msm_hdmi_phy_resource_enable() failure [ Upstream commit d27f831aaf20aaf06e41ceb1b260e10672269155 ] If msm_hdmi_phy_resource_enable() fails, e.g. when enabling regulators, it should reverse the state of things already changed. msm_hdmi_phy_resource_enable() is used also in probe path, thus such failure, which could be simple deferred probe, would leave these resources permanently enabled for the rest of the runtime. Cc: Fixes: 15b4a4523859 ("drm/msm/hdmi: Create a separate HDMI PHY driver") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/752654/ Link: https://lore.kernel.org/r/20260911-drm-msm-hdmi-fixes-before-eliza-v4-1-87bdb9f1987f@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 0a275d29d8557c787230138e50f4e59acb032f20 Author: Alexander Sverdlin Date: Tue Sep 29 14:08:02 2026 +0200 pwm: tiehrpwm: Clear period on disable to allow reconfiguration [ Upstream commit e74b9a7ee50071aad25d3989bf985292f90b0c6e ] Both channels share one period register, so ehrpwm_pwm_config() rejects a period differing from the sibling's period_cycles[]. That value was cleared only in .free(), not in .disable(), so a stopped channel kept blocking the sibling from switching to a new frequency. Clear it in .disable() too. Testcase: cd /sys/class/pwm/pwmchip0; echo 0 > export; echo 1 > export for p in pwm0 pwm1; do echo 1000000 > $p/period; echo 500000 > $p/duty_cycle echo 1 > $p/enable; echo 0 > $p/enable; echo 2000000 > $p/period done echo 1 > pwm0/enable # before: -EINVAL, after: succeeds Fixes: 01b2d4536f02 ("pwm: pwm-tiehrpwm: Fix conflicting channel period setting") Cc: stable@vger.kernel.org Signed-off-by: Alexander Sverdlin Link: https://patch.msgid.link/20260929120806.2790355-1-alexander.sverdlin@siemens.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit a8377f82a969fe5e2230306b14dcbcc74086d9c2 Author: Ryusuke Konishi Date: Tue Sep 29 15:38:14 2026 +0900 nilfs2: clear dirty flag on bdev buffers on log write failure [ Upstream commit 6faad04a002603d800134398fcd042b403b32d35 ] Since the commit referenced in the Fixes tag stopped directly calling inode_attach_wb(), a dirty flag is set on buffers (with mark_buffer_dirty()) allocated to the backing device for segment summaries and the super root block during log writes. While this dirty flag is cleared upon a successful log write, it remains uncleared if the log write fails. Consequently, when a log write fails, these backing device buffers are left in an inconsistent state where their uptodate flag and the dirty flag of the containing page/folio are cleared, but the buffer's dirty flag remains as stale garbage. Particularly when the block size is smaller than the page size, if other buffers on the same page/folio become dirty, this buffer unexpectedly becomes a target for writeback again. As a result, if the block is later reused for other data or metadata, that contents risks being corrupted. Fix this issue by calling clear_buffer_dirty() for the backing device buffers when aborting log writes in nilfs_abort_logs(). Fixes: 68142cb628f7 ("nilfs2: do not call inode_attach_wb() directly") Cc: stable@vger.kernel.org Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit b67a0ec93fd0d01101667d736d2c52ee2e1e0127 Author: Runyu Xiao Date: Tue Sep 29 17:59:20 2026 +0800 ASoC: pcm6240: do not free an unrequested IRQ [ Upstream commit 995b96380ba5d98131acc162608da3538e1395d8 ] The driver obtains an IRQ number from device tree but never requests an IRQ handler for the PCM6240 device. Removing the device must not pass that number to free_irq(). Leave IRQ ownership to a matching request path if one is added later. Fixes: 1324eafd37aa ("ASoc: PCM6240: Create PCM6240 Family driver code") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260929095920.2092147-1-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bed0159832b6ea0796b8e2ce6b74fd601cae9cdc Author: Srish Srinivasan Date: Wed Sep 23 23:58:11 2026 +0530 pseries/plpks: clear SED key data after use [ Upstream commit 217ba01e5b9096091acc2c1a3776cb3eb88c00ff ] Explicitly clear the temporary buffer containing SED key data after read and write operations. Fixes: ec8cf230cecc ("powerpc/pseries: PLPKS SED Opal keystore support") Cc: stable@vger.kernel.org # 6.7 Signed-off-by: Srish Srinivasan Tested-by: R Nageswara Sastry Reviewed-by: Greg Joyce Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260923182816.151451-8-ssrish@linux.ibm.com Signed-off-by: Sasha Levin commit 855d88643dd1dd6967662ada76397d291272585f Author: Srish Srinivasan Date: Wed Sep 23 23:58:10 2026 +0530 pseries/plpks: clear signed update authentication buffer [ Upstream commit 63de55024e7c85975f4410380323edb05b186d7c ] The PLPKS signed update operation uses an authentication buffer that contains a password. Freeing this buffer with kfree(), without wiping the contents, can leave sensitive data in memory. Use kfree_sensitive() to wipe the buffer when freeing it. Fixes: 899d9b8fee66 ("powerpc/pseries: Implement signed update for PLPKS objects") Cc: stable@vger.kernel.org # 6.3 Signed-off-by: Srish Srinivasan Tested-by: R Nageswara Sastry Reviewed-by: Nayna Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260923182816.151451-7-ssrish@linux.ibm.com Signed-off-by: Sasha Levin commit 06d8eacaab40104958df1515b76875df5dd94ae0 Author: Srish Srinivasan Date: Wed Sep 23 23:58:08 2026 +0530 pseries/plpks: clear sensitive PLPKS buffers [ Upstream commit fe18716ff314eb32299048fd64242d31b4e852cf ] PLPKS read, remove, and write operations use authentication buffers that contain passwords. The read output buffer may also contain sensitive data. Freeing these buffers with kfree(), without wiping the contents, can leave sensitive data in memory. Use kfree_sensitive() to wipe the buffers when freeing them. Fixes: 2454a7af0f2a ("powerpc/pseries: define driver for Platform KeyStore") Cc: stable@vger.kernel.org # 6.0 Signed-off-by: Srish Srinivasan Tested-by: R Nageswara Sastry Reviewed-by: Nayna Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260923182816.151451-5-ssrish@linux.ibm.com Signed-off-by: Sasha Levin commit a3c3ec5e36f431950dab8fd40778ec54aa305536 Author: Srish Srinivasan Date: Wed Sep 23 23:58:07 2026 +0530 pseries/plpks: validate input to plpks_signed_update_var() [ Upstream commit b59ff2d50b817eeec1259f357aae821c7834007f ] plpks_signed_update_var() dereferences the supplied PLPKS variable pointer without validating it. A NULL argument could therefore result in a NULL pointer dereference. Reject a NULL pointer argument with -EINVAL. Fixes: 899d9b8fee66 ("powerpc/pseries: Implement signed update for PLPKS objects") Cc: stable@vger.kernel.org # 6.3 Signed-off-by: Srish Srinivasan Tested-by: R Nageswara Sastry Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260923182816.151451-4-ssrish@linux.ibm.com Signed-off-by: Sasha Levin commit 02a30119e299070db5f3e6986812ebf2042aebf1 Author: Srish Srinivasan Date: Wed Sep 23 23:58:05 2026 +0530 pseries/plpks: fix error handling in plpks_read_var() [ Upstream commit d52a1659cb1718f93166ab8dd8621237e564a1c4 ] When a PLPKS variable is initialized without a policy and used to read an object with the PLPKS_WRAPPINGKEY policy set, the hypervisor returns H_AUTHORITY along with the object's policy. However, plpks_read_var() currently treats this the same as any other H_AUTHORITY failure and returns an error without propagating the policy information to the caller. Distinguish this case from other H_AUTHORITY failures and propagate the returned policy to the caller while preserving the authorization error. Remove the explicit assignment of zero to rc on H_SUCCESS, as it is redundant. Also validate the PLPKS variable pointer before dereferencing it. Fixes: 2454a7af0f2a ("powerpc/pseries: define driver for Platform KeyStore") Cc: stable@vger.kernel.org # 6.0 Signed-off-by: Srish Srinivasan Tested-by: R Nageswara Sastry Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260923182816.151451-2-ssrish@linux.ibm.com Signed-off-by: Sasha Levin commit 9eaa5727989ccfcbd75a732d98ebff8fdfd84972 Author: Wentao Liang Date: Thu Jun 4 06:43:14 2026 +0000 clk: starfive: jh7110-isp: fix refcount leak in jh7110_ispcrg_probe() [ Upstream commit 1c4f9480473917558908c083d1293b4ebb3d50c5 ] In jh7110_ispcrg_probe(), the error path for pm_runtime_get_sync() failure directly returns without releasing the runtime PM reference count. The call to __pm_runtime_resume() increments the usage count unconditionally before attempting to resume, and does not decrement it on failure. Thus the leaked reference makes it impossible to suspend the device later. All other error paths correctly jump to err_exit and call pm_runtime_put_sync(). Fix this by replacing pm_runtime_get_sync() with pm_runtime_resume_and_get(), which properly balances the reference count on error. Cc: stable@vger.kernel.org Fixes: 81279f5d0812 ("clk: starfive: Add StarFive JH7110 Image-Signal-Process clock driver") Signed-off-by: Wentao Liang Reviewed-by: Hal Feng Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit df10fb2564b6e66c552b13b60cb320d733e40a8b Author: Takashi Iwai Date: Tue Sep 29 14:53:41 2026 +0200 ALSA: core: Check shutdown flag at D0 power-state, too [ Upstream commit ad63c5b62843895e8c3cd7291ed07cc659df0355 ] The snd_power_ref_and_wait() skips the card->shutdown check when the card is already in D0 state and immediately returns as successful, by assuming the all-green in D0. This assumption makes the code after this sync point behaving as if all power is up and ready, even though actually it might have been already at the disconnected state. Add the missing check of shutdown flag there for the more consistent behavior. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260929125346.1478631-2-tiwai@suse.de Signed-off-by: Sasha Levin commit 6ebb9d8c7e204bbf0d82f5a35cfd8fd5a13939bd Author: Runyu Xiao Date: Tue Sep 29 16:54:00 2026 +0800 m68k: dmasound: Keep the Q40 IRQ handler registered [ Upstream commit fa2e77ac5bf81a60864e71fc72196227692d7162 ] Q40PlayNextFrame() re-registers the sample IRQ after stopping it. This function can be called with dmasound.lock held and from the sample IRQ handler, so free_irq() and request_irq() can sleep or deadlock. A failed re-registration can also leave playback without an IRQ. Register one handler for the lifetime of the driver and select mono or stereo sample handling inside that handler. Call the frame completion path after releasing dmasound.lock so it can refill the queue safely. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260929085400.2068977-1-runyu.xiao@seu.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8f419ef6801b9de394b92c9ca5523900ab3e4dca Author: Runyu Xiao Date: Tue Sep 29 16:45:40 2026 +0800 ALSA: sgio2audio: Only free successfully requested IRQs [ Upstream commit af3d225b639c6f9fb8fd5e1e27f11672d56724b6 ] snd_sgio2audio_create() calls snd_sgio2audio_free() when an IRQ request fails. The cleanup helper currently walks the complete IRQ table, including entries whose request_irq() calls have not been attempted yet. free_irq() then receives an IRQ and dev_id pair that was never registered. Pass the number of successfully requested IRQs to the cleanup helper on the request failure path, while retaining the full-table cleanup for teardown after all requests have succeeded. Fixes: 862c2c0a61c5 ("ALSA: ALSA driver for SGI O2 audio board") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260929084540.2065213-1-runyu.xiao@seu.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d5a82968ecc160bc48063912cf9e16f2c5ddd871 Author: Hitesh Patel Date: Mon Sep 28 17:45:05 2026 +0530 media: qcom: camss: vfe: Fix VFE reset while another line is streaming [ Upstream commit e5d4b0e69a4017fd39354499c9d7583f625f0524 ] vfe_disable_output() stops the write masters of the line being disabled and then resets the whole VFE. The reset is not limited to that line. When two lines of one VFE stream at the same time, which is the case whenever a CSID demultiplexes several virtual channels to different RDIs, stopping the first line resets the VFE underneath the second line. The second line's write master configuration is wiped, the buffers it had in flight are never completed, and the VFE is left in a state in which the next global reset is not acknowledged. Stopping or restarting the second line then fails with: VFE reset timeout Move the reset to vfe_disable() and do it under stream_lock, as part of the decrement that makes the count reach zero, so that exactly one caller resets and no line can be enabled while the reset runs. Stopping the line's write masters is enough to quiesce that line on its own. With a single line streaming, the reset happens exactly as before. Fixes: 7319cdf189bb ("media: camss: Add support for VFE hardware version Titan 170") Cc: stable@vger.kernel.org Signed-off-by: Hitesh Patel Suggested-by: Bryan O'Donoghue Reviewed-by: Bryan O'Donoghue [bod: Converted vfe_disable_output to void] Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit 94b6cd4401d4b8ee66ac4d919fa374ca4cb52890 Author: Hitesh Patel Date: Mon Sep 28 17:45:03 2026 +0530 media: qcom: camss: vfe-17x: Fix write master buffer done being dropped [ Upstream commit eed550a8191c2f6984047a1b794b313d1bacf77d ] The VFE 17x interrupt handler reads and clears the bus status registers on every interrupt, but only acts on the per write master BUF_DONE bits when bit 9 of IRQ_STATUS_0 is set as well. Bit 9 is the ping-pong flag of image master 1. It has nothing to do with the other write masters, and it is not guaranteed to be set in the same interrupt in which a write master reports a completed buffer. The bus status is read-to-clear. When a buffer done arrives while bit 9 is not set, the handler clears the status and never calls wm_done() for it. The buffer stays queued in the driver and the video node never receives that frame. With one RDI streaming this is rare. With two RDIs streaming on the same VFE, for instance two virtual channels demultiplexed by the CSID, the interrupt rate doubles and one of the two lines loses buffer done events continuously. Act on the bus status alone, as the other gen2 VFE handlers do. Fixes: 7319cdf189bb ("media: camss: Add support for VFE hardware version Titan 170") Cc: stable@vger.kernel.org Reviewed-by: Bryan O'Donoghue Reviewed-by: Loic Poulain Signed-off-by: Hitesh Patel Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit ebbda0b1d5fdce1db828504afcff87badaeac284 Author: Jiale Yao Date: Sat Sep 26 15:16:05 2026 +0800 cxl/acpi: Check ACPI companion before use [ Upstream commit 371c2ad1624283b6c7a62a28199f5161d388a738 ] Platform drivers can be forced to match devices outside their ID tables through driver_override. cxl_acpi_probe() assumes that every bound device has an ACPI companion and dereferences adev->dev.bus without checking the result of ACPI_COMPANION(). Force-binding cxl_acpi to a platform device without a companion therefore causes a NULL pointer dereference. This was reproduced by setting the driver override for the pcspkr platform device to cxl_acpi and binding it through sysfs: BUG: kernel NULL pointer dereference, address: 0000000000000280 #PF: supervisor read access in kernel mode RIP: cxl_acpi_probe+0xf4/0x220 Call Trace: platform_probe+0x4d/0x80 really_probe+0x106/0x370 device_driver_attach+0x4c/0xa0 bind_store+0xd0/0x100 Commit 2b3a5dabe89e ("platform/surface: acpi-notify: Check ACPI companion before use") fixed the same force-binding issue in another platform driver. Check the companion before setting up the CXL root and return -ENODEV when it is absent. Fixes: 7d4b5ca2e2cb ("cxl/acpi: Add downstream port data to cxl_port instances") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260926071605.3013893-1-yaojiale02@163.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 89579415a00b776698334586e6ecf01efd00049c Author: Ibrahim Hashimov Date: Thu Jul 9 00:46:18 2026 +0200 fs/ntfs3: fix integer overflow in find_log_rec() causing OOB read [ Upstream commit e2fcb0040b0b4097b2e97f3fbe77d3b66df9e816 ] find_log_rec() validates the on-disk LFS_RECORD_HDR.client_data_len field (`len`, a raw u32 read straight from a mounted $LogFile page) against the log's total available space: len = le32_to_cpu(rh->client_data_len); rec_len = len + log->record_header_len; if (rec_len >= log->total_avail) return -EINVAL; The addition is unchecked. For len in [0xffffffd0, 0xffffffff] (i.e. log->record_header_len away from UINT_MAX), `rec_len` wraps to a small u32 value that trivially clears the `rec_len >= log->total_avail` guard, so a record whose declared length is actually ~4 GiB is reported as valid and in-page. Because find_log_rec() wrongly accepts the record, its caller read_log_rec_lcb() hands it back to log_replay() as good. On the transaction-table replay leg, log_replay() re-derives the record length directly from the same raw, still-unclamped client_data_len field and uses it to size the restart-table blob: rec_len = le32_to_cpu(frh->client_data_len); /* ~0xffffffff */ ... t16 = le16_to_cpu(lrh->redo_off); rt = Add2Ptr(lrh, t16); t32 = rec_len - t16; /* still ~4 GiB */ if (!check_rstbl(rt, t32)) return -EINVAL; check_rstbl()'s own `bytes < ts` bounds guard is defeated because the caller-supplied `bytes` (t32) is itself the poisoned ~4 GiB value, so the guard can never trigger. The subsequent entry-validation loop then walks `rt->used` (also attacker-controlled) entries of sizeof(struct RESTART_TABLE) == 0x18 bytes each straight past the end of the kmalloc(log->page_size) log-page buffer allocated in read_log_page(), producing an out-of-bounds read that is reachable simply by mounting a crafted $LogFile (no genuine dirty-page / crash-recovery state is required). Confirmed via KASAN as a slab-out-of-bounds read in check_rstbl(), called from log_replay() -> ntfs_loadlog_and_replay() -> ntfs_fill_super() -> mount(2). Fix the root cause instead of hardening every downstream consumer of the poisoned length: make the addition in find_log_rec() overflow-safe with check_add_overflow(), mirroring the pattern fs/ntfs3/run.c already uses to validate other attacker-controlled on-disk length/offset arithmetic decoded from MAPPING_PAIRS runs, e.g.: if (check_add_overflow(vcn64, len, &next_vcn)) return -EINVAL; ... if (check_add_overflow(lcn, len, &lcn_end)) return -EINVAL; (fs/ntfs3/run.c, run_unpack()). With the overflow rejected instead of silently wrapped, `rec_len` is only ever a true, non-wrapped sum, so the existing `rec_len >= log->total_avail` check now correctly rejects any oversized record up front. log_replay()'s transaction-table leg then never gets a chance to re-read the poisoned client_data_len, and check_rstbl() is never invoked with an attacker-inflated `bytes` for this path. Verified on a v6.19 KASAN build: mounting a crafted $LogFile whose client_data_len overflows trips a KASAN slab-out-of-bounds-read report in check_rstbl() before this fix; with check_add_overflow() applied, the same image is cleanly rejected during log replay and no KASAN report fires. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 55026a95f24a7e874dce1ab498dd54638f883b24 Author: Lucas Costa <2000.costalucas@gmail.com> Date: Fri Sep 25 16:30:08 2026 -0300 spi: bcm2835: fix device_node reference leak in bcm2835_spi_setup() [ Upstream commit 8db44cca03df066186d6220bfad9fa482d7cdc13 ] of_find_compatible_node() returns a device_node with its reference count incremented, but bcm2835_spi_setup() only uses the return value to test for a matching node in the loop and never releases it. Declare the node with a scope-based __free(device_node) cleanup so the reference is dropped automatically when leaving the loop body, matching the existing __free(kfree) usage in the same function. Fixes: e19c1272c80a ("spi: bcm2835: Restore native CS probing when pinctrl-bcm2835 is absent") Cc: stable@vger.kernel.org Signed-off-by: Lucas Costa <2000.costalucas@gmail.com> Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260925193008.127314-1-2000.costalucas@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c3255befb131945f624c03311860e7b5f279bcd5 Author: Cheick Traore Date: Thu Sep 24 11:53:56 2026 +0200 iio: adc: stm32: fix minimum sampling time values [ Upstream commit ef04fdc999ee40a58d513ea48d391c7dc78c908c ] - On stm32mp15: vddcpu and vddq_ddr are not connected to internal channel, so their sampling time shouldn't be set. - On stm32mp13: vddcpu and vddq_ddr are connected to internal channels and the value for vddcore was not correct. Values from the datasheet are 1us (e.g. 1000ns) for ts_vddcore, ts_vddcpu and ts_vddq_ddr. Fixes: 7cb2303dd024 ("iio: adc: stm32: manage min sampling time on all internal channels") Cc: stable@vger.kernel.org Signed-off-by: Cheick Traore Signed-off-by: Fabrice Gasnier Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit de16c360141a8d2b7e1fd28e0902954ccfdb6d05 Author: Jiale Yao Date: Fri Sep 25 20:43:30 2026 +0800 iio: accel: adxl380: reject devices without match data [ Upstream commit 9f6d174e9fa5b265e7a0a6caa0c5b579bf899702 ] SPI driver_override allows a device to bind to this driver without matching either the OF or SPI device ID table. In that case, spi_get_device_match_data() returns NULL. adxl380_spi_probe() passes the result to adxl380_probe(), which dereferences chip_info to set the IIO device name and operations, causing a NULL pointer dereference. Commit 572a00852635 ("iio: dac: ad5686: missing NULL check on match data") fixed the same driver_override issue in another SPI driver. Reject devices without match data in the SPI frontend. Fixes: df36de13677a ("iio: accel: add ADXL380 driver") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 880a85d01493cc5c4fa24c8a3a8a6bfa91e30f72 Author: Jiale Yao Date: Fri Sep 25 20:43:28 2026 +0800 iio: accel: adxl313: reject devices without match data [ Upstream commit defd4c0b29f1cd17caa5feebac33fc5fdf4e1916 ] SPI driver_override allows a device to bind to this driver without matching either the OF or SPI device ID table. In that case, spi_get_device_match_data() returns NULL. adxl313_spi_probe() dereferences chip_data to select the regmap configuration, causing a NULL pointer dereference. Commit 572a00852635 ("iio: dac: ad5686: missing NULL check on match data") fixed the same driver_override issue in another SPI driver. Reject devices without match data before selecting the configuration. Fixes: d6e3ee74d16f ("iio: accel: adxl313: simplify with spi_get_device_match_data()") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 458957dcb87f931a84ed56679c07f21e508c7b6e Author: Jiale Yao Date: Fri Sep 25 20:57:44 2026 +0800 iio: adc: ti-adc128s052: validate SPI match data [ Upstream commit 4ac257f2fd2a9cac00e748486fa003b4e1cc453e ] SPI driver_override allows a device to bind to this driver without matching either the firmware tables or SPI device ID table. In that case, spi_get_device_match_data() returns NULL. adc128_probe() also obtains the IIO device name by dereferencing the result of spi_get_device_id(), which is NULL on the same override path. The probe can therefore crash before it reaches the match data access. Commit 572a00852635 ("iio: dac: ad5686: missing NULL check on match data") fixed the same driver_override issue in another SPI driver. Reject devices without match data and use the always available SPI modalias for the IIO device name. Fixes: d5f0da0c6972 ("iio: adc: ti-adc128s052: Switch to use spi_get_device_match_data()") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 365cf2ef7a0b6b9698d1d23274c3107df96e887e Author: Jiale Yao Date: Fri Sep 25 20:57:43 2026 +0800 iio: adc: mcp3911: reject devices without match data [ Upstream commit d3410a48d5eb9dd8238099cb0ee368d12005a385 ] SPI driver_override allows a device to bind to this driver without matching either the OF or SPI device ID table. In that case, spi_get_device_match_data() returns NULL. mcp3911_probe() stores the result and later calls through chip->config and accesses other chip-specific fields, causing a NULL pointer dereference. Commit 572a00852635 ("iio: dac: ad5686: missing NULL check on match data") fixed the same driver_override issue in another SPI driver. Reject devices without match data before continuing the probe. Fixes: 732ad34260d3 ("iio: adc: mcp3911: add support for the whole MCP39xx family") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit fc83dadf1677ea6d85d6aec5f8dd19c285590e7a Author: Jiale Yao Date: Fri Sep 25 20:57:42 2026 +0800 iio: adc: max11205: reject devices without match data [ Upstream commit a07b5db685b2a3084240f9b4a9ee44f3b478c6e3 ] SPI driver_override allows a device to bind to this driver without matching either the OF or SPI device ID table. In that case, spi_get_device_match_data() returns NULL. max11205_probe() immediately dereferences the returned chip information to set the IIO device name, causing a NULL pointer dereference. Commit 572a00852635 ("iio: dac: ad5686: missing NULL check on match data") fixed the same driver_override issue in another SPI driver. Reject devices without match data before using the chip information. Fixes: bf3c855be801 ("iio: adc: max11205: simplify with spi_get_device_match_data()") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 71c63820b641d1af1a8286bc6b5aa7cfca634d50 Author: Jiale Yao Date: Fri Sep 25 21:17:36 2026 +0800 iio: pressure: bmp280: validate SPI match data [ Upstream commit 206fc54554c28d76c5d8f66091b846ef1dd88f64 ] A device bound through driver_override need not match an entry in the driver tables. In that case spi_get_device_match_data() returns NULL, but bmp280_spi_probe() immediately dereferences the result. Validate the match data before selecting the regmap bus. Fixes: faac4dda9a91 ("iio: pressure: bmp280: Use spi_get_device_match_data()") Signed-off-by: Jiale Yao Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 384d81172104ec346940c254e262f82795ea880e Author: Jiale Yao Date: Fri Sep 25 21:17:35 2026 +0800 iio: potentiometer: x9250: reject devices without match data [ Upstream commit d13716e3defd5b8cec3ee2c27f4d9b7e01314067 ] A device bound through driver_override need not match an entry in the driver tables. In that case spi_get_device_match_data() returns NULL, but x9250_probe() later dereferences the result while naming the IIO device. Reject devices without match data before enabling the regulators. Fixes: 66bfc528a6fd ("iio: potentiometer: Add support for the Renesas X9250 potentiometers") Signed-off-by: Jiale Yao Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 12d9f22371ee28174965750a31efc8489988b2c8 Author: Jiale Yao Date: Fri Sep 25 21:17:33 2026 +0800 iio: frequency: adf4377: reject devices without match data [ Upstream commit 2f3196d27e3bfcee0569d23a123aedcc6ddd39f1 ] A device bound through driver_override need not match an entry in the driver tables. In that case spi_get_device_match_data() returns NULL, but the result is later dereferenced by the property parsing and initialization paths. Reject devices without match data before continuing probe. Fixes: 6140a92cd086 ("iio: frequency: adf4377: add adf4378 support") Signed-off-by: Jiale Yao Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 4fc25c41ff21b961b31fa1ffdd2add9996c08863 Author: Jiale Yao Date: Fri Sep 25 21:17:31 2026 +0800 iio: dac: ad5755: validate SPI match data [ Upstream commit 85e2c8ca7ac9e39a61e7fb18728918f6e966f439 ] A device bound through driver_override need not match an entry in the driver tables. In that case spi_get_device_match_data() returns NULL, but ad5755_probe() stores and later dereferences the result. Validate the match data before it is used. Fixes: 62d3fb9dcc09 ("iio: dac: ad5755: make use of of_device_id table") Signed-off-by: Jiale Yao Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 0aefefae0a0102a48a306461c90d01d1faac7fc2 Author: Wentao Liang Date: Thu Sep 17 16:48:53 2026 +0000 ASoC: codecs: wcd9335: Fix SLIM interface device leak in wcd9335_slim_status() [ Upstream commit 082723fee626532f176727b6438b666a96d5246c ] of_slim_get_device() returns a device with an elevated reference count, and wcd->slim_ifc_dev is intentionally kept for the codec lifetime on success. However, all the failure paths of wcd9335_slim_status() return without dropping that reference, leaking the SLIM interface device whenever the register maps cannot be created or the codec fails to come up. Put the device on each of those error paths. Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917164853.2163184-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 46bfb435097bd730f1b687275a94ab0c13a65593 Author: Lu Baolu Date: Mon Sep 28 11:27:15 2026 +0800 iommu/vt-d: Avoid out-of-range shift in qi_desc_dev_iotlb_pasid() [ Upstream commit ddea230c9fc28d1f2090ceeab3d66ce2bea658e9 ] Callers request a full Device-TLB flush by passing MAX_AGAW_PFN_WIDTH (64 - VTD_PAGE_SHIFT == 52) as @size_order. Two expressions in qi_desc_dev_iotlb_pasid() are not prepared for a value that large: unsigned long mask = 1UL << (VTD_PAGE_SHIFT + size_order - 1); ... if (!IS_ALIGNED(addr, VTD_PAGE_SIZE << size_order)) The second evaluates to 1UL << 64, which is undefined on all architectures. On x86_64 the shift count masks to zero, IS_ALIGNED(addr, 1) is trivially true, and the alignment sanity check silently degrades into a no-op. The first evaluates to 1UL << 63. That is well defined on 64-bit builds, where unsigned long is 64 bits wide, but is undefined on 32-bit ones. In practice x86 masks the shift count to five bits, so the expression yields 1UL << 31 and ~mask becomes 0x7fffffff. That value is zero-extended when applied to the 64-bit descriptor, so desc->qw1 &= ~mask; clears qw1[63:32] as well as bit 31, collapsing the ADDR field that had just been filled with ones. Reaching that requires a scalable-mode PASID configuration on 32-bit x86, which is not a realistic deployment, but the construct is wrong regardless. Compute the mask with BIT_ULL() so that it is 64-bit on every architecture, and skip the alignment check for a full flush, where it is both meaningless and the source of the out-of-range shift. Note that @size_order must not be clamped below 64 - VTD_PAGE_SHIFT. With S set, hardware derives the invalidation range from the least significant zero bit N of ADDR and matches bits [63:N+1] of the incoming address. For size_order 52 the descriptor sets ADDR[63:12] and clears bit 63, making N = 63 and the comparison range empty, so everything is invalidated. Reducing @size_order to 51 would instead leave N = 62 and cause hardware to compare address bit 63; since callers pass an address of 0, only the lower half of the address space would be invalidated. Bound @size_order at 64 - VTD_PAGE_SHIFT so that a bogus caller cannot reintroduce an out-of-range shift, without altering the full-flush encoding. The non-PASID variant qi_desc_dev_iotlb() already uses 1ULL and is unaffected. Fixes: f701c9f36bcb7 ("iommu/vt-d: Factor out invalidation descriptor composition") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260623060122.3796325-1-guanghuifeng%40linux.alibaba.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit d5a8c9046fd62a0143b0a50e33e7d9ddc24d4f74 Author: David Heidelberg Date: Wed Sep 16 00:25:47 2026 +0200 arm64: dts: qcom: sdm845-xiaomi-polaris: Extend the xbl_mem region [ Upstream commit 38458f12419f456b16385c118bcacd76899d99b9 ] Xiaomi's Oreo-era tree still had the CAF 1 MiB region, the 2 MiB version arrived with the Pie import. This isn't a board-layout quirk, it tracks the firmware. The later XBL wants one extra MiB below the old region. Cc: stable@vger.kernel.org Fixes: be497abe19bf ("arm64: dts: qcom: Add support for Xiaomi Mi Mix2s") Signed-off-by: David Heidelberg Link: https://patch.msgid.link/20260916-sdm845-xbl-mem-v1-2-6e3c88507997@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b168ac9ad43194fe881f9a2120687cb6d721603c Author: David Heidelberg Date: Wed Sep 16 00:25:46 2026 +0200 arm64: dts: qcom: sdm845-xiaomi-beryllium: Extend the xbl_mem region [ Upstream commit 511c4fea32708a065e03503c0e4d44f48990c530 ] Xiaomi's Oreo-era tree still had the CAF 1 MiB region, the 2 MiB version arrived with the Pie import. This isn't a board-layout quirk, it tracks the firmware. The later XBL wants one extra MiB below the old region. Cc: stable@vger.kernel.org Fixes: 77809cf74a8c ("arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)") Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260916-sdm845-xbl-mem-v1-1-6e3c88507997@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2baf7c818f4ca210fd116c787fc19adf9e49617d Author: Piotr Kubik Date: Wed Sep 9 16:49:29 2026 +0200 netfilter: ctnetlink: fix inverted IPv6 address match in dump filter [ Upstream commit 1ae2d094b0200f687923298c0e42579273558988 ] ctnetlink_filter_match_tuple() rejects an entry when !ipv6_addr_cmp(filter, entry) is true. ipv6_addr_cmp() is a memcmp() and returns 0 for equal addresses, so the condition is true exactly when the addresses match: a CTA_FILTER dump with an IPv6 CTA_IP_SRC or CTA_IP_DST skips every entry that matches the requested address and returns all the others. The IPv4 branch compares with != and behaves correctly. Observed with libnetfilter_conntrack NFCT_FILTER_DUMP_TUPLE: a dump filtered on src 2001:db8::10 returned only the unrelated entries, and a dump filtered on ::1 returned every entry except the ::1 ones. conntrack-tools does not use the tuple filter for -L, which is why this went unnoticed. Use ipv6_addr_equal() so the IPv6 branch mirrors the IPv4 one. Fixes: cb8aa9a3affb ("netfilter: ctnetlink: add kernel side filtering for dump") Cc: stable@vger.kernel.org Signed-off-by: Piotr Kubik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit bc977f434e9e7d0ce7f065ff18eba71e73e5f854 Author: Orgad Shaneh Date: Tue Sep 15 07:13:25 2026 +0000 MIPS: mm: do not write a huge TLB entry when the probe misses [ Upstream commit 0cb17268887e1df5c425ea052f5146b42d126323 ] __update_tlb() probes for the 8K pair at the address it is given and, for a huge pmd, writes the huge entry with tlbwi at the probed index or with tlbwr when the probe misses. That works only if the caller passes the faulting address, so that the probe finds the 4K entry the refill handler loaded for the faulting page and the huge entry replaces it. update_mmu_cache_pmd() is not called that way. do_set_pmd() has always passed the huge-aligned address, and since commit ebcfc63d6bca ("mm: abstract THP allocation") the anonymous THP fault path does too (map_anon_folio_pmd()). The probe then misses the stale 4K entry, which sits at the faulting page somewhere else in the 2 MB range, tlbwr adds a huge entry next to it, and the TLB holds two entries matching the faulting address. Octeon raises "Machine Check exception - caused by multiple matching entries in the TLB" on the next refill of that page; a process on a CN63XX board died this way within a second of start, on the first anonymous THP of its bss. Skip the write when the probe misses. The refill and TLBL/TLBS handlers probe the faulting address themselves and rewrite the stale entry with the huge one (they also set the software young bit), so the entry is installed on the next access at the cost of one exception. Fixes: fd062c847a8c ("MIPS: TLB support for hugetlbfs.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit bc0aa354dc779c755150045e2b118565fe1d0767 Author: Runyu Xiao Date: Wed Sep 2 23:22:56 2026 +0800 peci: npcm: Initialize state before requesting IRQ [ Upstream commit 425125e6d408b5969afb99c3e95a391f1f1ad81d ] The PECI interrupt handler uses the lock and completion object as soon as the interrupt is delivered. Initialize both before registering the handler so an early interrupt cannot access uninitialized state. Fixes: 3e16184a1bd8 ("peci: Add peci-npcm controller driver") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Reviewed-by: Iwona Winiarska Link: https://lore.kernel.org/r/20260902152256.3591658-1-runyu.xiao@seu.edu.cn Signed-off-by: Iwona Winiarska Signed-off-by: Sasha Levin commit d1a16db5c5fc37c8d645629497f6e2870a268cc0 Author: Runyu Xiao Date: Wed Sep 2 22:26:00 2026 +0800 peci: aspeed: Initialize state before requesting IRQ [ Upstream commit 61cf765b654b76a62510269521a65e4e4a488f4c ] The PECI interrupt handler uses the lock and completion object as soon as the interrupt is delivered. Initialize both before registering the handler so an early interrupt cannot access uninitialized state. Fixes: a85e4c52086c ("peci: Add peci-aspeed controller driver") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Reviewed-by: Iwona Winiarska Link: https://lore.kernel.org/r/20260902142600.3580382-1-runyu.xiao@seu.edu.cn Signed-off-by: Iwona Winiarska Signed-off-by: Sasha Levin commit 3dd69eadc618b902b2c3f81aaefdeaf9b38b18d3 Author: Ma Ke Date: Mon Sep 14 17:50:09 2026 +0800 ASoC: wcd9335: Fix device reference leak in wcd9335_slim_status() [ Upstream commit f0cc352be29ba616e0682f66f551d3f3029886fd ] wcd9335_slim_status() obtains the SLIM interface device with of_slim_get_device(), which uses device_find_child() internally and returns the device with a reference held. As the device_find_child() documentation says: you will need to drop the reference with put_device() after use. The reference is stored in wcd->slim_ifc_dev and never dropped, so the SLIM interface device cannot be released. Fix it by using devm_add_action_or_reset() or put_device() respectively. Found by code review. Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec") Cc: stable@vger.kernel.org Signed-off-by: Ma Ke Link: https://patch.msgid.link/20260914095009.12049-1-make_ruc2021@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8aeec50673467d278a3e5c6f1552d0304da9df6f Author: David Cemin Date: Sat Sep 12 11:21:31 2026 -0700 ASoC: sdw_utils: clear stale RT711 device reference on exit [ Upstream commit 7c7df141dcabaa5370b5e52a9d64e2c1ea13a338 ] asoc_sdw_rt711_exit() drops the reference held in ctx->headset_codec_dev but leaves the pointer populated. If the card cleanup path reaches the exit hook more than once after a failed or deferred probe, a later invocation reuses the stale pointer and calls put_device() again, underflowing the refcount and leading to oopses when later probe, driver bind, or suspend paths walk the SoundWire bus after the device reference was released. Observed as boot- and suspend-time oopses on an arm64 platform with an RT712 headset codec, reproducible deterministically by repeated machine-driver probe cycling with the codec drivers unloaded. Clear the pointer after put_device() so repeated cleanup becomes a no-op, which also makes the existing NULL check at the top of the exit hook effective. This matches what commit 046173b98de3 ("ASoC: sdw_utils: fix double put_device() on aggregated amps") did for the aggregated amp references. Fixes: 811648340707 ("ASoC: Intel: sof_sdw: avoid oops in error handling") Cc: stable@vger.kernel.org Signed-off-by: David Cemin Link: https://patch.msgid.link/20260912182131.1156475-1-dcemin@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a7c82e4ded7a8db5812275d33338c4b60837ae39 Author: Breno Leitao Date: Fri Sep 18 04:01:57 2026 -0700 dcache: report a Tasks-RCU quiescent state in dentry_kill() [ Upstream commit a647a53bc89a046bee4a12a0a5627f2dfaaef807 ] I am constantly seeing the following warning on Meta's fleet: INFO: rcu_tasks detected stalls on tasks: native_queued_spin_lock_slowpath locked_inode_to_wb_and_lock_list inode_io_list_del evict __dentry_kill shrink_dentry_list shrink_dcache_tree d_invalidate btrfs_delete_subvolume btrfs_ioctl_snap_destroy btrfs_ioctl do_syscall_64 dentry_kill() is the common funnel for dentry teardown: dput(), shrink_dentry_list() and shrink_dcache_tree() all reach it, once per dentry, and its cond_resched() is the only reschedule point on that path. cond_resched() is not an RCU-tasks quiescent state. Use cond_resched_tasks_rcu_qs() so the teardown reports an RCU-tasks quiescent state as it proceeds. Fixes: 9c5f1d30199d ("dcache: move cond_resched() into the end of __dentry_kill()") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260918-dcache-task-rcu-qa-v1-1-963ec83e6d0b@debian.org Reviewed-by: Paul E. McKenney Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 099fa406c463d1c1cd20434a472861db50c02306 Author: Ricardo Neri Date: Thu Sep 24 19:33:20 2026 -0700 hwmon: (coretemp) Refresh the temperature on the first read [ Upstream commit e463cd582ca125e359ad1a66cb076434c14638b2 ] show_temp() reads the status MSR only when the cached temperature is older than one second. Commit 5c0e64dde80f ("hwmon: (coretemp) Remove obsolete temp_data->valid") dropped the tdata->valid check that used to force the very first read, leaving that comparison as the only trigger. A never-updated temp_data carries a zero timestamp, which does not look stale on 32-bit kernels: jiffies starts 300 seconds short of wrapping, so the comparison stays false until jiffies wraps and passes HZ. For the first 301 seconds of uptime temp%d_input reports the zero left by the allocator rather than the CPU temperature. 64-bit kernels are unaffected: jiffies starts at a positive value there and does not wrap. Backdate the timestamp when the temperature data is allocated. One jiffy older than the caching interval is stale under either word size, and the first refresh overwrites it. Fixes: 5c0e64dde80f ("hwmon: (coretemp) Remove obsolete temp_data->valid") Cc: stable@vger.kernel.org Signed-off-by: Ricardo Neri Link: https://patch.msgid.link/20260924-coretemp-temp-fault-v1-1-1884f0ff97d5@linux.intel.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit eaa3b815c7aac5059d9380df06afb49816ea8744 Author: Richard Weinberger Date: Thu Sep 17 16:53:29 2026 +0200 mtd: Call get_wunit() on the master partition [ Upstream commit 904f18430e8cce829cb9130eab7a93020e33fc89 ] The code checks whether master has get_wunit() but still calls it on the child. Fix this. Fixes: 46b5889cc2c5 ("mtd: implement proper partition handling") Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 7d3b537aa342b2db925be4875cf1f348c6efe703 Author: Wentao Liang Date: Thu Sep 17 10:25:50 2026 +0000 mtd: mtdsuper: Fix MTD device reference leak in mtd_get_sb() [ Upstream commit 62ee3da38f41bef83c1cf250f6816a0ee187674b ] mtd_get_sb() is called with a reference to the MTD device already taken by the caller. When sget_dev() fails, the function returns the error without dropping that reference, so the device is never released and its refcount never reaches zero. Every mount attempt on an MTD device whose superblock cannot be set up leaks a reference. Restore the put_mtd_device() that the fs_context conversion dropped on this path. Fixes: 0f071004109d ("mtd: Provide fs_context-aware mount_mtd() replacement") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit de587b7dd1269be9b83d418ffd3007203044dc2d Author: Wentao Liang Date: Thu Sep 17 10:24:07 2026 +0000 mtd: maps: l440gx: Fix double put of the PM device in init_l440gx() [ Upstream commit e6ca524ee5b2705be30ea19ce2e55122d9f9ed8f ] The PIIX4 PM device reference taken with pci_get_device() is dropped again before the iobase resource is allocated. If pci_assign_resource() fails, the error path calls pci_dev_put() on pm_dev a second time, releasing a reference that is no longer owned and underflowing the reference count. Remove the extra pci_dev_put(). Fixes: dd8e9ed6ed54 ("[MTD] Switch to pci_get_device and do ref counting") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit a9f3748e2c7e2aea10ef72d6421192795e3b02a9 Author: Wentao Liang Date: Thu Sep 17 10:22:44 2026 +0000 mtd: maps: l440gx: Fix double put of the ISA bridge in init_l440gx() [ Upstream commit 521ad948e04934b2d70ae899bc016bbb38802e90 ] init_l440gx() takes a single reference on the PIIX4 ISA bridge with pci_get_device() and drops it again right after the lookups, before the flash window is set up. The pci_assign_resource() failure path then calls pci_dev_put() on the same device a second time, releasing a reference that is no longer owned and underflowing the reference count. Remove the extra pci_dev_put(). Fixes: dd8e9ed6ed54 ("[MTD] Switch to pci_get_device and do ref counting") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 084eb0d1e89eb83059a3464551175a7aa7ea7489 Author: Wentao Liang Date: Thu Sep 17 10:20:51 2026 +0000 mtd: amd76xrom: Fix PCI device reference leak in amd76xrom_init_one() [ Upstream commit 1a122f5fecbabd47b81b1be3f0934f57b78aad42 ] init_amd76xrom() obtains the PCI device with pci_get_device() and hands the reference over to amd76xrom_init_one(), which stores it in window->pdev. When reserving the ROM window fails, that function returns -EBUSY directly instead of going through amd76xrom_cleanup(), so the reference is neither released nor cleared. Drop the reference and clear window->pdev on that path. Fixes: dd8e9ed6ed54 ("[MTD] Switch to pci_get_device and do ref counting") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 178e4cdeefa8335d381132e641f5b3f975b9bd3e Author: Orgad Shaneh Date: Wed Sep 16 16:27:31 2026 +0000 mtd: cfi_cmdset_0002: cap the write-buffer chunk at 256 bytes on an x8 device [ Upstream commit cfc5ebc9540e29f8f96db88bbfa261139e5afedb ] The Write to Buffer command takes the number of words to program minus one, and do_write_buffer() sends that count as a single bus word: map_write(map, CMD(words - 1), cmd_adr); CMD() replicates the value into every device lane, so each device reads the count off its own data lines - eight of them on an x8 part. A count that does not fit in eight bits is truncated there, which limits one Write to Buffer to 256 words on an x8 device, however large a buffer the chip advertises in its CFI query. The M29EW on a Cavium Octeon CN6335 board (an x16 part strapped to x8) advertises MaxBufWriteSize = 512 bytes, so cfi_amdstd_write_buffers() split the data into 512-byte chunks and do_write_buffer() sent a count of 511. The chip saw 511 & 0xff = 255, expected 256 bytes, and aborted the program when the 257th arrived. Chunks below 256 bytes - the leading partial chunk of a write - completed normally, so only the full-size ones failed: MTD do_write_buffer_wait(): software timeout, address:0x03278bff. jffs2: Write of 4164 bytes at 0x02c789b4 failed. returned -5, retlen 68 jffs2: No space for garbage collection. Aborting GC thread Clamp MaxBufWriteSize for x8 devices in the write-buffer fixup, and recompute mtd->writebufsize, which cfi_cmdset_0002_setup() derives from MaxBufWriteSize before the fixups run. The clamp deliberately keys off the device width rather than the part, even though the driver already recognises this one in is_m29ew(): the ceiling comes from the width of a device's data bus, not from the chip, so any x8 device advertising a larger buffer is told a count it cannot receive. The M29EW is only where it was found. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit da569798aa126c7fa2620692408cfa86f0e96576 Author: Myeonghun Pak Date: Mon Sep 14 21:06:47 2026 -0400 mtd: maps: pci: balance PCI enable on cleanup [ Upstream commit 3be16e5d4990bf96309ac5ba35cb369c6015bce7 ] mtd_pci_probe() leaves the PCI device enabled on later probe failure and mtd_pci_remove() does not disable it either. Use pcim_enable_device() to release the enable reference after the existing map and region cleanup. The imbalance is already present in the initial Git import. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 84b95f19edad0416c8686176c5ff48904b9c7ab1 Author: Wentao Liang Date: Thu Sep 17 10:29:24 2026 +0000 mtd: rawnand: atmel: Fix MCK clock leak in atmel_nand_controller_init() [ Upstream commit 94edcda45d888c3bb1310de11e10e4537c166f00 ] atmel_nand_controller_init() takes a reference to the MCK clock with of_clk_get() and keeps it in nc->mck for the lifetime of the controller. If the "atmel,smc" phandle is missing or the SMC regmap cannot be obtained afterwards, the error path jumps to out_release_dma which only releases the DMA channel, so the clock reference is leaked. The callers return the error directly and never run atmel_nand_controller_cleanup(), where the clock is normally put. Release the reference on those error paths. The path on which of_clk_get() itself fails keeps jumping to out_release_dma, as nc->mck only holds an error pointer there. Fixes: f9ce2eddf176 ("mtd: nand: atmel: Add ->setup_data_interface() hooks") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit f9969008222c0c48d4bd03c510f15a81475f10f9 Author: Michael J. Ruhl Date: Thu Sep 10 06:59:55 2026 -0700 platform/x86/intel/pmt: Block mmap when callback is present [ Upstream commit 0d4cd92b41dd33a3112959f9be86002ff309de73 ] With the introduction of the .read_telem() callback, control for access to a devices data area must be done by the callback owner. This means that an area cannot be mmap-ed with the default PMT handler. If the .read_telem() callback is present, do not support mmap. Fixes: 045a513040cc ("platform/x86/intel/pmt: Use PMT callbacks") Cc: stable@vger.kernel.org Signed-off-by: Michael J. Ruhl Link: https://patch.msgid.link/20260910135954.1586360-2-michael.j.ruhl@intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 270c883e2fb14c891d994f1873d15a1eb1a83c8e Author: Ridham Khurana Date: Wed Sep 23 17:25:48 2026 +0000 hwmon: (lm95245) Fix negative temperature conversion [ Upstream commit f58c16056f8585ebafb0f1f5d90c23085443a4b9 ] temp_from_reg_signed() uses only the high byte when the sign bit is set and drops the fractional bits in the low byte. Writing -500 to temp2_offset stores 0xff80 (-0.5 degrees C) in the offset registers, but reading temp2_offset back returns -1000. Negative temp1_input and temp2_input values are rounded down to the next whole degree the same way. The chip reports -0.125 degrees C as 0xffe0, which the driver returns as -1000. Treat the register pair as a single 16-bit two's complement value. Fixes: fffd80ccc1e6 ("hwmon: LM95245 driver") Cc: stable@vger.kernel.org Signed-off-by: Ridham Khurana Link: https://patch.msgid.link/20260923172551.1593798-1-khurana.ridham222@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit b61fbcfca4cc057a2e5464ffe25ad5d7ec0dcdb6 Author: Wentao Liang Date: Thu Sep 17 14:30:52 2026 +0000 regulator: core: Fix coupled regulators reference leak on removal [ Upstream commit b9205f0837ca91a0bbe6aa9002207656840c1406 ] of_parse_coupled_regulator() returns the coupled regulator with its device reference incremented and regulator_resolve_coupling() stores it in coupling_desc.coupled_rdevs[]. regulator_remove_coupling() clears those pointers without dropping the references, so they are leaked when the couple is torn down. Release the reference of each coupled regulator while removing the coupling. Fixes: d3d64537c339 ("regulator: core: Resolve coupled regulators") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917143052.2156903-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 45b45ad6a42d8e8252f132977edc23b0d66679bc Author: Aamir Ahmed Date: Sat Sep 5 21:48:07 2026 +0100 clk: mvebu: ap-cpu-clk: Assign .num before accessing .hws [ Upstream commit b4243850393f2f24e21b9f4b2c56233e60c904b4 ] Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS) about the number of elements in .hws[], so that it can warn when .hws[] is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in ap_cpu_clock_probe(), which reads .hws[] to skip clusters that have already been set up and writes it inside the CPU node loop, but only assigns .num after the loop. With CONFIG_UBSAN_BOUNDS and a compiler that implements __counted_by (GCC 15.1+ or Clang 20.1+), this triggers an array-index-out-of-bounds report during probe of the AP806 and AP807 CPU clocks, and with CONFIG_UBSAN_TRAP the first access traps. Initialize .num with nclusters, the number of elements .hws[] was allocated with, right after the allocation. For the in-tree AP806 and AP807 device trees, which list the CPU nodes in ascending order, this is exactly the value the old assignment produced. It is also the correct value for any other node order, since of_clk_hw_onecell_get() rejects indices at or beyond .num. Cc: stable@vger.kernel.org Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") Assisted-by: LLM Signed-off-by: Aamir Ahmed Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit f97556197b7280e19d336dbff6b9d47b7e9eb99b Author: Junjie Cao Date: Sun Sep 20 10:42:32 2026 +0800 ASoC: rt712-sdca-dmic: fix drvdata type in the gain controls [ Upstream commit 0bc42544a4a06e8d76eb412d2b1414db910a311d ] rt712_sdca_dmic_set_gain_get() and rt712_sdca_dmic_set_gain_put() take the component drvdata as struct rt712_sdca_priv, but this driver stores a struct rt712_sdca_dmic_priv. regmap and mbq_regmap are at the same offsets in both structs, so the register accesses work. slave is not: rt712_sdca_priv has dmic_component in front of it, so its slave overlays rt712_sdca_dmic_priv's params, which this driver never writes. When regmap_write() fails in the put handler, dev_err() is called with &NULL->dev (RSI below): rt712-sdca-dmic sdw:0:3:025d:1713:01: Defer on undeferrable control: 40800f13 BUG: kernel NULL pointer dereference, address: 0000000000000058 RIP: 0010:__dev_printk+0x10/0x70 RDX: ffffcdac45f83cd0 RSI: 0000000000000008 RDI: ffffffffa09cb5cb Call Trace: _dev_err+0x7f/0x99 rt712_sdca_dmic_set_gain_put.cold+0x20/0x25 [snd_soc_rt712_sdca_dmic] snd_ctl_elem_write+0x19a/0x1f0 [snd] snd_ctl_ioctl+0x658/0x8a0 [snd] Seen on a Dell Precision 5690 running 7.2.5-200.fc44, with alsactl writing the control during boot. Compile-tested only. Fixes: 63a511284c9e ("ASoC: rt712-sdca: Add RT712 SDCA driver for Mic topology") Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2532834 Cc: stable@vger.kernel.org Signed-off-by: Junjie Cao Link: https://patch.msgid.link/20260920024232.710189-1-junjie.cao@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4eaf7813cdf64754883958b02db088c269812f22 Author: Guangshuo Li Date: Thu Sep 24 21:49:32 2026 +0800 ASoC: Intel: atom: Fix platform device leak on probe failure [ Upstream commit dcc36d766dc82bc57cd730915d484119befcfca8 ] sst_acpi_probe() registers platform devices for the SST platform and machine board using platform_device_register_data(), but does not unregister them when later probe steps fail. Fixes: caf94ed8629a ("ASoC: Intel: bytcr_rt5640: fixup DAI codec_name with HID") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260924134932.1590967-1-lgs201920130244@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 073b9a25570261eb8e26ee72130bc34abc01e4a2 Author: Jiacheng Xu Date: Sun Sep 20 13:37:26 2026 +0800 kobject: fix out-of-bounds access in kobject_action_type() [ Upstream commit d516455c940555566642b975d1835c67f08136b3 ] kobject_action_type() compares the input against each known action using strncmp() and then indexes the action string using count_first to check for an exact-length match. An embedded NUL can make strncmp() return zero even when count_first exceeds the length of the action string. For example, the five-byte input "add\0X" makes the parser access kobject_actions[KOBJ_ADD][5], which is beyond the end of the "add" string. Check the action string length with strlen() instead of indexing it with the input-derived offset. This rejects malformed action strings containing embedded NUL bytes with -EINVAL instead of invoking undefined behavior. Cc: stable@kernel.org Fixes: 60a96a59569b ("Driver core: accept all valid action-strings in uevent-trigger") Signed-off-by: Jiacheng Xu Reviewed-by: Vishal Moola (Fractile) Link: https://patch.msgid.link/20260920053726.22626-1-stitch@zju.edu.cn Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit ac163d9cbbbcf9e87681e73fbe5adeffeb679a43 Author: Ryusuke Konishi Date: Thu Sep 24 01:41:19 2026 +0900 nilfs2: fix deadlock between nilfs_evict_inode() and find_inode() [ Upstream commit ff1227f70eead8704ecfec69259fb4c041f92cda ] Syzbot reported a deadlock between nilfs_evict_inode(), executed via an asynchronous workqueue (kworker) as: process_one_work() process_scheduled_works() nilfs_iput_work_func() nilfs_dispose_list() iput() iput_final() evict() s_op->evict_inode() nilfs_evict_inode() and find_inode(), called via nilfs_mkdir() nilfs_new_inode() nilfs_insert_inode_locked() insert_inode_locked4() inode_insert5() find_inode() When an inode is deleted (i_nlink == 0), nilfs_evict_inode() clears its ifile bitmap entry and then synchronously triggers the log writer via nilfs_transaction_commit() if IS_SYNC(inode) is true. If a concurrent directory creation via nilfs_new_inode() attempts to allocate the same newly freed inode number, however, find_inode() called just before inserting it into the inode hash, blocks waiting for the old inode's evict() to complete. Meanwhile, the synchronous log writer invoked from nilfs_evict_inode() tries to acquire a write lock on 'ns_segctor_sem' which is read locked by the caller of nilfs_new_inode() (in this case, nilfs_mkdir()), resulting in a deadlock. The synchronous log writer invocation from nilfs_evict_inode() is a legacy artifact; it is no longer necessary because the call itself (triggered by iput()) is now handled asynchronously with a kworker if i_nlink == 0. It merely increases the risk of deadlock. Fix this deadlock by removing the synchronous log writer trigger from nilfs_evict_inode(). Reported-by: syzbot+6646318bbcf419411bc5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6646318bbcf419411bc5 Fixes: 7ef3ff2fea8b ("nilfs2: fix deadlock of segment constructor over I_SYNC flag") Tested-by: syzbot+6646318bbcf419411bc5@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit a9552570797d003bb8534526c13a6c5187dcafdf Author: Tiezhu Yang Date: Thu Sep 24 10:17:56 2026 +0800 perf loongarch: Fix discarded const qualifier in _get_field() [ Upstream commit ed1293302f811fa709897d4a90ad78592938e4aa ] When building perf on LoongArch, the following compilation errors occur: CC arch/loongarch/util/header.o arch/loongarch/util/header.c: In function '_get_field': arch/loongarch/util/header.c:31:15: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 31 | line2 = strrchr(line, ' '); | ^ arch/loongarch/util/header.c:36:12: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 36 | nl = strrchr(line, '\n'); | ^ cc1: all warnings being treated as errors Declare 'line2' and 'nl' as const char * to ensure type safety. In modern glibc versions, strrchr() returns a 'const char *' if the input string is const. This is similar to commit 7378b6656aa4 ("perf riscv: Fix discarded const qualifier in _get_field()"). Fixes: 492ac37fa38faf52 ("perf kvm: Add kvm-stat for loongarch64") Signed-off-by: Tiezhu Yang Acked-by: Huacai Chen Acked-by: Namhyung Kim Cc: Bibo Mao Cc: Huacai Chen Cc: stable@vger.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ba9153966a853bc42ce0c7ce775aad7dcdd8211f Author: David Heidelberg Date: Thu Sep 3 17:21:42 2026 +0200 mfd: wcd934x: Fix NULL pointer dereference on IRQ probe deferral [ Upstream commit dcf0e640b553d33512fbcaedb909c32ba9636a64 ] ddata->dev is only assigned at the end of wcd934x_slim_probe(), but the of_irq_get() error path has passed it to the error print since the driver was added, while it is still NULL. This used to be harmless with dev_err(), which copes with a NULL device and was skipped on -EPROBE_DEFER. Since the switch to dev_err_probe(), a deferred IRQ reaches device_set_deferred_probe_reason() -> dev_driver_string(), which dereferences the NULL pointer and crashes during probe. Use dev, which is already valid at this point. Cc: stable@vger.kernel.org Fixes: 0f1b1b899521 ("mfd: wcd934x: Simplify with dev_err_probe()") Reported-by: Sashiko Link: https://lore.kernel.org/mfd/20260903145651.AC1311F00ACA@smtp.kernel.org/ Signed-off-by: David Heidelberg Link: https://patch.msgid.link/20260903-wcd-dma-v3-1-d3920c6563c4@ixit.cz Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 5a62155f734290ccf4bc9b89521cb03bd20ba9fa Author: David Heidelberg Date: Thu Sep 3 16:42:05 2026 +0200 mfd: wcd934x: set DMA mask on parent to silence "DMA mask not set" [ Upstream commit b296be1dc008fe3a536341afae01f66bb302e67f ] The wcd934x MFD parent (a slim_device) never initializes its dma_mask/coherent_dma_mask. When the DT-aware children pass through of_dma_configure() this triggers the "DMA mask not set" warning for each child. Cc: stable@vger.kernel.org Fixes: f959dcd6ddfd ("dma-direct: Fix potential NULL pointer dereference") Assisted-by: tencent:hy3 Signed-off-by: David Heidelberg Link: https://patch.msgid.link/20260903-wcd-dma-v2-1-189cff560a28@ixit.cz Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 0275de453cc4271fd1221ea992d673f923113300 Author: Hongyan Xu Date: Fri Aug 14 23:30:19 2026 +0800 mfd: da903x: Cancel IRQ work during teardown [ Upstream commit fd2258999ecdc7164ef0cda2d4102e4558a5660f ] The IRQ handler disables the IRQ and schedules irq_work. Releasing the IRQ does not drain that work, which can continue to use the devm-allocated chip and notifier state. Manage both IRQ-work cancellation and subdevice removal with devres. Register the subdevice-removal action before requesting the IRQ, then add the IRQ-work action after the request. This avoids leaving a live IRQ without work cancellation if action registration fails. Devres cleanup then disables the IRQ and drains the work before releasing the IRQ and removing child devices. Register both actions before creating the children so partial probe failures use the same ordering. This issue was found by the author's in-house static analysis tool. The patch was reviewed by the author against the latest mainline tree. Fixes: 26b8f5e1e2d1 ("mfd: add base support for Dialog DA9030/DA9034 PMICs") Cc: stable@vger.kernel.org Suggested-by: Lee Jones Assisted-by: Codex:GPT-5 Signed-off-by: Hongyan Xu Link: https://patch.msgid.link/20260814153019.1114-1-getshell@seu.edu.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 4d09016f6b98b284ad4776168a21dc91ad4b2dbc Author: Gabor Juhos Date: Fri Sep 18 11:27:49 2026 +0200 clk: qcom: gcc-ipq5018: mark 'gpll0_main' clock as critical [ Upstream commit 33f9cb56cc28d002511e471be74f8ff241984178 ] On IPQ5018, the APCS core clock feeds the CPUs. It can use different clocks as its parent, but during system boot it utilizes GPLL0. Under some cicumstances, the 'gpll0_main' clock is getting disabled during kernel start which results in a system hang then the hardware watchdog restarts the board after a while. This can happen when a driver gets a clock in its probe function, then releases it either directly or by devres cleanup on probe failure. For example, since v6.18 the kernel often fails to boot on the TP-Link Archer AX55 v1 board by using the in-tree dts. In the failing configuration, the 'ipq-cmn-pll' driver is built into the kernel and the problem is caused by the pm_runtim_put() call in the ipq_cmn_pll_clk_probe() function. Due to this call, runtime pm disables the 'gcc_cmn_blk_ahb_clk' clock asynchronously which results in disabling 'gpll0_main' as well. Mark the clock as critical in order to avoid such hangs. Cc: stable@vger.kernel.org Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018") Signed-off-by: Gabor Juhos Reviewed-by: Konrad Dybcio Reviewed-by: Mieczyslaw Nalewaj Tested-by: Stanislaw Pal Link: https://lore.kernel.org/r/20260918-ipq5018-mark-gpll0_main-critical-v1-1-fbe8f27a0106@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit dd2c42571919191e37812d047126858c0fac926a Author: Francesco Dolcini Date: Mon Sep 14 20:39:31 2026 +0200 arm64: dts: freescale: imx8mp-verdin-yavia: fix external GPIOs [ Upstream commit f377ac5999a5d045168ddd25d204691c6653c06a ] pinctrl_gpios_ext_yavia (SODIMM 64/66) is defined but never applied to gpio3, so those pins stay at their NAND reset function instead of GPIO. Fix SODIMM 64 to the correct pad, MX8MP_IOMUXC_NAND_READY_B (GPIO3_IO16). Fixes: b694fbe2ff40 ("arm64: dts: imx8mp-verdin: Add yavia carrier board") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 100efce4a6290b6515727c74cf76e6eda8187257 Author: Guangshuo Li Date: Tue Sep 15 19:25:10 2026 +0800 media: atmel-isi: release unregistered video device on remove [ Upstream commit c0a6d78dad3af1def80f04df82bfd70456ec406c ] atmel_isi_probe() allocates the video device before registering the V4L2 async notifier. The video device is registered later from the notifier complete callback once the remote subdevice has been bound. The remove path relies on the notifier unbind callback to unregister the video device. However, if the remote subdevice is never bound, or the complete callback fails before video_register_device() succeeds, the video device remains unregistered. In that case the unbind path does not release the object allocated by video_device_alloc(), and the remove path leaks it. Only unregister the video device from the unbind callback when it has actually been registered, and clear the driver pointer afterwards. After unregistering and cleaning up the notifier, release the video device directly if the pointer is still present. This covers devices that were allocated but never registered while avoiding a second release of successfully registered devices. This issue was found by manual code inspection. Fixes: d12c9088c0b2a ("[media] atmel-isi: remove dependency of the soc-camera framework") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Eugen Hristev Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit fdb7aa4df7a68b6e90aeeedaef597d00ed17680c Author: Wentao Liang Date: Thu Sep 17 10:13:47 2026 +0000 media: vpif_display: Fix i2c adapter reference leak in vpif_probe() [ Upstream commit f5863ea3f99265e5e297e3dcf0f47432fee2b8ac ] vpif_probe() takes a reference to the i2c adapter with i2c_get_adapter() and passes it to v4l2_i2c_new_subdev_board(), which does not consume it, but the reference is never released, so it is leaked both when the probe succeeds and when it fails after the adapter has been acquired. Release the reference with i2c_put_adapter() on the success path and in the probe_subdev_out cleanup. Fixes: e7332e3a552f ("V4L/DVB (12176): davinci/vpif_display: Add VPIF display driver") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5dafeb9d39a05941685c13d6fbeb1f0b3817eec7 Author: Wentao Liang Date: Thu Sep 17 10:12:22 2026 +0000 media: vpif_capture: Fix i2c adapter reference leak in vpif_probe() [ Upstream commit b00fbdad64d4ea7d594bc67988c1722fe5b3be50 ] vpif_probe() takes a reference to the i2c adapter with i2c_get_adapter() and passes it to v4l2_i2c_new_subdev_board(), which does not consume it, but the reference is never released, so it is leaked both when the probe succeeds and when it fails after the adapter has been acquired. Release the reference with i2c_put_adapter() on the success path and in the probe_subdev_out cleanup, and initialise i2c_adap so that the cleanup is a no-op when the adapter was never acquired. Fixes: 6ffefff5a9e7 ("V4L/DVB (12906c): V4L : vpif capture driver for DM6467") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 7029d63a3d25a52ef7e02d714e8921c2b114f324 Author: Wentao Liang Date: Thu Sep 17 09:54:43 2026 +0000 media: au0828: Fix media device leak in au0828_usb_probe() [ Upstream commit 7b7a69c91c0537d48150942d9707614a4fdd3766 ] au0828_media_device_init() takes a reference to a media device with media_device_usb_allocate(). When au0828_v4l2_device_register() fails right after, the error path only unregisters the entities and frees au0828_dev, so that reference is never released. Release it with media_device_delete() on that path. Fixes: 812658d88d26 ("media: change au0828 to use Media Device Allocator API") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b62b9ad7c7c6daf68664a79def8483b9abc46786 Author: Runyu Xiao Date: Tue Sep 15 16:26:38 2026 +0800 media: adv7180: Initialize mutex before ancillary clients [ Upstream commit 9d46d17a65e86010b1f5604e5cf61ce1e197f77a ] The VPP ancillary-client error path unregisters the CSI client before destroying state->mutex. For I2P variants, the failure can occur before mutex_init(), so cleanup destroys an uninitialized mutex. Initialize the mutex immediately after allocating the driver state, before creating any ancillary clients. This keeps every cleanup path matched with a completed mutex initialization. A QEMU x86_64 test using an i2c-stub bus instantiated an ADV7280 client at address 0x21 and occupied its VPP ancillary address 0x42. This forced i2c_new_ancillary_device() to return -EBUSY. An instrumentation oracle observed an uninitialized mutex on the buggy kernel and an initialized mutex on the fixed kernel. The failure was deliberately injected to exercise the error path; no natural crash was observed. Fixes: 851a54effbd8 ("[media] adv7180: Add I2P support") Cc: stable@vger.kernel.org Assisted-by: LLM Codex Signed-off-by: Runyu Xiao Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ef6bf8d0222bc6b2990d80ae9177206c57feb14a Author: Myeonghun Pak Date: Mon Sep 14 21:11:05 2026 -0400 media: tw68: balance PCI enable on cleanup [ Upstream commit fc02261fdca3ea95e4dcb6b38ab77f0f197c3750 ] tw68_initdev() leaves the PCI device enabled after a later probe failure or tw68_finidev(). Use pcim_enable_device() to balance the enable reference when the driver is detached or probe fails. The managed disable runs after the managed IRQ has been released. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: e15d1c12c587 ("[media] tw68: refactor and cleanup the tw68 driver") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9e01d9848326f348587bcc05deb637fe6cf48db2 Author: Myeonghun Pak Date: Sun Sep 13 22:28:08 2026 -0400 media: cx18: Disable PCI device on probe failure [ Upstream commit 2aefbc29765641e1e1a26b96cee194ac7d34ff49 ] cx18_setup_pci() enables the PCI device but does not disable it when DMA mask setup or the memory-region reservation fails. Later probe failure paths release the region without balancing the enable either. Unwind the enable inside cx18_setup_pci() when that helper fails after enabling the device. Once setup succeeds, disable it in the probe cleanup after releasing the memory region. Setup failures skip that cleanup, so each successful enable is balanced exactly once. Keep the existing error codes and normal removal path unchanged. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 1c1e45d17b66 ("V4L/DVB (7786): cx18: new driver for the Conexant CX23418 MPEG encoder chip") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Assisted-by: OpenAI:GPT-5.6 Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit cecd9e9cc10655762233ca2dce9f624c95bcba52 Author: Myeonghun Pak Date: Sun Sep 13 18:33:13 2026 -0400 media: go7007: unregister the I2C adapter on USB probe failure [ Upstream commit 14165cd16fa7c233aec6a407b56b304e7a283911 ] USB probe failures after I2C adapter registration free the backing go7007 structure without unregistering the adapter. If i2c_adapter_online is set, unregister the adapter before releasing USB resources so that I2C client removal can still use its callbacks. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 59aea928d57f ("[media] go7007: don't continue if firmware can't be loaded") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Assisted-by: OpenAI:GPT-5.6 Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 105c30dcee65b11f447ae7da7086b5d85876cbe6 Author: Myeonghun Pak Date: Fri Sep 11 13:55:37 2026 -0400 media: marvell: manage the MMP camera clock provider [ Upstream commit 9887716132d6c3c58cc67841dfb441c5a4a0d209 ] mmpcam_probe() registers an OF clock provider before requesting the IRQ. Neither a later probe failure nor driver removal unregisters that provider, although the underlying clock is registered with devm_clk_register(). This leaves the provider referring to a clock whose lifetime has ended. Use devm_of_clk_add_hw_provider() with the existing mclk_hw so the provider is unregistered before the managed clock and camera storage are released. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 81a409bfd551 ("media: marvell-ccic: provide a clock for the sensor") Cc: stable@vger.kernel.org Assisted-by: OpenAI:GPT-5.6 Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 802e61f3ba7ab0dd212866286ddbe062de157e65 Author: Rohinthan P Date: Sat Sep 19 07:41:09 2026 +0530 media: v4l2-ctrls: do nothing if controls[0] == NULL in cluster functions [ Upstream commit 9ff738f93084351ed6e818d4d58679a9e9083a8d ] The V4L2 control framework is designed to allow drivers to instantiate controls and clusters without checking for errors after each call, checking hdl->error only once at the end. However, if allocating the master control (controls[0]) fails, e.g. due to memory allocation failure, v4l2_ctrl_cluster() triggers a WARNING: ncontrols == 0 || controls[0] == NULL WARNING: drivers/media/v4l2-core/v4l2-ctrls-core.c:2525 at v4l2_ctrl_cluster Additionally, v4l2_ctrl_auto_cluster() attempts to dereference master->minimum without checking if controls[0] is NULL, leading to a NULL pointer dereference when master control creation fails. Update both v4l2_ctrl_cluster() and v4l2_ctrl_auto_cluster() to silently return if controls[0] is NULL, preserving the design that control creation errors are caught at the end when the driver checks hdl->error. Also update function documentation in include/media/v4l2-ctrls.h. Fixes: 71c689dc2e73 ("media: v4l2-ctrls: split up into four source files") Cc: stable@vger.kernel.org Reported-by: syzbot+cf896de36144391bcde1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cf896de36144391bcde1 Suggested-by: Hans Verkuil Signed-off-by: Rohinthan P Signed-off-by: Hans Verkuil [hverkuil: simplified the v4l2_ctrl_auto_cluster code a bit] Signed-off-by: Sasha Levin commit baa95c79cd395955ef5e8f6abc86c9cedea7c42c Author: Pengpeng Hou Date: Sun Sep 20 11:40:10 2026 +0800 media: cec: extron: clear response tail before dispatch [ Upstream commit a601427f03e015e3d4d2ba44cfa6e0de144983b9 ] The serial receive buffer is reused between responses. Terminating a short response with one NUL leaves bytes from the previous response behind it, while the dispatcher also checks fixed offsets beyond some prefixes. Those checks can consume stale tail bytes. Clear up to ten bytes at the end of each completed response, limited by the remaining array capacity. This includes the terminator and covers the dispatcher's fixed-offset tests without adding a separate length condition to every prefix branch. The issue was found by our static-analysis tool. Fixes: 056f2821b631 ("media: cec: extron-da-hd-4k-plus: add the Extron DA HD 4K Plus CEC driver") Cc: stable@vger.kernel.org Assisted-by: gpt 5 Signed-off-by: Pengpeng Hou Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit fd72fec7761165164ada464c6785d4ee9feee001 Author: Karl Mehltretter Date: Sat Sep 19 07:49:34 2026 +0200 crypto: qat - zero the VF migration state buffer on save [ Upstream commit 5d504e65516dde8c88117378292e9c78f3d2cf58 ] The QAT VF migration state buffer is allocated with kmalloc(), while qat_vf_save_state() exposes all state_size bytes to userspace. The state manager writes only the serialized sections, leaving the unused tail unchanged. The first save can therefore disclose stale heap contents, and subsequent saves can disclose data left by an earlier migration. Zero the whole buffer before writing the setup data. Once the setup data is present, preserve it and zero the remaining state area before each state save. Fixes: f0bbfc391aa7 ("crypto: qat - implement interface for live migration") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8fbb3ec7958c86c4b8ba7ec23e91fdeff2611946 Author: Weili Qian Date: Fri Sep 18 20:27:24 2026 +0800 crypto: hisilicon/hpre - fix GFP flags for dma_alloc_coherent [ Upstream commit 40ec9605cb195e065470f8f23ef94b1b541411a3 ] The HPRE driver hard-codes GFP_ATOMIC for RSA/DH and GFP_KERNEL for ECDH. This may cause "scheduling while atomic" in atomic context or unnecessary allocation failures under memory pressure. Select GFP flags dynamically based on CRYPTO_TFM_REQ_MAY_SLEEP and store them in hpre_asym_request::flags. The areq field is a union of rsa/dh/ecdh request pointers; reading base.flags through any union member other than the one that was written would be type-punning, so a dedicated flags field avoids that. Fixes: 98dfa9343f37 ("crypto: hisilicon/hpre - don't use GFP_KERNEL to alloc mem during softirq") Cc: stable@vger.kernel.org Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c677fa1624a81672f582477b9455faa3be4da91b Author: Weili Qian Date: Fri Sep 18 20:27:23 2026 +0800 crypto: hisilicon/hpre - fix ECDH destination DMA mapping [ Upstream commit 12d8edda8cdb41d18c4891851e25bf58be6be995 ] hpre_ecdh_dst_data_init() rejects valid requests whose output length does not equal ctx->key_sz << 1, and maps the user buffer using the user-provided len instead of the hardware transfer size. Drop the redundant length check and use ctx->key_sz << 1 for dma_map_single() so the whole hardware output is mapped. Fixes: 05e7b906aa7c ("crypto: hisilicon/hpre - add 'ECDH' algorithm") Cc: stable@vger.kernel.org Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit dffac12de0c2ea42def331437b7c4e3f5053682b Author: Weili Qian Date: Fri Sep 18 20:27:22 2026 +0800 crypto: hisilicon/hpre - return -EOVERFLOW for small ECDH output buffer [ Upstream commit 232804a5ed70a8ace32c46d341d438aeba54bc67 ] hpre_ecdh_msg_request_set() returns -EINVAL when the output buffer is too small, after setting req->dst_len to the required size. -EINVAL is misleading because the caller can retry with a larger buffer. Return -EOVERFLOW as other kpp implementations do. Fixes: 05e7b906aa7c ("crypto: hisilicon/hpre - add 'ECDH' algorithm") Cc: stable@vger.kernel.org Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2ec1f31430466b01ba771ec05b732bd71a011467 Author: Weili Qian Date: Fri Sep 18 20:27:20 2026 +0800 crypto: hisilicon/hpre - fix pointer dereference before length check [ Upstream commit 9770bb7d335f8f8db01e99168bbdd9ce2cb6238c ] In hpre_rsa_drop_leading_zeros(), the loop condition dereferences *ptr before checking *len, causing an out-of-bounds read when *len is zero. Swap to while (*len && !**ptr) to test length first. Fixes: c8b4b477079d ("crypto: hisilicon - add HiSilicon HPRE accelerator") Cc: stable@vger.kernel.org Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 42e2b518240cf72afd1f7b0ab9f3ed8e730e138c Author: Mohamad Raizudeen Date: Fri Sep 18 17:29:50 2026 +0530 crypto: amlogic - Fix IRQ handler return value and fallthrough logic [ Upstream commit 4b8ae2732070c5669adee2d5d3bb97b14af53a63 ] In meson_irq_handler(), when an interrupt matches a flow but the status register is empty, the driver prints an error but doesn't return. It falls through the loop and incorrectly prints an `unknown irq` message. Fix this by returning immediately. For empty status registers, return IRQ_NONE instead of IRQ_HANDLED to avoid masking spurious interrupts and allow the kernel to detect interrupt storms. Also use dev_err_ratelimited() to prevent console lockups during an interrupt storm. Additionally, the handler returned IRQ_HANDLED for genuinely unknown interrupts. Return IRQ_NONE instead for unhandled interrupts. Cc: stable@vger.kernel.org Fixes: 48fe583fe5417 ("crypto: amlogic - Add crypto accelerator for amlogic GXL") Signed-off-by: Mohamad Raizudeen Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6161721e0cc7cc45be5d4b2edfbec7d3f211bfeb Author: Yuchao Zhang Date: Tue Sep 22 12:46:06 2026 +0800 md: validate bblog_size when loading v1.x badblocks metadata [ Upstream commit ae5f89b23cb88667cfa1273b42d6a551db9c651e ] In super_1_load(), when the on-disk feature_map does not have MD_FEATURE_BAD_BLOCKS set but sb->bblog_offset is non-zero, rdev->badblocks.shift is initialized to 0 without validating sb->bblog_size. The same field is validated in the MD_FEATURE_BAD_BLOCKS branch ("sectors > (PAGE_SIZE / 512)"), but this branch bypasses that check. A forged on-disk superblock (malicious storage device or crafted image) can therefore carry an oversized sb->bblog_size. When bad blocks are later recorded, super_1_sync() sets bb->size from sb->bblog_size and md_write_metadata() issues a bio larger than the single rdev->bb_page, reading beyond the page and leaking kernel memory contents to disk. sb->bblog_size is never modified by the kernel between load and sync, and the MD_FEATURE_BAD_BLOCKS branch already validates it, so checking it in this branch is sufficient to cover both paths. Fix this by rejecting an oversized sb->bblog_size with -EINVAL, matching the existing check in the MD_FEATURE_BAD_BLOCKS branch. Fixes: 2699b67223ac ("md: load/store badblock list from v1.x metadata") Cc: stable@vger.kernel.org Signed-off-by: Yuchao Zhang Link: https://patch.msgid.link/20260922044606.30774-1-ndaugoing@gmail.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 3d8ce7c54eaf41b8a3576a331897202f4ba219fb Author: Wentao Liang Date: Wed Sep 16 09:12:51 2026 +0000 EDAC/i10nm: Fix mdev reference leak in i10nm_get_ddr_munits() [ Upstream commit f0d8c34b3b5e845113581d7d3b24ddaa61bce1f0 ] In i10nm_get_ddr_munits(), get_ddr_munit() returns a PCI device with its reference count incremented. If ioremap() fails to map the MMIO space of the memory controller, the function returns -ENODEV without putting the reference held by mdev, leaking it. Put the device reference before returning on the ioremap failure path. [Tony: Dropped the Cc: stable tag] Fixes: c545f5e41225 ("EDAC/i10nm: Skip the absent memory controllers") Signed-off-by: Wentao Liang Signed-off-by: Tony Luck Reviewed-by: Qiuxu Zhuo Link: https://patch.msgid.link/20260916091251.1997522-1-vulab@iscas.ac.cn Signed-off-by: Sasha Levin commit b211997e8e76404cd1eeb224afb0e13867642b84 Author: Aldo Ariel Panzardo Date: Mon Sep 21 12:19:39 2026 -0300 nilfs2: fix checkpoint root lifetime on sysfs errors [ Upstream commit 2cb947450e0e5a88bb6bb5fca6dbfda1910e74b0 ] nilfs_find_or_create_root() links a new checkpoint root into the checkpoint tree and drops ns_cptree_lock before creating the root's sysfs group. If nilfs_sysfs_create_snapshot_group() then fails, the root is freed while it is still reachable from ns_cptree, so a concurrent nilfs_lookup_root() can dereference freed memory. nilfs_sysfs_create_snapshot_group() allocates memory and creates sysfs nodes and may sleep, so it cannot run under the ns_cptree_lock spinlock. Reorder the creation path so that the sysfs group is set up before the root is published: initialize the root, create its sysfs group outside the lock, and only then take ns_cptree_lock to link it into the tree. On sysfs failure the root was never visible and is freed directly; in the unlikely case a root with the same checkpoint number is already present, the sysfs group of the new root is removed before it is freed. Concurrent insertions are already serialized by ns_snapshot_mount_mutex, so only the race against nilfs_lookup_root() needs to be closed. Because kobject_put() does not guarantee that the embedded kobject's release callback has run by the time it returns (CONFIG_DEBUG_KOBJECT_RELEASE defers it), the container must not be freed until the release completes. Keep that wait_for_completion() of snapshot_kobj_unregister inside the sysfs helpers, so both the creation error path and nilfs_sysfs_delete_snapshot_group() wait for the release before their callers free the root. Fixes: dd70edbde262 ("nilfs2: integrate sysfs support into driver") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Acked-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit d2934a28b85de88e5e04571361a38472135263f7 Author: Wentao Guan Date: Fri Sep 18 17:09:10 2026 +0800 cpufreq/amd-pstate: Skip auto_sel write when it already matches the mode [ Upstream commit b400642c5e93863ec17ea15fcbd3efc81c299531 ] Since commit 9dfd13f80c85 ("cpufreq/amd-pstate: Toggle auto_sel in active mode on shared memory systems"), shmem_init_perf() programs AUTONOMOUS_SELECTION_ENABLE unconditionally, including in active mode. Platforms that exclusively support autonomous selection report this field as an Integer of 1, as required by the ACPI specification, instead of as a register descriptor. cppc_get_reg_val() reads such a field back successfully, but cppc_set_reg_val() rejects the write with -EOPNOTSUPP because the entry is not an ACPI_TYPE_BUFFER. shmem_init_perf() propagates that error, so every amd_pstate_epp_cpu_init() fails, cpufreq_register_driver() ends up with an empty policy list and returns -ENODEV, and amd-pstate refuses to load at all: amd_pstate: failed to set auto_sel, ret: -95 amd_pstate: Failed to initialize CPU 0: -95 ... amd_pstate: failed to register with return -19 Skip the write when the register already holds the value the requested mode needs. Active and guided mode are fixed on these platforms, which report auto_sel as 1, while passive mode still fails to load on a platform that cannot disable autonomous selection, exactly as it did before the offending commit. Fixes: 9dfd13f80c85 ("cpufreq/amd-pstate: Toggle auto_sel in active mode on shared memory systems") Cc: stable@vger.kernel.org Reviewed-by: K Prateek Nayak Tested-by: K Prateek Nayak Tested-by: LFRon Signed-off-by: Wentao Guan Link: https://lore.kernel.org/r/20260918090909.86544-1-guanwentao@uniontech.com Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit e55bddffd63dd84bf9da807e9bcbd21624c77da4 Author: Wentao Liang Date: Wed Sep 16 10:21:12 2026 +0000 drm/mali-dp: Fix runtime PM leak in malidp_crtc_atomic_enable() [ Upstream commit 73ef663c75688168e31dbe9c585b939be410a945 ] malidp_crtc_atomic_enable() resumes the device with pm_runtime_get_sync() and returns early when the resume fails. The runtime PM usage count is incremented by pm_runtime_get_sync() even when the resume fails, so returning without dropping the reference leaks it and, once the error has been hit, prevents the device from ever suspending again. Drop the runtime PM reference with pm_runtime_put_noidle() on the resume failure path before returning. Fixes: 85f6421889ec ("drm: mali-dp: Enable power management for the device.") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Acked-by: Liviu Dudau Link: https://patch.msgid.link/20260916102112.2018372-1-vulab@iscas.ac.cn Signed-off-by: Liviu Dudau Signed-off-by: Sasha Levin commit cac8d63d6d82ea2659c3a093cdbf4547d089ef7e Author: Judith Mendez Date: Wed Sep 9 16:47:43 2026 -0500 arm64: dts: ti: k3-am62x-phyboard-lyra: Set SD clock pin as OUTPUT [ Upstream commit 1d62ef8d47b535d31fb9cf38e5c36eb55b0189a4 ] MMC clock pins must be configured as OUTPUT-only per TRM [0] with receiver disabled (RXACTIVE bit = 0). Change MMC CLK pins from PIN_INPUT to PIN_OUTPUT to match documentation. [0] https://www.ti.com/lit/pdf/spruiv7 Rev. C: Table 12-246. MMCSDi I/O Signals Fixes: f1b3adade045 ("arm64: dts: ti: Add am62x-phyboard-lyra carrier board") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Acked-by: Wadim Egorov Link: https://patch.msgid.link/20260909214743.899477-16-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 6985036229e7ac06fe523727dae7c4226d83dc1c Author: Judith Mendez Date: Wed Sep 9 16:47:39 2026 -0500 arm64: dts: ti: k3-am62-phycore-som: Set eMMC clock pin as OUTPUT [ Upstream commit a3c2b6c52e02d58941c0b91bfba052788aeff890 ] MMC clock pins must be configured as OUTPUT-only per TRM [0] with receiver disabled (RXACTIVE bit = 0). Change MMC CLK pins from PIN_INPUT to PIN_OUTPUT to match documentation. [0] https://www.ti.com/lit/pdf/spruiv7 Rev. C: Table 12-246. MMCSDi I/O Signals Fixes: 3443c1c4ed61 ("arm64: dts: ti: Add basic support for phyBOARD-Lyra-AM625") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Acked-by: Wadim Egorov Link: https://patch.msgid.link/20260909214743.899477-12-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 179d2fd672c22154576c64de05f09a188d18ad50 Author: Judith Mendez Date: Wed Sep 9 16:47:37 2026 -0500 arm64: dts: ti: k3-am62x-sk-common: Set SD clock pin as OUTPUT [ Upstream commit 1e2e5016bda94b2bcd86258b5eb77fe3006639a0 ] MMC clock pins must be configured as OUTPUT-only per TRM [0] with receiver disabled (RXACTIVE bit = 0). Change MMC CLK pins from PIN_INPUT to PIN_OUTPUT to match documentation. [0] https://www.ti.com/lit/pdf/spruiv7 Rev. C: Table 12-246. MMCSDi I/O Signals Fixes: d19a66ae488a ("arm64: dts: ti: k3-am625-sk: Enable on board peripherals") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260909214743.899477-10-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 2bc609548d81ccbe94f456d7691319510836e27f Author: Judith Mendez Date: Wed Sep 9 16:47:36 2026 -0500 arm64: dts: ti: k3-am625-beagleplay: Set MMC clock pins as OUTPUT [ Upstream commit c074abebc76f0e59d13dea499f582806c6a3d94d ] MMC clock pins must be configured as OUTPUT-only per TRM [0] with receiver disabled (RXACTIVE bit = 0). Change MMC CLK pins from PIN_INPUT to PIN_OUTPUT to match documentation. [0] https://www.ti.com/lit/pdf/spruiv7 Rev. C: Table 12-246. MMCSDi I/O Signals Fixes: f5a731f0787f ("arm64: dts: ti: Add k3-am625-beagleplay") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260909214743.899477-9-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 9de1f0dcdeb399dfd21cf2a4c001403e0bb1e0ac Author: Judith Mendez Date: Wed Sep 9 16:47:34 2026 -0500 arm64: dts: ti: k3-am62-lp-sk: Set eMMC clock pins as OUTPUT [ Upstream commit 156f4c2208c8e5e04002402494de28c21c0afcbc ] MMC clock pins must be configured as OUTPUT-only per TRM [0] with receiver disabled (RXACTIVE bit = 0). Change MMC CLK pins from PIN_INPUT to PIN_OUTPUT to match documentation. [0] https://www.ti.com/lit/pdf/spruiv7 Rev. C: Table 12-246. MMCSDi I/O Signals Fixes: e6a51ffabfc1 ("arm64: ti: dts: Add support for AM62x LP SK") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260909214743.899477-7-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 31b025a297c16e6dd4a291a02463d3c20f55ec4c Author: Judith Mendez Date: Wed Sep 9 16:47:33 2026 -0500 arm64: dts: ti: k3-am62a-phycore-som: Set eMMC clock pin as OUTPUT [ Upstream commit 4834050197f205a649e36661ca150e6ac8295008 ] MMC clock pins must be configured as OUTPUT-only per TRM [0] with receiver disabled (RXACTIVE bit = 0). Change MMC CLK pins from PIN_INPUT to PIN_OUTPUT to match documentation. [0] https://www.ti.com/lit/pdf/spruj16 Rev. C: Table 12-257. MMCSDi I/O Signals Fixes: d69383885576 ("arm64: dts: ti: Add basic support for phyBOARD-Lyra-AM62Ax") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Acked-by: Wadim Egorov Link: https://patch.msgid.link/20260909214743.899477-6-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 93ae7c18f1bffec3dbd9a772475b76de6ca83987 Author: Judith Mendez Date: Wed Sep 9 16:47:32 2026 -0500 arm64: dts: ti: k3-am62a7-sk: Set SD clock pin as OUTPUT [ Upstream commit cfad4f39124b218c2cbbbe17e742971abc9ac8b4 ] MMC clock pins must be configured as OUTPUT-only per TRM [0] with receiver disabled (RXACTIVE bit = 0). Change MMC CLK pins from PIN_INPUT to PIN_OUTPUT to match documentation. [0] https://www.ti.com/lit/pdf/spruj16 Rev. C: Table 12-257. MMCSDi I/O Signals Fixes: 38c4a08c820c ("arm64: dts: ti: Add support for AM62A7-SK") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260909214743.899477-5-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 46f8b65d87d913d92a96a67e08d216e44936e921 Author: Judith Mendez Date: Wed Sep 9 16:47:31 2026 -0500 arm64: dts: ti: k3-am62a7-sk: Set eMMC clock pin as OUTPUT [ Upstream commit aa7d5b1efa75e58c9d440dfd720205045fe6a806 ] MMC clock pins must be configured as OUTPUT-only per TRM [0] with receiver disabled (RXACTIVE bit = 0). Change MMC CLK pins from PIN_INPUT to PIN_OUTPUT to match documentation. [0] https://www.ti.com/lit/pdf/spruj16 Rev. C: Table 12-257. MMCSDi I/O Signals Fixes: e041ec6e86e7 ("arm64: dts: ti: k3-am62a7-sk: Enable eMMC support") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260909214743.899477-4-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 51e70d656c3699c51218eb84cbdc3d321c1d413c Author: Judith Mendez Date: Wed Sep 9 16:47:29 2026 -0500 arm64: dts: ti: k3-am62a: Fix MMC0_CLK register address [ Upstream commit 9852f2badc438de82b6828c11c80ef0a656f1d4d ] MMC0_CLKLB and MMC0_CLK have incorrectly swapped register addresses as per datasheet [0]. Set the correct MMC0_CLK address and drop the unneeded MMC0_CLKLB pin configuration. [0] https://www.ti.com/lit/gpn/am62a7 Rev. E: Table 5-1. Pin Attributes Fixes: e041ec6e86e7 ("arm64: dts: ti: k3-am62a7-sk: Enable eMMC support") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Acked-by: Udit Kumar Link: https://patch.msgid.link/20260909214743.899477-2-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 526f00e7c4a253cf1c46841c02628d94b35ee50f Author: Wentao Liang Date: Wed Sep 16 07:31:36 2026 +0000 ASoC: ti: davinci-mcasp: Fix runtime PM imbalance in __davinci_mcasp_set_clkdiv() [ Upstream commit ba593d662183de74d2b733b4c6e8cd26f04f0a65 ] In __davinci_mcasp_set_clkdiv(), pm_runtime_get_sync() is called at the entry of the function. If an invalid div_id is provided, the function hits the default switch case and directly returns -EINVAL without calling pm_runtime_put(), resulting in a runtime PM reference leak. Add pm_runtime_put() in the default case before returning -EINVAL. Fixes: 4ed8c9b737b6 ("ASoC: McASP: add support for clock dividers") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Tested-by: Sen Wang Link: https://patch.msgid.link/20260916073136.1971673-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1df745e85bb37bcea7e36ca0be1de599fc0490a5 Author: Sean Young Date: Wed Sep 9 11:04:40 2026 +0100 media: meson-ir-tx: Prevent divide by zero in meson_irtx_prepare_pulse() [ Upstream commit 05d9c515cf13056875abbf73adb4a19dd7ba32eb ] If an excesively high carrier is set, meson_irtx_prepare_pulse() will cause a divide by zero if tb_us is 0. Prevent such a carrier from being set. Fixes: 49be1c78d575 ("media: rc: introduce Meson IR TX driver") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5cc1572ef96cb186608b9df8f9cad43095387549 Author: Sean Young Date: Fri Sep 4 10:09:16 2026 +0100 media: ir_toy: Validate the maximum tx carrier [ Upstream commit 27303392aa87b61692faadec8b00e0ca66bf98dd ] Reject any carrier the hardware cannot generate. This also fixes a divide by zero if a carrier of U32_MAX/16 is set. Fixes: 8bff1386d62d ("media: ir_toy: allow tx carrier to be set") Cc: stable@vger.kernel.org Signed-off-by: Sean Young Acked-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3b5ca1a674e9b0145201e4b2b8b47ea174c47d27 Author: Myeonghun Pak Date: Thu Sep 10 15:45:25 2026 -0400 leds: ktd2692: Pass context to regulator cleanup [ Upstream commit c73e9f04445f361d5f19ca2edfde742ce18348ef ] regulator_disable_action() retrieves the driver context from device driver data. However, ktd2692_parse_dt() registers the action before ktd2692_probe() stores the context with platform_set_drvdata(). If devm_add_action_or_reset() cannot allocate the action, it invokes the callback immediately. A later probe failure also invokes it during managed-resource unwinding. Both paths dereference a NULL context. Pass the already allocated context directly to the action and retain the device pointer in it for error reporting. The context is allocated before the action is registered, so reverse-order devres unwinding keeps it alive through the callback. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: ee78b9360e14 ("leds: ktd2692: Fix an error handling path") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260910194525.99654-1-mhun512@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit ca324e5719248adba7e5bec5bfcfb480be46f191 Author: Cong Nguyen Date: Mon Jul 27 17:49:27 2026 +0700 staging: media: imx: csc-scaler: fix ipu_image_convert_run leak on queue error [ Upstream commit 07643be7b1eff94f7a49e142c1e92a1029d3db21 ] device_run() allocates an ipu_image_convert_run object and, on the success path, hands it to the IPU image conversion core via ipu_image_convert_queue(); the run object is then freed asynchronously by the completion callback ipu_ic_pp_complete(). However, if ipu_image_convert_queue() fails, the core never takes ownership of the run object and the completion callback is never invoked. The "err" label finishes the mem2mem job and reports the buffers as errored, but never frees the run object that was just allocated, leaking it on every queue failure. Free the run object in the error path. There is no risk of a double free: the completion callback only runs after the object was successfully queued, which is mutually exclusive with reaching the error path. It is also safe for the earlier "goto err" on allocation failure, since run is NULL there and kfree(NULL) is a no-op. Fixes: a8ef0488cc59 ("media: imx: add csc/scaler mem2mem device") Cc: stable@kernel.org Signed-off-by: Cong Nguyen Signed-off-by: Frank Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2849bbaafd4f485aee87109d4225eb222eee5418 Author: Hui Peng Date: Tue Sep 22 02:32:04 2026 +0000 seccomp: restore knotif->state when SECCOMP_ADDFD_FLAG_SEND is interrupted [ Upstream commit 832b9b176be06a20747a267db6bc0010a24b74f4 ] In seccomp_notify_addfd(), when SECCOMP_ADDFD_FLAG_SEND is set in addfd.flags, knotif->state is optimistically transitioned from SECCOMP_NOTIFY_SENT to SECCOMP_NOTIFY_REPLIED before waking the tracee and waiting on kaddfd.completion: if (addfd.flags & SECCOMP_ADDFD_FLAG_SEND) { knotif->state = SECCOMP_NOTIFY_REPLIED; ... } If wait_for_completion_interruptible(&kaddfd.completion) is interrupted by a signal before the tracee dequeues the kaddfd request (!list_empty(&kaddfd.list)), seccomp_notify_addfd() removes kaddfd from knotif->addfd and returns -EINTR to the supervisor without having installed the file descriptor. However, knotif->state is left as SECCOMP_NOTIFY_REPLIED (with knotif->error == 0 and knotif->val == 0). This causes two problems: 1. When the tracee runs in do_user_notif(), it checks if (knotif.state != SECCOMP_NOTIFY_REPLIED) after calling seccomp_handle_addfd(). Because knotif->state is already SECCOMP_NOTIFY_REPLIED, the tracee exits the notification wait loop prematurely and returns 0 from the trapped syscall without the file descriptor ever having been installed. 2. If the supervisor retries SECCOMP_IOCTL_NOTIF_ADDFD or SECCOMP_IOCTL_NOTIF_SEND before the tracee runs, it fails with -EINPROGRESS because knotif->state is no longer SECCOMP_NOTIFY_SENT. Fix this by restoring knotif->state back to SECCOMP_NOTIFY_SENT if SECCOMP_ADDFD_FLAG_SEND was set and kaddfd was not consumed before the interrupted wait. Also add a seccomp_bpf selftest (user_notification_addfd_send_interrupted) covering this race. Tested in QEMU against Linux 7.3.0-rc3 using the user_notification_addfd_send_interrupted selftest added in this patch (./seccomp_bpf -t user_notification_addfd_send_interrupted): on the unfixed kernel the test fails because the retry ioctl(listener, SECCOMP_IOCTL_NOTIF_ADDFD, &addfd) returns -EINPROGRESS (-1) and the tracee prematurely exits do_user_notif() with return value 0 instead of FD 42, whereas with this patch applied the test passes. Fixes: 0ae71c7720e3 ("seccomp: Support atomic "addfd + send reply"") Cc: stable@vger.kernel.org Reviewed-by: Bradley Morgan Assisted-by: LLM Signed-off-by: Hui Peng Link: https://patch.msgid.link/20260922023204.2504832-1-benquike@gmail.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit ffd5a804f79ef6f7e57f04ad226f356dbebd6986 Author: Oleg Nesterov Date: Mon Apr 6 15:37:32 2026 +0200 signalfd: don't dequeue the forced fatal signals [ Upstream commit d72e0fb3b00c6a1146bcfd7186ad9f6f609ba236 ] These signals should act like SIGKILL, in that userspace must never dequeue them. But as Kusaram explains, io_uring-driven signalfd_read_iter() called from get_signal() -> task_work_run() paths can do this before get_signal() has a chance to dequeue such a signal and notice SA_IMMUTABLE. Change signalfd_poll() and signalfd_dequeue() to add pending SA_IMMUTABLE signals to ctx->sigmask. TODO: we should probably change force_sig_info_to_task(HANDLER_EXIT) to make fatal_signal_pending() true, or add a fatal_or_forced_signal_pending() helper. Then signalfd_dequeue() could just return -EINTR in this case. This also makes sense for get_signal(), which could prioritize a fatal signal sent by (say) force_sig_seccomp(force_coredump => true), just like it already prioritizes SIGKILL. Cc: stable@kernel.org Reported-by: syzbot+0a4c46806941297fecb9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0a4c46806941297fecb9 Tested-by: syzbot+0a4c46806941297fecb9@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/69d122fd.050a0220.2dbe29.001c.GAE@google.com/ Suggested-by: Kusaram Devineni Signed-off-by: Oleg Nesterov Reviewed-by: Kees Cook Link: https://patch.msgid.link/adO3HG8bvwRPcmte@redhat.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 4674aa905d20d7e54c5208f6e526898ca623517c Author: Runyu Xiao Date: Mon Sep 21 22:26:08 2026 +0800 PCI: pciehp: Make 'pciehp_poll_mode' parameter read-only [ Upstream commit 5ab17178fca6026d329cb6ced33c30f3b7d3e50a ] pciehp_request_irq() and pciehp_free_irq() select different resources based on the global pciehp_poll_mode parameter. The parameter is currently writable through sysfs, so changing it while a controller is active can make teardown try to stop a nonexistent polling thread or call free_irq() for an IRQ that was not requested. Keep the parameter available for boot and module configuration, but prevent runtime changes to the registration mode. Reproducer: Boot an x86_64 guest in QEMU with a native PCIe hotplug root port and an e1000 device, using these device options: -device pcie-root-port,id=rp1,chassis=1,slot=1 -device e1000,bus=rp1 Pass "pcie_ports=native pciehp.pciehp_poll_mode=1" to the guest kernel. As root in the guest, replace the device name below with a bound pciehp service device and run: # dev=0000:00:1c.0:pcie004 # driver=/sys/bus/pci_express/drivers/pciehp # echo 0 > /sys/module/pciehp/parameters/poll_mode # echo "$dev" > "$driver/unbind" # dmesg | grep 'Trying to free already-free IRQ' The unfixed kernel accepts the runtime mode change and reports the warning when the service device is removed. The fixed kernel rejects the write and removes the device without the warning. The mode change is a deliberate privileged test action and is not expected during ordinary operation. Assisted-by: LLM Codex Signed-off-by: Runyu Xiao Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Link: https://patch.msgid.link/20260921142608.270312-1-runyu.xiao@seu.edu.cn Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 7e1052d3ab39fb144d46673cc69e5a377c3892d8 Author: Hui Peng Date: Mon Sep 21 03:25:55 2026 +0000 ata: libata-scsi: abort multi-sector pass-through commands when multi_count is 0 [ Upstream commit 3bab8c7e0c6ba187a47163a1f71477213a278c48 ] When an ATA_12, ATA_16, or ATA_32 pass-through command with a multi-sector PIO command opcode (ATA_CMD_READ_MULTI, ATA_CMD_WRITE_MULTI, ATA_CMD_READ_MULTI_EXT, ATA_CMD_WRITE_MULTI_EXT, or ATA_CMD_WRITE_MULTI_FUA_EXT) is submitted via SG_IO on a device where multiple-sector mode is not configured (dev->multi_count == 0), ata_scsi_pass_thru() currently logs a warning and still dispatches the taskfile. When the DRQ interrupt fires, ata_pio_sectors() triggers WARN_ON_ONCE(qc->dev->multi_count == 0) and computes nsect = min((qc->nbytes - qc->curbytes) / qc->sect_size, 0) = 0, failing to transfer any sectors: ata1.00: invalid multi_count 1 ignored WARNING: drivers/ata/libata-sff.c:666 at ata_pio_sectors+0x27d/0x300 Call Trace: ata_sff_hsm_move+0x211/0x22e0 __ata_sff_port_intr+0x1c8/0x520 ata_bmdma_port_intr+0xa1/0x5b0 ata_bmdma_interrupt+0x1f5/0x550 Per ACS-3 section 7.12.7.21, if IDENTIFY DEVICE word 59 bit 8 is cleared to zero (multi_count == 0) and a READ MULTIPLE or WRITE MULTIPLE command is received without a preceding successful SET MULTIPLE MODE command, the device returns command aborted (ABRT). Per the SAT specification, an ABRT error translates to the ABORTED COMMAND sense key with NO ADDITIONAL SENSE INFORMATION (0x00, 0x00). Fail multi-sector taskfile commands in ata_scsi_pass_thru() with ata_scsi_set_sense(dev, scmd, ABORTED_COMMAND, 0, 0) when dev->multi_count == 0. Fixes: 1dce589c38c3 ("libata passthru: support PIO multi commands") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Hui Peng Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20260921032556.1160734-1-benquike@gmail.com Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 7d4932831f09285473fc6ed66c4f911dff3e713a Author: Tsz Shan Chan Date: Fri Sep 4 11:19:48 2026 +1000 iio: light: apds9306: fix default sampling frequency definition [ Upstream commit a1c005f6336aa41f23552e66ea1b98b9ee493a86 ] APDS9306_SAMP_FREQ_10HZ is defined as 0. According to the datasheet (Broadcom AV02-4755EN, page 11, ALS_MEAS_RATE), bits[2:0] set the measurement rate: - 000: 25ms (40Hz) - 001: 20ms (20Hz) - 010: 100ms (10Hz) Change APDS9306_SAMP_FREQ_10HZ from 0 to 2 to write the correct value for 10Hz. Datasheet: https://docs.broadcom.com/doc/AV02-4755EN Fixes: 620d1e6c7a3f ("iio: light: Add support for APDS9306 Light Sensor") Reviewed-by: Andy Shevchenko Signed-off-by: Tsz Shan Chan Acked-by: Subhajit Ghosh Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit f8b829c8763a5ed0cd8b9b5c84b7c89d8de22466 Author: Jean-Baptiste Maneyrol Date: Mon Sep 14 14:43:42 2026 +0200 iio: imu: inv_icm42600: force accel odr change when switching power mode [ Upstream commit d52047d84963e5cf7c8ad502e0adf003fb0669de ] When accel must switch from low-power mode to low-noise due to a change in ODR, there is an hardware bug that sometimes prevent the ODR change flag to be set in the FIFO header. If this happens, the driver is stuck waiting for the ODR change flag that is never happening. Fix this by using accel_force_odr flag set when switching mode for forcing apply of ODR change. Do the apply after parsing FIFO data to let the flag do the job if it is here. Fixes: ec74ae9fd37c ("iio: imu: inv_icm42600: add accurate timestamping") Cc: stable@vger.kernel.org Signed-off-by: Jean-Baptiste Maneyrol Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 6247347e67b73a65d957075f1ee88275afe9c30b Author: Shehryar Ahmad Date: Wed Sep 16 10:55:31 2026 +0500 iio: accel: adis16201: fix channel order for buffer mode [ Upstream commit a4b9f1137b76faab6891ce0bd3f5c02dda7c392d ] Reshuffle adis16201_channels to ascending scan_index order to avoid data corruption during IIO core demultiplexing since the ADIS driver builds the buffer in channel array order, while the IIO core demultiplexes it in scan_index order. This changes the raw buffer byte layout for existing adis16201 users reading buffered data directly. Fixes: 591298e54cea ("Staging: iio: accel: adis16201: Move adis16201 driver out of staging") Cc: stable@vger.kernel.org Signed-off-by: Shehryar Ahmad Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit a5b471da7c1d61e136877a37b907dc6019d687cd Author: Wentao Liang Date: Wed Sep 16 07:25:41 2026 +0000 regulator: rt6190: Fix runtime PM imbalance in rt6190_out_enable() [ Upstream commit e0d673e5a5c4084f0da90c06ed3b0bc45e47d679 ] In rt6190_out_enable(), pm_runtime_get_sync() is called at the start of the function. However, if any subsequent regmap or regulator operation fails, the function returns directly without dropping the runtime PM reference, causing a runtime PM reference leak. Add an error handling path with pm_runtime_put() to keep the reference count balanced on failure. Fixes: e6999e7cca7e ("regulator: rt6190: Add support for Richtek RT6190 regulator") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: ChiYuan Huang Link: https://patch.msgid.link/20260916072541.1968033-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0750f30ddb16349d1fc33cf6cf79ffdcea2f3c78 Author: Karl Mehltretter Date: Sat Sep 12 12:09:37 2026 +0200 fpga: Fix of_fpga_mgr_get() reference in fpga_mgr_lock() docs [ Upstream commit ac02245b0ca28388ba16273f2fa683c90da2e5dc ] The fpga_mgr_lock() comment lists of_fpga_mgr_put() as a source of a manager pointer. The helper which obtains that pointer is of_fpga_mgr_get(). Correct the reference. Fixes: ebf877a51ad7 ("fpga: mgr: separate getting/locking FPGA manager") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Xu Yilun Link: https://lore.kernel.org/r/20260912100937.86316-1-kmehltretter@gmail.com Signed-off-by: Xu Yilun Signed-off-by: Sasha Levin commit 43ae36791a1085f899d46b9e0f931c1ef204cc0d Author: Wentao Liang Date: Thu Sep 17 16:51:30 2026 +0000 ASoC: codecs: wm8994: Fix runtime PM leak in wm8994_mic_detect() [ Upstream commit b2c0e5bf750e33b0e1dcdfbb2df8103a06c7caab ] wm8994_mic_detect() resumes the component before configuring the MICBIAS pins, but the default case of the micbias switch returns -EINVAL right after taking that reference, skipping the pm_runtime_put() on the success path. This leaks a runtime PM reference on every call with an invalid micbias. Release the reference before returning -EINVAL. Fixes: f5a2cda4f1db ("ASoC: wm8994: Ensure the device is resumed in wm89xx_mic_detect functions") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260917165130.2163278-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ed090987c9a2ddd65c8bdfd2c690196ae4292a89 Author: Wentao Liang Date: Thu Sep 17 14:28:10 2026 +0000 regulator: core: Fix rdev reference leak in regulator_resolve_supply() [ Upstream commit 195bbe5e1c29aa1349655a6162958149c1176034 ] regulator_resolve_supply() takes a reference on the looked-up regulator with regulator_dev_lookup(), but when the supply resolves to the regulator itself that reference is never dropped: it leaks on the early return and is lost as well when r is replaced with the dummy regulator. Release the reference before handling the self-referent case. Fixes: 4b639e254d3d ("regulator: avoid resolve_supply() infinite recursion") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917142810.2156816-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6906557ad9c3bbab023e1484351f39d5f897ad18 Author: Wentao Liang Date: Thu Sep 17 14:25:35 2026 +0000 regulator: core: Fix c_rdev reference leak in regulator_resolve_coupling() [ Upstream commit c41b69e9f76fd9632662714c1d37860468e8d773 ] of_parse_coupled_regulator() returns the coupled regulator with its device reference incremented, but regulator_resolve_coupling() returns without dropping it when the coupled regulator belongs to a different coupler, leaking the reference. Fixes: d8ca7d184b33 ("regulator: core: Introduce API for regulators coupling customization") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917142535.2156720-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5ad3c880b2ec0ba26572c8b4d753dcfb7a9849c3 Author: Shengming Hu Date: Wed Sep 16 14:09:26 2026 +0800 cpufreq: conservative: Restrict deferred downscaling to low load [ Upstream commit 0fa55c5539173bceaeb400c69b1974aaa0cdb8dc ] For a shared cpufreq policy, dbs_update() derives the load used for the frequency decision from the maximum load among its CPUs, but it may also record deferred idle periods accumulated by an idle CPU in the policy. Consequently, a single update can contain both a high decision load from one CPU and multiple deferred idle periods from another CPU. The conservative governor applies the deferred down steps before evaluating the decision load. If that load subsequently triggers an up step, the deferred down steps can outweigh the single up step and produce a net frequency reduction. This was observed on a policy shared by CPUs 2 and 3. A CPU-bound SCHED_EXT task kept CPU 2 fully utilized while CPU 3 remained idle. On this system, SCHED_EXT generated update-util callbacks less frequently than CFS, resulting in sparse DBS updates such as: load=100 idle_periods=7 interval=59 ms load=100 idle_periods=4 interval=39 ms load=100 idle_periods=2 interval=19 ms load=100 idle_periods=7 interval=59 ms With the default 5% frequency step and a 2.6 GHz policy maximum, seven deferred periods reduce the requested frequency by seven 130 MHz steps before the high decision load adds only one step. Repeated updates therefore keep the policy near 530 MHz even though CPU 2 is fully utilized. There are two load values relevant to this behavior: * sample_load is calculated from the busy and elapsed time of the current sample. * decision_load is returned by dbs_update() for the governor's frequency decision. After a long idle interval, it may reuse prev_load to improve the response to a waking task and can therefore differ from sample_load. The problem is that idle_periods is derived from accumulated idle time and is applied independently of whether the current sample load is in the conservative governor's downscaling region. A high sample load and multiple deferred idle periods can therefore coexist, particularly when updates are sparse. As suggested by Zhongqiu Han, calculate the sample load separately from the decision load. If no time has elapsed, use prev_load for the sample load as the existing load calculation does, since no load can be calculated for that interval. Record the maximum sample load for the policy and apply deferred down steps only when it is below down_threshold. This makes deferred downscaling follow the same threshold that the conservative governor normally uses to determine whether the policy load is low enough to reduce the frequency. The existing code applies deferred down steps whenever idle_periods is valid, regardless of the sample load. When the decision load is in the hold region, the locally adjusted frequency is not submitted unless another frequency-update branch is taken. Thus, when the sample and decision loads are the same and both are in the hold region, this change does not alter the requested frequency. The difference becomes visible when the decision load causes a frequency update. In particular, if it exceeds up_threshold, the governor applies a single up step after the deferred down steps and submits the resulting request. Multiple deferred down steps can then outweigh that up step and cause a frequency reduction even when the sample load is above down_threshold. With this change, deferred down steps are skipped whenever the maximum sample load is at or above down_threshold, keeping deferred downscaling consistent with the conservative governor's threshold semantics. The requested frequency may therefore be higher than with the existing behavior when deferred idle periods are present and the decision load causes a frequency update. This is intentional, because the lower request previously resulted from applying deferred downscaling while the sampled policy load was outside the governor's downscaling region. Accelerated deferred downscaling remains available when the policy sample load is below down_threshold, including after a workload has completed and the policy has become idle. Fixes: 00bfe05889e9 ("cpufreq: conservative: Decrease frequency faster for deferred updates") Cc: All applicable Reviewed-by: Luo Haiyang Reviewed-by: Run Zhang Suggested-by: Zhongqiu Han Signed-off-by: Shengming Hu Link: https://patch.msgid.link/20260916140926740-DCokXh6dAgtqDn1EWdCh@zte.com.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5c9a7eea926fdaed105da882e3bf3c5d11ea26f8 Author: Martin Wilck Date: Mon Sep 7 17:51:03 2026 +0200 md/raid5: validate payload size before calculating payload_len [ Upstream commit 38c795105992bbaa3418dd39cbff7348ad17537c ] Commit b0cc3ae97e89 ("md/raid5: validate payload size before accessing journal metadata") introduced a bounds check to verify that a given payload fits into the current metadata block. In order to calculate the payload size, it has to access the members payload->header.type and payload->size, the offset of which may already be past the end of the metadata block, because the loop condition only checks that the first byte of the payload is inside, and the payload entries have variable sizes. Later on, payload->checksum[0] and payload->checksum[1] are accessed without verifying that payload->size is large enough. Add another check to make sure that payload->size can be safely accessed, and make sure that the checksum fields are accessible. This issue has been found by AI (gemma4, Gemini) during a backport review. Cc: Junrui Luo Cc: stable@vger.kernel.org Fixes: b0cc3ae97e89 ("md/raid5: validate payload size before accessing journal metadata") Signed-off-by: Martin Wilck Link: https://patch.msgid.link/20260907155103.2325511-1-mwilck@suse.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 9410f368f1b70a564950d714ba3b9b145eaa93dd Author: Cao Guanghui Date: Thu Aug 27 16:03:41 2026 +0800 md/raid5: fix NULL pointer dereference in raid5_free_percpu [ Upstream commit 41742e35268d6a45161b187f51f42bc2ade14d0d ] If cpuhp_state_add_instance() fails in raid5_alloc_percpu() (e.g., the startup callback raid456_cpu_up_prepare fails due to an allocation failure), conf->node is never added to the cpuhp instance list and its pprev remains NULL (from kzalloc initialization). When setup_conf() then jumps to abort, free_conf() calls raid5_free_percpu(), which checks conf->percpu (non-NULL, since it was allocated before the cpuhp failure) and proceeds to call cpuhp_state_remove_instance(). This calls hlist_del() on the unhashed node, which dereferences node->pprev (NULL), causing a kernel panic. Guard the removal with hlist_unhashed_lockless() so that the cpuhp instance is only removed if it was actually added. The lockless variant uses READ_ONCE() for the pprev read, which is safe here because the actual removal is synchronized by cpuhp_state_mutex inside cpuhp_state_remove_instance(). Fixes: 29c6d1bbd7a2 ("md/raid5: Convert to hotplug state machine") Cc: stable@vger.kernel.org Signed-off-by: Cao Guanghui Link: https://patch.msgid.link/20260827080341.112296-2-ghuicao@163.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit fa1f5f15514c52936e12c77c6f719af6ec51a152 Author: Cao Guanghui Date: Thu Aug 27 16:03:40 2026 +0800 md/raid5: track disks array size to fix extra_page leak on error paths [ Upstream commit 5028ceee173bfcf844469cfb0d1c151d3f6d0296 ] free_conf() iterates conf->pool_size entries to free extra_page allocations, but pool_size may not reflect the actual size of the conf->disks array. Two scenarios cause a mismatch: 1. setup_conf() early abort: pool_size is 0 (not yet set by grow_stripes) but conf->disks has max_disks entries with extra_page allocated. The loop iterates 0 times, leaking all pages. 2. resize_stripes() Step 4 failure: conf->disks was replaced with a newsize-entry array in Step 3, but pool_size is only updated on success. The loop iterates pool_size (old, smaller value) times, leaking (newsize - pool_size) pages. Add a dedicated disks_cnt field to track the actual number of entries in conf->disks. Set it immediately after each allocation or replacement (in setup_conf and resize_stripes Step 3, where the array is safely stalled with no concurrent access), and use it in free_conf() instead of pool_size. This leaves pool_size untouched, preserving the check_reshape() retry behavior that depends on pool_size only being updated on full success. Fixes: d7bd398e97f2 ("md/r5cache: handle alloc_page failure") Cc: stable@vger.kernel.org Signed-off-by: Cao Guanghui Link: https://patch.msgid.link/20260827080341.112296-1-ghuicao@163.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit faa69d106473443b94d5c9d74ff5119009fb378a Author: Guangshuo Li Date: Mon Sep 14 19:34:22 2026 +0800 iio: adc: at91-sama5d2: disable autosuspend on remove [ Upstream commit 022996906e70c6bc9a7968ee663ebbe314fe1524 ] at91_adc_probe() enables runtime PM autosuspend with pm_runtime_use_autosuspend(). The probe error path correctly undoes this setting with pm_runtime_dont_use_autosuspend(), but the normal remove path only disables runtime PM. The runtime PM API requires pm_runtime_use_autosuspend() to be undone with pm_runtime_dont_use_autosuspend() at driver exit unless runtime PM was enabled with devm_pm_runtime_enable(). Leaving the autosuspend flag set therefore leaves the runtime PM state incompletely cleaned up after the driver is unbound. Add the missing pm_runtime_dont_use_autosuspend() call to the remove path. This issue was found by manual code inspection. Fixes: 75d7556ac0e4 ("iio: adc: at91-sama5d2_adc: add runtime pm support") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Joshua Crofts Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 1f4304a52166e49a3470cd9488f7a67bab3c6648 Author: Guangshuo Li Date: Mon Sep 14 19:30:12 2026 +0800 iio: accel: mma9553: disable autosuspend on remove [ Upstream commit 4dda1f9d25fb889649e81bbf015809daa512a049 ] mma9553_probe() enables runtime PM autosuspend with pm_runtime_use_autosuspend(). The probe error path correctly undoes this setting with pm_runtime_dont_use_autosuspend(), but the normal remove path only disables runtime PM. The runtime PM API requires pm_runtime_use_autosuspend() to be undone with pm_runtime_dont_use_autosuspend() at driver exit unless runtime PM was enabled with devm_pm_runtime_enable(). Leaving the autosuspend flag set therefore leaves the runtime PM state incompletely cleaned up after the driver is unbound. Add the missing pm_runtime_dont_use_autosuspend() call to the remove path. This issue was found by manual code inspection. Fixes: 40cb761306d6 ("iio: add driver for Freescale MMA9553") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Joshua Crofts Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9a8709cacfb9da0ae4203231656170780fdd75ac Author: Guangshuo Li Date: Mon Sep 14 19:24:47 2026 +0800 iio: accel: mma9551: disable autosuspend on remove [ Upstream commit 8061720f6be1811478914f8b6143778d70f6033f ] mma9551_probe() enables runtime PM autosuspend with pm_runtime_use_autosuspend(). The probe error path correctly undoes this setting with pm_runtime_dont_use_autosuspend(), but the normal remove path only disables runtime PM. The runtime PM API requires pm_runtime_use_autosuspend() to be undone with pm_runtime_dont_use_autosuspend() at driver exit unless runtime PM was enabled with devm_pm_runtime_enable(). Leaving the autosuspend flag set therefore leaves the runtime PM state incompletely cleaned up after the driver is unbound. Add the missing pm_runtime_dont_use_autosuspend() call to the remove path. This issue was found by manual code inspection. Fixes: 6da93a6710a3 ("iio: accel: mma9551: Add runtime pm support") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Joshua Crofts Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit c8bc770db48741a1ddaf0dde69f84ae85526fea7 Author: Guangshuo Li Date: Mon Sep 14 19:20:53 2026 +0800 iio: accel: kxcjk-1013: Disable autosuspend on remove [ Upstream commit 1de1206a42741adfb72ca8b37dc71a6bc80cb074 ] kxcjk1013_probe() enables runtime PM autosuspend with pm_runtime_use_autosuspend(). The probe error path correctly undoes this setting with pm_runtime_dont_use_autosuspend(), but the normal remove path only disables runtime PM. The runtime PM API requires pm_runtime_use_autosuspend() to be undone with pm_runtime_dont_use_autosuspend() at driver exit unless runtime PM was enabled with devm_pm_runtime_enable(). Leaving the autosuspend flag set therefore leaves the runtime PM state incompletely cleaned up after the driver is unbound. Add the missing pm_runtime_dont_use_autosuspend() call to the remove path. This issue was found by manual code inspection. Fixes: 124e1b1d0924 ("iio: accel: kxcjk-1013: support runtime pm") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Joshua Crofts Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 2808548842c017d3d827e623fd9a4a2efbdb9fdc Author: Wentao Liang Date: Wed Sep 16 07:29:00 2026 +0000 ASoC: arizona-jack: Fix runtime PM imbalance in arizona_start_hpdet_acc_id() [ Upstream commit e04dcb895b4622d67164e218a1179785e2c75999 ] In arizona_start_hpdet_acc_id(), pm_runtime_get_sync() is called to keep the device powered during headphone detection. If setting the HPDET mode or starting the measurement fails and the function jumps to err, pm_runtime_put_autosuspend() was not called while info->hpdet_active was set to false, resulting in a runtime PM usage count leak. Add pm_runtime_put_autosuspend() in the err error path to keep runtime PM balanced. Fixes: 9dd5e53d9d2f ("extcon: arizona: Retry HPDET identification for high impedance") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260916072900.1971595-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fca3a8892b54bec4e1e1c3dd642b32dc7c36e9cd Author: Wentao Liang Date: Wed Sep 16 07:27:37 2026 +0000 ASoC: wm8994: Fix runtime PM imbalance in wm8994_component_probe() [ Upstream commit 480a5528cb6268d626632d45d4a1f29b4c0c11df ] In wm8994_component_probe(), pm_runtime_get_sync() is invoked before reading the GPIO configuration registers. If either regmap_read() fails, the function jumps to err_irq without calling pm_runtime_put(), leaving the runtime PM usage count incremented and causing a leak. Add pm_runtime_put() on both GPIO read failure paths before jumping to err_irq. Fixes: f5a2cda4f1db ("ASoC: wm8994: Ensure the device is resumed in wm89xx_mic_detect functions") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260916072737.1970990-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7b5980b6206dfbb4369bd0f94f3ed3957445072c Author: Liu Chao Date: Sun Sep 13 20:04:58 2026 +0800 usb: fotg210: validate endpoint index in ep0 handlers [ Upstream commit bbddb219b00af0792242a0ad1dc7fb3344f38733 ] fotg210_set_feature(), fotg210_clear_feature() and fotg210_get_status() use wIndex from the USB setup packet to index the fotg210->ep[] array without verifying that the endpoint number falls below FOTG210_MAX_NUM_EP (5). USB_ENDPOINT_NUMBER_MASK is 0x0f, so a malicious host can issue a setup packet with wIndex 5..15, resulting in an out-of-bounds array read. The resulting wild pointer is then dereferenced in fotg210_set_epnstall() or fotg210_is_epnstall(), which compute an MMIO register offset from ep->epnum and perform iowrite32 through it. fotg210_clear_feature() is especially problematic: the out-of-bounds access occurs at function entry (source-level) regardless of which USB_RECIP_* case is taken, because the ep pointer is computed before the switch statement. Add upper-bound checks on the endpoint number derived from wIndex in all three functions. Invalid endpoint numbers in clear_feature now trigger fotg210_request_error() (STALL) instead of silently falling through to fotg210_set_cxdone(). Also add the missing le16_to_cpu() conversion for ctrl->wIndex in fotg210_get_status() to fix a sparse endianness warning. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Cc: stable@vger.kernel.org Signed-off-by: Liu Chao Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260913120458.1608186-1-liuc63@xiaopeng.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f888c7db1681c136bb761c43964a2271c7a89c12 Author: Karl Mehltretter Date: Wed Sep 2 21:23:23 2026 +0200 crypto: atmel-tdes - sync output bounce buffer before DMA [ Upstream commit a38fdcb9c944525ca71e6aaf35e708586d0ae87d ] The slow path maps its output bounce buffer once at probe time with dma_map_single() and DMA_FROM_DEVICE, then reuses the mapping for every request. After the CPU copies a result from the buffer, dma_sync_single_for_device() must hand the buffer back to the device before the next DMA transfer. The driver omits this call, so cache lines from the previous result can remain valid while the device writes the next one. This bug was masked by the completion paths calling dma_sync_single_for_device() immediately before the CPU copied the output, where dma_sync_single_for_cpu() was required. For DMA_FROM_DEVICE on ARM926, dma_sync_single_for_device() invokes arm926_dma_map_area(), which invalidates the cache lines. The misplaced call therefore discarded the stale lines before every copy-out. Commit c8a9a647532f ("crypto: atmel-tdes - fix DMA sync direction") correctly changed the completion paths to call dma_sync_single_for_cpu(). On ARM926, that function invokes arm926_dma_unmap_area(), which is a no-op. The missing pre-DMA dma_sync_single_for_device() was therefore exposed on ARM926-based SAM9X60 and SAM9X7 SoCs. With CONFIG_CRYPTO_SELFTESTS=y all four DES/TDES algorithms fail on SAM9X75: alg: skcipher: atmel-ecb-tdes encryption test failed (wrong result) on test vector 2, cfg="unaligned buffer, offset=1" Call dma_sync_single_for_device() for the output buffer before starting DMA in both atmel_tdes_crypt_pdc() and atmel_tdes_crypt_dma(). Fixes: c8a9a647532f ("crypto: atmel-tdes - fix DMA sync direction") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 65d266218efdb5224fa11182b4d15df503999175 Author: Yousef Alhouseen Date: Sun Jun 28 11:55:59 2026 +0200 ntfs3: bound index head insertions by buffer capacity [ Upstream commit 2f497d23652ff23da07b08cfb4b4a1c2a87f1892 ] hdr_insert_head() shifts the existing index entries by ins_bytes without checking that the resulting used size fits within hdr->total. A directory index root larger than the newly allocated index buffer can therefore make the memmove write beyond the buffer. Reject insertions whose size would exceed the index header capacity and make both split callers unwind the new node when that happens. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Reported-by: syzbot+45ef5a8d661162757547@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=45ef5a8d661162757547 Cc: stable@vger.kernel.org Signed-off-by: Yousef Alhouseen Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit bce7b522aeb3a0494230f68b0f66e2873e4b6aa6 Author: Muhammad Bilal Date: Tue Sep 15 22:46:15 2026 +0500 platform/x86: hp-bioscfg: fix slab-out-of-bounds write in hp_convert_hexstr_to_str() [ Upstream commit 6a6f3051e705b5c8facb0bf5984d5b981509e0b7 ] hp_convert_hexstr_to_str() decodes an ACPI string made up of space-separated ASCII hex-byte tokens of the form "0xHH". For example, the four-byte input "0x41" decodes to the single character 'A', and the nine-byte input "0x09 0x41" decodes to "\tA": each token is read in a five-byte step (four characters for the token, one for the trailing delimiter), and produces one output byte, or two if that byte is '\\', '\r', '\n', or '\t', which are written back out as a backslash followed by the matching letter. The output buffer is sized with kmalloc(input_len, GFP_KERNEL), the raw encoded length of the input, not the decoded length. For well-formed input this is generous, since five input bytes never decode to more than two output bytes. But input_len comes directly from the ACPI string length reported by firmware and isn't guaranteed to respect the five-byte encoding, so a short input_len can undersize the allocation. With input_len == 1, only one byte is allocated, yet decoding still produces at least one output byte plus the NUL terminator written unconditionally afterwards, so two bytes are needed. That terminator write then lands one byte past the end of the allocation. KASAN caught exactly this during BIOS attribute enumeration on boot, triggered by a one-byte encoded input value: BUG: KASAN: slab-out-of-bounds in hp_convert_hexstr_to_str+0x6d8/0x710 [hp_bioscfg] Write of size 1 at addr ffff8881032e5d81 by task (udev-worker)/520 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff8881032e5d80, ffff8881032e5d81) Size the allocation to the worst-case decoded length instead of the raw input length: two output bytes for every five-byte input chunk (DIV_ROUND_UP(input_len, 5)), plus one byte for the terminator. Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260915174615.63924-1-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit b770c123e654ff35a0809ec70856c1a145a9ed6c Author: Guangshuo Li Date: Tue Sep 15 15:45:30 2026 +0800 media: i2c: alvium-csi2: balance runtime PM usage count on remove [ Upstream commit 0d2ca640318612402ae1c640d2da56b2914ff994 ] alvium_probe() increments the runtime PM usage count with pm_runtime_get_noresume() before enabling runtime PM. The probe error path correctly balances this reference with pm_runtime_put_noidle(), but the normal remove path only disables runtime PM. pm_runtime_disable() does not decrement the usage count, so a successful probe followed by driver removal leaves the runtime PM usage count unbalanced. Add the missing pm_runtime_put_noidle() to the remove path, matching the existing probe error cleanup. This issue was found by manual code inspection. Fixes: 0a7af872915e ("media: i2c: Add support for alvium camera") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit a53a677c1ddc38d8773587eb3897f44700dde03b Author: Niklas Cassel Date: Tue Sep 15 10:41:31 2026 +0200 ata: libata: Do not leave ata_host_stop() registered when activation fails [ Upstream commit d2f977008cbbae195df678ee1e70e5802f9bd0b8 ] ata_host_start() registers ata_host_stop() as a devres action as soon as it has succeeded, which hands the release of the host resources over to devres: ->port_stop() and ->host_stop() are then called by the driver core when probe() fails. ata_host_activate() and ahci_host_activate_multi_irqs() can both fail after ata_host_start() has succeeded, e.g. if devm_request_irq() or ata_host_register() fails, and they return the error with the devres action still registered. A driver which releases the host resources in its probe() error path therefore releases them twice: once itself and once through ->host_stop(). All ahci-platform drivers are in that situation, e.g. ahci_probe() calls ahci_platform_disable_resources() while ahci_host_stop() does the same through devres. This gives refcount underflow warnings from the clk, regulator and phy cores and, for shared resources, can disable resources which are still in use by other devices. Add ata_host_undo_start(), which stops the ports and drops the devres action without calling ->host_stop(), and call it from both activation helpers when they fail. Releasing the host resources on failure is then always left to the caller, which is what all callers having a probe() error path already assume. This changes the semantics for the drivers which implement ->host_stop() while also completely lacking error handling for the activate host call. Add activate host error handling for sata_qstor and sata_fsl. For sata_fsl this also means that hcr_base and host_priv are now released when activating the host fails, which ->host_stop() did not do when ata_host_start() itself failed. Note that ata_pci_sff_activate_host() is deliberately left as is: none of its callers releases the host resources in its probe() error path, they all rely on ->host_stop() being called by devres, including ata_pci_init_one(), which releases the devres group of the host itself. Fixes: 1896b15eddb4 ("ahci_platform: perform platform exit in host_stop() hook") Cc: stable@vger.kernel.org Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20260915084127.692494-13-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit a6fccb378b6bff288acde99c81876d8b7c086fcd Author: Niklas Cassel Date: Tue Sep 15 10:41:30 2026 +0200 ata: libahci: Free the IRQs when activating a multi-IRQ host fails [ Upstream commit 34a4a34431ed81d85d14f8fb8035e5a25214ad39 ] ahci_host_activate_multi_irqs() requests one IRQ per port, but it does not free them when requesting one of them, or when registering the host, fails. The IRQs are only freed by the driver core, when it releases the devres of the device after probe() has returned, while the caller of ahci_host_activate() releases the resources of the host in its probe() error path, e.g. ahci_probe() disables the clocks, regulators, resets and PHYs of the host. An IRQ handler running in that window would access the MMIO of a host which is no longer clocked. ahci_host_activate_multi_irqs() did free the IRQs until commit 0a142b26921c ("ahci: cleanup ahci_host_activate_multi_irqs"), which removed the explicit free because devm makes it unnecessary. That is true for freeing the IRQs as such, but not for the window described above: devres is only released after probe() has returned, i.e. after the error path of the caller has released the resources of the host. Note that this window cannot be hit with the current users: the only user of AHCI_HFLAG_MULTI_MSI is the AHCI PCI driver, which does not release any resource in its probe() error path, and the ports of the host are still frozen, i.e. their interrupts are masked, when ata_host_register() fails. Free the IRQs explicitly again, like ata_host_activate() does, so that the IRQ handlers cannot run once ahci_host_activate() has failed. Fixes: 0a142b26921c ("ahci: cleanup ahci_host_activate_multi_irqs") Cc: stable@vger.kernel.org Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20260915084127.692494-12-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 497648f35f3d229be812329e0580583e90bbc555 Author: Niklas Cassel Date: Tue Sep 15 10:41:28 2026 +0200 ata: ahci_st: Assert the power down reset in the probe() error path [ Upstream commit 91e0a7452d7a81e924a499b23f30f3bf85fddbd2 ] st_ahci_probe_resets() deasserts the "pwr-dwn" reset, but the probe() error path of st_ahci_probe() only releases the host resources, so the SATA IP is left powered up when probe() fails after st_ahci_probe_resets() has succeeded, e.g. when ahci_platform_enable_resources() fails. The reset is asserted by st_ahci_host_stop(), however ->host_stop() is only called through the ata_host_stop() devres action registered by ata_host_start(), so it does not cover any failure happening before the host has been started. Factor the assert out into st_ahci_assert_pwrdwn() and call it when either ahci_platform_enable_resources() or ahci_platform_init_host() fails. The "pwr-dwn" reset control is an exclusive one, so asserting it once more from st_ahci_host_stop() is harmless. No functional change intended for ->host_stop() and st_ahci_suspend(). Fixes: 76884cb2f7da ("ahci: st: Add support for ST's SATA IP") Cc: stable@vger.kernel.org Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20260915084127.692494-10-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 56088c9ab9edd73cdc3f0949c692d013779deaf0 Author: Niklas Cassel Date: Tue Sep 15 10:41:27 2026 +0200 ata: ahci_st: Do not ignore errors when getting the reset controls [ Upstream commit c74ee9230a8d1d2f6fcbceff55f56f7dd9b9cccd ] st_ahci_probe_resets() treats any error from devm_reset_control_get() as "reset control not defined" and continues with a NULL reset control: drv_data->pwr = devm_reset_control_get(dev, "pwr-dwn"); if (IS_ERR(drv_data->pwr)) { dev_info(dev, "power reset control not defined\n"); drv_data->pwr = NULL; } This also swallows -EPROBE_DEFER, which is returned when the reset controller providing the reset has not been probed yet. probe() then continues as if the device tree did not specify any reset, so the resets of the SATA IP are never deasserted, and st_ahci_configure_oob() and ahci_platform_init_host() access the MMIO of an IP which is still held in reset and powered down, which can result in an external abort. The resets are optional in the binding, as they are not part of its required properties, so use devm_reset_control_get_optional(), which returns NULL if the reset is not specified in the device tree, and propagate all other errors. Note that an absent reset is now indicated by a NULL reset control instead of an error, so the "reset control not defined" messages are dropped. Fixes: 76884cb2f7da ("ahci: st: Add support for ST's SATA IP") Cc: stable@vger.kernel.org Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20260915084127.692494-9-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 305021c93f4457c56d899e858742860df7bf0b8b Author: Chao Yu Date: Thu Sep 10 22:11:26 2026 +0800 f2fs: compress: fix to handle race between truncate and writeback [ Upstream commit c0337e331b065074ce20e4258a578e07dd7e4083 ] fsstress reports a kernel BUG in f2fs_truncate_partial_cluster(): kernel BUG at fs/f2fs/compress.c:1238! RIP: 0010:f2fs_truncate_partial_cluster+0x292/0x2a0 Call Trace: f2fs_truncate+0xf6/0x210 f2fs_setattr+0x6b7/0x770 notify_change+0x33b/0x520 do_truncate+0xc2/0xf0 vfs_truncate+0x153/0x1d0 ksys_truncate+0x78/0xd0 __x64_sys_truncate+0x16/0x20 do_syscall_64+0xbe/0x540 The root cause is that Thread A (truncate) and Thread B (background writeback or fsync) can race as follows: Thread A Thread B - f2fs_setattr - f2fs_truncate - f2fs_truncate_blocks - f2fs_truncate_partial_cluster - f2fs_is_compressed_cluster return 1 - f2fs_write_cache_pages - f2fs_write_multi_pages - f2fs_write_raw_pages - f2fs_write_single_data_page dn.data_blkaddr != COMPRESS_ADDR (cluster converted to normal) - f2fs_prepare_compress_overwrite - f2fs_is_compressed_cluster return 0 - return 0 - f2fs_bug_on(sbi, err == 0): BUG! Writeback path does not acquire i_gc_rwsem or filemap_invalidate_lock. When a compressed cluster fails compression during writeback, it is overwritten with raw data blocks. If Thread A checked f2fs_is_compressed_cluster() before the conversion, but calls f2fs_prepare_compress_overwrite() after the conversion, f2fs_prepare_compress_overwrite() returns 0 because the cluster is no longer a compressed cluster. To fix this, remove the f2fs_bug_on() and retry checking the cluster status when f2fs_prepare_compress_overwrite() returns 0, so that it can fall back to f2fs_do_truncate_blocks() to handle it as a normal cluster. Cc: stable@kernel.org Fixes: 3265d3db1f16 ("f2fs: support partial truncation on compressed inode") Reviewed-by: Zhiguo Niu Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 49d7e920a2098fa6763b111924d99630d366af39 Author: Jiucheng Xu Date: Mon Sep 7 19:35:42 2026 +0800 f2fs: force out-place update for all writes on compressed file [ Upstream commit a64a3fec11e77a3a0dc0009bdc58b925e45a1bb4 ] For compressed file, compressed write may fail and fall back to raw write. -Thread A - Thread B - f2fs_write_multi_pages - f2fs_down_write(&sbi->cp_rwsem); - f2fs_write_compressed_pages - ... - f2fs_trylock_op - ... - f2fs_down_read_trylock(&sbi->cp_rwsem); - ... - f2fs_write_raw_pages - ... Thread B acquires the lock first, which causes Thread A to fail lock acquisition and fall back to raw-data write. IPU_FORCE is enabled on small-capacity storage devices (< 16GB), so f2fs_write_raw_pages() overwrites the original compressed data in-place. The in-memory node has been updated with raw-data addresses, while the node metadata stored on eMMC still remains in compressed state. If a power-cut occurs before the node is flushed to disk, on-disk inconsistency arises: disk data is raw, yet metadata treats it as a compressed cluster, leading to decompression failure. To eliminate this risk completely, force out-place update for all write operations on compressed file. Cc: stable@kernel.org Fixes: 4c8ff7095bef ("f2fs: support data compression") Signed-off-by: Jiucheng Xu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 55aa09a95e15ebfb5d8413096ce465462a03372b Author: Matthew Sakai Date: Tue Aug 11 15:02:34 2026 -0400 dm vdo indexer: validate record page numbers better [ Upstream commit e3683a76a313a81f3f7bc7f65e4fc1e61232838b ] Move the record_page_number validation check into the chapter index lookup function in order to detect (and discard) corrupted values on all paths. Signed-off-by: Matthew Sakai Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d38fccf91d1cc00d9173b4df439ca77ab4d909ec Author: Matthew Sakai Date: Tue Aug 11 15:02:33 2026 -0400 dm vdo indexer: prevent delta list overflow on load [ Upstream commit 936293c9f3f4f2a0d1b80df9332e96c552ac3b37 ] Check for corrupted delta lists sizes that overflow the memory available for the delta_lists. An overflow can cause the delta list data to be written outside the reserved delta memory space. Signed-off-by: Matthew Sakai Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit de769c810575592bbe0926150bdf34517e7b84c4 Author: Kyle Zeng Date: Thu Jun 11 14:21:10 2026 -0700 affs: validate blocks before freeing them [ Upstream commit 78ea2058abf3ee053c0bd9c1b9a77304cb4ae58b ] affs_free_block() accepts block numbers from on-disk file block tables when truncating or unlinking files. The function currently rejects only block numbers greater than s_partition_size before subtracting s_reserved and using the result to index the in-memory bitmap descriptor array. That check still accepts reserved blocks and the one-past-end block at s_partition_size. A crafted image can therefore make the subtraction underflow or make the computed bitmap index equal to s_bmap_count, leading to an out-of-bounds access on s_bitmap before the bitmap block is read and updated. Use the existing AFFS block validity helper so freeing uses the same range as block reads and writes: s_reserved <= block < s_partition_size. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") CC: stable@vger.kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Kyle Zeng Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 068f07643851341ce83d6ee112b963c3a5ccf29e Author: Bradley Morgan Date: Thu Aug 13 07:43:43 2026 +0000 PM: CPU: Restore synchronize_rcu() to cpu_pm_unregister_notifier() [ Upstream commit 61f7eee7d4664079fbce821576891c3ee5ccf597 ] cpu_pm_notify() walks the notifier chain lockless under only rcu_read_lock(). That only works if a removed notifier block is not freed until every concurrent walker is done with it. The chain used to be an atomic_notifier, whose unregister ends in synchronize_rcu(). Commit b2f6662ac08d ("PM: cpu: Make notifier chain use a raw_spinlock_t") switched it over to a raw_notifier, and in doing so replaced that with raw_notifier_chain_unregister(), which does not synchronize. The grace period quietly went away, so a driver that frees the memory holding its notifier block right after cpu_pm_unregister_notifier() returns can race with a concurrent walker: cpu1 (idle exit) cpu2 (driver remove) ---------------- -------------------- cpu_pm_notify(CPU_PM_EXIT) rcu_read_lock() nb = rcu_dereference_raw(*nl) cpu_pm_unregister_notifier(&od->nb) unlink, no grace period remove() frees od (devm) nb->notifier_call(nb, ...) /* use after free */ The rcu_read_lock() on cpu1 does not stop cpu2 from freeing the block, and nothing else does. The read side is the idle exit path, so this can hit on any system where a driver with a cpu_pm notifier gets unbound. Add the grace period back. It is only needed when a notifier was actually removed, so wait on success and return -ENOENT without waiting otherwise. The kerneldoc gets back the "may sleep" note that the same commit dropped. Fixes: b2f6662ac08d ("PM: cpu: Make notifier chain use a raw_spinlock_t") Cc: All applicable Signed-off-by: Bradley Morgan [ rjw: Subject tweak ] Link: https://patch.msgid.link/20260813074343.26460-3-include@grrlz.net Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c501bac2c5f8d7699d3dab4893113eeb2093e15b Author: Runyu Xiao Date: Sun Aug 30 09:51:04 2026 +0800 crypto: ccp - Initialize DBC ioctl mutex before registering device [ Upstream commit e9b1d168f2a70c0764d5748893fdf631c504c171 ] dbc_dev_init() registers the DBC misc device before initializing ioctl_mutex. Once misc_register() publishes the device, userspace can open it and invoke dbc_ioctl() while the mutex is still uninitialized. Initialize ioctl_mutex before calling misc_register() so the published ioctl callback always sees an initialized mutex. Fixes: c04cf9e14f10 ("crypto: ccp - Add support for fetching a nonce for dynamic boost control") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260829133410.1708684-1-runyu.xiao@seu.edu.cn/ Signed-off-by: Runyu Xiao Assisted-by: Codex:GPT-5 Reviewed-by: Tom Lendacky Reviewed-by: Mario Limonciello (AMD) > --- Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 80e4e0d7b3905e0d71dfdfbe0eb6a7a3ef475492 Author: Karl Mehltretter Date: Sat Aug 29 11:18:50 2026 +0200 lib/842: require a complete history block for repeat templates [ Upstream commit deb631649882bbf43f7c2fc79b5990139fd744ba ] An 842 repeat template copies the preceding eight-byte output block. The decoder rejects a repeat only when no output has been produced. A short-data operation can produce between one and seven bytes before a repeat. Such a stream makes the repeat copy read before the start of the output buffer. Depending on the surrounding mapping, this can fault or bring preceding memory into the decompressed data. This is also reachable through zram's compressed writeback path. With 842 selected, targeted corruption of the compressed data on its backing device to a short-data-then-repeat stream made a KASAN kernel report a vmalloc-out-of-bounds read when zram read the page back. Require at least one complete output block before accepting a repeat. Fixes: 2da572c959dd ("lib: add software 842 compression/decompression") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bf2fa75552d5962db8538278d282b454bd88dfff Author: Karl Mehltretter Date: Sat Aug 29 11:18:49 2026 +0200 lib/842: reject output overflows from index and short data [ Upstream commit 38ed7182f3491ec1449ff246551e11ad82adba45 ] The output length passed to sw842_decompress() is the caller's buffer capacity. Indexed copies write 2, 4 or 8 bytes and short-data templates write up to 7, but neither checks that capacity before writing and decrementing p->olen. Overwriting an undersized destination then underflows p->olen, which is unsigned, so every later bounds check in the stream passes. Subsequent operations keep writing past the destination, and a matching CRC lets sw842_decompress() return success with an output length larger than the capacity the caller supplied. This is reachable through zram's compressed writeback path. With 842 selected, targeted corruption of the compressed data on its backing device made a KASAN kernel report vmalloc-out-of-bounds writes in __do_index() and sw842_decompress() when zram read the page back. Check the remaining output before both operations and return -ENOSPC, matching the other output-producing templates. Fixes: 2da572c959dd ("lib: add software 842 compression/decompression") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e68d7c1677df95bbc0eaf87359e37c56471b48d6 Author: Karl Mehltretter Date: Sat Aug 29 06:26:04 2026 +0200 crypto: atmel-aes - fix AADLENR for standalone GHASH [ Upstream commit 0dd8cded0e6f8c9635fe1d79d60dc7b2599b099b ] atmel_aes_gcm_ghash_init() writes dd->total, the request's text length, to AES_AADLENR. But the GHASH it runs hashes the dd->datalen bytes passed in: the 16-byte length block, or the padded IV when the IV is not 96 bits. The data sheet requires AES_AADLENR to hold the length of that input. With empty plaintext and empty AAD, dd->total is 0 and the tag comes out wrong. Later requests only pass because dd->total still holds the previous request's length. This is testmgr's first gcm(aes) vector, so CONFIG_CRYPTO_SELFTESTS=y fails at boot: alg: aead: atmel-gcm-aes encryption test failed (wrong result) on test vector 0, cfg="in-place (one sglist)" Without selftests the broken atmel-gcm-aes is preferred at priority 300. Seen on a SAM9X75 Curiosity with 6.18 and current mainline. Write dd->datalen instead. Fixes: d4419548dba9 ("crypto: atmel-aes - add support to GCM mode") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0cf18855b2c51ffabfdaeb6f3ee226a7cd67139b Author: Karl Mehltretter Date: Sat Aug 29 05:58:21 2026 +0200 crypto: atmel-tdes - zero-initialize device state [ Upstream commit dbe70508d507acd677e67eaf029040f5e3a3b2b3 ] Commit c659d07f11a3 ("crypto: atmel-tdes - Switch to managed version of kzalloc") accidentally replaced kzalloc() with devm_kmalloc(), so the device state is no longer zeroed. atmel_tdes_hw_init() tests dd->flags during probe: a stale TDES_FLAGS_INIT skips the hardware reset, and a stale TDES_FLAGS_BUSY makes atmel_tdes_handle_queue() treat the engine as permanently busy, leaving every request queued and never dispatched. Seen on a SAM9X75 Curiosity: the first TDES request after boot never completes and the TDES interrupt count stays at zero, while the AES and SHA engines on the same SoC work normally. Switch to devm_kzalloc(), matching the Atmel AES and SHA drivers. Fixes: c659d07f11a3 ("crypto: atmel-tdes - Switch to managed version of kzalloc") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 85fc823a00341f63fea31a4efccf362c9a94a113 Author: Junrui Luo Date: Tue Sep 8 15:27:21 2026 +0800 media: vicodec: zero-initialize stateful decoder heap buffers [ Upstream commit 27953c044974baf7e24dee3e9342fe0103dea80c ] The stateful decoder leaks uninitialized kernel heap memory to userspace. A process that can open the decoder video node gets it back in the CAPTURE buffers it dequeues. The reference frame and the compressed frame buffer are allocated with kvmalloc() in vicodec_start_streaming(), and the decoder can read them before they have been written. The first frame is allowed to be a P-frame, in which case it is decoded against a reference frame that was never produced, and the padding rows below the visible area are never written for any frame. Use kvzalloc() for both allocations. Fixes: 256bf813ba39 ("media: vicodec: add the virtual codec driver") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 285eb18ef6cfd494d9a41a98635779dd29c73f29 Author: Fan Wu Date: Wed Sep 9 08:13:41 2026 +0000 media: vivid: cancel svid ctrl work on release [ Upstream commit 1adaefca7111235ff0a2219dd4899ac24601d6e8 ] vivid_dev_release() cancels update_hdmi_ctrl_work but not its sibling update_svid_ctrl_work, which vivid_vid_cap_s_ctrl() queues on update_svid_ctrls_workqueue when a VIVID_CID_SVID_IS_CONNECTED_TO_OUTPUT control is changed. The two work items were added together, but only one of them is cancelled on release. If the svid work is still pending or running when the last v4l2_device reference is dropped, update_svid_ctrls_work_handler() runs after kfree(dev): the handler iterates the global vivid_devs[] array and calls v4l2_ctrl_modify_range() on every vivid_dev instance, including this one after it has been freed. Add the missing cancel_work_sync() next to the hdmi sibling, before vivid_free_controls() releases the control handlers the work uses. This issue was found by an in-house static analysis tool. Fixes: d7c969f37515 ("media: vivid: Add 'Is Connected To' menu controls") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit af8382230b821b50fd01920043e54618b497d726 Author: Juan Perdomo Date: Tue Sep 8 00:07:34 2026 -0400 media: cx231xx: preserve I2C transfer length [ Upstream commit a19c9502a69bbd42c18816b09cbefdeb4cb68066 ] The I2C core stores message lengths in u16, but cx231xx truncates them to u8 when populating cx231xx_i2c_xfer_data. A 0x700-byte read therefore becomes a zero-length request. USB treats zero-length control transfers as OUT regardless of bRequestType, so the IN control pipe trips the usb_submit_urb() direction warning. Use u16 for buf_size, matching both i2c_msg.len and VENDOR_REQUEST_IN.wLength. Oversized transfers then reach the existing URB_MAX_CTRL_SIZE check and return -EINVAL. Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver") Cc: stable@kernel.org Reported-by: syzbot+ddccc0c0dbc0a38ffccb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ddccc0c0dbc0a38ffccb Tested-by: syzbot+ddccc0c0dbc0a38ffccb@syzkaller.appspotmail.com Signed-off-by: Juan Perdomo Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 883ba9671d826fe7e6a5d2cd6789eb42f46f9ec5 Author: Maxim Skokov Date: Sat Sep 5 18:58:18 2026 +0300 media: vivid: round the height down to the vertical subsampling factor [ Upstream commit a2ec28dd2a88d0721fc4a30242861e2be01d4023 ] syzbot reports a vmalloc out-of-bounds write in the test pattern generator: BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2617 [inline] BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_buffer+0x2063/0x4160 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705 Write of size 720 at addr ffffc900038f9d50 by task vivid-000-vid-c/6017 The reproducer requests a 720x49 NV12 capture format, i.e. an odd height for a format whose chroma plane is vertically subsampled. The buffer size is derived from the height by a truncating division: sizes[p] = (tpg_g_line_width(&dev->tpg, p) * h) / dev->fmt_cap->vdownsampling[p] + dev->fmt_cap->data_offset[p]; For a single buffer holding both planes tpg_g_line_width() returns 720 + 720 / 2 = 1080, so 1080 * 49 = 52920 bytes get allocated. tpg_fill_plane_buffer() however emits one chroma line for every two luma lines, i.e. DIV_ROUND_UP(49, 2) = 25 lines, and thus needs 49 * 720 + 25 * 720 = 53280 bytes. The memcpy() of the last chroma line runs 360 bytes past the end of the buffer. An odd height is not meaningful for a 4:2:0 format in the first place, since the chroma plane would have to hold half a line. Rather than fixing up each of the ~10 sites that divide the height by vdownsampling[], round the height down to a multiple of the vertical subsampling factor where it enters the driver. Adjusting the format is what TRY_FMT/S_FMT are for, and it keeps every later division exact. Formats without vertical subsampling are unaffected and keep accepting odd heights. Tested with the syzbot reproducer, which no longer triggers the splat, and by streaming NV12, NV21, YUV420, YVU420 and YUYV at heights 47, 48, 49, 51, 480, 481 and 1081. v4l2-compliance gives identical results before and after (48 of 50 succeeded on the vivid device in both cases; the two failures are pre-existing and unrelated). Fixes: ddcaee9dd4c0 ("[media] vivid: add support for single buffer planar formats") Cc: stable@kernel.org Reported-by: syzbot+cb43e758a4dc84dd467f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cb43e758a4dc84dd467f Signed-off-by: Maxim Skokov Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 521afd30851cd5d8a850e0d73083a60554e118d8 Author: Eric Kim Date: Tue Aug 18 12:48:29 2026 +0900 sched/fair: Reset NUMA fault locality after scan period update [ Upstream commit e81ee06308379a5f2ededf997bcf17551bce5db7 ] When updating the task scan period for NUMA locality checks, update_task_scan_period() checks whether there were no faults or failed migration on the last scan window, at which it prolongs the scan period. However, p->numa_faults_locality, which is used to check for migration failure and number of faults at the previous scan window is not cleared after changing the scan period, which unintentionally increases numa_scan_period up to numa_scan_period_max even when there were no migration failures or no faults at previous scan. Fix this by jumping to the out label on early exit at this case to ensure p->numa_faults_locality is always cleared before returning. Closes: https://lore.kernel.org/all/20250404095354.311156-1-qlsdnjs236@chungbuk.ac.kr/ Reported-by: Binwon Song Signed-off-by: Eric Kim Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/Message-ID: Signed-off-by: Sasha Levin commit 613356daa816250a5359f75d1c39fa6270b07a25 Author: Jean-Baptiste Maneyrol Date: Thu Sep 3 21:37:13 2026 +0200 iio: imu: inv_icm42600: fix odr change not caught in certain cases [ Upstream commit f670d4d3477386d62017936f0121909f93ac17f8 ] When using both accel and gyro with different frequencies, the ODR change flag in the FIFO header can be sometime in a packet with invalid data. Since we are ignoring these packets, we miss the ODR change and any further change are blocked until sensor is turned off. Fix this by moving the packet data validity check after the ODR change flag check. Fixes: ec74ae9fd37c ("iio: imu: inv_icm42600: add accurate timestamping") Cc: stable@vger.kernel.org Signed-off-by: Jean-Baptiste Maneyrol Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 3a5b603cfda397359a3ab51f4df53c34b4e66af9 Author: Shengzhuo Wei Date: Thu Aug 27 05:22:29 2026 +0800 power: supply: bq27xxx: synchronize work cancellation on suspend [ Upstream commit f0ff5673aa07ded2bb383ac526c1faee4fe9ca07 ] The poll work requeues itself via mod_delayed_work() while the device is not removed. cancel_delayed_work() does not wait for a callback that is already running, so a poll racing with suspend can keep issuing I2C transfers after suspend returns and requeue itself into early resume. Use cancel_delayed_work_sync() to quiesce polling before suspend completes, as the teardown path already does. Fixes: dfcb264a01a9 ("power: supply: bq27xxx: Stop and start delayed work in suspend and resume") Cc: stable@vger.kernel.org Signed-off-by: Shengzhuo Wei Link: https://patch.msgid.link/20260827-bq27xxx-suspend-cancel-sync-v1-1-77a67711cbc3@cherr.cc Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 83bcb065882b59a19071bd5ec350e51ec7faf221 Author: Robin Snyders Date: Wed Aug 12 01:30:02 2026 +0200 power: supply: qcom_smbx: notify battery overvoltage recovery [ Upstream commit 2548e4fa576a87a3b0d1b15a9c3f909bc54887b5 ] The battery-overvoltage IRQ is configured for both edges, but its handler only notifies the power-supply core while the fault bit is asserted. The falling edge therefore does not publish the recovered health and status. The handler also ignores register-read failures before testing status. Handle read errors, log only an asserted fault, and notify the power-supply core after every successful edge read. Fixes: 8648aeb5d7b7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver") Cc: stable@vger.kernel.org Signed-off-by: Robin Snyders Link: https://patch.msgid.link/20260812-qcom-smbx-fixes-v1-5-eb48246be599@snyders.xyz Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 428c794e25a7bcd9be9d89f68ab7b0a25879ed79 Author: Robin Snyders Date: Wed Aug 12 01:30:00 2026 +0200 power: supply: qcom_smbx: fix float voltage selector [ Upstream commit 2a26d260e72a95e9f13b9e475f63aa404600fcb2 ] FLOAT_VOLTAGE_CFG encodes 3,487,500 uV as selector zero and advances in 7,500 uV steps. The current calculation adds one to that selector, so it programs the requested float voltage one step too high. Remove the extra offset and name the hardware encoding constants. Fixes: 8648aeb5d7b7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver") Cc: stable@vger.kernel.org Signed-off-by: Robin Snyders Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260812-qcom-smbx-fixes-v1-3-eb48246be599@snyders.xyz Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit d9b72045d266624059654701a280c54de45da682 Author: Robin Snyders Date: Wed Aug 12 01:29:59 2026 +0200 power: supply: qcom_smbx: test battery health status bits [ Upstream commit 68f645192f64e1037685dbdb0dffb41a5a012056 ] BATTERY_CHARGER_STATUS_2 contains independent status and fault bits. Switching on the complete register only recognizes a fault when it is the sole asserted bit, and can report a healthy battery when another status bit is set at the same time. Test the relevant fault bits in priority order, matching the Qualcomm downstream driver handling. Fixes: 8648aeb5d7b7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver") Cc: stable@vger.kernel.org Signed-off-by: Robin Snyders Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260812-qcom-smbx-fixes-v1-2-eb48246be599@snyders.xyz Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 3a7a0b0751b4684c8ae9067b798b5de7c99524e9 Author: Robin Snyders Date: Wed Aug 12 01:29:58 2026 +0200 power: supply: qcom_smbx: include base when petting watchdog [ Upstream commit 2f0dec12007891398e6e3041aca0b8656918973d ] BARK_BITE_WDOG_PET is an offset from the charger peripheral base, but the watchdog bark handler writes it as an absolute SPMI address. This can write another PMIC peripheral and leave the charger watchdog unserviced. Add the charger base, as all other qcom_smbx register accesses do. Fixes: 8648aeb5d7b7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver") Cc: stable@vger.kernel.org Signed-off-by: Robin Snyders Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260812-qcom-smbx-fixes-v1-1-eb48246be599@snyders.xyz Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 501ea019dcfc5af79f7ad0099af687557bef89f9 Author: Karl Mehltretter Date: Thu Aug 27 07:37:41 2026 +0200 ACPI: pfr_update: zero-initialize capability query result [ Upstream commit d776369a9eded071df83e4738e1572c4c5b912d7 ] query_capability() copies four ACPI buffers into fixed-size fields using the firmware-supplied lengths. The existing overflow guard rejects oversized buffers, but shorter buffers are accepted and leave trailing bytes of the stack-allocated cap_hdr uninitialized. PFRU_IOC_QUERY_CAP then copies the entire structure to userspace. Zero-initialize cap_hdr before querying the firmware. This preserves the existing handling of short firmware responses while preventing disclosure of kernel stack data. Oversized buffers remain rejected. A QEMU _DSM returning one-byte buffers reproduced nonzero stack suffix bytes in all four fields. With this change, the ioctl still succeeds and each unwritten suffix is zero-filled, while 64-byte buffers continue to return -EINVAL. Fixes: 0db89fa243e5 ("ACPI: Introduce Platform Firmware Runtime Update device driver") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/1a001e1fee9.637da6dc3533246.238498880682901704%40a0rg.com Cc: All applicable Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260827053741.79425-1-kmehltretter@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 594286674cb98a82882d6f69c339a91a8ac8b9d7 Author: Runyu Xiao Date: Sun Aug 30 13:33:08 2026 +0800 dmaengine: altera-msgdma: initialize state before requesting IRQ [ Upstream commit a5f8e3471fc20567df888267885dec3eb340eb37 ] msgdma_probe() registers the IRQ before initializing the tasklet, lock, and descriptor lists used by the interrupt handler. A pending interrupt can access incomplete state during probe. Initialize the handler state before requesting the IRQ so the interrupt path observes ready software state. Fixes: a85c6f1b2921 ("dmaengine: Add driver for Altera / Intel mSGDMA IP core") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Acked-by: Adrian Ng Ho Yin Reviewed-by: Frank Li Link: https://patch.msgid.link/20260830053308.2190597-1-runyu.xiao@seu.edu.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8c7715b303aaaed097335ea6a55e20435fc87183 Author: Damon Ding Date: Fri Aug 28 14:51:51 2026 +0800 drm/bridge: analogix_dp: Restore mandatory samsung DP DT properties [ Upstream commit 02f569dd66c94dd67b2586f776235cf4177409ed ] Revert the change that made samsung,link-rate and samsung,lane-count optional for Exynos DP. Add error checking to fail probe early if the required DT properties are missing. If these properties are missing, video_info->max_link_rate and video_info->max_lane_count remain zero, and so do link_train.link_rate and link_train.lane_count used in the subsequent link training flow, resulting in link training failure. There is no way at all a device can work without these properties. Here is the code flow when either max_link_rate or max_lane_count is 0: analogix_dp_commit() -> analogix_dp_full_link_train(dp, max_lanes = 0, max_rate = 0) analogix_dp_full_link_train(max_lanes, max_rate): // Read sink capabilities via DPCD and sanitize them link_rate = read_dpcd(DP_MAX_LINK_RATE); // >= 0x06 after fixup lane_count = read_dpcd(DP_MAX_LANE_COUNT); // >= 1 after fixup // Clamp by the limits from DT if (link_rate > max_rate) // 0x06 > 0, always true link_rate = max_rate; // link_rate = 0 if (lane_count > max_lanes) // 1 > 0, always true lane_count = max_lanes; // lane_count = 0 // Configure TX with the zeroed values set_link_bandwidth(link_rate = 0) // writel() is only executed for bwtype == 0x06/0x0a, // so LINK_BW_SET is never written and stays at // reset value; phy_configure() gets link_rate = 0. set_lane_count(lane_count = 0) // writel(0, ANALOGIX_DP_LANE_COUNT_SET) enables 0 lanes; // phy_configure() is called with lanes = 0. // Program sink for link training drm_dp_dpcd_write(DP_LINK_BW_SET, {link_rate = 0/lane_count = 0}) // DP spec requires link rate in {0x06, 0x0a, 0x14} and // lane count in {1, 2, 4}. Writing zeros is illegal, so // the sink cannot enter the training state. // Training loop for (lane = 0; lane < lane_count /* 0 */; lane++) // loop body never executes; training_lane[] stays // uninitialized and no training register is programmed Since the sanitized sink values are always non-zero (link_rate >= 0x06, lane_count >= 1), the clamping with a zero maximum unconditionally forces the training parameters to zero. Clock recovery can never be achieved, so link training fails deterministically. Consequently, making these properties mandatory again cannot break any existing device: a DT without them could never have worked in the first place. Failing probe early with a clear error message is more helpful than a silent link training failure at runtime. Fixes: 0d0abd894ead ("drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288") Cc: stable@vger.kernel.org Reviewed-by: Luca Ceresoli Signed-off-by: Damon Ding Link: https://patch.msgid.link/20260828065153.590802-4-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin commit 8937d384205b6d385ce1c1bea6c16145de72d9b4 Author: Fan Wu Date: Thu Jul 16 10:15:39 2026 +0000 media: nuvoton: npcm-video: quiesce VCD IRQ before teardown [ Upstream commit ae8a4b51df30e39c07704efd5500361d8138c4d0 ] The VCD IRQ is devm-requested, but npcm_video_remove() frees the video object before devres releases that IRQ. The threaded handler dereferences video->vcd_regmap before checking VIDEO_STREAMING, so an interrupt in that interval can access freed memory. Request the IRQ with IRQF_NO_AUTOEN. Enable it after starting capture and setting VIDEO_STREAMING, and disable it first in stop_streaming(). disable_irq() waits for an in-flight threaded handler to finish, after which stop_streaming() can mask and reset the VCD without a handler re-enabling it. Use vb2_video_unregister_device() during remove. It releases the vb2 queue and calls stop_streaming() for an active stream, ensuring that the IRQ is disabled before the video object is freed. Do not release the queue separately. If streaming is never started, IRQF_NO_AUTOEN keeps the IRQ disabled until devres releases it. This issue was found by an in-house static analysis tool. Fixes: 46c15a4ff1f4 ("media: nuvoton: Add driver for NPCM video capture and encoding engine") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Tested-by: Marvin Lin Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 8d1cf1a3de3647565d2ce60daf1448defe6cc7ce Author: Greg Kroah-Hartman Date: Thu Apr 9 15:49:46 2026 +0200 media: stv0900: bound DiSEqC reply length to msg[] size [ Upstream commit 6d7e70111b9c80a9e4cb17fe6a6c4f5470847722 ] The FIFO_BYTENBR field is 4 bits (mask 0x0f), giving a length of 0..15 but reply->msg is __u8[4] in struct dvb_diseqc_slave_reply. A faulty or malicious device reporting more than 4 bytes will the array and clobber the stack. The stb0899, tda10071, and s5h1420 drivers all properly bound the FIFO count against sizeof(reply->msg) before the read loop, so do the same thing in this driver. Fixes: 99277b3824e4 ("V4L/DVB (10803): Add core code for ST STV0900 dual demodulator.") Cc: stable@kernel.org Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 96154ed498d5ca7a883c61ca5904d4243106f737 Author: Greg Kroah-Hartman Date: Thu Apr 9 15:49:45 2026 +0200 media: stv090x: bound DiSEqC reply length to msg[] size [ Upstream commit bad6ce6e0856f344910ba95b006e6c0ebee2d9c8 ] The FIFO_BYTENBR_FIELD register field is 4 bits wide, giving a length of 0..15, but reply->msg is __u8[4] in struct dvb_diseqc_slave_reply. A faulty or malicious DiSEqC slave (or i2c bus glitch) reporting more than 4 bytes will the array and clobber the stack. The stb0899, tda10071, and s5h1420 drivers all properly bound the FIFO count against sizeof(reply->msg) before the read loop, so do the same thing in this driver. Fixes: e415c689a884 ("V4L/DVB (11579): Initial go at TT S2-1600") Cc: stable@kernel.org Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 6c131308cadc0dded0b7fca90482edef4fb66802 Author: Greg Kroah-Hartman Date: Thu Apr 9 15:49:44 2026 +0200 media: adv7604: avoid negative array index in log_status when cp_read fails [ Upstream commit 10d8dfda1c08f6788049aa100685e223d857f901 ] cp_read() returns the negative errno from regmap_read() on I2C failure. adv76xx_log_status() shifts the result right by 4 and uses it directly to index csc_coeff_sel_rb[16] causing the right shift of a negative number to result in -1, reading a negative place in the array. Commit 8163419e3e05 ("media: adv7842: Avoid possible out-of-bounds array accesses in adv7842_cp_log_status()") fixed the identical pattern in the adv7842, so do the same thing here. Fixes: 54450f591c99 ("[media] adv7604: driver for the Analog Devices ADV7604 video decoder") Cc: stable@kernel.org Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 62fc9430b94612372224f893f3b4f32ab34d992a Author: James Hilliard Date: Fri Sep 4 19:05:37 2026 -0600 mtd: rawnand: sunxi: reject ECC maximization on small pages [ Upstream commit a3c84084a73e170374b7dd493947efdef4ee57bc ] When nand-ecc-maximize is set, the driver selects a 1024-byte ECC step and divides the available OOB bytes by the resulting number of steps. A NAND with a smaller page therefore produces zero steps and a division by zero. The older controllers also provide a 512-byte ECC block mode, but the hardware documentation describes that as an ECC block size within NAND pages whose supported sizes start at 1024 bytes. It does not document a 512-byte NAND page mode. Reject pages smaller than 1024 bytes before deriving the step count. This prevents the division by zero at the point where the incompatible maximized geometry is selected without changing explicitly configured 512-byte ECC block handling. Fixes: 4796d8655915 ("mtd: nand: sunxi: Support ECC maximization") Cc: stable@vger.kernel.org Signed-off-by: James Hilliard Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 15b002552e70c8cc2c2a8060b8ed68779ad2951f Author: Balakrishnan Sambath Date: Wed Aug 19 11:49:20 2026 +0530 media: microchip-isc: don't sleep in the clk .is_enabled callback [ Upstream commit 61490ff518c7b3ea3ff1cd16bbc012e9e4f1ab74 ] isc_clk_is_enabled() calls pm_runtime_resume_and_get() and pm_runtime_put_sync(), which can sleep and are not safe here, as .is_enabled must run in atomic context. clk_disable_unused() calls it so at boot, and CONFIG_DEBUG_ATOMIC_SLEEP reports a "sleeping function called from invalid context" BUG. Use the atomic-safe pm_runtime_get_if_active() and pm_runtime_put() instead. A suspended ISC has its clocks gated, so report the clock disabled when the device is not already active. Fixes: 01192aa1c5c2 ("media: atmel-isc: Enable the clocks during probe") Cc: stable@vger.kernel.org Signed-off-by: Balakrishnan Sambath Reviewed-by: Eugen Hristev Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 816bd2af170dcca59b4654964d252bc9d8f7ebc7 Author: Balakrishnan Sambath Date: Mon Aug 17 12:22:05 2026 +0530 media: microchip-isc: fix PM runtime leak in AWB work handler [ Upstream commit 21ad8225822a892c4c273bf1368d477a83a19dbb ] Early return when streaming stops skips pm_runtime_put_sync(), leaking the reference and preventing runtime suspend. Fixes: 314c96e5203d ("media: atmel: atmel-isc-base: use mutex to lock awb workq from streaming") Cc: stable@vger.kernel.org Signed-off-by: Balakrishnan Sambath Reviewed-by: Eugen Hristev Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit cb323f0650b92b1cf606d3ab83d41c1673c94fea Author: Balakrishnan Sambath Date: Mon Aug 17 12:22:02 2026 +0530 media: microchip-isc: do not touch WB registers when not streaming [ Upstream commit d8983c47d4d95eb1ed889dbb7516d3738fa854d8 ] isc_s_awb_ctrl() called isc_update_awb_ctrls() unconditionally, writing the white balance registers even when the device is runtime suspended; on many ARM platforms accessing the unclocked registers is an external abort. The write was also done without awb_lock, racing isc_awb_work(), which holds it so the DMA done IRQ cannot latch a half-updated pipeline. Write the registers only while streaming and not stopping, under awb_lock, and update the profile there. The isc->stop check covers the window where isc_stop_streaming() has gated the clocks but vb2 still reports streaming. Otherwise the new values stay cached and isc_configure() programs them at the next stream start. Fixes: 4e52889f48fe ("media: atmel: atmel-isc-base: expose white balance as v4l2 controls") Cc: stable@vger.kernel.org Reviewed-by: Eugen Hristev Signed-off-by: Balakrishnan Sambath Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e57d9cea533d232ffa31fd77f6d79fa704af57fc Author: Balakrishnan Sambath Date: Mon Aug 17 12:22:01 2026 +0530 media: microchip-isc: disable histogram and flush AWB work on teardown [ Upstream commit 00d87c379915a3689b2488bd37f490875d79e20f ] isc_stop_streaming() and the isc_start_streaming() error path dropped the runtime PM reference with the histogram still enabled. A HISDONE firing just before the stop, or a failed isc_update_profile() on the start path, can queue isc_awb_work(), which reads the histogram registers before taking its own PM reference and faults on the unclocked device. Disable the histogram, synchronize the IRQ and flush the work before the device is left unclocked. isc_configure() is the one enabling the histogram and then calling isc_update_profile(), so do the cleanup in its own failure path; isc_stop_streaming() does the same on teardown. synchronize_irq() must come before cancel_work_sync(), so an in-flight handler cannot re-queue awb_work after it is cancelled. Fixes: 93d4a26c3dab ("[media] atmel-isc: add the isc pipeline function") Cc: stable@vger.kernel.org Signed-off-by: Balakrishnan Sambath Reviewed-by: Eugen Hristev Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d5596198234d79e02648f8fbec8dd677a40e87d8 Author: Balakrishnan Sambath Date: Mon Aug 17 12:22:00 2026 +0530 media: microchip-isc: synchronize the IRQ before disabling clocks on stop [ Upstream commit 19fa5407da5ef3e605cacfcd90f70d8b2c121cd7 ] isc_stop_streaming() masks the DMA interrupt and then drops the runtime PM reference, which disables the ISC clocks. microchip_isc_interrupt() may still be executing on another CPU at that point; it reads ISC_INTSR over regmap, and touching the unclocked registers triggers an external abort. Store the IRQ number at probe and call synchronize_irq() after masking the interrupt, before dropping the PM reference. Fixes: 106267444f12 ("[media] atmel-isc: add the Image Sensor Controller code") Cc: stable@vger.kernel.org Signed-off-by: Balakrishnan Sambath Reviewed-by: Eugen Hristev Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 65737f75007237bf3507d85e6d4c648388810688 Author: Balakrishnan Sambath Date: Mon Aug 17 12:21:58 2026 +0530 media: microchip-isc: fix awb_mutex and lock lifecycle [ Upstream commit 5540b48c0702f6a1389db3d473d7fd0db930422a ] isc->lock and awb_mutex were initialised in isc_async_complete() and destroyed in isc_async_unbind(), tying their lifetime to the subdev bind/unbind cycle instead of the device: - isc_async_unbind() destroyed awb_mutex before cancel_work_sync(), which takes it; - a failed .complete() left them initialised, and isc->lock was destroyed only on the .complete() error path, so the normal unbind path leaked it; - a rebind runs .complete() again and reinitialises a live mutex. Initialise both with devm_mutex_init() at probe so they live for the whole device lifetime and are freed at remove, and drop the init and destroy from the .complete()/.unbind() callbacks. isc_async_complete_err then only returned ret, so drop the label and return directly at each error site. Fixes: 314c96e5203d ("media: atmel: atmel-isc-base: use mutex to lock awb workq from streaming") Cc: stable@vger.kernel.org Reviewed-by: Eugen Hristev Signed-off-by: Balakrishnan Sambath Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d7a194ddb089e63731c2f12a1d6f458aebecaab3 Author: Srinivas Kandagatla Date: Tue Sep 8 09:28:01 2026 +0100 ASoC: codecs: lpass-wsa-macro: use v2.5 Compander1 addresses on v2.5+ [ Upstream commit 233d36a96009682208cc4ca1139b9e5641a8bf09 ] wsa_macro_set_spkr_mode() unconditionally writes CDC_WSA_COMPANDER1_CTL3 (0x5CC) and CDC_WSA_COMPANDER1_CTL7 (0x5DC). On v2.5+ silicon these registers moved to CDC_2_5_WSA_COMPANDER1_CTL3 (0x5EC) and CDC_2_5_WSA_COMPANDER1_CTL7 (0x5FC); the v2.1 addresses are dead on that hardware, so the update_bits() calls take a bus error: wsa_macro 6c90000.codec: ASoC error (-5): at snd_soc_component_update_bits() on 6c90000.codec for register: [0x000005dc] The flat regcache had been hiding the read side of this by returning the zero-initialised cache slot instead of doing a bus read, so the error only becomes visible once the cache reports the miss honestly and regmap falls back to a real bus read. Select the correct address for Compander1 CTL3/CTL7 based on codec_version. The Compander0 and Boost registers used in the same function have the same address across versions, so they stay unchanged. Also collapse the two mode branches to a single sequence with mode-selected values, which is what the switch was doing anyway. Fixes: 727de4fbc546 ("ASoC: codecs: lpass-wsa-macro: Correct support for newer v2.5 version") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260908082806.648797-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f4e42c4b50d1f41f88699120bd20c1d52fb4058d Author: Xu Rao Date: Tue Aug 11 19:28:40 2026 +0800 media: m2m-deinterlace: fix default capture field [ Upstream commit 4ee3ebede5d01efdcdd88c94f9df271d2eb237de ] queue_init() initializes default formats for both the source and capture queues. It first sets the source field to V4L2_FIELD_SEQ_TB, but then stores the capture default, V4L2_FIELD_INTERLACED_TB, in the source queue again while initializing the capture queue. This overwrites the valid source default and leaves the capture field at its zero-initialized value, V4L2_FIELD_ANY. vidioc_streamon() accepts only V4L2_FIELD_SEQ_TB or V4L2_FIELD_SEQ_BT on the source queue, and requires the capture queue to use a compatible interlaced or NONE field. Userspace that relies on the default formats can therefore get -EINVAL when starting streaming. Initialize the capture field instead. The bug is usually hidden because mem2mem applications commonly call S_FMT on both queues before streaming; the TRY_FMT paths normalize the fields and S_FMT overwrites q_data[].field. Fixes: 8f0755c06b90 ("[media] media: Add mem2mem deinterlacing driver") Cc: stable@vger.kernel.org Reviewed-by: Jacopo Mondi Signed-off-by: Xu Rao Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ba7c2b44be45817ee9f90cf1273c55e3135f1bcc Author: Punnay Sharma Date: Sat Aug 8 00:04:43 2026 +0530 staging: media: av7110: fix sp8870 initialization failure state [ Upstream commit 30684fa98394bc0eb4362282908612aab7d4dad9 ] The SP8870 DVB frontend driver prematurely flags the device as initialized at the very beginning of the sp8870_init() routine, prior to requesting the firmware (dvb-fe-sp8870.fw) and executing the I2C upload sequence. If request_firmware() times out or sp8870_firmware_upload() encounters an I2C bus error, the function aborts and returns -EIO. However, because `state->initialised` is already set to 1, all subsequent invocations of `fe->ops.init()` by the DVB core will immediately return 0 (success) without attempting to load the firmware again. This leaves the demodulator microcontroller halted and the frontend permanently dead until the module is forcibly reloaded. Relocate the `state->initialised = 1` assignment to the end of sp8870_init(), ensuring the flag is only set after the firmware is successfully uploaded and the system controller is actually restarted. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Punnay Sharma Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 8bf9a373504361b9645e76416dc654d3b61ace99 Author: Punnay Sharma Date: Sat Aug 8 00:04:42 2026 +0530 staging: media: av7110: fix corrupted BER reporting in sp8870 [ Upstream commit 5764f9bd7b7a72c6df49db6c8c00d4f9994a55ba ] In sp8870_read_ber(), the 14-bit Bit Error Rate (BER) is assembled by reading two I2C registers: 0xC08 (lower 6 bits) and 0xC07 (upper 8 bits). The current implementation masks the lower bits via `tmp = ret & 0x3F;` but subsequently overwrites `tmp` entirely when processing the upper bits using a direct assignment (`tmp = ret << 6;`). This logical error causes the lower 6 bits of the BER hardware metric to be silently discarded. Fix this by using a bitwise OR (`tmp |= ret << 6;`) to correctly merge the MSB and LSB payloads before returning the metric to the DVB core. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Punnay Sharma Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9906d20c5db4f17843cdeb5f2844321954fc76c3 Author: Julian Braha Date: Sat Aug 1 18:53:54 2026 +0100 media: marvell-cam: fix unmet dependency for VIDEO_MMP_CAMERA [ Upstream commit 1179929b3abd4adb6ca7fae91d649c64a7293aca ] VIDEO_MMP_CAMERA selects I2C_GPIO without ensuring 'GPIOLIB || COMPILE_TEST' is enabled, despite I2C_GPIO depending on it. Let's add the same dependency to VIDEO_MMP_CAMERA. This unmet dependency bug was found by kconfirm, a static analysis tool for Kconfig. Fixes: 67a8dbbc4e04 ("[media] marvell-cam: Basic working MMP camera driver") Cc: stable@vger.kernel.org Signed-off-by: Julian Braha Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 476a2d3c0e4fb456aa3581842e4397c44cfe2ad0 Author: Jeffin Philip Date: Thu Aug 27 09:52:29 2026 +0530 media: vidtv: fix uaf in vidtv_bridge_on_new_pkts_avail [ Upstream commit 2af02ccd048b77713695d7817cf645ca50bf349e ] Attempting to unbind a dvbdevice that is in the process of feeding data causes a UAF as we free the underlying device without stopping the feed first. Fix this by stopping the stream first using vidtv_stop_streaming(). However, our codepath in the reproducer (mentioned in the below reply) does not decrement our users (dmxdev->dvr_dvbdev->users) to 1 after it has been incremented to 2 by our read() in the reproducer, that is only possible on .release. This can cause a task hang as dvb_dmxdev_release() uses wait_event() in the wait_queue unless we use a close(fd)(in the reproducer). Is this a problem? Please advise. Reported-by: syzbot+c7fc4794e59786f5b4dc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c7fc4794e59786f5b4dc Fixes: f90cf6079bf6 ("media: vidtv: add a bridge driver") Cc: stable@vger.kernel.org Signed-off-by: Jeffin Philip Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 22797db3f9ca19e253cb2816a66fcbc9251464cb Author: Piyush Patle Date: Mon Aug 24 19:21:15 2026 +0530 media: vidtv: fix frontend reference leak on unbind [ Upstream commit 6f412f9fe6a1f3ce9694757f50353bbec221d832 ] dvb_register_frontend() keeps two references to the frontend. One is released by dvb_unregister_frontend(), and the other by dvb_frontend_detach(). vidtv only called dvb_unregister_frontend(), so the second reference was never released. As a result, __dvb_frontend_free() was never called, leaking the frontend private data and its struct dvb_device. The detach call was removed by commit 63101b756893 ("media: vidtv: fix driver unbind/remove") because it caused an OOPS. The demod .release callback freed vidtv_demod_state, and the I2C remove callbacks then accessed the freed state. That commit also removed those accesses from the I2C remove callbacks. Restore the detach call, but remove the demod .release callback. vidtv_demod_state is owned by the I2C client and is already freed by vidtv_demod_i2c_remove(), so the frontend detach path should not free it. Tested with kmemleak and KASAN over 10 bind/unbind cycles. The reported frontend and dvb_device leaks were present before the fix and were gone after it, with no KASAN reports. Reported-by: syzbot+32f018fd65e799f79ae0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=32f018fd65e799f79ae0 Fixes: 63101b756893 ("media: vidtv: fix driver unbind/remove") Cc: stable@vger.kernel.org Tested-by: syzbot+32f018fd65e799f79ae0@syzkaller.appspotmail.com Signed-off-by: Piyush Patle Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3ba760923c0846e3ea2ab811d19d2ca29bf5b118 Author: Junrui Luo Date: Sat Aug 15 22:56:38 2026 +0800 media: vicodec: make encoder CAPTURE dimensions read-only [ Upstream commit 2532e9d2f8ccb330a9c924b1ee34c5629240d352 ] Setting the encoder's compressed CAPTURE format to a smaller resolution than the raw OUTPUT format makes the encoder write past the end of the CAPTURE buffer. For a stateful encoder the CAPTURE width and height are not client-settable; Documentation/userspace-api/media/v4l/dev-encoder.rst specifies them as "ignored (read-only)" on VIDIOC_S_FMT. vicodec only implements half of that: vidioc_s_fmt_vid_out() derives the CAPTURE coded size and sizeimage from the OUTPUT format, but S_FMT on the CAPTURE queue overwrites them. The encoder then takes its geometry from the OUTPUT queue alone, and v4l2_fwht_encode() gets no destination length. Overwrite the requested width and height with the OUTPUT queue's coded dimensions in vidioc_try_fmt_vid_cap(), making them read-only as the interface requires. Fixes: efec9c815e5d ("media: vicodec: pass on enc output format to capture side") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1a5ec52bc663c10a975451eba090a6c51283c060 Author: Junrui Luo Date: Sat Aug 15 22:56:36 2026 +0800 media: vicodec: fix out-of-bounds write on under-rounded coded dimensions [ Upstream commit 0183746ebca4c478027e2261b904f844f1443b19 ] A capture format whose width or height is one more than a multiple of 16 makes the FWHT codec write one 8x8 block row, or column, past the end of the capture plane, and read the same block out of the reference frame for P-coded frames. vic_round_dim() is documented to round a frame dimension up so that both the luma and the chroma plane end up a multiple of 8, but it only rounds the chroma plane: round_up((dim) / (div), 8) * (div) For div == 2 the result is a multiple of 16 in every case but one: when dim % 16 == 1, dim / div is already a multiple of 8 and the macro returns dim - 1. encode_plane() and decode_plane() round the same dimension with round_up(dim, 8), which yields dim + 7 -- one block more than the coded dimension that sized the buffer. On a KASAN-enabled kernel, a 641x360 YUYV P-frame triggers: BUG: KASAN: slab-out-of-bounds in add_deltas+0x450/0xcc0 Read of size 1 at addr ffff888009070800 by task trigger_bin/70 Call Trace: add_deltas+0x450/0xcc0 decode_plane+0x1916/0x3390 fwht_decode_frame+0x173/0x620 v4l2_fwht_decode+0x751/0x1120 device_run+0x6bb/0x1850 Round the dimension itself up to a multiple of 8 * div. The rounding changes only for div == 2 and dim % 16 == 1, and MAX_WIDTH and MAX_HEIGHT are both multiples of 16, so the rounded value still fits the advertised limits. Fixes: 3b15f68e19c2 ("media: vicodec: Add support for resolution change event.") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9b113c0f905cac76c34d7a37132172939824a7e5 Author: Younho Choi Date: Tue May 26 21:22:05 2026 +0900 media: vim2m: keep transaction buffer count stable while streaming [ Upstream commit 50f5fed44d8e24081e8feed5154746fe193f11b8 ] V4L2_CID_TRANS_NUM_BUFS controls how many buffer pairs a vim2m mem2mem job processes before the job is completed. The driver stores the value in ctx->translen and device_work() uses it later to decide whether the current transaction should continue. Letting userspace change this control while streaming is active can make a queued job observe a different transaction length than the one it started with. That leaves the transaction state inconsistent with the buffers currently queued for the job. Grab the transaction buffer count control while either queue is streaming, and release it only after both queues have stopped streaming. The V4L2 control framework then rejects changes with -EBUSY while the value is in use, while still allowing userspace to configure the value before streaming starts. Keep the control handler alive until after v4l2_m2m_ctx_release(), since releasing the mem2mem context can call stop_streaming(), which now ungrabs the control. Fixes: 96d8eab5d0a1 ("V4L/DVB: [v5,2/2] v4l: Add a mem-to-mem videobuf framework test device") Cc: stable@vger.kernel.org Signed-off-by: Younho Choi Reviewed-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ebf9f25c8c425e1fd3039eeedf7a9b6cb6b519f3 Author: Runyu Xiao Date: Sun Aug 30 22:30:02 2026 +0800 media: saa7146: Initialize interrupt lock before requesting IRQ [ Upstream commit e07c75a6bc4adf1ed09ede31756261e2c6bdede5 ] The saa7146 interrupt handler can call SAA7146_IER_DISABLE(), which serializes register access with dev->int_slock. request_irq() allows the shared handler to run before saa7146_init_one() reaches the current lock initialization block. Initialize dev->int_slock before requesting the interrupt so every handler path sees an initialized lock. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 027740b8c75bc34710a624ffefbbcd3b18ab54a4 Author: Shengzhuo Wei Date: Thu Aug 27 22:59:10 2026 +0800 media: go7007: bound EZ-USB I2C transfers to the usb_buf size [ Upstream commit 816c4628b23e8c3d925978433f4dd1a13620c01b ] go7007_usb_i2c_master_xfer() copies msgs[i].len bytes into go->usb_buf, a 16-byte buffer embedded in struct go7007, without any length check. The adapter declares no transfer limits, so an SMBus block transfer issued through /dev/i2c-N can write up to 34 bytes into it and corrupt the struct fields that follow the buffer. Bound the transfer size with i2c_adapter_quirks so the I2C core rejects oversized messages before they reach the driver. Fixes: 7955f03d18d1 ("[media] go7007: move out of staging into drivers/media/usb.") Cc: stable@vger.kernel.org Signed-off-by: Shengzhuo Wei Assisted-by: GLM:5.3 Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 47bef8371a645f528e972d3def10c665c03fbfa1 Author: Linkai Gong Date: Tue Aug 25 10:26:16 2026 +0800 media: i2c: tc358743: add missing color-space strings [ Upstream commit cb37e83f1bbdf0964ed0a9524ce45a0694f98205 ] VI_STATUS3 S_V_COLOR is four bits, so the index after the shift is 0-15. input_color_space[] only has 14 entries. Add the two reserved values so log_status() cannot walk off the table. Fixes: d32d98642de6 ("[media] Driver for Toshiba TC358743 HDMI to CSI-2 bridge") Cc: stable@vger.kernel.org Signed-off-by: Linkai Gong Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e73a96db220877bb846845a0e27e271609430bde Author: Ruoyu Wang Date: Fri Aug 14 21:41:00 2026 +0800 media: au0828: Free URBs when starting DVB streaming fails [ Upstream commit b8dd133d96a40012f4b67fd48d8ddd7306a3e024 ] start_urb_transfer() stores each allocated URB in dev->urbs[], but sets urb_streaming only after all URBs have been submitted. If a later URB or transfer buffer allocation fails, earlier entries are left allocated. A submission failure calls stop_urb_transfer(), but that function returns immediately while urb_streaming is false, leaving both submitted and unsubmitted URBs behind. Make stop_urb_transfer() release every populated slot regardless of the streaming flag and clear each slot after release. Route all start errors through this cleanup. usb_kill_urb() safely handles both submitted and unsubmitted URBs, while the existing preallocation check preserves the lifetime of shared transfer buffers. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 265a6510629a ("V4L/DVB (7621): Add support for Hauppauge HVR950Q/HVR850/FusioHDTV7-USB") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2bcc2adaed82047d43a2f78b444b09aa9e9f1103 Author: Takashi Sakamoto Date: Tue Sep 8 21:28:40 2026 +0900 firewire: core: fix source bus ID detection for AT context in big-endian systems [ Upstream commit 6393d75914a6ac95a05621db8d9d6a98eafe72f7 ] The source bus ID bit in AT DMA context is not detected correctly on big-endian systems because the little-endian data is not converted to CPU endianness. Fix the bug. The helper functions related to this are never used in driver code, so extend the test to check the field instead. Cc: stable@vger.kernel.org # v6.12 Fixes: 8db9d1557122 ("firewire: ohci: add static inline functions to serialize/deserialize data of AT DMA") Link: https://lore.kernel.org/r/20260908122840.2886621-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Signed-off-by: Sasha Levin commit 5afa77304fc3bd98eb950a2efa6272a08c4d58f8 Author: Andi Shyti Date: Fri Aug 28 15:59:50 2026 +0200 media: cx231xx: Fix cleanup path on failure [ Upstream commit 6e30287eaf3e41b86dfb86df3b811526693d74b4 ] If cx231xx_init_v4l2() fails the probe currently jumps to err_init, which only unregisters the V4L2 device. The analog devices and I2C resources are left registered while the driver state can be released. A subsequent driver bind attempts to create the same I2C mux channel links and triggers a warning when the existing "channel-0" link is encountered. The remaining devices may also access released driver state. This produces the following warning can't create symlink to channel 0 WARNING: drivers/i2c/i2c-mux.c:403 at i2c_mux_add_adapter+0xcd8/0xeb0 Call Trace: i2c_mux_add_adapter+0xcdc/0xeb0 cx231xx_dev_init+0x2fb/0x1260 cx231xx_usb_probe+0xc48/0x2140 usb_probe_interface+0x657/0xc70 ... Jump to err_video_alt instead, which performs the full device cleanup before unregistering the V4L2 device. Reported-by: Farhad Alemi Closes: https://github.com/farhad-alemi/public_bug_reports/tree/main/185-warning-in-i2c-mux-add-adapter/ Fixes: 4d2a7d3509f5 ("[media] cx231xx: move analog init code to a separate function") Signed-off-by: Andi Shyti Cc: # v3.17+ Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3cd008aa8391ba1d788035d6e33f092d15f95dfa Author: Fan Wu Date: Wed Jul 29 07:26:13 2026 +0000 media: cx231xx-audio: drain wq_trigger before audio fini [ Upstream commit a691c54986412e1fa87f036d2577d5a78a75e658 ] audio_trigger() is deferred work (dev->wq_trigger) armed from snd_cx231xx_capture_trigger() on every PCM START/STOP; it dereferences dev->adev state and may free the URBs via cx231xx_isoc_audio_deinit(). cx231xx_audio_fini() tore down that state without draining wq_trigger, so work armed before or racing fini ran against freed state. Use disable_work_sync() in fini to drain the work and prevent further queueing. Initialize the work, lock and stream_started counter at the top of cx231xx_audio_init(), before any fallible allocation, and clear the partially-built audio state on its error path, so fini is safe even if a later step fails. This issue was found by an in-house static analysis tool. Fixes: 61b04cb24a12 ("[media] cx231xx-audio: fix some locking issues") Cc: stable@vger.kernel.org # v6.10+ Link: https://lore.kernel.org/r/8c7e1294-b906-4636-890c-b64d03b0e1d0@kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit edacfe07e5acaf83ef046f32a77444e9c7efb6e6 Author: Andrea Pesaresi Date: Sat Aug 29 17:19:55 2026 +0200 arm64: dts: mediatek: mt7986: correct timer frequency [ Upstream commit 1cf18e4b9815beaf0439c5b57b65b45151c82ad7 ] The MT7986 architected timer runs at 12,986,200 Hz rather than 13 MHz. Firmware reports 13 MHz through CNTFRQ_EL0, causing the system clock to run slow by about 1062 ppm. This exceeds the kernel's 500 ppm NTP correction limit and leaves clock discipline saturated. The corrected rate comes from MediaTek's downstream OpenWrt feed, where it is applied to both MT7986A and MT7986B. Since upstream mt7986b.dtsi includes mt7986a.dtsi, add it once to the common timer node so the architected timer driver uses the actual counter rate. Fixes: 50137c150f5f ("arm64: dts: mediatek: add basic mt7986 support") Cc: stable@vger.kernel.org Link: https://github.com/mediatek/mtk-openwrt-feeds/commit/6a4c41c41410cd5042ad10c39da6593ba036283c Link: https://github.com/openwrt/openwrt/issues/24789 Signed-off-by: Andrea Pesaresi Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 71e5b557d50b04f669f86896559cce29ce4e2e08 Author: Baolin Liu Date: Mon Sep 7 16:26:02 2026 +0800 isofs: fix Rock Ridge CE extent validation on multisession media [ Upstream commit 43de050fa4a31f7e7a73cf8974dcf6037e161a39 ] Commit a36d990f5913 ("isofs: validate Rock Ridge CE continuation extent against volume size") compares the CE extent directly with s_nzones. The extent is an absolute block number, while s_nzones is the number of blocks relative to the selected ISO session. The comparison is therefore wrong when a multisession disc starts at a non-zero block. isofs_get_last_session() selects the last session on multisession media, and its volume descriptors describe a volume beginning at that session's LBA. For example, a session beginning at LBA 45447 with 64 blocks can contain a valid CE at absolute LBA 45467. The existing check rejects that CE, so the ER continuation record is not read, Rock Ridge is disabled, and the mount falls back to Joliet names. Save the selected session start in filesystem-block units and validate the CE extent against the half-open interval [session_start, session_end). Scale the session length to the same block units and retain a separate block-device limit. The lower bound is intentional: accepting arbitrary blocks before the selected session could make a CE read data from a previous session or another filesystem on the device. Only apply the bounds check when cont_extent is non-zero. A zero extent is the in-memory sentinel indicating that no CE continuation was found, rather than a request to read block zero. For a single-session image, session_start is zero and the effective volume boundary remains unchanged. Build-tested with: make CONFIG_RUST= CONFIG_RUST_DRIVERS= fs/isofs/ Fixes: a36d990f5913 ("isofs: validate Rock Ridge CE continuation extent against volume size") Cc: stable@vger.kernel.org Signed-off-by: Baolin Liu Link: https://patch.msgid.link/20260907082602.3777551-1-liubaolin12138@163.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 04a3774bfa9335fccfee0e95e20bb89e01fb7e30 Author: Thorsten Blum Date: Wed Aug 26 17:31:43 2026 +0200 thermal: intel: int340x: Fix temperature selection around 0 C [ Upstream commit e56e2b49c67d132728e52ce493079e83cc914657 ] Since commit 7251b9e8a007 ("thermal/intel: Fix intel_tcc_get_temp() to support negative CPU temperature"), intel_tcc_get_temp() can report negative temperatures. proc_thermal_get_zone_temp() still uses *temp as the current maximum and as an implicit "no reading yet" marker. However, this breaks when a CPU reports 0 C, because a subsequent negative reading can overwrite it. Use bool temp_valid to track whether a valid temperature has been read. Initialize *temp with the first valid reading and only update it with warmer readings. Fixes: 7251b9e8a007 ("thermal/intel: Fix intel_tcc_get_temp() to support negative CPU temperature") Cc: 6.3+ # 6.3+ Signed-off-by: Thorsten Blum Acked-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260826153144.299746-3-blum@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6675b728d5065a56a885b46d1385ca5fb2ea5994 Author: Thorsten Blum Date: Sat Aug 15 11:01:34 2026 +0200 thermal: intel: powerclamp: Reject invalid window_size values [ Upstream commit 40989202104e498ff9adfb8c575d6cd159f13988 ] window_size_set() sets ret to -EINVAL if new_window_size is outside the valid range, but then falls through and still updates window_size to the clamped value. Return -EINVAL immediately and do not update window_size. Also drop the now-redundant clamp() call. Fixes: d6d71ee4a14a ("PM: Introduce Intel PowerClamp Driver") Cc: All applicable Signed-off-by: Thorsten Blum Link: https://patch.msgid.link/20260815090136.88540-2-thorsten.blum@linux.dev Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 9f2a2f5386a498190f063d7ededb0da2704c8415 Author: Francesco Dolcini Date: Thu Aug 13 13:12:36 2026 +0200 arm64: dts: ti: k3-am62-verdin: Set MMC clock pins as OUTPUT [ Upstream commit 0ddd661c19ec1465e1f2c204fa9b2488acfabf4b ] MMC clock pins must be configured as OUTPUT-only per TRM [0] with receiver disabled (RXACTIVE bit = 0). Change MMC CLK pins from PIN_INPUT to PIN_OUTPUT to match documentation. Link: https://www.ti.com/lit/pdf/spruiv7 Rev. C: Table 12-246. MMCSDi I/O Signals [0] Fixes: 316b80246b16 ("arm64: dts: ti: add verdin am62") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini Reviewed-by: Judith Mendez Link: https://patch.msgid.link/20260813111238.56892-1-francesco@dolcini.it Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 288194ff49e8e98b4369e73a40c1eb9aeb8fc2e1 Author: Amir Goldstein Date: Wed Sep 2 18:49:25 2026 +0200 fs: make sure to call fsnotify_inoderemove() only once when inode is dead [ Upstream commit 669bb5af15d41a21359d00a441490f87a88eb52a ] Daehyeon reported a race wherein fsnotify_removeinode() can be called when inode still has a live alias. This can lead to several undesired outcomes such as crashes in fsnotify code or avoidance of inode mark notifications. Check that inode is really "dead", meaning no nlink and no more aliases before calling fsnotify_inoderemove() for final cleanup of inode marks. Also do not allow open_by_handle() to add new aliases to a "dead" inode. Ideally, we'd call fsnotify_inoderemove() once last inode reference is dropped to make things simpler. Alas fsnotify inode marks currently hold inode references and thus this doesn't work. Once we teach fsnotify to avoid holding inode references, these games with dead inodes can go as well. Reported-and-tested-by: Daehyeon Ko <4ncienth@gmail.com> Closes: https://lore.kernel.org/linux-fsdevel/20260827045007.3831259-1-4ncienth@gmail.com/ CC: stable@vger.kernel.org Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Link: https://patch.msgid.link/20260902164924.1333135-2-jack@suse.cz Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 70aebfa9623b9849cad94432b154cd00426486b0 Author: Karl Mehltretter Date: Thu Sep 3 02:21:00 2026 +0200 fs_pin: publish pins with RCU list helpers [ Upstream commit 8d01d6b4c17c406f37a9b6edac93dfb858af30d0 ] pin_insert() initializes a pin before adding it under pin_lock. The kill paths read the list heads under RCU without taking that lock. Plain hlist insertion does not publish the earlier initialization to those readers. KCSAN weak-memory checking reported acct_on() callback initialization racing with pin_kill() after the superblock-list publication. The corresponding LKMM model permits the stale read with plain publication; the RCU release/acquire pair forbids it. Use the RCU hlist add and dereference helpers for both pin lists. Fixes: 2798d4ce6160 ("acct: get rid of acct_lock for acct->count") Cc: stable@vger.kernel.org Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260903002100.34822-1-kmehltretter@gmail.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 500aa6b08f722c440975b2c291a15c93c664d47b Author: Miquel Raynal Date: Tue Aug 11 17:56:23 2026 +0200 mtd: spi-nor: Unprepare legacy controllers upon RWW wait interruption [ Upstream commit f594a33f9721f08facd98d0a31adc14ff6da9d70 ] All the parallel locking helpers (spi_nor_prep_and_lock(), spi_nor_prep_and_lock_pe() and spi_nor_prep_and_lock_rd()) call spi_nor_prep() then wait with a killable sleep. If the sleep gets killed, we leave the controller in its prepared state. Call ->unprepare() in these cases. Fixes: 74df43b3f626 ("mtd: spi-nor: Enhance locking to support reads while writes") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Reviewed-by: Michael Walle Acked-by: Tudor Ambarus Signed-off-by: Michael Walle Signed-off-by: Sasha Levin commit 2d03759ef4ad9c7294bb6f0b49eff71d6958e833 Author: HyeongJun An Date: Mon Jul 20 23:11:04 2026 +0900 mtd: spi-nor: sfdp: check the length of the SCCR map [ Upstream commit 1413f38f37194673502e61cd3749e091c031370b ] The spi_nor_parse_sccr() sizes its buffer from the table length the flash reports in the SFDP parameter header. But it then reads DWORD1 and DWORD22 without ever checking the table is that long. So if a flash reports a length of one, the buffer is only four bytes while DWORD22 sits at byte offset 84. With a length of zero kmalloc() returns ZERO_SIZE_PTR rather than an error, so the NULL check doesn't catch it and the first read dereferences it. To fix this, reject a table that's too short for the highest DWORD the parser reads, the way spi_nor_parse_4bait() already does. The table is optional, so this isn't fatal. The spi_nor_parse_sfdp() warns and carries on. The spi_nor_parse_sccr_mc() doesn't need the same check. It works out the number of dice from the length it allocated with, so its highest index stays inside the buffer. Fixes: 7ab8b810757a ("mtd: spi-nor: sfdp: Add support for SCCR map for multi-chip device") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Signed-off-by: Michael Walle Signed-off-by: Sasha Levin commit 8cc513aa794d25cd6cf4dfe054eba600d4f813a5 Author: HyeongJun An Date: Mon Jul 20 23:11:03 2026 +0900 mtd: spi-nor: sfdp: check the length of the xSPI Profile 1.0 table [ Upstream commit b9f34a95a81021fa1f3c9cb8cfd458e66824cad6 ] The spi_nor_parse_profile1() sizes its buffer from the table length the flash reports in the SFDP parameter header. But it then reads DWORD1, DWORD4 and DWORD5 without ever checking the table is that long. So if a flash reports a length of one, the buffer is only four bytes while DWORD4 and DWORD5 sit at byte offsets 12 and 16. With a length of zero kmalloc() returns ZERO_SIZE_PTR rather than an error, so the NULL check doesn't catch it and the first read dereferences it. And the value doesn't just get thrown away. It ends up as the dummy cycle count for 8D-8D-8D fast reads. To fix this, reject a table that's too short for the highest DWORD the parser reads, the way spi_nor_parse_4bait() already does. The table is optional, so this isn't fatal. The spi_nor_parse_sfdp() warns and carries on. Fixes: fb27f198971a ("mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Signed-off-by: Michael Walle Signed-off-by: Sasha Levin commit 97fe6395873a9da20baee4d03ab19aacf7bad142 Author: Serin Yeh Date: Thu Aug 6 14:18:19 2026 +0800 media: i2c: ov8856: fix debug message to report actual CSI-2 lane count [ Upstream commit a15976e69b1c70ea16ef1f7172a846f6ef5dfa14 ] The driver currently prints the number of data lanes using ov8856->cur_mode->data_lanes in ov8856_get_hwcfg(). However, the ov8856->cur_mode structure is not assigned to a clearly supported mode at that point. Due to the missing pointer, enabling dynamic debug may lead to a kernel panic. Instead, the correct number of CSI-2 data lanes should be taken from bus_cfg.bus.mipi_csi2.num_data_lanes, which represents the real hardware configuration determined at runtime. Fixes: c492ec9ae9ed ("media: ov8856: Add support for 2 data lanes") Cc: stable@vger.kernel.org Signed-off-by: Serin Yeh Reviewed-by: Kieran Bingham Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 2025b47b79c478e1207b3b23329415877754ac29 Author: Abdun Nihaal Date: Sat Aug 1 17:19:09 2026 +0530 wifi: ath11k: Fix possible memory leak in ath11k_dp_srng_setup() [ Upstream commit 6132d70d0890c03546f6970893fd71938efb2a2f ] In ath11k_dp_srng_setup(), the memory allocated for ring->vaddr_unaligned is not freed in the error paths that follow. Fix that by calling ath11k_dp_srng_cleanup() in those error paths. Compile tested only. Issue found using a prototype static analysis tool built on the LLVM compiler infrastructure. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Baochen Qiang Signed-off-by: Abdun Nihaal Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260801114911.91483-1-nihaal@cse.iitm.ac.in Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 78043101fd8939609f0498e222b1aaf6e27452f6 Author: Runyu Xiao Date: Mon Aug 31 00:17:47 2026 +0800 hte: tegra194: Initialize slice locks before registering chip [ Upstream commit 1329abe1bae416ab2cff89c3312d33f745d341c7 ] Registering the HTE chip publishes its request callbacks to consumers. Initialize every slice lock before registration so a concurrent HTE request cannot use an uninitialized lock. Signed-off-by: Runyu Xiao Fixes: 09574cca6ad6 ("hte: Add Tegra194 HTE kernel provider") Cc: stable@vger.kernel.org Acked-by: Dipen Patel Signed-off-by: Dipen Patel Signed-off-by: Sasha Levin commit 0fccaaaf42f354fd5d2b1cc614eeb3c65d3a00b4 Author: Yuan Chen Date: Mon Aug 31 14:32:25 2026 +0800 bpf: Fix queue/stack map u32 index overflow [ Upstream commit 802a30c5db726639df7f93b3a1982ecc64202abe ] The queue/stack map addresses elements[] with the product of a u32 head/tail index and value_size, but the storage itself is allocated in 64-bit arithmetic. When max_entries * value_size reaches or exceeds U32_MAX, the product wraps and push/peek/pop operate on the wrong element, corrupting map data and leaking stale values to user space. max_entries == U32_MAX would also make the u32 capacity counter qs->size (max_entries + 1) wrap to 0 and permanently break the map. The original bound check was removed by commit a37fb7ef24a4 ("bpf: Eliminate rlimit-based memory accounting for queue_stack_maps maps"), which deleted the bpf_map_charge_init() call and with it the U32_MAX - PAGE_SIZE check that had earlier been moved into bpf_map_charge_init() by c85d69135a91. Oversized queue/stack maps can therefore be created again. Restore the bound in queue_stack_map_alloc_check() with a single comparison that rejects any max_entries/value_size combination whose element storage would reach or exceed U32_MAX bytes, keeping the u32 index multiplication overflow-free and the capacity counter valid. Fixes: a37fb7ef24a4 ("bpf: Eliminate rlimit-based memory accounting for queue_stack_maps maps") Signed-off-by: Yuan Chen Signed-off-by: Andrii Nakryiko Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260831063226.621309-2-chenyuan_fl@163.com Signed-off-by: Sasha Levin commit 4352760accafc4767928e7292b1c90e0a0aedecb Author: hanzhijian Date: Mon Aug 24 22:28:00 2026 +0800 clk: mstar: msc313-mpll: fix off-by-one in clock array allocation [ Upstream commit 712b75152c00a8ab0c56dbfe34caf88e3870ddde ] The hws array of mpll->clk_data is allocated with struct_size() using ARRAY_SIZE(output_dividers) as the element count, giving it 7 elements. But the probe function stores the MPLL clock at hws[0] and one fixed-factor clock for each output divider at hws[i + 1] for i in [0, ARRAY_SIZE(output_dividers)), writing 8 elements in total. The final write to hws[7] is past the end of the allocation. clk_data->num is also set to NUMOUTPUTS (8), so the clock framework reads hws[0..7], again accessing hws[7] out of bounds. Use NUMOUTPUTS as the element count so the allocation matches the number of clocks actually stored and exposed. Found by smatch: drivers/clk/mstar/clk-msc313-mpll.c:134 msc313_mpll_probe() error: buffer overflow 'mpll->clk_data->hws' 7 <= 7 Fixes: bef7a78da716 ("clk: mstar: MStar/SigmaStar MPLL driver") Cc: stable@vger.kernel.org Signed-off-by: hanzhijian Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit cad4a546a721558aedb9811208f281face221c8e Author: Laxman Acharya Padhya Date: Tue Aug 25 23:29:38 2026 +0545 wifi: rtw89: cap firmware section_num before parsing [ Upstream commit 273b0a8be083df6d0319ce62caa870e927f94a31 ] rtw89_fw_bin_info.section_info has FWDL_SECTION_MAX_NUM (10) entries. The v0/v1 header parsers take section_num from an 8-bit firmware field (0..255) and write info->section_info[i] with no cap. rtw89_fw_download_suit() keeps that object on the stack, so a crafted firmware blob overflows the stack. Reject a truncated header and a section table that does not fit in the firmware image before reading fw_hdr->sections[i]. Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Cc: stable@vger.kernel.org Acked-by: Ping-Ke Shih Signed-off-by: Laxman Acharya Padhya Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260825174438.63168-1-acharyalaxman8848@gmail.com Signed-off-by: Sasha Levin commit c9146a2b1bdf9db89c621bc96c247f7de9e20f9a Author: Yi Cong Date: Fri Aug 7 16:10:06 2026 +0800 wifi: rtw89: 8851b: fix swapped DPK channel/bandwidth backup fields [ Upstream commit 7e080e17ca38b72f6cf01e3bc750c243573e69a7 ] The .ch and .bw backup fields are swapped; .ch should store the channel and .bw the bandwidth, matching all other chips. Fixes: 0194a95cbe721a ("wifi: rtw89: 8851b: rfk: add DPK") Cc: stable@vger.kernel.org Signed-off-by: Yi Cong Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260807081006.240450-1-cong.yi@linux.dev Signed-off-by: Sasha Levin commit 46ff3bfce058bc0d0ac54b1338582ea7985fdd4f Author: イムティヤズ Date: Thu Aug 6 03:09:41 2026 +0600 wifi: rtw88: fix out-of-bounds CAM write when key table is full [ Upstream commit 10d58823cb44681466c022054030b8e68d94ce2f ] In rtw_ops_set_key(), when the CAM table is full, rtw_sec_get_free_cam() returns RTW_MAX_SEC_CAM_NUM (32) because find_next_zero_bit()/find_first_zero_bit() return the bitmap size when no free slot exists. The bounds check compares the returned index with ">" against total_cam_num (32), so the invalid index 32 passes the check. rtw_sec_write_cam() then indexes cam_table[32], an array declared with RTW_MAX_SEC_CAM_NUM (32) entries, causing an out-of-bounds write that corrupts the cam_map allocation bitmap. The write also sets bit 32 of cam_map, which overruns the bitmap as well. Fix the off-by-one by rejecting indices >= total_cam_num. Tested on: RTL8821CE (PCIe) on kernel 7.2.0-rc6-rtw88test-00059-g0d8395707651. The patched module loaded and associated to a WPA2 network; ping traffic passed with 0% packet loss. Reassociation and disconnect/reconnect cycles completed without errors, and the CAM table (debugfs dump_cam) showed valid key entries. The CAM-full boundary (28+ pairwise keys) requires an access point with 28+ clients and is not reachable in a single-client setup, so that path was verified by code inspection. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Cc: stable@vger.kernel.org Tested-by: イムティヤズ Signed-off-by: イムティヤズ Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260805210941.75136-1-reza1234khan1234@gmail.com Signed-off-by: Sasha Levin commit 374b7f2075a527123420d241323054cc50defc1d Author: Justin Chen Date: Wed Aug 26 13:14:59 2026 -0700 memory: brcmstb_dpfe: Bounds check DCPU-supplied MSG_ARG_COUNT [ Upstream commit 6b07f8c06caca015a0db69e3f323b5186469bc66 ] A compromised or buggy DCPU coprocessor can make any user who reads world-readable /sys/devices/.../dpfe_info|dpfe_dram trigger a kernel stack out-of-bounds read of arbitrary extent. This bounds checks chksum_idx against MSG_FIELD_MAX after reading the response from DCPU message RAM. Fixes: 5d06f53d9509 ("memory: brcmstb: dpfe: Compute checksum at __send_command() time") Cc: stable@vger.kernel.org Signed-off-by: Justin Chen Assisted-by: Gemini:gemini-3.1-pro-preview cursor Signed-off-by: Danesh Petigara Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260826201500.3000125-3-danesh.petigara@broadcom.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 1e5d89f835d55e59e2fcfb7e2407d74bc3983695 Author: Justin Chen Date: Wed Aug 26 13:14:58 2026 -0700 memory: brcmstb_dpfe: Fix out-of-bounds access due to DCPU offset [ Upstream commit 7c0b82d087908765c6c7daeb06943e21b78d523e ] On API v1/v2 boards, the DCPU coprocessor can steer kernel readl_relaxed() and writel_relaxed() to any address within 256 MB of the ioremapped DPFE dmem or regs base. The DCPU firmware provides a 28-bit offset which the driver adds to the ioremap base without any bounds checking in get_msg_ptr(). This allows a compromised DCPU firmware to trick the host kernel into reading or writing arbitrary memory-mapped I/O registers in vmalloc space. When combined with a root-writable sysfs file like dpfe_refresh, it provides an arbitrary MMIO write primitive. Similarly, world-readable sysfs files can be used to leak other devices' register contents. Fix this by recording the resource_size() of the dmem and regs ioremaps at probe time, and rejecting any offset that, along with the largest field accessed (DRAM_VENDOR_ERROR + sizeof(u32)), exceeds the recorded mapping size. Fixes: fee5f1ef6cf7 ("memory: brcmstb: dpfe: support new way of passing data from the DCPU") Cc: stable@vger.kernel.org Signed-off-by: Justin Chen Assisted-by: Gemini:gemini-3.1-pro-preview cursor Signed-off-by: Danesh Petigara Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260826201500.3000125-2-danesh.petigara@broadcom.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit d73722aafce9ac78731f96e2d7865f126797b5eb Author: Sam Price Date: Fri Aug 21 17:18:09 2026 +0200 microblaze: preserve the MSR carry flags across signals [ Upstream commit ca35dd21a5f8343f47a23e4e5b3f0ffccf76a4ae ] setup_sigcontext() and restore_sigcontext() copy r0-r31, pc, ear, esr and fsr to and from the signal frame but never touch MSR. The interrupted MSR is therefore dropped from the signal context entirely: the handler's ucontext does not expose it, a handler cannot adjust the resumed arithmetic flags through uc_mcontext.regs.msr, and -- because restore_sigcontext() leaves regs->msr as whatever the rt_sigreturn trap left in it -- the interrupted context resumes with the carry produced by the syscall entry path (_user_exception does "addi r14, r14, 4", which writes carry), not with its own. Other architectures round-trip the user-visible flags through the signal frame (arm's cpsr, csky's carry, x86's eflags), so a handler can both read and adjust the resumed flags; purely privileged status registers such as riscv's sstatus are left out. MicroBlaze should do the same for the user-writable bits. Concretely, MSR[C] (carry) is lost across signal delivery. Code that keeps a live carry across a point where a signal can be delivered -- for example an lwx/swx compare-and-swap retry loop, between the swx and the carry test -- resumes with the handler's carry and mis-evaluates the result; the same failure class as the rt_sigreturn r3/r4 clobber, reached through a different register. Demonstrated under qemu-system-microblazeel (machine petalogix-s3adsp1800): a handler that sets MSR_C in uc_mcontext.regs.msr has no effect before this change (0 of 132 in-window signals propagated) and takes effect after (130 of 132). Save MSR in setup_sigcontext() so the handler's ucontext exposes it. The signal frame is user-writable, so restore_sigcontext() must not restore it verbatim: MicroBlaze packs the user-writable carry (MSR_C, MSR_CC) and the privileged control bits (MSR_UM, MSR_VM, MSR_IE, MSR_EE, ...) into the one register, and a verbatim restore would let userspace alter privileged return state -- rtbd derives the resumed mode from MSR_UMS/MSR_VMS. Restore only MSR_C | MSR_CC from the frame and keep the rest from the current regs->msr. This mirrors x86's restore_sigcontext(), which masks the restored EFLAGS to FIX_EFLAGS for the same reason; arches whose status register is purely privileged (e.g. riscv sstatus) simply do not restore it at all. Comment on the exposed MSR reworded: it is not read-only, restore_sigcontext() applies MSR_C|MSR_CC from the frame. Author's Signed-off-by kept; he agreed to comment and changelog cleanups. Fixes: 2148daa9c45f ("microblaze_v8: Signal support") Cc: stable@vger.kernel.org Signed-off-by: Sam Price Signed-off-by: Ramin Moussavi Tested-by: Waldemar Brodkorb Link: https://patch.msgid.link/20260821151809.1233057-6-ramin.moussavi@yacoub.de Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit 5545d027ffa2aa99fb6dfefb5c5ccef8e5cc0826 Author: Ramin Moussavi Date: Fri Aug 21 17:18:07 2026 +0200 microblaze: don't clobber r3/r4 restored by rt_sigreturn [ Upstream commit da6829138a39fa3b9ec318ca54ff89af9d94d350 ] ret_from_trap begins by storing the system call return values r3 and r4 back into the saved user pt_regs. That is right for an ordinary system call, but sys_rt_sigreturn() returns through the same path and has to be transparent: restore_sigcontext() has just filled pt_regs from the signal frame, and every register must reach userspace exactly as saved. The two stores overwrite the restored r3/r4 with whatever the C function left in those registers. Only r4 is actually lost, and that follows from how sigreturn is written everywhere rather than from chance. Architectures have sys_rt_sigreturn() return the restored return-value register precisely so that this writeback stores the restored value -- arm returns regs->ARM_r0, riscv and csky regs->a0, arc regs->r0 -- and microblaze does the same through *rval_p = regs->r3 in restore_sigcontext(). But the entry macros treat r3 and r4 as a pair, so ret_from_trap writes back two registers while a C function has only one return value; nothing carries the restored r4. Commit 791d0a169b91 ("microblaze: Fix sys_rt_sigreturn_wrapper") introduced this in v2.6.37. The old wrapper saved r3/r4 before the call and reloaded them from pt_regs afterwards; switching brlid to brid removed the only point where they were reloaded, and the stores have been overwriting them ever since. Fix it the way the sibling paths already behave: ret_from_irq and ret_from_exc restore the full register set and do not perform these stores at all. Label the instruction after the stores ret_from_trap_no_rval and enter there, biasing r15 by -8 so that the ABI return "rtsd r15, 8" lands on it; naming the entry rather than computing ret_from_trap + 8 keeps it correct if the number of stores ever changes. Restoring the old save/reload would work too, but costs four memory accesses and a branch to undo damage that is better not done. Any value the compiler keeps in r4 across a signal is lost. The tightest windows are the lwx/swx compare-and-swap retry loops gcc emits for atomics: in uClibc-ng's libc.so alone, 50 of 364 such loops hold the address in r4. This is not specific to one libc -- musl passes the address as "r"(p), and glibc has no microblaze atomic-machine.h and so uses gcc's __atomic builtins, which expand the same way. Triggering it needs threads plus a signal storm, which is why it survived 15 years. Reproduced on qemu-system-microblazeel (petalogix-s3adsp1800) by running the uClibc-ng NPTL test tst-eintr1 40 times against an unchanged userspace: on v7.2 built with gcc 16.2.0, 23 of 40 iterations died with SIGSEGV without this patch and 0 of 40 with it; on v7.0 built with gcc 12.5.0 the same comparison gave 6 of 40 against 0 of 40. The register dump of a failing iteration shows the signature: a zero r4 and a fault at address 0, while r3 came back intact. Fixes: 791d0a169b91 ("microblaze: Fix sys_rt_sigreturn_wrapper") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Ramin Moussavi Tested-by: Waldemar Brodkorb Link: https://patch.msgid.link/20260821151809.1233057-4-ramin.moussavi@yacoub.de Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit 7c71462153f57957d75d429e1905b5f0ead6cd13 Author: Ramin Moussavi Date: Fri Aug 21 17:18:06 2026 +0200 microblaze: reserve the ABI argument-home area in the signal frame [ Upstream commit c5947d28c20955de897eeb98430f96db0494f7d7 ] The MicroBlaze procedure call standard reserves [r1+0] for the return address and lets a callee store its incoming register arguments r5..r10 into the caller-provided home slots at [r1+4]..[r1+24]. When the kernel enters a signal handler it sets r1 to point at struct rt_sigframe, whose leading member is the siginfo prepared for the handler. A handler that homes its arguments - which an unoptimised (-O0) build always does - therefore overwrites the first 24 bytes of that siginfo, so an SA_SIGINFO handler reads corrupted values. The stores stay within siginfo (128 bytes) and do not reach the ucontext behind it. Reserve the home area by making a seven-word gap -- the return-address slot plus the six argument slots, 28 bytes -- the first member of struct rt_sigframe, so the handler's argument stores land in scratch space instead of clobbering siginfo. Tested on qemu-system-microblazeel (petalogix-s3adsp1800) with the uClibc-ng NPTL test suite: tst-timer4, tst-timer5, tst-mqueue5 and tst-signal6 pass; before this change they failed because the handler clobbered the signal frame. Fixes: 2148daa9c45f ("microblaze_v8: Signal support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Ramin Moussavi Tested-by: Waldemar Brodkorb Link: https://patch.msgid.link/20260821151809.1233057-3-ramin.moussavi@yacoub.de Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit a0ecbf24755257f11c961e7b64140d5e4f9a257c Author: HyeongJun An Date: Fri Jul 24 11:53:22 2026 +0900 remoteproc: elf_loader: Bound the section header table [ Upstream commit b32177ead5f8925aa66ceed2bd533a85196f4f0c ] The rproc_elf_sanity_check() only checks the image is big enough to hold one section header. But find_table() walks e_shnum of them, and first dereferences the header at e_shstrndx to locate the section name table. Both fields are u16 and both come from the image, so an e_shstrndx of 65535 reads about 4 MB past the buffer. The commit 9f9967fed9d0 ("soc: qcom: mdt_loader: Ensure we don't read past the ELF header") added the same check to the MDT loader, and says the header "is sanitized beforehand" under remoteproc. That is what this patch makes true. Check e_shoff against the image size first, so the two bounds can use size_add() without an e_shoff above SIZE_MAX wrapping on 32-bit. The bounds are separate because e_shnum may be zero while find_table() still reads the e_shstrndx header. Fixes: 400e64df6b23 ("remoteproc: add framework for controlling remote processors") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Link: https://lore.kernel.org/r/20260724025322.2341205-1-sammiee5311@gmail.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 7fbc41dd8a3aaf620829f5875c9693e0ee905306 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Mon Aug 24 13:23:59 2026 +0900 ipc/mqueue: release notification resources during inode eviction [ Upstream commit eb85469f0dd69ca145d63117450e14c31f67f698 ] mqueue_flush_file() removes an mq_notify() registration only when the closing task belongs to the thread group stored in notify_owner. A task in a separate thread group created with CLONE_FILES can register SIGEV_THREAD notification and exit without closing the shared file table. If another thread group then unlinks and last-closes the queue, ->flush() skips the registration and inode eviction loses the only pointers to its resources. The orphaned registration permanently retains the notification skb, its netlink socket, a pid reference and a user namespace reference. An unprivileged process can repeat the sequence with new queues and sockets. No inode users remain during eviction. Remove any stale registration there after dropping info->lock, since netlink_sendskb() may release the final socket reference. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Link: https://patch.msgid.link/20260824042359.925145-1-4ncienth@gmail.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 17dd102dcaab51ea9323ede174978ab6fe4a62eb Author: Daehyeon Ko <4ncienth@gmail.com> Date: Thu Aug 13 22:38:43 2026 +0900 aio: prevent eventfd/epoll recursion on poll [ Upstream commit 398e3fa789aa5ffddc8689d8cbc7b31e1824130c ] aio_poll_wake() can complete a keyed poll request inline while the provider waitqueue lock is held. If the polled file is an epoll instance and the AIO result eventfd is watched by that same instance, signaling the result can feed back into epoll and try to take the provider waitqueue lock again. For example, a timerfd wake can follow this path: timerfd -> ep_poll_callback -> aio_poll_wake -> aio_complete -> eventfd_signal -> ep_poll_callback -> ep_poll_safewake The second ep_poll_safewake() recursively acquires ep->poll_wait.lock. eventfd_signal_allowed() does not prevent this because the wake chain did not begin in eventfd, so the task's eventfd recursion bit is still clear when aio_poll_wake() decides to complete inline. An unprivileged process can construct this graph and make a CPU spin on the recursive lock. DEBUG_SPINLOCK reports "BUG: spinlock recursion", and lockdep reports the same epoll waitqueue lock as both held and requested. Always defer eventfd-backed poll completions through the existing aio_poll_put_work() path. At this point the request has already been detached from the waitqueue and active request list, so the work item can publish the completion after the provider callback releases its lock. Poll completions without a result eventfd remain inline. Fixes: e8693bcfa0b4 ("aio: allow direct aio poll comletions for keyed wakeups") Cc: stable@vger.kernel.org Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Link: https://patch.msgid.link/20260813133843.2933127-1-4ncienth@gmail.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 76d8f3338e12e85d7f0dc8a2e5e0761e69b401dd Author: Jan Kara Date: Mon Aug 31 11:17:14 2026 +0200 udf: Make sure there's enough space for LVID implementation use field [ Upstream commit a61fb39759d719a4f4966742b4d28387e33d81c4 ] udf_lvid_valid() verifies that the LVID has enough space for all the tables and the reported length of ImplementationUse field. However it doesn't make sure the reported length is large enough to contain logicalVolIntegrityDescImpUse structure which OSTA specification requires. This can thus lead to accesses beyond the end of LVID buffer for suitably corrupted UDF filesystem. Add the length check. Reported-by: Yunpeng Tian Reported-by: Gongming Wang Reported-by: Mingda Zhang Reported-by: Qinrun Dai Cc: stable@vger.kernel.org Fixes: 781d2a9a2fc7 ("udf: Check LVID earlier") Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 2b7f29a9f95328cf4e59449b0b46f2458871985b Author: Karl Mehltretter Date: Thu Aug 13 04:40:26 2026 +0200 microblaze: Fix MB_MANAGER build with older binutils [ Upstream commit 79c8aa4da3d5453dd956d2170d1c9c716311ea06 ] Commit 88707ebe77e2 ("microblaze: Add custom break vector handler for mb manager") added the suspend mnemonic to the MB Manager break handler. GNU as only learned this mnemonic in binutils 2.42. Linux supports binutils 2.30, where enabling CONFIG_MB_MANAGER fails: arch/microblaze/kernel/entry.S:946: Error: unknown opcode "suspend" The suspend mnemonic is an alias for mbar 24, and both encode as 0xbb020004. Use the underlying instruction, which GNU as 2.30 already supports. Fixes: 88707ebe77e2 ("microblaze: Add custom break vector handler for mb manager") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202310310151.UhB396Qs-lkp@intel.com/ Suggested-by: Michal Simek Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260813024026.5402-1-kmehltretter@gmail.com Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit e86227c52828433eaff9c1315009a284e431796c Author: Fan Wu Date: Wed Jun 24 00:32:08 2026 +0000 media: imx-jpeg: finish the job on device_run() error paths [ Upstream commit 30b35fd2b999e1b8c26f8191d974d20c8848d2d6 ] mxc_jpeg_device_run() returns early through a shared "end" label on several error paths (no free slot, mxc_jpeg_alloc_slot_data() failure, or missing buffers or queue data), and none of them calls v4l2_m2m_job_finish(). Since the delayed work is queued only after the hardware is started, those paths neither finish the job directly nor queue timeout work that could finish it later. The job is left with TRANS_RUNNING set, so the wait_event() in v4l2_m2m_cancel_job() (reached from v4l2_m2m_ctx_release() at close) waits indefinitely and the close hangs. mxc_jpeg_alloc_slot_data() uses dma_alloc_coherent(), so the failure path is reachable under memory pressure. Return the src/dst buffers with VB2_BUF_STATE_ERROR and call v4l2_m2m_job_finish() on those paths: paths that have buffers use a "buf_finish" label; the no-buffer path uses "job_finish" directly. This mirrors the existing jpeg_parse_error path. This bug was found by static analysis. Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Reviewed-by: Ming Qian Signed-off-by: Frank Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 98bb5a7b262feb93c857eda521de13ba8c4278c0 Author: Sean Young Date: Tue Jul 7 18:10:02 2026 +0100 media: ir-hix5hd2: Ensure rdev is setup before interrupts are enabled [ Upstream commit f7509d2567cf92eeccc31c363a2e2ae43188930c ] Once the interrupt handler is enabled, priv->rdev can be used. Ensure it is setup correctly so there is no race condition. Fixes: a84fcdaa9058 ("[media] rc: Introduce hix5hd2 IR transmitter driver") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Sasha Levin commit d568a8484b92e5e66a01e8492f06ee7326ab9b1b Author: Sean Young Date: Mon Jul 13 13:52:43 2026 +0100 media: meson-ir-tx: Ensure probe error is propagated [ Upstream commit 2eb8a4cba70f521a8217021e227cfa28ba17724b ] devm_clk_get_enabled() may return -EPROBE_DEFER which needs to be propagated else the probe will not be deferred, it will fail instead. Fixes: 49be1c78d575 ("media: rc: introduce Meson IR TX driver") Signed-off-by: Sean Young Reviewed-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Sasha Levin commit 0ed13071f61f50efb91976fb1c080d5fb7eeceb9 Author: Sean Young Date: Mon Jul 6 19:24:59 2026 +0100 media: meson-ir-tx: Ensure rc_free_device() is called on unbind [ Upstream commit 32999b8a9d5c4f497c9739e70ac4ee390cd650a7 ] Make rc_dev devm managed. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Reviewed-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Sasha Levin commit 4b26912ba1e04e20050efb8368415b3a5c3a9a89 Author: Sean Young Date: Mon Jul 6 13:13:29 2026 +0100 media: meson-ir-tx: Ensure clock is disabled on unbind [ Upstream commit 1517326fcc9dfdb9acb24f42472366ac1b4b8237 ] clk_prepare_enable() needs a call to clk_disable_unprepare() on driver unbind. Make it devm managed. Fixes: 49be1c78d575 ("media: rc: introduce Meson IR TX driver") Signed-off-by: Sean Young Reviewed-by: Martin Blumenstingl Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Sasha Levin commit 6ad44df3151539535a0715843caa34a6b9417fa6 Author: Sean Young Date: Mon Jul 6 12:37:04 2026 +0100 media: sunxi-cir: Ensure no more interrupts can occur before free [ Upstream commit f9b33ec404200c03dd490ec133b8f9bf599c5444 ] Only call rc_free_device() once the hardware has been stopped. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Sasha Levin commit c2b5a19df174a8575c48d5159cd7bd2849f739c0 Author: Sean Young Date: Mon Jul 13 13:04:31 2026 +0100 media: redrat3: Ensure all urbs are suspended [ Upstream commit 1582f545273f2aa4eb4ee6f3a89b433f5c85c68f ] Ensure that the learn urb is stopped before suspend. Fixes: c49fcdde38cb ("[media] redrat3: enable carrier reports using wideband receiver") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5aa0ed2ecf48ead5e11c4e67c7d3c2c35775f3fb Author: Sean Young Date: Mon Jul 6 13:57:10 2026 +0100 media: redrat3: Ensure we don't read beyond the end of the packet [ Upstream commit cd49f62f4161c7340d9c9f53b67757575900c0bc ] The length and offset is provided by the usb device, so it should be validated. Fixes: 2154be651b90 ("[media] redrat3: new rc-core IR transceiver device driver") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Sasha Levin commit b6c2603d097f114a17f23bd8de4c0068d6cb1f45 Author: Sean Young Date: Mon Jul 6 12:25:43 2026 +0100 media: streamzap: Add missing rc_unregister_device() [ Upstream commit 3982d2eeb1bdf7a9c14e4ff69015cb456f11da51 ] If usb_submit_urb() fails during probe, then the error path is missing a call to rc_unregister_device(), which will leak various things like the input device. Fixes: 42844992664f ("media: rc: streamzap: Error handling in probe") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Sasha Levin commit 521cea0e92acdf35757ae1e54b6986d6aa7ac163 Author: Harry Wentland Date: Fri Aug 14 17:18:16 2026 -0400 drm/amd/display: Force GAMCOR for subsampled surfaces with PQ/Gamma22/HLG [ Upstream commit 2ffaa7c4050605cb27756f5336f778d1b21268b9 ] The ROM early-return checks for PQ, Gamma 2.2, and HLG in mod_color_calculate_degamma_params() do not consider the map_user_ramp parameter. When map_user_ramp is true (indicating a subsampled surface that requires post-scaler degamma via GAMCOR), the function still takes the ROM path, programming PRE_DEGAM instead. For subsampled formats the chroma channels must be upsampled by the scaler before degamma is applied. PRE_DEGAM sits before the scaler in the pipeline (CNVC domain), while GAMCOR sits after it (CM domain). Using the ROM for subsampled surfaces means degamma is applied to subsampled chroma before upsampling, producing incorrect results. Fix by gating the dcn_arch ROM capability checks on !map_user_ramp, forcing PQ/Gamma22/HLG through the GAMCOR LUT path when the surface is subsampled. Fixes: a8bf71649088 ("drm/amd/display: Internal refactoring to abstract color caps") Cc: stable@vger.kernel.org Assisted-by: Copilot:claude-opus-4.6 Signed-off-by: Harry Wentland Reviewed-by: Alex Hung Tested-by: Robert Mader Link: https://patch.msgid.link/20260814211816.1219597-11-harry.wentland@amd.com Signed-off-by: Sasha Levin commit 1871143400c7f459c647867cf544ed937dd50736 Author: YuBiao Wang Date: Wed Jul 29 17:53:57 2026 +0800 drm/amdgpu: recompute the dw estimate after allocating a new VM update job [ Upstream commit a74c7832b11827907de560169c7d4ac94505fd87 ] amdgpu_vm_sdma_update() keeps the number of free dwords of the current job in a local variable. When the job runs out of room it is committed and a new one is allocated, but that local variable is not refreshed and still describes the job which was just submitted. The stale value is then used to decide how many PTEs fit into the new job. If it happens to be copy_pte_num_dw + 7, or one more than that, the result is zero. copy_pte() encodes the transfer size as count * 8 - 1, so a count of zero asks the engine for a 1GB copy starting inside the IB pool. That runs off the end of the pool, faults on the first unmapped GART page above it and hangs the ring. Re-initialize the estimate from the newly allocated job, which is empty and therefore has its full budget available. Cc: stable@vger.kernel.org Signed-off-by: YuBiao Wang Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2a457374b6d7669f888d8b6baff73e8b963a95ea Author: Marek Czernohous Date: Sat Aug 15 21:54:20 2026 +0200 drm/nouveau: don't dereference outp before checking it in nouveau_dp_irq [ Upstream commit 843bc34db94bff0612c8294861b156489958897b ] nouveau_dp_irq() looks the encoder up and dereferences it in the same breath, five lines before testing it: struct nouveau_encoder *outp = find_encoder(connector, DCB_OUTPUT_DP); struct nouveau_drm *drm = nouveau_drm(outp->base.base.dev); ... if (!outp) return; find_encoder() walks the connector's possible encoders and returns NULL when none of them matches the requested type, so the NULL test is not decoration: it is the author saying this can happen. The initialiser above it dereferences the same pointer regardless. The NULL test predates the dereference. commit 773eb04d14a1 ("drm/nouveau/disp: expose conn event class") turned nouveau_dp_irq() into a work callback, and since the drm pointer was no longer passed in as an argument it was recovered from the encoder in the declaration block, which put the dereference above the existing test. Move the drm lookup below the test. No functional change when outp is non-NULL. Fixes: 773eb04d14a1 ("drm/nouveau/disp: expose conn event class") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Marek Czernohous Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/178682366004.3748010.14933649768375463967@gmail.com Signed-off-by: Sasha Levin commit bda77393313c8cc9166a74c4e4331f91ce97c48c Author: Marek Czernohous Date: Sat Aug 15 21:54:20 2026 +0200 drm/nouveau: cancel the DP IRQ work before freeing the connector [ Upstream commit f60849975a886d70883bcb6b3658c0fa83c6971f ] nouveau_connector_destroy() tears the two nvif events down and then frees the connector, but never cancels the work the IRQ event queues: nvif_event_dtor(&nv_connector->irq); nvif_event_dtor(&nv_connector->hpd); kfree(nv_connector->edid); ... kfree(connector); nouveau_connector_irq() queues that work unconditionally: schedule_work(&nv_connector->irq_work); return NVIF_EVENT_KEEP; A DP IRQ arriving just before nvif_event_dtor() therefore leaves nv_connector->irq_work on the system queue past the kfree(). When it runs, nouveau_dp_irq() derives both nv_connector and connector from the work_struct and dereferences them, and goes on to take outp->dp.hpd_irq_lock. There is no cancel_work_sync() for irq_work anywhere in the driver, so nothing else covers this. Add it after the event teardown, where no further work can be queued, and before anything is freed. Reported by the Sashiko review bot as a pre-existing issue, in its review of an earlier nv04 FIFO series of mine, and confirmed against the source. Reported-by: sashiko-bot Link: https://sashiko.dev/#/patchset/20260812231330.705425-1-mczernohous@gmail.com?part=1 Fixes: 773eb04d14a1 ("drm/nouveau/disp: expose conn event class") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Marek Czernohous Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/178682366002.3748010.4096452389040554615@gmail.com Signed-off-by: Sasha Levin commit d45c83c41b2d7cf25dbd9ba44a35ee66aaa23c67 Author: Marek Czernohous Date: Sun Aug 16 14:58:52 2026 +0200 drm/nouveau: disable the fence uevent work instead of just cancelling it [ Upstream commit 827eb9328eaed831d7cc426ac2705038a40835b6 ] nouveau_fence_context_del() drains the uevent work while the event that feeds it is still armed: cancel_work_sync(&fctx->uevent_work); nouveau_fence_context_kill(fctx, 0); nvif_event_dtor(&fctx->event); nouveau_fence_wait_uevent_handler() queues the work unconditionally: schedule_work(&fctx->uevent_work); return NVIF_EVENT_KEEP; so a non-stall interrupt arriving after cancel_work_sync() has returned re-arms the work that was just drained. The window closes in two steps, neither of which is the drain. The kill blocks the event when the last fence holding a notify_ref is signalled, which reaches atomic_xchg(&ntfy->allowed, 0) (nvkm/core/event.c:104), and nvkm_event_ntfy() skips a ntfy that is not allowed (:183). That stops further handlers from starting, but not one that is already inside nvkm_event_ntfy(): the event is created with wait = false (nouveau_fence.c:201), so nvkm_event_ntfy_block_() leaves it on the list and never takes event->list_lock. Only nvif_event_dtor() waits that one out: nvkm_event_ntfy_del() (:141) goes through nvkm_event_ntfy_remove(), which takes write_lock_irq() on that same list_lock (:84). Either way the re-arm happens after the drain, and the caller drops its reference immediately afterwards, for example nv84_fence_context_del(): nouveau_fence_context_del(&fctx->base); chan->fence = NULL; nouveau_fence_context_free(&fctx->base); That is a kref_put() on fctx->fence_ref, so the context outlives the teardown only while emitted fences still hold a reference of their own. That is no safety net: whenever none do, the count reaches zero right there and nouveau_fence_context_put() kfree()s fctx while the work is still queued. &fctx->uevent_work is embedded in that allocation, so the workqueue already dereferences freed memory when it picks the item up, and nouveau_fence_uevent_work() can then take fctx->lock on it. With CONFIG_DEBUG_OBJECTS_WORK and CONFIG_DEBUG_OBJECTS_FREE, kfree() of a still-queued work item is reported as the free of an active object. On live memory the re-armed work has nothing left to do: nouveau_fence_context_kill() empties fctx->pending and sets fctx->killed under fctx->lock, nouveau_fence_emit() then returns -ENODEV rather than queueing anything new, and nouveau_fence_update() only reaches nvif_event_block() if it signalled something off that list. The defect is the access to freed memory, not what the work would have found. Only chips from G84 on can reach this at all: nouveau_fence_context_new() returns before nvif_event_ctor() when priv->uevent is clear, and nv84_fence_create() is the only place that sets it. nv84_fence_context_del() is the context_del for all of those, because nvc0_fence_create() and gv100_fence_create() build on nv84_fence_create() and override only context_new. Use disable_work_sync() instead. It drains the work exactly like cancel_work_sync() does, and additionally increments the work item's disable count, after which "any attempt to queue @work will fail and return %false" (kernel/workqueue.c, disable_work()). The handler's schedule_work() then has nothing to re-arm, and the teardown order stays as it is. Draining a second time after nvif_event_dtor() would close the window as well, and without the newer API: once nvkm_event_ntfy_remove() has returned, no handler can start or still be running, so nothing re-arms the work past that point. disable_work_sync() is preferred here because it needs one synchronisation point instead of two, it keeps the work from being queued at all rather than cleaning up after it, and it is what drm has settled on for this (drm/xe, drm/panthor, drm_pagemap). Blocking the event rather than the work is not an option: fctx->event is created with wait = false, so a handler already inside nvkm_event_ntfy() can still queue the work. Note for backports: disable_work_sync() arrived in v6.10 with commit 86898fa6b8cd ("workqueue: Implement disable/enable for (delayed) work items"), while the fix being corrected here reached 6.6.18 and 6.7.6. linux-6.6.y therefore carries this bug without the API, and this patch would apply there and then fail to build. A 6.6.y backport wants the second drain described above instead, as its own patch. Reported-by: sashiko-bot Closes: https://lore.kernel.org/all/20260812233022.159301F000E9@smtp.kernel.org/ Fixes: 39126abc5e20 ("nouveau: offload fence uevents work to workqueue") Cc: # 6.10.x Assisted-by: Claude:claude-opus-5 Signed-off-by: Marek Czernohous Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/178688513268.513871.3468844663561639695@gmail.com Signed-off-by: Sasha Levin commit 796a4d6741b99c8a122582359621c43476eb24fe Author: Zhenhao Wan Date: Fri Aug 14 18:00:05 2026 +0800 drm/nouveau/svm: drain fault handler before freeing svmm [ Upstream commit b46ddaf0823405f81e681eb26ec98508f3eb9a07 ] The SVM fault handler nouveau_svm_fault() looks up each fault's nouveau_svmm under svm->mutex, caches it in the fault array, then drops svm->mutex and dereferences the svmm across blocking faults (mmu_interval_notifier_insert(), hmm_range_fault()). nouveau_svmm is not refcounted. On DRM file close nouveau_svmm_fini() -> mmu_notifier_put() frees it asynchronously via call_srcu() without waiting for the handler, and mmget_not_zero() pins the mm, not the svmm. flush_work() on the fault buffer otherwise runs only at device removal and suspend, never on close, so a fault handled concurrently with a close can dereference a freed svmm. The instance is already unlinked by nouveau_svmm_part() earlier in the same close, so no new fault can resolve to it. Drain the handler in nouveau_svmm_fini() before the free, guarding the flush with a NULL check on drm->svm: on device teardown nouveau_svm_fini() runs first and frees drm->svm (NULL) after blocking the notify and flushing the buffer, so the handler is already drained; on per-client close drm->svm is alive and the flush runs. Fixes: eeaf06ac1a55 ("drm/nouveau/svm: initial support for shared virtual memory") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260814-nouveau-svm-svmm-uaf-v2-1-8e6590519f07@gmail.com Signed-off-by: Sasha Levin commit 8d125070102467286ebe3b97661161446fe69ca8 Author: Zhenhao Wan Date: Thu Aug 13 21:14:08 2026 +0800 drm/nouveau: reject zero-size notifier object allocation [ Upstream commit 38125d38d850bd2fdd5d7840c3bd52d9d208995b ] nouveau_abi16_ioctl_notifierobj_alloc() passes the userspace-controlled info->size to nvkm_mm_head() as both size_max and size_min without a lower bound. A zero size satisfies the allocator's "e - s < size_min" gate (size_min == 0 makes the unsigned comparison inert) and yields a zero-length node, after which args.limit = ntfy->node->offset + ntfy->node->length - 1; underflows (offset 0, length 0 -> 0xffffffff) into an oversized ~4 GiB DMA window. The dma object constructor only rejects start > limit, so the validly ordered [base, base + 0xffffffff] range passes and is programmed into the GPU DMA context. The ioctl is DRM_RENDER_ALLOW, so any render node client can trigger this on pre-Fermi hardware. Reject a zero-size request before allocating anything. Fixes: ebb945a94bba ("drm/nouveau: port all engines to new engine module format") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260813-nouveau-abi16-notifierobj-zero-size-v1-1-20dee38077cb@gmail.com Signed-off-by: Sasha Levin commit a0561d132ee6514b785b488949ade79c522967b9 Author: Sean Young Date: Wed Nov 4 19:58:53 2026 -0500 media: rc: Fix race between bpf(BPG_PROG_ATTACH) and device unregister [ Upstream commit b3f5daf3222999d3f92f606a4eb5e35ab90fd0e4 ] Mark the device as unregistered before tearing down raw IR/bpf state, so that racing bpf(BPF_PROG_{ATTACH,DETACH,QUERY}) calls cannot slip in between ir_raw_event_unregister() completing and dev->registered being cleared. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Sasha Levin commit 0b65c96e51e6aac86f2db251b5bdc5255294a107 Author: Fan Wu Date: Wed Nov 4 18:46:06 2026 -0500 scsi: dc395x: sync the waiting_timer before freeing the host [ Upstream commit 0b1a79f2791a06f139dce5450e487307cf0e241f ] The waiting_timer callback re-arms itself and takes the host lock. adapter_uninit() currently stops it with timer_delete(), which does not wait for a callback already running on another CPU. The final scsi_host_put() that frees the host (and the host lock the callback dereferences) runs right after adapter_uninit(), so a concurrent or just re-armed callback can fire after the free, leaving a potential use-after-free window. Replace timer_delete() with timer_shutdown_sync() at the top of adapter_uninit(), before the host-lock section: the timer is dequeued, a running callback is waited for and rearming is blocked before the chip is halted, so it cannot fire at all once the adapter has ceased to function. Waiting outside the lock avoids the self-deadlock that would result from syncing a callback blocked on the lock we still hold. No shutdown is needed for selto_timer because it has no reachable armer or callback. This issue was found by an in-house static analysis tool. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Cc: Jamie Lenehan Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260911020544.42966-1-fanwu01@zju.edu.cn Signed-off-by: Martin K. Petersen (Oracle) [ sashal: Adjusted patch context to remove del_timer() calls where upstream removes timer_delete() calls. ] Signed-off-by: Sasha Levin commit e95e9efdbe0d0da90f9582396aefed921d2133bb Author: Fan Wu Date: Wed Nov 4 18:23:46 2026 -0500 media: s5p-mfc: use timer_shutdown_sync() for the self-rearming watchdog [ Upstream commit 63069b5917cba2e15b1a78b3f4ff99e45102c56f ] The MFC watchdog timer (s5p_mfc_watchdog) is self-rearming: every callback re-arms itself with add_timer() and, on a timeout, schedules watchdog_work. s5p_mfc_remove() tears this down with timer_delete_sync() followed by flush_work(). timer_delete_sync() dequeues the timer and waits for a callback that is already running, but it does not prevent a subsequent re-arm. Because the watchdog callback re-arms via add_timer(), this is the wrong shutdown primitive: once the wait returns nothing guarantees a just-queued re-arm will not fire later, dereferencing dev (clock on/off, deinit_hw, load_firmware, init_hw) after video_unregister_device(), DMA teardown and s5p_mfc_final_pm() have run, a potential use-after-free. Use timer_shutdown_sync(), which puts the timer into a shutdown state so that any add_timer()/mod_timer() from the callback becomes a no-op and no later firing is possible. Switch flush_work() to cancel_work_sync() so any watchdog_work that was already queued before the timer was stopped is cancelled rather than allowed to run to completion against the torn-down device. This issue was found by an in-house static analysis tool. No runtime reproducer is available. Fixes: af9357467810 ("[media] MFC: Add MFC 5.1 V4L2 driver") Cc: stable@vger.kernel.org Cc: Andrzej Hajda Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Reviewed-by: Marek Szyprowski Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil [ sashal: adapted the timer replacement to remove del_timer_sync() instead of timer_delete_sync() ] Signed-off-by: Sasha Levin commit 384c524e066459c91a8750a055fe70d56b334437 Author: Vernon Yang Date: Wed Nov 4 19:08:42 2026 -0500 mm: khugepaged: fix swap entry value to folio_pfn() [ Upstream commit 942c8ec27aa4ffc587511650718349964e1696e6 ] Patch series "mm: khugepaged: fix tracepoint UAF", v5. The khugepaged tracepoints take a folio pointer and call folio_pfn(), but by then the folio may no longer be valid: freed after folio_put(), folio_unlock() or pte_unmap_unlock(), or not a folio at all but an xarray-encoded swap entry. On classic SPARSEMEM, dereferencing it oopses khugepaged as soon as the trace event is enabled; on other memory models it merely prints a bogus pfn. Pass the pfn to the tracepoints directly, captured while the folio is still pinned, closing the use-after-free windows in mm_khugepaged_scan_file(), mm_khugepaged_scan_pmd() and mm_khugepaged_collapse_file(). This patch (of 3): When the swap entries found exceed max_ptes_swap, the loop is left via break with folio still holding the xarray value that encodes the swap entry, not valid folio pointer. That value is passed to trace_mm_khugepaged_scan_file(), which feeds it to folio_pfn(). On FLATMEM and SPARSEMEM_VMEMMAP, the page_to_pfn() is plain pointer arithmetic, so the trace event merely prints bogus scan_pfn. On classic SPARSEMEM, the page_to_pfn() reads page->flags, dereferencing the tiny encoded integer and oopsing khugepaged whenever the trace event is enabled. So when folio is the swap entry value, simply set pfn to -1, just like exhausted scan naturally. And the folio_put() has maybe dropped the last reference of folio. The trace_mm_khugepaged_scan_file() is left with a dangling folio pointer. so using the folio_pfn() before dropping the reference, closing use-after-free window. Link: https://lore.kernel.org/20260909025804.3233645-1-vernon2gm@gmail.com Link: https://lore.kernel.org/20260909025804.3233645-2-vernon2gm@gmail.com Fixes: d41fd2016ed0 ("mm/khugepaged: add tracepoint to hpage_collapse_scan_file()") Signed-off-by: Vernon Yang Signed-off-by: Andrew Morton Acked-by: David Hildenbrand (Arm) Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Lorenzo Stoakes Cc: Ryan Roberts Cc: Zach O'Keefe Cc: [ sashal: adjusted PFN capture context for the existing scanner, which lacks temporary folio references and corresponding folio_put() calls ] Signed-off-by: Sasha Levin commit be66694b2f818d7b14eb5022382b15df837459d8 Author: Fan Wu Date: Wed Nov 4 17:37:05 2026 -0500 ASoC: amd: ps: fix snd_acp63_remove() teardown ordering [ Upstream commit c53791d673ed4da6759d276078627ec4d0c6536b ] The ACP IRQ handlers dereference the SoundWire, SoundWire DMA, and PDM child platform devices, but snd_acp63_remove() unregisters them while the interrupt is still held by devres, which frees it only after remove returns. An interrupt in this window is a use-after-free. Mask the ACP interrupt sources and call devm_free_irq() before the first child device is unregistered. The masking goes through the new acp_hw_ops->disable_interrupts callback, keeping the remove path platform-agnostic. The interrupt line is shared, and acp_hw_deinit() clears the sources only after the children are gone, which would leave the line raised with no handler left to ack it. The window predates the tagged refactor, which only reshaped the dereferences. devm_free_irq() waits for in-flight handlers, but not for work the hardirq has already queued: acp63_irq_handler() schedules amd_sdw_irq_thread on the SoundWire manager. Draining that work in the manager's remove path is a soundwire-side change and follows separately. This issue was found by an in-house static analysis tool. Fixes: eaf825037d6d ("ASoC: amd: ps: refactor acp child platform device creation code") Cc: stable@vger.kernel.org Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Vijendar Mukunda Link: https://patch.msgid.link/20260929061349.3879-1-fanwu01@zju.edu.cn Signed-off-by: Mark Brown [ sashal: Replaced acp_hw_disable_interrupts() with the existing acp63_disable_interrupts() helper because the hardware operations framework is absent. ] Signed-off-by: Sasha Levin commit 2af4892580167181c3181b2f0b6ffab1be0096c9 Author: Yibo Tan Date: Wed Nov 4 14:37:03 2026 -0500 media: ipu-bridge: Fix use-after-free in IVSC error path [ Upstream commit 3d42d1c82717f0853379b516a7fab54b636e09cc ] ipu_bridge_get_ivsc_acpi_dev() returns an ACPI device with a reference held. If no matching CSI device is found, ipu_bridge_check_ivsc_dev() drops that reference before passing the device to dev_err(). Concurrent CSI device and ACPI namespace removal can drop the other references, making this the final put. dev_err() then reads the freed struct acpi_device and its kobject name. This was reproduced without kprobes by racing normal CSI platform-device unregistration and ACPI configfs table removal against the production ipu_bridge_init() entry. KASAN reported the final free through device_release(), followed by invalid reads through _dev_err(). Emit the error message while the lookup reference is still held, then drop the reference as before. Source reproducers and vulnerable/fixed serial logs, with only the build hostname redacted, are available at: https://github.com/kimaiden1984-boop/linux-ipu-bridge-acpi-uaf-reproducer The fixed target builds with W=1 on x86-64. This was not tested on physical IPU hardware. The tests establish runtime reachability but do not measure occurrence frequency on shipping systems or establish exploitability. Fixes: c66821f381ae ("media: pci: intel: Add IVSC support for IPU bridge driver") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Yibo Tan Signed-off-by: Sakari Ailus [ sashal: adjusted context for the error message that mentions only MEI instead of MEI or CVS ] Signed-off-by: Sasha Levin commit 4074511c39abed4b763392f0430bf84f166abb4c Author: Jérémy Jean Date: Wed Nov 4 19:58:58 2026 -0500 nvmet-auth: serialize access to DH-HMAC-CHAP state to fix UAF [ Upstream commit 53f6efe00cea0c0cf7bd99debe3cdac8567170b5 ] A REPLY AUTH_SEND command can derive a dhchap_skey key while a concurrent AUTH_RECEIVE command observing this REPLY state executes the failure path and frees that key. The REPLY command then continues and writes into freed memory, causing a use-after-free. KASAN reports it as: BUG: KASAN: slab-use-after-free in __sha256_final Write of size 4 at addr ffff88800359c540 ... nvmet_auth_sq_free (drivers/nvme/target/auth.c:237) nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:621) Add a mutex to each submission queue to serialize authentication commands and timeout handling. Unlock the mutex before completing requests and ignore outdated timeout callbacks. Limit timeout delays to prevent immediate expiry on 32-bit kernels. Fixes: 7a277c37d352 ("nvmet-auth: Diffie-Hellman key exchange support") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Christoph Hellwig Signed-off-by: Jérémy Jean Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 2cb518319b1a687d5c065bbb99b9a729b487bdb2 Author: Marco Crivellari Date: Wed Nov 4 19:58:57 2026 -0500 nvmet: replace use of system_wq with system_percpu_wq [ Upstream commit 3d553be6d295b6cca8fd35cb673fd13934ac4cbc ] This patch continues the effort to refactor workqueue APIs, which has begun with the changes introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") The point of the refactoring is to eventually alter the default behavior of workqueues to become unbound by default so that their workload placement is optimized by the scheduler. Before that to happen, workqueue users must be converted to the better named new workqueues with no intended behaviour changes: system_wq -> system_percpu_wq system_unbound_wq -> system_dfl_wq This way the old obsolete workqueues (system_wq, system_unbound_wq) can be removed in the future. Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Suggested-by: Tejun Heo Reviewed-by: Christoph Hellwig Signed-off-by: Marco Crivellari Signed-off-by: Keith Busch Stable-dep-of: 53f6efe00cea ("nvmet-auth: serialize access to DH-HMAC-CHAP state to fix UAF") Signed-off-by: Sasha Levin commit 04d1e4fc965c8a4378093174e908800f400b7485 Author: Weiming Shi Date: Wed Nov 4 19:56:34 2026 -0500 virtio_net: atomically disable rx mode work [ Upstream commit 1234707482053f1d1ac7c5756207d2c29057974c ] virtio-net uses a boolean to gate rx_mode_work during device teardown. The flag is changed under RTNL, but ndo_set_rx_mode checks it under the address-list lock. A callback can therefore pass the check and enqueue work after teardown has flushed it. The work is also enabled before late probe operations that can fail, allowing probe unwind to free the netdev with work still queued. KASAN reports the worker using a virtqueue that probe unwind already freed: BUG: KASAN: slab-use-after-free in virtqueue_add_split Workqueue: events virtnet_rx_mode_work Call Trace: virtqueue_add_split (drivers/virtio/virtio_ring.c:706) virtqueue_add_sgs (drivers/virtio/virtio_ring.c:2839) virtnet_send_command_reply (drivers/net/virtio_net.c:3565) virtnet_rx_mode_work (drivers/net/virtio_net.c:3833) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3405) Freed by task 119: kfree (mm/slub.c:6625) vp_del_vq.isra.0 (drivers/virtio/virtio_pci_common.c:259) vp_del_vqs (drivers/virtio/virtio_pci_common.c:285) virtnet_probe (drivers/net/virtio_net.c:7129) Use the workqueue disable mechanism to atomically reject new queue attempts and drain running work. Keep work disabled until probe succeeds or restore has reattached the netdev, then enable it and replay receive-mode state for a running interface. Disable it before resource teardown in freeze and remove. Fixes: b9f7425239a0 ("virtio-net: convert rx mode setting to use workqueue") Cc: stable@vger.kernel.org Reported-by: Assisted-by: LLM Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20261017114237.2786302-2-bestswngs@gmail.com Signed-off-by: Paolo Abeni [ sashal: adjusted context to match the existing virtio-net device lifecycle code ] Signed-off-by: Sasha Levin commit 23f917d95b88a73d1498dd00456cec418dd355c4 Author: Ruide Cao Date: Wed Nov 4 19:16:33 2026 -0500 mptcp: hold MP_JOIN msk ref when cloning reqsk [ Upstream commit c9c90cf437a9e6597611b6d3aad6e255fad22867 ] TCP request migration clones pending request sockets with inet_reqsk_clone(). For MPTCP MP_JOIN requests this byte-copies subflow_req->msk, but the clone does not own a reference. The original and cloned requests can consequently drop the same msk reference, leaving one request with a dangling pointer. This manifests as a KASAN slab-use-after-free in subflow_req_destructor(): BUG: KASAN: slab-use-after-free in subflow_req_destructor (net/mptcp/subflow.c:45) Write of size 4 at addr ff1100010e008d40 by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc5-00353-gc27e36054537 #10 PREEMPT(full) Call Trace: subflow_req_destructor (net/mptcp/subflow.c:45) subflow_v4_req_destructor (net/mptcp/subflow.c:694) __reqsk_free (net/ipv4/inet_connection_sock.c:906) reqsk_timer_handler (include/net/request_sock.h:137 net/ipv4/inet_connection_sock.c:1147) Allocated by task 10014: sk_prot_alloc (net/core/sock.c:2246) sk_clone (net/core/sock.c:2488) mptcp_sk_clone_init (include/net/sock.h:1848 net/mptcp/protocol.c:3564) subflow_syn_recv_sock (net/mptcp/subflow.c:883) tcp_check_req (net/ipv4/tcp_minisocks.c:934) Freed by task 0: slab_free_after_rcu_debug (include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6439) rcu_core (kernel/rcu/tree.c:2645 kernel/rcu/tree.c:2897) Last potentially related work creation: kmem_cache_free (mm/slub.c:2638 mm/slub.c:6377 mm/slub.c:6504) __sk_destruct (net/core/sock.c:2289 net/core/sock.c:2391) sk_destruct (net/core/sock.c:2419) __sk_free (net/core/sock.c:2430) sk_free (net/core/sock.c:2441) mptcp_close (include/net/sock.h:2020 net/mptcp/protocol.c:3399) inet_release (net/ipv4/af_inet.c:442) The buggy address belongs to the cache MPTCP of size 2968 The buggy address is 128 bytes inside a freed 2968-byte region A non-NULL subflow_req->msk means that the request owns one reference. The third ACK can concurrently transfer the original request reference to the child and release it, so taking an unconditional hold on the copied pointer is unsafe. MPTCP sockets use SLAB_TYPESAFE_BY_RCU and all current inet_reqsk_clone() callers run in an RCU read-side critical section. Document and lockdep-check that calling-context requirement. Read the pointer from the original request and acquire a reference only if it is still live. Use refcount_inc_not_zero_acquire() so the subsequent ownership validation cannot be reordered before the try-get, then re-read the original request to verify that it still owns the same msk. If either check fails, clear the clone pointer; otherwise its normal destructor balances the new reference. Mark the ownership-transfer store with WRITE_ONCE() to match the lockless reads. The following patch completes the clone fixup for MP_CAPABLE token ownership. Both patches carry the same Fixes tag and are required for stable backports. Fixes: c905dee62232 ("tcp: Migrate TCP_NEW_SYN_RECV requests at retransmitting SYN+ACKs.") Cc: stable@vger.kernel.org Reported-by: Kyle Zeng Reported-by: David Lee Reported-by: Vega Closes: https://lore.kernel.org/all/20260804095051.715355-1-david.lee@trailofbits.com/ Signed-off-by: Ruide Cao Signed-off-by: Ren Wei Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20261013-net-mptcp-misc-fixes-7-3-rc8-v1-3-932c9b182fc7@kernel.org Signed-off-by: Jakub Kicinski [ sashal: Adjusted the MPTCP include placement because the TCP ECN header is absent. ] Signed-off-by: Sasha Levin commit dd0978ebf56ee9dda9fc0ff36db91511c01fa716 Author: Zhao Li Date: Wed Nov 4 18:46:43 2026 -0500 wifi: mt76: mt7996: unlink TWT flow if the MCU rejects the agreement [ Upstream commit 022f5f8b7a0580da50fcbc34da853d03d4321fe2 ] mt7996_mac_add_twt_setup() links a new flow into dev->twt_list before asking the MCU to add the agreement, but exits without unlinking the flow if the request fails. The flow-ID and table masks are only committed after MCU success, so the still-linked flow is invisible to the mask-gated teardown paths. If the station retries the setup, the same slot is cleared and its embedded list node reinitialized while it is still linked, corrupting dev->twt_list. If the station disassociates instead, teardown skips the flow and station storage can be freed while the node remains linked. A later scheduling or debugfs twt_stats walk can then dereference the freed flow, resulting in a use-after-free. Unlink the flow when the MCU rejects the agreement. This restores the list to its pre-request state while leaving the unchanged mask and agreement accounting untouched. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260729173632.14387-3-enderaoelyther@gmail.com/ Assisted-by: Codex:gpt-5.6-sol Assisted-by: Kimi:K3 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260825112620.97568-1-enderaoelyther@gmail.com Signed-off-by: Felix Fietkau [ sashal: Changed the MCU helper argument from &msta->vif->deflink to msta->vif to match the existing interface. ] Signed-off-by: Sasha Levin commit 60e3352593f224306dfab578bf586b301642265f Author: Tianchu Chen Date: Wed Nov 4 19:08:51 2026 -0500 staging: rtl8723bs: fix protected RX frame validation in decrypt path [ Upstream commit 495cb31c791bdf3f9efef255a9587b05b0526c9d ] The RX software decrypt path mishandles crafted protected frames from a malicious AP in two ways: 1) decryptor() never checks that a protected frame is long enough to hold the 802.11 header plus the per-cipher trailer. All of rtw_wep_decrypt(), rtw_tkip_decrypt() and rtw_aes_decrypt() compute length = hdr.len - hdrlen - iv_len; and act on the result, and recvframe_chkmic() similarly computes datalen = hdr.len - hdrlen - iv_len - icv_len - 8; for TKIP (the 8-byte Michael MIC is not accounted for in icv_len). A frame shorter than hdrlen + iv_len + icv_len (+ 8 for TKIP) underflows these unsigned subtractions, turning into a ~4 GiB iteration count in aes_decipher()/arc4_crypt()/rtw_seccalctkipmic() or a ~4 GiB crc32_le() length, causing out-of-bounds reads/writes of up to ~4 GiB starting from the rx skb. Reject such frames in decryptor() before touching the IV; this covers all three ciphers and the TKIP MIC check, and also keeps the unconditional iv[3] access within the frame. 2) validate_80211w_mgmt() keeps using the frame - two memcpys through the stale rx_data pointer and a pkt_len update - before checking whether decryptor() returned NULL. On decrypt failure (e.g. a unicast protected deauth/disassoc/action frame with a bad MIC, which this path always software-decrypts) the skb has already been freed, so this is a use-after-free read/write, and the caller's error path frees the frame a second time, drifting free_recvframe_cnt. Bail out immediately when decryptor() fails, freeing the temporary mgmt_DATA buffer first. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/8ee3bdd1c45034200cb1aa9a7e9b575b9584643a@linux.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 15f6df6bdb4f7f318ab375f8705af789b5c24860 Author: Khasar Munkh-Erdene <02khasar@gmail.com> Date: Wed Nov 4 19:08:50 2026 -0500 staging: rtl8723bs: fix spacing around operators in rtw_recv.c [ Upstream commit 393b267e6f04a11d4b18b7dc1423fa59f173f72b ] Fix coding style issues by adding missing spaces around binary and ternary operators, as reported by checkpatch.pl. Signed-off-by: Khasar Munkh-Erdene <02khasar@gmail.com> Link: https://patch.msgid.link/20260225032909.72799-1-02khasar@gmail.com Signed-off-by: Greg Kroah-Hartman Omit the spacing change in rtw_handle_tkip_mic_err(), which remains in the receive OS glue. Keep the other operator-spacing fixes, including the decrypt and management-frame contexts required by the protected RX frame validation fix. Stable-dep-of: 495cb31c791b ("staging: rtl8723bs: fix protected RX frame validation in decrypt path") Signed-off-by: Sasha Levin commit 2cfc1ccf67ffe96811c816d27d44128c5d5833ec Author: Sean Christopherson Date: Wed Nov 4 18:12:46 2026 -0500 KVM: guest_memfd: Gracefully handle xarray errors when binding a memslot [ Upstream commit e6ecb88711d93b9e014532f17d3d29b57e80932c ] If inserting a memslot into a guest_memfd's bindings xarray fails, propagate the error back to the caller, i.e. fail memslot creation as well. Signalling success and continuing on with memslot creation results in use-after-free, as the guest_memfd instance will remain reachable via the memslot after the file is freed (kvm_gmem_release() won't nullify the file pointer due to lack of a valid binding). Opportunistically WARN and reject binding if KVM_MEMSLOT_GMEM_ONLY is already set, partly to guard against goofs elsewhere, but mostly so that KVM doesn't need to worry about clobbering flags when unwinding on failure. Regarding the unwind, the slot must be fully prepared before inserting it into the bindings, at which point the slot becomes reachable. I.e. waiting to update the slot in order to avoid the ugly unwind isn't an option. And as part of the unwind, explicitly nullify the relevant bindings, as xarray can store a subset of entries when populating a range. Fixes: a7800aa80ea4 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Reported-by: Dennis Tighe Reported-by: Sashiko Bot Closes: https://lore.kernel.org/all/20260823135031.4F6DC1F000E9%40smtp.kernel.org Reviewed-by: David Hildenbrand (Arm) Reviewed-by: Ackerley Tng Link: https://patch.msgid.link/20260922001332.1121266-2-seanjc@google.com Signed-off-by: Sean Christopherson [ sashal: Used gmem instead of f and omitted the guard and rollback cleanup for the unavailable KVM_MEMSLOT_GMEM_ONLY flag. ] Signed-off-by: Sasha Levin commit 727dfb28c6a2334f08cdaef82540137c9b094ab7 Author: Josef Bacik Date: Wed Nov 4 10:58:31 2026 -0500 mm/hugetlb: fix use-after-free of a new anon folio [ Upstream commit 824cc56bf43c714319992bad3558803cac6e77c0 ] For a fault in a private mapping with nothing in the page cache, hugetlb_no_page() allocates a folio, locks it and maps it. The folio has one reference, which belongs to the page table entry from then on. After dropping the page table lock the function still sets the migratable flag of the folio and unlocks it. Whoever zaps the entry in between frees the folio. The fault holds the fault mutex and the lock of the vma. MADV_DONTNEED and the first unmap of a hole punch, hugetlb_vmdelete_list(), do not take the fault mutex, and a private vma only has a lock if it owns a reservation map: not with MAP_NORESERVE, and not in the child after fork(). Then the flag is set in, and folio_unlock() is called on, a folio that is free or has a new owner. A surplus page goes back to the page allocator while it is locked: BUG: Bad page state in process init pfn:108e00 flags: 0x200000000000059(locked|uptodate|dirty|head|node=0|zone=2) page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set A page of the pool can be given to the next user, of any file, who locks it and loses the lock to the late folio_unlock(): kernel BUG at mm/filemap.c:1532! hugetlb_no_page+0x111b/0x23e0 hugetlb_fault+0x3a9/0x14a0 An unprivileged process is enough: threads that write to a MAP_PRIVATE | MAP_NORESERVE hugetlb mapping, threads that call MADV_DONTNEED on it, and one that takes the freed pages for another file. Until commit 3a47c54f09c4 ("hugetlbfs: revert use i_mmap_rwsem for more pmd sharing synchronization") the fault held i_mmap_rwsem for reading, which everybody who zaps takes for writing. The lock that commit bf4916922c60 ("hugetlbfs: extend hugetlb_vma_lock to private VMAs") gave to private vmas closed the window again, but only for those with a reservation map. Be done with the folio before the page table lock is dropped, as hugetlb_wp() is with its copy. The function already unlocks page cache folios under that lock. Original fix generated by an LLM and sent in private by Josef. [david@kernel.org: simplify+move comment] Link: https://lore.kernel.org/20261015-urgent_fixes-v1-2-42796911043b@kernel.org Fixes: 3a47c54f09c4 ("hugetlbfs: revert use i_mmap_rwsem for more pmd sharing synchronization") Signed-off-by: Josef Bacik Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: Muchun Song Reviewed-by: Lance Yang Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Oscar Salvador Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Adam Litke Cc: Mel Gorman Cc: Rik van Riel Cc: Peter Xu Cc: Kiryl Shutsemau Cc: Mike Rapoport Cc: Signed-off-by: Sasha Levin commit 4dcc24f41d4ad86625a7c4b712f8a7691fbf2711 Author: Oscar Salvador Date: Wed Nov 4 10:58:30 2026 -0500 mm,hugetlb: sort out folio locking in the faulting path [ Upstream commit 9293fb4765527c0d2375eb441d045a5a75f5210d ] Recent conversations showed that there was a misunderstanding about why we were locking the folio prior to call in hugetlb_wp(). In fact, as soon as we have the folio mapped into the pagetables, we no longer need to hold it locked, because we know that no concurrent truncation could have happened. There is only one case where the folio needs to be locked, and that is when we are handling an anonymous folio, because hugetlb_wp() will check whether it can re-use it exclusively for the process that is faulting it in. So, pass the folio locked to hugetlb_wp() when that is the case. Link: https://lkml.kernel.org/r/20250627102904.107202-3-osalvador@suse.de Link: https://lkml.kernel.org/r/20250630144212.156938-3-osalvador@suse.de Signed-off-by: Oscar Salvador Suggested-by: David Hildenbrand Acked-by: David Hildenbrand Cc: Gavin Guo Cc: Muchun Song Cc: Peter Xu Signed-off-by: Andrew Morton Stable-dep-of: 824cc56bf43c ("mm/hugetlb: fix use-after-free of a new anon folio") Signed-off-by: Sasha Levin commit c05b9915a6594da40070c2ef2a5429a32271dc46 Author: Oscar Salvador Date: Wed Nov 4 10:58:29 2026 -0500 mm,hugetlb: change mechanism to detect a COW on private mapping [ Upstream commit 2ae1ab9934c785b855583e3eabd208d6f3ac91e1 ] Patch series "Misc rework on hugetlb faulting path", v4. This patchset aims to give some love to the hugetlb faulting path, doing so by removing obsolete comments that are no longer true, sorting out the folio lock, and changing the mechanism we use to determine whether we are COWing a private mapping already. The most important patch of the series is #1, as it fixes a deadlock that was described in [1], where two processes were holding the same lock for the folio in the pagecache, and then deadlocked in the mutex. Note that this can also happen for anymous folios. This has been tested using this reproducer, below Looking up and locking the folio in the pagecache was done to check whether that folio was the same folio we had mapped in our pagetables, meaning that if it was different we knew that we already mapped that folio privately, so any further CoW would be made on a private mapping, which lead us to the question: __Was the reservation for that address consumed?__ That is all we care about, because if it was indeed consumed and we are the owner and we cannot allocate more folios, we need to unmap the folio from the processes pagetables and make it exclusive for us. We figured we do not need to look up the folio at all, and it is just enough to check whether the folio we have mapped is anonymous, which means we mapped it privately, so the reservation was indeed consumed. Patch#2 sorts out folio locking in the faulting path, reducing the scope of it ,only taking it when we are dealing with an anonymous folio and document it. More details in the patch. Patch#3-5 are cleanups. Here is the reproducer: #include #include #include #include #include #define PROTECTION (PROT_READ | PROT_WRITE) #define LENGTH (2UL*1024*1024) #define ADDR (void *)(0x0UL) #define FLAGS (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB) void __read(char *addr) { int i = 0; printf("a[%d]: %c\n", i, addr[i]); } void fill(char *addr) { addr[0] = 'd'; printf("addr: %c\n", addr[0]); } int main(void) { void *addr; pid_t pid, wpid; int status; addr = mmap(ADDR, LENGTH, PROTECTION, FLAGS, -1, 0); if (addr == MAP_FAILED) { perror("mmap"); return -1; } printf("Parent faulting in RO\n"); __read(addr); sleep (10); printf("Forking\n"); pid = fork(); switch (pid) { case -1: perror("fork"); break; case 0: sleep (4); printf("Child: Faulting in\n"); fill(addr); exit(0); break; default: printf("Parent: Faulting in\n"); fill(addr); while((wpid = wait(&status)) > 0); if (munmap(addr, LENGTH)) perror("munmap"); } return 0; } You will also have to add a delay in hugetlb_wp, after releasing the mutex and before unmapping, so the window is large enough to reproduce it reliably. : --- a/mm/hugetlb.c : +++ b/mm/hugetlb.c : @@ -38,6 +38,7 @@ : #include : #include : #include : +#include : : #include : #include : @@ -6261,6 +6262,8 @@ static vm_fault_t hugetlb_wp(struct vm_fault *vmf) : hugetlb_vma_unlock_read(vma); : mutex_unlock(&hugetlb_fault_mutex_table[hash]); : : + mdelay(8000); : + : unmap_ref_private(mm, vma, old_folio, vmf->address); : : mutex_lock(&hugetlb_fault_mutex_table[hash]); This patch (of 5): hugetlb_wp() checks whether the process is trying to COW on a private mapping in order to know whether the reservation for that address was already consumed. If it was consumed and we are the ownner of the mapping, the folio will have to be unmapped from the other processes. Currently, that check is done by looking up the folio in the pagecache and compare it to the folio which is mapped in our pagetables. If it differs, it means we already mapped it privately before, consuming a reservation on the way. All we are interested in is whether the mapped folio is anonymous, so we can simplify and check for that instead. Link: https://lkml.kernel.org/r/20250630144212.156938-1-osalvador@suse.de Link: https://lkml.kernel.org/r/20250627102904.107202-1-osalvador@suse.de Link: https://lkml.kernel.org/r/20250627102904.107202-2-osalvador@suse.de Link: https://lore.kernel.org/lkml/20250513093448.592150-1-gavinguo@igalia.com/ [1] Link: https://lkml.kernel.org/r/20250630144212.156938-2-osalvador@suse.de Fixes: 40549ba8f8e0 ("hugetlb: use new vma_lock for pmd sharing synchronization") Signed-off-by: Oscar Salvador Reported-by: Gavin Guo Closes: https://lore.kernel.org/lkml/20250513093448.592150-1-gavinguo@igalia.com/ Suggested-by: Peter Xu Acked-by: David Hildenbrand Cc: Muchun Song Signed-off-by: Andrew Morton : : #include : #include : @@ -6261,6 +6262,8 @@ static vm_fault_t hugetlb_wp(struct vm_fault *vmf) : hugetlb_vma_unlock_read(vma); : mutex_unlock(&hugetlb_fault_mutex_table[hash]); : : + mdelay(8000); : + : unmap_ref_private(mm, vma, old_folio, vmf->address); : Stable-dep-of: 824cc56bf43c ("mm/hugetlb: fix use-after-free of a new anon folio") Signed-off-by: Sasha Levin commit 0ecdbbf1d3e562cad975f4de48e17686770e2423 Author: Peter Xu Date: Wed Nov 4 10:58:28 2026 -0500 mm/hugetlb: rename avoid_reserve to cow_from_owner [ Upstream commit 30cef82bc6e8975a360ec05b707f7fb194c875ed ] The old name "avoid_reserve" can be too generic and can be used wrongly in the new call sites that want to allocate a hugetlb folio. It's confusing on two things: (1) whether one can opt-in to avoid global reservation, and (2) whether it should take more than one count. In reality, this flag is only used in an extremely hacky path, in an extremely hacky way in hugetlb CoW path only, and always use with 1 saying "skip global reservation". Rename the flag to avoid future abuse of this flag, making it a boolean so as to reflect its true representation that it's not a counter. To make it even harder to abuse, add a comment above the function to explain it. Link: https://lkml.kernel.org/r/20250107204002.2683356-4-peterx@redhat.com Signed-off-by: Peter Xu Reviewed-by: Oscar Salvador Cc: Ackerley Tng Cc: Breno Leitao Cc: Muchun Song Cc: Naoya Horiguchi Cc: Rik van Riel Cc: Roman Gushchin Signed-off-by: Andrew Morton Stable-dep-of: 824cc56bf43c ("mm/hugetlb: fix use-after-free of a new anon folio") Signed-off-by: Sasha Levin commit f72f2d97b4bd516e718ebfc122bedfd9262ba927 Author: Peter Xu Date: Wed Nov 4 10:58:27 2026 -0500 mm/hugetlb: stop using avoid_reserve flag in fork() [ Upstream commit be8d7314b18ede1c6cdebbb982c9659020e2f1f2 ] When fork() and stumble on top of a dma-pinned hugetlb private page, CoW must happen during fork() to guarantee dma coherency. In this specific path, hugetlb pages need to be allocated for the child process. Stop using avoid_reserve=1 flag here: it's not required to be used here, as dest_vma (which is destined to be a MAP_PRIVATE hugetlb vma) will have no private vma resv map, and that will make sure it won't be able to use a vma reservation later. No functional change intended with this change. Said that, it's still wanted to do this, so as to reduce the usage of avoid_reserve to the only one user, which is also why this flag was introduced initially in commit 04f2cbe35699 ("hugetlb: guarantee that COW faults for a process that called mmap(MAP_PRIVATE) on hugetlbfs will succeed"). I don't see whoever else should set it at all. Further patch will clean up resv accounting based on this. Link: https://lkml.kernel.org/r/20250107204002.2683356-3-peterx@redhat.com Signed-off-by: Peter Xu Reviewed-by: Oscar Salvador Cc: Ackerley Tng Cc: Breno Leitao Cc: Muchun Song Cc: Naoya Horiguchi Cc: Rik van Riel Cc: Roman Gushchin Signed-off-by: Andrew Morton Stable-dep-of: 824cc56bf43c ("mm/hugetlb: fix use-after-free of a new anon folio") Signed-off-by: Sasha Levin commit e4ed15ae7111ef97c92092998b8fcdbfb25f4fdf Author: Nirmoy Das Date: Wed Nov 4 10:57:56 2026 -0500 iommufd: Fix event queue release use-after-free [ Upstream commit 440ca8a4b69f40088065b9e05ef11373292a254e ] iommufd_eventq_fops_release() drops the file's users reference before reading eventq->ictx. Once that reference is dropped, IOMMU_DESTROY in another thread can remove and free the event queue, so the later load accesses freed memory. Read ictx while the users reference still pins the event queue, then drop the reference and put the saved context. The context reference taken by iommufd_eventq_init() keeps ictx valid until the put. Fault and vEVENTQ file descriptors share this release path. Fixes: 07838f7fd529 ("iommufd: Add iommufd fault object") Cc: stable@vger.kernel.org Assisted-by: LLM, Specula Signed-off-by: Nirmoy Das Link: https://patch.msgid.link/20261014133632.3440297-1-nirmoyd@nvidia.com Signed-off-by: Jason Gunthorpe [ sashal: Adapted eventq identifiers to fault identifiers in the existing fault release callback. ] Signed-off-by: Sasha Levin commit babcfd9adea84e92f415ca75f0a67add4b381855 Author: Honglei Huang Date: Fri May 29 10:23:17 2026 +0800 drm/amdgpu: drop retry loop in amdgpu_hmm_range_get_pages [ Upstream commit 342981fff32802a819d6fc7cf3c9fedf9f3d9d60 ] Since commit c08972f55594 ("drm/amdgpu: fix amdgpu_hmm_range_get_pages") moved mmu_interval_read_begin() out of the per-chunk loop, the captured notifier_seq is no longer refreshed across retries. As a result, the existing -EBUSY retry path can never make progress: hmm_range_fault() returns -EBUSY only when mmu_interval_check_retry(notifier, notifier_seq) reports that the sequence is stale. Once the sequence has advanced, the stored seq will never match again, so every subsequent call within the same invocation returns -EBUSY immediately. The "goto retry" therefore degenerates into a busy spin that simply burns CPU for the full HMM_RANGE_DEFAULT_TIMEOUT (~1s) window before finally bailing out with -EAGAIN. This is pure latency with no chance of recovery, and it actively hurts the KFD userptr stack: the caller ends up blocked for a second while holding mmap_lock, only to return -EAGAIN to the restore worker (or to userspace) which would have re-driven the operation immediately anyway. Drop the retry/timeout entirely and let -EBUSY propagate straight to out_free_pfns, where it is already translated to -EAGAIN. Recovery is handled at a higher level: the KFD restore_userptr_worker reschedules itself, and the userptr ioctl path returns -EAGAIN to userspace. No functional regression: the previous behaviour on -EBUSY was already to fail with -EAGAIN after a 1s stall; we just skip the stall. Reviewed-by: Christian König Signed-off-by: Honglei Huang Signed-off-by: Alex Deucher [ sashal: Removed the timeout/retry: loop and the -EBUSY special case; the only adaptation is keeping this tree's kzalloc'd struct hmm_range *hmm_range; declaration instead of upstream's &range->hmm_range context. ] Signed-off-by: Sasha Levin commit 5072f32330c71de91c1a844e7becaee48d743561 Author: Stefan Metzmacher Date: Fri Oct 23 19:26:09 2026 +0900 smb: smbdirect: fix buffer length underflow in RDMA transfers [ Upstream commit 7193241a49c958782ba4b8df06da3734d1e317d2 ] When a remote buffer descriptor is larger than the remaining local buffer, smbdirect_connection_rdma_xmit() clamps its length and sets buf_len to zero. The common accounting code then subtracts the clamped length from buf_len, causing it to underflow. If another descriptor follows, the loop processes it with a wrapped remaining length and includes memory beyond the local buffer in the RDMA transfer. A client can trigger an out-of-bounds kernel write with an SMB WRITE request, or an out-of-bounds kernel read with an SMB READ request, by supplying multiple RDMA buffer descriptors with an oversized descriptor before the last one. Remove the premature assignment to buf_len. Subtracting the clamped length already consumes the remaining buffer, so the next iteration stops and only descriptors within the local buffer are used to build work requests. Fixes: e628bf939aaf ("ksmbd: reduce descriptor size if remaining bytes is less than request size") Cc: stable@vger.kernel.org Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-33549 Signed-off-by: Stefan Metzmacher Signed-off-by: Namjae Jeon [ metze: in 6.12 the code is smb_direct_rdma_xmit() in fs/smb/server/transport_rdma.c ] Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Sasha Levin commit 383a883cf71525752a3092bba3c22aa1ab04df37 Author: Chris Mason Date: Fri Nov 6 05:11:25 2026 +0100 ovl: do not copy up a dentry that was removed commit f635192ad223d2009ee640b63adf5ce3198aa338 upstream. A change to a removed file through an open descriptor replaces whatever has its old name in the upper layer. Copy up must only create a name in the upper directory, never replace one. After an unlink, an rmdir or a rename over a lower dentry, a dentry that an open file keeps alive still has its old parent and name, but in the upper directory that name is now a whiteout or a new object. ovl_copy_up_workdir() renames the copy over it, which brings back the removed object and destroys whatever took its name. An unprivileged user opened a lower FIFO and unlinked it, root created a file at that name, and fchmod on the old descriptor replaced the file of root with the FIFO. Fix this by looking up the target name of the rename in ovl_copy_up_workdir() with LOOKUP_EXCL, so that copy up fails with -EEXIST if the name is taken, as copy up with O_TMPFILE already does when it links the copy to the name. Fixes: e9be9d5e76e3 ("overlay filesystem") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik [amir: use LOOKUP_EXCL instead of relying on d_unhashed()] Signed-off-by: Amir Goldstein [backport: no start_renaming_dentry() and LOOKUP_EXCL, fail with -EEXIST if the target of ovl_lookup_upper() is positive] Signed-off-by: Amir Goldstein Signed-off-by: Sasha Levin commit 862804fc1d8e6d11652d01f84451a0c9396d10cd Author: Chris Mason Date: Fri Nov 6 05:11:24 2026 +0100 ovl: hold a reference on the parent in readdir commit 16d319e12328acafeafd3eecdf09c46d7fb43452 upstream. Listing a directory on an overlay uses a freed dentry and crashes the kernel when a lookup moves the directory at the same time. Code that can sleep may only use d_parent without a reference while something stops a move of the dentry. ovl_iterate_real(), ovl_need_adjust_d_ino() and ovl_cache_update() use the d_parent of the listed directory and hold only the lock of that directory. When a lookup finds the directory under another parent after a change to a layer, d_splice_alias() moves it without that lock and drops its reference on the old parent. With a delay in ovl_iterate_real(), getdents64 on an overlay directory raced a rename in the lower layer and a lookup that moved its dentry, and after an rmdir of the old parent KASAN reported a use-after-free in security_inode_getattr(). Fix this by using dget_parent() in the three functions. Fixes: b5efccbe0a12 ("ovl: constant d_ino across copy up") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik [amir: fix comments in ovl_need_adjust_d_ino()] Signed-off-by: Amir Goldstein [backport: no ovl_need_adjust_d_ino(), take the parent with dget_parent() in ovl_iterate() and test a local flag] Signed-off-by: Amir Goldstein Signed-off-by: Sasha Levin commit a343bd631606d9d508808fca272e1e482ed6c61f Author: Chris Mason Date: Fri Nov 6 05:11:23 2026 +0100 ovl: check that the parents of volatile/dirty are dirs commit e34d2ef818e4c7676d8d8e1bf43e6a1ed39efb2a upstream. An unprivileged user crashes the kernel by mounting overlayfs with the volatile option. A dentry that serves as the parent of a lookup must be a directory. ovl_create_volatile_dirty() walks work/incompat/volatile/dirty by name, and ovl_lookup_or_create() returns an existing entry whatever its type. A file or a symlink that another task creates during the mount becomes the parent of the next lookup, which calls a NULL ->lookup. An unprivileged user mounted overlayfs with "volatile" in a user namespace while a second process created a symlink named work/incompat, and the mount task oopsed on a NULL ->lookup call. Fix this by returning -ENOTDIR from ovl_lookup_or_create() when the caller asked for a directory and the existing entry is a non-dir. Fixes: c86243b090bc ("ovl: provide a mount option "volatile"") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik Signed-off-by: Amir Goldstein [backport: no ovl_start_creating_upper(), check the child of ovl_lookup_upper() in ovl_lookup_or_create() instead] Signed-off-by: Amir Goldstein Signed-off-by: Sasha Levin commit d69100340b4cae08d40f898f1b601032403f6be6 Author: Hyunwoo Kim Date: Fri Oct 30 06:42:16 2026 +0900 inet: reject unhashed sockets during established lookups [ Upstream commit 4e2b3ef19e0e04adca38442f07dd6bc93c712bf1 ] TCP established ehash lookups are lockless. The socket caches involved use SLAB_TYPESAFE_BY_RCU, so memory can be reused before an RCU reader that retained its old address has finished. After a tuple match, __inet_lookup_established() and __inet6_lookup_established() acquire a reference and repeat the tuple check. They do not check whether the new object is hashed. If the address is reused for a socket with the same tuple, the lookup can acquire a reference to the new object and return it while its nulls node is unhashed. A PoC that drives reuse with a SYN cookie request socket reproduced the crash. The new request socket is unhashed and has a NULL rsk_listener. A lookup that had loaded the address of the old request socket acquired the reference published by tcp_get_cookie_sock() and returned the new object. tcp_v4_rcv() then read sk_state through the NULL listener. The resulting crash was: BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 7.3.0-00591-g0e135910deec #1 PREEMPT(lazy) ... RIP: 0010:tcp_v4_rcv+0x44e/0x1280 ... R10: 0000000000000001 R11: 00000000024ca8c0 R12: 0000000000000000 ... CR2: 0000000000000012 CR3: 0000000103d50004 CR4: 0000000000770ef0 ... Call Trace: ? raw_local_deliver+0xae/0x240 ip_protocol_deliver_rcu+0x2d/0x180 ip_local_deliver_finish+0x84/0x100 ip_sublist_rcv_finish+0x5f/0x70 ip_sublist_rcv+0x12a/0x1d0 ip_list_rcv+0xfd/0x130 __netif_receive_skb_list_core+0x223/0x250 netif_receive_skb_list_internal+0x1d2/0x2c0 ? try_fill_recv+0x39/0x7b0 napi_complete_done+0x74/0x170 virtnet_poll+0x445/0x600 __napi_poll+0x27/0x1e0 net_rx_action+0x2fe/0x3b0 handle_softirqs+0xc2/0x2c0 __irq_exit_rcu+0x74/0xd0 common_interrupt+0x7f/0x90 ... Kernel panic - not syncing: Fatal exception in interrupt After taking a reference, check whether the nulls node is unhashed in both IPv4 and IPv6 established lookups. If it is unhashed or the tuple no longer matches, drop the reference and restart the lookup. Lookups racing with the TIME_WAIT hashdance, or with a request being replaced by its child, now restart and find the new socket instead of returning the old one. Request sockets that were never inserted into ehash can have a nonzero refcount, and a stale lookup can hold a transient reference. Therefore, when SYN cookie, Fast Open, and request migration paths fail after setting a nonzero refcount, release the references held by those paths with reqsk_put() instead of freeing the request directly. Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Reviewed-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20261029214219.1035176-2-imv4bel@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 091c44b2d3c3cdc943f0a1fdfe63f210cb1da0c4 Author: Mike Rapoport (Microsoft) Date: Sun Sep 13 10:37:27 2026 +0300 x86/mm/pat: Use pr_warn() for early W^X warnings [ Upstream commit ea6fd393cb9e6811a748c7551de0dd3090f9dcde ] Nathan Chancellor reports the following warning: CPA detected W^X violation: 8000000000000123 -> 0000000000000123 range: 0xffffffffc0400000 - 0xffffffffc0400fff PFN 100e00 from its_alloc() doing set_memory_x() during early retpoline setup. The warning is not factually wrong but it is unproductive. First, the RWX permission is temporary and fixed up by execmem_restore_rox(). Second, at the time of the warning, all kernel text is mapped RWX. So there is not even a transient actual security issue. The right way to fix this up is to relax RWX detection during boot but make a final verification pass over all kernel page tables before running userspace. There is code to do that today (debug_checkwx()) but it must be enabled explicitly in Kconfig. For now, retain the warning even if it's unproductive, but make it scream less loudly: use pr_warn_once() rather than WARN_ONCE(). Remove the warning once debug_checkwx() behavior becomes unconditional. Closes: https://lore.kernel.org/all/20260905044253.GA3816371@ax162 Reported-by: Nathan Chancellor Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Dave Hansen Tested-by: Nathan Chancellor Tested-by: Ihor Solodrai Link: https://patch.msgid.link/20260913-fixes-verify-rwx-v3-1-5e1d6a08bd02@kernel.org Signed-off-by: Sasha Levin commit 39122e08c0ac5abc7c4ae537c169f085c9f21193 Author: Sean Christopherson Date: Thu Nov 5 12:08:12 2026 +0000 KVM: VMX: Formally define KVM's "0xdead" exit reason used for failed VM-Enter [ Upstream commit d85f7dc8cf3c91a131946dae4c3aa8d9c97322d7 ] Add EXIT_REASON_UNDEFINED to track KVM's magic "0xdead" value that's used to stuff the exit reason on a failed VM-Enter so that the magic can be reused by TDX, and to make it more obvious that it's an arbitrary, KVM- defined value (though the whole "dead" thing makes it pretty darn obvious). Opportunistically add a compile-time assert to ensure the KVM-defined exit reason never collides with a "real" exit reason. No functional change intended. Cc: Xiaoyao Li Cc: Yan Zhao Cc: Binbin Wu Cc: Rick Edgecombe Cc: stable@vger.kernel.org Reviewed-by: Binbin Wu Reviewed-by: Xiaoyao Li Link: https://patch.msgid.link/20260921235656.1107929-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Xiaoyao Li Signed-off-by: Sasha Levin commit dfd163fd06ea3b625631907d18b59f267520c7c3 Author: DaeMyung Kang Date: Tue Nov 3 17:04:45 2026 -0500 ksmbd: fix named stream write and EOF handling [ Upstream commit 02165c8d402392278a5cd2cf97645ed73a7ad4a1 ] An SMB WRITE to an existing named stream can silently discard data after its written range. ksmbd stores streams as xattr values, but the write path passes offset + count as the length of the replacement xattr even when the old stream is longer. Writing 26 bytes at offset 0 to a 60-byte stream reports 26 bytes written while discarding the remaining 34 bytes. Keep the existing xattr length when an in-place write ends before EOF. Reject writes that cross XATTR_SIZE_MAX rather than storing only the portion that fits while reporting the full requested count. Commit 4ea0bb8aaedf ("ksmbd: handle set/get info file for streamed file") intentionally skipped ordinary inode truncation for stream handles: an EOF SetInfo on an ADS had truncated the base file. That fixed the base file corruption but left stream EOF changes reporting success without resizing the stream. Handle these requests by resizing only the stream xattr; the base file size remains untouched. Zero-fill stream extensions. This is needed alongside the write fix: a short write's accidental truncation previously masked an ignored explicit EOF change. The stream resize helper returns xattr errors directly rather than using the base-file truncate path's EBADF conversion. Fixes: f44158485826 ("cifsd: add file operations") Fixes: 4ea0bb8aaedf ("ksmbd: handle set/get info file for streamed file") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon [ sashal: adapted fp->stream.pos updates to fp->filp->f_pos because the separate stream position field is absent ] Signed-off-by: Sasha Levin commit 60269faa92542140fc318783beddf27d6edfceda Author: DaeMyung Kang Date: Tue Nov 3 16:37:57 2026 -0500 ksmbd: use the existing xattr name for a named stream [ Upstream commit a7d1d52748e0fe4d06fdb871fc9899904fbba93f ] SMB stream names are case-insensitive, but ksmbd stores each named stream in an xattr whose name is case-sensitive. Opening an existing stream finds its xattr with a case-insensitive match, yet the handle keeps the name as the client spelled it, and every later operation that needs an exact name uses that spelling: - a WRITE or an end-of-file change creates a second xattr, so a stream created as "Foo" and written through "foo" ends up stored twice, and which value a later lookup returns depends on xattr list order; - delete-on-close and delete-pending removal can fail with -ENODATA, or remove only a case-variant copy and leave the original; - the share mode check compares stream names with strcmp(), so two opens of the same stream that differ only in case do not conflict. Have ksmbd_vfs_casexattr_len() copy the matching xattr's name into the handle when the stream is opened, so later operations use the name already on disk. The match must have the same length as the name it replaces; the stream lookup passes a length that includes the terminating NUL, which already guarantees that, and the check makes the copy safe for any caller. A stream that does not exist yet keeps the client's spelling, as before. smb2_rename() compares and looks up fp->stream.name case-insensitively, so it behaves the same with either spelling. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon [ sashal: adapted the ksmbd_vfs_casexattr_len() call-site update to get_file_stream_info() ] Signed-off-by: Sasha Levin commit 5a04348b4492fe993ed709e601f01877e5dab220 Author: Henry Hu Date: Tue Nov 3 16:37:31 2026 -0500 ksmbd: fix invalid pointer dereference when get_inode_acl() fails [ Upstream commit 19d180c7baab7126af5848ed87d5f7b5add0cef2 ] When get_inode_acl() fails, it returns an ERR_PTR(), but ksmbd_acls_fattr() stored that pointer in smb_fattr without checking for errors. Later callers then passed the error pointer to security descriptor helpers or posix_acl_release(), resulting in an invalid pointer dereference. This was reproduced on an XFS-backed share when xfs_get_acl() returned ERR_PTR(-ENOMEM). Querying the SMB ACL from a CIFS client triggered the crash: BUG: unable to handle page fault for address: fffffffffffffff8 RIP: smb_acl_sec_desc_scratch_len+0x58/0x90 [ksmbd] Call Trace: smb2_query_info+0x40d/0x17c0 [ksmbd] handle_ksmbd_work+0x1ca/0x770 [ksmbd] Fix this by checking the return values from get_inode_acl() in ksmbd_acls_fattr(). Treat -EOPNOTSUPP as indicating that no ACL is available, and propagate all other errors to the callers. Update smb2_open() and smb2_get_info_sec() to handle these errors. Cc: stable@vger.kernel.org Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Assisted-by: Codex:gpt-5.6-sol Reviewed-by: ChenXiaoSong Signed-off-by: Henry Hu Signed-off-by: Namjae Jeon [ sashal: kept the struct mnt_idmap parameter of ksmbd_acls_fattr() non-const ] Signed-off-by: Sasha Levin commit b2d710b12e86fd4cf02be090651fa6ea8683fc29 Author: Ian Bridges Date: Tue Nov 3 11:39:36 2026 -0500 ksmbd: fix session reference leak on compounded SESSION_SETUP [ Upstream commit 03bd8f5279e490e15e0c0f0fa388ffbd2fbacd65 ] A compound request can place SESSION_SETUP after another command. That earlier command leaves a reference to its session in work->sess. smb2_sess_setup() then overwrites work->sess with the session it looks up or creates, and the dispatcher later puts work->sess only once. The inherited reference is never dropped. That leaks the session, together with its setup connection and socket, and every repeat of the compound leaks another. unreferenced object (size 512): __kmalloc_cache_noprof+0x32c/0x3a0 ksmbd_smb2_session_create+0xf6/0x9c0 [ksmbd] smb2_sess_setup+0xda4/0x6280 [ksmbd] handle_ksmbd_work+0x88c/0x1cb0 [ksmbd] Save the inherited session on entry. After the request has been processed, release it once, but only when smb2_sess_setup() has replaced work->sess with its own session or cleared it. Do this after ksmbd_conn_unlock() so the put does not run under srv_mutex. An error path may instead leave the inherited session in work->sess. Keep it there, so the dispatcher still puts it and the error response is still signed or encrypted with it as before. Fixes: 7aa8804c0b67 ("ksmbd: fix user-after-free from session log off") Cc: stable@vger.kernel.org Signed-off-by: Ian Bridges Signed-off-by: Namjae Jeon [ sashal: omitted the installed flag update for the absent early work->sess assignment ] Signed-off-by: Sasha Levin commit 0efcfd3afbd7ac3737979732099f9e1efe378a58 Author: Mario Peter Date: Tue Nov 3 09:59:05 2026 -0500 driver core: take parent lock in async device attach [ Upstream commit 187a62f99da29b1a55602b0d401a783d8dc86161 ] For device types with need_parent_lock set (only USB interfaces), probe() must run with the parent device locked. A synchronous attach after device_add() gets this from the caller, e.g. usb_set_configuration() holds the udev lock while adding interfaces. __device_attach_async_helper() runs the probe from an async worker instead, where that lock isn't held, and only takes device_lock(dev). With async probing enabled for the hub driver (e.g. driver_async_probe=* or driver_async_probe=hub), this races when a multi-TT hub is configured. For multi-TT hubs, hub_probe() calls usb_set_interface(hdev, 0, 1) to select the TT-per-port altsetting, and usb_set_interface() creates the endpoint devices of the interface a second time: usb_set_configuration() async worker [udev locked] device_add(intf) queues the probe ----------> __device_attach_async_helper() [intf locked, udev not locked] hub_probe() usb_set_interface(hdev, 0, 1) create_intf_ep_devs(intf) create_intf_ep_devs(intf) create_intf_ep_devs() checks and sets intf->ep_devs_created without a lock of its own. If usb_set_configuration() has created ep_81 but not yet set the flag, usb_set_interface() skips removing the endpoint devices of the old altsetting and creates ep_81 again. With a synchronous probe, hub_probe() runs inside device_add() with the udev lock held, and usb_set_configuration() then finds ep_devs_created already set. Single-TT hubs don't call usb_set_interface() from hub_probe() and don't show this warning, but their probe runs without the udev lock as well. On an i.MX8MM board with an onboard USB2514 hub this hit 11 of 100 boots: sysfs: cannot create duplicate filename '.../1-1/1-1:1.0/ep_81' Call trace: sysfs_warn_dup usb_create_ep_devs create_intf_ep_devs usb_set_interface hub_probe usb_probe_interface really_probe __device_attach_async_helper async_run_entry_fn It also shows on v7.3-rc6 in QEMU, with dummy_hcd and a raw-gadget program emulating a multi-TT hub: re-authorizing the hub in a loop, while a SCHED_FIFO task preempts the writing task at random points for 3 ms, hit the warning in 29 of 6000 iterations. Take the parent lock in __device_attach_async_helper() as well, like __driver_attach_async_helper() does, and move __device_driver_lock/unlock() up for that. With this the warning was gone in 300 boots on the board and in 6000 iterations in QEMU. Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for drivers") Signed-off-by: Mario Peter Cc: stable@vger.kernel.org # 4.2 Cc: Dmitry Torokhov [ johan: switch to async_schedule_dev_nocall() to avoid deadlock if async_schedule_dev() runs synchronously when parent lock is held ] Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20261014133109.1392265-4-johan@kernel.org [ Fold the nested conditions into a single if statement; correct commit message to mention "device types" rather than "buses" for "need_parent_lock". - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 45984a2bc79215f7715873f67ecfe8cae416fcb2 Author: Vincent Liu Date: Tue Nov 3 09:59:04 2026 -0500 driver core: Check drivers_autoprobe for all added devices [ Upstream commit ea34511aaf755349999a1067b2984a541bee1492 ] When a device is hot-plugged, the drivers_autoprobe sysfs attribute is not checked (at least for PCI devices). This means that drivers_autoprobe is not working as intended, e.g. hot-plugged PCI devices will still be autoprobed and bound to drivers even with drivers_autoprobe disabled. The problem likely started when device_add() was removed from pci_bus_add_device() in commit 4f535093cf8f ("PCI: Put pci_dev in device tree as early as possible") which means that the check for drivers_autoprobe which used to happen in bus_probe_device() is no longer present (previously bus_add_device() calls bus_probe_device()). Conveniently, in commit 91703041697c ("PCI: Allow built-in drivers to use async initial probing") device_attach() was replaced with device_initial_probe() which faciliates this change to push the check for drivers_autoprobe into device_initial_probe(). Make sure all devices check drivers_autoprobe by pushing the drivers_autoprobe check into device_initial_probe(). This will only affect devices on the PCI bus for now as device_initial_probe() is only called by pci_bus_add_device() and bus_probe_device(), but bus_probe_device() already checks for autoprobe, so callers of bus_probe_device() should not observe changes on autoprobing. Note also that pushing this check into device_initial_probe() rather than device_attach() makes it only affect automatic probing of drivers (e.g. when a device is hot-plugged), userspace can still choose to manually bind a driver by writing to drivers_probe sysfs attribute, even with autoprobe disabled. Any future callers of device_initial_probe() will respect the drivers_autoprobe sysfs attribute, which is the intended purpose of drivers_autoprobe. Signed-off-by: Vincent Liu Link: https://patch.msgid.link/20251022120740.2476482-1-vincent.liu@nutanix.com Signed-off-by: Greg Kroah-Hartman Adapt the bus-side change to __bus_probe_device(), which is shared by the normal and deferred probe entry points. Preserve the deferred probe wrapper and its parent locking. Retain this change to provide the device_initial_probe() layout needed by the asynchronous attach parent-lock fix. PCI still calls device_attach() directly, so this change does not alter PCI probing. Stable-dep-of: 187a62f99da2 ("driver core: take parent lock in async device attach") Signed-off-by: Sasha Levin commit d2d6546f0c2b5149a2abb7cb5f1ff29d536e6d03 Author: Xiaoyao Li Date: Thu Nov 5 12:13:20 2026 +0000 KVM: VMX: Preserve negative return value in vmx_handle_exit() with bus lock detected [ Upstream commit cef48693da1e964e9f192bfc16cd0ed287c48337 ] Preserve the negative return value from __vmx_handle_exit() when a bus lock is detected, instead of always overwriting it with 0. The purpose of bus_lock_detected handling is to force a userspace exit to inform userspace that a bus lock happened. The negative return value can achieve this purpose, and changing the negative value to 0 fails to return an error to userspace. So, preserve the negative return value. Fixes: fe6b6bc802b4 ("KVM: VMX: Enable bus lock VM exit") Cc: stable@vger.kernel.org Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260805034602.5B2BB1F000E9@smtp.kernel.org/ Signed-off-by: Xiaoyao Li Link: https://patch.msgid.link/20260819094903.3060020-7-xiaoyao.li@intel.com Signed-off-by: Sean Christopherson Signed-off-by: Xiaoyao Li Signed-off-by: Sasha Levin commit 5078a4e41b29acdf6be52e4a7cc8a59c2a72a471 Author: Ian Bridges Date: Tue Nov 3 18:28:19 2026 -0500 ksmbd: fix use-after-free after a failed durable reconnect [ Upstream commit 248b5819591c577727930e4e255a455235fab50a ] ksmbd_reopen_durable_fd() republishes a detached durable handle in the reconnecting session's file table and takes no reference for that entry. If smb2_open() then fails, cleanup relies on the final ksmbd_fd_put() to remove the volatile id. Two reconnects of the same handle can both take a lookup reference before either attaches it. If the one that reopens first then fails and drops its references first, the other request makes the final put through ksmbd_put_durable_fd(). That frees the handle without removing the first session's table entry, so tearing that session down writes to freed memory. BUG: KASAN: slab-use-after-free in __close_file_table_ids+0x14d/0x740 [ksmbd] Call Trace: __close_file_table_ids+0x14d/0x740 [ksmbd] ksmbd_destroy_file_table+0x76/0x100 [ksmbd] ksmbd_session_destroy+0xf8/0x480 [ksmbd] ksmbd_dispose_sessions+0x13e/0x200 [ksmbd] ksmbd_conn_sessions_cleanup+0x4c3/0x6d0 [ksmbd] Freed by task 1030: __ksmbd_close_fd+0x97d/0x1000 [ksmbd] smb2_open+0x14eb/0xd9f0 [ksmbd] Commit 3515503322f4 ("ksmbd: fix durable reconnect error path file lifetime") handles a final put made by the reconnecting request, but not one made by another holder. Remove the volatile id under the file-table lock on this error path, before the references are dropped, as ksmbd_close_fd() does on the request_open path just above. Removal then no longer depends on which holder makes the final put. The stale comment in the reconnect cleanup is updated to match. A successful reconnect is unchanged. Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Cc: stable@vger.kernel.org Signed-off-by: Ian Bridges Signed-off-by: Namjae Jeon [ sashal: adapted cleanup to the simpler if (fp) error path in smb2_open() ] Signed-off-by: Sasha Levin commit b150049dffd0865fb6e60ce843299216687f02ad Author: Dairui Zhang Date: Tue Nov 3 17:39:52 2026 -0500 ksmbd: verify transform SessionId matches the decrypted header [ Upstream commit 798214e6fafcdcc29f5ba2661a473232b5e70cfb ] When an encrypted request comes in, the decryption key is picked by the SessionId in the transform header, but the request is then authorized under whatever session the decrypted inner header names. Nothing ever compares the two, so on a connection with more than one session a client can get a request decrypted with one session's key and run it as another session. Encrypted requests are exempt from signing too, so a valid AEAD tag is the only proof of session identity, and it is checked against the wrong session. MS-SMB2 says the server must check that the transform SessionId matches the one in the decrypted SMB2 header and treat a mismatch as a protocol error. Add that check in __handle_ksmbd_work() after decryption, before dispatching: the message has to be at least one fixed SMB2 header, the first operation must not set SMB2_FLAGS_RELATED_OPERATIONS and its SessionId must match the transform SessionId, and every following non-related operation in a compound chain must carry the same SessionId. NextCommand offsets must be 8-byte aligned and stay inside the message; the bounds check is done by subtraction so it cannot wrap. When the decrypted payload is a compression transform, the existing decompression step runs first and the decompressed SMB2 message is checked instead, since a compression transform header carries no SessionId. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Reported-by: Dairui Zhang Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Dairui Zhang Signed-off-by: Namjae Jeon [ sashal: adjusted context to match the existing decryption flow ] Signed-off-by: Sasha Levin commit f4d6f211be04c9b018ce4cfb9793ea1f48c150c3 Author: Ian Bridges Date: Tue Nov 3 16:38:08 2026 -0500 ksmbd: fix out-of-bounds read when padding the final compound response [ Upstream commit 714f27729121d59f103ca4dad7b0c2d1c125cd71 ] Compound response handling pads the last response of a compound to an 8-byte boundary by growing the final iov and the RFC1002 length. smb2_allocate_rsp_buf() allocates exactly response_sz. A command can fill the response buffer to within 7 bytes of its end, for example a QUERY_INFO whose output is bounded only by the space left. The padding can then run past the allocation, and ksmbd_tcp_writev() reads those bytes when it sends the response. BUG: KASAN: slab-out-of-bounds in _copy_from_iter+0x744/0x10e0 Call Trace: _copy_from_iter+0x744/0x10e0 tcp_sendmsg_locked+0x2290/0x3f80 ksmbd_tcp_writev+0x10c7/0x1ab0 [ksmbd] Allocate room for the padding when the request is a compound, as smb2_read() and smb2_read_pipe() do for their payloads. response_sz is unchanged, so commands still fill only up to it, and kvzalloc() zeroes the padding. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Ian Bridges Signed-off-by: Namjae Jeon [ sashal: adjusted context for direct work->conn->vals access instead of a local vals variable ] Signed-off-by: Sasha Levin commit 007eaa56b06fd05c55b86afabab3354ff7c24653 Author: Namjae Jeon Date: Tue Nov 3 11:57:51 2026 -0500 ksmbd: prevent share root removal through empty paths [ Upstream commit 9fd1fcbbf84986a7bcf601a2b90540899069d263 ] A FileLinkInformation request can supply "/" as the new link name. smb2_get_name() strips the trailing slash and passes an empty string to ksmbd_vfs_kern_path_start_removing(). ksmbd_vfs_path_lookup() resolves an empty pathname as the configured share path, without LOOKUP_BENEATH. With ReplaceIfExists set, smb2_create_link() can therefore remove the share root from its parent before link creation fails. An authenticated client with a writable share and DELETE access to a file can trigger this if the share root is empty and the mapped user has write and search permission on its parent directory. Return -EINVAL for empty pathnames when for_remove is set, before resolving the share path or acquiring removal resources. Ordinary lookups continue to accept empty pathnames for opening the share root. Fixes: 74d7970febf7 ("ksmbd: fix racy issue from using ->d_parent and ->d_name") Cc: stable@vger.kernel.org Reported-by: Zachariah Mithani (AploSec) Signed-off-by: Namjae Jeon [ sashal: Moved the empty-name guard to smb2_create_link() because the lookup helper lacks the for_remove parameter. ] Signed-off-by: Sasha Levin commit 139e8a3d6edd0c5b5dfe4ada2f636146e1209dc3 Author: Namjae Jeon Date: Tue Nov 3 11:39:43 2026 -0500 ksmbd: prevent stale data from being written by SMB2 WRITE requests [ Upstream commit bc0e0f5ac1d7b044d403f859406b4b66d4b1ce9b ] Initialize the compatibility byte in request buffers without zeroing the entire allocation. Keep the one-byte compatibility exception for SMB2 messages so valid zero-length WRITE requests remain compatible, and validate the data range in the WRITE handlers against the current compound request before accessing it. This prevents stale request-buffer data from being written to files or sent to IPC pipes. Fixes: 443d61d1fa9f ("ksmbd: allocate one more byte for implied bcc[0]") Cc: stable@vger.kernel.org Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-32436 Signed-off-by: Namjae Jeon [ sashal: replaced smb2_current_req_len() calls with inline request-length calculations using NextCommand and the receive-buffer offset ] Signed-off-by: Sasha Levin commit 0c96f614876e251ae9d6764e8d52d6544fef0424 Author: Aamir Ahmed Date: Tue Nov 3 10:34:14 2026 -0500 ksmbd: deny access for an empty DACL instead of granting the request [ Upstream commit de0cffef897c1c232ed973f89928cd6c93d0b1e3 ] smb_check_perm_dacl() returns the access mask it computes to the SMB2 CREATE handler, which uses it as the granted access for the open. For a security descriptor whose DACL is present but contains no ACEs, the function is supposed to deny access: an empty (non-NULL) DACL grants no access to anyone except the object owner's implicit READ_CONTROL and WRITE_DAC (MS-DTYP 2.4.5). The empty-DACL branch only denies when both - the DACL has no trailing bytes (pdacl_size == sizeof(struct smb_acl)), and - the request contains bits beyond READ_CONTROL / WRITE_DAC. In every other case it takes the shared "goto err_out" with rc still 0, which returns success without modifying *pdaccess, so the caller grants the full requested access. Three problems follow: - The READ_CONTROL / WRITE_DAC carve-out models the owner's implicit rights, but the check runs before is_owner is computed, so those rights are handed to *every* caller, not just the owner. For READ_CONTROL the SMB2 CREATE path does not fall back to inode_permission(), so any user can read the security descriptor of an object whose empty DACL is meant to deny them. - A request of exactly READ_CONTROL and/or WRITE_DAC is granted to any caller. WRITE_DAC lets the handle rewrite the DACL. - A DACL that declares zero ACEs but carries trailing bytes (pdacl_size > sizeof(struct smb_acl)) skips the deny entirely and is granted whatever was requested. On shares where the NT ACL is the authoritative access control -- e.g. "force user" shares, where every client maps to one POSIX identity so POSIX cannot distinguish users -- this is an access-control bypass. Compute is_owner before the empty-DACL branch and deny access from an empty DACL unless the caller is the owner requesting no more than READ_CONTROL / WRITE_DAC. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Aamir Ahmed Signed-off-by: Namjae Jeon [ sashal: added the missing mount-mapped UID ownership calculation for is_owner ] Signed-off-by: Sasha Levin commit 6c1ccd31b3a995a1a73e10e7bc8b6d96cf382241 Author: Zikang Gao <2715417602@qq.com> Date: Mon Nov 2 18:01:08 2026 -0500 smb: client: do not pass a NULL buf to is_oplock_break() [ Upstream commit 2225ab306575e424b3dad2ee1be2521c89249d15 ] receive_encrypted_read() sets *num_mids = 1 and never writes the caller's bufs[]. Offload returns -1 with *num_mids = 0, so the demultiplex thread skips the frame. The inline decrypt path returns 0 even when smb2_find_mid() fails. cifs_demultiplex_thread() then treats mids[i] == NULL as an oplock break and calls is_oplock_break(bufs[i], server) with bufs[i] still NULL. smb2_is_valid_oplock_break() reads hdr.Command at offset 12 and oopses. A large encrypted READ whose MessageId does not match is enough to panic cifsd. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 100 Comm: cifsd RIP: smb2_is_valid_oplock_break+0xc8/0x2270 [cifs] cifs_demultiplex_thread Kernel panic - not syncing: Fatal exception Return -1 when inline decrypt finds no mid, and skip is_oplock_break() plus the unknown-frame dump when bufs[i] is NULL. receive_encrypted_standard() already assigns bufs[*num_mids]. Fixes: c42a6abe3012 ("CIFS: Add capability to decrypt big read responses") Assisted-by: LLM Signed-off-by: Zikang Gao <2715417602@qq.com> Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Cc: stable@vger.kernel.org [ sashal: adjusted context for direct MID callbacks and release_mid() without a server argument ] Signed-off-by: Sasha Levin commit cfaec5094017bd9d41a0572325ec2cec4f7d5e31 Author: Fredric Cover Date: Mon Nov 2 18:00:55 2026 -0500 smb: client: fix early procfs exposure race [ Upstream commit 7b1afb631395c958993cda4631002258ef4151ea ] Currently, init_cifs() calls cifs_proc_init() near the beginning of the function, before INIT_LIST_HEAD, leading to a momentarily uninitialized, but exposed, procfs. If a userspace process reads this empty procfs, iterating over a zeroed list_head leads to a NULL pointer dereference and a kernel oops/panic. For example, if a delay is added between cifs_proc_init() and INIT_LIST_HEAD, and a userspace process is polling /proc/fs/cifs/DebugData, the following oops occurs: BUG: kernel NULL pointer dereference, address: 0000000000000608 Oops: Oops: 0000 [#1] SMP PTI CPU: 0 UID: 0 PID: 3477 Comm: cat Not tainted 7.3.0-02212-g4df4d2a577db-dirty #6 PREEMPT(lazy) RIP: 0010:cifs_debug_data_proc_show+0x103/0xd80 [cifs] Call Trace: ? seq_read_iter+0x86/0x400 ? seq_read_iter+0x86/0x400 seq_read_iter+0x183/0x400 proc_reg_read_iter+0x62/0x90 copy_splice_read+0x215/0x310 splice_file_to_pipe+0xec/0x1c0 do_splice+0x4b8/0x780 __se_sys_splice+0x18f/0x250 do_syscall_64+0x109/0x330 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by moving cifs_proc_init() down in init_cifs(), ensuring it runs only after all internal lists, locks, counters, and workqueues are fully ready, but before registering the filesystem. Update the error cleanup ladder and exit_cifs() to maintain proper LIFO order. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Fredric Cover Cc: stable@vger.kernel.org Signed-off-by: Paulo Alcantara [ sashal: Adjusted context for absent maperror initialization calls and a workqueue declaration without WQ_PERCPU. ] Signed-off-by: Sasha Levin commit 8cf9517996067cfbfc5abdb4cfb3d7e15a7b34a3 Author: Zi Yan Date: Wed Nov 4 10:56:48 2026 -0500 mm/rmap: don't discard lazyfree THPs at PMD level [ Upstream commit 984c0700854e35779a2bcce6b02783e709b6efa2 ] __discard_anon_folio_pmd_locked() clears a lazyfree THP's PMD before it determines whether the folio can be discarded, and restores it if the folio is dirty or has extra references. It is done under only the PMD lock and the anon_vma read lock inside try_to_unmap_one() and no mmap lock is held. The temporarily none PMD causes UAF. A parallel munmap() or mremap() is supposed to serialize with it on the PMD lock, but zap_pmd_range() (called by munmap()) and move_page_tables() (called by mremap()) do not take the lock when they see the temporarily none PMD and skip the PMD. There is no more page table walk after the none PMD is restored: - munmap(): free_pgtables() waits in unlink_anon_vmas() for the anon_vma lock, then free_pmd_range() drops the restored PMD as bad without removing the rmap, so the folio keeps a stale mapcount. - whole-VMA MREMAP_DONTUNMAP: dontunmap_complete() unlinks the source VMA from its anon_vma while the restored PMD still maps the folio. - plain mremap(): the THP is not moved but unmapped, so the THP's data is lost. In the first two cases, the folio stays mapped, but no VMA that maps it is linked to its anon_vma. When the anon_vma is freed, it is still reachable when one rmap walks the folio. Racing lazyfree reclaim against MREMAP_DONTUNMAP as an unprivileged user reproduces a KASAN use-after-free in folio_lock_anon_vma_read() as reported in the Closes link. One solution is to use an invalidated PMD instead of a cleared one until the discard is committed, but it needs arch fixes first. 1. GUP-fast still follows an invalidated PMD on riscv, LoongArch and s390. 2. sparc64 miscounts thp_pte_count when an invalidated PMD is set again or cleared. To keep the fix simple for backport, stop discarding lazyfree THPs at PMD level instead. try_to_unmap_one() splits the PMD and discards the folio at PTE level. unmap_huge_pmd_locked() and __discard_anon_folio_pmd_locked() are left in place, unused, to minimize this fix for backport and the invalidated PMD approach is planned as a follow-up series to use them again. Link: https://lore.kernel.org/20261012-lazyfree-stable-fix-v2-1-6387d6e30063@nvidia.com Fixes: 735ecdfaf4e8 ("mm/vmscan: avoid split lazyfree THP during shrink_folio_list()") Signed-off-by: Zi Yan Signed-off-by: Andrew Morton Reported-by: Kyle Zeng Closes: https://lore.kernel.org/r/20261009165214.40212-2-kylebot@openai.com Reviewed-by: Kyle Zeng Reviewed-by: Lance Yang Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Tested-by: JongHyuk Kim(MalHyuk) Link: https://lore.kernel.org/CADQRuqvXQ=YE=7T3oR66vTxE33pi=ygEeZKPTOU=cALZL0Figw@mail.gmail.com Assisted-by: LLM Cc: Rik van Riel Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Harry Yoo Cc: Jann Horn Cc: Signed-off-by: Zi Yan Signed-off-by: Sasha Levin commit e0d98aab41b79b88609f33fb4d8e7a80ab8f648d Author: David Woodhouse Date: Tue Oct 20 10:48:10 2026 +0100 tun: Require CAP_NET_ADMIN to attach to an ownerless device commit ffdf678dd16610e3f006dac904bd37c09684673c upstream. Twenty years ago I made creating a tuntap device require CAP_NET_ADMIN in commit ca6bb5d7ab22 ("[NET]: Require CAP_NET_ADMIN to create tuntap devices.") The idea was to allow the permissions on /dev/net/tun to be relaxed to 0666 and thus allow owners of tun devices assigned with TUNSETOWNER to actually open it and get at their devices. What we missed at the time was that persistent devices with *no* owner were already essentially world-consumable, and anyone who could open the device node could also attach to those. Even then, using persistent devices with no explicitly set owner — on the (false) presumption that CAP_NET_ADMIN would be required to open them — wasn't an egregious userspace bug. There are cases where it does make sense to separate the creation/configuration of the netdevice, from the process which shovels packets into it. Since then, TUNSETGROUP was added a year later in commit 8c644623fe7e ("[NET]: Allow group ownership of TUN/TAP devices."). Its commit message noted that if both uid and gid are set, both have to match (in itself a bizarre choice) — but still not that with *neither* set, no permission at all was required. Then in 2012 commit c8d68e6be1c3 ("tuntap: multiqueue support") allowed new queues to be attached to a device from the moment of its creation, with no way for userspace to close the race between creation and a subsequent TUNSET{OWNER,GROUP}. In 2024, commit 3ca459eaba1bf ("tun: fix group permission check") tried to fix things to be saner: only require the user *or* the group to match, in line with standard POSIX permissions, and require CAP_NET_ADMIN if neither the user nor group authorised the access (although it put the CAP_NET_ADMIN check first, and would wrongly have reported the capability as having been used even when it was not). That fix was reverted in commit a70c7b3cbc06 ("tun: revert fix group permission check") due to allegedly causing a regression in an selinux test suite which *expected* the attachment to succeed when authorised by none of user, group, nor CAP_NET_ADMIN: https://lore.kernel.org/netdev/CAFqZXNtkCBT4f+PwyVRmQGoT3p1eVa01fCG_aNtpt6dakXncUg@mail.gmail.com/ We should not break UAPI. But we don't have to consider an selinux test case which deliberately exercises a security flaw to be UAPI worth preserving either. To which end, I have fixed it in selinux-testsuite commit b2f894f0016b ("tests/tun_tap: set an owner on the device for the relabel tests"). So: fix the lack of CAP_NET_ADMIN check on devices which *haven't* been assigned an owner or group, while leaving the weird tun ownership model as it was (user *and* group have to match, if both are set). If someone still wants to fix the latter (which wasn't actually the reason the previous attempt was reverted), they can do it under separate cover. Permit attaching to an existing device only if an owner and/or group was set and the caller matches all that were set, or if the caller has CAP_NET_ADMIN. The only behavioural change is that a device with no owner or group now requires CAP_NET_ADMIN to attach — precisely the loophole we want to close. And put the CAP_NET_ADMIN check in the right place this time. Fixes: ca6bb5d7ab22 ("[NET]: Require CAP_NET_ADMIN to create tuntap devices.") Reported-by: Andrew Lutomirski Signed-off-by: David Woodhouse Cc: stable@vger.kernel.org Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/3c77f88acff5b3c2617b22d64faad15f6212619c.camel@infradead.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 79afb60ab43bf1db9fbebbd0326fb08d09a70540 Author: Peter Griffin Date: Tue Sep 8 12:37:27 2026 +0000 opp: fix use after free in _update_opp_table_clk() commit 1f6de65e3314519ce462bfd3a1d29e918f97e4e5 upstream. dev_pm_opp_put_opp_table() frees the opp_table which is subsquently used by dev_err_probe(). This causes an Oops during boot on gs101-oriole. cpu cpu0: error 000000006b6b6b6b: Couldn't find clock Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cd3 ... Hardware name: Oriole (DT) pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _of_add_table_indexed+0x80/0xbb0 lr : _of_add_table_indexed+0x6c/0xbb0 ... Call trace: _of_add_table_indexed+0x80/0xbb0 (P) dev_pm_opp_of_cpumask_add_table+0x70/0x120 dt_cpufreq_probe+0x23c/0x480 platform_probe+0x64/0xb8 Fixes: 84f05af0975c9 ("opp: Use clk_get_optional() to avoid leaving opp_table->clk as an error pointer") Signed-off-by: Peter Griffin Reviewed-by: Tudor Ambarus [ Viresh: use return value of dev_err_probe() ] Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit ea9137859d913a21aab5a3fe06414890159793a7 Author: Pablo Neira Ayuso Date: Mon Aug 10 10:18:22 2026 +0200 netfilter: conntrack: always lower timeout for non-closing RST packets commit 73df81b38cb7f70a347a97370386378a86e53019 upstream. The existing check might extend the timeout if the ESTABLISHED timeout has been tuned to be lower than UNACK via sysctl. Reported by sashiko. Fixes: bf80e6802273 ("netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit d1f5c16b97d4ce8f3316852d91385d8e4cc1c86a Author: Srinivasan Shanmugam Date: Thu Jun 25 10:25:24 2026 +0530 drm/amdgpu/powerplay: Align get_tonga_state_array() header with prototype commit 4986757d3207383c052689532e505edccc6df7c8 upstream. The function header above get_tonga_state_array() still refers to check_powerplay_tables() and does not describe all of the function parameters. Update it to match the current function prototype and include the missing parameter description. Fixes: 1ac24df78c56 ("drm/amd/pm: Validate Tonga PowerPlay state array bounds") Cc: Yang Wang Cc: Hawking Zhang Signed-off-by: Srinivasan Shanmugam Reviewed-by: Yang Wang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4e34aa7e0302a360a8f94048b36f4762a287aa12 Author: Sean Young Date: Wed Sep 23 09:32:02 2026 +0100 media: rc: Fix build failure with CONFIG_LIRC disabled commit 0c795849fd70d6bdb99aea5dd08d9b43128612f6 upstream. commit 37efd09ba2c6 ("media: rc: Ensure registered is cleared in error path") broke the build if CONFIG_LIRC was not enabled. Fixes: 37efd09ba2c6 ("media: rc: Ensure registered is cleared in error path") Reported-by: kernel test robot Link: https://lore.kernel.org/oe-kbuild-all/202609230511.Em5Osw74-lkp@intel.com Signed-off-by: Sean Young Signed-off-by: Greg Kroah-Hartman commit ea2c32cb4d2440aeea214f685b3bfaf4f96f8116 Author: Cheng Yongkang Date: Wed Nov 4 11:43:53 2026 -0700 io_uring/timeout: count cancelled timeouts in cq_timeouts Commit 1c8b49851543f41fc8bb18bcd1f15cc93d14b530 upstream. io_timeout_cancel() posts the cancelled timeout's -ECANCELED CQE without advancing ctx->cq_timeouts. io_timeout_fn() and io_kill_timeout() advance it for every timeout CQE they post, and io_flush_timeouts() computes the number of non-timeout completions as seq = cached_cq_tail - cq_timeouts to compare against each off timeout's target_seq. The cancelled timeout's CQE is therefore counted as a regular completion, so every cancellation makes an already armed off timeout fire one completion early. A ring with a keep-alive timeout of off=4 completes it after two NOPs when one off=100 victim is cancelled through IORING_OP_ASYNC_CANCEL, and before any NOP when two victims are cancelled. The cancel CQE should count, but the cancelled timeouts' -ECANCELED CQEs must not: the expected counts are three and two NOPs respectively. Advance cq_timeouts when io_timeout_extract() succeeds, under timeout_lock and before the -ECANCELED completion is queued, matching io_timeout_fn() and io_kill_timeout(). The -ENOENT and -EALREADY paths post no new timeout CQE and keep their accounting. Both the ASYNC_CANCEL and the TIMEOUT_REMOVE path go through io_timeout_cancel(). Fixes: bfe68a221905 ("io_uring: off timeouts based only on completions") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Cheng Yongkang Link: https://patch.msgid.link/179328314078.648427.13761781546953594668@gmail.com Signed-off-by: Jens Axboe [axboe: 6.12 uses a regular spinlock for ->timeout_lock] Signed-off-by: Greg Kroah-Hartman commit a85561cc4fc542443c9e3c363f8bcb2c016da68e Author: Chris Mason Date: Wed Nov 4 11:43:52 2026 -0700 io_uring/sqpoll: don't wait for the thread to exit Commit 360395e8dbf9d23579f74b84a1af11190813b0f8 upstream. io_sq_thread_stop() wakes the SQPOLL thread and waits for it to exit. The thread belongs to the thread group that created the ring, so a SIGSTOP or the cgroup freezer holds it in get_signal(), and the wake up doesn't change that. io_ring_exit_work() then sleeps in that wait until someone continues or kills the process. iou_exit has 64 slots, so 64 closed SQPOLL rings of a stopped process keep every other ring from being freed, for everyone. Don't wait. Set the stop bit, wake the thread, and let it exit when it gets to run again. The sqd can now outlive its last ring, so give it a second refcount with one reference for the rings and one for the thread, and free it with the last one. The thread can't reach a freed ring, rings leave ctx_list before dropping their reference, and the io-wq hash is refcounted. Fixes: 16efa4fce3b7 ("io_uring: allow IO worker threads to be frozen") Signed-off-by: Chris Mason Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d716bdb71b9d909682edbe6b28cb875834891305 Author: Chris Mason Date: Wed Nov 4 11:43:51 2026 -0700 io_uring: free XArray nodes left by a failed store Commit 51bab09b7ca1a9a6dd9303a3b7ee346f8128c963 upstream. A failed xa_store() can leave nodes without entries in the tree, and erasing every entry doesn't free those. An XArray needs xa_destroy() before it goes away, even an empty one. That was dropped for tctx->xa in commit ca6484cd308a ("io_uring: no need to call xa_destroy() on empty xarray") over a lockdep report from freeing the tctx in softirq context, and ctx->personalities never had it. Now that the nodes are charged, a store can fail at memory.max and the leaked nodes stay charged. Call xa_destroy() in io_uring_clean_tctx(), which the task runs itself in process context before the tctx is freed, in the error path of __io_uring_add_tctx_node(), and for ctx->personalities in io_ring_ctx_free(). Fixes: ca6484cd308a ("io_uring: no need to call xa_destroy() on empty xarray") Signed-off-by: Chris Mason Signed-off-by: Jens Axboe [axboe: 6.12 installs the tctx before adding the node and has no error path that frees it, drop that hunk. There's no ctx->hpage_acct either] Signed-off-by: Greg Kroah-Hartman commit d3e1361f57fe4e9973128adee977067a22052a61 Author: Chris Mason Date: Wed Nov 4 11:43:50 2026 -0700 io_uring: charge tctx nodes and personalities Commit 0b34e7b20a48710b6f53716bf7030920b69fdbdd upstream. The io_tctx_node allocated the first time a task touches a ring, and the XArray nodes behind tctx->xa and ctx->personalities, are plain GFP_KERNEL. tctx->xa is indexed by the ring pointer, so nearly every entry needs nodes of its own, and a task gets one entry per ring it has used. 642 threads on 4000 rings held 2.3GB with 59MB charged against a 64MB memory.max. Allocate the node with GFP_KERNEL_ACCOUNT and set XA_FLAGS_ACCOUNT on both XArrays. Fixes: 0f2122045b94 ("io_uring: don't rely on weak ->files references") Signed-off-by: Chris Mason Signed-off-by: Jens Axboe [axboe: 6.12 has kmalloc() for the node, inline in __io_uring_add_tctx_node()] Signed-off-by: Greg Kroah-Hartman commit a9b815dd52c9630c381c7a50549d4c576169c597 Author: Chris Mason Date: Wed Nov 4 11:43:49 2026 -0700 io_uring/rsrc: charge buffer arrays and nodes to memcg Commit 075d5837bafc317e796548f721b8fbf7add6821d upstream. The io_mapped_ubuf of a registered buffer has one bio_vec per page, unless the pages coalesce into huge pages. Huge pages only count against RLIMIT_MEMLOCK once per ring, so a buffer that maps the same 2MB folio over and over in a way that defeats coalescing gets a full bvec array per registration while only the one folio counts as locked. 1GB of that registered in 100 slots took several times a 64MB memory.max, with 2.6MB charged. Allocate the io_mapped_ubuf and the io_rsrc_node with GFP_KERNEL_ACCOUNT. An object reused from the ring caches stays charged to whoever allocated it first, same as the io_kiocb cache. Fixes: de2939388be5 ("io_uring: improve registered buffer accounting for huge pages") Signed-off-by: Chris Mason Signed-off-by: Jens Axboe [axboe: 6.12 predates the rsrc node rework, charge the imu kvmalloc() and the node kzalloc() instead] Signed-off-by: Greg Kroah-Hartman commit 50607993ccbdec9ea9218cd2a02718c6a71e43f7 Author: Josef Bacik Date: Wed Nov 4 11:43:48 2026 -0700 io_uring/io-wq: no new workers once the exit has begun Commit 47c68f925062a6013235d06add85a59f7d91e0fb upstream. io_wq_exit_start() sets IO_WQ_BIT_EXIT, but worker creation task_work queued before that stays queued until io_wq_exit_workers() cancels it. In between the task runs its task_work while canceling requests, and a worker can still get created. That's a problem for exec. begin_new_exec() calls io_uring_task_cancel() after de_thread(), when it's supposedly the only thread left, and io_wq_exit_workers() only waits for ->worker_done, which a worker completes before do_exit(). So the exiting worker is still in the thread group, using the mm, files and sighand, while exec replaces them. Easy to hit with a signal pending when create_io_thread() fails and the retry gets queued right before execve(). Cancel the queued creation task_work as soon as the exit bit is set. Pending work that isn't otherwise canceled now ends with -ECANCELED when the io-wq is destroyed, rather than depending on whether the task happened to run its task_work first. Fixes: 685fe7feedb9 ("io-wq: eliminate the need for a manager thread") Signed-off-by: Josef Bacik [axboe: the barrier is already upstream, see 0e5663856b69, only the cancel is new] Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit eddbf768508ca08724db40845e17008166bc7fc9 Author: Daan De Meyer Date: Wed Nov 4 11:43:47 2026 -0700 io_uring/net: don't retry a non-blocking connect() that fails with -EAGAIN Commit 71537ed811107c514c0342e98902d489d6d2b7cd upstream. IORING_OP_CONNECT on an O_NONBLOCK AF_UNIX stream socket retries a connect that fails with -EAGAIN because the listener's backlog is full. Polling the client socket doesn't help: an unconnected stream socket reports EPOLLOUT and EPOLLHUP right away, before the backlog drains. So io_uring retries the connect until the apoll retry limit is hit, then punts the request to io-wq. With a full backlog, io_connect() runs 128 times in the submitting task and once more in a new io-wq worker. That worker stays in the task's thread group, so a later unshare(CLONE_NEWUSER) fails with -EINVAL. None of this changes the result. __sys_connect_file() adds the socket's own O_NONBLOCK to every attempt, so the attempt from io-wq fails with -EAGAIN as well. That -EAGAIN becomes the CQE result, and connect(2) returns the same -EAGAIN. Let's complete the request with -EAGAIN right away when the socket has O_NONBLOCK set, like connect(2) does. io_accept() already completes -EAGAIN this way for IORING_ACCEPT_DONTWAIT. -EINPROGRESS still waits for the connection to complete. A blocking socket still ends up in io-wq, where the connect sleeps until the listener accepts. Fixes: f8e85cf255ad ("io_uring: add support for IORING_OP_CONNECT") Signed-off-by: Daan De Meyer Link: https://patch.msgid.link/20261027-b4-io-uring-connect-eagain-v1-1-f4e3aaaa49ee@amutable.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit be7e15638a36f81066c8ea24520a7777087f8375 Author: Yichong Chen Date: Wed Nov 4 11:43:46 2026 -0700 io_uring/net: keep recvmsg buffer select length within MAX_RW_COUNT Commit 18d3f56eb6e6500a65d81cf265f0fe74fd9ecab6 upstream. io_recvmsg() takes the transfer length from the ring provided buffer when sqe->len is 0, and such a buffer can be up to 4G. min_ret is an int, so 2G or more makes it negative and the (ret < min_ret) block is skipped, and the oversized length reaches the socket layer unchanged: an empty socket then completes with 0 instead of arming poll, and a short read is reported as complete. Clamp the length to MAX_RW_COUNT, as io_recv() does. Fixes: c7fb19428d67 ("io_uring: add support for ring mapped supplied buffers") Signed-off-by: Yichong Chen Link: https://patch.msgid.link/20261023112209.87979-1-chenyichong@uniontech.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit bcb3753faa62d915d3cf530a1c03e4b6d440c62d Author: Yichong Chen Date: Wed Nov 4 11:43:45 2026 -0700 io_uring/kbuf: advance head when a pickup empties the buffer ring Commit 8742f4b5a472c347fe568a73468a2d9e4d630b33 upstream. io_ring_buffers_peek() flags the request with REQ_F_BL_EMPTY if the buffers it picked were the last ones available, comparing head to tail. When the loop breaks because max_len was exhausted the buffer was picked, but head is left pointing at it, so the flag isn't set if it was the last buffer. A bundle receive then retries, finds no buffer, and the request, which has received data, is marked as failed on account of the -ENOBUFS. That severs a link, and ends a multishot. Fixes: 35c8711c8fc4 ("io_uring/kbuf: add helpers for getting/peeking multiple buffers") Signed-off-by: Yichong Chen Link: https://patch.msgid.link/20261023091711.83481-1-chenyichong@uniontech.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 43ad4a3090e1c2a0c34e9802882b42c5c078d556 Author: Chris Mason Date: Wed Nov 4 19:51:32 2026 +0100 ovl: set OVL_WHITEOUTS before publishing the upper dir commit cbec8610ec5aaf35df50094ff639febc23f20773 upstream. Listing a directory while it is copied up causes a use-after-free of the readdir cache. A merge directory must never be iterated as a real upper directory: that mode frees the cache in OVL_I(inode)->cache without looking at its refcount, while files opened in merged mode still use it. ovl_copy_up_workdir() publishes the upper dentry before it sets OVL_WHITEOUTS, and ovl_dir_open() samples both without a lock, so an open between the two stores finds the upper directory and takes it for a real one. With a delay between the two stores, an unprivileged process that listed a directory during its copy-up saw only "." and "..", and its next getdents freed the readdir cache of another descriptor. Fix this by setting OVL_WHITEOUTS before ovl_inode_update(), so that ovl_dir_reset() agrees with ovl_dir_open(), and by testing OVL_TYPE_MERGE() of the path type in ovl_dir_open(), so that an open that observes the upper dentry never iterates a merge dir as a real dir, regardless of the order in which it observes the flag. Fixes: b79e05aaa166 ("ovl: no direct iteration for dir with origin xattr") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik [amir: test OVL_TYPE_MERGE() instead of smp_rmb() in ovl_dir_open()] Link: https://lore.kernel.org/linux-unionfs/CAOQ4uxh-1J2OBjnDVbrrrjy1puSOW0kABvghN85ih6dtKUBTyA@mail.gmail.com/ Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit af1bb83d729215171e0286469a50205d89d9808e Author: Jiale Yao Date: Thu Sep 24 22:29:17 2026 +0800 HID: roccat: savu: reject short special reports commit 76c51fdc825a0486f8d88ff896d39acec8f377b4 upstream. The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to a helper which inspects data[0] and, for a special report, reads the complete struct savu_mouse_report_special. A truncated report can therefore cause an out-of-bounds read. Require enough data for the special report before calling the helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 6a2a6390cf09 ("HID: roccat: add support for Roccat Savu") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 34d9bad4931e62c6c89d42fe443fff22ed8c8bcd Author: Jiale Yao Date: Thu Sep 24 22:29:16 2026 +0800 HID: roccat: ryos: reject short special reports commit 02f3607d0beb82e76481568bf631235e6a319b47 upstream. The raw event callback runs before HID core validates and zero-pads the report. It reads the report number without checking the received length and passes matching data to roccat_report_event(), which copies a complete struct ryos_report_special. A truncated report can therefore cause an out-of-bounds read and expose adjacent data through the Roccat character device. Require a complete special report before inspecting or forwarding it. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 6f3a19360545 ("HID: roccat: add support for Ryos MK keyboards") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit c40fc6d690a1dfcf7a53496b7d15110cbed242a9 Author: Jiale Yao Date: Thu Sep 24 22:29:15 2026 +0800 HID: roccat: pyra: reject short button reports commit 493268f459bb6aeeecbc77f2204c11ad74d05213 upstream. The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to helpers which inspect data[0] and read a complete struct pyra_mouse_event_button for button reports. A truncated report can therefore cause an out-of-bounds read. Require enough data for the button report before calling either helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: cb7cf3da0daa ("HID: roccat: add driver for Roccat Pyra mouse") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit ee3166e260e4217b9b332d38eb3c75bd72d1bc63 Author: Jiale Yao Date: Thu Sep 24 22:29:14 2026 +0800 HID: roccat: kovaplus: reject short button reports commit e95917a606f486e46f5136fc1b72190742a091d6 upstream. The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to helpers which inspect data[0] and read a complete struct kovaplus_mouse_report_button for button reports. A truncated report can therefore cause an out-of-bounds read. Require enough data for the button report before calling either helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 0e70f97f257e ("HID: roccat: Add support for Kova[+] mouse") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit cb5e06e5f29246f7decc076ae6ca4a17a7b55247 Author: Jiale Yao Date: Thu Sep 24 22:29:13 2026 +0800 HID: roccat: konepure: reject short button reports commit 1590b7c9bea0abe7a5d25dbfe06287c48c238a6f upstream. The raw event callback runs before HID core validates and zero-pads the report. It reads the report number without checking the received length and passes matching data to roccat_report_event(), which copies a complete struct konepure_mouse_report_button. A truncated report can therefore cause an out-of-bounds read and expose adjacent data through the Roccat character device. Require a complete button report before inspecting or forwarding it. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 8936aa31cd5f ("HID: roccat: add support for Roccat Kone Pure gaming mouse") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit a54127de03ac111298bbd842902311408da8f03a Author: Jiale Yao Date: Thu Sep 24 22:29:12 2026 +0800 HID: roccat: koneplus: reject short button reports commit d879e17a8b4c572c0b53b4e42a36849484e8f00c upstream. The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to helpers which inspect data[0] and, for a button report, read the complete struct koneplus_mouse_report_button. A truncated report can therefore cause an out-of-bounds read. Require enough data for the button report before calling either helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 47dbdbffe15b ("HID: roccat: Add support for Roccat Kone[+] v2") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 783580550cb6da2fd19acf7d348dd21dbe7fb4b8 Author: Jiale Yao Date: Thu Sep 24 22:29:11 2026 +0800 HID: roccat: isku: reject short button reports commit 93e5f7f6189af76a2b2e2dfe647838a7b9f99d21 upstream. The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to helpers which inspect data[0] and, for a button report, read the complete struct isku_report_button. A truncated report can therefore cause an out-of-bounds read. Require enough data for the button report before calling either helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: d41c2a7011df ("HID: roccat: Add support for Isku keyboard") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 1c3e4f71f2a84fa6e431b85ca7f6b5f2b8dcc084 Author: Gabor Tanz Date: Mon Oct 12 17:03:57 2026 +0200 HID: quirks: Always poll the Anne Pro 2 with product ID a292 commit cbc13a78a89d087252947d0a51048e576cfcb3ef upstream. The wired Anne Pro 2 identifying as 04d9:a292 stops delivering keyboard input after a period of inactivity. Unplugging and reconnecting the keyboard restores input. Keeping ObinsKit running prevents the problem. A read-only userspace reader that keeps USB HID interface 1 open also prevents it, as does usbhid.quirks=0x04d9:0xa292:0x00000400 without either application running. Commit ca28aff0e1dc ("HID: quirks: Always poll Obins Anne Pro 2 keyboard") added HID_QUIRK_ALWAYS_POLL for product ID a293. The variant identifying as 04d9:a292 exhibits the same symptom. Apply the quirk to this product ID as well. Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Gabor Tanz Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 59c3fc7d74b232fe1784cc305913b9de77fcd230 Author: Jiale Yao Date: Thu Sep 24 22:44:12 2026 +0800 HID: pxrc: reject short input reports commit 0deb22da5a8c6663c3e071f55fd7d7e3189f5517 upstream. The HID core invokes raw_event callbacks before validating the report length. pxrc_raw_event() reads byte seven and writes bytes one and seven without checking that the report contains those bytes. A one-byte input report reproduced the first invalid access under KASAN: BUG: KASAN: slab-out-of-bounds in pxrc_raw_event+0x161/0x260 Read of size 1 by task hidtrigger/90 Call Trace: pxrc_raw_event+0x161/0x260 kasan_report+0x139/0x170 Require all eight bytes before reading or rewriting the report. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: acc3e34613da ("HID: Add driver for PhoenixRC Flight Controller") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 2067a0ac60b665d879e8b4d487b12226200ac96f Author: Jiale Yao Date: Thu Sep 24 22:44:11 2026 +0800 HID: prodikeys: validate fixed-format MIDI reports commit 0ff37294c41bd925258893310398bc2b45fcd4a7 upstream. The HID core invokes raw_event callbacks before validating the report length. Prodikeys reports 0x01 and 0x04 are passed to handlers that always read bytes one through three, regardless of the supplied size. A truncated report can therefore cause an out-of-bounds read. Require four bytes for the two fixed-format reports. Keep report 0x03 on its existing variable-length path, which derives the number of note pairs from size and only accesses complete pairs. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: 3a370ca1dcf8 ("HID: Prodikeys PC-MIDI HID Driver") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 28be73031ae5397a0592fa6308051f743fb428f7 Author: Lorenzo Stoakes (ARM) Date: Sat Sep 26 14:17:01 2026 +0100 HID: picoLCD: check for fb_deferred_io_init() error commit feade898fc958ff355101adf12d5632272e64220 upstream. fb_deferred_io_init() allocates deferred I/O state, populating info->fbdefio_state, or leaving it NULL if an error occurs. Currently picolcd_init_framebuffer() ignores its return value. Therefore if an error arises in fb_deferred_io_init() (for instance, due to an allocation failure) info->fbdefio_state is left NULL. When the file is subsequently opened, fb_open() will dereference a NULL pointer (calling fb_deferred_io_open()). Fix this by checking for the error. Also correct cleanup ordering - defio is initialised after the sysfs file, so cleanup defio first. Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 394a7a04c0915f86cde7c19de47f65ec3d3b6e54 Author: Jiale Yao Date: Thu Sep 24 22:44:10 2026 +0800 HID: mcp2221: validate response report length commit 1ae40774d386b7a51e4799200106429a7e14e8ec upstream. MCP2221 responses are 64-byte reports, but mcp2221_raw_event() currently accepts any report of at least four bytes. Several response handlers read far beyond that minimum. In particular, the I2C status response reads offset 20 and copies ADC samples starting at offset 50. Other GPIO, SRAM, and flash response handlers also access fixed offsets beyond byte three. The HID core invokes raw_event callbacks before validating the report length, so a truncated response can cause an out-of-bounds read. Require a complete protocol report before dispatching any response handler. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: 67a95c21463d ("HID: mcp2221: add usb to i2c-smbus host bridge") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 0210fd34232c8450fcaa5a68ff4360f275c755f2 Author: Jiale Yao Date: Thu Sep 24 22:44:09 2026 +0800 HID: mcp2200: validate READ_ALL response length commit 26ce0e6bf0b27fc6a2f490f38555dfd0a27c9605 upstream. The HID core invokes raw_event callbacks before validating the report length. mcp2200_raw_event() casts a READ_ALL response to struct mcp_read_all_resp and reads fields through offset ten without checking that the response contains the structure. A one-byte READ_ALL response reproduced the issue under KASAN: BUG: KASAN: slab-out-of-bounds in mcp2200_raw_event+0x24b/0x3a0 Read of size 1 by task hidtrigger/89 Call Trace: mcp2200_raw_event+0x24b/0x3a0 kasan_report+0x139/0x170 Reject an incomplete READ_ALL response with a protocol error before reading its fields. The common completion path then wakes the command waiter with the error instead of leaving it to time out. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: 740329d7120f ("HID: mcp2200: added driver for GPIOs of MCP2200") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 78d8c658721b1333549c4bce0fe3c33f8b542e35 Author: Jiale Yao Date: Thu Sep 24 22:44:08 2026 +0800 HID: logitech-dj: validate unnumbered keyboard reports commit c2deafcb4c8227771f768d77ed3c0a489250e9b2 upstream. The HID core invokes raw_event callbacks before validating the report length. For an unnumbered keyboard report, logi_dj_raw_event() uses the second byte as temporary storage while prepending a report ID. A one-byte report therefore makes both the initial write and the later restoration access data beyond the received report. Reject unnumbered keyboard reports that do not provide the temporary byte. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: 74808f9115ce ("HID: logitech-dj: add support for non unifying receivers") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit ef594cb02de0c7d4bea509d680eca738d0fdf8d6 Author: Jiale Yao Date: Thu Sep 24 22:44:07 2026 +0800 HID: elo: reject short touchscreen reports commit 1cb92fcb2ac344d78737e3c5cb7b061dfb2850b1 upstream. The HID core invokes raw_event callbacks before validating the report length. elo_raw_event() only checks the first-byte packet marker before elo_process_data() reads coordinates, flags, and pressure through offset seven. A truncated packet beginning with the expected marker can therefore cause an out-of-bounds read. Require the complete eight-byte SmartSet packet before parsing it. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: d23efc19478a ("HID: add driver for ELO 4000/4500") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit e178cdd6ed0f4ac20afc9220eceae3a89e6719af Author: Jiale Yao Date: Thu Sep 24 22:44:06 2026 +0800 HID: cp2112: validate response report lengths commit fc54e71a063c0dcc4bceba6d0f71805a9b84082d upstream. The HID core invokes raw_event callbacks before validating the report length. cp2112_raw_event() reads every field of a transfer status response without checking size. For a data response, it reads the length at offset two and copies that many bytes from offset three, again without ensuring that the input report contains them. Require a complete transfer status structure. For data responses, first require the header and then ensure the clamped payload length fits in the received report before copying it. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: e932d8178667 ("HID: add hid-cp2112 driver") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 74b48b876150b09dbddce8dab5b250c19ddd0a59 Author: Jiale Yao Date: Thu Sep 24 22:44:05 2026 +0800 HID: cougar: reject short special-key reports commit c6c0df8a4b73a0d563c5e64de640ef5ff525fc82 upstream. The HID core invokes raw_event callbacks before validating the report length. cougar_raw_event() reads the key code and action from offsets one and two without checking that those bytes are present. A short report on the special interface can therefore cause an out-of-bounds read. Consume reports that do not contain the action field before accessing the fixed offsets, consistent with the callback's handling of other reports on the special interface. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: b8e759b8f6da ("HID: cougar: Add support for the Cougar 500k Gaming Keyboard") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 8bc6279634b03222d79788481810562a7d3564fe Author: Alan Stern Date: Sat Oct 10 13:44:15 2026 -0400 HID: core: Fix out-of-bounds left shift by 32 in s32ton() commit 5fe63b415c636c7f4f6848a8e53bdd4bbf0c300d upstream. Syzbot reported an out-of-bounds shift (32-bit integer shifted left by 32) in the s32ton() routine in the HID core. This routine converts a signed 32-bit integer to a signed n-bit integer, and it caps the value of n at 32. But when n == 32 there's no need to do anything; it can simply return the input value. This will avoid calculating (1 << n) when n is 32, which was the cause of the invalid shift. Signed-off-by: Alan Stern Fixes: 69c02ffde6ed ("HID: core: clamp report_size in s32ton() to avoid undefined shift") Reported-by: syzbot+25a1d2907885b2182275@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/6ac9cbd8.a150a118.27e199.0025.GAE@google.com/ Tested-by: syzbot+25a1d2907885b2182275@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Link: https://patch.msgid.link/dfa0aa1c-e55e-4316-8307-f72a07383634@rowland.harvard.edu Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 65dddbaa40117ebb351080d56d22d8d53b78b1c8 Author: Basavaraj Natikar Date: Tue Oct 6 16:07:54 2026 +0530 HID: amd_sfh: Use report type from request node commit 85f1bea97f1909f81577cfcf3e4db9017e7f5337 upstream. Use report type from request node while sending feature and input reports to HID core. The cli_data report type array is never assigned and feature reports are sent as input reports. Fixes: 1434f9fc0e47 ("SFH: Create HID report to Enable support of AMD sensor fusion Hub (SFH)") Closes: https://github.com/ublue-os/bazzite/issues/5796 Cc: stable@vger.kernel.org Signed-off-by: Basavaraj Natikar Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 59501a37df7dd0b2366070eff22f1afc30155c6c Author: Basavaraj Natikar Date: Tue Oct 6 16:07:53 2026 +0530 HID: amd_sfh: Remove unsupported motion-state field from accelerometer report commit 6ff86122906357687735dd379c6279e3b2fa26af upstream. The accelerometer HID report descriptor declares a trailing motion-state field (usage 0x0451), but the Sensor Fusion Hub never reports this data, so each accelerometer input report is one byte shorter than the descriptor advertises. This was previously harmless because hid-core zero-padded short reports. Since commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") such reports are rejected instead: hid-sensor-hub 0020:1022:0001.0003: Event data for report 1 was too short (15 vs 14) As a result the accelerometer input events are dropped and screen auto-rotation stops working on AMD SFH systems. Remove the motion-state field from the accelerometer report descriptor and drop the unused in_accel_shake_detection member, so the descriptor matches the report actually provided by the hardware. Fixes: 1434f9fc0e47 ("SFH: Create HID report to Enable support of AMD sensor fusion Hub (SFH)") Reported-by: Andrej Scek Closes: https://lore.kernel.org/linux-input/CADrS85612m-Hh-G4BJmOhy-y6r3Ni3kD8_GM-2QRBeWWEEZWuA@mail.gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Basavaraj Natikar Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 356f75af018250bea158b051ad0754fb80bb4c86 Author: Jiale Yao Date: Thu Sep 24 22:44:13 2026 +0800 HID: zydacron: validate key report length commit 9932c9af185f8586e883d44ca562c12f4487c762 upstream. The HID core invokes raw_event callbacks before validating the report length. zc_raw_event() verifies the report ID in byte zero and then reads the key code from byte one for report IDs 0x02 and 0x03 without checking that the second byte is present. A one-byte report reproduced the issue under KASAN: BUG: KASAN: slab-out-of-bounds in zc_raw_event+0x54c/0x580 Read of size 1 by task hidtrigger/93 Call Trace: zc_raw_event+0x54c/0x580 __hid_input_report+0x2ef/0x3a0 inject_store+0x479/0x490 [faketrans] Require both the report ID and key code before processing the report. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: d0742abaa1c3 ("HID: add omitted hid-zydacron.c file") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit c05afb81b7da8652edd2b163f0bf79b228d7d31d Author: Amit Machhiwal Date: Mon Sep 28 17:58:37 2026 +0530 KVM: PPC: Fix get_d_signext() 12-bit displacement for paired-single D-form commit 31895b0ff96778b524c74b43a108090581271603 upstream. get_d_signext() has two compounding bugs since its introduction in 2010: 1. The extraction mask 0x8FF silently drops bits 8-10 of the 12-bit D field (PPC ISA bits 21-23), corrupting any displacement that has any of those bits set. 2. The sign-magnitude idiom "-(d & 0x7ff)" is wrong for two's-complement: for D=0xFFC (encoding of -4) it returns -252 instead of -4. Together these errors produce a wrong effective address for psq_l, psq_lu, psq_st, and psq_stu whenever the displacement is negative or is a positive value >= 0x100 with bits 8-10 set — essentially any real-world paired- single stack-relative access. The D field occupies the bottom 12 bits of the instruction word (confirmed by the adjacent W and I extractions via inst_get_field(inst,16,16) and inst_get_field(inst,17,19)). Replace the open-coded logic with the standard sign_extend32(inst & 0xfff, 11), which correctly performs two's-complement sign extension from 12 bits to 32 bits. Fixes: 831317b605e7 ("KVM: PPC: Implement Paired Single emulation") Cc: stable@vger.kernel.org Signed-off-by: Amit Machhiwal Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260928122837.8782-4-amachhiw@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 8f021a671b511a49468e87a4935b43b0a4d045c0 Author: Amit Machhiwal Date: Mon Sep 28 17:58:36 2026 +0530 KVM: PPC: Book3S HV: Add preempt_disable() around virtual-mode HPTE bit-lock users commit abbbe5ff83e7c9ed3a4d61b73011f1df7bf87907 upstream. kvmppc_hv_find_lock_hpte() requires virtual-mode callers to run with preemption disabled, because it can return with HPTE_V_HVLOCK still held until the caller later unlocks the HPTE. Existing virtual-mode callers in book3s_64_mmu_hv.c already follow that rule. Two virtual-mode call paths do not: 1. kvmppc_handle_exit_hv() calls kvmppc_hpte_hv_fault() for hash-mode data-side and instruction-side faults after guest exit, with preemption already enabled. kvmppc_hpte_hv_fault() calls kvmppc_hv_find_lock_hpte() directly. 2. kvmppc_pseries_do_hcall() executes virtual-mode handlers for HPT hcalls via kvmppc_pseries_do_hpt_hcall() with preemption enabled. The handlers for H_ENTER, H_REMOVE, H_READ, H_CLEAR_MOD, H_CLEAR_REF, H_PROTECT, and H_BULK_REMOVE spin on try_lock_hpte() or lock_rmap(), and H_ENTER also reaches kvmppc_do_h_enter(), which uses arch_spin_lock() on kvm->mmu_lock. That raw lock choice is intentional because kvmppc_do_h_enter() is also used by real-mode callers, so the correct fix is to establish the proper preemption context at the virtual-mode caller boundary. If a vCPU thread is preempted while holding HPTE_V_HVLOCK, any other thread on the same CPU trying to acquire the same bit-lock can spin indefinitely. The same applies to lock_rmap() users and to the H_ENTER path while holding the raw mmu_lock. Fix this by adding preempt_disable()/preempt_enable() pairs around the two kvmppc_hpte_hv_fault() call sites in kvmppc_handle_exit_hv(), and around the kvmppc_pseries_do_hpt_hcall() invocation in kvmppc_pseries_do_hcall(). Targeting only the HPT hcall helper avoids wrapping non-HPT hcalls (such as H_RTAS, H_CONFER, H_REGISTER_VPA) that perform page faults, blocking memory allocations, or context switches. Fixes: 6165d5dd99db ("KVM: PPC: Book3S HV: add virtual mode handlers for HPT hcalls and page faults") Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Amit Machhiwal Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260928122837.8782-3-amachhiw@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit fd7764eea189053ce6345950f11e4aeecd741fba Author: Sean Christopherson Date: Wed Aug 26 11:44:49 2026 -0700 KVM: x86: Zero reserved synic flags when delivering message to avoid stack leak commit 2616f497506a772db53e7bb1024cde50b4c165e0 upstream. Ensure all reserved flags are zeroed when setting the msg_pending flag as part of SynIC message delivery, as setting only msg_pending can leak seven bits of kernel stack data to the guest. E.g. gcc typically uses a bitwise-OR to set the msg_pending flag, without initializing the on-stack variable. Precisely zero the flags, e.g. as opposed to zeroing the entire structure, to make it somewhat more obvious that the flags *need* to be zeroed. E.g. it would be quite easy to misread the initial read of guest memory and think that zeroing the entire structure is completely superfluous. Fixes: 3a0e7731724f ("x86: kvm: hyperv: simplify SynIC message delivery") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Reviewed-by: Vitaly Kuznetsov Link: https://patch.msgid.link/20260826184449.814130-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 9d119b4921ac74bc606917fd274c10c966fa5b72 Author: Chengfeng Ye Date: Wed Aug 26 02:39:24 2026 +0800 KVM: x86: Take SRCU in kvm_zap_gfn_range() commit b59a87c1ba3c347e8aec5f932eb7abf13064fd62 upstream. kvm_zap_gfn_range() walks memslots and rmaps and may drop mmu_lock to reschedule. Callers that do not already hold kvm->srcu (or slots_lock) can race with memslot deletion: synchronize_srcu_expedited() does not wait, kvm_free_memslot() frees the old slot and its rmap, and the zap resumes on freed memory. The VFIO noncoherent-DMA path hits this by zapping the entire GPA space without SRCU. KASAN reported: BUG: KASAN: vmalloc-out-of-bounds in slot_rmap_walk_next+0x82/0x1c0 Read of size 8 at addr ffffc900005c1008 Call Trace: slot_rmap_walk_next+0x82/0x1c0 __kvm_rmap_zap_gfn_range+0x17a/0x280 kvm_zap_gfn_range+0x2a6/0x6a0 kvm_vfio_set_attr+0x576/0x770 kvm_device_ioctl+0x1ff/0x3b0 Take SRCU inside kvm_zap_gfn_range() so every caller is covered. Nesting with an existing kvm->srcu critical section is fine; the helper uses a local index. Drop the now-redundant SRCU pair from __kvm_set_or_clear_apicv_inhibit(). Fixes: 362ff6dca541 ("KVM: x86/mmu: Zap KVM TDP when noncoherent DMA assignment starts/stops") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Reviewed-by: Kai Huang Link: https://patch.msgid.link/20260825183924.237727-1-nicoyip.dev@gmail.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit e663aa0755a11f13e45ebe65a0c37d47f5529560 Author: Loc Nguyen Date: Fri Oct 2 05:42:54 2026 +0000 KVM: x86: Request event processing for exception VM-Exits commit 88b23a2e8286b7016c3b58dc10093cf28c22aa3d upstream. Request event processing whenever kvm_queue_exception_vmexit() queues an exception VM-Exit. Most callers reach the helper through kvm_multiple_exception(), which already sets KVM_REQ_EVENT, but nested asynchronous page faults call it directly. Without another event request, vcpu_enter_guest() skips kvm_check_and_inject_events() and re-enters L2. A subsequent VM-Exit can clear the pending exception while reconstructing vectoring state, losing the synthetic #PF VM-Exit. The APF reason remains PAGE_NOT_PRESENT and a later regular #PF can consume the stale value. Setting KVM_REQ_EVENT in the common helper ensures that L1 receives the queued VM-Exit before KVM re-enters L2. Fixes: 7709aba8f716 ("KVM: x86: Morph pending exceptions to pending VM-Exits at queue time") Cc: stable@vger.kernel.org Signed-off-by: Loc Nguyen Link: https://patch.msgid.link/20261002053723.3275202-2-loc@ryzome.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 3e38714080685288cef284d69ca1f42ea300b6bd Author: Sean Christopherson Date: Wed Sep 30 12:36:23 2026 -0700 KVM: x86: Preserve DR6.BLD (Bus Lock Detect) when delivering #DB payload commit 719a1d58bf43edd03b271df90b67c58c1e9a7da4 upstream. Preserve Bus Lock Detect if it isn't present in the payload. Unlike RTM, which is explicitly modified on every #DB, DR6.BLD is modified if and only if the #DB is due to a (coincident) Bus Lock Detect. Per Intel's SDM: Other debug exceptions do not modify this bit. And AMD's APM All other #DB exceptions leave DR6[BLD] unmodified, Restore the explicit RTM handling that was clobbered by commit 9a3ecd5e2aa1 ("KVM: X86: Rename DR6_INIT to DR6_ACTIVE_LOW"), as the semantics of any given bit are feature specific, i.e. are obviously not consistent for active-high versus active-low. In other words, while the bug was technically introduced when support for Bus Lock Detect was added, it's really that attempt to genericize handling of active-low bits that set KVM up to fail. Fixes: e8ea85fb280e ("KVM: X86: Add support for the emulation of DR6_BUS_LOCK bit") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260930193634.3415089-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 46da6967ef606e608f47c5f58ede337dfa809788 Author: David Woodhouse Date: Mon Aug 31 22:26:41 2026 +0100 KVM: x86/xen: Take kvm->srcu in __kvm_xen_has_interrupt() commit aa8ad943f242ef14d136c5440b1178de77466c9e upstream. kvm_gpc_check() checks the cached memslot generation against the current one, which dereferences kvm->memslots and therefore requires kvm->srcu to be held. __kvm_xen_has_interrupt() does not take it. Most callers do happen to hold kvm->srcu, but not all of them: - kvm_emulate_halt() on the VM-Exit path, via kvm_vcpu_has_events() and kvm_cpu_has_extint(). vcpu_enter_guest() drops the vCPU's SRCU lock before entering the guest, so it is not held on the way back out. - kvm_vcpu_block() -> kvm_vcpu_check_block() -> kvm_arch_vcpu_runnable(), which is the case the existing comment in this function describes. On a PROVE_RCU kernel the former produces: WARNING: suspicious RCU usage include/linux/kvm_host.h:1092 suspicious rcu_dereference_check() usage! ... kvm_gpc_check+0x344/0x3e0 [kvm] __kvm_xen_has_interrupt+0x83/0x310 [kvm] kvm_cpu_has_extint+0x1ff/0x370 [kvm] kvm_cpu_has_interrupt+0x16/0x100 [kvm] kvm_vcpu_has_events+0x4ce/0x690 [kvm] kvm_emulate_halt+0x52/0x1f0 [kvm] vmx_vcpu_run+0x988/0x2630 [kvm_intel] Use guard(srcu) so that the three existing early returns don't each need an explicit unlock. SRCU read sections nest, so this is harmless on the paths which already hold it, and srcu_read_lock() does not sleep, so it is also safe in the atomic case which this function already handles. Fixes: 7caf9571563e ("KVM: x86/xen: Use gfn_to_pfn_cache for vcpu_info") Cc: stable@vger.kernel.org Signed-off-by: David Woodhouse Assisted-by: Claude:claude-mythos-5 Reviewed-by: Paul Durrant Link: https://patch.msgid.link/20260831213632.81023-11-dwmw2@infradead.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 0381288c2fad72cdbe868216c179f6cbefc2ea01 Author: David Woodhouse Date: Mon Aug 31 22:26:37 2026 +0100 KVM: x86/xen: Enforce 4-byte alignment of vcpu_info registration commit eacdb76c5f04956035c5d7f7e1973028f30684a2 upstream. Xen's map_guest_area() enforces that vcpu_info is aligned to sizeof(xen_ulong_t). KVM has no such check, allowing a guest to register vcpu_info at an arbitrary byte alignment. Enforce unconditional 4-byte alignment regardless of the current shinfo mode. This is sufficient because subsequent commits ensure that all locked atomic operations on vcpu_info fields use at most 32-bit accesses. Return -ENXIO on failure, matching Xen's map_guest_area() behaviour for unaligned requests. Originally observed in review of an unrelated patch: https://lore.kernel.org/all/20260604193554.1BA311F00893@smtp.kernel.org/ Cc: stable@vger.kernel.org Fixes: 73e69a86347a ("KVM: x86/xen: register vcpu info") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260604193554.1BA311F00893@smtp.kernel.org Assisted-by: Kiro:claude-opus-4.6-1m Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant Link: https://patch.msgid.link/20260831213632.81023-7-dwmw2@infradead.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 24b407e17182b15f1e33df8219ea8f19dcfef027 Author: Sean Christopherson Date: Wed Sep 2 16:20:27 2026 -0700 KVM: x86/mmu: Bug the VM if KVM calcs a CPU role with EFER.LMA=1 && CR4.PAE=0 commit 34dacbe7ae93f2d3c26cd0bf3e08200b1fa2c180 upstream. Bug the VM if KVM attempts to construct a CPU role with the should-be- impossible combination of long mode being active without PAE paging being enabled. KVM's MMU construction assumes that EFER.LMA can be set if and only CR4.PAE is set, and will create a completely invalid MMU if that assumption fails. FNAME(walk_addr_generic) already has sanity checks to try and mitigate the fallout, but attempt to catch such bugs earlier, as this is (at least) the second time KVM has had bugs that escaped into FNAME(walk_addr_generic), and it's entirely possible the bad state could cause problems elsewhere. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260902232028.2767071-5-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit d6f3877eabf159167ee9972d627396412a04ac74 Author: Sean Christopherson Date: Wed Sep 2 16:20:26 2026 -0700 KVM: x86/mmu: Bug the VM if KVM attempts to walk more levels than the MMU has commit 115f9405a2ed6d78ee7ad8436bdd638743f6d1d4 upstream. Extend the "EFER.LMA && !CR4.PAE" check, which exists largely to guard against KVM configuring a paging32 MMU with more than 2 levels of paging, with a very explicit check for exactly that: that KVM isn't trying to walk more levels of paging than the MMU template provides. I.e. harden KVM against all bugs that would cause KVM to generates accesses beyond the bounds of guest_walker's arrays, regardless of how KVM ended up with the misconfigured MMU. Note, don't use w->cpu_role.base.level directly as the paging64 template only provides two levels of page tables for PAE paging on 32-bit hosts, and handles the third level by manually emulating the PDPTR access. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260902232028.2767071-4-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit f86b9e1a04708da64877ade0d411410bfb0a2b01 Author: Sean Christopherson Date: Mon Sep 21 17:13:28 2026 -0700 KVM: Use goto to handle errors during memslot preparation commit 23a205797cec86f391d0be886b9bc741e1262063 upstream. Use a goto to unwind early memslot changes if preparing for a memslot operation fails. This will allow moving the creation of guest_memfd bindings into kvm_set_memslot() without needing to copy+paste the unwind logic. No functional change intended. Cc: stable@vger.kernel.org Reviewed-by: David Hildenbrand (Arm) Reviewed-by: Ackerley Tng Link: https://patch.msgid.link/20260922001332.1121266-3-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit ccd10b6ce7fb6dc36b70fd75dfb8bab33e65e9ae Author: Sean Christopherson Date: Wed Sep 2 16:20:25 2026 -0700 KVM: nSVM: Ignore EFER.LMA if EFER.LME=0 when preparing L2 state commit 1c4c84a643b704e473cb171f7b61359ff29b12a4 upstream. Force EFER.LMA=0 if EFER.LME=0 when preparing L2 state for VMRUN, i.e. mimic real hardware's behavior of ignoring EFER.LMA if EFER.LME=0. VMRUN unfortunately allows the nonsensical combination, i.e. doesn't fail, but KVM itself has an invariant EFER.LMA can be set et if and only if EFER.LME is set. Breaking that invariant can lead to a variety of issue, particularly in MMU code that keys off EFER.LMA when determining whether to emulate/virtualization 4/5-level paging versus PAE paging. Cc: stable@vger.kernel.org Cc: Yosry Ahmed Link: https://patch.msgid.link/20260902232028.2767071-3-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 5636d57b61068918085360aaad18ab57872e5800 Author: Yosry Ahmed Date: Thu Sep 3 22:32:58 2026 +0000 KVM: SVM: Trigger new ASID allocation in both VMCBs on pCPU switch commit bf260dc9e7b8bfcd06c1a8e739797b1cf0917c72 upstream. When the pCPU where the VMCB was most recently used is switched, reset the ASID generation in both VMCBs, triggering new ASID allocation for the immediate VMRUN as well as the next VMRUN on the other VMCB. The ASID is shared between vmcb01 and vmcb02, and gets flushed on every nested transition. However, since pCPU tracking is done per VMCB, it is possible for one VMCB to allocate a new ASID when migrated to a new pCPU, and then the other VMCB reuses that ASID on the old pCPU. This can result in the same ASID being used by multiple vCPUs on the old pCPU. Example scenario: - vCPU runs on pCPU A, vmcb01 is active, asid=1. - vCPU migrates to pCPU B, vmcb01 pCPU changes, new asid=2. - Another vCPU runs on pCPU A and allocates asid=2 as well. - vCPU migrates back to pCPU A, and then switches to vmcb02 before it runs again with vmcb01. - No pCPU switch is detected for vmcb02, so VMRUN is done with asid=2. - Two vCPUs end up using asid=2 on the same pCPU. Keep the VMCB dirtying to the active VMCB only. Clean bits are tracked by a pCPU for each VMCB, so do not unnecessarily dirty a VMCB if its pCPU does not change. Additionally, initialize the tracked pCPU for vmcb02 to -1 on nested enablement as hardening, so that a new ASID allocation is always triggered when nested is disabled and re-enabled. No performance regression was noticed when overcommitting L1 vCPUs in L0 (to force rescheduling), pinning L1 <-> L2 vCPUs, and running CPUID in a tight loop bouncing between 2 vCPUs in L2. An alternative (and perhaps more proper) fix would be tracking the ASID per-VMCB instead (e.g. [1]). However, that's a more involved change, and it would result in having different ASIDs for L1 and L2 without actually properly maintaining them. It would probably work because all TLB flushes target the current VMCB, and the other VMCB is always flushed on nested transitions, but the code ends up in an arguably more fragile state. Punt a proper clean fix to an incoming (and overdue) overhaul of SVM's ASID usage [2]. [1] https://lore.kernel.org/lkml/20250205182402.2147495-2-yosry.ahmed@linux.dev [2] https://lore.kernel.org/kvm/20260728003557.1136583-1-yosry@kernel.org Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Signed-off-by: Yosry Ahmed Reviewed-by: Nikunj A Dadhania Link: https://patch.msgid.link/20260903223258.486034-1-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 11d1ba991c0754b2c3c1e31aa63b0818afc6e4f7 Author: Mike Rapoport (Microsoft) Date: Thu Aug 13 12:01:28 2026 +0300 x86/mm/pat: Fix effective RW computation in lookup_address_in_pgd_attr() commit ebaf7c9bbb1e16523d7036e7e1225ad2dfcc6482 upstream. lookup_address_in_pgd_attr() accumulates the effective NX and RW bits of the walked page table levels so that verify_rwx() can detect mappings that are both writable and executable. The RW bits are folded into a bool with rw &= pXd_flags(*pXd) & _PAGE_RW; but _PAGE_RW is 0x2. So consider the accumulation line: rw &= pXd_flags(*pXd) & _PAGE_RW; where rw=0x1 and the right side evaluates down to 0x2. It'll end up doing: rw = 0x1 & 0x2 and rw always ends up 0. This way rw becomes false at the first level walked, regardless of the actual permissions, and verify_rwx() treats every mapping as non-writable and never reports a W^X violation. Add double negation to the right side to normalize the _PAGE_RW flag to 0 or 1. Assisted-by: Copilot:claude-opus-4.8 Fixes: ceb647b4b529 ("x86/pat: Introduce lookup_address_in_pgd_attr()") Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Dave Hansen Reviewed-by: Juergen Gross Reviewed-by: Lorenzo Stoakes (ARM) Tested-by: syzbot@syzkaller.appspotmail.com Tested-by: Atish Patra Tested-by: Nikunj A Dadhania Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20260813-cpa-fixes-v2-5-39b4ff90f91d@kernel.org Signed-off-by: Greg Kroah-Hartman commit fc2105878c2da4d497d32b9ebc0411178d9a1b05 Author: David Howells Date: Tue Oct 6 14:30:01 2026 +0100 rxrpc: Fix return in rxrpc_recvmsg_data() for service calls commit 18a71e111c7505e16c2de91480561fc491f41341 upstream. When rxrpc_recvmsg_data() gets called on a service call that has received all of the request, RXRPC_CALL_RECVMSG_READ_ALL has been set, and this causes rxrpc_recvmsg_data() to jump straight out, indicating the end of the call (ie. rxrpc_kernel_recv_data() returns 1) without waiting for the call to be processed or the reply to be transmitted. rxperf_deliver_to_call() also has to be altered to call rxrpc_kernel_recv_data() to collect the final ACK on a service call as does afs_deliver_to_call(). Fixes: d001648ec7cf ("rxrpc: Don't expose skbs to in-kernel users [ver #2]") Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260914151340.3227501-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Eric Dumazet cc: "David S. Miller" cc: Jakub Kicinski cc: Paolo Abeni cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261006133011.531806-10-dhowells@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit d80982b086d620cbfdc95c345ea4f33d24d59f91 Author: David Howells Date: Tue Oct 6 14:30:00 2026 +0100 rxrpc: Fix double IRQ enablement commit 41eb0af096ba8754e584d47e6de42f1e4980ceae upstream. rxrpc_notify_socket() explicitly disables and then re-enables IRQs, but one of its call chains (rxrpc_input_queue_data() -> rxrpc_end_rx_phase() -> rxrpc_call_completed() -> rxrpc_set_call_completion()) has IRQs disabled around it. Fix this by making rxrpc_notify_socket() use irqsave spinlocks. Fixes: a2ea9a907260 ("rxrpc: Use irq-disabling spinlocks between app and I/O thread") Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260812110129.979970-6-dhowells@redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Eric Dumazet cc: "David S. Miller" cc: Jakub Kicinski cc: Paolo Abeni cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20261006133011.531806-9-dhowells@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit b0545c0cf32e4c03ebf5254162c091679ec16d2b Author: Chuck Lever Date: Sat Aug 8 11:40:11 2026 -0400 SUNRPC: Treat every TLS error alert as fatal commit 2c0dfe9d6d81e4bc9201b11dab3876cbfd01884e upstream. svc_tcp_sock_process_cmsg() decides whether an alert ends the session by reading the alert's level octet. RFC 8446 Section 6 retired that field. The severity is implicit in the description, and a receiver treats every alert listed in Section 6.2 as an error alert "regardless of the AlertLevel in the message". A peer that aborts with unexpected_message but leaves the legacy octet set to warning makes the server return -EAGAIN. svc_tcp_recvfrom() then leaves a dead TLS session attached to an open transport. NFSD keeps polling it. Decide from the alert description instead. close_notify and user_canceled are the closure alerts (RFC 8446 Section 6.1). Every other description ends the session, including one this kernel does not recognize. Fixes: 39067dda1d86 ("SUNRPC: Use new helpers to handle TLS Alerts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-3-62d9a631c880@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 3a791bd9456839f8f13c4686b2287524a0a04141 Author: Ameer Hamza Date: Sat Aug 15 03:19:52 2026 +0500 sunrpc: treat empty auth.unix.gid replies as negative entries commit a12cc0930235b86b934ade7c077a1935c2ac333d upstream. When rpc.mountd cannot resolve a uid (getpwuid() or getgrouplist() failure, e.g. while winbind or sssd is briefly unreachable), it answers the auth.unix.gid upcall with zero groups. unix_gid_parse() installs that as a valid positive entry, and svcauth_unix_set_client() then replaces the credential's group list with the empty one on every request, RPCSEC_GSS included via svcauth_gss_set_client(). One failed lookup strips that uid of all supplementary groups on every export for up to mountd's configured TTL (30 minutes by default), long after the NSS backend has recovered. mountd cannot send an empty list for a successful lookup, since getgrouplist(3) always includes at least the user's primary group, so a zero-group reply can only mean the lookup failed. Record it as a negative entry: unix_gid_find() then returns -ENOENT and svcauth_unix_set_client() keeps the groups the RPC credential already carries. This is the fallback that commit 3fc605a2aa38 ("[PATCH] knfsd: allow the server to provide a gid list when using AUTH_UNIX authentication") promised when no answer is available, and the same state try_to_negate_entry() already creates when no listener holds the channel open. Fixes: 3fc605a2aa38 ("[PATCH] knfsd: allow the server to provide a gid list when using AUTH_UNIX authentication") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Ameer Hamza Link: https://patch.msgid.link/20260814221953.108837-2-ameer.hamza@truenas.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 4d20ecd289ede2487ee5a23962fa78fcb47c0500 Author: Zhiling Zou Date: Sat Sep 12 21:56:09 2026 +0800 SUNRPC: trace an accepted transport before publishing it commit 06f90cf104fc21ee01e7ef1eb80e092173089b9f upstream. svc_handle_xprt() publishes a newly accepted transport before tracing it. svc_add_new_temp_xprt() places the transport on sv_tempsocks and clears XPT_BUSY, so another nfsd thread can dequeue it at once. If the peer has already closed the connection, that thread runs svc_delete_xprt(), which drops the list reference, the only reference the new transport holds. trace_svc_xprt_accept() then reads the transport's addresses and network namespace from freed memory. Before publication the accepting thread owns the transport exclusively: XPT_BUSY is still set from svc_xprt_init() and the transport is on no list. Emit the tracepoint there. Fixes: 11bbb0f76e99 ("SUNRPC: Trace a few more generic svc_xprt events") Cc: stable@vger.kernel.org Reported-by: VEGA Assisted-by: LLM Signed-off-by: Zhiling Zou Link: https://patch.msgid.link/d15495bff2247e3f9d4f9ef36df8e246a3898380.1789220778.git.zhilinz@nebusec.ai [ cel: trace before publication instead of taking an extra reference ] Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 1317f88f86b3b8462b5bf5e28b2cd1ab4c62c3ec Author: Chuck Lever Date: Sat Aug 8 11:40:12 2026 -0400 SUNRPC: Resume receiving after a TLS control record commit 8079c660b247f282340fbe7f55cf8a354009db9e upstream. A TLS control record delivers no payload to the RPC layer. svc_tcp_recvfrom() clears XPT_DATA before the receive, and svc_tcp_sock_recv_cmsg() returns -EAGAIN for the record it consumed. Nothing marks the transport ready again. kTLS raises data_ready for arriving TCP segments, not for records it has already decrypted. An RPC Call queued behind an alert or a KeyUpdate waits until the client sends more. The client blocks until its RPC timeout expires. The receive takes only the first two octets of the record. kTLS holds the remainder on its receive list, where each later receive takes two octets more. Drain a record that is not an alert, then mark the transport ready once a control record has been consumed. Fixes: 5e052dda121e ("SUNRPC: Recognize control messages in server-side TCP socket code") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-4-62d9a631c880@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f34df0121769b128dc302d691463145e156533ca Author: Chuck Lever Date: Sat Aug 8 11:40:10 2026 -0400 SUNRPC: Reject a TLS alert record that is not two octets commit d16bebe45272ced4f962d27b9efd8b32a3876bd9 upstream. tls_alert_recv() reads two octets from the kvec it is handed and does not check the length (net/handshake/alert.c). svc_tcp_sock_recv_cmsg() calls it for any positive receive, and the alert[] buffer it supplies carries no initializer. A one-octet alert body leaves the description read from uninitialized stack and reported through trace_tls_alert_recv(). The peer controls that length. Neither tls_rx_msg_size() nor tls_rx_one_record() enforces the two-octet Alert payload. A TLS 1.3 record carrying only the inner content-type octet decrypts to a zero-length payload. RFC 8446 Section 5.1 requires a record with an Alert type to carry exactly one message, so any other length is malformed. Require exactly two octets before parsing and return -EBADMSG otherwise. That closes the transport rather than acting on a partly uninitialized alert. Gate the path on a control message rather than a positive count so that a zero-length record reaches the check. Fixes: bee47cb026e7 ("sunrpc: fix handling of server side tls alerts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-2-62d9a631c880@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 514ce838b4f26780fa31da7d7f1e30d696ea6a9e Author: Chuck Lever Date: Sat Aug 15 12:28:44 2026 -0400 SUNRPC: Reject a socket that already has an svc_sock attached commit 0995447b8059c4d23853cdcddbe789c4a2b6bb88 upstream. Writing the same socket descriptor to /proc/fs/nfsd/portlist twice attaches a second svc_sock to one socket. svc_setup_socket() saves the socket's callbacks before installing its own, so the second attach records svc_write_space() as the old write_space callback. svc_udp_init() invokes that callback by way of svc_sock_setbufsize(), and svc_write_space() then calls itself until the kernel stack is exhausted: BUG: TASK stack guard page was hit at ffffc900037d7ff8 svc_write_space+0x90/0x2b0 net/sunrpc/svcsock.c:429 svc_write_space+0xe6/0x2b0 net/sunrpc/svcsock.c:430 ... 700 more ... svc_sock_setbufsize+0x18d/0x220 net/sunrpc/svcsock.c:386 svc_udp_init net/sunrpc/svcsock.c:854 [inline] svc_setup_socket+0xb2f/0x1090 net/sunrpc/svcsock.c:1498 svc_addsock+0x2fd/0x760 net/sunrpc/svcsock.c:1547 __write_ports_addfd fs/nfsd/nfsctl.c:742 [inline] write_ports+0xa5b/0xcc0 fs/nfsd/nfsctl.c:861 nfsctl_transaction_write+0x106/0x1a0 fs/nfsd/nfsctl.c:112 svc_data_ready() and svc_tcp_state_change() chain through their saved callbacks the same way, so a TCP descriptor added twice recurses on the next incoming segment instead. Reaching any of this takes a writer on portlist, and the nfsd filesystem sets no FS_USERNS_MOUNT, so the reproducer needs CAP_SYS_ADMIN in the initial user namespace. Reject a socket that already carries sk_user_data. svc_setup_socket() overwrites that field unconditionally, so a socket some other consumer has claimed is one NFSD would corrupt whether or not the callbacks recurse. Fixes: b41b66d63c73 ("[PATCH] knfsd: allow sockets to be passed to nfsd via 'portlist'") Cc: stable@vger.kernel.org Reported-by: syzbot+54cdc566f64abf51b7f1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=54cdc566f64abf51b7f1 Link: https://patch.msgid.link/20260815162844.8219-1-cel@kernel.org Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 0cbdbf26c456ef6ad1260dbd1b772239ce7bd071 Author: Chris Mason Date: Sun Sep 13 12:07:06 2026 -0400 sunrpc: pin gss module across auth_domain RCU free commit b64d21116374688c33302a6704387c27d1156d72 upstream. A gss auth_domain stores a raw pointer to svcauthops_gss in dom->flavour, and its release queues svcauth_gss_domain_release_rcu() via call_rcu(). Both live in auth_rpcgss.ko text, and nothing pins the module while a domain referencing it is reachable. rmmod auth_rpcgss can therefore unmap that text while an NFSD export still holds a reference to the domain. The export cache is one such holder. When the export is finally released, the domain reference drops from module text: svc_export_put() auth_domain_put(exp->ex_client) auth_domain_release() dom->flavour->domain_release(dom) /* into module text */ svcauth_gss_domain_release() call_rcu(&dom->rcu_head, svcauth_gss_domain_release_rcu) Once auth_rpcgss is unloaded, the domain_release call lands in unmapped memory. The rcu_barrier() in exit_rpcsec_gss() does not help: it waits only for callbacks already queued, and this one is not queued until the export goes away. NFSD's NFSv4 objects import symbols from auth_rpcgss.ko, so only a server built without CONFIG_NFSD_V4 can unload auth_rpcgss while exports still name a gss domain. Take a module reference in svcauth_gss_register_pseudoflavor() before publishing the domain and drop it at the end of svcauth_gss_domain_release_rcu(). The rcu_barrier() then holds the module image until this callback has returned. Fixes: 608a0ab2f54a ("SUNRPC: Add lockless lookup of the server's auth domain") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Chris Mason [ cel: rewrote description ] Link: https://patch.msgid.link/20260913160706.384180-1-cel@kernel.org Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 4f7d57d3dcd127aee89471935c51e62ed1229912 Author: Jeff Layton Date: Tue Sep 1 09:39:41 2026 -0400 SUNRPC: keep the first error in svc_register() commit 9ed91d7c4698e611ea5bfca45076008def831fb3 upstream. svc_register() assigns every pg_rpcbind_set() result to the same "error" variable and returns the last one, so a later result erases an earlier failure. Keep the first error instead of the last. Fixes: 642ee6b209c2 ("SUNRPC: Allow further customisation of RPC program registration") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260901-nfsd-nl-hang-v5-3-a540d86668b0@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 213fba11c0508f2e7d37ce8592072eed28ca0171 Author: Jérémy Jean Date: Thu Sep 10 12:51:20 2026 +0000 SUNRPC: fix oversized GSS proxy token copy commit 62319c2534b603b416fa2aa2f3ef18c311f75010 upstream. gss_read_proxy_verf() allocates one page per token chunk, but it copies the entire linear head of an RPC request into in_token->pages[0]. A UDP datagram can leave more than PAGE_SIZE bytes in the linear head, so a large RPCSEC_GSS INIT token overwrites following pages. Copy the linear head in page-sized chunks before switching to the request page array. The linear head itself can span multiple pages. Fixes: 5866efa8cbfb ("SUNRPC: Fix svcauth_gss_proxy_init()") Cc: stable@vger.kernel.org Signed-off-by: Jérémy Jean Assisted-by: Codex:gpt-5 Link: https://patch.msgid.link/20260910125120.3798995-1-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit d784d46e19b52a553d5c772a18e13b4c6dc84708 Author: Chuck Lever Date: Sat Aug 8 11:40:09 2026 -0400 SUNRPC: Do not credit control-record octets to the RPC stream commit 129e7107b971009bc81643d23f3ab949f540d321 upstream. svc_tcp_sock_recv_cmsg() receives up to two octets into a local buffer, and returns that count for any record type other than TLS_RECORD_TYPE_ALERT. Nothing reached the caller's buffer, but svc_tcp_read_marker() adds the count to sk_tcplen and svc_tcp_read_msg()'s caller adds it to sk_datalen. The RPC stream advances over octets it never received. The fragment marker is assembled from stale sk_marker octets. The message body comes from pages nothing wrote. A conforming client reaches this. RFC 8446 Section 4.6.3 lets either peer send KeyUpdate once it has sent its Finished, and svcsock has no rekey path. kTLS leaves the partially consumed record on ctx->rx_list, so the body drains two octets per svc_tcp_recvfrom() call. Each pair is credited the same way. Return -EAGAIN for a record that is not an alert. That is what svc_tcp_sock_process_cmsg()'s default arm returned before the receive moved into a local buffer. Fixes: bee47cb026e7 ("sunrpc: fix handling of server side tls alerts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-1-62d9a631c880@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 629a17cc81fe0b749bbee8303797b6c99a3e776b Author: Chuck Lever Date: Wed Sep 2 09:31:01 2026 -0400 SUNRPC: Copy the deferred RPC Call from the head buffer commit 2192a56b0686599358909c3e12e9a366f5b5d452 upstream. svc_defer() snapshots the RPC Call for replay once a pending cache upcall resolves. It copies the Call starting (rq_arg.len - head[0].iov_len) bytes before head[0].iov_base, a back-up that once covered a transport header. No transport has had one since commit 983084b2672c ("SUNRPC: Remove svc_rqst::rq_xprt_hlen"), so the two lengths are meant to be equal. An RPCSEC_GSS Call breaks that assumption. Unwrapping the integrity service truncates rq_arg.len by the length of the trailing checksum, and unwrapping the privacy service leaves rq_arg.len short by an amount the client sets with trailing bytes after the wrap token. Neither adjusts head[0].iov_len. Both lengths are size_t, so the subtraction underflows and the copy starts past head[0].iov_base. Every deferred integrity Call replays a shifted snapshot. A deferred replay skips GSS verification, so a shifted snapshot runs as an authenticated Call. With the privacy service the offset is client-chosen. A forged Call placed in that window, naming another user's GSS context handle, runs under that identity. Copy the Call from head[0].iov_base. Refuse to defer a Call whose length runs past the head buffer, so the copy cannot read out of bounds. Fixes: 260c1d1298f6 ("svc: Add transport hdr size for defer/revisit") Cc: stable@vger.kernel.org Reported-by: Kimi Security Team Reported-by: Yilin Zhang Link: https://patch.msgid.link/20260902133101.48914-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit c9c771118ad1f94d70430975383f4440cd2d88fb Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:00:49 2026 -0300 nfsd: zero NFSv4 COMPOUND tag padding commit 3f1181cb09c85499286c7f462d93530b0ebcafcc upstream. nfs4svc_encode_compoundres() copies the tag bytes into reserved XDR space and skips directly to the aligned end of the field. xdr_reserve_space() rounds the reservation up but does not initialize the padding bytes. A remote client can choose a tag length that is not a multiple of four, causing one to three stale bytes from the response page to be returned in the COMPOUND reply. Use xdr_encode_opaque_fixed() to copy the tag and clear its XDR padding. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260915160049.3105481-1-qwe.aldo@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 90202cf720f47d4183b4da8ef43bed7dfec0c572 Author: Jeff Layton Date: Tue Sep 1 09:39:40 2026 -0400 NFSD: validate transport name in listener_set before serv creation commit 421becdc5cf4d7d2fbda393e78ca76d25d277c0f upstream. nfsd_nl_listener_set_doit() holds nfsd_mutex for the whole listener teardown and rebuild. The code checks NFSD_A_SOCK_TRANSPORT_NAME for presence only, and not for content. An arbitrary name therefore reaches svc_xprt_create_from_sa(). There, a name that matches no registered class calls request_module("svc%s", name). That call is a TASK_KILLABLE usermode helper upcall, and it runs under nfsd_mutex. Check the name against the classes that NFSD can create: tcp, udp and rdma. The check goes in nfsd_nl_validate_listeners(), which runs before the code takes nfsd_mutex. The rejection names the offending attribute through extack, since -EPROTONOSUPPORT on its own does not say which entry carried the bad name. This narrows the upcall. It does not remove it. NFSD accepts "rdma" without a condition, so on a kernel that does not build svcrdma the name still reaches request_module("svcrdma") under nfsd_mutex. That is necessary for the modular case, where the autoload is legitimate. Fixes: 16a471177496 ("NFSD: add listener-{set,get} netlink command") Cc: stable@vger.kernel.org Assisted-by: LLM Link: https://syzkaller.appspot.com/bug?extid=c7eae0eb80858a2dba0f Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260901-nfsd-nl-hang-v5-2-a540d86668b0@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 2cdbc244cf895a436f04def419df3bb257e42608 Author: Chuck Lever Date: Tue Sep 1 16:19:46 2026 -0400 NFSD: Set nn->cld_net before registering the cld pipe commit 14996e662f3b734427e2d645cacffc27b779f7d1 upstream. rpc_mkpipe_dentry() instantiates the pipe's dentry before it returns, so the cld pipe can be opened as soon as nfsd4_cld_register_net() has run. __nfsd4_init_cld_pipe() does not store the new cld_net in nn->cld_net until after that call. cld_pipe_downcall() reaches the cld_net only through that pointer and takes cn_lock without checking it, so a write() that lands in the window oopses. Store nn->cld_net once @cn is fully initialized and before the pipe is registered, and clear it again when registration fails. Fixes: f3f8014862d8 ("nfsd: add the infrastructure to handle the cld upcall") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901-alemi-v2-6-e163f94a3a6e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 05f0effc7ed106ab3368d3b0079f55110b784a3e Author: Chuck Lever Date: Fri Aug 28 19:18:41 2026 -0400 NFSD: Return NFSERR_ISDIR for NFSv2 READ and WRITE on a non-regular file commit 07649099cc8c449ea8d37d0e8d6b532fecb24bf8 upstream. Commit 0ac903d1bfdc ("NFS: NFSERR_INVAL is not defined by NFSv2") changed the status NFSD returns for an NFSv2 READ or WRITE of a symlink or other non-regular file from NFSERR_INVAL to NFSERR_IO. RFC 1094 defines neither an INVAL nor a SYMLINK status. U-Boot's NFS client follows a symlink only when READ fails with NFSERR_ISDIR or NFSERR_INVAL. Since that commit it cannot load a boot image through a symlink exported by a Linux NFS server: the load completes with zero bytes transferred. Solaris returns NFSERR_ISDIR when the target of an NFSv2 READ or WRITE is not a regular file. Return the same status from NFSD. Other NFSv2 procedures continue to return NFSERR_IO. Fixes: 0ac903d1bfdc ("NFS: NFSERR_INVAL is not defined by NFSv2") Cc: stable@vger.kernel.org Reported-by: Jörg Sommer Closes: https://lore.kernel.org/linux-nfs/apE90ZRZB8IW_AiS@jo-so.de/ Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260828231841.282003-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 4e80f7648c9c1ad92824183cd9f2200aacf48d88 Author: Chuck Lever Date: Tue Aug 18 14:41:51 2026 -0400 NFSD: Resolve the recall-any mask names in the trace format commit c563a1f0679566d7d586802e5346591d0af8da78 upstream. RCA4_TYPE_MASK_* are enum constants, so the preprocessor cannot fold them into the print format that show_rca_mask() builds for the nfsd_cb_recall_any event. Nothing declares an eval map for them either, so trace_event_eval_update() has no substitution to apply at module load, and the event's format file ships the enumerator names verbatim. trace-cmd and perf cannot decode the bmval0 field. Declare the eval maps for the nine mask bits show_rca_mask() decodes. The format then carries the shift counts as integers, the same shape the SUNRPC trace points already emit from their BIT() flag decoders. Fixes: 638593be55c0 ("NFSD: add CB_RECALL_ANY tracepoints") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260818184151.31180-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit cb7e2de436b19a651324133c4b3bbe42d561c5ce Author: Chuck Lever Date: Tue Sep 1 16:19:44 2026 -0400 NFSD: Reject an oversized principal hash from nfsdcld commit dbed9418c48906dae1a7bc328fb3bc0d0d0020c8 upstream. __cld_pipe_inprogress_downcall() takes the principal hash length from the daemon's GraceStart downcall without checking it against the cc_princhash payload it describes, which holds at most SHA256_DIGEST_SIZE bytes. The length is stored verbatim in the reclaim record, and nfsd4_cld_check_v2() later hands it to memcmp() against a digest array of SHA256_DIGEST_SIZE bytes on the stack. A length up to U8_MAX reads past the end of that array, and the stray bytes can only make the comparison fail, denying the client its reclaim. The pipe is mode 0600 in rpc_pipefs, so the trigger is a broken or hostile nfsdcld rather than an unprivileged task. Reject a length larger than the wire field, as the existing check on the client name length does. Fixes: 6ee95d1c8991 ("nfsd: add support for upcall version 2") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901-alemi-v2-4-e163f94a3a6e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f394f6d81cda9dc8626aeb556600b9fe94d3a5c0 Author: Aldo Ariel Panzardo Date: Tue Sep 15 09:56:36 2026 -0300 nfsd: propagate SETXATTR value decode errors commit cfcfe0b38a66bbc4122c78a2b75e1b97b3534761 upstream. nfsd4_decode_setxattr() stores the status returned while assembling a non-empty attribute value, but then unconditionally returns nfs_ok. An allocation failure can therefore leave a NULL value buffer paired with a non-zero length and allow compound processing to continue. Return the decoder status so that the operation stops on the original error. Fixes: 23e50fe3a5e6 ("nfsd: implement the xattr functions and en/decode logic") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260915125636.2849626-1-qwe.aldo@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 1a5a227bca6a8a9f9d31230697aeb84c62a21da6 Author: Jérémy Jean Date: Mon Aug 17 20:57:14 2026 -0400 nfsd: preflight SEQUENCE replies before accepting a slot commit 35ff1a7a7e3835c3e974bc5c45d335897564ceae upstream. nfsd4_sequence() narrows the reply buffer to the session's cached reply limit before it accepts the slot seqid. A client may negotiate ca_maxresponsesize_cached down to NFSD_MIN_HDR_SEQ_SZ, and nfsd4_alloc_slot() then gives every slot a zero-length sl_data[]. A COMPOUND tag can fill that narrowed buffer until it holds the SEQUENCE opcode but not the status word that follows. nfsd4_encode_operation() returns without running nfsd4_encode_sequence(), so cstate.data_offset stays zero. It leaves op->status at nfs_ok as well, so the COMPOUND is treated as having succeeded. nfsd4_store_cache_entry() declines to cache a lone SEQUENCE that returned an error. That test reads the status the operation reported, so it passes here. The copy starts at offset zero and takes the whole reply, RPC and COMPOUND headers included, into the zero-length sl_data[]. The COMPOUND tag is copied along with it, so the client picks most of the bytes written past the end of the slot: BUG: KASAN: slab-out-of-bounds in read_bytes_from_xdr_buf+0x1bc/0x390 Write of size 80 at addr ffff888003a549cd by task kunit_try_catch/24 __asan_memcpy+0x38/0x60 read_bytes_from_xdr_buf+0x1bc/0x390 nfsd4_sequence_done+0x5b0/0x810 nfs4svc_encode_compoundres+0x1bf/0x240 Check that the fixed-size SEQUENCE result, plus room for a following operation's error status, fits the negotiated limit before narrowing the buffer and consuming the slot seqid. The slot and its reply cache are left unchanged, as RFC 8881 Section 2.10.6.1.2 requires of an error returned from SEQUENCE. Fixes: 47ee52986472 ("nfsd4: adjust buflen to session channel limit") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Tested-by: Mayank Jangid (OpenSec Intelligence) Link: https://patch.msgid.link/20260817-jean-v1-1-9e356596ab85@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 68ad60056fb5377849d033aea42e81ba3ee39f79 Author: Chuck Lever Date: Tue Sep 15 20:42:40 2026 -0400 NFSD: map fh_verify() status codes for NFS_ACLv3 replies commit b1eb9f1aea88a0d7ec8116a70c33b7b31ad0a3eb upstream. The NFS_ACLv3 protocol shares its status code space with NFSv3, which has NFS3ERR_BADHANDLE but no NFSERR_NOFILEHANDLE. An NFS_ACLv3 GETACL or SETACL request that carries an empty file handle gets a reply with status 10020, a value the client cannot interpret. Commit 1459ad57673b ("nfsd: Move error code mapping to per-version proc code.") made fh_verify() return nfserr_nofilehandle for an empty handle regardless of protocol version. The NFSv3 procedures gained nfsd3_map_status() in exchange, but the NFS_ACLv3 procedures did not, so the unmapped status reaches the encoder. Add the same mapping to the NFS_ACLv3 procedures. Fixes: 1459ad57673b ("nfsd: Move error code mapping to per-version proc code.") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260916004240.141975-2-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit eb97d69f5770857ecbe38da4ae3491d1aacb53ae Author: NeilBrown Date: Fri Jul 17 19:27:49 2026 +1000 nfsd: honour client-provided attributes for NFS4_CREATE_EXCLUSIVE4_1 commit ddfabbc7840891e09cd500ab97c9cd36b650ec24 upstream. When a file is created with a v4.1 OPEN which requests NFS4_CREATE_EXCLUSIVE4_1, the request can include attributes to be set. However when the mtime/atime are set to hold the verifier, the other ia_valid flags are cleared, so no attributes requested by the client are used. This code was originally written for NFSv3 where NFS3_CREATE_EXCLUSIVE never includes attributes. When it was updated for v4.1, the fact that an exclusive create CAN include attributes was not handled properly. Fixes: ac6721a13e5b ("nfsd41: make sure nfs server process OPEN with EXCLUSIVE4_1 correctly") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: NeilBrown Link: https://patch.msgid.link/20260717093001.1972119-2-neilb@ownmail.net Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 202b7a6c462daa55a9f4b01f0a25eca2b8d5f2e3 Author: Cen Zhang (Microsoft Security FORGE Labs) Date: Fri Aug 28 00:19:25 2026 -0400 nfsd: hold cl_lock in client_has_openowners() commit 5336899b5491eaa2ac22c2925d87daab2b140eb3 upstream. client_has_openowners() walks clp->cl_openowners and reads so_stateids without clp->cl_lock. nfs4_put_stateowner() unhashes that openowner under cl_lock and then frees it, so a concurrent EXCHANGE_ID with mismatched creds can use-after-free the nfs4_openowner. BUG: KASAN: slab-use-after-free in client_has_state+0x10a/0x140 fs/nfsd/nfs4state.c:3718 client_has_openowners() nfsd4_exchange_id nfsd4_proc_compound nfsd_dispatch svc_process Take clp->cl_lock while client_has_openowners() walks the openowner list. Fixes: 4eaea1342507 ("nfsd: improve client_has_state to check for unused openowners") Cc: stable@vger.kernel.org Reported-by: Xiang Mei (Microsoft) Cc: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) Link: https://patch.msgid.link/20260828041925.36758-1-blbllhy@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 6239443bacb4cb1bb4a9e868474ccc03b2f709ce Author: Chuck Lever Date: Mon Aug 24 10:04:40 2026 -0400 NFSD: Fix out-of-bounds read in the rpc_status dump commit cbea14890783fead76f878caf0775a62a42049bf upstream. nfsd_nl_rpc_status_get_dumpit() loads args->opcnt and args->ops separately, then walks ops[] before rechecking rq_status_counter. A COMPOUND that completes between the two loads runs nfsd4_release_compoundargs(), which zeroes opcnt and points ops back at the eight-entry inline array. A dump that already sampled an opcnt of 200 clamps it to the sixteen slots in rq_opnum, then indexes iops[0..15]. iops is the last member of struct nfsd4_compoundargs and rq_argp is allocated at exactly that size, so the walk runs off the end of the allocation. The trailing recheck discards the sampled data, but the read has already happened. NFSD_CMD_RPC_STATUS_GET carries no GENL_ADMIN_PERM, so an unprivileged local user can repeat the dump against a busy server until it lands in the window. Sample opcnt and ops into locals, then finish the counter recheck before dereferencing ops. An unchanged counter means both came from the same COMPOUND, where opcnt cannot exceed what ops holds. Fixes: bd9d6a3efa97 ("NFSD: add rpc_status netlink support") Cc: stable@vger.kernel.org Reported-by: Prabhakar Pujeri Closes: https://lore.kernel.org/linux-nfs/20260823113255.3417-1-prabhakar.pujeri@dell.com/ Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260824-nfsd-posix-acl-ownership-v1-1-090fffc608ec@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit c480c7bea087d923f97a0fd88e51943c3a9cb407 Author: Wentao Liang Date: Thu Sep 17 16:31:54 2026 +0000 nfsd: Fix id-to-name cache entry leak in idtoname_parse() commit 8ca3b74c0c447af17d0e27e76658a3d4cae3c5ba upstream. idtoname_lookup() returns the id-to-name cache entry with a new reference. The name is parsed between the lookup and the update call, and when the parsed name is malformed (negative length or longer than IDMAP_NAMESZ), idtoname_parse() jumps to the error label without dropping the reference returned by idtoname_lookup(), leaking the cache entry. Release the reference with cache_put() before taking the error exit. Fixes: f9ecc921b5b5 ("[PATCH] knfsd: Use new cache code for name/id lookup caches") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260917163154.2162438-1-vulab@iscas.ac.cn Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit d79a7e7845e2ac8cf98340f22f2e9a90d568529b Author: Chuck Lever Date: Sun Aug 16 13:19:14 2026 -0400 NFSD: Fail a pool_threads read whose reply does not fit commit e27c63245903402ccfdb46c576462981a7e032e3 upstream. The reply to a pool_threads read is the list of per-pool thread counts, formatted into a buffer of SIMPLE_TRANSACTION_LIMIT bytes. snprintf() truncates its last write and strlen() measures only what fit, so a reply too long for that buffer ends mid-number with no terminating newline. A pool running 4096 threads is reported as 40. Nothing marks the reply as incomplete, so an administrator reads a plausible but wrong count. Take snprintf()'s return value, which reports the truncation strlen() cannot see, and fail the read with -ENAMETOOLONG when the list does not fit. That is the errno svc_one_xprt_name() already returns for the same condition. Suggested-by: David Laight Fixes: eed2965af1ba ("[PATCH] knfsd: allow admin to set nthreads per node") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260812193349.13347-1-david.laight.linux@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 065764e256ebff20201dca5bc6ff075c6cb62e17 Author: Ameer Hamza Date: Mon Aug 24 22:36:41 2026 +0500 nfsd: don't modify a session slot when replaying its cached reply commit 2987838317501ff67b672ac2a441fe34b7729f3d upstream. nfsd4_sequence() claims a session slot by setting NFSD4_SLOT_INUSE under nn->client_lock. A reply served from the slot's reply cache does not claim it, and that distinction lived only in cstate->status, which nfsd4_sequence() set to nfserr_replay_cache. Commit cc028a10a48c ("NFSD: Hoist status code encoding into XDR encoder functions") moved nfsd4_proc_compound()'s cstate->status assignment below the out: label, and the replay path's goto out was the one path that relied on skipping it. The test in nfsd4_sequence_done() therefore no longer identifies a replay, and every replay now stores its reply and clears NFSD4_SLOT_INUSE as though it owned the slot. NFSD4_SLOT_INUSE is the interlock: check_slot_seqid() rejects every sequence id for a slot that is in use, before replay_matches_cache() runs. A replay never sets it, so two replays can be in flight on the same slot at once. One can read slot->sl_cred under nn->client_lock while the other's completion frees and rebuilds it from the XDR encoder without that lock. Two completions can also collide with each other and release the same group_info twice. free_svc_cred() leaves cr_uid, cr_gid and cr_flavor intact, so the reader passes every earlier test in same_creds() and dereferences a NULL cr_group_info. From a 6.12.91 production server: BUG: kernel NULL pointer dereference, address: 0000000000000004 CPU: 63 UID: 0 PID: 39015 Comm: nfsd RIP: 0010:same_creds+0x38/0xa0 [nfsd] RDX: 0000000000000000 Call Trace: nfsd4_sequence+0x6a8/0x910 [nfsd] nfsd4_proc_compound+0x345/0x670 [nfsd] nfsd_dispatch+0x100/0x220 [nfsd] svc_process_common+0x311/0x700 [sunrpc] svc_process+0x131/0x1c0 [sunrpc] svc_recv+0x7ef/0x9c0 [sunrpc] nfsd+0xa3/0x100 [nfsd] Kernel panic - not syncing: Fatal exception Since v6.14 a live session's slot table can shrink, and the unowned store becomes a use-after-free write. nfsd4_sequence() defers the shrink while a slot is in use, but it tests NFSD4_SLOT_INUSE, which a replay does not set, so free_session_slots() can kfree() the slot the replay still holds in cstate->slot. Record the claim in cstate->slot_owned when nfsd4_sequence() accepts a request and test that in nfsd4_sequence_done(), so only the request that claimed the slot updates its cached reply and clears NFSD4_SLOT_INUSE. svc_generic_init_request() zeroes the compound response before each request, so the flag starts clear. Fixes: cc028a10a48c ("NFSD: Hoist status code encoding into XDR encoder functions") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Ameer Hamza Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260824173641.3274260-1-ameer.hamza@truenas.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit e058341ceb177226fdb20a36d48fa827851d9c81 Author: Chuck Lever Date: Tue Sep 1 16:19:41 2026 -0400 NFSD: Don't complete a cld upcall the daemon has not read commit 7f4bf851aca4e18940ebf2bddf4ba6783802ee81 upstream. cld_pipe_downcall() matches a reply to its upcall on the xid alone. A write that arrives before the daemon has read that upcall completes __cld_pipe_upcall() while its struct rpc_pipe_msg is still queued on the pipe. The waiter returns, its stack frame goes away, and the pipe keeps a list_head that points into it. The next rpc_queue_upcall() walks that pointer: BUG: KASAN: vmalloc-out-of-bounds in __list_add_valid_or_report Read of size 8 at addr ffffc90007027950 by task syz.0.96/13066 __list_add_valid_or_report+0x6a/0x130 rpc_queue_upcall cld_pipe_upcall nfsd4_cld_grace_start nfsd4_cld_tracking_init The pipe is mode 0600 in rpc_pipefs, so the trigger is a broken or hostile nfsdcld rather than an unprivileged task. Record whether the daemon has consumed the whole message and complete only when it has. cld_pipe_destroy_msg() runs on every path by which the pipe releases a message, so it can maintain that flag under cn_lock. nfsdcld sends its -EINPROGRESS downcalls only after reading the upcall, so the new check does not break the GraceStart record stream. Fixes: f3f8014862d8 ("nfsd: add the infrastructure to handle the cld upcall") Cc: stable@vger.kernel.org Reported-by: Farhad Alemi Closes: https://lore.kernel.org/linux-nfs/CA+0ovCjVF58WLeen2ctdzHyWUASAAW3Y=Yjihyq0pFApYawtDg@mail.gmail.com/ Link: https://patch.msgid.link/20260901-alemi-v2-1-e163f94a3a6e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 6338a0182628da8ea1e66ac5397510796e71c632 Author: Chuck Lever Date: Mon Aug 17 21:08:36 2026 -0400 NFSD: Do not send CB_RECALL_ANY to NFSv4.0 clients commit 95ff0c079b9cab91f2327beb4197a3bc48c71f55 upstream. deleg_reaper() sends CB_RECALL_ANY to every ACTIVE client holding delegations, but CB_RECALL_ANY is an NFSv4.1 operation. An NFSv4.0 client's callback service accepts only CB_GETATTR and CB_RECALL, so it replies OP_ILLEGAL. The decoder maps the unexpected opnum to -EIO, and nfsd4_cb_done() marks the client's callback channel down. Nothing brings the channel back. nfsd4_run_cb_work() sets NFSD4_CB_UP only for a minor version above zero, and the only nfsd4_probe_callback() call site an NFSv4.0 client reaches is nfsd4_setclientid_confirm(). One visit from the reaper therefore leaves the channel marked down until the client re-establishes its clientid. RENEW then returns NFS4ERR_CB_PATH_DOWN for as long as the client holds delegations. nfsd4_cb_channel_good() stops returning true, so the client is granted no further delegations. Skip clients at minor version zero. Fixes: 44df6f439a17 ("NFSD: add delegation reaper to react to low memory condition") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260817-recall-any-keep-count-v5-1-3b2cffce701e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 019cf7e0eebf6dc14b465cc984390b41c854da69 Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:00:22 2026 -0300 NFSD: copy SETXATTR data from all XDR buffer segments commit b01319947c69b0e3ea0fcd4b675eb892f9cad8a0 upstream. nfsd4_vbuf_from_vector() manually copies the head followed by whole pages starting at offset zero. This assumes that all remaining data starts at the beginning of the page array and that no data is stored in the tail. However, nfsd4_decode_setxattr() passes an xdr_buf returned by xdr_stream_subsegment(). Such a sub-buffer can have a nonzero page_base and can span its page and tail segments. Ignoring that layout can copy the wrong bytes into the value passed to vfs_setxattr(). Use read_bytes_from_xdr_buf(), which observes the complete xdr_buf layout. Fixes: c1346a1216ab ("NFSD: Replace the internals of the READ_BUF() macro") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260915160022.3105295-1-qwe.aldo@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 842e2215a87d062b69d5170840f34fbd83f47b41 Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:01:19 2026 -0300 nfsd: clear XDR padding in GETXATTR replies commit daba58690339ae86f1ebeb5197aa1369fae37e57 upstream. nfsd4_vbuf_to_stream() uses a raw memcpy() for the first fragment of an attribute value. xdr_reserve_space() aligns the reservation but does not initialize the extra bytes. If the complete value fits in that fragment, the loop that clears padding for the final fragment is never entered. A remote client reading an attribute whose length is not a multiple of four can therefore receive one to three stale bytes from the response page. Encode the first fragment with xdr_encode_opaque_fixed(), matching the final-fragment path and ensuring that any XDR padding is zeroed. Fixes: 23e50fe3a5e6 ("nfsd: implement the xattr functions and en/decode logic") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260915160119.3105745-1-qwe.aldo@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 4a6c685d7e443d5c12197d01576202544247d107 Author: Jeff Layton Date: Tue Sep 1 09:39:39 2026 -0400 NFSD: cap the number of listeners accepted in listener_set commit 9a05e5ee0a98b9550521df86936b5f825bc07ec2 upstream. nfsd_nl_listener_set_doit() matches each requested listener against the existing set. The nested loop that does this is O(N * M), where N is the requested count and M is the existing count. The loop runs under sv_lock with bottom halves disabled. A userland request with a very large listener list can therefore spin in atomic context for a long time. Reject a request that carries more than NFSD_NL_LISTENER_MAX (1024) entries. The check goes in nfsd_nl_validate_listeners(), before the code takes any lock. The limit is far above any realistic configuration. This patch does not cap M. Only the message size bounded N; real sockets bound M. A listener_set result set is the requested set, so that path also holds M at the cap, but __write_ports_addxprt() adds two listeners per call and removes none, so repeated calls can push M past it. The worst case under sv_lock is therefore 1024 * M, plus 1024 nla_parse_nested() calls. Both interfaces require CAP_NET_ADMIN. Fixes: 16a471177496 ("NFSD: add listener-{set,get} netlink command") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260901-nfsd-nl-hang-v5-1-a540d86668b0@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 88f3916a239fc945362eaac13ca2e29f59539f42 Author: Benjamin Coddington Date: Thu Oct 15 07:33:07 2026 -0400 NFSv4/flexfiles: fail I/O to the data server once a lock is lost commit 7fa2ad367abe6d3155daefb57331e7fce1a17afd upstream. When a client loses a byte-range lock, because its lease expired and it may not recover the lock (nfs.recover_lost_locks=0) or because reclaim failed, it marks the lock state NFS_LOCK_LOST and fails further I/O by that lock owner. Otherwise an application that believes it holds a lock over a range is never told that the lock is gone, and can overwrite data that another client has since written under its own lock on that range. The NFSv4 READ/WRITE and file layout I/O paths apply this in rpc_call_prepare, where nfs4_set_rw_stateid() returns -EIO for a lost lock. The flexfiles data server I/O path does not: the NFSv3 data server path never checked, and the check on the NFSv4 path was removed when the data server stateid began to be taken from the layout. Fail read and write RPCs to the data server in rpc_call_prepare when the lock is lost. The data server path has no use for the stateid that nfs4_set_rw_stateid() selects, and selecting it looks up a delegation or open stateid on every I/O. Instead add nfs4_lock_context_lost(), which only tests NFS_LOCK_LOST, and check it alongside the open state. Its lookup, __nfs4_lookup_lock_state(), is split out of __nfs4_find_lock_state() and takes no reference: a lock state is only unlinked from state->lock_states under state->state_lock, so one found while holding that lock cannot be freed before it is released. Use it in nfs4_copy_lock_stateid() as well, which only reads the lock state under that lock. That drops a reference get and put from stateid selection for all NFSv4 I/O without changing the stateid selected. Terminating the RPC in rpc_call_prepare is not enough on its own. The done callback reads the -EIO as a data server connection error, forgets the device ID, and resets the I/O to pNFS (or, for an NFSv4 data server, possibly to the MDS). After a reset to pNFS a new LAYOUTGET is granted and rpc_call_prepare fails the I/O again, without end. The existing NFS_CONTEXT_BAD check does not loop, since the open state is then invalid and pnfs_update_layout() fails the reset I/O, but it still forgets the device ID. So when an RPC that was never sent fails and the open context is bad, the open state is invalid, or the lock is lost, complete it with -EIO without error handling. An RPC that was sent and failed is handled as before, so a real data server error is still reported to the MDS. Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver") Fixes: bb21ce0ad227 ("flexfiles: use per-mirror specified stateid for IO") Cc: stable@vger.kernel.org Tested-by: Arun Potharaju Assisted-by: LLM Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 9e4d05691e6677dcbaa6d20a87ee8bb6269c7c4b Author: Benjamin Coddington Date: Tue Sep 15 08:22:09 2026 -0400 NFSv4/filelayout: Anchor page coalescing on pattern_offset commit 7f2d221b01f356b6bb3bb6efef998f8b28339824 upstream. filelayout_pg_test() bounds page coalescing to a single stripe unit using an offset relative to pls_range.offset, but the data server is selected by nfs4_fl_calc_j_index() using an offset relative to pattern_offset. When a segment's pattern_offset and range offset are not congruent modulo the stripe unit, the coalescing window is shifted off the DS-selection grid, so a coalesced I/O can straddle a stripe boundary and send the bytes past it to the wrong data server. Anchor coalescing on pattern_offset to match nfs4_fl_calc_j_index(). Stripe-congruent segments, including the common whole-file pattern_offset 0 case, are unchanged. Fixes: c6194271f94b ("pnfs: filelayout: support non page aligned layouts") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 1658fe9e4440665cf34799c543816bd3259eb503 Author: Benjamin Coddington Date: Fri Sep 4 08:56:02 2026 -0400 NFSv4.1/pnfs: suspend pNFS on NFS4ERR_TOOSMALL from LAYOUTGET commit 28c950413605fb5b6cb3863c5e3274ea69701097 upstream. If the layout for the requested range is larger than the size the client advertised in loga_maxcount, RFC 8881 Section 18.43.3 has the metadata server return NFS4ERR_TOOSMALL. The client caps loga_maxcount at a single page, so a flexfiles server that stripes a layout segment across several dozen data servers produces this error today. The client has no handling for it: nfs4_stat_to_errno() maps the error to -ETOOSMALL during decode, which nothing in the layoutget path recognizes and nfs_error_is_fatal() does not consider fatal, so pnfs_update_layout() clears the layout fail bit and returns no segment. The I/O falls back to the MDS, but because no fail bit was set, every subsequent pageio attempt sends another LAYOUTGET that is doomed to the same NFS4ERR_TOOSMALL. Files whose layouts do not fit the reply buffer never use pNFS and pay an extra round trip on every pageio. Map -ETOOSMALL to -EMSGSIZE in the layoutget exception handler and have pnfs_update_layout() treat it like NFS4ERR_LAYOUTUNAVAILABLE: mark the layout mode as failed and fall back to I/O through the MDS. Fixes: d600ad1f2bdb ("NFS41: pop some layoutget errors to application") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Benjamin Coddington Reviewed-by: Jeff Layton Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit e4db79581b42ced776b726587571969aac162c74 Author: Chuck Lever Date: Tue Sep 1 16:19:48 2026 -0400 pnfs/blocklayout: Complete a device upcall when the pipe is closed commit 2a25cc8e984610828a526086313b8a7aeefe507d upstream. Once blkmapd has read a whole upcall, rpc_pipe_read() unlinks the message from every pipe list, so the purges in rpc_pipe_release() and rpc_close_pipes() no longer reach it. bl_upcall_ops supplies no .release_pipe callback, and bl_pipe_destroy_msg() returns without completing the upcall because a downcall is expected to follow. A daemon that exits between the read and the write therefore strands its waiter: bl_resolve_deviceid() sleeps in wait_for_completion() and never returns, and it holds nn->bl_mutex across that wait, so every later device resolution in the net namespace blocks behind it. Add a .release_pipe that completes an upcall blkmapd has consumed and left unanswered. Completing an upcall retires it, so a message the framework has already purged is no longer in flight and is not completed a second time here. Fixes: fe0a9b740881 ("pnfsblock: add device operations") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901-alemi-v2-8-e163f94a3a6e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 4ef03b442c589034637804bcfbecfce7a4c684d8 Author: Chuck Lever Date: Tue Sep 1 16:19:45 2026 -0400 pnfs/blocklayout: Complete a device upcall only on its own reply commit acfbea6c5e27c68d6b6d12849eb2b7f8466ccf06 upstream. bl_pipe_downcall() wakes bl_resolve_deviceid() on any write of the right size, without checking that blkmapd has read the upcall being replied to. A write that arrives first returns the waiter while its struct rpc_pipe_msg is still queued on the pipe, which then holds a list_head into a dead stack frame. Reaching the pipe takes root, so the trigger is a broken or hostile blkmapd. The wait has two further defects. bl_resolve_deviceid() sets TASK_UNINTERRUPTIBLE only after rpc_queue_upcall() has made the message visible, so a reply that lands in between wakes a running task and the schedule() that follows sleeps forever holding bl_mutex. And nn->bl_mount_reply is never reset, so when the pipe purges an unread upcall the waiter takes the previous reply as its own. Move the message into struct nfs_net, where bl_mutex already limits the pipe to one upcall per net namespace. Accept a reply only while blkmapd has read the whole message and no earlier reply has been taken, and reject any other write with -EINVAL. Wait for that reply on a completion so it cannot slip past the sleep, and check msg->errno before trusting it. Fixes: fe0a9b740881 ("pnfsblock: add device operations") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901-alemi-v2-5-e163f94a3a6e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 7b554be891128f304c7b9c61637a1d3f928917cf Author: Benjamin Coddington Date: Tue Sep 15 08:22:06 2026 -0400 pNFS: Fix CB_NOTIFY_DEVICEID CHANGE to consume ndc_immediate commit a0cb76dc3b2919af8257fc08b4f9a79a35442483 upstream. decode_devicenotify_args() gated the trailing ndc_immediate on cbd_layout_type rather than cbd_notify_type, so the flag was never consumed and a multi-item cnda_changes<> misaligned after the first entry. Fixes: 1be5683b03a7 ("pnfs: CB_NOTIFY_DEVICEID") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit cde80904e285a7ac29ba2e06bc23a60b09b05f54 Author: Dominik Maier Date: Fri Oct 23 01:21:16 2026 +0200 smb: client: fix slab-out-of-bounds write in id_mode_to_cifs_acl() commit a377a3645c7d0246af0bc4ef24db94bb2670bdde upstream. In id_mode_to_cifs_acl(), while the chown branch reserves sizeof(struct smb_ntsd) + 2 * sizeof(struct smb_sid) (plus sizeof(struct smb_acl) and the worst-case ACE space after commit 0ee150794c75 ("smb: client: fix heap overflow in DACL owner/group rewrite")), the chmod branch only adds 2 * sizeof(struct smb_ace) or 5 * sizeof(struct smb_ace) to secdesclen (or 1 * sizeof(struct smb_ace) on posix). However, the chmod branch also invokes build_sec_desc() -> copy_sec_desc(), which unconditionally writes the Owner SID at pnntsd + sidsoffset and the Group SID at pnntsd + sidsoffset + sizeof(struct smb_sid) (2 * 68 = 136 bytes total), and set_chmod_dacl() always writes a struct smb_acl header (8 bytes) even when the source descriptor has dacloffset == 0. When a security descriptor has compact or overlapping Owner/Group SIDs (or dacloffset == 0), calling chmod() under-allocates pnntsd and writes past the end of the slab buffer. Reserve sizeof(struct smb_acl) + 2 * sizeof(struct smb_sid) (plus sizeof(struct smb_ntsd) on the posix path) in the chmod branch of id_mode_to_cifs_acl(). Fixes: 7ee0b4c635c0 ("cifs: fix hardcoded default security descriptor length") Fixes: f5065508897a ("cifs: Retain old ACEs when converting between mode bits and ACL.") Assisted-by: ARTIST LLM Signed-off-by: Dominik Maier Cc: stable@vger.kernel.org Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 8e0d425b808c367f5033eb72aa4528ae18473627 Author: Abdifatah Suruur Date: Fri Oct 23 14:52:46 2026 +0300 smb: client: fix fiemap wild read on empty truncated response commit f5baa17a0f316c235d61623ac8e8fb32c2b3c0cc upstream. smb3_fiemap() treats -E2BIG from SMB2_ioctl() as a truncated range blob and loops for the next chunk. If the server reports STATUS_BUFFER_OVERFLOW with OutputCount == 0, SMB2_ioctl() returns -E2BIG with out_data == NULL and out_data_len == 0, and the existing length checks accept the empty result. The loop then evaluates next = out_data[num - 1].file_offset + ... with num == 0, reading 16 bytes before NULL. Reject a truncated range blob that contains no range, so the resume offset is never computed from an empty response. Also require the last range in a truncated blob to advance the resume offset without overflowing, and to stay within the requested range; a malicious or broken server could otherwise make no progress or underflow len and loop forever. Free the previous response buffer before retrying. Reproduced on 6.6.87.2 with a malicious SMB2 server that answers FSCTL_QUERY_ALLOCATED_RANGES with STATUS_BUFFER_OVERFLOW and OutputCount == 0; an FS_IOC_FIEMAP ioctl on the mount oopses in cifs_fiemap() with CR2 = fffffffffffffff8. The code path is unchanged on mainline. Fixes: 2f3ebaba13ce ("cifs: add fiemap support") Cc: stable@vger.kernel.org Signed-off-by: Abdifatah Suruur Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 75fd4c72aa3dcfabb318144636f416be6796d423 Author: Luxiao Xu Date: Fri Oct 16 15:11:01 2026 +0800 smb: client: fix buffer overflow in SMB2_tcon() commit 73cc469b0ff7551f8537ea919709973e6dc4f514 upstream. In SMB2_tcon(), unc_path is allocated with a fixed buffer size of MAX_SHARENAME_LENGTH * 2 bytes (672 bytes). However, the user-controlled UNC path (tree) length is passed to cifs_strtoUTF16(), which assumes the destination buffer is large enough and writes strlen(tree) + 1 UTF-16 code units. Commit 62a1a439e0fd ("cifs: clean up handling of unc= option") removed the length check on UNC mount options, allowing mount paths to exceed MAX_SHARENAME_LENGTH while retaining the fixed-size buffer allocation in SMB2_tcon(). Consequently, an oversized UNC string causes cifs_strtoUTF16() to write past the end of the heap object, resulting in a slab-out-of-bounds write. Furthermore, if a tree exceeds MAX_TREE_SIZE characters, strscpy() truncates it in cifs_tcon::tree_name, causing subsequent reconnects or failovers to fail. Fix this by first verifying that the length of tree does not exceed MAX_TREE_SIZE, returning -EINVAL if it does. Then, dynamically allocate unc_path based on the length of tree so that it safely accommodates all UTF-16 code units for paths within MAX_TREE_SIZE. Fixes: 62a1a439e0fd ("cifs: clean up handling of unc= option") Cc: stable@vger.kernel.org Reported-by: Xin Liu Closes: https://bugtracker.nebusec.ai/f/3292 Assisted-by: LLM Suggested-by: Paulo Alcantara Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei [pc: remove unused MAX_SHARENAME_LENGTH] Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit d1b779a4b5acf9a8692b7f002bf6d98e0597cc86 Author: Paulo Alcantara Date: Sun Oct 25 20:48:08 2026 -0300 smb: client: don't resurrect an exiting tcon from cached dir workers commit d58e7b40908a8a57755811d5b37af1df3380278f upstream. cfids_laundromat_worker() bumps tcon->tc_count for every expired open cfid and queues cached_dir_offload_close() without checking whether the tcon is already being torn down. Racing with the final cifs_put_tcon(), the tcon comes back from zero and gets torn down twice: T1 T2 cifs_put_tcon() --tc_count == 0, TID_EXITING tconInfoFree() free_cached_dirs() cancel_delayed_work_sync() cfids_laundromat_worker() ++tc_count == 1 queue_work(serverclose_wq) kfree(tcon->origin_fullpath) kfree(tcon) cached_dir_offload_close() close_cached_dir() [UAF] cifs_put_tcon() tconInfoFree() [double free] cached_dir_lease_break() also bumps tc_count without tc_lock, racing with the laundromat's locked update. Take the tcon reference through a helper that refuses once the tcon is TID_EXITING or its refcount has dropped to zero. Queued put_work and close_work then always hold a tcon reference, so tconInfoFree() can't run before they finish and free_cached_dirs() doesn't need to flush any workqueue. If the laundromat can't get a reference, put the cfid back on the dying list for free_cached_dirs() to free; its handle goes away with the tree connection. The lease break path finds the tcon on ses->tcon_list under cifs_tcp_ses_lock, so it can't see TID_EXITING, but it now takes tc_lock. Fixes: 3fa640d035e5 ("smb: During unmount, ensure all cached dir instances drop their dentry") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: David Howells Cc: Namjae Jeon Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e736ee3660eac5922729a9b3c55cecd74611663c Author: VeroFess Date: Mon Oct 26 15:01:03 2026 +0900 smb: server: size directory name conversion buffer correctly commit f1f37834eaba5904103af1f18afe3510c7e9dc71 upstream. A 2048-byte ASCII directory name needs 4098 bytes when converted to UTF-16, including the terminator. ksmbd_convert_dir_info_name() caps its allocation at PATH_MAX and writes past the end of that buffer. Allocate space for one UTF-16 code unit per input byte plus the terminator. Use kmalloc_array() to check the size calculation. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Assisted-by: gpt 6 sol with daybreak blue Signed-off-by: VeroFess Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 01b7cf35894d4f6876ea9942929529660edd7b4c Author: Darrick J. Wong Date: Mon Oct 12 08:22:25 2026 -0700 xfs: range-check bc_levels array access in scrub tracepoints commit 73b7276b8a4b5eb272f3c3b36ea3042e786f4741 upstream. LOLLM noticed xchk_btree()'s odd habit of passing cur->bc_nlevels to xchk_btree_ptr_ok when we're checking the pointer to the root block at the start of the btree scan. This enables us to skip checking the pointer for an inode btree's root (since it doesn't have one) but doesn't handle per-AG btrees quite correctly. There isn't a problem for __xfs_btree_check_ptr itself, but the corruption tracepoint naively walks off the end of bc_level[]. Fix that by adding a helper to do an implicit range check. Cc: stable@vger.kernel.org # v5.16 Fixes: 6ca444cfd66354 ("xfs: prepare xfs_btree_cur for dynamic cursor heights") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit c6d52522e23726465c5f6009c2fbcb54bae2c9c2 Author: Darrick J. Wong Date: Sun Oct 4 22:56:51 2026 -0700 xfs: propagate errors while checking null siblings commit e5bde75a816b3549942f4b09a8bf09006b7ea9de upstream. LOLLM observes that if xfs_da3_path_shift returns an error here, scrub doesn't handle it the way that it handles most runtime errors. Instead, it drops the error and keeps going, even though that's not how that's supposed to work. Fix that by calling xchk_da_process_error to set corruption flags and then jump out of the flow of execution. Cc: stable@vger.kernel.org # v4.15 Fixes: 7c4a07a424c18d ("xfs: scrub directory/attribute btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 3a7ebc913bed7c63852c578cb3453a15e4fdadde Author: Darrick J. Wong Date: Mon Oct 12 23:07:48 2026 -0700 xfs: opportunistically skip btree block checks commit 4ce244b234c251963fca6dff9de6edf26a209d08 upstream. LOLLM notices that both callers of xchk_btree_get_block will return early if *pblock is NULL after a successful return. However, xchk_btree_get_block itself can return 0 after flagging a corruption. There's no point in continuing after we've found a corruption, so null the pointer out. Cc: stable@vger.kernel.org # v4.15 Fixes: cc3e0948d2686f ("xfs: scrub the shape of a metadata btree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 5d6cfd08e8c68e614e141dd3e7681ecb2e52a3ba Author: Darrick J. Wong Date: Mon Oct 12 23:06:46 2026 -0700 xfs: only written file data blocks can be shared commit 634b63baf05062988456a0bd5df2696c14ea2949 upstream. LOLLM noticed that xchk_refcountbt_rmap_check (and its rt equivalent) will count any rmap owner towards the shared count. However, the only blocks that can be shared between xfs files are written file data blocks; and the only blocks that can have single-refcount entries are COW staging extents. Fix the checking code. Cc: stable@vger.kernel.org # v4.16 Fixes: dbde19da963706 ("xfs: cross-reference the rmapbt data with the refcountbt") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit d5a1bd53cd95ea12028a028c66edf6bcb0788f83 Author: Darrick J. Wong Date: Mon Oct 12 08:21:38 2026 -0700 xfs: never reset the default quota timer commit ddf4fe30c3fd7d37cf9bad3887ddb69984954cf4 upstream. LOLLM notices that xrep_quota_fix_timer doesn't check the dquot id, which means that it can inadvertently reset the default quota timer when we really meant to ensure that a (non-root) quota overage timeout has a sane timestamp. Fix that. Cc: stable@vger.kernel.org # v6.8 Fixes: a5b91555403e3a ("xfs: repair quotas") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 00d30345f93cdfd3e09fbbaa01079ddb359322c8 Author: Darrick J. Wong Date: Mon Oct 12 23:05:43 2026 -0700 xfs: fix data fork block count check in xrep_inode_blockcounts commit 147f9f8300cb284923e08bb8a7b32ba9681c45ed upstream. LOLLM notices that for non-reflink realtime files, the @count output of xchk_inode_count_blocks includes both the file blocks on the realtime volume and the bmap btree blocks on the data volume. Therefore, we must compare this value to rblocks + dblocks to avoid unnecessary failure. Cc: stable@vger.kernel.org # v6.8 Fixes: 2d295fe65776d1 ("xfs: repair inode records") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit d81cc4b379f0ad4cad022896a174313fdba5a780 Author: Darrick J. Wong Date: Mon Oct 12 08:21:54 2026 -0700 xfs: fix correction of unwritten extents in quota file data fork commit 6f2792720673f569fa3e1f68181b9d6fd26802b5 upstream. LOLLM noticed a couple of problems with the code that fixes unwritten mappings in the quota file's data fork: first, we should zero the ondisk contents as part of converting them to "unwritten" just in case we crash shortly after the conversion. Second, and more importantly, it noticed that we fail to resynchronize the iext tree cursor after modifying the iext tree. If the tree shape changes, we could be in a world of hurt. Third, we should force a quotacheck if we reset an ondisk dquot. Fix all issues. Cc: stable@vger.kernel.org # v6.8 Fixes: a5b91555403e3a ("xfs: repair quotas") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 7fd7a78cb5cce2a6fabd50cf77d059a10cbcf9b8 Author: Darrick J. Wong Date: Mon Oct 12 08:20:51 2026 -0700 xfs: don't subtract excess usage twice when computing agf_btreeblks commit 4439b626fb5104204952aa2f169451688fb6be26 upstream. LOLLM noticed that the free space btree repair code calculates agf_btreeblks from the number of blocks we wrote to rebuild the free space btrees (minus the roots). That's correct. However, it observes that we subtract the "excess" reservation, which is not correct. Fix this accounting problem. Cc: stable@vger.kernel.org # v6.8 Fixes: 4bdfd7d15747b1 ("xfs: repair free space btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 047f69d36ef28aed9cd000fb7383e570ee020a3b Author: Darrick J. Wong Date: Mon Oct 12 23:08:51 2026 -0700 xfs: don't rescan ifree and icount when frozen commit 18028768415e3c05ab7edb22d740e2f4dc52836a upstream. LOLLM points out that it's pointless to rescan the AGs if we've already frozen the filesystem because there won't be any more perturbations. Fix this to mark the scan incomplete and exit. Cc: stable@vger.kernel.org # v5.2 Fixes: 75efa57d0bf5fc ("xfs: add online scrub for superblock counters") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 4a6217e7bdf3b1cdd28799d19c175cb3bad375ec Author: Darrick J. Wong Date: Mon Oct 12 23:05:28 2026 -0700 xfs: don't overrun incore inode when cleaning attr forks commit c28b4b48deac17749ed1ebe4289a4ba73541ddc6 upstream. LOLLM noticed that xrep_dinode_check_afork doesn't check for a di_forkoff value that is so large that the attr fork would begin after the end of the inode space. This causes afork_{ptr,size} to be nonsense. What we really ought to do here is zap the attr fork. Cc: stable@vger.kernel.org # v6.8 Fixes: e744cef2060559 ("xfs: zap broken inode forks") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 6e24a3e5157706ea12038d600217a5d3dec789b4 Author: Darrick J. Wong Date: Mon Oct 12 23:07:17 2026 -0700 xfs: don't clear COWEXTSIZE on directories on reflink filesystems commit 3978b1f3109dfd5c648442bb040f9abd58608226 upstream. LOLLM noticed that xrep_dinode_flags clears the COWEXTSIZE flag unnecessarily on directories on reflink filesystems. Directories just pass the hint along to new children, so it's valid to leave the flag set. Cc: stable@vger.kernel.org # v6.8 Fixes: 2d295fe65776d1 ("xfs: repair inode records") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 63be61660db6b672ca4dfc83c9f317c6de53f24f Author: Darrick J. Wong Date: Mon Oct 12 23:07:33 2026 -0700 xfs: clear set[ug]id mode bits when zapping attr fork commit eb20a959760c21e3547cd811d0d9b0b29df98959 upstream. LOLLM observes that zapping a file's attr fork could result in ACLs being removed from the file. Because we have no idea what we're deleting, we should clear the setuid and setgid bits in addition to the access mode bits so that nobody can access the file. Cc: stable@vger.kernel.org # v6.8 Fixes: e744cef2060559 ("xfs: zap broken inode forks") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit bc608aa7ca3e51a69c8af7b3f1f02bebb7359783 Author: Darrick J. Wong Date: Mon Oct 12 08:23:27 2026 -0700 xfs: clarify various parts of the bitmap API commit 00f32fdf54983371d39162efef7df693e2842ffb upstream. LOLLM pointed out some underspecified parts of the xbitmap{32,64} API. Specifically, the behavior of set/clear/test functions when the length parameter is zero is not well defined, nor is what happens when someone tries to disunion a bitmap with itself. None of these situations are expected, but we'll define zero-length set and clear to be nops, and the rest to be checked by assertions. Cc: stable@vger.kernel.org # v6.8 Fixes: 6ece924b952262 ("xfs: create separate structures and code for u32 bitmaps") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit cfd510192a19f9313245870d2bc9310a88a8a348 Author: Darrick J. Wong Date: Mon Oct 12 08:20:35 2026 -0700 xfs: check for termination during rmap btree walk commit 1fc241cdeab276dc6c3ec14840faa706ed7712ff upstream. LOLLM complains that we should check for a fatal signal *every* time we walk a record in the rmap btree as part of rebuilding the free space btrees. Fix that, and improve responsiveness to ^C of xfs_scrub. Cc: stable@vger.kernel.org # v6.8 Fixes: 4bdfd7d15747b1 ("xfs: repair free space btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit a8f28af800d76e45767788379a372ea11157c227 Author: Darrick J. Wong Date: Mon Oct 12 23:07:01 2026 -0700 xfs: check for fragments when full-extent sharing matches commit 95e213c1ddb40dfb0a8178ed35c9f29992a320e1 upstream. LOLLM noticed that xchk_refcountbt_process_rmap_fragments returns early if there are enough rmap records that overlap the space referenced by a refcountbt record to match the refcount in that refcountbt record. Unfortunately, it never checks the fragment list in this case, so it won't find the discrepancy between the rmap and refcount btrees. Cc: stable@vger.kernel.org # v4.16 Fixes: dbde19da963706 ("xfs: cross-reference the rmapbt data with the refcountbt") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit af559d87fdd921b90c86125f78d8b97d754432dd Author: Aldo Ariel Panzardo Date: Wed Sep 23 08:57:44 2026 -0300 xfs: bound inode fork length against the fork size during log recovery commit 9232301894a06e664d8de2da97175cf98419bd16 upstream. xlog_recover_inode_commit_pass2() copies an inode log item's data/attr fork region into the inode buffer using the on-log region length without bounding it against the fork capacity, e.g.: len = item->ri_buf[2].iov_len; memcpy(XFS_DFORK_DPTR(dip), src, len); The only guard is an ASSERT, which is a no-op on production kernels (CONFIG_XFS_DEBUG off), and xfs_dinode_verify() runs only after the copy. A crafted image with a dirty log can therefore drive a heap out-of-bounds write at mount time. The XFS_ILOG_DBROOT sibling already passes XFS_DFORK_DSIZE as a bound; the DDATA/DEXT and ADATA/AEXT memcpy paths did not. Bound each logged fork region against the destination fork size before copying it, and reject the log item with -EFSCORRUPTED when it does not fit. Because the recovered inode is only verified after the fork data has been copied in, the checks are done up front, before any memcpy into the on-disk inode. Fixes: 658fa68b6f34 ("xfs: refactor log recovery inode item dispatch for pass2 commit functions") Cc: stable@vger.kernel.org # v5.8 Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit aaeb3e51052c94959bbc286ccda0c6f2feb3cd69 Author: Aldo Ariel Panzardo Date: Wed Sep 23 08:57:54 2026 -0300 xfs: bound da-node entry count against the correct geometry commit 3df5e5aaa3bc0913236c48ab29b7df3a785aa29f upstream. xfs_da3_node_verify() bounds the node entry count against the larger of the directory and attribute geometries because, as a buffer verifier, it cannot tell whether the block belongs to the directory or the attribute tree. When the directory block size exceeds the fs block size (e.g. mkfs.xfs -n size=64k -b size=4k), an attribute node buffer is a single fs block that holds only m_attr_geo->node_ents entries, yet a crafted attr node may claim a count up to m_dir_geo->node_ents and still pass the verifier. xfs_da3_node_lookup_int() then indexes btree[] up to that count during its binary search -- an out-of-bounds read via getxattr/listxattr on a mounted crafted image. The buffer verifier is the wrong place to tighten this: it has no fork context, and the transaction-less read path used by getxattr does not run xfs_da3_node_set_type() either. xfs_da3_node_lookup_int(), on the other hand, always runs on that path and holds args->geo, the geometry of the fork actually being searched. Bound the entry count against args->geo->node_ents there, before walking the entries. Fixes: 7ab610f9e0f1 ("xfs: move node entry counts to xfs_da_geometry") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit b85c7410c7242dfeeda6e00ec4c57fb833292697 Author: Darrick J. Wong Date: Sun Oct 4 22:58:09 2026 -0700 xfs: always zero the whole shortform header when zeroing attr fork commit 52aa50cea408e27454d206cccecbe4f694a6c1e1 upstream. LOLLM noticed that xrep_xattr_fork_remove can decide to reset the attr fork contents to an empty shortform header, but then fails to zero the padding byte in the header. Fix that. Cc: stable@vger.kernel.org # v6.10 Fixes: e47dcf113ae348 ("xfs: repair extended attributes") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 67deef18ed5f7e2f969e2990cf3ab5fab2353a7f Author: Darrick J. Wong Date: Mon Oct 12 23:08:04 2026 -0700 xfs: always report scrub errors in tracepoints commit 1ccc8f553d885d49c1bfe141ea1f331511940b3a upstream. LOLLM complains that the error processing functions in scrub will sometimes zero out *error before recording a tracepoint. This makes diagnosing problems harder, so let's fix that. Cc: stable@vger.kernel.org # v4.15 Fixes: 4700d22980d459 ("xfs: create helpers to record and deal with scrub problems") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 7759a4711b5c443a9dcb9cfff161b550c519aaf5 Author: Darrick J. Wong Date: Mon Oct 12 08:22:09 2026 -0700 xfs: always report inode repair setup failures commit ce9098338a7e1a77246684242d10779fc4d4a539 upstream. LOLLM noticed that xchk_setup_inode silently discards errors being returned by xrep_setup_inode. Fix that, and fix the stub macro so that it actually "returns" a value. Cc: stable@vger.kernel.org # v6.8 Fixes: 2d295fe65776d1 ("xfs: repair inode records") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit f56d0d49f555db88cac92b20dcc988664c72c280 Author: Darrick J. Wong Date: Sun Oct 4 22:58:25 2026 -0700 xfs: always forget cached ACLs if the attr fork swap succeeds commit 41ee987f53785b9443388a756912b1a0fe3c9592 upstream. LOLLM complains that xrep_xattr_rebuild_tree omits the xfs_forget_acl call if the attr fork swap succeeds (and hence the acls might have changed) but reaping the old attr fork fails. Fix it so that we always purge the cached acls if the swap succeeds, even if subsequent steps do not. This avoids some cache coherency problems with access controls. Cc: stable@vger.kernel.org # v6.10 Fixes: e47dcf113ae348 ("xfs: repair extended attributes") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit c83a636a6e836011cb7d1b4166fc5131c90f322b Author: Darrick J. Wong Date: Mon Oct 12 08:21:07 2026 -0700 xfs: abort directory tree repair whenever dl->aborted is set commit 4582327e7068194d55941b49dd66be211b9e3f90 upstream. LOLLM observed that if the live update hooks for the directory tree repair code ever fail, they'll set dl->aborted, but then the main repair code path won't check it to exit early. This can cause incorrect repairs, so let's check for hook errors and abort the repair. Cc: stable@vger.kernel.org # v6.10 Fixes: 3f31406aef493b ("xfs: fix corruptions in the directory tree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 56b701b3c272f143bb5f6a346bfbb1fe28ee14b1 Author: Aldo Ariel Panzardo Date: Wed Sep 23 08:58:23 2026 -0300 xfs: reject remote xattr entries with an out-of-range value length commit 15ccd92a782a0253f4a17895f3d3f71e5c1d1973 upstream. xfs_attr3_leaf_verify_entry() validates a remote attribute entry's name but never bounds its on-disk value length (xfs_attr_leaf_name_remote. valuelen, a __be32). A crafted leaf with valuelen = 0x80000000 passes the verifier and the CRC. That length is later assigned into the signed int args->rmtvaluelen (xfs_attr3_leaf_getvalue), becoming negative, which slips past the signed -ERANGE check in xfs_attr_copy_value(); a getxattr() with a small buffer then memcpy()s a full remote block into the small kvalue buffer (xfs_attr_rmtval_copyout) -- a heap out-of-bounds write with attacker-controlled content, from an unprivileged getxattr(2) on a mounted crafted image. Reject remote entries whose value length exceeds XFS_XATTR_SIZE_MAX in the leaf verifier, so the malicious block is rejected at read time. Fixes: c84760659dcf ("xfs: check attribute leaf block structure") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 91d0cf6244280e67bdc2787a60a10f635ac064c0 Author: Aldo Ariel Panzardo Date: Wed Sep 23 08:58:22 2026 -0300 xfs: reject out-of-range attribute value lengths in xfs_attr_copy_value commit 0643549ffecaeb716c0b75590a9b76dfa5eb35b3 upstream. xfs_attr_copy_value() takes the value length as a signed int and, for a remote xattr, is handed args->rmtvaluelen. That field is filled from the on-disk __be32 xfs_attr_leaf_name_remote.valuelen in xfs_attr3_leaf_getvalue(), so a crafted length such as 0x80000000 is stored into the signed rmtvaluelen as a negative number. The "buffer too small" guard in xfs_attr_copy_value() is a signed comparison: if (args->valuelen < valuelen) return -ERANGE; A negative valuelen therefore compares as smaller than the caller's buffer size, skips the -ERANGE path, and is then used as a copy length, leading to an out-of-bounds copy of a full remote block into a small getxattr(2) buffer on a mounted crafted image. Reject a value length that is negative or larger than the maximum xattr size before it is used, so a bogus on-disk length can no longer slip through the value copier. Fixes: 9df243a1a9e6 ("xfs: consolidate attribute value copying") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 57666e97887b3565b6d375298c9ab61cfc1c26e7 Author: Darrick J. Wong Date: Mon Oct 12 08:22:41 2026 -0700 xfs: reject absurdly large xattr value lengths in xchk_xattr_actor commit fd012955641881169a9f01a00f656f6ca73842ec upstream. LOLLM suggests that we shouldn't try to allocate absurdly large buffers for xattr value checks because that will push reclaim very hard, never succeed, and is pointless because nobody can create xattrs that large. Since the xattr repair code ignores values larger than XATTR_SIZE_MAX, we can flag the corruption and return early. Cc: stable@vger.kernel.org # v5.3 Fixes: 6d6ccedd76823c ("xfs: only allocate memory for scrubbing attributes when we need it") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 9b8a85025df329bc3d3e063d153aea3baf72d266 Author: Aleksandr Nogikh Date: Mon Nov 2 17:39:00 2026 -0500 media: usbtv: fix null-pointer dereference on disconnect [ Upstream commit cb705f75d03e946a4514488beb9e3bac9bcdb2e6 ] A null-pointer dereference can occur in usb_make_path() when called from usbtv_querycap() (and other ioctl handlers) during device disconnection. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057] RIP: 0010:usb_make_path include/linux/usb.h:985 [inline] RIP: 0010:usbtv_querycap+0x9c/0x100 drivers/media/usb/usbtv/usbtv-video.c:612 ... Call Trace: v4l_querycap+0x236/0x470 drivers/media/v4l2-core/v4l2-ioctl.c:1106 __video_do_ioctl+0x8af/0xc70 drivers/media/v4l2-core/v4l2-ioctl.c:3133 video_usercopy+0x860/0x1430 drivers/media/v4l2-core/v4l2-ioctl.c:3475 v4l2_ioctl+0x18d/0x1e0 drivers/media/v4l2-core/v4l2-dev.c:366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 This happens due to a race condition between the USB device disconnect routine (usbtv_disconnect()) and V4L2 ioctls. When the device is disconnected, usbtv_disconnect() sets usbtv->udev = NULL without holding the usbtv->v4l2_lock mutex. Concurrently, an ioctl handler like usbtv_querycap() can be executing under the v4l2_lock and attempt to use usbtv->udev, leading to a crash. To fix this, move the usbtv->udev = NULL assignment into usbtv_video_free() and protect it with mutex_lock(&usbtv->v4l2_lock). This ensures that no non-queue ioctl handler can run concurrently with the pointer being nullified. If an ioctl is already running, the mutex will block the disconnect path until the ioctl finishes. If an ioctl is blocked waiting for the lock, it will acquire it after the disconnect routine releases it, but will then check video_is_registered() (which was cleared by vb2_video_unregister_device()) and safely return -ENODEV. Acquiring v4l2_lock after vb2_video_unregister_device() avoids reintroducing a historical deadlock issue, and usbtv_audio_free() remains safe as it is called before usbtv_video_free(). Fixes: 65e6a2773d65 ("media: usbtv: Remove useless locks in usbtv_video_free()") Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.6-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+37a57a84893052ab6071@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=37a57a84893052ab6071 Link: https://syzkaller.appspot.com/ai_job?id=5abbe65a-5853-4bc2-9135-5c75f88d51ed Signed-off-by: Aleksandr Nogikh Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3f887ad633d0dd8177ea0c67ec1fbe3ae3f080bc Author: Johan Hovold Date: Mon Nov 2 17:38:59 2026 -0500 media: usbtv: drop redundant device reference [ Upstream commit dbc6798b80481a20f9aff671bc4d529eae63c9e8 ] Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. Drop the redundant device reference to reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of memory leaks when drivers fail to release it. Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Stable-dep-of: cb705f75d03e ("media: usbtv: fix null-pointer dereference on disconnect") Signed-off-by: Sasha Levin commit 917018fa35757578bb3875bad5fb415c01361ac7 Author: Al Viro Date: Wed Nov 4 15:05:38 2026 +0800 ufs: fix ufs_read_cylinder() failure handling commit 0bfd3e1078c537cd66a8addb1c01835de4234a4c upstream. 1) ufs_load_cylinder() should return NULL on ufs_read_cylinder() failures. ufs_error() is not enough. As it is, IO failure on attempt to read a part of cylinder group metadata is likely to end up with an oops. 2) we drop the wrong buffer heads when undoing sb_bread() on IO failure halfway through the read - we need to brelse() what we've got from sb_bread(), TYVM... Signed-off-by: Al Viro Signed-off-by: Joseph Qi Signed-off-by: Sasha Levin commit 6c9730c73f8496530f7bf6712a9e5523a8428725 Author: Jean Delvare Date: Tue Nov 3 17:04:39 2026 +0100 EDAC/mc: Really fix error path ordering in edac_mc_alloc() The backport of 51520e03e70d ("EDAC/mc: Fix error path ordering in edac_mc_alloc()") to stable kernel branches is incomplete due to a different memory allocation scheme. In v6.19 and earlier, the device initialization must be moved further up so that all jumps to the error label are covered. Signed-off-by: Jean Delvare Cc: stable@kernel.org # v6.19- Signed-off-by: Sasha Levin commit 51d76b7d4654247b1766addadfb72ec862498e4c Author: Joseph Qi Date: Tue Nov 3 19:08:03 2026 +0800 ksmbd: fix breaking_cnt leak on early return in oplock_break() For leases, oplock_break() increments breaking_cnt before calling oplock_break_pending(), and returns early when the pending check reports nothing to break: the level is already at or below the requested level and, for a lease, the state is not HANDLE|READ caching. Neither early return decrements the counter, and wait_lease_breaking(), the only place that force-clears it, sits below those returns, so breaking_cnt stays elevated for the life of the open. A stuck breaking_cnt makes same_client_has_lease() skip lease upgrades forever, and every subsequent same-client CREATE on that lease is answered with SMB2_LEASE_FLAG_BREAK_IN_PROGRESS, so the client never resumes caching. The ordering dates back to the original SMB3 server code, but the early return became routinely reachable for leases already broken to NONE when smb_break_all_levII_oplock() stopped filtering out non-level-II leases in 17699905a381, "ksmbd: fix lease break and ack state handling". Move the increment below the pending check so the early returns cannot strand the counter. This is the minimal equivalent of the reorder that mainline made in b0148dc5625d, "ksmbd: serialize oplock close with pending break ownership". Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Joseph Qi Signed-off-by: Sasha Levin commit 5ad61a34963f32fc1637d26e88cf6e02a3b99d08 Author: Yongjun Gwon Date: Mon Nov 2 17:39:47 2026 -0500 ksmbd: serialize directory emptiness checks with readdir [ Upstream commit 7220980b2423d06a0604516129bfa4cec8a697ae ] SMB2 QUERY_DIRECTORY holds fp->readdir_lock while it calls iterate_dir() on fp->filp. An SMB2 SET_INFO request with FILE_DISPOSITION_INFORMATION can resolve the same FileId and call ksmbd_vfs_empty_dir() on the same filp without that lock. iterate_dir()'s inode read lock permits concurrent readers and does not serialize per-file iterator state. ext4 stores its dx readdir cursor and fname RB tree in file->private_data. Concurrent reset or refill can therefore free a fname node while the other worker still traverses it or retains its RB-tree link, resulting in use-after-free accesses. An authenticated SMB client with list and delete rights on a directory in a writable KSMBD share backed by ext4 can trigger this when the directory takes the dx readdir path. The client overlaps an SMB2 QUERY_DIRECTORY request with an SMB2 SET_INFO request carrying FILE_DISPOSITION_INFORMATION on one live FileId. In one x86_64 SMP KASAN multi-shot guest using ksmbd-for-next at 171df27077fb, the unmodified kernel reported a cross-worker use-after-free before a panic. The first report's access and free stacks show the two request paths directly (trimmed): BUG: KASAN: slab-use-after-free in ext4_htree_store_dirent+0x488/0x550 Read of size 8 by task kworker/2:0/29 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ext4_htree_store_dirent+0x488/0x550 htree_dirblock_to_tree+0x535/0x990 ext4_htree_fill_tree+0x319/0xba0 ext4_readdir+0x175a/0x2f40 iterate_dir+0x1b6/0x630 smb2_query_dir+0x1003/0x1cc0 Freed by task 279: free_rb_tree_fname+0x67/0xc0 ext4_readdir+0x13a9/0x2f40 iterate_dir+0x1b6/0x630 ksmbd_vfs_empty_dir+0xa2/0x100 smb2_set_info+0x2ffa/0x45d0 Take fp->readdir_lock across the entire emptiness check. This places both iterators over that handle's filp in the same lock domain while preserving the disposition status handling. The exact code change completed a warning-free x86_64 KASAN bzImage build. Tracing three request pairs showed that the two iterate_dir() calls no longer overlapped and the expected statuses were preserved. A further 1,600 reproducer iterations completed with expected statuses and no KASAN report, Oops, or panic. The reproducer and complete guest configuration are available privately to maintainers on request. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Yongjun Gwon Signed-off-by: Namjae Jeon [ sashal: adapted to the existing directory check without the ksmbd_stream_fd() guard ] Signed-off-by: Sasha Levin commit 2342577f08c75727d562d200f260c9de2a6a422a Author: Takashi Iwai Date: Wed Jan 21 09:20:20 2026 +0100 ALSA: usb-audio: Use the right limit for PCM OOB check [ Upstream commit 70b4db7d258118a7464f039112a74ddb49a95b06 ] The recent fix commit for addressing the OOB access of PCM URB data buffer caused a regression on Behringer UMC2020HD device, resulting in choppy sound. The fix used ep->max_urb_frames for the upper limit check, and this is no right value to be referred. Use the actual buffer size (ctx->buffer_size) as the upper limit instead, which also avoids the regression on the device above. Fixes: ef5749ef8b30 ("ALSA: usb-audio: Prevent excessive number of frames") Link: https://bugzilla.kernel.org/show_bug.cgi?id=220997 Link: https://patch.msgid.link/20260121082025.718748-1-tiwai@suse.de Signed-off-by: Takashi Iwai [ sashal: Backport differs from upstream only in indentation, since the for loop sits one block shallower in this tree; the changed lines are otherwise identical. ] Signed-off-by: Sasha Levin commit 0b78d524b9a547786a3e7db85903e563790e4437 Author: Darrick J. Wong Date: Thu Sep 24 21:11:17 2026 -0700 xfs: fix xchk_stats_estimate_bufsize to allow for the trailing null commit 6b8d60784b61a17bd591cb4c6e8aa9ed29c24f5c upstream. LOLLM complains that xchk_stats_estimate_bufsize underestimates the buffer size by 1 byte because scnprintf wants to store a null byte after the newline in each line. Each call to scnprintf overwrites the null left by the previous call, but we still need the null byte for the last line in the file. Cc: stable@vger.kernel.org # v6.6 Fixes: d7a74cad8f4513 ("xfs: track usage statistics of online fsck") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 9849ad859485c316e1b7da1dec2814ff3a7017c5 Author: Darrick J. Wong Date: Thu Sep 24 21:10:45 2026 -0700 xfs: adjust checks for cross-AG reaping issues commit 4c6668ecebc61bb0a53d4c6e95509bc960cf6bbc upstream. While analyzing the reaping code for the previous patch, I studied the xfs_fsblock_t code to reconstruct how this code works. AGs have a superblock at the start of each AG which means that regions in the xfsb_bitmap (aka xfs_fsblock_t bitmap) cannot cross an AG boundary, so we don't need a loop here like we do for xfs_rtblock_t bitmaps. However, the checks here are not quite right -- there can be quite a lot of reserved space in COW forks, which means that the bitmap extent actually can exceed XFS_MAX_BMBT_EXTLEN. We also don't have an explicit debugging check that we never cross AGs, so add that here. Cc: stable@vger.kernel.org # v6.8 Fixes: 66da11280f7ecd ("xfs: reintroduce reaping of file metadata blocks to xrep_reap_extents") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 6c77b8c00e1072f0f39420be7fbede1cc5f8cffc Author: Darrick J. Wong Date: Thu Sep 24 21:13:06 2026 -0700 xfs: jump out of xchk_bmap_check_rmap if fatal signals commit 49d300a51442bd64b627645b7b0b1cd66e492905 upstream. LOLLM observes that we never check for fatal signals inside the loop that checks file fork mappings against the rmapbt. This can lead to lengthy delays in responding to a ^C, so add some bailout checks. Cc: stable@vger.kernel.org # v4.17 Fixes: 5e777b62b0bcb6 ("xfs: bmap scrubber should do rmap xref with bmap for sparse files") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit bbb234712cc1baada3d04f4900e5ce4c8e70fb49 Author: Darrick J. Wong Date: Thu Sep 24 21:13:22 2026 -0700 xfs: mark overfull dabtree node blocks as corrupt commit f61c91a2e5994fa81141d6c06dadae1fed206018 upstream. LOLLM observes that we need to range-check the dabtree node record count before using it to index an array. Fix that. Cc: stable@vger.kernel.org # v4.15 Fixes: 7c4a07a424c18d ("xfs: scrub directory/attribute btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 273d2ab0bcd687df4726ad11c86cffa703f452a9 Author: Darrick J. Wong Date: Thu Sep 24 21:13:38 2026 -0700 xfs: check fork type against dabtree block magic number commit 43030b72a11a532e7e3c21ac84a8625425b4201b upstream. LOLLM complains that we fail to flag dabtree blocks that should never be associated with the file fork -- data forks can't point to xattr leaves, and attr forks can't point to dirent blocks. Add the missing checks. Cc: stable@vger.kernel.org # v4.15 Fixes: 7c4a07a424c18d ("xfs: scrub directory/attribute btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 9ebf7830d193eb1730a7a1323930129f89c448c7 Author: Darrick J. Wong Date: Sun Sep 27 23:16:36 2026 -0700 xfs: abort dirtree repair if the live update hook dies commit 07732dea4f5d0410e1566b81a58a1154bf9dcb29 upstream. LOLLM notices that if the live update hook for the directory tree repair code hits an error, it will set dl->aborted and stops working. If the repair code ever sees that condition, it ought to bail out immediately instead of continuing with obsolete data. Cc: stable@vger.kernel.org # v6.10 Fixes: 3f31406aef493b ("xfs: fix corruptions in the directory tree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit ddf31f8c45e1d8a0033612cf55d1edebad4af647 Author: Darrick J. Wong Date: Sun Sep 27 23:17:07 2026 -0700 xfs: fix revalidation of xchk_dquot_iter cached mappings commit 6c64d650460b455980a6023d43bc6c8859c1cfd2 upstream. LOLLM noticed that the purpose of xchk_dquot_iter_revalidate_bmap is to revalidate the quota file mapping after we've (presumably) done something to the quota file contents. However, the "yes this is valid" code isn't quite strong enough -- the mapping must cover at least the block at fileoff, not just end after fileoff. Fix that. Cc: stable@vger.kernel.org # v6.8 Fixes: 21d7500929c8a0 ("xfs: improve dquot iteration for scrub") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 039fff875f46e325d40194ed173e1ec869be7a96 Author: Darrick J. Wong Date: Sun Sep 27 23:16:51 2026 -0700 xfs: bail out of directory tree repairs on error commit d83ca4e7cc65dce6a02fd3427cefd174517657a3 upstream. LOLLM complains that we ignore errors returned by xrep_dirpath_retain_parent and can set the dotdot entry to random stack garbage. Fix that by passing errors all the way out. Cc: stable@vger.kernel.org # v6.10 Fixes: 3f31406aef493b ("xfs: fix corruptions in the directory tree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit cc44255c3a5eae494964ae171e484f3acf13fef4 Author: Darrick J. Wong Date: Sun Sep 27 23:17:54 2026 -0700 xfs: assign an owner to scrub_stats_fops commit fe67a493c7a76cf75556152af24285a114f69d34 upstream. LOLLM complains that file_operations structs for debugfs files are supposed to have an owner set so that the module can't get unloaded if someone's sitting on a debugfs file long after unmount/rmmod. Fix that. Cc: stable@vger.kernel.org # v6.6 Fixes: d7a74cad8f4513 ("xfs: track usage statistics of online fsck") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 31f20ee2bbd518c4cff8e8079ebbede51a6c7386 Author: Darrick J. Wong Date: Sun Sep 27 23:17:38 2026 -0700 xfs: allow softlimit with no hardlimit in quota scrub commit 342c2e00b3a99099a7088f7b8c8f075670c603a9 upstream. LOLLM observes that the sysadmin can set a user's soft limit to a nonzero value and the hard limit to zero, so those aren't corruptions. Cc: stable@vger.kernel.org # v4.15 Fixes: c2fc338c87a31f ("xfs: scrub quota information") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 32a4e4be6af9d68283e333844997b2269312bf49 Author: Darrick J. Wong Date: Sun Sep 27 23:18:10 2026 -0700 xfs: fix lost errno returned from xfarray_foliosort commit 8c4f172c246717b1420f138a159ed15c315a58bd upstream. LOLLM noticed that we stop the sort early but don't actually pass along the error code, which could enable repair code to continue running with an unsorted array. Fix that. Cc: stable@vger.kernel.org # v6.9 Fixes: ee13fc67205b98 ("xfs: convert xfarray_pagesort to deal with large folios") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 1f88a2c46bac04827eb56d0a9cc29527a04eebe6 Author: Darrick J. Wong Date: Sun Sep 27 23:17:23 2026 -0700 xfs: don't repair fs summary counters with garbage commit 22a8a7501c0146dba4ce99b8256975ffe945125d upstream. LOLLM noticed that if we scan the filesystem and come up with totally garbage numbers for the summary counters, we don't actually mark the scan incomplete. Because we don't do this, repair can install the garbage values into the filesystem, making things worse. Don't do that. Cc: stable@vger.kernel.org # v6.9 Fixes: 4ed080cd7cb077 ("xfs: repair summary counters") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 8a1f86e2acaa853be76db884dcb82f183cca7746 Author: Darrick J. Wong Date: Sun Sep 27 23:18:25 2026 -0700 xfs: fix skipped inode mask handling in iscan commit 63341d4af16fe850716b454fcd18990590d07d97 upstream. xfs_highbit64() returns -1 if none of the bits in its argument are set. In this particular callsite, a totally zeroed mask means that no inodes were skipped, so executing the if-body is incorrect. Fix that. Cc: stable@vger.kernel.org # v6.9 Fixes: 82334a79c6eb1c ("xfs: iscan batching should handle unallocated inodes too") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 66436c033f396e3f1df4027d6368486fcd11ab65 Author: Darrick J. Wong Date: Sun Sep 27 23:18:41 2026 -0700 xfs: don't proceed with xattr repair if the live update fails commit 833f98b3be45bc7c6ce4c87bdc4892f546ab72ee upstream. LOLLM observes that we ought to make one last check for failed live updates before replacing the xattr structure. Let's be cautious here. Cc: stable@vger.kernel.org # v6.10 Fixes: e5d7ce0364d8ee ("xfs: replay unlocked parent pointer updates that accrue during xattr repair") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 9d31894780974d239832f22377ae4a66655626f7 Author: Darrick J. Wong Date: Sun Sep 27 23:18:57 2026 -0700 xfs: don't fix the directory tree if live update fails commit c8226f3d1a7eafe472addc232689e9c9a0c36a1c upstream. LOLLM complains that we don't double-check dl->aborted one last time to before committing repairs to the filesystem. This is important because the live update handler could have set ->aborted if it encountered a runtime error. Cc: stable@vger.kernel.org # v6.10 Fixes: 3f31406aef493b ("xfs: fix corruptions in the directory tree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 2df2ec51b6745db9f7acab3a79aa87977e2ec7a9 Author: Darrick J. Wong Date: Sun Oct 4 22:56:20 2026 -0700 xfs: don't pass iget failures up when marking ondisk inodes commit 7f5e8bf335e5e257fb82cf5b3521980ded60e863 upstream. LOLLM observes a couple of problems with this callsite -- an ENOMEM return is completely ignored and a subsequent run through the loop body obliterates the return value completely. Also, an error value indicating that the list is corrupt can get passed up (thus terminating the repair) even though we can handle corrupt lists. Fix the callsite not to have these problems. Cc: stable@vger.kernel.org # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit e8ce55fa962553faaade7121aed714f787f5d218 Author: Darrick J. Wong Date: Sun Oct 4 22:56:35 2026 -0700 xfs: always reset incore attr fork buffer when resetting fork commit 71cb13685e72a3c5d118732559c727a0c9090b7f upstream. LOLLM noticed that the local format attr fork verifier depends on if_bytes being set correctly. However, the fork reset function doesn't reset that correctly, which can cause post-repair verifier failures. Fix that. Cc: stable@vger.kernel.org # v6.10 Fixes: e5d7ce0364d8ee ("xfs: replay unlocked parent pointer updates that accrue during xattr repair") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 7e4f5e9ab4b621da5ea3fbe54702e1e7777532e2 Author: Darrick J. Wong Date: Tue Sep 22 23:02:02 2026 -0700 xfs: fix inode btree repair when a cluster is larger than a chunk commit 65b89ac3e8c2f041384f715a71b9d113edfa32e5 upstream. LOLLM noticed that on filesystems where an inode cluster buffer is larger than an inode chunk, we can run through the loop body in xrep_ibt_process_cluster more than once, and the number of inodes that we pass to xrep_ibt_cluster_record is incorrectly large. In this case we can run right off the end of the buffer. Fix this by moving the nr_inodes computation inside the loop. Note that this is only likely to happen on filesystems with (say) 512b inodes and 64k fsblocks. Cc: stable@vger.kernel.org # v6.8 Fixes: dbfbf3bdf639a2 ("xfs: repair inode btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 05652a8e8df6984be77152c2f0ca6d731a5ca011 Author: Darrick J. Wong Date: Tue Sep 22 23:02:49 2026 -0700 xfs: actually report corrupt xattrs as XFAIL during cross-referencing commit b339cc253019518c61b8b150fb7ea727fdae59f4 upstream. Some LLM reports that xchk_dir_parent_pointer really ought to report xattr corruption errors as XFAIL (cross-referencing failed) when a directory scrub tries to find the parent pointer for a dirent name. Let's do that. Cc: stable@vger.kernel.org # v6.10 Fixes: 61b3f0df5c2358 ("xfs: check dirents have parent pointers") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 6f85707eee2f82b97f3a03cc758359891cdfad1e Author: Darrick J. Wong Date: Tue Sep 22 23:02:34 2026 -0700 xfs: fix buffer overflow in corrupt inline attr structure commit 017dd7a84ff4cd2275eb62f4ee6d63c705bac107 upstream. LOLLM noticed a buffer overrun if the xattr scrubber encounters a file with a shortform attr fork with sf->count > 0 but if_bytes == sizeof(struct xfs_attr_sf_hdr). Basically, we have enough data to have a header with a nonzero count, but no space for any of those shortform entries. In this case, the xfs_attr_sf_nextentry() call will run off the end of if_data and blow up. Cc: stable@vger.kernel.org # v6.4 Fixes: ae0506eba78fd1 ("xfs: check used space of shortform xattr structures") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 1c31473dd46427e6a07c9b7f40333b0d652fdb83 Author: Darrick J. Wong Date: Tue Sep 22 23:03:20 2026 -0700 xfs: fix unnecessary dapos truncation in xchk_dir_walk commit f60a2ef8d8a7ac6dedf4d0c3325cc3fc2fe0d948 upstream. LOLLM points out that the all the implementations of xchk_dirent_fn can handle a signed @dapos parameter, so the truncation here breaks the information captured in scrub tracepoints if the directory is very large. I don't think it ever made sense to do the truncation for the VFS readdir code for programs that can handle 64-bit offsets, but commit 15440319767942 has been around for 17 years without complaints so I'll leave that alone. Stumbled-over: 15440319767942 ("[XFS] truncate readdir offsets to signed 32 bit values") Cc: stable@vger.kernel.org # v6.4 Fixes: 4c233b5c4f29df ("xfs: streamline the directory iteration code for scrub") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 0d7595f3e510a5cc9dcc9b46750f9c51b3632ccc Author: Darrick J. Wong Date: Tue Sep 22 22:57:53 2026 -0700 xfs: online quotacheck must dirty dquot if enforcement adjustments needed commit 244425cf63d7e3a0ff5736b41f0e0afe807f7031 upstream. LOLLM noticed that we have no way to force xchk_commit_dquot to call xfs_qm_adjust_dqenforcement if nothing else is wrong with the dquot. Therefore, add a new predicate to force the dirty flag if the dquot has zero limits and there are default limits; or if the grace period timer needs adjusting. Cc: stable@vger.kernel.org # v6.9 Fixes: 96ed2ae4a9b06b ("xfs: repair dquots based on live quotacheck results") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 426ba9b807dfda7a0f41754ce8689b2fda4ad36d Author: Darrick J. Wong Date: Tue Sep 22 22:58:08 2026 -0700 xfs: fix buffer overruns in xfs_ioc_attr_list commit 0b9081a774ee7b9dff1e9ac3765b73c1d6bba5b2 upstream. When we converted the al_offset array in struct xfs_attrlist into a VLA, the size of the object shrank by 4 bytes. Unfortunately, the buffer size validation in the attrlist ioctl wasn't updated to notice this, so the al_offset[0] assignment blindly writes off the end of the buffer. LOLLM noticed the omitted check and complained. Cc: stable@vger.kernel.org # v6.5 Fixes: 371baf5c9750a2 ("xfs: convert flex-array declarations in struct xfs_attrlist*") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 25f3396f3d6fe88bfc41a3ed1c15d212f667c4d2 Author: Darrick J. Wong Date: Tue Sep 22 22:57:37 2026 -0700 xfs: fix missing xfs_qm_adjust_dqlimits call in quotacheck repair commit da483b8a9c2c3e7b23655699680feb57a194000c upstream. LOLLM noticed that everywhere else in the kernel, a call to xfs_qm_adjust_dqlimits precedes every call to xfs_qm_adjust_dqtimers. In particular, mount-time quotacheck does this, but online quotacheck does not. Looking at xfs_qm_adjust_dqlimits, that function is in charge of conveying default limits to a dquot if that dquot's limits have been zeroed. That's quite possible in a repair, so we actually need to do that. However, there's a pre-existing pattern in the kernel -- for non-root dquots, first we call xfs_qm_adjust_dqlimits to set the dquot's limits to the defaults if they are zero, and then xfs_qm_adjust_dqtimers to start grace periods if the dquot's usage is above the softlimit. The grace period decision cannot be made correctly if we forget to import the default limits. Therefore, let's combine both into a single xfs_qm_adjust_dqenforcement helper that takes care of both pieces, which fixes quotacheck and makes it hard to repeat this mistake. Cc: stable@vger.kernel.org # v6.9 Fixes: 96ed2ae4a9b06b ("xfs: repair dquots based on live quotacheck results") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 30413b169a845efa82bc6b2d911259e9a59414a0 Author: Darrick J. Wong Date: Tue Sep 22 22:58:55 2026 -0700 xfs: fix xfs_rename_space_res for non-pptr filesystems commit a800b926346c3aa2482421f5c0272280ee7d32e8 upstream. We don't need to reserve space for a parent pointer update for an existing target if parent pointers are disabled. Fix this regression (which LOLLM noticed) so that rename reservations go back to what they were before parent pointers. Cc: stable@vger.kernel.org # v6.10 Fixes: 5a8338c88284df ("xfs: Add parent pointers to rename") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 8c87bbd3c7f63f9bda784b3f1f35612c647d0b9f Author: Darrick J. Wong Date: Tue Sep 22 22:59:11 2026 -0700 xfs: fix ondisk symlink target validation in xrep_dinode_check_dfork commit aafe21c23ad8263251085291019d8860ddc51da9 upstream. LOLLM noticed that online repair of a broken symlink file could fail unnecessarily if a local-format symlink target isn't null terminated. The ondisk target isn't required to be null terminated, but repair enforces that anyway because it uses the validator for the incore symlink target. (The incore buffer is always null-terminated). Fix this by reverting the changes to xfs_symlink_shortform_verify and adding an ondisk-specific helper in inode_repair.c. Cc: stable@vger.kernel.org # v6.8 Fixes: e744cef2060559 ("xfs: zap broken inode forks") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Reviewed-by: Dave Chinner Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 25d8208e56e79ea344c251114aedbafc14c71cbf Author: Darrick J. Wong Date: Tue Sep 22 23:01:00 2026 -0700 xfs: compute the correct fdblocks/frextents for repair when they're negative commit f98d007017acf0eaec2e116ff9c0ece735f61bb3 upstream. LOLLM observed that if either fdblocks or frextents are negative, we'll set the CORRUPT flag and exit immediately. This doesn't work for a repair because we still have to walk the filesystem metadata to compute the correct summary counters so that we can install the new values. Currently we just write zeroes into the summary counters, which isn't right. Cc: stable@vger.kernel.org # v6.9 Fixes: 4ed080cd7cb077 ("xfs: repair summary counters") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 4a9c2b4f4381baf44fb72ee4377be00a62c08a27 Author: Darrick J. Wong Date: Tue Sep 22 23:01:31 2026 -0700 xfs: clear the symlink zapped flag if inline symlink is ok commit f8d0d90f2e24b1f4a14796ae63cebfd820cadfcd upstream. LOLLM noticed that we fail to clear the SYMLINK_ZAPPED flag if an inline symlink checks out ok, even after a repair. Fix that. Cc: stable@vger.kernel.org # v6.8 Fixes: d9041681dd2f53 ("xfs: set inode sick state flags when we zap either ondisk fork") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit ce8fa086d095141675801bb9dea81d24fb43c5ef Author: Amir Goldstein Date: Sun Oct 18 11:52:52 2026 +0200 ovl: skip copy up of empty security.capability commit 50912a1715b8a7c614b654011a0db750e372b43e upstream. ovl_copy_xattr() gives up if it can't read an attribute that listxattr() has named. An empty security.capability, which anybody has been able to store on any file for a long time, is such a case: it is listed, and getxattr() has nothing to return for it. A file in a lower layer that carries one can't be copied up: it can't be written to, renamed or have its mode changed. There is nothing to copy if there are no data. Go on with the next one. Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities") Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik [amir: treat -EINVAL as no capability too, and do the same in ovl_copy_up_meta_inode_data()] Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit e876482d955476d0c066afda8273bfd38e0f65be Author: Chris Mason Date: Fri Oct 16 21:17:23 2026 +0000 ovl: set the revalidate flags after d_instantiate() commit 75e89c0055c1d7f7eeb462995f11253ca5864f79 upstream. stat() of a file on an overlayfs mount triggers a kernel warning and fails with ECHILD if another task is creating that file at the same time. This happens on an overlay with a FUSE upper layer, which is the layer where overlayfs creates new files. Write access to a directory on such an overlay is all a user needs to run the two tasks. The revalidate flags are DCACHE_OP_REVALIDATE and DCACHE_OP_WEAK_REVALIDATE. They tell path walk to call ->d_revalidate() or ->d_weak_revalidate() on a dentry, so that the filesystem can check that the cached dentry is still valid. An overlay dentry only has one of these flags if a dentry in one of its layers has it. FUSE dentries have the first one. When a flag is set on an overlay dentry, path walk calls ovl_dentry_revalidate_common(). That function only expects a dentry without an inode in RCU walk, while the dentry is being destroyed. For such a dentry outside of RCU walk, it hits a WARN_ON() and returns -ECHILD. So a negative overlay dentry must never have the flags set. ovl_instantiate() breaks this rule. When a task creates a file, the overlay dentry for the new name is hashed but still negative. ovl_instantiate() then works in this order: - It copies the flags from the new upper dentry to the overlay dentry. - It calls ovl_get_inode(), which can sleep in a getxattr request to the FUSE server. - Only then does it call d_instantiate(). A second task that looks up the name between the first step and the last finds a negative dentry with the flags set and revalidates it. Reproduced with a FUSE server that delays its getxattr reply: stat() of a name that was being created hit the WARN_ON() and failed with ECHILD. Fix this by setting the flags after d_instantiate(). Fixes: bccece1ead36 ("ovl: allow remote upper") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 07b000b5b458723ca85d67dbbe5f6359c0202cfc Author: Chris Mason Date: Fri Oct 16 21:17:04 2026 +0000 ovl: read the nlink xattr of every indexed non-dir commit eb644ed5c6d9afdb1554c41cef1f39d150fbc554 upstream. With nfs_export=on, data written through a file handle to a lower file, i.e. a file that exists only in a lower layer of the overlay, can be lost on the next mount. A lookup of the file by name then returns -EIO. Also, a file with one name reports st_nlink 2 once it has been copied to the upper layer. After such a file is removed, its file handle can still open it until the next mount. Before a lower file is changed for the first time, overlayfs copies it to the writable upper layer. This is called copy up. The index directory is $workdir/index, where $workdir is the directory given by the workdir= option. Each entry is named after the file handle of a lower inode, so that overlayfs can get from the handle to the copied up inode. With nfs_export=on, copy up indexes every non-directory: it copies the file to an entry in the index directory and then hard links that entry into the upper directory. The index entry is an extra link to the upper inode, so overlayfs stores the link count that users should see in the overlay.nlink xattr. A file can also be opened by handle, either by an NFS client or by a process with CAP_DAC_READ_SEARCH calling open_by_handle_at(). If the file is not in the dcache, its overlay dentry is disconnected, i.e. it has no parent yet. Copy up then creates the index entry but no hard link in the upper directory. The index entry has i_nlink 1 and holds the only copy of the data written to the file. ovl_get_nlink() reads the stored count. Its caller passes a default, which the function returns if there is no stored count. If the lower inode has i_nlink 1, the function returns the default without reading the xattr. That was correct as long as only lower files with multiple links were indexed. On the next mount, ovl_verify_index() looks for orphans, i.e. index entries of files whose last name was removed. For an index entry with i_nlink 1, it passes a default of 0 to ovl_get_nlink() and treats a result of 0 as an orphan. Here the lower inode also has i_nlink 1, so the result is the default. ovl_indexdir_cleanup() then replaces the entry with a whiteout, which in the index marks a file as deleted. The written data is lost. A lookup by name then returns -EIO, because a whiteout as the index entry of a lower file that still exists is a bad index. ovl_get_inode() gets the wrong count the same way. Its default is the i_nlink of the upper inode, which includes the index entry, so a copied up file with one name reports st_nlink 2. When that name is removed, the count drops to 1 rather than 0. ovl_nlink_end() replaces the index entry with a whiteout only at a count of 0, so the entry stays, and the handle of the removed file still opens it. Reproduced by writing through open_by_handle_at() to an uncached lower file with one link. After a remount the data was lost, and the name returned EIO. Fix this by adding an argument to ovl_get_nlink() that says whether the caller found an index entry, and by skipping the xattr only if the caller found none. Known gaps: - An index entry that a kernel without this patch left behind for a removed file now stays, and the handle of that file keeps working. The entry has i_nlink 1 and a stored count of 1, just like the entry of a file that was only written by handle. Without this patch, the next mount treated it as an orphan. Fixes: fbd2d2074bde ("ovl: index all non-dir on copy up for NFS export") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 5763b78017dd4a75b29a7249113adb325200c79f Author: Amir Goldstein Date: Fri Oct 16 09:33:58 2026 +0200 ovl: fortify ovl_copy_xattr() against underlying layer modifications commit e6b9117076fb4c0ff4a670efa9c876d9a50d79ab upstream. Adapt ovl_getxattr_value() to be used from ovl_copy_xattr(), by allowing to pass it a pre-allocated buffer, which can be resized and by handling the ENODATA/EOPNOTSUPP return codes in the caller. This replaces the retry loop in ovl_copy_xattr() with a single retry after resizing the buffer. If the value changed again by then, the underlying layer was modified, so return -EIO instead of retrying. As a side effect, ovl_copy_up_meta_inode_data() now returns -EIO instead of -ERANGE in this case of underlying xattr size changes. Reported-by: Fahad Alharbi Tested-by: Fahad Alharbi Suggested-by: Miklos Szeredi Link: https://lore.kernel.org/linux-fsdevel/CAJfpegsVoUyqy0dYkTvBGRZvgdv_nmzmCw_uF+LP-Vq3EhEkSg@mail.gmail.com/ Fixes: e4ad29fa0d22 ("ovl: use a minimal buffer in ovl_copy_xattr") Cc: stable@vger.kernel.org Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit a8ad9bba205f7c6f3b86fcf0bd2d98adcd750f2e Author: Chris Mason Date: Wed Oct 7 12:10:59 2026 +0000 ovl: fix a torn path in ovl_get_redirect() commit 2001cd7ca5560198131e46c6ca3c3472b06145c2 upstream. A hard link of a metacopy file that races with a rename of an ancestor stores a redirect to the wrong lower file. Each component of an absolute redirect must be the name that a dentry has in the parent that the walk continues with. ovl_get_redirect() copies the name under d_lock and calls dget_parent() after the unlock, and the callers for a hard link hold no lock that stops a rename across directories. A rename between the two steps combines the old name with the new parent. With delays in ovl_get_redirect(), an unprivileged user hard-linked a metacopy file while renaming its ancestor to another directory, the stored redirect named another lower path, and after a remount the file showed the data of a root-only file. Fix this by taking the parent first and checking it again under d_lock. Fixes: e04527fefba6 ("ovl: fix dentry leak in ovl_get_redirect") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 3b1f5a4652539014f0162944f1a5f71ee520188a Author: Chris Mason Date: Wed Oct 7 09:45:28 2026 +0000 ovl: do not copy up an xattr value that was never read commit 755b5c5c9277be251a51623d6065abab948c61bc upstream. Copy-up stores uninitialized kernel memory in an xattr of the upper file, where the user can read it. ovl_copy_xattr() may only pass bytes to ovl_do_setxattr() that ovl_do_getxattr() has read. When the read fails with -ERANGE the function asks for the size again, and if the new size fits the buffer it stores the buffer although nothing was read into it. The buffer comes from kvmalloc(), or it still holds the value of the previous xattr. A FUSE lower layer that answers every sized GETXATTR with -ERANGE made copy-up store 4096 bytes that the server never sent, with a kernel pointer in them, as an xattr of the upper file. Fix this by failing the copy-up with -EIO when the size that follows -ERANGE fits the buffer. Reported-by: Fahad Alharbi Closes: https://lore.kernel.org/linux-fsdevel/CAOQ4uxjhfpNVvoVrTayj46H2CViTOc3oxzM6xdb8+E7ikE2CSA@mail.gmail.com/ Fixes: e4ad29fa0d22 ("ovl: use a minimal buffer in ovl_copy_xattr") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 4a58c0d62bd23173dee3f337f623d3e14b6c9dd4 Author: Chris Mason Date: Fri Oct 16 21:17:07 2026 +0000 ovl: always encode the origin fh when index is enabled commit 949f9d8a5580c77a45fa759123367682aba4d173 upstream. On an overlay with index=on,nfs_export=on, copy up of a directory crashes the kernel once an LSM has started to deny CAP_DAC_READ_SEARCH to the mounter, the task that mounted the overlay. The mount and the LSM policy change require root. After that, any user who can write to a directory that exists only in a lower layer triggers the oops by doing so. Before a file or directory that exists only in a lower layer is changed for the first time, overlayfs copies it to the writable upper layer. This is called copy up. On copy up, ovl_get_origin_fh() encodes the file handle of the lower inode, called the origin. It returns NULL if ovl_can_decode_fh() says that the lower filesystem cannot decode handles. Whether the callers can handle NULL depends on the index option: - Without an index, NULL is fine: the callers store an empty origin xattr. - With index enabled, overlayfs keeps entries for copied up inodes in an internal index directory. The name of an index entry is derived from the handle, so ovl_get_origin_fh() must return a handle or an error. The mount only enables the index if ovl_can_decode_fh() succeeds for all layers, but the result can change later. The function checks the export operations of the filesystem and capable(CAP_DAC_READ_SEARCH). Copy up runs with the mounter's credentials, and an LSM can start to deny the capability to those credentials after the mount. ovl_get_origin_fh() then returns NULL with index enabled. This goes wrong in two callers: - With nfs_export=on, copy up of a directory creates an index entry for the directory. ovl_create_index() passes the NULL handle to ovl_get_index_name_fh(), which dereferences it. - If the result changes while mount(2) is still running, ovl_get_indexdir() passes a NULL from ovl_get_origin_fh() to ovl_verify_set_fh() in the same way. Before the commit in the Fixes tag, these two callers encoded the handle themselves, without consulting ovl_can_decode_fh(). Reproduced with a BPF LSM program that started to deny the capability after the mount. An unprivileged touch in a directory that had not been copied up yet oopsed in ovl_get_index_name_fh(). With this patch the touch succeeds and the directory gets its index entry. Fix this by calling ovl_can_decode_fh() in ovl_get_origin_fh() only when index is disabled. Fixes: 5b02bfc1e7e3 ("ovl: do not encode lower fh with upper sb_writers held") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 17a540e65e567c8e4dd165a3ce5b592842ba5ab5 Author: Chris Mason Date: Wed Oct 7 10:47:10 2026 +0000 ovl: use the pinned upper dir in ovl_fix_origin() commit 4f61ff2ebfb3d2967b83b6a4d456242244d5a61f upstream. Renames made directly on the upper filesystem during a lookup crash the kernel. A dentry that is passed to vfs_setxattr() must be pinned. ovl_fix_origin() passes upper->d_parent to ovl_set_impure() without a reference, and the lookup holds no lock of the upper directory. A rename on the upper filesystem changes d_parent, and only the child pins the new parent, so a second rename and an rmdir free it. With delays in ovl_fix_origin() and ovl_set_impure(), renaming the upper directory twice and removing the intermediate parent during the lookup of a merge directory without an origin xattr gave a KASAN use-after-free in vfs_setxattr(). Fix this by passing the upper dentry that the overlay parent holds. Fixes: 9678e6303057 ("ovl: fix inconsistent d_ino for legacy merge dir") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik [amir: add helper ovl_set_impure_dir()] Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 9d844cf28544bfb3e121d31c68f3062bb237022e Author: Chris Mason Date: Wed Oct 7 10:34:08 2026 +0000 ovl: take a snapshot of the name for copy up commit 65bf000962a33ec9d2488e4e1797b6cf630abcbb upstream. The copy up of a directory reads a freed dentry name when a lookup moves the directory at the same time. A pointer to the name of a dentry is only valid while something stops a move of the dentry. ovl_do_copy_up() keeps a plain copy of c->dentry->d_name in c->destname, and ovl_copy_up_start() only keeps ovl_rename() away. When a lookup finds the same directory under another name after a change to the lower layer, d_splice_alias() moves the dentry and frees its external name. With a delay in ovl_do_copy_up(), a chmod of a lower-only directory with a 60 byte name raced with a rename of that directory in the lower layer and a stat of the new name, and KASAN reported a use-after-free in lookup_noperm_common(). Fix this by using take_dentry_name_snapshot() for c->destname. Fixes: 829c28be9bb9 ("ovl: use d_splice_alias() in place of d_add() in lookup") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit af78baeacd731a98531eaa3103bfe03f147cffb7 Author: Weiming Shi Date: Sun Oct 25 02:07:30 2026 -0700 smb: client: stop processing a read response after a receive error commit 51efca72345acdbedc4af76782d464bd15ba50ff upstream. cifs_read_iter_from_socket() may call cifs_reconnect() before returning an error. The reconnect path aborts pending mids and invokes their callbacks. The callback can then release the cifs_io_subrequest containing rdata. cifs_readv_receive() nevertheless continues after a negative return and may dereference rdata in cifs_readv_discard(). KASAN reports the resulting UAF: BUG: KASAN: slab-use-after-free in cifs_readv_receive Read of size 4 by task cifsd cifs_readv_receive (fs/smb/client/transport.c:1284) cifs_demultiplex_thread (fs/smb/client/connect.c:1355) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) Freed by task 148: netfs_put_subrequest (fs/netfs/objects.c:267) netfs_read_collection (fs/netfs/read_collect.c:460) netfs_wait_for_in_progress (fs/netfs/misc.c:462) Return the socket error immediately, as this path did before the iterator conversion. This also avoids adding a negative length to total_read. Cc: stable@vger.kernel.org Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list") Reported-by: co+24c7c12d69e63c6d@bugs.sh Assisted-by: LLM Signed-off-by: Weiming Shi Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 9bb37c10bbd57a4a2b7fa61f7c4af479225d0c11 Author: Diego Oliva Date: Tue Sep 29 10:16:31 2026 +0100 smb: client: fix OOB last_entry pointer from unbounded LastNameOffset commit 570c783a96f054dd3ac409a92772e9afb705d21c upstream. CIFSFindFirst() and CIFSFindNext() locate the last entry of a TRANS2_FIND_FIRST2 or TRANS2_FIND_NEXT2 response by adding the LastNameOffset of the response parameters to the start of the data area, and store the result in psrch_inf->last_entry. MS-CIFS 2.2.6.2.2 defines that offset as the offset of the entry's file name; the client follows the reading of NT and Samba servers, which point it at the entry. LastNameOffset is only checked against CIFSMaxBufSize, which says nothing about the response actually received: validate_t2() lets the data area start up to 1024 bytes into the buffer, and SendReceive() copies at most CIFSMaxBufSize + MAX_CIFS_HDR_SIZE bytes of a response, 16468 by default, into a cifs_request allocation of CIFSMaxBufSize + MAX_SMB2_HDR_SIZE bytes, 16588 by default. The pointer itself can therefore be placed anywhere from the end of the received data to 820 bytes past the end of the allocation. The read through that pointer is far larger than its displacement. find_cifs_entry() hands last_entry to cifs_save_resume_key() after every FindNext and after the FindFirst of a search rewind, and cifs_fill_dirent() takes the length of the name from the entry itself: a __le32 FileNameLength for most levels, a __u8 for SMB_FIND_FILE_INFO_STANDARD, and for SMB_FIND_FILE_UNIX the result of a scan for the terminating NUL over up to PATH_MAX + 1 UTF-16 units. The name is recorded as the resume name of the search, and the next CIFSFindNext() rejects only a recorded length of PATH_MAX or more before copying the name into the ResumeFileName of its request and sending it with the resume key taken from the same entry: up to 4 KiB of memory from past the end of the allocation leaks to the server, and for SMB_FIND_FILE_UNIX the NUL scan runs about twice as far before the length is even known. The entry does not have to lie outside the response for that either: a maximal response ends about 120 bytes before the end of the allocation, so an entry in its last bytes with a name just under PATH_MAX has nearly all of that name copied from past the allocation. It needs nothing unusual from the client: a FindNext response that reports no entries and does not end the search makes find_cifs_entry() send the next FindNext at once, carrying whatever was parsed at LastNameOffset, and a search rewind can do the same after its FindFirst. SMB1 is not negotiated by default: this takes a malicious or compromised server, a mount of it with an explicit vers=1.0, which CONFIG_CIFS_ALLOW_INSECURE_LEGACY (default y) permits, and a directory listing on that mount. With KASAN enabled, a response that places the last entry past the buffer, with a large DataOffset and a LastNameOffset near the end of its range, gives: ================================================================== BUG: KASAN: slab-out-of-bounds in cifs_save_resume_key.isra.0+0x7aa/0x7f0 Read of size 4 at addr ffff88807b55c33b by task ls/83 CPU: 1 UID: 0 PID: 83 Comm: ls Not tainted 7.3.0-rc4-00457-gf14572c203d5 #69 PREEMPT(lazy) Call Trace: kasan_report+0xdf/0x1a0 cifs_save_resume_key.isra.0+0x7aa/0x7f0 cifs_readdir+0x1ed6/0x29c0 iterate_dir+0x1c0/0x570 __x64_sys_getdents64+0x133/0x270 do_syscall_64+0x109/0x5d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 83 on cpu 0 at 19.317556s: cifs_buf_get+0x36/0x90 smb_init+0x4f/0x110 CIFSFindNext+0xf7/0x14c0 cifs_readdir+0xf51/0x29c0 The buggy address belongs to the object at ffff88807b558000 which belongs to the cache cifs_request of size 16588 The buggy address is located 623 bytes to the right of allocated 16588-byte region [ffff88807b558000, ffff88807b55c0cc) ================================================================== The four bytes read there are the FileNameLength of the entry, which cifs_fill_dirent() takes before anything checks where the entry lies. Ignore the last entry when it does not start inside the received response or the response holds no entries; for a response without entries, last_entry pointed into or past its empty data area and cifs_save_resume_key() parsed whatever the buffer held there. The entry is bounded by the response that was received, which is what the buffer holds, rather than by the data area the response declares, which a later patch checks against the received length. Record the search handle before the last entry is examined, since a response without a usable last entry still carries the handle that the search is continued and closed with; leaving the assignment in the else branch would drop the handle of every response without entries. This bounds where the last entry starts, not how far it is parsed: an entry that starts within the final bytes of the response still has its fixed part read past the end of the received data and its name, up to 4095 bytes, copied from past the end of the allocation, until the following patch bounds the parse itself. A response without a usable last entry continues the search with an empty resume name, since the preceding patch, "smb: client: fix use-after-free infoleak via the readdir resume name", drops the recorded name whenever a new response is installed. This patch applies on top of that one and relies on it: without it, every response rejected here would leave the previous name in place, pointing into a buffer that has been released. A conforming server is not affected: the last entry lies inside the data area of the response. Fixes: 0752f1522a91 ("[CIFS] make sure we have the right resume info before calling CIFSFindNext") Fixes: b77d753c413e ("[CIFS] Check that last search entry resume key is valid") Cc: stable@vger.kernel.org Assisted-by: Bynario AI Signed-off-by: Diego Oliva Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 84908981fbda3c133b60e75568d853d3191f9fb2 Author: Cen Zhang Date: Thu Oct 22 17:08:41 2026 +0800 ocfs2: snapshot dentry names in file and setattr traces commit 8cd3ff30659775a6831c66687a69d2b83d163591 upstream. Patch series "ocfs2: stabilize dentry names in file and setattr traces", v4. Snapshot names at all six users of ocfs2__file_ops and at the separate setattr event. Patch 1 handles the five ordinary file-operation callers and setattr. Patch 2 handles release separately to preserve its locked open-count sample and take the snapshot outside that critical section. The release explanation distinguishes its existing RCU lifetime coverage from name/length consistency. It does not claim that the ordinary callers' external-name UAF interleaving crosses the held inode spinlock. The release source change is unchanged from v3. Patch 1 also removes the read callback's redundant NULL-inode check. The two patches apply independently and leave trace formats unchanged. This patch (of 2): The open, fsync, read, write and splice-read trace calls pass the live dentry name and length to the shared ocfs2__file_ops event class. ocfs2_setattr() passes the same unprotected arguments to its own event. Both events size and copy a __string field separately. A reference to the dentry does not pin the external storage backing an individual name. With an event enabled, a caller can be preempted after loading the name pointer. A long-to-short rename can then replace the name and reclaim its old external allocation before the trace callback sizes or copies it, provided no other snapshot retains that allocation. The setattr inode lock does not exclude every rename: a same-directory rename of a source directory need not take that directory's inode lock. It can therefore change the dentry name while setattr records its event. Inline names and separately loaded lengths can also change during trace record sizing and copying. Take a dentry name snapshot around each of these six trace calls and pass both the string and length from the snapshot. Check event enablement before taking a snapshot. Keep the event classes and formats unchanged. Also remove the redundant NULL-inode check in the read callback. file_inode() returns the open file's inode, which is already used by the trace call above the check. The historical report below is from the read path. KASAN report as below: BUG: KASAN: slab-use-after-free in strlen+0x85/0xa0 Read of size 1 at addr ffff88810a5b2b18 by task python3/496 [CPU and host details omitted.] Call Trace: dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? strlen+0x85/0xa0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? strlen+0x85/0xa0 kasan_report+0xe0/0x110 ? strlen+0x85/0xa0 strlen+0x85/0xa0 trace_event_raw_event_ocfs2__file_ops+0xf0/0x480 ? __pfx_trace_event_raw_event_ocfs2__file_ops+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? pmbd_probe_hit_cookie+0xe7/0x1c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_pmbd_probe_hit_cookie+0x10/0x10 ocfs2_file_read_iter+0x6cd/0xb30 ? __pfx_ocfs2_file_read_iter+0x10/0x10 ? selinux_file_permission+0x11d/0x540 ? srso_alias_return_thunk+0x5/0xfbef5 ? security_file_permission+0x26/0x80 vfs_read+0x7d2/0xc20 ? __pfx_vfs_read+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_do_sys_openat2+0x10/0x10 ksys_read+0x111/0x200 ? __pfx_ksys_read+0x10/0x10 ? irqentry_exit+0xbe/0x820 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on_prepare+0x11d/0x150 ? srso_alias_return_thunk+0x5/0xfbef5 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f [User register dump omitted.] Allocated by task 489: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x2de/0x780 __d_alloc+0x5fc/0x8c0 d_alloc_parallel+0x106/0x11d0 lookup_open+0x3ff/0x13e0 path_openat+0x95e/0x2020 do_file_open+0x21e/0x470 do_sys_openat2+0xf4/0x1b0 __x64_sys_openat+0x136/0x1e0 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 0: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 __rcu_free_sheaf_prepare+0x65/0x2a0 rcu_free_sheaf_nobarn+0x1d/0x50 rcu_core+0x6be/0x1ed0 handle_softirqs+0x1fa/0x8d0 __irq_exit_rcu+0x113/0x1e0 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x6c/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 The buggy address belongs to the object at ffff88810a5b2b00 which belongs to the cache kmalloc-rcl-192 of size 192 The buggy address is located 24 bytes inside of freed 192-byte region [ffff88810a5b2b00, ffff88810a5b2bc0) [Page and shadow-memory dumps omitted.] Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0088-v7-6324344256f0c3b1c3d8-0@gmail.com Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0088-v7-6324344256f0c3b1c3d8-1@gmail.com Fixes: 468eedde23d6 ("ocfs2: Remove mlog(0) from fs/ocfs2/file.c") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit ce7b46556af15642a1e9f8d0c596022dd7cfb4a7 Author: Cen Zhang Date: Wed Oct 14 11:47:15 2026 +0800 ocfs2: pin refcount trees before dropping the lookup lock commit 8c714a074074af7ae59233c1fa6ef9d7aa710462 upstream. A refcount tree returned to ocfs2_lock_refcount_tree() must stay alive until that caller releases its operation reference. However, ocfs2_get_refcount_tree() returns the cached pointer after dropping osb_lock, and the caller only takes its kref afterwards. The registry reference does not protect this gap from concurrent removal. This can happen when another node frees a refcount root and reuses its block with a different generation while this mount retains the old cached tree. Two local operations on different inodes sharing the new root, such as data CoW and an external xattr update, can then look up the same stale tree. Their inode locks are independent, and both the REFCOUNT DLM lock and rf_sem are acquired after the first operation reference. The following ordering is possible, with no other operation references: Data CoW Xattr update -------- ------------ Look up the old tree under osb_lock, then drop osb_lock Look up the same tree and take a kref Acquire the tree locks and read the new on-disk generation Erase the old tree under osb_lock Unlock and drop the operation kref Drop the registry kref, freeing tree Take a kref through the freed tree pointer The final kref_get() accesses freed rf_getcnt storage, and subsequent accesses in ocfs2_lock_refcount_tree() also use the freed allocation. Take the operation reference in ocfs2_get_refcount_tree() before releasing osb_lock, including when an insertion loses to another lookup. Removal must acquire the same lock, so it cannot drop the registry reference before the lookup has pinned the tree. Keep the existing unlock and error path puts. The two callers that already hold the refcount tree lock keep their borrowed lookup behavior and do not acquire an extra reference. KASAN report as below: BUG: KASAN: slab-use-after-free in ocfs2_lock_refcount_tree+0x94a/0x9b0 Read of size 4 at addr ffff888117212820 by task python3/497 [Kernel and hardware identification omitted.] Call Trace: dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? ocfs2_lock_refcount_tree+0x94a/0x9b0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? ocfs2_lock_refcount_tree+0x94a/0x9b0 kasan_report+0xe0/0x110 ? ocfs2_lock_refcount_tree+0x94a/0x9b0 ocfs2_lock_refcount_tree+0x94a/0x9b0 ? __pfx_ocfs2_lock_refcount_tree+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? ocfs2_refcount_cow+0x3b6/0xd90 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kmalloc_cache_noprof+0x28d/0x610 ? ocfs2_refcount_cow+0x3b6/0xd90 ocfs2_refcount_cow+0x410/0xd90 ? __pfx_ocfs2_refcount_cow+0x10/0x10 ? __pfx___might_resched+0x10/0x10 ? down_write+0x11a/0x1f0 ? __pfx_down_write+0x10/0x10 ? ocfs2_inode_unlock+0x1a9/0x260 ? __pfx_ocfs2_inode_unlock+0x10/0x10 ? ocfs2_file_write_iter+0x1413/0x1d30 ocfs2_file_write_iter+0x157b/0x1d30 ? __pfx_ocfs2_file_write_iter+0x10/0x10 ? lock_acquire+0x190/0x300 ? __x64_sys_pwrite64+0x1b7/0x220 ? __pfx___might_resched+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? security_file_permission+0x26/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_is_held_type+0x8f/0x100 vfs_write+0x639/0x1010 ? __pfx_ocfs2_file_write_iter+0x10/0x10 ? lock_vma_under_rcu+0x154/0x4a0 ? __pfx_vfs_write+0x10/0x10 ? lock_release+0x121/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 __x64_sys_pwrite64+0x1b7/0x220 ? __pfx___x64_sys_pwrite64+0x10/0x10 ? irqentry_exit+0xbe/0x820 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on_prepare+0x11d/0x150 ? srso_alias_return_thunk+0x5/0xfbef5 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Register dump omitted.] Allocated by task 491: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x28d/0x610 ocfs2_allocate_refcount_tree+0x49/0x1a0 ocfs2_create_refcount_tree+0x5d7/0x1630 ocfs2_attach_refcount_tree+0x57d/0x1100 __ocfs2_reflink.isra.0+0x1c4/0x1940 ocfs2_reflink+0x501/0x9b0 ocfs2_reflink_ioctl+0x6b2/0x920 ocfs2_ioctl+0x538/0x640 __x64_sys_ioctl+0x163/0x1d0 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 498: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x308/0x580 ocfs2_lock_refcount_tree+0x672/0x9b0 ocfs2_xattr_set+0x72c/0x2530 ocfs2_xattr_user_set+0xaf/0xf0 __vfs_setxattr+0x143/0x1b0 __vfs_setxattr_noperm+0x112/0x5b0 __vfs_setxattr_locked+0xfe/0x2b0 vfs_setxattr+0x13c/0x370 do_setxattr+0x128/0x170 filename_setxattr+0x147/0x190 path_setxattrat+0x1ac/0x260 __x64_sys_setxattr+0xcb/0x140 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff888117212800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 32 bytes inside of freed 1024-byte region [ffff888117212800, ffff888117212c00) [Page and memory dumps omitted.] Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0037-v4-9f1a261dfbc341721689@gmail.com Fixes: 374a263e790c ("ocfs2: Add refcount tree lock mechanism.") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Tao Ma Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit 76986d0ad2e1b71a304db59980f7d3440709cf69 Author: Jiaming Zhang Date: Mon Sep 14 11:49:40 2026 +0800 ocfs2: fix chunk number of the first chunk in a local quota file commit 4effccfd50baee4f325694964aeee997dca7bd96 upstream. Mounting a crafted OCFS2 image can corrupt kernel memory. When the local quota file header of such an image claims zero chunks, the first quota entry allocated during the mount gets a chunk number taken from a kernel pointer, and releasing that entry clears a bit far outside the chunk bitmap. The write will corrupt the data stored at that address, and the corruption may lead to a system crash or damage unrelated data. Mounting requires CAP_SYS_ADMIN, so it takes an untrusted image, such as removable media or a loop mount of a file from elsewhere. Since the chunk number comes from a kernel pointer, the address of the bit that gets cleared differs from boot to boot, and the issue has been reported under several titles: - BUG: unable to handle kernel paging request in ocfs2_local_release_dquot - KASAN: use-after-free Write in ocfs2_local_release_dquot - KASAN: slab-out-of-bounds Write in ocfs2_local_release_dquot - KASAN: slab-use-after-free Write in ocfs2_local_release_dquot - KFENCE: use-after-free write in ocfs2_local_release_dquot Note that none of these is a use-after-free in the quota code: the chunk and its buffer head are alive. The bit that gets cleared lies far outside the bitmap. KASAN and KFENCE name each report based on the object occupying that address, which explains why the same issue is reported under so many different titles. In the report I sent, the address fell in a free page, which KASAN labels use-after-free. There are known reproducers. Both a syzkaller and a C reproducer are available from the Google Drive link [1] in my report thread. The issue was found by our modified syzkaller, not a theoretical thing found by an LLM. I have not seen it outside fuzzing, so it is not affecting me in the real world. The local quota file in OCFS2 is divided into chunks, and each chunk begins with a header block holding a bitmap of the quota entries that chunk has handed out. Chunks are numbered from zero, and that number is used to convert the file offset of an entry back into a bit position in the bitmap. ocfs2_local_quota_add_chunk() appends a new chunk to the in-memory list and numbers it one past the chunk that was last: list_add_tail(&chunk->qc_chunk, &oinfo->dqi_chunk); chunk->qc_num = list_entry(chunk->qc_chunk.prev, struct ocfs2_quota_chunk, qc_chunk)->qc_num + 1; The predecessor is looked up after the new chunk is added to the list, so if the list was empty, the prev pointer is the list head itself. The head is the dqi_chunk member of struct ocfs2_mem_dqinfo and is not a chunk, so reading qc_num through it lands 16 bytes past the start of the head, on the dqi_gqinode pointer that follows it. The first chunk of the file is then numbered with the lower half of a kernel pointer instead of 0. The list is empty when the local quota file header claims the file has no chunks. ocfs2_local_read_info() takes dqi_chunks from that header without validating it, so an image with dqi_chunks == 0 takes this path when the first quota entry is allocated. ocfs2_create_local_dquot() turns the bad number into a file offset with ol_dqblk_off(), which shifts a 32-bit block number left by the block size bits, so the top bits of such a large block number are lost. ocfs2_local_release_dquot() turns the offset back into a bit index with ol_dqblk_chunk_off(), using the full chunk number, so the lost bits push that index far outside the bitmap, and clearing it corrupts unrelated memory. Compute the chunk number before putting the chunk on the list, and use 0 when the list is empty. Link: https://lore.kernel.org/20260914034940.4070970-1-r772577952@gmail.com Link: https://drive.google.com/drive/folders/1-LzPTgOALEc3eOjmgM6oOfRKkYXJ-bnO?usp=drive_link [1] Fixes: 9e33d69f553a ("ocfs2: Implementation of local and global quota file handling") Signed-off-by: Jiaming Zhang Signed-off-by: Andrew Morton Closes: https://lore.kernel.org/lkml/CANypQFZ05tpth0Xc33gmP6jgPnkY4VuezyHcsajV-SqCsmN_gg@mail.gmail.com/ Reviewed-by: Joseph Qi Assisted-by: Claude Code:claude-opus-5 Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Greg Kroah-Hartman commit 7873680692369bcdf65480a8d81ccd2f298a13b3 Author: Cen Zhang Date: Wed Oct 14 11:43:40 2026 +0800 ocfs2: cancel quota sync work before freeing quota info commit 1dd1f005026d52642b994d63baa16b0b31f3b14f upstream. OCFS2 quota info owns dqi_sync_work and must outlive both its timer and qsync_work_fn(). ocfs2_local_free_info() frees that owner without cancelling the work, relying on the quota suspend/disable wrappers. Loading quotas on a read-only to read-write remount can successfully queue the work in ocfs2_global_read_info() and then fail while attaching a dquot to an existing inode in add_dquot_ref(). The quota core unwinds that failure directly through dquot_disable(), bypassing the OCFS2 wrapper: Remount task (s_umount write) Timer/workqueue ocfs2_global_read_info() schedules dqi_sync_work add_dquot_ref() returns an error dquot_disable() ocfs2_local_free_info() frees oinfo delayed-work timer expires qsync_work_fn() reads oinfo The timer core can then write to the freed embedded timer, or qsync_work_fn() can read oinfo->dqi_gqinode before its s_umount trylock. The outer ocfs2_disable_quotas() cleanup skips the failed type because dquot_disable() has already cleared its loaded state. Cancel dqi_sync_work synchronously at the start of ocfs2_local_free_info(), before dropping the global inode or freeing any owner state. The work is initialized whenever read_file_info() succeeds. dquot_disable() holds s_umount for write, so the callback skips its quota scan via down_read_trylock() and can finish without waiting for teardown. The synchronous cancel also handles its self-rearm. KASAN report as below: BUG: KASAN: slab-use-after-free in __run_timers+0x9e9/0xa10 Write of size 8 at addr ffff888111b0aad0 by task swapper/3/0 Call Trace: dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? __run_timers+0x9e9/0xa10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? __run_timers+0x9e9/0xa10 kasan_report+0xe0/0x110 ? __run_timers+0x9e9/0xa10 __run_timers+0x9e9/0xa10 ? __pfx___run_timers+0x10/0x10 ? __lock_acquire+0x5a3/0x2140 ? __pfx_do_raw_spin_lock+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 timer_expire_remote+0xfa/0x160 ? __pfx_timer_expire_remote+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x160 tmigr_handle_remote_up+0x4ba/0x9d0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? tmigr_handle_remote+0x21a/0x340 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups_from+0x5a/0x160 tmigr_handle_remote+0x24f/0x340 ? __pfx_tmigr_handle_remote+0x10/0x10 ? lock_acquire+0x190/0x300 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 run_timer_softirq+0x222/0x270 ? __pfx_run_timer_softirq+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? lockdep_hardirqs_on_prepare+0xb8/0x1a0 ? srso_alias_return_thunk+0x5/0xfbef5 handle_softirqs+0x1fa/0x8d0 ? __pfx_handle_softirqs+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock+0x23/0x40 ? srso_alias_return_thunk+0x5/0xfbef5 ? __hrtimer_rearm_deferred+0x1fb/0x5d0 __irq_exit_rcu+0x113/0x1e0 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x6c/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 ? ct_kernel_exit.constprop.0+0xc5/0xf0 ? do_idle+0x3ae/0x650 default_idle+0x9/0x10 default_idle_call+0x6c/0xb0 do_idle+0x3ae/0x650 ? cpuhp_online_idle+0x9c/0xb0 ? __pfx_do_idle+0x10/0x10 ? __entry_text_end+0x1020f6/0x1020f9 ? lockdep_hardirqs_on_prepare+0xeb/0x1a0 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 cpu_startup_entry+0x54/0x60 start_secondary+0x223/0x2d0 ? __pfx_start_secondary+0x10/0x10 common_startup_64+0x13e/0x158 Allocated by task 523: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x28d/0x610 ocfs2_local_read_info+0x181/0x1580 dquot_load_quota_sb+0x69e/0x11c0 dquot_load_quota_inode+0x227/0x3e0 ocfs2_enable_quotas+0x27c/0x520 ocfs2_reconfigure+0x964/0xd00 reconfigure_super+0x3ca/0xa70 path_mount+0x141e/0x1e80 __x64_sys_mount+0x24b/0x2d0 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 523: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x308/0x580 ocfs2_local_free_info+0x47b/0x800 dquot_disable+0x5d9/0x17a0 dquot_load_quota_sb+0xd3c/0x11c0 dquot_load_quota_inode+0x227/0x3e0 ocfs2_enable_quotas+0x27c/0x520 ocfs2_reconfigure+0x964/0xd00 reconfigure_super+0x3ca/0xa70 path_mount+0x141e/0x1e80 __x64_sys_mount+0x24b/0x2d0 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff888111b0a800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 720 bytes inside of freed 1024-byte region [ffff888111b0a800, ffff888111b0ac00) Host details, register and page dumps omitted. Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0052-v3-b4904bd6c85daf033adf@gmail.com Fixes: 1a6152d36dee ("quota: propagate error from __dquot_initialize") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Reviewed-by: Jan Kara Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Chao Yu Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit ecc5b17b8d2b1f720262e991896da2c909154a4d Author: Joseph Qi Date: Wed Oct 14 19:23:21 2026 +0800 ocfs2/dlm: hold the lookup reference across convert AST enqueue commit 125fe08ff6cfa064e1212f586f01993ee45c0330 upstream. dlm_convert_lock_handler() drops the reference it took when it found the lock on res->granted at its leave label, one statement before it calls dlm_queue_ast(). dlm_free_dead_locks() takes res->spinlock and drops the list and base references, so a peer death landing in that gap leaves the handler's own put as the one that frees the lock, and __dlm_queue_ast() then reads lock->lockres from freed memory. The handler is registered next to dlm_create_lock_handler(), so a convert message buffered on a dying peer's socket arrives on the same o2net receive work that o2net_disconnect_node() does not wait for. The two can interleave as follows, with the reference counts as they are before this fix: Socket data-ready Node-down thread Receive worker ----------------- ---------------- -------------- o2net_data_ready() select sc under callback read lock o2net_disconnect_node() queue shutdown begin flush; new color queue sc_rx_work in the new color release callback lock shutdown socket flush returns read buffered convert_lock dlm_convert_lock_handler() find lock on res->granted dlm_lock_get() refs = 3 lock res->spinlock __dlmconvert_master() call_ast = 1 unlock res->spinlock DLM node-down cleanup lock res->spinlock dlm_free_dead_locks() unlink lock put list ref refs = 2 put base ref refs = 1 unlock res->spinlock dlm_lock_put() refs = 0 free lock dlm_queue_ast() __dlm_queue_ast() read lock->lockres (use-after-free) __dlmconvert_master() only moves the lock between lists, so the count entering the gap is base, list and lookup. Drop the lookup reference after the AST is queued instead of before it and the race ends with the one __dlm_queue_ast() took, which dlm_flush_asts() releases later with ast_pending cleared and ast_list unlinked. No extra get is needed, and the normal case ends with the same count as before. dlmconvert_master() has the same shape but is only reached from dlmlock() for a lock this node owns, which dlm_free_dead_locks() never matches. Link: https://lore.kernel.org/20261014112321.2955584-1-joseph.qi@linux.alibaba.com Fixes: 2c5c54aca9d0 ("ocfs2/dlm: Add missing dlm_lock_put()s") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Reviewed-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Signed-off-by: Greg Kroah-Hartman commit 11643cb726c6077c8d80766516c20ff25ba29609 Author: Cen Zhang Date: Tue Oct 13 23:39:29 2026 +0800 ocfs2/dlm: hold a lock reference across grant AST enqueue commit 71743471204e21113295c786e5cfa570294234a4 upstream. A newly granted remote lock must remain alive until its grant AST is queued. dlmlock_master() publishes the lock on res->granted with its base and queue references, then drops res->spinlock before calling dlm_queue_ast(). The resource's reserved AST count does not retain the lock itself. This can fail when a peer dies with an immediately grantable CREATE buffered on its socket. O2NET's node-down callback flushes receive work before DLM cleanup, but the flush only waits for work queued on entry. A data-ready callback that already selected the socket container can queue new receive work after the flush advances its work color. Socket shutdown does not discard bytes already queued for TCP receive. The late receive work and DLM node-down cleanup can interleave as follows (the lock reference operations shown are before this fix): Socket data-ready Node-down thread Receive worker ----------------- ---------------- -------------- o2net_data_ready() select sc under callback read lock o2net_disconnect_node() queue shutdown begin flush; new color queue sc_rx_work in the new color release callback lock shutdown socket flush returns read buffered CREATE dlmlock_master() lock res->spinlock add lock to granted unlock res->spinlock DLM node-down cleanup lock res->spinlock dlm_free_dead_locks() unlink lock put queue/base refs free lock unlock res->spinlock dlm_queue_ast() __dlm_queue_ast() read lock->lockres (use-after-free) DLM cleanup holds res->spinlock while dlm_free_dead_locks() drops the queue and base references. The CREATE handler no longer holds that spinlock when __dlm_queue_ast() reads the lock, before taking its AST list reference. Take a temporary lock reference under res->spinlock when a grant AST will be queued, and drop it after dlm_queue_ast(). This keeps the lock alive across cleanup until the AST path has taken its own reference, without reversing the existing AST/resource lock order. KASAN report as below: BUG: KASAN: slab-use-after-free in __dlm_queue_ast+0x8a4/0xc00 Read of size 8 at addr ffff88810ead5940 by task kworker/u16:3/52 CPU: 3 UID: 0 PID: 52 Comm: kworker/u16:3 Not tainted 7.3.0-rc4-next-20260921-pmb-bt-functional-v1+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: o2net o2net_rx_until_empty Call Trace: dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? __dlm_queue_ast+0x8a4/0xc00 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? __dlm_queue_ast+0x8a4/0xc00 kasan_report+0xe0/0x110 ? __dlm_queue_ast+0x8a4/0xc00 __dlm_queue_ast+0x8a4/0xc00 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_spin_lock+0x130/0x270 ? __pfx___dlm_queue_ast+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x45/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? lockdep_hardirqs_on_prepare+0xeb/0x1a0 dlm_queue_ast+0x46/0x70 dlmlock_master+0x51f/0xf50 ? __pfx_dlmlock_master+0x10/0x10 ? dlm_create_lock_handler+0x2b2/0x870 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 dlm_create_lock_handler+0x35b/0x870 ? __pfx_dlm_create_lock_handler+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? kvm_clock_get_cycles+0x31/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_dlm_create_lock_handler+0x10/0x10 o2net_rx_until_empty+0x1dae/0x32c0 ? reacquire_held_locks+0xdd/0x200 ? __pfx_o2net_rx_until_empty+0x10/0x10 ? lock_acquire+0x190/0x300 ? process_one_work+0x935/0x1b40 ? process_one_work+0x834/0x1b40 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 process_one_work+0x9a8/0x1b40 ? __pfx_process_one_work+0x10/0x10 ? lock_acquire+0x190/0x300 ? lock_is_held_type+0x8f/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x65c/0xe40 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kthread_parkme+0x177/0x220 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_worker_thread+0x10/0x10 kthread+0x351/0x460 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x659/0x940 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x74f/0xf70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 52: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x89/0x90 kmem_cache_alloc_noprof+0x20b/0x5c0 dlm_new_lock+0x39/0x5f0 dlm_create_lock_handler+0x16e/0x870 o2net_rx_until_empty+0x1dae/0x32c0 process_one_work+0x9a8/0x1b40 worker_thread+0x65c/0xe40 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 Freed by task 603: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kmem_cache_free+0x242/0x580 dlm_lock_release+0x1df/0x2f0 dlm_lock_put+0x51/0x80 __dlm_hb_node_down+0x15be/0x2710 dlm_hb_node_down_cb+0x6c/0xa0 o2hb_run_event_list+0x34a/0x500 o2hb_do_disk_heartbeat+0x1a07/0x2950 o2hb_thread+0x1ed/0xdc0 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff88810ead5900 which belongs to the cache o2dlm_lock of size 184 The buggy address is located 64 bytes inside of freed 184-byte region [ffff88810ead5900, ffff88810ead59b8) [Page and shadow memory dumps omitted.] Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0043-v5-1ad07df761ff49638789@gmail.com Fixes: 2c5c54aca9d0 ("ocfs2/dlm: Add missing dlm_lock_put()s") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Kees Cook Cc: Sunil Mushran Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit dffcdb5633641360204daee2f27d259a06f494ca Author: Cen Zhang Date: Fri Oct 9 13:21:42 2026 +0800 ocfs2/heartbeat: unlink live slots when their node is missing commit 3ccd24c3f7a577b84a532cb027f1378385b82ef6 upstream. o2hb_shutdown_slot() returns immediately when its node is no longer in the configfs registry. A slot can still be linked in o2hb_live_slots when that lookup fails. Region teardown or startup-error cleanup then frees the slot array without removing its embedded list member. With the same peer live in another region, the next list update can follow a predecessor into the freed array. Reusing the node number can also make a later insertion encounter that stale member. Always remove the slot under o2hb_live_lock, even when node lookup fails. Preserve aggregate membership accounting and the last-region DOWN callback: the existing callback interface explicitly permits a NULL node for DOWN events. Only drop the node reference when lookup returned one. This closes both normal release and startup-abort paths without changing the publication or callback locking protocol. Also require a configured node before admitting a new live slot in o2hb_check_slot(). The early live-bitmap check is not held through admission: the last live slot in another region can be removed in between. Without a node, admission can then queue an UP event with a NULL argument and hit the event helper's BUG_ON. Existing live slots can still leave and generate NULL-node DOWN events. A controlled probe-instrumented test reproduced this while stopping one of two regions after removing the peer from configfs. Its KASAN report includes: BUG: KASAN: slab-use-after-free in __list_del_entry_valid_or_report+0x1e0/0x210 Read of size 8 at addr ffff888106a4ac60 by task o2hb-pmbd0058_b/497 Call Trace: dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 kasan_report+0xe0/0x110 __list_del_entry_valid_or_report+0x1e0/0x210 o2hb_do_disk_heartbeat+0x1591/0x2c50 o2hb_thread+0x1ed/0xe70 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 Allocated by task 491: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x2de/0x780 o2hb_region_dev_store+0x7c2/0x1b60 configfs_write_iter+0x2f9/0x4f0 vfs_write+0x639/0x1010 ksys_write+0x111/0x200 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 491: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x308/0x580 o2hb_unmap_slot_data+0x1db/0x330 o2hb_region_release+0x14b/0x4f0 config_item_cleanup+0x14b/0x230 config_item_put+0x79/0x90 configfs_rmdir+0x58a/0x910 vfs_rmdir+0x2e8/0x820 filename_rmdir+0x3b1/0x520 __x64_sys_rmdir+0x4b/0x70 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0058-v2-9446113c2b16c817c538@gmail.com Fixes: a7f6a5fb4bde ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Yufan Chen Cc: Kees Cook Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit 6ed2a693e60d33514b4e4fa0bef267a01eca6b60 Author: Sean Young Date: Wed Aug 12 15:46:42 2026 +0100 media: rc: Fix ABBA deadlock by making locks more fine grained commit c6d68866ad8aa1e957a3e5a6ede971148f1e3d59 upstream. The ir_raw_event_unregister() function takes the ir_raw_handler_lock first and then the rc_dev->lock. Other functions like change_protocol do this in the reverse order. This means that an ir decoder module unload and writing to the protocol sysfs file can cause a deadlock. ir_raw_handler_lock protects the client list, amongst other things. Split this out into a separate lock so we can ensure the locking order is always the same. Fixes: 93cffffc18f6 ("[media] media: rc: fix decoder module unloading") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 52efde6424420e0cf33df2ba23a8495cc141581f Author: Sean Young Date: Mon Jul 6 18:47:51 2026 +0100 media: rc: Fix use after free in bpf progs commit f95a9f8472f97c30106513fc7494b7abad243949 upstream. Since commit dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks"), rcdev->raw is no longer set to NULL after device unregister. raw->progs could point to stale data. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit dbc33be4381cec822906781abb58465d136208a2 Author: Sean Young Date: Fri Sep 4 14:07:44 2026 +0100 media: rc: After rc_unregister_device() timers can be re-armed commit ef41a67979aed4d7d4f393c56c1e25b6754e2b78 upstream. If rc_keydown() is called after rc_register_device(), then the timers can be re-armed. Delete them again for a final time. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 31d5d26130bf4b53684e662e3c3add03662b69d3 Author: Sean Young Date: Mon Jul 13 11:18:39 2026 +0100 media: rc: Use after free in ir_raw_event_handle() commit 3ae19773168104fa57d2a2ec57731e89df54175f upstream. If rc_unregister_device() is called while IR is being processed, then ir_raw_event_handle() could call wake_up_process(dev->raw->thread) after kthread_stop(dev->raw->thread). Avoid use after free by using get_task_struct(). Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 15c53a8b50a9595fbd14befe8eb0455616e648a5 Author: Sean Young Date: Tue Sep 1 11:02:22 2026 +0100 media: rc: mce_kbd: Fix inconsistent locking of keylock commit 29ee25fa9beb3232808e6d0b3e8ebfb0427cb820 upstream. data->keylock is taken with spin_lock() in ir_mce_kbd_decode(), which runs in the raw IR decode kthread with local interrupts enabled, but with spin_lock_irqsave() in mce_kbd_rx_timeout(), the rx_timeout timer callback, which runs in softirq context. If the decode kthread is holding keylock via spin_lock() when a timer interrupt fires on the same CPU and the softirq runs mce_kbd_rx_timeout(), the softirq spins forever waiting for a lock that only the now-preempted kthread can release, while the kthread cannot run again until the softirq gives up the CPU. This deadlocks the CPU. Fixes: 53a62800efb2 ("media: rc: mce_kbd decoder: fix race condition") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 114c870480277554bf8242a14fa136347da81aef Author: Weigang He Date: Sat Sep 26 15:49:29 2026 +1000 media: rc: fintek-cir: process a full RX buffer instead of overflowing it commit d1febef1bcfa7bbc401729f994c375b91a833911 upstream. fintek_get_rx_ir_data() drains the CIR RX FIFO into fintek->buf[], which holds RX_BUF_LEN (32) bytes, for as long as CIR_STATUS reports pending RX data: do { sample = fintek_cir_reg_read(fintek, CIR_RX_DATA); ... fintek->buf[fintek->pkts] = sample; fintek->pkts++; ... } while (status & rx_irqs); Nothing bounds fintek->pkts. If the hardware reports data for more than RX_BUF_LEN reads in one interrupt, the loop writes past the end of buf[], starting with the pkts counter that follows it in struct fintek_dev. Hand a full buffer to fintek_process_rx_ir_data(), which parses the samples and resets fintek->pkts, before storing the next sample. This keeps the parser state consistent and drops no samples. The loop still relies on the status register to terminate. The driver does not document the hardware FIFO depth, so it is not known whether a working device can trigger this. Found by static analysis tool CodeQL. Fixes: 9bdc79ea07d9 ("[media] fintek-cir: new driver for Fintek LPC SuperIO CIR function") Cc: stable@vger.kernel.org Assisted-by: LLM codeql Signed-off-by: Weigang He Signed-off-by: Sean Young Signed-off-by: Greg Kroah-Hartman commit 4c94661218f2accf309372cac59ebe9e21853349 Author: Sean Young Date: Fri Aug 7 11:50:22 2026 +0100 media: rc: Ensure registered is cleared in error path commit 37efd09ba2c62e46e3a3a793025c186f8cd1a417 upstream. If rc_register_device() fails, ensure that registered is not set to true. If lirc_register() succeeded, then userspace could have an open file descriptor open. This leads to a use-after-free. lirc_unregister() must be called with registered = false, else there is a possibility that an fd is open and polling, which would never return POLLERR unless registered is false. Note that registered must be changed under dev->lock, many functions read registered under lock (e.g. lirc_ioctl). Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5698bd38cf2a64c8bdb84243ec9c664d7b941135 Author: Sean Young Date: Wed Aug 12 13:00:23 2026 +0100 media: rc: Ensure that rc_unregister_device() does not free input device commit 61c7ca95d2483c77dfdde1b007cbe846f145dec4 upstream. During or after rc_unregister_device(), IR may still be reported which results in a input event being reported. This could result in a null pointer deref in rc_keydown() or a use-after-free of the input device if the pointer was read before it is set to NULL. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2b76fa7fb0a44ded2367e51b1d296f962854301f Author: Janne Grunau Date: Fri Oct 2 11:13:29 2026 +0100 nvmem: core: Fix OOB read for bit offsets of more than one byte commit 24530401e8001aaa637dd5007fcdc6fbc00300be upstream. When the bit offset is BITS_PER_BYTE or larger the read position is advanced by `bytes_offset`. This is not taken into account in the per-byte read loop which still reads `cell->bytes` resulting in an out of bounds read of `bytes_offset` bytes. The information read OOB does not leak directly as the erroneously read bits are cleared. Detected by KASAN while looking for a use-after-free in simplefb.c. Cc: stable@vger.kernel.org Fixes: 7a06ef751077 ("nvmem: core: fix bit offsets of more than one byte") Tested-by: Dmitry Sinyavin Signed-off-by: Janne Grunau Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20261002101329.1084348-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 3146e37745171f9b9b8aab48d9b8dbcb14a186e0 Author: Myeonghun Pak Date: Sun Oct 4 00:10:19 2026 -0400 power: supply: sbs-battery: disable polling before supply teardown commit 5c1c602463d597c5189ddc5a73dece588ba2c57a upstream. The managed poll-work cancellation is registered before the power supply, so cleanup unregisters the supply before draining polling. A pending or running poller can then call power_supply_changed() on the released supply. Commit 8d59cf3887fb ("power: supply: sbs-battery: Fix use-after-free in power_supply_changed()") moved the IRQ request after supply registration, but did not change the poll-work cancellation order. Add a later managed action that disables and drains polling before supply teardown. Its retained disabled state prevents external-power callbacks from rearming the poll work after it has been drained. Keep the original autocancel to initialize work before supply callbacks can run and to cover failed supply registration. The teardown ordering issue was found by static analysis. Fixes: 6d0c5de2fd84 ("power: supply: Clean-up few drivers by using managed work init") Cc: stable@vger.kernel.org # 6.10+ Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20261004041019.1123723-1-mhun512@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 2156c5aefd2c97a60766520bd04f4790f3b38f64 Author: Bryan O'Donoghue Date: Fri Sep 18 14:56:36 2026 +0100 phy: core: Fix race-condition between _of_phy_get() and try_module_get() commit 090055ee629523092688da42428558ba56d4272f upstream. Sashiko asked during a patch review if the existing usage pattern had a race condition; specifically in of_phy_get() if it was possible between returning from _of_phy_get() and running try_module_get() that a module might be unbound leading to use-after-free. Looking at the code this appears to be so, there is no linkage between the phy and module under a synchronisation primitive. Using the phy_provider_mutex in phy_get() will ensure there is a link between the returned phy pointer and the module_get() bumping the module reference count. Amend phy_get(), of_phy_get() and devm_of_phy_get_by_index() to fix the same usage pattern. phy_provider_unregister() must take the phy_provider_mutex so amending phy_get()/of_phy_get() to take that same mutex guarantees there is no use-after-free. Fixes: ff764963479a1 ("drivers: phy: add generic PHY framework") Cc: stable@vger.kernel.org Reviewed-by: Manivannan Sadhasivam Reviewed-by: Loic Poulain Tested-by: Oleg Keri # Lenovo Yoga Slim 7x Gen 11 (Glymur) Signed-off-by: Bryan O'Donoghue Link: https://patch.msgid.link/20260918-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v20-1-dc244e124e71@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 14ab6a4761d2e4a02cb6859aee19788f38a24056 Author: Nickolai Zeldovich Date: Fri Oct 16 10:00:43 2026 -0400 resource: report a devm_request_resource() conflict under the lock commit d2f7bdfdeac8137e942b32e0badc40e181127d7b upstream. devm_request_resource() calls request_resource_conflict(), which takes resource_lock, tries to insert the new resource and returns a pointer to the conflicting resource after dropping the lock. The error message is then formatted from that pointer: conflict->name and the %pR argument read the name, start, end, flags and desc of a resource that nothing pins any more. The owner of the conflicting resource may call release_resource() and free it the moment the lock is dropped. The conflicting resource normally belongs to another device. With two devices whose drivers claim overlapping regions (two PCI host bridges whose "ranges" windows overlap, two instances of a controller on the same aperture, or a stale claim an administrator is replacing), the following interleaving reads freed memory: CPU 0: driver B probe CPU 1: driver A unbind devm_request_resource(devB, root, resB) request_resource_conflict() write_lock(&resource_lock) __request_resource() -> resA write_unlock(&resource_lock) devres_release_all(devA) devm_resource_release() release_resource(resA) put_device() -> kfree(resA) dev_err(..., resA->name, resA) use after free Both halves are reachable from userspace on any kernel: a write to the "unbind" file of the driver that holds the region and a write to the "bind" file of the driver that wants it. One in-tree path is drivers/pci/bus.c devm_request_pci_bus_resources(), called from host bridge probe for every bridge window; the windows are the embedded struct resource of kzalloc'ed resource_entry objects that pci_free_resource_list() frees when the other bridge is released. In the common case the "resource collision" message is garbled; with the slab object poisoned (CONFIG_SLUB_DEBUG) or reused, formatting conflict->name oopses, and KASAN reports a slab-use-after-free read in devm_request_resource(). All of this happens in a probe that is already failing with -EBUSY. The window is a few hundred instructions wide and exists only when two devices actually collide, so the race has not been observed outside of analysis. Do the same here: take resource_lock, insert with __request_resource() and print the diagnostic while the lock still keeps the conflicting resource in the tree, then drop the lock. The return values and the devres handling are unchanged. The change was built for x86_64 and RISC-V; the resource KUnit tests pass on both. Found by formal verification of kernel/resource.c against the kernel binary. Link: https://lore.kernel.org/20261016140043.790048-1-nickolai@csail.mit.edu Fixes: 8d38821cbcf5 ("resources: Add device-managed request/release_resource()") Signed-off-by: Nickolai Zeldovich Signed-off-by: Andrew Morton Acked-by: Tejun Heo Reviewed-by: Bradley Morgan Assisted-by: LLM Cc: Bjorn Helgaas Cc: Ilpo Järvinen Cc: Thierry Reding Cc: Signed-off-by: Greg Kroah-Hartman commit ae50223c56b9a1c27d4f824c9e2fbbefc8686891 Author: YANXIN LI Date: Sat Jul 18 19:03:07 2026 +0000 ufs: use u64 for directory size in ufs_last_byte commit 1eff23433e73d7da4f9e3529d2701e34962b161f upstream. ufs1_read_inode() and ufs2_read_inode() copy the untrusted 64-bit on-disk size into inode->i_size. ufs_last_byte() then truncates that value to an unsigned int before calculating the valid extent of a directory folio. A directory size of exactly 4 GiB is truncated to zero. In ufs_find_entry(), subtracting the requested record length from that zero forms an endpoint almost 4 GiB beyond the mapped folio. A crafted UFS2 image produces: BUG: KASAN: use-after-free in ufs_find_entry+0x583/0x6e0 [ufs] Read of size 1 ... ufs_find_entry ufs_inode_by_name ufs_lookup __lookup_slow path_lookupat The KASAN classification reflects that the adjacent physical page was free; the source-level operation is an out-of-folio read. A controlled UFS1 test with CONFIG_UFS_FS_WRITE enabled also made ufs_find_entry() return a directory entry from an adjacent anonymous page. unlink() then passed that pointer to ufs_delete_entry(), which cleared the adjacent page's 3 2-bit d_ino. This write result reproduced three out of three times. UFS normally requires a privileged mount path. A relevant boundary is a privileged automounter or image-processing service handling an attacker-supplied filesystem. The write primitive additionally requires UFS1 to be mounted read-write with CONFIG_UFS_FS_WRITE enabled; the read is reachable with read-only UFS2. Keep the intermediate size arithmetic at 64 bits so non-final pages are bounded at PAGE_SIZE. With this change, the same controlled tests reach the real on-disk directory entry and produce no adjacent-page write or KASAN report. A reproducer and full validation logs are available on request. The vulnerable helper is present in v7.2-rc3, v7.1, v6.18.38, v6.12.95, v6.6.111, and upstream master at 1229e2e57a5c. Runtime reproduction and fix validation were performed in an x86-64 QEMU guest running v7.2-rc3 with generic KASAN. Fixes: b71034e5e67d ("[PATCH] ufs: directory and page cache: from blocks to pages") Cc: stable@vger.kernel.org Signed-off-by: YANXIN LI Link: https://patch.msgid.link/20260718190300.867109-1-fadouse@pm.me Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit a28791bdb256abd0f338a9b32a95392907d1c987 Author: Nguyen Quang Le Kien Date: Tue Aug 11 14:08:10 2026 +0800 usb: gadget: fix refcount underflow in gadgetfs_bind() error path commit cb3b441f2698455a48e9a023d5f7f4e3fcb94c73 upstream. gadgetfs_bind() calls get_dev() only on the success path, but gadgetfs_unbind() called from the enomem error label unconditionally calls put_dev(). When bind fails (e.g. ENOMEM), put_dev() fires without a matching get_dev(), leaving the refcount unbalanced. A subsequent close of the ep0 file descriptor calls dev_release() -> put_dev() which hits zero and frees the object; then gadgetfs_kill_sb() calls put_dev(the_device) again on the already-freed pointer, triggering a refcount underflow and use-after-free. Fix by calling get_dev() at the start of gadgetfs_bind(), before any error path that invokes gadgetfs_unbind(), so the reference is always balanced regardless of whether bind succeeds or fails. Reported-by: syzbot+8496ab5e117502750445@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=8496ab5e117502750445 Signed-off-by: Nguyen Quang Le Kien Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260811060810.295666-1-khiemtranzo532001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit c2c268ec920867b42ad5a26781f3c0ec426fb897 Author: Rosen Penev Date: Fri Sep 11 14:31:44 2026 -0700 wifi: ath9k: delete channel-context timers on deinit commit 81394dfb9a7905472957628b560ae894eae3a30f upstream. ath9k_deinit_channel_context() cancels chanctx_work but does not delete the offchannel and sched timers set up by ath9k_init_channel_context(). If either timer fires after deinit (e.g. during driver unload or suspend), it accesses sc->sc_ah which may already be freed by ath9k_hw_deinit(), causing a use-after-free. Delete both timers with timer_shutdown_sync() before cancelling the work item. Assisted-by: LLM Signed-off-by: Rosen Penev Acked-by: Toke Høiland-Jørgensen Cc: stable@vger.kernel.org # v6.2+ Fixes: 705d0bf83dbe ("ath9k: Add a routine for initializing channel contexts") Link: https://patch.msgid.link/20260911213144.130192-1-rosenp@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit 9cdf4fae8fde297ed9ce6bb0058d25449606ee66 Author: Yuchao Zhang Date: Tue Sep 22 15:21:55 2026 +0800 xen-blkfront: unbind irq before tearing down ring and shadow requests commit f3e27b7955727a4d7c0e9264a2a209fbba788bdc upstream. In blkif_free_ring(), the driver tears down the ring's persistent grants, shadow request arrays, and shared ring structure (xenbus_teardown_ring), and only calls unbind_from_irqhandler() at the very end. While blkif_free_ring() is freeing persistent grants and clearing the shadow array, the event channel interrupt (blkif_interrupt) is still registered and active. If an interrupt arrives from the backend during this teardown window, blkif_interrupt() reads rinfo->ring.sring and, via blkif_completion(), accesses rinfo->shadow[id].grants_used and rinfo->shadow[id].sg. blkif_free_ring() tears these structures down without holding rinfo->ring_lock, and the handler only checks info->connected at entry, so this is a real race resulting in a use-after-free or NULL pointer dereference. Fix this by moving unbind_from_irqhandler() to the beginning of blkif_free_ring(). Calling unbind_from_irqhandler() first frees the IRQ and synchronizes with any in-flight interrupt handlers on other CPUs before ring memory and shadow request structures are deallocated, matching the teardown order in drivers/net/xen-netfront.c. Fixes: 11659569f720 ("xen/blkfront: split per device io_lock") Cc: stable@vger.kernel.org Signed-off-by: Yuchao Zhang Acked-by: Roger Pau Monné Signed-off-by: Juergen Gross Message-ID: <20260922072155.34625-1-ndaugoing@gmail.com> Signed-off-by: Greg Kroah-Hartman commit b05d5ed61e84ad15536e4e51db79a1d1c221c6f1 Author: Igor Putko Date: Sat Oct 3 19:33:37 2026 +0300 serial: core: shut down initialized port on removal commit 810d467c11f0c85107874d08dfdd11acba6aa0c0 upstream. When a serial port configured as a console is opened and subsequently closed, tty_port_shutdown() skips invoking port->ops->shutdown() because port->console is true. As a result, tty_port_initialized() remains true and the port's interrupt handler stays registered in the irq subsystem. If the underlying device is later unbound or removed (e.g. via sysfs driver unbind or device hot-unplug), serial_core_remove_one_port() unregisters the console, frees uport->name via kfree(), and tears down the port without shutting it down or freeing its IRQ. Consequently, the irqaction descriptor remains registered in genirq with action->name pointing to freed memory. This triggers a use-after-free read whenever genirq accesses action->name, such as when reading /proc/interrupts: BUG: KASAN: slab-use-after-free in string+0x476/0x570 Call Trace: string+0x476/0x570 vsnprintf+0x422/0x1300 seq_printf+0x... show_interrupts+... Fix this by acquiring port->mutex in serial_core_remove_one_port() after console unregistration, clearing port->console under the mutex to prevent data races with concurrent tty_port_shutdown(), and invoking uart_shutdown(NULL, state) if the port remains initialized. This ensures that port->ops->shutdown() is called and the IRQ is freed before kfree(uport->name). Reported-by: syzbot+843bf2f48f4d12e6682e@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=843bf2f48f4d12e6682e Fixes: 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") Fixes: f7048b15900f ("tty: serial_core: Add name field to uart_port struct") Signed-off-by: Igor Putko Link: https://patch.msgid.link/20261003163337.45577-1-igorpetindev@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit c08e076cb1976942a4bfcbc1c4dff76addd51fc7 Author: Vernon Yang Date: Wed Sep 9 10:58:03 2026 +0800 mm: khugepaged: fix folio is used after folio_put/unlock() commit 9010383e71e6ce75fcd3c8f87133c8ce6c0e6ab4 upstream. On the rollback path, folio_put() has already dropped the last reference of new_folio. On the success path, new_folio is already unlocked and can be freed concurrently. The trace_mm_khugepaged_collapse_file() is left with a dangling folio pointer. So using the folio_pfn() before dropping the reference, closing use-after-free window. Link: https://lore.kernel.org/20260909025804.3233645-4-vernon2gm@gmail.com Fixes: 4c9473e87e75 ("mm/khugepaged: add tracepoint to collapse_file()") Signed-off-by: Vernon Yang Signed-off-by: Andrew Morton Acked-by: David Hildenbrand (Arm) Acked-by: Lorenzo Stoakes (ARM) Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Ryan Roberts Cc: Zach O'Keefe Cc: Signed-off-by: Greg Kroah-Hartman commit e92aeeb4c3704f036ad1563630882b39f4c6c801 Author: Imre Kaloz Date: Wed Oct 14 17:08:43 2026 +0200 mm/slab: sample slab_state once in kmem_cache_destroy() commit 088bfdc0d7947d623f4899b9011c866e4445074d upstream. kmem_cache_release() tests slab_state >= FULL after kmem_cache_destroy() has dropped slab_mutex and unlinked the cache, and for a SLAB_TYPESAFE_BY_RCU cache after rcu_barrier(). If slab_late_init() runs before that test it sets slab_state to FULL but skips the unlinked cache, which never got a sysfs entry, so sysfs_slab_release() calls kobject_put() on a kobject that was never initialized: WARNING: lib/kobject.c:734 at kobject_put+0x64/0x2c0, CPU#1: kworker/u8:3/55 kobject: '(null)' ((____ptrval____)): is not initialized, yet kobject_put() is being called. refcount_t: underflow; use-after-free. kobject_put+0x64/0x2c0 sysfs_slab_release+0xc/0x20 kmem_cache_destroy+0x104/0x1e0 bioset_exit+0x13c/0x1e0 disk_release+0x54/0x140 put_disk+0x18/0x40 floppy_async_init+0xbec/0xd10 slab_state >= FULL asks whether the cache has a kobject, which cache creation skips while slab_state <= UP. UP is the state just below FULL, so a false sample cannot skip a kobject_put() that was owed. Seen on sparc64 at boot, where the asynchronous floppy init tears down its bio slab while the late initcalls are running. Sample slab_state once, under slab_mutex which slab_late_init() holds when it sets FULL, and use the result for both the unlink and the release. The history of this problem dates back to v3.2: Commit 69cb8e6b7c29 ("slub: free slabs without holding locks") in v3.2 moved sysfs_slab_remove() outside slub_lock and introduced a race condition between kmem_cache_destroy() and slab_sysfs_init(). Commit 945cf2b6199be ("mm/sl[aou]b: Extract a common function for kmem_cache_destroy") in v3.7 accidentally closed the race while extracting a common implementation for kmem_cache_destroy(). Commit 5413dfba88d6 ("slub: drop mutex before deleting sysfs entry") in v3.8 re-opened the race by dropping slab_mutex around sysfs_slab_remove() in __kmem_cache_shutdown(), to avoid a lockdep splat between slab_mutex and the sysfs lock. Commit 657dc2f97220 ("slab: remove synchronous rcu_barrier() call in memcg cache release path") in v4.11 shifted from synchronous rcu_barrier() to asynchronous RCU work for SLAB_TYPESAFE_BY_RCU caches. That commit, again, accidentally closed the race by moving sysfs_slab_release() to shutdown_cache(), but only for !SLAB_TYPESAFE_BY_RCU caches because destruction of SLAB_TYPESAFE_BY_RCU caches is done in an RCU work. Commit 0495e337b703 ("mm/slab_common: Deleting kobject in kmem_cache_destroy() without holding slab_mutex/cpu_hotplug_lock") in v6.0 re-introduced the race for !SLAB_TYPESAFE_BY_RCU caches. Fixes: 69cb8e6b7c29 ("slub: free slabs without holding locks") Fixes: 5413dfba88d6 ("slub: drop mutex before deleting sysfs entry") Fixes: 0495e337b703 ("mm/slab_common: Deleting kobject in kmem_cache_destroy() without holding slab_mutex/cpu_hotplug_lock") Cc: stable@vger.kernel.org Signed-off-by: Imre Kaloz Reviewed-by: Jose A. Perez de Azpillaga Reviewed-by: Harry Yoo (Meta) Link: https://patch.msgid.link/20261014150844.8536-1-kaloz@kernel.org Reviewed-by: Vlastimil Babka (SUSE) Signed-off-by: Harry Yoo (Meta) Signed-off-by: Greg Kroah-Hartman commit d8f44a9e4820797067b8cdf1b6a4cb0c0ae3d143 Author: Rik van Riel Date: Sat Aug 8 23:20:31 2026 -0400 media: redrat3: fix UAF in probe error path leaving rc device registered commit af452b9e01331b5338a1e5141624f17607239207 upstream. redrat3 stores its device name and phys path inside the main rr3 structure, and the rc device's device_name and input_phys point into rr3. When the RC device is registered, it keeps those pointers. KASAN: slab-use-after-free in string_nocheck lib/vsprintf.c:648 Read of size 1 at addr ffff888051fda758 by task udevd/7464 Call Trace: string_nocheck lib/vsprintf.c:648 [inline] string+0x216/0x2d0 lib/vsprintf.c:730 vsnprintf+0x74a/0xef0 lib/vsprintf.c:2945 vscnprintf+0x41/0x90 lib/vsprintf.c:3014 sysfs_emit+0x10e/0x180 fs/sysfs/file.c:761 input_dev_show_name+0x58/0x70 drivers/input/input.c:1282 Allocated by task 10: redrat3_dev_probe+0x477/0x2570 drivers/media/rc/redrat3.c:1023 Freed by task 10: redrat3_delete drivers/media/rc/redrat3.c:466 [inline] redrat3_dev_probe+0x1bf4/0x2570 drivers/media/rc/redrat3.c:1124 Syzkaller triggers this via usb probing. It probes the RedRat3 USB interface, which calls redrat3_dev_probe() in redrat3.c. That function allocates rr3, then builds an rc device whose name points into rr3 via redrat3_init_rc_dev() in redrat3.c, and registers it with rc_register_device(). When the detector enable fails after the RC device is registered, the probe jumps to the led_free path. That path unregisters the LED but does not unregister the RC device before freeing rr3 via redrat3_delete() in redrat3.c. The RC device still holds device_name = rr3->name which is now freed. Later udevd reads /sys/.../input device name via sysfs_emit() in file.c, which calls input_dev_show_name() in input.c, which emits dev->name which is the freed rr3->name. When the detector enable fails after the RC device is registered, the error path must not leave the RC device registered. Make the probe error path clean up the same way redrat3_dev_disconnect() does. This change should be safe because the RC device is fully registered at this point and its teardown via rc_unregister_device() is protected by the input device mutex, and rr3 is still alive during unregister so device_name remains valid until after unregister. The URBs are killed before rc_free, so no completion can run after rc is freed. No new lock ordering is introduced. Reported-by: syzbot+302b9b575a06733ff60c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=302b9b575a06733ff60c Link: https://lore.kernel.org/all/6a74a76d.ec7c9571.3ac9bb.0056.GAE@google.com/ Fixes: 2154be651b90 ("[media] redrat3: new rc-core IR transceiver device driver") Cc: stable@vger.kernel.org Assisted-by: Hermes:muse-spark-1.2 syzkaller Signed-off-by: Rik van Riel Signed-off-by: Sean Young Signed-off-by: Greg Kroah-Hartman commit e89700269a8158781cb0053589a0d7f206bdf7cb Author: Balakrishnan Sambath Date: Mon Aug 17 12:21:59 2026 +0530 media: microchip-isc: take a reference on the parsed endpoints commit f2eb2fd388bf3f1959556a326e797cacca341c86 upstream. for_each_endpoint_of_node() drops the reference on the current node as it advances. xisc_parse_dt() and isc_parse_dt() store the node in subdev_entity->epn and release it later with of_node_put(), but never took their own reference, so the stored pointer refers to an already-released node. This underflows the refcount and can use-after-free, reachable through the camera device tree overlay. Take a reference with of_node_get() when storing the node, and drop it in microchip_isc_subdev_cleanup() so the entities the bind loop never reaches on an early exit do not leak it. Fixes: c9aa973884a1 ("media: atmel: atmel-isc: add microchip-xisc driver") Fixes: d6701f13bd07 ("media: atmel: Use v4l2_async_notifier_add_fwnode_remote_subdev") Cc: stable@vger.kernel.org Signed-off-by: Balakrishnan Sambath Reviewed-by: Eugen Hristev Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c287bcddda615b3c954cb5b1fc7e59292c878eeb Author: Cong Nguyen Date: Sat Aug 8 16:07:29 2026 +0700 media: microchip-csi2dc: fix async notifier leak on probe error path commit c7528789244ce7329ca883170fb9315d739ae985 upstream. csi2dc_of_parse() ends up calling csi2dc_prepare_notifier(), which registers the V4L2 async notifier with v4l2_async_nf_register(). The probe error label csi2dc_probe_cleanup_notifier is reached after csi2dc_of_parse() has already succeeded (e.g. when media entity init, csi2dc_power() or v4l2_async_register_subdev() fail), but it calls only v4l2_async_nf_cleanup() and never v4l2_async_nf_unregister(). The notifier therefore stays chained in the global notifier_list while the enclosing struct csi2dc_device is freed, leading to list corruption and a use-after-free when the list is next walked. Unregister the notifier before cleaning it up on the error path, matching the teardown already done in csi2dc_remove(). Fixes: 2de0b3c0f678 ("media: atmel: introduce microchip csi2dc driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Reviewed-by: Eugen Hristev Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 8445398f75ed573cd8eafaa01273c10990e05eae Author: Fan Wu Date: Fri Aug 7 05:35:53 2026 +0000 media: marvell: mcam: stop DMA and cancel s_bh_work before freeing DMA buffers commit 0f29f84317c1e35f6a9265277be33e60d3fc8c1c upstream. In vmalloc mode the frame-completion IRQ queues mcam_frame_work() on cam->s_bh_work, which memcpy()s from the dma_bufs[] that mcam_free_dma_bufs() frees with dma_free_coherent(). mccic_shutdown() frees those buffers without stopping the controller, so while streaming a late frame IRQ can re-arm the work after the buffers are gone, causing a use-after-free. Stop the controller in mccic_shutdown() when streaming is still active (gated on an open fd, which holds a runtime-PM reference, so the device is powered), cancel s_bh_work in mcam_free_dma_bufs(), and move INIT_WORK() into mccic_register() before the device can be published. Fixes: 67a8dbbc4e04 ("[media] marvell-cam: Basic working MMP camera driver") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 77e1c41d65a9f3cd22d73d0ec1f33cf6cd37b341 Author: Fan Wu Date: Tue Jun 23 10:30:31 2026 +0000 media: imx-jpeg: cancel timeout worker when streaming stops commit 78fdfbf117c409273eecbfa7a528ef42358a0e38 upstream. Each per-fd context ctx owns a delayed_work (ctx->task_timer, callback mxc_jpeg_device_run_timeout) armed via schedule_delayed_work() at the end of mxc_jpeg_device_run() to recover a stalled encode/decode job. The only existing cancellation is cancel_delayed_work() in the frame-done IRQ handler, which de-queues a pending work item but does not wait for a callback that has already started, and it only runs when a frame completes. When the fd is closed while a job is in flight (the frame-done IRQ has not fired yet), nothing syncs the worker before mxc_jpeg_release() frees ctx with kfree() after v4l2_m2m_ctx_release(). A queued or executing mxc_jpeg_device_run_timeout() can then recover ctx through container_of(&ctx->task_timer) and dereference it (ctx->mxc_jpeg, slot_data, dev_warn) after ctx has been freed. Cancel the worker from mxc_jpeg_stop_streaming(). The cancel cannot live in mxc_jpeg_release(): mxc_jpeg_device_run() arms the timer while holding only hw_lock, not the mxc_jpeg->lock mutex that release holds, so a cancel in release could still race a concurrent mxc_jpeg_device_run() that re-arms the timer afterwards. mxc_jpeg_stop_streaming() instead runs inside v4l2_m2m_ctx_release() -> vb2_queue_release(), i.e. after v4l2_m2m_cancel_job() has set TRANS_ABORT and waited for any in-flight job to finish (so __v4l2_m2m_try_queue() will not queue and v4l2_m2m_try_run() will not run any further job for this context, which prevents mxc_jpeg_device_run() from re-arming the timer) and before the m2m context is freed. cancel_delayed_work_sync() removes a pending work item and waits for a running callback, so the worker can no longer race with the subsequent kfree(). The cancel is placed before the buffer-release loop so a concurrently running timeout callback cannot race with it over the same buffers. If the frame-done IRQ canceled a still-pending timer, this cancel is a no-op; if the timeout callback has already started, it waits for the callback to finish. The same mxc_jpeg_stop_streaming() call is also reached from VIDIOC_STREAMOFF, which drains the worker early, although STREAMOFF itself does not free ctx -- the use-after-free arises only when the fd is later closed. This bug was found by static analysis. Fixes: cfed9632ca8e ("media: imx-jpeg: Add a timeout mechanism for each frame") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Reviewed-by: Ming Qian Signed-off-by: Frank Li Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit fda9ca3cbee24f6e48c04946a8d2f66565d2d4b2 Author: Shuangpeng Bai Date: Wed Aug 12 23:12:35 2026 -0400 media: gspca: use vb2_video_unregister_device() on disconnect commit 3dbbbc3cafa2de377d9b97af4e35b8b6b5282047 upstream. gspca uses vb2_fop_release(), but gspca_disconnect() only unregisters the video device. If the queue owner closes the device after USB disconnect, vb2_fop_release() releases the queue and invokes gspca_stop_streaming() at that point. gspca_stream_off() calls subdriver stop callbacks and usb_set_interface() through gspca_dev->dev. By the time the late close runs, the USB core can have freed the usb_device, resulting in a use-after-free. This was observed as a KASAN use-after-free in sd_stopN(). Use vb2_video_unregister_device() so the queue is released and streaming is stopped synchronously during disconnect, while the usb_device is still valid. Since the helper takes the queue lock, which is usb_lock, call it after dropping that lock. Fixes: f729ef5796d8 ("media: videobuf2-v4l2.c: add vb2_video_unregister_device helper function") Cc: stable@vger.kernel.org # 5.10.x Suggested-by: Hans Verkuil Signed-off-by: Shuangpeng Bai Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 262bca0d6761f4fd8755e8e223ea666d6cb81f1b Author: Myeonghun Pak Date: Sat Sep 12 22:05:54 2026 -0400 media: cx23885: unregister DVB bus when SP2 CI setup fails commit 22f552ff726a82a086be4ef02ce5099a0e8624b6 upstream. The DVBSKY S950C, DVBSKY T980C and TechnoTrend CT2-4500 CI paths register the DVB bus before attaching their SP2 CI client. If that client cannot be created, bound, or pinned, the current error path removes the I2C frontend components and only deallocates the frontend list, leaving the registered DVB adapter behind. Removing an I2C demod before unregistering the DVB bus can also expose the use-after-free ordering fixed for the normal remove path. Unregister the DVB bus immediately when SP2 CI setup fails, before the existing I2C client cleanup. The bus helper empties the frontend list, so the later frontend deallocation has nothing left to release. Keep failures from vb2_dvb_register_bus() on the existing cleanup path. Also release an unbound SP2 client and propagate the actual I2C creation or CI registration error. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 2b0aac3011bc ("[media] cx23885: move CI/MAC registration to a separate function") Cc: stable@vger.kernel.org Assisted-by: OpenAI:GPT-5.6 Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0f86aba67317d65b2dc89995dd5ddefe219411a7 Author: Amit Machhiwal Date: Mon Sep 28 17:58:35 2026 +0530 KVM: PPC: Book3S HV: Add SRCU protection for virtual-mode HPT hcalls commit 61a39797bb136243c48b46e2586d8a9e2cea6a89 upstream. The virtual-mode HPT hcall handlers (H_ENTER, H_REMOVE, H_BULK_REMOVE, H_CLEAR_REF, H_CLEAR_MOD) call into book3s_hv_rm_mmu.c, which accesses memslots via kvm_memslots_raw(). kvm_memslots_raw() uses rcu_dereference_raw_check() to bypass SRCU lockdep annotation checking. This is safe in real mode because the entire guest entry/exit is wrapped in srcu_read_lock/unlock inside kvmppc_run_core() and kvmhv_run_single_vcpu(). However, since commit 6165d5dd99db ("KVM: PPC: Book3S HV: add virtual mode handlers for HPT hcalls and page faults"), these same handlers are also executed in virtual mode via kvmppc_pseries_do_hcall(), which runs after SRCU has already been released on guest exit. A concurrent KVM_SET_USER_MEMORY_REGION deletion or move can therefore call synchronize_srcu_expedited() — which does not wait for this thread — and then kfree(slot) and vfree(slot->arch.rmap) while the hcall handler still holds a raw pointer to the memslot. lock_rmap() then writes to freed vmalloc memory, leading to use-after-free and memory corruption. Because kvm_memslots_raw() suppresses lockdep checks, this race is entirely silent. Fix this by factoring out the 7 HPT hcall handlers (H_REMOVE, H_ENTER, H_READ, H_CLEAR_MOD, H_CLEAR_REF, H_PROTECT, H_BULK_REMOVE) into a helper function, kvmppc_pseries_do_hpt_hcall(), and wrapping its call site in srcu_read_lock(&kvm->srcu) / srcu_read_unlock(&kvm->srcu, idx). Targeting only the HPT hcalls avoids wrapping non-HPT hcalls that sleep (such as H_CONFER, H_REGISTER_VPA, H_PAGE_INIT) or handlers that already acquire SRCU internally (such as H_RTAS). Fixes: 6165d5dd99db ("KVM: PPC: Book3S HV: add virtual mode handlers for HPT hcalls and page faults") Cc: stable@vger.kernel.org # v5.14+ Suggested-by: Ritesh Harjani (IBM) Signed-off-by: Amit Machhiwal Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260928122837.8782-2-amachhiw@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 9d7af67e5425ad08d1ab9bbf4a3ad987d7871834 Author: Kyle Zeng Date: Sun Oct 25 02:27:52 2026 +0000 io_uring/io-wq: save worker type before dropping its reference commit 37e425460b7c41687e51e3254b1eb1d799da9614 upstream. io_wq_cancel_tw_create() inspects cb->func after calling io_worker_cancel_cb(). For an existing worker, that call can drop the last worker reference and wake io_worker_exit(). If the canceling task is preempted, the worker can be unlinked and freed by kfree_rcu() before the callback function is inspected. KASAN reports a slab-use-after-free read in this path. Save whether the callback belongs to an unpublished continuation worker while its reference is still held, then use the saved result for the conditional free. This preserves the existing accounting and frees only the worker allocated for the canceled continuation. Fixes: e6db6f9398da ("io_uring/io-wq: only free worker if it was allocated for creation") Cc: stable@vger.kernel.org Signed-off-by: Kyle Zeng Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 81e3e5ae4228f95414665877f5e487917fbef9c0 Author: Yousef Alhouseen Date: Mon Jun 29 17:29:47 2026 +0200 HID: hiddev: keep state alive through disconnect unlock commit 03f449b5de36a25fc5eba7dabf2b4494389bdb91 upstream. mutex_unlock() clears the mutex owner before taking its wait lock. A thread spinning in the final hiddev file release can acquire existancelock after hiddev_disconnect() clears the owner, then free hiddev before the disconnecting thread reaches the mutex wait lock. This causes a use-after-free in the mutex slow unlock path. Give the connection and each open file an explicit reference. Drop each reference only after its existancelock critical section has completed, so neither unlock path can free the mutex while the other is still using it. Fixes: 079034073faf ("HID: hiddev cleanup -- handle all error conditions properly") Reported-by: syzbot+563191a4939ddbfe73d4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=563191a4939ddbfe73d4 Cc: stable@vger.kernel.org Signed-off-by: Yousef Alhouseen Link: https://syzkaller.appspot.com/bug?extid=563191a4939ddbfe73d4 Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 18d9bba2ae291657a87c85eb3a4f82b73147e55e Author: Richard Patel Date: Fri Oct 9 14:58:42 2026 +0000 genirq: Move interrupt thread exit_work object to irqaction commit 89a9e003a2ef73f67dff03dfd59e0a5474b56b0b upstream. irq_thread() registers irq_thread_dtor() as exit task_work using a stack-allocated callback_head. On normal interrupt thread exit, this work gets cancelled and never runs. On x86, an abnormal interrupt thread exit (e.g. handler oops) discards the stack, including the callback_head, while that callback_head is still pending. By the time exit_task_work() runs, the stack memory formerly backing callback_head is already clobbered. irq_thread() <-- on_exit_work allocated ** IRQ handler faults ** oops_end() rewind_stack_and_make_dead() <-- on_exit_work freed make_task_dead() do_exit(SIGSEGV) ... exit_shm() <-- on_exit_work clobbered ... exit_task_work() <-- stack use-after-free exit_shm()+0x30 <-- wild jump to return addr Thus, a benign threaded IRQ oops (e.g. a NULL pointer deref) is turned into a wild jump. This is caught by kernel IBT: ** first fault ** Oops: general protection fault, kernel NULL pointer dereference 0x3c0: 0000 [#1] SMP NOPTI ... ** second fault ** Missing ENDBR: exit_shm+0x30/0x1c0 kernel BUG at arch/x86/kernel/cet.c:133! ... ? task_work_run+0x5c/0x90 ? do_exit+0x209/0x460 ? rewind_stack_and_make_dead+0x16/0x20 ... note: irq/165-AudioDS[1427] exited with irqs disabled Fixing recursive fault but reboot is needed! Fix this by storing the callback_head in struct irqaction. The irqaction is only freed once irq_thread_dtor() finishes. Fixes: 2deb4be28077 ("x86/dumpstack: When OOPSing, rewind the stack before do_exit()") Signed-off-by: Richard Patel Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009145842.1616117-3-ripatel@wii.dev Signed-off-by: Greg Kroah-Hartman commit ec397edc4c8ca868865953926831b539698469e6 Author: Richard Patel Date: Fri Oct 9 14:58:41 2026 +0000 genirq: Defer kfree(irqaction) until irq_thread_dtor() finishes commit d04adff6860587e843948b0c31174f8ae11b8dfe upstream. When an interrupt thread exits abnormally via do_exit() (e.g. the interrupt handler oopses) without returning from irq_thread(), a concurrent call to free_irq() could free the irqaction before the irq_thread_dtor() exit task work runs. irq thread (oopsed) free_irq() ------------------- ---------- do_exit() exit_mm() complete_vfork_done() -------> kthread_stop() returns exit_files() ... kfree(action) exit_task_work() irq_thread_dtor() action->... <- use-after-free Track the pending exit work with the IRQTF_EXIT_WORK thread flag, and have __free_irq() wait for the bit to clear before kfree(). irq_thread_dtor() only runs on irq_thread abnormal exit. If that dtor also faults, free_irq() will hang indefinitely, but double IRQ thread faults require a reboot anyways. [ tglx: Add missing include ] Fixes: ed3e694d78cc ("move exit_task_work() past exit_files() et.al.") Signed-off-by: Richard Patel Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009145842.1616117-2-ripatel@wii.dev Signed-off-by: Greg Kroah-Hartman commit 6e2299a9356de3364e193d6eaf123b90d7698c1d Author: Ngoc Quy Date: Wed Oct 14 16:55:40 2026 +0700 fs/proc/task_mmu: pin mm_users in do_pagemap_scan() commit 4fb975471717c953f912776bb60301add1ffae11 upstream. The PAGEMAP_SCAN ioctl takes mmap_read_lock() on an mm obtained from /proc//pagemap without holding a reference to mm_users. proc_mem_open() deliberately grabs only mm_count, so a consumer that touches the address space has to call mmget_not_zero() first. Every other consumer in this file does -- m_start(), do_procmap_query(), show_smaps_rollup() and pagemap_read() -- but do_pagemap_scan() does not. Without that reference the target can reach exit_mmap() concurrently, and exit_mmap() calls unmap_vmas() while holding mmap_lock only for reading, which does not exclude the scanner. For ordinary VMAs this is harmless, as free_pgtables() and remove_vma() run afterwards under mmap_write_lock. A shared hugetlb VMA is different: __hugetlb_zap_end() frees the VMA's hugetlb_vma_lock inside the read-locked phase. walk_hugetlb_range() can therefore load vma->vm_private_data, have the lock freed underneath it, and then down_read() a freed rw_semaphore. The load happens before the freeing side clears the pointer, so this is a use-after-free and not a NULL dereference. Any unprivileged user can reach it with no huge pages configured, as hugetlb_reserve_pages() allocates the lock before the VM_NORESERVE early return. Pin mm_users across the scan, the way the other consumers do. mmput() from the exiting task can then no longer reach exit_mmap() while a walk is in progress. [akpm@linux-foundation.org: remove unneeded & undesirable test for !mm] Link: https://lore.kernel.org/20261014095540.3261469-1-ngocquy0700@gmail.com Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs") Signed-off-by: Ngoc Quy Signed-off-by: Andrew Morton Assisted-by: Claude:claude-opus-5 Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Muhammad Usama Anjum Cc: Signed-off-by: Greg Kroah-Hartman commit 291010d5de1c9efc38e98c416b6230500bfae438 Author: Xiang Mei Date: Sat Sep 12 14:15:12 2026 -0700 fbdev: udlfb: don't rebuild the mode list while the framebuffer is in use commit ac9cfa552102b8e80e88c2872e80dc9cb5f07dda upstream. dlfb_setup_modes() frees info->modelist with fb_destroy_modelist() and rebuilds it, but fbcon holds raw pointers into that list in fb_display[i].mode and nothing un-publishes them the way do_unregister_framebuffer() and store_modes() do with fbcon_delete_modelist(). The function does refuse to install a new mode while the framebuffer has users (dlfb->fb_count != 0), but only after the list is already destroyed. Reached from the 0666 "edid" sysfs attribute, an unprivileged write to /sys/class/graphics/fb0/edid therefore fails with -EINVAL and still leaves every fb_display[i].mode dangling; the next console switch reads the freed fb_videomode in fb_videomode_to_var(). Test fb_count before touching the list. fbcon takes a reference through fbcon_open(), so that condition covers exactly the states in which fb_display[] points into the list, and the errno returned to userspace is unchanged. BUG: KASAN: slab-use-after-free in fb_videomode_to_var (drivers/video/fbdev/core/modedb.c:905) Read of size 4 at addr ffff8880107b449c by task kworker/1:1/47 Workqueue: events console_callback Call Trace: fb_videomode_to_var (drivers/video/fbdev/core/modedb.c:905) display_to_var (drivers/video/fbdev/core/fbcon.c:998) fbcon_switch (drivers/video/fbdev/core/fbcon.c:2182) redraw_screen (drivers/tty/vt/vt.c:994) complete_change_console (drivers/tty/vt/vt_ioctl.c:1141) console_callback (drivers/tty/vt/vt.c:3358) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... The buggy address is located 28 bytes inside of freed 96-byte region [ffff8880107b4480, ffff8880107b44e0) Cc: stable@vger.kernel.org Fixes: 7d9485e2c53c ("Staging: udlfb: Add functions to expose sysfs metrics and controls") Reported-by: co+ed9902f2e44184d9@bugs.sh Closes: https://lore.kernel.org/all/1jSCSNaDKmuUG7h40rTsSl1rMaSwdlJef4rp%40bugs.sh/ Assisted-by: Claude:claude-opus-5 Signed-off-by: Xiang Mei Link: https://lore.kernel.org/all/1jSCSNaDKmuUG7h40rTsSl1rMaSwdlJef4rp%40bugs.sh/ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 0c782a29f66eab8f2f9ce2b4325cfb5b9f01f8ff Author: Yibo Tan Date: Tue Sep 15 22:45:28 2026 +0800 fbdev: atmel_lcdfb: Prevent FIFO work after removal commit 20b3b97cf89cb381bf07516090d99399cc9b91fd upstream. The LCD controller IRQ schedules sinfo->task to recover from a FIFO underflow. Probe currently requests the IRQ before initializing the work, so an early interrupt can schedule an uninitialized work item. The probe error path and remove path cancel the work before freeing the IRQ. A FIFO-underflow interrupt can schedule the work again after that cancellation. framebuffer_release() may then free sinfo while the work is still pending. KASAN reported a use-after-free in atmel_lcdfb_task() when an underflow interrupt occurred during removal. With the IRQ freed before the work was cancelled, the same test completed without a kernel diagnostic. Initialize the work before requesting the IRQ. In both cleanup paths, free the IRQ before cancelling the work so that it cannot be scheduled again after cancellation. Fixes: d22579b83735 ("atmel_lcdfb: FIFO underflow management") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Yibo Tan Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 01806613d39191f530e72926960b20638e8cde93 Author: Osama Abdelkader Date: Thu Oct 8 12:09:35 2026 +0200 drm/panthor: Fix TOCTOU race between GROUP_REGISTERED check and erase commit 7764289d76a38c3a2f9b093bf17e193ab54acd70 upstream. panthor_group_destroy() checks the GROUP_REGISTERED mark and then calls xa_erase() without holding the xarray lock across both. If the handle is destroyed by another thread in between, and a concurrent GROUP_CREATE reuses the freed ID, the first destroy erases and releases the new, still-initializing group, leading to a use-after-free in panthor_group_create(). Do the mark check and erase atomically under xa_lock(). Fixes: eec7e23d848d ("drm/panthor: Prevent potential UAF in group creation") Assisted-by: Claude:claude-opus-5.5 Reviewed-by: Boris Brezillon Reviewed-by: Liviu Dudau Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Steven Price Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20261008100935.3059587-1-osama.abdelkader@gmail.com Signed-off-by: Greg Kroah-Hartman commit a82b3dec02bd42eedbc2733b092910f3b6bc4948 Author: Bui Viet Dung Date: Thu Oct 8 11:54:13 2026 +0700 Bluetooth: hci_vhci: Pin module for debugfs file operations commit 645ee6b176c958579cff1c783413d5cff65c8197 upstream. An open debugfs file retains its file_operations pointer in the debugfs proxy state. However, force_suspend_fops, force_wakeup_fops, aosp_capable_fops, and force_devcoredump_fops have no .owner set to THIS_MODULE. As a result, full_proxy_open_regular() calls fops_get() which succeeds without taking a reference to the hci_vhci module. When userspace opens any of these debugfs files and later closes the /dev/vhci file descriptor (triggering vhci_release() and debugfs file removal), the open debugfs file descriptor remains valid in userspace. Because the module refcount was not incremented, the hci_vhci module can be unloaded via delete_module (rmmod hci_vhci). When the userspace process subsequently closes the debugfs file descriptor, full_proxy_release() accesses the already unmapped file_operations structure, resulting in a kernel page fault / oops: BUG: unable to handle page fault for address: fffffbfff846f18b #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:full_proxy_release+0x8e/0x140 Call Trace: __fput+0x39f/0xa60 fput_close_sync+0xff/0x200 __x64_sys_close+0x8c/0xf0 do_syscall_64+0xc3/0x590 entry_SYSCALL_64_after_hwframe+0x76/0x7e Modules linked in: ... [last unloaded: hci_vhci(E)] The issue was discovered via manual code audit of drivers/bluetooth/hci_vhci.c and verified on a Linux 7.3-rc6 test VM with CONFIG_BT_VHCI=m by keeping a debugfs file open across controller teardown and module unload. Set .owner = THIS_MODULE on all four file_operations structures so that debugfs pins the module until all file descriptors are closed. Fixes: 28010791193a ("Bluetooth: vhci: Prevent use-after-free by removing debugfs files early") Cc: stable@vger.kernel.org Signed-off-by: Bui Viet Dung Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 8f8555e03bb2596b0d521c5b95c72cbd76e7d9af Author: Sung Byeongchan Date: Sat Oct 3 19:18:54 2026 +0900 ALSA: pcmtest: handle multiple wraps in random capture fill commit 6541871e8e63e721733cd120af4d9cd22c5ef62f upstream. The random capture helpers assume that the data generated for one timer tick wraps the DMA ring at most once. However, b_rw describes 200 ms of audio because the timer runs at 5 Hz, so it can be several times larger than a small ring. For 48 kHz, S16_LE, four-channel capture with a 512-frame buffer, the DMA ring is 4096 bytes while one tick generates 76800 bytes. After filling the 4096-byte tail, the existing code issues a second 72704-byte write from the ring base, writing 68608 bytes beyond the ring. Both interleaved and non-interleaved capture are affected. KASAN reports the first write into the adjacent free page as a use-after-free in the random-byte generator. The underlying defect is an out-of-bounds write from the live DMA ring, not a stale DMA allocation. Split each random write repeatedly at the interleaved ring or per-channel block boundary. Keep the hardware-pointer update exactly once after the complete logical write. The issue reproduced on three of three clean boots. With this change, the same vulnerable geometry completed six times without a sanitizer finding. Boundary, pattern-fill, no-timer, open/close, and module-reload controls also completed normally. snd-pcmtest is a test driver, and selecting random fill requires an administrator-controlled module parameter. The written values come from the kernel random generator; no privilege escalation or attacker-controlled write primitive was demonstrated. Fixes: 315a3d57c64c ("ALSA: Implement the new Virtual PCM Test Driver") Cc: stable@vger.kernel.org Assisted-by: OpenAI Codex Signed-off-by: Sung Byeongchan Link: https://patch.msgid.link/20261003101854.1423146-1-tjdqudcks0424@naver.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d93d8307024eb141c8d1b127c01c6c33f1a2d6c4 Author: Takashi Iwai Date: Tue Sep 29 14:53:42 2026 +0200 ALSA: control: Fix UAF in snd_ctl_elem_add() on card disconnect commit d4febca239be3c91498762dd0535a87d4af1eabc upstream. A use-after-free can be triggered via SNDRV_CTL_IOCTL_ELEM_ADD when a USB audio card is disconnected while an ELEM_ADD ioctl is in flight. The reproducer parks the ioctl thread inside copy_from_user() using userfaultfd, then tears down the USB device. Unlike every other ALSA control _user handler (ELEM_INFO, ELEM_READ, ELEM_WRITE, TLV_*), snd_ctl_elem_add_user() never calls snd_power_ref_and_wait(), so the parked thread holds no power reference. snd_card_disconnect() therefore cannot observe it via snd_power_sync_ref() and proceeds unimpeded: 1. card->shutdown is set to 1 2. device_del(&card->card_dev) drops the kobject reference on the parent USB interface device (card->dev = &intf->dev) 3. The USB core drops its own reference and calls device_release(), freeing the struct usb_interface, including the embedded struct device that card->dev points to When the userfaultfd is resolved and the thread resumes, snd_ctl_elem_add() acquires controls_rwsem without checking card->shutdown and calls __snd_ctl_add_replace(). Because the reproducer pre-registered the same control, the CTL_ADD_EXCLUSIVE path calls dev_err(card->dev, ...) on the freed USB interface: KASAN: slab-use-after-free Read in __dev_printk Add a card->shutdown guard immediately after acquiring controls_rwsem in snd_ctl_elem_add(). At that point card->shutdown is guaranteed to be stable: snd_card_disconnect() sets it before freeing the parent device, and it never transitions back to 0. A thread that acquired the lock before disconnect sees shutdown=0 and holds the write lock through the rest of the operation, preventing concurrent disconnect from proceeding past its own controls_rwsem-less shutdown=1 store (which happened earlier, outside the lock) from racing with dev_err(). Reported-by: Farhad Alemi Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260929125346.1478631-3-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 9758d91c671d27507bfb0171f011f64341047294 Author: Miguel Ojeda Date: Sun Oct 18 15:13:13 2026 +0200 objtool/rust: add one more `noreturn` Rust function for Rust 1.101.0 commit 6b704ec9007a3f23ec5ded8f320825ac444f307d upstream. Starting with Rust 1.101.0 (expected 2026-12-24), `objtool` may report: rust/kernel.o: warning: objtool: _R..._4core6result13unwrap_failed...() falls through to next function _R..._4core6result13unwrap_failed...() (and others) due to calls to the `noreturn` symbol: core::result::unwrap_failed::unwrap_failed_inner Rust introduced this helper when making `unwrap_failed` generic [1]. The existing entry for `unwrap_failed` does not match the new helper. Thus add the mangled one to the list so that `objtool` knows it is actually `noreturn`. See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions") for more details. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Cc: Josh Poimboeuf Cc: Peter Zijlstra Link: https://github.com/rust-lang/rust/pull/164059 [1] Assisted-by: LLM Link: https://patch.msgid.link/20261018131313.59391-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 3fee2a5ef405f08ea3d87d2014ae7d38e61dd06f Author: Karl Mehltretter Date: Thu Aug 27 06:17:08 2026 +0200 klist: avoid accesses after waking klist_remove() commit 732e3e10234cbe302d0dcbaa98c91c66628209cb upstream. klist_remove() waits until a node is unreferenced so that its caller can free the containing object. klist_release() currently publishes waiter->woken and wakes the waiter before its final accesses to the waiter and node. klist_remove() can then return, allowing its stack waiter and the containing object to be freed or reused while klist_release() is still running. In particular, bus_remove_driver() can free drv->p while __device_attach() walks the same bus klist with bus_for_each_drv(). On an arm64 Cortex-A72 system, an unpatched 7.2.0-rc3 kernel with CONFIG_PREEMPT_RT=y and CONFIG_KASAN=y reproduced the bug through the in-tree I2C/at24 path. KASAN reported a use-after-free in klist_dec_and_del() reached from klist_next()/bus_for_each_drv() while at24 was being unregistered. Clear n_klist and take a task reference before publishing woken. Use release/acquire accesses for that publication and wake the referenced task. The task reference keeps the waiter task alive if it returns and exits before wake_up_process(). Link: https://lore.kernel.org/20260827041708.31682-1-kmehltretter@gmail.com Fixes: 8b0c250be489 ("[PATCH] add klist_node_attached() to determine if a node is on a list or not.") Fixes: 210272a28465 ("driver core: Remove completion from struct klist_node") Signed-off-by: Karl Mehltretter Signed-off-by: Andrew Morton Assisted-by: LLM Cc: Danilo Krummrich Cc: Greg Kroah-Hartman Cc: Matthew Wilcox (Oracle) Cc: "Rafael J. Wysocki" Cc: Signed-off-by: Greg Kroah-Hartman commit 4ceab4c59cc8bceab0472f65a6c46fcce3419b52 Author: Ping Cheng Date: Wed Oct 7 15:00:27 2026 -0700 HID: wacom: Write shared touch initial status only once commit cae3031c691dff0be61a26bc64e31a6939010d5c upstream. For consistency with how the shared has_mute_touch_switch is handled during registration, let's apply WRITE_ONCE to is_touch_on too. Cc: stable@vger.kernel.org Fixes: ba16e5ffbaa1 ("HID: wacom: Advertise SW_MUTE_DEVICE capability prior to registration") Reviewed-by: Lee Jones Signed-off-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit e4996955171d397be73ecd17e8e04ff6dba9fc66 Author: Ping Cheng Date: Wed Oct 7 15:03:35 2026 -0700 HID: wacom: Setup SW_MUTE_DEVICE according to the order of input registration commit 97ce491bcef2d231b8d51cee8e579183319a5ba4 upstream. The refactored SW_MUTE_DEVICE code assumed that stylus will be the first regiestered input. In reality, touch can be registered before stylus, such as the Wacom Cintiq Pro 13 and 16. This patch covers both touch-first and stylus-first cases. Cc: stable@vger.kernel.org Fixes: ba16e5ffbaa1 ("HID: wacom: Advertise SW_MUTE_DEVICE capability prior to registration") Reviewed-by: Lee Jones Signed-off-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 4eeb0a16f11c72a0a15e793310470418d1c2d3cd Author: Lee Jones Date: Wed Sep 9 11:12:27 2026 +0000 HID: wacom: Redesign shared sibling data lifecycle commit 480c9cb14ae81f8e112ff83f8778b3d7b9324dc8 upstream. The Wacom driver coordinates state between sibling interfaces of the same physical device using a shared structure 'wacom_shared' inside 'wacom_hdev_data'. The driver kept a volatile representative pointer 'data->dev' pointing to a sibling 'hid_device' for physical path comparisons during sibling matching. This pointer management is fragile. When the representative device is disconnected, wacom_remove_shared_data() failed to clear/update 'data->dev', leading to a Use-After-Free vulnerability when subsequent sibling probes dereference the dangling 'data->dev' pointer. Resolve this issue by redesigning the sibling data lifecycle: - Eliminate the volatile 'data->dev' representative pointer completely - Redesign 'wacom_hdev_data' to store stable static copies of the required attributes upon first allocation: 'phys' path string, 'vendor', 'product' IDs and the sibling's 'device_type' - Use these static attributes for stable sibling matching in wacom_are_sibling() and wacom_get_hdev_data() This ensures sibling matching remains safe and stable even if individual siblings are dynamically added or removed. To secure the lifecycle against concurrent probe/disconnect races: - Switch kref_put() to kref_put_mutex() in wacom_remove_shared_data() to serialize refcount drops with list traversal and lookup - Modify wacom_release_shared_data() to assume the list lock is already held Also, do not accumulate the 'device_type' capability flag during subsequent sibling probes. Keeping only the first probed sibling's device_type exactly preserves the original sibling matching behavior without introducing side effects. Cc: stable@vger.kernel.org Fixes: 4492efffffeb ("Input: wacom - share pen info with touch of the same ID") Signed-off-by: Lee Jones Acked-by: Ping Cheng Tested-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 6704d7e9ca8aa1ec66d97fe1b2bc89e07ad710c7 Author: Lee Jones Date: Wed Sep 9 11:12:26 2026 +0000 HID: wacom: Fix Use-After-Free in wacom_bamboo_pad commit 3a523ecf9ac3fdd33f5eb31c43937ee44135395b upstream. wacom_bamboo_pad_pen_event() accesses wacom->shared->pen locklessly relative to wacom_remove_shared_data() which nullifies it. This can lead to a Use-After-Free if the sibling device is removed while events are being processed. Resolve this by introducing RCU protection for pen and touch pointers: - Annotate 'pen' and 'touch' in wacom_shared struct with __rcu. - Wrap lockless readers in wacom_bamboo_pad_pen_event() with rcu_read_lock() and rcu_dereference(). - Update writers in wacom_sys.c using rcu_assign_pointer(). - Use rcu_dereference_protected for comparisons under wacom_udev_list_lock. - Also use rcu_access_pointer in wacom_sibling_pending() and wacom_mode_change_work() to avoid warnings (while lockless access in the latter remains a pre-existing issue). Cc: stable@vger.kernel.org Fixes: 8c97a765467c ("HID: wacom: add full support of the Wacom Bamboo PAD") Signed-off-by: Lee Jones Acked-by: Ping Cheng Tested-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 1178927ffa54a1f9e52fa4e5974862023237fce6 Author: Lee Jones Date: Wed Sep 9 11:12:25 2026 +0000 HID: wacom: Fix Use-After-Free in wacom_intuos_pad commit ef32877368a7013c060ef6bd03a30b6da2fe0c41 upstream. wacom_intuos_pad() accesses wacom->shared->touch_input locklessly inside the interrupt handler context. If the Touch sibling device is disconnected, wacom_remove_shared_data() clears 'touch_input' outside any lock, creating a Time-of-Check to Time-of-Use (TOCTOU) race condition where a preempted reader in interrupt context dereferences the freed pointer, leading to a Use-After-Free. Resolve this by introducing RCU protection for the touch_input pointer: - Annotate 'touch_input' in wacom_shared struct with __rcu - Wrap all lockless readers in wacom_wac.c with guard(rcu)() and rcu_dereference() using a unified wacom_report_touch_mute() helper - Update writers in wacom_sys.c using rcu_assign_pointer() - Call synchronize_rcu() in wacom_remove_shared_data() to ensure all active RCU readers have finished before the input device is freed Also wrap wacom_set_shared_values() and touch/pen assignments in wacom_add_shared_data() inside the wacom_udev_list_lock to serialize concurrent probe assignments, and verify that 'shared->touch == hdev' before setting touch_input to prevent concurrent sibling probe state desynchronization. Cc: stable@vger.kernel.org Fixes: 961794a00eab ("Input: wacom - add reporting of SW_MUTE_DEVICE events") Signed-off-by: Lee Jones Acked-by: Ping Cheng Tested-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 64a4b7b20f864687dc3da88bd2acfccdf8056ce6 Author: Lee Jones Date: Wed Sep 9 11:12:24 2026 +0000 HID: wacom: Advertise SW_MUTE_DEVICE capability prior to registration commit ba16e5ffbaa10fde960918d69af5e49f2b3fdd5e upstream. Input subsystem guidelines require that device capabilities are advertised before the input device is registered. The Wacom driver was violating this by advertising the SW_MUTE_DEVICE capability post-registration in wacom_set_shared_values() (and duplicating it in device-specific setup cases). Resolve this by moving the SW_MUTE_DEVICE capability setup to wacom_setup_touch_input_capabilities() for all touch devices that support it. For generic touch devices whose capabilities depend on mute switch usages parsed from a sibling Pen/Pad interface, defer registration with -EPROBE_DEFER until the sibling has parsed its descriptors and initialized shared capabilities. Cc: stable@vger.kernel.org Fixes: d2ec58aee8b1 ("HID: wacom: generic: support generic touch switch") Signed-off-by: Lee Jones Acked-by: Ping Cheng Tested-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 35cd4a9f06e66b0d2c6e2cce80199298b130e3e3 Author: Lee Jones Date: Wed Sep 9 11:12:23 2026 +0000 HID: wacom: Use hdev->product in wacom_setup_touch_input_capabilities commit 86472508a7ef74b525e79a79d2d02d911a641d6b upstream. Replace the lookup-dependent 'wacom_wac->shared->touch->product' references with 'hdev->product' inside wacom_setup_touch_input_capabilities() since 'hdev' is already available (via container_of) and represents the touch device itself. Cc: stable@vger.kernel.org Signed-off-by: Lee Jones Acked-by: Ping Cheng Tested-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 49dfd61f1c2ddfe028d4a9a603afc33b013e9ee9 Author: Harald Freudenberger Date: Tue Oct 6 17:46:03 2026 +0200 s390/zcrypt: Fix out-of-bounds ptr advance in cca_query_crypto_facility() commit 9fd7fca66735307fd7afa3450882a55ef80f2add upstream. The FQ reply parser code blindly advanced the walk pointer by a length value read directly from the hardware reply payload without checking that the advance stayed within the allocated reply buffer. A corrupt or malicious device response could push ptr beyond the cprbmem region, causing an out-of-bounds dereference or kernel memory exposure via the subsequent memcpy(). Fix this by tracking the remaining reply buffer space in a variable and validating each device-supplied length field against it before advancing or dereferencing the pointer. Fixes: 2004b57cde6b ("s390/zcrypt: code cleanup") Signed-off-by: Harald Freudenberger Cc: stable@vger.kernel.org Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 2281a65091dfb116ed79ebe52bc69fb27c7c2626 Author: Heiko Carstens Date: Tue Oct 13 15:34:52 2026 +0200 s390/signal: Fix incorrect return address in signal frame commit adc9e872f7350e3ac29c1818d8c68b0760b4ba23 upstream. exit_to_user_mode_loop() can call arch_do_signal_or_restart() multiple times when signals are pending. If the first call set up a vDSO system call restart by saving the real user return address and adjusting psw.addr so it points to the vDSO stub, a second call builds the signal frame with the wrong return address. Restore psw.addr from arch_data, and set the return code to -EINTR before building the signal frame. This requires restart_block.arch_data to be properly initialized for all tasks. Move the initialization in copy_thread() in front of the kernel thread check, so that it also covers kernel threads and their children (PID 1, usermode helpers). Only PID 0 is left uninitialized, since it never returns to user space. Fixes: df29a7440c4b ("s390/signal: switch to using vdso for sigreturn and syscall restart") Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit e0682a8fb9c27dffc461a8a4e76b54a65f7391e9 Author: Heiko Carstens Date: Mon Oct 12 10:36:27 2026 +0200 s390/probes: Fix wrong opcode for cgrb fixup commit d7ccab11a13475e656b9d2277900422c1bfc12c5 upstream. The last byte of the cgrb instruction is 0xe4, however the probes code compares against 0xe6. Fix it. Fixes: 6b169ac9b434 ("s390/kprobes: add support for compare and branch instructions") Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit c340698144cd18b1bdb777665269892279e25eb3 Author: Sumanth Korikkar Date: Tue Oct 6 13:13:03 2026 +0200 s390/cpum_cf: Check session mask before cpu offline commit 99a95985dfc85eecad97f0991a2401d2fcef294c upstream. cfset_offline_cpu() stops counter sets for every active session without checking whether the outgoing cpu belongs to the session mask. For example, run an hwctr session on cpu0 and a cpu bound perf event on cpu1: lshwc -l 9999 -i 5 0:b perf stat -C 1 -e cpum_cf/CPU_CYCLES/ sleep 120 chcpu -d 1 chcpu -e 1 Although the hwctr session does not include cpu1, cfset_offline_cpu() decrements its counter set reference count. The subsequent perf teardown decrements it again, causing it to underflow. The perf event keeps the percpu state alive across hotplug. When cpu1 comes online, the hwctr session is started there and the reference count moves from -1 to 0. Stopping the hwctr session then decrements it to -1 again, so the zero triggered counter set disable path is skipped. Check the session mask before stopping counter sets on the outgoing cpu. This prevents the unmatched decrement and the resulting reference count underflow. Fixes: a029a4eab39e ("s390/cpumf: Allow concurrent access for CPU Measurement Counter Facility") Reported-by: Christian Borntraeger Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Sumanth Korikkar Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 3e00737e95485b2a35bf5f515f56a4c416d5971f Author: Niklas Cassel Date: Tue Sep 15 10:41:29 2026 +0200 ata: sata_fsl: Fix use-after-free of host_priv on probe() failure commit 70b1196740d61aabda13b2ad0e9c1dfa2ef9cfa3 upstream. sata_fsl_host_stop() releases hcr_base and host_priv: static void sata_fsl_host_stop(struct ata_host *host) { struct sata_fsl_host_priv *host_priv = host->private_data; iounmap(host_priv->hcr_base); kfree(host_priv); } ->host_stop() is called by the driver core through the ata_host_stop() devres action which ata_host_start() registers, so it is called both when the device is unbound and when probe() fails after the host has been started. The error_exit_with_cleanup label of sata_fsl_probe() releases hcr_base and host_priv as well, and it is reachable from the two device_create_file() calls which are done after the host has been activated. In that case sata_fsl_host_stop() runs on an already freed host_priv, resulting in a use-after-free and a double iounmap()/kfree(). Add a separate error label for the failures happening after the host has been activated, which only detaches the host and leaves hcr_base and host_priv to sata_fsl_host_stop(). Note that ata_host_detach() is dropped from error_exit_with_cleanup, as that label is now only reachable while host is still NULL. Fixes: 6c8ad7e8cf29 ("sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl") Cc: stable@vger.kernel.org Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20260915084127.692494-11-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 2588c5693f4535e856841976cb1e1532bae77109 Author: Binbin Deng <18983559317@163.com> Date: Wed Sep 23 13:46:23 2026 +0800 apparmor: fix a use-after-free in aa_lookupn_ns() commit f292873ceb4bd3a1a0f75f884361cd556e457692 upstream. aa_lookupn_ns() takes a reference on the namespace it finds with aa_get_ns(), which is kref_get() on the reference count that the namespace is released through, without checking whether the namespace is still in use. A concurrent removal of a ":"-prefixed namespace looks the same namespace up and only then takes the parent lock to remove it, so the last reference can be dropped between the lookup and the aa_get_ns() call: the reference count then reports the increment on a zero count and the kernel classifies the following use of the object as a use-after-free. A user with CAP_MAC_ADMIN can trigger this by writing a ":" removal and a ":/" removal to /sys/kernel/security/apparmor/.remove concurrently. refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0xc0/0xe0, CPU#6 Call Trace: aa_lookupn_ns+0xa9/0xc0 aa_remove_profiles+0x4fb/0x730 ? __kvmalloc_node_noprof+0x219/0x5c0 ? __pfx_aa_remove_profiles+0x10/0x10 ? aa_loaddata_alloc+0x65/0x1f0 ? _copy_from_user+0x2d/0x80 ? aa_loaddata_alloc+0x111/0x1f0 profile_remove+0x2ee/0x4a0 vfs_write+0x21e/0xcf0 ? rcu_core+0x29c/0x1740 ? timerqueue_linked_add+0x1f4/0x3d0 ? __pfx_vfs_write+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? __pfx_rcu_core+0x10/0x10 ? __pfx_hrtimer_update_next_event+0x10/0x10 ? mutex_unlock+0x7b/0xd0 ? fdget_pos+0x24d/0x4b0 ksys_write+0xf7/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? restore_fpregs_from_fpstate+0x37/0xc0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix by rejecting a namespace whose reference count is zero. Fixes: 3664268f19ea0 ("apparmor: add namespace lookup fns()") Cc: stable@vger.kernel.org Signed-off-by: Binbin Deng <18983559317@163.com> Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit cda6c4819b4a45dbeac92652eaaffb156b3f11b1 Author: David Hildenbrand (Arm) Date: Thu Oct 15 18:07:09 2026 +0200 mm/hugetlb: fix use-after-free in hugetlb_mfill_atomic_pte() commit d8a9cd7fd2fb01211430c933932da58839b8ca65 upstream. Let's fix another instance where we use a folio after dropping the PTL, where someone else could e.g., MADV_DONTNEED it once we drop the PTL, making us trigger a use-after-free on the folio. Link: https://lore.kernel.org/20261015-urgent_fixes-v1-3-42796911043b@kernel.org Fixes: cb6acd01e2e4 ("hugetlbfs: fix races and page leaks during migration") Fixes: 1c9e8def43a3 ("userfaultfd: hugetlbfs: add UFFDIO_COPY support for shared mappings") Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Reported-by: Lorenzo Stoakes (ARM) Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: Muchun Song Reviewed-by: Lance Yang Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Oscar Salvador Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Adam Litke Cc: Mel Gorman Cc: Rik van Riel Cc: Peter Xu Cc: Kiryl Shutsemau Cc: Mike Rapoport Cc: Josef Bacik Cc: Signed-off-by: Greg Kroah-Hartman commit 883eee3a9e66add5dc93455dfca5b0ba5294c2d4 Author: Deepanshu Kartikey Date: Wed Sep 30 14:05:51 2026 +0530 media: imon: fix use-after-free in display_close via dev_dbg commit 118a3590a4080c71c565265b05b3f92e814d7647 upstream. ictx->dev is a raw pointer to the usb_interface's embedded device. On disconnect, usb_disconnect() can drop the last reference on the interface and free it while a userspace fd for /dev/lcd0 is still open. When that fd is later closed, display_close() dereferences the now-freed ictx->dev via dev_dbg(), causing a use-after-free. Remove the dev_dbg() calls that dereference ictx->dev in display_close() and free_imon_context(), rather than taking a reference on the device. Fixes: 21677cfc562a ("V4L/DVB: ir-core: add imon driver") Cc: stable@vger.kernel.org Reported-by: syzbot+9bfac891bdd42eb708fc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9bfac891bdd42eb708fc Link: https://lore.kernel.org/all/20260918054851.26083-1-kartikey406@gmail.com/T/ [v1] Link: https://lore.kernel.org/all/20260928121230.35359-1-kartikey406@gmail.com/T/ [v2] Signed-off-by: Deepanshu Kartikey Signed-off-by: Sean Young Signed-off-by: Greg Kroah-Hartman commit ed8d9b2015afd540f6159ed272702a87f02fbd05 Author: Anuj Bolewar Date: Tue Aug 4 10:18:21 2026 +0530 media: hackrf: fix use-after-free in hackrf_alloc_urbs() error path commit 6802ad4b6b267dda02209b5811edac7825c8a5f6 upstream. hackrf_alloc_urbs() frees the URBs it allocated so far when one allocation fails, but leaves the entries in dev->urb_list[] and dev->urbs_initialized untouched. The caller, hackrf_start_streaming(), then calls hackrf_free_urbs() on the error path, which walks dev->urbs_initialized entries and calls usb_free_urb() a second time on the already-freed URBs, causing a use-after-free (slab-use-after-free Write in usb_free_urb()). Drop the redundant cleanup loop inside hackrf_alloc_urbs() and let hackrf_free_urbs(), which the caller already invokes on error, own the cleanup of the successfully allocated URBs. Reported-by: syzbot+832ce9fa3face1b7d44d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=832ce9fa3face1b7d44d Fixes: 969ec1f6bd92 ("[media] hackrf: HackRF SDR driver") Cc: stable@vger.kernel.org Signed-off-by: Anuj Bolewar Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4c28161c8893bf7a396bda1ba9d8fa6e528c1a21 Author: Pei Xiao Date: Tue Aug 4 14:47:01 2026 +0800 media: cx23885: Fix use-after-free in cx23885_finidev due to race condition commit 75016a992d9b03f5cc6df1414d1da35840d4feeb upstream. In cx23885_v4l2_dev_notify_init, &dev->cx25840_work is bound with cx23885_av_work_handler, and &dev->ir_rx_work and &dev->ir_tx_work are bound with cx23885_ir_rx_work_handler and cx23885_ir_tx_work_handler. cx23885_irq can schedule these works on system_wq when an AV_CORE interrupt is received, and the IR subdevice can also schedule the IR works from its interrupt service routine via the v4l2_device notify callback. If we remove the device, cx23885_finidev makes cleanup and the memory allocated for dev is released by kfree(dev), while the works mentioned above may still be pending or running. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cx23885_irq | schedule_work(&dev->cx25840_work) cx23885_finidev | cx23885_input_fini(dev) | cx23885_ir_fini(dev) | cx23885_shutdown(dev) | free_irq(pci_dev->irq, dev) | pci_disable_device(pci_dev) | cx23885_dev_unregister(dev) | v4l2_device_unregister(v4l2_dev) | kfree(dev) | // dev is freed | | cx23885_av_work_handler | // use dev (use-after-free) Fix it by canceling the works after the IRQ handler that can schedule them has been stopped, and before proceeding with the remaining cleanup in cx23885_finidev. Note that the flush_work() calls in cx23885_input_ir_stop() do not close this race: they only wait for works that are already queued or running at that moment, they do not prevent the IRQ handler, which is still registered at that point, from scheduling the works again afterwards, and they are skipped entirely when dev->sd_ir is NULL. The cancel_work_sync() calls are therefore placed after free_irq(), the only point at which no new work can be scheduled. Fixes: e5514f104d87 ("V4L/DVB: cx23885: Move AV Core irq handling to a work handler") Cc: stable@vger.kernel.org Assisted-by: Codex:deepseek-v4-flash Signed-off-by: Pei Xiao Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0cfc8c1884451c4c3839dfeb1e0e2b008bc00efc Author: Fan Wu Date: Mon Aug 10 05:51:28 2026 +0000 media: au0828: fix use-after-free in bulk_timeout timer on disconnect commit 521030837bee352515d5ea57cc6a29581db3506e upstream. start_urb_transfer() arms dev->bulk_timeout, whose callback au0828_bulk_timeout() queues dev->restart_streaming; that work in turn calls start_urb_transfer() and re-arms the timer. au0828_dvb_unregister() cancels restart_streaming on disconnect but does not sync bulk_timeout. au0828_usb_release() then frees dev with kfree(), so a timer still armed or pending at that point can fire after the free and dereference dev through timer_container_of(). Sync the timer with timer_shutdown_sync() before cancel_work_sync(). The timer callback queues the work, so the timer must be stopped first; the shutdown variant is needed because the work re-arms the timer through start_urb_transfer(). The dvb->frontend == NULL early return guards the register-failure path where the timer was never set up. This bug was found by static analysis. Fixes: 53460c53b761 ("[media] au0828: Add timer to restart TS stream if no data arrives on bulk endpoint") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6506c27da6756c0c7590ef60774ee5d35f6a4100 Author: Chuck Lever Date: Sat Aug 22 21:40:15 2026 -0400 lockd: Fix use-after-free in nlmsvc_retry_blocked commit f5b7634f0f213299a07b461fb10385c8639a4ab8 upstream. nlmsvc_retry_blocked() examines the block at the head of nlm_blocked under nlm_blocked_lock, then releases the lock before calling nlmsvc_grant_blocked() or retry_deferred_block(). The nlm_blocked list reference is all that keeps the block alive across that window. nlmsvc_grant_blocked() does take one of its own, but not until after the lock has been dropped. Unmounting the nfsd filesystem while a lock request is still blocked reaches nlmsvc_traverse_blocks(), which drops the list reference and frees the block along with the nlm_rqst hanging off it. BUG: KASAN: slab-use-after-free in nlm_async_call+0xd6/0x230 Read of size 8 at addr ffff88811b04c808 by task lockd/8377 nlm_async_call+0xd6/0x230 nlmsvc_retry_blocked+0x61c/0x800 lockd+0x144/0x1c0 Freed by task 8392: nlmsvc_release_block+0x231/0x290 nlmsvc_traverse_blocks+0x139/0x1b0 nlm_traverse_files+0x1aa/0xa00 nlmsvc_free_host_resources+0x12/0x60 nlm_shutdown_hosts_net+0x127/0x280 lockd_down+0xd5/0x1c0 Take a reference before releasing nlm_blocked_lock and drop it once the retry has run. Fixes: 0e4ac9d93515 ("lockd: handle fl_grant callbacks") Cc: stable@vger.kernel.org Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/linux-nfs/20260818235808.3458075-1-shuangpeng.kernel@gmail.com/ Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260822-lockd-retry-blocked-uaf-v3-1-761661eae60c@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 1824d884e5076e3fdd83f44256746f2f95d062ec Author: Günther Noack Date: Tue Oct 6 12:58:47 2026 +0200 landlock: Fix superblock use-after-free in release_inode() commit 3e271a27c46fd591d1011c7de5a644a41e2010f1 upstream. Without this fix, release_inode() (task 1) can race with a umount operation in hook_sb_delete() (task 2). The order of operations in which the race occurs is: * task 2: hook_sb_delete() arrives at the end of the function, waiting for landlock_superblock(sb)->inode_refs to become zero. * task 1: release_inode(): does atomic_long_dec_and_test(), decrementing inode_refs to zero. * task 2: gets woken up through some other means, sees that inode_refs is zero and returns. The caller is the unmount operation and proceeds to release the superblock. * task 1: Runs wake_up_var(&landlock_superblock(sb)->inode_refs), *dereferencing the sb_security on the freed-up superblock*. Notably, wake_up_var() does not dereference the pointer passed to it, and only uses it to determine an overapproximated set of tasks to wake up. So while it's potentially possible for an attacker to provide a different value for that pointer, this only results in the wrong set of tasks getting woken up, and in this scenario, no further tasks are actually waiting. Nevertheless, KASAN detects it as a slab-use-after-free read on sb->s_security: BUG: KASAN: slab-use-after-free in release_inode+0x196/0x290 Read of size 8 at addr ffff888103b6c0a8 by task repro/217 release_inode+0x196/0x290 landlock_put_object+0x71/0x90 landlock_free_rules+0x38/0xc0 landlock_put_ruleset+0x47/0x130 fop_ruleset_release+0x33/0x40 __fput+0x305/0x780 Freed by task 54: kfree+0x11c/0x390 process_scheduled_works+0x766/0xe50 worker_thread+0x7bc/0xb20 The fix is to determine &landlock_superblock(inode->i_sb)->inode_refs only once earlier in release_inode(), and later use that precalculated address for the wake_up_var() call, without having to dereference through the superblock. Cc: stable@vger.kernel.org Fixes: cb2c7d1a1776 ("landlock: Support filesystem access-control") Assisted-by: LLM Signed-off-by: Günther Noack Link: https://patch.msgid.link/20261006105847.2541190-1-gnoack@google.com Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 74e01caeea4c16298f28bfb7ea87b0c9835e1777 Author: Yehyeong Lee Date: Sun Oct 18 00:38:05 2026 +0900 nvmet-fc: fix use-after-free in nvmet_fc_ls_create_connection() commit 2c29f8c9b9e598c09fa50aa02200136a107f6b3f upstream. nvmet_fc_ls_create_connection() looks up the association with nvmet_fc_find_target_assoc(), which returns it with a reference held, and drops that reference as soon as the target queue has been allocated. iod->assoc is then dereferenced again by nvmet_fc_makeconnid() while building the connection id. The queue only borrows the pointer and takes no reference of its own. Once the lookup reference is dropped the association is kept alive solely by the reference taken when it was created, so a disconnect LS or a remote port unregister running concurrently can free it before nvmet_fc_makeconnid() reads it: BUG: KASAN: slab-use-after-free in nvmet_fc_handle_ls_rqst_work (drivers/nvme/target/fc.c:193 drivers/nvme/target/fc.c:1841 drivers/nvme/target/fc.c:1995 drivers/nvme/target/fc.c:2021) Read of size 8 at addr ffff888179f1b000 by task kworker/u9:2/1167 Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvmet-wq nvmet_fc_handle_ls_rqst_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) nvmet_fc_handle_ls_rqst_work (drivers/nvme/target/fc.c:193 drivers/nvme/target/fc.c:1841 drivers/nvme/target/fc.c:1995 drivers/nvme/target/fc.c:2021) process_scheduled_works (kernel/workqueue.c:3322 kernel/workqueue.c:3405) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (archkernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Freed by task 1167 on cpu 0 at 405.998150s: kasan_save_track (mm/kasan/common.c:57 mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (include/linux/kasan.h:235 mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) nvmet_fc_handle_ls_rqst_work (drivers/nvme/target/fc.c:1808 drivers/nvme/target/fc.c:1995 drivers/nvme/target/fc.c:2021) process_scheduled_works (kernel/workqueue.c:3322 kernel/workqueue.c:3405) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (archkernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) The buggy address belongs to the object at ffff888179f1b000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 0 bytes inside of freed 2048-byte region [ffff888179f1b000, ffff888179f1b800) Hold the lookup reference until the response has been built, and drop it on the error path as well. Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/linux-nvme/20260731204504.2396434-1-shuangpeng.kernel@gmail.com Fixes: c53432030d86 ("nvme-fabrics: Add target support for FC transport") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit df3008607f2c3343f7ad34001af656a185c123ee Author: James Kim Date: Mon Sep 14 13:23:27 2026 +0900 rapidio: mport_cdev: fix use-after-free in mport_mm_close() commit 0f2cd84858e67cf8e02438bf28243bcdc67aa49a upstream. A use-after-free vulnerability was identified in mport_mm_close() in drivers/rapidio/devices/rio_mport_cdev.c, identical to the pattern previously addressed in dma_req_free(). This is observable from userspace when an application creates an mmap mapping via the RapidIO character device and subsequently unmaps it (or terminates, triggering exit_mmap()). During munmap, mport_mm_close() is invoked and drops the mapping reference via kref_put(). If kref_put() drops the last reference, mport_release_mapping() is called, which frees the underlying rio_mport_mapping structure. The subsequent mutex_unlock() then dereferences map->md to unlock buf_mutex, leading to a use-after-free: mport_mm_close() -> mutex_lock(&map->md->buf_mutex); ... -> kref_put(&map->ref, mport_release_mapping); /* map is freed */ -> mutex_unlock(&map->md->buf_mutex); /* UAF: map used */ Fix this by caching map->md before kref_put() and using the cached pointer for mutex unlocking, ensuring that freed memory is not accessed. Link: https://lore.kernel.org/20260914042327.49798-1-james010kim@gmail.com Fixes: e8de370188d0 ("rapidio: add mport char device driver") Signed-off-by: James Kim Signed-off-by: Andrew Morton Cc: Alexandre Bounine Cc: Dan Carpenter Cc: Greg Kroah-Hartman Cc: Matt Porter Cc: Signed-off-by: Greg Kroah-Hartman commit d88e3e844fad0f6b9fbeb8c8862f9272a7c26a99 Author: Henry Martin Date: Sat Oct 10 11:28:56 2026 +0800 smb: client: fix use-after-free in cifs_ses_add_channel() commit 031278577380e7875d95aed81a2b2bcac39be923 upstream. The error path of cifs_ses_add_channel() calls cifs_put_tcp_session() before cifs_chan_clear_need_reconnect(). The latter reaches cifs_ses_get_chan_index(), which dereferences server->terminate; if the put was the final reference, TCP_Server_Info is already freed and this is a use-after-free. Same put-then-use pattern as the recently fixed sibling in commit 717e0a25036b ("cifs: Fix server use-after-free in cifs_chan_skip_or_disable()"). Move the put last, but do not read chan->server after dropping chan_lock: chan points into ses->chans[], and once chan_count is decremented a concurrent add_channel can reuse the slot and overwrite the pointer, so the put would act on the new channel's server. Cache the pointer under chan_lock, clear the reconnect bit and decrement chan_count while still holding the reference, and release it after the unlock. This issue was discovered by Tencent CodeBuddy Security. Fixes: ee1d21794e55a ("cifs: handle when server stops supporting multichannel") Signed-off-by: Henry Martin Cc: stable@vger.kernel.org Reviewed-by: Namjae Jeon Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 8c8f8029fe07634b626e96472b584b29a33993b8 Author: Diego Oliva Date: Tue Sep 29 10:16:30 2026 +0100 smb: client: fix use-after-free infoleak via the readdir resume name commit 59131dd72f62b198fc9ea1489ad9d3573154f684 upstream. CIFSFindNext() copies the resume name that cifs_save_resume_key() recorded from the last entry of the previous response into its request; psrch_inf->presume_name points into the response buffer that entry came from, and nothing ever clears it. find_cifs_entry() records a new name only from a response with a usable last entry, and cifs_readdir() only from an entry it walks to, so a response that carries no entries and leaves last_entry NULL, because CIFSFindFirst() or CIFSFindNext() rejected LastNameOffset, refreshes neither and presume_name keeps pointing into the previous response. That buffer has already been released: by CIFSFindNext() before it installs the new response, or by find_cifs_entry() when it rewinds the search, which does not drop the name either and can then fail in initiate_cifs_search() before a new response replaces it. The next CIFSFindNext() then copies up to PATH_MAX - 1 bytes of the resume name out of the released buffer into its request and sends them to the server: a use-after-free read that leaks kernel memory to a malicious or compromised server, which can provoke it with a single FindNext response that carries no entries and a LastNameOffset above CIFSMaxBufSize, which is all the existing check rejects. With KASAN enabled, a server that answers a listing that way gives: CIFS: VFS: ignoring corrupt resume name ================================================================== BUG: KASAN: slab-use-after-free in CIFSFindNext+0x8ca/0x14c0 Read of size 4080 at addr ffff88807c823f98 by task ls/83 CPU: 0 UID: 0 PID: 83 Comm: ls Tainted: G B 7.3.0-rc4-00457-gf14572c203d5 #69 PREEMPT(lazy) Tainted: [B]=BAD_PAGE Call Trace: kasan_report+0xdf/0x1a0 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x23/0x60 CIFSFindNext+0x8ca/0x14c0 cifs_readdir+0xf51/0x29c0 iterate_dir+0x1c0/0x570 __x64_sys_getdents64+0x133/0x270 do_syscall_64+0x109/0x5d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 83 on cpu 1 at 13.497119s: cifs_buf_get+0x36/0x90 smb_init+0x4f/0x110 CIFSFindNext+0xf7/0x14c0 cifs_readdir+0xf51/0x29c0 Freed by task 83 on cpu 0 at 13.584018s: cifs_buf_release+0x41/0x80 CIFSFindNext+0xfce/0x14c0 cifs_readdir+0xf51/0x29c0 The buggy address is located 16280 bytes inside of freed 16588-byte region [ffff88807c820000, ffff88807c8240cc) ================================================================== The same memcpy() first reads past the end of that object while it is still live, a slab-out-of-bounds read that the following patches bound; that is the taint the report above carries. SMB1 is not negotiated by default; reaching this code requires an explicit vers=1.0 mount. Clear presume_name and resume_name_len whenever a new response is installed and when the rewind path releases the search buffer, so that the name never outlives the buffer it points into, and reset resume_key with them, since it was taken from the same entry and would otherwise be sent with an empty name. A response without a usable last entry then continues the search with an empty resume name rather than a stale one; CIFSFindNext() skips the copy of a zero-length name so that it never runs on the NULL pointer. The next patch in the series leaves last_entry NULL for a response that carries no entries, and bounds LastNameOffset against the received response rather than against CIFSMaxBufSize. Responses that are given a last entry today then take the path fixed here, so that patch must not be applied without this one. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: b77d753c413e ("[CIFS] Check that last search entry resume key is valid") Cc: stable@vger.kernel.org Assisted-by: Bynario AI Signed-off-by: Diego Oliva Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 0a908446c5edc42905f9136e91bbf4e45d0747b6 Author: Zijing Yin Date: Mon Sep 7 01:54:35 2026 -0700 SUNRPC: fix netns use-after-free in write_gssp() commit e7a8721b7edb54a157623f9e31d71345333b5fb9 upstream. While fuzzing with a customized syzkaller, I hit a refcount warning in xprt_alloc(), reached from a write to /proc/net/rpc/use-gss-proxy: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0xf8/0x120 CPU: 0 PID: 10404 Comm: syz.0.17 Not tainted 7.3.0-rc1-00096-gcfebfd3db73d Call Trace: xprt_alloc+0x83f/0x9d0 xs_setup_xprt+0xaf/0x3c0 xs_setup_local+0x47/0x7f0 xprt_create_transport+0x16c/0x730 rpc_create+0x38e/0x7f0 gssp_rpc_create+0xe2/0x180 set_gssp_clnt+0xba/0x1b0 write_gssp+0x200/0x310 proc_reg_write+0x240/0x330 vfs_write+0x2aa/0x1050 ksys_write+0x12a/0x250 do_syscall_64+0x117/0x750 entry_SYSCALL_64_after_hwframe+0x77/0x7f create_use_gss_proxy_proc_entry() stores the struct net pointer as the proc entry's private data without taking a reference on it, and an open file descriptor does not pin the namespace either, as procfs only pins the proc_dir_entry. write_gssp() reads that pointer back with pde_data() and hands it to set_gssp_clnt(), which reaches xprt_init(): xprt->xprt_net = get_net_track(net, &xprt->ns_tracker, GFP_KERNEL); get_net_track() -> get_net() -> refcount_inc() is unconditional, so rpc_create() assumes its caller holds a reference on args.net. write_gssp() does not. Dropping the last ns.count reference does not make the file go away. __put_net() only queues cleanup_net() on a workqueue, and the remove_proc_entry() that fences off further writes runs from the rpcsec_gss pernet .exit method, that is, from inside cleanup_net(). A write landing between those two points increments a refcount that is already zero. cleanup_net() does not re-read ns.count, so the namespace is freed anyway and the rpc_xprt -- along with the AF_LOCAL socket opened for it -- is left pointing at freed memory. The resurrected count is visible to the rest of that teardown too: with CONFIG_IPV6_MROUTE the same cleanup_net() worker then trips !mr_can_free_table() in ip6mr_free_table(), which tests check_net() on the namespace it is freeing. It reduces to opening /proc/net/rpc/use-gss-proxy inside a new network namespace, calling setns() back to the original one to drop the last reference, and then writing "1" to the still-open descriptor. Take the reference in write_gssp() itself and refuse the write when the namespace is already gone. This is what procfs does for every other /proc/net file: get_proc_net() is maybe_get_net(PDE_NET(PDE(inode))) and seq_open_net() returns -ENXIO when it fails. PDE_NET() cannot be reused here because the parent directory /proc/net/rpc carries no namespace pointer. Adding a .pre_exit to rpcsec_gss_net_ops so the entry is removed earlier would only narrow the window, since pre_exit also runs from cleanup_net(). Live namespaces are unaffected: a write still returns the error from set_gssp_clnt(), a write of "2" still returns -EINVAL, and reads are untouched. Fixes: 030d794bf498 ("SUNRPC: Use gssproxy upcall for server RPCGSS authentication.") Cc: stable@vger.kernel.org Signed-off-by: Zijing Yin Link: https://patch.msgid.link/20260907085435.644076-1-yzjaurora@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 9389b2a21223032ab7d873806d283cc33bc34b01 Author: Andreas Wendleder Date: Tue Oct 13 02:01:24 2026 +0200 wifi: b43: fix use-after-free in b43_bcma_remove() commit c6c8bc355657115664131b38c53c5ddf7d93b072 upstream. b43_one_core_detach() frees the struct b43_wldev it is given the bus device of. b43_bcma_remove() then reads wldev->dev again to free the bus device, which is a read of freed memory. b43_ssb_remove() does not have the problem: it takes a copy of wldev->dev at the start. Do the same here. Fixes: 96838d61102a ("b43: Fix memory leaks in b43_bus_dev_ssb_init and b43_bus_dev_bcma_init") Cc: stable@vger.kernel.org Signed-off-by: Andreas Wendleder Link: https://patch.msgid.link/20261013000124.48605-1-gonsolo@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 005934dfa7008aab63966cdea53391cedc398655 Author: Li RongQing Date: Mon Jun 15 15:01:15 2026 +0800 x86/ioperm: Prevent NULL dereference on theoretical missing IO bitmap [ Upstream commit 2d36d3b451a94899db9c965adde15492ffe6027a ] Outside the IOPL emulation path, the IO bitmap is always expected to be allocated when TIF_IO_BITMAP is set. The paranoid WARN_ON_ONCE() handles the case where the flag and the pointer got out of sync. In this theoretical scenario, which presumes some other bug in the code that triggers the WARN_ON_ONCe(), return early, instead of continuing and dereferencing a NULL pointer. [ mingo: Clarified the changelog. ] Signed-off-by: Li RongQing Signed-off-by: Ingo Molnar Reviewed-by: Sohil Mehta Cc: H. Peter Anvin Link: https://patch.msgid.link/20260615070115.4720-1-lirongqing@baidu.com Signed-off-by: Sasha Levin commit 0f2e9b734d5e74d7ffc3dc13c3d4ef8037906cae Author: Kevin Cheng Date: Fri Oct 30 10:37:13 2026 +0000 KVM: VMX: Synthesize nested EPT violation GVA_IS_VALID/GVA_TRANSLATED bits [ Upstream commit 96b067b59ad9ccede585fcadab27543188353bff ] When injecting an EPT Violation into L2 in response to a fault detected while emulating an L2 GVA access, synthesize the GVA_IS_VALID and GVA_TRANSLATED bits using information provided by the walker, instead of pulling the bits from vmcs02.EXIT_QUALIFICATION. The information in vmcs02.EXIT_QUALIFICATION is valid/correct if and only if the fault being injected into L1 is the direct result of an EPT Violation VM-Exit from L2. E.g. if KVM is emulating an I/O instruction and the memory operand's translation through L1's EPT fails, using vmcs02.EXIT_QUALIFICATION is wrong as the semantics for EXIT_QUALIFICATION would be for an I/O exit, not an EPT Violation exit. Opportunistically clean up the formatting for creating the mask of bits to pull from vmcs02.EXIT_QUALIFICATION. Signed-off-by: Kevin Cheng [sean: use plumbed in @access bits, massage changelog] Link: https://patch.msgid.link/20260522232701.3671446-5-seanjc@google.com Signed-off-by: Sean Christopherson [doebel: no advanced EPT vmexit info here, so the mask keeps only the two GVA bits; set GVA_TRANSLATED via !(access & PFERR_GUEST_PAGE_MASK)] Signed-off-by: Bjoern Doebel Signed-off-by: Sasha Levin commit 8b458190d211a3c8caee32deb9152df09fdbc088 Author: Sean Christopherson Date: Fri Oct 30 10:37:12 2026 +0000 KVM: x86: Tell ->inject_page_fault() whether or a fault came from hardware [ Upstream commit fe0b872d750023eda270cbc01c53ead52b1049d8 ] When injecting a page fault (including nested TDP faults into L1), tell the injection routine whether or not the fault originated in hardware, i.e. if KVM is effectively forwarding a fault it intercept. For nested TDP fault injection, KVM needs to grab PAGE_WALK vs. GUEST_FINAL information from the VMCB/VMCS, _if_ the fault originated in hardware. Note, simply checking whether or not the original exit was due a #NPF or EPT Violation isn't sufficient/correct, as the fault being synthesized for L1 may or may not be the "same" fault that triggered a VM-Exit from L2. E.g. if access to emulated MMIO in L2 hits a !PRESENT fault (EPT Violation or #NPF), e.g. because MMIO caching is disabled or it's the first time the GPA has been accessed by L2, then KVM will enter the emulator. If emulating the MMIO instruction then hits a nested TDP fault, e.g. because L2 was accessing MMIO with a MOVSQ (memory-to-memory move), or because L1 has since unmapped the code stream, then the TDP fault synthesized to L1 will not be the same emulated fault the triggered the VM-Exit. No functional change intended (nothing uses the new param, yet...). Link: https://patch.msgid.link/20260522232701.3671446-3-seanjc@google.com Signed-off-by: Sean Christopherson [doebel: keep this tree's split kvm_requeue_exception()/_e() declarations and EXPORT_SYMBOL_GPL()] Stable-dep-of: 96b067b59ad9 ("KVM: VMX: Synthesize nested EPT violation GVA_IS_VALID/GVA_TRANSLATED bits") Signed-off-by: Bjoern Doebel Signed-off-by: Sasha Levin commit f7a725a5ea4264eddeff4dbb2309941aebed6098 Author: Paolo Bonzini Date: Fri Oct 30 10:37:11 2026 +0000 KVM: x86/mmu: pass PFERR_GUEST_PAGE/FINAL_MASK to kvm_translate_gpa [ Upstream commit bd1c40114b02cf63ba33da8e7df71ed0fc2a3019 ] The XS/XU bit for EPT are only applied to final accesses, and use the U bit from the page walk itself. While strictly speaking not necessary (any value of PFERR_USER_MASK would be the same for page table accesses, because they're reads and writes only), it is clearer and less hackish to only apply MBEC to PFERR_GUEST_FINAL_MASK. Allow kvm-intel.ko to distinguish the two cases. Tested-by: David Riley Signed-off-by: Paolo Bonzini [doebel: load_pdptrs() lives in arch/x86/kvm/regs.c in this tree; keep this tree's mmu_is_nested() in the Hyper-V hunk] Stable-dep-of: 96b067b59ad9 ("KVM: VMX: Synthesize nested EPT violation GVA_IS_VALID/GVA_TRANSLATED bits") Signed-off-by: Bjoern Doebel Signed-off-by: Sasha Levin commit 5ca3d622e6e9f376c39acdd1b8eb28ef9d23c548 Author: Christoph Zwerschke Date: Mon Nov 2 16:32:43 2026 +0100 Revert "Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU" This reverts commit f05baf6e0680d8c10d2fbbc5953848fc3e3db957 which is commit 980084de4d9b25193398d89a1c0430ba3501b683 upstream. With the device ID in the table, the adapter is handed over to btrtl, which in this tree, together with the backport of commit 4a23ce935f74 ("Bluetooth: btrtl: Add the support for RTL8761CUV"), now requires rtl_bt/rtl8761cu_fw.bin. That file is only shipped by linux-firmware since 20251111. On systems with older firmware packages, such as Debian trixie, the adapter no longer initializes. Without the ID entry it binds via the generic Bluetooth class and works on its ROM firmware, as it did before the backport. Mainline keeps the ID entry, so this revert is for 6.12.y only, as agreed in the regression thread. Reported-by: Erik Brangs Closes: https://bugs.debian.org/1149377 Link: https://lore.kernel.org/all/179104011040.2214689.5921682013387867802@eldamar.lan/ Signed-off-by: Christoph Zwerschke Signed-off-by: Sasha Levin commit 448ad785f4f74be55cca8e0c01c0d633fc5f2670 Author: Christoph Zwerschke Date: Mon Nov 2 16:32:42 2026 +0100 Revert "Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU" This reverts commit 32412aff8d11d00672053cb10750869f2de94a1f which is commit 6f0624b4427e38c3bb63a951c536cf8adaee1238 upstream. With the device ID in the table, the adapter is handed over to btrtl, which in this tree, together with the backport of commit 4a23ce935f74 ("Bluetooth: btrtl: Add the support for RTL8761CUV"), now requires rtl_bt/rtl8761cu_fw.bin. That file is only shipped by linux-firmware since 20251111. On systems with older firmware packages, such as Debian trixie, the adapter no longer initializes. Without the ID entry it binds via the generic Bluetooth class and works on its ROM firmware, as it did before the backport. Mainline keeps the ID entry, so this revert is for 6.12.y only, as agreed in the regression thread. Reported-by: Erik Brangs Closes: https://bugs.debian.org/1149377 Link: https://lore.kernel.org/all/179104011040.2214689.5921682013387867802@eldamar.lan/ Signed-off-by: Christoph Zwerschke Signed-off-by: Sasha Levin commit 04858d29d3f0fd6bc1d28894b8d4f49ca7818622 Author: Eric Dumazet Date: Tue Oct 13 13:50:22 2026 +0200 vlan: restore HW VLAN tag insertion with reorder_hdr off [ Upstream commit c2124f80be4ceb6ec566ca3b5fc87f84ea9c36e0 ] Commit 447cbe95ebb9 ("vlan: fix skb_under_panic and races when toggling HW VLAN offload") replaced vlan_passthru_header_ops with vlan_header_ops unconditionally to avoid lockless data races when modifying hard_header_len dynamically under RTNL. Prior to that commit, vlan devices on top of a real device capable of HW VLAN TX offload used vlan_passthru_header_ops, which never inserted the 802.1Q header in the frame. Now, with reorder_hdr=off (as done by Home Assistant OS / NetworkManager when flags are omitted over D-Bus), vlan_dev_hard_header() always pushes an in-band 802.1Q header, and vlan_dev_hard_start_xmit() hands the frame to the real device as is, even if the real device supports HW VLAN TX offload. This is a regression for r8169 users (Realtek RTL8168h), who report transmit queue timeouts (NETDEV WATCHDOG): this NIC stalls when asked to offload checksum and/or TSO for frames carrying an in-band tag. Users of r8152 based USB adapters were affected as well. Reverting the blamed commit, disabling TX checksum offload (which also disables TSO), or setting reorder_hdr=on were all reported to work around the issue. Keep vlan_dev_hard_header() as is: the in-band header keeps the frame layout seen at the vlan device egress (taps, tc, netfilter) unchanged, and is relied upon by stacked vlans (Q-in-Q) and by AF_PACKET SOCK_DGRAM users sending ETH_P_8021Q frames. Instead, when vlan_dev_hard_start_xmit() gets a frame carrying an in-band tag with our protocol and the real device can insert tags, move that tag to skb->vlan_tci with __skb_vlan_pop(), so that the real device inserts it. Frames sent on the wire are unchanged, except that frames shorter than 64 bytes with their tag now get up to 4 bytes of extra padding, as with reorder_hdr=on and before 447cbe95ebb9. skb_reset_mac_header() is needed first, because not all ndo_start_xmit() callers set the mac header (e.g. AF_XDP copy mode, which uses __dev_direct_xmit()). vlan_set_encap_proto() may read the two bytes after the vlan header, so frames whose linear part is shorter than VLAN_ETH_HLEN + 2 are sent unchanged, as before. This also makes sure h_vlan_proto, read earlier in the function, was in the linear part. Shared skbs (e.g. from pktgen) are also sent unchanged, since popping the tag modifies the skb, as are skbs already carrying a hwaccel tag (e.g. from generic XDP redirect), whose tag must not be overwritten, skbs carrying XDP metadata, which the pop would have to move, and CHECKSUM_PARTIAL skbs whose csum_start lies within the first VLAN_ETH_HLEN bytes (only possible with bogus offsets, e.g. from AF_XDP tx metadata), which the pop would leave before skb->data. If popping the header fails (memory allocation failure), the frame is dropped and counted in tx_dropped, rather than handing the real device a frame with an in-band tag. tx_bytes is now sampled before the pop, so the vlan device statistics do not change. This also applies to frames provided by the sender with our tag (AF_PACKET SOCK_RAW, or frames redirected from another reorder_hdr=off vlan): the real device now inserts their tag too. Fixes: 447cbe95ebb9 ("vlan: fix skb_under_panic and races when toggling HW VLAN offload") Reported-by: Jan Čermák Closes: https://lore.kernel.org/netdev/CAPa5EdCj3v17tB-SF2JNecq5Q8s1Pranr-XzAFWNpNTBPgPG7w@mail.gmail.com/ Reported-by: Stefan Agner Reported-by: hitchin999 Closes: https://github.com/home-assistant/operating-system/issues/5019 Tested-by: Jan Čermák Signed-off-by: Eric Dumazet Cc: Heiner Kallweit Link: https://patch.msgid.link/20261013115022.1043024-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f7fba81b00699360f96ed7d9a47b8c801e74c6f9 Author: Kuniyuki Iwashima Date: Wed May 6 03:59:18 2026 +0000 tcp: Fix potential UAF in reqsk_timer_handler(). commit 97c8a3c1f73d828de43a5a88e8a9a143efb2b661 upstream. When TCP socket migration fails at inet_ehash_insert() in reqsk_timer_handler(), we jump to the no_ownership: label and free the new reqsk immediately with __reqsk_free(). Thus, we must stop the new reqsk's timer before jumping to the label, but the timer might be missed since the cited commit, resulting in UAF. As we are in the original reqsk's timer context, we can safely call timer_delete_sync() for the new reqsk. Let's pass false to __inet_csk_reqsk_queue_drop() to stop the new reqsk's timer. Fixes: 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") Reported-by: Damiano Melotti Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260506035954.1563147-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f2eca58cf5de3554f7083c0ae5f78a93e2fe88c3 Author: Namjae Jeon Date: Sat Oct 17 09:44:48 2026 +0900 ksmbd: validate security descriptor offsets before pointer arithmetic commit 3474e1a304fbf9f7c996b24adcd519e031227a90 upstream. parse_sec_desc() constructs SID and DACL pointers by adding untrusted 32-bit offsets to the security descriptor before checking their bounds. The existing checks reject offsets into the descriptor header, but do not reject offsets beyond the descriptor's length. On a 32-bit kernel, a large offset can wrap the pointer before the descriptor. The end-only checks in parse_sid() and parse_dacl() can then accept it, allowing an authenticated SMB2 SET_INFO request to access memory outside the security descriptor and fault the kernel. Check each nonzero offset against acl_len before constructing its pointer. Initialize the optional owner and group SID pointers to NULL so an omitted SID remains absent when parsing the DACL. Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Cc: stable@vger.kernel.org Reported-by: Ratnaker Gautam Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 15ce03c3e390f30ed9542b00aead405aae35bf27 Author: Karl Mehltretter Date: Sat Oct 3 01:29:38 2026 +0200 ksmbd: use u8 for SMB2 oplock level values commit f622fedabbb58c8006ee21373968ae07bf8a9467 upstream. The SMB2 oplock level is an unsigned 8-bit wire value, but smb20_oplock_break_ack() stores it in a plain char. On architectures where plain char is signed, the value 0xff becomes -1 and cannot compare equal to SMB2_OPLOCK_LEVEL_LEASE (0xff). The acknowledgment is consequently rejected with STATUS_INVALID_OPLOCK_PROTOCOL instead of the intended STATUS_INVALID_PARAMETER. Use u8 for the request and response oplock-level variables. This preserves all wire values in their original representation. Fixes: 80a56d4a826c ("ksmbd: align SMB2 oplock break ack handling") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 605e7c1fa01b6cbf15ba48e02ab42015dfb0bc46 Author: DaeMyung Kang Date: Fri Oct 9 00:25:35 2026 +0900 ksmbd: return end of file for reads past a named stream's data commit 626611dc22a3b63b3264a7a797d9dbc530234fcd upstream. A READ on a non-empty named stream at or beyond its end fails with STATUS_INVALID_PARAMETER. ksmbd_vfs_stream_read() returns -EINVAL when the offset is not below the stream length, and smb2_read() maps -EINVAL to that status. smb2_read() already turns a zero-byte read into STATUS_END_OF_FILE, the status a regular file returns at its end, and an empty stream already takes that path. Return 0 instead of -EINVAL so that non-empty streams do the same. Clients that read a stream until end of file otherwise get an error once they have read all of its data. The buffered copychunk path converts a zero-byte source read to -EIO, as it does for a regular file that shrinks during copying. Fixes: 2ae1a6cc4302 ("cifsd: fix potential read overflow in ksmbd_vfs_stream_read()") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 583ede545a14f275a959772b5e1e50fe3e14b861 Author: Abdifatah Suruur Date: Sat Oct 17 13:54:54 2026 +0300 ksmbd: reserve space for the UTF-16 terminator in stream info commit a025c4991a7d83edc4dd339e3ea86d8ff6226eca upstream. smb_strtoUTF16() always writes a terminating zero UTF-16 unit after the converted characters, but get_file_stream_info() budgets only sizeof(struct smb2_file_stream_info) + streamlen * 2 for a stream entry and sizeof(struct smb2_file_stream_info) + 7 * 2 for the trailing "::$DATA" entry. When an entry exactly fills the 448-byte small response buffer, the terminator is written two bytes past the allocation. Reserve one extra UTF-16 unit in both budget checks. The terminator is not part of the wire format, so the reported lengths are unchanged. Cc: stable@vger.kernel.org Signed-off-by: Abdifatah Suruur Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit f5f6a705247314540b780dbf94c319d764b84bb4 Author: DaeMyung Kang Date: Fri Oct 9 00:25:37 2026 +0900 ksmbd: preserve unreadable named streams on open commit 80c816c047f7cae3c99cc75740c1f5d2c4d97b45 upstream. A write-only client can open an existing named stream with FILE_OPEN_IF without permission to read the underlying file. The case-insensitive lookup finds the xattr name, but querying its value length then fails with -EACCES. smb2_set_stream_name_xattr() treats every negative result as a missing stream and replaces the existing xattr with an empty value. A failed xattr list is not proof that the stream is absent either: for example, -ENOMEM can lead to the same empty replacement. Preserve listing errors and create a stream only for -ENOENT or -ENODATA. The latter can occur if the xattr is removed between listing its name and querying its value. Return other lookup errors without changing the stream. A write-only FILE_OPEN now reports access denied instead of name not found. FILE_OVERWRITE_IF and FILE_SUPERSEDE on an unreadable stream also fail instead of appearing to replace it. Stream writes and EOF changes already need to read the old value, so such handles cannot update the stream after opening either. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit cd27b2436d7fd04aaa8166ff3ce0da74cb12fe49 Author: Jan Koester Date: Mon Oct 26 10:25:37 2026 +0100 ksmbd: ignore network devices of other namespaces commit 1f5ce2b8b9164b3fcb93a18fe1e7b451c2fc6eea upstream. With no interface list configured, ksmbd binds every interface that comes up. ksmbd_netdev_event() does not look at the device's namespace, and create_socket() opens the listener in the namespace of the task raising NETDEV_UP. A container with its own address on a bridge brings up its interface and finds port 445 in its namespace already taken by ksmbd, so an SMB server running inside the container fails with "Address already in use". Interfaces are also matched by name only, so a container's eth0 going down would stop the listener on the host's eth0. Only handle netdev events for devices in init_net. Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Cc: stable@vger.kernel.org Signed-off-by: Jan Koester Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 32934b13b1a63c86d2fa68df0bfb28c51ce38879 Author: Cen Zhang (Microsoft) Date: Thu Oct 22 00:12:16 2026 -0400 ksmbd: fix parent dentry lifetime in directory enumeration commit 171df27077fb49b4af2c53ad2cedcd0e39664fe8 upstream. ksmbd_populate_dot_dotdot_entries() builds the ".." entry from the open directory's d_parent and passes that pointer to ksmbd_vfs_fill_dentry_attrs() without taking a reference. That pointer is only valid while the directory stays under this parent. If a concurrent rename moves the directory elsewhere, the old parent loses its last reference; a following rmdir then turns it into a negative dentry with d_inode cleared, and after the RCU grace period the dentry itself is freed. The worker still holds the raw pointer and dereferences d_inode through vfs_getattr() and vfs_getxattr(). A remote SMB client, authenticated or guest, triggers this by listing a directory while that directory is moved under a new parent and the old parent is deleted. It can be done by the client itself with write access or by other concurrent writers, triggering null-ptr-deref and slab-use-after-free on a KASAN build. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: ksmbd-io handle_ksmbd_work RIP: 0010:xattr_permission+0x9d/0x160 Call Trace: vfs_getxattr+0x9c/0x1b0 ksmbd_vfs_getxattr+0x82/0x100 ksmbd_vfs_get_dos_attrib_xattr+0x7f/0x130 ksmbd_vfs_fill_dentry_attrs+0x435/0x650 ksmbd_populate_dot_dotdot_entries+0x25e/0x630 smb2_query_dir+0xcf9/0x1a20 handle_ksmbd_work+0x5f1/0x1c80 process_one_work+0x90b/0x19d0 Fix by using the dentry reference counting APIs: take the parent with dget_parent(), take a matching dget() on ".", and dput() the dentry once ksmbd_vfs_fill_dentry_attrs() has returned or the pattern does not match. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Cc: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft) Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit bd92e03122f33c159b552867a4abc098d405dfed Author: Giorgi Kobakhia Date: Fri Sep 11 17:08:17 2026 -0700 ksmbd: fix overflow in dacloffset bounds check in build_sec_desc() commit eb96e2a0e817807c48dc8387ca6a5249fdeae3a0 upstream. When the large dacl_offset is provided, dacl_offset + sizeof(struct smb_acl) overflows on 32-bit builds and the check is passed, Which makes le16_to_cpu(ppdacl_ptr->size) read out-of-bounds. This only happens for dacl_offset in range [0xFFFFFFF8, 0xFFFFFFFF]. So the oob read is max 8 bytes preceding the allocated ppntsd. unsigned int dacl_offset = le32_to_cpu(ppntsd->dacloffset); int ppdacl_size, ntacl_size = ppntsd_size - dacl_offset; if (!dacl_offset || (dacl_offset + sizeof(struct smb_acl) > ppntsd_size)) goto out; Commit beff0bc9d69b ("ksmbd: fix overflow in dacloffset bounds check") fixes similar checks in other functions. But leaves this one out, because it is only valid for 32-bit builds. Reproduced on 32-bit ARM with KASAN, by a client sending SMB2 SET_INFO(SEC) with dacloffset=0xfffffff8, then QUERY_INFO(SEC) on the same file: BUG: KASAN: slab-out-of-bounds in build_sec_desc (fs/smb/server/smbacl.c:1105) Read of size 2 at addr c2a273fa by task kworker/1:1/35 CPU: 1 UID: 0 PID: 35 Comm: kworker/1:1 Not tainted 7.3.0-rc2+ #5 Workqueue: ksmbd-io handle_ksmbd_work Call trace: kasan_check_range from build_sec_desc (fs/smb/server/smbacl.c:1105) build_sec_desc from smb2_query_info (fs/smb/server/smb2pdu.c:7676) smb2_query_info from handle_ksmbd_work (fs/smb/server/server.c:160) handle_ksmbd_work from process_one_work (kernel/workqueue.c:3401) process_one_work from worker_thread (kernel/workqueue.c:3473) worker_thread from kthread (kernel/kthread.c:436) Add overflow check. Fixes: 8f0541186e9a ("ksmbd: fix heap-based overflow in set_ntacl_dacl()") Cc: stable@vger.kernel.org Assisted-by: LLM claude Tested-by: Xiang Mei Signed-off-by: Giorgi Kobakhia Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 0129f7196a05a974bfb3ac4efd8380be651a51b9 Author: Dairui Zhang Date: Mon Sep 28 13:20:26 2026 +0800 ksmbd: fix OOB read and cross-share confusion in ksmbd_validate_name_reconnect() commit 783a7fc454991544bf92268d8f2413af1a7c7eb8 upstream. ksmbd_validate_name_reconnect() indexes ab_pathname[share->path_sz + 1] without checking that the path is longer than share->path_sz + 1 (d_path() fills the buffer from the end). A durable fp is not bound to its original share, so a client can preserve a file from a short-path share and reconnect it on a long-path share, making strcmp() read past the PATH_MAX buffer - with a long enough share path this oopses the kernel, and on a mapped page it also gives a byte-equality oracle on adjacent heap (the reconnect succeeds exactly when the out-of-bounds string equals the requested name). A same-share variant with the durable fp at the share root reads 1 byte past the buffer (strlen(ab_pathname) == share->path_sz). Check before comparing: the path must be longer than share->path_sz, it must start with share->path, and the next character must be '/'. The share root itself is accepted only for an empty name. Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Reported-by: Dairui Zhang Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Dairui Zhang Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit ea2c572da27b08b4bfd21e9e9d4cf5ba427ed99c Author: Namjae Jeon Date: Sun Oct 4 09:42:27 2026 +0900 ksmbd: fix extended session security negotiation for raw NTLMSSP commit 6868f857514bbfd2ed10b9b566664dc4a8ca039d upstream. ksmbd_build_ntlmssp_challenge_blob() only advertises extended session security when conn->use_spnego is true. As a result, raw NTLMSSP negotiation drops NTLMSSP_NEGOTIATE_EXTENDED_SEC from the challenge even when the client requested it. A Windows capture shows an initial SPNEGO authentication succeeding, followed by a raw NTLMSSP negotiation on the same TCP connection. The raw challenge omits extended session security, and the client does not send an AUTHENTICATE message. The unfinished session then occupies the pending session slot, causing subsequent SESSION_SETUP requests to fail with STATUS_INSUFFICIENT_RESOURCES. Set NTLMSSP_NEGOTIATE_EXTENDED_SEC whenever the client requests it, independently of the SPNEGO wrapper, as required by [MS-NLMP]. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Reported-by: Tea La Forgia Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 04abe2050f64ecf064452cbb7e757688e32de34e Author: DaeMyung Kang Date: Sat Oct 17 12:40:50 2026 +0900 ksmbd: avoid restoring only in-memory EOF after allocation change commit 9455e920aebe41217cabff3f81e90da4c407fdb6 upstream. When SetAllocation requests a size below the allocated block count but above EOF, ksmbd truncates the file to that size and restores only the in-memory i_size. The larger EOF remains on disk and reappears after a reboot. A 3-byte file preallocated to 64 KiB can acquire a 4 KiB EOF after reducing its allocation to 4 KiB. Extending EOF this way is not a reliable way to reclaim the preallocation beyond the old EOF either. Only use this truncate path when the requested allocation is at or below the observed EOF. A truncate to the existing EOF still lets filesystems release preallocated blocks beyond EOF. Remove the in-memory-only i_size restoration. The size check still precedes vfs_truncate() taking the inode lock, so a concurrent shrink can make the truncate extend EOF; that race also existed in the original path. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit daeab6cbbae5860b42b0fc88f0d8582ac73e9b4f Author: Michail Andreas Michalopoulos Date: Mon Oct 19 21:11:16 2026 +0200 ksmbd: accept share config responses from ksmbd-tools before 3.5.3 commit 4f1ce9ffb996a524acf864316479a7806ae500c6 upstream. ksmbd-tools releases before 3.5.2 do not have the payload_sz field in struct ksmbd_share_config_response; the field occupies the last word of their reserved[] area, so the kernel always sees payload_sz == 0 from them. ipc_validate_msg() and share_config_request() used to treat payload_sz == 0 as "legacy userspace" and skip the payload size checks. That case was removed by commit f25e93768fcc ("ksmbd: prevent out-of-bounds reads in share config responses"). With payload_sz == 0: - the IPC$ (pipe) response fails the final message size comparison: these tools always send a one-byte payload, so msg_sz is sizeof(*resp) + 1, but the expected size is now computed as sizeof(*resp) + 0; - every other share fails "payload_sz <= veto_list_sz". In addition, ksmbd-tools before 3.5.3 copy a global "veto files" setting into the IPC$ response, so with such a configuration IPC$ also fails the now unconditional "veto_list_sz > payload_sz" check, even though pipe shares never use a veto list. ksmbd_ipc_share_config_request() then returns NULL and every tree connect fails with STATUS_BAD_NETWORK_NAME, so ksmbd cannot serve any share when used with these ksmbd-tools releases, for example the 3.5.1 package shipped by Ubuntu 24.04. Login still works, which makes the failure look like a configuration problem: CIFS: VFS: BAD_NETWORK_NAME: \\127.0.0.1\IPC$ CIFS: VFS: \\127.0.0.1 failed to connect to IPC (rc=-2) When payload_sz is zero, derive it from the size of the message actually received and store it back in the response, so that the checks in ipc_validate_msg() and the path and veto list parsing in share_config_request() all use the same bound. The response is the kernel's own copy made by handle_response(), and msg_sz has already been checked to be at least sizeof(*resp), so this cannot underflow. All checks added by that commit then apply unchanged, bounded by the bytes that really arrived, and newer ksmbd-tools that fill in payload_sz are unaffected. Also skip the veto list size check for pipe shares: share_config_request() reads neither the path nor the veto list for them. Tested in QEMU with ksmbd-tools 3.5.1 and 3.5.7 and the in-kernel SMB client over loopback, with and without a global "veto files" setting. Fixes: f25e93768fcc ("ksmbd: prevent out-of-bounds reads in share config responses") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Michail Andreas Michalopoulos Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit b7310a8e2236bf716ca6546b6a988f739a69edfd Author: David Heidelberg Date: Mon Sep 21 12:46:23 2026 +0200 backlight: qcom-wled: Fix WLED3 brightness register stride commit e60dc9c05e0f415ef8bc63b3179abdd49830a619 upstream. WLED3 has a 16-bit brightness register pair per string, at 0x40 + 2*n, which is what the pm8941-wled driver wrote to: rc = regmap_bulk_write(wled->regmap, wled->addr + WLED3_CTRL_REG_VAL_BASE + 2 * i, v, 2); The restructuring for WLED3 turned that into WLED3_SINK_REG_BRIGHT(n), defined as 0x40 + n, so the two byte writes for consecutive strings overlap: string 1 overwrites the MSB of string 0 with its own LSB, and with the default three strings only string 1 ends up with the requested value. Use the 2 byte stride. Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: David Heidelberg Reviewed-by: Daniel Thompson (RISCstar) Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-2-bab8c7ef73cb@ixit.cz Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit ef4a0e652e58cb00520ae7081c1e6eaf0da10e55 Author: David Heidelberg Date: Mon Sep 21 12:46:24 2026 +0200 backlight: qcom-wled: Fix unbalanced OVP IRQ enable at probe commit 5eda6b51461932f9fd835ef9e4574650c69c4fe8 upstream. wled_configure_ovp_irq() derives the initial state of the OVP interrupt from the hardware: /* Keep OVP irq disabled until module is enabled */ if (!(val & WLED3_CTRL_REG_MOD_EN_MASK)) disable_irq(wled->ovp_irq); but wled->brightness, which is what the rest of the driver uses to tell whether the module is on, is left at zero. On boards where the bootloader hands the kernel a lit backlight the two disagree. MOD_EN is already set, so the interrupt is left enabled, while wled_update_status() still believes the backlight is off and takes if (!!brightness != !!wled->brightness) rc = wled_module_enable(wled, !!brightness); on the first backlight update. wled_module_enable() then schedules wled_ovp_work(), which calls enable_irq() on the already enabled interrupt: Unbalanced enable for IRQ 176 WARNING: CPU: 0 PID: 160 at kernel/irq/manage.c:774 __enable_irq+0x50/0x80 Hardware name: Xiaomi Pocophone F1 (DT) Workqueue: events wled_ovp_work Call trace: __enable_irq+0x50/0x80 enable_irq+0x48/0xa0 wled_ovp_work+0x18/0x24 process_one_work+0x1d0/0x350 worker_thread+0x13c/0x460 kthread+0x110/0x114 ret_from_fork+0x10/0x20 The bootloader is not the only way to get there. The readback runs after wledN_setup(), and wled4_setup() sets MOD_EN itself on the path where the sink configuration does not already match, as does the tail of wled_auto_string_detection(), which all three setup paths can reach through wled_auto_detection_at_init(). A cold-booted board with a dark panel can therefore reach the same disagreement. Move the MOD_EN readback into wled_probe() and use it to seed wled->brightness, so the driver starts out agreeing with the hardware, and key the OVP interrupt off wled->brightness instead. The first backlight update then only reprograms the brightness registers and leaves both the module and the interrupt alone. The OVP interrupt also stays armed from probe whenever the module is already enabled, rather than being disabled at probe and only enabled once something writes brightness. Note that a backlight update requesting brightness 0 before any non-zero one now really does turn the module off wherever MOD_EN was already set, where before it was silently ignored. wled->brightness is seeded with default-brightness rather than the level the bootloader actually programmed, so the first update can still step the brightness. Reading that level back is version specific and is done in a follow-up, to keep this fix small enough to backport. Assisted-by: LLM Fixes: 8663c188beea ("backlight: qcom-wled: Add auto string detection logic") Cc: stable@vger.kernel.org Signed-off-by: David Heidelberg Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-3-bab8c7ef73cb@ixit.cz Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit a4fdcde0855cf0dc754da02dc23b4af36b64e3f8 Author: David Heidelberg Date: Mon Sep 21 12:46:22 2026 +0200 backlight: qcom-wled: Fix NULL pointer dereference in wled_remove() commit 1dbd46d4b2fb416a8202b1a8e4ef9d0cadbe075f upstream. wled_probe() doesn't set the driver data for the platform device. As a result, platform_get_drvdata() in wled_remove() will return NULL, and the first dereference of it crashes on unbind. Set the platform device driver data in wled_probe(). Cc: stable@vger.kernel.org Fixes: feeab87b3072 ("backlight: qcom-wled: Add support for short circuit handling") Signed-off-by: David Heidelberg Reviewed-by: Daniel Thompson (RISCstar) Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-1-bab8c7ef73cb@ixit.cz Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit ace927a1f5cc818dc8737de09200b08d78109144 Author: Myeonghun Pak Date: Fri Oct 2 23:04:39 2026 -0400 backlight: lm3630a: Cancel delayed work before destroying workqueue commit 2cf184caab8b406fdd9db126ee40d62418237456 upstream. The interrupt handler queues delayed work to read the interrupt status. After free_irq() stops the producer, this work can still be waiting on its timer. destroy_workqueue() cannot drain delayed work that has not yet been queued by its timer, so the timer can outlive both the workqueue and the devm-allocated chip containing the work. Cancel the delayed work synchronously after freeing the IRQ and before destroying the workqueue. This also waits for any running status read to finish before the chip's resources are released. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20261003030439.599330-1-mhun512@gmail.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit cdb9126a79b608b4331dfdc03beb05be8d2563be Author: Kameron Carr Date: Mon Oct 19 16:09:46 2026 -0700 Drivers: hv: vmbus: Bounds check the shared ring buffer indices commit 1d287c17cc5bfd6386fe0770999be410b248d021 upstream. In a CoCo VM the host is untrusted. Since the VMBus ring buffer read and write indices live in shared memory, the guest has to treat both as potentially malicious. hv_ringbuffer_write() copies into the ring at write_index with no bounds checking, so the host can make the guest write packet data at any offset up to 4 GiB past the start of the ring buffer. read_index matters too: the available space derived from both indices is the only bound on how much is copied, and an out-of-range index can make it far larger than the ring. The fix is to validate both indices before use and to use the validated snapshot instead of re-accessing. For invalid indices, hv_ringbuffer_write() logs and returns -EIO. One re-read of write_index is left unchecked in this patch: hv_get_ring_bufferindices() fetches it again for the prev_indices trailer. The value is only returned to the host and is not used as an offset or length for indexing. Since this is not a security issue, it is addressed later in the series. Open-coding the bytes available arithmetic keeps the fix free of prerequisites; a later patch refactors it into a helper function. Fixes: 3e7ee4902fe6 ("Staging: hv: add the Hyper-V virtual bus") Cc: stable@vger.kernel.org # 5.15.x Reviewed-by: Michael Kelley Signed-off-by: Kameron Carr Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit 7bbef48f0b91095be567ea1dda5f9aead1d61a9d Author: Johan Hovold Date: Wed Oct 14 15:31:07 2026 +0200 driver core: fix parent lock use-after-free on USB disconnect commit 0f554506a3fc6a21e714adf38cc3eb0ffe1bb452 upstream. USB interfaces should be probed with their parent USB device lock held and the USB bus therefore sets the need_parent_lock bus flag so that driver core takes the parent lock when needed. Driver core is only guaranteed to hold a reference to the parent device during initial probe however and nothing prevents the device and its parent from being deregistered and the parent potentially freed, for example, while iterating over devices in driver_attach() or bus_rescan_devices_helper(). Since commit 524134d42231 ("USB: don't cancel queued resets when unbinding drivers") USB interfaces hold a reference to their parent USB device, but a parent hub may still go away while probing a USB device (e.g. via the drivers_probe sysfs interface). This can lead to a use-after-free when taking the parent device lock before checking the device->p->dead flag of the device being probed. As only USB interfaces actually need the parent lock, make the need_parent_lock feature even more fine grained by making it a device type rather than bus feature. By requiring that any users also make sure that their devices hold a reference to their parents (like USB does), driver core can lock a device and its parent without first checking if the device has been deregistered. Note that this will also increase parallelism when using asynchronous probe as USB devices connected to the same hub can now be probed in parallel. Fixes: bf74ad5bc417 ("[PATCH] Hold the device's parent's lock during probe and remove") Cc: stable@vger.kernel.org # 2.6.16: 524134d42231: USB: don't cancel queued resets when unbinding drivers Cc: stable@vger.kernel.org # 2.6.16 Cc: Alan Stern Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20261014133109.1392265-2-johan@kernel.org [ Fix mention of bus vs. device type in __device_driver_{un}lock(). - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit e96ec6ceb55bb8e49edc24a4c2443e29fa1e5889 Author: Josef Bacik Date: Tue Oct 27 18:18:19 2026 +0100 driver core: Limit the messages on a refused uevent commit a01c8e5b1dff1ce489e6b339139e744db36b8bb3 upstream. A write to a "uevent" file which is no valid action makes kobject_synth_uevent() print a warning and uevent_store() an error every time. This is generally considered a bad thing so rate limit these messages. Fixes: b0e37c0d8a6a ("net-sysfs: make sure objects belong to container's owner") Cc: stable Signed-off-by: Josef Bacik Link: https://patch.msgid.link/2026102718-conduit-glorious-a8dc@gregkh Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 9bb694ebe1e960f74535611546489b1542519283 Author: Johan Hovold Date: Wed Oct 14 15:31:08 2026 +0200 driver core: take parent lock on deferred probe commit 4059f8986c8f50102a04335cc1da4921dfd262d8 upstream. USB interfaces should be probed with the parent USB device lock held, but this is not honoured when probe is deferred. Add a new bus_probe_device_deferred() helper to handle deferred probe where the parent device lock is not held. Fixes: d1c3414c2a9d ("drivercore: Add driver probe deferral mechanism") Reported-by: Mario Peter Link: https://lore.kernel.org/20261007131514.1260696-1-mario.peter@leica-geosystems.com Cc: stable@vger.kernel.org # 3.4 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20261014133109.1392265-3-johan@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 8b2e96ac5c61e94256a6bf69b928d2c9427809a9 Author: Jamal Hadi Salim Date: Wed Oct 28 13:27:03 2026 +0100 net/sched: act_ife: do not consume the inner header on egress commit 498c631f9c6d74aad4bf43039fa3ce70ae9a8bb7 upstream. The issue: tcf_ife_decode() unconditionally calls eth_type_trans(), which pulls ETH_HLEN. On egress this consumes the inner Ethernet header, and the device receives an skb whose data points to the L3 header: - loopback_xmit() parses L3 data as Ethernet: the "ethertype" comes from the inner IPv4 source address, and the decapsulated packet is dropped or misparsed. - a real NIC transmits the frame without its Ethernet header. (The __skb_pull() BUG this used to trigger in loopback_xmit() when the remaining linear area was short is handled by "loopback: use eth_type_trans_careful()".) The Fix: Parse the inner Ethernet header with eth_type_trans() in both directions, then restore the egress data position and MAC length. On ingress the existing behavior is unchanged. On egress, push the inner Ethernet header back after parsing so the xmit path sees the original frame and later actions see a consistent network header. Conditions to recreate the bug: - egress tc filter on lo: action ife decode pipe; - AF_PACKET SOCK_RAW frame: outer Ethernet with ETH_P_IFE, IFE metadata, inner Ethernet + a valid IPv4 ICMP echo request to a local address; - before this patch, no echo is received; after it, the echo is delivered and answered. Fixes: ef6980b6becb ("introduce IFE action") Cc: stable@vger.kernel.org Signed-off-by: Jamal Hadi Salim [edumazet: reworded changelog, the crash is now handled in loopback] Signed-off-by: Eric Dumazet Acked-by: Alexei Starovoitov Link: https://patch.msgid.link/20261028122703.2093730-6-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5491e70747386a5ee11a2d1c384d8d9c5ee52fee Author: Antonio Quartulli Date: Mon Oct 26 16:31:12 2026 +0100 net/sched: fix packet reordering on requeue commit 14368b9aa1017fee35d2589be7b17e0485c0f93e upstream. dev_requeue_skb() appends requeued skbs to the tail of q->gso_skb, while dequeue_skb() takes them back one at a time from the head. If the driver returns NETDEV_TX_BUSY again for the first of them, it moves behind the skbs still parked there and is sent after them. This showed up as heavy TCP reordering while benchmarking over veth, which returns NETDEV_TX_BUSY whenever its ring is full since commit dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to reduce TX drops"). Requeue the skbs at the head of gso_skb, keeping their order. With 4 TCP streams over a veth pair with a pfifo qdisc, this removes about 1.3M out-of-order segments and 15-37k retransmits per 15 seconds, and raises throughput from about 40 to 76 Gbit/s. Fixes: a53851e2c321 ("net: sched: explicit locking in gso_cpu fallback") Fixes: 9540d977618c ("net: sched: fix skb leak in dev_requeue_skb()") Cc: stable@vger.kernel.org Signed-off-by: Antonio Quartulli Reviewed-by: Eric Dumazet Acked-by: Jesper Dangaard Brouer Link: https://patch.msgid.link/20261026153113.3275494-1-antonio@mandelbit.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8d5f768780e26cb82c389219ae7fdb1cd7255421 Author: owen kwan Date: Sat Oct 24 10:34:15 2026 -0400 net/sched: sch_teql: fix use-after-free on lower qdisc drop commit 782d6bb8f9b8e9d8591181662222bf74cd3ecf79 upstream. The issue: teql_master_xmit() tests the slave's ndo_start_xmit() return value against NETDEV_TX_OK alone. A slave that consumes the skb but returns an error code (rc < NET_XMIT_MASK, e.g. NET_XMIT_DROP) is treated as if the skb were still owned, so the loop restores skb->dev and calls __skb_pull() on it. A VLAN slave returns the result of dev_queue_xmit() from its ndo_start_xmit() (propagated since cbbef5e18307), and when the lower qdisc drops the packet that value is NET_XMIT_DROP after the skb has been freed, giving a use-after-free in teql_master_xmit(). The Fix: test for consumption with dev_xmit_complete(), which accepts NETDEV_TX_OK and every rc < NET_XMIT_MASK, matching other callers that need to distinguish consumed results from busy. Only NETDEV_TX_OK keeps the packet counted in tx_packets/tx_bytes and advances the slave; a consumed result that is neither a success nor NET_XMIT_CN ends the attempt and is charged to tx_dropped, so lower-qdisc drops are no longer reported as good transmits. NET_XMIT_CN is counted like success because it can accompany acceptance of the current packet: pfifo_head_drop drops the old head, enqueues the current skb and returns NET_XMIT_CN. Conditions to recreate the bug: With CONFIG_NET_SCH_TEQL, CONFIG_VLAN_8021Q and CONFIG_DUMMY enabled, add lkrdummy0 (dummy) and lkrvlan0 (VLAN id 37 on lkrdummy0); set a pfifo limit 0 root on lkrdummy0 and a teql0 root on lkrvlan0; bring teql0 up with an address and send one UDP packet to it. The VLAN xmit returns NET_XMIT_DROP from the lower qdisc while holding a freed skb. Fixes: 572a9d7b6fc7 ("net: allow to propagate errors through ->ndo_hard_start_xmit()") Link: https://lore.kernel.org/netdev/179248763469.3135.1739559328868319628@kernel.org/ Link: https://lore.kernel.org/netdev/20261023162821.GN708417@horms.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: owen kwan Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-Y0BY.v2.r0.20261024060625-2@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 165711bea6f2938749031d9e3fb3a5ae7b74fede Author: Jamal Hadi Salim Date: Sat Oct 24 10:34:14 2026 -0400 net/sched: sch_teql: fix slaves_lock IRQ deadlock commit 8b2043279dae25483fe1f2d926e76d41ab95c398 upstream. This is a followup of commit e5b811fe7931 ("net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF") as reported by Sashiko. The issue: master->slaves_lock serializes the master's ring of slave qdiscs. The control paths -- teql_dequeue(), teql_destroy() and teql_qdisc_init() -- take it with spin_lock_bh(), while teql_master_xmit() (the master's ndo_start_xmit) takes it with plain spin_lock(). netpoll_send_skb() wraps the transmit in local_irq_save(), and __netpoll_send_skb() asserts lockdep_assert_irqs_disabled(), so teql_master_xmit() reached from netconsole always acquires slaves_lock with hard IRQs disabled. On PREEMPT_RT spinlock_t is an rtmutex, and Documentation/locking/locktypes.rst names local_irq_disable(); spin_lock(&lock); as a sequence that breaks there because the rtmutex requires a fully preemptible context. This is reachable without any panic: the nbcon printer thread calls netconsole's write_thread() callback on every message. The usual remedy -- folding the IRQ disable into the lock with spin_lock_irqsave() -- is unavailable because the local_irq_save() is netpoll's, not ours. On non-RT the same asymmetry leaves slaves_lock acquirable with hard IRQs disabled on one path and held with hard IRQs enabled on another. That is only exploitable during the panic console flush (netconsole is CON_NBCON_ATOMIC_UNSAFE, so console_is_usable() admits its write_atomic() only from nbcon_atomic_flush_unsafe(), which panic() alone calls), and even then an IRQ-saving lock does not help if the holder oopsed inside the section or was stopped by panic_other_cpus_shutdown(). So the non-RT half is hardening; the PREEMPT_RT half is the bug. The Fix: take slaves_lock as a raw spinlock with IRQs saved at every site. Since skb_queue_purge() takes the queue's spinlock_t and may not nest inside a raw lock on PREEMPT_RT, move its call in teql_destroy() outside the raw section; dat->q is the dying qdisc's own queue and was never serialized by slaves_lock, so the move is behaviour-neutral. The new critical sections contain only RCU pointer assignments and netdev_get_tx_queue(); skb_queue_purge(), netif_wake_queue() and dev_reset_queue() are all outside them. teql_destroy()'s ring walk is O(slaves), two pointer loads and a compare per iteration, so even a large ring is microseconds with IRQs off. Keeping the purge conditional rather than dropping it outright is the conservative call for a backport. Some context: commit 6301f6a34ed8 ("net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants") hardened the parent fix; together they addressed the master->slaves resurrection use-after-free and the xmit-side BH warning but left the reverse direction -- a hard IRQ re-entering xmit while a control path holds the lock -- unaddressed. Conditions to recreate the bug: - CONFIG_PREEMPT_RT, CONFIG_NET_SCH_TEQL, CONFIG_DUMMY and CONFIG_NETCONSOLE. - Run `ip link add dev teqlslave0 type dummy`, bring teqlslave0 up, attach it with `tc qdisc add dev teqlslave0 root teql0`, and bring teql0 up. - Configure a netconsole target on teql0 with explicit local and remote IP addresses and a remote MAC address, then emit a console message. The nbcon printer thread reaches teql_master_xmit() with hard IRQs disabled by netpoll; taking slaves_lock as a spinlock_t is invalid on PREEMPT_RT. No panic or concurrent qdisc change is required. - Reachable by an admin with CAP_NET_ADMIN; teql devices exist only in the initial netns (no per-netns ops), so a user namespace does not suffice. Fixes: e5b811fe7931 ("net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF") Reported-by: Sashiko (gemini) Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260630150922.238714-1-jhs%40mojatatu.com Link: https://lore.kernel.org/netdev/20260630150922.238714-1-jhs@mojatatu.com/ Cc: stable@vger.kernel.org Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-Y0BY.v2.r0.20261024060625-1@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 47ae95cdcb9b1d6770c624ae778828b1d698801a Author: Yuhang Zheng Date: Mon Oct 12 09:07:19 2026 +0800 net/sched: cls_flower: avoid stale mask references after delete commit 58f7989da6e715ce834ac861b7ba6ae9f9bdb098 upstream. Flower releases a mask reference when a filter is removed from the classifier. The filter object can remain alive while dump, walk, or hardware reoffload paths hold a reference to it. Those paths can then dereference f->mask after the mask has already been released. Keep the mask reference until the filter reference count reaches zero. Release the mask synchronously from the final __fl_put() while the caller still holds the tcf_proto reference, and leave the existing RCU work to free the mask. This keeps the mask available to every reader that still holds the filter. The filter is still removed from the classifier indexes immediately. Therefore, a deleted filter can temporarily retain an otherwise empty mask; fl_delete() uses the handle IDR, rather than the mask list, to determine whether the classifier has become empty. Failed mask assignment can leave fnew->mask as an error or borrowed pointer without an owned mask reference. Clear it before the common failure path so the final put cannot release an unowned reference. This fix does not add fields, snapshots, or per-filter memory. Fixes: 92149190067d ("net: sched: flower: set unlocked flag for flower proto ops") Cc: stable@vger.kernel.org Reported-by: Xin Liu Tested-by: Yucheng Lu Signed-off-by: Yuhang Zheng Signed-off-by: Ren Wei Link: https://patch.msgid.link/20261012010720.2248662-2-n05ec@lzu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5d4561a679f69d62c039a1c325937befe7f6e230 Author: Jamal Hadi Salim Date: Sat Oct 10 17:02:49 2026 -0400 net/sched: cls_bpf: accept dev-bound programs on shared blocks commit d305547d1632a242818c5ebb430c85121a2ed434 upstream. The issue: Follow-up to commit 120977e2c096 ("net/sched: cls_bpf: reject dev-bound programs bound to a different device"), which derived the target device from block->q: dev = block->q ? qdisc_dev(block->q) : NULL; tcf_block_create() leaves block->q NULL for shared blocks, so a device-bound program attached through a shared block is rejected with -EINVAL even when it is bound to a netdev that owns the block. The offload path (cls_bpf_offload_cmd()) never consults block->q and drives the per-device callbacks for shared blocks as before. The Fix: Accept the attach on a shared block when bpf_offload_dev_match() matches every netdev bound to the block, and reject an empty block. Every member must match because the offload path broadcasts the program to every callback registered on the block, so an any-member check would re-admit the wrong-device attach on a mixed block. Every dev-bound SCHED_CLS attach is skip_sw, which becomes err_stop and aborts the offload on the first failing callback, so the all-members rule is the offload path's own semantics. Iterate the public block->ports xarray (913b47d3424e, v6.8-rc1) rather than block->owner_list, which is private to cls_api.c. The shared-block rejection reports "Program is not bound to every device in the block", distinct from the non-shared message, because a member can exist without a registered callback (netdevsim registers its block callback ingress-only). Context note: This patch is not an independent fix: it re-exposes the shared-block replay path that commit 120977e2c096 ("net/sched: cls_bpf: reject dev-bound programs bound to a different device") had closed, so patch 1 must be applied first, including in stable. A stable tree taking this patch alone would re-enable shared-block attaches on a kernel whose netdevsim callback is still unchecked. Conditions to recreate the bug: - CONFIG_NETDEVSIM=y, CONFIG_NET_CLS_BPF=y - load a dev-bound SCHED_CLS program for netdevsim device B (prog_ifindex=B), pin it in bpffs - tc qdisc add dev B ingress_block 22 clsact - tc filter add block 22 ingress bpf da object-pinned skip_sw Unfixed, the filter add fails with -EINVAL ("Program is bound to a different device"); fixed, it succeeds. Adding a second, independently backed netdevsim device to the same block makes the attach fail again. Fixes: 120977e2c096 ("net/sched: cls_bpf: reject dev-bound programs bound to a different device") Reported-by: Sashiko (nipa) Link: https://lore.kernel.org/netdev/20260809094418.901607-1-jhs@mojatatu.com/ Link: https://lore.kernel.org/netdev/QDISC-PYC7.v1.20261003103747@mojatatu.com/ Cc: stable@vger.kernel.org Reviewed-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-PYC7.v2.20261010165947-3@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0189f725242087679bc9f1bbf77ad086f56a72c8 Author: Hari Mishal Date: Wed Sep 16 16:23:32 2026 +0200 drm/amd/display: guard dc_sink dereferences in MST mode validation [ Upstream commit 217f64f348c90cba62164e7ff38e0ccf78a5ca09 ] dm_dp_mst_is_port_support_mode() reads aconnector->dc_sink->dsc_caps... for the DSC branch-throughput check, and get_conv_frl_bw()'s HDMI-PCON FRL-bandwidth path reads aconnector->dc_sink->edid_caps.max_frl_rate, both without a NULL check. dc_sink is cleared asynchronously on MST unplug, and both functions run from paths that the driver's own comments document as racing that teardown: the connector probe worker's ->mode_valid callback and a compositor's atomic check, neither of which holds the MST manager lock that the teardown path uses. The former does have an existing dsc_aux NULL check, but dsc_aux isn't reliably cleared in every path that clears dc_sink, so it doesn't cover this. Fail the port-support check and skip the FRL conversion path when the sink is already gone. Fixes: f04d275d94e1 ("drm/amd/display: add mst port output bw check") Fixes: 5c9b8b27a883 ("drm/amd/display: Tie FRL support into amdgpu_dm") Assisted-by: gkh_clanker_t1000 Signed-off-by: Hari Mishal Reviewed-by: Fangzhi Zuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 7c3db8da4e039698ae198c870712428644e965c7) Cc: stable@vger.kernel.org [ sashal: Dropped the conflicting get_conv_frl_bw() hunk because this tree has no HDMI-PCON FRL code, keeping only the dc_sink NULL guard in dm_dp_mst_is_port_support_mode(). ] Signed-off-by: Sasha Levin commit 76d8c791fe238b871824fb44653370a5885fc262 Author: Jiakai Xu Date: Wed Mar 18 09:29:56 2026 +0000 RISC-V: KVM: Fix double-free of sdata in kvm_pmu_clear_snapshot_area() [ Upstream commit 310e2096b082ae0010e7afef666073b966ac2fa7 ] In kvm_riscv_vcpu_pmu_snapshot_set_shmem(), when kvm_vcpu_write_guest() fails, kvpmu->sdata is freed but not set to NULL. This leaves a dangling pointer that will be freed again when kvm_pmu_clear_snapshot_area() is called during vcpu teardown, triggering a KASAN double-free report. First free occurs in kvm_riscv_vcpu_pmu_snapshot_set_shmem(): kvm_riscv_vcpu_pmu_snapshot_set_shmem arch/riscv/kvm/vcpu_pmu.c:443 kvm_sbi_ext_pmu_handler arch/riscv/kvm/vcpu_sbi_pmu.c:74 kvm_riscv_vcpu_sbi_ecall arch/riscv/kvm/vcpu_sbi.c:608 kvm_riscv_vcpu_exit arch/riscv/kvm/vcpu_exit.c:240 kvm_arch_vcpu_ioctl_run arch/riscv/kvm/vcpu.c:1008 kvm_vcpu_ioctl virt/kvm/kvm_main.c:4476 Second free (double-free) occurs in kvm_pmu_clear_snapshot_area(): kvm_pmu_clear_snapshot_area arch/riscv/kvm/vcpu_pmu.c:403 [inline] kvm_riscv_vcpu_pmu_deinit.part arch/riscv/kvm/vcpu_pmu.c:905 kvm_riscv_vcpu_pmu_deinit arch/riscv/kvm/vcpu_pmu.c:893 kvm_arch_vcpu_destroy arch/riscv/kvm/vcpu.c:199 kvm_vcpu_destroy virt/kvm/kvm_main.c:469 [inline] kvm_destroy_vcpus virt/kvm/kvm_main.c:489 kvm_arch_destroy_vm arch/riscv/kvm/vm.c:54 kvm_destroy_vm virt/kvm/kvm_main.c:1301 [inline] kvm_put_kvm virt/kvm/kvm_main.c:1338 kvm_vm_release virt/kvm/kvm_main.c:1361 Fix it by setting kvpmu->sdata to NULL after kfree() in kvm_riscv_vcpu_pmu_snapshot_set_shmem(), so that the subsequent kfree(NULL) in kvm_pmu_clear_snapshot_area() becomes a safe no-op. This bug was found by fuzzing the KVM RISC-V PMU interface. Fixes: c2f41ddbcdd756 ("RISC-V: KVM: Implement SBI PMU Snapshot feature") Signed-off-by: Jiakai Xu Signed-off-by: Jiakai Xu Reviewed-by: Nutty Liu Reviewed-by: Andrew Jones Link: https://lore.kernel.org/r/20260318092956.708246-1-xujiakai2025@iscas.ac.cn Signed-off-by: Anup Patel [ sashal: Kept the local SBI_ERR_FAILURE error code in the context line, since upstream has SBI_ERR_INVALID_ADDRESS there, and added the same kvpmu->sdata = NULL; line. ] Signed-off-by: Sasha Levin commit bda58943c9f0d66e35ace20e8ec42ae548e3f1c3 Author: Timur Kristóf Date: Tue Oct 6 23:16:07 2026 +0200 drm/amdgpu/uvd3.1: Fix checking whether UVD firmware keyselect was already set [ Upstream commit 800ea86e83e137395eba54103e5c459c2bc9965f ] The PASS_MASK is for a different register not for UVD_FW_START. It was a mistake to check this flag. It should be enough to check that the register is non-zero. Fixes: 889a2cfd889c ("drm/amdgpu/uvd3.1: Don't validate the firmware when already validated") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20261006211607.75407-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 9dee462c83259ca769aa1bf82228adee9831685c) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 693f16f5c980ab10ccaccd5bf5a9ada828bb0eeb Author: Donggeun Yoo Date: Mon Sep 14 14:34:43 2026 +0900 tracing: Fix NULL dereference when copying keys for a field variable [ Upstream commit a0777b9e53157f1f6848a0fd0650f5465391ea81 ] In event_hist_trigger_parse() where it needs to create actions like "onmatch", it calls: event_hist_trigger_parse() { create_actions() { action_create() { trace_action_create() { trace_action_create_field_var() { create_field_var_hist() Where create_field_var_hist() does a loop on the hist_data representing the keys. The issue is, if the keys uses one of the pseudo field types (like common_cpu), the hist_data field element will have NULL for its field member causing a NULL pointer dereference when accessing the key_field->field->name. # echo 'hist:keys=common_cpu:ts0=common_timestamp.usecs' > \ events/sched/sched_waking/trigger # echo 'my_synth u64 lat; int prio' > synthetic_events # echo 'hist:keys=common_cpu:wakeup_lat=common_timestamp.usecs-$ts0:\ onmatch(sched.sched_waking).my_synth($wakeup_lat,prio)' > \ events/sched/sched_switch/trigger KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:create_field_var_hist+0x771/0x1380 Call Trace: trace_action_create_field_var+0x360/0x600 trace_action_create+0x393/0xe80 event_hist_trigger_parse+0x3e47/0x69e0 trigger_process_regex+0x1a6/0x250 event_trigger_write+0xce/0x160 Instead of accessing it directly, use the proper handler expr_field_str() to get the name. The three previous patches are prerequisites: without them a .buckets key and a common_stacktrace key each render into a command that cannot be parsed back. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260914053443.981201-5-donggeunyoo.kernel@gmail.com Fixes: 02205a6752f2 ("tracing: Add support for 'field variables'") Signed-off-by: Donggeun Yoo Assisted-by: Claude:claude-fable-5 Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 5c19263d8ed82bafe3947ad01c1730dc0bd51130 Author: Pengpeng Hou Date: Thu Jun 11 13:59:45 2026 +0800 tracing: Bound histogram expression strings with seq_buf [ Upstream commit 935601a4276f28105498609f7f98aa66e86e9c96 ] expr_str() allocates a fixed MAX_FILTER_STR_VAL buffer and then builds expression names with a series of raw strcat() appends. Nested operands, constants, field flags, and generated field names can push the rendered string past that fixed limit before the name is attached to the hist field. Build expression strings with seq_buf and return -E2BIG when the rendered name would exceed MAX_FILTER_STR_VAL. This keeps the existing tracing-side limit while replacing the raw append logic with bounded construction. Link: https://patch.msgid.link/20260611055945.22348-4-pengpeng@iscas.ac.cn Signed-off-by: Pengpeng Hou Signed-off-by: Steven Rostedt Stable-dep-of: a0777b9e5315 ("tracing: Fix NULL dereference when copying keys for a field variable") Signed-off-by: Sasha Levin commit 22bf8f94de9e496b89ffbbe0ec2e6fcc0f1044fa Author: Pengpeng Hou Date: Thu Jun 11 13:59:44 2026 +0800 tracing: Return ERR_PTR() from expr_str() [ Upstream commit a5ca27e8ff1c10e949af7cfe474d6d1a08fb5601 ] expr_str() currently reports all failure cases as NULL, so callers cannot distinguish invalid recursion depth from allocation failure or later string construction errors. Return ERR_PTR()-encoded errors from expr_str() and make parse_unary() and parse_expr() propagate them. Clear expr->name before destroying the hist field so the error pointer is not freed as a string. Link: https://patch.msgid.link/20260611055945.22348-3-pengpeng@iscas.ac.cn Signed-off-by: Pengpeng Hou Signed-off-by: Steven Rostedt Stable-dep-of: 935601a4276f ("tracing: Bound histogram expression strings with seq_buf") Signed-off-by: Sasha Levin commit 5c3b15f237f8b2e39da2314ae6b1d7cf83734750 Author: Pengpeng Hou Date: Thu Jun 11 13:59:43 2026 +0800 tracing: Use __free() for expr_str() buffer [ Upstream commit 988995c0552b6213b6bf16cea57258d4842c1488 ] expr_str() allocates a temporary expression buffer and manually frees it on some error paths. Convert the buffer to __free(kfree) and return it with return_ptr() on success. This keeps ownership handling separate from the later ERR_PTR() conversion and string-bound change. Link: https://patch.msgid.link/20260611055945.22348-2-pengpeng@iscas.ac.cn Signed-off-by: Pengpeng Hou Signed-off-by: Steven Rostedt Stable-dep-of: a0777b9e5315 ("tracing: Fix NULL dereference when copying keys for a field variable") Signed-off-by: Sasha Levin commit 34fa480b6319e0edc216f141b9039cb41033cbaa Author: Tom Zanussi Date: Mon Apr 13 17:35:37 2026 -0500 tracing: Fix fully-qualified variable reference printing in histograms [ Upstream commit 9236eebd138aa2753f7b30fc6cee7b7202841247 ] The syntax for fully-qualified variable references in histograms is subsys.event.$var, which is parsed correctly, but not displayed correctly when printing a histogram spec. The current code puts the $ reference at the beginning of the fully-qualified variable name i.e. $subsys.event.var, which is incorrect. Before: trigger info: hist:keys=next_comm:vals=hitcount:wakeup_lat=common_timestamp.usecs-$sched.sched_wakeup.ts0: ... After: trigger info: hist:keys=next_comm:vals=hitcount:wakeup_lat=common_timestamp.usecs-sched.sched_wakeup.$ts0: ... Link: https://patch.msgid.link/5dee9a86d062a4dd68c2214f3d90ac93811e1951.1776112478.git.zanussi@kernel.org Signed-off-by: Tom Zanussi Signed-off-by: Steven Rostedt (Google) Stable-dep-of: a0777b9e5315 ("tracing: Fix NULL dereference when copying keys for a field variable") Signed-off-by: Sasha Levin commit 8f4456d78795405cc3fef13a6855bae020103d2c Author: Christian Brauner Date: Fri Oct 9 23:51:58 2026 +0200 ntfs3: free replaced mount options after a grace period [ Upstream commit 56c3824de56b5275c02ff6b6aa27ddbacfbb9b25 ] ntfs_fs_reconfigure() replaces the old mount options with new mount options in sbi->options. The old mount options land in fs_context and are freed as soon as remount returns. With a pathwalk held up in ntfs_nls_to_utf16() between loading sbi->options and dereferencing it while a remount replaces them: BUG: KASAN: slab-use-after-free in ntfs_nls_to_utf16+0x7ae/0x7c0 Read of size 8 at addr ff110001044fd448 by task walker/98 Call Trace: ntfs_nls_to_utf16+0x7ae/0x7c0 ntfs_d_hash+0x22b/0x500 link_path_walk+0x11ad/0x1d30 path_lookupat+0x63/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 [...] Allocated by task 95: __kmalloc_node_track_caller_noprof+0x2a2/0x730 kmemdup_noprof+0x25/0x50 ntfs_fill_super+0x1e5/0x4550 [...] Freed by task 97: kfree+0x1db/0x5b0 put_fs_context+0x13c/0x7d0 path_mount+0x54a/0x2130 __x64_sys_mount+0x20c/0x270 That info is needed in rcu lookup in the dentry hash and dentry compary methods for ntfs3 and causes a UAF today. Delay freeing with an rcu grace period. ntfs_nls_to_utf16() reads ->nls and ->ads once under rcu_read_lock() so the hooks pair with the release in ntfs_fs_reconfigure(). That also covers callers outside of rcu pathwalk such as ntfs_lookup(). They don't hold rcu_read_lock() themselves and wouldn't be protected by the grace period otherwise. Remount refuses to change the iocharset so ->nls stays valid after rcu_read_unlock(). Fixes: a3a956c78efa ("fs/ntfs3: Add option "nocase"") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-8-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) [ sashal: Kept the older ntfs_nls_to_utf16() and applied only the RCU read of nls, dropping the ads hunks because that option and its splitting code don't exist in this tree. ] Signed-off-by: Sasha Levin commit 4dd36cf72d2c6c090958c0d7b542fa8211635d2d Author: Christian Brauner Date: Fri Oct 9 23:51:55 2026 +0200 ipc: drop the mqueue mount with kern_unmount() on setup failure [ Upstream commit f0e48172a59e517e613b73f73cc35f24fd123aeb ] mq_init_ns() creates the mqueue mount with fc_mount_longterm(), so its ->mnt_ns is MNT_NS_INTERNAL. When setting up the mqueue or ipc sysctls or msg_init_ns() fails afterwards, create_ipc_ns() drops it with a plain mntput(). With ->mnt_ns set that takes the fast path of mntput_no_expire(). The count drops to zero and nothing ever kills the mount, so the mount and the mqueue superblock are leaked. Commit dc55e35f9e81 ("ipc: Store mqueue sysctls in the ipc namespace") added the first failure path after mq_init_ns() and never dropped the mount. Commit 7229d74e5e8c ("ipc: create_ipc_ns: drop mqueue mount on sysctl setup failure") tried to fix that with a mntput() but that doesn't help for a long-term mount. Use kern_unmount(). free_ipc() open-codes the same thing for a namespace that made it. Fixes: dc55e35f9e81 ("ipc: Store mqueue sysctls in the ipc namespace") Fixes: 7229d74e5e8c ("ipc: create_ipc_ns: drop mqueue mount on sysctl setup failure") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-5-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 9d97118d973cccf1e5ce80661ed4620a3ef9456d Author: Vlad Kulikov Date: Tue Oct 21 21:13:39 2025 +0300 ipc: create_ipc_ns: drop mqueue mount on sysctl setup failure [ Upstream commit 7229d74e5e8c1f140529d405c88d4493e37ce4e3 ] If setup_mq_sysctls(ns) fails after mq_init_ns(ns) succeeds, the error path skipped releasing the internal kernel mqueue mount kept in ns->mq_mnt. That leaves the vfsmount/superblock referenced until final namespace teardown, i.e. a resource leak on this rare failure edge. Unwind it by calling mntput(ns->mq_mnt) before dropping user_ns and freeing the IPC namespace. This mirrors the normal ordering used in free_ipc_ns(). Link: https://lkml.kernel.org/r/20251021181341.670297-1-vlad_kulikov_c@pm.me Signed-off-by: Vlad Kulikov Reviewed-by: Jan Kara Cc: Aleksa Sarai Cc: Christian Brauner Cc: David Hildenbrand Cc: Ma Wupeng Signed-off-by: Andrew Morton Stable-dep-of: f0e48172a59e ("ipc: drop the mqueue mount with kern_unmount() on setup failure") Signed-off-by: Sasha Levin commit fe48b4c48d4131192a10bc6ea526a8a36b345501 Author: Dibin Moolakadan Subrahmanian Date: Tue Sep 22 19:05:38 2026 +0530 drm/i915/dmc: Add sanity check for DMC load address [ Upstream commit 7dedc5bb11f95e96fe80757c924d8d9aa7327759 ] For DMC firmware header version 3, the firmware load address is stored in dmc_info->start_mmioaddr and later used by dmc_load_program(). Unlike the MMIO address table, the firmware load address is not validated. Add a sanity check to ensure it is within the valid range. BSpec: 69671, 68378 Fixes: 3d5928a168a9 ("drm/i915/xelpd: Pipe A DMC plugging") Cc: stable@vger.kernel.org Assisted-by: Claude-Code:Sonnet-5 Signed-off-by: Dibin Moolakadan Subrahmanian Reviewed-by: Mitul Golani Signed-off-by: Ankit Nautiyal Link: https://patch.msgid.link/20260922133535.3180973-6-dibin.moolakadan.subrahmanian@intel.com (cherry picked from commit 5e47ee5c76ca9becde8df4ad5202845b7ffcbc4c) Signed-off-by: Joonas Lahtinen [ sashal: Changed drm_err(display->drm, ...) to drm_err(&i915->drm, ...) because parse_dmc_fw_header() here has no display variable and uses i915. ] Signed-off-by: Sasha Levin commit 14d3b79f05d13b2d772f9c532129cd4896505c44 Author: Bihaan Sen Date: Fri Sep 25 17:14:38 2026 +0530 Input: xpad - add support for 8BitDo Pro 2 Wired Controller for Xbox [ Upstream commit 41363c27b8509bd4efcba244803edac9ba25d1b5 ] The 8BitDo Pro 2 Wired Controller for Xbox is already matched by the vendor-wide XPAD_XBOXONE_VENDOR(0x2dc8) entry, but a later hardware revision reports product ID 0x201e, which has no entry in the xpad_device table. The device therefore binds and functions but is exposed to userspace as "Generic X-Box pad". Add the VID/PID pair so the controller is named correctly, and set MAP_SHARE_BUTTON to expose the share button as KEY_RECORD. Signed-off-by: Bihaan Sen Link: https://patch.msgid.link/20260925114459.110253-1-stevewholikesthings@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov [ sashal: Dropped the missing 8BitDo Ultimate 3-mode (0x200f) context line from the hunk, so the single new 0x201e device entry is added after the 0x2000 entry. ] Signed-off-by: Sasha Levin commit aec1d35d76ad883bae83c24707010115f38d02ac Author: Weiming Shi Date: Fri Oct 2 02:23:26 2026 +0800 net: team: free skb when broadcast has no txable port [ Upstream commit 489114c9ecae44e523361a4b3e610ee5ebd9189c ] bc_transmit() sends the original skb through the last txable port. When no port is txable, it returns false without consuming the skb, but team_xmit() still returns NETDEV_TX_OK. AF_PACKET sends then retain the skb and its socket write-memory charge. A TX-enabled, link-down port keeps the broadcast transmit op installed. Carrier can stay up through a second link-up, TX-disabled port or be forced on by userspace. Free the original skb on the no-port path while leaving the existing drop accounting intact. Discovered by Sashiko during review of previous commit. Cc: stable@vger.kernel.org Fixes: 5fc889911a99 ("team: add broadcast mode") Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20261001182326.572045-3-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a5f43540e14589b53f80306d25c043c0abdcbca0 Author: Alexey Charkov Date: Wed Sep 30 20:13:03 2026 +0400 regulator: of: fill in supply names in of_regulator_bulk_get_all() [ Upstream commit e2151c29cec73f6cc70abf1c7cbc7b9b202489f5 ] of_regulator_bulk_get_all() returns an array it allocated itself, and fills in only the consumer of each entry. Every other way of getting a bulk array has the supply name set, because the caller provides it, and the core expects it to be there: regulator_bulk_enable() prints it when a supply fails to enable, so a caller that hands such an array to it dereferences uninitialised memory on that path. Copy each name into the array's own allocation, right behind the entries, so that it shares the array's lifetime and callers still have nothing extra to free. That also retires the fixed 64 byte stack buffer the names were assembled in, which is_supply_name() never bounded the copy against. Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260928-b4-rk3576-reboot-mode-v1-0-65486b03bd41@flipper.net?part=3 Fixes: 27b9ecc7a9ba ("regulator: Add of_regulator_bulk_get_all") Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260930-regulator-get-all-v2-1-ca82070d22f2@flipper.net Signed-off-by: Mark Brown [ sashal: Replaced the kmalloc_array context line with the commit's own kzalloc(size_add(size_mul(...), names_len), ...) allocation, since kmalloc_objs isn't available here. ] Signed-off-by: Sasha Levin commit 6c8013ea84fcc51cf26aa870b61b5388c7196ed5 Author: Christian Brauner Date: Fri Oct 2 15:52:39 2026 +0200 namespace: never expire a locked mount [ Upstream commit f78ddcc872248c7aa1d7e904928441a0be4c6d5d ] Locked mounts are special. They protect the underlying files and directories from being revealed. do_umount() refuses to unmount locked mounts but shrink_submounts() doesn't. A shrinkable mount can become locked once the owner of a user namespace puts it beneath a locked mount with MOVE_MOUNT_BENEATH. The locked property now moves to the mount at the bottom making it possible to unmount the top mount. So umount() of an unlocked ancestor now expires the bottom mount first and the covered directory is revealed: move_mount(c -> x/hidden, MOVE_MOUNT_BENEATH) = 0 the cover after the lock moved: umount2(x/hidden) = 0 the holder of the lock: umount2(x/hidden) = EINVAL the root of the copy, busy: umount2(x) = EBUSY reads x/hidden/secret: "covered-by-root" So leave a locked mount alone as it dies together with its parent. A plain umount() of an unlocked mount with a locked one below it is EBUSY from now on. It's the same for any other locked child. A lazy umount still takes the whole tree. mark_mounts_for_expiry() never sees a locked mount. lock_mnt_tree() leaves a mount on an expiry list alone and nothing else puts a locked one on such a list. Add an assert for this. Fixes: 5ff9d8a65ce8 ("vfs: Lock in place mounts from more privileged users") Fixes: c62a4766937e ("move_mount: transfer MNT_LOCKED") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261002-work-mount-fixes-4-v1-8-dd44b89d44ce@kernel.org Signed-off-by: Christian Brauner (Amutable) [ sashal: Dropped the missing is_mounted() context lines and replaced VFS_WARN_ON_ONCE() with WARN_ON_ONCE(), since the former macro doesn't exist here. ] Signed-off-by: Sasha Levin commit 5fa8b8bfda81945d81096fd2519d54700eeaca88 Author: Theo Andersen Carton Date: Thu Sep 17 21:15:12 2026 +0200 drm/amdgpu: skip the noirq suspend reset for a switcheroo-parked GPU [ Upstream commit eadb85cca111152bd334b861fb53747ab851d13a ] amdgpu_pmops_suspend_noirq() resets the ASIC unconditionally. When the GPU has been parked by vga_switcheroo it has neither power nor a PCIe link, so the reset cannot reach it: pci_set_power_state() reports the device as inaccessible and amdgpu_asic_reset() returns -EINVAL. A failure there aborts the entire noirq suspend phase, and with it the system suspend, so the machine cannot sleep at all while the GPU is switched off. amdgpu_device_prepare(), amdgpu_device_suspend() and amdgpu_device_resume() all bail out early on DRM_SWITCH_POWER_OFF. This callback was added later, for an unrelated reason, and did not inherit the check. nouveau guards every one of its PM callbacks the same way. Bail out the same way here. On a single-GPU system switch_power_state is never DRM_SWITCH_POWER_OFF, so this is a no-op there. Found on a MacBookPro11,5, where the Radeon is powered down through apple-gmux so that the internal panel can be driven by the iGPU instead. Every suspend failed in amdgpu_pmops_suspend_noirq() while the card was off; with this check a full S3 cycle completes. Fixes: 9e051720f9d3 ("drm/amdgpu: Ensure HDA function is suspended before ASIC reset") Signed-off-by: Theo Andersen Carton Signed-off-by: Alex Deucher (cherry picked from commit 539d0558638a6dcc066f1cf592b6b9a52adc8ea4) Cc: stable@vger.kernel.org [ sashal: Adjusted context because the older function lacks the reset-domain lock and int r;, so the switcheroo power-off early return is placed after adev->suspend_complete = true;. ] Signed-off-by: Sasha Levin commit 889d5ff5645bdec47719fe0c0e30d04f8306c167 Author: Alex Deucher Date: Fri Sep 25 13:46:19 2026 -0400 drm/amdgpu/gmc12: properly pass flush_type to gmc_v12_0_flush_vm_hub() [ Upstream commit 0bfb1bfc82e8fa386d4fad1caa5812b6afafa626 ] In gmc_v12_0_flush_gpu_tlb(), flush_type was not properly passed to gmc_v12_0_flush_vm_hub(). This only affected the MMIO path. In most cases the flush would go through MES. Reviewed-by: Mukul Joshi Signed-off-by: Alex Deucher (cherry picked from commit 6498e33f22a12fdc759a0c78bfe0547819277a36) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 4dc43cb2ce9a225cb96ba5dd15c500cc63433d30 Author: Pierre-Eric Pelloux-Prayer Date: Mon Sep 15 14:25:44 2025 +0200 drm/amdgpu: remove gart_window_lock usage from gmc v12 [ Upstream commit c79cf5a7d903a16459846b4296fc3cd988837c54 ] This lock was part of the SDMA workaround originally implemented in gmc_v10_0_flush_gpu_tlb (a70cb2176f7ef6f moved it to amdgpu_gmc_flush_gpu_tlb). This means this lock is useless and be safely dropped. Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Christian König Signed-off-by: Alex Deucher Stable-dep-of: 0bfb1bfc82e8 ("drm/amdgpu/gmc12: properly pass flush_type to gmc_v12_0_flush_vm_hub()") Signed-off-by: Sasha Levin commit 729d8870cdd15044871b9b29a992d722b640fa46 Author: Timur Kristóf Date: Wed Sep 23 14:20:31 2026 +0200 drm/amd/display: Fix fast updates on DCE 6.x [ Upstream commit 88427119e1f039c8cdffd63726c136a986ef519f ] DCE6 should use legacy fast updates, just like all DCE8 - DCN2. Set that flag for DCE 6.0, 6.1 and 6.4 (all DCE6 versions). Technically DCE6 should have been included when the fast update code was refactored, but it just happened to work until now. A recent commit "Attach only plane updates that actually changed" has exposed this issue because with that commit, DC accidentally took the new fast update code path for DCE6 as well, which caused it to boot into a black screen with a flip done timeout. This fix should be backported to all kernel versions that have "Refactor fast update to use new HWSS build sequence", but this patch won't apply cleanly to older kernels due to another refactor in "Remove dc param from check_update". Fixes: 0baae6246307 ("drm/amd/display: Refactor fast update to use new HWSS build sequence") Fixes: 9ec11bb842b6 ("drm/amd/display: Remove dc param from check_update") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923122033.1046651-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 698fda6e360625850413a2d1a90b72ae5f03073d) Cc: stable@vger.kernel.org [ sashal: Set enable_legacy_fast_update in debug_defaults instead of a separate config_defaults/check_config, and dropped the is_apu context line in dce64_construct. ] Signed-off-by: Sasha Levin commit b82f3c1131456537a514595c3991b62652507c9d Author: Christian Brauner Date: Wed Sep 30 15:31:56 2026 +0200 namespace: check a recursive bind mount for mount namespace loops [ Upstream commit c640a01a78e42302879006ed7b7d5a9a943ba815 ] do_loopback() refuses to bind mount the file of a mount namespace that is as old as the caller's or older because a mount namespace that holds a mount of its own file, or of an ancestor's, would cause a cycle. But it only checks the dentry the bind mount starts from. With MS_REC everything below it is copied and do_loopback() passes CL_COPY_MNT_NS_FILE so mount namespace files below the source are copied. That's fine for a source in the caller's own mount namespace. Every mount namespace file in there passed the same check when it was bind-mounted. It isn't fine for a source in another mount namespace. may_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter what mount namespace it lives in so that /proc//ns/ and pidfds can be bind mounted. If we create a bind-mount stack of mount namespaces file descriptors the kernel will copy them irrespective of their ancestoral relationship to the mount namespace in question: 151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw 152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw Mount 152 is a mount of the mount namespace file of mount namespace 4026532293 inside mount namespace 4026532293. That namespace and every mount in it are leaked... All it takes is a process in an older mount namespace that stacks the file and repeating it leaks without limit: after control: Shmem: 380 kB child: mount(/proc/self/fd/6, MS_BIND|MS_REC): ok after cycle: Shmem: 65916 kB do_move_mount() runs check_for_nsfs_mounts() over a detached tree for exactly that reason. Do the same for the copy before it is grafted. Fixes: e149ed2b805f ("take the targets of /proc/*/ns/* symlinks to separate fs") Fixes: ef4144ac2dec ("pidfs: allow bind-mounts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-4-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) [ sashal: Uses lock_mount() with separate parent and mp, so the call is graft_tree(mnt, parent, mp), and adds a forward declaration of check_for_nsfs_mounts() ahead of its use. ] Signed-off-by: Sasha Levin commit 0499b6d1c9d4477d6538b88c30f9d0c1a28b3e75 Author: Mikulas Patocka Date: Wed Sep 30 18:42:20 2026 +0200 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 2a2423bf745a89e989b00f06eceb4ffb50c74624 Author: Paulo Alcantara Date: Mon Sep 28 10:23:00 2026 -0300 smb: client: require stable pages for signed connections [ Upstream commit 53c5c2c1095eb21e214811fec16cd75f89d72ee2 ] When signing, cifs computes the SMB signature over the pagecache folios in place and then hands those same folios to the socket. If a buffered write mutates a folio while a write subrequest is still in flight, the signature no longer matches the data that follows it, the server rejects the write with STATUS_ACCESS_DENIED (-EACCES), and the error is latched in the mapping, so the next fsync()/fallocate() returns -EIO. Mark the mapping for stable writes so netfs_perform_write() waits for writeback to complete before modifying an in-flight folio. This is only needed when the connection is signed. Fixes: 3ee1a1fc3981 ("cifs: Cut over to using netfslib") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Replaced the missing local tcon in cifs_set_ops() with cifs_sb_master_tcon(cifs_sb) when checking ses->server->sign. ] Signed-off-by: Sasha Levin commit a6c781f391d0ccfdbacdf5f5b2e99d4200ffe464 Author: Paulo Alcantara Date: Sat Sep 26 17:15:47 2026 -0300 smb: client: only require read lease for size-extending zero range [ Upstream commit fafc68cccf8a00ed0a1f47c1413a3f16ce4dcdfa ] smb3_zero_range() refuses any FALLOC_FL_ZERO_RANGE that clears FALLOC_FL_KEEP_SIZE with -EOPNOTSUPP whenever the inode is not read caching: /* if file not oplocked can't be sure whether asking to extend size */ rc = -EOPNOTSUPP; if (keep_size == false && !CIFS_CACHE_READ(cifsi)) goto zero_range_exit; The read lease is only needed to trust the cached i_size when deciding whether the range extends the file. When it is not held, the size can instead be fetched from the server, which is authoritative, rather than refusing the request outright: query the server's end of file and take the larger of it and the cached size for the interior-vs-extend decision. The larger of the two is used because the server's end of file reflects another client's growth while the cached size reflects this client's own writes that may not have reached the server yet; using the server size alone would wrongly shrink the file when the range flush above left an extending write unwritten. The query isn't lease-protected either, so its result is only trusted to confirm the range is interior, never to justify extending: if it still shows the range going past EOF, refuse with -EOPNOTSUPP instead of calling SMB2_set_eof(), which could otherwise shrink the file if another client extended it further between the query and the call. For the same reason, take the larger of the already-computed i_size and a fresh i_size_read(inode) right before that call, instead of relying on either alone: the local variable carries the query's result, which is never written back to the inode, while a concurrent write on this client can still extend the cached i_size during the flush, the query, or the zero-data round trip that happen in between. Rejecting interior ranges is observed as generic/363 randomly failing against Windows Server with do_zero_range: fallocate: Operation not supported fsx issues an interior, non-KEEP_SIZE zero range while the inode is transiently not read caching: the server had just downgraded the file's lease from RWH to RH after breaking the write caching, and the ensuing handle reopen/revalidation left CIFS_CACHE_READ momentarily clear. The range sat well within the server's end of file, so no extend was needed, yet the range was refused and fsx aborted. This keeps the emulation correct even when a genuine lease break from another client leaves the inode without read caching -- the case the -EOPNOTSUPP guard turned into a hard failure. The extra round trip only happens on the no-lease path; the common cached case is unchanged. Fixes: 30175628bf7f ("[SMB3] Enable fallocate -z support for SMB3 mounts") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: added the missing remote_i_size local declaration in smb3_zero_range() so the new code compiles; the rest of the patch is unchanged. ] Signed-off-by: Sasha Levin commit 6e7a06704457594f06e4ea58a17a5d162ccc735c Author: Paulo Alcantara Date: Sat Sep 26 13:04:44 2026 -0300 smb: client: drain and invalidate before server-side copy/clone [ Upstream commit c9b1194e8ec99d95db25db45edd2fbf690f043ab ] cifs_file_copychunk_range() and the clone (FICLONE) path of cifs_remap_file_range() do not serialise the destination page cache against the server-side copy the way the other server-side range operations (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range() and smb3_insert_range()) do. cifs_file_copychunk_range() invalidates the destination range with filemap_invalidate_inode(), which takes and drops the mapping's invalidate_lock internally, so the lock is no longer held when the copychunk ioctl is issued. It also never drains in-flight netfs I/O on the target. The clone path never takes the invalidate_lock at all (only i_rwsem), uses a bare truncate_inode_pages_range() and likewise does not drain outstanding I/O. As a result an asynchronous destination writeback can complete after the server-side copy/clone has run and reinstate stale data over the region just written by the server, corrupting the file. This is the same class of corruption as commit d7d2adcd022b ("smb/client: flush dirty data before punching a hole") and has been seen randomly in generic/363 against Windows Server. Fix both paths to follow the established ordering: hold the target mapping's invalidate_lock across the flush and invalidation of the destination and the server ioctl, and call netfs_wait_for_outstanding_io() on the target to drain in-flight writes before the ioctl is issued. Only the target inode's invalidate_lock is required, as the source is merely flushed and not invalidated; i_rwsem (already held via lock_two_nondirectories()) is acquired before the invalidate_lock, matching the VFS lock ordering. Since filemap_invalidate_inode() takes that same lock internally, replace it with its own unmap/flush/invalidate steps instead of calling it, and return early on a zero-length copy to avoid a range underflow. Fixes: 8101d6e112e2 ("cifs: Fix copy offload to flush destination region") Fixes: c54fc3a4f375 ("cifs: Fix flushing, invalidation and file size with FICLONE") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Kept the tree's existing min_t(loff_t, ..., i_size_read()) truncate lines in cifs_remap_file_range() and added only the netfs_wait_for_outstanding_io() call after them. ] Signed-off-by: Sasha Levin commit 1506390a788c45af11008adc91a38dfb5beaf03c Author: Paulo Alcantara Date: Sat Sep 26 12:59:18 2026 -0300 smb: client: flush dirty data before zeroing a range [ Upstream commit 8f8d32c1044f70e46e87550e039a15ff20a4b21c ] smb3_zero_range() emulates FALLOC_FL_ZERO_RANGE by invalidating the page cache over the target range with truncate_pagecache_range() and then issuing FSCTL_SET_ZERO_DATA to the server. Dirty data was only flushed conditionally, when the range reached or extended EOF. For a purely interior zero range that does not reach EOF, no flush happened, so a dirty folio overlapping the range could be written back to the server after the FSCTL and refill the range that was just zeroed with stale data. Fix this by unconditionally flushing and waiting for dirty data in the range before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA, exactly as was done for smb3_punch_hole() in commit d7d2adcd022b ("smb/client: flush dirty data before punching a hole"); the two paths are structurally identical here. This is observed as generic/363 randomly reading stale data where a zeroed range is expected against Windows Server. Fixes: 91d1dfae4649 ("cifs: Fix FALLOC_FL_ZERO_RANGE to preflush buffered part of target region") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Adapted to the branch's i_size_read() size handling instead of netfs_read_sizes(), and dropped the now-unused remote_size and ictx variables after removing the conditional flush. ] Signed-off-by: Sasha Levin commit 6787575545cd8af1da3778d7c1ae43a4398a6b26 Author: Paulo Alcantara Date: Fri Sep 25 19:35:12 2026 -0300 smb: client: flush and commit data before querying allocated ranges [ Upstream commit aa994489bd835547c191827acc460192e147032d ] The mode 0 / FALLOC_FL_KEEP_SIZE fallocate emulation for small interior ranges in smb3_simple_fallocate_range() issues FSCTL_QUERY_ALLOCATED_RANGES and zero-fills any sub-range the server reports as an unallocated hole, to force block allocation without changing file contents. This is unsafe against Windows servers. Per the Win32 documentation, FSCTL_QUERY_ALLOCATED_RANGES only reports ranges that *may* contain nonzero data and is explicitly not coherent with recently written data: "a call to FSCTL_QUERY_ALLOCATED_RANGES [after writing to a network file] would not necessarily return a correct list of allocated regions. To ensure coherency [...] flush the data to the file" fsx (generic/363) reproduces the resulting corruption against Windows Server 2022: a range is written, an uncached read returns the data, yet the next FSCTL_QUERY_ALLOCATED_RANGES on that range reports it as a whole hole, so the emulation overwrites live data with zeroes. A network trace confirmed the WRITE, the READ returning data and the query returning an empty range list within microseconds. Samba does not exhibit this; its query is coherent with the written data. Write back the dirty pages, drain any outstanding I/O and issue an SMB2 FLUSH to force the server to commit the data before querying the allocated ranges, so the query reflects the data actually present. With this, generic/363 passes against both Windows Server 2022 and Samba over 100000 fsx operations. Fixes: 966a3cb7c7db ("cifs: improve fallocate emulation") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Added a local inode variable and moved the lock release into a single out_unlock label, since buf is allocated after the query here and no out: label is needed. ] Signed-off-by: Sasha Levin commit eba974d6c850e77db87f6f9ae343164227dffefc Author: Paulo Alcantara Date: Sun Sep 20 16:38:03 2026 -0300 smb: client: discard post-EOF pagecache when extending a file via clone range [ Upstream commit 4721587f96cb8de8164f3fd203093a0875560999 ] cifs_remap_file_range() discarded the pagecache only for the folios overlapping the destination region, so when a clone extends the file the folio straddling the old EOF - which may hold data dirtied past EOF through an mmap - was never dropped and became visible as file content once the file was extended. Start the discard at the smaller of fstart and the old EOF. i_size is still old here, so nothing past the old EOF is flushed to the server. Fixes: c54fc3a4f375 ("cifs: Fix flushing, invalidation and file size with FICLONE") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Replaced upstream's local i_size snapshot with an inline i_size_read(target_inode) call, using min_t(loff_t, ...) for the type check, since this tree lacks that variable. ] Signed-off-by: Sasha Levin commit 4703fd059ff4ef27b7f614178cdd1d7110d7037a Author: Paulo Alcantara Date: Sun Sep 20 15:05:44 2026 -0300 smb: client: clear post-EOF pagecache when extending a file via truncate [ Upstream commit 35024595f641e790e24609f3f046e1667e3b280a ] cifs_setsize() relied on pagecache_isize_extended() to zero the tail of the folio straddling the old EOF, but that helper is a no-op on CIFS (i_blkbits is 14), so data dirtied past EOF through an mmap survived and became visible once the file was extended. Use netfs_clear_stale_post_isize() instead, called after i_size is updated since cifs_setsize() callers hold i_rwsem exclusively for the whole resize. truncate_pagecache() is then called as in truncate_setsize(): a no-op on extend, and it drops the pagecache beyond the new EOF on shrink. Also thread old_size as an explicit parameter through cifs_setsize() and cifs_resize_file_locked(), captured by each caller before its own resize RPC. This closes a race where a concurrent stat() could adopt the RPC's already-updated server size via is_size_safe_to_change() before cifs_setsize() reads old_size itself. Closes: https://sashiko.dev/#/patchset/20260921230755.1133425-1-pc%40manguebit.org Fixes: c510edb9734a ("cifs: call pagecache_isize_extended() in cifs_setsize() when extending") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Adapted to older CIFS code: dropped the missing cifs_do_truncate() hunk, kept extern prototypes and older cifs_setsize() body, and used existing old_eof in smb3_simple_falloc(). ] Signed-off-by: Sasha Levin commit 5a219231b178aad7329cfed9914540298b4026df Author: Yu-Hsiang Tseng Date: Wed Sep 23 22:13:44 2026 +0800 ALSA: hda/realtek: Fix silent speaker on Higole F9B [ Upstream commit 2a8ee6897302ca12ff39e8eb180503956797c60c ] The Higole F9B is an Alder Lake-N mini PC with a 7" touchscreen and an ALC269VC codec (subsystem ID 0x10ec111e). Its DMI strings are all "Default string", so the SSID is the only way to identify it. The internal speaker is silent out of the box. The generic parser assigns DAC 0x03 to the speaker pin 0x14 and DAC 0x02 to the headphone pin 0x15, but the speaker only reproduces what DAC 0x02 plays, whatever its connection selection says. Checked one path at a time, only the gain of DAC 0x02 and the mute of pin 0x14 change what comes out of the speaker. User space only knows the path it was told the speaker uses, so selecting the speaker turns the path that actually reaches it all the way down. Route both 0x14 and 0x15 through mixer 0x0c (DAC 0x02), which is what ALC290_FIXUP_MONO_SPEAKERS already does. Tested on the device: the speaker plays. Cc: Assisted-by: LLM Signed-off-by: Yu-Hsiang Tseng Link: https://patch.msgid.link/20260923141344.1543158-1-asas1asas200@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2e9b8c79ae6c1dcf650ea288cf8fc69ee5241dd9 Author: Sean Christopherson Date: Fri Sep 4 10:06:40 2026 -0700 KVM: SVM: Update control fields on #VMEXIT if and only if VMRUN succeeded [ Upstream commit e27fc915c8f575ab5630e27d97465c2077d4b9d1 ] Leave control.erap_ctl and control.clean as-is in the VMCS if VMRUN fails, because as per AMD: there's no explicit architectural guarantee about the behavior in the presence of VMRUN failures. So the best thing to do would be to assume that if VMRUN fails, the actions requested in the control fields may not have been performed. Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260904170642.3291466-3-seanjc@google.com> Signed-off-by: Paolo Bonzini [ sashal: Replaced the svm_is_vmrun_failure() helper with an open-coded exit_code != SVM_EXIT_ERR check, moved vmcb_mark_all_clean() into that block, and dropped the ERAPS hunk since the feature is absent. ] Signed-off-by: Sasha Levin commit bfe48e689ba011d3d6cf8adcca03072aa0430133 Author: Sean Christopherson Date: Fri Sep 4 10:06:39 2026 -0700 KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN [ Upstream commit 60d93c27859fb3ec5b5a689e24de303f166477d0 ] Don't reset the VMCB's TLB control back to "do nothing" on a failed VMRUN, as empirical testing shows that the CPU performs the requested TLB flush if and only if VMRUN is successful, i.e. clearing TLB control on a failed VMRUN effectively drops a TLB flush. Explicitly track the need to flush all ASIDs on a per-CPU basis, as the ASID reuse condition is tied to the pCPU, not to the vCPU. As a bonus, this also obviates the need to avoid clobbering FLUSH_ALL_ASID with TLB_CONTROL_FLUSH_ASID, e.g. in svm_flush_tlb_asid(). Deliberately don't bother saving/restoring the "old" tlb_ctl on failure, in quotes because it's not exactly the old tlb_ctl, it's the tlb_ctl from after pre_svm_run(), but before updating tlb_ctl for flush_all_asids. If VMRUN fails and TLB_CONTROL_FLUSH_ALL_ASID is forced, then the next successful run of the VMCB *may* unnecessarily flush all ASIDs, which strictly speaking could result in noisy neighbor issues. However, the fact that new_asid() is already guest-triggerable, because of KVM's flawed behavior of clearing the ASID on emulated INIT, means that a guest can already trigger a flush of all ASIDs at roughly the same rate. And once KVM stops clobbering the ASID on emulated INIT, *or* assigns a static ASID to each vCPU, this flaw goes away. Fixes: 38e5e92fe8c0 ("KVM: SVM: Implement Flush-By-Asid feature") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Suggested-by: Yosry Ahmed Cc: Tom Lendacky Cc: Jim Mattson Signed-off-by: Sean Christopherson Message-ID: <20260904170642.3291466-2-seanjc@google.com> Signed-off-by: Paolo Bonzini [ sashal: Replaced the missing svm_is_vmrun_failure() helper with an open-coded exit_code != SVM_EXIT_ERR check and dropped the ERAPS-only context around the post-VMRUN tlb_ctl reset. ] Signed-off-by: Sasha Levin commit 6ba3d758cd40888908f96d68d69322dad65a871e Author: Hao Ge Date: Wed Sep 23 14:37:59 2026 +0800 netfs: Fix missing alloc tagging of direct mempool allocations [ Upstream commit b78b728e21c32ec4c330b299f657fb1eb02dffc2 ] Commit 1d78d56c43ef ("netfs: Fix folio_queue ENOMEM in writeback by adding a mempool") added a mempool for the folio_queues and made the request, subrequest and folio_queue allocations distinguish between writeback and everything else. Writeback is part of memory reclaim and must not fail due to ENOMEM, so it allocates under GFP_NOFS through mempool_alloc(), which may dip into the pool's reserve and, if that runs empty, wait for elements to be returned. The GFP_KERNEL paths, which can return -ENOMEM to their callers, invoke the pool's ->alloc() callback directly instead. The direct call, however, skips the alloc_hooks() wrapper that the mempool_alloc() macro provides. The pool callbacks, mempool_alloc_slab() and mempool_kmalloc(), call kmem_cache_alloc_noprof() and kmalloc_noprof() and rely on current->alloc_tag having been set by the caller. With CONFIG_MEM_ALLOC_PROFILING_DEBUG=y this leads to current->alloc_tag not set WARNING: ./include/linux/alloc_tag.h:161 at __alloc_tagging_slab_alloc_hook alloc_tag was not set WARNING: ./include/linux/alloc_tag.h:166 at __alloc_tagging_slab_free_hook at allocation and free time respectively, as reported when reading files on a CIFS mount. The allocations are also missing from /proc/allocinfo. Wrap the direct ->alloc() invocations in alloc_hooks() with a new mempool_alloc_noreserve() helper in include/linux/mempool.h, next to the other alloc_hooks()-wrapped macros such as mempool_alloc(). The GFP_KERNEL paths keep their failable allocation semantics, they just get tagged now. Fixes: 1d78d56c43ef ("netfs: Fix folio_queue ENOMEM in writeback by adding a mempool") Reported-by: Erhard Furtner Closes: https://lore.kernel.org/all/0b004319-9ef7-437c-a4dd-174d6a9a83db@mailbox.org/ Tested-by: Erhard Furtner Suggested-by: Suren Baghdasaryan Cc: stable@vger.kernel.org Signed-off-by: Hao Ge Link: https://patch.msgid.link/20260923063759.34667-1-hao.ge@linux.dev Acked-by: Vlastimil Babka (SUSE) Signed-off-by: Christian Brauner (Amutable) [ sashal: Adjusted context for older mempool_t/extern prototypes without the bulk API, and kept the branch's extra rreq->origin condition in netfs_alloc_subrequest() while swapping in mempool_alloc_noreserve(). ] Signed-off-by: Sasha Levin commit 97c9ca40b67eafbe61a253e28cd51dddb7c6bec4 Author: Christian Brauner Date: Wed Sep 23 14:27:57 2026 +0200 fs: don't silently unmount busy mounts [ Upstream commit 6857e209015f95be7a8f19a9cd5dac345b9b9859 ] The propagate_mount_busy() helper exists to decide whether a synchronous can suceed. It does that by looking at the copies of the victims in the mounts its parent propagates to. One of those functions from propagation hell. It skips a copy that has child mounts except for the case of a single child mount covering the copy's root. That algorithm used to be exact. It isn't anymore. Originally only childless copies were unmounted during propagation. And 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.") ended up adding covered mounts to both sides in one go. Along came 99b19d16471e ("mnt: In propgate_umount handle visiting mounts in any order") and that started to unmount more than before: [1]: A copy of a mount is unmounted when each of its children is either its overmount or a copy of the victim itself. In the former case the overmount gets reparented. In the latter case the copy of the victim will end up being unmounted. So propagate_umount() ended up being rewritten without adjusting propagate_mount_busy(). And currently propagate_mount_busy() doesn't look at copies of the victim that have two or more children nor a single child that is not the overmount. So any such copy in [1] is not checked for references. The result is that a synchronous unmount succeeds, pulling out a mount that is still in use. A container can run into this with its own mounts. The host shares a tree with the container and the host has a mount in that tree: mount -t tmpfs none /mnt mount --make-shared /mnt mount -t tmpfs none /mnt/a The container's /mnt is a slave copy of the host mount. The container now takes a detached copy of the tree and mounts that copy beneath its propagated copy of /mnt/a and keeps the file descriptor to the tree open: unshare -m --propagation unchanged mount --make-rslave / fd = open_tree(AT_FDCWD, "/mnt", OPEN_TREE_CLONE | AT_RECURSIVE) move_mount(fd, "", AT_FDCWD, "/mnt/a", MOVE_MOUNT_BENEATH) grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 777 775 ... /mnt/a ... master:646 776 777 ... /mnt/a ... master:647 778 777 ... /mnt/a/a ... master:647 The now attached tree (777) is now mounted beneath the container's copy of /mnt/a. That's also where the host mount sits (as seen from the host mount namespace). So the propagated copy (776) of the host's mount is on top of its root and the copy of that (778) is inside it. Now the host runs: umount /mnt/a and it succeeds. The moved tree tree and the copy inside of it are gone from the container. Now only the propagated copy is left and it got reparented to where it was before: grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 776 775 ... /mnt/a ... But the file descriptor still refers to the moved tree. So a synchronous umount detached a mount that is still in use. Teach propagate_mount_busy() the same checks that propagate_umount() does. It now checks for a single victim mount without children for which it can assume that MNT_LOCKED is cleared on every copy like propagate_umount() does. The copies form chains. IOW, when a copy itself receives propagation from the victim's parent then the mount at the same mountpoint inside that copy is a copy as well. Whether a mount receives propagation from the victim's can simply be checked by walking its masters. Walk each chain once from its top so we are sure that nested copies stay linear. Check every reference once of every copy that gets unmounted. Link: https://patch.msgid.link/20260923-work-mount-fixes-v1-5-f424cf8d3242@kernel.org Fixes: 99b19d16471e ("mnt: In propgate_umount handle visiting mounts in any order") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) [ sashal: Replaced the missing m->overmount with a root-mountpoint check and scaled the refcount check by the number of allowed children, since children pin their parent here; removed the unused find_topper(). ] Signed-off-by: Sasha Levin commit 710da683028f862be07bec6c8090ab4bdf2289c5 Author: Ilya Maximets Date: Mon Sep 21 16:55:47 2026 +0200 net/sched: act_ct: remove 'add_helper' dead code [ Upstream commit 00df72e39f306e2f7adb68528a5c92109da6a0a9 ] This variable can only become 'true' when the connection is not confirmed, but it is only checked when it is confirmed. So, it can be treated as being always false and just removed. Fixes: a21b06e73191 ("net: sched: add helper support in act_ct") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Reviewed-by: Xin Long Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260921145655.3167436-6-i.maximets@ovn.org Signed-off-by: Jakub Kicinski [ sashal: Adjusted context because the helper-run block sits after the mark/labels/extension setup, so the add_helper removals and condition change are applied as two separate hunks. ] Signed-off-by: Sasha Levin commit 6c7438b11cdb081b7035c5aa2b25490ccff11464 Author: Kendall Willis Date: Tue Aug 25 17:06:07 2026 -0500 serial: 8250_omap: fix wake irq cleared during suspend [ Upstream commit 73f3e6ca7a6a7c952977c7c94f1c6dddebcafa34 ] The wake irq was cleared in shutdown(), which runs during the suspend sequence, making it impossible to wake the system via UART. Move wake irq setup to probe() and teardown to remove() so the irq remains armed during suspend when the UART is a wakeup source. Cc: stable@kernel.org Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Signed-off-by: Kendall Willis Reviewed-by: Tony Lindgren Link: https://patch.msgid.link/20260825-uart-wakeirq-fix-v2-1-0b9fba03d9b6@ti.com Signed-off-by: Greg Kroah-Hartman [ sashal: Kept the older pm_runtime_get_sync() and uart_port_lock_irq() code in the startup and shutdown hunks, since the guard/scoped_guard and UART_CAP_RPM context from upstream is missing here. ] Signed-off-by: Sasha Levin commit 8565d45307a1f800023f40f105c81d4e1d60a6e6 Author: Sean Christopherson Date: Mon Sep 21 14:16:08 2026 -0700 KVM: x86: Fill kvm_run exit fields in common get_nested_state_pages() error paths [ Upstream commit c1214f293d77c6e425a379f90d09bdb4815993a8 ] Fill kvm_run with "internal error, emulation" in the common error handling paths for getting nested state pages, as requiring each check to manually fill kvm_run is error prone and requires a non-trivial amount of copy+paste. Specifically, both SVM and VMX fail to fill kvm_run if load_pdptrs() fails, and SVM fails to fill kvm_run if kvm_hv_verify_vp_assist() fails. If those flows fail, the *best* case scenario is that KVM will exit to userspace with KVM_EXIT_UNKNOWN. The worst case scenario is that KVM exits with a stale exit_reason and confuses userspace. Note, SVM never exits to userspace if something goes sideways when dealing with vmcb12 assets while emulating VMRUN, i.e. lack of SVM-specific code is not a bug. Fixes: 0f85722341b0 ("KVM: nVMX: delay loading of PDPTRs to KVM_REQ_GET_NESTED_STATE_PAGES") Fixes: 232f75d3b4b5 ("KVM: nSVM: call nested_svm_load_cr3 on nested state load") Fixes: 3f4a812edf5c ("KVM: nSVM: hyper-v: Enable L2 TLB flush") Cc: stable@vger.kernel.org Reported-by: Jinwoo Lee Closes: https://lore.kernel.org/all/20260813043932.3214460-1-rkskek9254@gmail.com Reported-by: Stefan Teodorescu Link: https://patch.msgid.link/20260921211608.1030158-3-seanjc@google.com Signed-off-by: Sean Christopherson [ sashal: Adapted to local code by keeping nested_svm_vmrun_msrpm(svm), vmx->nested.nested_run_pending, and the open-coded nested_ops->get_nested_state_pages(vcpu) call instead of kvm_nested_call(). ] Signed-off-by: Sasha Levin commit 1e231eedb0c5aafdc8d96a816ec75554aa69004d Author: Sean Christopherson Date: Mon Sep 21 14:16:07 2026 -0700 KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails [ Upstream commit 10180a277549339020b08000206092c07e0bff5a ] Re-pend GET_NESTED_STATE_PAGES before exiting to userspace if getting the nested pages fails in the KVM_RUN path. If userspace re-runs the vCPU, and vmcs02 holds valid PFNs from the *previous* run of L2, then KVM could re-enter L2 with stale, unpinned PFNs mapped into e.g. the vAPIC page. Note, both SVM and VMX (as of commit 11722439fb20 ("KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit") ensure the request is cleared on VM-Exit (including the "forced" case), i.e. there is no risk of double-mapping due to emulated VMLAUNCH/VMRESUME/VMRUN *and* the request trying to map the nested pages. Fixes: 671ddc700fd0 ("KVM: nVMX: Don't leak L1 MMIO regions to L2") Cc: stable@vger.kernel.org Reported-by: Jinwoo Lee Closes: https://lore.kernel.org/all/20260813043932.3214460-1-rkskek9254@gmail.com Reported-by: Stefan Teodorescu Link: https://patch.msgid.link/20260921211608.1030158-2-seanjc@google.com Signed-off-by: Sean Christopherson [ sashal: Replaced the kvm_nested_call(get_nested_state_pages)(vcpu) context line with a direct kvm_x86_ops.nested_ops->get_nested_state_pages(vcpu) call, since the wrapper doesn't exist here. ] Signed-off-by: Sasha Levin commit c92bae390176d2d7405d4a1fe5676838eeee86a2 Author: Imre Deak Date: Mon Sep 7 20:44:13 2026 +0300 drm/i915/dp_mst: Fix configuring TUs for a disconnected stream [ Upstream commit a443e0b8d647c1401b110d9f919d8c6cb8607260 ] During an atomic commit after all the MST stream CRTC state is computed the driver ensures that the sum of TUs of all the streams on a given MST topology link is within limits (63 for 8b10 and 64 for 128b132b). For a disconnected stream the DRM MST core's BW verification doesn't ensure this, because the topology state it uses for this is destroyed as soon as the stream (i.e. MST connector/port) is disconnected. The driver should keep the link state valid even for such disconnected streams, as userspace may disable them one-by-one only in a deferred way. Ensure the link's sum of TUs stays within limits in this case by simply reusing the maximum link BPP limit from the stream's (i.e. CRTC's) old state. The disconnection can happen either via the whole topology getting disconnected or via only the given stream's port getting disconnected. Check for both of these conditions separately, as a connector gets unregistered after a link disconnect event only in a deferred way. Cc: stable@vger.kernel.org # v6.10+ Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16073 Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16384 Reviewed-by: Luca Coelho Signed-off-by: Imre Deak Link: https://patch.msgid.link/20260907174413.741851-2-imre.deak@intel.com (cherry picked from commit ee00f8fbb2b202002ab90834e02e9ba372773a36) Signed-off-by: Jani Nikula [ sashal: Replaced the undeclared crtc argument with intel_crtc_for_pipe(display, pipe) in the intel_dp_mst_stream_disconnected() call in intel_link_bw_init_limits(), since this tree has no local crtc variable there. ] Signed-off-by: Sasha Levin commit 36a2ba21d38a86bae84441e4c8d5b10653ef341a Author: Adarsh Das Date: Sat Sep 19 16:27:32 2026 +0530 smb: client: delete compound mids on send failure before unlock [ Upstream commit 8f6f8a48399f82f4a83f7b9f25b9707e0062a4f9 ] When sending a compound request fails, smb_send_rqst() kicks off a reconnect. compound_send_recv() still has those mids on pending_mid_q, but it unlocks the server without removing them first. During reconnect, cifs_abort_connection() walks pending_mid_q and runs each mid callback. With no response yet, those callbacks return credits and drop in_flight. Then compound_send_recv()'s send-error path returns the same credits again. in_flight ends up decremented twice and smb2_add_credits() WARNs. syzbot hits this during SMB2_negotiate when the socket send fails. cifs_call_async() already calls delete_mid() before unlock on send failure. Do the same for compound chains and set cancelled_mid[] so the out: path does not delete them again. Fixes: ee258d79159a ("CIFS: Move credit processing to mid callbacks for SMB3") Reported-by: syzbot+eeb58d2197d88720a228@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/6a727d22.40259c87.584f4.04ce.GAE@google.com Tested-by: syzbot+eeb58d2197d88720a228@syzkaller.appspotmail.com Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Adarsh Das Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 85f2d80a260f2ee90647da094b80a2d5ce719750 Author: David Francis Date: Wed Aug 5 09:16:51 2026 -0400 drm/amdkfd: Avoid integer underflow in EOP ring size calculation. [ Upstream commit 8ee521b8b189799e361d4233c5180ba56656d4d4 ] The low 6 bits of cp_hqd_eop_control store the base-2 logarithm of the EOP ring size. This was calculated as order_base_2(q->eop_ring_buffer_size / 4) - 1 But order_base_2 can in theory return 0, so this could underflow (although in practice the ring buffer size cannot be less than 4096). Change this to order_base_2(q->eop_ring_buffer_size / 8) using properties of logarithms. Also add to the above comment to make the mathematics more clear. Reviewed-by: Kent Russell Signed-off-by: David Francis Signed-off-by: Alex Deucher (cherry picked from commit f0f43fcf8b2b3a924cad9444340921c96ed5f634) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 1ab281c7ce2dc5195d337f2c16e22eba356b47f9 Author: David Francis Date: Wed Aug 5 09:51:35 2026 -0400 drm/amdkfd: Avoid integer underflow with ffs in EOP ring size calc [ Upstream commit c883d0a132d430ef7ebb23fd94323be94d0fbdb8 ] The low 6 bits of cp_hqd_eop_control store the base-2 logarithm of the EOP ring size. This was calculated as ffs(q->eop_ring_buffer_size / sizeof(unsigned int)) - 1 - 1 But ffs can in theory return 1 or 0, so this could underflow (although in practice the ring buffer size cannot be less than 4096). Change this to ffs(q->eop_ring_buffer_size / sizeof(unsigned int) / 4) using properties of logarithms. Reviewed-by: Kent Russell Signed-off-by: David Francis Signed-off-by: Alex Deucher (cherry picked from commit 4f18c56630383c14bfc6b2d65f88f2f895d2121a) Cc: stable@vger.kernel.org [ sashal: Dropped the hunk for the GFX 12.1 MQD manager file, which doesn't exist in this tree; the other three files take the upstream change unchanged. ] Signed-off-by: Sasha Levin commit 904d1408b1322627e813a9a3be99ad40bd583f2b Author: Xiaogang Chen Date: Tue Jun 16 17:18:59 2026 -0500 drm/amdkfd: Guard m->cp_hqd_eop_control setting by q->eop_ring_buffer_size [ Upstream commit 8cd2ea7bab77b7aa087b1a6cc26d2df03c2a6ed9 ] To avoid wraparound if the value is 0. Signed-off-by: Xiaogang Chen Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit c0cae35661868af207077a4306bc42c7c972947c) Cc: stable@vger.kernel.org Stable-dep-of: c883d0a132d4 ("drm/amdkfd: Avoid integer underflow with ffs in EOP ring size calc") Signed-off-by: Sasha Levin commit 0f5107dc5ed4caa2d9378ec5393d09688df50590 Author: Darrick J. Wong Date: Mon Sep 14 22:37:36 2026 -0700 xfs: don't cross reference rmapbt with bitmaps if they're incomplete [ Upstream commit d7b92cbe566f6fe54368f62e4b515d9f80c43a18 ] LOLLM points out that runtime errors (e.g. ENOMEM) when we're trying to compute space usag bitmaps are silently dropped by the rmapbt scrubber. We ought to flag that as an incomplete scrub instead of reporting cross-referencing errors based on faulty data. Cc: stable@vger.kernel.org # v6.4 Fixes: fed050f3452da0 ("xfs: cross-reference rmap records with ag btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit 96ad5311ff75d374430ec82a1843bcb193145c93 Author: Tzung-Bi Shih Date: Sun Sep 13 14:48:51 2026 +0800 watchdog: rzv2h: Avoid division by zero [ Upstream commit 6274281c41efa8dd1aa5234c59ad904ff89d7af4 ] clk_get_rate() could return 0. Avoid a division by zero panic. Fixes: f6febd0a30b6 ("watchdog: Add Watchdog Timer driver for RZ/V2H(P)") Cc: stable@vger.kernel.org Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260913064851.8239-4-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit d540147cb470773d49356028fa85b373fb8fc078 Author: Lad Prabhakar Date: Wed Aug 20 21:23:20 2025 +0100 watchdog: rzv2h: Add support for configurable count clock source [ Upstream commit ef6080fec60af92fc00b96743e85779927baf87b ] Add support for selecting the count clock source used by the watchdog timer. The RZ/V2H(P) SoC uses the LOCO as the count source, whereas on RZ/T2H and RZ/N2H SoCs, the count source is the peripheral clock (PCLKL). Introduce a `count_source` field in the SoC-specific data structure and refactor the clock rate selection logic accordingly. This prepares the driver for supporting the RZ/T2H and RZ/N2H SoCs, which differ in their watchdog clocking architecture from RZ/V2H(P). Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Stable-dep-of: 6274281c41ef ("watchdog: rzv2h: Avoid division by zero") Signed-off-by: Sasha Levin commit 90c9d66e6173bae4ad227ac36a2f4ac86cb30cdf Author: Lad Prabhakar Date: Wed Aug 20 21:23:18 2025 +0100 watchdog: rzv2h: Obtain clock-divider and timeout values from OF match data [ Upstream commit 19f7eaec4d9d1dcd8b49e14dbad56a65810c2910 ] Update the rzv2h_wdt driver to fetch clock configuration and timeout parameters from device tree match data rather than relying on hardcoded constants. Introduce a new structure rzv2h_of_data that encapsulates minimum and maximum clock select values (cks_min and cks_max), clock divider (cks_div), timeout cycle count (timeout_cycles), and the timeout period select bits (tops). These values are provided through the OF match table and retrieved via of_device_get_match_data() during probe. This change allows dynamic configuration of the watchdog timer for different SoCs, such as the RZ/T2H, which require different settings. Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Stable-dep-of: 6274281c41ef ("watchdog: rzv2h: Avoid division by zero") Signed-off-by: Sasha Levin commit 7ca26b2cf707f2245af71a92dbca3f9f214ba730 Author: Zongmin Zhou Date: Sun Nov 1 18:18:18 2026 -0500 RISC-V: KVM: Fix sdata leak and stale snapshot_addr in snapshot_set_shmem [ Upstream commit b7749531a9b195f4fd7db92ca3cc49bda1a4dc8d ] A guest may call SBI_PMU_SNAPSHOT_SET_SHMEM repeatedly. Each call overwrites kvpmu->sdata without freeing the old buffer (memory leak), and if a later kvm_vcpu_write_guest() fails, the error path frees sdata but leaves snapshot_addr stale. A subsequent SBI_PMU_COUNTER_START then passes the INVALID_GPA check and crashes the host with a NULL buffer in kvm_vcpu_read_guest(). Fix this by clearing the previously installed snapshot area before installing a new one, which keeps sdata and snapshot_addr consistent. The SBI spec suggests a single invocation but defines no error code for repeated calls, so KVM must tolerate them. Fixes: c2f41ddbcdd756 ("RISC-V: KVM: Implement SBI PMU Snapshot feature") Cc: stable@vger.kernel.org Signed-off-by: Zongmin Zhou Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260826064117.58029-1-min_halo@163.com Signed-off-by: Anup Patel [ sashal: Dropped the __GFP_ACCOUNT flag from the kzalloc context line, since this tree lacks it, and inserted the same 8-line clear block before the GFP_ATOMIC allocation. ] Signed-off-by: Sasha Levin commit 004fd9f933fa80f5d64e0351960e159589203945 Author: Xie Bo Date: Mon Aug 10 13:15:44 2026 +0800 RISC-V: KVM: Propagate interrupted G-stage faults [ Upstream commit f41fb17143df890855d3de980f8eb92dfd595817 ] __kvm_faultin_pfn() reports an interrupted host page fault with KVM_PFN_ERR_SIGPENDING. RISC-V currently handles it as a generic error PFN and returns -EFAULT. Return -EINTR for the signal-pending sentinel so callers can distinguish an interrupted fault from an invalid userspace mapping. Do not log the expected interruption as a vCPU exit error. Fixes: 9d05c1fee837 ("RISC-V: KVM: Implement stage2 page table programming") Cc: stable@vger.kernel.org Signed-off-by: Xie Bo Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260810051544.3953925-3-xb@ultrarisc.com Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit 612dd3539a1d1f5200923c39e0a6ad600b31d56d Author: Paulo Alcantara Date: Sun Sep 13 21:15:41 2026 -0300 smb: client: fix fattr leaking on wsl_to_fattr() failure [ Upstream commit e1253a82bb4c0fed6706a5839fc8b6e01be1abe2 ] wsl_to_fattr() mutates fattr fields as it parses each WSL EA. If validation later fails, the function returns false with partially mutated fattr fields that callers do not reset. Fix this by parsing into local variables and only committing them to fattr on success. Closes: https://sashiko.dev/#/patchset/20260906200517.725015-1-pc%40manguebit.org Fixes: 78e26bec4d6d ("smb: client: parse uid, gid, mode and dev from WSL reparse points") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: David Howells Cc: Tom Talpey Cc: Shyam Prasad N Cc: Ronnie Sahlberg Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org [ sashal: Kept cifs_sb->mnt_cifs_flags instead of the missing cifs_sb_flags(cifs_sb) helper in the declarations context; the rest of the change matches upstream. ] Signed-off-by: Sasha Levin commit 0ba7c696eea3af41ac4712197566a7b94eedc637 Author: Jonghyuk Kim(MalHyuk) Date: Wed Sep 2 10:27:20 2026 +0900 drm/msm: RCU-free the scheduler-containing ring and VM objects [ Upstream commit 01c8d1f385f788f1bbbbb7687c4386d614281218 ] Both struct msm_ringbuffer and struct msm_gem_vm embed a struct drm_gpu_scheduler. msm_ringbuffer_destroy() and the VM free callback msm_gem_vm_free() call drm_sched_fini() on the embedded scheduler and then free the containing object with plain kfree(). drm_sched_fence_get_timeline_name() returns fence->sched->name, and the scheduler fence keeps a .release callback so it is not ops-detached on signalling. A finished fence exported to userspace (the submit out-fence, or a VM_BIND fence, via sync_file / drm_syncobj) keeps pointing at the embedded scheduler after the ring/VM is freed, so a later get_timeline_name() -- reachable unprivileged through SYNC_IOC_FILE_INFO -- dereferences freed slab memory (KASAN slab-use-after-free read). Per the dma-fence lifetime contract the exporter must keep the data backing a signalled fence alive for an RCU grace period. Free the scheduler-containing objects with kfree_rcu() instead of kfree(). Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler") Fixes: 92395af63a99 ("drm/msm: Add VM_BIND submitqueue") Cc: stable@vger.kernel.org Signed-off-by: Jonghyuk Kim(MalHyuk) Patchwork: https://patchwork.freedesktop.org/patch/750234/ Message-ID: <20260902012720.880783-1-malhyuk97@gmail.com> Signed-off-by: Rob Clark [ sashal: Dropped the VM half (the msm_gem_vm rcu field and its kfree_rcu) since that struct doesn't exist here, and kept only the ring rcu_head and kfree_rcu() change. ] Signed-off-by: Sasha Levin commit 155bdf95d331b3db690b980eb687436cc4a4858d Author: Kevin Wang Date: Wed Aug 26 09:51:55 2026 +0800 drm/amd/pm: fix gpu metrics energy accumulator for smu 13.0.0/13.0.7 [ Upstream commit 13ddcc7acb9adbed7627e952a61d1d62cd9546fc ] GPU metrics v1.3 defines energy_accumulator as a 64‑bit field. The unsupported‑firmware code path assigns UINT_MAX, which is neither the full‑width invalid value for this field nor its default value. Fixes: 8de9edb35976 ("drm/amd/pm: remove invalid gpu_metrics.energy_accumulator on smu v13.0.x") Signed-off-by: Kevin Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit c2b948c4fe16eb13d98ff5d1371956cb2f55cdc6) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9e3ea03feed2b58bd09c85ed37ba1943b2a0bac3 Author: Prike Liang Date: Mon Aug 31 10:51:04 2026 +0800 drm/amdgpu: skip gfx switch_power_profile during GPU reset [ Upstream commit 1f1d43418d61c8511779e0f63a954a78b9433b43 ] During resume from GPU reset, the gfx idle work may invoke switch_power_profile before the reset completes. This causes the following assert error because the register access occurs without first releasing the GPU reset semaphore: [ 1576.768935] CR2: 0000559ea133ead0 CR3: 00000002e6c42000 CR4: 0000000000350ef0 [ 1576.768940] Call Trace: [ 1576.768944] [ 1576.768953] amdgpu_device_rreg+0x21/0x50 [amdgpu] [ 1576.769158] smu_msg_v1_send_msg+0x1a4/0x6e0 [amdgpu] [ 1576.769437] smu_cmn_send_smc_msg_with_params_ext+0xba/0x120 [amdgpu] [ 1576.769721] smu_cmn_send_smc_msg_with_param+0x33/0x40 [amdgpu] [ 1576.769993] smu_v13_0_0_set_power_profile_mode+0x192/0x2b0 [amdgpu] [ 1576.770267] smu_bump_power_profile_mode+0x5d/0x80 [amdgpu] [ 1576.770538] smu_switch_power_profile+0xa4/0xf0 [amdgpu] [ 1576.770839] amdgpu_dpm_switch_power_profile+0x6f/0x90 [amdgpu] [ 1576.771210] amdgpu_gfx_profile_idle_work_handler+0xe9/0x130 [amdgpu] [ 1576.771460] process_one_work+0x23e/0x6f0 [ 1576.771491] worker_thread+0x1c4/0x380 [ 1576.771506] kthread+0x10c/0x150 [ 1576.771512] ? __pfx_worker_thread+0x10/0x10 [ 1576.771518] ? __pfx_kthread+0x10/0x10 [ 1576.771530] ret_from_fork+0x314/0x390 [ 1576.771537] ? __pfx_kthread+0x10/0x10 [ 1576.771546] ret_from_fork_asm+0x1a/0x30 Signed-off-by: Prike Liang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit d93b1ff538ce9750c01e0dd0aa62575579c0fc08) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit ce935a6a883e67231e5e8dc6040ea42f021e4935 Author: Alex Deucher Date: Wed Mar 26 10:26:25 2025 -0400 drm/amdgpu/pm: add workload profile pause helper [ Upstream commit 7f991dd3641ef52e0a25b43f27cc61440c4bdcb4 ] To be used for display idle optimizations when we want to pause non-default profiles. Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit 6dafb5d4c7cdfc8f994e789d050e29e0d5ca6efd) Stable-dep-of: 1f1d43418d61 ("drm/amdgpu: skip gfx switch_power_profile during GPU reset") Signed-off-by: Sasha Levin commit 46048904da209cc73276bd23b399ba2d87d0dc27 Author: Arie Miller Date: Thu Sep 3 22:21:29 2026 -0400 hwmon: (asus_rog_ryujin) Synchronize HID command and report handling [ Upstream commit 06d48355bf41028c1321acda6a4391cd70098be8 ] rog_ryujin_execute_cmd() holds status_report_request_lock while reinitializing a completion, intending to exclude raw-event handling. However, rog_ryujin_raw_event() does not acquire the lock when it updates the completion. A response can therefore race with reinit_completion() and be lost, leaving the command to time out. Hold the lock while parsing reports and updating their completions. Use the irqsave variants in both paths because raw-event handling may run in interrupt context. Fixes: ed3e03790c5c ("hwmon: Add driver for ASUS ROG RYUJIN II 360 AIO cooler") Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hwmon/20260812104617.858D01F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol sparse Signed-off-by: Arie Miller Link: https://patch.msgid.link/20260904022129.97896-3-renari@arimil.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 550310c75a5c0b97adbfce95e54318ccca80917e Author: Paulo Alcantara Date: Sun Sep 6 16:01:16 2026 -0300 smb: client: fix file type corruption in posix_reparse_to_fattr() [ Upstream commit 65d5dbdc089be42fc48a6f77bc6b648307f34b17 ] Setting the file type in cf_mode without clearing the existing S_IFMT bits first is wrong as it corrupts the file type when cf_mode already has type bits set (e.g. S_IFREG | S_IFCHR == S_IFLNK). Use a local ftype variable to collect the new file type and apply it after validation succeeds, clearing S_IFMT and setting the new type in a single assignment. This avoids stripping cf_mode on malformed reparse points where the function returns false early. Closes: https://sashiko.dev/#/patchset/20260906172005.627163-1-pc%40manguebit.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 4d33932b54654d2480b362aa4694e391b9b042dc Author: Pali Rohár Date: Fri Sep 13 11:46:35 2024 +0200 cifs: Rename struct reparse_posix_data to reparse_nfs_data_buffer and move to common/smb2pdu.h [ Upstream commit b6d002f0a345218edbe9de049693004482a81327 ] Function parse_reparse_posix() parses NFS-style reparse points, which are used only by Windows NFS server since Windows Server 2012 version. This style is not understood by Microsoft POSIX/Interix/SFU/SUA subsystems. So make it clear that parse_reparse_posix() function and reparse_posix_data structure are not POSIX general, but rather NFS specific. All reparse buffer structures are defined in common/smb2pdu.h and have _buffer suffix. So move struct reparse_posix_data from client/cifspdu.h to common/smb2pdu.h and rename it to reparse_nfs_data_buffer for consistency. Note that also SMB specification in [MS-FSCC] document, section 2.1.2.6 defines it under name "Network File System (NFS) Reparse Data Buffer". So use this name for consistency. Having this structure in common/smb2pdu.h can be useful for ksmbd server code as NFS-style reparse points is the preferred way for implementing support for special files. Signed-off-by: Pali Rohár Acked-by: Paulo Alcantara (Red Hat) Reviewed-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: 65d5dbdc089b ("smb: client: fix file type corruption in posix_reparse_to_fattr()") Signed-off-by: Sasha Levin commit 1d53e92a72ae7ff043f7943aafc92e51c8adbe10 Author: Pali Rohár Date: Sat Sep 28 14:13:44 2024 +0200 cifs: Remove struct reparse_posix_data from struct cifs_open_info_data [ Upstream commit 65ccccee4eb1a8147a3242238f7730bd8359077e ] Linux SMB client already supports more reparse point types but only the reparse_posix_data is defined in union of struct cifs_open_info_data. This union is currently used as implicit casting between point types. With this code style, it hides information that union is used for pointer casting, and just in mknod_nfs() and posix_reparse_to_fattr() functions. Other reparse point buffers do not use this kind of casting. So remove reparse_posix_data from reparse part of struct cifs_open_info_data and for all cases of reparse buffer use just struct reparse_data_buffer *buf. Signed-off-by: Pali Rohár Reviewed-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: 65d5dbdc089b ("smb: client: fix file type corruption in posix_reparse_to_fattr()") Signed-off-by: Sasha Levin commit 0961dec6f76e632e6d3cf6e488214b66358b0f1f Author: Pali Rohár Date: Sat Sep 28 14:16:31 2024 +0200 cifs: Remove duplicate struct reparse_symlink_data and SYMLINK_FLAG_RELATIVE [ Upstream commit 2948f0d4db40d839db2c1d141121c2e4e12a6faa ] In file common/smb2pdu.h is defined struct reparse_symlink_data_buffer which is same as struct reparse_symlink_data and is used in the whole code. So remove duplicate struct reparse_symlink_data from client/cifspdu.h. In file common/smb2pdu.h is defined also SYMLINK_FLAG_RELATIVE constant, so remove duplication from client/cifspdu.h. Signed-off-by: Pali Rohár Acked-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Stable-dep-of: 65d5dbdc089b ("smb: client: fix file type corruption in posix_reparse_to_fattr()") Signed-off-by: Sasha Levin commit b1c5d479f8520e6084ef088fea35d7bc40837e1a Author: Paulo Alcantara Date: Sun Sep 6 14:40:23 2026 -0300 smb: client: fix WSL reparse point uid/gid override [ Upstream commit cd2b2b57921d4caa7875e83198bb2aa71254328b ] wsl_to_fattr() unconditionally overwrites cf_uid/cf_gid with values from WSL extended attributes ($LXUID/$LXGID), ignoring the forceuid and forcegid mount options. Fix this by initializing cf_uid/cf_gid to the mount defaults and gating the $LXUID/$LXGID EA parsing on forceuid/forcegid. Closes: https://sashiko.dev/#/patchset/20260906190803.667489-1-pc%40manguebit.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Replaced the missing cifs_sb_flags(cifs_sb) helper with a direct cifs_sb->mnt_cifs_flags read, and kept the existing cf_mode &= ~S_IFMT line alongside the new cf_uid/cf_gid initialisation. ] Signed-off-by: Sasha Levin commit 0b9689ae4cf2fe8d37690261f277be0356800a93 Author: Paulo Alcantara Date: Sun Sep 6 14:39:44 2026 -0300 smb: client: fix uid/gid override in getattr with posix extensions [ Upstream commit cf4d35896621b7298eef51b7a465e5c0cb22f670 ] When mounting with 'multiuser,posix' options, cifs_getattr() overrides the server-provided uid/gid with the current process's fsuid/fsgid. This is because the condition only checks for unix extensions (tcon->unix_ext) but not posix extensions (tcon->posix_extensions). With SMB3 POSIX extensions, the server provides real uid/gid values just like with unix extensions, so they should be preserved rather than replaced with the caller's credentials. Add a tcon->posix_extensions check to the condition so that uid/gid from the server are properly reported in stat results. Reported-by: Arthur Lesuisse Closes: https://lore.kernel.org/r/DB9P190MB2012266F6B8DECBE5D26A1798DB52@DB9P190MB2012.EURP190.PROD.OUTLOOK.COM Suggested-by: Arthur Lesuisse Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Kept the tree's direct cifs_sb->mnt_cifs_flags access instead of the sbflags helper, and added !tcon->posix_extensions to the existing condition. ] Signed-off-by: Sasha Levin commit 8a9a8dfab8f6fb3b85859fb021e4275fadd59ad1 Author: Théo Lebrun Date: Fri Aug 28 16:07:33 2026 +0200 mips: select CONFIG_WEAK_REORDERING_BEYOND_LLSC from CONFIG_EYEQ [ Upstream commit bbc448c541ed90d52f9ec22f17394304e3bf170e ] On I6500 CPU cores, lld and scd give no ordering guarantees (same as all other instructions). To respect the assumption that arch_cmpxchg() is fully ordered, we must inject sync instructions above and below our lld/scd loops using the already in place WEAK_REORDERING_BEYOND_LLSC infrastructure. Otherwise, bad things can happen: [ 34.054496] CPU 3 Unable to handle kernel paging request at virtual address 0000000000000000, epc == a80000080838e01c, ra == a80000080838dfc4 [ 34.054559] Oops[#1]: [ 34.069561] CPU: 3 UID: 0 PID: 170 Comm: pipe_race Not tainted 7.2.0-rc6-01553-gb73c35220968-dirty #103 VOLUNTARY [ 34.079932] Hardware name: Mobile EyeQ5 MP5 Evaluation board [ 34.085592] $ 0 : 0000000000000000 0000000000000001 0000000000000000 0000000000000000 [ 34.093616] $ 4 : a800000808ee2618 000000000b7a879d 0000000000001000 0000000000000000 [ 34.101638] $ 8 : 0000000000e3f2c9 0000000000000000 a800000808a2a9f8 0000000000000000 [ 34.109660] $12 : a8000008139ffcd8 ffffffff84080018 a80000080837fae0 7878787878787878 [ 34.117682] $16 : a800000807e82940 0000000000001000 0000000000000000 0000000000000000 [ 34.125704] $20 : a800000802920e00 a8000008139ffdf8 a800000802649400 0000000000e3f2c9 [ 34.133726] $24 : 0000000000000006 00000001200406e0 [ 34.141783] $28 : a8000008139fc000 a8000008139ffd10 0000000000e3f2c8 a80000080838dfc4 [ 34.149837] epc : a80000080838e01c anon_pipe_read+0xd4/0x428 [ 34.155697] ra : a80000080838dfc4 anon_pipe_read+0x7c/0x428 [ 34.161549] Status: 140000e3 KX SX UX KERNEL EXL IE [ 34.166551] Cause : 40800408 (ExcCode 02) [ 34.170574] BadVA : 0000000000000000 [ 34.174161] PrId : 0001b028 (MIPS I6500) [ 34.178183] Process pipe_race (pid: 170, threadinfo=000000005ca35720, task=00000000e1013890, tls=000000014ebbb780) [ 34.188568] Stack : a800000802649400 0000000000000000 0000000000000000 a8000008139ffdd0 [ 34.196623] 0000000000000fba a800000808ee0000 0000000000000001 a8000008130c3e80 [ 34.204676] a8000008080d1280 a8000008139ffd58 a8000008139ffd58 1dbd2b22ea1dd500 [ 34.212729] a800000802649400 a800000808ee0000 ffffffffffffffea 0000000000000001 [ 34.220783] 0000000000001000 0000000000000000 00000001200ae518 ffffffffffffffff [ 34.228836] 000000fffbe0e530 a80000080837edf4 000000fffbe0e530 0000000000000000 [ 34.236890] 0000000000000000 0000000000000000 000000014ebb55a0 0000000000001000 [ 34.244943] 0000000000000001 a800000802649400 0000000000000000 0000000000000000 [ 34.252996] 0000000000000000 0000400400000000 0000000000000000 1dbd2b22ea1dd500 [ 34.261049] 00000000140000e3 a800000802649400 a800000802649400 a800000808ee0000 [ 34.269103] ... [ 34.271568] Call Trace: [ 34.274026] [] anon_pipe_read+0xd4/0x428 [ 34.279533] [] vfs_read+0x25c/0x318 [ 34.284607] [] ksys_read+0x104/0x138 [ 34.289763] [] syscall_common+0x44/0x68 [ 34.295187] [ 34.296689] Code: f84000cf 02209825 de020010 d8400004 02002825 0040f809 02802025 f84000c3 [ 34.306504] [ 34.308099] ---[ end trace 0000000000000000 ]--- My initial reproducer was the xdp-tools test suite. A standalone reproducer would be an lld/scd loop that, when the read is reordered by the CPU, triggers a fault. We can achieve this from userspace by stressing an anonymous pipe, which uses a mutex. Program used: // SPDX-License-Identifier: GPL-2.0 // pipe_race.c - reproducer for MIPS LL/SC reordering vs fs/pipe.c // // Two userspace processes on an anonymous pipe: // parent = writer: tight write() loop // child = reader: tight read() loop #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include #include int main(void) { long wrsize = 70; // bytes per write() long rdsize = 4096; // bytes per read() int pfd[2]; char *buf; pid_t pid; int ret; ret = pipe(pfd); assert(!ret); pid = fork(); assert(pid >= 0); if (pid == 0) { /* reader */ close(pfd[1]); buf = malloc(rdsize); assert(buf); for (;;) { ssize_t n = read(pfd[0], buf, rdsize); if (n < 0 && errno == EINTR) continue; if (n <= 0) _exit(n < 0 ? 1 : 0); } } close(pfd[0]); /* writer */ buf = malloc(wrsize); assert(buf); memset(buf, 'x', wrsize); for (;;) { ssize_t n = write(pfd[1], buf, wrsize); if (n < 0 && errno == EINTR) continue; if (n != wrsize) break; } kill(pid, SIGKILL); wait(NULL); return 0; } Fixes: fbe0fae601b7 ("MIPS: mobileye: Add EyeQ6H support") Cc: stable@vger.kernel.org Signed-off-by: Théo Lebrun Reviewed-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer [ sashal: Adjusted context: the upstream HOTPLUG_PARALLEL select line is absent here, so the single select WEAK_REORDERING_BEYOND_LLSC line was added after select USE_OF instead. ] Signed-off-by: Sasha Levin commit 9943f0df9a346860cade5e9a12fc1c1f4957eaad Author: John Hubbard Date: Sun Sep 6 14:58:22 2026 -0700 rust: allow `clippy::as_underscore` in the generated bindings [ Upstream commit 2ac74c6db40adaa29c50cbb281ae9a6f63de18e1 ] A CLIPPY=1 build emitted about 15000 `as _` conversion warnings, all of them in bindgen's generated output and none in hand-written code. [ The lint messages look like: error: using `as _` conversion --> rust/bindings/bindings_generated.rs:18947:9 | 18947 | self._bitfield_1.get_const::<0usize, 16u8>() as u32 as _ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^- | | | help: consider giving the type explicitly: `u32` | = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.98.0/index.html#as_underscore = note: `-D clippy::as-underscore` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::as_underscore)]` - Miguel ] bindgen 0.73 returns each bitfield read through a trailing `as _`, and 0.72 returns it through a transmute, which the lint ignores. The bindings and uapi crates allow `clippy::all` over the generated code. That group does not cover `clippy::as_underscore`, a restriction lint. Allow `clippy::as_underscore` by name in the bindings and uapi crates. Assisted-by: LLM Signed-off-by: John Hubbard Link: https://patch.msgid.link/20260906215822.1201022-1-jhubbard@nvidia.com Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). [ Removed CI sentence. - Miguel ] Signed-off-by: Miguel Ojeda [ sashal: Added only the as_underscore lint allow, omitting the unrelated cast_lossless/ptr_as_ptr/ref_as_ptr context lines missing from this tree. ] Signed-off-by: Sasha Levin commit 73e5b7b14df0430ef2135e9bd9fa3f5b253ef789 Author: Mikulas Patocka Date: Wed Sep 2 16:36:26 2026 +0200 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 Signed-off-by: Sasha Levin commit 9b88f0fcbd4b746de0478b4fd99fa495eb26b857 Author: Ido Schimmel Date: Fri Aug 28 22:23:43 2026 +0300 ipv6: udp: Create exceptions before socket matching [ Upstream commit ac76cab50e899a7346408b8d3c3a4192c2eefb9f ] Currently, when ICMPv6 Packet Too Big and Redirect Message packets are locally delivered and quote a UDP packet, an exception is only created in the IPv6 exception cache if the kernel can match the UDP packet to an existing socket. This behavior allows off-path attackers to conduct a side-channel attack on the exception cache in order to discover the ephemeral port used by a connected UDP socket. Commit 4785305c05b2 ("ipv6: use siphash in rt6_exception_hash()") and commit a00df2caffed ("ipv6: make exception cache less predictible") tried to mitigate such attacks by making it harder for attackers to discover hash collisions in the exception cache and by randomizing the number of exceptions a hash bucket can hold, respectively. Unfortunately, both of the mitigations can be bypassed. Instead, mitigate such attacks by always creating an exception, even before trying to find a matching socket. Do that by calling ip6_update_pmtu() and ip6_redirect(), the helpers used when the quoted packet did not originate from a socket. This means that guesses (right or wrong) from an off-path attacker will always result in an exception being created or updated in the cache that the attacker can observe. Pass the ifindex of the ingress device and the default uid, in a similar fashion to icmpv6_err(). Unlike IPv4, an oif of 0 would not match any nexthop in ip6_redirect_nh_match() and no exception would be created in response to a Redirect Message. Note that this does not allow attackers to create exceptions that they could not create before, as both helpers can already be reached with little to no validation. For example, by sending an ICMPv6 error that quotes an ICMPv6 Echo Reply or one that quotes a UDP source port that matches a wildcard socket. Also note that in the good case (matched socket) the above scheme comes at the cost of an extra route lookup, as the no socket helpers perform their own lookup before the one performed by ip6_sk_update_pmtu() / ip6_sk_redirect(). When the two resolve to different nexthops, it also results in two exceptions being created for the same destination IP. One in the exception cache of the nexthop resolved by the no socket helpers and another in the exception cache of the nexthop used by the socket. Fixes: 2b760fcf5cfb ("ipv6: hook up exception table to store dst cache") Cc: stable@vger.kernel.org Reported-by: Amit Klein Reported-by: Noam Caspi Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260828192344.2596928-4-idosch@nvidia.com Signed-off-by: Jakub Kicinski [ sashal: Adapted the fix to this tree's __udp6_lib_err(), which takes an extra udptable argument, and placed the new helper call before the socket lookup, with saddr/daddr already set in the declarations. ] Signed-off-by: Sasha Levin commit 950bf049fcc361926831cdf5ea0ee7d58a9badbe Author: Ido Schimmel Date: Sun Nov 1 16:27:39 2026 -0500 ipv6: Fix redirect exception creation for UDP/RAW sockets [ Upstream commit cd51b74bdd0b75aedf255dc67306a16dd057f7ee ] When an ICMP Redirect Message is matched to a socket, both IPv4 and IPv6 verify that the source IP of the ICMP packet is the current gateway for the quoted packet. Both also pass the socket's bound device as the expected nexthop device. The difference is that IPv4 treats "oif=0" as "any", whereas IPv6 always requires an exact match (see ip6_redirect_nh_match()), since the gateway address is usually a link-local address. Therefore, when an IPv6 UDP/RAW socket is not bound to a device, the above verification fails and an exception is not created. This also happens when the socket is bound to a VRF, as l3mdev_update_flow() resets the oif to 0. Fix this by passing the ifindex of the ingress device as the expected nexthop device. This is consistent with the existing callers of ip6_redirect(). Note that for ICMPv6 Redirect Message packets the VRF driver does not reset skb->dev to the VRF device, so skb->dev is correct, even when it is a VRF port. Fixes: b55b76b22144 ("ipv6:introduce function to find route for redirect") Cc: stable@vger.kernel.org Reviewed-by: Eric Dumazet Reviewed-by: David Ahern Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260828192344.2596928-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski [ sashal: Context line adapted to use the sk->sk_uid field directly, since the sk_uid(sk) accessor doesn't exist in this tree. ] Signed-off-by: Sasha Levin commit cdd1f99eaa4d4db82d506eb50e724460671c7cac Author: Daehyeon Ko <4ncienth@gmail.com> Date: Wed Aug 26 09:39:28 2026 +0900 vsock/vmci: validate packet source for connected sockets [ Upstream commit ad9a7da3fa39c2d616ec0dd3cf6e30531d032fe7 ] vmci_transport_recv_stream_cb() looks up sockets first by the full source and destination tuple, then by destination only in the bound table. The fallback can select a non-listening socket without checking whether the packet came from its stored peer. This was reproduced with two VMCI contexts. A RST from the context not stored in a TCP_SYN_SENT socket reset that socket after it was selected by the destination-only lookup. VMCI can process notification packets in bottom-half context when the socket is not owned by user context, or defer packets to a workqueue. Use vsock_check_source() after taking the socket lock in the bottom-half path, and recheck after lock_sock() in the workqueue path. Listening sockets continue to accept packets from any source. Reply with a RST addressed from the received packet before dropping a source that fails validation. This preserves the existing reset behavior for bound non-listening and concurrently closed sockets without directing the reset to a connected socket's stored peer. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reported-by: Sashiko Closes: https://lore.kernel.org/netdev/20260814121255.6B5001F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Suggested-by: Stefano Garzarella Suggested-by: Paolo Abeni Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Vishnu Dasa Link: https://patch.msgid.link/20260826003929.966160-3-4ncienth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bc737f5f5cc3fcd10bd919527cacc0efd703c30b Author: Yunpeng Tian Date: Sun Aug 30 18:46:56 2026 -0700 smb: client: reject SetEA requests that do not fit the request buffer [ Upstream commit 4aa2c106aef4bf3dfd97c30842db0767b26e8428 ] CIFSSMBSetEA() copies the caller's extended attribute value into the SMB request buffer without checking that it fits. The requirement is stated in the source but was never implemented: /*BB add length check to see if it would fit in negotiated SMB buffer size BB */ /* if (ea_value_len > buffer_size - 512 (enough for header)) */ if (ea_value_len) memcpy(parm_data->list.name + name_len + 1, ea_value, ea_value_len); The only bound applied on the way in is in cifs_xattr_set(): #define MAX_EA_VALUE_SIZE CIFSMaxBufSize ... if (size > MAX_EA_VALUE_SIZE) CIFSMaxBufSize is the full payload capacity of the buffer, so a value of exactly that size leaves no room for the SMB header, the TRANS2 parameter block, the fealist header and the EA name that are written ahead of it in the same object. SendReceive() already enforces the correct limit on this very length: if (in_len > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE) but it is called after the copy has taken place. An unprivileged setxattr(2) on an SMB1 mount with a 250-byte name and a 16384-byte value writes 16384 bytes starting 345 bytes into a 16588-byte cifs_request object, ending 141 bytes past it: BUG: KASAN: slab-out-of-bounds in CIFSSMBSetEA+0xabc/0xde0 Write of size 16384 at addr ffff888003aa0159 by task init/68 __asan_memcpy+0x3c/0x60 CIFSSMBSetEA+0xabc/0xde0 cifs_xattr_set+0xd3a/0xff0 __vfs_setxattr+0x13e/0x1a0 The buggy address is located 345 bytes inside of allocated 16588-byte region Apply SendReceive()'s limit to the assembled request before the copy rather than after it, and widen the byte counters so the sum cannot wrap before it is tested. byte_count is also tested against U16_MAX, because it is stored in the 16-bit pSMB->ByteCount. That becomes reachable when CIFSMaxBufSize is raised at module load, where it may be set as high as 1024*127: with a 5-byte EA name and a 65521-byte value, count is exactly U16_MAX while byte_count is 65556, and cpu_to_le16() would truncate it to 20 and transmit a frame whose ByteCount does not match its length. Testing byte_count covers count as well, since byte_count is the larger of the two and count's only 16-bit consumer is written after this point. check_add_overflow() is evaluated first so that total_len is assigned before it is reported. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yunpeng Tian Reported-by: Mingda Zhang Reported-by: Gongming Wang Reported-by: Qinrun Dai Cc: stable@vger.kernel.org Signed-off-by: Yunpeng Tian Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara [ sashal: Replaced upstream's in_len (from smb_init()'s return value) with be32_to_cpu(pSMB->hdr.smb_buf_length) and reduced the size limit by 4 to match SendReceive(). ] Signed-off-by: Sasha Levin commit e5e28b0cd56249d1a45155ee6b656c1bbd8a2b3e Author: Janani Sunil Date: Thu Aug 13 15:56:56 2026 +0200 iio: adc: adi-axi-adc: Initialize state mutex [ Upstream commit 549b71ce050637dd32678371ad76c445a2f8c9aa ] The AXI ADC register access paths serialize transactions with st->lock, but probe does not initialize it. Initialize the mutex before registering the backend. Fixes: 7ecb8ee5c93b ("iio: adc: adi-axi-adc: support digital interface calibration") Signed-off-by: Janani Sunil Cc: Signed-off-by: Jonathan Cameron [ sashal: Changed devm_mutex_init(dev, ...) to devm_mutex_init(&pdev->dev, ...) because this probe function has no local dev variable. ] Signed-off-by: Sasha Levin commit f8119fe52cd616f4d91f9d9706e74ec01dc34cea Author: Guangshuo Li Date: Wed Aug 12 17:44:25 2026 +0800 i2c: qcom-cci: fix autosuspend cleanup [ Upstream commit f98d4986482151a835b521a734722fe8dc5ca37d ] cci_probe() calls pm_runtime_use_autosuspend(), but the remove path does not call the matching pm_runtime_dont_use_autosuspend() before disabling runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without undoing the autosuspend setting during teardown, this reference is not dropped and usage_count remains unbalanced. Use devm_pm_runtime_set_active_enabled() to manage the runtime PM state. Its managed cleanup disables autosuspend and runtime PM and restores the suspended state on probe failure and driver removal. Remove the now redundant manual runtime PM cleanup. This issue was found by manual code inspection. Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver") Signed-off-by: Guangshuo Li Cc: # v5.8+ Reviewed-by: Vladimir Zapolskiy Reviewed-by: Loic Poulain Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260812094425.3515179-1-lgs201920130244@gmail.com Signed-off-by: Sasha Levin commit 1bd9e0d120a54d398e683cd1659a3eca8c4232db Author: Vladimir Zapolskiy Date: Sat May 16 02:41:21 2026 +0300 i2c: qcom-cci: Remove overcautious disable_irq() calls [ Upstream commit f0285c286bca5a1e018ba25040cef6c7806c31ef ] In cci_probe() the controller's interrupt is requested using a devres managed API, and in cci_probe() error path and cci_remove() it'd be safe to rely on devres mechanism to free and shutdown the interrupt, thus explicit disable_irq() calls can be removed as unnecessary ones. Signed-off-by: Vladimir Zapolskiy Reviewed-by: Loic Poulain Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260515234121.1607425-5-vladimir.zapolskiy@linaro.org Stable-dep-of: f98d49864821 ("i2c: qcom-cci: fix autosuspend cleanup") Signed-off-by: Sasha Levin commit c6431bd0de0d7fe6ef64ffb78c0ead1e0b3b19a3 Author: Vladimir Zapolskiy Date: Sat May 16 02:41:19 2026 +0300 i2c: qcom-cci: Do not check return value of cci_init() [ Upstream commit 17c5d247e3e4708cac05ff087c8013c0dda383a2 ] The cci_init() function is not supposed to fail, and it never returns a non-zero, so it'd make sense to convert its signature to void. Signed-off-by: Vladimir Zapolskiy Reviewed-by: Loic Poulain Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260515234121.1607425-3-vladimir.zapolskiy@linaro.org Stable-dep-of: f98d49864821 ("i2c: qcom-cci: fix autosuspend cleanup") Signed-off-by: Sasha Levin commit 0ff00fc18abb2b4913eb821f5e28897fc3874625 Author: Hui Su Date: Tue Aug 18 18:33:36 2026 +0800 io_uring/waitid: honor task_work cancellation [ Upstream commit 14572de82e5022899e5856008bc9cac97004a88c ] io_waitid_cb() may run through the fallback task_work path when task_work_add() can no longer queue work to the originating task. The fallback runs from a kworker and io_uring marks such task work as canceled through tw.cancel. io_waitid_cb() currently ignores tw.cancel and calls __do_wait(). waitid is task-context dependent: __do_wait() performs child lookup relative to current, and the retry path also uses current->signal->wait_chldexit. If the callback runs from the fallback kworker, current is therefore not the task that submitted the request. Honor tw.cancel before entering __do_wait(). Complete the request with -ECANCELED and skip the siginfo copy, since canceled task work may run without the submitting task's userspace execution context. Keep the existing siginfo handling for normal waitid completion and explicit cancellation. Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Cc: stable@vger.kernel.org Signed-off-by: Hui Su Link: https://patch.msgid.link/20260818103336.1922818-2-sh_def@163.com Signed-off-by: Jens Axboe [ sashal: Replaced the upstream tw.cancel check with io_should_terminate_tw(ctx) and the (req, ts) callback signature, and kept the existing copy_si parameter instead of hardcoding true. ] Signed-off-by: Sasha Levin commit 76d36aa4d2eaf74896711abfb4563b0c8b85292d Author: Shakeel Butt Date: Tue Jul 28 19:46:12 2026 -0700 memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done [ Upstream commit 6b0d1083364fc8e7cc2f7d1f93ee3ee78f4d52f7 ] At Meta, we are seeing instances where an OOM killed job is stuck in the exit path for several hours. In one particular case, the job was stuck for more than 8 hours and I had to manually remove the memory.max limits to allow the process to exit. The job was a single process job and had ~55 GiB memory.max and zswap enabled. It had almost 0 anon in memory and ~111 GiB in zswap compressed to ~51 GiB zswap pool (i.e. almost all of memory.current was zswap). Nothing was left on the LRUs to reclaim. On further inspection, I observed ~20k threads of that process stuck with the following stack: [<0>] mem_cgroup_out_of_memory+0x4e/0xa0 [<0>] charge_memcg+0x8bf/0x990 [<0>] mem_cgroup_swapin_charge_folio+0x4e/0x80 [<0>] __read_swap_cache_async+0x10c/0x260 [<0>] swapin_readahead+0x116/0x3f0 [<0>] do_swap_page+0x13c/0x1ce0 [<0>] handle_mm_fault+0x61d/0x11f0 [<0>] do_user_addr_fault+0x3e7/0x6d0 [<0>] exc_page_fault+0x8f/0x110 [<0>] asm_exc_page_fault+0x22/0x30 [<0>] __get_user_8+0x14/0x20 [<0>] futex_cleanup+0x27/0x1c0 [<0>] futex_exit_release+0x47/0x60 [<0>] do_exit+0x107/0x940 [<0>] do_group_exit+0x81/0xa0 [<0>] get_signal+0x2b1/0x6e0 [<0>] arch_do_signal_or_restart+0x1a/0x1c0 [<0>] exit_to_user_mode_loop+0xa8/0x1c0 [<0>] do_syscall_64+0x152/0x250 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 In addition the dmesg was filled with "Out of memory and no killable processes..." messages. I have no idea why oom reaper was not able to reap/unmap the process. My guess is that since oom reaper tries to acquire mmap_lock in read mode limited number of times and then gives up, there might be a thread of that process which had mmap_lock in write mode at that time. My initial suspicion was the futex_cleanup and kernel page fault causing infinite fault and charge retries but that was put to rest in previous discussions happened on similar problem [1]. My current theory is that it is just a simple slow serialization behind the oom_lock. Unlike page allocator, memcg charge code takes the oom_lock without the "try". Though memcg oom code uses mutex_lock_killable(), note that in the call stack get_signal() consumes SIGKILL (or sigdelset(SIGKILL)) before calling do_group_exit(). So this mutex_lock_killable() is just a mutex_lock() here. Therefore 10s of thousands of threads are waiting on oom_lock and one by one they get -EFAULT from get_user() in the futex cleanup code and bails out. Discussion from [1] led to commit a75ffa26122b ("memcg, oom: do not bypass oom killer for dying tasks") which routes dying tasks into the OOM path precisely so the oom_reaper can reap their mm and free the memory asynchronously. But the reaper is best-effort and one-shot: if it cannot take mmap_lock for read (e.g. a sibling thread holds it for write) it sets MMF_OOM_SKIP and never retries, leaving only the glacial oom_lock-serialized synchronous drain. Once MMF_OOM_SKIP is set there is no more asynchronous reclaim coming for the mm, so a dying task charging against it has nothing left to wait for: it frees its memory only once it finishes exiting. Running reclaim and the (no-victim) OOM killer for it is then pointless, and doing it for 10s of thousands of exiting threads is what serializes them behind oom_lock. So before reclaim, if current is an OOM victim whose reaper is done, fail the charge. Reproduced with 20k threads, each parking a robust futex head on its own zswapped page, OOM-group-killed while a sibling holds mmap_lock for write so the reaper gives up and sets MMF_OOM_SKIP. Tested on next-20260728 and baseline show ~90 seconds exit time while with the patch the exit time reduced to ~3 seconds. Link: https://lore.kernel.org/20260729024612.3369005-1-shakeel.butt@linux.dev Link: https://lore.kernel.org/7a4e5591f45df455e6a485fc5400989569d3d22d.camel@surriel.com/ [1] Signed-off-by: Shakeel Butt Acked-by: Johannes Weiner Acked-by: Michal Hocko Cc: David Rientjes Cc: Muchun Song Cc: Nhat Pham Cc: Rik van Riel Cc: Roman Gushchin Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton to ~51 GiB zswap pool (i.e. almost all of memory.current was zswap). Nothing was left on the LRUs to reclaim. On further inspection, I observed ~20k threads of that process stuck with the following stack: [<0>] mem_cgroup_out_of_memory+0x4e/0xa0 [<0>] charge_memcg+0x8bf/0x990 [<0>] mem_cgroup_swapin_charge_folio+0x4e/0x80 [<0>] __read_swap_cache_async+0x10c/0x260 [<0>] swapin_readahead+0x116/0x3f0 [<0>] do_swap_page+0x13c/0x1ce0 [<0>] handle_mm_fault+0x61d/0x11f0 [<0>] do_user_addr_fault+0x3e7/0x6d0 [<0>] exc_page_fault+0x8f/0x110 [<0>] asm_exc_page_fault+0x22/0x30 [<0>] __get_user_8+0x14/0x20 [<0>] futex_cleanup+0x27/0x1c0 [<0>] futex_exit_release+0x47/0x60 [<0>] do_exit+0x107/0x940 [<0>] do_group_exit+0x81/0xa0 [<0>] get_signal+0x2b1/0x6e0 [<0>] arch_do_signal_or_restart+0x1a/0x1c0 [<0>] exit_to_user_mode_loop+0xa8/0x1c0 [<0>] do_syscall_64+0x152/0x250 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 In addition the dmesg was filled with "Out of memory and no killable processes..." messages. I have no idea why oom reaper was not able to reap/unmap the process. My guess is that since oom reaper tries to acquire mmap_lock in read mode limited number of times and then gives up, there might be a thread of that process which had mmap_lock in write mode at that time. My initial suspicion was the futex_cleanup and kernel page fault causing infinite fault and charge retries but that was put to rest in previous discussions happened on similar problem [1]. My current theory is that it is just a simple slow serialization behind the oom_lock. Unlike page allocator, memcg charge code takes the oom_lock without the "try". Though memcg oom code uses mutex_lock_killable(), note that in the call stack get_signal() consumes SIGKILL (or sigdelset(SIGKILL)) before calling do_group_exit(). So this mutex_lock_killable() is just a mutex_lock() here. Therefore 10s of thousands of threads are waiting on oom_lock and one by one they get -EFAULT from get_user() in the futex cleanup code and bails out. Discussion from [1] led to commit a75ffa26122b ("memcg, oom: do not bypass oom killer for dying tasks") which routes dying tasks into the OOM path precisely so the oom_reaper can reap their mm and free the memory asynchronously. But the reaper is best-effort and one-shot: if it cannot take mmap_lock for read (e.g. a sibling thread holds it for write) it sets MMF_OOM_SKIP and never retries, leaving only the glacial oom_lock-serialized synchronous drain. Once MMF_OOM_SKIP is set there is no more asynchronous reclaim coming for the mm, so a dying task charging against it has nothing left to wait for: it frees its memory only once it finishes exiting. Running reclaim and the (no-victim) OOM killer for it is then pointless, and doing it for 10s of thousands of exiting threads is what serializes them behind oom_lock. [ sashal: Replaced mm_flags_test() with test_bit(MMF_OOM_SKIP, ¤t->signal->oom_mm->flags) since the helper doesn't exist here, and kept the older memcg_memory_event() context line. ] Signed-off-by: Sasha Levin commit 24c77d8651bf35bee5dbd3b70710090dc8fb10c2 Author: Breno Leitao Date: Mon Jul 20 06:23:45 2026 -0700 mm/kmemleak: report RCU-tasks quiescent states during the scan [ Upstream commit 3541a2b06ecd78ba333188df04368dcf97273d6a ] kmemleak_scan() can run for ages on large debug kernels. It was causing some soft-lockups which I got fixed with commit 3175fcfec8b16baeb ("mm/kmemleak: avoid soft lockup when scanning task stacks") with our beloved cond_resched(). I've got the fix above deployed in the Meta fleet, and now I am seeing: INFO: rcu_tasks detected stalls on tasks: task:kmemleak state:R ... nvcsw: 274/274 holdout: 1 idle_cpu: -1/3 scan_block scan_gray_list kmemleak_scan and, worse, blocks the callers waiting on that grace period. Here a BPF struct_ops map free, which waits via synchronize_rcu_mult(call_rcu, call_rcu_tasks), is stuck long enough to also trip the hung task check: INFO: task kworker/...:bpf_map_free_deferred blocked for 122 seconds __wait_rcu_gp bpf_struct_ops_map_free Then I've learned that cond_resched() is not an RCU-tasks quiescent state, so, we need to use stronger primitives. Use cond_resched_tasks_rcu_qs() at the scan reschedule points so the scan reports an RCU-tasks quiescent state as it proceeds. Inspired by commit b96285e10aad ("tracing: Have osnoise_main() add a quiescent state for task rcu"). Link: https://lore.kernel.org/20260720-kmemleak_rcu_task-v1-1-5b460ade777d@debian.org Fixes: c4b28963fd79 ("mm/kmemleak: rely on rcu for task stack scanning") Signed-off-by: Breno Leitao Reviewed-by: Paul E. McKenney Reviewed-by: SJ Park Reviewed-by: Catalin Marinas Cc: Breno Leitao Cc: Puranjay Mohan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 716b60195015849b860408778c7e999d18b4f557 Author: Breno Leitao Date: Mon Jun 15 10:49:07 2026 -0700 mm/kmemleak: stop the task stack scan early when interrupted [ Upstream commit eb11f56eeca56069613d00bf623607e305b271d9 ] scan_block() already checks scan_should_stop() for every pointer and bails out of the current block, but the task stack walk cannot tell and keeps issuing a separate scan_should_stop() between every task. Return that status from scan_block() and use it as the task stack loop condition, so the walk stops as soon as a scan is interrupted. Link: https://lore.kernel.org/20260615-kmemleak-stack-resched-v3-2-acecd7d7fd92@debian.org Signed-off-by: Breno Leitao Suggested-by: Catalin Marinas Reviewed-by: Catalin Marinas Reviewed-by: Oleg Nesterov Cc: Davidlohr Bueso Cc: Lance Yang Cc: Qian Cai Cc: SeongJae Park Signed-off-by: Andrew Morton Stable-dep-of: 3541a2b06ecd ("mm/kmemleak: report RCU-tasks quiescent states during the scan") Signed-off-by: Sasha Levin commit e639b76e9ed3f0804fcb2fc81a91974d026ca684 Author: Eckhart Mohr Date: Fri Aug 21 16:44:34 2026 +0200 ALSA: hda/realtek: Add quirk for TongFang XxAF5xxx [ Upstream commit e72d5659a2606056a0c34af212b46a3275a55bbf ] Fix microphone detection on built in headphone jack for some devices Signed-off-by: Eckhart Mohr Cc: stable@vger.kernel.org Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20260821144437.27233-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 859e50f3139925a55d055707db49b56891382a10 Author: Eckhart Mohr Date: Fri Jul 24 21:00:13 2026 +0200 ALSA: hda/realtek: Add quirk for TongFang X6SP45xU [ Upstream commit 26a94400ffa4fcbeff32e23abebb83a1a20eb401 ] TongFang X6KK45xU and X6SP45xU have actually different PCI IDs. This patch Adds the missing PCI ID to fix headphone detection and clarifies the naming. Fixes: d595255241e5 ("ALSA: hda/realtek: Add quirk for TongFang X6xx45xU") Signed-off-by: Eckhart Mohr Cc: stable@vger.kernel.org Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20260724190109.169889-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Stable-dep-of: e72d5659a260 ("ALSA: hda/realtek: Add quirk for TongFang XxAF5xxx") Signed-off-by: Sasha Levin commit 39ba2c3dfc788edb2e2992766819e3f67ee9ba23 Author: Eckhart Mohr Date: Wed Jul 8 15:21:06 2026 +0200 ALSA: hda/realtek: Add quirk for TongFang X6xx45xU [ Upstream commit d595255241e5fec0c94adeebf2565524398e37c5 ] Fix microphone detection on built in headphone jack for some devices. Signed-off-by: Eckhart Mohr Cc: stable@vger.kernel.org Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20260708132135.102680-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Stable-dep-of: e72d5659a260 ("ALSA: hda/realtek: Add quirk for TongFang XxAF5xxx") Signed-off-by: Sasha Levin commit dd2275f25607963f84ef98379fffc350ab282bae Author: Gary Guo Date: Thu Aug 20 14:57:32 2026 +0100 rust: cfi: disable function merging if CFI is enabled [ Upstream commit 29b03d1de967a177176d12811d970cac7882afcf ] In Rust doc tests, there is a dummy `__module_firmware_test_init` function generated by the example in `module_firmware!`'s documentation, which just returns zero. Many other documentation examples generate functions that produce zero. LKP test robot reports [1] a `Flags::zeroed` instance; my local reproduction has a `Bounded::new::<0>`. LLVM's MergeFunctionsPass incorrectly merges functions with different KCFI types, causing `__module_firmware_test_init` to be merged into one of the zero-returning functions. As module init is invoked via an indirect function call, KCFI is checked and this produces a KCFI failure. I've reported this bug to upstream LLVM [2]; in the meantime, disable function merging if CFI is enabled. No separate treatment is needed for CONFIG_RUST_INLINE_HELPERS, as Clang does not enable function merging by default. [ LLVM already has a pending PR: https://github.com/llvm/llvm-project/pull/217665 which solves the issue. In addition, I asked upstream Rust if the unstable `-Zmerge-functions=disabled` flag will remain around: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/.60-Zmerge-functions.3Ddisabled.60/ and it does indeed look like that will be the case. - Miguel ] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202608201017.100a4511-lkp@intel.com [1] Link: https://github.com/llvm/llvm-project/issues/217629 [2] Signed-off-by: Gary Guo Cc: stable@vger.kernel.org Fixes: ca627e636551 ("rust: cfi: add support for CFI_CLANG with Rust") Reviewed-by: Sami Tolvanen Link: https://patch.msgid.link/20260820135733.37121-1-gary@kernel.org [ Fixed typos as discussed. Reworded slightly for other typos. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 6c5ea25d5d6437768f21c0ee5d8ced348c49c1a9 Author: Frank Sorenson Date: Fri Jul 31 12:12:29 2026 -0500 cifs: add cifs_resize_file_locked() to guard fscache_resize_cookie() under i_rwsem [ Upstream commit 32a7af68df7361fe7cf153cf36124d04b94aec00 ] cifs_setsize() calls fscache_resize_cookie() without holding i_rwsem. When the fscache cookie is active (FSCACHE_COOKIE_IS_CACHING is set), fscache_resize_cookie() performs a real resize that requires i_rwsem held exclusively. If another file descriptor has the same inode open, fscache_use_cookie() was already called from that cifs_open(), making the cookie active. In that case, calling cifs_setsize() from cifs_do_truncate() (invoked from cifs_open() without i_rwsem) races against concurrent fscache I/O. Strip fscache_resize_cookie() from cifs_setsize(), making it a pure size/page-cache helper. Add cifs_resize_file_locked() for callers that already hold i_rwsem: it calls netfs_resize_file() and cifs_setsize(), then temporarily activates the cookie with fscache_use_cookie() to perform the resize under the lock, then deactivates it with cifs_fscache_unuse_inode_cookie(). Using fscache_use_cookie() before the resize ensures correctness whether or not another fd already holds the cookie active. Switch cifs_file_set_size(), smb2_duplicate_extents(), and both size- extension branches of smb3_simple_falloc() to the new wrapper; those paths already hold i_rwsem via VFS setattr, lock_two_nondirectories(), or cifs_fallocate() respectively. cifs_do_truncate() continues to call cifs_setsize() followed by cifs_invalidate_cache(), since it runs without i_rwsem. Fixes: fa724e235cfd ("cifs: add fscache_resize_cookie() to cifs_setsize()") Cc: stable@vger.kernel.org Cc: David Howells Cc: Paulo Alcantara Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara [ sashal: Dropped the "small range beyond EOF" hunk and the second falloc extension branch, which this tree lacks, and kept local i_blocks and cifs_truncate_page code and the older cifs_set_file_size naming. ] Signed-off-by: Sasha Levin commit 695d0be9b36c26efae7c62f91acce5928acc4f61 Author: Yang Wang Date: Wed Aug 5 11:44:54 2026 +0800 drm/amdgpu: Disable runtime PM for externally attached dGPUs [ Upstream commit c52feb4365396b6a881b5e8a95540517ffabb3b7 ] pci_is_thunderbolt_attached() requires an upstream PCI bridge with is_thunderbolt set from an Intel Thunderbolt VSEC. This does not cover the affected ASM4242 USB4 PCI hierarchy: 00:02.2 \- 0f:00.0 [1b21:2421] +- 10:01.0 [1b21:2423] -> 45:00.0 -> 46:00.0 | -> 47:00.0 -> 48:00.0 -> 49:00.0 [1002:7590] \- 10:03.0 -> 76:00.0 [1b21:2425] USB4 Host Router The host router is outside the GPU upstream bridge chain, leaving no ancestor with is_thunderbolt set. PCI core propagates DEVICE_REMOVABLE below the external-facing PCIe tunnel. Disable Runtime PM when either pci_is_thunderbolt_attached() or dev_is_removable() is true. Cc: stable@vger.kernel.org Signed-off-by: Yang Wang Reviewed-by: Candice Li Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher [ sashal: Adapted the context to this tree's older code, where amdgpu_device_supports_baco() takes dev (a drm_device) instead of adev. ] Signed-off-by: Sasha Levin commit 9a96cf8dbb1bd2c1e906976e3d6a85ee3008874e Author: Tiezhu Yang Date: Mon Aug 17 22:07:14 2026 +0800 LoongArch: Expand module virtual address space to 2GB [ Upstream commit 18210a104bb97e28c26dc31fd9fc7b5c381fec62 ] The current 256MB module virtual address space is easily exhausted when loading massive graphics drivers such as amdgpu along with the large unstripped symbol tables, resulting in allocation failures of "execmem: unable to allocate memory". Thus, expand the module virtual address space to 2GB while keeping the current normal code model '-mcmodel=normal', rather than using the medium code model '-mcmodel=medium'. This approach avoids the extra performance overhead and larger binary size of forcing every function call into a 2-instruction sequence of 'pcaddu18i + jirl'. Given that individual module code segments rarely exceed 128MB, most jumps remain fast direct calls by using the bl instruction. For the long-distance jumps exceeding the +/-128MB limit, apply_r_larch_b26() emits PLT entries, while signed_imm_check() guarantees the run-time safety by rejecting any out-of-bound instruction offsets. There is still a risk that the distance between .init.text and .text of the same module exceeds 128MB. So we divide the 2GB virtual space to be two sub-regions: the first 256MB is for module text, and the rest is for module data. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen [ sashal: Adapted the hunk context to this tree, where the MODULES_VADDR defines sit outside CONFIG_64BIT and the init guard is plain CONFIG_EXECMEM, leaving the changed lines identical to upstream. ] Signed-off-by: Sasha Levin commit 48d34dc062eb15614d2c506a83b19866f7acb6d7 Author: fangqiurong Date: Fri Aug 14 11:26:23 2026 +0800 sched_ext: Fix exit_task leak on fork failure during enable [ Upstream commit 03506edca637a8465dba9f635c50e9884fbcaf4e ] scx_fork() initializes tasks when scx_init_task_enabled is set, but scx_cancel_fork() only exits them when scx_enabled() is true. A fork that fails in the enable window (between releasing scx_fork_rwsem and setting __scx_enabled) runs ops.init_task() but never ops.exit_task(). Gate scx_cancel_fork() on scx_init_task_enabled. Fixes: 4269c603cc26 ("sched_ext: Enable scx_ops_init_task() separately") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: fangqiurong Signed-off-by: Tejun Heo [ sashal: Applied the fix to kernel/sched/ext.c with the older variable name scx_ops_init_task_enabled in place of scx_init_task_enabled. ] Signed-off-by: Sasha Levin commit 80f42de91c571754cb46b3098e76a8c136d9acc9 Author: Denis Batishchev Date: Mon Aug 10 17:14:41 2026 +0200 ALSA: hda/realtek: Enable micmute LED on HP EliteBook 6 G1a p/n: AD3Q9ET#UUG [ Upstream commit e7da28b820d12927de30abf554c727a319f80359 ] The HP EliteBook 6 G1a (SSID 103c:8e0d) uses a Realtek ALC236 codec. Without a quirk no fixup is selected and the mic-mute LED stays off. It needs the same ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk as the already-supported 14" variant (SSID 103c:8dfb), so add it. Signed-off-by: Denis Batishchev Cc: Link: https://patch.msgid.link/20260810151440.2306217-2-ii343hbka@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2008229271621390e091f5dbe61a3246409610fc Author: Jeff Layton Date: Thu Jun 11 16:00:56 2026 -0400 nfsd: use test_and_clear_bit for somebody_reclaimed to prevent lost update [ Upstream commit 0a5a548861ab09e79a6b3062ac17e410323af3cd ] clients_still_reclaiming() uses separate test_bit() and clear_bit() calls on NFSD_NET_SOMEBODY_RECLAIMED. A concurrent set_bit() from the OPEN or LOCK reclaim path arriving between the test and clear is silently lost, causing the next laundromat tick to end grace prematurely. Replace with test_and_clear_bit() to make the read-and-clear atomic. Fixes: 8c67a210c90c ("nfsd: convert nfsd_net boolean flags to unsigned long flags word") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-13-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 2b7d0e7dfbeabfb2eb4bbdeb08e9d5a0d954034a Author: Thomas Gleixner Date: Fri Aug 7 17:07:08 2026 +0200 futex: Sanitize and document task_struct::futex::state transitions [ Upstream commit f9ece060cc43eae8a1f148737d193ba0d07b8f88 ] The futex state is used to prevent a waiter from attaching to the lock owner while the owner runs the futex cleanup in exit() or exec(). Only the state transition from FUTEX_STATE_OK to FUTEX_STATE_EXITING must be done with the task's pi_lock held, the transition away from FUTEX_STATE_EXITING has no serialization requirements on the writer side, but it's completely non obvious why. It's magically protected by exit_pi_state(), which operates under tsk::pi_lock, as that's the state which has to be correct when the waiter observes the new state. OTOH, taking the pi_lock in futex_cleanup_end() is not a performance issue because at that point the lock should be uncontended in the vast majority of cases. Aside of that the handling of FUTEX_STATE_EXITING in attach_to_pi_owner() and handle_exit_race() is confusing at best. Protect the store in futex_cleanup_end() with tsk::pi_lock, handle FUTEX_STATE_EXITING in attach_to_pi_owner() explicitly and document how this is supposed to work. Reported-by: Peter Zijlstra Signed-off-by: Thomas Gleixner Reviewed-by: Kyle Zeng Acked-by: Peter Zijlstra Cc: stable@vger.kernel.org [ sashal: Adapted to the older field names tsk->futex_state and futex_exit_mutex instead of tsk->futex.state and futex::exit_mutex, with context adjusted for the missing private-mm check. ] Signed-off-by: Sasha Levin commit 7bc109b41a12c18d6c8445bd8e739aa1d7559b62 Author: Bibo Mao Date: Mon Aug 10 12:21:50 2026 +0800 LoongArch: KVM: Set vcpu->cpu before IN_GUEST_MODE is set [ Upstream commit 32d05564a6128d59ea876cf9078fe6866a809e14 ] In function kvm_make_vcpu_request(), it will send IPI to physical CPU when vCPU is in IN_GUEST_MODE mode. And physical CPU is set in function kvm_check_vpid(), thus it should be called before IN_GUEST_MODE is set. Otherwise IPI will send to wrong old physical CPU where vCPU is running. Cc: stable@vger.kernel.org Fixes: 2fc3bd86db4b ("LoongArch: KVM: Implement basic vcpu interfaces") Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 92ea274f2a6b550c41daa7a94155e4822ca47b17 Author: Bibo Mao Date: Thu Jun 11 20:46:43 2026 +0800 LoongArch: KVM: Deliver interrupt after IN_GUEST_MODE is set [ Upstream commit 8c5cd2b9d6a724998c1ab9af06ac897b6152d568 ] Interrupt delivery should be called after IN_GUEST_MODE is set. Other threads may be posting interrupt however does not send IPI to the vCPU, since the vCPU is not in IN_GUEST_MODE yet. Here move function call with kvm_deliver_intr() after IN_GUEST_MODE is set, and set mode with OUTSIDE_GUEST_MODE with atomic method. Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Stable-dep-of: 32d05564a612 ("LoongArch: KVM: Set vcpu->cpu before IN_GUEST_MODE is set") Signed-off-by: Sasha Levin commit 694d3607c0dfe8313de95b2324912b32022c9b56 Author: Bibo Mao Date: Thu Apr 9 18:56:36 2026 +0800 LoongArch: KVM: Check kvm_request_pending() in kvm_late_check_requests() [ Upstream commit 14d2714d6537a9df5bea2515185034dbb9d30f03 ] Add kvm_request_pending() checking firstly in kvm_late_check_requests(), at most time there is no pending request, then the following pending bit checking can be skipped. Also embed function kvm_check_pmu() in to kvm_late_check_requests(), and put it after the kvm_request_pending() checking. Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Stable-dep-of: 32d05564a612 ("LoongArch: KVM: Set vcpu->cpu before IN_GUEST_MODE is set") Signed-off-by: Sasha Levin commit 1adde9691d0b0ea65917fa44ad50f84f2b48e679 Author: Bibo Mao Date: Sun Nov 9 16:02:09 2025 +0800 LoongArch: KVM: Skip PMU checking on vCPU context switch [ Upstream commit 11f340ece403e71aa2b643a2562a58ed3ac12e2c ] PMU hardware about VM is switched on VM exit to host rather than vCPU context sched off, PMU is checked and restored on return to VM. It is not necessary to check PMU on vCPU context sched on callback, since the request is made on the VM exit entry or VM PMU CSR access abort routine already. Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Stable-dep-of: 32d05564a612 ("LoongArch: KVM: Set vcpu->cpu before IN_GUEST_MODE is set") Signed-off-by: Sasha Levin commit 77eee0805d5ea993299d18c2b2e9ddec288a3b93 Author: Adrian Hunter Date: Fri Aug 7 17:56:30 2026 +0300 i3c: master: Fix potential UAF in i3c_device_uevent() [ Upstream commit e5e8dd2e959f470524c16ca444d001c90d6bb3ad ] i3c_device_uevent() dereferences i3cdev->desc without holding the bus normal-use lock. Since the descriptor pointer can be replaced concurrently, including when a uevent is generated from sysfs, this can result in dereferencing a stale descriptor and lead to a use-after-free. Use i3c_device_get_info() instead, which protects access to the descriptor with the normal-use lock. Commit 6cf7b65f7029 ("i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock") replaced the accessor with a direct descriptor dereference because i3c_device_get_info() would recursively acquire bus->lock during device registration. This change depends on "i3c: master: Fix recursive locking during device registration", which moves device registration out from under bus->lock and removes the possibility of that deadlock. Without that change, restoring the i3c_device_get_info() call would reintroduce the deadlock. Fixes: 6cf7b65f7029 ("i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock") Cc: stable@vger.kernel.org # requires "i3c: master: Fix recursive locking during device registration" Signed-off-by: Adrian Hunter Acked-by: Mukesh Savaliya Reviewed-by: Frank Li Link: https://patch.msgid.link/20260807145638.168865-7-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 5fa7d671d65c8a6a13a3a12b09eb70159942e565 Author: Guopeng Zhang Date: Mon Jul 13 16:57:56 2026 +0800 mm: memcg-v1: fix wrong linux-mm list address in deprecation warnings [ Upstream commit 45b1ec4887bdcc58af885540d9fefa8b67d17d57 ] The deprecation warnings for memory.oom_control and memory.pressure_level use linux-mm-@kvack.org instead of the linux-mm mailing list address. Remove the extra hyphen. Link: https://lore.kernel.org/20260713085756.2973549-1-guopeng.zhang@linux.dev Signed-off-by: Guopeng Zhang Acked-by: Michal Hocko Acked-by: Johannes Weiner Reviewed-by: Muchun Song Acked-by: Shakeel Butt Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit b1448f8d9fed4e10c58fdc7623b49b792084e491 Author: Keren Sun Date: Fri Nov 15 15:57:43 2024 -0800 mm: remove unnecessary whitespace before a quoted newline [ Upstream commit 91478b238e584d0ec1ea8c58ef46e4e14d58e526 ] Remove whitespaces before newlines for strings in pr_warn_once() Link: https://lkml.kernel.org/r/20241115235744.1419580-3-kerensun@google.com Signed-off-by: Keren Sun Reviewed-by: Roman Gushchin Cc: Johannes Weiner Cc: Michal Hocko Cc: Muchun Song Cc: Shakeel Butt Signed-off-by: Andrew Morton Stable-dep-of: 45b1ec4887bd ("mm: memcg-v1: fix wrong linux-mm list address in deprecation warnings") Signed-off-by: Sasha Levin commit db07e9b0320e480f05f5c12e8e4d6699f0d3acb7 Author: Thiébaud Weksteen Date: Wed Jul 8 11:21:07 2026 +1000 module: validate string table section types [ Upstream commit 9a5ff45689329835f874cefe5174e577d141d423 ] In elf_validity_cache_sechdrs, section sizes and offsets are validated, unless the section type is SHT_NULL or SHT_NOBITS. Later, elf_validity_cache_secstrings and elf_validity_cache_index_str access the section name table (.shstrtab) and symbol string table (.strtab) headers without first ensuring that their types are SHT_STRTAB. If a section type is SHT_NULL or SHT_NOBITS, sh_offset has not been validated and may reference out-of-bounds memory when dereferenced in elf_validity_cache_secstrings or elf_validity_cache_strtab. Validate that both string section headers are of type SHT_STRTAB before caching them. Cc: stable@vger.kernel.org Signed-off-by: Thiébaud Weksteen Reviewed-by: Aaron Tomlin Reviewed-by: Petr Pavlu Signed-off-by: Petr Pavlu Signed-off-by: Sasha Levin commit 3eafa6b2e38ec468edda97fd6f78f3619af9d898 Author: Matthew Maurer Date: Tue Oct 15 23:16:42 2024 +0000 module: Factor out elf_validity_cache_index_str [ Upstream commit 0a9395334496d3be8bde491e46087540cb8f141d ] Pull out index validation for the symbol string section. Note that this does not validate the *contents* of the string table, only shape and presence of the section. Signed-off-by: Matthew Maurer Reviewed-by: Sami Tolvanen Signed-off-by: Luis Chamberlain Stable-dep-of: 9a5ff4568932 ("module: validate string table section types") Signed-off-by: Sasha Levin commit a19215105674a425861ae1edc547e7dcfcc6ff38 Author: Matthew Maurer Date: Tue Oct 15 23:16:41 2024 +0000 module: Factor out elf_validity_cache_index_sym [ Upstream commit 9bd4982cf7d65f4c9e0793d5a8fda6ad838e8554 ] Centralize symbol table detection and property validation. Signed-off-by: Matthew Maurer Reviewed-by: Sami Tolvanen Signed-off-by: Luis Chamberlain Stable-dep-of: 9a5ff4568932 ("module: validate string table section types") Signed-off-by: Sasha Levin commit ea97ea606363c681312120e05eb443e854b74d14 Author: Matthew Maurer Date: Tue Oct 15 23:16:40 2024 +0000 module: Factor out elf_validity_cache_index_mod [ Upstream commit 0be41a9367d1fbb16b4b57d81082341af114bad7 ] Centralize .gnu.linkonce.this_module detection and property validation. Signed-off-by: Matthew Maurer Reviewed-by: Sami Tolvanen Signed-off-by: Luis Chamberlain Stable-dep-of: 9a5ff4568932 ("module: validate string table section types") Signed-off-by: Sasha Levin commit a1648f82ec44fa1ab8beb0923ca7c2038f93a5f2 Author: Matthew Maurer Date: Tue Oct 15 23:16:39 2024 +0000 module: Factor out elf_validity_cache_index_info [ Upstream commit fbc0e4e482aac7f2b0d20f0a11f6d5eeda346fda ] Centralize .modinfo detection and property validation. Signed-off-by: Matthew Maurer Reviewed-by: Sami Tolvanen Signed-off-by: Luis Chamberlain Stable-dep-of: 9a5ff4568932 ("module: validate string table section types") Signed-off-by: Sasha Levin commit 930088ffcbb346330d1c52f1405f9604408c1f35 Author: Matthew Maurer Date: Tue Oct 15 23:16:38 2024 +0000 module: Factor out elf_validity_cache_secstrings [ Upstream commit 3c5700aeabd87e81d9153a7666b28d0e405c6c88 ] Factor out the validation of section names. There are two behavioral changes: 1. Previously, we did not validate non-SHF_ALLOC sections. This may have once been safe, as find_sec skips non-SHF_ALLOC sections, but find_any_sec, which will be used to load BTF if that is enabled, ignores the SHF_ALLOC flag. Since there's no need to support invalid section names, validate all of them, not just SHF_ALLOC sections. 2. Section names were validated *after* accessing them for the purposes of detecting ".modinfo" and ".gnu.linkonce.this_module". They are now checked prior to the access, which could avoid bad accesses with malformed modules. Signed-off-by: Matthew Maurer Reviewed-by: Sami Tolvanen Signed-off-by: Luis Chamberlain Stable-dep-of: 9a5ff4568932 ("module: validate string table section types") Signed-off-by: Sasha Levin commit f19f1a1c5fe56274e95b342e8138f4b774febf97 Author: Matthew Maurer Date: Tue Oct 15 23:16:37 2024 +0000 module: Factor out elf_validity_cache_sechdrs [ Upstream commit c92aab819d56d51631f0484ed7af11d9d8ff4cb0 ] Factor out and document the validation of section headers. Because we now validate all section offsets and lengths before accessing them, we can remove the ad-hoc checks. Signed-off-by: Matthew Maurer Reviewed-by: Sami Tolvanen Signed-off-by: Luis Chamberlain Stable-dep-of: 9a5ff4568932 ("module: validate string table section types") Signed-off-by: Sasha Levin commit 0942824a099f964eca7bb82dcaa395d0b89bc557 Author: Matthew Maurer Date: Tue Oct 15 23:16:36 2024 +0000 module: Factor out elf_validity_ehdr [ Upstream commit 90f8f312db720dbabec7c6258ef580b50129cc21 ] Factor out verification of the ELF header and document what is checked. Signed-off-by: Matthew Maurer Reviewed-by: Sami Tolvanen Signed-off-by: Luis Chamberlain Stable-dep-of: 9a5ff4568932 ("module: validate string table section types") Signed-off-by: Sasha Levin commit 26d285b8a5135ed86005ce35f2e33c82516da033 Author: Stanislaw Gruszka Date: Fri Mar 27 12:00:04 2026 +0100 module/kallsyms: fix nextval for data symbol lookup [ Upstream commit 0e9f090a4e9bfae5a190ccf89eab3bf14f6b0f96 ] The symbol lookup code assumes the queried address resides in either MOD_TEXT or MOD_INIT_TEXT. This breaks for addresses in other module memory regions (e.g. rodata or data), resulting in incorrect upper bounds and wrong symbol size. Select the module memory region the address belongs to instead of hardcoding text sections. Also initialize the lower bound to the start of that region, as searching from address 0 is unnecessary. Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka Reviewed-by: Petr Pavlu Signed-off-by: Petr Pavlu Signed-off-by: Sasha Levin commit a1dec7a90d3bd77906c02567e68056deda01114a Author: Sebastian Andrzej Siewior Date: Wed Jan 8 10:04:33 2025 +0100 module: Use RCU in find_kallsyms_symbol(). [ Upstream commit f01369239293e4900af7be673e0fd26fe54f85e1 ] The modules list and module::kallsyms can be accessed under RCU assumption. Use rcu_dereference() to reference the kallsyms pointer in find_kallsyms_symbol(). Use a RCU section instead of preempt_disable in callers of find_kallsyms_symbol(). Keep the preempt-disable in module_address_lookup() due to __module_address(). Signed-off-by: Sebastian Andrzej Siewior Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20250108090457.512198-5-bigeasy@linutronix.de Signed-off-by: Petr Pavlu Stable-dep-of: 0e9f090a4e9b ("module/kallsyms: fix nextval for data symbol lookup") Signed-off-by: Sasha Levin commit 3a447dd02129693bd84e6b16b2e91d9e341b3fc4 Author: Jose Villaseñor Montfort Date: Tue Jul 28 14:13:09 2026 -0600 HID: input: read battery capacity from its actual report offset [ Upstream commit d07644524b6511b622ee7b0e2e68c9ee43d522a4 ] hidinput_query_battery_capacity() assumes the state-of-charge value is the first byte following the report ID (buf[1]) and ignores where the battery field actually sits within the report. An Apple Magic Trackpad 2 precedes the AbsoluteStateOfCharge byte with a byte of status flags in its battery reports, so this query returns the flags byte instead of the charge level. The device happens to make that easy to observe, because it exposes the same cell twice: its report descriptor declares AbsoluteStateOfCharge in two reports (0x90 and 0x9b), so hidinput_setup_battery() registers two power supplies. Only the first one is refreshed by hid-magicmouse -- it uses hid_get_battery(), which returns the first battery of the list -- and that refresh goes through the report event path, which parses the field correctly. Nothing ever reports the second one, so every read of its capacity takes the query path above. On a USB-C Magic Trackpad over USB, on an unpatched 7.1.5: hid--battery-144 = 100% (Charging) <- report event path hid--battery-155 = 3% (Discharging) <- query path Both are the same physical battery. A raw HIDIOCGINPUT of the two reports at that same moment: report 0x90 -> [90 03 64] report 0x9b -> [9b 03 64 64 00 00 10 00 00 00 00 00 00 00] ^flags ^SoC = 0x64 = 100% The device answers correctly in both cases; only the offset the kernel reads the capacity from is wrong. 0x03 is the flags byte (present, charging), reported as "3%". Bluetooth takes the same query path for its capacity, where the trackpad reported a bogus near-constant ~4% -- 0b100, the FullyCharged flag -- regardless of the real charge. Store the battery field's offset within the report at setup time and use it when querying, so the capacity is read from its real position. The report event path already parses the field correctly through the HID core; only the explicit GET_REPORT query was wrong. Devices whose capacity field is the first field in the report have a report_offset of 0 and are unaffected (buf[1 + 0] == buf[1]). Fixes: 581c4484769e ("HID: input: map digitizer battery usage") Cc: stable@vger.kernel.org Signed-off-by: Jose Villaseñor Montfort Reviewed-by: Alec Hall Signed-off-by: Jiri Kosina [ sashal: Adapted to the older HID layout by storing the battery report offset as a flat battery_report_offset field in struct hid_device instead of struct hid_battery, and keeping manual kfree() instead of __free(kfree). ] Signed-off-by: Sasha Levin commit 5d56d75d2fbd36c66826bee6e0ae01eb2c2f5550 Author: Dev Jain Date: Fri Jul 3 11:41:57 2026 +0000 mm/migrate: use huge_ptep_get() in remove_migration_pte() [ Upstream commit ac1ec50d71b953524100ddc09057ee61a3dfaff3 ] remove_migration_pte() converts migration entries back to present PTEs after folio migration completes. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get(). On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave. It is not clear whether this has a trivially visible effect to userspace. Use huge_ptep_get() to dereference a huge pte pointer. Link: https://lore.kernel.org/20260703114202.365553-5-dev.jain@arm.com Fixes: 290408d4a250 ("hugetlb: hugepage migration core") Signed-off-by: Dev Jain Acked-by: Muchun Song Acked-by: David Hildenbrand (Arm) Cc: Alistair Popple Cc: Andi Kleen Cc: Anshuman Khandual Cc: Byungchul Park Cc: Catalin Marinas Cc: Dave Hansen Cc: Gregory Price Cc: Harry Yoo Cc: "Huang, Ying" Cc: Jann Horn Cc: Josh Poimboeuf Cc: Joshua Hahn Cc: Jun'ichi "Nick" Nomura Cc: Kiryl Shutsemau Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Mel Gorman Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Pedro Falcato Cc: Rakie Kim Cc: Ralph Campbell Cc: Rik van Riel Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Will Deacon Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e1f0748db452f9e5f4ae0fe81ec9ef178219633e Author: Dev Jain Date: Fri Jul 3 11:41:56 2026 +0000 mm/rmap: use huge_ptep_get() in try_to_migrate_one() [ Upstream commit 9be12ffa78cd087d41086f937a156435d4e588e9 ] try_to_migrate_one() is used by folio migration to replace a present mapping with a migration entry. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads the huge pte entry with ptep_get(). On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave. It is not clear whether this has a trivially visible effect to userspace. Use huge_ptep_get() to dereference a huge pte pointer. Commit a98a2f0c8ce1 copied the bug from try_to_unmap_one into try_to_migrate_one. [akpm@linux-foundation.org: coding-style cleanups] Link: https://lore.kernel.org/20260703114202.365553-4-dev.jain@arm.com Fixes: a98a2f0c8ce1 ("mm/rmap: split migration into its own function") Signed-off-by: Dev Jain Acked-by: Muchun Song Acked-by: David Hildenbrand (Arm) Cc: Alistair Popple Cc: Andi Kleen Cc: Anshuman Khandual Cc: Byungchul Park Cc: Catalin Marinas Cc: Dave Hansen Cc: Gregory Price Cc: Harry Yoo Cc: "Huang, Ying" Cc: Jann Horn Cc: Josh Poimboeuf Cc: Joshua Hahn Cc: Jun'ichi "Nick" Nomura Cc: Kiryl Shutsemau Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Mel Gorman Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Pedro Falcato Cc: Rakie Kim Cc: Ralph Campbell Cc: Rik van Riel Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Will Deacon Cc: Zi Yan Cc: Signed-off-by: Andrew Morton [ sashal: Kept the tree's existing pfn/zone-device code and added only the hugetlb huge_ptep_get() read, skipping the upstream softleaf and pteval rewrite. ] Signed-off-by: Sasha Levin commit f6bce546fcd62011f28668af00abf91f7c527f65 Author: Mario Limonciello Date: Tue Jul 21 13:17:52 2026 -0500 platform/x86/amd/pmc: Fix msg_port restoration in amd_stb_debugfs_open_v2() [ Upstream commit cbb32ff92f8a62212e0f7384b1de986ced92082b ] amd_stb_debugfs_open_v2() switches dev->msg_port to MSG_PORT_S2D to query S2D telemetry but only restores it to MSG_PORT_PMC on one path. The early return on the dump_custom_stb path (and the error/allocation returns) leave the port stuck on MSG_PORT_S2D, so subsequent SMU communication - including the s2idle prepare/restore handlers - is directed at the wrong mailbox. Consolidate the exit path through a single label so the message port is always restored, mirroring the fix in amd_stb_s2d_init(). Reported-by: sashiko.dev Link: https://sashiko.dev/#/patchset/20260717162023.956346-1-mario.limonciello%40amd.com Fixes: 2851f4f8ed4e ("platform/x86/amd/pmc: Define enum for S2D/PMC msg_port and add helper function") Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260721181756.143084-3-mario.limonciello@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen [ sashal: Kept this tree's older names (amd_pmc_stb_v2_data, amd_pmc_stb_handle_efr) and its kmalloc(struct_size(...), GFP_KERNEL) call instead of kmalloc_flex when applying the msg_port restoration. ] Signed-off-by: Sasha Levin commit 9aad3e3a40f667ef244c570ccebf1830d1f56d76 Author: Lukas Wunner Date: Fri Jul 24 17:24:04 2026 +0200 PCI/AER: Emit TLP Log only for unmasked errors [ Upstream commit a8bf2dd750de7d682fdaa2127f4e3217ce9c4a82 ] Per PCIe r7.0 sec 6.2.5, the prefix and header of an offending TLP is only recorded for unmasked Uncorrectable Errors. Yet when the AER driver determines whether a prefix and header has been logged, it does not take the Uncorrectable Error Mask Register into account. Fix it. Fixes: 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver") Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v2.6.19+ Link: https://patch.msgid.link/2e712b96ba5bfc729d78bfc23f7fb7d285aa3d6d.1784905909.git.lukas@wunner.de [ sashal: Open-coded the unmasked-status check as (status & ~mask) & AER_LOG_TLP_MASKS in two places, since this tree has no tlp_header_logged() helper to modify. ] Signed-off-by: Sasha Levin commit 9ed109a49624a687155eecd8ec2a948f4e2c6229 Author: Lukas Wunner Date: Fri Jul 24 17:24:01 2026 +0200 PCI/AER: Fix mapping of errors to agent & layer [ Upstream commit 1017599755b8b578a671f8fac175bce56189d01c ] PCIe r7.0 sec 6.2.7 documents the agent and layer of each Correctable and Uncorrectable Error. Based on this spec section, the AER driver maps detected errors to an agent and layer using a set of macros and logs them. Most errors listed in sec 6.2.7 map to the "Receiver" agent and "Transaction Layer", so the macros use these as defaults unless an error maps to something else. However the macros have not been amended since their introduction in 2006 with commit 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver"). They are still based on PCIe r1.0 sec 7.2.5 (renumbered to 6.2.7 in PCIe r1.1 and newer). Amend the macros to map errors introduced since then to the appropriate agent and layer. PCIe r2.1 introduced a new "Component" agent and "General" layer for Internal Errors and Header Log Overflow. Add them to the macros. Unsupported Request is currently mapped to the "Requester" agent, even though it is reported by the "Receiver". Fix the incorrect mapping. Sec 6.2.7 neglects to list an agent for Data Link Protocol Error and Surprise Down Error. Map the latter to "Component" because PCIe r7.0 sec 3.2.1 states that the error is "associated with the detecting Port". Map the former to "Receiver" because every occurrence of Data Link Protocol Error in the spec refers to it being logged in the Receiving Port. I have had these errata reported to the PCI-SIG Protocol Working Group. (There's also a layout erratum in the REPLAY_NUM Rollover row wherein columns are shifted to the left, but that's already corrected in the PCIe r7.1 draft as of 2026-04-07.) Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/aec4820a75e949b332585a08cb1808fda7f40ea4.1784905909.git.lukas@wunner.de [ sashal: Added the six missing PCI_ERR_UNC_* bit 26–31 defines to pci_regs.h, since the new transmitter mask needs them and this tree lacks them. ] Signed-off-by: Sasha Levin commit ad9d1d929939e5ad0d258ddb8366173e96489778 Author: Yosry Ahmed Date: Mon Jul 13 18:10:18 2026 +0000 KVM: x86: Always initialize EFER reserved bits on vendor initialization [ Upstream commit a4b8acd428ba3f03952ef309d7f438dbc357557b ] EFER reserved bits are statically initialized, and do not reset if a vendor module is re-loaded. For example, loading kvm_amd with nested=1 removes EFER.SVME (and potentially EFER.LMSLE) from the reserved bits. Reloading kvm_amd with nested=0 does not add them back, allowing userspace to set EFER.SVME with nested=0. Re-initializing EFER reserved bits before configuring them on vendor initialization. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260713181020.2735367-4-yosry@kernel.org Signed-off-by: Sean Christopherson [ sashal: Applied the EFER reserved-bits reset inline in kvm_x86_vendor_init() in x86.c, just before hardware_setup(), instead of in a new kvm_init_efer_bits() helper called from kvm_setup_efer_caps() in msrs.c. ] Signed-off-by: Sasha Levin commit 9c757d77a6eb58ca4a47cada5ab60451e6c2d247 Author: Jackson Lee Date: Fri Jun 26 10:22:32 2026 +0900 media: chips-media: wave5: Resume device before setting EOS flag [ Upstream commit a52e6f7923c17a672135b485ffd96fbd72f46267 ] Setting the EOS flag talks to the firmware via send_firmware_command(), which accesses VPU registers. Both the STREAMOFF path (wave5_vpu_dec_job_abort()) and the V4L2_DEC_CMD_STOP path (wave5_vpu_dec_stop()) can run while the device is runtime suspended, so those register accesses hit powered-down hardware and the SoC raises an asynchronous SError, panicking the kernel: SError Interrupt on CPU3, code 0x00000000bf000000 -- SError send_firmware_command+0x2c/0x160 [wave5] wave5_vpu_dec_set_bitstream_flag+0x6c/0x80 [wave5] wave5_vpu_dec_update_bitstream_buffer+0x80/0xec [wave5] wave5_vpu_dec_job_abort+0x44/0xa0 [wave5] v4l2_m2m_cancel_job+0x110/0x19c [v4l2_mem2mem] v4l2_m2m_streamoff+0x24/0x140 [v4l2_mem2mem] Resume the device with pm_runtime_resume_and_get() around the EOS firmware command and release it with pm_runtime_put_autosuspend(), matching the runtime PM handling already done in wave5_vpu_dec_device_run(). Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil [ sashal: Guarded the pm_runtime_put_autosuspend() calls on a successful pm_runtime_resume_and_get() and added the missing pm_runtime.h include, instead of putting unconditionally as upstream does. ] Signed-off-by: Sasha Levin commit f018a483a83ca29e1e8401f45b350639117e8f7b Author: Jackson Lee Date: Fri Jun 26 10:22:27 2026 +0900 media: chips-media: wave5: Set inst->std during default format initialization [ Upstream commit cfcefc5a996f6a00b310c963b5f811430f28a30a ] When the encoder is opened, wave5_set_default_format() sets up the default capture format (e.g. H.264) but does not initialize inst->std. As a result, inst->std remains zero, which does not match any valid encoder codec. If STREAMON is called before the user explicitly calls S_FMT on the capture queue — as v4l2-compliance does in testBlockingDQBuf — the codec/product check in wave5_vpu_enc_init_seq() fails with "Unsupported encoder-codec & product combination" because inst->std is neither W_HEVC_ENC nor W_AVC_ENC, returning -EOPNOTSUPP. Fix this by setting inst->std via wave5_to_vpu_std() in wave5_set_default_format(), so that the codec type is always consistent with the default capture pixel format from the moment the instance is opened. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil [ sashal: Adapted wave5_set_default_format() to the older function body (fixed 416x240 format setup) and dropped the conf_win context lines this tree lacks, keeping the added inst->std assignment unchanged. ] Signed-off-by: Sasha Levin commit b3a6f2e19a9d72df303250c2dd7caacd913d84ee Author: Sean Christopherson Date: Thu Jul 9 13:49:39 2026 -0700 KVM: x86/mmu: Use split "zap all fast" helpers when invalidating memslot [ Upstream commit db095727ff5739f4f46ee641ee6ef450032886db ] Manually invoke the front half and back half of the "zap all fast" flow when invalidating a memslot so that mmu_lock is acquired at function scope in kvm_arch_flush_shadow_memslot(). This will allow putting more code inside the critical section without having to take mmu_lock twice in quick succession. Opportunistically open code checking whether or not to do the fast zap, to discourage removing the local "zap_all" in a future cleanup, i.e. to ensure the SLOT_ZAP_ALL quirk is queried exactly once. Processing the front half but not the back half of the fast zap (if SLOT_ZAP_ALL were disabled concurrently) would result in KVM unnecessarily keeping invalid TDP MMU roots until the VM is destroyed. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-10-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit 57410e3ec1ecb2eb61eef90559626017d8314d48 Author: Sean Christopherson Date: Thu Jul 9 13:49:33 2026 -0700 KVM: SEV: Mark vCPU RUNNABLE after AP_CREATE, even if VMSA is unusable [ Upstream commit 98ade8c48c28c227fe2e80e545ff0c57cd4712a3 ] Always mark the vCPU as RUNNABLE after responding to AP_CREATE, even if the guest-specified VMSA is unusable, e.g. isn't backed by a memslot or doesn't have a backing guest_memfd page. If the VMSA is unusable, leaving the vCPU in a non-running state will effectively hang the vCPU instead of reporting an error to userspace. This will also allow retrying the VMSA load in the future, to fix a bug where KVM doesn't honor guest_memfd invalidation events, e.g. if AP_CREATION races with PUNCH_HOLE. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-4-seanjc@google.com Signed-off-by: Sean Christopherson [ sashal: Replaced the missing kvm_set_mp_state() helper with open-coded pv_unhalted/mp_state assignments, and the function is non-static in this tree. ] Signed-off-by: Sasha Levin commit 55d518095ea4a84c5c7134d4669a4999b37f82e0 Author: Sean Christopherson Date: Thu Jul 9 13:49:32 2026 -0700 KVM: SEV: Extract loading of guest-provided VMSA to a separate helper [ Upstream commit 0060569e4f18a7dee2dd8728595e909f19a23c24 ] Extract the loading/retrieval of a guest-provided VMSA to a separate helper so that KVM can reuse the core logic when refreshing the VMSA after an MMU invalidation from guest_memfd. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-3-seanjc@google.com Signed-off-by: Sean Christopherson [ sashal: Kept the non-static function and its sev_snp_guest() check, and used direct mp_state assignments and kvm_release_pfn_clean(pfn) in place of kvm_set_mp_state() and the page-based release. ] Signed-off-by: Sasha Levin commit e2d16c2128f59f76f8473fd0a7c952331c72c817 Author: Julian Haarmann Date: Sun Jun 14 22:30:26 2026 +0200 platform/x86: lenovo/ymc: Only match lower byte in WMI lid switch query response [ Upstream commit bbc497b5231829d32c3a53b6e66be1add76c0064 ] On newer Lenovo Yoga devices like the "Yoga 9 2-in-1 14IPH11 - Type 83SE", the hinge switch WMI query returns extra data in the upper bits (e.g. 0x50001 laptop mode, 0x50002 tablet mode, ect.). The driver previously checked for exact matches (0x01 laptop, 0x02 tablet, ect.) causing newer switches to not work. Mask the WMI query result to only match the lower byte and ignore upper bits. Signed-off-by: Julian Haarmann Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260614203235.235724-1-julian.haarmann@student.kit.edu Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit fb63056a4c8ba3e771500af5dc9afaf40e1fbb89 Author: Matthew Auld Date: Fri Jun 12 18:05:02 2026 +0100 drm/xe/display: skip FORCE_WC and vm_bound check for external dma-bufs [ Upstream commit 3e493f88c84088ccd7b53cdd23ac5c875c9a60dd ] Currently, xe_display_bo_framebuffer_init() unconditionally attempts to apply XE_BO_FLAG_FORCE_WC to the buffer and rejects the FB creation with -EINVAL if the BO is already VM_BINDed. However, for imported dma-bufs (ttm_bo_type_sg), this check doesn't seem to make much sense since CPU caching policy is entirely controlled by the exporter. Plus there is no place to set this flag, in the first place. Also this is not rejected if not yet vm_binded, but that seems arbitrary since setting or not setting FORCE_WC should a noop either way, at this stage, and whether it is currently VM_BINDed makes no difference. Currently if we run an app and offload rendering to an external dGPU, like NV or another xe device, the dma-buf passed back to the compositor (igpu) will be an actual external import from xe pov, and it will be missing FORCE_WC, and if the compositor side did a VM_BIND before turning into it into an fb the whole thing gets rejected. So it looks like we either need to reject outright, no matter what, or this usecase is valid and we need to loosen the restriction for sg buffers. Proposing here to loosen the restriction. Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7919 Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: Maarten Lankhorst Cc: # v6.12+ Reviewed-by: Maarten Lankhorst Link: https://patch.msgid.link/20260612170501.550816-2-matthew.auld@intel.com [ sashal: Applied the sg-BO check to intel_fb_bo.c and intel_plane_pin_fb() instead of the refactored display file, and used the older XE_BO_FLAG_SCANOUT name in place of XE_BO_FLAG_FORCE_WC. ] Signed-off-by: Sasha Levin commit e3e03deb7455db7e955c9acc5f7db8f90494571d Author: Qing Luo Date: Mon Nov 2 01:53:45 2026 -0800 sctp: auth: discard auth_chunk when skb_clone fails [ Upstream commit 9ae7ed101cf28613071ebfbc42668c8917a670cf ] When processing AUTH + COOKIE-ECHO packets, if skb_clone() fails due to memory pressure, chunk->auth_chunk is NULL. The original code still sets chunk->auth = 1 and continues, leaving the COOKIE-ECHO to be processed without a valid auth_chunk for deferred verification. Discard the AUTH chunk early via pdiscard when skb_clone() fails, so that the receive loop can continue processing remaining chunks in the inqueue instead of stalling the entire packet. Signed-off-by: Qing Luo Acked-by: Xin Long Link: https://patch.msgid.link/20260723061107.384106-1-l1138897701@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Harshvardhan Jha Signed-off-by: Harshit Mogalapalli Signed-off-by: Sasha Levin commit 7999c8819f9991ed5c7f2c1f16efc902e32e4abc Author: Pablo Neira Ayuso Date: Sun Nov 1 15:27:30 2026 +0000 netfilter: nf_conntrack_expect: add and use nf_ct_expect_related_pair() commit 4aa63842fc92de1bce59d4709a0d32e718890bb2 upstream. Add a new function to insert a pair of expectations, this is required by the SIP and H323 NAT helpers. The spinlock is held to check if there is a slot for both expectations, in such case, insert them. This removes the need for nf_ct_unexpect_related() inside the loop to find a pair of consecutive ports, otherwise inserting expectations whose dead flag is already set on can happen. Bump master_help->expecting for the expectation class after checking if the expectation fits in the master expectation list, which is needed for this new _pair() function variant to run the eviction routine including the preallocated slot for the first expectation in the pair. [ Joas: nf_ct_expect_insert() and __nf_ct_expect_check() do not take a master_help argument in this tree, so keep their existing signatures; nf_ct_expect_related_report() gets master_help from nfct_help(expect->master) for the moved expecting[] increment. ] Fixes: b8b09dc2bf35 ("netfilter: nf_conntrack_expect: use conntrack GC to reap expectations") Reported-by: Jaeyeong Lee Link: https://patch.msgid.link/178377968720.33756.12204817361601593230@proton.me/ Signed-off-by: Pablo Neira Ayuso Signed-off-by: Joas Antonio dos Santos Signed-off-by: Sasha Levin commit 02c6acc1fc46301fe5017e11e0eccf3bbd1b09d2 Author: Bui Viet Dung Date: Thu Oct 8 20:07:53 2026 +0700 wwan: wwan_hwsim: Pin module for debugfs file operations commit a388f17e23b7e305cb306aafd73bb10d6b8ca452 upstream. An open debugfs file retains its file_operations pointer in the debugfs proxy state. However, wwan_hwsim_debugfs_portdestroy_fops, wwan_hwsim_debugfs_portcreate_fops, wwan_hwsim_debugfs_devdestroy_fops, and wwan_hwsim_debugfs_devcreate_fops in wwan_hwsim.c have no .owner set to THIS_MODULE. As a result, full_proxy_open_regular() calls fops_get() which succeeds without taking a reference to the wwan_hwsim module. When a userspace process opens any of these debugfs files, a subsequent module unload (rmmod wwan_hwsim) can succeed while the file descriptor remains open. When the userspace process subsequently closes the descriptor, full_proxy_release() accesses the already unmapped file_operations structure, triggering a kernel oops in full_proxy_release(): BUG: unable to handle page fault for address: fffffbfff84f90ef Oops: 0000 [#2] SMP KASAN NOPTI RIP: 0010:full_proxy_release+0x8e/0x140 Call Trace: __fput+0x357/0xaa0 fput_close_sync+0xe6/0x1a0 file_close_fd_locked+0x17e/0x2f0 do_close+0x33/0x70 __x64_sys_close+0x44/0x80 do_syscall_64+0xc3/0x590 entry_SYSCALL_64_after_hwframe+0x76/0x7e The issue was discovered via manual code audit of wwan_hwsim.c and reproduced on a Linux 7.3-rc6 test VM with CONFIG_WWAN_HWSIM=m. Set .owner = THIS_MODULE on all four debugfs file_operations structures in wwan_hwsim.c so that debugfs pins the module until close has completed. Fixes: 9ee23f48f670 ("wwan_hwsim: add debugfs management interface") Cc: stable@vger.kernel.org Signed-off-by: Bui Viet Dung Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20261008130753.313875-1-dungvn2345@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 0d7f6c2b3c07fa239ebc169280eba9932cc56f46 Author: Giorgi Kobakhia Date: Mon Sep 28 13:04:45 2026 -0700 udf: fix return value for non-recorded-allocated extents in udf_map_block() commit 0f242ca0878896df30292f4922700a32e8fdd039 upstream. When someone creates a corrupted UDF filesystem where symlink contains other extent type than EXT_RECORDED_ALLOCATED, it can leads to a crash like: Oops: general protection fault KASAN: maybe wild-memory-access RIP: 0010:page_get_link (fs/namei.c:6503) Call Trace: vfs_readlink (fs/namei.c:6419) do_readlinkat (fs/stat.c:583) __x64_sys_readlink (fs/stat.c:605 fs/stat.c:602 fs/stat.c:602) This is because in this case udf_map_block() fails to convert return value of inode_bmap() from 1 to 0. Returned '1' propagates through udf_bread() all the way up to __page_get_link() where it ends up being treated as a folio pointer with obvious results. Move the reset to 0 line outside the if, so udf_map_block() returns either 0 or -errno, even if the extent type is not EXT_RECORDED_ALLOCATED. Fixes: c226964ec786 ("udf: refactor inode_bmap() to handle error") Cc: stable@vger.kernel.org Assisted-by: LLM Tested-by: Xiang Mei Signed-off-by: Giorgi Kobakhia Link: https://patch.msgid.link/20260928200445.18722-1-gkobakhi@asu.edu Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit a7f354751b05ead5538176deadb9bc5b1fda0a3c Author: Jonathan Gopel Date: Sun Oct 4 11:13:50 2026 -0600 thunderbolt: Do not RPM complete unrelated subtrees on unplug commit 96a8479804e3f7af43e639e9df39f562f1a75fd5 upstream. When a Thunderbolt device is unplugged, that switch and every switch subsequent to it on the bus device list is `complete()`d, not just its child devices. In the case of multiple domains, it may cause, eg, an attempt to `complete()` the uninitialized domain 1 root switch RPM completion on unplug of a switch from domain 0 (though ordering is not guaranteed numerically sorted). I initially noticed this issue on a Dell XPS9720 when the system would seem to sporadically not wake after unplugging a Thunderbolt dock. I tried multiple kernel versions including v7.2.7 and v7.3-rc4 to see if that resolved the issue, but the issue persisted. Eventually I found that I could consistently generate a kernel Oops reporting a page fault at 0xffff_ffff_ffff_fff8 on unplug from one side of the laptop and went bug hunting. I became suspicious of the `bus_for_each_dev()` walk that I ultimately ended up changing. To confirm this issue, I did an eBPF trace of `bus_for_each_dev()`, `complete_rpm()`, and `complete()` while unplugging in a variety of situations and found that an unplug from domain 0 tries to `complete_rpm()` domain 1's switch, whose RPM completion is not initialized and thus is holding a null wait-list pointer, triggering the page fault. Here are the key sections of that eBPF trace. Note that HEAD denotes the completion's own wait-list HEAD: ``` RESCAN_ENTER domain=0 COMPLETE rescan_domain=0 target=0-1 target_domain=0 route=0x1 parent=0-0 unplugged=1 COMPLETION done=0 head=HEAD next=HEAD prev=HEAD BUS_WALK domain=0 start=0-1 callback=complete_rpm CALLBACK_ENTER rescan_domain=0 dev=1-0 parent=domain1 is_switch=1 COMPLETE rescan_domain=0 target=1-0 target_domain=1 route=0x0 parent=domain1 unplugged=0 COMPLETION done=0 head=HEAD next=0 prev=0 complete+5 complete_rpm+43 bus_for_each_dev+133 icm_free_unplugged_children+250 icm_rescan_work+42 ``` This patch gates the `complete()` on an additional condition - that the Thunderbolt domain matches the domain of the device that was unplugged. I only have a single system with multiple Thunderbolt domains - the Dell XPS9720. I am consistently able to reproduce the Oops on that system. Since running with this patch, I have not seen the Oops reoccur. I have also tested it on a Thinkpad X1-Gen12, and that system boots and runs well with it, but it only has a single Thunderbolt domain, so it does not exercise the multi-domain failure case. Fixes: 4f7c2e0d8765 ("thunderbolt: Make sure device runtime resume completes before taking domain lock") Cc: stable@vger.kernel.org Signed-off-by: Jonathan Gopel Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 6132073655e826052562f90f939f532aac6fbafe Author: Cen Zhang Date: Tue Oct 13 09:58:58 2026 +0800 ocfs2: publish the filecheck owner before adding sysfs attributes commit e062baf5680845705d21df415c8f0751c96b0792 upstream. ocfs2_filecheck_create_sysfs() initializes the filecheck allocation before calling kobject_init_and_add(), but assigns entry->fs_fcheck only after that call returns. The default attribute group can already be visible while registration is in progress. A concurrent read can therefore enter ocfs2_filecheck_attr_show() with a NULL fs_fcheck and try to lock its fc_lock. Assign the initialized owner before adding the kobject, so every activated attribute has valid state. Clear the pointer when addition fails, preserving the existing teardown guard and error cleanup. A controlled probe-instrumented test kernel with the original OCFS2 registration ordering produced this Oops during a concurrent sysfs read: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:kasan_byte_accessible+0x15/0x30 Call Trace: __kasan_check_byte+0x13/0x50 lock_acquire+0x113/0x300 _raw_spin_lock+0x31/0x40 ocfs2_filecheck_attr_show+0x138/0x5f0 ocfs2_filecheck_show+0x5d/0x90 sysfs_kf_seq_show+0x1d3/0x360 seq_read_iter+0x480/0x1110 kernfs_fop_read_iter+0x419/0x5a0 vfs_read+0x7d2/0xc20 ksys_read+0x111/0x200 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Modules linked in: Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0086-v4-1b3a3c5fd05c1fb41df9@gmail.com Fixes: 5f483c4abb50 ("ocfs2: add kobject for online file check") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Heming Zhao Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Gang He Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit ae5ea8ca2db9a0306c04f4777433908456ce8541 Author: Cen Zhang Date: Fri Oct 16 09:17:13 2026 +0800 ocfs2: pin owning modules for open debugfs files commit 26d7e34b4226709084461a07bf28d9066fa96d8c upstream. The OCFS2 debugfs file operation tables do not set owner. The full debugfs proxy obtains real_fops with fops_get() at open and keeps it until final release. Without an owner, this does not acquire a reference to the module containing the table and its callbacks. Removing the debugfs entries does not drain retained open files. An open connected_nodes file can therefore outlive ocfs2_nodemanager and make full_proxy_release() read real_fops->release from freed module memory. Heming also reproduced the issue with fs_state and asked for the other OCFS2 debugfs operation tables to be checked. Set owner to THIS_MODULE in all eleven explicit debugfs operation tables: five in ocfs2_nodemanager, four in ocfs2_dlm, and two in ocfs2. The existing debugfs get/put pair then holds the appropriate module until final release. Leave the open, read and release callbacks unchanged. The blockcheck table already sets owner through DEFINE_DEBUGFS_ATTRIBUTE(), so it needs no change. The original controlled test used an unloadable OCFS2 module and case-local probe filters without changing the candidate open, unload or release logic. Closing a retained connected_nodes file after normal unload produced: BUG: unable to handle page fault for address: fffffbfff804cfef Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:full_proxy_release+0xbf/0x190 Call Trace: __fput+0x39a/0xa60 fput_close_sync+0xff/0x200 __x64_sys_close+0x8c/0xf0 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Modules linked in: [last unloaded: ocfs2_nodemanager] Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0089-v6-f7fda843f80887488145@gmail.com Fixes: 2309e9e040fe ("ocfs2/net: Add debug interface to o2net") Fixes: 87d3d3f3931f ("ocfs2/hb: Expose the list of heartbeating nodes via debugfs") Fixes: 3ba169ccec1c ("ocfs2/cluster: Add new function o2net_fill_node_map()") Fixes: 50397507e856 ("ocfs2: Expose the file system state via debugfs") Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Fixes: 7209300a9b98 ("ocfs2/dlm: Dumps the purgelist into a debugfs file") Fixes: d0129aceaecc ("ocfs2/dlm: Dumps the mles into a debugfs file") Fixes: 4e3d24ed1a12 ("ocfs2/dlm: Dumps the lockres' into a debugfs file") Fixes: 007dce53a29c ("ocfs2/dlm: Dump the dlm state in a debugfs file") Fixes: db02754c8a12 ("ocfs2/cluster: Show o2net timing statistics") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Suggested-by: Heming Zhao Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Kees Cook Cc: Karl Mehltretter Cc: Christophe JAILLET Cc: Yufan Chen Cc: Mike Rapoport Cc: Zhang Cen Cc: Christian Brauner Cc: Sunil Mushran Cc: Kurt Hackel Cc: Jan Kara Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit 102ebaf4db4c81668db6a85d88273826dc94e539 Author: Cen Zhang Date: Tue Oct 20 11:45:04 2026 +0800 ocfs2: drain quorum work before removing the cluster commit b584c45b6066fd9799c44ffb9badcb5db351c8a6 upstream. The configured cluster must remain available until an in-flight quorum decision has finished using its fencing method. o2quo_make_decision() drops qs_lock before calling o2quo_fence_self(), which marks heartbeat regions for unclean stop and then reads o2nm_single_cluster->cl_fence_method. Cluster removal clears the singleton without waiting for this independent system-workqueue item. When a failed-quorum decision overlaps removal of the heartbeat regions, nodes and cluster through configfs, the worker can be preempted after marking the regions and resume after the singleton has been cleared: Quorum worker Configfs removal select fence; drop qs_lock o2hb_stop_all_regions() remove regions; join heartbeat threads remove nodes; stop o2net clear singleton; release cluster read cl_fence_method The resumed read dereferences NULL instead of applying the configured fencing method. The heartbeat thread's dependency protects the local node only until the thread exits, and draining o2net does not wait for qs_work. Add o2quo_flush_work() to drain pending or running quorum decisions before clearing the singleton in o2nm_cluster_group_drop_item(). By this point the heartbeat regions and nodes have been removed, so their work publishers are stopped. The worker can finish while the cluster and its configured fencing method remain available. It does not acquire the configfs mutex held by the removal path. Keep o2quo_exit() as the counterpart of o2quo_init() for module teardown and initialization failure, and have it call the same drain helper. Cluster removal uses only the explicitly named drain operation. KASAN report as below: Oops: general protection fault, probably for non-canonical address 0xdffffc000000011b: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000008d8-0x00000000000008df] CPU: 0 UID: 0 PID: 72 Comm: kworker/0:2 Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: events o2quo_make_decision RIP: 0010:o2quo_fence_self+0x65/0x200 Register dump omitted. Call Trace: o2quo_make_decision+0x345/0x3a0 ? __pfx_o2quo_make_decision+0x10/0x10 ? process_one_work+0x834/0x1b40 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 process_one_work+0x9a8/0x1b40 ? __pfx_process_one_work+0x10/0x10 ? lock_acquire+0x190/0x300 ? lock_is_held_type+0x8f/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x65c/0xe40 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kthread_parkme+0x177/0x220 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_worker_thread+0x10/0x10 kthread+0x351/0x460 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x659/0x940 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x74f/0xf70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0064-v5-e3870bf6571b80b07b52@gmail.com Fixes: f6656d26d17b ("ocfs2/cluster: Make fence method configurable - v2") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit d2b05b1190bdecbff2d26f48b376345b6f5ec5ea Author: Cen Zhang Date: Thu Oct 22 17:09:10 2026 +0800 ocfs2/dlm: drain join handlers before releasing module text commit 28f366d84023651e50e32e29931401ba0df3e679 upstream. The code for a registered DLM handler must remain resident until its last invocation finishes. dlm_unregister_net_handlers() only removes dlm_join_handlers from the o2net registry. o2net_handler_get() takes a kref on the wrapper, but that reference does not pin ocfs2_dlm text. o2net_process_message() calls nh_func after dropping o2net_handler_lock. With CONFIG_OCFS2_FS_O2CB=m, ocfs2_dlm can be loaded independently of ocfs2_stack_o2cb while nodemanager continues handling messages from a configured, heartbeating peer. If no dependent module or module reference prevents normal unload, the following ordering is possible: Receive worker Module unload -------------- ------------- o2net_handler_get() take wrapper kref drop handler lock dlm_exit() unregister handlers release DLM module text call saved nh_func in released module text Use o2net_unregister_and_flush_handler_list() in the shared DLM unregister helper. It first prevents new lookups, then waits for the ordered o2net workqueue to drain, including a concurrent destruction of that queue. The acquired invocation therefore finishes before dlm_exit() returns and the loader releases the callback code. The same helper covers partial registration and dlm_init() error unwind before module memory is released. Skip the drain when the private join-handler list is empty. Early dlm_init() failures can reach this helper before any handler has been published. Partial-registration failure also reaches it a second time after the first call has already unregistered and drained the list. Neither case needs to take o2net_wq_mutex or drain unrelated work. The list is changed only by serialized module init/exit paths; a nonempty list still uses the full unregister-and-flush helper. Oops report as below: Oops: int3: 0000 [#1] SMP KASAN NOPTI CPU: 2 UID: 0 PID: 54 Comm: kworker/u16:3 Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy) Hardware identification omitted. Workqueue: o2net o2net_rx_until_empty [ocfs2_nodemanager] RIP: 0010:0xffffffffc0423871 [Instruction byte dump omitted.] Register dump omitted. Call Trace: ? o2net_rx_until_empty+0x19b1/0x3300 [ocfs2_nodemanager] ? __pfx_o2net_rx_until_empty+0x10/0x10 [ocfs2_nodemanager] ? lock_acquire+0x190/0x300 ? process_one_work+0x935/0x1b40 ? process_one_work+0x834/0x1b40 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 ? process_one_work+0x9a8/0x1b40 ? __pfx_process_one_work+0x10/0x10 ? lock_acquire+0x190/0x300 ? lock_is_held_type+0x8f/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 ? worker_thread+0x65c/0xe40 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kthread_parkme+0x177/0x220 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_worker_thread+0x10/0x10 ? kthread+0x351/0x460 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_kthread+0x10/0x10 ? ret_from_fork+0x659/0x940 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x74f/0xf70 ? __pfx_kthread+0x10/0x10 ? ret_from_fork_asm+0x1a/0x30 Modules linked in: ocfs2_nodemanager [last unloaded: ocfs2_dlm] ---[ end trace 0000000000000000 ]--- Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0076-v6-12de5f4628f57fba3be3@gmail.com Fixes: 6714d8e86bf4 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit 05e204042f213f9d862c6901f53cece61aa5209c Author: Wei Jie Law Date: Wed Oct 21 10:03:09 2026 +0800 net: usb: pegasus: do not advance rx_skb->data on dropped frames commit bfa09dccf98cf78dd9282259b2140bd1472f5ae9 upstream. For the 0x8513 chip, read_bulk_callback() skips the 2-byte receive header by advancing pegasus->rx_skb->data in place. This is done before the pkt_len > PEGASUS_MTU check, and when that check drops the frame the good path resubmits the same skb with the advanced rx_skb->data as the transfer buffer, still PEGASUS_MTU bytes long. Every frame with an oversized length field therefore moves the receive buffer two more bytes towards the end of the skb data area. A device that keeps sending such frames makes the host controller write received data over skb_shared_info and past the end of the allocation, and the corrupted skb_shared_info is used when the skb is eventually freed. With an emulated device sending frames filled with 0x5a on a KASAN kernel: BUG: KASAN: slab-out-of-bounds in dummy_timer+0xade/0x3f00 [dummy_hcd] Write of size 1536 at addr ffff888105821202 by task swapper/1/0 ... Oops: general protection fault, probably for non-canonical address 0xeb4b474b4b4b4b4c: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0x5a5a5a5a5a5a5a60-0x5a5a5a5a5a5a5a67] RIP: 0010:skb_release_data+0x36f/0x800 Only skip the header with skb_reserve() once the frame is going to be passed up, so the receive buffer always starts at the beginning of the skb data area. Unlike the old pointer adjustment, skb_reserve() also moves skb->tail, so the two header bytes now count against the buffer size: lower the length limit for the 0x8513 accordingly, otherwise a pkt_len of PEGASUS_MTU - 1 or PEGASUS_MTU would trip skb_over_panic(). Found by code review with LLM assistance and reproduced with an emulated USB device (raw-gadget + dummy_hcd). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Wei Jie Law Reviewed-by: Simon Horman Link: https://patch.msgid.link/20261021020310.34045-2-law.wei.jie@gt.tech.gov.sg Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0a978359afe76aadfbc57acee88c08999543a7ae Author: Kaho Jiang Date: Wed Oct 21 19:57:33 2026 -0400 net: ipv4: add zero check for snd_cwnd_clamp commit 363c8c79220d0db4d65dcd570529ddda15067cb5 upstream. When RTAX_CWND is locked, user is able to pass 0 into it. This could lead to writing 0 to tp->snd_cwnd, leading to a division by zero error. Oops: divide error: 0000 [#1] SMP KASAN NOPTI Call Trace: tcp_reno_cong_avoid (net/ipv4/tcp_cong.c:510 (discriminator 1)) tcp_ack (net/ipv4/tcp_input.c:3517 net/ipv4/tcp_input.c:3873 net/ipv4/tcp_input.c:4440) tcp_rcv_established (net/ipv4/tcp_input.c:6685) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1854) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2248) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207 (discriminator 1)) ip_local_deliver_finish (net/ipv4/ip_input.c:241 (discriminator 1)) ip_local_deliver (./include/linux/netfilter.h:325 ./include/linux/netfilter.h:319 net/ipv4/ip_input.c:262) ip_rcv (./include/net/dst.h:481 (discriminator 6) net/ipv4/ip_input.c:492 (discriminator 6) ./include/linux/netfilter.h:325 (discriminator 6) ./include/li) __netif_receive_skb_one_core (net/core/dev.c:6297 (discriminator 4)) __netif_receive_skb (net/core/dev.c:6410) process_backlog (net/core/dev.c:6761) __napi_poll.constprop.0 (net/core/dev.c:7830) net_rx_action (net/core/dev.c:7893 net/core/dev.c:8050) handle_softirqs (kernel/softirq.c:645) __irq_exit_rcu (kernel/softirq.c:679 kernel/softirq.c:519 kernel/softirq.c:758) irq_exit_rcu (kernel/softirq.c:775) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1062 (discriminator 35) arch/x86/kernel/apic/apic.c:1062 (discriminator 35)) RIP: 0010:tcp_cong_avoid_ai (net/ipv4/tcp_cong.c:482) Fix by checking if user pass in zero as parameter and if lock is present. Fixes: 814d488c6126 ("tcp: fix the timid additive increase on stretch ACKs") Cc: stable@vger.kernel.org Suggested-by: Eric Dumazet Reported-by: co+71b6509cb791e531@bugs.sh Signed-off-by: Kaho Jiang Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20261021235732.1313305-2-kj2864@nyu.edu Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 1db31d3ddc386a8094a34e186243e26ce8fd175d Author: Xiang Mei Date: Tue Sep 15 20:45:34 2026 -0700 media: go7007: only set audio_enabled if go7007_snd_init() succeeded commit 2eacf058d2dbb0ae3aaf576459da9e5f2b6bbfbd upstream. go7007_register_encoder() sets go->audio_enabled before calling go7007_snd_init() and discards its return value. go7007_snd_init() assigns go->snd_context only on success, so a failed ALSA setup leaves audio_enabled set with snd_context still NULL. The disconnect path tests audio_enabled and calls go7007_snd_remove(), which dereferences snd_context unconditionally. go7007_snd_init() returns -ENODEV once its never-decremented static card counter reaches SNDRV_CARDS, so SNDRV_CARDS attach/detach cycles arm the next attach; no memory pressure is needed. Set go->audio_enabled only once go7007_snd_init() has succeeded. Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: usb_hub_wq hub_event RIP: 0010:go7007_snd_remove (drivers/media/usb/go7007/snd-go7007.c:273) Call Trace: go7007_usb_disconnect (drivers/media/usb/go7007/go7007-usb.c:1336) usb_unbind_interface (drivers/usb/core/driver.c:461) device_remove (drivers/base/dd.c:618) device_release_driver_internal (drivers/base/dd.c:1349) bus_remove_device (drivers/base/bus.c:664) device_del (drivers/base/core.c:3965) usb_disable_device (drivers/usb/core/message.c:1478) usb_disconnect hub_event (drivers/usb/core/hub.c:5966) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Kernel panic - not syncing: Fatal exception Cc: stable@vger.kernel.org Fixes: 866b8695d67e ("Staging: add the go7007 video driver") Assisted-by: LLM Signed-off-by: Xiang Mei Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ffafe6ecce8794ed821689b874964da3ab9d0869 Author: Xiang Mei Date: Sat Sep 12 17:29:45 2026 -0700 media: em28xx: reject audio endpoint with zero packet size commit aebfe430ba885d2f8fc882d7a6d60a7fdbe535d8 upstream. em28xx_audio_urb_init() divides by the audio endpoint's wMaxPacketSize without checking it, so a USB device that declares a zero-sized audio endpoint divides by zero at probe time. Reject a zero-sized audio endpoint like a missing one; the caller already unwinds on a negative return. Oops: divide error: 0000 [#1] SMP NOPTI Workqueue: usb_hub_wq hub_event RIP: 0010:em28xx_audio_init (drivers/media/usb/em28xx/em28xx-audio.c:718) Call Trace: em28xx_init_extension (drivers/media/usb/em28xx/em28xx-core.c:1248) em28xx_init_dev.isra.0 (drivers/media/usb/em28xx/em28xx-cards.c:3887) em28xx_usb_probe (drivers/media/usb/em28xx/em28xx-cards.c:4258) usb_probe_interface (drivers/usb/core/driver.c:396) ... usb_set_configuration (drivers/usb/core/message.c:2268) usb_generic_driver_probe (drivers/usb/core/generic.c:250) usb_probe_device (drivers/usb/core/driver.c:291) ... usb_new_device (drivers/usb/core/hub.c:2703) hub_event (drivers/usb/core/hub.c:5961) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Kernel panic - not syncing: Fatal exception Fixes: 1b3fd2d34266 ("[media] em28xx-audio: don't hardcode audio URB calculus") Cc: stable@vger.kernel.org Reported-by: co+9782320f78c23f40@bugs.sh Closes: https://lore.kernel.org/all/51lCz4R7QyTUKbh4mhXNaNzX0evpk0siOzbh%40bugs.sh/ Assisted-by: Claude:claude-opus-5 Signed-off-by: Xiang Mei Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 287a899734c08abd536e623add08df7d7b307e11 Author: Myeonghun Pak Date: Sun Sep 13 22:28:09 2026 -0400 media: cx88: Disable PCI device on MPEG initialization failure commit 80494a83223bc972145c23890b083d20651512bd upstream. cx8802_init_common() enables the PCI device, then returns directly if DMA mask setup or IRQ registration fails. cx8802_probe() frees the device and drops the shared core reference without disabling PCI. Disable the PCI device on both post-enable failures. Preserve -EIO for a DMA mask failure and the original request_irq() error. Do not call the full fini helper because the IRQ was not successfully requested. The successful probe and normal removal paths are unchanged. These missing error-path disables are present in the initial Git import. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Assisted-by: OpenAI:GPT-5.6 Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c6696ac94c8c3ad79a9fa57fc334af2dc1a1f72e Author: Xiang Mei Date: Mon Sep 14 18:42:43 2026 -0700 libceph: bound mon_command ack decode to front len commit 62b41a16d8603d4d809fda212f15c3e9c783a82b upstream. handle_command_ack() bounds the decode with msg->front_alloc_len, the size of the reply buffer, instead of msg->front.iov_len, the number of bytes the monitor sent. mon_alloc_msg() routes every CEPH_MSG_MON_COMMAND_ACK to get_generic_reply(), which returns the preallocated ->reply of whichever generic request carries the same tid, so the buffer keeps its fixed size however short the reply is. An ack with hdr.front_len below sizeof(struct ceph_mon_request_header) + sizeof(u32), including 0, still passes ceph_decode_need(), and ceph_decode_32() returns four bytes that were never received: uninitialized slab memory, stale bytes of an earlier message, or bytes the peer planted by sending a reply that lands in the same buffer and is then rejected. The read stays within the allocation, so KASAN does not flag it. req->result reaches userspace through ceph_monc_do_statfs(), ceph_monc_get_version() and ceph_monc_blocklist_add(); rbd hands it back from write() on /sys/bus/rbd/add_single_major, and rbd_get_client() passes it to ERR_PTR() unchecked, which faults: rbd: failed to get latest osdmap: -186318427 BUG: unable to handle page fault for address: fffffbfffe9ca034 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:do_rbd_add (drivers/block/rbd.c:7105) Call Trace: ... kernfs_fop_write_iter (fs/kernfs/file.c:345) vfs_write (fs/read_write.c:595 fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception Use msg->front.iov_len, matching handle_subscribe_ack(), handle_statfs_reply(), handle_get_version_reply() and handle_auth_reply(). A well-formed ack has front.iov_len >= 22 and is unaffected; a short one takes the existing bad: path. This applies commit d3c32939fa0e ("libceph: bound get_version reply decode to front len") to the last decode-side use of front_alloc_len in this file. Cc: stable@vger.kernel.org Fixes: 6305a3b41515 ("libceph: support for blacklisting clients") Reported-by: co+25860fb17af97289@bugs.sh Assisted-by: Cursor Signed-off-by: Xiang Mei Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit f2b883022c4480d06c838b2775b5c56dbf161f39 Author: Andrea Parri Date: Wed Sep 30 15:38:30 2026 +0200 kcsan: Avoid division by zero in kcsan_prandom_u32_max() commit 99b6fcce87037cfb6b5e177848342e97f5141205 upstream. KCSAN's skip_watch, udelay_task and udelay_interrupt parameters can be changed at runtime through /sys/module/kcsan/parameters/, where 0 means watching every access or not delaying at all. With the default CONFIG_KCSAN_SKIP_WATCH_RANDOMIZE=y and CONFIG_KCSAN_DELAY_RANDOMIZE=y, writing 0 to any of them makes the next watchpoint setup divide by zero: # echo 0 > /sys/module/kcsan/parameters/udelay_task Oops: divide error: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 93 Comm: sh Not tainted 7.3.0-rc5 #3 PREEMPT(lazy) RIP: 0010:kcsan_setup_watchpoint+0x1b5/0x410 Code: ... 65 89 05 ad 8d 98 02 d3 ee f6 29 d7 e8 22 0e 0f 01 ... RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 ... __show_trace_log_lvl+0x1bd/0x315 __die_body.cold+0x19/0x2b die+0x34/0x50 ... BUG: TASK stack guard page was hit at ffffd3ab001fbfe8 (...) reset_kcsan_skip() and delay_access() pass these values unchecked to kcsan_prandom_u32_max(), which returns "state % ep_ro". delay_access() halves the delay for compound and assert accesses, so udelay_interrupt=1 is enough there. The oops path runs instrumented code, which faults again until the stack overflows. With skip_watch=0 the guest hangs without printing anything. The division came in with commit 71a076f4a61a ("kcsan: Rewrite kcsan_prandom_u32_max() without prandom_u32_state()"). Before it, the helper scaled the random value with a multiply-shift, which yields 0 for ep_ro == 0. Go back to that via reciprocal_scale(). Tested in an x86-64 KCSAN guest with virtme-ng: after this patch, writing 0 to each parameter, or 1 to udelay_interrupt, no longer oopses. skip_watch=0 now watches every access, which is very slow with the default delays but completes when they are set to 0. Fixes: 71a076f4a61a ("kcsan: Rewrite kcsan_prandom_u32_max() without prandom_u32_state()") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Marco Elver Signed-off-by: Andrea Parri Signed-off-by: Marco Elver Signed-off-by: Greg Kroah-Hartman commit a79fbd0a5655968c16c864fc8dae5eea884c216b Author: Fang Xieyan Date: Thu Sep 17 18:43:06 2026 +0800 kcov: ignore an out-of-range comparison count in write_comp_data() commit f5263bee9eb84d2388fd7555a18d518e17226894 upstream. write_comp_data() reads the comparison record count from area[0] and uses it to index the coverage buffer: area = (u64 *)t->kcov_area; max_pos = t->kcov_size * sizeof(unsigned long); count = READ_ONCE(area[0]); /* Every record is KCOV_WORDS_PER_CMP 64-bit words. */ start_index = 1 + count * KCOV_WORDS_PER_CMP; end_pos = (start_index + KCOV_WORDS_PER_CMP) * sizeof(u64); if (likely(end_pos <= max_pos)) { The buffer is mmap'd writable into the collecting process, so count is under its control and end_pos <= max_pos is its only bound. A count that wraps the u64 multiply leaves end_pos below max_pos, so the check passes while the record store lands 24 bytes before the buffer, in the unmapped vmalloc guard page, and faults: BUG: unable to handle page fault for address: ffa0000000b60fe8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:write_comp_data+0x7e/0xa0 ... Kernel panic - not syncing: Fatal exception Bound count first: only max_pos / (sizeof(u64) * KCOV_WORDS_PER_CMP) records fit, so a larger count is not a valid index and is dropped. kcov_move_area() bounds the same untrusted count this way, and no count the end_pos <= max_pos check accepts reaches that limit, so no valid record is lost. kcov is a root-only debugfs file (debugfs_create_file_unsafe("kcov", 0600, ...)) and write_comp_data() exists only under CONFIG_KCOV_ENABLE_COMPARISONS, so this is a local, debug-kernel robustness fix: the process corrupts its own buffer and the kernel oopses. It crosses no privilege boundary. Additional details at [1] Link: https://lore.kernel.org/20260917104306.22145-1-fangxy@xiaopeng.com [1] Fixes: ded97d2c2b2c ("kcov: support comparison operands collection") Signed-off-by: Fang Xieyan Signed-off-by: Andrew Morton Reviewed-by: Alexander Potapenko Assisted-by: Hawkeye:GLM-5.3-flash Assisted-by: Qoder:Qwen3.8-Max Cc: Andrey Konovalov Cc: Dmitry Vyukov Cc: Marco Elver Cc: Victor Chibotaru Cc: Signed-off-by: Greg Kroah-Hartman commit 37d01a684e6087e264895ab34b829d2267ad607c Author: Yuanfu Xie Date: Wed Sep 30 15:09:45 2026 +0800 ceph: fail readdir when the MDS reply carries no dirfrag commit 728c856d7da04fb79f7aa00e974ffb6f55e55995 upstream. A ceph mount oopses in ceph_readdir() when the MDS answers a READDIR request with a reply whose extra blob is empty. parse_reply_info() skips reply blobs whose length is zero, so parse_reply_info_readdir() never runs, r_reply_info.dir_dir stays NULL, and the reply still parses as successful. ceph_mdsc_do_request() returns 0 and ceph_readdir() then reads rinfo->dir_dir->frag with no NULL check: /* extra */ ceph_decode_32_safe(&p, end, len, bad); if (len > 0) { ... err = parse_reply_info_extra(&p, p + len, req, features, s); ... } The oops on v7.3.0-rc4-00537-ga3ff15db6820, one getdents64(2) on the mount root after an ms_mode=legacy mount, trimmed: BUG: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 266 Comm: ls Tainted: G N 7.3.0-rc4-00537-ga3ff15db6820 #1 PREEMPT(lazy) RIP: 0010:ceph_readdir+0xbff/0x3ea0 Call Trace: ? __pfx_ceph_readdir+0x10/0x10 wrap_directory_iterator+0xa2/0xe0 iterate_dir+0x1da/0x5d0 __x64_sys_getdents64+0x13b/0x2a0 do_syscall_64+0xdd/0x4a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The unconditional frag read came in with 81c6aea5275ea ("ceph: handle frag mismatch between readdir request and reply"), so the bug is old. Treat a reply with no dirfrag as a protocol violation: warn once, drop the request and return -EIO, the same way ceph_readdir() already handles the two malformed-reply cases later in the function. Tested on v7.3.0-rc4-00537-ga3ff15db6820 (KASAN). Unpatched, the getdents64(2) above takes the machine down (oops=panic) on the first READDIR reply. With the patch it warns once and getdents64(2) returns -EIO, no oops, no hang. A conformant reply for an empty directory — dirfrag present, zero entries, FRAG_END|FRAG_COMPLETE — still lists "." and ".." and returns EOF on both kernels, so normal readdir behavior is unchanged. The oops is still present in v7.3-rc5 (72d3fcf802c45). Cc: stable@vger.kernel.org Fixes: 81c6aea5275ea ("ceph: handle frag mismatch between readdir request and reply") Signed-off-by: Yuanfu Xie Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 6304b40fdc8bdde881e2bf7b7cbe501261e4abd3 Author: Baokun Li Date: Fri Oct 23 16:19:08 2026 +0800 blk-crypto: fix NULL deref and UAF in __blk_crypto_evict_key() commit c8c53d669d4e45b3a804013251a34387d7e11bfb upstream. Sashiko reported a possible NULL pointer dereference, triggered by the following flow: dm-inlinecrypt ctor # first use of the fallback ├─ blk_crypto_init_key() # succeeds, ctx->key.size != 0 ├─ blk_crypto_start_using_key() │ ├─ hw-wrapped key: -EOPNOTSUPP │ │ # profile never allocated (NULL) │ └─ raw key: fallback_start_using_mode() │ └─ blk_crypto_fallback_init() fails │ └─ kfree(profile) # not NULLed ├─ goto bad └─ inlinecrypt_dtr() # evicts whenever key.size is set └─ blk_crypto_evict_key() └─ blk_crypto_config_supported_natively() = false └─ blk_crypto_fallback_evict_key() └─ __blk_crypto_evict_key(blk_crypto_fallback_profile) └─ profile->num_slots # BOOM!!! This issue can be reproduced using the following commands: dd if=/dev/zero of=/tmp/backing bs=1M count=64 LOOP=$(losetup -f --show /tmp/backing) SZ=$(blockdev --getsz $LOOP) KEY=$(head -c 64 /dev/urandom | od -An -tx1 | tr -d ' \n') dmsetup create ic --table "0 $SZ inlinecrypt aes-xts-plain64 \ $KEY 0 $LOOP 0 1 keytype:hw-wrapped" And the following oops is triggered: ================================================================== blk-crypto: loop0: no support for wrapped keys Oops: general protection fault, probably for non-canonical address 0xdffffc000000000b: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000058-0x000000000000005f] CPU: 5 UID: 0 PID: 901 Comm: dmsetup 7.3.0-rc3 #1 PREEMPT(lazy) RIP: 0010:__blk_crypto_evict_key+0x2e/0x3b0 Call Trace: blk_crypto_evict_key+0x24c/0x320 inlinecrypt_dtr+0xf6/0x160 inlinecrypt_ctr+0x2d3/0xbd0 dm_table_add_target+0x661/0xf40 table_load+0x1c4/0x490 ctl_ioctl+0x32f/0x5f0 dm_ctl_ioctl+0xe/0x20 ================================================================== dm-inlinecrypt is the only caller that can evict a key that was never started, as fscrypt frees such a key without evicting it. Fix this by returning early from blk_crypto_fallback_evict_key() when tfms_inited[] is not set for the key's mode. tfms_inited[] is only set after blk_crypto_fallback_init() has successfully initialized the profile, so the crash above is no longer reachable. The bug has been latent since commit c984ff1423ae ("blk-crypto: dynamically allocate fallback profile") was merged in v6.5, and only became actually triggerable when commit e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption") was merged in v7.2. Fixes: c984ff1423ae ("blk-crypto: dynamically allocate fallback profile") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://patch.msgid.link/sashiko-outbox-167341@kernel.org Suggested-by: Eric Biggers Link: https://patch.msgid.link/20261014155131.GB322435@quark Signed-off-by: Baokun Li Reviewed-by: Eric Biggers Link: https://patch.msgid.link/20261023081908.3505413-1-libaokun@linux.alibaba.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e2d9b170afdd981297ff519a34232f881ee7e0b6 Author: Rohinthan P Date: Wed Sep 23 12:50:50 2026 +0530 media: em28xx: use video_unregister_device for radio_dev [ Upstream commit 2579cbe68005f46fc7f8f95364f6b101b07b9d1c ] Commit 7c8bf63b7937 ("media: em28xx: use vb2_video_unregister_device") converted device unregistrations in em28xx to use vb2_video_unregister_device() instead of video_unregister_device(). However, radio devices do not have an associated videobuf2 queue (v4l2->radio_dev.queue is NULL). Calling vb2_video_unregister_device() on a radio device triggers a WARNING in vb2_video_unregister_device(): !vdev->queue WARNING: drivers/media/common/videobuf2/videobuf2-v4l2.c:1264 at vb2_video_unregister_device+0x1f8/0x200 Call Trace: em28xx_v4l2_init+0x1c39/0x3150 drivers/media/usb/em28xx/em28xx-video.c:3085 As documented in vb2_video_unregister_device(), video_unregister_device() should be used instead when vdev->queue is NULL. Revert to calling video_unregister_device() for v4l2->radio_dev in both em28xx_v4l2_fini() and the em28xx_v4l2_init() error unwind path. Fixes: 7c8bf63b7937 ("media: em28xx: use vb2_video_unregister_device") Reported-by: syzbot+f26bc23e42eeb548dee1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f26bc23e42eeb548dee1 Signed-off-by: Rohinthan P Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 400c92b69a32798ab2dc1282abc2ce3820791fb7 Author: Christian Brauner Date: Fri Oct 16 10:50:57 2026 +0200 Revert "namei: don't reveal overmounted entries in refwalk" [ Upstream commit 214897acc8c2e5d6b63189d23ccaed6fa2af45a9 ] This reverts commit 8189ab688f5a2c745dc90b63374da02f213d6994. This bug class is bigger than can be fixed with this simple patch. Back out of it and give us some time to fix this properly. Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 51c8a9c86507d00b0fb9e303252bd575904d58e1 Author: Petr Mladek Date: Tue Oct 13 17:41:41 2026 +0200 nbcon/reboot: Switch NBCON consoles into the emergency mode in emergency_restart() [ Upstream commit d8e5fc3002294a28af53e97f6c83a35956e738f3 ] When the system is going down a normal way, the NBCON kthreads are flushed and stopped properly via a syscore shutdown callback, see printk_kthreads_shutdown(). One missing piece is emergency_restart() where the kthreads are not stopped. It might be called from several non-panic code paths, e.g. sysrq-o, kdb_reboot(), or some watchdogs. Fix it by explicitly entering the emergency (atomic) mode and trying to flush the consoles there. Note that printk_trigger_flush() must be used instead of pr_flush() because the later is not safe in an atomic context. Reported-by: kernel test robot Closes: https://lore.kernel.org/all/202608061008.48a1e76e-lkp@intel.com/ Suggested-by: John Ogness Reviewed-by: John Ogness Link: https://patch.msgid.link/20261013154141.94016-1-pmladek@suse.com Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit f1e8a77a422e197587d9be3cc68cffbdff13cc60 Author: Michael Reeves Date: Tue Oct 6 18:03:15 2026 +1100 regmap: Remove debugfs before cache teardown [ Upstream commit 834035934cef9e60169de682f4dc9feafd49e51a ] regmap_exit() and regmap_reinit_cache() destroy the register cache before removing debugfs. A concurrent debugfs cache operation can therefore access cache state after the backend exit callback starts freeing it. Remove debugfs before cache teardown, and clear the debugfs pointer after removal. During cache reinitialization, recreate debugfs only after the new cache initializes successfully. Signed-off-by: Michael Reeves Reviewed-by: Peng Fan Link: https://patch.msgid.link/20261006-regcache-lifecycle-submit-v3-1-37bdd82fd47c@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a289c890d836012968e8b40d3dda5611b6ba130f Author: Matus Gajdos Date: Fri Oct 2 14:52:37 2026 +0200 ALSA: usb-audio: Add native DSD support for Cambridge Audio streamers [ Upstream commit 4e1462e7cd6a9b920f441842726cc2b9d232673e ] The Cambridge Audio streamer advertises the UAC2 RAW_DATA format on altsetting 2 of its playback interface, but without the DSD_RAW quirk flag the driver exposes it only as a SPECIAL format that cannot be used. Add QUIRK_FLAG_DSD_RAW for the device (USB ID 22e8:ca10), so the altsetting is exposed as DSD_U32_BE, enabling native DSD64/128/256 playback. Tested with: gst-launch-1.0 filesrc location=file.dsf ! \ avdemux_dsf ! dsdconvert ! \ alsasink device=hw:2,0 Signed-off-by: Matus Gajdos Link: https://patch.msgid.link/20261002125237.82188-1-matuszpd@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit aec9161261a0acec04644c13b2a11caaefc3de45 Author: Jaidheer Sirigineedi Date: Fri Oct 2 13:59:51 2026 -0500 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg3xxx (103c:8bfd) [ Upstream commit 13dffca9043500ed6033d770b491a043fb952bc5 ] The mute LED on the HP Pavilion Laptop 15-eg3xxx (PCI SSID 103c:8bfd, Realtek ALC287) does not work because the machine has no entry in the quirk table. No fixup is applied, so the mute LED is never driven, even though the mute function itself works. The LED is controlled via GPIO pin 4 (mask 0x10), which is exactly what ALC287_FIXUP_HP_GPIO_LED configures. This was verified on the hardware with hda-verb: setting the GPIO data bit lights the mute LED, and clearing it turns the LED off. hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x10 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION 0x10 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x10 # LED on hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x00 # LED off Add a quirk entry for 103c:8bfd using ALC287_FIXUP_HP_GPIO_LED. Signed-off-by: Jaidheer Sirigineedi Link: https://patch.msgid.link/20261002185951.33855-1-jaidheer7@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ce938a0e4164575b1374ded63a847223bfaa0a12 Author: Miquel Raynal Date: Thu Oct 1 17:14:44 2026 +0200 spi: cadence-qspi: Fix status polling with octal DTR chips [ Upstream commit fd99864b0ac936e870c7ae28354c5cd3dad5efd0 ] Most SPI NOR chips today use 0x05 as ReaD Status Register (RDSR) opcode. After almost every transaction, the core will wait for the said transation to be digested by the chip by polling its status register. This mechanism has been automated by certain chips, such as the Cadence QSPI controller. Unfortunately, the feature has been disabled for various (relevant) reasons. Disabling this feature has been done by setting WRITE_COMPLETION_CTRL_REG.DISABLE_POLLING_FLD, keeping the rest of the register intact. In this same register, there is also a field named WRITE_COMPLETION_CTRL_REG.OPCODE_FLD, which by default also contains 0x05, as primary RDSR opcode. As a result, both the SPI NOR and SPI NAND cores, primary users through spi-mem of the spi_mem_ops interface, do send their own RDSR. In this driver, such command goes through one of the fifth possible data path specifically crafted for short register-like commands, named STIG. In STIG mode, the opcode of the operation is written to OSPI_FLASH_CMD_CTRL_REG. This means that the opcode field of STIG configuration and the opcode field of the automatic polling configuration contain the same value. Unfortunately, the TRM explains in two different places that this configuration is forbidden, without explaining why it is problematic: $12.4.2.4.11 OSPI Software-Triggered Instruction Generator (STIG) ``` OSPI_FLASH_CMD_CTRL_REG[31-24] CMD_OPCODE_FLD bits should be set different than OSPI_DEV_INSTR_RD_CONFIG_REG[7-0] RD_OPCODE_NON_XIP_FLD and OSPI_DEV_INSTR_WR_CONFIG_REG[7-0] WR_OPCODE_FLD. ``` and $12.4.2.5.2 Configuring the OSPI Controller for Optimal Use ``` When using the OSPI Controller, the opcodes in OSPI_DEV_INSTR_RD_CONFIG_REG[7-0] RD_OPCODE_NON_XIP_FLD, OSPI_DEV_INSTR_WR_CONFIG_REG[7-0] WR_OPCODE_FLD and OSPI_WRITE_COMPLETION_CTRL_REG[7-0] OPCODE_FLD bit fields shall not match the opcode in the OSPI_FLASH_CMD_CTRL_REG[31-24] CMD_OPCODE_FLD bit field. ``` For some reasons, this is only unveiled now when testing in ODTR mode. Plain SDR modes work flawlessly with the same chips. One possible reason for this, is that the internal data path in ODTR mode is very different due to the extra opcode extension/repetition which may be interpreted differently (this is a wild guess). For sure there is an interference, as even the TRM states that there is some magic happening: $12.4.2.4.13 OSPI Command Translation ``` The WREN and the RDSR device instructions are the only ones that are sent by the controller under the hood. ``` I cannot probe the bus when the problem arises, so I don't know exactly what is sent on the bus. Practically speaking, the chip was driving the lines low (reading all 0s), which is not the usual default state when the chip is not driving the lines (all 1s). Other people on the mailing list claimed successfully using ODTR chips with this controller. My take here is that either they were using a variant of the IP without write completion at all (there is a quirk for it), or they were using chips slightly more flexible about their opcode sequency or maybe with different addr/dummy requirements. Clearing the WRITE_COMPLETION_CTRL_REG.OPCODE_FLD while disabling write completion polling entirely seems the best compromise. Signed-off-by: Miquel Raynal Link: https://patch.msgid.link/20261001-winbond-spi-next-cadence-rdsr-fix-v1-1-ec5ff594ba5d@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ce197ed7395553878b7b913ca97e4c3af6f71941 Author: Eckhart Mohr Date: Thu Oct 1 20:34:00 2026 +0200 ALSA: hda/realtek: Add quirk for ASRock NUC BOX-358H [ Upstream commit 9a44b828dd7c0be1d0d6d6cf178d9727ceb6da6e ] Fix headphone jack detection for some devices Signed-off-by: Eckhart Mohr Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20261001183403.103990-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1afdfc6a1ff0aa897bb83a2951a52d4eea91671a Author: Reinhard Speyerer Date: Fri Sep 25 15:14:32 2026 +0200 net: usb: qmi_wwan: add Rolling Wireless RN947R [ Upstream commit 7375d38364a9aa66fb31716bcefef38aecad75d8 ] Add Rolling Wireless RN947R 0x9300 composition: DIAG + ADB + NMEA + MODEM + RMNET + QDSS + ADPL T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=9300 Rev= 0.00 S: Manufacturer=Rolling Wireless S: Product=RN947R S: SerialNumber=xxxxxxxxxxx C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#=21 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#=22 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Reinhard Speyerer Link: https://patch.msgid.link/arZzuOOvLUZtdOlv@arcor.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9eecff7fb5fe0d8adda26db41a4366868223e46d Author: Vladimir Murzin Date: Tue Sep 22 11:37:56 2026 +0100 usb: mtu3: Fix double dereference in TP_printk [ Upstream commit cfb3293c4573289f11f913611f530ea6b1926d67 ] Paul reported kernel splat: [ 0.000000] TRACE EVENT ERROR: Event mtu3_gadget_ep_set_halt has double dereference in TP_printk: &REC->gpd_ring->dma [ 0.000000] ------------[ cut here ]------------ [ 0.000000] Event mtu3_gadget_ep_set_halt has double dereference in TP_printk: &REC->gpd_ring->dma [ 0.000000] WARNING: kernel/trace/trace_events.c:420 at test_double_dereference+0x144/0x14c, CPU#0: swapper/0/0 [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.3.0-rc1 #15247 PREEMPT [ 0.000000] Hardware name: linux,dummy-virt (DT) [ 0.000000] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.000000] pc : test_double_dereference+0x144/0x14c [ 0.000000] lr : test_double_dereference+0x144/0x14c [ 0.000000] sp : ffffc80aa7633bf0 [ 0.000000] x29: ffffc80aa7633bf0 x28: ffffc80aa7c0f047 x27: 000508b58019388f [ 0.000000] x26: 0000000000000003 x25: 0000000000000007 x24: ffffc80aa5fceff8 [ 0.000000] x23: ffffc80aa7c0f05a x22: ffffc80aa64edfe8 x21: ffffc80aa7c0fce8 [ 0.000000] x20: ffffc80aa7c0f047 x19: 0000000000000013 x18: 0000000000000001 [ 0.000000] x17: 6572656420656c62 x16: 756f642073616820 x15: 746c61685f746573 [ 0.000000] x14: 0000000000000000 x13: ffff000139d90000 x12: 0000000000000045 [ 0.000000] x11: 00000000000000cf x10: ffff00013f546428 x9 : ffff000139d90000 [ 0.000000] x8 : 3fffffffffffc000 x7 : 0000000000000001 x6 : 0000000000000001 [ 0.000000] x5 : ffff00013f4e6440 x4 : 0000000000000000 x3 : 0000000000000000 [ 0.000000] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffc80aa764a700 [ 0.000000] Call trace: [ 0.000000] test_double_dereference+0x144/0x14c (P) [ 0.000000] trace_event_raw_init+0x37c/0x5d8 [ 0.000000] event_init+0x34/0xc0 [ 0.000000] trace_event_init+0xec/0x588 [ 0.000000] trace_init+0x24/0x6e0 [ 0.000000] start_kernel+0x4a0/0x8ec [ 0.000000] __primary_switched+0x88/0x90 [ 0.000000] irq event stamp: 0 [ 0.000000] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 0.000000] hardirqs last disabled at (0): [<0000000000000000>] 0x0 [ 0.000000] softirqs last enabled at (0): [<0000000000000000>] 0x0 [ 0.000000] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] TRACE EVENT ERROR: Event mtu3_gadget_ep_disable has double dereference in TP_printk: &REC->gpd_ring->dma [ 0.000000] TRACE EVENT ERROR: Event mtu3_gadget_ep_enable has double dereference in TP_printk: &REC->gpd_ring->dma Which also observed by Mark and myself. The splat it result of new check introduced by b5cc230af5e5 ("tracing: Warn when an event dereferences a pointer in TP_printk()") which correctly catches issue with %pad dereferencing the address saved in the ring buffer. TP_fast_assign() logic gets executed when the tracepoint is triggered, however the TP_printk() is executed when the user reads the trace buffer which could be seconds, minutes, hours, days, even months later and nothing guarantee that __entry->gpd_ring pointer will still be pointing to what it was when it was recorded. Fix the issue by capturing immediate value of gpd_ring.dma when trace point is triggered. Reported-by: Paul E. McKenney Tested-by: Mark Rutland Reviewed-by: Steven Rostedt Signed-off-by: Vladimir Murzin Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit b66c6cd6d090ebfcc879df4d0775f958d1ec47a2 Author: renpanpan Date: Wed Sep 30 14:55:04 2026 +0800 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 14-dv1001TU [ Upstream commit ece609abc95cc0f75e633d93f3d868b030d9a8fe ] The HP Pavilion 14-dv1001TU (subsystem ID 103c:8987) uses a Realtek ALC287 codec. The mute LED on this machine is controlled by GPIO bit 0x10, which was verified via hda-verb, but the subsystem ID is missing from the quirk table. As a result, the ALC287_FIXUP_HP_GPIO_LED fixup that drives GPIO 0x10 is never applied and the mute LED stays off even though the associated LED class device toggles correctly. Add the missing SND_PCI_QUIRK entry to map this subsystem ID to ALC287_FIXUP_HP_GPIO_LED so the mute LED works as expected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221810 Signed-off-by: renpanpan Link: https://patch.msgid.link/20260930065504.24151-1-rppxj178543@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e764ecf35c098a13e00ca72e54808d5461c58271 Author: Muhtasham Nawr al-Mahmud Date: Thu Sep 24 20:45:12 2026 +0600 ALSA: hda/realtek: Fix speakers on ASUS PM3406CHA [ Upstream commit 0eee030c2c09c7a44be778de5f451d9e7a2f09c1 ] The ASUS ExpertBook PM3406CHA uses an ALC256 codec with subsystem ID 1043:1664. On Linux boot, the internal speakers are silent even though playback is routed to the codec and the speaker pin is configured for output. The codec starts with coefficient 0x10 set to 0x1d20. Writing 0x7f20 to coefficient 0x10 immediately restores internal speaker output. This was reproduced on the affected hardware from a fresh boot using hda-verb. Reducing a larger initialization sequence showed that this coefficient write alone is sufficient; no GPIO, EAPD, pin-control, or other coefficient changes are required. After applying the coefficient in userspace, speaker output also remains functional across suspend and resume. Add a machine-specific HDA fixup that writes the required coefficient. The fixup has been compile-tested, but could not be boot-tested because the affected hardware is no longer available. Closes: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/2162718 Signed-off-by: Muhtasham Nawr al-Mahmud Link: https://patch.msgid.link/20260924144512.3989-1-muhtaseem2005@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit df5c9fc2a38293f1d482df9205f176e788351a72 Author: Zhang Heng Date: Mon Sep 21 20:44:50 2026 +0800 ALSA: hda/realtek: Add quirk for Acer Nitro AN515-45 [ Upstream commit 0d90a929836344f1d3b39f22f08ccecc62378a59 ] The Acer Nitro AN515-45 requires ALC2XX_FIXUP_HEADSET_MIC to make the headset microphone work properly. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221925 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260921124450.639601-2-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e8959b66760097f59bc583e0d9b49f6c6dde25b8 Author: Tarun Noonemunthala Date: Wed Sep 23 15:10:14 2026 +0530 ALSA: hda/realtek: Add quirk for HP ENVY 13-aq1xxx [ Upstream commit a01a223bd685be42e908d970de32eeb3646097f3 ] The HP ENVY Laptop 13-aq1xxx (PCI SSID 103c:86ad) uses an ALC285 codec with two speaker pairs: front (pin 0x14) and bottom (pin 0x17). The BIOS leaves pin 0x14 as [N/A] ("not connected"), so the generic parser never enables the front pair and only the bottom speakers are audible. The vendor driver (RTKVHD64.sys) programs that pin with the value 0x90170150 and runs the HP amplifier initialization, which is already implemented in the driver as ALC285_FIXUP_HP_GPIO_AMP_INIT. Add a board fixup that applies the pin configuration for 0x14 and chains to the existing amplifier init fixup. The pin value was recovered from the vendor driver's own configuration data. The patch and this changelog were prepared with an AI coding assistant (see the Assisted-by tag below); the change was reviewed and tested by the submitter on the affected machine. Tested on an HP ENVY 13-aq1xxx by rebuilding snd-hda-codec-alc269 from the Fedora 7.1.10 source and loading it: the codec now reports "line_outs=2 (0x14/0x17)", pin 0x14 comes up as an output (Pin-ctls 0x40) with its amplifier unmuted, and both speaker pairs play. Assisted-by: OpenCode:deepseek-v4.1-flash checkpatch Signed-off-by: Tarun Noonemunthala Link: https://patch.msgid.link/20260923094014.58867-1-ntarun2000@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9d6f14594536b987206cdcfdc9671dc25bedb4e9 Author: Luis Banha Date: Tue Sep 22 00:01:05 2026 +0100 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-ec1xxx [ Upstream commit 775aa96c310d59f3d15a6e5a9bd1796fd1ba95ec ] The mute LED on the HP Pavilion Gaming Laptop 15-ec1xxx (103c:87b2) does not work automatically. Add the ALC285_FIXUP_HP_MUTE_LED quirk to fix this behavior. Signed-off-by: Luis Banha Link: https://patch.msgid.link/20260921230105.16844-1-luisbanha26@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 834cd749a411e9e9cfff6a583fbb9a9cd97cb315 Author: Zhang Heng Date: Mon Sep 21 20:44:49 2026 +0800 ALSA: hda/realtek: Add quirk for Lenovo ThinkBook G8+ [ Upstream commit 4322ac247f4ce7932edbd46aa37f3dae62cde424 ] Fix Bass Speaker volume control on Lenovo ThinkBook G8+ by adding quirk 17aa:38dc with ALC285_FIXUP_SPEAKER2_TO_DAC1. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221799 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260921124450.639601-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0c1cb4872fd45d96be8b4a7db9ecb2ff3bd4e175 Author: KIM MinWoo Date: Wed Sep 23 10:37:56 2026 +0900 ALSA: hda/realtek: Add quirk for Lenovo ThinkBook 16p Gen 3 ARH (21EK) [ Upstream commit 3867e38b2d4b844d89076f988c7b9741c87a9858 ] The ThinkBook 16p Gen 3 ARH (SSID 17aa:3871) has a TI TAS2563 amplifier device on I2C, exposed by ACPI as INT8866, the same arrangement as the Yoga 7 14ARB7 (SSID 17aa:3870). Without a quirk, the codec falls back to the vendor-wide Lenovo quirk (ALC269_FIXUP_LENOVO_XPAD_ACPI), the amplifier is never bound, and the internal speakers stay silent while the headphone output works. Reuse the Yoga 7 14ARB7 fixup, which binds the INT8866 device as a side codec. ALC287_FIXUP_TAS2781_I2C does not work on this machine because it looks for a TIAS2781 device. Assisted-by: LLM Signed-off-by: KIM MinWoo Link: https://patch.msgid.link/20260923013756.106033-1-phrimm136@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit cb2f6bf21d88e258d54c9e58b24fa1440417d493 Author: Tomasz Bojanowski Date: Wed Sep 23 20:49:57 2026 +0200 ALSA: usb-audio: Add mixer mapping for MSI MAG B850M MORTAR WIFI [ Upstream commit 7b457ae8cf711831f19d20963f5ed2fdf4842d3a ] The USB audio device 0db0:cc78 (Realtek ALC4080) on the MSI MAG B850M MORTAR WIFI motherboard exposes all playback controls as "PCM", which makes it hard to tell the outputs apart. Its mixer layout matches the one of the MSI MPG X570S Carbon Max Wifi (units 29, 30 and 32), so reuse msi_mpg_x570s_carbon_max_wifi_alc4080_map for this device too. With the mapping applied, the controls show up as "Speaker", "Front Headphone" and "IEC958". Tested with a patched snd-usb-audio module on a 7.2.7 kernel. Signed-off-by: Tomasz Bojanowski Link: https://patch.msgid.link/20260923184957.6687-1-tomasz@bojanowski.me Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 88c8e8ab2bce04a044920135fbc10bb328b1d646 Author: Hernan Ganzo Date: Mon Sep 21 21:55:38 2026 +0100 ALSA: hda/realtek: Limit internal mic boost on HP Pavilion 15 (103c:2164) [ Upstream commit 786fb6b3f513937f712db5a9ba6a12cbc6982ba9 ] The HP Pavilion 15 with the ALC3227 codec (SSID 103c:2164) exposes the full four-step internal mic boost on pin 0x12: nsteps=3 with stepsize=0x2f, that is 0, 12, 24 and 36 dB. Combined with the ADC capture gain of +30 dB the analogue cascade reaches 66 dB, and the internal microphone clips on the ambient noise of a quiet room; the upper two steps are unusable at any useful input level. This is the defect class ALC269_FIXUP_LIMIT_INT_MIC_BOOST exists for. The machine matches no SSID quirk and falls through to the pin table, which selects ALC269_FIXUP_HP_MUTE_LED_MIC1 through a pin signature shared with several other HP models. Add an SSID entry instead, using ALC269_FIXUP_LIMIT_INT_MIC_BOOST_MUTE_LED: the existing fixup that applies alc269_fixup_limit_int_mic_boost() and chains to the same mute LED fixup, as already done for 103c:218b. The boost becomes 0 or 12 dB and the LED handling is unchanged. Tested on the affected machine by selecting the same fixup through the model string (snd-hda-intel.model), which bypasses the SSID and pin tables, with the driver confirming the selection: snd_hda_codec_alc269 hdaudioC1D0: ALC3227: picked fixup limit-mic-boost (model specified) With that, Internal Mic Boost reports Limits 0 - 1 (0 or 12 dB) instead of 0 - 3 (0 to 36 dB), so alc269_fixup_limit_int_mic_boost() clamps this codec's internal mic pin as intended. Note that /proc/asound/card1/codec#0 keeps printing the unclamped hardware caps (nsteps=0x03): that file reads codec parameters uncached by design, while the fixup overrides the driver's cached parameter that the control is built from. This does not by itself make the default capture volume sane -- the remaining 12 dB on top of the +30 dB ADC gain is still hotter than this machine's usable operating point. It removes the two unusable steps from the hardware range, which is what a quirk of this class can do. Signed-off-by: Hernan Ganzo Link: https://patch.msgid.link/20260921205538.41192-1-gp@sneemgp.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 220ccef5e8ffd1e83e89535930ae2f726f7638f1 Author: Jasper Firth Date: Fri Sep 25 23:06:25 2026 +1000 ASoC: Intel: bytcr_rt5651: Add quirk for Chuwi Hi8 with generic DMI strings [ Upstream commit c5a8fc2abe05cf6db71f57ff0177fddc59861a1a ] Some Chuwi Hi8 tablets with model number CWI513 ship with a BIOS (American Megatrends 5.11, dated 05/21/2016) whose DMI sys_vendor and product_name are both "Default string". The tested unit is labelled just "Hi8", but its model number is the same as the existing "Chuwi Hi8 Pro (CWI513)" entry, and it needs the same quirks. That entry matches on sys_vendor "Hampoo" and product_name "X1D3_C806N", so it never applies to these units. Without its quirks the internal speaker, whose amplifier has a differential input wired across LOUT left and right, cancels to a faint distorted residual for any centred (L == R) content, and the headphone channels are swapped. Add an entry matching board_vendor "Hampoo" and board_name "Cherry Trail CR", plus the BIOS date since those two are too generic on their own. drivers/platform/x86/touchscreen_dmi.c already matches the Chuwi HiBook the same way. The quirks are those of the existing Hi8 Pro entry, except for the over-current detection scale factor: 1.0 instead of the 0.75 from BYT_RT5651_DEFAULT_QUIRKS. With 0.75 and a CTIA headset (inline mic and one button), loud speech into the mic, and headphone playback coupling onto the mic line, were reported as spurious KEY_PLAYPAUSE presses, one of them held for a whole 8 second speech window. With 1.0 the same test gave no spurious events, and 3 real button presses were reported as exactly 3 press/release pairs. Tested on a unit with the generic DMI strings, with a module built from this patch and no quirk module parameter. The quirks were applied via the new entry, the card components read "cfg-spk:1 cfg-mic:in2 cfg-hp:lrswap", and the following all work: speaker, headphone left/right order, jack and headset-mic detection, headset button, and the internal and headset mics. The problem was diagnosed with the help of an AI coding assistant, which also drafted this changelog. Assisted-by: Claude Opus 5.5 Signed-off-by: Jasper Firth Link: https://patch.msgid.link/20260925-hi8-quirk-v1-1-ffd00b0447f9@hotmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3090a0a33d3bbf44358516562a7fc9196c4dd046 Author: Daniel Ortiz Date: Sat Sep 19 20:19:20 2026 -0500 ASoC: amd: yc: Add DMI quirk for Lenovo V15 G6 ARP [ Upstream commit d395e1b62d9694f2e4add9122f8d473eacd374aa ] The Lenovo V15 G6 ARP (product name 83UU) uses the ACP6x PDM interface for its internal digital microphone array. Its firmware exposes neither the AcpDmicConnected _DSD property nor the _WOV method, so acp6x_probe() falls through to the DMI check and returns -ENODEV, leaving acp_yc_mach.0 unbound and no capture device registered. Add a DMI quirk entry for this model. With it, the machine driver binds and the DMIC capture device is created: acp_yc_mach acp_yc_mach.0: Enabling ACP DMIC support via DMI card 2: acp6x [acp6x], device 0: DMIC capture dmic-hifi-0 Capture was verified working with arecord and PipeWire. Signed-off-by: Daniel Ortiz Link: https://patch.msgid.link/20260920011920.2482786-1-letargopausado@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6d3df45115c84bcf6f8441cef9e5a31c29b59995 Author: Andy Moreton Date: Wed Sep 16 13:56:41 2026 +0100 sfc: add X4D PF support [ Upstream commit 24fedc7a569bce181728f0dd616504bef9f1513b ] X4D is an X4 controller instance as an IP block in an SoC. It has the same feature set as X4. Signed-off-by: Andy Moreton Reviewed-by: Pieter Jansen van Vuuren Reviewed-by: Alejandro Lucero Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260916125641.12238-1-alucerop@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3fa9e8c34b05e64e6e1d65d5980aaec58fb0d2e9 Author: Rosen Penev Date: Mon Sep 14 17:44:06 2026 -0700 gpio: mvebu: keep resume masks within the irqchip cache [ Upstream commit 02af7eac17bc62a72335c1fc8c4af4471654f6cc ] mvebu_gpio_resume() writes the edge/level mask registers saved at suspend time straight back to hardware, bypassing the irqchip's mask_cache_priv. genirq skips mask_irq() for a line it already considers masked, so restoring a bit in hardware that genirq thinks is still masked leaves that line unmasked behind genirq's back. An asserted level line then has nobody to ack it, and the moment interrupts are re-enabled the chained handler storms, hanging resume. AND the restored mask values with the matching irqchip mask cache so only lines genirq currently considers unmasked are unmasked again. Read the caches under gc->lock to keep them consistent with the mask/unmask handlers. Tested on Helios4 (armhf): 5 suspend cycles woken by magic packet, no hang; mvebu_gpio_resume() returns in 6 usecs. Assisted-by: LLM Signed-off-by: Rosen Penev Link: https://patch.msgid.link/20260915004406.115230-1-rosenp@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 63c4ba1fa06e12faa6be381a8b4bf41f3a6ca755 Author: Seiji Adachi Date: Thu Sep 17 22:18:51 2026 +0900 ASoC: amd: yc: Add Lenovo ThinkPad E16 Gen 2 (21JN) to quirks [ Upstream commit 4cae4ca34992d210d115e8e891f1e88c9df5f24c ] Signed-off-by: Seiji Adachi Link: https://patch.msgid.link/20260917131851.2122144-1-seiji_adachi@yahoo.co.jp Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1d7f659085de242a4261842272efc65f235abd8f Author: Ewan D. Milne Date: Tue Sep 15 13:38:00 2026 -0400 scsi: devinfo: Add BLIST_SKIP_IO_HINTS for EMC Symmetrix [ Upstream commit f06a44e235ef188689ba23ffc72e9e89b10951a9 ] EMC Symmetrix returns an error on MODE SENSE for page 0Ah subpage 05h because it does not implement the SBC-5 I/O hints. These commands began to be sent as a result of commit 4f53138fffc2 ("scsi: sd: Translate data lifetime information"). Add BLIST_SKIP_IO_HINTS to avoid sending these commands because in large configurations the failed commands are displacing other useful information in internal error logs. Signed-off-by: Ewan D. Milne Link: https://patch.msgid.link/20260915173800.39117-1-emilne@redhat.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit c1e8577f0f9d46d74de709a2b78924e383402db3 Author: Dmitry Antipov Date: Wed Sep 2 12:45:49 2026 +0300 HID: roccat: fix locking in roccat_connect() and roccat_disconnect() [ Upstream commit d76994443eed0af297cb82bd038ae9d76327ef90 ] Extend critical section in roccat_connect() to ensure that partially initialized 'struct roccat_device' is never exposed in 'devices' list, and do the same in roccat_disconnect() to avoid racy 'devices' access against roccat_release(). Signed-off-by: Dmitry Antipov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 383f7577677b5c061dca5d4378238becf8baf4b6 Author: Maurizio Lombardi Date: Tue Sep 8 16:34:34 2026 +0200 nvme-fc: do not warn on controller removal race [ Upstream commit 62b70e6c87121ae5b79ca20c3a5b005590336ec5 ] In nvme_fc_reconnect_or_delete(), the system attempts to remove the controller when reconnect limits are reached by calling nvme_delete_ctrl(). This call is currently wrapped in a WARN_ON(). If a user concurrently deletes the controller via sysfs, the controller's state may have already transitioned out of the CONNECTING state. When this happens, nvme_delete_ctrl() correctly rejects the operation and returns -EBUSY. Because of the WARN_ON() wrapper, this race condition triggers an unnecessary kernel warning stack trace. Remove the WARN_ON() macro around nvme_delete_ctrl(); this allows the system to safely ignore the -EBUSY return value if the controller is already being deleted. Signed-off-by: Maurizio Lombardi Reviewed-by: Daniel Wagner Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 080aa267bc1b1b04c7ef21852f563676ac875adc Author: Youth Cao Date: Fri Sep 4 00:14:44 2026 +0800 HID: i2c-hid: Add i2c-hid-quirk-bad-input-size quirk for 0911:5288 device [ Upstream commit 58d97b45f3f43af0afd9c74e8480d22d36fd3f72 ] I have recently acquired a cheap Apollo Lake-based laptop that uses a Hynitron CST128-A touchpad controller. While booting from a Debian LiveCD, the kernel log is flooded with the following error (though the touchpad works well): i2c_hid_acpi i2c-ALPS0001:00: i2c_hid_get_input: incomplete report (27/42405) The CST128-A was identified via ACPI as ALPS0001:00, and the I2C HID device ID (0911:5288) was shared with the Hantick 5288. Add the I2C_HID_QUIRK_BAD_INPUT_SIZE quirk option to the existing Hantick 5288 quirk entry to suppress the kernel log flood. Signed-off-by: Youth Cao Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 84ea0ab391ad22491292261df4bb0b51db972255 Author: Namjae Jeon Date: Sat Jul 11 23:20:41 2026 +0900 ksmbd: handle allocated range queries on dense files [ Upstream commit 350684e0498512d06963858b810101f58563810b ] FSCTL_QUERY_ALLOCATED_RANGES currently relies on SEEK_DATA and SEEK_HOLE for every file. That works for files with holes, but it is not a good match for dense files. A zeroed range in a dense file may be represented as an unwritten extent and skipped by SEEK_DATA. The server can then return no allocated ranges even though the file should still be treated as allocated from the protocol point of view. For dense files, report the requested range clipped to EOF as allocated instead of probing holes. Keep using SEEK_DATA and SEEK_HOLE for files marked with FILE_ATTRIBUTE_SPARSE_FILE, and wait for writeback before probing so punch-hole updates are visible to the filesystem seek implementation. This fixes the case where a query after zeroing data could return no ranges for a dense file. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 9ce99ddf7daf33ba2c1b254eb417a43acdf2b6a7 Author: Fernando Fernandez Mancera Date: Mon Jun 1 21:30:46 2026 +0200 netfilter: tproxy: use DEBUG_NET_WARN_ON_ONCE for protocol fallbacks [ Upstream commit 1f0391aea883e99d402d0f77ba3530e4e879350d ] Replace WARN_ON calls with DEBUG_NET_WARN_ON_ONCE in the default switch blocks of nf_tproxy_get_sock_v4 and v6. Unsupported transport protocols are already safely handled by returning a NULL socket pointer. This prevents unnecessary system panics when panic_on_warn=1 is enabled in production systems. Link: https://patch.msgid.link/cover.1786968834.git.zhilinz@nebusec.ai/ Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d19f802323c2d02619f14a98f9870eb6516d9dc3 Author: Xiubo Li Date: Tue Jul 14 14:20:37 2026 +0800 ceph: fix use-after-dereference of NULL ci in __ceph_remove_cap() [ Upstream commit a354d7eaa1a57f1532c8072a424cc2d339a73cc0 ] The NULL check for "ci" in __ceph_remove_cap() was dead code because ci was dereferenced via &ci->netfs.inode before the check, and cap->session was dereferenced via session->s_mdsc->fsc->client even earlier. On a double-remove, both cap->ci and cap->session are set to NULL by the first call, so the second call would crash before ever reaching the guard. Move ci, session, cl, and inode initializations after the NULL check so that the early-return actually works. Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 2d75679b6e42fd88b53d69cee24ebf3687c2459f Author: Mehmet Aysel Date: Tue Aug 25 12:24:31 2026 +0300 ASoC: amd: acp-config: Add HVY-WXX9/M1060 DMI quirk [ Upstream commit 032bb633e0c34a88b70a4bfc65ebd4e2b510f706 ] Add DMI match table entry for HUAWEI HVY-WXX9 board, product version M1060, a MateBook D16 2021 (Ryzen 5 4600H) revision not covered by the existing M1010/M1020/M1040 entries. This board uses the same FLAG_AMD_LEGACY / ACP_PCI_DEV_ID configuration as the other HVY-WXX9 variants. Signed-off-by: Mehmet Aysel Link: https://patch.msgid.link/20260825092432.56292-1-mehmet4ysel@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6dff8abd98397537a5fc38a266a3f179634b0b7d Author: Bob Song Date: Wed Aug 26 19:53:44 2026 +0800 ALSA: hda/conexant: Always enable the headset-mic pin on plugin [ Upstream commit 9642a5e843758686e02a7f0d1df9eb0f7f96603c ] Rename the function to cx_process_headset_detect_plug_type() to reflect that it only reports the detected plug type, and move the pin control write into cx_update_headset_mic_vref() so that node 0x19 is always set to enable the headset mic with the 80% VREF whenever the mic is present, regardless of the type detection result. Signed-off-by: Bob Song Link: https://patch.msgid.link/20260826115344.2128835-1-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d05b3fd6146a0e6484d49a1b8845f1cb35da4974 Author: Xiubo Li Date: Thu Jul 23 14:28:19 2026 +0800 ceph: do not cache negative dentries for snapped directories [ Upstream commit af59562a5b3d34fb3aa7753f2543393578d06dbf ] When a LOOKUP/LOOKUPSNAP in a snapped directory returns ENOENT without a trace, ceph_finish_lookup() creates a negative dentry via d_add(dentry, NULL). For live directories this is fine — the dentry naturally expires. But for snapped directories, ceph_d_revalidate() unconditionally trusts all cached dentries (valid = 1), so a negative dentry created by a transient error persists forever, hiding entries that genuinely exist in the snapshot. Only cache negative dentries for live (non-snapshotted) parent directories. For snapped parents, skip the negative dentry so that VFS retries the lookup on the next access. Since the conditions that trigger a negative dentry (MDS transient error, local ENOENT shortcut, or MDS null dentry lease) are all rare in snapped directories, the performance impact of this change is negligible. Link: https://tracker.ceph.com/issues/78529 Reported-by: Andras Pataki Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit f73988b69ebde3fdf72722cc8e7b5455fd0cb8a5 Author: Mehmet Aysel Date: Tue Aug 25 12:24:32 2026 +0300 ASoC: amd: acp3x-es83xx: Add HVY-WXX9/M1060 DMI quirk [ Upstream commit c1a39c228aceebc0ede83781ea906d257e324009 ] Add matching DMI table entry for the ES83xx machine driver, so the HUAWEI HVY-WXX9 / M1060 board (MateBook D16 2021, Ryzen 5 4600H) can successfully probe its ES8316 codec via the acp3x-es83xx machine driver, consistent with the existing M1010/M1020/M1040 entries for the same board name. Signed-off-by: Mehmet Aysel Link: https://patch.msgid.link/20260825092432.56292-2-mehmet4ysel@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ce6efe48786bacfbe241287ccb0519a09b7db09f Author: Federico Valentín Andrade Date: Mon Aug 24 11:02:11 2026 -0300 ALSA: usb-audio: Skip mixer creation on M-Audio Venom [ Upstream commit 4c0ec35e011309bd7091053ad5bbc01420967a66 ] The M-Audio Venom (0763:2084) does not answer any GET_CUR request of its feature units, hanging up the USB microcontroller and "responding" with timeouts. So the mixer building lasts around 47 seconds, and the device does not stream at all. The same GET_CUR requests issued through libusb (with no kernel driver bound) complete correctly and blazingly fast. So it seems to only happen during the initial probe. I defined an explicit composite quirk to bypass the mixer creation, as it is not needed (the synth already comes with volume controls). With both this and the device flag applied, the synth works flawlessly. Signed-off-by: Federico Valentín Andrade Link: https://patch.msgid.link/20260824140211.17003-3-fandrade@frba.utn.edu.ar Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 60a4e18bd1e379b16cd9c12152749889b3144b50 Author: Li Jun Date: Wed Aug 12 18:09:14 2026 +0800 tpm: tpm_tis_spi: fix nodef CR50 tpm_tis_spi_resume is null [ Upstream commit b4d1adc70471d0752bba674552d19971ed9fa869 ] if no define CONFIG_TCG_TIS_SPI_CR50 in config, the add of tpm_tis_spi_resume is null, this cause the tpm chip to fail to resume. Signed-off-by: Li Jun Link: https://lore.kernel.org/r/20260812100914.3540149-1-lijun01@kylinos.cn Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 4e3bc4fef23c82645bffd3591a61df9d976121f7 Author: Dave Carey Date: Thu Jul 30 08:43:36 2026 -0400 HID: multitouch: Fix stale MT slots when contact count drops to zero [ Upstream commit e8e60b6439eed340a611e9d7a5b9bcbd0ef62725 ] The INGENIC 17EF:6161 touchscreen (Lenovo Yoga Book 9 14IAH10) reports HID_DG_CONTACTCOUNT=0 in the frame immediately following the last finger lift rather than omitting the frame entirely. In mt_touch_report() the existing code only updates num_expected when contact_count is non-zero, so a zero contact count on the first packet of a new frame leaves num_expected at its previous value (e.g. 2 for a two-finger gesture). The sync check "num_received >= num_expected" then evaluates "0 >= 2" and never fires, preventing INPUT_MT_DROP_UNUSED from releasing the stale slots. Those slots remain active in the kernel MT layer until the next touch, at which point they are released in a batch alongside the new contact — causing the userspace event consumer to miss the intervening finger-up sequence and corrupt its gesture session state. Fix by resetting num_expected to 0 when contact_count is zero and num_received is still 0 (i.e., this is the first and only packet of the frame, not a continuation packet in a multi-packet sequence). With num_expected=0 the sync check "0 >= 0" fires immediately, calling input_mt_sync_frame() which drops the stale slots via INPUT_MT_DROP_UNUSED. The num_received==0 guard is critical: continuation packets in a multi-packet frame arrive after at least one contact has already been processed (num_received>0), so they are correctly excluded from this path and the existing multi-packet logic is unaffected. Signed-off-by: Dave Carey Tested-by: Dave Carey Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 360d5cce3a7b6f9b849c572c0f90d77379d1bcdf Author: Vadim Klishko Date: Mon Jul 27 22:17:18 2026 -0600 HID: i2c-hid: Add a quirk for a Cirque I2C device. [ Upstream commit 1c942462c3969b287a86ab6dbb143324289d564e ] Cirque touchpads with PID D0C1 generate an error when probed by the I2C HID driver, resulting in no hidraw device created. Adding I2C_HID_QUIRK_NO_IRQ_AFTER_RESET fixes the issue. Signed-off-by: Vadim Klishko Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit de382418e49cb9090c613a25004d6d798cdaf823 Author: Zhang Heng Date: Mon Aug 24 21:03:02 2026 +0800 ASoC: amd: yc: Add DMI entry for Alienware m18 R1 AMD [ Upstream commit fd8ed52ecea6b93e23d52cb2758fb4fb4029067f ] Add DMI entry so the YC machine driver probes on this model and the internal DMIC works. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221485 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260824130302.553419-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a96c68dd3978606556ae0ac20b802b6475857f9e Author: Jimmy Zuber Date: Mon Aug 24 14:30:51 2026 +0000 fuse: zero the partial EOF page when extending a file [ Upstream commit 34b5c4a6e4fb9dbb3f9d87f3b0fb0372105c8302 ] Extending a fuse file past a non-page-aligned EOF does not zero the tail of the old last page. When that page is cached and has been mmap-dirtied beyond the old EOF, the now in-bounds tail is served to later reads as stale data rather than zeros, which violates POSIX file-extension semantics. Some file systems get this zeroing automatically at writeback time (block_write_full_folio() / iomap_writeback_handle_eof() zero the tail of the folio straddling i_size). A non-writeback caching fuse file system uses neither path, so it has to zero the tail itself from the size-extending paths, like XFS (xfs_file_write_zero_eof()) and ext4 (ext4_block_zero_eof()) do. Call truncate_pagecache_range() over the newly-exposed range up front from the three paths that extend a file, before the new size is published: - a buffered write whose position is past the old EOF (fuse_perform_write()); - a size-extending setattr/truncate (fuse_do_setattr()); - a size-extending fallocate (fuse_file_fallocate()). This unmaps the stale mappings and zeroes the partial tail of the old EOF folio, so a later read returns zeros. Truncating [old EOF, write start) before a buffered write keeps the dropped range disjoint from the written data, so a write that lands inside the old EOF folio is preserved. writeback_cache connections are unaffected, as their writes go through iomap_file_buffered_write(), which zeroes post-EOF folios. The bug is observable on a non-writeback_cache server that returns FOPEN_KEEP_CACHE on writable files (without FOPEN_DIRECT_IO), and is caught by the new write_extend_eof fuse selftest. Signed-off-by: Jimmy Zuber Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 99936774831fb46f0566f651b8839cbda2967751 Author: Zhang Heng Date: Mon Aug 24 20:37:52 2026 +0800 ALSA: hda/realtek: Add quirk for Lenovo IdeaPad Slim 3 15ABR8 [ Upstream commit be79a45e2ec289eb9fad519e8f5a3d4fc3789dd0 ] The internal microphone on Lenovo IdeaPad Slim 3 15ABR8 (subsystem 17aa:3862) exhibits severe distortion at default gain levels. The Capture Volume is fixed at 63 (max) and cannot be lowered without explicit userspace intervention. The existing fixup ALC269_FIXUP_LIMIT_INT_MIC_BOOST limits the gain range and resolves the issue. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221891 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260824123752.525173-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a7d43b1cecbb1b31d3e880772795e4e5b395f1bc Author: Md Rabbani Date: Fri Aug 21 11:57:18 2026 +0600 net: stmmac: fix device node reference leaks in stmmac_mtl_setup() [ Upstream commit 317fe168f4c0fc30e5c375c22d9c8911940aea9b ] In stmmac_mtl_setup(), q_node is shared across the RX and TX queue parsing loops. When the RX queue loop breaks early because the number of parsed queues reaches plat->rx_queues_to_use, q_node retains an acquired reference count. If the error check passes (queue == plat->rx_queues_to_use), execution proceeds directly to the TX queue loop, where of_get_next_child() immediately overwrites q_node with the first TX child, permanently leaking the retained RX child device node reference. Switch both loops to for_each_child_of_node_scoped() so child node references are automatically dropped upon loop exit or early break, and remove the now-unnecessary function-scoped q_node variable and its manual of_node_put() at the exit label. Signed-off-by: Md Rabbani Link: https://patch.msgid.link/20260821055718.57-1-rabbanyhmm@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8609ddbab9d75079c8db11537354c96b0a055ae8 Author: Sumeet Pawnikar Date: Sat Aug 22 15:16:57 2026 +0530 powercap: intel_rapl: Fix kernel panic during PMU unbind [ Upstream commit 916b61abba586d950a4d8264e2841cc5ccfa4df1 ] rapl_package_add_pmu() fails internally at perf_pmu_register(), and rapl_pmu_update() leaves the global rapl_pmu.pmu structure zero-initialized via memset and returns an error. But any previously probed packages retain has_pmu = true. When the driver is subsequently unbound or removed, rapl_package_remove_pmu_locked() sees has_pmu == true and unconditionally calls perf_pmu_unregister(&rapl_pmu.pmu) on the zeroed-out structure. This attempts a list_del_rcu() on a NULL list head, immediately causing a kernel panic. Fix this by checking if the PMU is actually registered before attempting to unregister it. Signed-off-by: Sumeet Pawnikar Reviewed-by: Abel Vesa [ rjw: Added empty line after the new conditional ] Link: https://patch.msgid.link/20260822094657.12489-1-sumeet4linux@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 8e29c8e085f0c4f4b3e3de41d86c7e249afbd3e3 Author: Helge Deller Date: Sat Aug 22 12:03:15 2026 +0200 fbcon: Fix KASAN slab-out-of-bounds Read in fbcon_prepare_logo [ Upstream commit 94e6a058b16820e02f25e1221a4c4e713ba23550 ] Ensure the logo will not exceed the screen size, which then should fix a reported KASAN: slab-out-of-bounds Read in fbcon_prepare_logo. Reported-by: syzbot+0c815b25cdb3678e7083@syzkaller.appspotmail.com Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 675fdbd76694c3df5f9d8e560ff9045ca7fda1f5 Author: Shiji Yang Date: Wed Aug 19 21:07:07 2026 +0800 net: ethernet: mtk_wed: increase WED v2 WDMA RESV_BUFF to 0x80 [ Upstream commit c0ef04232f9fac083c3d8a77ce58ba32243e6734 ] Change WDMA RESV_BUFF from 0x40 to 0x80 to avoid CDM TX FIFO overflow. Without this patch mt7986 and mt7981 may have WDMA TX hang issue. This patch was pulled from mtk-openwrt-feeds GPL open source project. Link: https://github.com/mediatek/mtk-openwrt-feeds/commit/07c87502e854b68b48544d101b6fe17ec059b97b Signed-off-by: Shiji Yang Reviewed-by: Simon Horman Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/OSZPR01MB779537889255E2F606E47EABBCA52@OSZPR01MB7795.jpnprd01.prod.outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0881b9f1b71d257906bc7553e3e4b815f8f9f9b4 Author: Jenson Johnathon Reggentin Date: Wed Aug 19 21:23:59 2026 +0200 docs: block: fix dead http link in blk-mq.rst [ Upstream commit b40a680ea4efe4ef2addada63e304a94d19500d1 ] The current link http://kernel.dk/blk-mq.pdf leads to a 404 error page. https://www.kernel.dk/blk-mq.pdf leads to the correct document. v2 to add the missing www. prefix in the actual file change. Signed-off-by: Jenson Johnathon Reggentin Acked-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20260819192422.42189-1-mail@jregg.de> Signed-off-by: Sasha Levin commit e1317d6248125677c1d1483f2c6cc67f22447f53 Author: Chen Changcheng Date: Mon Jul 27 15:34:38 2026 +0800 scsi: snic: Fix SCSI host leak on workqueue allocation failure [ Upstream commit 12e67eb89eb2b9516685c744d3f7de0a2d1bd701 ] In snic_add_host(), if scsi_add_host() succeeds but alloc_ordered_workqueue() fails, the function returns -ENOMEM with shost->work_q left as NULL. The caller's error path then calls snic_del_host(), which returns early when !shost->work_q without calling scsi_remove_host(). The Scsi_Host remains registered in sysfs as a zombie device even after the probe has failed. This causes: - The leaked host remains visible in /sys/class/scsi_host/ after probe failure, with state "running". - Subsequent SCSI host numbering is permanently shifted (the leaked host ID from ida_alloc() is never reclaimed). - Memory leak: the Scsi_Host allocation can never be freed because device_add() took a reference that can only be released by device_del() inside scsi_remove_host(). Fix by adding scsi_remove_host() in the workqueue allocation failure path inside snic_add_host(), undoing the successful scsi_add_host() before returning the error. This is cleaner than modifying snic_del_host() because snic_del_host() is called from a shared error label that also serves paths where snic_add_host() was never invoked. Reproducer (requires no real SNIC hardware): - Build CONFIG_SCSI_SNIC=y (built-in) - Add snic.test_mode=1 snic.inject_wq_fail=1 to kernel cmdline - Boot with a PCI device matching the snic driver (e.g. QEMU edu device, PCI ID 0x1234:0x11e8, temporarily added to the driver's PCI ID table) Before the fix: # /sys/class/scsi_host/ contains a zombie host0: $ cat /sys/class/scsi_host/host0/proc_name snic_scsi $ cat /sys/class/scsi_host/host0/state running # ata_piix gets host1, host2 (host0 stuck): scsi host1: ata_piix scsi host2: ata_piix After the fix: # host0 is properly freed and reused by ata_piix: scsi host0: ata_piix scsi host1: ata_piix # No zombie host in /sys/class/scsi_host/ Signed-off-by: Chen Changcheng Acked-by: Narsimhulu Musini Link: https://patch.msgid.link/20260727073438.209673-1-chenchangcheng@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit e595282d86e6299d9e180bc9b7487b741e42ee19 Author: Will Porter Date: Sat Aug 22 20:53:53 2026 -0500 ALSA: usb-audio: Add iD14 MkI to monitor-mix volume quirk [ Upstream commit 17056a36d276a740f09dca723de1bc6aa3eb4ef9 ] Add the iD14 MkI USB ID to the existing audient_id14_map. This names feature unit 12 Monitor Mix Playback Volume. Live meter A/B testing on MkI USB ID 2708:0002 reproduced the same asymmetric attenuation seen on MkII. At ALSA value 104, the right channel was 23.07 dB below the left. At 127, both channels were equal. The misleading Speaker Playback Volume name causes PipeWire to adopt FU12 as the stream master. Reuse the existing map to keep the control available while preventing that selection. Hardware-tested on Bazzite 7.2.0-ogc4.1.fc44.x86_64 with this change backported. ALSA exposed Monitor Mix Playback Volume after module load and USB reconnect. PipeWire volume changes from 100% to 35% and back left all four FU12 values at 127. Channel-isolated left/right playback remained balanced after reconnect. Build-tested with CONFIG_SND_USB_AUDIO=m using the focused sound/usb target. Assisted-by: Codex:gpt-5 Signed-off-by: Will Porter Link: https://patch.msgid.link/20260823015353.686080-1-mrwillporter@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit df3ba527d95f32d859c92446bc13cc3ae5ca6382 Author: Csaba Budai Date: Fri Aug 21 12:25:14 2026 +0200 ALSA: hda/realtek: Fix ALC700 audio on Intel Hades Canyon [ Upstream commit 1fcccdc20a76b4639b00124cf2a379b837bd2bf7 ] On Intel Hades Canyon systems with an ALC700 codec, analog audio can become unusable after rebooting from Windows into Linux. The affected system uses codec subsystem ID 8086:2073. In the broken state, Realtek coefficient 0x1b has value 0x4a4b. Setting bit 0x0400 changes it to 0x4e4b and immediately restores normal analog playback. The BIOS also sets this bit after disabling and re-enabling onboard audio, while Windows may leave it cleared. Linux currently does not restore it during codec initialization. Add a machine-specific fixup for Intel Hades Canyon which sets only bit 0x0400 of coefficient 0x1b during HDA_FIXUP_ACT_INIT. The fix has been verified across Windows -> Linux reboots on an Intel NUC8i7HNB with an ALC700 codec. Signed-off-by: Csaba Budai Link: https://patch.msgid.link/20260821102514.11194-1-ilyr73@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 445abfb44ba7e83c682fc6183b176c38efee98ae Author: Daeho Jeong Date: Thu Aug 20 09:43:40 2026 -0700 f2fs: avoid setting SBI_NEED_FSCK on transient resize failure [ Upstream commit 258c95150c26a30db1896eacd3bdef26314f2ca1 ] When free_segment_range() fails in f2fs_resize_fs(), no on-disk superblock or filesystem metadata has been modified yet, and free_segment_range() safely restores all in-memory counters before returning. However, the current error recovery path unconditionally sets the SBI_NEED_FSCK flag and prints a scary error message on any error, forcing an unnecessary and time-consuming fsck.f2fs repair on the subsequent mount/reboot. Fix this by separating the error recovery path with a dedicated recover_user_blocks label to bypass setting SBI_NEED_FSCK on free_segment_range() failures. Signed-off-by: Daeho Jeong Signed-off-by: Sunmin Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 527f91d7ce6dae395ab08df739ba21cc722bd217 Author: Robin Everaars Date: Mon Aug 17 14:14:17 2026 +0000 ACPI: button: Add DMI quirk for Razer Blade Pro 17 early 2020 lid switch [ Upstream commit 415125669c2ddc773c579a60df108f75712dfa83 ] The lid switch reports "close" but can miss the matching "open", leaving _LID closed after resume. systemd-logind then suspends the system again roughly every 35 seconds. Reading the embedded controller's PSTA byte while _LID is stale shows that bit 0x04 is set, which the DSDT treats as open. The DSDT returns the cached LIDS byte from _LID. Its wake path aborts in RTEC on an unhandled SystemCMOS region before copying PSTA to LIDS. Initialize the lid state to open on resume, matching the existing quirk for the Razer Blade Stealth 13 late 2019. With button.lid_init_state=open, a physical close suspended once and resume reported open without another suspend. Signed-off-by: Robin Everaars Link: https://patch.msgid.link/20260817141414.213075-1-robineveraars@pm.me Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 7bdf1f7760188f1f0b929619e26c57002384f06e Author: Tao Cui Date: Fri Aug 14 22:41:16 2026 +0800 sched_ext/scx_flatcg: expire cached hweights on weight changes [ Upstream commit 94c20e1fb334c2082b443c4470a86ad982f67282 ] fcg_cgroup_set_weight() updates cgc->weight and the parent's child_weight_sum but doesn't bump hweight_gen, so the hweights cached by cgrp_refresh_hweight() stay stale until some task activation bumps the generation. For cgroups whose tasks never go through a 0->n runnable transition (e.g. persistently busy ones), a cpu.weight change never propagates to scheduling at all. Bump hweight_gen on weight changes so the next refresh recomputes with the new weight. Verified on a flatcg VM: a live cpu.weight 100->800 change on a busy cgroup leaves HWT update at 0 and the distribution unchanged; with it, hweight_gen increments and the refresh recomputes. Signed-off-by: Tao Cui Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit bda421c0ef8eb61c69d41a4aa6b063bb9bc96e74 Author: Namjae Jeon Date: Wed Aug 19 10:01:11 2026 +0900 ksmbd: enable TCP keepalive for accepted connections [ Upstream commit 56549c18a4f75309161ca780feaa4d17904e3ee9 ] A client that disappears without sending a FIN or RST can leave its ksmbd connection in ESTABLISHED indefinitely. ksmbd sets a socket receive timeout, but the connection receive loop retries timeout errors without a limit, so the connection remains in conn_list and consumes the per-IP connection quota. Enable SO_KEEPALIVE on accepted TCP sockets so the TCP stack can detect a silent peer failure. The keepalive idle time, interval, and probe count remain controlled by the existing TCP sysctl settings. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 404d2098d548f91c66c22f32e57d601fb6684317 Author: BingKun Yue Date: Mon Aug 17 14:39:42 2026 +0800 fbdev: platinumfb: add error checking for ioremap calls [ Upstream commit ba13226fc966004713aed47931db8922b84d1960 ] The ioremap() and ioremap_wt() calls in platinumfb_probe() were not checked for failure. If any of these mappings fail, the driver would dereference NULL pointers, leading to a kernel panic. Add proper error checking and use goto-based cleanup to avoid code duplication across the error paths. Signed-off-by: BingKun Yue Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 4a8b4439ad93a46f600fd52de54f50cdbf32e809 Author: Randy Dunlap Date: Thu Aug 13 16:29:34 2026 -0700 fbdev: maxine: fix 64-bit build error [ Upstream commit 3adec5c640dc09dca5605043e138412fd5a0629d ] The KSEG1ADDR() macro is only defined for non-64BIT builds. Use the CKSEG1ADDR() macro instead. In file included from ../drivers/video/fbdev/maxinefb.c:34: ../drivers/video/fbdev/maxinefb.c: In function 'maxinefb_ims332_write_register': ../include/video/maxinefb.h:16:41: error: implicit declaration of function 'KSEG1ADDR'; did you mean 'CKSEG1ADDR'? [-Wimplicit-function-declaration] 16 | #define MAXINEFB_IMS332_ADDRESS KSEG1ADDR(0x1c140000) ../drivers/video/fbdev/maxinefb.c:66:49: note: in expansion of macro 'MAXINEFB_IMS332_ADDRESS' 66 | register unsigned char *regs = (char *) MAXINEFB_IMS332_ADDRESS; ../drivers/video/fbdev/maxinefb.c:66:40: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 66 | register unsigned char *regs = (char *) MAXINEFB_IMS332_ADDRESS; Signed-off-by: Randy Dunlap Acked-by: Maciej W. Rozycki Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 12871ea3102aa08adf6f770fd9ead4c92dc8518c Author: Carlos Song Date: Thu Jul 16 15:19:56 2026 +0800 i2c: imx-lpi2c: properly unwind resources on probe failure [ Upstream commit cbd043b00ee3f542c115c8809c4d9a67465c07d5 ] When probe fails at devm_clk_rate_exclusive_get() or clk_get_rate(), which occur before runtime PM is initialized, the clocks enabled by clk_bulk_prepare_enable() are never disabled. When probe fails after runtime PM is initialized, the previous error path called pm_runtime_put_sync(), which triggers the runtime suspend callback. However, due to different clock management strategies on different SoCs[1] (to avoid deadlocks between the global prepare_lock and runtime PM), the callback may only disable clocks without unpreparing them, causing an incomplete unwind. Introduce a new error label 'clk_disable' to explicitly invoke clk_bulk_disable_unprepare(). Replace pm_runtime_put_sync() with the sequence of pm_runtime_disable(), pm_runtime_set_suspended() and pm_runtime_put_noidle() to bypass the runtime suspend callback during error recovery. During the LPI2C driver probe phase, clock APIs are used exclusively to manage clocks. Once probing succeeds, clock management is handed over to the runtime PM core. [1] https://lore.kernel.org/all/20251125084718.2156168-1-carlos.song@nxp.com/ Signed-off-by: Carlos Song Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260716071957.2670263-2-carlos.song@oss.nxp.com Signed-off-by: Sasha Levin commit cf6a26b856bd338cff943bbf00508cc4db3544ed Author: Pengpeng Hou Date: Sat Jul 4 20:17:34 2026 +0800 rtc: brcmstb-waketimer: add missing MODULE_DEVICE_TABLE() [ Upstream commit 402c89d28fecd28652a4bfe997f08f6544836381 ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704121734.54941-1-pengpeng@iscas.ac.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 0edae53da5a6bec3a01d6a5b199323c98d15355f Author: Robert Leussler Date: Tue Jul 21 08:19:07 2026 +0000 rtc: ds1307: fix RX8130 wakeup alarm WADA bit for day-of-month mode [ Upstream commit 878d93aaa596a861dbc8d71f7c38e62a2e805f01 ] The RX8130 wakeup alarm never fired when set via /sys/class/rtc/rtc0/wakealarm. The root cause is that the WADA bit (bit 3) in the Extension register (0x1c) was never set before programming the alarm registers. Per the RX8130 datasheet: WADA=0 - Week alarm: register 0x19 is compared against day-of-week WADA=1 - Day alarm: register 0x19 is compared against day-of-month rx8130_set_alarm() always writes a BCD day-of-month value to alarm register 0x19, so WADA must be 1. With WADA=0 the hardware matched the day-of-month value (e.g. 15) as a day-of-week index, which is always out of range (valid weekdays are 0-6), so the alarm interrupt was never asserted. Fix by setting the WADA bit in rx8130_set_alarm() before writing the Extension register back to the device. This is consistent with rx8130_read_alarm(), which decodes the same register under the same assumption (24-hour and day-of-month mode). Signed-off-by: Robert Leussler Link: https://patch.msgid.link/20260721081907.3518648-1-robert.leussler@leica-geosystems.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 6290f6bf571da674974fb9208cbac01998d1f06b Author: Jack Yu Date: Thu Aug 20 17:24:15 2026 +0800 ASoC: rt712-sdca: Pull high JD2 to prevent from entering TV mode [ Upstream commit dfb8bc1d286fd97b7cf47e3af5df84cfb068d214 ] Add a patch setting to prevent ALC712 from entering TV mode which may cause unexpected issues. Signed-off-by: Jack Yu Link: https://patch.msgid.link/20260820092415.2979641-1-jack.yu@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ad16fbd488ce1803030a65f766f3211db8212da3 Author: Jinqian Yang Date: Thu Jul 16 19:59:40 2026 +0800 virtio_ring: fix infinite loop in virtnet_poll_cleantx when device is broken [ Upstream commit 0d0eff39ceb3dcbf7847a6f4517086c207c60081 ] virtnet_poll_cleantx() contains a do-while loop that cleans up transmitted TX buffers and calls virtqueue_enable_cb_delayed() to check whether more buffers need processing. When the virtio backend stops responding during guest reboot, used->idx is never updated, so virtqueue_enable_cb_delayed() always returns false and the loop never terminates. Then it will block reboot process, and the guest will hang. The problem occurs during guest reboot under network traffic: 1. kernel_restart() -> device_shutdown() traverses the device list 2. virtio_dev_shutdown() calls virtio_break_device() which sets vq->broken = true 3. virtio_dev_shutdown() then calls virtio_synchronize_cbs() to wait for in-flight callbacks to complete 4. A virtio interrupt fires, softirq is deferred to ksoftirqd which calls net_rx_action() -> virtnet_poll() -> virtnet_poll_cleantx() 5. virtnet_poll_cleantx() enters the do-while loop and never exits because the QEMU backend has stopped updating used->idx, despite vq->broken having been set to true in step 2. Since the loop runs inside ksoftirqd (a SCHED_OTHER kthread), it is visible to the scheduler and does not trigger a hard lockup. However, the kthread never leaves the loop, so RCU detects it as a CPU stall and reports it periodically. Meanwhile, the reboot process remains blocked in device_shutdown() because virtio_dev_shutdown() cannot complete its synchronization step, and the guest hangs permanently. This can be reproduced on a guest with a virtio-net device: run iperf3 traffic in the guest, then trigger reboot. The reboot occasionally hangs permanently with RCU stall on ksoftirqd. Observed on ARM64 KVM guest: CPU#1 RCU stall (ksoftirqd/1), repeated periodically: virtqueue_enable_cb_delayed_split <- virtnet_poll <- __napi_poll <- net_rx_action <- handle_softirqs <- run_ksoftirqd <- smpboot_thread_fn <- kthread Fix by adding a vq->broken check in virtqueue_enable_cb_delayed(), so that the loop exits immediately when the device is broken, allowing the device shutdown to proceed. Signed-off-by: Jinqian Yang Reviewed-by: Xuan Zhuo Signed-off-by: Michael S. Tsirkin Message-ID: <20260716115940.394832-1-yangjinqian1@huawei.com> Signed-off-by: Sasha Levin commit 2d6252f7abcdca6abd897c3ceeb5da5d845036d3 Author: Pengpeng Hou Date: Sat Jul 4 23:25:28 2026 +0800 rtc: ab-eoz9: add missing MODULE_DEVICE_TABLE() [ Upstream commit 7490b8356e52e09c196645912f2c054f79aa5f3a ] The driver has a match table for the i2c bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704152528.53258-1-pengpeng@iscas.ac.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 617668ddfbf0dad026fd768703468f4a95896726 Author: Denis V. Lunev Date: Wed Jun 24 16:08:46 2026 +0200 virtio_balloon: warn on failed buffer add in tell_host() [ Upstream commit 198eda395067b56ee605de076f0519620f4e5d90 ] tell_host() ignores the return value of virtqueue_add_outbuf() and goes on to kick the queue and wait_event() for the host's ack. The comment claims "We should always be able to add one buffer to an empty queue", but that does not hold once the virtqueue has been broken (e.g. on device shutdown): the add then fails with -EIO and the following wait_event() would block forever on a buffer the host can never return. Warn and bail out on failure, mirroring virtballoon_free_page_report(). Suggested-by: David Hildenbrand Signed-off-by: Denis V. Lunev Signed-off-by: Michael S. Tsirkin Message-ID: <20260624140846.2616797-5-den@openvz.org> Signed-off-by: Sasha Levin commit eb1ad336069cb43b6d3aeb42f9e8ea86b278a738 Author: Weimin Xiong Date: Thu Jul 16 13:43:53 2026 +0800 vdpa/mlx5: roll back MR update after VQ setup failure [ Upstream commit 11f79e2780043ad94424a8db02a7a9022ba93252 ] mlx5_vdpa_change_map() must install the new MR before rebuilding or resuming virtqueues, because both paths read the MR keys from mvdev->mres.mr[]. If rebuilding the virtqueue resources fails, the new MR must not remain installed after its reference is released. Keep an extra reference to the old MR before replacing it. On setup failure, restore the old MR; the saved reference then becomes the map reference, while replacing the new MR drops its map reference. Make mlx5_vdpa_change_map() consume new_mr on all error paths so that set_map_data() does not release an MR already released during rollback. v2: - Keep the new MR installed while virtqueues are rebuilt. - Restore the old MR only after setup_vq_resources() fails. Signed-off-by: Weimin Xiong Signed-off-by: Michael S. Tsirkin Message-ID: <20260716054353.155805-1-xiongwm2026@163.com> Signed-off-by: Sasha Levin commit c1d97298e9d94da55b799809df066e6051e5d71a Author: Gilles Risch Date: Mon Aug 17 02:43:26 2026 +0200 drm/radeon: fix internal display on iMac11, 1 (RV770/DCE3.1) [ Upstream commit 275c3332585bbabcefad109a6978cc0cbecf2008 ] The Apple iMac11,1 (27-inch, Late 2009) uses a Mobility Radeon HD 4850 (RV770/DCE3.1) with a 2560x1440 internal panel on an internal DisplayPort path. Without this fix the display stays dark under KMS. This machine suffers from the same issue as iMac10,1 and iMac11,2: Apple routes the internal display through Link B of the DIG encoder instead of Link A. Add iMac11,1 to the existing DMI quirk and move the Apple-specific encoder assignment into its own block, independent of the DCE version check. Additionally, the 2560x1440 panel requires RADEON_PLL_USE_FRAC_FB_DIV and ATOM_ENCODER_CMD_DP_VIDEO_ON, limited to iMac11,1 via dmi_match() to avoid affecting other boards. Reviewed-by: Lukas Wunner Signed-off-by: Gilles Risch Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 786662bc08445d38da2f9bf4815fd515e212abe7 Author: Xiong Weimin Date: Fri Jun 26 10:05:45 2026 +0800 vdpa_sim: hold iommu_lock across dma_unmap passthrough transition [ Upstream commit 7b411448c668bfab0d0e572cee5a592cea396ce7 ] vdpasim_dma_map() updates the IOTLB and the passthrough (iommu_pt) state under iommu_lock. vdpasim_dma_unmap() clears iommu_pt and resets the IOTLB before taking iommu_lock, then deletes the mapping while holding the lock. A concurrent dma_map(), dma_unmap(), or reset path that also touches the same address space can therefore observe or modify the IOTLB and iommu_pt state without consistent locking. Perform the passthrough transition and range deletion under the same iommu_lock scope, matching dma_map(). Tested-on: openEuler VM (6.16.8, /usr/src/linux-6.16.8) Tested-by: Xiong Weimin Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <20260626020545.607600-3-15927021679@163.com> Signed-off-by: Sasha Levin commit 160221009e11247a5122c63a5105d93bbfa63f8f Author: Kuninori Morimoto Date: Tue Aug 18 01:46:29 2026 +0000 ASoC: codec: max98926: fixup invert setup mask [ Upstream commit dd0ae9a2e19a24c532c9aa80a44f572b4907bcdf ] invert might have both WCI/BCI mask, but regmap_update_bits() masks BCI only. It needs both mask. Fixup it. static int max98926_dai_set_fmt(...) { ... switch (fmt & SND_SOC_DAIFMT_INV_MASK) { case SND_SOC_DAIFMT_NB_NF: break; case SND_SOC_DAIFMT_NB_IF: => invert = MAX98926_DAI_WCI_MASK; break; ^^^^^^^^^^^^^^^^^^^^^ case SND_SOC_DAIFMT_IB_NF: => invert = MAX98926_DAI_BCI_MASK; break; ^^^^^^^^^^^^^^^^^^^^^ case SND_SOC_DAIFMT_IB_IF: => invert = MAX98926_DAI_BCI_MASK | MAX98926_DAI_WCI_MASK; break; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ default: ... } ... regmap_update_bits(max98926->regmap, MAX98926_FORMAT, MAX98926_DAI_BCI_MASK, invert); ... ^^^^^^^^^^^^^^^^^^^^^ } Signed-off-by: Kuninori Morimoto Link: https://patch.msgid.link/87wltomc97.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0790bcd121abd7bdd9c3e7d8fcb896b0f4d4d068 Author: Andrew Onyshchuk Date: Thu Aug 6 08:44:17 2026 -0700 platform/x86: thinkpad_acpi: Fix fan speed reporting on Edge E330 [ Upstream commit 8d840dad456f88374d8a3b03851452a280d6ee50 ] The ThinkPad Edge E330 with H3 firmware uses the non-standard EC fan register block. Without a matching quirk, thinkpad_acpi reads the legacy tachometer registers and reports 0 RPM. Add the H3 BIOS family to TPACPI_FAN_NS so the driver reads the fan period from EC register 0x95 using the existing non-standard reporting path. Tested on a ThinkPad Edge E330 with BIOS H3ET77WW and EC H3EC35WW. Signed-off-by: Andrew Onyshchuk Reviewed-by: Mark Pearson Link: https://patch.msgid.link/20260806154417.618575-1-andryk.rv@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit d90750ce770584181bd9a2821e6afc53205f2667 Author: Yaroslav Dudkov Date: Fri Aug 7 18:05:53 2026 +0000 platform/x86: msi-ec: Add MSI Katana GF76 11UEK EC firmware [ Upstream commit 0b30e6e583b2988864ffa7aeb2905bc2d0c7d575 ] Add the firmware string '17L1EMS1.107' to the ALLOWED_FW_13 array. This enables Embedded Controller support, including battery charge thresholds, for the MSI Katana GF76 11UEK (MS-17L1) laptop. Tested on MSI Katana GF76 11UEK with EC firmware 17L1EMS1.107 and BIOS E17L1IMS.312. Signed-off-by: Yaroslav Dudkov Link: https://patch.msgid.link/20260807180553.869371-1-aroslavdudkov622@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 485d0897dcd48cf9e5f61450bd86130abcce633b Author: Alex Elder Date: Wed Aug 12 11:38:30 2026 -0500 net: stmmac: use dma_addr_t for DMA addresses [ Upstream commit 0c1f9020d2ada55aed8a2e055903ad9cd5d49dab ] In jumbo_frm() (implemented in both "chain_mode.c" and "ring_mode.c"), an unsigned integer local variable is used to hold the value returned by dma_map_single(). On systems where a dma_addr_t is 64 bits, the subsequent dma_mapping_error() check of the returned value operates only on the low 32 bits (whose high bit won't be sign-extended). In this case, dma_mapping_error() would return 0 (no error) even if there were one. Fix this in both spots by using a dma_addr_t for the local variable. Reported-by: Sashiko Link: https://lore.kernel.org/linux-devicetree/20260606010122.21A211F00899@smtp.kernel.org/ Reviewed-by: Maxime Chevallier Signed-off-by: Alex Elder Link: https://patch.msgid.link/20260812163832.271742-2-elder@riscstar.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a3729563467b7c1e8fbb319d2b64a705b34f09ee Author: Jia Zhu Date: Tue Jul 7 21:36:23 2026 +0800 NFSv4: pin the superblock for active state owners [ Upstream commit 8cb1ce7aa0e8ac30e55f5bccfb80125f2e43e84a ] NFSv4 open state can outlive the file and dentry that created it. This was observed in production when NFSv4 state recovery, such as after a server reboot or lease expiration, raced with unmount. The race requires recovery to hold an open state reference while the last open file is closed and the filesystem is unmounted, allowing the superblock's active reference to drop to zero between refcount_inc(&state->count) and nfs4_put_open_state(): state manager umount nfs4_run_state_manager() nfs4_do_reclaim() nfs4_reclaim_open_state() refcount_inc(&state->count) ... close last file generic_shutdown_super() "Busy inodes after unmount" nfs_free_server() nfs4_put_open_state() iput(inode) evict() nfs_clear_inode() nfs_zap_acl_cache() The "VFS: Busy inodes after unmount" warning is the visible symptom of that lifetime mismatch: superblock teardown proceeds even though the NFS open state still pins an inode. After umount has freed the server, the state manager can then run nfs4_put_open_state() for the last open-state reference. The resulting iput(inode) can evict an NFS inode with freed server data, causing crashes at nfs_zap_acl_cache(). This can be reproduced by delaying the reclaim path before nfs4_put_open_state(), then closing the last file and unmounting the NFS mount. Pin the superblock while a state owner is active, and drop the pin when the owner becomes idle again, so the NFS server stays alive until all open state associated with the owner has been released. Assisted-by: Codex:GPT-5 Signed-off-by: Jia Zhu Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 1fe9b3c0d97d8bd6669dc8280da24c77c232a9f3 Author: ZhangGuoDong Date: Fri Jul 3 14:54:48 2026 +0800 NFS: Verify symlink inode before caching target [ Upstream commit 3265f1998ae9a9282a8a6ca95467d9572d6ebb82 ] nfs_symlink() copies the symlink target into a folio before issuing the SYMLINK RPC. After a successful reply, it caches that folio in the instantiated inode mapping and assumes that the dentry now names a symlink. If the dentry is instantiated with a non-symlink inode, the raw symlink target folio can be inserted into the wrong mapping. When that inode is a directory, reclaim or unmount later calls nfs_readdir_clear_array() through nfs_dir_aops and interprets the symlink target as a readdir cache array, which can lead to invalid kfree() calls. A vmcore from a 4.19-based kernel showed the crash when reclaiming a directory mapping on unmount: Stack trace: nfs_readdir_clear_array+0x4d/0x70 [nfs] page_cache_free_page.isra.35+0x1a/0x90 delete_from_page_cache_batch+0x1cf/0x2c0 truncate_inode_pages_range+0x24d/0x910 [...] nfs_evict_inode+0x15/0x30 [nfs] evict+0x115/0x2b0 dispose_list+0x48/0x60 evict_inodes+0x16c/0x1b0 generic_shutdown_super+0x3f/0x120 nfs_kill_super+0x1b/0x40 [nfs] deactivate_locked_super+0x3f/0x70 cleanup_mnt+0x3b/0x80 The current code still has the same unchecked cache insertion pattern, so it may be susceptible to the same failure mode. Verify that the instantiated inode is a symlink before caching the target folio. If the type is wrong, drop the suspect dentry and skip the cache insertion while preserving the successful SYMLINK result. Co-developed-by: Jackie Liu Signed-off-by: Jackie Liu Signed-off-by: ZhangGuoDong Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit c7bd0a02e5e1baad2c8c6edc06707ab88f4ae871 Author: Thomas Huth Date: Tue Aug 11 17:46:18 2026 +0200 smb: server: Free session data in user_session.c with kfree_sensitive() [ Upstream commit 9a4bd6507c21f66e84dc021705a4b9d84773111e ] struct ksmbd_session contains some arrays with sensitive information, like sess_key, smb3encryptionkey, smb3decryptionkey and smb3signingkey. Thus let's make sure that this information cannot leak via the heap and use kfree_sensitive() to free it. Signed-off-by: Thomas Huth Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 85ddd1b95018db842ea256072952814987561a10 Author: Namjae Jeon Date: Sat Aug 15 22:19:38 2026 +0900 ksmbd: notify parent directory leases on child create [ Upstream commit abe5acb34282206c2a6303d0e09b3165b1addf0e ] BVT_DirectoryLeasing_ReadWriteHandleCaching requires a parent directory lease break notification when another client creates a child in the leased directory. A child CREATE without a lease context did not notify the parent lease holders because the notification path expected a non-NULL lease context. Allow the parent lease notification helper to handle a NULL child lease context and notify matching parent leases. Invoke it after a child is created without a lease context while preserving the existing lease-key filtering for requests that provide one. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 1524c1949b4f01d5fea81e268cae7839dda1e935 Author: Benjamin Coddington Date: Thu Jun 25 08:05:49 2026 -0400 pNFS: honor clora_changed when recalling a layout [ Upstream commit aceaa5991bdf744e9c3fa1e5ad73405b1801eaab ] When the metadata server recalls a layout with clora_changed FALSE, the layout is not changing and the client may complete its modified writes to the storage devices before returning the layout (RFC 8881, Section 20.3.3). Only when clora_changed is TRUE -- the server is restriping, or a storage device has failed -- should the client stop writing to the storage devices and redirect through the metadata server. Since commit b739a5bd9d9f ("NFSv4/flexfiles: Cancel I/O if the layout is recalled or revoked") the client cancels in-flight I/O on every recall, regardless of clora_changed. For an unchanged recall this abandons writes whose data may already have reached the storage device; such a write can then land after the LAYOUTRETURN, which the server sees as a write without a layout. Pass the recall's clora_changed value through pnfs_mark_matching_lsegs_return() and only cancel in-flight I/O when the layout is actually changing. When it is not, the existing deferred return path waits for the in-flight writes to drain before sending the LAYOUTRETURN. Other callers, which are tearing down or returning the layout for their own reasons, continue to cancel as before. Signed-off-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 5b7af697ff5286e45a7f9982a6532d76a21ad3c3 Author: Thomas Huth Date: Wed Aug 12 21:36:32 2026 +0900 smb: server: Make sure that passkey is not leaked on the heap in user_config.c [ Upstream commit 2c5a176882695f73b52482df03b0017b006ef2d1 ] Use kfree_sensitive() to free the user->passkey (and the struct ksmbd_login_response in ksmbd_login_user() that contains the same information) to avoid that this information could leak somewhere else via the heap. Signed-off-by: Thomas Huth Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 77d2460f4413993123fefb961e391f598e567231 Author: Namjae Jeon Date: Fri Jul 17 12:05:00 2026 +0900 ksmbd: honor client signing-required in all modes [ Upstream commit bc2f3f3dd69424f76e2ed3dc53d29bfd6c9966d4 ] The SMB2 NEGOTIATE request's SMB2_NEGOTIATE_SIGNING_REQUIRED bit requires the server to set Connection.ShouldSign. KSMBD represents that state with conn->sign, but previously set it only when its signing configuration was auto or disabled. Set conn->sign whenever the client requires signing, independently of the server's signing mode. Keep the mandatory server-mode handling unchanged. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 1c5fd7b0940b01673666b73ac25b29f22872010b Author: Namjae Jeon Date: Wed Jul 29 21:26:26 2026 +0900 ksmbd: reject blocking compound lock requests [ Upstream commit 16a7f7c2ecf3c893b65f0fb78fa7a7171ae0ba9e ] Clients set SMB2_LOCKFLAG_FAIL_IMMEDIATELY when a LOCK request contains multiple lock elements, and servers reject requests that omit it. Accepting such a request can leave earlier elements locked while a later element waits asynchronously, enabling prolonged partial lock ownership and avoidable deadlocks. Return STATUS_INVALID_PARAMETER before processing any element when a multi-element lock request contains a blocking lock. Unlock arrays remain unaffected. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit e46e51ad4b7f293d82a011ffef3f499ea0cbe942 Author: Gael Blivet Date: Fri Jul 17 09:37:20 2026 +0200 ksmbd: fix AsyncId zeroed before use in smb2_lock() cancel response [ Upstream commit 7b461610882c8baa64d56dade57cdbfb686739fa ] release_async_work() zeroes work->async_id before the CANCELLED path calls smb2_send_interim_resp(work, STATUS_CANCELLED), which reads work->async_id to build the response's AsyncId field. The cancellation response for a cancelled blocked-lock request is sent with AsyncId=0 instead of the id the client received in the original STATUS_PENDING response for this request. Checked against every other release_async_work() call site in this file: smb2_read()/smb2_write() don't send a further async response afterward (their status goes out on the synchronous path instead), and smb2_notify()'s two async paths already transfer the id to a separate struct before releasing, so this reordering is scoped to smb2_lock() only. Send the STATUS_CANCELLED response while work->async_id is still valid, then release the async work afterward. Signed-off-by: Gael Blivet Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 40f87cc5e2a5f5d5dc5f211b948b23405c5fa4bc Author: Namjae Jeon Date: Wed Jul 29 21:24:11 2026 +0900 ksmbd: fix SMB2 byte-range lock end offset [ Upstream commit 54d90311f9b4eb23f3b0b62650b0cfddb11a12ef ] SMB2 describes a byte-range lock using an offset and a length, while Linux file_lock uses an inclusive end offset. smb2_lock() currently sets fl_end to start + length and consequently locks one extra byte for every nonzero-length request. Translate nonzero lengths to start + length - 1 and reject ranges that cannot be represented by loff_t instead of silently truncating them at OFFSET_MAX. Track zero-length locks from the request length so one-byte ranges are not mistaken for zero-length locks after endpoint conversion. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 698f2afb8134cd749ad30fc0c626ba2dd6a19a9a Author: Yashraj Ghule Date: Sun Aug 16 16:36:55 2026 +0530 ALSA: hda/realtek: Fix mute LED for HP Victus 15-fa1xxx (MB 8C3F) [ Upstream commit 19b02fecd8f857909af779afe3816e487ac10cd0 ] The HP Victus 15-fa1xxx with motherboard 8C3F is missing the existing mute LED quirk for ALC245 codecs. Add the 103c:8c3f subsystem ID to the existing ALC245_FIXUP_HP_MUTE_LED_COEFBIT quirk. Tested on HP Victus 15-fa1xxx (MB 8C3F). The mute LED works as intended. Signed-off-by: Yashraj Ghule Link: https://patch.msgid.link/20260816110655.11592-1-yashrajghule.221@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2a6ad0d06934628f10fb53513921efbb42e44745 Author: ChenXiaoSong Date: Thu Jul 23 04:11:30 2026 +0000 smb/server: cancel async requests when closing connection [ Upstream commit 4fd5bad647bfa45eb86bfd2f03ba1bef3fcd5851 ] An async request may still be waiting when a connection is closed. This can stop the connection from closing. Cancel active async requests before waiting for them to finish. Suggested-by: Namjae Jeon Signed-off-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 9388b837277f9b621e2d701c8782440619b1672a Author: Gael Blivet Date: Thu Jul 9 18:50:46 2026 +0200 ksmbd: report actual xattr value length in stream enumeration [ Upstream commit 689f1eb3719d61700b58f984ac8602837f004f8c ] get_file_stream_info() (FileStreamInformation QUERY_INFO) reported each enumerated stream's StreamSize/StreamAllocationSize as stream_name_len -- the byte length of the stream's *name*, not its data. This is the same bug class already fixed for EndOfFile/ AllocationSize on an open stream handle (ksmbd_stream_eof()), just missed at this second site: a client enumerating streams sees a size derived from the name string length instead of the stream's actual content length, inconsistent with what querying the same stream by handle reports. Compute the real value length the same way ksmbd_stream_eof() does, via ksmbd_vfs_casexattr_len() on the already-known xattr key. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Gael Blivet Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 202b29621b69ae3cb4231baa81279deb90ea6e5d Author: Gael Blivet Date: Thu Jul 9 02:01:11 2026 +0200 ksmbd: skip fallocate for SMB2_CREATE_ALLOCATION_SIZE on a stream handle [ Upstream commit bfdf81c62f4f52a3626ea62db0744def6778e83f ] smb2_open() calls vfs_fallocate(fp->filp, ...) unconditionally when a client's CREATE request includes an AllocationSize create context. For a stream handle, fp->filp refers to the base file's data fork (streams are xattr-backed on the same underlying file, not separate files), so this pre-allocates storage on the base file's actual data instead of doing anything meaningful for the stream -- fallocate has no applicability to an xattr-backed stream at all. Skip the fallocate call for stream handles. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Gael Blivet Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 9e60add09d3633ea3960f9f1eff68693da85b0b5 Author: Namjae Jeon Date: Wed Jul 8 22:21:25 2026 +0900 ksmbd: allow FSCTL_SET_SPARSE without input buffer [ Upstream commit 86c84cc760080929b7be44bceebe5854957b99da ] FSCTL_SET_SPARSE without an input buffer sets a file sparse. Treat a zero-length input buffer as SetSparse=true and keep rejecting truncated non-empty buffers. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit fc4574db96d3aeb26b5d71ed8019b801059fda56 Author: Namjae Jeon Date: Sun Jul 12 00:03:34 2026 +0900 ksmbd: honor byte-range locks for zero data [ Upstream commit 8b57448a147d2378088e63cd473e7f2a967d6802 ] FSCTL_SET_ZERO_DATA changes file allocation state and must respect byte-range locks over the affected part of the file. Check the requested range, clipped to EOF, before issuing the fallocate operation. Return STATUS_FILE_LOCK_CONFLICT when the range conflicts with an existing lock. Ranges starting past EOF are left untouched by the lock check so they continue to succeed. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 4fde4f17ca5569baa9be9d4b9279b371a6ac15b5 Author: Namjae Jeon Date: Thu Jul 9 20:08:10 2026 +0900 ksmbd: handle empty QUERY_ALLOCATED_RANGES output [ Upstream commit 7f07791522a251e2be087d11ae9cd51eb3408f1d ] FSCTL_QUERY_ALLOCATED_RANGES can be issued with a valid input buffer but without room for an output range. Do not reject the request before looking at the file layout. If the query would produce a range, return STATUS_BUFFER_TOO_SMALL. If it produces no ranges, return success with an empty output. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit ff2f880f1b5b8bfa2e2741740a75664ab98fe815 Author: Namjae Jeon Date: Tue Jul 7 00:19:39 2026 +0900 ksmbd: return buffer too small for short security queries [ Upstream commit 2103add92a02505bdd536ba6fce7f64a427222a2 ] SMB2 QUERY_INFO security requests with an output buffer too small for the self-relative security descriptor header can fall through descriptor construction and be reported as STATUS_INVALID_INFO_CLASS. After validating the file handle, reject buffers shorter than struct smb_ntsd with STATUS_BUFFER_TOO_SMALL before building the descriptor. This fixes smb2.getinfo.qsec_buffercheck. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit c1ae1cea23667acfb13e6d35b6e1511f414248ee Author: Gael Blivet Date: Tue Jul 7 11:55:01 2026 +0200 ksmbd: fix off-by-one rejecting minimal COPYCHUNK query-limits request [ Upstream commit d68d4b3293034f549d55f407a23b4c0a6c90e50a ] The FSCTL_COPYCHUNK/FSCTL_COPYCHUNK_WRITE input length check uses in_buf_len <= sizeof(struct copychunk_ioctl_req), which rejects a buffer that is exactly sizeof(struct copychunk_ioctl_req) bytes -- the minimal, valid request containing only the fixed header with ChunkCount=0 and no chunk entries, used by clients to query the server's copy limits before issuing a real copychunk. Since copychunk_ioctl_req ends in a flexible array member, the correct minimum is that the buffer covers the fixed header, so use offsetof(..., Chunks) with '<' instead of '<=' against sizeof(): same value, but the boundary case is now correctly accepted. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Gael Blivet Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 11bbbbbecfff8b7897aedaa16c0e5b136a1b1d90 Author: Namjae Jeon Date: Sat Jul 4 18:21:33 2026 +0900 ksmbd: reject SMB3.1.1 binding with mismatched cipher [ Upstream commit 7019a11f79dc408f2b47b1027240e7f198784c9a ] SMB3.1.1 multichannel connections belonging to the same session must use the same negotiated encryption cipher. ksmbd validates the dialect and client GUID during session binding, but does not compare the cipher negotiated by the new connection with the cipher used by the existing session channels. This allows a channel negotiated with AES-128-CCM to bind to a session using AES-128-GCM. Compare the new connection's cipher with an existing session channel and return STATUS_INVALID_PARAMETER when they differ. This fixes smb2.session.bind_negative_smb3encGtoCs. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit dadb138bf1fc55cd9de249253e567cb6d759b324 Author: Gael Blivet Date: Thu Jul 9 02:01:06 2026 +0200 ksmbd: fix durable handle v2 default timeout units (60 -> 60000) [ Upstream commit c1d7bbfc5e081875053723d1a69eb2cf341eaaf1 ] When a client's Durable Handle Request V2 sets Timeout=0 ("let the server choose"), fp->durable_timeout was set to 60. Every other use of this field is in milliseconds: DURABLE_HANDLE_MAX_TIMEOUT (300000) in smb2pdu.h, the nonzero branch immediately above (min_t(unsigned int, dh_info.timeout, DURABLE_HANDLE_MAX_TIMEOUT), where dh_info.timeout is the wire value and already milliseconds per spec), and the scavenger in vfs_cache.c, which adds it directly to jiffies_to_msecs(jiffies). 60 is off by 1000x: the handle becomes scavenger-eligible 60 milliseconds after close instead of 60 seconds. A client requesting Timeout=0 is relying entirely on the server's default to cover the gap between a dropped connection and its reconnect -- 60ms is not enough time for even a fast network blip to be detected and reconnected, so any real disruption loses the race and a subsequent DH2C reconnect fails with a durable-handle lookup miss instead of succeeding. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Gael Blivet Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 3857c032e8f6f9b6e9dce24f3479f5cdd12a75d6 Author: Namjae Jeon Date: Sun Jul 5 16:01:27 2026 +0900 ksmbd: allow I/O on directory named streams [ Upstream commit 8184c425a19d44f138d42b44cc363917c08e5f1c ] Named streams are stored as extended attributes on the base inode. The VFS read and write helpers reject directory inodes before or together with checking whether the handle represents a stream. Permit read and write operations when a directory-backed handle is a named stream. Continue rejecting direct I/O on ordinary directory handles. This fixes creation of the directory stream in smb2.getinfo.complex. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 2db5dd32df1276b6c23b42fe30fb5e1769042439 Author: Namjae Jeon Date: Tue Jul 7 00:49:37 2026 +0900 ksmbd: preserve access denied status for copychunk [ Upstream commit f7c0366e0a80bf8cd5eacc5479927abb50958b5e ] The copychunk error mapping handles -EACCES in an independent if statement. The following error chain therefore reaches its final else clause and overwrites STATUS_ACCESS_DENIED with STATUS_UNEXPECTED_IO_ERROR. Join the -EACCES check to the remaining error chain so an access failure is returned as STATUS_ACCESS_DENIED. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 01bedc2de5059232e71127c3911efd9ae088398d Author: Namjae Jeon Date: Sun Jul 5 15:55:14 2026 +0900 ksmbd: protect private extended attributes [ Upstream commit 4ea46ea602fc7055eee4b5b0e84f90f22da7f7e7 ] SMB clients can currently create an EA named NTACL because SMB EAs are mapped into the user namespace while the ksmbd security descriptor is stored as security.NTACL. Allowing the reserved logical name makes the server-private ACL metadata appear writable through the SMB EA API. Reject NTACL, DOSATTRIB, and DosStream-prefixed EA names without regard to case. Filter the same private names from EA query results so stale or externally-created user namespace attributes cannot be exposed. This fixes smb2.ea.acl_xattr when acl_xattr_name is configured as NTACL. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit cfe96744fbaa5efeb4f11b72c4917d02eef0b218 Author: David C.C.M. Gall Date: Fri Aug 7 18:22:00 2026 +0200 crypto: keembay - use crypto_memneq() to compare CCM AEAD tags [ Upstream commit ff2ac77a034e03b64e2ba34f775097427dfa5547 ] Use crypto_memneq() for constant-time comparison. The CCM path in ocs-aes.c verifes the received authentication tag with memcmp(), which returns early on the first mismatched byte. This leaks valid-prefix length and allows for valid tag forgery which violates the INT-CTXT guarantee of AEAD. Assisted-by: gregkh_clanker_t1000 Signed-off-by: David C.C.M. Gall Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3bdb78ce50e7508c775f031c353b0f4803689cd3 Author: Israel Téllez García Date: Fri Aug 14 14:48:43 2026 +0200 libbpf: Fix ring buffer consumer loop on 32-bit position wrap [ Upstream commit fdd4fad0bbbd08501465c5f9b556963093c5d58a ] ringbuf_process_ring() walks the records between the consumer and the producer with an ordering comparison: while (cons_pos < prod_pos) { cons_pos and prod_pos mirror the kernel's ring positions and are unsigned long here too, so on 32-bit they wrap at 2^32 bytes of traffic. When producer_pos has wrapped and consumer_pos has not, prod_pos is the smaller of the two, the loop body never runs and no record is consumed. Since consumer_pos only advances inside that loop, it never wraps either and the consumer stops delivering samples for good, with no error returned to the caller: ring_buffer__poll() keeps reporting zero records while the kernel side fills up and starts dropping. Compare the distance instead. The consumer never runs ahead of the producer, so prod_pos - cons_pos is the amount of unconsumed data and stays correct across the wrap. 64-bit hosts are unaffected in practice: the counters would need 16 EiB to wrap. This is the userspace counterpart of the kernel-side walk fixed in "bpf: Fix pending_pos walk on 32-bit ring position wrap"; a 32-bit consumer hits whichever of the two comes first. Signed-off-by: Israel Téllez García Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260814124843.22041-5-i.tellez@btesa.com Signed-off-by: Sasha Levin commit 1f6c2905cec18ca24a0827ae1ccdb5926138f2d4 Author: David C.C.M. Gall Date: Fri Aug 7 17:44:16 2026 +0200 crypto: sa2ul - use crypto_memneq() to compare AEAD tag [ Upstream commit 7064af16d2b418d61571dba9bb0116a547ade124 ] Use crypto_memneq() for a constant-time comparison. sa_aead_dma_in_callback() compares the computed authentication tag against the received tag with memcmp(), which short-circuits on the first differing byte. An attacker who can submit decrypt requests and observe completion latency could recover the expected tag byte by byte. Valid tag forgery for AEAD breaks the INT-CTXT guarantee. Assisted-by: gregkh_clanker_t1000 Signed-off-by: David C.C.M. Gall Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2fb994b41eaa405a3d7c3ad668325f96904db64c Author: David C.C.M. Gall Date: Fri Aug 7 18:13:52 2026 +0200 crypto: keembay - use crypto_memneq() to compare GCM AEAD tags [ Upstream commit 353b3a85136f2a0cf3e872acf8ad6c1dec0b7a8e ] Use crypto_memneq() for constant-time comparison. The GCM path in keembay-ocs-aes-core.c verifes the received authentication tag with memcmp(), which returns early on the first mismatched byte. This leaks valid-prefix length and allows for valid tag forgery which violates the INT-CTXT guarantee of AEAD. Assisted-by: gregkh_clanker_t1000 Signed-off-by: David C.C.M. Gall Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c3557319f5349392893d329714874090dec9e896 Author: Eric Dumazet Date: Wed Aug 12 14:22:57 2026 +0000 gre: fix ERSPAN o_flags race/corruption in xmit and fill_info [ Upstream commit 9958e69b98930834a576e156f6458166d1db1c02 ] For IPv4 ERSPAN: In erspan_xmit(), the driver clears IP_TUNNEL_SEQ_BIT (for version 0) and IP_TUNNEL_KEY_BIT directly in the shared tunnel->parms.o_flags structure. Since transmit paths can run locklessly and concurrently, this leads to a data race. Furthermore, modifying tunnel->parms.o_flags permanently alters the tunnel configuration. To work around this, erspan_fill_info() (which reports config to userspace) was setting IP_TUNNEL_KEY_BIT back. If erspan_fill_info (running under RTNL) and erspan_xmit (running locklessly) race, erspan_xmit might see IP_TUNNEL_KEY_BIT set when it shouldn't, leading to GRE header corruption (injecting a key field into the ERSPAN GRE header). Fix this by: 1) Passing flags as an argument to __gre_xmit(). 2) Using local stack flags in ipgre_xmit(), gre_tap_xmit(), and erspan_xmit() to prevent TOCTOU data races with concurrent configuration updates, and passing them to __gre_xmit(). 3) Removing the racy modification of t->parms.o_flags in erspan_fill_info(). 4) Forcing IP_TUNNEL_KEY_BIT in the reported flags for ERSPAN locally in ipgre_fill_info(). For IPv6 ERSPAN: ip6erspan_tunnel_xmit() was locklessly clearing IP_TUNNEL_KEY_BIT in t->parms.o_flags even though it does not use these flags for building the GRE header (it uses local flags). This permanently corrupts the configuration and races with ip6gre_fill_info() which reads it. Remove the redundant and racy modification. This should remove false sharing in a fast path. Add const qualifiers in ipgre_fill_info(), erspan_fill_info() and ip6gre_fill_info() to clarify that these methods are not supposed to write any live parameters. Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260812142257.21283-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9784b55cb787ebff6d836f67dd0b5ba5a003e482 Author: Yang Wen Date: Thu Aug 13 22:29:19 2026 +0800 exfat: keep FITRIM within the requested range [ Upstream commit 2de727471b3b13409466a4af4f8824a86073bf4b ] exfat_find_free_bitmap() searches the entire allocation bitmap and may wrap around to its beginning. exfat_trim_fs() does not verify that the returned cluster is still within the requested FITRIM range. As a result, a partial FITRIM operation may discard free clusters outside the user-specified range and report a trimmed length larger than the requested length. Validate each returned cluster against the requested range and stop the search when it wraps around or passes the range end. Signed-off-by: Yang Wen Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit fad7635285c8d2a04b88d25e5ace549a7a4ac97c Author: Anuj Bolewar Date: Sun Aug 2 22:05:17 2026 +0530 drm/virtio: reclaim pending vbufs before tearing down vqs [ Upstream commit 61d85f99b5a55d4f717c4bb2f4c4acabf22ee3fc ] virtio_gpu_free_vbufs() destroys the vbufs kmem_cache after the virtqueues have already been released. Commands that were queued but never completed by the device leave their vbuffers stranded in the virtqueue, so the cache still holds live objects when virtio_gpu_deinit() tears everything down. This triggers a WARNING in virtio_gpu_free_vbufs: BUG virtio-gpu-vbufs (Not tainted): Objects remaining in cache on __kmem_cache_shutdown() Drain any buffers still sitting in the control and cursor virtqueues in virtio_gpu_deinit() after the device has been reset and before the virtqueues are deleted, following the same pattern used by virtio_console's remove_vqs(). Each reclaimed buffer is released with free_vbuf(), dropping the reference on any GEM objects it holds. Pending RESOURCE_UNREF commands are handled as well: their resp_cb_data still references a GEM object, so it is cleaned up with virtio_gpu_cleanup_object() to avoid leaking it on teardown. Reported-by: syzbot+06f9b2a53ba4a5a47644@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=06f9b2a53ba4a5a47644 Signed-off-by: Anuj Bolewar Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260802-virtio-gpu-reclaim-vbufs-v2-1-5767fb860691@gmail.com Signed-off-by: Sasha Levin commit 629cbc3b4d4e0189c661d1c518b16a469d38af45 Author: Basavaraj Natikar Date: Mon Aug 3 23:22:27 2026 +0530 HID: amd_sfh: Serialize access to the shared emp2 pointer [ Upstream commit c57016bcf6d0b57cda5579e5d6856bd9bbe52a77 ] The SFH accessors reach the device through a file-global emp2 pointer that is published at probe and cleared on remove. amd_get_sfh_info() is exported and called from other modules on unrelated threads, so a reader can observe a non-NULL emp2 and then race a concurrent unbind that clears it and frees the device. Serialize the emp2 publish/clear and all readers under a mutex, so a reader either sees a live device for the whole access or sees NULL. Signed-off-by: Basavaraj Natikar Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit db72ba3b4551fcff2e96f18505a9343a7579cda3 Author: Neil Andrews Date: Thu Aug 13 20:41:24 2026 +0000 ALSA: usb-audio: Rename the Audient iD14 monitor mix volume control [ Upstream commit 9c0564fcc21aec4f5b7648f61865ce3fc2b84a7f ] On the Audient iD14 (2708:0008), feature unit 12 is traced through to the Speaker output terminal and is therefore exported as "Speaker Playback Volume". The name fits it badly. It advertises Volume on only four of its six logical channels, which the driver records as cmask=0xf, channels=4 on a 6-channel playback stream, and it sits on the monitor mixer branch rather than in the direct playback path: INPUT_TERMINAL 2 (USB streaming, 6ch) -> EXTENSION_UNIT 51 -> FEATURE_UNIT 10 (no controls) -> OUTPUT_TERMINAL 20 (Speaker) while FU 12 hangs off MIXER_UNIT 60 and feeds back into EXTENSION_UNIT 51. Userspace adopts the control as the stream's hardware playback volume, so any setting below 0 dB attenuates part of the stream and not the rest. Measured over the device's own digital loopback, with one -12 dBFS tone per channel played straight to hw:, PCM channel 0 is unaffected while channel 1 tracks the control: at 107/127 (-20 dB) the two read -15.89 and -35.89 dBFS, a 20.00 dB imbalance, and at 127/127 both read -15.89 dBFS. Give the unit a non-standard name so that it is no longer taken for the stream's master volume. Dropping the control instead also fixes the imbalance, but FU 12 keeps its value across a module reload, so dropping it strands a device that is already attenuated with nothing able to reset it. Renaming leaves the monitor gain reachable and that recovery path intact. The mapped name ends in "Playback" because a name from the map suppresses the automatic " Playback" but still gets " Volume" appended; the control comes out as "Monitor Mix Playback Volume". Tested on the ACP path with PipeWire, which is where the problem reproduces: the control now stays at 127 at every volume setting and the imbalance is 0.00 dB, and setting it by hand to 107 and back to 127 gives 20.00 dB and 0.00 dB as before. Link: https://lore.kernel.org/linux-sound/0102019fed22f9d3-fa294ec5-02f1-4fd3-b3fa-76efc14331cc-000000@eu-west-1.amazonses.com/T/#u Signed-off-by: Neil Andrews Link: https://patch.msgid.link/0102019ffcdbb1e6-9b59d3cc-ef05-4df1-8f9f-fb2f425bcda2-000000@eu-west-1.amazonses.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bce6b0499bc2edffbed1cc5169cddabca318ff3c Author: Takashi Iwai Date: Thu Aug 13 17:03:49 2026 +0200 ALSA: hda/intel: Add sanity check for BAR0 size [ Upstream commit 9895573b0185f922be4cf500a0f2e5b9560ab1c3 ] The recent reports from syzkaller showed that we can bind any wild PCI device to HD-audio controller, and if PCI BAR of the device is too small, it may lead to a crash, as the driver believes as if the full register range were accessible. For avoiding such a problem, add a safeguard before the actual probe to check the available BAR0 size. Note that the threshold (0x200) is chosen to cover all needed registers at probing. But this doesn't mean that it would cover fully for all features including the extended ones. Reported-by: syzbot+10cd2d1efe8eeb604bee@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=10cd2d1efe8eeb604bee Reported-by: syzbot+5ebe7cd17e48b4293660@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5ebe7cd17e48b4293660 Link: https://patch.msgid.link/20260813150354.763502-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 19b7dcd385e9393781a4620a4fcc78ffcecc2803 Author: Farhan Ali Date: Wed Aug 5 09:55:16 2026 -0700 PCI: Avoid saving config space state if inaccessible [ Upstream commit e18d1abc3bff0a24a5299f3c150ab9546e9439aa ] The current reset process saves the device's config space state before reset and restores it afterward. However errors may occur unexpectedly and it may then be impossible to save config space because the device may be inaccessible (e.g. DPC). This results in saving invalid values that get written back to the device during state restoration. With a reset we want to recover/restore the device into a functional state. So avoid saving the state of the config space when the device config space is inaccessible. Signed-off-by: Farhan Ali [bhelgaas: comment] Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Schnelle Reviewed-by: Bjorn Helgaas Link: https://patch.msgid.link/20260805165518.794-4-alifm@linux.ibm.com Signed-off-by: Sasha Levin commit 0fbb4c928f294bac921d27d9f4775c94939f72ca Author: Michail Tatas Date: Fri Aug 7 01:30:20 2026 +0300 ipmi: Fix leak in __ipmi_bmc_register [ Upstream commit 18e633dd9674c8bf118ea8583bb5a531edc2728a ] In case that ida_alloc(&ipmi_bmc_ida,...) succeeds and then platform_device_register() fails, ipmi_bmc_ida is leaked. Fix by freeing the error path Signed-off-by: Michail Tatas Message-ID: Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit e19c7549f20e3695fe3dc3956a61cf7d076e0014 Author: Charles Keepax Date: Fri Aug 7 13:14:25 2026 +0100 soundwire: dmi-quirks: Disable ghost Realtek on Asus ROG Zephyrus Duo [ Upstream commit 5b08a3afd2995e5312c4c47ffea9d21b651e8e13 ] The Asus ROG Zephyrus Duo also has a Realtek device in the ACPI that doesn't exist in the physical hardware. This confuses the machine driver into attempting to create DAI links for the device. Add a quirk to remove this device. Suggested-by: Bard Liao Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260807121425.1952003-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f0e7f07eed947be20a1041343bf265c97a3f3144 Author: Arash Golgol Date: Wed Aug 12 16:20:54 2026 +0330 regulator: fan53555: Add support for FAN53555BUC23X type [ Upstream commit e739acbe05b06de78ef7089470f122432f651faa ] FAN53555BUC23X has the ID 0 and REV 0xc, starts at 600mV and increments in 12.5mV steps. Per the datasheet, the FAN53555BUC23X (23 option) is grouped with the 00 and 13 options for soft-start timing (t_SS = 300us typ.), so the existing enable_time = 400 is reused here as well. This variant is found on the ASUS Tinker Edge R (RK3399Pro) as the supply regulator for both vdd_gpu and vdd_cpu_b. Verified across the full GPU OPP table with the userspace devfreq governor. Signed-off-by: Arash Golgol Link: https://patch.msgid.link/20260812125054.19111-1-arash.golgol@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit af09bbb010f0d5256de3be4a7089c7dd1cec3c54 Author: Jiaming Zhang Date: Mon Aug 10 17:24:21 2026 +0800 hfsplus: validate extent record length before writing it back [ Upstream commit 627b7865c062ff642c0000f3a4775f1a44b986a4 ] __hfsplus_ext_write_extent() writes the cached extent record back into a B-tree node using fd->entrylength as the length, and fd->entrylength is derived in __hfs_brec_find() from two on-disk values: fd->entrylength = len - keylen; A crafted image can keep both len and keylen valid but make fd->entrylength negative (keylen > len). __hfsplus_ext_write_extent() doesn't check fd->entrylength before consuming it, and hfs_bnode_write() takes the length as u32, so the negative value turns into a huge one. The copy then reads data past the end of hip->cached_extents, which is only sizeof(hfsplus_extent_rec) bytes long, and leaks kernel memory into the image. Reject an fd->entrylength that does not match sizeof(hfsplus_extent_rec) in __hfsplus_ext_write_extent(), mirroring the check already performed in __hfsplus_ext_read_extent(). Link: https://lore.kernel.org/lkml/cbd7003314c530d4f910eacf019ff80adad6687e.camel@dubeyko.com/ Signed-off-by: Jiaming Zhang Reviewed-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260810092422.1691377-1-r772577952@gmail.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 99d5c11ac242dd1ef0757d89dd6aa9f6847aa06b Author: Dmytro Moroziuk Date: Wed Aug 12 15:18:56 2026 +0300 ALSA: hda/conexant: Add mute LED quirk for HP ProBook 440 G5 [ Upstream commit 191fe151eb85ff6cb24189fc88c970745497c057 ] The HP ProBook 440 G5 requires the CXT_FIXUP_MUTE_LED_GPIO quirk to properly toggle the physical mute and mic-mute LEDs via the CX8200 codec. Without this quirk, the LEDs remain permanently dark. Signed-off-by: Dmytro Moroziuk Link: https://patch.msgid.link/20260812121856.30353-1-dmorozyk1@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d719d1e909935ebee1170eb01818a05c90e1902d Author: Matt Turner Date: Mon Aug 10 16:28:34 2026 -0400 alpha: run the remote RTC access in a worker, not an IPI callback [ Upstream commit 6f45effbd74012f1715584ba51abaa3196a47c08 ] On Marvel the CMOS clock is only reachable from the boot cpu, so remote_read_time() and remote_set_time() bounce the access there with smp_call_function_single(), whose callback runs in hard interrupt context. alpha_rtc_read_time() calls mc146818_get_time() with a 10 ms timeout. That waits out the RTC update cycle in mc146818_avoid_UIP(), which drops rtc_lock and udelay()s 100 us at a time until the update completes or the timeout expires: for (i = 0; UIP_RECHECK_LOOPS_MS(i) < timeout; i++) { spin_lock_irqsave(&rtc_lock, flags); ... if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) { spin_unlock_irqrestore(&rtc_lock, flags); udelay(UIP_RECHECK_DELAY); continue; } So a clock read from a non-boot cpu can spin for up to 10 ms in hard interrupt context on the boot cpu, while the cpu that sent the request spins in smp_call_function_single() waiting for it to finish. mc146818_set_time() does not poll, but it takes rtc_lock too, and rtc_lock is a spinlock_t. Only raw spinlocks may be taken in hard interrupt context, so lockdep reports the write path as soon as a non-boot cpu sets the clock: [ BUG: Invalid wait context ] ----------------------------- swapper/0/0 is trying to lock: fffffc0003690470 (rtc_lock){....}-{3:3}, at: mc146818_set_time+0x74/0x450 other info that might help us debug this: context-{2:2} no locks held by swapper/0/0. stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc1 #1 NONE Trace: [] dump_stack+0x28/0x44 [] __lock_acquire+0xb0c/0x1060 [] lock_acquire.part.0+0xd0/0x300 [...] [] mc146818_set_time+0x74/0x450 [] _raw_spin_lock_irqsave+0x7c/0xc0 [] do_remote_set+0x90/0xc0 [] __flush_smp_call_function_queue+0x314/0x5c0 [] generic_smp_call_function_single_interrupt+0x24/0x40 [] handle_ipi+0xa4/0x230 [] do_entInt+0x1a4/0x2e0 The rtc class ops are always called from process context, so there is no reason to run the access from an interrupt at all. Use work_on_cpu() to run it in a worker on the boot cpu. Alpha does not support cpu hotplug, so the boot cpu cannot go offline while the work is pending. Tested on an AlphaServer ES47 (Marvel/EV7): hwclock read and write pinned to a non-boot cpu, twenty times, with no splat. Signed-off-by: Matt Turner Reviewed-by: Magnus Lindholm Link: https://lore.kernel.org/r/20260810202835.3592833-1-mattst88@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit a8273634398bc75191f76dfebd3f47ae01b4a2ef Author: Chao Shi Date: Mon Aug 10 18:02:58 2026 -0400 nvme: ratelimit the completion-path messages driven by device data [ Upstream commit c05c86681170e381e24498257db3a879deb1ae89 ] nvme_find_rq() and nvme_handle_cqe() print an unratelimited message for every completion queue entry whose command id does not resolve to an in-flight request. Both are reached from the completion interrupt path (nvme_irq() -> nvme_poll_cq() -> nvme_handle_cqe()) and the decision to print is made entirely from device-supplied data, so a controller that posts a stream of bogus command ids drives unbounded printk from hard interrupt context. This is not hypothetical. A single boot under an emulated controller that posts invalid completions produced 846 "could not locate request for tag 0x0", 846 "invalid id 0 completed on queue 2" and 123 "genctr mismatch" lines. Once the tag set has been torn down every subsequent completion resolves to nothing, so the print rate is bounded only by how fast the device can post entries. Ratelimit the three messages. The information they carry is diagnostic and repeats, so the suppression count printed by the ratelimit helpers is enough to tell that the condition persists. This matches how the other device-driven error prints in the driver are already handled, for example the status messages in nvme_log_error() and nvme_log_err_passthru(). nvme_find_rq() lives in nvme.h and is shared by pci, tcp, rdma, apple and target-loop, so all transports are covered. Found by FuzzNvme. Signed-off-by: Chao Shi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 9b960d3c92e8754fbff31f01ada6509582da5068 Author: Griffin Kroah-Hartman Date: Tue Jul 7 16:23:27 2026 +0200 nfc: nxp-nci: Add remove on IRQ error [ Upstream commit 56345cea6a30dc7a1b036d5fb7900434b4a4c5e8 ] Add a call to nxp_nci_remove() in nxp_nci_i2c_probe() when the request_threaded_irq() fails. Previously, IRQ resources were not being freed upon error. Assisted-by: gkh_clanker_2000 Cc: David Heidelberg Cc: Carl Lee Cc: Jakub Kicinski Cc: Krzysztof Kozlowski Cc: Ian Ray Cc: "Uwe Kleine-König (The Capable Hub)" Signed-off-by: Griffin Kroah-Hartman Signed-off-by: Greg Kroah-Hartman Reviewed-by: Ian Ray Link: https://patch.msgid.link/2026070726-observer-fang-9716@gregkh Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 55e73266afd96451e4bf12e4b42d3ff2a8256c95 Author: Griffin Kroah-Hartman Date: Tue Jul 7 16:22:17 2026 +0200 nfc: mrvl: spi: Unregister dev on allocation fail [ Upstream commit d832b95697384a2b67f20b35106bbf925358cde9 ] Call nfcmrvl_nci_unregister_dev() if nci_spi_allocate_spi() fails, unwrapping the previous call to nfcmrvl_nci_register_dev() during the nfcmrvl_spi_probe() function. Assisted-by: gkh-clanker-2000 Cc: David Heidelberg Signed-off-by: Griffin Kroah-Hartman Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026070716-crucial-slouchy-b8a9@gregkh Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit fe4d3fb702e6cd0d9cd619380c0c32f9241cf8be Author: Vasant Hegde Date: Tue Aug 11 04:08:58 2026 +0000 iommu/amd: Fix missing CMD_COMPLETE_PPR response for invalid PPR requests [ Upstream commit bc1f5ec826bfa510e7138e2be5aad23907850874 ] The AMD IOMMU spec, requires the host to respond with a CMD_COMPLETE_PPR command when an EVENT_TYPE_INV_PPR_REQ event is received with the RX bit cleared. This response was missing in the current implementation, leaving invalid PPR requests unacknowledged. Introduce amd_iommu_report_ppr_err() to handle EVENT_TYPE_INV_PPR_REQ events. The new function logs the invalid PPR request and when the RX bit is cleared, sends CMD_COMPLETE_PPR response. Reported-by: Gaultier Delbarre Co-developed-by: Wei Huang Signed-off-by: Wei Huang Signed-off-by: Vasant Hegde Reviewed-by: Ankit Soni Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 14b39ed41b930d65901ec4fd4e4f1e7e72317c37 Author: Feng Tang Date: Fri Aug 7 08:24:36 2026 +0800 selftests: net: reuseport_bpf_numa: consider cpuless numa node [ Upstream commit 88b8d85e889e2fe1cce3e66e50c3029dda94842a ] reuseport_bpf_numa case failed when testing on a platform with CXL memory: #./reuseport_bpf_numa ---- IPv4 UDP ---- send node 0, receive socket 0 ./reuseport_bpf_numa: failed to pin to node: Invalid argument The root cause is that the platform has 2 numa nodes: node 0 has both cpu and memory, while node 1 is a CXL node which only has memory, and caused numa_run_on_node() to fail. Add sanity check to skip cpuless numa node for the numa binding test. Signed-off-by: Feng Tang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260807002436.43991-1-feng.tang@linux.alibaba.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f1fe12069b9a6ddd2084d9857b302627f3d0295a Author: John Johansen Date: Tue Jul 28 13:14:49 2026 -0700 apparmor: fix auditing of mount binary data [ Upstream commit b9f2181b90ec047488dcb4fb1c631d417aff07e0 ] AppArmor only mediates non-binary mount data, and should only audit the mount data if it is non-binary. Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit a0fcb604bb2bde33b84f4c40fd542e63df66b843 Author: Rongguang Wei Date: Fri Aug 7 15:09:14 2026 +0800 tap: fix incorrect variable used for USO check in set_offload() [ Upstream commit fac7973f004de6dd51fb15a33e33ed37718e58bb ] The USO features in set_offload() incorrectly uses feature_mask and features argument. The USO feature was written to the local features variable instead of feature_mask. All other offload bits (TSO, TSO_ECN) are stored in feature_mask which becomes tap->tap_features and is used by tap_handle_frame() for GSO segmentation. Without NETIF_F_GSO_UDP_L4 in tap->tap_features, making USO on tap effectively non-functional. Keeping the USO handling inside the TUN_F_CSUM block avoids enabling GRO/LRO when userspace requests USO without CSUM. This has not worked since the beginning, so commit 399e0827642f ("driver/net/tun: Added features for USO.") Signed-off-by: Rongguang Wei Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260807070914.112698-1-clementwei90@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1be48ae752e7e6816ceb7eec77480475ac7631ef Author: Geliang Tang Date: Sun Jul 26 10:46:49 2026 +0800 nvme-tcp: look up host_iface in the current netns [ Upstream commit 58202950e39c127d593ec4f0624d8b8985a285b1 ] nvme_tcp_alloc_ctrl() looks opts->host_iface up in &init_net, the boot-time netns. When called from any other netns - e.g. the selftest's ns2, where ns2eth1 actually lives - the lookup misses and the controller setup fails with "invalid interface passed": nvmet: adding nsid 1 to subsystem nqn.2014-08.org.nvmexpress.mptcpdev nvmet_tcp: enabling port 24660 (0.0.0.0:24099) # nvme discover -a 10.1.1.1 --tos=0x10 --host-iface=ns2eth1 nvme_tcp: invalid interface passed: ns2eth1 # failed to add controller, error invalid interface Look the device up in current->nsproxy->net_ns instead so the check sees the calling task's netns. Reviewed-by: Hannes Reinecke Signed-off-by: Geliang Tang Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 3e3143c481ae9942dd32eab770f67ffbec11f5eb Author: Zhe Liu Date: Mon Aug 10 14:35:35 2026 +0800 docs: cgroup-v2: fix stale "io" controller introduction [ Upstream commit 3345c7248a9e2a91cb9e2477c29af16881706f4f ] The introductory paragraph for the IO controller still states that weight based distribution is "available only if cfq-iosched is in use" and that "neither scheme is available for blk-mq devices". This text dates from when the cgroup v2 documentation was first written (2015) and was correct at the time, but is no longer accurate: * cfq-iosched was removed in v5.0; * blk-mq is now the only block I/O path, and both the absolute limit scheme (io.max via blk-throttle) and the weight based scheme (io.weight via iocost, or io.bfq.weight under BFQ) work on it; * latency based protection (iolatency) and I/O priority (ioprio) controllers have since been added. The rest of the section already documents io.weight, io.max, io.cost.{qos,model}, io.latency and io.prio.class correctly, so the introduction is the only part that contradicts them. Rewrite it to reflect the current state. Signed-off-by: Zhe Liu Reviewed-by: Tao Cui Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 0bd197c92edc280a60488632c765e78913cac57c Author: Brian Grech Date: Thu Aug 6 10:16:45 2026 -0500 selftests/net: fin_ack_lat: fix latency threshold typo [ Upstream commit 2373107782a98ba15931a37bbd9dd46d7213e5aa ] The commit message for af8c8a450bf4 ("selftests: net: Add FIN_ACK processing order related latency spike test") states: "if the latency is larger than 1 second (spike), print a message". However the code uses a threshold of 100000 us (100 ms), not 1000000 us (1 s). The lower threshold causes false positives on slower hardware where normal connection latency occasionally exceeds 100 ms but never approaches the 1 s spike that indicates the actual FIN/ACK race bug. Fix the threshold to match the documented intent. Reviewed-by: Simon Horman Signed-off-by: Brian Grech Link: https://patch.msgid.link/20260806151645.4172900-1-bgrech@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 731ade148b8be5a1c960e44d295df86c290b2a7c Author: Hari Mishal Date: Fri Jul 17 16:43:53 2026 +0200 nvmet: passthru: fix OOB reads when parsing ns id descriptor list [ Upstream commit bc7f75eba50012ed447654d8ce169ebaba695193 ] nvmet_passthru_override_id_descs() walks a namespace identification descriptor list populated from the underlying passthru controller's Identify response, which is device reported. The loop advanced pos by device controlled amounts (sizeof(*cur) + nidl) without checking that the next descriptor header actually fits inside the buffer, so a malicious device could push pos to within a few bytes of the buffer end and cause cur->nidl, cur->nidt or the reserved field to be read past the allocation. Additionally, when a CSI descriptor lands exactly at the last valid header offset, cur + 1 points one byte past the end of the buffer. The unconditional memcpy(&csi, cur + 1, NVME_NIDT_CSI_LEN) could read that out-of-bounds byte and copy it back to the initiator via nvmet_copy_to_sgl(), leaking adjacent heap memory. Bounds check both the descriptor header and the CSI value before dereferencing them. Signed-off-by: Hari Mishal Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit b7d905971a9657b32b99714aa3845d1da154b334 Author: Dapeng Mi Date: Fri Jul 17 16:03:36 2026 +0800 perf/x86: Free hybrid state on PMU init failure [ Upstream commit 96746e731e1626545e343974ca4673739dceb31b ] If PMU initialization fails, for example in check_hw_exists(), hybrid state can be left partially initialized: x86_pmu.hybrid_pmu is not freed and perf_is_hybrid remains set. This can leak memory and leave stale hybrid state reachable after a failed init path. Add x86_pmu_free_hybrid() and use it on PMU init failure paths so all hybrid-related state is consistently reset. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Thomas Falcon Reviewed-by: Zide Chen Link: https://patch.msgid.link/20260717080342.1879573-3-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit 552a0ed80c7efcb4af5a9bef744d8d114f54f937 Author: Dapeng Mi Date: Fri Jul 17 16:03:35 2026 +0800 perf/x86: Unregister PMI handler on PMU init failure [ Upstream commit 91787047b1dc52b1fee68b07f79af70aae5fce47 ] Fix an NMI handler leak in init_hw_perf_events(). When PMU initialization fails after register_nmi_handler(), the error path exits without calling unregister_nmi_handler(), leaving a stale NMI_LOCAL "PMI" handler registered. Add the missing call before clearing x86_pmu state. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Thomas Falcon Reviewed-by: Zide Chen Link: https://patch.msgid.link/20260717080342.1879573-2-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit 246c0ed3b5adfd5501df596ac4b0c6119f715b13 Author: Michal Pecio Date: Mon Aug 10 07:57:28 2026 +0200 ALSA: usx2y: Stop clearing urb->hcpriv before submission [ Upstream commit fabae5548149ef5c8a056875d9ebdc38366db539 ] This is managed by USB core and drivers aren't expected to touch it. It should only be not NULL on a submitted URB, in which case clearing defeats the "submitted while active" sanity check in usb_submit_urb() and may crash the HCD handling the URB and panic the kernel. Signed-off-by: Michal Pecio Link: https://patch.msgid.link/20260810075728.483c827e.michal.pecio@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 61dce150302e43822ab4a9014f9fa62dfc63dc9c Author: Guanghui Feng Date: Wed Aug 5 07:42:57 2026 +0800 iommu/vt-d: Fix CACHE_TAG_NESTING_DEVTLB polluting shared variables in flush loop [ Upstream commit 3846e469c1ba1407260066070bff5c88ee39a4c7 ] In cache_tag_flush_range(), the CACHE_TAG_NESTING_DEVTLB case modifies the shared local variables 'addr' and 'mask' before falling through to CACHE_TAG_DEVTLB. This causes all subsequent CACHE_TAG_DEVTLB entries in the same loop iteration to incorrectly use the full-range flush parameters (addr=0, mask=MAX_AGAW_PFN_WIDTH) instead of the precisely calculated PSI range. This is not the intended behavior, as regular DEVTLB entries should always perform targeted range-based invalidation. Fix this by having CACHE_TAG_NESTING_DEVTLB directly call cache_tag_flush_devtlb_psi() with the full-range constants and break, instead of modifying shared variables and falling through. This ensures CACHE_TAG_DEVTLB always uses the original calculated addr and mask for precise range flush. This change slightly affects trace_cache_tag_flush_range() behavior. Previously, after addr/mask were overwritten, the tracepoint could record a full-range flush even when the caller requested a narrower range. The tracepoint should reflect caller intent. Although this helper may widen the actual hardware invalidation range for implementation reasons, that does not change what the caller requested, so logging the requested range is the correct behavior. If the actual invalidation range sent to hardware is needed, it is already visible via the qi_submit trace event, which records the invalidation descriptors emitted by the driver. Signed-off-by: Guanghui Feng Signed-off-by: Guixin Liu Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 17dda622884fcdec185083aad8264cf1bd32d68e Author: Pengpeng Hou Date: Mon Jul 6 17:30:38 2026 +0800 fbdev: udlfb: validate vendor descriptor items [ Upstream commit 3cc2fad376ac7360b4518277aa923752624db59c ] dlfb_parse_vendor_descriptor() walks key-length-value items inside the DisplayLink vendor descriptor. Require each item to contain its key, length and declared value bytes before reading item-specific fields such as max_area. Signed-off-by: Pengpeng Hou Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 1b54341a2c8005c772f5928797c72047bbb2a5c6 Author: Andreas Kemnade Date: Thu Jul 2 17:50:35 2026 +0200 fbdev: omap2: dsi: do not copy isr table [ Upstream commit 31875c51c31edec57b3620f278680c23a823763b ] To te able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table. Suggested-by: sashiko-bot@kernel.org Signed-off-by: Andreas Kemnade Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 492b7dcb7f3db6684d3d57268f8dba6b0dfdf336 Author: Atish Patra Date: Fri Aug 7 19:24:30 2026 -0600 RISC-V: perf: fix resource cleanup on driver probe failure [ Upstream commit e24a1418e90beac2ef4384bc9b0b5a10f19b806e ] Sashiko pointed out various UAF and memory leak issues around pmu_sbi_device_probe() error paths. If the probe fails, here are list of cleanups needed. a. Already registered pmu must be freed b. per cpu IRQ must be released c. pmu_ctr_list data structure must be freed d. cpu hotplug state must be cleaned up only if added. Fix the resource cleanup by reorganizing the code around probe failure. Reported-by: Sashiko AI Reviewed-by: Charlie Jenkins Signed-off-by: Atish Patra Link: https://patch.msgid.link/20260807-counter_delegation-v9-1-58658104e487@meta.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 986332050529cb212b9485ddd3195a63a6493d2b Author: Rui Qi Date: Fri Aug 7 19:24:33 2026 -0600 riscv: kprobes: Prevent probes in breakpoint handlers [ Upstream commit e7d8ea6c6d1bc685a8943ffad2d3679be92d164f ] The ftrace selftest multiple_kprobes.tc registers kprobe events on the first 256 text symbols from /proc/kallsyms. If handle_break() is selected as a probe target on RISC-V, the breakpoint exception path can trap again before it reaches the kprobe breakpoint handler. That recursively enters do_trap_break() and can make the system unresponsive. Mark handle_break() and its local probe dispatch helpers as nokprobe symbols so they are added to the kprobe blacklist, matching other low-level breakpoint exception paths. Signed-off-by: Rui Qi Reviewed-by: Nam Cao Link: https://patch.msgid.link/20260806043807.2583001-1-qirui.001@bytedance.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 5d85de145077de51af264f860a123ea999d76397 Author: Daniel Golle Date: Tue Aug 4 04:10:46 2026 +0100 net: dsa: mt7530: check CORE_PLL_GROUP4 access in mt7531_setup() [ Upstream commit 1ae63b018d3d70e96d420b59a1334860cf232bc6 ] mt7531_setup() reads CORE_PLL_GROUP4 through the MT7531 indirect c45 PHY access, modifies it and writes it back to enable the PHY core PLL, but checks neither the read nor the write. Now that the indirect access functions propagate command-write failures, a failed read returns a negative errno that would be bit-modified and written back into the PLL register, and a failed write-back would go unnoticed. Check both and bail out. The adjacent EEE advertisement writes push a constant value and cannot corrupt state, so they are left as is. Signed-off-by: Daniel Golle Link: https://patch.msgid.link/a7dfe3b66ea6ac1ae7915034de0527060e6ddcd4.1785811140.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bb7a7de37a7f68b543d682f91a5fa1f163290a4c Author: Daniel Golle Date: Tue Aug 4 04:10:26 2026 +0100 net: pcs: mtk-lynxi: check regmap reads in mtk_pcs_lynxi_get_state() [ Upstream commit 5cc65c01cdc577621d1320f4aa03a1382c5a4a45 ] mtk_pcs_lynxi_get_state() ignores regmap_read()'s return value; a failed read leaves bm and adv holding uninitialized stack values which are then decoded into the reported link state. The regmaps backing the MT7531 SGMII PCS instances sit on an MDIO bus where reads can fail. Check both reads and report the link as down on error; phylink presets state->link before the callback, so a bare return would leave a failed read reported as link-up. Signed-off-by: Daniel Golle Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/fce70657fc03bbaf60a04c0fbf2f418531135c4f.1785811140.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 862d6c599ec14542f28e0b85a41f7d9b4abbc2ff Author: Daniel Golle Date: Tue Aug 4 04:10:33 2026 +0100 net: dsa: mt7530: check bus->read() error in core_rmw() [ Upstream commit 573d6e3afe3d01e34dc82c77bf22ca96a74d805e ] core_rmw() accesses the MMD core registers directly rather than through the regmap and has the same unchecked bus->read() as the one just fixed in the MDIO regmap backend: a negative errno is consumed as register data, modified and written back to the switch. Check the read and bail out like the surrounding bus accesses do. Signed-off-by: Daniel Golle Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/48bb9f0b311a9efeda2a6b24a7e05d4792393a3b.1785811140.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 55a219de3940bc84c2175d72e9fe443af534aa05 Author: Laxman Acharya Date: Wed Aug 5 23:22:01 2026 +0545 Bluetooth: hci_event: fix out-of-bounds read in LE PA report reassembly [ Upstream commit e3643fbddb257c928c075cab05bbd929106b56ee ] hci_le_per_adv_report_evt() is dispatched with a minimum length of sizeof(struct hci_ev_le_per_adv_report), which only covers the fixed part of the event and not the trailing data[] array: struct hci_ev_le_per_adv_report { __le16 sync_handle; __u8 tx_power; __u8 rssi; __u8 cte_type; __u8 data_status; __u8 length; __u8 data[]; } __packed; The handler notifies the ISO layer via hci_proto_connect_ind(), which reaches iso_connect_ind(). That function retrieves the stored event with hci_recv_event_data() and, while reassembling the periodic advertising data, does: memcpy(hcon->le_per_adv_data + hcon->le_per_adv_data_offset, ev->data, ev->length); ev->length is taken directly from the event and is never validated against the amount of data the event actually carries. A controller that reports a length larger than the received event therefore causes the memcpy() to read past the end of the event buffer. The leaked bytes are stored in hcon->le_per_adv_data and can subsequently be read back from user space via getsockopt(BT_ISO_BASE). Validate that the event contains ev->length data bytes before it is consumed, mirroring the check already performed by hci_le_ext_adv_report_evt() and hci_le_adv_report_evt(). Signed-off-by: Laxman Acharya Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 85c654b0353d32114d9b42c50c701adacb38b825 Author: Daniel Golle Date: Tue Aug 4 04:10:40 2026 +0100 net: dsa: mt7530: error out on failed PHY_IAC command writes [ Upstream commit 1c95dcb7e923beebccdc79adc3dc1ec8c52295d0 ] MT7531_PHY_ACS_ST is only ever set by the command write that precedes each poll in the MT7531 indirect PHY access functions, and that write's return value is discarded. A failed write leaves ACS_ST at 0 from the previous access, so the poll succeeds on its first iteration and the functions return stale IAC contents as if they were fresh PHY data. Check the writes and bail out before polling. Signed-off-by: Daniel Golle Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/c34602e63a20ebbfb97babd145c82832d7a0b523.1785811140.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 76eb6501146433324bac89f42c4de6985a278472 Author: Muhammad Saheed Date: Wed Aug 5 01:40:51 2026 +0530 Bluetooth: hci_sync: Disable legacy instance's ext adv before setup snapshot [ Upstream commit 75722cde87ee24029e93e4e32d85309989f55991 ] hci_setup_ext_adv_instance_sync(...) only disabled HCI_OP_LE_SET_EXT_ADV_ENABLE before setup snapshot in case of non-legacy instances (instance > 0) and never disabled the same for legacy instance (instance == 0). This would lead to failure in setting ext adv params with HCI_ERROR_COMMAND_DISALLOWED (0x0c) error like below, when toggling the discoverable/connectable property of a controller with advertising enabled. ``` $ btmgmt advertising off hci0 Set Advertising complete, settings: powered ssp br/edr le secure-conn wide-band-speech cis-central cis-peripheral $ btmgmt connectable on hci0 Set Connectable complete, settings: powered connectable ssp br/edr le secure-conn wide-band-speech cis-central cis-peripheral $ btmgmt connectable off hci0 Set Connectable complete, settings: powered ssp br/edr le secure-conn wide-band-speech cis-central cis-peripheral $ btmgmt advertising on hci0 Set Advertising complete, settings: powered connectable ssp br/edr le advertising secure-conn wide-band-speech cis-central cis-peripheral $ btmgmt connectable on Set Connectable for hci0 failed with status 0x0a (Busy) $ btmgmt connectable off Set Connectable for hci0 failed with status 0x0a (Busy) $ dmesg ... [ 21.970527] hci0: Opcode 0x2036 [ 21.970529] hci0: opcode 0x2036 plen 25 [ 21.970537] hci0: skb len 28 [ 21.970539] hci0: length 1 [ 21.976099] hci0: result 0x0c [ 21.976105] hci0: end: err -16 [ 21.976114] Bluetooth: hci0: Opcode 0x2036 failed: -16 ``` Signed-off-by: Muhammad Saheed Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 6a8a53b1f0c0df28265a828a37e92317986a75d4 Author: Li Qiang Date: Thu Jul 16 16:47:30 2026 +0800 Bluetooth: hci_bcsp: validate received packet lengths [ Upstream commit ceea75ad8925425ee6520ead964b55888fe871ec ] The BCSP transmit path reads an HCI command header when an extension packet has only been tested for a nonzero length. Its LE configuration packet handler also indexes bytes through offset seven without a length check. Validate the complete command and LE configuration packet headers before accessing their fields. Signed-off-by: Li Qiang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c20a043e619dfe9bec061e85bbd813b6e08e264f Author: Chen Changcheng Date: Wed Jul 22 16:31:36 2026 +0800 Bluetooth: btrsi: Move set_bt_context after successful HCI registration [ Upstream commit 290a3644609526f7ac12529cd1618042fa5a32db ] In rsi_hci_attach(), ops->set_bt_context() stores the newly allocated h_adapter into common->bt_adapter before hci_alloc_dev() and hci_register_dev() are called. If either of these fails, h_adapter is freed but common->bt_adapter remains a non-NULL dangling pointer. This causes a deterministically reachable use-after-free when the device operates in a BT+WiFi coexistence mode and CONFIG_RSI_COEX is enabled. The following software-only trigger paths exist: 1. SDIO driver .remove (rsi_disconnect) 2. USB driver .disconnect (rsi_disconnect) 3. SDIO driver .shutdown (rsi_shutdown) 4. Hibernation .freeze (rsi_freeze) All four paths check: if (IS_ENABLED(CONFIG_RSI_COEX) && coex_mode > 1 && bt_adapter) rsi_bt_ops.detach(bt_adapter); // use-after-free coex_mode is set during rsi_91x_init(), before rsi_hci_attach() is called, and is not cleared on attach failure. Since set_bt_context() already wrote bt_adapter before the failure, the deinit paths see a non-NULL dangling pointer and proceed to detach it. Fix this by moving set_bt_context() after hci_register_dev() succeeds. On failure paths bt_adapter stays NULL, and the deinit callers correctly skip the detach call. Signed-off-by: Chen Changcheng Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit fef4ab49d666a310be30089afd85bcc166284472 Author: Garrett Blackmon Date: Fri Aug 7 10:07:08 2026 -0500 ALSA: hda/realtek: Fix speakers on ASUS ROG Zephyrus G14 GA403UM [ Upstream commit 140fe610af607fd70da95c447943fc2690855519 ] The GA403UM (SSID 1043:1044) uses the same ALC285 codec + dual CS35L56 I2C amplifier topology as the GA403U and GA403W variants, which already have quirk entries (1043:1b13, 1043:1024). Without the quirk, the woofers sit on a separate DAC from the tweeters, so the hardware volume control only scales part of the speaker system and the headset microphone pins are not configured. Apply the existing ALC285_FIXUP_ASUS_GA403U_HEADSET_MIC fixup to the GA403UM as well. Signed-off-by: Garrett Blackmon Link: https://patch.msgid.link/20260807150708.33785-1-garrett@blackmon.dev Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4724ba2cff8c678be9410d6694ef09d2d8771e78 Author: Zhang Heng Date: Fri Aug 7 20:58:56 2026 +0800 ALSA: hda/realtek: Fix headset mic on ASUS Vivobook S14 S5406SA [ Upstream commit f2d08f3651fb12634347fef2c41687a807a7dcba ] On the ASUS Vivobook S14 S5406SA (subsystem 0x104310c4, Lunar Lake platform) with an ALC294 codec, the headset microphone (3.5mm jack) fails to capture any audio. Adding the ALC2XX_FIXUP_HEADSET_MIC quirk resolves the issue and restores proper headset mic recording. Link: https://github.com/thesofproject/linux/issues/5729 Signed-off-by: Zhang Heng Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260807125857.678297-3-zhangheng@kylinos.cn Signed-off-by: Sasha Levin commit c25102cab6bf1e5a52f4c4d5f94eecd9d5e10a2f Author: Junhao He Date: Wed May 27 16:27:07 2026 +0800 ACPI: APEI: Handle repeated SEA error storms [ Upstream commit e61487226b7df39e5f4683b036ee6aa7a5039d7b ] When hardware memory corruption occurs and a user process accesses the corrupted page, the CPU triggers a Synchronous External Abort (SEA). The kernel invokes do_sea() to handle the exception, which calls memory_failure() to handle the faulty page. Scenario 1: Memory Error Interrupt First, then SEA The page is already poisoned by the memory error interrupt path. The subsequent SEA handler sends a SIGBUS to the task, which accesses the poisoned page. This flow is correct. Scenario 2: SEA first, then memory error interrupt (problematic scenario) If a user task directly accesses corrupted memory through a PFNMAP-style mapping (e.g., devmem), the page may still be in the free-buddy state when SEA is handled. In this case, memory_failure() will poison the page without invoking kill_accessing_process(), and then takes the free-buddy recovery path. After the CPU returns to the task context, the task re-enters the SEA handler due to the same access. However, ghes_estatus_cached() suppresses all subsequent entries during the 10-second window, preventing ghes_do_proc() from being called. This suppression blocks the MF_ACTION_REQUIRED-based SIGBUS delivery, causing the kernel to fail to kill the task immediately. Consequently, the process keeps re-entering the SEA handler, leading to an SEA storm. Later, the memory error interrupt path also cannot kill the task, leaving the system stuck in this repeated loop. The following error logs are explained using the devmem process: NOTICE: SEA Handle [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9 [Hardware Error]: event severity: recoverable [Hardware Error]: section_type: ARM processor error [Hardware Error]: physical fault address: 0x0000001000093c00 [T54990] Memory failure: 0x1000093: recovery action for free buddy page: Recovered [ T9955] EDAC MC0: 1 UE Multi-bit ECC on unknown memory (page:0x1000093 offset:0xc00 grain:1 - APEI location: ...) NOTICE: SEA Handle NOTICE: SEA Handle ... ... ---> SEA storm ... NOTICE: SEA Handle [ T9955] Memory failure: 0x1000093: already hardware poisoned ghes_print_estatus: 1 callbacks suppressed [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9 [Hardware Error]: event severity: recoverable [Hardware Error]: section_type: ARM processor error [Hardware Error]: physical fault address: 0x0000001000093c00 [T54990] Memory failure: 0x1000093: already hardware poisoned [T54990] 0x1000093: Sending SIGBUS to devmem:54990 due to hardware memory corruption To resolve this, return an error when encountering the same SEA again. The subsequent SEA handler invocation uses arm64_notify_die() to send a SIGBUS signal to the task, which terminates the process and prevents it from re-entering the handler loop. Signed-off-by: Junhao He Reviewed-by: Wupeng Ma Reviewed-by: Shuai Xue Reviewed-by: Tony Luck Link: https://patch.msgid.link/20260527082707.2013499-1-hejunhao3@h-partners.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6dff4338b0e10e1301192b4e93569cf3840d512d Author: Aurabindo Pillai Date: Wed Jul 22 14:44:37 2026 -0400 drm/amd: Add DCN6 register headers [ Upstream commit fe219bd7d9783a6cb9249bc333546cb58d2c2723 ] Add new headers for: - dcn 6.0.0 - dpcs 6.0.0 - mmhub 5.0.1 Signed-off-by: Aurabindo Pillai Signed-off-by: Roman Li Reviewed-by: Ivan Lipski Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5afdf9cf8a2a0cb33d7527fe30576f7b91c8f5d7 Author: Filipe Manana Date: Fri Jun 12 12:02:14 2026 +0100 btrfs: fix memory barrier order in reloc_root_is_dead() [ Upstream commit 6f1c97695a6e230ee15c9e052e1933bdccfd5fa3 ] When we set a root's reloc_root to NULL, we do it like this: static void clear_reloc_root(struct btrfs_root *root) { root->reloc_root = NULL; /* * Need barrier to ensure clear_bit() only happens after * root->reloc_root = NULL. Pairs with have_reloc_root(). */ smp_wmb(); clear_bit(BTRFS_ROOT_DEAD_RELOC_TREE, &root->state); } So that a NULL reloc_root is always seen before seeing that the bit BTRFS_ROOT_DEAD_RELOC_TREE was cleared. But on the read side we have: static bool reloc_root_is_dead(const struct btrfs_root *root) { smp_rmb(); if (test_bit(BTRFS_ROOT_DEAD_RELOC_TREE, &root->state)) return true; return false; } And then callers of reloc_root_is_dead() access root->reloc_root. Because the read memory barrier is placed before testing the bit, the CPU is completely free to speculatively reorder those two loads. It can read root->reloc_root before it actually checks the dead tree bit. Sashiko reported this as an existing problem in another patch review, see the link in the Link tag below. Fix this by moving the read memory barrier to happen after testing the bit and update the comment to reflect current reality. Link: https://sashiko.dev/#/patchset/cf84f1a217c719e25b6b69e4298dd7afd36c9427.1781194426.git.fdmanana%40suse.com Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 71e9850c372b1eff90fdc6b2e7509327b602c66b Author: Pengpeng Hou Date: Mon Jul 6 17:17:01 2026 +0800 Bluetooth: hci_nokia: validate firmware packet bounds [ Upstream commit 45640627e3ddc5f4d3a0d08618a596a8c65d48a5 ] nokia_setup_fw() walks a length-prefixed firmware stream and decodes HCI command packets from each record. Check that each record fits in the remaining firmware image, that command records contain the HCI command header, and that the payload length is covered before submitting the command. Signed-off-by: Pengpeng Hou Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3f94d50d769a653bb9e1877427e0b097cff504a8 Author: Pavel Zverev Date: Wed Jul 8 01:15:49 2026 +0300 Bluetooth: btusb: Add support for 1357:c123 Realtek 8852BE device [ Upstream commit 335d7bd554a20f33acf762655cafe1089f7f5822 ] Wiko Hi MateBook 14 Ryzen 200 laptops (DMI system-product-name "MNCA-XX", board "M1060") are equipped with an RTL8852BE Wi-Fi/BT combo chip (rtw89_8852be), whose Bluetooth radio enumerates as 1357:c123 instead of one of the already-supported 1358:c123 / 0bda:c123 identifiers, presumably due to OEM rebranding. Without a matching entry it only matches the generic USB Bluetooth class fallback, so the Realtek firmware/config (rtl8852btu_fw.bin / rtl8852btu_config.bin) is never loaded and the adapter cannot discover or connect to any device, even though hciconfig reports it as powered and scanning. Device descriptor: idVendor 0x1357 idProduct 0xc123 bcdDevice 0.00 iManufacturer 1 Realtek iProduct 2 Bluetooth Radio bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 1 Bluetooth Adding the same BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH quirk already used for 1358:c123 and 0bda:c123 fixes firmware loading and normal operation. Signed-off-by: Pavel Zverev Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4a0c87d2d6116860990b37bd8ec119e33c8f723e Author: Rui Qi Date: Fri Aug 7 16:15:11 2026 +0800 selftests/ftrace: Force C locale in ftracetest [ Upstream commit c13fcd3951dcc19524ce0b3e852844b16cd32b22 ] Some ftracetest test cases parse command output by matching English field names. Tools such as readelf may localize their output via gettext, while ftracetest currently inherits the user locale from the environment. If a translated field name is printed, parsing can fail even though the tested kernel behavior is unchanged. For example, add_remove_uprobe can fail to find the ELF entry point and then write a uprobe event with a missing offset. Export LC_ALL=C in the top-level ftracetest runner so every test case gets stable command output by default. Link: https://lore.kernel.org/all/20260807081512.2974757-2-qirui.001@bytedance.com/ Signed-off-by: Rui Qi Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 4bcda5539ed90427e057f3ef1b5e884392dfee63 Author: Andreas Haufler Date: Tue Jul 21 10:32:13 2026 +0200 tools/lib/thermal: Fix misplaced extern "C" closing brace [ Upstream commit cb0ec27efac2aaf92393ad563a35fb6f00d0a6cd ] The public libthermal header opens the C++ 'extern "C" {' block inside the __LIBTHERMAL_H include guard, but places the closing brace after the guard has already ended: #endif /* __LIBTHERMAL_H */ #ifdef __cplusplus } #endif On a single inclusion the braces still balance, so the problem is invisible. On the second inclusion of the header in the same C++ translation unit the include guard skips the opening 'extern "C" {', while the closing '}' lives outside the guard and is emitted anyway. This leaves a stray '}' and breaks compilation for any C++ consumer that includes the header more than once. Move the closing block inside the include guard so both halves of the 'extern "C"' declaration are guarded consistently. Signed-off-by: Andreas Haufler Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260721083230.91246-1-andreas@haufler.info Signed-off-by: Sasha Levin commit b04fcf7045e7283c5b11d06838ff12d33c02db21 Author: Yunye Zhao Date: Thu Jul 23 21:55:34 2026 +0800 md: add cond_resched() to md_do_sync()'s skip path [ Upstream commit 162eb5ba791f6260fdaabae75fa2df20134f67d8 ] When sync_request() reports a skipped region (*skipped == 1), md_do_sync()'s main loop advances the cursor and takes an early continue: j += sectors; ... if (last_check + window > io_sectors || j == max_sectors) continue; If the personality returns a small span per call (raid10 recovery returns only 128 sectors), syncing a large, mostly clean array iterates this branch an enormous number of times without ever yielding the CPU. On a non-preemptive kernel the resync thread then trips the soft-lockup watchdog: watchdog: BUG: soft lockup - CPU#149 stuck for 313s! [mdX_resync] md_bitmap_start_sync+0x6f/0xe0 raid10_sync_request+0x2c9/0x1530 [raid10] md_do_sync+0x810/0x1030 md_thread+0xa7/0x150 Add a cond_resched(). This does not reduce the wasted iterations; the excessive iteration count is a raid10 problem addressed separately. Signed-off-by: Yunye Zhao Link: https://patch.msgid.link/20260723135535.101995-3-yunye.zhao@linux.alibaba.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit a1dafb10a79fba80e35e4a83331fc59001ce9bd7 Author: Yu Kuai Date: Mon Aug 3 03:50:13 2026 +0800 md/raid5: reject zero-sector reshape chunks [ Upstream commit a41bb2ee1aca486853e84920565e50c15f86fa5d ] Sashiko reported that RAID5 can accept a reshape chunk size that becomes zero sectors. chunk_size_store() stores the sysfs byte value as n >> 9, so writing a value below 512 bytes sets mddev->new_chunk_sectors to zero. RAID5 then accepted that pending reshape geometry and raid5_start_reshape() installed it into conf->chunk_sectors, letting reshape code divide by zero. Reject zero-sector chunks both in check_reshape(), where normal sysfs requests are validated, and in raid5_start_reshape(), so assembly/resume paths also cannot install zero chunk geometry. Test script: in QEMU, create a plain three-disk RAID5 array with 64K chunks, write/read back a small pattern, write 1 to /sys/block/md0/md/chunk_size, add a fourth disk, and run mdadm --grow --raid-devices=4 --backup-file=... . The script scans dmesg for divide error/Oops/KASAN signatures. Bad kernel, eb29914412c3: echo 1 > /sys/block/md0/md/chunk_size mdadm --grow /dev/md0 --raid-devices=4 --backup-file=/root/md0-grow.bak Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: raid5_get_active_stripe+0x863/0xc10 Call Trace: raid5_sync_request md_do_sync md_thread Kernel panic - not syncing: Fatal exception Fixed kernel: echo 1 > /sys/block/md0/md/chunk_size bash: echo: write error: Invalid argument chunk_write_rc=1 grow_rc=skipped RESULT: REJECTED_ZERO_CHUNK_NO_OOPS Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-5-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 0cf4c17737c59a73717f1e439d0804fb73ae7ab0 Author: Shang En Sim Date: Thu Aug 6 22:51:27 2026 -0700 ALSA: hda/realtek: Enable mute LEDs on HP Spectre x360 16-aa0xxx [ Upstream commit bfcdc1c0eaeae5525c726193568e8d638b2afdc0 ] The HP Spectre x360 2-in-1 Laptop 16-aa0xxx with PCI subsystem ID 0x103c:0x8c17 only gets the CS35L41 amplifier setup from ALC287_FIXUP_CS35L41_I2C_2, so the speaker-mute and mic-mute keyboard LEDs do not work. Use ALC245_FIXUP_HP_SPECTRE_X360_16_AA0XXX like subsystem ID 0x8c16 so the mute LEDs work. Tested on HP Spectre x360 2-in-1 Laptop 16-aa0xxx. Signed-off-by: Shang En Sim Link: https://patch.msgid.link/20260807055139.58707-1-sim@shangen.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e8c67442a8a494d44d0a75965d6fa83757be34ae Author: Junzhe Yu Date: Tue Aug 4 12:55:33 2026 +0800 ext4: guard against NULL s_group_info in ext4_get_group_info [ Upstream commit 8f3901fbb40745046e513226ad84e8b84492632d ] Resend: previous attempt was rejected by vger for containing HTML. ================================================================== ext4_mark_group_bitmap_corrupted() already treats a NULL return from ext4_get_group_info() as "nothing to do", but ext4_get_group_info() indexes s_group_info without checking whether the array exists. During mount, fast-commit replay runs inside jbd2_journal_load() from ext4_load_and_init_journal(), which is before ext4_mb_init() allocates s_group_info. Replaying an FC UNLINK for an inode whose bitmap bit is already clear takes:   ext4_fc_replay_unlink -> iput -> ext4_evict_inode -> ext4_free_inode     -> ext4_mark_group_bitmap_corrupted -> ext4_get_group_info and faults on the NULL s_group_info base. Userspace only mounts a dirty ext4 image; this is a supported recovery path. Return NULL when s_group_info (or the per-block grp_info row) is unset so the existing caller check is effective during early mount. Tested on Linux v6.6.145 KASAN: crafted FC-unlink image previously triggered KASAN null-ptr-deref / panic in ext4_get_group_info; with this patch, mount succeeds (EXT4 "bit already cleared" may still log). Also observed on v6.6.144; still present on torvalds/linux as of f5098b6bae76 (2026-07-26). A self-contained Docker/QEMU reproducer (craft + mount + patch verify) is available on request. Signed-off-by: Yu Junzhe Link: https://patch.msgid.link/65c955b0-716b-4599-b925-59c2782e38b4@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 6bc55ea1a97ab28123b374f5c426d3043953472c Author: Pengpeng Hou Date: Tue Jun 30 14:52:45 2026 +0800 HID: rmi: check report length before trimming sentinel bytes [ Upstream commit 28a3e326fad2451bdb66b747dd1f7ccbb900eed6 ] rmi_check_sanity() trims trailing 0xff sentinel bytes, but its loop reads data[valid_size - 1] before checking that valid_size is non-zero. Reverse the condition so the length is proved before the last byte is inspected. Signed-off-by: Pengpeng Hou Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 732d68bdbb4628170e9364dbc86e37a2f910d67e Author: liulhong617 Date: Wed May 13 09:02:55 2026 +0800 arm64: mm: fix accidental linear mapping of no-map reserved memory [ Upstream commit 7ace06a01efaba1ec585630aa4c98ac39b38452a ] When reserved-memory regions with the "no-map" property are not page-aligned, the kernel may accidentally map them into the linear mapping, contradicting the no-map semantics. The root cause is a mismatch between /proc/iomem's address boundaries and the actual page table mapping boundaries: 1. /proc/iomem derives its ranges from memblock via memblock_region_reserved_base_pfn/memblock_region_reserved_end_pfn, which perform PFN rounding so the displayed boundaries are page-aligned. This gives the impression that the no-map region occupies whole pages. 2. However, memblock_mark_nomap() splits memblock.memory regions at exact byte boundaries (memblock_isolate_range preserves raw DT base/size with no alignment). When for_each_mem_range iterates the non-NOMAP regions adjacent to a no-map region, it returns start/end values that are NOT page-aligned — they are the precise byte boundaries from the memblock split. 3. These sub-page-aligned values are passed to __create_pgd_mapping_locked(), which does: phys &= PAGE_MASK; addr = virt & PAGE_MASK; end = PAGE_ALIGN(virt + size); The downward rounding of phys via PAGE_MASK extends the mapped range backward into the adjacent no-map region, effectively including no-map memory in the linear mapping. For example, with 64K pages, reserved_region@A2000000 (base=0xA2000000, size=0x8000, no-map) causes for_each_mem_range to return start=0xA2008000 for the next mappable region. After phys &= PAGE_MASK, the actual mapping starts at 0xA2000000 — the entire no-map region is incorrectly mapped. Fix this by rounding the mappable range inward to PAGE_SIZE boundaries before passing it to __map_memblock: start is rounded UP and end is rounded DOWN. This ensures the mapped area never overlaps with adjacent no-map regions. The cost is at most one page of unmapped gap at each boundary, which is preferable to violating no-map semantics. Signed-off-by: liulhong617 Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 75bc8534fb3179a45f54d524d50357819d3b7080 Author: Stefan Hansson Date: Tue Aug 4 10:55:41 2026 +0200 wifi: rsi: Fix types to appease CFI [ Upstream commit da308f6e471252ae5e8009dcea16bc5e9c9dc5dd ] Avoids errors like: CFI failure at kthread+0x124/0x1cc (target: rsi_coex_scheduler_thread+0x0/0x1b4 [redpine_91x]; expected type: 0x89fb613d) As seen in the aforementioned error this was tested using the downstream redpine_91x driver found in the Librem 5's downstream source tree. However, it appears that this driver is a modified version of the rsi driver found in mainline Linux and as such I decided to port the changes here too. Signed-off-by: Stefan Hansson Link: https://patch.msgid.link/20260804-rsi-cfi-fix-v2-1-59679a520240@postmarketos.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit dae5d6a419300e3a4331a66ff98f18e9e71cc991 Author: Charles Keepax Date: Mon Jul 20 10:57:41 2026 +0100 soundwire: dmi-quirks: Disable ghost Realtek on Asus Zenbook Duo [ Upstream commit ca02ffd4975ca5249abf0cfb750a495d23b453ee ] The Asus Zenbook Duo also has a Realtek device in the ACPI that doesn't exist in the physical hardware. This confuses the machine driver into attempting to create DAI links for the device. Add a quirk to remove this device. Signed-off-by: Charles Keepax Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260720095741.3592825-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 9653e043f69f9ffa34657a029ba104c0a335ef2a Author: Praveen Talari Date: Mon Jul 27 22:33:12 2026 +0530 opp: Use clk_get_optional() to avoid leaving opp_table->clk as an error pointer [ Upstream commit 84f05af0975c9f9c8ffee0361d6f7cbb1f289231 ] _update_opp_table_clk() uses clk_get(dev, NULL) to acquire the device's clock. On platforms where the perf domain device has no Linux clock and is instead managed entirely by firmware via devm_pm_opp_of_add_table() (through of_genpd_add_provider_simple()/onecell()), clk_get() returns -ENOENT. That case is treated as valid (the OPP table can still have entries sourced from firmware), but opp_table->clk is left holding ERR_PTR(-ENOENT) rather than being reset to NULL: opp_table->clk = clk_get(dev, NULL); ret = PTR_ERR_OR_ZERO(opp_table->clk); ... if (ret == -ENOENT) { opp_table->clk_count = 1; return opp_table; /* opp_table->clk is still ERR_PTR(-ENOENT) */ } Consumers that only check IS_ERR(opp_table->clk) treat this as a valid clk and pass it straight into the clk consumer API. In particular, dev_pm_opp_set_rate() calls clk_round_rate(opp_table->clk, target_freq), and clk_round_rate() only guards against a NULL clk, so it dereferences the error pointer to read clk->exclusive_count and crashes: Unable to handle kernel NULL pointer dereference at virtual address 000000000000002e ... pc : clk_round_rate+0x3c/0x188 ... Call trace: clk_round_rate+0x3c/0x188 (P) dev_pm_opp_set_rate+0x114/0x33c Rather than teaching every clk consumer API to special-case ERR_PTR(-ENOENT), fix it at the source: use clk_get_optional() instead of clk_get() in _update_opp_table_clk(), which already translates -ENOENT into a NULL clk. This documents that the clock is genuinely optional for such devices, and keeps opp_table->clk holding either a valid clk or NULL, never a lingering -ENOENT error pointer. _opp_config_clk_single() is only wired up via opp_table->config_clks when a clk was actually found, and every other opp_table->clk consumer already tolerates NULL through the standard clk API (which treats a NULL clk as a no-op), so no other call site needs to change. Suggested-by: Sebastian Reichel Reviewed-by: Sebastian Reichel Signed-off-by: Praveen Talari Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit cd788fbac95d19dcf41fd5643e6c810b30c13058 Author: Carl Quist Date: Thu Aug 6 11:47:18 2026 +0200 ALSA: hda/realtek: Enable mute LED on HP Laptop 15-dy0xxx [ Upstream commit eb2b516900f2cff6c931a0d664a625ee93855779 ] The mute LED on the HP Laptop 15-dy0xxx (PCI SSID 103c:864f, Realtek ALC236) does not work, because the machine has no entry in the quirk table. No fixup is applied, so no mute LED classdev is registered and nothing ever drives the LED. The LED is controlled by COEF index 0x07, bit 0. This was verified on the hardware with hda-verb: setting the bit lights the mute LED and clearing it turns the LED off. hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x07 hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x1 # LED on hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x200 # LED off That is exactly what ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 configures, and the closely related HP Laptop 15-dw0xxx (103c:85f0) already uses it. Bit 9 (0x200) is set by default on this board and is preserved by the fixup's read-modify-write. Tested on an HP Laptop 15-dy0xxx (SKU 7FU54UA#ABA, board 864F, BIOS F.40). Signed-off-by: Carl Quist Link: https://lore.kernel.org/CAOtcGaxXndKxTK5MVSEcmF-LUy+V51K7fhE=qvLA+VvW5ZyCNA@mail.gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit fce3b3085fe8884929a14ffdcf781b91ea27a171 Author: Zihan Xi Date: Fri Jul 31 16:46:23 2026 +0000 xsk: account ring allocations to memcg [ Upstream commit b0057c68df711bf6a62033c072ac61c4f9d3cbc1 ] AF_XDP rings are allocated from setsockopt() and can be mapped into user space. The shared xskq_create() helper allocates the ring backing memory, but the user-controlled and long-lived allocation is not charged as kmem to the allocating memory cgroup. The current implementation uses vmalloc_user(), which allocates the backing pages with GFP_KERNEL | __GFP_ZERO. Use the same VM_USERMAP vmalloc path, but pass GFP_KERNEL_ACCOUNT so the ring backing pages are attributed to memcg/kmem and can be constrained by existing cgroup memory limits. This keeps the existing zeroing and mmap semantics while avoiding AF_XDP-specific optmem or RLIMIT_MEMLOCK accounting. Signed-off-by: Zihan Xi Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20260731164623.4694-2-zihanx@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a35dcf6b398cc22a8af7ad7e32cde484941b9663 Author: Jinhui Guo Date: Thu Jul 30 13:13:41 2026 +0800 net: usb: cdc_ether: add quirk for AMI BMC stale link events [ Upstream commit 089ca284afb0f3b2870a5ce41524cbc91ed350d4 ] On AMD Genoa/Turin platforms the BMC-provided USB-Ethernet gadget (American Megatrends, VID 0x046b PID 0xffb0) intermittently fails to respond to ARP after AC cold boot. usbmon captures a stale NETWORK_CONNECTION(off) immediately followed by NETWORK_CONNECTION(on) on the interrupt endpoint (~130us apart) after enumeration. Because alloc_netdev() leaves __LINK_STATE_NOCARRIER cleared, netif_carrier_ok() returns true when the spurious OFF arrives, so usbnet_cdc_status() cannot recognise it as redundant and schedules EVENT_LINK_CHANGE. __handle_link_change() then calls unlink_urbs(), killing ~60 rx URBs whose payload has already been DMA'd into memory — xHCI trace confirms them completing as -ECONNRESET with non-zero residual length. rx_complete() drops these unconditionally. The following ON restores the carrier and re-submits URBs, but the ARP reply is already lost; the interface looks "up but silent" until ifdown/ifup. Fix this by adding a device-specific quirk with FLAG_LINK_INTR set, which makes usbnet_probe() call netif_carrier_off() after bind. With initial carrier == OFF, usbnet_cdc_status() recognises the spurious OFF as matching the current state and drops it; the subsequent ON is the first real event and brings the link up cleanly without ever tearing down the rx queue. The scheduled link-change kevent is harmless because EVENT_DEV_OPEN is not yet set at probe time. This is applied as a device-specific quirk rather than a change to the shared cdc_info driver_info because some CDC devices never send NETWORK_CONNECTION notifications; forcing carrier off for them would leave the link permanently DOWN. Restricting the change to this VID/PID keeps that class of device untouched. Tested on Genoa and Turin across 100+ AC cold boot cycles; ping first-packet success rate went from intermittent to 100%. Signed-off-by: Jinhui Guo Link: https://patch.msgid.link/20260730051341.24930-1-guojinhui.liam@bytedance.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0549cd3cba44a5cc98060d3cc1d01c5aed12be65 Author: Johan Alvarado Date: Fri Jul 31 14:45:22 2026 -0500 net: stmmac: raise TX completion interrupt at the end of an xmit burst [ Upstream commit d21a374995df9d7cfd193427748a19dcc87956a9 ] The TX mitigation logic only sets the Interrupt on Completion bit once every tx_coal_frames descriptors (STMMAC_TX_FRAMES = 25), with the tx_coal_timer hrtimer (STMMAC_COAL_TX_TIMER = 5000 us) as the only fallback. TX skbs are freed exclusively from the TX completion path, so any flow that keeps fewer than 25 frames in flight has all of its skbs held for up to 5 ms after transmission. Paced flows never queue enough frames to reach the frame threshold: TCP Small Queues caps the amount of unfreed data at roughly two pacing intervals worth, which at moderate pacing rates is only a couple of packets. Every small burst then stalls until the coalesce timer fires, and throughput collapses to approximately tsq_limit / tx_coal_timer regardless of link capacity. This is easily reproducible with BBR, which paces its output and thus keeps only a few frames in flight at a time. On a YT6801 (dwmac-motorcomm) equipped Orange Pi 5 Pro, a BBR upload over a ~23 ms RTT path is capped at 5.24 Mbit/s, while CUBIC reaches 207 Mbit/s on the same path. BBR measures the stalled send rate as the path bandwidth and locks its estimate near the floor, so the connection never recovers. Lowering the coalesce settings with ethtool -C (tx-usecs 100 tx-frames 1) lifts the same transfer to 447 Mbit/s, confirming the mechanism. Fix this by setting the IC bit on the last descriptor of every xmit burst, i.e. whenever netdev_xmit_more() reports that no further frames are pending in the current dequeue batch. Frame-based coalescing still applies within a burst, bulk traffic keeps batching through qdisc bulk dequeue and NAPI polling, and the coalesce timer becomes a pure fallback instead of the primary completion mechanism for lightly queued flows. tx-frames 0 keeps its meaning of timer-based mitigation only. Signed-off-by: Johan Alvarado Link: https://patch.msgid.link/20260731194522.55069-1-contact@c127.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9fd1557a39365734dc164d661222aa0acd249fcb Author: Felix Fietkau Date: Sat Aug 1 14:53:32 2026 +0000 wifi: mt76: mt7603: file buffered frames under the TID reported to mac80211 [ Upstream commit 0bbd6c52dfff62b319963f54cd9370f9486e59d2 ] The PS queue filed redirected frames under the TID taken from the TXD, while mac80211 was told about the TID taken from the QoS header, or TID 0 for anything that is not a QoS data frame. When the two disagree, mt7603_release_buffered_frames() skips the frame because it does not match the requested TIDs, so it stays in the PS queue until the station wakes up. Buffered MMPDUs hit this whenever they were sent on a non-zero TID. Use one TID for both. Link: https://patch.msgid.link/20260801145334.1166751-8-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit abce07cad39df85bf62e86e34589adc38d0f4f5d Author: Marcos Paulo Medeiros Date: Mon Jul 27 10:21:51 2026 -0300 ACPI: video: force native backlight on Acer Nitro AN515-46 [ Upstream commit 525ba51157ac6e1772b5412eae26b20dd7ef8bda ] The Acer Nitro AN515-46 is a hybrid graphics laptop whose internal panel is driven by the AMD GPU (Radeon 680M); the discrete NVIDIA GPU only drives external outputs. The firmware nevertheless advertises the NVIDIA WMI EC backlight GUID, so the backlight type resolves to nvidia_wmi_ec. The nvidia-wmi-ec-backlight driver however fails to probe ("EC backlight control failed: AE_NOT_FOUND") and, since the backlight type is still nvidia_wmi_ec, amdgpu skips registering its own backlight device. The result is no backlight device at all, leaving the brightness keys and the desktop brightness slider non-functional. Booting with acpi_backlight=native makes amdgpu register its backlight interface and brightness control works. Add a DMI quirk to use the native backlight on this model by default. Signed-off-by: Marcos Paulo Medeiros Link: https://patch.msgid.link/20260727132151.12792-1-maarcospm1996@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d30c130ff6954e6c963fcc8f834e16f8032b1ab8 Author: Stefan Haberland Date: Wed Aug 5 13:15:57 2026 +0200 s390/dasd: Snapshot intrc before freeing the request block [ Upstream commit dc3e3f7306cb74066f231251602b1be5aaec7bd8 ] __dasd_cleanup_cqr() maps the completion result to a block status by reading cqr->intrc, but only after discipline->free_cp() has returned the request block to its memory pool (dasd_eckd_free_cp() ends in dasd_sfree_request()). On SMP another CPU can reallocate that block and overwrite cqr->intrc before it is read, completing the request with the wrong error. proc_bytes is already snapshotted before free_cp() for the same reason; do the same for intrc. Reviewed-by: Jan Höppner Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260805111612.1285190-5-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a8d0b24b224757fc16639c2eeda7912b9c433020 Author: Simon Glass Date: Tue Jul 14 07:35:42 2026 -0600 kconfig: abort rather than loop for ever on EOF [ Upstream commit f915149f5cfbd0d4406ec0b0f57b1d2c8685ae55 ] When a non-interactive 'make oldconfig' or 'syncconfig' meets a new int or hex symbol whose default cannot be applied, conf_string() reads a value from stdin. At end of file fgets() returns NULL, no value is set and the loop asks again. The result is an endless loop which fills the output until it exhausts memory, rather than a clean failure. Detect this in conf_string(): if the value cannot be set and stdin is at end of file, stop with an error that names the symbol. Note that a symbol with no default doesn't trigger this, since sym_calc_value() falls back to 0, which is accepted at end of file. The loop is triggered by a broken Kconfig file, with a default whose text fails sym_string_valid(). Such mistakes do creep in from time to time and are hard to debug, since the build fills the log with repeated prompts instead of pointing at the offending symbol. Some bad defaults draw a parse-time warning, but menu_validate_number() accepts a reference to any int or hex symbol, so a cross-type reference loops with no warning at all. For example, "0xff" is not a valid int value: config HEXSYM hex default 0xff config VAL int "Value" default HEXSYM Interactive use is unaffected, since feof() only becomes true once a read actually hits end of file: an invalid answer at a terminal still re-prompts, while Ctrl-D at such a prompt exits with the error instead of looping. bool and tristate symbols and choices already accept the default on an empty line, so they still take their defaults in a non-interactive build. Tested with int and hex symbols carrying such defaults: with empty stdin, the code without this change produces around 190MB of repeated prompts within two seconds, while with the change it exits 1 naming the symbol. Piped and interactive (pty) sessions still re-prompt on an invalid answer and then accept a valid one. A new string symbol with no default still takes the empty string at end of file, since any text is valid for a string. Signed-off-by: Simon Glass Link: https://patch.msgid.link/20260714133545.3294648-1-sjg@chromium.org Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit 5088ed8ef8832a23ae5a544c907b4d8de0342341 Author: Allison Henderson Date: Wed Jul 29 21:16:29 2026 -0700 net/rds: unpin MR pages with unpin_user_pages_dirty_lock() [ Upstream commit a507023e6ff1d0b4e7aac49b2f547fed0c21ea4e ] The pages backing an RDS memory region are pinned in __rds_rdma_map() with rds_pin_pages(), which uses pin_user_pages_fast(): each page's refcount is biased by GUP_PIN_COUNTING_BIAS to account the pin. The scatterlist is then handed to the IB transport, and the transport releases the pages in __rds_ib_teardown_mr() with set_page_dirty(page); put_page(page); put_page() drops a single reference instead of removing the pin bias, so every MR teardown permanently strands the remaining references and the pages are never freed - a userspace-triggerable memory leak of up to RDS_MAX_MSG_SIZE per RDS_GET_MR/RDS_GET_MR_FOR_DEST call. The conversion to the pin API updated the unpin sites in rdma.c but missed this one on the transport side. Release the pages with unpin_user_pages_dirty_lock(), which removes the pin bias and also dirties the page under the folio lock, closing the truncation race that a bare set_page_dirty() leaves open. Dirtying under the folio lock can sleep, which is safe in every path that reaches __rds_ib_teardown_mr(): the registration-reuse path (rds_ib_map_frmr()) runs in syscall context, and the pool flush (rds_ib_unreg_frmr()) runs under pool->flush_lock, a mutex, and already sleeps in rds_ib_post_inv(). The WARN_ON that guarded the old irq-context set_page_dirty() case is dropped along with it. Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260730041629.3512480-5-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 493ededd5fde6f5b9c93e85b5bee40ffcd31964c Author: Sharath Srinivasan Date: Wed Jul 29 21:16:28 2026 -0700 net/rds: fix rds_message leak in the rds_send_xmit() drop path [ Upstream commit eb8a59a17f4a8b6f2afb4a8063e99dd96cc3fab0 ] When rds_send_xmit() picks the next message off cp_send_queue it takes its own reference with rds_message_addref(). If the message then hits the never-retransmit check (RDS_MSG_FLUSH, or an RDMA op that was already retransmitted), it is moved to the local to_be_dropped list and that reference is dropped after the batch. However, if RDS_MSG_ON_CONN has already been cleared, the message is not added to to_be_dropped and the reference taken above is never dropped: cp_xmit_rm has not been set at this point, so the loop simply abandons rm and the rds_message (and everything it pins: pages, MRs, notifiers) leaks after an RDMA error. The only other places that clear RDS_MSG_ON_CONN are rds_send_path_drop_acked() and rds_send_drop_to(), and both can run while rds_send_xmit() has dropped cp_lock between moving the message to cp_retrans and re-taking the lock in the never-retransmit check: rds_send_path_drop_acked() can ack away a message that already sat on cp_retrans - the RDS_MSG_RETRANSMITTED case above - and rds_send_drop_to() runs on socket close. Both unlink the message under cp_lock and put their own reference, leaving the xmit-path reference stranded. Drop the reference directly in that case. This mirrors Oracle UEK commit "net/rds: fix rds_message memleak in rds_send_xmit". Signed-off-by: Gerd Rausch Signed-off-by: Sharath Srinivasan [achender: port to net-next; update commit message, checkpatch nits] Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260730041629.3512480-4-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f206cfe95a286ff2174874ecbedf30d60ff15d49 Author: Håkon Bugge Date: Wed Jul 29 21:16:27 2026 -0700 net/rds: hold the socket while an rds_mr references it [ Upstream commit 9079adef042c1e7a6141dcdfd3041acd30607297 ] Each rds_mr stores a bare back pointer to the socket that created it (mr->r_sock) but takes no reference on it. When the mr is destroyed it references the rs. Hence, provisions must be made to avoid the rs being destroyed before all mrs referencing it have been destroyed. The MR itself is refcounted, and in-flight messages legitimately hold MR krefs that can outlive the socket: rds_release() drops the rb-tree references via rds_rdma_drop_keys(), but a send completion arriving afterwards drops the final message reference from the CQ handler and ends up in rds_message_purge() __rds_put_mr_final() rds_destroy_mr() -> takes rs->rs_rdma_lock dereferencing a socket that may already have been freed. Oracle UEK fixed the same use-after-free ("rds: Add proper refcnt when an RDS MR references an RDS Socket") after seeing crashes of the form: PF: supervisor write access in kernel mode _raw_spin_lock_irqsave+0x4a/0x6a __rds_put_mr_final+0x2c/0xe0 [rds] rds_message_purge+0x13c/0x150 [rds] rds_message_put+0x39/0x54 [rds] rds_ib_send_cqe_handler+0x147/0x3dd [rds_rdma] To fix this, take a socket reference when an MR is created and drop it when the final MR kref goes away. The reference cycle is broken by rds_release(), which always runs rds_rdma_drop_keys() on close. So the socket reference held by an MR never prevents release, it only delays sk_free() until the last MR user is done. The hold sits next to kref_init() at both allocation sites - __rds_rdma_map() and the on-demand-paging path in rds_cmsg_rdma_args() - so every MR owns exactly one socket reference from the moment it becomes kref-managed. For that to work on the ODP path, its get_mr() error handling is converted from a bare kfree() to kref_put(..., __rds_put_mr_final), with r_trans_private cleared first since it holds an ERR_PTR there; both sites then tear down through the same path and a future error-path change cannot silently leak or double-drop the reference. Signed-off-by: Håkon Bugge [achender: port to net-next (sock_hold/sock_put in place of the UEK rds_sock_addref/rds_sock_put helpers); also balance the reference on the rds_cmsg_rdma_args() ODP path and unify its error path with __rds_put_mr_final(); update commit message] Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260730041629.3512480-3-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ad1afbc5af35c807a444bfaedfd726e3dcf7d832 Author: Allison Henderson Date: Wed Jul 29 21:16:26 2026 -0700 net/rds: don't use unpin_user_pages_dirty_lock() from atomic context [ Upstream commit d100966325f782aa7775e5f0e8fb04f66f56308e ] rds_rdma_free_op() and rds_atomic_free_op() are reached from the IB send completion path via rds_ib_tasklet_fn_send() rds_ib_send_cqe_handler() rds_message_put() rds_message_purge() rds_rdma_free_op() / rds_atomic_free_op() which runs in tasklet (softirq) context. Both functions unpin the user pages of the op with unpin_user_pages_dirty_lock(), which uses set_page_dirty_lock() and thus may take the folio lock and sleep. Sleeping in softirq context is not allowed and can deadlock or crash. Dirtying the pages with the non-sleeping set_page_dirty() instead would just trade one bug for another, as pointed out during review: the pinned range can be file-backed. rds_pin_pages() pins with FOLL_LONGTERM, which refuses fs-dax but takes the page-cache pages of a MAP_SHARED file mapping just fine, and RDS does not restrict what memory the caller registers as an RDMA destination. For a file-backed page, set_page_dirty() from a tasklet can take non-irq-safe filesystem locks (e.g. mapping->i_private_lock and inode->i_lock in block_dirty_folio()) and deadlock against the task it interrupted. Without the folio lock, it races with truncation clearing folio->mapping, which is the race set_page_dirty_lock() exists to close. The pre-pin_user_pages() version of this code dirtied pages that way from the tasklet, so that bug is older than the sleeping unpin. The page dirtying therefore has to move to process context, not merely avoid the folio lock. When the final rds_message_put() runs in atomic context, rds_rdma_free_op() and rds_atomic_free_op() now leave the op's pages pinned and flag the op. Later, rds_message_put() hands the message to a work item that unpins the flagged ops' pages and frees the message from process context. Here, unpin_user_pages_dirty_lock() is safe outside the atomic context. Everything else keeps running in the caller's context exactly as before: the rest of the purge - the zerocopy completion, the socket put and the MR reference drops - as well as RDMA writes, whose pages the remote side only reads and which unpin without dirtying, everything on rds_tcp, and final puts that already happen in process context (socket close, connection teardown). Deferring only the unpin means the work item touches nothing but the pinned pages and the rds module's own memory: it cannot call back into a transport module, so it changes nothing about the transports' shutdown and unload ordering. rds_exit() drains any pending unpin work via destroy_workqueue(rds_wq) before the module goes away. The Oracle UEK kernel avoids the sleeping unpin by calling set_page_dirty() directly from the tasklet, which is subject to the file-backed page problem above, so this deliberately does not follow UEK here. Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260730041629.3512480-2-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ae972bfac391f73173ac6960e989c9a2f6653930 Author: Wahid Khan Date: Mon Jul 20 23:26:56 2026 +0530 HID: intel-ish-hid: ignore post-init ENUM_DEVICES from firmware [ Upstream commit f3f3f6df05226dfa220c4e603310dae94595060a ] Some ISH firmware versions (observed on Tiger Lake LP, 8086:a0fc, GUID {33AECD58-B679-4E54-9BD9-A04D34F0C226}) periodically re-send an unsolicited HOSTIF_DM_ENUM_DEVICES response roughly every 79 seconds. The current guard collapses two distinct cases into one condition: if (!(response_flag) || init_done) -> bad packet + ish_hw_reset This incorrectly treats a valid post-init firmware announcement as a corrupted packet, triggering an ISH soft-reset and a full ISHTP re-initialisation cycle on each occurrence (~1100 times per day on affected hardware). Split the check: reject messages with no response flag as before, but simply discard valid ENUM_DEVICES messages that arrive after init is complete. Signed-off-by: Wahid Khan Acked-by: Srinivas Pandruvada Tested-by: Zhang Lixu Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit df4ec4ce597d6e716bec5c25064c653fde94948f Author: Yuxiang Lin Date: Thu Jul 23 01:56:02 2026 +0800 HID: quirks: add ALWAYS_POLL quirk for AULA Mini 60 HE Pro Dongle [ Upstream commit 2884e21b18613708f050ec75330b265dd07ecc03 ] The AULA Mini 60 HE Pro wireless keyboard dongle (USB ID 0c45:fefe) becomes unresponsive after roughly one minute of idle. No error appears in dmesg; the only recovery is physically replugging the dongle. This has been reproduced across kernels 6.8, 6.14 and 7.1.3. Testing shows HID_QUIRK_ALWAYS_POLL alone resolves the issue, verified via usbhid.quirks=0x0c45:0xfefe:0x400. Signed-off-by: Yuxiang Lin Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 486cc1ceb69685639828a4604926af1f128332a5 Author: Aaron Ma Date: Mon Aug 3 13:39:32 2026 +0800 HID: quirks: Add ALWAYS_POLL quirk for Beitong BTP-KP20D dongle [ Upstream commit bfff246b3a31cb45ec297ca5e2a77c1410b207ac ] The BTP-KP20D dongle in Direct/HID mode (20dd:5159) re-enumerates every few seconds because usbhid never submits its interrupt-IN URB: no HID driver binds to the vendor-specific report descriptor, so the device is never opened, and the firmware treats the idle endpoint as a lost link. Add HID_QUIRK_ALWAYS_POLL to keep the interrupt-IN URB submitted from probe time. Signed-off-by: Aaron Ma Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 1996e79ecbc73b2b4fdf0b9bc433ba2993982a5e Author: Stuart Hayhurst Date: Tue Jul 21 18:12:48 2026 +0100 HID: logitech-hidpp: Add support for G502 X Plus USB mouse [ Upstream commit 6f4b44abe4ccdcfdab75c9493b8c7634fee37133 ] The wireless dongle is already supported, this adds detection for the mouse in wired mode. Supports battery reporting. Signed-off-by: Stuart Hayhurst Reviewed-by: Bastien Nocera Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit ff46bc4a9cffb1df68acc3a0cce8c1080c96fb19 Author: Mauricio Orozco Date: Wed Jul 29 22:34:55 2026 -0500 ALSA: hda/realtek: Add quirk for ASUS VivoBook M515DA/X515DAP [ Upstream commit a9fa2a016e805504223abf8c9b373ac9f7bfb9b3 ] The ASUS VivoBook M515DA/X515DAP (subsystem ID 1043:1e3e) requires the ALC256_FIXUP_ASUS_MIC_NO_PRESENCE fixup to enable the internal microphone. Without this quirk, the internal microphone captures only silence under Linux, while it works correctly under Windows. The fix has been verified on real hardware. Tested on an ASUS VivoBook M515DA/X515DAP running Linux Mint 22.3 with Ubuntu HWE kernel 7.0.0-28. Signed-off-by: Mauricio Orozco Link: https://patch.msgid.link/20260730033506.8958-1-mauoro3@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7cb26fc31cde58ddf756f0ad252e2cdf45cf9ebb Author: Mariano Baragiola Date: Tue Jul 28 16:26:10 2026 -0300 wifi: wilc1000: validate monitor transmit frame headers [ Upstream commit 9d96e037ff90a2fc81a841b2002d500a5a4a5351 ] wilc_wfi_mon_xmit() reads the radiotap length before ensuring that the fixed header is present. After stripping that header, it reads the frame type and all three 802.11 addresses without checking how much frame data remains. A truncated monitor injection can therefore cause out-of-bounds reads. Validate the radiotap header first, use the common 802.11 helper to check the variable header length, and require a complete three-address header before using the addresses. This covers QoS and four-address data headers while rejecting short control headers that this path cannot classify. Signed-off-by: Mariano Baragiola Link: https://patch.msgid.link/20260728192610.2236361-1-mbaragiola@linux.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 192cdd4b45dc988bf2395720c94a7feff685315f Author: Can Peng Date: Thu Jul 23 13:56:17 2026 +0800 wifi: brcmfmac: validate msgbuf flowring IDs before use [ Upstream commit 32856f39fefdc75bd253cab999f996750628648e ] Firmware messages carry flow_ring_id values which brcmfmac converts to an internal flowid by subtracting BRCMF_H2D_MSGRING_FLOWRING_IDSTART. The resulting value is used as a bit index in txstatus_done_map and as an array index into msgbuf->flowrings and the flowring state. Validate the firmware supplied flow_ring_id before using it. This prevents flow_ring_id values below BRCMF_H2D_MSGRING_FLOWRING_IDSTART from underflowing and rejects values outside msgbuf->max_flowrings. In the tx status path, complete the packet with an error after removing a valid packet id so the skb is not leaked when the flow ring id is invalid. Signed-off-by: Can Peng Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260723055618.550834-1-pengcan@kylinos.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1b6a7156d291d468abb7847f9f83cd7f78e73360 Author: Can Peng Date: Fri Jul 24 17:25:30 2026 +0800 wifi: brcmfmac: Set DMA direction for msgbuf packet IDs [ Upstream commit f0ba5fd51ff23077ce66cb9be79d41a4b7c19c5e ] brcmf_msgbuf_init_pktids() takes the DMA direction from its callers, but never stores it in the packet ID state. Since the state is zeroed, pktids->direction remains DMA_BIDIRECTIONAL for both the TX and RX packet ID pools. All msgbuf packet ID map and unmap paths use pktids->direction. As a result, TX buffers requested with DMA_TO_DEVICE and RX buffers requested with DMA_FROM_DEVICE are mapped and unmapped as DMA_BIDIRECTIONAL instead. Store the caller-provided direction when initializing the packet ID state. Signed-off-by: Can Peng Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260724092530.674624-1-pengcan@kylinos.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit eca9cd4d59b0b689013023f48a3de505d43beebe Author: Felix Fietkau Date: Sat Aug 1 14:53:29 2026 +0000 wifi: mt76: mt7603: fix U-APSD service period termination [ Upstream commit 697badc27a9b3b2a8d86092abeed767714f735a2 ] Frames released from the driver PS queue were all tagged with MORE_DATA and none of them ever carried the EOSP bit, so from the client's point of view a U-APSD service period was started but never finished. Clients that keep their receiver on until EOSP arrives stop sending trigger frames, and all downlink traffic for that station stalls until they give up. ieee80211_sta_eosp() only cleared the service period state inside mac80211, which is why the mismatch went unnoticed. Assign MORE_DATA per frame and set the wire EOSP bit on the last one. If the last released frame is a bufferable MMPDU it has no QoS control field to carry EOSP, so let mac80211 append a QoS-Null frame instead. Also stop handing the remaining frame budget to mt76_release_buffered_frames() once frames have been released from the PS queue: both would signal the end of the same service period. Releasing fewer frames than requested is allowed, and MORE_DATA tells the client to trigger again. Link: https://patch.msgid.link/20260801145334.1166751-5-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit aea3309d634702eddd2cd1c38ada3a1fa700d4a9 Author: Felix Fietkau Date: Sat Aug 1 14:53:28 2026 +0000 wifi: mt76: set the EOSP bit in the QoS header of the last released frame [ Upstream commit 0b8d2524716099ea4743fa65bc364f94b3106a31 ] When the driver implements .release_buffered_frames, mac80211 leaves the U-APSD signalling entirely to the driver: "In this case it is also responsible for setting the EOSP flag in the QoS header of the frames" (include/net/mac80211.h). Only IEEE80211_TX_STATUS_EOSP was being set, which merely ends the service period inside mac80211, so on air the service period was never terminated. Clients that wait for EOSP before going back to doze keep the SP open and stop triggering, which stalls all downlink traffic for that station. Set the wire EOSP bit on the last frame of a U-APSD service period. EOSP has no meaning for a PS-Poll response, so pass the release reason down and leave those frames alone. Link: https://patch.msgid.link/20260801145334.1166751-4-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e95dd433ea5bfd30f9c96010e89b8af34800cb67 Author: Felix Fietkau Date: Fri Jul 24 12:48:07 2026 +0000 wifi: mt76: mt7615: fix NULL deref in mt7615_mac_set_rates [ Upstream commit 98aff74779da9f417386c589c36848e9c568f0f9 ] mt7615_tx() falls back to the vif BSS wcid when mac80211 hands a frame over without a station, e.g. while a station is being torn down, and to the global wcid when there is no vif either. Both tx_prepare_skb implementations derive a mt7615_sta from that wcid unconditionally and, if the rate control probe flag is set, pass it to mt7615_mac_set_rates(), which dereferences the NULL vif backpointer of the per-vif embedded sta: Unable to handle kernel read from unreadable memory at virtual address 0000000000000002 ... pc : mt7615_mac_set_rates lr : mt7615_tx_prepare_skb Neither entry is rate controlled by mac80211: the embedded sta has an empty rate set, and for the global wcid the container_of does not yield a valid mt7615_sta at all. Only resolve the sta for wcids that belong to a station. Reported-by: Chad Monroe Link: https://patch.msgid.link/20260724124813.3961474-23-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2057f2540d621f05fbd1907bbc8061adcfaa2621 Author: Peter Ujfalusi Date: Thu Jul 30 15:28:57 2026 +0300 ASoC: SOF: Intel: mtl: Power down DSP if it is left enabled in pre_fw_run() [ Upstream commit 31fd7a0bbfa4b7e8aff11f278e817664c6a5f68b ] It is expected that the DSP is in power down state when the firmware boot is attempted. If the DSP for any reason was left powered up then the DSP boot will fail since the ROM boot sequence might not be able to run. Make sure that the DSP is off before proceeding to boot it up. Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20260730122857.5294-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 80d00f8024fff9c562c9e4bbc9ad0e70566b25a2 Author: ZhaoJinming Date: Wed Jul 29 10:00:05 2026 +0800 wifi: ath11k: fix resource leak on error in ext IRQ setup [ Upstream commit 8ab38bbac02298e3fb03008ed4a0227485c0fd62 ] In ath11k_ahb_config_irq(), when a CE request_irq() fails, the function returns the error immediately without freeing the CE IRQs that were successfully registered in previous loop iterations. The probe error path does not call ath11k_ahb_free_irq() either, so the previously registered CE IRQ handlers remain attached to the interrupt lines and are never released. In ath11k_ahb_config_ext_irq(), when an external request_irq() fails, the error is only logged and the loop continues. The function then returns 0 indicating success, leaving the device in a partially configured state where some external IRQs are not registered. This causes enable_irq()/disable_irq()/free_irq() to be called on unregistered IRQs during runtime and remove/shutdown, triggering WARN_ON(!desc->action), and missing interrupt handlers lead to data loss. Additionally, if alloc_netdev_dummy() fails for a later IRQ group, the function returns -ENOMEM without freeing the ext IRQs and napi_ndev that were successfully set up for earlier groups. Fix all three issues: propagate the error up to the caller and unwind all successfully registered IRQs and allocated resources on failure. Also move ab->irq_num[irq_idx] assignment after request_irq() succeeds in the ext IRQ path to match the CE IRQ path and avoid storing a stale IRQ number on failure. Signed-off-by: ZhaoJinming Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260729020005.219253-1-zhaojinming@uniontech.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5ee03c7eea5d4eb86211cfeec3025337fef6375e Author: Geetha sowjanya Date: Mon Jun 1 13:03:18 2026 +0530 perf: marvell: Cancel CN10K DDR PMU hrtimer on device remove [ Upstream commit 7dbcb0268d1e2a1d3badb0c6e77ee70e550b1787 ] cn10k_ddr_perf_remove() did not cancel the poll hrtimer before returning. If the device was unbound while perf events were still active the timer callback could run post-free. To fix the issue by adding hrtimer_cancel() in remove(). Signed-off-by: Geetha sowjanya Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 3aafe3f22d17ddd3d19ab769c371ab276a5d2e77 Author: Pablo Neira Ayuso Date: Tue Jul 28 10:40:06 2026 +0200 netfilter: nf_tables: call skb_valid_dst() before skb_dst() [ Upstream commit 689db98e535bf8efb5bc9c36f4fd3de3bd715eb6 ] When fetching the dst_entry from the skb, check if it valid, ie. this is not a template dst, for extensions that can be used from the netdev ingress and egress chains. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 4d39a039d0b7737f8475c2431f18572b3b186a3b Author: Minghao Zhang Date: Wed Jul 29 15:46:52 2026 +0000 netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets [ Upstream commit bf80e6802273a900311b44e47c9b1a59c6d2473c ] Commit be0502a3f2e9 ("netfilter: conntrack: tcp: only close if RST matches exact sequence") keeps an established conntrack entry in ESTABLISHED when an in-window RST does not match the expected sequence number exactly, so the endpoint can validate the RST with a challenge ACK. The timeout selection nevertheless uses the CLOSE timeout for every RST packet. The bug is that timeout selection is based on the packet type, not on the state transition result: even when RST validation keeps new_state in ESTABLISHED, the timeout is still forced to TCP_CONNTRACK_CLOSE. Linux TCP independently rate limits challenge ACKs per socket. A second non-exact RST can therefore arrive after the first challenge ACK has restored the timeout but before the rate limit expires. The second RST lowers the timeout to 10 seconds again while the endpoint suppresses the second challenge ACK, allowing the conntrack entry to expire while both TCP endpoints remain established. Using the ESTABLISHED timeout for such RSTs would avoid this short expiration window, but it could also retain stale entries for the five-day default because conntrack cannot reliably match the endpoint's exact TCP state. Use the UNACK timeout for RST packets that leave the conntrack entry in TCP_CONNTRACK_ESTABLISHED. Exact-match RSTs and accepted RST packet trains still fall through to timeouts[new_state], which preserves the CLOSE timeout when conntrack accepts the RST as closing the flow. This avoids the aggressive 10-second expiration window for non-exact RSTs while preserving the short timeout for RSTs that conntrack accepts as closing the flow. Suggested-by: Florian Westphal Reported-by: Minghao Zhang Reported-by: Jianjun Chen Signed-off-by: Minghao Zhang Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit da96e10577bc2f96d36b687aac0e5084d66abf32 Author: Ahmed Naseef Date: Sun Jul 19 12:25:30 2026 +0400 wifi: mt76: mt7603: add 0x7592 EEPROM chip ID [ Upstream commit d16447d7470502e998d82e806ca7ed49d1baa853 ] Some EcoNet based routers ship an on-flash EEPROM whose chip-id is 0x7592 instead of the expected 0x7603. The device probes as PCI 14c3:7603 and the hardware MT_HW_CHIPID register reports 0x7603, independent of the EEPROM value. This is seen across multiple EcoNet EN751221 and EN7528 based devices (for example the Genexis Platinum 4410). Signed-off-by: Ahmed Naseef Link: https://patch.msgid.link/20260719082530.3879831-1-naseefkm@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a3e7517abea1bc0dc019bcc05331293a981e5ac9 Author: Prashant Rahul Date: Thu Jul 16 21:55:10 2026 +0530 wifi: mt76: mt7921: fix memory leak when skb_linearize fails in mcu rx event [ Upstream commit 4361f1660101270611eb5dc39799f620b35f2e4d ] The ownership of sk_buff skb is passed to mt7921_queue_rx_skb, each path inside it under the switch case handles cleaning of skb and it is true for mt7921_mcu_rx_event as well. mt7921_mcu_rx_event, on a success path, either queues skb via mt76_mcu_rx_event or cleans it immediately inside mt7921_mcu_uni_rx_unsolicited_event. However inside mt7921_mcu_rx_event, if skb_linearize fails, the function returns immediately and never bothers cleaning skb which leaks skb. Since skb is fully owned at this point, it is safe to call dev_kfree_skb which fixes the leak. Granted, the skb_linearize failure is rare as it can only fail under heavy memory usage, but at the same time, leaking memory under heavy memory usage can worsen the OOM condition. Signed-off-by: Prashant Rahul Link: https://patch.msgid.link/20260716-mt7921-mem-leak-v1-1-6e9c0ea19f63@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 496e06f1a4e6c5c3883f822b8f645c91431394d4 Author: David Bauer Date: Sat May 16 16:49:42 2026 +0200 wifi: mt76: mt7915: configure noise floor reporting on reset [ Upstream commit a92cd5dd792a63a5d8a72142835382d4edbe9933 ] When performing a full system recovery of the MCU on a dual-phy platform, band 0 (usually 2.4GHz) stops reading correct noise floor data. This is due to noise floor reporting only being configured correctly for the second device PHY. Configure the respective registers correctly after restarting the MCU firmware to fix reported noise-floor values. Signed-off-by: David Bauer Link: https://patch.msgid.link/20260516144944.2574053-1-mail@david-bauer.net Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 12ffcc552ce46e2ddf72241365481b43929509ae Author: Devin Wittmayer Date: Fri Jun 12 17:25:44 2026 -0700 wifi: mt76: mt76x02: report rx FCS errors to mac80211 [ Upstream commit ddae0bcb01e71c1184bb3f526f9622e31dc38f3b ] When the fcsfail filter is enabled the hardware passes frames with a bad FCS up to the driver, but mt76x02_mac_process_rx() never checks MT_RXINFO_CRCERR and hands them to mac80211 without RX_FLAG_FAILED_FCS_CRC. In monitor mode the radiotap flags byte then never gets IEEE80211_RADIOTAP_F_BADFCS set and corrupted frames cannot be told apart from clean ones. Set RX_FLAG_FAILED_FCS_CRC from the descriptor CRC error bit, matching mt7603, mt7615, mt7915, mt7921, mt7925 and mt7996. Reported-by: 0072a70 <90307219+0072a70@users.noreply.github.com> Closes: https://github.com/morrownr/mt76/issues/38 Tested-by: 0072a70 <90307219+0072a70@users.noreply.github.com> Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260613002544.27750-3-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 97c5a29cbaaabfefe839f0b0c75336abc228c962 Author: David Bauer Date: Thu Jun 11 23:56:56 2026 +0200 wifi: mt76: mt7603: free beacon SKB on error [ Upstream commit 965cbdbdfbd37a659a05ff88e49c216975bd9d2e ] The SKB containing the generated beacon is not freed when the beacon queue is deected stuck and scheduled for recovery. Fixes potential memory leaks in case the beacon queue is detected stuck. Signed-off-by: David Bauer Link: https://patch.msgid.link/20260611215658.259324-1-mail@david-bauer.net Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 8553f4d9c06b31ee0aaae6b8050a8c8754365c56 Author: Hari Mishal Date: Fri Jul 17 17:06:22 2026 +0200 virtio_console: take a kref in find_port_by_vq() to fix port UAF [ Upstream commit 18dd0b4e489e4f0e3b748cf36ccb909c75a3efab ] find_port_by_vq() returns a raw struct port pointer without taking a reference on it, unlike find_port_by_devt_in_portdev() which does. find_port_by_vq()'s only two callers, in_intr() and out_intr(), run as virtqueue interrupt callbacks, entirely independent of and possibly concurrently with unplug_port(), which itself runs from a workqueue when the host sends a VIRTIO_CONSOLE_PORT_REMOVE control message. unplug_port() removes the port from portdev->ports under ports_lock, then later drops its last reference with kref_put(), freeing it via remove_port(). find_port_by_vq() also walks portdev->ports under ports_lock, so if it finds the port still on the list, the list removal, and therefore the eventual kref_put(), has not happened yet, and taking a reference at that point is always safe. Without doing so, in_intr()/out_intr() can be left holding a pointer to a port that unplug_port() frees on another core before they are done using it. Both triggers are host-controlled as the host decides when to send the PORT_REMOVE control message and when to kick the port's data vq. So a malicious backend could race the two on purpose, without any guest side cooperation. The freed object is a generic kmalloc allocation containing a wait_queue_head_t, which in_intr()/out_intr() pass to wake_up_interruptible() after touching the stale pointer. wake_up_interruptible() invokes a function pointer read out of the wait queue's entries. If the freed slab slot is reclaimed with attacker influenced content before that call, then this is an arbitrary function call primitive rather than just undefined behaviour. Take a reference in find_port_by_vq() while still holding ports_lock, matching find_port_by_devt_in_portdev(), and release it in in_intr() and out_intr() once they are done with the port. Signed-off-by: Hari Mishal Link: https://patch.msgid.link/20260717150622.23636-1-harimishal1@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7d5b6da4dd7bc5e144dc06237146c0d165b3dffd Author: Rosen Penev Date: Wed Jul 29 10:46:46 2026 +0100 nvmem: brcm_nvram: fix out-of-bounds access on malformed flash data [ Upstream commit a67e2c323a47a2254ed3472b5e4c53abac20f116 ] The length check in brcm_nvram_parse() validated header->len against priv->nvmem_size (the full partition size) instead of priv->data_len (the actual allocated data buffer). A malformed flash partition with header->len between the two would pass the check, causing brcm_nvram_add_cells() to read and write priv->data[len - 1] beyond the heap allocation. Also add a minimum bound: len < sizeof(*header) could underflow the data[len - 1] access. Fix both bounds by rejecting len outside [sizeof(*header), priv->data_len]. Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260729094647.111468-14-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2a4339c56851c5ee1636fc01a989fe0d8968548c Author: Rosen Penev Date: Wed Jul 29 10:46:45 2026 +0100 nvmem: brcm_nvram: reject empty NVRAM partition [ Upstream commit fde46579cf8872138b296349c2bd8a3cd3f132e2 ] If the partition is completely erased (all padding bytes), the trimming loop reduces data_len to 0. devm_kzalloc(dev, 0, GFP_KERNEL) returns ZERO_SIZE_PTR ((void *)16), which is non-NULL and bypasses the NULL check. The subsequent cast of priv->data to struct brcm_nvram_header * and dereference of header->magic causes a page fault on address 0x10. Reject data_len smaller than the header before allocating. Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260729094647.111468-13-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 42cab89fa9e20889174d73b6e5eb824366b51af5 Author: 이상호 Date: Thu Jul 2 07:07:29 2026 +0900 romfs: detect hard link cycles [ Upstream commit d30b5a954e0a4dcc16bba9c310c13709a6169a52 ] romfs_iget() follows on-disk hard link entries until it reaches a non-hard link inode: pos = be32_to_cpu(ri.spec) & ROMFH_MASK; The target position is image-controlled, and the loop does not detect cycles. A crafted romfs image can make the root inode a hard link. The hard link can point back to itself and leave mount(2) spinning in the kernel. Reject excessive hard link indirection with -ELOOP. Normal romfs images do not need long hard link chains. This bounds corrupted-image traversal. Propagate romfs_iget() errors from lookup because hard link traversal can now fail with -ELOOP. Signed-off-by: 이상호 Link: https://patch.msgid.link/20260701220729.822112-1-kudo3228@gmail.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit ffbc5f103030e5c495389223a44bc4b2ee2564bf Author: bui duc phuc Date: Wed Jul 29 17:00:18 2026 +0700 regulator: rt6245: Restore state on enable failure [ Upstream commit e95a0a309ca02bf26dc937cdeb3fe2a235c65f63 ] Currently, if regcache_sync() fails after the enable GPIO has been asserted, the driver returns with enable_gpio still set high and regcache_cache_only() left disabled. This leaves the device state inconsistent with the disabled state, where the enable GPIO is low and cache_only is enabled. On failure, restore the original state by setting cache_only back to true and driving the enable GPIO low before returning the error. Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260729100018.66577-1-phucduc.bui@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8826e7b53916744535b845024fe4d0fe94f953a1 Author: Oleg Proshkin Date: Thu Jun 11 18:46:29 2026 +0300 mfd: axp20x: Preserve other control bits when powering off [ Upstream commit 3756bf05c963563f1325af105356541882dd5899 ] axp20x_power_off() triggers shutdown by writing AXP20X_OFF (BIT(7)) to the power-off control register with regmap_write(), which rewrites the whole register and clears other control bits in it. On the AXP221/AXP223 (and the register-compatible AXP228) - that register also holds the CHGLED auto-control bit. Clearing it during an orderly shutdown disables the hardware charge indicator, so the charge LED stays dark while the board is powered off and charging. Other variants keep unrelated configuration in the same register too. Set only the power-off bit with regmap_set_bits() and leave the rest of the register untouched. The shutdown register is readable on every variant, so the read-modify-write should be safe. Tested on a ClockworkPi uConsole (Raspberry Pi Compute Module 4, AXP228, which enumerates as AXP221): register AXP20X_OFF_CTRL reads 0x08 at runtime, so the old code left it 0x80 whereas setting only BIT(7) leaves 0x88. Writing 0x88 at power-off enables the charge LED while still powering off the PMIC. Signed-off-by: Oleg Proshkin Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260611154629.76607-1-oleg.pro171@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 90df913cb65dcd1e6431ff5767bb4308fb651bd5 Author: Bob Song Date: Thu Jul 30 09:53:01 2026 +0800 ALSA: hda/realtek: add missing error checks for COEF index reads in alc269 [ Upstream commit 5b106b40ed22098f2bc049efb645148d038444bd ] alc_read_coef_idx() and alc_read_coefex_idx() can return -1 on error via snd_hda_codec_read(). Several codec initialization and shutdown functions save these return values and later write them back to hardware registers without checking for errors, potentially corrupting COEF register state on a read failure. Add error checks in: - alc282_init() and alc282_shutup(): check coef78 before write-back - alc285_hp_init(): check coef38/coef0d/coef36 before update, check val before write-back, and break polling loop on error - alc294_hp_init(): break polling loop on read error Signed-off-by: Bob Song Link: https://patch.msgid.link/20260730015302.253008-1-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e491a8021969c3fe23d215ae8905231173fb1bb6 Author: Dmitry Torokhov Date: Wed Jun 10 16:03:52 2026 -0700 mfd: ipaq-micro: Fix out-of-bounds stack read in ipaq_micro_str [ Upstream commit da3a98c941753255418616d249e5b40db0927c26 ] ipaq_micro_str() decodes a UTF-16LE string into an ASCII string. It copies characters to a stack buffer retstr, but fails to null-terminate it. When kstrdup() is called on retstr, it can read past the buffer into uninitialized stack memory, potentially leaking stack contents. Fix this by initializing retstr to zero. Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov Link: https://patch.msgid.link/aintJF4X5tWDW-Ej@google.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 13a304e62b4bce20b9dc33d64376a32a2209203e Author: Konstantin Komarov Date: Thu Jul 30 10:42:58 2026 +0200 fs/ntfs3: Fix memory leak in indx_find_sort() [ Upstream commit 194491be54e1c9e4d29d3ee777b05ff031c4b670 ] When popping a level from the index lookup stack, indx_find_sort() frees the struct indx_node but not the index buffer it owns. Every call that descends and then pops a level leaks that allocation. Free n->index before freeing the node itself. Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 43cb985a4e4a206b1e9b1d494d6169a52b46493c Author: Bob Song Date: Thu Jul 30 09:53:02 2026 +0800 ALSA: hda/realtek: add missing NULL check for codec->bus->pci [ Upstream commit 3b36ac93739e7b119a30affaee9c2dd41f24efbb ] In alc269_probe(), codec->bus->pci is dereferenced without a NULL check for the ALC236 vendor ID case. Add the missing check, consistent with the existing pattern used elsewhere in the same function. Signed-off-by: Bob Song Link: https://patch.msgid.link/20260730015302.253008-2-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c7302757ee9ed286dfefa03b952812cf4e27d2ff Author: Yichong Chen Date: Tue Jul 28 12:29:23 2026 +0800 exfat: free new directory cluster if zeroing fails [ Upstream commit ce12a39bed483008683438962b3a605374e6f803 ] exfat_alloc_new_dir() allocates a cluster for a new directory before zeroing it. If exfat_zeroed_cluster() fails, the function returns the error but leaves the allocated cluster in use. Free the newly allocated cluster before returning the zeroing error. Signed-off-by: Yichong Chen Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 7f30c0bb37390a5069fa829491c07d14d136f22c Author: Armin Wolf Date: Mon Jul 20 15:19:19 2026 +0200 platform/x86: dell-smbios-wmi: Fix chardev resource management [ Upstream commit 41427211f663c6eb36986ca2ea68d7e87aac52e9 ] When unbinding the WMI driver while a userspace application has an open file descriptor for the character device, a UAF occurs: KASAN: slab-use-after-free in _copy_to_user from platform/x86/dell-smbios-wmi The reason for this is that even after calling misc_deregister(), userspace appications can still call read() and/or ioctl() on open file descriptors associated with the already unregistered character device. This causes a UAF by attempting to access the already freed state container of the WMI driver. Fix this by no longer storing the state container inside filp->private_data. Instead retrieve the state container using get_first_smbios_priv() and return -ENODEV if the state container does not exist anymore. Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/platform-driver-x86/178144969601.60470.13396800403157907003@gmail.com/ Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260720131921.368000-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 4db4ac0277b6047f52319f662b87728e9c8e6166 Author: wangdicheng Date: Wed Jul 29 15:09:35 2026 +0800 ALSA: hda/conexant: Add NULL check for dc_mode_path [ Upstream commit 273806f38ce95c95c288a03d3de1e423cd3e5543 ] snd_hda_add_new_path() returns NULL when no path exists between the given NIDs, but olpc_xo_update_mic_pins() passes dc_mode_path straight to snd_hda_activate_path() which dereferences it without checking. Add the missing NULL guards, same as the local path variable already has in the same function. Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260729070935.548050-2-wangdich9700@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 92f2096df01891e10e3ab1edd93cbf61d7e4c506 Author: Yichong Chen Date: Wed Jul 29 10:25:43 2026 +0800 exfat: clean up new entry on add entry failure [ Upstream commit 0901a71e8cff5c60dd464529cba2ed30a2ab0a3f ] exfat_add_entry() initializes a new directory entry set before writing it with exfat_put_dentry_set(). If the write fails, mkdir/create returns an error but a partially written entry may be left behind. For non-zero-size directories, the failure also happens after a cluster has been allocated for the new directory. Clean up the new entry best-effort, and free the newly allocated directory cluster only when the cleanup writeback succeeds. This avoids freeing a cluster that may still be referenced by an on-disk entry if the cleanup fails. Signed-off-by: Yichong Chen Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit c8f5a6b274ed76443ee2d81068212e09cea1c770 Author: David Strahan Date: Wed Jul 22 17:04:00 2026 -0500 scsi: smartpqi: Add new PCI device-ids [ Upstream commit 1a220e6e87a31c2572cd07ff47023e5cd92ac80f ] All PCI ID entries in Hex. Add PCI IDs for Hurray Data controllers: VID / DID / SVID / SDID ---- ---- ---- ---- 9005 / 028f / 207d / 4246 9005 / 028f / 207d / 4256 9005 / 028f / 207d / 4356 9005 / 028f / 207d / 4940 9005 / 028f / 207d / 4a46 Add PCI IDs for ZTE controllers: VID / DID / SVID / SDID ---- ---- ---- ---- 9005 / 028f / 1cf2 / 5451 9005 / 028f / 1cf2 / 5452 9005 / 028f / 1cf2 / 5453 Add PCI ID for Ramaxel controller: VID / DID / SVID / SDID ---- ---- ---- ---- 9005 / 028f / 1f3f / 0670 Signed-off-by: David Strahan Reviewed-by: Don Brace Link: https://lore.kernel.org/linux-scsi/20260722220401.6357-1-david.strahan@microchip.com/ Link: https://patch.msgid.link/20260722220401.6357-4-david.strahan@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a3aa50d53e38c71e4479db1d103d64a964a601bd Author: Gary Guo Date: Thu Jul 23 23:00:40 2026 +0100 ata: ata_generic: Don't store pci_device_id [ Upstream commit 4f3075f629077a8cb3d3455c794a1f4a8fc8b43e ] pci_device_id is not guaranteed to live longer than probe due to presence of dynamic ID. All information apart from driver_data can be easily retrieved from pci_dev, so just store driver_data. Signed-off-by: Gary Guo Signed-off-by: Bjorn Helgaas Reviewed-by: Danilo Krummrich Acked-by: Damien Le Moal Link: https://patch.msgid.link/20260723-pci_id_fix-v4-1-3580726844e1@garyguo.net Signed-off-by: Sasha Levin commit 1f30f876bce870d77d018ba60cf41422abaa1fb4 Author: Dmitry Osipenko Date: Thu Jun 25 11:30:52 2026 +0300 clk: tegra: support 48MHz clock for pll_p_out1 [ Upstream commit 46e31d69a547530fbef499bde888b6bb45a1deac ] UEFI on Surface2 sets pll_p_out1 to 48MHz which is not supported by kernel and causes BUG() early on. Add 48MHz clock support for pll_p_out1. Acked-by: Thierry Reding Signed-off-by: Dmitry Osipenko Signed-off-by: Jonas Schwöbel Signed-off-by: Svyatoslav Ryhel Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 81005ac54ffc025ba1514f20f4572ad36453d52e Author: Chen Changcheng Date: Fri Jul 24 10:52:18 2026 +0800 media: cx88: fix memory leak in cx8802_register_driver() error path [ Upstream commit e228b8b1a5b47a72b265671dc6d864c0da5528d0 ] In cx8802_register_driver(), when drv->probe(driver) fails (non-zero), the allocated cx8802_driver struct is freed neither in the else branch nor later in cx8802_unregister_driver() (which only frees entries that were added to dev->drvlist on success). Each failed probe leaks the driver struct. Add kfree(driver) in the else branch to fix the leak. Signed-off-by: Chen Changcheng Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f3f56fb196c767c15058883645a5364dcfdbe03e Author: Pengpeng Hou Date: Sat Jul 4 23:01:41 2026 +0800 clk: imx: imx8qxp-lpcg: add missing MODULE_DEVICE_TABLE() [ Upstream commit e89485455ac49925565061733c0d73d568333fc0 ] The driver has a match table for the of bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Reviewed-by: Frank Li Reviewed-by: Brian Masney Reviewed-by: Peng Fan Link: https://patch.msgid.link/20260704150344.59563-1-pengpeng@iscas.ac.cn Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit b613bc90d0fba87bd39caccccb4624ea994bdc46 Author: Pengpeng Hou Date: Sun Jul 5 08:17:05 2026 +0800 clk: imx: imx8qxp: add missing MODULE_DEVICE_TABLE() [ Upstream commit cd21fdcbef3fb32136f72075ab668b075423b3f6 ] The driver has a match table for the of bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Reviewed-by: Brian Masney Link: https://patch.msgid.link/20260705001705.70400-1-pengpeng@iscas.ac.cn Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 21bf85fc46948f528a30f9a2360d7750b4548045 Author: Nicolin Chen Date: Tue Jul 14 13:55:08 2026 -0700 iommu/tegra241-cmdqv: Rate-limit the error ISR's log message [ Upstream commit a86c36163c9722545d27e92bdad8418fdcaa8b1d ] tegra241_cmdqv_isr() logs the error-map registers on every error interrupt. A malfunctioning device, or a guest deliberately faulting its own VCMDQs, can raise these interrupts rapidly, and the unconditional dev_warn() then floods the kernel log. Rate-limit the message with dev_warn_ratelimited(), and pass the error-map registers straight to it so their four MMIO reads run only when the limiter prints, instead of building the string on every interrupt. Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 1d6f74a6f8dcda9ffff9cd1e23a538ad7c15cb80 Author: Yichong Chen Date: Mon Jul 27 17:12:14 2026 +0800 exfat: write moved entry before removing source [ Upstream commit 896fcc93574fd511ee04a4110e8ea59d6d8d43d7 ] exfat_move_file() removes the old directory entry before the new entry has been written. If writing the new entry fails, rename returns an error after the source entry has already been marked deleted. Write the new entry first, then remove the old entry and update the cached inode location. This keeps the source entry intact if creating the destination entry fails. Signed-off-by: Yichong Chen Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 7254c4dd420d8462ff0cff0fa73ef865b72c7642 Author: Jay Vadayath Date: Fri Jul 17 11:40:19 2026 -0700 udf: bound lengthAllocDescs from unallocated space entry [ Upstream commit b8228f59dc58aea06dc024efd8f64c2d048c4578 ] udf_read_inode() copies the on-disk lengthAllocDescs field of a USE (unallocSpaceEntry) inode into iinfo->i_lenAlloc without checking that it fits in the i_data buffer that is subsequently allocated for the inode. udf_count_free_table(), called from udf_statfs(), then walks the allocation descriptor array up to i_lenAlloc bytes, so a crafted UDF image with lengthAllocDescs larger than (blocksize - sizeof(struct unallocSpaceEntry)) causes udf_get_fileshortad() to read past the end of the kmalloc'd i_data buffer. KASAN report from mounting a crafted UDF image and calling statfs() from an unprivileged process: BUG: KASAN: slab-out-of-bounds in udf_get_fileshortad+0x126/0x130 Read of size 4 at addr ffff8880042137d8 by task poc/65 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x610 kasan_report+0xce/0x100 udf_get_fileshortad+0x126/0x130 udf_current_aext+0x3c4/0xa10 udf_next_aext+0x241/0x440 udf_statfs+0xb7d/0x11c0 statfs_by_dentry+0x117/0x1e0 user_statfs+0xac/0x130 __do_sys_statfs+0x80/0xe0 do_syscall_64+0x102/0x5a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reject USE inodes whose lengthAllocDescs would place descriptors past the end of the i_data buffer, mirroring the checks the rest of the UDF code performs on descriptor lengths. This bug was discovered by Artiphishell's vTriage pipeline, which generated a userspace reproducer that reliably triggers the KASAN report on an unpatched kernel. The fix below was drafted with the Claude coding assistant; a userspace reproducer (and the crafted UDF image) is available on request. Assisted-by: LLM Signed-off-by: Jay Vadayath Link: https://patch.msgid.link/20260717184021.13476-1-jay@artiphishell.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 1e171c16ab5e3e357e1ef83fca61d66f5d0af2a6 Author: Jan Kara Date: Mon Jul 27 13:37:12 2026 +0200 udf: Fix bh leak for unallocated space entries [ Upstream commit d95094d4c0a62ea17b8a7c6399b42381b8a55bc0 ] When processing unallocated space entries we didn't properly release the inode bh. Fix it. Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 8e51823c401ff23d55686b135c84290810809dcc Author: Tyrel Datwyler Date: Wed Jul 22 17:01:20 2026 -0700 scsi: ibmvfc: free ibmvfc_target allocations with mempool_free [ Upstream commit 99143433f7f14139ac373c553ec8e1317d0ae58a ] The ibmvfc_target *tgt structures for discovery are allocated using mempool_alloc but in turn free'd via kfree in ibmvfc_release_target breaking pool guarentees. Fixup ibmvfc_release_target to call mempool_free instead so that memory is properly returned to the mempool instead of the general allocator. Signed-off-by: Tyrel Datwyler Link: https://patch.msgid.link/20260723000149.969416-5-tyreld@linux.ibm.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d8bb5c59a8713e9ec9ea95a71336d984ff5de296 Author: Tyrel Datwyler Date: Wed Jul 22 17:01:19 2026 -0700 scsi: ibmvfc: check for NULL evt in implicit LOGO and target delete path [ Upstream commit 0122eab60b151d7815f420a91c7315944a037714 ] Unlike ibmvfc_tgt_implicit_logout the ibmvfc_tgt_implicit_logout_and_del path fails to check for a NULL evt returned from ibmvfc_get_reserved_event and passes that directly to ibmvfc_send_event which will unconditionally derefence the evt. Check for a NULL evt and perform same escalation as ibmvfc_implicit_logout. Signed-off-by: Tyrel Datwyler Link: https://patch.msgid.link/20260723000149.969416-4-tyreld@linux.ibm.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 73c460ace00bd5b03ccb16b92091782f702ae5d4 Author: Jiaxing Hu Date: Sat Jul 18 15:11:43 2026 +1200 iommu/rockchip: Clear stale page faults before enabling stall [ Upstream commit b10d5920cafa292ee3cab9c20f813da4fe4f00b8 ] Boot firmware can leave an IOMMU bank in PAGE_FAULT_ACTIVE before the driver has configured paging: PAGE_FAULT_ACTIVE=1 STALL_ACTIVE=0 IDLE=1 Such a bank ignores CMD_ENABLE_STALL and never reaches STALL_ACTIVE, so rk_iommu_enable_stall()'s readx_poll_timeout() spins until it times out (seen on the RK3576 NPU, whose MMUs share this poll across banks). Rather than special-casing these banks in the stall path, acknowledge the stale fault with CMD_PAGE_FAULT_DONE before enabling stall, so every bank starts from a clean state and the normal stall sequence applies to all of them. Banks without a pending fault are untouched. Signed-off-by: Jiaxing Hu Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit eb3267507d9dbacb03105a761fdb28c555969a10 Author: Pengpeng Hou Date: Tue Jun 16 08:43:48 2026 +0800 hsi: omap_ssi: remove debugfs on port creation failure [ Upstream commit 760318e2e69857214314e94ac477219f0c89106b ] ssi_probe() creates the controller debugfs tree before creating the SSI port child devices. If a port device cannot be created, the error path removes any children and tears down the controller, but leaves the debugfs tree behind. Remove the controller debugfs tree on the port creation failure path, matching the normal remove path. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260616004348.97684-1-pengpeng@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 854904aacf60a172292c3be01dfc5f913bb95df3 Author: Tomer Maimon Date: Wed Jul 15 15:29:21 2026 +0300 pinctrl: npcm8xx: move GPIO IRQ setup into request_resources [ Upstream commit b8edfde12e355030e708394c0fa11632559c7ac5 ] npcmgpio_irq_startup() calls pinctrl_gpio_direction_input(), which may sleep while taking the pinctrl core mutex. That makes IRQ startup trip lockdep when CONFIG_PROVE_LOCKING is enabled. Move the direction change into irq_request_resources() and keep startup limited to the ack and unmask operations that are safe in atomic context. Signed-off-by: Tomer Maimon Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b0383baabdffd630f69eae552741a75a3a6bd6a9 Author: Tomer Maimon Date: Wed Jul 15 15:29:23 2026 +0300 pinctrl: npcm8xx: fix debounce register selection [ Upstream commit 602ee6c9447e4382c7e145b26a1c940813f2a144 ] Each DBNCS register programs debounce source selection for 16 GPIOs. The current offset calculation advances the register address every four GPIOs, so offsets 4-15 and 20-31 end up touching the wrong selector register. Advance the DBNCS offset per 16 GPIOs so each line uses the debounce selector bank that matches the hardware layout. Signed-off-by: Tomer Maimon Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1993ef95d0650579d99887a1a5172e92e5f962e3 Author: Tomer Maimon Date: Wed Jul 15 15:29:19 2026 +0300 pinctrl: npcm8xx: clear pending GPIO events during init [ Upstream commit cd39cce4cfd499f555eb8b8252636609c3468f57 ] A bank may retain pending event status across resets of the GPIO block. If probe leaves the old state in place, the chained IRQ handler can see spurious events as soon as the irqchip is registered. Disable event generation and clear EVST before wiring each GPIO bank into gpiolib so the driver starts from a known state. Signed-off-by: Tomer Maimon Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6c9069dc8bfe31d54f47c6263a2a9a606848ce68 Author: Tomer Maimon Date: Wed Jul 15 15:29:17 2026 +0300 pinctrl: npcm8xx: enable RMII outputs from RMII groups [ Upstream commit c6ccdc305589dd7c7976116e0870a23f291c5fa9 ] NPCM8xx uses GCR_INTCR4 bits to release the R1, R2 and RMII3 transmit outputs from Hi-Z. Those bits need to follow the mandatory r1, r2 and rmii3 pin groups. The R1_OEn, R2_OEn and R3_OEn side groups are optional and should not be required just to enable RMII transmit outputs. Program the INTCR4 bits when the corresponding RMII groups are selected and clear them again when those pins switch back to GPIO or another shared function. Signed-off-by: Tomer Maimon Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 0e2161e267b5298ae63737e640b778eafa72500f Author: Pengpeng Hou Date: Tue Jun 16 08:59:01 2026 +0800 firmware: imx: scu: manage mailbox channels and global handle [ Upstream commit 55c748d596f841a18cf659ce0999f64029a5c88c ] imx_scu_probe() requests mailbox channels with the non-managed mbox_request_channel_byname() helper and then publishes sc_ipc through the global imx_sc_ipc_handle. Later probe failures, including child population failure, can leave the channels and global handle live after the probe has failed. Register devres actions to free each mailbox channel and clear the global handle. Also depopulate partially created child devices when devm_of_platform_populate() reports an error. Signed-off-by: Pengpeng Hou Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 582b3d633ec61d1a678651c2131e6739b4d6f45f Author: Abdun Nihaal Date: Thu Jul 23 18:14:16 2026 +0530 platform/x86: int1092: Fix info leak in parse_package() [ Upstream commit f5eb833730c071b68a68de5d1df442aae4ae7e6e ] Sashiko reports a possible information leak that can occur as follows: 1. In parse_package(), memory allocated for data->device_mode_info is not zerozed initially as it is allocated with devm_kmalloc_array(). 2. In the for loop after the allocation, a malformed ACPI package provided by firmware can cause some fields in data->device_mode_info to remain uninitialized. 3. Later in update_sar_data(), the uninitialized fields gets copied to the fields of context->sar_data, which can be exposed to userspace through sysfs attribute read (intc_data_show()). Fix the leak by switching to use devm_kcalloc() for allocation. Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260710052806.100107-1-nihaal%40cse.iitm.ac.in Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20260723-platx86-v4-2-93b4a178b595@cse.iitm.ac.in Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit e1fdeb7e32b3c8f1609ccaec16276a4674899e93 Author: Konstantin Komarov Date: Thu Jul 2 13:07:13 2026 +0200 fs/ntfs3: load ATTR_BITMAP run extents from $MFT extension records [ Upstream commit e31886cb6e0e14cf65e27da0bf1a422ff419d893 ] When $MFT's ATTR_BITMAP attribute is heavily fragmented, its run list can span multiple MFT extension records (attribute list entries with vcn > 0). The non-primary segment handler in ntfs_read_mft() only processed ATTR_DATA extension segments for MFT_REC_MFT, silently skipping any ATTR_BITMAP segments. This left sbi->mft.bitmap.run incomplete, causing wnd_init() to fail with -ENOENT when wnd_rescan() tried to look up a VCN not covered by the truncated run list. Observed on a 16 TB NTFS volume (0xFFFFFEFF total clusters) whose MFT bitmap run list was split across 97 extents in extension records. wnd_rescan() successfully looked up VCNs 0-122 from the runs loaded from the base record, then failed at VCN 123 (the last cluster of the bitmap) whose run was only present in an extension record. Fix by extending the MFT_REC_MFT special case to also handle ATTR_BITMAP extension segments, storing their runs into sbi->mft.bitmap.run the same way the primary segment does. Signed-off-by: Senjin Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit c92dec522208c8725f59e13ecada38bc38bef3fc Author: Senjin Date: Sat Jun 13 20:16:14 2026 +0000 fs/ntfs3: fix lseek EINVAL on sparse/compressed files with 64-bit clusters [ Upstream commit 789af83e41aef54c1ff1cee16adc27822e0a0d71 ] When CONFIG_NTFS3_64BIT_CLUSTER is enabled, sbi->maxbytes_sparse is set to -1. As a signed loff_t this is -1LL, the most negative value. Any lseek on a sparse or compressed file passes this as maxsize to vfs_setpos(), which returns -EINVAL whenever offset > maxsize, and since -1LL is less than any non-negative offset, every seek fails, including lseek(fd, 0, SEEK_SET). The intent of -1 here appears to be "no limit" (matching the spirit of MAX_LFS_FILESIZE assigned to sbi->maxbytes and sb->s_maxbytes in the same block), but the signed type makes it the minimum instead of the maximum. Fix by assigning MAX_LFS_FILESIZE to sbi->maxbytes_sparse in the 64-bit cluster path, consistent with the other two limits set there. Observed on a 16 TB NTFS volume with 0xFFFFFEFF total clusters compiled with CONFIG_NTFS3_64BIT_CLUSTER=y. Sequential reads via dd/cp worked correctly; any lseek call on sparse files returned EINVAL, preventing archive managers and other tools from random-accessing files on the volume. The non-64-bit-cluster path correctly sets maxbytes_sparse to (1ull << (cluster_bits + 32)) - 1, a large positive value. Signed-off-by: Senjin Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit d08d367832a87cecb23034cf56b2a1df73f56317 Author: Konstantin Komarov Date: Thu Jul 2 13:29:09 2026 +0200 ntfs3: fix info-leak in ntfs_rename() [ Upstream commit 2fa56613b25d0c983ef3ff6d3e865d4254280abe ] Hard to say about copy_to_user_iter(), but at least the first splat looks correct. At the end of fill_name_de(), data layout is: struct NTFS_DE *e = buf; ... |<- data_size + sizeof(struct NTFS_DE) ->|<- XXX ->| buf |----------------------------------------------------------- |<- ALIGN(data_size, 8) + sizeof(struct NTFS_DE) ->| ;; e->size If 'buf' was allocated with kmalloc(), XXX remains uninitialized and passed as such to memcpy() called from hdr_insert_de(). So using kzalloc() for all buffers passed to fill_name_de() looks the simplest and most safe solution. OTOH if someone would have said that an overhead of PAGE_SIZE'd memset() is too large, more fine-granted solution is to memset() XXX only. Reported-by: syzbot+905d785c4923bea2c1db@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=905d785c4923bea2c1db Signed-off-by: Dmitry Antipov Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit df347bd702520a86a9a7e670778b5041043a93ef Author: Kyle Zeng Date: Thu Jun 11 14:33:31 2026 -0700 fs/ntfs3: reserve NUL byte when converting UTF-16 names [ Upstream commit 4871fedaabbfd574ac0a075b80e75afdd532e11e ] ntfs_utf16_to_nls() appends a trailing NUL to the converted output, but it passes the caller-supplied size directly to the conversion loop. For the UTF-8 path, utf16s_to_utf8s() can legitimately fill all buf_len bytes and return buf_len, after which ntfs_utf16_to_nls() writes the terminator one byte past the end of the destination buffer. The same contract problem exists for the NLS path when a converted character consumes the last available byte. Reserve one byte for the terminator before doing either conversion. The function continues to return the number of converted bytes, excluding the NUL terminator. Assisted-by: Codex:gpt-5.5 Signed-off-by: Kyle Zeng Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit bf30a9b084beb7c67883e840e9643a896155003f Author: Brian Norris Date: Wed Jul 22 16:09:42 2026 -0700 PCI/portdrv: Allow probing even without child services [ Upstream commit 834171efeefffb1a0f2136f32e76669bbc11db86 ] The PCIe port driver fails to probe if it finds no child services, presumably under the assumption that the driver is not useful in that case. However, the driver *can* still be useful for power management support -- namely, it still configures the port for runtime PM / D3, which may be important for allowing a bridge to enter low power modes. Thus, allow probe to succeed even if no IRQs and no child services are available. This also mirrors existing behavior for ports that don't support any portdrv services (PCIe hotplug, AER, DPC, PME, bwctrl), where we'd also probe successfully. This change is a bit more important after commit f5cd8a929c82 ("PCI: dwc: Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI controller"), because it's common for some DWC-based systems to: 1. have only the "aer" and "pcie_pme" port services available and 2. not define legacy INTx interrupts properly in their device tree. After commit f5cd8a929c82, such systems may fail pcie_init_service_irqs() and so exit with -ENODEV. Link: https://lore.kernel.org/all/nyada24tqwlkzdceyoxbzitzygvp4elvj5oajnqdwb33xkcdwk@76vnrx45fsfd/ Signed-off-by: Brian Norris [bhelgaas: reorder pcie_port_device_register() decls per Lukas] Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Link: https://patch.msgid.link/20260722160942.v4.1.I5fd5d83f518681b3949d8ab2f16ba8244fd3e774@changeid Signed-off-by: Sasha Levin commit 2c397bfb5aee30ec3cbae84434603670e88eba6d Author: Ruoyu Wang Date: Thu Jun 18 02:22:27 2026 +0800 ntfs3: initialize err in attr_wof_frame_info [ Upstream commit dd64afb32c4d8d3c934ae84df59a2e463d6fa43c ] attr_wof_frame_info() may reuse a cached offsets folio. In that case the loop can fill the output offsets without calling attr_load_runs_range() or ntfs_read_run(), leaving err uninitialized before the common return path. Initialize err to 0 for the successful cached path. Signed-off-by: Ruoyu Wang Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 62acbc8e806f3861949958311d0e800b8f6e7fca Author: Pengpeng Hou Date: Sat Jul 4 20:18:51 2026 +0800 soc: ixp4xx: qmgr: add missing MODULE_DEVICE_TABLE() [ Upstream commit 01479280fa5d4691013bcd64fdfd935117b69769 ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Message-ID: <20260704121851.63805-1-pengpeng@iscas.ac.cn> Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e71892a6c0b876990eddac3ec078ccd471943e56 Author: Randolph Sapp Date: Mon Oct 13 12:01:23 2025 -0500 drm/etnaviv: force flush on power register ops [ Upstream commit c182a2ae13886463f7ae36e034449477306d182b ] Add gpu_write_power_sync to verify that power register modifications have reached the endpoint device in sequence specific sections that do not validate device state. These sequence specific areas have been detected experimentally with an am57xx-evm through numerous boot and module load+unload cycles. Signed-off-by: Randolph Sapp Reviewed-by: Lucas Stach Signed-off-by: Lucas Stach Link: https://patch.msgid.link/20251013170122.1145387-2-rs@ti.com Signed-off-by: Sasha Levin commit 4ebec873529d6c9f3f34acf9f03c06d6a12474db Author: Rosen Penev Date: Sun Jul 19 19:02:29 2026 -0700 ata: pata_ep93xx: fix PIO fallback when DMA init fails [ Upstream commit c303c3619a1d5cf7d4b457106062d16724724a80 ] ep93xx_pata_dma_init() returns an error when dma_request_chan() fails, which causes ep93xx_pata_probe() to abort entirely. The probe function already has a PIO fallback path (it checks both channel pointers before enabling UDMA), so the DMA init should not fail the probe on non-fatal errors. Propagate -EPROBE_DEFER, such that we allow the DMA controller driver to load, in case we got probed before the DMA controller driver. For all other failures (e.g. -ENODEV when the DMA controller is missing in the device tree), fall back to PIO. Assisted-by: Opencode:Big-Pickle Signed-off-by: Rosen Penev Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 473a527b78c07595597fa0297a3db91980b2b3b2 Author: Benjamin Marzinski Date: Mon Jul 6 16:23:24 2026 -0400 bitops: make the *_bit_le functions use unsigned long [ Upstream commit 1c61b0a6e5c472737619f74f79c390363ee258df ] The *_bit_le functions use a signed integer for the bit number. However, the *_bit functions can use an unsigned long. This causes problems if there is a large bitmap and a bit number > 0x80000000 is passed in. Since that is a negative int, it will get sign extended to a long when getting passed to the *_bit function, turning it into a huge bit number. This usually ends up with the memory address wrapping around and the function accessing memory before the start of the bitmap. Avoid this by making the *_bit_le functions take an unsigned long. This can be triggered by faking an almost 4TB dm-mirror device, which uses bitmaps to track the mirror regions: $ dmsetup create bigzero --table '0 8589934590 zero' $ dmsetup create mymirror --table '0 8589934590 mirror core 2 2 nosync 2 /dev/mapper/bigzero 0 /dev/mapper/bigzero 0' This will access memory before the start of the sync_bits bitmap, and likely hit the guard page of the previously allocated clean_bits bitmap, causing a kernel panic with the old code. I looked and didn't see any crazy code using the signed int to intentionally try and access bits before some address within the bitmap. Signed-off-by: Benjamin Marzinski Signed-off-by: Yury Norov Signed-off-by: Sasha Levin commit 3ccc1c6eec2baa23c741011c626d7bb20c840f30 Author: Zhang Yi Date: Tue Jul 14 16:00:36 2026 +0800 ext4: use FGP_WRITEBEGIN for tail block zeroing [ Upstream commit e1cf7b5f5c8ad1e00d00c50c61c3e8fdc79cd422 ] ext4_load_tail_bh() returns a locked folio that callers immediately mutate through folio_zero_range() and mark_buffer_dirty(). Use FGP_WRITEBEGIN so that, on backing devices that require stable writes, __filemap_get_folio() waits for writeback to finish before returning the folio; on regular devices the wait is a no-op. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260714080044.4038124-2-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 4a5335847d0e7a90a409dad14b63422d71f9060f Author: Zhang Yi Date: Tue Jul 14 16:00:38 2026 +0800 ext4: check return value of ext4_get_block() in ext4_load_tail_bh() [ Upstream commit 705a3fd3bac167f1dabe3d3bba46cd484c5528dd ] ext4_load_tail_bh() ignores the return value of ext4_get_block(), so an I/O or allocation failure is silently discarded. buffer_mapped(bh) stays false and the function returns NULL, which callers such as ext4_block_do_zero_range() treat as "nothing to do" and return success. This can mask real failures during zero-range, truncate, or punch-hole operations, potentially exposing stale data if the block was not actually a hole and needed zeroing. So propagate the error to the callers. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260714080044.4038124-4-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 9323760f57a2991042f421a9edafc1db26d89116 Author: Alexander Wilhelm Date: Fri Jul 3 09:35:38 2026 +0200 wifi: ath12k: fix scan command endianness on big endian [ Upstream commit 6c90f68f97de591e0413f7d2de59449a0388bbab ] ath12k_wmi_scan_req_arg stores scan parameters in CPU-native byte order, while ath12k_wmi_send_scan_start_cmd() writes them into a WMI command buffer whose contents must be in little-endian format. The existing code copies the channel list and writes s_ssid and hint_bssid related values to the command buffer without endian conversion. As a result, scan requests contain invalid parameters on big-endian systems and fail. Convert the channel list as well as the s_ssid and hint_bssid related values to little-endian before writing them to the WMI command buffer. This preserves the existing behaviour on little-endian systems while fixing scan requests on big-endian architectures. Signed-off-by: Alexander Wilhelm Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260703-fix-channel-list-copy-v2-1-372c39306d79@westermo.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit beda9980b6eed9b6453f6a60d6ef656003cf9c0f Author: Manikanta Pubbisetty Date: Fri Jul 10 11:34:06 2026 +0530 wifi: ath10k: trigger hardware recovery upon rx failures [ Upstream commit f78210dd4bea09090b828adc2733cad4b9916306 ] When an error occurs during RX packet processing (e.g., MSDU done failure), the driver sets rx_confused and drops all subsequent RX packets until a Wi-Fi ON/OFF cycle clears the flag. This can leave the device in a bad state where it cannot process RX data traffic. Instead of leaving the device in such a state, trigger hardware recovery so that such an error state can be reset and the device can function again normally. Tested-on: WCN3990 hw1.0 WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189 Signed-off-by: Manikanta Pubbisetty Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260710060406.3323260-1-manikanta.pubbisetty@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 91f7cc7c94be51e6e6d502b1c226ccbebcde77c7 Author: Pengpeng Hou Date: Sat Jul 4 09:10:40 2026 +0800 wifi: ath11k: validate regulatory capability phy_id [ Upstream commit f8729a40ebcc94d164be8f154483a21669f3ab52 ] ath11k_wmi_tlv_ext_hal_reg_caps() copies firmware regulatory capability records into soc->hal_reg_cap[] using reg_cap.phy_id as the destination index. The loop count is bounded by num_phy, but the phy_id embedded in each record is not checked against the fixed MAX_RADIOS-sized destination array. Reject firmware records whose phy_id does not fit soc->hal_reg_cap[] before copying the parsed capability. Signed-off-by: Pengpeng Hou Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260704011040.26233-1-pengpeng@iscas.ac.cn Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit d8e8452d6c7caab63815cd9f11d0c7df66d7c82a Author: Mukesh Ojha Date: Fri Jul 17 20:16:07 2026 +0530 iommu/qcom: Publish pgtbl_ops before releasing init_mutex [ Upstream commit a05b67cd45ad09a19f41b2d37255da714512e0ca ] qcom_domain->pgtbl_ops was assigned after mutex_unlock(). Another thread calling qcom_iommu_init_domain() would see qcom_domain->iommu already set (domain fully initialized) and skip re-initialization under the mutex. If it then called qcom_iommu_map() before the first thread set pgtbl_ops, it would observe a NULL ops pointer and return -ENODEV for valid mappings. Move the assignment to before mutex_unlock() so that once the mutex is released the domain is fully visible to concurrent operations. Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit d520e17ba4c2278ce541b6bfc132aceae636e8f5 Author: Pengpeng Hou Date: Mon Jun 15 14:52:41 2026 +0800 thermal: intel: int340x: clean up RFIM groups on DVFS failure [ Upstream commit 28f34d7dafa6dfa657efd6760b7c78e98c9b2f6a ] proc_thermal_rfim_add() can create the FIVR and DLVR sysfs groups before creating the DVFS group. If DVFS group creation fails while both earlier groups are enabled, the current error handling removes only one group: the FIVR branch returns before the DLVR cleanup branch can run. This leaves the DLVR group behind even though RFIM setup fails. Use one DVFS failure path that removes all previously created RFIM groups before returning the error. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260615065245.84252-1-pengpeng@iscas.ac.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ff71191bf2a92935fc7edee8ad86a1a6c204f886 Author: Mukesh Ojha Date: Fri Jul 17 20:16:08 2026 +0530 iommu/qcom: Enable clocks before hardware access in qcom_iommu_ctx_probe() [ Upstream commit cb776a03a53429aa59e25a8cbc3d1a48bd11afdb ] qcom_iommu_ctx_probe() reads and writes the CB_FSR register to clear any stale IRQ left by the bootloader. This happens during devm_of_platform_populate() which is called from the parent device's probe before any pm_runtime_get(). The parent's clocks (iface, bus, tbu) are therefore not guaranteed to be on, making the register access unreliable on rebind or after a suspend cycle. Use pm_runtime_resume_and_get() on the parent device to ensure clocks are enabled before the register access, and release the reference immediately after. Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 818fae7f884d4b9b41f831d0dc55684743b989e3 Author: Mukesh Ojha Date: Fri Jul 17 20:16:05 2026 +0530 iommu/qcom: Check pm_runtime_resume_and_get() return in probe [ Upstream commit e910315ae08a23bc953daed10b1c518abac1df49 ] The SMMU_INTR_SEL_NS register write in qcom_iommu_device_probe() uses pm_runtime_get_sync() without checking the return value. If runtime resume fails the subsequent writel_relaxed() would access hardware with clocks potentially disabled. Switch to pm_runtime_resume_and_get() which handles the usage-count cleanup on failure, check the return value, and unwind the already registered iommu device on error. Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 4c22a1949f3113f42c77c2ac0ac8765690946dec Author: Heiko Schocher Date: Tue Jul 21 06:19:32 2026 +0200 drm/panel: simple: Add Kyocera tcg070wvlq panel [ Upstream commit 900517da69afca6f72dacf14278aee3b65275507 ] Commit 922fb2db0287 ("dt-bindings: display: simple: Add Kyocera tcg070wvlq panel") added the compatible string for the Kyocera tcg070wvlq panel to the devicetree bindings documentation (panel-simple.yaml), but the corresponding entry was not added to the panel-simple driver. Add the missing compatible entry to the driver. Signed-off-by: Heiko Schocher Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260721041935.757240-1-hs@nabladev.com Signed-off-by: Sasha Levin commit 7668caa7eeb26437d13a8f80e26a91abc5fda74e Author: Esteban Urrutia Date: Sat Jul 11 23:14:01 2026 -0400 iommu/arm-smmu-qcom: Add SM8450 MDSS compatible [ Upstream commit d149c8b2c0146a01f1be326ddb1e182b55aee638 ] Add the compatible for the MDSS client on the Snapdragon 8 Gen 1 so it can be properly configured by the IOMMU driver. Otherwise, there is an unhandled context fault, because the framebuffer is already configured in UEFI. Reviewed-by: Konrad Dybcio Signed-off-by: Esteban Urrutia Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit b6f14196dc5b653585f3d553233550f5b2234ed2 Author: Baokun Li Date: Mon Jun 8 19:11:48 2026 +0800 ext4: reject mount if clusters/inodes per group are not 8-aligned [ Upstream commit d42dc7726a003262b73ffef2b744ff57a5488799 ] The block and inode bitmap checksums are computed over a whole number of bytes: ext4_inode_bitmap_csum_*() use EXT4_INODES_PER_GROUP(sb) >> 3 and ext4_block_bitmap_csum_*() use EXT4_CLUSTERS_PER_GROUP(sb) / 8 as the length passed to ext4_chksum(). If s_inodes_per_group or s_clusters_per_group is not a multiple of 8, the trailing fractional bits are excluded from the checksum. Those bits are then unprotected, and any incremental csum update path that assumes a byte-aligned bitmap can compute a checksum inconsistent with the full recalculation, corrupting the on-disk bitmap checksum. Reject such filesystems at mount time by adding the missing " & 7" alignment checks alongside the existing range validation. Suggested-by: Theodore Ts'o Link: https://patch.msgid.link/h3n7jlfhyna64dn5o76qxcspnhxdddcs6crpxftmy7gnl7b3sx@jenszfpcsnit Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260508121539.4174601-1-libaokun%40linux.alibaba.com?part=10 Signed-off-by: Baokun Li Reviewed-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20260608111150.827117-2-libaokun@linux.alibaba.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 45c7e0fe0dfa8c5a88ec6f596f6e75e69414ed46 Author: Lachlan Hodges Date: Tue Jul 21 15:39:58 2026 +1000 wifi: cfg80211: include cf1 offset when sending chandef [ Upstream commit 5a69b8dffd2a1b06e4cc4c9003c639eb78bac4cd ] The cf1 offset is not included when sending the chandef leading to incorrect channel resolution in usermode. Include it. Signed-off-by: Lachlan Hodges Link: https://patch.msgid.link/20260721053958.227853-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit b3b9b88fa2eab792ad4d142a0a30278fdb2fc46f Author: Kuan-Wei Chiu Date: Tue Jul 14 00:24:50 2026 +0000 riscv, bpf: Add support for BPF_MOVSX in RV32 JIT [ Upstream commit c6a08afdfe3a81b1a54e921921e9481dd6c78f8a ] The current rv32 bpf jit compiler incorrectly treats BPF_MOVSX as a standard zero-extended move operation. The bpf instruction set allows sign-extension moves by reusing the BPF_MOV opcode with the instruction offset set to 8, 16, or 32. Update the bpf_jit_emit_insn() function to check the offset field for both ALU and ALU64 MOV operations. If the offset is non-zero, emit the correct slli and srai instructions to perform the sign extension. Before this patch: [ 19.549705] test_bpf: #82 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) [ 19.551354] test_bpf: #83 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) [ 19.552576] test_bpf: #84 ALU64_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) [ 19.553542] test_bpf: #85 ALU64_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) [ 19.554807] test_bpf: #86 ALU64_MOVSX | BPF_W jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) After this patch: [ 17.931172] test_bpf: #82 ALU_MOVSX | BPF_B jited:1 125 PASS [ 17.932198] test_bpf: #83 ALU_MOVSX | BPF_H jited:1 124 PASS [ 17.933039] test_bpf: #84 ALU64_MOVSX | BPF_B jited:1 124 PASS [ 17.933918] test_bpf: #85 ALU64_MOVSX | BPF_H jited:1 124 PASS [ 17.934751] test_bpf: #86 ALU64_MOVSX | BPF_W jited:1 122 PASS Signed-off-by: Kuan-Wei Chiu Reviewed-by: Pu Lehui Link: https://lore.kernel.org/bpf/20260714002451.4091139-3-visitorckw@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit b31608d5a40a5ef60d4b68908695fc4363611a56 Author: Pengpeng Hou Date: Sat Jul 4 23:23:36 2026 +0800 power: reset: piix4-poweroff: add missing MODULE_DEVICE_TABLE() [ Upstream commit ffefc5d9a052f67bc87b57d1107fd7cc1fa1a3d4 ] The driver has a match table for the pci bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704152336.51384-1-pengpeng@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 3e7bb387e80cdbc618bcdccf11de65c078035a95 Author: Yuyang Huang Date: Sat Jul 11 09:54:02 2026 +0900 net: prestera: ignore duplicate RIF destruction events [ Upstream commit 3cbbc9fa33382d03f2813118e672eb318eba9cde ] During address teardown, the inetaddr notifier may be called multiple times for the same interface. Ignore NETDEV_DOWN events if the RIF has already been destroyed, rather than returning -EEXIST, which aborts the notifier chain. Cc: Ido Schimmel Cc: Kuniyuki Iwashima Signed-off-by: Yuyang Huang Link: https://patch.msgid.link/20260711005405.2861680-2-yuyanghuang@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a2a1de94796e8d35f28bc901cf36b6e2ed846870 Author: Aleksander Jan Bajkowski Date: Sun Jul 19 12:01:55 2026 +0200 net: sfp: add quirk for HORACO copper SFP+ module [ Upstream commit 1bb028baab541900d3603d4f93c1c0fb5aba5401 ] Add quirk for a copper SFP+ module that identifies itself as "OEM" "HC-10GE-113C". It uses RollBall protocol to talk to the PHY. Signed-off-by: Aleksander Jan Bajkowski Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260719100158.874882-1-olek2@wp.pl Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9c8ca9ebda30ea293c8040ea4a6b75fcb7883e1a Author: Pengpeng Hou Date: Mon Jun 15 14:31:05 2026 +0800 power: supply: cros_pchg: unregister EC notifier [ Upstream commit 631adfa03595c63b2a621cdc62db60bb1ce5f91c ] cros_pchg_probe() registers an EC event notifier whose callback uses the devm-allocated charger_data via container_of(). The driver has no remove callback and does not unregister the notifier, so the notifier chain can retain a pointer to freed driver state after unbind or probe cleanup. Register a devm cleanup action immediately after the notifier is installed so the notifier is unregistered before the driver state is released. Also fail probe if the notifier cannot be registered, instead of leaving a charger device that cannot receive EC events. Signed-off-by: Pengpeng Hou Reviewed-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260615063105.39152-1-pengpeng@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit ba70646da8901f3afe919e437028516f74920a6b Author: Kuan-Wei Chiu Date: Tue Jul 14 00:24:49 2026 +0000 riscv, bpf: Add support for BPF_SDIV and BPF_SMOD in RV32 JIT [ Upstream commit 2e0fa2389c50fd3a69bb738efa74e127b7516938 ] The current rv32 bpf jit compiler incorrectly treats BPF_SDIV and BPF_SMOD as unsigned operations. The BPF instruction set allows signed division and modulo by reusing the BPF_DIV and BPF_MOD opcodes with the instruction offset set to 1. Update the emit_alu_r32() function to accept an 'is_sdiv' variable and emit the correct div and rem instructions when the offset is 1. Before this patch: [ 44.161771] test_bpf: #165 ALU_SDIV_X: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) [ 44.167385] test_bpf: #166 ALU_SDIV_K: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) [ 44.171053] test_bpf: #169 ALU_SMOD_X: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) [ 44.172081] test_bpf: #170 ALU_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) After this patch: [ 16.002192] test_bpf: #165 ALU_SDIV_X: -6 / 2 = -3 jited:1 95 PASS [ 16.002983] test_bpf: #166 ALU_SDIV_K: -6 / 2 = -3 jited:1 1059 PASS [ 16.017167] test_bpf: #169 ALU_SMOD_X: -7 % 2 = -1 jited:1 136 PASS [ 16.023002] test_bpf: #170 ALU_SMOD_K: -7 % 2 = -1 jited:1 109 PASS Signed-off-by: Kuan-Wei Chiu Reviewed-by: Pu Lehui Link: https://lore.kernel.org/bpf/20260714002451.4091139-2-visitorckw@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 42c395a037d2ab95b66dce454b4d1a96c84cd746 Author: Thomas Renninger Date: Fri Jul 17 08:51:22 2026 +0200 ACPI: sysfs: Properly map BERT and CCEL data to their ACPI tables [ Upstream commit e45ee607ca6f9f97a2f97be356d844a912971a16 ] In the case of multiple BERT ACPI tables, one gets: sysfs: cannot create duplicate filename '/firmware/acpi/tables/data/BERT' This is because both: /firmware/acpi/tables/BERT1 /firmware/acpi/tables/BERT2 are attempted to be mapped to the same data table: /firmware/acpi/tables/data/BERT Address this problem by passing and using the same filename for data tables. Signed-off-by: Thomas Renninger Reported-by: Michal Suchanek Closes: https://bugzilla.suse.com/show_bug.cgi?id=1270211 [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260717065129.72924-3-trenn@suse.de Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e716e0a6a56ca7c2761324755bfa0c2a8cd46409 Author: Zhao Li Date: Thu Jul 9 03:59:04 2026 +0800 wifi: mac80211_hwsim: clear PMSR request state on abort [ Upstream commit 37a77bd1395e8261d1760ae39c7f5eb637300550 ] mac80211_hwsim saves the in-flight cfg80211 PMSR request and its wdev in data->pmsr_request / data->pmsr_request_wdev when a measurement starts, and clears them only when it reports completion. mac80211_hwsim_abort_pmsr() never cleared that saved state. cfg80211 owns the request and frees it once the abort callback returns (cfg80211_pmsr_process_abort() calls rdev_abort_pmsr() then kfree(req)), so after an abort data->pmsr_request dangles. A later hwsim PMSR report then dereferences the freed request in hwsim_pmsr_report_nl() and completes it; a use-after-free. Clear data->pmsr_request and data->pmsr_request_wdev once the abort matches the active request. Move the wmediumd/virtio notification check below the clear so the saved state is dropped even when no notification is sent. Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260708195911.84365-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 631331a536083f3ce72df133d9db26eb0a3c7601 Author: Shahar Tzarfati Date: Wed Jul 15 21:27:43 2026 +0300 wifi: mac80211: ibss: read deauth reason_code after frame length check [ Upstream commit aa4c0a649903567762edf2bbc7fff608953b3ca4 ] The function was reading reason_code from the frame before validating that the frame is at least IEEE80211_DEAUTH_FRAME_LEN bytes long. Move the reason_code read to after the length check so the field is guaranteed to be present before it is accessed. Signed-off-by: Shahar Tzarfati Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715212706.db26604650bd.I2caa73c396b8c9d357224b9334d5df3cafac498e@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 39e5768669acf9a5eedd03c77baeef652d8d3c05 Author: Yun Zhou Date: Tue Jun 23 14:19:03 2026 +0800 ext4: set EXT4_STATE_NO_EXPAND in ext4_evict_inode [ Upstream commit 2c0e4fb511f97467dafc91b6afb3414100289081 ] An inode being evicted will never need its extra isize expanded. Set EXT4_STATE_NO_EXPAND before ext4_mark_inode_dirty() in ext4_evict_inode() to make this explicit and prevent any unnecessary work in ext4_try_to_expand_extra_isize(). This also provides defense-in-depth for the s_writepages_rwsem deadlock during mount-time orphan cleanup, ensuring the expand path is blocked for inodes under eviction regardless of how they are reached. Signed-off-by: Yun Zhou Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260623061903.2148767-2-yun.zhou@windriver.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 4b623cb3e44ac338a7f2e290dbd8d05b6b672473 Author: Ali Alaei Date: Sun Jun 28 16:34:50 2026 +0200 PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX [ Upstream commit 72b32eccbcd591b9606edacf3bd7c455176d7660 ] On Intel Arrow Lake-HX systems (e.g. Core Ultra 9 275HX on Acer Predator PH16-73), the VMD controller reports BUS_RESTRICT_CFG = 3 in the VMCONFIG register. The existing switch statement only handled values 0, 1, and 2, causing vmd_get_bus_number_start() to return -ENODEV and aborting the entire VMD probe. This leaves NVMe drives behind the VMD controller invisible to the kernel. Hardware registers (VMCAP/VMCONFIG at offsets 0x40/0x44): VMD 0000:00:0e.0 (8086:ad0b): VMCAP=0x000f, VMCONFIG=0x03b8 BUS_RESTRICT_CFG(0x03b8) = (0x03b8 >> 8) & 0x3 = 3 Add cfg=3 as a fallthrough to cfg=2, setting busn_start=224, which is the correct bus number base for this hardware. Also add a PCI_POSSIBLE_ERROR() guard after reading VMCONFIG: a failed config space read returns 0xFFFF, and BUS_RESTRICT_CFG(0xFFFF) = 3, so without this guard a removed or errored device would falsely match the new case 3 instead of being caught as an error. Reported-by: Lin Mohan Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221137 # Arrow-Lake-S Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221136 # Arrow-Lake-S Signed-off-by: Ali Alaei Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260628143450.92492-1-ali.alaei.tabatabaei@gmail.com Signed-off-by: Sasha Levin commit 999c7fcbb9e44499872412059c22bacf26386c94 Author: Baokun Li Date: Mon Jun 8 19:11:49 2026 +0800 ext4: reduce max cluster size to match documented 256MB limit [ Upstream commit afa3caf2fbc417f755f36e271c4b3c2d45ccda9d ] The mke2fs man page documents: Valid cluster-size values are from 2048 to 256M bytes per cluster. but EXT4_MAX_CLUSTER_LOG_SIZE was set to 30 (1GB), allowing crafted filesystem images to specify cluster sizes up to 1GB. On 32-bit systems with bigalloc enabled, the consistency check in ext4_handle_clustersize(): s_blocks_per_group == s_clusters_per_group * (clustersize / blocksize) can overflow when the cluster ratio is large enough. Since s_blocks_per_group is not range-checked in the bigalloc path, the wrapped product can pass the consistency check, leading to inconsistent group geometry and potential out-of-bounds block allocation. Reduce EXT4_MAX_CLUSTER_LOG_SIZE to 28 to match the documented 256MB limit. With this cap, the maximum product is: (blocksize * 8) * (256M / blocksize) = 2^31 which fits safely in a 32-bit unsigned long for all block sizes. Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260608061112.392391-1-libaokun%40linux.alibaba.com Signed-off-by: Baokun Li Reviewed-by: Andreas Dilger Link: https://patch.msgid.link/20260608111150.827117-3-libaokun@linux.alibaba.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 2ff81efb11b7d70b121be5d5ccd9a47c342b32a9 Author: Kate Hsuan Date: Fri Jul 10 20:51:22 2026 +0800 ACPI: battery: Sanitise model_number by dropping unprintable characters [ Upstream commit 6587dd87595cfae6bf1304cd0cd1df2274424e42 ] The battery Embedded Controller (EC) may return the model name with trailing unprintable or non-ASCII characters. For example, on some systems: $ cat /sys/class/power_supply/BAT0/model_name LNV-5B10W51864�� If a non-ASCII or an unprintable character is found, it will be replaced with '\0' to ensure the model_number is a valid string. If left intact, the malformed string prevents udev rules and hwdb working correctly. Link: https://gitlab.freedesktop.org/upower/upower/-/work_items/345 Signed-off-by: Kate Hsuan Reviewed-by: Mark Pearson [ rjw: Subject tweak ] Link: https://patch.msgid.link/20260710125122.1621877-1-hpa@redhat.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d8fa603ec3edbe66fa173c166c2bb543cc503cac Author: Pengpeng Hou Date: Mon Jul 6 17:41:41 2026 +0800 ACPI: FPDT: validate table and record lengths [ Upstream commit 458b40fcdd04a9a0334830de5a536d8425454e4b ] FPDT records are supplied by firmware and are walked through length fields stored in the table itself. Check the main-table entry length before reading an entry, check the mapped subtable length before remapping it, and check each record length before saving a typed record pointer for sysfs. This keeps malformed firmware records from being interpreted as complete resume, suspend, or boot records when the current item is shorter than the structure consumed by the driver. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260706094141.82438-1-pengpeng@iscas.ac.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5ae52b5881d3b55e7f2fb7794a180843ef64763b Author: Bob Song Date: Fri Jul 17 10:49:48 2026 +0800 ALSA: hda: Check snd_hda_power_pm construct error before executing verb [ Upstream commit df27e4dc80c4a30ad206432cb848aab00de22ca7 ] When userspace writes 1 to /sys/bus/pci/devices/XX/remove to remove HDA PCI device, the HDA hardware control path is shut down and devres unmaps the BAR virtual address bus->remap_addr automatically during driver removal. If a delayed HDA verb command arrives after the MMIO region is unmapped, the driver will access invalid virtual addresses and trigger a page fault splat. So add an error check right after constructing snd_hda_power_pm. Signed-off-by: Bob Song Link: https://patch.msgid.link/20260717024948.506335-1-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 172faa1f46f9e848ce103e6a28754840556d7377 Author: Nizar Al-Kabbani Date: Sun Jul 19 12:08:43 2026 +0300 platform/x86: asus-nb-wmi: map ProArt key (0x8b) to KEY_PROG3 [ Upstream commit 6303451189a6d8f304221065c44ccd597e0acbe5 ] The dedicated "ProArt" key on the ASUS ProArt PX13 (HN7306) emits ASUS WMI event code 0x8b. This code is absent from the asus-nb-wmi sparse keymap, so pressing the key only produces a "Unknown key code 0x8b" message and does nothing in userspace. On this model the key is exposed solely through the WMI interface and has no HID scancode, so it can only be handled inside asus-nb-wmi. Map 0x8b to KEY_PROG3 so the key emits a bindable event, consistent with the existing KEY_PROG3 mapping used for the ASUS programmable/Armoury key. Signed-off-by: Nizar Al-Kabbani Reviewed-by: Denis Benato Link: https://patch.msgid.link/20260719090843.66777-1-nizar.m.kabbani@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 8f9c382fe02c277b26751d44eeb4453c2e9087d8 Author: Yousef Alhouseen Date: Tue Jun 30 12:50:15 2026 +0200 media: go7007: s2250: propagate control I/O failures [ Upstream commit 59dc14a6cb5ff1ae5ce2f6ebf51fe0139e1c0623 ] The brightness and contrast paths use oldvalue after read_reg_fp() without checking whether the read succeeded. A failed read leaves oldvalue uninitialized and can write arbitrary reserved register bits. Return read and write errors from every control path so failed hardware access cannot be reported as a successful control update. Signed-off-by: Yousef Alhouseen Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 186481d39e27b15d76333f96651b756553a80092 Author: Rituparna Warwatkar Date: Tue Jul 14 16:10:59 2026 +0200 media: dvb-core: fix feed leak on failed DMX_ADD_PID [ Upstream commit 9fa26c971ca310dd10a3bc0014f2fc7ea7167bba ] dvb_dmxdev_add_pid() allocates a new dmxdev_feed, links it into filter->feed.ts and, when the filter is already running, immediately starts the feed. If starting the feed fails, the newly allocated feed remains on the list. Subsequent restart and rollback paths may then operate on this stale entry, leaving feed resources allocated and causing leaks in drivers that allocate resources from ->start_feed() and release them from ->stop_feed(). Remove the feed from the list and free it when dvb_dmxdev_start_feed() fails. Reported-by: syzbot+e9a1f5e196de6663631b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e9a1f5e196de6663631b Signed-off-by: Rituparna Warwatkar Link: https://patch.msgid.link/20260714141059.63582-1-rwarwatkar@gmail.com Signed-off-by: Mauro Carvalho Chehab Message-ID: <20260714141059.63582-1-rwarwatkar@gmail.com> Signed-off-by: Sasha Levin commit ed7c17088459c4d4b44076f11d28f208a874e195 Author: Emmanuel Grumbach Date: Fri Jul 17 17:31:07 2026 +0300 wifi: iwlwifi: mvm: ignore sync frames when sync is disabled [ Upstream commit a790f60cc4d7dc64a2d7cadb94a3d9f60392bed4 ] Gate time-sync frame interception on the active flag so frames are not queued after time-sync teardown. Assisted-by: GitHubCopilot:GPT-5.3-Codex Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260717172958.ac73ee199a25.Ic1489244f9b02da93060f0a0e5b300a73527f265@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit d0e5b3757fce05a09d313f59d821e4db76d8c01f Author: Aditya Sherawat Date: Fri Jul 10 00:12:00 2026 +0530 drm/msm/adreno: Add support for A704 GPU [ Upstream commit 1f69339da06255a7f8560b4768fff83992c03deb ] Adreno A704 GPU found in Shikra is an IP reuse of A702 GPU with very minimal changes. The only KMD facing difference is the chipid and the zap firmware which is specified via devicetree. Just add the new chipid to enable support for A704 GPU in Shikra. Signed-off-by: Aditya Sherawat Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/738931/ Message-ID: <20260710-shikra-gpu-v6-1-b388ec5dce77@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 0b55bc6ad391b0c770f11b7f3b16199f7fb000f4 Author: Yuho Choi Date: Mon Jun 8 13:27:17 2026 -0400 driver core: attribute_container: Unwind device_add() on attr failure [ Upstream commit 8cfe7ad274bb42c4653b645267410d4a3a23db98 ] attribute_container_add_class_device() first calls device_add() and then creates the container attributes. If attribute_container_add_attrs() fails, the helper returns the error with the class device still registered. Callers use an error from this helper as a failed add and do not call device_del() on that path. Undo the successful device_add() before returning the attribute creation error. Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260608172717.88657-1-dbgh9129@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8976ea8b3c2148247303a573bb6b6381562d4e15 Author: Logan Gunthorpe Date: Tue Jul 14 15:20:10 2026 -0600 PCI: switchtec: Add Microchip PCI1008 to NTB DMA alias quirk [ Upstream commit 00a479ba1d01249d43ca5e453380d1ed60946f8a ] Add the PCI1008 device ID to the quirk_switchtec_ntb_dma_alias PCI fixup table. Without it, DMA transactions from a PCI1008 switch's NTB function are not given the correct requester ID alias, which can misdirect them under an IOMMU. Signed-off-by: Logan Gunthorpe Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260714212010.230606-4-logang@deltatee.com Signed-off-by: Sasha Levin commit a1e7269161fb363d3cc7f7afa4500ad4f8da7d16 Author: Logan Gunthorpe Date: Tue Jul 14 15:20:09 2026 -0600 PCI: switchtec: Add Microchip PCI1008 device ID [ Upstream commit 0d8a6306c680ee534be131e360f0cafa2bada7be ] Add the Microchip PCI1008 device ID to the core switchtec management driver's PCI ID table. Without it, the management endpoint on a PCI1008 switch is not bound by this driver, preventing userspace tools from configuring or monitoring the switch and leaving NTB functionality unavailable. Signed-off-by: Logan Gunthorpe Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260714212010.230606-3-logang@deltatee.com Signed-off-by: Sasha Levin commit 60163c5681ef387dd78e7e90ac67f07b735930e2 Author: Yousef Alhouseen Date: Wed Jun 24 19:51:39 2026 +0200 misc: ibmvmc: reject oversized inbound messages [ Upstream commit 18189e5d84aa0b3bc89189cba13b9105634cb6fb ] ibmvmc_recv_msg() trusts the message length from the CRQ. It passes that length directly to h_copy_rdma(). The destination buffer is only max_mtu bytes. A larger length can overrun it before userspace reads the message. Validate the CRQ length before issuing the RDMA copy. Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260624175139.7981-1-alhouseenyousef@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c8c51be0c072553dd3c5e968e70c840924a5535f Author: Pei Xiao Date: Wed Jul 1 10:01:10 2026 +0800 ipack: ipoctal: add rwsem to guard against TOCTOU in remove path [ Upstream commit 7d3a708af7f4e2af9e114d731bd60d30c1ec884e ] The "removed" flag check in each tty op has a TOCTOU race with __ipoctal_remove(): the device could be removed between the flag check and the subsequent access to hardware resources (channel registers via iowrite8, or xmit_buf in write_tty). Close this race by introducing a read-write semaphore (remove_sem). The tty ops acquire the read lock via guard(rwsem_read) for the full duration of the operation, while __ipoctal_remove() acquires the write lock via scoped_guard(rwsem_write) when setting the removed flag. This ensures that once removed is true, no in-flight tty op can still be accessing resources that are about to be freed by the remove path. Signed-off-by: Pei Xiao Link: https://patch.msgid.link/fbce75010a0f0a3a3709a5e06fd0ffd19ca0a0ed.1782870760.git.xiaopei01@kylinos.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 04332f741ad85070c5ea9c8d147c1f830c5dabd0 Author: Yousef Alhouseen Date: Wed Jun 24 20:59:25 2026 +0200 misc: ibmvmc: release send buffer on write errors [ Upstream commit fd62c1f591372f7dc4c5bc041569c2f0a4a86be1 ] ibmvmc_get_valid_hmc_buffer() marks the selected send buffer busy before ibmvmc_write() validates the backing storage or copies data from user space. Error exits after that point leave the buffer permanently busy. Keep the buffer pointer until ownership is handed to the hypervisor, and mark it free again on local write failures. Also report an RDMA send failure instead of returning a successful byte count. Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260624185925.2133-1-alhouseenyousef@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 69087b4e91dba2af5a7e25982c798b28b541ad77 Author: Pengpeng Hou Date: Mon Jul 6 17:19:35 2026 +0800 greybus: manifest: validate string descriptor header [ Upstream commit 18b6510f642dbcb856c3af8be974d1600f3ba2d3 ] identify_descriptor() computes a string descriptor size from desc->string.length. Require the descriptor to contain the fixed string descriptor header before reading the variable string length. The existing descriptor-size check then reports the short descriptor. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260706091935.78020-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 221c2d9ad5e6a5514bf783fe27ac6f83b78a2b04 Author: Yousef Alhouseen Date: Wed Jun 24 21:09:19 2026 +0200 misc: hpilo: validate device queue entries before use [ Upstream commit 7bf6940d7cf41f1f0330a9bae4b7a886e18fd8e3 ] ilo_pkt_dequeue() trusts descriptor IDs and lengths read from the shared FIFO entry. A bad entry can select a descriptor outside the allocated queue memory or report a packet length larger than one descriptor. Reject entries whose descriptor index or packet length exceeds the queue layout before deriving the packet pointer returned to read and write paths. Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260624190919.3432-1-alhouseenyousef@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6a35f590c7c3e62755a59ac40d48190028e96605 Author: Yousef Alhouseen Date: Tue Jun 30 12:49:23 2026 +0200 misc: genwqe: handle a first DMA address of zero [ Upstream commit d401772a9e18e837631450844f835229354528a4 ] genwqe_setup_sgl() uses zero as the initial previous DMA address. DMA address zero is valid, so a first entry at that address enters the merge path before last_s has been assigned and dereferences NULL. Only merge adjacent mappings after an SGL data entry has been created. Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260630104923.53827-1-alhouseenyousef@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b75a2a20b415e6f31f367f3a70b4a2af18eb97ca Author: Yousef Alhouseen Date: Mon Jun 29 18:06:05 2026 +0200 misc: bcm-vk: validate write size before allocation [ Upstream commit f66c40cd90954f52809b3eabd386137f56bb6215 ] bcm_vk_write() uses the user-supplied write count to size a flexible-array work entry and then copies count bytes into that array. The allocation expression is evaluated before any overflow check, so a very large count can wrap the allocation smaller than the subsequent copy. Reject empty writes, check the allocation arithmetic before kzalloc(), and initialize the __counted_by field before copying into to_v_msg[]. Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260629160605.29412-1-alhouseenyousef@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8c43c229a6ab1b21d9243cb9fd10dd340799b6b8 Author: Ian Abbott Date: Thu Jun 18 11:09:17 2026 +0100 comedi: pcmuio: Add sanity check to interrupt handler [ Upstream commit 6f6f6644e011fa910db744e9978127a443b94001 ] The driver requests an interrupt handler for the device, after setting device registers to disable interrupt generation. The interrupt handler should not be called prematurely unless the user-configured I/O port base address and/or IRQ number are incorrect or the hardware is bad. For safety, check the dev->attached flag in the interrupt handler pcmuio_interrupt() to ensure the device has been fully set up, avoiding a possible null pointer dereference of dev->subdevices by pcmuio_handle_asic_interrupt(). Also make use of the IRQ_HANDLED(x) macro for the normal return path of the interrupt handler. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-11-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 75dd215f3b8eda9b088360e90b4dc96c13653a46 Author: Ian Abbott Date: Thu Jun 18 11:09:14 2026 +0100 comedi: pcm816: Fix sanity check in interrupt handler [ Upstream commit 4fdac5090ce3616283216d9a1d2b9664e8e20747 ] The driver requests an interrupt handler for the device before it is fully set up. For safety, the interrupt handler checks the dev->attached flag to ensure the device is fully set up, but it currently does that after dereferencing the devpriv->dma pointer which may be NULL if dev->attached is false. Move the dereference of the devpriv->dma pointer after dev->attached has been checked to avoid the possible null pointer dereference. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-8-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 938c264ef62ca325d8770c37acd0330f0b5f4768 Author: Ian Abbott Date: Thu Jun 18 11:09:16 2026 +0100 comedi: pcmmio: Add sanity check to interrupt handler [ Upstream commit ea72e2fc9026f375314421ddfa4dbdc49432a899 ] The driver requests an interrupt handler for the device, after setting device registers to disable interrupt generation. The interrupt handler should not be called prematurely unless the user-configured I/O port base address and/or IRQ number are incorrect or the hardware is bad. For safety, check the dev->attached flag in the interrupt handler to ensure the device has been fully set up, avoiding a possible null pointer dereference of dev->read_subdev. Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/lkml/20260610115912.780131-1-jjy600901@snu.ac.kr/ Reported-by: Sangyun Kim Reported-by: Kyungwook Boo Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-10-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9ba6e3b771b24bd329f1650d0b9e8594e2c33571 Author: Ian Abbott Date: Thu Jun 18 11:09:08 2026 +0100 comedi: aio_iiro_16: Add sanity check to interrupt handler [ Upstream commit 1ca44751915134f19e8627768159781e75b5da50 ] The driver requests an interrupt handler for the device, after setting device registers to disable interrupt generation. The interrupt handler should not be called prematurely unless the user-configured I/O port base address and/or IRQ number are incorrect or the hardware is bad. For safety, check the dev->attached flag in the interrupt handler to ensure the device has been fully set up, avoiding a possible null pointer dereference of dev->read_subdev. Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/lkml/20260610115912.780131-1-jjy600901@snu.ac.kr/ Reported-by: Sangyun Kim Reported-by: Kyungwook Boo Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-2-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f3a10f7670f673f5652454664bf4f7bcdbd13487 Author: Ian Abbott Date: Thu Jun 18 11:09:13 2026 +0100 comedi: pcm711: Fix sanity check in interrupt handler [ Upstream commit f876cbfe3e066bc9e3f3210907bd534be82946c8 ] The driver requests an interrupt handler for the device before it is fully set up. For safety, the interrupt handler checks the dev->attached flag to ensure the device is fully set up, but it currently does that after dereferencing the dev->read_dev pointer which may be NULL if dev->attached is false. Move the check to avoid the possible null pointer dereference. Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/lkml/20260610115912.780131-1-jjy600901@snu.ac.kr/ Reported-by: Sangyun Kim Reported-by: Kyungwook Boo Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-7-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4699834f0f698e87b2f6b73d45850a84e413db7d Author: Ian Abbott Date: Thu Jun 18 11:09:10 2026 +0100 comedi: dt2811: Fix sanity check in interrupt handler [ Upstream commit 8dda63825752ab19fcbc2a19ecab91d128112415 ] The driver requests an interrupt handler for the device, after setting device registers to disable interrupt generation. The interrupt handler should not be called prematurely unless the user-configured I/O port base address and/or IRQ number are incorrect or the hardware is bad. For safety, the interrupt handler checks the dev->attached flag to ensure the device is fully set up, but it currently does that after dereferencing dev->read_subdev, which may be NULL if dev->attached is false. Move the check to avoid the possible null pointer dereference. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-4-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3bd63c80ce570c4fd545e49a226d89e2020c19c5 Author: Ian Abbott Date: Thu Jun 18 11:09:09 2026 +0100 comedi: das6402: Add sanity check to interrupt handler [ Upstream commit e90d0550c5b3056c8821f5cd714f80902de0fca6 ] The driver requests an interrupt handler for the device, after setting device registers to disable interrupt generation. The interrupt handler should not be called prematurely unless the user-configured I/O port base address and/or IRQ number are incorrect or the hardware is bad. For safety, check the dev->attached flag in the interrupt handler to ensure the device has been fully set up, avoiding a possible null pointer dereference of dev->read_subdev. Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/lkml/20260610115912.780131-1-jjy600901@snu.ac.kr/ Reported-by: Sangyun Kim Reported-by: Kyungwook Boo Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-3-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6b772ff3257d163900ccb8a1085c0f4993fccdee Author: Ian Abbott Date: Thu Jun 18 11:09:18 2026 +0100 comedi: quatech_daqp_cs: Fix sanity check in interrupt handler [ Upstream commit 1bc9538df6be8dac8727179d8bcc0d880648361b ] The driver requests an interrupt handler for the device before it is fully set up. For safety, the interrupt handler checks the dev->attached flag to ensure the device is fully set up, but it currently does that after dereferencing the dev->read_dev pointer which may be NULL if dev->attached is false. Move the check to avoid the possible null pointer dereference. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-12-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4f4bdfb166c0403e832d0d1fa8ef5539fc81dd18 Author: Ian Abbott Date: Thu Jun 18 11:09:15 2026 +0100 comedi: pcm818: Fix sanity check in interrupt handler [ Upstream commit 956e8478261a575d1e87490f2e5db1788b8c209d ] The driver requests an interrupt handler for the device before it is fully set up. For safety, the interrupt handler checks the dev->attached flag to ensure the device is fully set up, but it currently does that after dereferencing the dev->read_dev pointer which may be NULL if dev->attached is false. Move the check to avoid the possible null pointer dereference. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-9-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4f7ea5bca644964290db824c500f78b5d63e1222 Author: Ian Abbott Date: Thu Jun 18 11:09:11 2026 +0100 comedi: ni_at_a2150: Fix sanity check in interrupt handler [ Upstream commit e7356cdc7077a4f30fc5232a18e9fc6a4d404581 ] The driver requests an interrupt handler for the device before it is fully set up. For safety, the interrupt handler checks the dev->attached flag to ensure the device is fully set up, but it currently does that after dereferencing various pointers which may be NULL if dev->attached is false. Move the check to avoid the possible null pointer dereferences. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-5-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 28b5b935970bd79f9d13e5af85fde24f5878446c Author: Ian Abbott Date: Thu Jun 18 11:09:12 2026 +0100 comedi: ni_atmio16d: Add sanity check to interrupt handler [ Upstream commit 13f4796223489a5349b466ce54bb868f46c9fefd ] The driver requests an interrupt handler for the device, after setting device registers to disable interrupt generation. The interrupt handler should not be called prematurely unless the user-configured I/O port base address and/or IRQ number are incorrect or the hardware is bad. For safety, check the dev->attached flag in the interrupt handler to ensure the device has been fully set up, avoiding a possible null pointer dereference of dev->read_subdev. Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/lkml/20260610115912.780131-1-jjy600901@snu.ac.kr/ Reported-by: Sangyun Kim Reported-by: Kyungwook Boo Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-6-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9f8682556745a5e0088090c5e3d5e14b7117ba16 Author: Pengpeng Hou Date: Sat Jul 4 23:26:42 2026 +0800 uio: sercos3: add missing MODULE_DEVICE_TABLE() [ Upstream commit a432f68c51fc6761658445e80a798b8425fdb3dc ] The driver has a match table for the pci bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704152642.54769-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7379dac3b36d7c7f7ec67e70657db15743bab6d5 Author: Michail Tatas Date: Fri Jul 17 01:24:13 2026 +0300 USB: misc: uss720: Fix leak in get_1284_register [ Upstream commit 15902712b9e2a46649cba2f22002d05faec2a990 ] if wait_for_completion_timeout() times out in get_1284_register() then we do not destroy the reference acquired via kref_get() in submit_async_request. Add the missing kref_put in the timeout path. link: https://syzkaller.appspot.com/bug?extid=56962eb32ba0136cd330 Reported-by: syzbot+56962eb32ba0136cd330@syzkaller.appspotmail.com Signed-off-by: Michail Tatas Link: https://patch.msgid.link/allaDTUua9n5DQ0a@michalis-linux Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 692525e5cc47e49464300b6550ae0f5577058734 Author: Oliver Neukum Date: Fri Jul 10 11:55:18 2026 +0200 usb: misc: cypress_cy7c63: check result of IO [ Upstream commit 0673b919e0933541ae56bb3f0253853f696d3773 ] If the device returns a bogus short read, treat it as EIO. Actually check for IO errors. Signed-off-by: Oliver Neukum Link: https://patch.msgid.link/20260710095523.1646308-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 89e258e9bcd26c279b8619d1db445310e12556bd Author: Lucas Martins Alves Date: Tue Jul 14 13:49:49 2026 +0000 usb: musb: host: clear stale RX interrupt on three-strikes error [ Upstream commit 3a3a48487344a653f46a4aadc9ba296386eb3541 ] Unplugging a busy USB Ethernet adapter can leave a stale RX interrupt pending while the host handles MUSB_RXCSR_H_ERROR. On AM335x/DSPS platforms this can retrigger the same three-strikes error before the disconnect path completes, flooding the log and potentially leaving the host port stuck until reboot. Clear the pending endpoint RX interrupt when aborting the transfer so the error storm is broken, and rate limit the error message to avoid spamming the log while the fault path completes. Signed-off-by: Lucas Martins Alves Link: https://patch.msgid.link/20260714134941.18508-1-lucas.alves@lumal21.com.br Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1cf245c31de327ae60aa0f6a99d1c2b3d86b20f5 Author: Hans Verkuil Date: Fri Jul 10 13:07:32 2026 +0200 media: cec/core: drop cec_post_state_event call [ Upstream commit 2ff4b91e82bd76e1a6e1ff22bfc9aeda08e12a61 ] No need to call cec_post_state_event() if the next call is to cec_adap_unconfigure() since that will also call cec_post_state_event(). This fixes the case when, when the physical address is invalidated, you get two CEC_EVENT_STATE_CHANGE events: one with a non-zero log_addr_mask and one with a zero log_addr_mask. You just want to see the event with phys_addr set to f.f.f.f and log_addr_mask set to 0. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 982e4cdcb491db46723107d536626970f64d8b39 Author: Hans Verkuil Date: Fri Jul 10 11:53:17 2026 +0200 media: cec: tegra_cec: don't break off msg on NACK [ Upstream commit be627f257ce283c95fd2988080dc0db3a20d0d2a ] The Tegra CEC hardware has a bug where, if the first attempt to transmit a message is NACKed so the transmit is aborted, then the second attempt can contain corrupt data. Ensure that the full message is always transmitted to avoid hitting this bug. I suspect some internal state is not reset in the case of aborting a message due to a NACK. Signed-off-by: Hans Verkuil Reviewed-by: Mikko Perttunen Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8fc1753a4f0f2a867a7013e8a08a666c14e9147e Author: Shivaprasad G Bhat Date: Fri May 15 13:45:18 2026 +0000 scsi: qla2xxx: Handle INTx not connected while passing through [ Upstream commit 7268e509b43ac1734e1bdb7d18553f7e1080dfb4 ] The PCI_INTERRUPT_PIN reports if the device supports the INTx. However, when the device is assigned to a guest via vfio, the PCI_INTERRUPT_PIN is set to 0 (i.e none) if the line is not connected and/or the platform cannot route the interrupt. In such cases, the guest PCI_INTERRUPT_PIN is 0 and the port number becomes -1 (255, uint8_t underflow) for qla[25|27|28]xx and qla2031 devices. The flt_region_nvram is never set, and subsequently the LUN detection fails. Below warnings show the NVRAM configuration failure: []-0073:1: Inconsistent NVRAM checksum=0xffffffc0 id=HCAM version=0x100. []-0074:1: Falling back to functioning (yet invalid -- WWPN) defaults. []-0076:1: NVRAM configuration failed. Handle this case and set the port_no to devfn like its done everywhere else. Reference: commit 2bd42b03ab6b ("vfio/pci: Virtualize zero INTx PIN if no pdev->irq") Signed-off-by: Shivaprasad G Bhat Reviewed-by: Kyle Mahlkuch Link: https://patch.msgid.link/177885270578.1573.14283751510936407585.stgit@linux.ibm.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 318a85c3435e3a50b3f8bba326968e2604abe53a Author: Mikko Perttunen Date: Tue Jun 9 17:09:17 2026 +0900 gpu: host1x: Wait for timeout worker completion on channel free [ Upstream commit 7a39b9856acccc8e9b05845ca2bf62494fcd3dfa ] cdma_timeout_destroy() used cancel_delayed_work() to cancel pending timeout work when destroying the CDMA. Usually this is fine, but there is a narrow race condition where the timeout handler has started execution but has not taken cdma->lock; the channel is freed causing cdma_stop to take cdma->lock and flush the channel; host1x_cdma_deinit then proceeds with deinitializing cdma while the handler is waiting to take cdma->lock. Therefore change cdma_timeout_destroy to use cancel_delayed_work_sync instead to ensure any pending timeout work completes before proceeding. Signed-off-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-1-7c1131c0b3ad@nvidia.com Signed-off-by: Sasha Levin commit 1ff13dda3fe614d62eb22cbc25c4319ea41ba585 Author: Namhyung Kim Date: Fri Jul 10 17:32:35 2026 -0700 tools/lib/api: Fix potential double-free from fdarray__grow() [ Upstream commit eadce0f46a1d066b812c7e5aa46a33711c78a755 ] If the realloc for fda->entries succeeds but the realloc for fda->priv fails, the error path frees the newly allocated entries. However, fda->entries is neither updated to point to the new entries block nor cleared to NULL. If realloc moved the allocation to a new block, the old fda->entries pointer is now freed memory. When fdarray__exit() is later called to clean up, it executes free(fda->entries), which would trigger a double-free on that old pointer. Reported-by: Sashiko Review Closes: https://lore.kernel.org/linux-perf-users/20260710200150.11FE71F00A3A@smtp.kernel.org Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 16c9cfe5d260c16de3b10be9286625ad47b6f2e9 Author: Emmanuel Grumbach Date: Tue Jul 14 17:02:16 2026 +0300 wifi: iwlwifi: mvm: reset the smart fifo state upon FW stop [ Upstream commit a51cc8131214870af92abbceab64877b27e690c2 ] The smart fifo is a feature in the firmware configured by the driver. The driver keeps a state to remember what was the last configuration sent to the firmware. Obviously, if the firmware stops, we need to reconfigure the smart fifo. Since we didn't reset that state upon firmware stop, we thought the firmware is already properly configured and we didn't send the smart fifo configuration command as part of the init sequence. Reset the smart fifo state in iwl_mvm_stop_device() so that we will properly send the command during the init that will come later. Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260714165826.7d3c5efe2d1a.I16b23c328a677257257f695fa6f439e41fbcd081@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit d17e17c6771d11e9198165d62ff46fd04138befd Author: Jingyi Wang Date: Tue Jun 23 02:05:36 2026 -0700 remoteproc: core: cancel crash_handler work in rproc_add() error path [ Upstream commit 0ec167625b4fea30b26da33c188e853ff25d5583 ] Ensure crash_handler work is cancelled before tearing down rproc resources to avoid accessing freed memory. Signed-off-by: Jingyi Wang Link: https://lore.kernel.org/r/20260623-rproc-attach-issue-v3-3-8e24310707ce@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 62906ab364d9c090da62e5e45f8eb05ca0507a72 Author: Jingyi Wang Date: Tue Jun 23 02:05:35 2026 -0700 remoteproc: qcom: Check subdev start status in rproc_stop() [ Upstream commit f44ae8ce156a387b07d40e2d6a0ef979a2748aa1 ] For rproc that doing attach, rproc_start_subdevices() is called only when attach successfully. If rproc_report_crash() is called in the attach function, rproc_boot_recovery()->rproc_stop()->rproc_stop_subdevices()-> glink_subdev_stop() could be called and cause NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000300 Mem abort info: ... pc : qcom_glink_smem_unregister+0x14/0x48 [qcom_glink_smem] lr : glink_subdev_stop+0x1c/0x30 [qcom_common] ... Call trace: qcom_glink_smem_unregister+0x14/0x48 [qcom_glink_smem] (P) glink_subdev_stop+0x1c/0x30 [qcom_common] rproc_stop+0x58/0x17c rproc_trigger_recovery+0xb0/0x150 rproc_crash_handler_work+0xa4/0xc4 process_scheduled_works+0x18c/0x2d8 worker_thread+0x144/0x280 kthread+0x124/0x138 ret_from_fork+0x10/0x20 Code: a9be7bfd 910003fd a90153f3 aa0003f3 (b9430000) ---[ end trace 0000000000000000 ]--- Introduce "subdevs_started" flag to indicate rproc_start_subdevices() has been called successfully. Ensure subdevices are only stopped if they have been started. Signed-off-by: Jingyi Wang Link: https://lore.kernel.org/r/20260623-rproc-attach-issue-v3-2-8e24310707ce@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5252d55d9044614bb0a46d444ef34ca1a5d756c8 Author: Yousef Alhouseen Date: Tue Jun 30 12:52:57 2026 +0200 media: go7007: avoid undefined shifts in MPEG-4 headers [ Upstream commit 41f82777e547732460290ceb28fcc7c1b95ef192 ] The byte-alignment paths can call CODE_ADD() with a zero bit length. The macro then shifts an int by name.b, which can be 32 after the preceding bit was flushed. vti_bitlen() can likewise shift a signed int into its sign bit while searching for the bit length, and the package mask construction can shift by the full type width. Make zero-length additions a no-op, derive the bit length with fls(), and build the mask with GENMASK(). Signed-off-by: Yousef Alhouseen Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 8c915df0972f65cd07afe25029fb6e8525a571ca Author: Pengpeng Hou Date: Tue Jun 30 14:56:36 2026 +0800 media: cx18: stop VBI start-code scan before short tail [ Upstream commit bf533acaaa7dee21d49bcaabf8e813ea36bddcd8 ] compress_sliced_buf() scans one byte at a time while testing a four-byte VBI start code. The final iterations can read beyond the remaining buffer tail. Stop the scan once fewer than four bytes remain. Signed-off-by: Pengpeng Hou Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f3aad2511a927a60dc63842ebb51f9d45de9d88f Author: Pengpeng Hou Date: Tue Jun 30 15:19:33 2026 +0800 media: ivtv: stop VBI start-code scan before short tail [ Upstream commit f373cf17fb8e7a530bc6e1e36fc41cb5dab2cdaa ] compress_sliced_buf() scans one byte at a time while testing a four-byte VBI start code. The final iterations can read beyond the remaining buffer tail. Stop the scan once fewer than four bytes remain. Signed-off-by: Pengpeng Hou Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1f27b31ce1dfb8d87974e565c1738aafba12f11d Author: Jurison Murati Date: Wed Jun 10 12:22:37 2026 +0200 media: i2c: ov8865: Program the sensor on stream start [ Upstream commit 4e1446ac169a1a621ba90502ab8db3be821fe726 ] The sensor registers are only written in the runtime PM resume handler; ov8865_set_fmt() merely stores the requested mode, relying on the sensor being runtime suspended between uses so that the next resume applies it. That assumption breaks when something keeps the sensor powered. On IPU3 platforms, ipu_bridge instantiates the VCM device with a DL_FLAG_PM_RUNTIME device link to the sensor, so a userspace process holding the VCM subdev open (e.g. wireplumber's camera monitor) pins the sensor runtime-active. A subsequent set_fmt() then never reaches the hardware: the sensor keeps streaming the mode programmed on the last resume while the CSI-2 receiver expects the newly negotiated format. On a Surface Book 2 (IPU3, ov8865 + dw9719 VCM), requesting the 3264x2448 mode while the hardware was left programmed for the 1632x1224 binned mode makes ipu3-cio2 report "frame sync error" and "payload length is 10340352, received 2585088" (exactly one binned frame) for every frame, and the inverse case stalls the stream after a single frame. Camera applications end up displaying one bogus frame forever. Program the sensor configuration and apply the control values on stream start instead, where the negotiated mode is always current, and only write the configuration in the runtime PM resume handler when resuming with the stream already started. Signed-off-by: Jurison Murati Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 5c182d82b1422434131d145c3ea5c94718962041 Author: Lucas Stach Date: Mon May 11 10:51:47 2026 +0200 drm/etnaviv: check all modules for idle after reset [ Upstream commit 1006d1f7c03d92b28c252333836635df8e165401 ] While the FE is an important part of the GPU, which needs to be idle after reset, all other modules should be idle after a proper reset. Check all present modules for being idle to determine whether the reset was successful. Reviewed-by: Christian Gmeiner Link: https://patch.msgid.link/20260511085148.652256-1-l.stach@pengutronix.de Signed-off-by: Lucas Stach Signed-off-by: Sasha Levin commit 364ba1161aea50c575b295d03f9795221fb88256 Author: Jurison Murati Date: Wed Jun 10 12:22:36 2026 +0200 media: i2c: ov8865: Drop the runtime PM usage count on stream failure [ Upstream commit 3fe797a12bfa9a49aa998ee722e5f25c957b9b15 ] ov8865_s_stream() takes a runtime PM reference when enabling the stream, but returns without releasing it if ov8865_sw_standby() fails, leaving the reference unbalanced and the sensor powered indefinitely. The same applies to a failure while disabling the stream, in which case the reference acquired at stream start is never dropped. Drop the reference in a single place, both when disabling the stream and on failure, and only update the streaming state on success. Signed-off-by: Jurison Murati Reviewed-by: Daniel Scally Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 8c37d932da4004c1f84f93f41e5cf3f93b4cfc1e Author: Haoxiang Li Date: Wed Apr 1 11:05:55 2026 +0800 iwlwifi: dvm: add missing cleaup for on error path [ Upstream commit 94280e6e0c69a5327e377803732f494d8b5a74cd ] In iwlagn_tx_agg_start(), call iwlagn_dealloc_agg_txq() to clear bit on error path. Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260401030555.541685-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit cfad7d434f07f86cac94cdd263bdec797e964f12 Author: Hari Mishal Date: Thu Jul 9 14:30:32 2026 +0200 nvme: bound ns descriptor header and body to identify buffer [ Upstream commit 3c568b35a0d309acb40746552bec2af24cd550ef ] nvme_identify_ns_descs() allocates a buffer and gives it to the controller, which populates it and then iterates the buffer with variable byte increments that vary by type and body size. But, there is no bounds check inside the iteration itself except the loop bound itself. Fix this by checking and stopping iteration if the next header or its declared body would go past the buffer itself. Assisted-by: gkh_clanker_t1000 Reviewed-by: Christoph Hellwig Signed-off-by: Hari Mishal Signed-off-by: Greg Kroah-Hartman Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit a4fc90fe36b71d56856fb88fe8eb089c3f46fa42 Author: Charles Keepax Date: Wed Jul 8 13:29:48 2026 +0100 soundwire: intel_auxdevice: Add cs42l44 to wake_capable_list [ Upstream commit d08e4d9197396ceb906715d976b63aed0c5cc8e5 ] Add cs42l44 to the wake_capable_list because it can generate jack events whilst the bus is stopped. Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260708122948.1502227-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 9ca9b2b4b92aec80954493312d6803274c9ef545 Author: Bard Liao Date: Fri Jul 3 09:16:56 2026 +0800 soundwire: dmi-quirks: add a global ghost list [ Upstream commit b7a5d101d7d267922e828c40135bcaccf8cfb3bf ] Not like other ghost devices, the 0x000000D010010500 ADR doesn't belong to any codec. We should disable it in all devices. Signed-off-by: Bard Liao Reviewed-by: Charles Keepax Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260703011656.2572959-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 695486d2a3aa3f80bbe9145d53f1e7bfe3cd63f4 Author: Niranjana Vishwanathapura Date: Mon Jul 13 13:23:16 2026 -0700 drm/xe: only resume exec queues that were actually suspended [ Upstream commit 65f40fa5022bcdb90d3a39e4948adf2aa16732a3 ] A consumer-issued suspend() can fail (e.g. the queue is killed, banned or wedged), leaving the queue un-suspended. The consumer must then not issue the matching resume(): resuming a queue that was never suspended is incorrect. Add an lr.suspended flag to struct xe_exec_queue that records whether a consumer suspend() succeeded and a matching resume() is still owed. Set it on a successful suspend() in the preempt-fence path, clear it on resume(), and only resume queues that have it set. In resume_and_reinstall_preempt_fences() also skip queues that have since been reset/killed/banned/wedged: such a queue's suspend may not have completed (suspend_pending can still be set, e.g. a preempt fence signalled with -ENOENT without waiting), so resuming it would trip the !suspend_pending assert in the backend. Leave it marked suspended and let teardown resolve its state. A queue is only ever suspended by a single consumer at a time (preempt-fence mode and hw engine group fault mode are mutually exclusive), so a single flag is sufficient. Assisted-by: Github-Copilot:Claude-opus-4.8 Signed-off-by: Niranjana Vishwanathapura Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260713202317.2187787-9-niranjana.vishwanathapura@intel.com Signed-off-by: Sasha Levin commit 3fddb2971693d018222dd23090c1a59b68885b61 Author: Hans Verkuil Date: Tue May 19 13:33:38 2026 +0200 media: em28xx: use vb2_video_unregister_device [ Upstream commit 7c8bf63b79371f5b57da1bd1401bd420180ac6e6 ] Use vb2_video_unregister_device instead of video_unregister_device to ensure any streaming is correctly stopped at unregister time. Signed-off-by: Hans Verkuil Tested-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7e474104882fe65f1d44f0ae6b7248f9acc6f76f Author: Hans Verkuil Date: Tue Jun 16 14:42:16 2026 +0200 media: em28xx: requeue buffers if start_streaming fails [ Upstream commit 67f87b104f4ef3108607ac9d8fa2075b13ed314d ] If start_streaming fails, then all queued buffers must be returned to vb2 in state QUEUED. Otherwise it will trigger a WARN_ON. Signed-off-by: Hans Verkuil Tested-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4ea3369f96e542b58e5d61354d20f2fbb5bb548b Author: Hans Verkuil Date: Tue Jun 16 14:00:12 2026 +0200 media: em28xx: dev_info->pr_info since dev has been freed [ Upstream commit c132b07f7e5853c0df35a9b94b8e204cdc6afdef ] In em28xx_free_device() dev_info passed &dev->intf->dev, but that device can be freed already. Just use pr_info instead. Signed-off-by: Hans Verkuil Tested-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a58fc54764c99184471ad33b0200b9511c5b3845 Author: Mike Tipton Date: Mon Jun 29 13:33:36 2026 -0700 pmdomain: qcom: rpmhpd: Skip retention by default [ Upstream commit 7178817f190496f2bfdec181fb4aa72832448468 ] Retention is very rarely an operational corner. In the majority of cases, HW cannot operate properly at Retention levels and so the minimum operational level when enabling a rail is the first corner above Retention. A small subset of always-on use cases can operate at Retention, but those aren't controlled from HLOS. Currently, we allow Retention by default and only disallow it special cases. But this leaves us open to various failures when the PD is enabled without first being voted to an OPP above Retention. Such as when a child GDSC PD requests to enable its parent RPMh PD. In this case, the GDSC would get stuck powering on. Newer chips have started supporting Retention on rails that didn't previously (such as for MMCX). Instead of adding more special cases to skip Retention on MMCX, start skipping Retention by default since it's almost never desired from an HLOS perspective. Signed-off-by: Mike Tipton Reviewed-by: Konrad Dybcio Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 325eb7e7bdd10222cfa2a01e9d04e4dd2f5df33f Author: Pengpeng Hou Date: Sat Jul 4 20:46:09 2026 +0800 crypto: keembay - add missing MODULE_DEVICE_TABLE() [ Upstream commit b73b71df4cb4ca241165ad31218c82dfe489147c ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 375c0fbc096f4d8e4463fe3d8653fd45cfea11f8 Author: Pengpeng Hou Date: Sat Jul 4 23:22:30 2026 +0800 pinctrl: sx150x: add missing MODULE_DEVICE_TABLE() [ Upstream commit 5fe4b12c087db3e565f53b87f1dafdf2f0d1ee0f ] The driver has a match table for the i2c bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e55e1e2cc8fffcbff979654b2105955da98e348a Author: Gabriel Prostitis Date: Mon Jun 1 08:44:11 2026 +0200 USB: gadget: inode: fix mm lifetime handling [ Upstream commit a1c33c80e11ecd5c3310a38c4be324095dd85ac5 ] priv stores a pointer to the submitting task's mm_struct, but does not currently hold a reference to it while async requests are pending. This can result in a use-after-free if the task exits before completion handling finishes. Take a reference with mmgrab() when queuing the read request and release it with mmdrop() on request completion. Reported-by: Gabriel Prostitis Signed-off-by: Gabriel Prostitis Acked-by: Alan Stern Link: https://patch.msgid.link/20260601-mm-uaf-fix-v2-2-3c942a707bce@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit df727ceba718daf42516335579ab24aa001cc00a Author: David Laight Date: Mon Jun 8 10:55:21 2026 +0100 usb_string_copy: Use kzalloc() to avoid leaking old data [ Upstream commit 057df423bf4747091cf942af57307627e941e1fb ] If the string is read while being updated (which is why the copy is done in place) and the new string is longer than the old one, then the reader can read memory that isnt part of either string. Use memcpy() to copy the known length string instead of strcpy. Signed-off-by: David Laight Link: https://patch.msgid.link/20260608095523.2606-37-david.laight.linux@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit df911277f9bf9dd1749d736d23fd76bb7a4540bb Author: Xu Rao Date: Thu Jun 11 17:12:28 2026 +0800 usb: gadget: u_audio: clean up capture endpoint on feedback failure [ Upstream commit 7a0d4f60da261f61dcb50c8e05fa53cc7d4d4427 ] u_audio_start_capture() enables the capture OUT endpoint, queues capture requests and marks the stream active before setting up the optional feedback endpoint. If feedback endpoint configuration or enablement fails, the function returns an error while the capture endpoint remains enabled and its requests may remain queued. The current code even leaves TODO comments at these return paths. Unwind the already started capture endpoint on these failures. Also set fb_ep_enabled only after usb_ep_enable() succeeds, so the software state matches the endpoint state. Signed-off-by: Xu Rao Link: https://patch.msgid.link/183621D513E0DE8B+20260611091229.4017443-1-raoxu@uniontech.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2f5d9479c2550d60caacd44d34286a3020983546 Author: Haoxiang Li Date: Sat Jun 20 20:06:31 2026 +0800 usb: fsl_qe_udc: check qe_alloc_request() failure in ch9getstatus() [ Upstream commit 612551bf7cf7113b8bbd5e8c1eea86d9427c2f95 ] qe_alloc_request() may return NULL on allocation failure. ch9getstatus() passes the return value directly to container_of() and then immediately dereferences the resulting qe_req pointer. Check the allocation result before using it and stall the control request on failure. Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260620120631.2894977-1-haoxiang_li2024@163.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8537572fa1629cd31e622c5cdc9865d8c1386e88 Author: Aniket Randive Date: Mon Jul 6 15:07:49 2026 +0530 serial: qcom_geni: Disable closing_wait for console to prevent shutdown timeout [ Upstream commit acba38e675dd66f52925cb9edf9ed8db16335875 ] During system power-off, systemd closes the console UART and blocks in tty_wait_until_sent() waiting for pending TX completion before uart_shutdown() can cancel pending TX operations. With the default closing_wait of 30s, this causes a watchdog reset when systemd is responsible for watchdog feeding. Set closing_wait to ASYNC_CLOSING_WAIT_NONE in startup() for console ports to bypass tty_wait_until_sent() on close, allowing uart_shutdown() to cancel TX commands cleanly. This change doesn't impact regular ports functionality. Signed-off-by: Aniket Randive Link: https://patch.msgid.link/20260706093749.836121-1-aniket.randive@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2dc1da9b279866efdcbe2fc267a3c933bae29d59 Author: Haoxiang Li Date: Tue Jun 23 22:05:39 2026 +0800 tty: serial: pch_uart: add check for pci_get_slot() [ Upstream commit 970ede67de0e3f6a1e707ec99ae49d80bf3f2966 ] Add check for pci_get_slot() to prevent a potetial null pointer dereference in pch_request_dma(). Signed-off-by: Haoxiang Li Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260623140539.2272473-1-haoxiang_li2024@163.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e49e1848a214c952669e9e97800372123950a155 Author: Rahul Bukte Date: Wed Jun 10 14:41:30 2026 +0900 serial: 8250: force synchronous probe for the ISA and PNP drivers [ Upstream commit 31e11af34e2c7cc61e25533ab877b1f9cc3eb528 ] On x86_64 defconfig, booting with driver_async_probe=serial hangs in early init. The 8250 PNP driver is put onto the async probe pool. serial8250_register_8250_port() runs in a kworker concurrently with the ISA registration done from the serial8250_init() initcall resulting in a deadlock or NULL dereference. - Deadlock: serial_core_register_port() holds port_mutex across serial_core_add_one_port() uart_configure_port() autoconfig_irq() probe_irq_on() async_synchronize_full(), which waits for the async probe pool to drain. The async PNP worker reaches the "port already in use" check and tries to unregister it. serial8250_register_8250_port() uart_remove_one_port() serial_core_unregister_port() This blocks on port_mutex. The init thread waits for the worker and the worker waits for the init thread. - NULL deref: when the worker instead observes a slot whose port.dev is set but whose port_dev has not yet been populated, it hits the null pointer on the call to serial_core_get_ctrl_dev() in serial_core_unregister_port(). Signed-off-by: Rahul Bukte Link: https://patch.msgid.link/20260610054130.2825182-1-rahul.bukte@sony.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d4b22438d4a22d6ed99d0320e254a20711942a50 Author: Xu Rao Date: Mon Jul 6 17:25:00 2026 +0800 mmc: block: reject invalid perdev_minors before division [ Upstream commit 5253aee00a4383cb0482d5e99bde48b8054ae2c0 ] The mmcblk.perdev_minors module parameter is parsed as a signed int and is used during mmc_blk_init() to compute the number of supported block devices. Passing perdev_minors=0 makes the init path divide by zero when it computes max_devices. Negative values are invalid as well and would make max_devices negative before it is later used as an IDA limit. Reject non-positive perdev_minors values before registering any mmcblk resources. Signed-off-by: Xu Rao Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 715a974c078389e305bad1ebd40406a9e56140c5 Author: Arnd Bergmann Date: Thu Jun 18 16:32:47 2026 +0200 media: v4l2-tpg: reduce stack usage for kasan builds [ Upstream commit c49cdaafa443ccf861a72d3191121294742c28c7 ] tpg_fill_plane_buffer() is a rather complex function. While there is nothing wrong with it per se, I have run into corner cases with clang-22 on s390 using KASAN that makes it run out of registers and blow the stack warning limit from excessive spills: drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2629:6: error: stack frame size (1560) exceeds limit (1536) in 'tpg_fill_plane_buffer' [-Werror,-Wframe-larger-than] 2629 | void tpg_fill_plane_buffer(struct tpg_data *tpg, v4l2_std_id std, Forcing the two largest callees out of line completely avoids the problem and prevents all the register spills, with the stack usage for each function going down to a few bytes for the local variables. Arguably this is a problem caused by clang rather than the code, but a noinline_for_stack annotation is an easy workaround. Signed-off-by: Arnd Bergmann Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 74ef90eb23fc7e390217169a46f583aed02c0a45 Author: Pengpeng Hou Date: Sat Jul 4 20:26:31 2026 +0800 media: cec: tegra: add missing MODULE_DEVICE_TABLE() [ Upstream commit 8dcf23edaf4bdf22259f6a47cfddc8bb1467425c ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9589e491a12c607a0a8842494a1836ac28408fb2 Author: Chris Lew Date: Mon Apr 6 09:59:50 2026 +0530 rpmsg: char: Check for ongoing chrdev destroy [ Upstream commit 1f9c2897afb0fe86c1fdf4f5e23c5fb8f7442f6d ] A null pointer panic is observed when stopping a remoteproc and closing a character device using the RPMSG_DESTROY_EPT_IOCTL. There is a race where each context calls rpmsg_chrdev_eptdev_destroy(). The thread that runs second will call cdev_device_del() for a second time, which fails because the first call already removed the device from sysfs. Add a check at the beginning of destroy and exit early if the destroy call has already been done. [ 26.654130] Call trace [ 26.656658] kernfs_find_and_get_ns+0x28/0x8 [ 26.661140] sysfs_unmerge_group+0x2c/0x7 [ 26.665357] dpm_sysfs_remove+0x38/0x8 [ 26.669305] device_del+0xa4/0x3e [ 26.672811] cdev_device_del+0x28/0x7 [ 26.676675] rpmsg_chrdev_eptdev_destroy+0x68/0x98 [ 26.682765] rpmsg_eptdev_ioctl+0x130/0x11c8 [ 26.688318] __arm64_sys_ioctl+0xb4/0x10 [ 26.692448] invoke_syscall+0x50/0x12 [ 26.696312] el0_svc_common.constprop.0+0xc8/0xf [ 26.701151] do_el0_svc+0x24/0x3 [ 26.704570] el0_svc+0x40/0x17 [ 26.707810] el0t_64_sync_handler+0x120/0x13 [ 26.712288] el0t_64_sync+0x1a0/0x1a Signed-off-by: Chris Lew Signed-off-by: Vishnu Santhosh Link: https://lore.kernel.org/r/20260406-rpmsg-char-fix-chrdev-destroy-race-v1-1-7317434fa246@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 42ba1a68b06317154f1c4dd096673803b050a60b Author: Pranjal Shrivastava Date: Mon Jun 15 23:50:34 2026 +0000 PCI/ATS: Ensure pci_ats_supported() is PF-aware for VFs [ Upstream commit 4f2cd6091ac41566a7300f5a4590d20a99aaa8bc ] Update pci_ats_supported() to additionally check the associated PF's status when called on a VF. This ensures that PF-level quirks and untrusted status are correctly propagated to VFs, providing a robust support check that aligns with the kernel's PF-centric ATS configuration model and is immune to the timing of VF-specific fixups. Reviewed-by: Jason Gunthorpe Reviewed-by: Samiullah Khawaja Reviewed-by: Nicolin Chen Reviewed-by: Lu Baolu Reviewed-by: Kevin Tian Acked-by: Bjorn Helgaas Signed-off-by: Pranjal Shrivastava Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit aad4d251f61dd829d3cfa0b500fe7109d1bd5f2a Author: Pengpeng Hou Date: Sat Jul 4 12:06:51 2026 +0800 ASoC: codecs: max98396: Unwind supplies on resume failure [ Upstream commit d20de7409dfa8e3341af7f157cd42130bd4ba3a7 ] max98396_resume() enables the core, pvdd, and vbat supplies before leaving cache-only mode, resetting the device, and replaying cached register state. The function currently ignores regcache_sync() failures, and the optional pvdd/vbat enable failures return without unwinding supplies that were already enabled in this resume attempt. Rework the function to use common error labels. This propagates sync failures, restores cache-only/dirty state on failed cache replay, and disables each supply acquired by this resume path before returning the error. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704040651.47558-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit dac12cf65300841e66e8b0c6f7bdbe630e61a9fb Author: Qingtao Cao Date: Wed Jun 3 11:06:11 2026 +1000 bus: mhi: core: Fix sys error transition latency [ Upstream commit 22568e8f13a42ab69b7d624741768cbf15dded74 ] Bring forward the idea to fix the power down latency in mhi_pm_disable_transition() further to mhi_pm_sys_error_transition() so that the transition into system error (triggered by AT!RESET) in the modems won't have to return only after the timeout of up to 24 seconds. Once the device gets reset, there is no guarantee that it will send an interrupt to indicate the state transition. So polling is the sensible option here. Signed-off-by: Qingtao Cao [mani: commit log] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Krishna Chaitanya Chundru Link: https://patch.msgid.link/20260603011333.3306102-2-qingtao.cao.au@gmail.com Signed-off-by: Sasha Levin commit 13504342b2b0ab4a7d09586263a379db8d0e27f3 Author: John Garry Date: Mon Jul 6 12:54:02 2026 +0000 nvme: don't reference NS after unlocking in nvme_ns_head_ctrl_ioctl() [ Upstream commit 77c57daf98a2ad95ec9ac1371caeff8939cc1f58 ] In nvme_ns_head_ctrl_ioctl(), once we drop the SRCU read lock we should not reference the NS to lookup the controller, so use the available controller pointer directly. Reviewed-by: Christoph Hellwig Signed-off-by: John Garry Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 371bdf10f5e76d5aa8dc60b6296daf1aff65f6e5 Author: Alex Deucher Date: Mon Jun 15 18:55:21 2026 -0400 drm/amdgpu/gfx11: WARN() rather than BUG() for invalid SDMA engine [ Upstream commit c24edbd5ae0e4f24e0179e8c9f22a867016177bb ] There's no need to crash the kernel for these cases. Reviewed-by: Kent Russell Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a7755cb594dc78ea3745e3ef0a9792906b66d27b Author: Alex Deucher Date: Mon Jun 15 18:57:29 2026 -0400 drm/amdgpu/atomfirmware: WARN() rather than BUG() [ Upstream commit d7c595044965c826e6f3ce30590d3ec4399cd633 ] There's no need to crash the kernel for this case. Just return an error. Reviewed-by: Kent Russell Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2164a233264d9b5b6f90304505f66aaa2fc39580 Author: Deepanshu Kartikey Date: Sun Jun 21 09:28:41 2026 +0530 udf: avoid recursive s_alloc_mutex deadlock when freeing AED blocks [ Upstream commit 31e5e0c8c8e2617eb9f7a20c1cf5df23f592ade2 ] udf_table_prealloc_blocks() and udf_table_new_block() call udf_delete_aext() on the unallocated-space-table inode while holding sbi->s_alloc_mutex. When the deleted allocation descriptor empties an allocation-extent (AED) block, udf_delete_aext() returns that block to free space via udf_free_blocks(). For a table-managed partition that path is udf_free_blocks() -> udf_table_free_blocks() -> mutex_lock(&sbi->s_alloc_mutex), i.e. the task tries to acquire a mutex it already holds. On a PREEMPT_RT kernel the rtmutex deadlock detector reports this as -EDEADLK: rtmutex deadlock detected WARNING: kernel/locking/rtmutex.c:1698 at rt_mutex_handle_deadlock udf_table_free_blocks fs/udf/balloc.c:376 [inline] udf_free_blocks+0xa8c/0x1900 fs/udf/balloc.c:678 udf_delete_aext+0x4f5/0xc00 fs/udf/inode.c:2381 udf_table_prealloc_blocks fs/udf/balloc.c:544 [inline] udf_prealloc_blocks+0xbd4/0x10e0 fs/udf/balloc.c:702 On a non-RT kernel the same path is a hard self-deadlock (or a lockdep recursive-locking splat). It is reachable from a crafted UDF image via the write/sendfile path. The allocator already refuses to recurse on the add side: see the comment in udf_table_free_blocks() explaining why it must not call udf_add_aext() while holding s_alloc_mutex. Apply the same rule to the delete side. Let udf_delete_aext() report the AED block it would otherwise free through a new out-parameter, and have the two callers that hold s_alloc_mutex free it after dropping the lock. The block is already unlinked from the inode's descriptor chain by then, so nothing can reference it in the meantime. All other callers pass NULL and keep freeing the block inline, exactly as before. The out-parameter is pre-initialised with the reserved partition number 0xFFFF, which can never name a real block, so the caller can tell whether a block was handed back. Reported-by: syzbot+6a680377e13041c19d50@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6a680377e13041c19d50 Signed-off-by: Deepanshu Kartikey Link: https://syzkaller.appspot.com/bug?extid=6a680377e13041c19d50 Link: https://patch.msgid.link/20260621035841.56194-1-kartikey406@gmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 17eaa5804977c45200fa863cd51d8973e12c0c84 Author: Kyle Zeng Date: Fri Jun 12 15:58:46 2026 -0700 udf: validate extent partition references in udf_current_aext() [ Upstream commit 120ec50984b8645232c2c004310dd94ceff5520e ] Long allocation descriptors carry an on-disk extLocation.partitionReferenceNum. udf_current_aext() copies that value into a kernel_lb_addr and returns it to several consumers. If the partition reference is outside s_partitions, callers can later index s_partmaps out of bounds. The truncate/free path can pass such an extent to udf_free_blocks(), where the invalid partition reference causes a slab out-of-bounds read. Validate eloc->partitionReferenceNum in udf_current_aext() before returning a decoded extent. This rejects invalid file extents and indirect allocation descriptor extents in the common parser, so callers do not need to duplicate the partition-map bounds check. Assisted-by: Codex:gpt-5.5 Signed-off-by: Kyle Zeng Link: https://patch.msgid.link/20260612225846.97678-1-kylebot@openai.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 782ceea4d6147171f5e6f88620a90c76ae53ecc6 Author: Devansh Soni Date: Fri Jun 19 18:27:24 2026 +0530 staging: rtl8723bs: fix missing unregister_netdev on sdio_alloc_irq failure [ Upstream commit 51b554f1a758570159a770983c7a0ccd7c761491 ] In rtw_drv_init(), if rtw_drv_register_netdev() succeeds but sdio_alloc_irq() fails, the error path jumps to free_if1 and calls rtw_sdio_if1_deinit(). However, rtw_sdio_if1_deinit() calls rtw_free_netdev() without a preceding unregister_netdev(), freeing a still-registered netdev but leaving stale sysfs entries behind. Signed-off-by: Devansh Soni Link: https://patch.msgid.link/20260619125724.12458-1-devanshsoni874@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1cd04bccf9de56096057b3055c063d42fcc3d211 Author: Xixin Liu Date: Thu Jun 25 10:00:00 2026 +0800 nvme: zns: cap zone report nr_zones by DMA buffer size [ Upstream commit 09c9062d4f62199a634a45e2bb9e6e8e572cc78c ] With Partial Report (PR=1), the Number of Zones (NZ) field in the report header must equal the number of zone descriptors fully transferred in the DMA buffer (ZNS Command Set Specification Rev 1.2, section 3.4.2). nvme_ns_report_zones() does not cap the parse loop by max_in_buf derived from buflen. Cap nz with min3() over the device-reported count, nr_zones - zone_idx, and max_in_buf. Signed-off-by: Xixin Liu Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 8865553ded8f3349008969fa1301b4fda582eb7e Author: Xixin Liu Date: Wed Jul 1 14:30:00 2026 +0800 nvme-auth: use crypto_memneq for DH-HMAC-CHAP response comparison [ Upstream commit 3a6d89836ab09d53f4c32c57588689a378ce4363 ] DH-HMAC-CHAP authentication compares HMAC response digests with memcmp(). Standard memcmp() may stop at the first differing byte, which can leak timing information to a remote attacker and allow incremental recovery of the expected digest. Use crypto_memneq() for constant-time comparison on both the host path that validates the controller Success1 response and the target path that validates the host Reply digest. Other memcmp() uses in the NVMe auth code (e.g. fixed string prefix checks) are not security-sensitive and are left unchanged. Signed-off-by: Xixin Liu Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit e7a1496612cffb7cae9a509d39ea53cd118610d8 Author: John Garry Date: Tue Jun 30 10:27:17 2026 +0000 nvme: handle positive error codes in nuse_show() [ Upstream commit dd516cd7624648c71d338d99368587f10ecc9f0b ] Function __nvme_submit_sync_cmd() returns a positive error code for NVMe errors. Otherwise, we get 0 for success or a negative error code for a kernel error. In nuse_show() -> ns_{head}_update_nuse() -> nvme_identify_ns() -> nvme_submit_sync_cmd() -> __nvme_submit_sync_cmd(), we then may get a positive error code returned. Function nuse_show() - being a device attr handler - should return the number of bytes written to the buffer or a negative error code. Convert any positive NVMe error code to -EIO. Signed-off-by: John Garry Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit be8d29f656568b7476ed928f0fa488ff35262837 Author: Tanmay Shah Date: Mon Jun 29 17:48:05 2026 -0700 remoteproc: core: Full attach detach during recovery [ Upstream commit d93ffd549fb4df18c934ca7a47d4128a18c718cb ] Current attach on recovery mechanism loads the clean resource table during recovery, but doesn't re-allocate the resources. RPMsg communication will fail after recovery due to this. Fix this incorrect behavior by doing the full detach and attach of remote processor during the recovery. This will load the clean resource table and re-allocate all the resources, which will set up correct vring information in the resource table. Signed-off-by: Tanmay Shah Link: https://lore.kernel.org/r/20260630004806.3835488-2-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 47f526465e60167a88276c21f4d038d41126ca93 Author: Jerome Brunet Date: Mon Jul 6 11:32:11 2026 +0200 clk: sunxi-ng: fix ccu probe clock unregister on error [ Upstream commit 81f4ddc9f7e0c11d3e9d24d0f30023845a02f7ee ] When registering clocks with sunxi_ccu_probe(), the number of ccu_clocks and the number of hw clocks might be different, eventhough they usually are the same. If they are different, it could lead to out-of-bound access or registered clock left behind on error. Use a different variable when iterating on hw clocks so every registered clock, and only those, gets unregistered on error. Reported-by: Sashiko Closes: https://lore.kernel.org/r/20260629131254.7E34C1F00A3A@smtp.kernel.org Reviewed-by: Chen-Yu Tsai Signed-off-by: Jerome Brunet Link: https://patch.msgid.link/20260706-a733-rtc-v4-3-f330728db3d3@baylibre.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 8ca6c61f06be19015ade0d3a36d7b07438303255 Author: Marek Szyprowski Date: Wed Jun 3 10:39:35 2026 +0200 mmc: dw_mmc: stop and complete DMA also in STATE_DATA_BUSY state [ Upstream commit cb3fcb8d118b874178251d1f02613f60d25e4ddc ] When transfer was stopped in STATE_DATA_BUSY state, there was no call to dma_ops->cleanup function, so the DMA mapped buffer was never properly unmapped. Fix this by calling dw_mci_stop_dma() function also in that state to ensure proper cleanup call when DMA transfer was used. Signed-off-by: Marek Szyprowski Reviewed-by: Shawn Lin Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit a6ab601b19f474018791cb9e7d453771d800e4f4 Author: Pengpeng Hou Date: Sat Jul 4 20:41:15 2026 +0800 mmc: sdhci-of-ma35d1: add missing MODULE_DEVICE_TABLE() [ Upstream commit 9b3732cce41d177acac731e0b8024d72f0dfde38 ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. Signed-off-by: Pengpeng Hou Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 0155039139c4251a3d29fe00fdce9f794ccc375f Author: Ben Dooks Date: Mon Jun 22 15:50:36 2026 +0100 mmc: cqhci: fix to missed endian conversions [ Upstream commit 0aae2c73175821a71c0e20607f8e333be5b71940 ] Fix two places where the wrong type or conversion of little-endian types to fix the following sparse warnings: drivers/mmc/host/cqhci-core.c:487:15: warning: incorrect type in assignment (different base types) drivers/mmc/host/cqhci-core.c:487:15: expected restricted __le32 [usertype] drivers/mmc/host/cqhci-core.c:487:15: got int drivers/mmc/host/cqhci-core.c:566:19: warning: incorrect type in assignment (different base types) drivers/mmc/host/cqhci-core.c:566:19: expected unsigned long long [usertype] *task_desc drivers/mmc/host/cqhci-core.c:566:19: got restricted __le64 [usertype] * Signed-off-by: Ben Dooks Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 0357617a838b12fb99a6bcb52a30012e2d1ec45e Author: Pengpeng Hou Date: Tue Jun 23 14:11:12 2026 +0800 mmc: moxart: report DMA completion timeout [ Upstream commit e29e650077e01dddf69bc8fac31e0cd60043aa7c ] moxart_transfer_dma() waits for the DMA completion but ignores wait_for_completion_interruptible_timeout(). It then unconditionally reports the full transfer length in data->bytes_xfered. Terminate the DMA channel and set data->error when the wait is interrupted or times out. Only report host->data_len as transferred after the completion is observed. Signed-off-by: Pengpeng Hou Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 5bc117ac8a9194654e2f3ad6e4f79db9e80ccd02 Author: Pengpeng Hou Date: Sat Jul 4 20:22:30 2026 +0800 gpio: sifive: add missing MODULE_DEVICE_TABLE() [ Upstream commit 8fe6fa0f223f44b8b869319d1b9c383749aa147b ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704122230.75964-1-pengpeng@iscas.ac.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 8257e6426d1e1dd7a7555513d112a5127d9f2def Author: David Heidelberg Date: Sat Jun 27 19:50:15 2026 +0200 dt-bindings: arm: qcom,ids: Add SoC ID for Snapdragon SDM 850 [ Upstream commit d529495c991a2b7d07c01622e8b3cb5ec066acee ] Add SoC ID for Qualcomm Snapdragon SDM850. Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260627-sda850-v2-1-44bf46ade42e@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0acfae9c557eba160509e5ad76e4806f55ad9938 Author: Zhiwei Zhang <202275009@qq.com> Date: Fri Jun 26 09:59:20 2026 +0800 RDMA/rxe: Check PDs for memory window binds [ Upstream commit fbbe1d5cd7d400a98afcf337969cfdb808cb198f ] The IBTA Software Transport Verbs specification requires the QP, Memory Window and Memory Region for a Bind Memory Window operation to belong to the same HCA and protection domain. rxe only checked the QP and MW protection domain for type 2 MWs. Move the QP/MW PD check to the common bind path and also reject binding an MW to an MR from a different PD. Invalid bind requests continue to fail with IB_WC_MW_BIND_ERR. Reviewed-by: Zhu Yanjun Signed-off-by: Zhiwei Zhang <202275009@qq.com> Link: https://patch.msgid.link/tencent_FD4FB25AA4FFA845E63F5AC36CF4A46CDC0A@qq.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 74f37101f3eaa08bd2328ae8e813da2b3500c05d Author: David Heidelberg Date: Sat Jun 27 19:50:16 2026 +0200 soc: qcom: socinfo: Add SoC ID for SDM850 [ Upstream commit 743af1d6a8b4bfa62dd01b5c2d81b1c62ea597f7 ] Recognize the SDM850 SoC. Signed-off-by: David Heidelberg Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260627-sda850-v2-2-44bf46ade42e@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e09d3ad685a6db51b5b2bf4863b46e54178a5901 Author: Pengpeng Hou Date: Sat Jul 4 23:16:33 2026 +0800 iio: adc: max1241: add missing MODULE_DEVICE_TABLE() [ Upstream commit 790a2080e0c9eabefea3561dec301172043de236 ] The driver has a match table for the spi bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit f2689d82f2932650596a866d253212b3df3ace39 Author: Yun Zhou Date: Fri Jul 3 14:55:48 2026 +0800 block: reject block device inodes with i_rdev == 0 in lookup_bdev() [ Upstream commit 83887ad02f30c1814bed5da3ca999f7b0f3f337c ] lookup_bdev() blindly returns inode->i_rdev without validating it. When a FUSE filesystem exposes a root inode with S_IFBLK mode but i_rdev == 0 (via rootmode=060000), any subsequent mount attempt using that path as a block device source propagates dev_t 0 into the superblock machinery. After commit 9ee5f161a4db ("fs: maintain a global device-to-superblock table") this triggers a WARNING in super_dev_register(). Reject i_rdev == 0 early with -ENODEV since no real block device driver registers major 0. Reported-by: syzbot+72fe3ea5814121fbc76e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=72fe3ea5814121fbc76e Signed-off-by: Yun Zhou Link: https://patch.msgid.link/20260703065548.1135125-1-yun.zhou@windriver.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 03f77ea05b1f960cfc7de4dfe965fe421bb6ad0f Author: Chin-Yen Lee Date: Thu Jun 25 14:15:44 2026 +0800 wifi: rtw89: wow: add QoS control field to WoWLAN ARP response for MLO [ Upstream commit 03a963f4aeda538acad50806e94ef25d95b78743 ] Some MLO APs expect WoWLAN ARP response frames to be transmitted as QoS data frames and may discard frames that do not contain a QoS Control field. Add a QoS Control field and use the QoS Data subtype when generating WoWLAN ARP responses for MLD vifs. Keep the existing frame format unchanged for non-MLO connections. This allows WoWLAN ARP responses to be accepted by MLO APs while preserving compatibility with legacy APs. Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260625061545.44808-10-pkshih@realtek.com Signed-off-by: Sasha Levin commit c1522a0a928f26584bb277c410e2bc4b5e52eb72 Author: William Hansen-Baird Date: Tue Jun 30 16:15:51 2026 +0200 wifi: rtlwifi: fix disabling of ASPM for RTL8723BE with AER flooding [ Upstream commit 04a46c2dbf3b516c96a1d19b72917b56055ad6c1 ] commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723") adds code which sets ppsc->support_aspm to false in _rtl_pci_update_default_setting() in order to disable ASPM. This does not, however, disable ASPM. Rather, it disables driver control of ASPM, and blocks calls to rtl_pci_enable_aspm() and rtl_pci_disable_aspm(). In some cases, the pci device supplied to the probe function has ASPM enabled. The code would therefore not disable ASPM, as it means to, but rather just leave it enabled. This was discovered through testing on a Razer Blade 14 2017. Implement a new __rtl_pci_disable_aspm(hw) function which does not check ppsc->support_aspm before disabling and call it from rtl_pci_disable_aspm(). Then move the code added in the previous commit to rtl_pci_init_aspm() to allow adding a call to __rtl_pci_disable_aspm(hw). This makes sure ASPM is disabled while still disabling driver control of ASPM to block it from being enabled later. Signed-off-by: William Hansen-Baird Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260630141553.785769-2-william.hansen.baird@gmail.com Signed-off-by: Sasha Levin commit f27e5cc76efdbb41ccf455c8e6d7da549750a673 Author: Chih-Kang Chang Date: Thu Jun 25 14:15:45 2026 +0800 wifi: rtw89: wow: only WiFi 6 chips initialize RF registers in WoWLAN mode [ Upstream commit dbff9040587e9bd6d3ee337315971957f9f76612 ] Only the WiFi 6 chips need to initialize RF register when WoWLAN download FW for some power save issue. Applying the same initialization flow to WiFi 7 chips might trigger the error 'RF parameters exceed size. path=1, idx=1500.'. This happens because normal mode uses rtw89_phy_config_rf_reg_v1(), which skips registers with addresses below 0x100. However, WoWLAN mode uses rtw89_phy_config_rf_reg_noio(), and WiFi 7 chips do not satisfy the rtw89_chip_rf_v1() condition. As a result, more RF registers are configured, causing the size overflow error. Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260625061545.44808-11-pkshih@realtek.com Signed-off-by: Sasha Levin commit 7a2ffca1353ce099c8cfb0bf430eeab70584281d Author: William Hansen-Baird Date: Tue Jun 9 11:53:59 2026 +0200 wifi: rtlwifi: rtl8723be: Remove unnecessary irq save/restore in hw_init() [ Upstream commit 1b4cd55626b6ffa93d18848412afb912a4add585 ] rtl8723be hw_init() calls local_save_flags(flags) followed by local_irq_enable(). Later, local_irq_restore(flags) is called. This causes warnings from Lockdep on boot and modprobe, as local_irq_restore(flags) should only be called while irqs are disabled. The warning was introduced to detect this class of bug in [1]. With testing I found that all paths which call hw_init() have irqs already enabled for rtl8723be. Furthermore, the calls were originally added for the rtl8192ce in commit f78bccd79ba3 ("rtlwifi: rtl8192ce: Fix too long disable of IRQs") before later being added to most other rtlwifi drivers. Commit d3feae41a347 ("rtlwifi: Update power-save routines for 062814 driver") then replaces the call to spin_lock_irqsave() before hw_init(), and thus the codepath which caused irqs to be disabled in hw_init and prompted the original commit has been removed. The same irq save/restore pattern is also present in the hw_init() of rtl8192ce, rtl8723ae, rtl8188ee, rtl8192se and rtl8192cu, however I don't have the hardware to test them, so I did not include them in my changes. Tested on a Razer Blade 14 2017. Example of output from Lockdep prior to fix: raw_local_irq_restore() called with IRQs enabled ... Call Trace: rtl8723be_hw_init+0x5992/0x7220 [rtl8723be] ? static_obj+0x61/0xa0 rtl_pci_start+0x222/0x5c0 [rtl_pci] rtl_op_start+0x128/0x1a0 [rtlwifi] ? __kasan_check_read+0x11/0x20 drv_start+0x16c/0x550 [mac80211] ... irq event stamp: 887679 hardirqs last enabled at (887689): [] __up_console_sem+0x90/0xa0 hardirqs last disabled at (887698): [] __up_console_sem+0x75/0xa0 softirqs last enabled at (887670): [] __irq_exit_rcu+0x175/0x2f0 softirqs last disabled at (887649): [] __irq_exit_rcu+0x175/0x2f0 ---[ end trace 0000000000000000 ]--- [1] https://lore.kernel.org/all/20210111153707.10071-1-mark.rutland@arm.com/ Signed-off-by: William Hansen-Baird Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260609095359.2964193-1-william.hansen.baird@gmail.com Signed-off-by: Sasha Levin commit 1475370630ef87e140f148c649d6a7cf03fbd1e6 Author: Ben Dooks Date: Wed Jun 17 09:49:43 2026 +0100 dmaengine: dw-axi-dmac: fix __le32 on set of CH_CTL_H_LLI_VALID [ Upstream commit 89aba9c39bdda8a973a6ffed7c9e93321edcfc16 ] When writing the lli->ctl_hi, this is an __le32 type so the value being orred should be convered to __le32 by cpu_to_le32. Fixes 1deb96c0fa58a ("dmaegine: dw-axi-dmac: Support device_prep_dma_cyclic()") -- Note, the call to axi_chan_irq_clear() is passing lli->status_lo through which is also an __le32 but it does not seem to be set anywhere. Is this also a bug? Signed-off-by: Ben Dooks Link: https://patch.msgid.link/20260617084944.705266-1-ben.dooks@codethink.co.uk Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8378bf554d149378c9f1f63f32e655389b047852 Author: Yun Zhou Date: Tue Jun 30 14:03:11 2026 +0800 net: mvneta_bm: add suspend/resume support to prevent crash after resume [ Upstream commit 140be217df577961bea1ca36240439a463026cbd ] The mvneta driver uses the hardware Buffer Manager (BM) for RX buffer allocation. During suspend, mvneta disables its clock, causing BM to lose all buffer address state. On resume, mvneta_bm_port_init() re- attaches the BM pool to the NIC, but BM hardware returns stale/garbage buffer addresses. When NAPI poll processes these buffers, DMA cache sync hits an invalid virtual address causing a kernel panic: Unable to handle kernel paging request at virtual address b0000080 PC is at v7_dma_inv_range Call trace: v7_dma_inv_range from arch_sync_dma_for_cpu+0x94/0x158 arch_sync_dma_for_cpu from __dma_sync_single_for_cpu+0xc4/0x15c __dma_sync_single_for_cpu from mvneta_rx_swbm+0x6c8/0xf48 mvneta_rx_swbm from mvneta_poll+0x6fc/0x70c mvneta_poll from __napi_poll.constprop.0+0x2c/0x1e0 __napi_poll.constprop.0 from net_rx_action+0x160/0x2c4 net_rx_action from handle_softirqs+0xd8/0x2b8 handle_softirqs from run_ksoftirqd+0x30/0x94 run_ksoftirqd from smpboot_thread_fn+0x100/0x204 smpboot_thread_fn from kthread+0xf4/0x110 kthread from ret_from_fork+0x14/0x28 Fix by adding suspend/resume callbacks to the BM driver: - suspend: drain all buffers (with DMA unmapping), free the BPPE regions, and reset pool state to FREE before stopping BM and gating the clock. - resume: enable the clock, reinitialize BM defaults, and restore pool read/write pointers and size registers. Pool allocation and buffer refill are handled by mvneta_resume() through the normal mvneta_bm_port_init() path, which sees pools as FREE and performs full initialization identical to probe. Add a device_link (DL_FLAG_AUTOREMOVE_CONSUMER) in mvneta_probe to guarantee BM resumes before mvneta and suspends after mvneta. If the link cannot be created, fall back to SW buffer management to avoid a potential crash on resume due to unordered PM transitions. Signed-off-by: Yun Zhou Link: https://patch.msgid.link/20260630060311.4072140-1-yun.zhou@windriver.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e1f38372cd2e2dfec201b31a2ef1bedab18a3747 Author: Pengpeng Hou Date: Mon Jun 15 17:16:45 2026 +0800 dmaengine: pl330: remove debugfs file on teardown [ Upstream commit 0d3e3376b289cdaff5b3b6c1581999926ff1000f ] init_pl330_debugfs() creates a debugfs file with struct pl330_dmac as private data. pl330_remove() then unregisters the DMA device and frees the PL330 channel/thread state without removing that file. Keep the debugfs dentry and remove it before tearing down the DMAC state used by the debugfs show callback. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260615091645.28878-1-pengpeng@iscas.ac.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ceff23dc55d2b348be64cfe2f4ed9f51329cbcf9 Author: Charles Keepax Date: Tue Jun 30 09:11:32 2026 +0100 soundwire: dmi-quirks: Disable ghost Realtek on Asus Expertbook [ Upstream commit 90af3209742db61a7f9d7d054a16165818cfc6d8 ] The Asus Expertbook B9406CAA also has a Realtek device in the ACPI that doesn't exist in the physical hardware. This confuses the machine driver into attempting to create DAI links for the device. Add a quirk to remove this device. Closes: https://github.com/thesofproject/linux/issues/5828 Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260630081132.3294488-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 71448fee7b544a0c91585cb13c64620709212b80 Author: Jiayuan Chen Date: Wed Jun 10 11:02:59 2026 +0800 netfilter: ebtables: bound num_counters like nentries in do_replace() [ Upstream commit 43ae85af154b27f9a0ff602f7a01e3a7583ffdab ] do_replace_finish() allocates the counter buffer before it is validated: counterstmp = vmalloc_array(repl->num_counters, sizeof(*counterstmp)); do_replace() only checks num_counters against INT_MAX / sizeof(struct ebt_counter), so vmalloc_array() can be asked for up to 134217726 * 16 = 2147483616 bytes (~2 GiB). num_counters must in fact equal nentries: do_replace_finish() later rejects the request when repl->num_counters != t->private->nentries. get_counters() folds the per-CPU counters back into one entry per rule, so what userspace gets is bounded by nentries, never by nentries * nr_cpus. Apply the same upper bound used for nentries (MAX_EBT_ENTRIES) to the incoming num_counters so the over-sized allocation can no longer be requested. The allocation is still kept outside the ebt_mutex, since vmalloc() may sleep and trigger reclaim; only the bound is tightened. Signed-off-by: Jiayuan Chen Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 258fa11e19891026170b1b29794f766a3c4009a1 Author: Yousef Alhouseen Date: Tue Jun 30 12:12:16 2026 +0200 net: usb: rtl8150: handle link status read failures [ Upstream commit 8c9c5b9a689612dcb92a04a4218c975cd19f19d8 ] set_carrier() ignores the result of the USB control transfer and tests the stack variable supplied as its receive buffer. If the device rejects or aborts the request, that variable remains uninitialized and the driver chooses an arbitrary carrier state. Leave the existing carrier state unchanged when the link status cannot be read. A transient USB error should not be treated as link loss. Reported-by: syzbot+9db6c624635564ad813c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9db6c624635564ad813c Suggested-by: Petko Manolov Signed-off-by: Yousef Alhouseen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260630101216.10365-1-alhouseenyousef@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9b78f1f076e29b6494c9915159c6ee18c0ebef92 Author: Yuan Chen Date: Wed Jun 10 22:50:53 2026 +0800 libbpf: Skip bpf_object__probe_loading() when BPF token is in use [ Upstream commit d262a25d8b58b697b2a1a2fe4b0078446cc00e11 ] bpf_object__probe_loading() tries to load trivial SOCKET_FILTER and TRACEPOINT programs to verify the BPF environment works. When a BPF token is in use with restricted program type permissions, these probe loads may fail because the token does not allow the specific program types, even though BPF loading is perfectly functional. Fix by skipping the probe when a token FD is present: BPF token creation itself proves the kernel has a working BPF subsystem. Real BPF issues will be caught during actual program and map loading. Signed-off-by: Yuan Chen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260610145059.113412-2-chenyuan_fl@163.com Signed-off-by: Sasha Levin commit 18b4a1566fcb0ec3040d5796226dcd57afb6b898 Author: Haikun Zhou Date: Wed Jul 1 09:30:18 2026 +0800 drm/panel-edp: Support MB116AS01'3 edp panel [ Upstream commit 844e71ba7d7a50c5ffa29d147afaeaafb19b39e4 ] MB116AS01'3 raw edid: 00 ff ff ff ff ff ff 00 21 63 03 12 00 00 00 00 00 23 01 04 95 1a 0e 78 23 e7 05 9c 5b 56 93 27 21 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 36 1c 56 92 50 00 1c 30 60 18 a8 00 00 90 10 00 00 18 00 00 00 fd 00 28 3c 30 30 07 01 0a 20 20 20 20 20 20 00 00 00 fe 00 48 4b 43 20 4d 59 20 20 20 20 0a 20 20 00 00 00 fe 00 4d 42 31 31 36 41 53 30 31 27 33 20 20 01 cb 70 20 79 02 00 22 00 14 1c 1a 01 84 55 05 91 00 5f 00 17 00 ff 02 1b 00 09 00 07 00 2b 00 06 27 00 28 3b 00 00 81 00 13 72 1a 00 00 03 01 28 3c 00 00 00 00 00 00 3c 00 00 00 00 25 01 09 1c 1a 01 1c 1a 01 28 3c 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e7 90 Signed-off-by: Haikun Zhou Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260701013018.2621972-1-zhouhaikun5@huaqin.corp-partner.google.com Signed-off-by: Sasha Levin commit 9c369f45f60304a7363f4cfaa24cdf1205f2c247 Author: Eric Huang Date: Wed Jun 17 14:42:48 2026 -0400 drm/amdkfd: add sanity check in svm_range_is_valid [ Upstream commit aa7e29cf9a37092cf5057a612ee09f28df20258f ] to prevent svm range to be overflow or underflow. Signed-off-by: Eric Huang Reviewed-by: Philip Yang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 18fefe9efa63eaff76cf6e08735538028fafba7e Author: Yang Wang Date: Tue Jun 23 11:37:41 2026 +0800 drm/amd/pm: Validate legacy hwmgr PP table offsets [ Upstream commit 0ceb6bc43e62f0e73b282c9de8f4bc4d5498f281 ] processpptables.c walks several variable-length PPLIB tables by using offsets from the VBIOS PowerPlay table. Some paths dereference extended headers, state arrays, clock arrays, non-clock arrays, or VCE records before checking that the referenced data is inside the table buffer. Add local bounds helpers and validate the relevant offsets and entry sizes before dereferencing them. This prevents truncated or malformed legacy PowerPlay tables from driving out-of-bounds reads during hwmgr initialization and table entry lookup. Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 053663009c69499921bd5f8243e091ffe35e209a Author: Yang Wang Date: Tue Jun 23 16:36:21 2026 +0800 drm/amd/pm: Validate Vega10 PPTable subtable bounds [ Upstream commit 9914149f99fd2ddcfd2a8c1053a57d96ec43448e ] v1: Vega10 PPTable parsing uses VBIOS-provided offsets, revision fields and entry counts to locate subtables. Malformed data can otherwise drive out-of-bounds reads from soft_pp_table_size, and voltage lookup tables can overrun their fixed-size destination arrays. Add shared bounds helpers and validate fixed-size subtables, dynamic entry arrays and revision-specific layouts before consuming thermal, fan, power-tune, clock dependency, PCIE, hard-limit and voltage lookup data. v2: if ucRevId is not matched, fallback to default table size instead of returning -EINVAL. Signed-off-by: Yang Wang Reviewed-by: Asad Kamal Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit af725fd0550a0e027c73339859b4145c769740ce Author: Yang Wang Date: Tue Jun 23 16:37:07 2026 +0800 drm/amd/pm: Validate Tonga PPTable subtable bounds [ Upstream commit 53ef33c084c5778cc2dcd1efff25e31b6e231141 ] v1: Tonga PPTable parsing also relies on VBIOS offsets, revision fields and entry counts for several subtables. Malformed data can cause out-of-bounds reads, while voltage lookup tables can overrun their fixed-size destination arrays. Add common bounds helpers and validate fixed subtables, dynamic entry arrays and revision-specific layouts before consuming voltage lookup, dependency, PCIE, power-tune, hard-limit, thermal, fan, GPIO, PPM and VCE state data. v2: correct to handle get_tonga_ppm_table() return value. Signed-off-by: Yang Wang Reviewed-by: Asad Kamal Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 486b408703e8b0dd72fdc4a3fdc1710fba1ce422 Author: Xiang Liu Date: Tue Jun 23 10:59:18 2026 +0800 drm/amd/pm: Guard VBIOS AC timing table walk [ Upstream commit 2bf6867e5953a140fc91c3159987656e44ed29fb ] Reject AC timing blocks with a stride smaller than a dword before walking VBIOS data. A zero stride can otherwise keep reg_data pinned on a nonmatching MEM_ID forever. Also bound the data-block and END marker reads by the returned VRAM_Info table size so malformed index/data sizes do not push the timing walk past the table. Signed-off-by: Xiang Liu Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3e3ff4c61d4a19206c81ee3b7dc1edd355c23c0e Author: Yang Wang Date: Tue Jun 23 11:36:39 2026 +0800 drm/amd/pm: Validate Tonga PowerPlay state array bounds [ Upstream commit 1ac24df78c566d767a5ef05a1fe0ecc55bac248d ] process_pptables_v1_0.c builds the Tonga state array pointer from usStateArrayOffset before checking that the table buffer covers the referenced data. A truncated PowerPlay table can therefore lead to out-of-bounds reads while validating the state array. Validate the fixed table size first, then check the state array offset and entry range before dereferencing the state array. Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 84b146adeba1c9b53e04d3fa1061489799cc8954 Author: Yang Wang Date: Tue Jun 23 11:36:20 2026 +0800 drm/amd/pm: Use uploaded size for legacy custom PPTable [ Upstream commit 055a40c32f3a2dcd4d1a6f85ff4c231cf35f1b53 ] The legacy powerplay path used to allocate hardcode_pp_table from the original VBIOS PPTable size, copy only the uploaded bytes into it, and keep soft_pp_table_size unchanged. If a custom PPTable is shorter than the original table, later code can still treat the stale tail as valid table data. Treat the uploaded buffer as the complete custom PPTable: duplicate the uploaded buffer directly, replace hardcode_pp_table atomically, and set soft_pp_table_size to the uploaded size. Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a1e2155510a56a2534a9519175ba77777e48f3d1 Author: Yang Wang Date: Tue Jun 23 00:04:33 2026 +0800 drm/amd/pm: Validate pp_table header before reading size [ Upstream commit a17e79d01f22182a9fcbe79fcbe2ad1477d43e0f ] smu_sys_set_pp_table() reads usStructureSize from the uploaded pp_table buffer before validating that the buffer contains a complete ATOM_COMMON_TABLE_HEADER. A short write can therefore make the driver read past the supplied sysfs buffer. Reject empty or header-short uploads before dereferencing the header pointer. Keep the existing structure-size check for the full uploaded table. Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8dbfdbe377c1e90d543d2822252c4b5bee7d6127 Author: Yang Wang Date: Tue Jun 23 11:37:23 2026 +0800 drm/amd/pm: Validate Vega hwmgr PowerPlay table bounds [ Upstream commit 3a8d8e0b7f61cd759d5d4870b6220161f8a5b114 ] The Vega hwmgr PowerPlay table parsers read fixed table fields, state array entries, or SMC PPT fields before validating that the VBIOS table buffer covers those structures. A truncated table can therefore lead to out-of-bounds reads during hwmgr initialization. Reject tables smaller than the fixed PowerPlay table. For Vega10, also validate the state array offset and entry range before dereferencing the state array. Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ce4546a3bd7760e4a2c22f6ff378ecf91138bf49 Author: Lijo Lazar Date: Wed Jun 17 14:42:02 2026 +0530 drm/amdgpu: Guard reads in pcie state readout [ Upstream commit 230753e46a4a9d04dad6a9b5dbaeb7fd52add7d0 ] Internal US/DS switch may not be exposed in passthrough. Guard the upstream port reads to avoid a NULL dereference. Signed-off-by: Lijo Lazar Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7300033159bac4b1719c351312f55b6ab81f39f8 Author: Matthew Jacob Date: Fri Jun 19 11:45:46 2026 -0700 drm/amdgpu: Support some Barco AMD based graphics adapters [ Upstream commit 3dc4d68ee26a7ac12069ff0562ad8935106c79b6 ] These adapters typically are only supported by Barco on the Windows platform. However, with these changes in the linux driver, multiple monitor support should work correctly. Signed-off-by: Matthew Jacob Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bb253c2d41c9df594f1fd90b5b3a69b9d866485f Author: Lijo Lazar Date: Thu Jun 18 10:56:54 2026 +0530 drm/amd/pm: validate vega10 profile mode inputs [ Upstream commit bf939f2a1687ef4ab815640096357f8ef5bd5fb6 ] Check for out of range profile modes and custom params that exceed 8 bits. Signed-off-by: Lijo Lazar Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a8d4cbb2b385dc78a7418fd262889b08498a0845 Author: Lijo Lazar Date: Mon May 18 17:43:32 2026 +0530 drm/amdgpu: Validate ATIF buffer length before use [ Upstream commit b978b7d43963bbb3e2d850288f7c21ac11c3b751 ] Add a min_size parameter to amdgpu_atif_call() to validate that the returned ACPI buffer is of type ACPI_TYPE_BUFFER, holds at least a u16 size field, does not claim more data than was actually returned, and meets the minimum size required by the calling function. Each caller passes its required minimum via sizeof() or offsetof() of the expected output struct and drops its own size check. Signed-off-by: Lijo Lazar Assisted-by: Claude Sonnet (Cursor AI) Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 466cddce41689aac1e9bf4e2a1680d711e77c6ff Author: Lijo Lazar Date: Mon Jun 15 11:02:51 2026 +0530 drm/amdgpu: Add checks to vbios fetch through ATRM [ Upstream commit 8c3fcfc14fc1320a1155acb2dd7656fce7003bc0 ] Check if a valid buffer object is returned after ATRM call. Also, match the buffer length against requested size before copying. Signed-off-by: Lijo Lazar Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7b2d27a2775807043d7cbacf41b98949c8b6f4fe Author: Abhijeeth Babu Date: Thu Jun 18 00:56:11 2026 +0530 i2c: acpi: Force ELAN1300 touchpads to 100 kHz [ Upstream commit 9e9762e578db7556bea644bb5a8a2435f63544d1 ] The ELAN1300 touchpad with HID ID 04F3:3104 on the ASUS VivoBook X513UA_KM513UA exhibits severe pointer jumps and erratic movement when the I2C bus operates at 400 kHz. The system DSDT describes the touchpad using an I2cSerialBusV2 resource with a speed of 0x00061A80, corresponding to 400 kHz, on the AMDI0010:03 controller. At this speed, libinput repeatedly reports: kernel bug: Touch jump detected and discarded Add ELAN1300 to i2c_acpi_force_100khz_device_ids so that it operates at 100 kHz. Before the change, nine touch-jump events were recorded, with additional messages suppressed by libinput's rate limiter. With the bus forced to 100 kHz, no touch-jump events have been observed and the touchpad operates normally. The affected system uses BIOS X513UA.319 dated 2023-05-09. Signed-off-by: Abhijeeth Babu Acked-by: Mika Westerberg Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260617192611.125513-1-babu.jeeth@gmail.com Signed-off-by: Sasha Levin commit 1ac43b85223777f1409d9d199ad114500c4c78ac Author: Nicolas Escande Date: Tue Jun 23 17:16:13 2026 +0200 wifi: ath12k: avoid setting 320MHz support on non 6GHz band [ Upstream commit eaf478b3ea68e1b5df659acd24c4df5850e12325 ] On a split phy qcn9274 (2.4GHz + 5GHz low), "iw phy" reports 320MHz related features on the 5GHz band while it should not: Wiphy phy1 [...] Band 2: [...] EHT Iftypes: managed [...] EHT PHY Capabilities: (0xe2ffdbe018778000): 320MHz in 6GHz Supported [...] Beamformee SS (320MHz): 7 [...] Number Of Sounding Dimensions (320MHz): 3 [...] EHT MCS/NSS: (0x22222222222222222200000000): This is also reflected in the beacons sent by a mesh interface started on that band. They erroneously advertise 320MHz support too. This should not happen as IEEE Std 802.11-2024, subclause 9.4.2.323.3 says we should not set the 320MHz related fields when not operating on a 6GHz band. For example it says about Bit 0 "Support For 320 MHz In 6 GHz" "Reserved if the EHT Capabilities element is indicating capabilities for the 2.4 GHz or 5 GHz bands." Fix this by clearing the related bits when converting from WMI eht phy capabilities to mac80211 phy capabilities, for bands other than 6GHz. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1 Signed-off-by: Nicolas Escande Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260623151613.72113-1-nico.escande@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 2575e0ccf032f72e920306b813cf0dcb0ca6e81e Author: Jiawen Liu <1298662399@qq.com> Date: Sat Jun 20 12:39:29 2026 +0400 spi: bcmbca-hsspi: return error from failed controller suspend [ Upstream commit faa878d4805ca375738294bc52eae310eb287b16 ] spi_controller_suspend() can fail if pending transfers cannot stop. bcmbca_hsspi_suspend() ignored the error and still disabled the PLL and core clocks. Return the error before disabling the clocks. Signed-off-by: Jiawen Liu <1298662399@qq.com> Link: https://patch.msgid.link/tencent_54F5634545908FBA724E758054BF03953808@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9d225297088ab24a65a849f917ff2c100a9d65b8 Author: Jiawen Liu <1298662399@qq.com> Date: Sat Jun 20 12:39:31 2026 +0400 spi: nxp-fspi: disable runtime PM on probe failures [ Upstream commit 5d14285d60ba95561609a293064654a0c7d7d928 ] nxp_fspi_probe() enables runtime PM and autosuspend before several operations that can fail. Some failure paths returned directly before the devm cleanup action was installed, leaving runtime PM enabled. Route those failures through a common runtime PM cleanup path. Use pm_runtime_resume_and_get() for the initial clock enable. Signed-off-by: Jiawen Liu <1298662399@qq.com> Link: https://patch.msgid.link/tencent_8FC0B8DFAF4AE67AEBA20548045D53A77707@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3e74300f0e9b1092818fd3d5e23517518ece8553 Author: Damon Ding Date: Thu Jun 25 15:19:16 2026 +0800 drm/panel-edp: Add BOE NE160QDM-NY1 panel [ Upstream commit be4f10d44757211fd656fa57f37034657f26c883 ] Add an entry for the BOE NE160QDM-NY1 eDP panel. The panel's AUX backlight functionality is verified and working on the RK3576 EVB1 board. edid-decode (hex): 00 ff ff ff ff ff ff 00 09 e5 85 09 00 00 00 00 1c 1e 01 04 b5 22 15 78 03 7c e5 a4 55 4c 9f 26 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 6b 6e 00 a0 a0 40 84 60 30 20 36 00 58 d7 10 00 00 1a 00 00 00 fd 0c 3c a5 1f 1f 4e 01 0a 20 20 20 20 20 20 00 00 00 fe 00 42 4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe 00 4e 45 31 36 30 51 44 4d 2d 4e 59 31 0a 01 ed 02 03 1d 00 e3 05 80 00 e6 06 05 01 6a 6a 24 6d 1a 00 00 02 03 3c a5 00 04 6a 24 6a 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff Signed-off-by: Damon Ding Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260625071916.744686-1-damon.ding@rock-chips.com Signed-off-by: Sasha Levin commit bb94af864be489854876d35dcfa8078c9b1bca1f Author: Jiawen Liu <1298662399@qq.com> Date: Thu Jun 18 20:45:17 2026 +0400 spi: bcm63xx-hsspi: return error from failed controller suspend [ Upstream commit 3b5414d76a0381db77b9694537254af7acfa187a ] spi_controller_suspend() can fail if the SPI core cannot stop the controller. bcm63xx_hsspi_suspend() ignored that error, disabled the PLL and core clocks, and returned success. Return the suspend error before disabling the clocks. Signed-off-by: Jiawen Liu <1298662399@qq.com> Acked-by: William Zhang Link: https://patch.msgid.link/tencent_B5A06807924A77C8690730EBF7A052AABE05@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4534dc8dba5f5061907508a8af28cc0d98efb8ee Author: Jiawen Liu <1298662399@qq.com> Date: Thu Jun 18 20:45:16 2026 +0400 spi: bcm63xx: return error from failed controller suspend [ Upstream commit bbbc1ef5b35341c5122418a14f8924688a4bb954 ] spi_controller_suspend() can fail if the SPI core cannot stop the controller. bcm63xx_spi_suspend() ignored that error, disabled the controller clock, and returned success. Return the suspend error before tearing down the clock. Signed-off-by: Jiawen Liu <1298662399@qq.com> Link: https://patch.msgid.link/tencent_0BD7D4091B90EC17A8B2BA5EBA8803725905@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 551606d33d67f5ce001a26772791b5dc37d3fcd9 Author: Jiawen Liu <1298662399@qq.com> Date: Thu Jun 18 20:45:18 2026 +0400 spi: bcm-qspi: return error from failed controller suspend [ Upstream commit 44d09ef0ba690ac46d17eb05c12a47a5dd75e231 ] spi_controller_suspend() can fail if the SPI core cannot stop the controller. bcm_qspi_suspend() ignored that error, disabled the controller clock, uninitialized the hardware, and returned success. Return the suspend error before tearing down the clock and hardware state. Signed-off-by: Jiawen Liu <1298662399@qq.com> Reviewed-by: Kamal Dasu Link: https://patch.msgid.link/tencent_21BF5F9512F56D45FD9018BAF14ED2805808@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6dce529867d257f7f018176e6e24f33792b638ea Author: Zide Chen Date: Thu Jun 11 09:00:26 2026 -0700 perf/x86/intel/uncore: Fix PCI PMU cleanup on setup failure [ Upstream commit 003267cb94e21d762eb72d6977d84f44f1705bb7 ] When uncore_pci_pmu_register() fails, pmu->boxes[die] is set to NULL before returning. In the uncore_pci_remove() path, this causes uncore_pci_pmu_unregister() to be skipped entirely, leaking pmu->activeboxes. In the uncore_bus_notify() path, uncore_pci_pmu_unregister() may still be called and must exit early when pmu->boxes[die] is NULL to avoid a NULL pointer dereference, and to ensure activeboxes is only decremented for a previously active box. Additionally, since pci_get_drvdata() returns NULL on registration failure, uncore_pci_remove() can no longer treat NULL drvdata as an indicator of an auxiliary PCI device. Remove the associated WARN_ON_ONCE(). Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://sashiko.dev/#/patchset/20260512233048.9577-1-zide.chen@intel.com?part=1 Link: https://patch.msgid.link/20260611160033.66760-2-zide.chen@intel.com Signed-off-by: Sasha Levin commit 1494aae9dc03030c8961791ca0edc32c470ab180 Author: Zizhi Wo Date: Mon Jun 29 21:09:43 2026 +0800 fat: reject name longer than NAME_MAX in msdos_format_name() [ Upstream commit 9d7ed813ee5ff0d469bd99630828ed6fdef4e8da ] msdos_format_name() performs no upper-bound check on the input name length. It silently truncates an arbitrarily long name into the 8.3 form (11 bytes) and returns success. The subsequent fat_scan() then matches only against these 11 truncated bytes, so it returns an inode as long as any entry with the same 8.3 name exists on disk. For example, passing a 300-byte name of all 'A's returns 0 with res set to "AAAAAAAA" (8 'A's + 3 padding spaces), reporting success for a name far longer than NAME_MAX. As a result, when a user calls open() on a path component longer than NAME_MAX (255) bytes, the VFS only enforces PATH_MAX, not the length of an individual component. The dentry keeps the original long name but gets an inode attached and becomes positive. Later in vfs_open() -> fsnotify_open() -> fanotify_info_copy_name() triggers WARN_ON_ONCE(), and the event is reported to userspace with an empty name. vfat is not affected, as create goes through xlate_to_uni() which refuses names longer than FAT_LFN_LEN. Fix this by checking 'len > NAME_MAX' at the entry of msdos_format_name(), the single entry point for all msdos name handling, aligning with the NAME_MAX check that xfs/9p/ceph/simple_lookup() perform at lookup. Signed-off-by: Zizhi Wo Link: https://patch.msgid.link/20260629130943.3671939-1-wozizhi@huaweicloud.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 67b65040883e6688ed177caacc63d3cc4fcaeaf4 Author: Dapeng Mi Date: Tue Jun 16 12:46:49 2026 +0800 perf/x86/intel: Fallback to sw branch type decoding if no hw decoding [ Upstream commit 170cc6b02e3d5203ccaa49ffea1ee5a7ab08c885 ] intel_pmu_lbr_filter() currently assumes arch-LBR provides hardware branch-type decoding and skips software decoding on that path. However, arch-LBR may not always expose branch-type information. In that case, treating entries as hardware-decoded can misclassify sampled branches (for example, defaulting to JCC), which breaks branch-type filtering results. Fix this by using software branch-type decoding when hardware branch-type decoding is unavailable (that is, when x86_lbr_type is not enabled). This keeps branch classification and filtering behavior correct across arch-LBR configurations. Since x86_lbr_type is only set to true when arch-LBR is supported, it's unnecessary to check if the CPU has the arch-LBR feature. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260616044654.3468742-4-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit efcbcfeedcc4db97f90b90bf3f6c96c42cf27064 Author: Bryam Vargas Date: Tue Jun 16 20:56:15 2026 -0500 iio: accel: fxls8962af: clamp the device-reported FIFO sample count [ Upstream commit 2f8225b91eb478ca2e9aec8aaef4d229765bcebe ] fxls8962af_fifo_flush() transfers the sample count the device reports in BUF_STATUS into an on-stack buffer sized for FXLS8962AF_FIFO_LENGTH (32) samples, but the count is a 6-bit field (0..63) that is only checked for zero. A device, or an attacker on the I2C/SPI bus, reporting 33..63 overflows the buffer by up to 186 bytes: a stack out-of-bounds write. Clamp the count to FXLS8962AF_FIFO_LENGTH before the transfer, mirroring the clamp already applied in fxls8962af_set_watermark(). Conforming hardware reports at most that many samples and is unaffected. Signed-off-by: Bryam Vargas Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 4796017cd10f72856ca07f5aaed981242d6b9210 Author: Mithil Bavishi Date: Wed Jun 3 22:40:48 2026 -0700 ARM: OMAP2+: Add CFI type for omap4_finish_suspend [ Upstream commit 4a7b197ad28d71f9fac873f283b4408df3fdb287 ] With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower() because omap_pm_ops.finish_suspend points directly to the assembly routine omap4_finish_suspend, which lacks the expected KCFI type metadata. Annotate omap4_finish_suspend with SYM_TYPED_FUNC_START so the assembly routine carries the KCFI type metadata. Signed-off-by: Mithil Bavishi Reviewed-by: Nathan Chancellor Reviewed-by: Andreas Kemnade Link: https://patch.msgid.link/20260604054048.18980-1-bavishimithil@gmail.com Signed-off-by: Kevin Hilman (TI) Signed-off-by: Sasha Levin commit 6b73f80fae3f9116a9c532b1eea335d1c1b09f9b Author: Uwe Kleine-König (The Capable Hub) Date: Fri Jun 26 08:04:23 2026 +0200 regmap: maple: Workaround for another false-positive compiler warning [ Upstream commit dffd32eb2b0e714a8ae23f98518ad7152cb06369 ] Similar to the issue fixed in commit 542440fd7b30 ("regmap: maple: work around gcc-14.1 false-positive warning"), I see an uninitialized warning for upper_index and upper_last. Happens with arc-linux-gnu-gcc (Debian 15.3.0-1) 15.3.0 on an allmodconfig for ARCH=arc. Signed-off-by: Uwe Kleine-König (The Capable Hub) Link: https://patch.msgid.link/20260626060427.2548578-2-u.kleine-koenig@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8d27af4d965b429654b2c17b30f9b78afab0a772 Author: Haoxiang Li Date: Mon Jun 22 23:11:27 2026 +0800 ASoC: hdac_hdmi: Fix resource cleanup on probe failure [ Upstream commit 785903b7770f19ea05b8a76081dff691c56fa771 ] hdac_hdmi_dev_probe() gets the HDA link before allocating and initializing the HDMI codec private data. Several later error paths return directly without dropping the link reference, leaving the hlink refcount unbalanced. Release the link reference on probe failures. Also turn display power off if the failure happens after it has been enabled. This issue was dicussed in: https://lore.kernel.org/all/s5h1s0esk8o.wl-tiwai@suse.de/ I think the paths fixed here are probe failure paths: the device has not been fully initialized or bound, and runtime PM suspend cannot be relied on to balance the reference taken during probe. Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260622151127.1198196-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cdb43c826f5c6345a1f93ed8319aca8c95141e17 Author: Pengpeng Hou Date: Mon Jun 15 14:45:48 2026 +0800 ASoC: tlv320aic26: remove keyclick sysfs file [ Upstream commit ae375f8d063d71e598c0d7e14fc056154c84d7a7 ] aic26_probe() creates the keyclick sysfs file on the component device. The file callback uses the ASoC component pointer stored in the driver private data. There is no matching remove callback, so the sysfs file can remain after the component is removed while its backing component state is gone. Add a component remove callback that removes the keyclick file. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260615064549.34110-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bb42c8afaff669c2f27e455831163437c0d8c2e4 Author: William Theesfeld Date: Mon Jun 1 16:35:00 2026 -0400 clk: zynq: handle kasprintf() failure in periph_clk registration [ Upstream commit d4d0d335e8d37c6c7e1c5664c7664288eca5a09b ] zynq_clk_register_periph_clk() ignores the return value of the two kasprintf() calls used to build the mux and divider clock names, and passes the resulting (possibly NULL) pointers straight into clk_register_mux(), clk_register_divider() and clk_register_gate() as the clock '"'name'"' argument. On allocation failure that name later gets dereferenced by the clock framework (e.g. in debugfs name formatting), causing a NULL-pointer dereference. Check both kasprintf() returns. On failure unwind any allocated name buffer and the spinlock, then fall through to the existing err label which sets clks[] to ERR_PTR(-ENOMEM). Freeing the spinlock on the error path is correct here because no clk_register_*() call has had a chance to take ownership of it; the success path intentionally hands it off to the registered clocks. The neighbouring zynq_clk_register_fclk() in the same file already uses this per-allocation goto-label cleanup pattern; this change brings periph_clk into line with it. Signed-off-by: William Theesfeld Reviewed-by: Brian Masney Reviewed-by: Michal Simek Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 14f938b3665effb0f2120c0889f70de8b293c21e Author: Pengpeng Hou Date: Mon Jun 15 14:44:56 2026 +0800 ASoC: sma1303: remove fault-check sysfs group on remove [ Upstream commit ce3733792d38ade8df8ce288a96ff0c6ad858bf3 ] sma1303_i2c_probe() creates a sysfs group that exposes the fault-check controls. The check_fault_status store callback can queue check_fault_work. sma1303_i2c_remove() only cancels the delayed work. It does not remove the sysfs group, so the controls can remain published after remove while their callbacks still use the driver data and can queue the work again. Remove the sysfs group before cancelling the delayed work. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260615064456.28615-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7a9746810d716ce1cb5a82c8c5f1b72d82c822f9 Author: Kemeng Shi Date: Tue Jun 23 15:51:32 2026 +0800 irqdomain: Plug leak in irq_domain_alloc_irqs_locked() error path [ Upstream commit 13856e22217fbf7c1200633716ff87ccb50fd89a ] When irq_domain_trim_hierarchy() fails in irq_domain_alloc_irqs_locked(), the error handling path fails to undo the hierarchy allocations. Add the missing cleanup. [ tglx: Massage change log ] Signed-off-by: Kemeng Shi Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260623075134.4432-2-shikemeng@huaweicloud.com Signed-off-by: Sasha Levin commit 7743b3f14433f111603290a914b79af36cbc46ea Author: Pengpeng Hou Date: Wed Jun 24 22:40:15 2026 +0800 media: cec: stm32: return an error when log-address wait times out [ Upstream commit 3bc2e4a26465386332ee1a40219d8dafba335b0b ] stm32_cec_adap_log_addr() waits for TXSOM to clear before disabling CEC and updating the logical address registers. The wait result is ignored, so a timeout can still be reported as a successful logical address update. Return the polling error before touching the address registers. Compute the address mask only for valid logical addresses so the invalid-address path does not evaluate a shift based on CEC_LOG_ADDR_INVALID. Signed-off-by: Pengpeng Hou Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 53ad74a92b934f880467720730f330916b316a39 Author: Kryštof Černý Date: Fri Jun 12 09:55:07 2026 +0200 w1: ds2482: add OF device match table [ Upstream commit 53f33fd74d3993af0fbb5494b5be709f6ca6b712 ] Add an of_device_id table and hook it into the i2c driver so the ds2482/ds2484 can be matched and auto-probed from Device Tree. This allows automatic module loading when instantiated via DT. Signed-off-by: Kryštof Černý Link: https://patch.msgid.link/20260612-w1-of-autoload-v1-1-74e8a17626e6@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 57206de03850e996f47a03a3c17bc56772d740d7 Author: Pengpeng Hou Date: Wed Jun 24 13:37:44 2026 +0800 gpio: pca9570: Use I2C match data [ Upstream commit 415c63896b76fd98883e190bc7518383cb01779c ] The driver stores chip metadata in both the OF match table and the I2C id table, but probe currently reads it with device_get_match_data(). That helper only returns firmware-node match data, so an I2C-id/modalias match can leave chip_data NULL before the driver dereferences it to read ngpio. Use i2c_get_match_data() so the I2C id table driver_data is consumed when firmware match data is not present. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260624053744.72612-1-pengpeng@iscas.ac.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 9ed5084ad144c47ed4d863a5a511316e7d019780 Author: YiPeng Chai Date: Tue Jun 16 16:18:22 2026 +0800 drm/amdgpu: add bounds check to prevent array overflow [ Upstream commit db15c49a17b8fab9ada38f3a548e5353d7d6b1a8 ] Add bounds check to prevent array overflow. v2: Add warning messages. Signed-off-by: YiPeng Chai Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3f42a8be82f5d1a6041b1a0f2768c0f6d3875a52 Author: Gangliang Xie Date: Tue Jun 16 17:04:47 2026 +0800 drm/amdgpu: add buf length check [ Upstream commit 473f99e4a262776141366f7fb10f101d0f22b019 ] add buf length check before using it to access data Signed-off-by: Gangliang Xie Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4edc3fa76cb2326c7ca77c167dbf640fc36c01ac Author: Ruoyu Wang Date: Mon Jun 8 14:36:38 2026 +0800 drm/radeon: avoid double free in r600 DPM cleanup [ Upstream commit d3f30034f861a585f8e487ae1555d9f288a96f87 ] r600_parse_extended_power_table() uses manual kfree() calls for some early allocation failures, but the freed pointers are left in the dynamic power-management state. If device teardown later calls r600_free_extended_power_table(), those stale pointers can be freed again. Use the common extended power table cleanup helper for those early failure paths as well, and clear each pointer after freeing it so repeated cleanup stays safe. Signed-off-by: Ruoyu Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b2a4082f3e46c98190daa25e9baae5a6915013af Author: Charlene Liu Date: Thu May 21 20:36:01 2026 -0400 drm/amd/display: fix max dispclk_khz/dppclk_khz double 1000 [ Upstream commit f48124ff35357d05a98d9cd5cb7982e7e5509003 ] [why] Fix regresson caused by double roundup and index out of range Reviewed-by: Dillon Varone Reviewed-by: Dmytro Laktyushkin Signed-off-by: Charlene Liu Signed-off-by: Aurabindo Pillai Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e62db8922f57b48855758967f98fd4fc111b9640 Author: Asad Kamal Date: Wed Jun 3 17:30:29 2026 +0800 drm/amdgpu: Gate debugfs MMIO access on kernel lockdown [ Upstream commit 17ac73b24006700f50972d37e297dec1f523c14a ] amdgpu_regs, amdgpu_regs2, and related debugfs nodes allow arbitrary MMIO read/write via RREG32/WREG32 without checking security_locked_down(). On kernel_lockdown=integrity systems this bypasses the same restrictions as /dev/mem and PCI config space sysfs. Check LOCKDOWN_PCI_ACCESS (matching pci-sysfs) at the entry of every debugfs handler that performs direct register access. v2: Use consistent check as per previous check to use LOCKDOWN_DEBUGFS(Lijo) v3: Do not create any entry from amdgpu_debugfs_regs_init() if LOCKDOWN_PCI_ACCESS is active and log once. (Lijo) Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a17744e6c6c7c743d4d93f9e941eb3f1a0b5d6c1 Author: Asad Kamal Date: Wed Jun 3 02:03:33 2026 +0800 drm/amd/pm: Validate OD DPM triples before mutating tables [ Upstream commit b390cb9d776039fc4f0be13b2649299079227d12 ] vega10_odn_edit_dpm_table() and smu7_odn_edit_dpm_table() could mutate the live ODN table for valid triples, then return 0 after detecting a truncated buffer or out-of-range index. Validate all (index, clock, voltage) triples first and return -EINVAL on any failure; only then apply updates. v2: Use distinct message for different error case, removed unused input_level from validation loop (Lijo) v3: Reject negative level indices, input[] is long but was compared only against unsigned table bounds, so negative values could pass and truncate when assigned to uint32_t input_level. Set DPMTABLE_OD_UPDATE_SCLK/MCLK only after validation passes, so a failed sysfs write does not leave need_update_dpm_table set for a later commit. Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit aa864c7ddfa02ff1b0d4bded606ed779247a1a41 Author: Jonas Karlman Date: Mon May 18 19:37:45 2026 +0000 drm/rockchip: dw_hdmi: Use resume_early pm ops for system suspend [ Upstream commit af3a9eadc11896f6677bcb7102bfb7c84be48d2d ] rockchip_drm_sys_resume()/drm_mode_config_helper_resume() is called before the resume pm ops of dw-hdmi. This result in an atomic_enable() before dw_hdmi_rockchip_resume()/dw_hdmi_resume() is called. Resume (without changes): - rockchip_drm_sys_resume() - drm_mode_config_helper_resume() - atomic_enable() - dw_hdmi_rockchip_resume() - dw_hdmi_resume() - dw_hdmi_init_hw() Change to use resume_early pm ops for system suspend to ensure pm ops for dw-hdmi is run before rockchip-drm pm ops. Also fix a possible NULL pointer dereference timing issue while at it. Resume (with changes): - dw_hdmi_rockchip_resume_early() - dw_hdmi_resume() - dw_hdmi_init_hw() - rockchip_drm_sys_resume() - drm_mode_config_helper_resume() - atomic_enable() Signed-off-by: Jonas Karlman Tested-by: Heiko Stuebner #rk3328 Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260518193748.2482823-12-jonas@kwiboo.se Signed-off-by: Sasha Levin commit d063975ed22cdc2cb609a9828e5f658448193606 Author: YuanZhe Liu <25031212351@stu.xidian.edu.cn> Date: Tue Oct 13 14:35:54 2026 +0800 ALSA: line6: Clear prev_fbuf on capture buffer release commit aa118c8f61d59387961d58ffae831c5259a9f222 upstream. A KASAN slab-use-after-free read was reported in submit_audio_out_urb() when generating an impulse test signal: BUG: KASAN: slab-use-after-free in create_impulse_test_signal sound/usb/line6/playback.c:76 [inline] BUG: KASAN: slab-use-after-free in submit_audio_out_urb+0x1848/0x1b20 sound/usb/line6/playback.c:249 Read of size 2 at addr ffff888008d74870 by task syz.2.3214/7785 Allocated by task 11: kmem_cache_alloc_noprof+0x2f0/0x390 mm/slub.c:4144 line6_buffer_acquire+0x1a1/0x220 sound/usb/line6/pcm.c:158 line6_pcm_acquire+0xb6/0x230 sound/usb/line6/pcm.c:329 line6_startup_work+0x3c/0x50 sound/usb/line6/driver.c:728 Freed by task 7785: kfree+0xf8/0x390 mm/slub.c:6566 line6_buffer_release sound/usb/line6/pcm.c:176 [inline] line6_buffer_release+0xa5/0xf0 sound/usb/line6/pcm.c:170 __line6_pcm_release sound/usb/line6/pcm.c:305 [inline] line6_pcm_release+0x5a/0x80 sound/usb/line6/pcm.c:313 snd_toneport_monitor_put+0x11b/0x190 sound/usb/line6/toneport.c:183 line6pcm->prev_fbuf points into the capture PCM stream buffer (line6pcm->in.buffer), which is updated during audio_in_callback() to feed rate synchronization, software monitoring, and impulse test signal generation on playback side. When all capture streams are closed, line6_buffer_release() frees pstr->buffer with kfree(). However, it does not clear line6pcm->prev_fbuf. If playback is subsequently started (e.g. via impulse test signal volume control snd_line6_impulse_volume_put()), submit_audio_out_urb() dereferences the stale pointer line6pcm->prev_fbuf under in.lock, resulting in a slab-use-after-free read. Clear prev_fbuf and prev_fsize in line6_buffer_release() when releasing the capture stream buffer under in.lock, ensuring that no stale buffer pointer can be accessed by submit_audio_out_urb(). Fixes: 63e20df1e5b2 ("ALSA: line6: Reorganize PCM stream handling") Cc: stable@vger.kernel.org Co-developed-by: Bin Yu Signed-off-by: Bin Yu Co-developed-by: Cheng Wen Signed-off-by: Cheng Wen Signed-off-by: YuanZhe Liu <25031212351@stu.xidian.edu.cn> Link: https://patch.msgid.link/20261013063554.571-1-25031212351@stu.xidian.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 094e8139cf5a5e37b363ac984f628359558415e6 Author: Yao Kai Date: Mon Jul 6 12:13:13 2026 +0800 ext4: validate readdir offset before accessing dirent commit bc4b7b0414c33b2c8898eb04386df0d21a13dad8 upstream. A corrupted directory can trigger the following KASAN report when ext4_readdir() resumes from an invalid position: BUG: KASAN: use-after-free in __ext4_check_dir_entry+0x5ef/0x820 Read of size 2 at addr ffff88810a646000 by task repro_linear/509 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 kasan_report+0xce/0x100 __ext4_check_dir_entry+0x5ef/0x820 ext4_readdir+0xcde/0x2b70 iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x12b/0x220 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f KASAN reports use-after-free because the out-of-bounds access lands in an adjacent freed page. The directory buffer itself is still referenced. ext4_dir_llseek() invalidates the directory cookie so that ext4_readdir() rescans directory entries from the start of the block. The rescan checks only the lower bound of rec_len before advancing. A corrupted rec_len can therefore place the offset where the block has insufficient space for a complete directory entry. The rescan itself may dereference that truncated entry, or the main loop may pass it to __ext4_check_dir_entry(). The latter reads de->rec_len before validating the range. For example: block offset 0 4092 4096 |---- de1.rec_len = 4092 -----|----| de2.inode | de2.rec_len ^ OOB, reported as UAF de2 starts at offset 4092 in this 4 KiB block. Its four-byte inode fits in the block, but its rec_len starts at offset 4096 and crosses the boundary. The minimum safe length is inode-dependent. Encrypted and casefolded directory entries need eight additional hash bytes, while a valid metadata checksum tail is only 12 bytes. Cache the metadata checksum feature state and derive the minimum directory entry length from the on-disk format. Use it to bound both the rescan and the offset passed to the main loop. Report an offset in a truncated block tail and skip the remainder of the block, while continuing to accept an offset exactly at the block boundary. Reported-by: syzbot+5322c5c260eb44d209ed@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5322c5c260eb44d209ed Fixes: ac27a0ec112a ("[PATCH] ext4: initial copy of files from ext3") Signed-off-by: Yao Kai Reviewed-by: Zhihao Cheng Reviewed-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20260706041313.708346-1-yaokai34@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit cadffc83ee1a560d5cd18e6d607c1d76f6fd4bd4 Author: Zihan Xi Date: Thu Sep 24 05:15:21 2026 +0000 net: gso: limit recursive IP-in-IP segmentation commit 006c8b834aed8b02bd8fb9fb05e9e7ead37d1763 upstream. IP-in-IP GSO can re-enter inet_gso_segment() or ipv6_gso_segment() for each nested IP header. encap_level tracks header bytes, not callback depth, so a deep chain can exhaust the kernel stack. Making inet_gso_segment() stackable introduced unbounded IPv4 nesting; IPIP GSO/TSO later made the path reachable. The IPv6 stackable path was introduced separately and uses the same guard. Count IPv4 and IPv6 GSO handler entries in skb_gso_cb, initialized once per top-level GSO operation and preserved across GRE/UDP context changes. Use the existing IP_TUNNEL_RECURSION_LIMIT for both handlers. The first five entries pass, and the sixth returns -EINVAL before dispatching another GSO callback. Fixes: 3347c9602955 ("ipv4: gso: make inet_gso_segment() stackable") Cc: stable@vger.kernel.org Reported-by: Vega Closes: https://lore.kernel.org/all/cover.1790157745.git.zihanx@nebusec.ai/ Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260924051521.32568-2-zihanx@nebusec.ai Signed-off-by: Paolo Abeni [ Ting-Han: ipv6_gso_segment() still calls ipv6_hopopt_jumbo_remove() right after skb_reset_network_header() in this version; keep the new recursion check directly after skb_reset_network_header() as upstream does, before the jumbo removal ] Signed-off-by: Ting-Han Hou Signed-off-by: Greg Kroah-Hartman commit b6f70f00f5937c9ab0797be766ec8b7df489d29d Author: Jérémy Jean Date: Fri Oct 9 14:53:53 2026 +0200 lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON state commit 24f07e8c07a0c0dd275331cbb41c79a78741eef9 upstream. When poly1305_blocks_neon() resumes from a base 2^26 accumulator and the next update contains an odd number of full 16-byte blocks, it processes one leading block through poly1305_mult() so that the remaining NEON work has an even block count. That requires converting the accumulator to the base 2^64 form used by poly1305_mult(). The final ADC of that conversion stores the carry into d2, but the following accumulation and poly1305_mult() use h2. If the conversion carries across bit 128, the carry is dropped and the emitted tag is wrong. This was introduced by Cryptogams commit 03dc4adf91c8 ("arm/poly1305-armv*.pl: optimize branches."), which removed the reduction that consumed d2 shortly before Linux imported the code. OpenSSL's copy did not take that change. The carry is possible because the NEON code stores the accumulator [h0, h1, h2, h3, h4] in a lazily reduced, redundant base 2^26 form: its final carry chain leaves h0, h2, h3 < 2^26, but h1 and h4 may slightly exceed 2^26 - 1. For example, the reachable state h0 = 4 h1 = 2^26 h2 = 2^26 - 1 h3 = 2^26 - 1 h4 = 2^24 - 1 represents 4 + 2^26*2^26 + (2^26-1)*2^52 + (2^26-1)*2^78 + (2^24-1)*2^104 = 2^128 + 4, despite the bit representing the 2^128 term (bit 24 of h4) not being set; the extra comes from the h1 limb being above the normal base 2^26 range. When this value is converted into the non-redundant base 2^64 form, a carry into the new 2^128 bit (in bit 0 of h2) is necessary to preserve the value. Given the above bounds, a carry into bit 128 happens exactly when h1 >= 2^26, h2 = h3 = 2^26 - 1, and h4 mod 2^24 = 2^24 - 1. Store the carry into h2, matching the other base 2^26 to base 2^64 conversions in poly1305_blocks() and poly1305_emit(). This bug causes an incorrect tag to be emitted. However, this is unlikely to happen in practice where Poly1305 is used with a random key, since the random key tends to distribute the accumulator values throughout their valid range. There isn't an obvious way for an attacker without knowledge of the r_key to cause [h0, h1, h2, h3, h4] to land on the precise values where this bug occurs. [EB: Rewrote the commit message to more clearly describe the bug and its impact, and simplified explanation about why there's a carry bit.] Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Jason A. Donenfeld Signed-off-by: Jérémy Jean Link: https://patch.msgid.link/20261009125354.315476-2-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 3a0cdf3eb9c3026b046efe32f01b9090ab4e2d73 Author: Christian Brauner Date: Wed Oct 28 15:03:34 2026 -0400 fork: don't create io threads once PF_POSTCOREDUMP is set [ Upstream commit 1f978881ce6c9ac4f4d4a7b6a6e52339eadcd350 ] zap_process() skips every thread that already has PF_POSTCOREDUMP set. Such a thread is past synchronize_group_exit(), so a coredump can't catch it anymore. It isn't counted in core_state->threads_remaining and it isn't sent SIGKILL. do_exit() sets PF_POSTCOREDUMP in synchronize_group_exit() and calls io_uring_files_cancel() right after that. The cancellation runs task work and a create_worker_cb() that io-wq queued before the exit creates a new io-wq worker from there. If another thread started a coredump in the meantime that worker joins a thread-group which is already being dumped. zap_process() never saw it so it was never counted. But when it exits it sees signal->core_state in synchronize_group_exit() and decrements threads_remaining like any other thread. So the count reaches zero one thread early and the dumper leaves coredump_wait_inactive() while a thread it counted is still running. The task has no fatal signal pending because zap_process() deliberately didn't send it one, and it never went through get_signal() so it doesn't have PF_SIGNALED either. Refuse to create an io thread when the creator has PF_POSTCOREDUMP. That costs nothing. io_uring_files_cancel() raises IO_WQ_BIT_EXIT before it runs any task work, so a worker created from there only ever gets to exit again, and io_should_retry_thread() doesn't retry -EINTR. Clearing PF_POSTCOREDUMP for the new thread in copy_process() was the other option. It makes the worker a thread like any other, but it only helps while the dump hasn't started. A worker born after zap_process() has run is invisible to it whatever its flags say and still decrements threads_remaining on the way out. Refusing to create it covers both, and then no task is ever born with the flag, so there is nothing to clear. Moving io_uring_files_cancel() ahead of synchronize_group_exit() closes the same window. It runs the cancellation, and whatever that can block on, before the thread announces itself to the dumper. A thread that blocks there never reaches coredump_task_exit() at all, so the dumper ends up waiting for a thread that never parks. Refusing the creation leaves the cancellation where it is. But it's very ugly to run io_uring work even before we did all the generic exit work. Fixes: 92307383082d ("coredump: Don't perform any cleanups before dumping core") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-14-8e4adb1619e6@kernel.org Acked-by: Oleg Nesterov Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit c7ee0f9de827d01080376eb8750d86fe65383aef Author: Christian Brauner Date: Wed Oct 28 15:03:33 2026 -0400 fork: move the coredump and exec checks into create_io_thread() [ Upstream commit e760200370e4de054b6b5f568a7faa911e2956bb ] Only a PF_USER_WORKER thread returns from get_signal() after a fatal signal and can go on to create a thread. get_signal() sets PF_SIGNALED before it dumps core and before it lets a PF_USER_WORKER thread return. That flags sticks. The exec'ing thread itself is never signaled. But it doesn't need the check anyway as we moved cancellation of io_uring requests before de_thread(). create_io_thread() is the only way a signaled thread creates another one. vhost_task_create() is reached from ioctls alone. io_should_retry_thread() doesn't retry -EINTR, so io-wq callers give up the same way they did when copy_process() refused. Suggested-by: Oleg Nesterov Link: https://lore.kernel.org/r/aq0VLTyxNatFmLOK@redhat.com Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-13-8e4adb1619e6@kernel.org Acked-by: Oleg Nesterov Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: 1f978881ce6c ("fork: don't create io threads once PF_POSTCOREDUMP is set") Signed-off-by: Sasha Levin commit 289f954b51ef34e42a10002f3bbf1db6930d8e92 Author: Christian Brauner Date: Wed Oct 28 16:13:33 2026 -0400 exec: cancel io_uring requests before de_thread() [ Upstream commit b42c85c20d84ff3e4f0f027d6596c3b3b4a20657 ] begin_new_exec() cancels the exec'ing thread's io_uring requests after de_thread() made it the only thread in the thread-group. Now io_uring_task_cancel() runs task work after. If it runs a create_worker_cb() item then a io-wq queued on the thread before the exec creates a new io-wq worker thread. Said thread joins the thread-group which de_thread() just took down. The io-iwq sticks around until it notices that its workqueue is dying. But code after de_thread() relies on being single-threaded. Move io_uring_task_cancel() before de_thread() but behind the point of no return. Any worker created during task work run from io_uring_task_cancel() is just a sibling thread that de_thread() will take down and reap. Once io_uring_task_cancel() returned the thread has neither a task context nor a workqueue left so nothing can add a thread behind de_thread()'s back anymore. Suggested-by: Oleg Nesterov Link: https://lore.kernel.org/r/aq0_lvHDViIpX_Mu@redhat.com Fixes: 3bfe6106693b ("io-wq: fork worker threads from original task") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-12-8e4adb1619e6@kernel.org Acked-by: Oleg Nesterov Reviewed-by: Jens Axboe Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit e12324a3fc4507d5ee796dcb14db6b53ffc12a27 Author: André Draszik Date: Fri Oct 30 12:15:53 2026 +0000 kbuild: link-vmlinux.sh: improve detection of third pass requirement commit 14b8b4bf2d7bd5d58c17adbeed0edfda1dfc1a7f upstream. It can happen that symbol sizes within .tmp_vmlinux1.kallsyms.o and .tmp_vmlinux2.kallsyms.o differ, without affecting file size on disk because of section alignment and/or padding emitted by the assembler. link-vmlinux.sh doesn't detect this case currently and keeps using .tmp_vmlinux2.kallsyms.o to link the final vmlinux. Due to the different symbol sizes, other symbols are shifted within the final image compared to .tmp_vmlinux2, and the final comparison of System.map against "${kallsyms_sysmap}" fails with the message: Inconsistent kallsyms data Try "make KALLSYMS_EXTRA_PASS=1" as a workaround This can happen in particular if the linker emits additional symbols that might have different names between our (re-)linking steps, e.g. because those names depend on the virtual address of the symbol. Linker stubs for ARM errata work-arounds are one such case. These changed symbol names can cause the output of the token compression of kallsyms.c to change due to the changed symbol substring count, which in turn can change the size of the kallsyms_names symbol itself, causing the potential shift of subsequent symbol addresses in .tmp_vmlinux2.kallsyms.o and therefore the final image. Update link-vmlinux.sh to not rely on file size of .tmp_vmlinux?.kallsyms.o alone but to also consider symbol offsets within to resolve this, and do a third pass if required. Signed-off-by: André Draszik Tested-by: Nathan Chancellor Reviewed-by: Nicolas Schier Signed-off-by: Nicolas Schier [AD: adjust context] Signed-off-by: André Draszik Signed-off-by: Sasha Levin commit a359762c50087d05ced6ce5b1df1b13d7e10944c Author: Ridham Khurana Date: Mon Sep 21 20:41:47 2026 +0000 platform: cznic: turris-omnia-mcu: Add missing MODULE_DEVICE_TABLE() [ Upstream commit 59797443846bc2451c35816026bbb79d281c9f23 ] The driver wires of_omnia_mcu_match into the i2c_driver's .of_match_table but never exports it with MODULE_DEVICE_TABLE(), so no module alias is generated and the module is not autoloaded when the MCU is probed from the device tree. Found by code inspection. Not tested on the hardware itself; with the module built, the alias lookup $ modprobe -R 'of:Nsystem-controllerT(null)Ccznic,turris-omnia-mcu' reports no match before this change and resolves to turris_omnia_mcu after it. Fixes: 992f1a3d4e88 ("platform: cznic: Add preliminary support for Turris Omnia MCU") Signed-off-by: Ridham Khurana Link: https://patch.msgid.link/20260921204204.797294-1-khurana.ridham222@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 86d74888d2a812110fd6a5d9b6468a3dc8623283 Author: Daniel Schaefer Date: Thu Jul 23 01:18:58 2026 +0800 iio: hid-sensor: als: scale each channel individually [ Upstream commit cad928dad9a4c26aa56b4223dc2a29bca517fb5f ] Some sensors have multiple channels (not just brightness but color ALS sensors) with different scaling factors. Signed-off-by: Daniel Schaefer Link: https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/merge_requests/413 Tested-by: Sven Vainküla #Asus ProArt PX13 laptop. Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit cf88969012cfef92219dbc8c810fb92007fdde29 Author: SJ Park Date: Wed Oct 28 07:11:49 2026 -0700 mm/damon/sysfs: put target pids for apply_inputs() failure damon_sysfs_build_ctx() invokes damon_sysfs_apply_inputs() for setting damon_ctx object with user inputs. If it is configured for virtual address spaces monitoring, the setup also increases reference counts of monitoring target pids. If the setup is failed, damon_sysfs_build_ctx() deallocates the damon_ctx object without decreasing the reference counts of the pids. If the failure happened after increasing reference counts of pids, the pids can be leaked. Fix the leaks by decreasing the pid reference counts before deallocating the damon_ctx object. The issue was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260730040740.140836-1-sj@kernel.org Fixes: 74bd8b7d2f8e ("mm/damon/sysfs: move targets setup code to a separated function") Cc: # 5.19.x Signed-off-by: SJ Park Signed-off-by: Sasha Levin commit 57f04f5099be86e7736740cacbc4edfe1ec764c1 Author: SJ Park Date: Wed Oct 28 07:11:48 2026 -0700 mm/damon/sysfs: put target pids for damon_start() failure damon_sysfs_turn_damon_on() allocates and sets up damon_ctx to start. If it is for virtual address space monitoring, the setup increases the reference counts of the target pids. After the setup, the function invokes damon_start(). If damon_start() fails, it deallocates the damon_ctx object without decreasing the reference counts of target pids. As a result, pids can be leaked. Fix the leak by putting pids using damon_sysfs_destroy_targets() before deallocating the damon_ctx object. Fixes: a61ea561c871 ("mm/damon/sysfs: link DAMON for virtual address spaces monitoring") Cc: # 5.18.x Signed-off-by: SJ Park Signed-off-by: Sasha Levin commit 403f3a6b2c0c00002adbef503604a9ba57d11b38 Author: Baolin Wang Date: Wed Oct 28 00:33:55 2026 +0800 mm: vmscan: fix dirty folios throttling on cgroup v1 for MGLRU [ Upstream commit 13b6b620910436c29dea398382e83c9499fd13e4 ] The balance_dirty_pages() won't do the dirty folios throttling on cgroupv1. See commit 9badce000e2c ("cgroup, writeback: don't enable cgroup writeback on traditional hierarchies"). Moreover, after commit 6b0dfabb3555 ("fs: Remove aops->writepage"), we no longer attempt to write back filesystem folios through reclaim. On large memory systems, the flusher may not be able to write back quickly enough. Consequently, MGLRU will encounter many folios that are already under writeback. Since we cannot reclaim these dirty folios, the system may run out of memory and trigger the OOM killer. Hence, for cgroup v1, let's throttle reclaim after waking up the flusher, which is similar to commit 81a70c21d917 ("mm/cgroup/reclaim: fix dirty pages throttling on cgroup v1"), to avoid unnecessary OOM. The following test program can easily reproduce the OOM issue. With this patch applied, the test passes successfully. $mkdir /sys/fs/cgroup/memory/test $echo 256M > /sys/fs/cgroup/memory/test/memory.limit_in_bytes $echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs $dd if=/dev/zero of=/mnt/data.bin bs=1M count=800 Link: https://lore.kernel.org/3445af0f09e8ca945492e052e82594f8c4f2e2f6.1774606060.git.baolin.wang@linux.alibaba.com Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation") Signed-off-by: Baolin Wang Reviewed-by: Barry Song Reviewed-by: Kairui Song Acked-by: Johannes Weiner Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: David Hildenbrand Cc: Lorenzo Stoakes (Oracle) Cc: Michal Hocko Cc: Qi Zheng Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton Signed-off-by: Leno Hou Signed-off-by: Sasha Levin commit 7ccd2e123e16f6e92bff0a8f797d938eb4ee388f Author: SJ Park Date: Tue Oct 27 18:02:46 2026 -0700 mm/damon/core: error damos_commit_quota_goal() for zero target_value commit 610c4438fb66e06d9e693c0ad3b2c1be54c0d61f upstream. Patch series "mm/damon: move zero damos quota target_value handling to the core layer". Having zero DAMOS quota target value can cause division by zero. DAMON API callers are checking the target value parameters to avoid that. It is easy to make mistakes in some of the multiple API callers. Move that to the core layer. Patch 1 adds the corner case handling into the core layer DAMON parameters validation logic. Patches 2 and 3 remove no more needed DAMON API callers side handling of the corner case in DAMON_LRU_SORT and DMON_SAMPLIE_MTIER, respectively. This patch (of 3): If a DAMOS scheme has a damos_quota_goal of zero target_value, damos_quota_goal() could trigger division-by-zero error. Hence each DAMON API callers should do the zero target_value validation. It is easy to make mistakes. Actually such bugs in DAMON_LRU_SORT and DAMON_SAMPLE_MTIER were found and fixed [1]. It is better to handle the corner case only once in the core layer, instead of multiple places in all DAMON API callers. One straightforward option is using an alternative denominator for the corner case in the damos_quota_goal(). However, the zero target_value is meaningless. In this case, the quota goal is always evaluated as achieved or over-achieved. The quota will only keep being reduced. Simply avoid using zero target_value by adding a check in the core layer DAMOS quota goal parameters validation/commit path, damos_commit_quota_goal(). Update it to return an error in the case. Also update its caller to propagate the error. Notes for stable kernel porting. The upstream commit doesn't have Fixes: and therefore not ported to stable kernels. It turned out it fixes commit 8b549a4fd3c5 ("mm/damon/sysfs-schemes: commit damos quota goals user input to DAMOS") which was merged into v6.8. The user impact is a race condition that can result in divide-by-zero. Hence backport. Reproducing the issue requires sysfs write permission, certain DAMON ABI usages that are supposed to be uncommon, and a rare race timing, though. The issue was discovered [2] by Sashiko as a part [3] of its bug report. Also, the upstream commit on this stable kernel can fix the issue for parameters commit paths but DAMON start path. That's because DAMON start path does not invoke damon_commit_quota_goals(). To fix the path with minimum change, add a new small validation of quota goal target value before damon_start() call. [2] https://sashiko.dev/#/bug/linux-7f814c9a-986f-4103-a55a-ef9537dcf62b [3] https://lore.kernel.org/20261021005234.94107-1-sj@kernel.org Link: https://lore.kernel.org/20260903010722.94244-1-sj@kernel.org Link: https://lore.kernel.org/20260903010722.94244-2-sj@kernel.org Link: https://lore.kernel.org/20260803134034.15217-1-sj@kernel.org [1] Signed-off-by: SJ Park Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Sasha Levin commit 5e1d24bffe763c1319f942a72b041659d56cbb91 Author: Sasha Levin Date: Thu Oct 29 11:04:41 2026 -0400 Revert "KVM: s390: move pv gmap functions into kvm" This reverts commit 0962b3d34c742be43c7488a7cad839e73ae08005. Signed-off-by: Sasha Levin commit b968162099a1a92fa141e10fbab78125a121a639 Author: Sasha Levin Date: Thu Oct 29 11:04:41 2026 -0400 Revert "KVM: s390: use __kvm_faultin_pfn()" This reverts commit 151690151a255c29115975ee474718b94a84ffb5. Signed-off-by: Sasha Levin commit 635580232ad70a44b352c0a53b3accf113de61a7 Author: Sasha Levin Date: Thu Oct 29 11:04:41 2026 -0400 Revert "KVM: s390: move gmap_shadow_pgt_lookup() into kvm" This reverts commit 4f2fe83204ec878499b33b260d9b1b8c8c20f512. Signed-off-by: Sasha Levin commit c891a96103c4c3f75ac8873345e99f2c53988234 Author: Sasha Levin Date: Thu Oct 29 11:04:41 2026 -0400 Revert "KVM: s390: pv: fix race when making a page secure" This reverts commit 45a6af5413239dcd0d0084e41ea04ce685c4d3c2. Signed-off-by: Sasha Levin commit c6eb0d9b70e8560aa4d14c2ba10711bf10daac99 Author: Sasha Levin Date: Thu Oct 29 11:04:41 2026 -0400 Revert "KVM: s390: Fix FOLL_*/FAULT_FLAG_* confusion" This reverts commit f5b6a9fa37d0770f9977b9b3b9fb1dc6cb0423f3. Signed-off-by: Sasha Levin commit 23a5e1b8b77c2d977ec0923397ffc70be6581574 Author: Sasha Levin Date: Thu Oct 29 11:04:41 2026 -0400 Revert "s390/uv: Don't return 0 from make_hva_secure() if the operation was not successful" This reverts commit cd78dd7fb054945c81d7106a094590be36f0553a. Signed-off-by: Sasha Levin commit 6c7b5eb6f7f424f5b82d0f9469a5f5adcdf4d973 Author: Fuad Tabba Date: Thu Oct 29 02:23:08 2026 +0000 KVM: arm64: Transfer the hyp stack pages out of the host stage-2 [ Upstream commit 3a8c562892b96f35bba1e00d5e455a15963bbb92 ] fix_host_ownership() walks only the linear-map alias of each memblock region, and the per-CPU hyp stack, mapped in the private VA range for its guard page, has none. Walk each stack's VA range with the same walker. Fixes: 1a919b17ef012 ("KVM: arm64: Add guard pages for pKVM (protected nVHE) hypervisor stack") Reported-by: Hiroyuki Katsura Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Reviewed-by: Vincent Donnefort Tested-by: Vincent Donnefort Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260908110713.1540304-2-fuad.tabba@linux.dev Signed-off-by: Oliver Upton [ 38f9e4b905a0 ("arm64: kvm: Introduce nvhe stack size constants") is not backported because it converts nvhe stack code in eight files to NVHE_STACK_SIZE, and the hyp stack here is one page, so PAGE_SIZE replaces it. ] Assisted-by: LLM Signed-off-by: Mark Bundschuh Signed-off-by: Sasha Levin commit a9039d6c9de5dfd91f360b085da75899055b15a5 Author: Namjae Jeon Date: Wed Sep 30 20:39:53 2026 +0900 ksmbd: wait for negotiation before receiving another PDU [ Upstream commit 68f410faedaf6ee74d81e574733c50ebcc1bd8ed ] The receive thread queues a request and can read the next PDU before the negotiation worker finishes. While need_neg is set, the next PDU can cause ksmbd_init_smb_server() to replace conn->ops. A pipelined SMB2 request can therefore make the worker handle an earlier, shorter SMB1 request with SMB2 operations and read beyond its buffer. An SMB1 multi-protocol negotiate may be followed by an SMB2 NEGOTIATE that changes conn->ops again. Wait for work queued while the connection is new or needs negotiation to complete before reading another PDU. This keeps the operations stable for both stages of negotiation without changing when need_neg is cleared. Fixes: dc8289f91238 ("ksmbd: fix slab-out-of-bounds in init_smb2_rsp_hdr") Reported-by: ihopenre-eng Reviewed-by: ihopenre-eng Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit fe8477e23dd2ee6bce231d65f2586a333b211dc0 Author: Zizhen Liu Date: Thu Oct 22 18:42:17 2026 +0800 net: skbuff: propagate shared-frag marker in skb_zerocopy() commit 79dc34beb1fdb3da79753e51e15c68591a2561fe upstream. skb_zerocopy() moves frag descriptors from @from into @to and takes a reference on each frag, but it does not copy skb_shinfo(from)->flags into skb_shinfo(to)->flags. A destination skb holding the same page-cache backed frags as the source therefore reports skb_has_shared_frag() as false. That breaks the invariant relied on by later in-place writers. ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(); with the marker lost, an skb that skb_zerocopy() built for nfnetlink_queue or for an openvswitch upcall is decrypted in place, letting an unprivileged user write into the page cache of a root-owned read-only file. Propagate SKBFL_SHARED_FRAG when frag descriptors are copied, as done for the other frag-transfer helpers. Fixes: af2806f8f90a ("net: Export skb_zerocopy() to zerocopy from one skb to another") Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb frags") Cc: stable@kernel.org Signed-off-by: Zizhen Liu Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20261022104217.1852191-1-pointerliu@126.com Signed-off-by: Jakub Kicinski [ sashal: Adjusted context in skb_zerocopy() due to missing from->unreadable propagation. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman