commit dfcdacd1d25b85eb2e85d2b9ccb030e15e6c1b27 Author: Alexandre Frade Date: Tue Nov 10 21:19:54 2026 +0000 Linux 6.18.63-xanmod1 Signed-off-by: Alexandre Frade commit c66867ef86e3677a3ab3ff01ae16622a042dc571 Merge: dd88d1689590 1cdda838e847 Author: Alexandre Frade Date: Tue Nov 10 21:18:43 2026 +0000 Merge tag 'v6.18.63' into 6.18 This is the 6.18.63 stable release commit 1cdda838e8475edf89b73ff0cc952005dd0b1fa7 Author: Greg Kroah-Hartman Date: Tue Nov 10 13:07:06 2026 -0500 Linux 6.18.63 Link: https://lore.kernel.org/r/20261107134852.069646174@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Miguel Ojeda Tested-by: Ron Economos Tested-by: Barry K. Nathan Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit c5f54af611ff6fe1d53fa05d8e87b469dc56122b 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 a97aa838903d15f865d80809f5198ff459c6634a 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 5d68f3fd958b90b65faa879108ef2a47fa3c25c0 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 26d2534b6f1e78f3515f68b62786c38fcb210f92 Author: John Johansen Date: Thu Oct 29 16:53:12 2026 -0700 apparmor: fix uninitialized variable warning in aa_inherit_files [ Upstream commit ed35bbe7d06e6505401eff3f3c7a36bd1f167a17 ] Fix the following warning All warnings (new ones prefixed by >>): >> security/apparmor/file.c:737:53: warning: variable 'file' is uninitialized when used here [-Wuninitialized] 737 | int error = aa_file_perm(OP_INHERIT, cred, label, file, | ^~~~ security/apparmor/file.c:724:36: note: initialize the variable 'file' to silence this warning 724 | struct file *devnull = NULL, *file; | ^ | = NULL 1 warning generated. vim +/file +737 security/apparmor/file.c 719 720 /* based on selinux's flush_unauthorized_files */ 721 void aa_inherit_files(const struct cred *cred, struct files_struct *files) 722 { 723 struct aa_label *label = aa_get_newest_cred_label(cred); 724 struct file *devnull = NULL, *file; 725 bool devnull_tried = false; 726 unsigned int n = 0; 727 728 revalidate_tty(cred, label); 729 730 /* 731 * Revalidate access to inherited open files. Each file is 732 * revalidated holding only a reference to it, with no locks 733 * held, as revalidation may sleep (e.g. unix socket mediation 734 * dropping path refs, or allocating path buffers). 735 */ 736 while ((n = iterate_fd(files, n, get_next_file, &file)) != 0) { > 737 int error = aa_file_perm(OP_INHERIT, cred, label, file, Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202610292346.ehqNujiE-lkp@intel.com/ Fixes: a913281f60015 ("apparmor: don't revalidate inherited files under files->file_lock") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 99c09b6a5ebeddf2643c4266f4381efc4754e5c7 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 337783277c0b0ee57bde6d9be4c9ea3d93c5d31d 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 662ac91c9ffd4e71da45d6998c381658c209824b 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 f4acf474e4dc4f235a6fd343a8bc808ff6de62a8 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 0da582bda88a6b0621aa9c6305354a14244bd922 Author: Edvard Conrad Date: Thu Oct 29 22:18:40 2026 +0100 fs: let backing files inherit FMODE_NONOTIFY from the user file [ Upstream commit c3d355f427cea70fbe31b49e21f1915dbf37f2e6 ] When fanotify reports a permission event, copy_event_to_user() creates the event fd with dentry_open_nonotify(), so that the listener's use of that fd does not generate further events. If the event's path is on a stacked filesystem, the stacked filesystem's ->open() opens the real file with backing_file_open(). Since commit ebe559609d78 ("fs: get rid of __FMODE_NONOTIFY kludge"), FMODE_NONOTIFY lives in f_mode only and the backing file does not inherit it: it is allocated with the default fsnotify mode, and fsnotify_open_perm_and_set_mode() raises FS_OPEN_PERM on the real path if the backing filesystem has permission event watchers. Before that commit __FMODE_NONOTIFY travelled in f_flags, and overlayfs copies the user file's f_flags into the backing open (ovl_open_realfile()), so the backing file was exempt implicitly. Commit bc2473c90fca ("ovl: enable fsnotify events on underlying real files") relied on that when it dropped FMODE_NONOTIFY from OVL_OPEN_FLAGS. The nested event is queued to the same group, from inside the listener's read(2), and can only be answered by another reader thread of that group. A listener holding filesystem marks on both the stacked and the backing filesystem therefore deadlocks as soon as all of its reader threads are inside such a read(2) at the same time, and every other task that touches a marked filesystem queues up behind it. Observed with a commercial anti-malware agent (16 reader threads) on an ostree/composefs host: / is an overlayfs whose data layer is the ostree object store on the same btrfs that holds /etc and /home, and a systemd-sysext overlay sits on /usr. Every on-demand scan of /usr wedged the whole machine until the group was killed. Stack of a blocked reader thread on 7.2.7: fanotify_get_response fanotify_handle_event send_to_group fsnotify __fsnotify_parent do_dentry_open vfs_open backing_file_open ovl_open_realfile [overlay] ovl_open [overlay] do_dentry_open vfs_open backing_file_open ovl_open_realfile [overlay] ovl_open [overlay] do_dentry_open vfs_open dentry_open_nonotify copy_event_to_user fanotify_read vfs_read ksys_read Userspace cannot avoid this: the backing open happens while the kernel builds the fd, before the event is reported, and fid reporting is not available for permission event classes. Make a backing file inherit FMODE_NONOTIFY when the user file it is opened for must not generate events. This restores the pre-6.14 behaviour for the fds that fanotify creates (and for any other FMODE_NONOTIFY file), while ordinary opens through a stacked filesystem keep generating events on the real path, as intended by bc2473c90fca. Verified with a self-contained reproducer (private tmpfs lower layers, an overlayfs over them, FAN_OPEN_PERM filesystem marks on the overlay and on one lower layer, a child opening a file through the overlay) in a qemu VM on this tree built with defconfig plus OVERLAY_FS, FANOTIFY and FANOTIFY_ACCESS_PERMISSIONS: without this patch the listener's read(2) never returns and the child's open is released only by the listener's death; with it read(2) returns, the event is answered and the open completes. backing_tmpfile_open() is left alone: its only caller is ovl_create_tmpfile(), whose user file is a regular overlayfs file. Fixes: ebe559609d78 ("fs: get rid of __FMODE_NONOTIFY kludge") Cc: stable@vger.kernel.org Reviewed-by: Amir Goldstein Signed-off-by: Edvard Conrad Link: https://patch.msgid.link/P58Wrer--F-9@tuta.io Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 8bceb60345446206ddaa648020e5bbff65409af8 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 325b62c95822975a65fe5d0c70e106a68f1ee700 Author: Chris Mason Date: Thu Oct 29 15:00:22 2026 +0100 iov_iter: fix NULL deref in iov_iter_alignment() [ Upstream commit a290a9e5cf5fbba05d6c59b94b36d00f4fc15ef2 ] Since commit 111a12b422a8 ("io_uring/rsrc: reject zero-length fixed buffer import") io_import_fixed() hands out an empty ITER_BVEC for a zero-length request. Its count is 0 and its bvec array is NULL. iov_iter_alignment() only checks the count for ITER_UBUF. For ITER_BVEC it calls iov_iter_alignment_bvec() and the do-while loop in there reads bvec->bv_len before it looks at the count. So it dereferences NULL. btrfs checks the alignment of a direct read with iov_iter_alignment() before it looks at the count and f2fs does the same. So any user that can open a file on btrfs can oops the kernel with a single zero-length IORING_OP_READ_FIXED on an O_DIRECT file descriptor. With IOSQE_ASYNC the oops happens in an io-wq worker. The dead worker stays on the worker list and when the task that submitted the request exits io-wq writes to the freed task_struct of the worker. That's just fallout from the oops though. Empty iterators with a NULL array aren't unusual. afs, tls and tipc create them as well. So leave io_uring alone and make iov_iter_alignment() return 0 for an empty iterator of any type. Fixes: 111a12b422a8 ("io_uring/rsrc: reject zero-length fixed buffer import") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Link: https://patch.msgid.link/20261029-work-fs-ai-fixes-v1-3-88f22792f6f7@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 4a70894450cb4d0d5308a9b831e30a8fe0a5a156 Author: Christian Brauner Date: Thu Oct 29 15:00:21 2026 +0100 backing-file: enforce append-only and immutable backing inodes [ Upstream commit 19b18e01d0361ce495be153ecce80b581086ab3f ] FUSE passthrough opens the backing file anew whenever the FUSE file is opened. fuse_passthrough_open() passes the flags of that open to backing_file_open() which opens the backing file with vfs_open() and the credentials of the server. But vfs_open() doesn't go through may_open(). So the backing inode is never checked for S_APPEND and S_IMMUTABLE. The checks that did run were done on the FUSE inode and that one never has either flag. So anyone who may open the FUSE file for writing can overwrite an append-only backing file anywhere or write to an immutable one. The server only has to register the file and a read-only or even an O_PATH file descriptor is enough for that. Registering requires CAP_SYS_ADMIN but the writer can be any user that the server lets open the file. The FUSE inode is checked instead of the backing inode in a few more places: - do_mmap() refuses a shared mapping of an append-only file that was opened for writing. A FUSE file opened with O_RDWR | O_APPEND passes the open check and can then be mapped shared and written to at any offset. - fcntl(F_SETFL) and RWF_NOAPPEND refuse to take append mode away from a file on an append-only inode. On the FUSE file both succeed. A synchronous write still appends because the backing file was opened with O_APPEND. But an asynchronous write is submitted with the flags of the user's kiocb and lands at the given offset. Do the checks on the backing inode. backing_file_open() refuses to open an immutable inode for writing and an append-only inode for writing without O_APPEND, just like may_open(). backing_file_mmap() refuses a shared mapping of an append-only inode, just like do_mmap(). And writes and splices to a backing file in append mode fail if append mode was taken away from the user file. A FUSE file that was opened before the backing file became append-only can still write anywhere. That's what happens on the native filesystem as well and the backing file of such a file isn't in append mode. Two differences remain. F_SETFL succeeds and the next write fails. And FUSE reports EIO for a refused open because it turns every error from opening the backing file into EIO. overlayfs uses the same helpers but it mirrors S_APPEND and S_IMMUTABLE in its own inode and a chattr through the overlay never sets them on the upper inode. So for overlayfs this only changes something if the upper inode is changed behind the overlay's back. Fixes: 4a90451bbc7f ("fuse: implement open in passthrough mode") Reported-by: Chris Mason Cc: stable@vger.kernel.org # v6.9+ Link: https://patch.msgid.link/20261029-work-fs-ai-fixes-v1-2-88f22792f6f7@kernel.org Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 7d0e4a0f1aedaa81250538b9c115a4ba53d69f1f 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 a08cef6d1aead92a85dea5a8b7a826b4355d0303 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 464df36ba29d68bfab38d19c18127fdcebeb5a3f 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 7d6eccadf776e56f13873b1b8de4e7583b51fc02 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 e5b1fefc2dcd8951874be43f409c8a61f574f6d9 Author: Guanglei Zhu Date: Wed Sep 16 19:53:07 2026 +0800 apparmor: check accept index + 1 is in bounds [ Upstream commit afe5d5a747393cb3d00795db31d7fce5108a766a ] aa_lookup_condperms() returns perms[index + 1] when an accept entry has ACCEPT_FLAG_OWNER set and the subject uid does not match the file uid, so such an entry consumes two slots in the perms table. But verify_dfa_accept_index() only checks that index is within the perms table, so a policy that sets the owner flag on the last entry is accepted, and the runtime lookup then reads perms[index + 1] one entry past the end of the table. The perms table is allocated by unpack_perms_table() with a u16 size read from the policy blob, so a crafted policy can place the owner flag at index size - 1 to reach the out-of-bounds read. Check that index + 1 is also in bounds when the owner flag is set. Fixes: 6f442d42c0d89 ("apparmor: fix profile verification and enable it") Cc: stable@vger.kernel.org Signed-off-by: Guanglei Zhu Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 4971c6f821ff06a01c0779d0b1f9d0fd6452e3fe Author: Li RongQing Date: Thu Oct 8 11:15:33 2026 +0800 apparmor: avoid potential double free when remapping DFA tables [ Upstream commit 7ccd884a5e5386f4c7d98625113f4924f70286b4 ] When unpacking a DFA, aa_dfa_unpack() stores a table in dfa->tables before attempting to remap a 16-bit table to 32-bit. However, remap_data16_to_data32() frees the original table when allocation of the new table fails. This leaves the corresponding dfa->tables entry pointing to freed memory. If the unpacking then fails, dfa_free() attempts to free the same table again. Only publish the table to dfa->tables after any required remapping has completed successfully, so that dfa->tables never contains a pointer to a table that has already been freed. Fixes: 9208c05f9fdf ("apparmor: add support for 2^24 states to the dfa state machine.") Cc: stable@vger.kernel.org Signed-off-by: Li RongQing Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 8c054c71d47d19472d2aa2efbae89d2c85e0b7cf 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 f021ba9c6f5e60560a040a54d22df166106941fb 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 594a389f90686159f4a2198f370b43fcec01fdec Author: Christian Brauner Date: Sat Oct 24 12:38:27 2026 +0200 proc: don't let an entry below /proc//net be a mountpoint [ Upstream commit eeecea75ece2ba894bee4d3c53ed2e40abda8f0e ] proc_net_d_revalidate() always returns 0 so that a dentry below /proc//net is never reused after setns(). So lookup_fast() will end up calling d_invalidate(), which unhashes the dentry and detaches every mount on it, in every mount namespace; including locked mounts. Then lookup_slow() creates a new dentry for the same entry. So a mount on /proc//net/dev succeeds and goes away with the first lookup of the name by anybody with search permission on the directory. Given it's 0555 that's everyone's grandma. A mask on such a name hides nothing as the repro below shows. Treat those entries like I did fd/, fdinfo/ and map_files/ and refuse to mount on them in the first place. It's nonsensical theater otherwise: procnet net/dev stat // SPDX-License-Identifier: GPL-2.0 /* * procnet: cover an entry of /proc// with a bind mount, lock the mount, * then look the name up. * * The first task stays alive, is its pid. The "container" task has its * own mount namespace. There it binds a mask on /proc//. It drops to * uid 1000 and enters a new user namespace with a new mount namespace, so that * the mask is locked. Then one task looks the name up: * * stat the container calls stat() on the name * umount the container calls umount2(MNT_DETACH) on the name * nobody a task with uid 65534 in the first namespaces calls stat() * * The container lists its mounts before and after (that does not look the * name up) and then reads the name. MASK is fine. Anything else means that * the lookup uncovered the entry. * * usage: procnet stat|umount|nobody * name "status" is the control, "net/dev" is a file below net, "net/stat" is * a directory below net */ #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include #include #include #include #define WORK "/run/pn" static char target[128]; static void die(const char *what) { fprintf(stderr, "FATAL %s: %s\n", what, strerror(errno)); exit(2); } static void write_str(const char *path, const char *s, int flags) { int fd = open(path, O_WRONLY | flags, 0644); if (fd < 0 || write(fd, s, strlen(s)) < 0) die(path); close(fd); } /* list the mounts below /proc without a lookup of the target */ static void mounts(const char *when) { char line[512]; FILE *f = fopen("/proc/self/mountinfo", "r"); int n = 0; if (!f) die("mountinfo"); while (fgets(line, sizeof(line), f)) { if (!strstr(line, " /proc/")) continue; printf("container: %s: mount: %s", when, line); n++; } fclose(f); if (!n) printf("container: %s: nothing is mounted below /proc\n", when); } static void show(const char *when, int isdir) { char buf[48] = ""; int fd; if (isdir) { struct dirent *de; DIR *d = opendir(target); int hit = 0; if (!d) { printf("container: %s: opendir(%s) = %s\n", when, target, strerror(errno)); return; } printf("container: %s: readdir(%s) =", when, target); while ((de = readdir(d))) { if (de->d_name[0] == '.') continue; printf(" %s", de->d_name); hit |= strcmp(de->d_name, "MASK"); } closedir(d); printf("%s\n", hit ? " <-- HIT" : ""); return; } fd = open(target, O_RDONLY); if (fd < 0) { printf("container: %s: open(%s) = %s\n", when, target, strerror(errno)); return; } if (read(fd, buf, sizeof(buf) - 1) < 0) die("read"); close(fd); if (strchr(buf, '\n')) *strchr(buf, '\n') = 0; printf("container: %s: read(%s) = \"%s\"%s\n", when, target, buf, strncmp(buf, "MASK", 4) ? " <-- HIT" : ""); } int main(int argc, char **argv) { const char *name = argc > 1 ? argv[1] : "net/dev"; const char *op = argc > 2 ? argv[2] : "stat"; int isdir = !strcmp(name, "net/stat"); int to_host[2], to_cont[2]; struct stat st; pid_t pid; char c; setvbuf(stdout, NULL, _IOLBF, 0); snprintf(target, sizeof(target), "/proc/%d/%s", getpid(), name); if (unshare(CLONE_NEWNS) || mount(NULL, "/", NULL, MS_REC | MS_PRIVATE, NULL)) die("unshare"); mkdir(WORK, 0755); if (mount("W", WORK, "tmpfs", 0, NULL)) die("mount W"); write_str(WORK "/mask", "MASK", O_CREAT); mkdir(WORK "/maskdir", 0755); write_str(WORK "/maskdir/MASK", "MASK", O_CREAT); if (pipe(to_host) || pipe(to_cont)) die("pipe"); pid = fork(); if (pid < 0) die("fork"); if (!pid) { if (unshare(CLONE_NEWNS)) die("container unshare"); if (mount(isdir ? WORK "/maskdir" : WORK "/mask", target, NULL, MS_BIND, NULL)) { printf("container: bind the mask on %s: %s\n", target, strerror(errno)); exit(0); } printf("container: bind the mask on %s: ok\n", target); if (setgid(1000) || setuid(1000) || prctl(PR_SET_DUMPABLE, 1)) die("setuid"); /* lock the mount: a new user namespace with a copy of the tree */ if (unshare(CLONE_NEWUSER | CLONE_NEWNS)) die("container userns"); write_str("/proc/self/setgroups", "deny", 0); write_str("/proc/self/uid_map", "0 1000 1", 0); write_str("/proc/self/gid_map", "0 1000 1", 0); mounts("before"); errno = 0; if (!strcmp(op, "stat")) { stat(target, &st); printf("container: stat(%s): %s\n", target, strerror(errno)); } else if (!strcmp(op, "umount")) { umount2(target, MNT_DETACH); printf("container: umount2(%s, MNT_DETACH): %s\n", target, strerror(errno)); } else if (write(to_host[1], "g", 1) != 1 || read(to_cont[0], &c, 1) != 1) { die("sync"); } mounts("after"); show("after", isdir); exit(0); } close(to_host[1]); if (read(to_host[0], &c, 1) == 1) { pid_t p2 = fork(); if (!p2) { if (setgid(65534) || setuid(65534)) die("setuid"); errno = 0; stat(target, &st); printf("nobody: uid %u: stat(%s): %s\n", getuid(), target, strerror(errno)); exit(0); } waitpid(p2, NULL, 0); if (write(to_cont[1], "g", 1) != 1) die("sync"); } waitpid(pid, NULL, 0); return 0; } Fixes: 1fde6f21d90f ("proc: fix /proc/net/* after setns(2)") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261024-work-procfs-fixes-v1-1-46b03c3a8fac@kernel.org Acked-by: Jan Kara Reviewed-by: Aleksa Sarai Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit bf04f8bdd6f0065afe6997a4a2affeece2090d57 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 24705093eeb28c70f56ea509d9110e802435b1b8 Author: Christian Brauner Date: Mon Oct 26 21:53:29 2026 +0100 userns: don't drop the exec securebits [ Upstream commit bf5ba73c9bdd5e872eb35e801e429a3b526f8f04 ] SECBIT_EXEC_RESTRICT_FILE and SECBIT_EXEC_DENY_INTERACTIVE tell script interpreters to only run what AT_EXECVE_CHECK allows and to refuse interactive input. A service manager sets them together with their lock bits so that nothing below it can turn them off again. But set_cred_user_ns() resets all securebits to SECUREBITS_DEFAULT. So any task that can create a user namespace sheds the locked exec bits with a single unshare(CLONE_NEWUSER) and joining one with setns() does the same. The lock is pointless if anyone who may create a user namespace can drop it, and that is pretty much everyone. Resetting the other bits is fine. They are about how capabilities are computed and a new user namespace starts out with a full set of capabilities anyway. The exec bits grant nothing though. They are restrictions a task placed on itself, just like no_new_privs which a user namespace doesn't touch either. So keep them and their locks. Reproducer: // SPDX-License-Identifier: GPL-2.0 /* Lock the exec securebits, then create a user namespace and look at them again. */ #define _GNU_SOURCE #include #include #include #define SECBIT_EXEC_RESTRICT_FILE (1 << 8) #define SECBIT_EXEC_RESTRICT_FILE_LOCKED (1 << 9) #define SECBIT_EXEC_DENY_INTERACTIVE (1 << 10) #define SECBIT_EXEC_DENY_INTERACTIVE_LOCKED (1 << 11) int main(void) { int bits = SECBIT_EXEC_RESTRICT_FILE | SECBIT_EXEC_RESTRICT_FILE_LOCKED | SECBIT_EXEC_DENY_INTERACTIVE | SECBIT_EXEC_DENY_INTERACTIVE_LOCKED; if (prctl(PR_SET_SECUREBITS, bits, 0, 0, 0)) { perror("PR_SET_SECUREBITS"); return 1; } printf("before: 0x%x\n", prctl(PR_GET_SECUREBITS, 0, 0, 0, 0)); printf("clear locked bits: %s\n", prctl(PR_SET_SECUREBITS, 0, 0, 0, 0) ? "refused" : "ALLOWED"); if (unshare(CLONE_NEWUSER)) { perror("unshare(CLONE_NEWUSER)"); return 1; } printf("after unshare(CLONE_NEWUSER): 0x%x\n", prctl(PR_GET_SECUREBITS, 0, 0, 0, 0)); return 0; } On v7.1 this prints "before: 0xf00", "clear locked bits: refused" and "after unshare(CLONE_NEWUSER): 0x0". With this patch the last line reads 0xf00 as well. Fixes: a0623b2a1d59 ("security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits") Cc: stable@vger.kernel.org # v6.14+ Link: https://patch.msgid.link/20261026-work-securebits-userns-v1-1-b35473fa1a34@kernel.org Reviewed-by: Mickaël Salaün Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 0aba8e759cfcdc6242348dc82b97c96405f90762 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 f8cd83f7b7ea7b72ccf6fc0b30ea8272207f0702 Author: Linmao Li Date: Mon Oct 26 09:23:45 2026 +0800 r8152: Use BMSR to detect the link state [ Upstream commit 85b4bc79dde77aadda0929a22f3532b208a3e1f8 ] r8152 detects carrier from PLA_PHYSTATUS without reading BMSR, so BMSR_LSTATUS can remain latched low after link up. Since commit f6f2e946aa4d ("net: mii: Fix the Speed display when the network cable is not connected"), the first speed query can then report SPEED_UNKNOWN, which applications such as NetworkManager may cache until the next carrier change. Use BMSR_LSTATUS in set_carrier() so a latched link down can turn carrier off after the link has recovered. If BMSR reports down but PLA_PHYSTATUS reports up, reschedule the link work to read the current state without waiting for another notification. Tested on an RTL8153B: NetworkManager reported 1000 Mb/s after 3 of 3 rebinds, instead of an unknown speed. Fixes: f6f2e946aa4d ("net: mii: Fix the Speed display when the network cable is not connected") Cc: stable@vger.kernel.org Suggested-by: Hayes Wang Signed-off-by: Linmao Li Reviewed-by: Hayes Wang Link: https://patch.msgid.link/20261026012345.1902285-1-lilinmao@kylinos.cn Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a20f98ffe158ea5eeb9932a3badbce267cd04917 Author: Georgia Garcia Date: Fri Oct 16 19:08:51 2026 -0300 apparmor: don't revalidate inherited files under files->file_lock [ Upstream commit a913281f600157aa036b7c02afbb18a0ac115187 ] aa_inherit_files() revalidates inherited files on exec using iterate_fd(), which calls the callback with files->file_lock held, so the revalidation is done with IN_ATOMIC. However the unix socket mediation path can sleep: aa_unix_file_perm() drops a ref on the peer's path with path_put(), and unix_fs_perm() -> aa_path_perm() allocates a buffer with aa_get_buffer(false), resulting in BUG: sleeping function called from invalid context at fs/dcache.c:1039 ... dput.part.0+0x24/0x180 path_put+0x2c/0x60 aa_unix_file_perm+0x42a/0x17b0 aa_file_perm+0xcd3/0x1060 match_file+0x10b/0x190 iterate_fd+0xe6/0x280 aa_inherit_files+0x250/0x4f0 Only grab a ref on each file under iterate_fd(), and revalidate it after the lock is dropped, so revalidation is done with no locks held and does not need to be atomic. Denied fds are still replaced with /dev/null, or closed if it can not be opened. Fixes: b1aea2c19607 ("apparmor: fix race in unix socket mediation when peer_path is used") Cc: stable@vger.kernel.org Signed-off-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 084a9234681ed6e2f8828341984d8770fb10ab66 Author: Maxime Bélair Date: Mon Aug 24 17:58:02 2026 +0200 apparmor: fix NULL ctx->peer derefs in unix socket ctx updates [ Upstream commit 4de32fd05ce9e63b492899215ea929e7d306cdab ] aa_unix_file_perm lazily refreshes the AppArmor context cached on a unix socket. Two of the helpers it uses assume ctx->peer has already been set: update_peer_ctx -> l = aa_label_merge(old, label, GFP_ATOMIC); update_sk_ctx -> } else if (aa_label_is_subset(plabel, old)) { where @old is ctx->peer. Neither aa_label_merge nor aa_label_is_subset allows NULL. So both fault on the aa_label->size load. BUG: kernel NULL pointer dereference, address: 000000000000004c RIP: 0010:__aa_label_next_not_in_set+0xb/0xd0 Call Trace: aa_label_is_subset+0x3f/0x70 aa_unix_file_perm+0x5e8/0x9d0 aa_file_perm+0x45a/0x550 apparmor_file_permission+0x44/0xb0 security_file_permission+0x40/0x100 rw_verify_area+0x56/0x180 vfs_write+0x7c/0x480 ksys_write+0xbf/0xf0 ctx->peer is only recorded for stream connections and socket pairs. unix_dgram_connect sets unix_peer(sk) without going through that path, so a connected AF_UNIX datagram socket has unix_peer(sk) set while ctx->peer is still NULL, and the first write that needs revalidation reaches the helpers above. Both derefs date back to the Fixes: commit, but the update_sk_ctx() one was dormant until commit 4483efe4f215 ("apparmor: fix shadowing of plabel that prevents cache from being updated") stopped @plabel being shadowed, which is why bisecting the oops lands there. A NULL @old just means no peer label has been recorded yet, so install the label directly instead of merging or comparing against it. Fixes: 88fec3526e84 ("apparmor: make sure unix socket labeling is correctly updated.") Cc: stable@vger.kernel.org Reported-by: Aurelien Jarno Closes: https://bugs.debian.org/1145111 Tested-by: Fabian Grünbichler Reviewed-by: Georgia Garcia Signed-off-by: Maxime Bélair Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 6ad9711f4fec328a970821ad5cd3a49b1dad9380 Author: Yongjian Wang Date: Mon Oct 26 15:23:09 2026 +0800 Revert "net: advertise TCP MSS from the configured MTU, not the learned PMTU" [ Upstream commit 564313447e545eea13038f74ada9272ab129b3cb ] This reverts commit 2640e6419594 ("net: advertise TCP MSS from the configured MTU, not the learned PMTU"). That commit stopped the learned PMTU from lowering the MSS we advertise in SYN and SYN-ACK. For symmetric paths it argued that "the peer runs its own PMTU discovery and usually already knows the real path MTU". That only holds if ICMP "fragmentation needed" can reach the peer. When the peer sits behind a firewall that drops inbound ICMP, its PMTU discovery is a black hole (RFC 2923, section 2.1), and the smaller MSS we advertised was the only thing keeping its full-size segments off the narrow hop. Inbound ICMP filtering is very common in enterprise and carrier networks, and it is pervasive in mainland China. We hit this in production after the commit was backported to 6.12.111: TCP connections that reach a server through a relay with a smaller-MTU hop complete the handshake, then stall as soon as the client sends full-size segments. Clients on networks that let ICMP through, and connections that bypass the relay, are unaffected, which made it hard to trace back to the kernel. Reproducer, network namespaces on a single host: cli --(1500)-- r1 --(1456)-- r2 --(1500)-- srv r1 drops ICMP frag-needed towards cli. srv has already learned PMTU 1456 towards cli, then cli uploads 1 MB to srv: kernel SYN-ACK MSS 1 MB upload 6.12.107 1416 OK 6.12.111 1460 stalls, times out 7.3-rc7 1460 stalls, times out 7.3-rc7 + this revert 1416 OK The asymmetric case the commit was written for does not need a new default: the advertised MSS can already be set per route with the advmss metric, which takes precedence over default_advmss(). With this revert applied, on an asymmetric path where srv learned PMTU 1456 towards cli while cli->srv is 1500 end to end: srv route to cli SYN-ACK MSS largest cli->srv segment default 1416 1404 advmss 1460 1460 1448 So DSR-style setups can opt in with "ip route ... advmss ", while hosts whose peers cannot complete PMTU discovery keep working by default. Fixes: 2640e6419594 ("net: advertise TCP MSS from the configured MTU, not the learned PMTU") Closes: https://lore.kernel.org/regressions/4F0FAEB6-A13B-47F3-BFF1-C706686C6F64@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Yongjian Wang Reviewed-by: Eric Dumazet Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20261026-advmss-revert-v1-2-272fa4b7ecb6@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4d4bd7bcc14e80ab38d5ea2cf6018afd00660f20 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 74cc51e2f1bf6f2b8b8da4c36c70ca781f9192ee 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 b80b417d864b3f99dbcdfb64c5ba49ccfbfdd139 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 61e7228c532950643d9ccaa2274d30c61a00d376 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 009c3d488595eb52245be30cb7b9de83f7d89f22 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 129119bb1c3dba3c47bc620a831355dbd1451c7b 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 1890437496271781a9d4ab1ba2ba9bbe4cc7c073 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 13ebf8ef96ac6988f56167a2e50ae290d59fc6f6 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 32bfe3eddb18691b482893c730fd71b0996e4aca Author: Seiji Nishikawa Date: Wed Oct 14 15:45:24 2026 +0900 nvme-tcp: fix io_work priority inversion when send_mutex is held [ Upstream commit 5db358f3a7f9c33717622c1597d15c4c91997b19 ] Commit f42d4796ee10 ("nvme-tcp: fix I/O stalls on congested sockets") added a check in nvme_tcp_io_work() that sets pending to true when the queue has pending requests and the socket is writeable. The check is placed after the mutex_trylock() block, so it also runs when mutex_trylock(&queue->send_mutex) failed and io_work did not send anything. When .queue_rq sends a request directly from its own context, it holds send_mutex and can give up the CPU in lock_sock_nested() when another task needs the CPU, for example the io_work kworker of the same queue, which runs on the same CPU. Then io_work cannot take send_mutex, but the requests are still on req_list and the socket is writeable, so pending is set to true. io_work loops until the deadline and queues itself again on io_cpu, without sleeping. This is a priority inversion. io_work runs on the high priority nvme_tcp_wq and cannot make progress until send_mutex is released, but it keeps running. The task holding send_mutex runs at normal priority and needs the CPU to release it. The scheduler keeps giving the CPU to io_work, so the task holding send_mutex may not run again, and the requests on the queue are not sent and time out. This is the same problem that commit 70f437fb4395 ("nvme-tcp: fix io_work priority inversion") fixed. That commit removed "pending = !llist_empty(&queue->req_list)" from the path where mutex_trylock() fails, and let the task holding send_mutex queue io_work again in nvme_tcp_queue_request() after it releases the mutex. The new check brings back the same behavior in a different form. Two things make this easier to hit. nvme_tcp_queue_request() sends directly only when it runs on io_cpu, so the task that takes send_mutex is on the same CPU as the io_work kworker of that queue when it takes the mutex. Also, when the tasks are in a cgroup with the cpu controller enabled, the whole group competes with the nice -20 kworker as one entity, so each task in the group gets even less CPU time. We hit this on a 6 CPU VM running a database on nvme-tcp storage. In the vmcore, 2 tasks held send_mutex of 2 queues and were runnable in lock_sock_nested() for 103 seconds, while the kworkers for those queues kept running io_work on their CPUs. All database tasks were in one cgroup, which got only about 0.3% of the CPU against the nice -20 kworker. Requests timed out, and blk_mq_timeout_work() waited in synchronize_srcu() for the tasks still in .queue_rq. Only do the pending check if io_work could take send_mutex. If it could not, the task holding send_mutex sends what it can in nvme_tcp_send_all(), and queues io_work again after it releases the mutex if requests are still pending, so no request is left behind. Fixes: f42d4796ee10 ("nvme-tcp: fix I/O stalls on congested sockets") Cc: stable@vger.kernel.org # v6.16+ Signed-off-by: Seiji Nishikawa Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 80b1428dbf81f4bb14d66606f61d1e1cb556ce0f 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 5e4325c515dc5719d2dab3520327d1f04c661596 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 d6792894711a19e093681ee874095bf7f4543c6b 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 868a29f30f15e6a75371ccbc64a9d0bdc2be4795 Author: Andrea Parri Date: Thu Oct 22 15:29:33 2026 +0200 nvmet: pci-epf: require SGLs to match the command data length [ Upstream commit 9fb4adbc39751697b9fcf71e45bd5d5119c3f07c ] The PCI endpoint target sends the host every byte a read command's SGL describes, even when the SGL describes more than the command transfers. The excess is kmalloc() memory the command never wrote, so the host receives stale target memory. Any successful read can do this, including Identify. nvmet_pci_epf_alloc_iod_data_buf() allocates each segment at the length of its SGL data descriptor, but sets req->transfer_len from iod->data_len, the length the command implies. Once the command completes, nvmet_pci_epf_transfer_iod_data() sends every segment in full. Nothing compares the descriptor lengths with iod->data_len, and the MDTS check only bounds iod->data_len. Fail the command with Data SGL Length Invalid when the data descriptors do not add up to iod->data_len, before any segment is allocated. The tcp and rdma transports take the data length from the SGL itself, so there most commands already reject a mismatch in nvmet_check_transfer_len(). PRP lists are built from iod->data_len and are unaffected. Found by code inspection. Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver") Cc: stable@vger.kernel.org Tested-by: Niklas Cassel Signed-off-by: Andrea Parri Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 5dc1fa00e67e8ab728a1284b8c889675e6eb8605 Author: Andrea Parri Date: Thu Oct 22 15:29:32 2026 +0200 nvmet: pci-epf: report transport errors in command completions [ Upstream commit 46ed7310a60029826eedb01081a4556643ed5f3b ] When the PCI endpoint target fails a command itself, the host receives a successful completion. This happens for a data length above MDTS, malformed PRPs or SGLs, a buffer allocation failure, an SQ that is not live, and a failed DMA of the command data. A write whose data cannot be fetched from the host is thus reported as written, though nothing was executed. Each of these paths sets iod->status and calls nvmet_pci_epf_complete_iod(), which then reloads iod->status from iod->cqe.status. The nvmet core only fills that field when it completes the request, which these paths never do, so it is still zero and nvmet_pci_epf_cq_work() posts a success status to the host. Drop the reload. Every path already sets iod->status before completion: nvmet_pci_epf_queue_response() copies it from the request's CQE, and the transport error paths set it themselves. Found by code inspection. Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver") Cc: stable@vger.kernel.org Tested-by: Niklas Cassel Signed-off-by: Andrea Parri Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 224aa110632eaccdafa62e106fbeb81420c0d84e 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 36c3af0e94b6c385c4934c028cbca27e138ae1ee 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 63c2733ed1fc1d40a6c42577a3e82e0e1323e945 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 9a048334a7dce061f6c75d3b334b4a4f28db60fc 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 241fed9fa149e538546116e22d88420bac606291 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 61329755f28185322ab4f7640112b1e5c2f505ee 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 2ebe4f0736129014d6fc475215fc5bf0a0549737 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 5e3cdfc8554dfc43b90ca13231e694bd145390d5 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 33e747a4822b77117a17805e0c7df9e0bb03413b 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 3646b7c04717004d0abfc71dd35d25a646c34f45 Author: Kamil Sawicki Date: Fri Oct 23 20:48:35 2026 -0400 net: limit priority VLAN untag depth [ Upstream commit d3ff07f5acc573e5f72bf1c581bae5d05191ba61 ] The priority VLAN receive path can repeatedly remove VID 0 tags and retry packet processing. Unlike the read-only VLAN protocol parser, this path has no limit on the number of nested tags it consumes. Each skb_vlan_untag() advances skb->data and resets header offsets. The offsets are stored in 16-bit fields. With enough nested tags, the network or transport offset can wrap. A later protocol handler can then derive a large pull length from the wrapped offsets and access memory outside the skb allocation. Apply the existing VLAN_MAX_DEPTH limit to the exceptional VID 0 retry. Count the tag already stored in skb VLAN metadata as the first level, then stop before untagging a ninth level. Keep the accounting inside this uncommon branch so the regular VLAN receive path is unaffected. A single VID 0 priority tag before a real VLAN tag is valid. No normal deployment was found that intentionally emits multiple consecutive VID 0 tags; permitting eight levels is therefore conservative. The issue was found while researching the Linux network receive path for Google kvmCTF, with OpenAI Codex (gpt-5.6-sol) assisting the analysis. The affected path, reproducer and fix were manually reviewed and tested. Fixes: 36b2f61a42c2 ("net: handle 802.1P vlan 0 packets properly") Cc: stable@vger.kernel.org Reviewed-by: Willem de Bruijn Signed-off-by: Kamil Sawicki Reviewed-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20261024004835.17862-1-user148783812897@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7f695fb47b4073d6bbd5bb9d5c4f969327641eab 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 7f1ed723c19846fd176243acb68ecdccb22bfa72 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 48f413a3999ac9421f97c2330242dc72f72ae24f 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 08a3f27f91a91fe105012ce8d910540d6a54b37d 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 cfa7fd53ed06c8cce47390a86781316bbb9d1e78 Author: Jesse Zhang Date: Sun Oct 18 19:17:57 2026 +0800 drm/amdgpu: reject CS chunks too large for kvmalloc() [ Upstream commit ba4c3c202919405f461a393e823e4b72c8518494 ] The CS ioctl copies every chunk with vmemdup_array_user() before it looks at it, for whatever length_dw userspace gives. kvmalloc() warns about allocations above INT_MAX when called without __GFP_NOWARN, so any process with the render node can trigger a warning. On navi31, a CS with a chunk of length_dw 0x20000000 returns -ENOMEM after: WARNING: mm/slub.c:6841 at __kvmalloc_node_noprof+0x5a5/0x7d0 Reject such chunks with -EINVAL before trying to copy them. Fixes: 2098105ec65c ("drm: drop drm_[cm]alloc* helpers") Signed-off-by: Jesse Zhang Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit dab5f5280406088591645f499f048dcfefab8d7d) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit ec01397e6c4082f78e1a40e0baff7c8979653dda 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 03bb7b94d6e408bb52c5c25d4fd7bca2c794be3c 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 1916c2f2d1bdb979b4610b5514c0af37fc7ed2bd Author: lvyating Date: Tue Oct 27 19:47:32 2026 +0800 perf machine: Fix NULL deref in thread__resolve_callchain_sample() [ Upstream commit 4626d370ae89b8af4d46a45372b269f926ec662d ] When recording with -j stack, resolve_lbr_callchain_sample() can dereference a NULL 'chain' pointer while resolving the branch stack. $ perf record -j stack -e branches:u uname perf: Segmentation fault Fix it by checking 'chain' for NULL before dereferencing it. Fixes: 29be60c93d2d9300 ("perf build-id: Mark DSO in sample callchains") Reviewed-by: Ian Rogers Reviewed-by: Shengming Hu Signed-off-by: lvyating Tested-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Dai Hualiang Cc: he.yilin@zte.com.cn Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Qingtao Liu Cc: Shen Lin Cc: stable@vger.kernel.org Cc: ye.zhihao1@zte.com.cn Cc: zhang.cheng35@zte.com.cn Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1e70a9c88381bb29fc64acc427afc1e09d0a8b9d 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 f5841241474fa4465d24f88860ace7683fdc6fc7 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 4e4c9733886db991f7aedaa0ff9bd5f26851ae18 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 815c31e67f3feb82926b823469c953af8d3b84f7 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 eef4bbc5174dc79a95b99984c28a0b3fb2a06535 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 18de2985eb99f1de3b54b9edd4374b5dd428ec9f 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 53e0ad94f3da17bbcefafb967ee17d928b040d0d 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 a307ab34e323be8e18cfca948d6fee6a00457ca4 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 45d58b3dcb3d2d4c24046815ccef0a5526723f0a 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 a6a76018c2d666949a7ab357986037349b3433dc Author: Huacai Chen Date: Tue Oct 27 22:51:23 2026 +0800 LoongArch: Call cpu_final_simd() with pure_initcall() [ Upstream commit 9b56c3659a7e5d930ab3c07ea74cc46af65b6d20 ] After commit 35ebc4de105989034f12 ("xor: remove macro abuse for XOR implementation registrations"), using "simd=128" to limit SIMD on a platform with 256bit SIMD instructions causes a boot failure. Because cpu_final_simd() is called with arch_initcall() now, which is after xor_init(), LASX flavors are selected but not workable. Call cpu_final_simd() with pure_initcall() which is before xor_init(). Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 66995f75c5926a0d6cef69b668f3170541b327d9 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 4d816922640628e1df36d740b38478d03d09d81a 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 db13dbefa22eef5d20173766d7e1e71a1f9dc7dc 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 834ca8b916c768411693b62aaeb33f7ce39fe10e Author: Sinan Turunc Date: Mon Oct 26 22:36:39 2026 +0000 ALSA: usb-audio: Bound packet copies by the PCM buffer size [ Upstream commit 06be918062adc1a5a76dc346803b136b20bdb5ae ] retire_capture_urb() and prepare_playback_urb() assume that one USB packet never carries more data than the whole ALSA ring buffer. Nothing enforces that: the packet size comes from the device (wMaxPacketSize, and curpacksize == maxpacksize when the class-specific endpoint descriptor sets MaxPacketsOnly), while the PCM hardware constraints only require 64-byte periods, two periods and a period time of one data interval. An 8 kHz mono U8 stream on a 128-byte buffer is legal, and a full-speed device can send 1023-byte packets into it. On the first oversized packet hwptr_done is wrapped once and stays beyond buffer_bytes (895 for 1023 bytes into 128). On the next packet the wrap arithmetic in the copy path computes bytes1 = subs->buffer_bytes - oldptr with oldptr > buffer_bytes, so bytes1 wraps to about 4 GB and memcpy() runs off the end of the URB buffer and of the vmalloc'd DMA buffer: BUG: KASAN: slab-out-of-bounds in retire_capture_urb+0x251/0x870 Read of size 4294966529 at addr ffff88800c1e2800 by task vhci_rx/82 and for playback, where copy_to_urb() has the same shape: BUG: KASAN: vmalloc-out-of-bounds in copy_to_urb.isra.0+0x188/0x430 Read of size 4294966529 at addr ffffc9000004537f by task vhci_rx/79 prepare_playback_urb+0x98a/0x1fc0 Truncate an oversized capture packet to the buffer size, and stop filling a playback URB once it holds a whole buffer. With bytes <= buffer_bytes the single wrap of hwptr_done and the two-part memcpy() in both copy paths stay inside the buffer. A device whose packets do not fit the buffer at all was never going to play correctly anyway. Reproduced on 7.3-rc7 with a USB/IP device (dummy_hcd cannot carry isochronous data) advertising a UAC1 endpoint with MaxPacketsOnly and wMaxPacketSize 1023, and a PCM client using period_size 64, periods 2. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Sinan Turunc Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20261026223543.620-2-enscrpt@pm.me Signed-off-by: Sasha Levin commit 9e48dbf6841e67c311a4099b768b4e331eae15c4 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 a6814a094d3bf29bb35b1212a718fd9639469d0a 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 a3d1e34ce1284fb9ea2e01e479123d3f285b4612 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 01c9e3038a39a1eb683f0b7e2a9d59398b5d759d 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 0cc5459983d1e158dce54e539f7d5c94777c0ac9 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 b124b5a2d82f894cda2b327f4b9fec28b7a590a3 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 1179a864db9dff2258d72deee2348d967cfd6f29 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 9189524229c35f8aca0584c7cb758d4406e0e1de Author: Srinivas Kandagatla Date: Fri Oct 23 18:13:12 2026 +0100 ASoC: codecs: wsa883x: Accept temperatures across the full trim range [ Upstream commit 6a55cf0d9dd2e2493a5030a4f7b0413d31165e45 ] wsa883x_get_temp() rejects any reading outside 5..45 degC with -EAGAIN, so a speaker that has been playing, or sits in a warm chassis, becomes unreadable above 45 degC. Bound the check by the -10..150 degC two-point trim range instead, and use inclusive comparisons, as in_range() excludes the upper bound. Fixes: a02c42d41af7 ("ASoC: codecs: wsa883x: Implement temperature reading and hwmon") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20261023171316.819857-4-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e4ab85f273f41aa7dbfc2a876f2c42275c9ba783 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 a55460a33402c09a8733d5ddbcb6db9865de50be 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 2431c46f95a353ecea7a3db2da54164f2e654505 Author: Chao Yu Date: Mon Oct 26 08:23:50 2026 +0800 f2fs: fix to update superblock crc in sanity_check_area_boundary() [ Upstream commit f8f956c7ec8c0285d7a80bed497d2f7adcbded15 ] This patch fixes the bug reported by Sashiko: We should update superblock crc along w/ raw_super->segment_count in sanity_check_area_boundary() if sb_checksum feature is enabled. Cc: stable@kernel.org Fixes: d440c52d3151 ("f2fs: support superblock checksum") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit c94e08ae4ad38ef847e273d9d989b106a083dd2e 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 6f8082c1fb88f478826d355ec3cefc6ff09da6e1 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 fa6e5325278c620391ee6b75abc731532d66e57f 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 ff6e8ae28b522586507f7de81230b471a4d9c633 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 512b5cf725d576aba222d976f9cb9a197d3316ab 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 32da9f494080b609a1979d6ae21e0bd1bdd30591 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 5f4eda68e31881d82d017a1bd51d774fd342f23b 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 e1cf4b41bfbe86f06f272e4c9e87e383d62014fa 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 813221c8bbc9ce0c22b8a190478f6718d9c69a31 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 410855d5e5b63e6a9b5225f0680b68336de90ab2 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 112f3dba7af4da07c95151e6236213ba7c6b00c9 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 f0dbd6b9b05e919ebab668f3479aebbcd2431fce 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 de314d21f7adb39bd2de38c2f7145375201ca180 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 23e0bbd385b17c30ad5aa03f6b7663c6341f019d 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 ab62a3677aadb0bd46f37330cbf44202cff3a59b 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 7f4f3e6fe58c25ac5b6977b089634bd5c48a66a4 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 046d542cd77b36395f6f9fd63e8de0e69612a34d 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 5ab17ed54e8b7ca64a8d167a09d6a2c865ed51cc 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 e9d72cf5d1bf5b4ddfe86707ada614973d75bf64 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 acaec29310a634f15007cb25c4ee5c87552c6204 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 5c4d3a1f50545607a841be707e144f49ede855a1 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 2da8a5e6c0abb3388f8f1a959d4a986b039b6c45 Author: Fuad Tabba Date: Fri Oct 16 09:15:58 2026 +0100 KVM: arm64: Set HCR_EL2.BSU to Inner Shareable for guests [ Upstream commit 00e73757518020273ccf6308a51f214e58c21ad5 ] KVM sets HCR_EL2.BSU to Inner Shareable for guests, so that a guest's barriers cover the TLB and I-cache invalidations that HCR_EL2.FB broadcasts. However, since HCR_BSU_IS became an alias of the generated HCR_EL2_BSU_IS, it is the unshifted field value 0b01, which sets bit 0 (VM, already set) and leaves BSU at 0b00. A guest's DSB NSH is then not required to wait for a broadcast TLBI to complete on other CPUs. Build the field with SYS_FIELD_PREP_ENUM(). Fixes: d0f39259eff4 ("arm64: sysreg: Add layout for HCR_EL2") Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20261016081558.805411-1-fuad.tabba@linux.dev Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 4c4c4a69cc2dc9237acd25caacee5552206ce0ab 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 035b7372117f174b5b3a10378b77a5380fcd54e1 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 fa12106f992805d7bb4938ad88669bd18a7709ca 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 e87cd6f7507f682f0f32ef83917b6729738bce7c 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 482a6e8ab6ae8f719a204966688daecdbcd6ff70 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 cb24274f7d304d992e940be51234a3d9cfc179b5 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 41a885c81a18d41613b78888d9aa1e95393473f7 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 a402a7a7dea719dd48bd9da81463195835255e3a Author: Gregory Price (Meta) Date: Mon Oct 19 14:50:02 2026 -0400 mm/vmscan: reclaim every zone in per-node proactive reclaim [ Upstream commit d0a12d80d2f7e9f4ed2030b6f04c8a897956bf84 ] user_proactive_reclaim() limits per-node reclaim to gfp_zone(GFP_KERNEL), which is ZONE_NORMAL. Proactive reclaim serves no allocation, but that limit makes shrink_node() skip every ZONE_MOVABLE folio, so writing to /sys/devices/system/node/nodeN/reclaim never reclaims a node's movable memory. A movable-only node, such as dax/kmem or hotplugged memory onlined movable, reclaims nothing and fails with -EAGAIN. To reproduce, fill a movable-only node with clean page cache and write 200M to its nodeN/reclaim: the write fails with -EAGAIN and the page cache stays. The same write to a ZONE_NORMAL node frees 200MB. Scan every zone, as memory.reclaim does. Link: https://lore.kernel.org/20261019185002.3428594-1-gourry@gourry.net Fixes: b980077899ea ("mm: introduce per-node proactive reclaim interface") Signed-off-by: Gregory Price (Meta) Signed-off-by: Andrew Morton Reviewed-by: Barry Song Reviewed-by: Johannes Weiner Reviewed-by: Harry Yoo (Meta) Acked-by: Shakeel Butt Reviewed-by: Yosry Ahmed Reviewed-by: SJ Park Reviewed-by: Balbir Singh Acked-by: Davidlohr Bueso Acked-by: Michal Hocko Reviewed-by: Xueyuan Chen Acked-by: Lorenzo Stoakes (ARM) Acked-by: Vishal Moola (Fractile) Cc: Kairui Song Cc: Qi Zheng Cc: Axel Rasmussen Cc: Yuanchu Xie Cc: Wei Xu Cc: Baoquan He Cc: Baolin Wang Cc: David Hildenbrand Cc: Michal Hocko Cc: Roman Gushchin Cc: Signed-off-by: Sasha Levin commit e251079d676c481cc905d1ac226851b1ef49a4b8 Author: Lorenzo Stoakes (ARM) Date: Mon Oct 19 16:57:48 2026 +0100 mm/mremap: correctly uncharge accountable VMAs in error path [ Upstream commit 65e722a74df992719676ead85a9e93fb2b5a0983 ] The mremap error path is a fragile and unwieldy beast - it reverses the page table move then updates vma_remap_struct state to swap VMA, length and address between old and new VMAs in copy_vma_and_data(). If the mremap() operation didn't specify MREMAP_DONTUNMAP then its caller, move_vma(), invokes unmap_source_vma(), which unmaps the new VMA rather than the old one. For accountable VMAs when MREMAP_DONTUNMAP is not specified, unmap_source_vma() unsets VMA_ACCOUNT_BIT during this unmap in order that only the delta of a VMA expansion is charged (performed by vrm_calc_charge() earlier). Therefore nothing uncharges the expanded VMA size, and there is a permanent leak in global Committed_AS. Resolve the issue by uncharging when MREMAP_DONTUNMAP is not specified. Link: https://lore.kernel.org/20261019-other-mremap-charge-leak-v1-1-d94477fe6545@kernel.org Fixes: fdbef6149135 ("mm/mremap: don't account pages in vma_to_resize()") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Brian Geffon Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Signed-off-by: Sasha Levin commit 38efa986446b83eaefde90558bc0ee7dbe903782 Author: Lorenzo Stoakes (ARM) Date: Mon Oct 19 15:28:27 2026 +0100 mm/mremap: populate calculated fields in vrm state correctly [ Upstream commit 34e753f8d927069785f6b675f5769da5da4ef78e ] Commit d5c8aec0542e ("mm/mremap: initial refactor of move_vma()") introduced the vma_remap_struct helper to pass state sanely through mremap() logic. Part of this state is vrm->delta - equal to the absolute difference between vrm->old_len and vrm->new_len (the old and new lengths of the VMA, respectively). This value is used to correctly charge accounted VMAs. When shrinking a VMA, mremap_to() sets vrm->old_len equal to vrm->new_len having performed the shrink of the VMA first, prior to any potential move (e.g. MREMAP_FIXED | MREMAP_MAYMOVE specified). However it does not recalculate vrm->delta, which results in incorrectly overcharging the VMA when both moving and shrinking a VMA. The charge leaks to Committed_AS globally, meaning a mischievous user can cause allocations to fail across the system in strict overcommit mode. Resolve the issue by abstracting the update of vrm->delta to vrm_populate_calculated() and invoking this from mremap_to() when vrm->old_len is changed. Additionally, update vrm->remap_type whose value depends on vrm->delta. The field is not read again after the shrink, but it is the logically correct thing to do and protects against future changes which break this. Link: https://lore.kernel.org/20261019-mremap-fix-shrink-charge-v1-1-a3ce209e5360@kernel.org Fixes: d5c8aec0542e ("mm/mremap: initial refactor of move_vma()") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Reported-by: Nickolai Zeldovich Closes: https://lore.kernel.org/all/20261017233527.797191-1-nickolai@csail.mit.edu/ Reviewed-by: Xueyuan Chen Reviewed-by: Pedro Falcato Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Signed-off-by: Sasha Levin commit 5b040ba4b592f9ccbc7d072767e1be8c545c9f24 Author: Nickolai Zeldovich Date: Fri Oct 16 18:27:21 2026 -0400 mm/truncate: fix the zeroing end of pagecache_isize_extended() [ Upstream commit 8f9039840588dd618c72a726c192126bb7b98228 ] A process that extends a file by 4 GiB or more past a dirty folio, on a file system whose block size is smaller than the page size (ext4 with 1k blocks), reads back the bytes it wrote through a shared mapping beyond the old end of file instead of zeroes, and a later write into that block carries them to the disk. With the example of commit 52aecaee1c26 ("mm: zero range of eof folio exposed by inode size extension") and the truncate taken 4 GiB further (pwrite 2k at 0, mmap the first page and write 'X' over [2k, 4k), truncate(2) to 4 GiB + 2k), the read of [2k, 4k) returns the 2048 'X' bytes, and a pwrite of 16 bytes at 3k followed by fsync() and a remount leaves 1008 'X' bytes on the disk in [3k+16, 4k). No privilege is needed, and every size extension of 4 GiB or more reaches it: truncate(2)/ftruncate(2) through truncate_setsize(), writes beyond the end of file through generic_write_end(), ext4, iomap, btrfs, exfat, ntfs, afs and orangefs. Affected since v6.13. pagecache_isize_extended() zeroes the part of the dirty folio straddling the old end of file that the size extension exposes, from the old size to the new size or the end of the folio, whichever comes first: end = min_t(unsigned int, to - folio_pos(folio), folio_size(folio)); min_t() converts both operands to unsigned int before comparing, so the loff_t difference to - folio_pos(folio) is reduced modulo 2^32 first. When the file grows by 4 GiB or more past the folio, end is that residue instead of folio_size(folio): below offset nothing is zeroed, above it only [offset, end) is. The bytes beyond the old end of file stay in the dirty folio and, now inside i_size, are file data. Compare in loff_t; the result is at most folio_size(folio) and fits end. Found while formally verifying pagecache_isize_extended() against the kernel binary. Link: https://lore.kernel.org/20261016222721.791785-1-nickolai@csail.mit.edu Fixes: 52aecaee1c26 ("mm: zero range of eof folio exposed by inode size extension") Signed-off-by: Nickolai Zeldovich Signed-off-by: Andrew Morton Reviewed-by: Jan Kara Reviewed-by: Baokun Li Assisted-by: LLM Cc: Matthew Wilcox (Oracle) Cc: Brian Foster Cc: Theodore Ts'o Cc: Signed-off-by: Sasha Levin commit abdf941e56626dc9a04f3fde86fe8c79ce8c3776 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 98e52d6946a95a28cc59605d97de364bdcd7691f Author: Jiayuan Chen Date: Thu Oct 15 14:05:27 2026 +0800 mm/swap: fix swap_cache_get_folio() returning a folio that left the swap cache [ Upstream commit 60f34fedf3a4c91ed631ed2f80713ab993cde5ee ] swap_cache_get_folio() reads the folio from the swap table and takes a reference with folio_try_get(), without any lock. If the folio is removed from the swap cache and freed in between, and its memory gets reused, folio_try_get() still succeeds and we return a page that has nothing to do with the swap entry: CPU 0 CPU 1 do_swap_page() swap_cache_get_folio() swp_tb = swap_table_get() folio = swp_tb_to_folio(swp_tb) madvise(MADV_DONTNEED) zap_nonpresent_ptes() swap_put_entries_direct() swap_put_entries_cluster() __try_to_reclaim_swap() swap_cache_del_folio() folio_put() <- freed page reused, e.g. as an anon folio of another task folio_try_get(folio) <- succeeds return folio swap_update_readahead() <- may clear PG_readahead on it folio_lock_or_retry() <- locks it folio_matches_swap_entry() fails, unlock and put filemap_get_entry() does the same lockless lookup for the page cache, and after folio_try_get() it rechecks the xarray, because the folio may have been freed and reused in between. swap_cache_get_folio() lost that recheck when the swap cache moved to the swap table. So CPU 0 writes to a folio it doesn't own: it may clear PG_readahead and takes the folio lock of someone else's page, before folio_matches_swap_entry() finds out the folio is not ours. When the race occurs, a swap fault can acquire a reference to a physical page that has been freed and reused for an unrelated purpose, potentially by another process. The fault handler may then clear that page's PG_readahead/PG_reclaim flag, wait on or acquire its folio lock, and potentially attempt to remove it from an unrelated swap cache. These operations can interfere with unrelated workloads and may cause unexpected stalls and impaired reclaim. The subsequent swap-entry validation normally prevents the wrong folio from being mapped into the faulting process. It's documented that caller always double checks the folio so this part is harmless from the aspect of data corruption or crash. Recheck the slot after folio_try_get() and retry if it no longer holds this folio. [akpm@linux-foundation.org: add LLM-generated description of userspace impact] Link: https://lore.kernel.org/20261015060528.302634-1-jiayuan.chen@linux.dev Fixes: 8578e0c00dcf ("mm, swap: use the swap table for the swap cache and switch API") Signed-off-by: Jiayuan Chen Signed-off-by: Andrew Morton Reviewed-by: Kairui Song Cc: Chris Li Cc: Kemeng Shi Cc: Nhat Pham Cc: Baoquan He Cc: Barry Song Cc: Youngjun Park Cc: Signed-off-by: Sasha Levin commit f48ad207e5b617d990382053cfabe8414eb79f77 Author: Vernon Yang Date: Mon Oct 12 10:29:17 2026 +0800 mm: vmscan: don't count per-node proactive reclaim as memory pressure [ Upstream commit 2ca8b38962f239b17f7881a4710c11328ce38ac9 ] When the cgroup has no memory pressure at all, writing to /sys/devices/system/nodeX/reclaim triggers proactive reclaim on NUMA node, causing increase in the writer cgroup's memory PSI. Due to this reclaim is performed in the context of the write(), accounted as memory pressure on the writer, like commit e22c6ed90aa9 ("mm: memcontrol: don't count limit-setting reclaim as memory pressure"). This is unexpected, the similar scenarios (e.g. senpai) will continue to occur, only this time it is for the /sys/devices/system/nodeX/reclaim knob. The Documentation/ABI/stable/sysfs-devices-node documentation also notes that "This interface is equivalent to the memcg variant." This patch unifies the semantics of the memcg and node interfaces: per-node proactive reclaim is no longer counted as memory pressure, and the per-node proactive reclaim interface no longer produces phantom pressure. I ran demo[1] that performs per-node proactive reclaim 10000 times in qemu, writer cgroup memory.pressure as follows: without patch: some avg10=31.53 avg60=13.42 avg300=3.31 total=10602985 full avg10=31.53 avg60=13.42 avg300=3.31 total=10602985 with patch: some avg10=9.59 avg60=3.41 avg300=0.81 total=2686221 full avg10=9.59 avg60=3.41 avg300=0.81 total=2686221 Link: https://lore.kernel.org/20261012022917.1102467-1-vernon2gm@gmail.com Link: https://github.com/vernon2gh/app_and_module/tree/main/reclaim_node_psi [1] Fixes: b980077899ea ("mm: introduce per-node proactive reclaim interface") Signed-off-by: Vernon Yang Signed-off-by: Andrew Morton Reviewed-by: Baolin Wang Reviewed-by: Barry Song Reviewed-by: Ridong Chen Acked-by: Davidlohr Bueso Cc: David Hildenbrand Cc: Kairui Song Cc: Qi Zheng Cc: Shakeel Butt Cc: Axel Rasmussen Cc: Yuanchu Xie Cc: Wei Xu Cc: Baoquan He Cc: Johannes Weiner Cc: Michal Hocko Cc: Lorenzo Stoakes Cc: Roman Gushchin Cc: Signed-off-by: Sasha Levin commit 1900cb4401985376b3bf98dd54b97fa42688cf58 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 be6be6707c2953dc4ee979e7e4605fe436d87429 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 695d0c95c13f678acddc6912f6b711a29cbcbf3b 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 87f6bb4b82ac4334ff4b5ff0becff9690fe39911 Author: Cen Zhang (Microsoft) Date: Mon Oct 12 16:15:14 2026 -0400 userfaultfd: fix UFFDIO_MOVE livelock on large folio with extra references [ Upstream commit 454143aeb4c6c85ca7d50df36d1a66a64d88283e ] To move one page out of a large folio, move_pages_ptes() first has to split the folio. __folio_split() refuses if the folio has any reference beyond its page table mappings and the caller's own, and it reports the refusal as -EAGAIN. move_pages() treats returned -EAGAIN as a transient race and keeps retrying the same address, holding the VMA read locks the whole time. This is incorrect since in some cases userspace can hold such a reference indefinitely, such as by registering the page as an io_uring buffer. An unprivileged user can trigger this with three threads: first holds such a reference on a page of a THP, second calls UFFDIO_MOVE on another page of the same THP and spins in the kernel forever holding the VMA read locks, and third calls fork() or mprotect(), which takes mmap_lock for writing and then waits forever for those read locks. From then on every mmap_lock user of that mm hangs, including other processes inspecting it through /proc//, until the process is SIGKILLed. The hung task detector reports the blocked tasks (third one), and with kernel.hung_task_panic=1 the machine panics: INFO: task wedge:95 blocked for more than 122 seconds. task:wedge state:D stack:12528 pid:95 tgid:95 ppid:94 Call Trace: __schedule+0x596/0x1110 schedule+0x36/0xf0 __vma_start_exclude_readers+0x100/0x170 __vma_start_write+0x51/0xd0 __split_vma+0x208/0x3d0 vma_modify+0x6a8/0x840 vma_modify_flags+0xce/0x110 mprotect_fixup+0xbe/0x480 do_mprotect_pkey+0x2d9/0x580 __x64_sys_mprotect+0x1a/0x30 Fix by returning -EBUSY instead of -EAGAIN in move_pages_ptes(), the caller of split_folio(), when the split fails. Thus, move_pages() does not retry -EBUSY and the ioctl drops its locks and returns to userspace instead of spinning. Link: https://lore.kernel.org/20261012201514.97015-1-cenzhang@linux.microsoft.com Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Signed-off-by: Cen Zhang (Microsoft) Signed-off-by: Andrew Morton Reported-by: Acked-by: David Hildenbrand (Arm) Assisted-by: LLM Cc: Mike Rapoport Cc: Peter Xu Cc: Suren Baghdasaryan Cc: Andrea Arcangeli Cc: Cc: Signed-off-by: Sasha Levin commit fe6e1017449126be6ae477483945c31ea1b0a03e 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 6dddcb5b8bf84da259ab32cc372d0465537097d0 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 e9d4d0f7d9ca54980fa989280ea75cbed3190c99 Author: David Hildenbrand (Arm) Date: Tue Oct 13 13:41:24 2026 +0200 mm: disallow ioremap'ing ordinary RAM in generic_access_phys() [ Upstream commit 4590752e20aa393cc0d4fe538c0747d14a98c97a ] generic_access_phys() can end up getting called on CoW PFNMAP mappings, resulting in it trying to ioremap anonymous folios, which especially the x86 code doesn't enjoy, and which is in general just odd/wrong. E.g., with a CoW mapping of a PCI BAR: ioremap on RAM at 0x0000000045623000 - 0x0000000045623fff WARNING: arch/x86/mm/ioremap.c:216 at __ioremap_caller.isra.0+0x4c2/0x5f0 Call Trace: generic_access_phys+0x130/0x4d0 mm/memory.c:7178 kernfs_vma_access+0x1ce/0x280 fs/kernfs/file.c:437 __access_remote_vm+0x58f/0x890 mm/memory.c:7256 mem_rw+0x2a1/0x670 fs/proc/base.c:912 But more generically, we should disallow access to anything that looks like ordinary RAM in the system: including allocating memory (e.g., alloc_pages) and mapping them in a VM_PFNMAP. For pages with an online memmap, allow only pages marked as reserved (PageReserved). This also includes memblock allocations, however, distinguishing them from other MMIO is tricky, and nobody should really be mapping them in a PFNMAP (except someone abusing /dev/mem, which we do not care about). So only allow access if there is no online memmap, or if the pages are marked reserved. Reject other pages with -EINVAL. Note that, just like other pfn_to_online_page() users, we won't care about concurrent memory offlining; mapping memory that can concurrently get offlined is highly dubious. Link: https://lore.kernel.org/20261013-generic_access_phys-v1-1-b3963ef76e37@kernel.org Fixes: 28b2ee20c7cb ("access_process_vm device memory infrastructure") Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Reported-by: Closes: https://syzkaller.appspot.com/bug?extid=49b1021becba70c1f3f6 Reported-by: Nguyen Ngoc Thang Closes: https://lore.kernel.org/r/20261001152524.171115-1-ngocthang2710.1999@gmail.com/ Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: Mike Rapoport (Microsoft) Tested-by: Lance Yang Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Benjamin Herrenschmidt Cc: Peter Zijlstra Cc: Rik van Riel Cc: Signed-off-by: Sasha Levin commit 7ea08a7ca9e1612b6615487c1e536a98b01f6f56 Author: Hongfu Li Date: Wed Sep 23 10:05:15 2026 +0800 mm/hugetlb: account migration target folio in per-node NR_HUGETLB vmstat [ Upstream commit 92635a3ffe8bb48304f50625dd591a27d7505698 ] Patch series "mm: fix hugetlb NR_HUGETLB accounting on folio migration", v2. The hugeTLB counters added by 05d4532b60e3 ("memcg/hugetlb: add hugeTLB counters to memcg") are maintained in two per-node places: - the per-node vmstat counter NR_HUGETLB, exposed as nr_hugetlb in /proc/vmstat; - the per-node memcg lruvec stat, exposed via memory.numa_stat. Both are accounted against the folio's node, and both drift when a hugetlb folio is migrated, though in different ways. A migration target folio is allocated by alloc_hugetlb_folio_nodemask() and inherits the old folio's state without ever being accounted, while the old folio is freed right after and its free is accounted. That alone loses vmstat accounting: the target node has no matching increment for the decrement on the old node, so /proc/vmstat's nr_hugetlb shrinks by nr_pages per migration. Patch 1 accounts the folio where it is obtained, so the increment pairs with the free in free_huge_folio() on the successful as well as the failed migration path. The memfd page cache preallocation helper has the same asymmetry and is fixed in the same patch. The per-node lruvec stat breaks differently. mem_cgroup_migrate() moves the charge to the new folio and drops the old folio's memcg data, so the old folio's free right after migration skips the memcg per-node decrement; the count stays attributed to the old node for the rest of the charge's life, and the target folio never gets an increment on its new node. Patch 2 moves that per-node accounting along with the charge, in move_hugetlb_state(). This patch (of 2): The NR_HUGETLB vmstat counter is maintained per folio's node: incremented when a huge page is handed to a user via hugetlb_alloc_folio() and decremented when it is returned to the pool via free_huge_folio(). A folio obtained by alloc_hugetlb_folio_nodemask() never goes through hugetlb_alloc_folio(), so it is never accounted, while its free always is. For a migration target this means the target node gets no matching increment for the decrement on the old node, so the global nr_hugetlb in /proc/vmstat drops by nr_pages for each migration. The same asymmetry affects the failed migration path, which frees the target again right away, and the temporary folio hugetlb_mfill_atomic_pte() takes from the same helper. alloc_hugetlb_folio_reserve(), used to preallocate the memfd page cache folios, has the same asymmetry: the folio is handed to a user without being accounted, while its free is accounted through free_huge_folio(). Account the folio where it is obtained, in alloc_hugetlb_folio_nodemask() and alloc_hugetlb_folio_reserve(), so that the increment pairs with the decrement in free_huge_folio(): a successful migration hands the folio to a user, a failed one frees it again. Link: https://lore.kernel.org/20260923-for-hugetlb_state3-v2-0-e8a36245bfab@kylinos.cn Link: https://lore.kernel.org/20260923-for-hugetlb_state3-v2-1-e8a36245bfab@kylinos.cn Fixes: 05d4532b60e3 ("memcg/hugetlb: add hugeTLB counters to memcg") Signed-off-by: Hongfu Li Signed-off-by: Andrew Morton Tested-by: Joshua Hahn Reviewed-by: Joshua Hahn Acked-by: Muchun Song Acked-by: Oscar Salvador Cc: David Hildenbrand Cc: Shakeel Butt Cc: Michal Hocko Cc: Johannes Weiner Cc: Nhat Pham Cc: Michal Hocko Cc: Roman Gushchin Cc: Chris Down Cc: Signed-off-by: Sasha Levin commit fb307eadea56944075197c1d34905b458cf561f1 Author: David Hildenbrand (Arm) Date: Thu Oct 15 18:07:16 2026 +0200 mm/mremap: fix calling fixup_hugetlb_reservations() on the wrong VMA [ Upstream commit cc078ca0b5b79b4a9e514b7f1b489f2afc83b195 ] In case we fail to move the page tables, for example, because we fail to allocate a page table, we actually keep the old VMA. Calling fixup_hugetlb_reservations() on the old VMA is wrong. Fix it by just calling it on the VMA that will be removed. The user-visible impact is that the VMA loses its reservations, meaning that the existing reservations get stranded (leaked) and new hugetlb folios that are getting allocated in the VMA cannot make use of the reservations, failing these allocations. Link: https://lore.kernel.org/20261015-urgent_fixes-v1-10-42796911043b@kernel.org Fixes: b714ccb02a76 ("mm/mremap: complete refactor of move_vma()") 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: Josef Bacik Cc: Signed-off-by: Sasha Levin commit 1b6f6cf3a78dffe7588155884edd9f3ea06ac8ea Author: Josef Bacik Date: Thu Oct 15 18:07:11 2026 +0200 mm/hugetlb: don't clear the resv_map of a VMA whose lock is held [ Upstream commit d42032c0fe3ca007986c1229128775af0340fbec ] Since commit bf4916922c60 ("hugetlbfs: extend hugetlb_vma_lock to private VMAs") the lock of a private hugetlb VMA that owns a reservation is the rw_sema of its resv_map. The hugetlb_vma_*lock*() helpers find it through vma->vm_private_data, anew for every lock and every unlock. At the end of mremap() the old VMA has to let go of the resv_map, which now belongs to the new VMA: clear_vma_resv_huge_pages() stores NULL into vm_private_data. mremap() holds mmap_lock for writing and has write locked the VMA, which keeps away everybody who comes through the mm. It does not keep away those who find the VMA through the file. For hole punch and truncation hugetlb_vmdelete_list() does hugetlb_vma_trylock_write(vma); locks resv_map->rw_sema unmap_hugepage_range(vma, ...); vm_private_data = NULL hugetlb_vma_unlock_write(vma); no resv_map: does nothing and the rw_sema stays write locked for ever: WARNING: lock held when returning to user space! mremap_punch/116 is leaving the kernel with locks still held! locks held by mremap_punch/116: 1, last CPU#1: #0: (&resv_map->rw_sema){+.+.}-{4:4}, at: hugetlb_vmdelete_list+0x46/0x160 The next fault in the new VMA sleeps in hugetlb_vma_lock_read(), uninterruptibly, and it holds its entry of hugetlb_fault_mutex_table[]. That table is global, so a fault of any other process on a page that hashes to the same entry sleeps uninterruptibly as well. All those who take the lock of a private VMA without taking the mmap/vma lock are affected: rmap walks. So hold i_mmap_rwsem around the clearing of the resv_map. No change of behaviour, other than that mremap() of a hugetlb VMA takes i_mmap_rwsem once more. Original fix generated by an LLM and sent in private by Josef. [david: avoid local variable, move and refine comment, description cleanups+simplifications] Link: https://lore.kernel.org/20261015-urgent_fixes-v1-5-42796911043b@kernel.org Fixes: bf4916922c60 ("hugetlbfs: extend hugetlb_vma_lock to private VMAs") Signed-off-by: Josef Bacik Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Reported-by: Chris Mason 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 fa5ee143d0e6fa86c7173d4e6389f2b4bbd075a5 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 03ea1f756ecf84d05f923940583ea20691c825f5 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 4dd4043fcfa06d27c2ed22cc51c8a1b2e0e632bc Author: Caleb Kan Date: Thu Oct 22 09:33:30 2026 +0100 stackdepot: stop preallocating after the final pool [ Upstream commit 8f56ea8e0706d92774603260779c7032f03ef3ac ] depot_init_pool() decides whether another pool is needed before it increments pools_num. When it registers the last allowed pool, pools_num is still one below stack_max_pools, so the existing comparison clears new_pool. With new_pool cleared, stack_depot_save_flags() can allocate another order-2 pool after a lookup miss. depot_keep_new_pool() retains its pointer in the global new_pool, so the allocation is not lost. However, pools_num has already reached stack_max_pools, and depot_init_pool() rejects every attempt to register the pool. It remains allocated and unusable until reboot. The non-NULL pointer prevents later saves from allocating more spare pools. Account for the pool being registered in the limit check so registering the final pool installs STACK_DEPOT_POISON and prevents the extra allocation. Link: https://lore.kernel.org/20261022083330.3159793-1-matt@readmodwrite.com Fixes: 31639fd6cebd ("stackdepot: use variable size records for non-evictable entries") Signed-off-by: Caleb Kan Signed-off-by: Matt Fleming Signed-off-by: Andrew Morton Reviewed-by: Marco Elver Cc: Andrey Konovalov Cc: Mikhail Gavrilov Cc: Caleb Kan Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: Vlastimil Babka Cc: Signed-off-by: Sasha Levin commit e93fbad317c8c8501697c7bbbebc285999f340e1 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 5e208e3883fd79e841bd98d99ae9f3cfef5ad191 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 3c9620afa60869f5e637ec047a04ba71f1557512 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 e89d8e7c00ec52c207950a4f80c77e82565de9fe 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 657a3f18227d375fe34c565f511a268c63f20784 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 a3e6b9d63f4545f2e2c6522eb7b180a607420ef7 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 6252388f4ee900826173c2a71d9071b7a2b699f9 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 9a62816f8891b0804c5e36538377b1a618a0bcab 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 57492dac0edfdc29d0c6a5b931456f2a5545e964 Author: Igor Velkov Date: Thu Oct 15 21:51:50 2026 +0300 genirq/kexec: Do not take the bus lock of an interrupt chip on the crash path [ Upstream commit 717862eac6eff0eea8ac30a0c0de0bed84922aab ] machine_kexec_mask_interrupts() calls irq_set_irqchip_state() for every started interrupt. That function takes the bus lock of the chip and desc->lock, and syncs the chip when it drops them. On the crash path interrupts are off and the other CPUs are stopped, so a chip whose bus transfer is completed by an interrupt never returns from the sync. On RK3399 boards with an RK808 PMIC the RTC alarm interrupt belongs to the regmap-irq chip of the RK808, which sits on I2C. rk808_irq_chip sets init_ack_masked, so regmap_irq_sync_unlock() writes the ack register on every unlock, and the I2C controller needs its own interrupt to finish the transfer. A panic with a crash kernel loaded prints SMP: stopping secondary CPUs and then nothing until the watchdog resets the board. machine_kexec_mask_interrupts() takes neither lock for the other operations on the descriptor. Move the search for the chip that implements irq_set_irqchip_state() into __irq_set_irqchip_state(), which takes no locks, and call it from machine_kexec_mask_interrupts(). Fixes: 78fd584cdec0 ("arm64: kdump: implement machine_crash_shutdown()") Suggested-by: Thomas Gleixner Signed-off-by: Igor Velkov Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261015-kexec-irq-bus-lock-v2-1-2af15f0757b6@iav.lv Signed-off-by: Sasha Levin commit ca59f6aa7c29c5248ea996d4a5e2fa7964ae74e8 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 5244ac2547e5d1310d233f490e193024803422ef 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 5ba40b5a2d6220666f9263e92ef38e43029ac6b8 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 a1028ed2d71d28395c58af1ab73abd0e42cc9909 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 2e98c0261fc6b500db9d7f09b32b023b0f03c4cb 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 20661adcee8783ba73fa6405842042dd161915c0 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 0a71f66c8f3ee1f1592268d75766489e96c37525 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 d9c558a9a047c6d768b7c915bdc978631c836f84 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 930132f707c7ea67bc9cb8099ef784195cb6ca8c 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 532570df1ea04da4b2463477abf92b739a072ad0 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 160acc23dea8d3b5acae35e1effb32788a9aebd1 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 5ce06b8a03a7d8400408b953d7312dbc5219bb51 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 25a82a59738578a2ad4175b604e59a63ba8e6d32 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 2fec4e4547ee28e5ebe54c34d67b4afcaf3fc0a7 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 55441fd25257971833e914ccd7337b2f2118534f 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 4429d405124e6199092f029afd5630c84019d6f9 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 848ca02a4a39f2b15ad52d59ecef9df36c942215 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 0be8ba845e49ae45cdaf60e3f38be8514efe5f00 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 d14b8b4bad5c44b90fbcb78d21ceb9d18b528eef 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 3402ea1ee81cb2cfa61184d6eaffd1e9743c754c 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 7511c1c4baa944dd73f724566bf78abf15944502 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 62518ed062b5a93e091b43cdfa05b9d9796ac184 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 e204d8b84f97b732f6cf0b3b78ccfff8016d78b0 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 5ec6159e99f1d06b511aff863d830e0d917926ab 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 0a4c515925cc1130821e14de528b8c2792ada94f 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 7ad9304dbef135174734028a1637c776fcabe1a9 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 d84a3fde13fb8ea01cae89a6c5292e74a34ecbef 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 ade5975527b7fd33b6bc4da6c84b378b3d8bfbd9 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 ff7cf939ebe93be3c42873f62dcbd34255d992de 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 9d74fa5c7b7db7f9594eb9842976c2656986d1e6 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 bd188a034bb18892ac97bff077f5e156f6096240 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 be9f947632398a96e68fe21fa17890e255f31fdb 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 aea3d821519b58c0ea4074734cb5cd1000a8cf65 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 16452d2c14525e6da15960afb8feea69a9060f19 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 6d1ca6232ed36257a6ee9124d98cbfe667e5a266 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 ea1c50e9f1362caf17be32831cd9bf36289cd48e 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 bea16873a071bc62162efb6213e9141ac7732a67 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 80ee045485b98533c5732f417df19229e3794928 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 fbeb004b09658d9ae54af6951f0220a2ecf5dd7c 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 83babb400486507c98e151ec08a3663ffe1563a7 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 9e93f41a3483974fc7df24def7f7999909cfd5ec 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 1ca1ed1e5752c2fcb61a25ec31e612b1d88e2b4e 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 ff386540eef6fabdb330bee9ef927c9fafe71496 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 ac01bab1bff8f08d57fdaedb624e36fb65d147c6 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 58d07ddaa5f33052a29cb26ca226da281e5f3475 Author: Zhen Han Date: Sun Sep 20 02:31:31 2026 +0000 drm/amdkfd: correct vram_available calculation [ Upstream commit 9131cc85d0dedd8ba4cae60dbe5985d081551f30 ] reserve_mem_limit() computes available VRAM as vram_size - reserved - vram_pin_size - kfd.vram_used However, kfd.vram_used already includes BOs that are later pinned. Pinning does not consume extra VRAM. Subtracting vram_pin_size counts those bytes twice and causes fake-OOM while VRAM is still free. Reuse get_available_memory() in reserve_mem_limit(). Move ALIGN_DOWN to the ioctl so the userspace ABI is unchanged. The VRAM counter is a parameter: the ioctl passes vram_used_aligned[], the gate passes vram_used[] so a 4K BO is not charged 2MB. kfd.vram_pinned is only updated in gpuvm_pin_bo(). dma-buf pin calls amdgpu_bo_pin() only, so the counter stays zero. Update it from amdgpu_bo_pin() through a KFD helper, on first pin and last unpin, matching vram_pin_size. Track per-XCP pins in vram_pin_size_xcp[] and kfd.vram_pinned[]. Pins that are not owned by a single partition go to vram_pin_size_common, which every partition subtracts. A KFD VRAM BO always carries a partition, so the KFD credit is only correct for xcp >= 0. Call the helper for both branches and let it warn once and skip if that ever stops holding: without the credit the BO would be subtracted through vram_pin_size_common and never added back, which is the double counting this patch removes, and kfd.vram_pinned[] would be indexed out of bounds. Suggested-by: Philip Yang Signed-off-by: Zhen Han Reviewed-by: Mukul Joshi Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher (cherry picked from commit 894cbb31c50e3cf49657130396bbf6c0475304e4) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit c2a3bef88fe10cdb286ad8414b44c7a2935017ff Author: Daniel Phillips Date: Sun Mar 5 22:54:35 2023 -0800 amdkfd: Fix memory availability double accounting of kfd pinned objects [ Upstream commit 16df12d7158fb55f20d6e985abd1996cbabab9f8 ] Pinned objects that are not kfd objects reduce the total vram available to kfd, so we subtract the total size of pinned objects from kdf vram availability. However this double counts objects pinned by kfd itself, because they are counted both as used and pinned. So track the total size of objects pinned by kfd and add it back to kfd availability to remove the double accounting. Signed-off-by: Daniel Phillips Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit b8257bdb26ca5d9a75f4b81f629422f17afa221b) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 2368f9aed09cbabb5a8980c2fbc78bde98e170e9 Author: John Fisher Date: Fri Oct 9 09:45:17 2026 +1300 drm/amdgpu: wait for pending page table updates before switching a VM to CPU updates [ Upstream commit 53d9ef2f518add783bb48a69d77bbc8aea99e911 ] amdgpu_vm_make_compute() switches a VM from SDMA to CPU page table updates when a KFD process acquires it. It syncs "with the last SDMA update/clear" through amdgpu_bo_sync_wait() on the root PD, but that walks the reservation with DMA_RESV_USAGE_READ, and the clears of the VM's page tables (the root PD from amdgpu_vm_init(), and the PDs/PTs the seq64 mapping allocates at the render node's open) are added there by amdgpu_vm_sdma_commit() with DMA_RESV_USAGE_BOOKKEEP only: amdgpu_vm_pt_clear() commits them with a NULL fence, so they do not reach vm->last_update. The CPU path's own waits (amdgpu_vm_cpu_update(), amdgpu_bo_kmap()) use DMA_RESV_USAGE_KERNEL. None of them waits for a clear that is still queued. When one is, the CPU writes the first entries of the new compute VM (the KFD trap handler's TBA/TMA page at AMDGPU_VA_RESERVED_TRAP_START, mapped during ACQUIRE_VM) into a page directory the SDMA then clears. The entries are gone, the handler's page is unmapped, and the first wave save of any queue of the process faults in the SQC instruction fetch at the handler's address (GCVM_L2_PROTECTION_FAULT_STATUS 0x008012B1, PERMISSION_FAULTS 0xb). The MES then fails REMOVE_QUEUE and SUSPEND, and the device takes a MODE1 reset with VRAM lost on 7.2.9; on 7.3-rc6 the queue is reset instead. The window is the time between the render node's open and ACQUIRE_VM. ROCr spends milliseconds there and is practically never hit; a minimal KFD client that opens the render node and acquires the VM at once is hit most of the time. On a Radeon AI PRO R9700 (gfx1201, Resizable BAR, so vm_update_mode defaults to CPU updates for compute VMs), a wave reading the trap handler's page right after queue creation found it unmapped in 8 of 12 runs; a 5 ms sleep between the open and ACQUIRE_VM made that 0 of 9, and the same sleep after queue creation instead 3 of 3. The wait covered these jobs until commit 926c79ad6ecd ("drm/amdgpu: promote the implicit sync to the dependent read fences") narrowed amdgpu_sync_resv() from DMA_RESV_USAGE_BOOKKEEP to DMA_RESV_USAGE_READ; the VM's page table jobs have been added with BOOKKEEP since commit 4247084057cf ("drm/amdgpu: use DMA_RESV_USAGE_BOOKKEEP v2"), so from v6.16 on the sync in amdgpu_vm_make_compute() waits for nothing of them. Record the clears in vm->last_update, as amdgpu_vm_update_pdes() does with its updates, and wait for it, uninterruptibly, before switching the update functions. The clears all go through vm->delayed, so the last one covers the earlier ones; immediate clears are not recorded, as before. With this, on 7.3-rc6 and on 7.2.9, the same client reads the handler 10 of 10 times, 8 busy queues on the 4 compute slots complete in 5 of 5 runs on 7.3-rc6 and 3 of 3 on 7.2.9 (1 of 6 before), 16 and 32 queues complete on 7.3-rc6, and two processes with 8 queues each complete together on both, with no fault. Fixes: 926c79ad6ecd ("drm/amdgpu: promote the implicit sync to the dependent read fences") Cc: Prike Liang Reviewed-by: Christian König Signed-off-by: John Fisher Signed-off-by: Alex Deucher (cherry picked from commit 9ec91b35baba45209c3fcd00f086224a158dd512) Cc: stable@vger.kernel.org # v6.16+ Signed-off-by: Sasha Levin commit 2cbdce3fdf929ec5c13007611a37672720bcfb8e 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 38bb73854a4a0d38162c1776fa1a469de897bc96 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 b260effe83a6566fd1d4038fa5ca9bc8a43c7208 Author: Elena Sakhnovitch Date: Wed Oct 14 14:29:35 2026 -0400 drm/amdgpu/gmc9: add extra type-2 TLB flush for gfx942/gfx950 [ Upstream commit 232213c9bd7f703836164f23160b76657094a7db ] Add extra type-2 TLB flush for GC 9.5.0, similar race condition was observed as Vega20+XGMI. Add to GC 9.4.3 and 9.4.4 too, as they share the same multi-XCD TLB topology. Reported-by: Shahzeb Ahmed Reported-by: Manjunath Gaonkar Signed-off-by: Elena Sakhnovitch Reviewed-by: Apurv Mishra Signed-off-by: Alex Deucher (cherry picked from commit 138cfb165ae6aa98c0767b431e718d1a8199db28) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 1436e441ad19a475ce3fdaacee7efe670405cae9 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 01d08b4de4b1fbac7f980643ed9b4d7460ff1412 Author: Kevin Wang Date: Thu Oct 15 15:38:26 2026 +0800 drm/amd/pm: reapply umd profile state after recovery [ Upstream commit ad6eb088a508d927641c8a76d1ca7911dfb7c80b ] Resume and full GPU reset retain the selected UMD profile level in driver state. The GFX and PMFW state behind it is reinitialized. Add a generic DPM reapply path after CG and PG restoration. It restores the UMD GFX state and asks the PM backend to replay the retained level. v2: - Reapply only GFX CG to preserve the profile-owned GFX PG reference. - Fall back to AUTO when reapply fails without failing device recovery. - Propagate PowerPlay DPM errors before accepting AUTO fallback. - Limit workload-profile error reporting to the swSMU reapply path. This covers: - PCI runtime resume - Full GPU reset recovery - System resume, including S3 and s2idle Signed-off-by: Kevin Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit fd0699fc9f4266fc07d6ce6dbb484fac04601106) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit b900cb2316ff78943f6b19360d931e312b751011 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 87a531b56f2b8992e6082c2e57ec034548bd11d4 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 2081dc291247066cf174f9ad4b20eaffc5663dc0 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 7c43b9c2e9f803f078e22b25fb4f0250988fa17d 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 6130c38c3e735215694b579927e6406bc00ad784 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 94b703ea1438cff1de0f3036a0800bbb90f66256 Author: Maciej Kucharek Date: Thu Oct 15 11:57:11 2026 +0200 drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0 [ Upstream commit 5b56ede880317bd912f914d5cd38ba1d357677fa ] On MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. The EFI stub enables the iGPU on these machines through apple_set_os(). On a MacBookPro11,5 (Radeon R9 M370X, 1002:6821, subsystem 106b:0149), the driver adopts this layout at init: MC_VM_FB_LOCATION=0x007f0000, HDP_NONSURFACE_BASE=0 VRAM at 0x0-0x7fffffff, GART table at 0x1400000 The driver posts the ASIC again on S3 resume and after a GPU reset. The VBIOS asic_init table then moves VRAM back to the VBIOS default: MC_VM_FB_LOCATION=0xf47ff400, HDP_NONSURFACE_BASE=0xf4000000 gmc_v6_0 does not reprogram these registers. The GART table is then no longer in VRAM, and the gfx ring test times out: amdgpu: ring gfx test failed (-110) amdgpu: resume of IP block failed -110 Reset and post the ASIC at driver load on Apple boards with VRAM at 0. The driver then uses the VBIOS layout (VRAM at 0xf400000000) from the start, and later posts keep it. After the reset, FB_BASE is not 0, so a module reload does not reset the ASIC again. The test is the same one that commit c54e4d105077 ("drm/amdgpu: make Mac FB workaround generic") uses: an Apple subsystem vendor and VRAM at 0. The VI quirk for the MacBookPro14,3 resets at load for the same reason: commit b6b1d9721851 ("drm/amdgpu: reset VI ASIC on MacBookPro14,3") Other Apple SI boards get the same reset if FB_BASE reads 0 at load. Tested on a MacBookPro11,5 with 7.2.5 and this patch: the panel comes up at boot, and 4 of 4 deep S3 cycles resume. Without the patch, S3 resume fails every time. The GPU reset path is not tested. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5978 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 60dd16ae10f286cb9cce5b6027b2d5ee869637af) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d72ea8b655133aed1c4b316cbc9c07a43e9fdf43 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 1c2c129c4e7fc2b70c81554415a1d8826563a247 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 2d12e5db3317566e400144e1f99d334f7fabf3dd 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 e27d2775f9dbfe3301ddafc78bb9861399762084 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 0f3f389215cb80d97540f87cef3d07a72776ac38 Author: Takashi Iwai Date: Tue Oct 20 13:31:17 2026 +0200 ALSA: line6: Handle period elapsed calls outside the locks [ Upstream commit 443ed4edc2678cc51c5a01e7dffc4c890be40051 ] LINE6 driver may call snd_pcm_period_elapsed() for both playback and capture substreams at processing the playback substream, and this may lead to a ABBA deadlock. Move the actual calls of snd_pcm_period_elapsed() outside the locks for avoiding it. The capture period notification at submitting the initial playback URBs (only with the impulse mode) is simply skipped, as it's done in the lock context; it'll be caught up at the next period. Fixes: f56742cc4189 ("ALSA: line6: Add LINE6_CAP_IN_NEEDS_OUT, a void playback stream during capture") Reported-by: Sashiko Closes: https://sashiko.dev/#/bug/linux-5a9de389-e6ea-410d-8322-e74e14152603 Cc: Link: https://patch.msgid.link/20261020113118.234689-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0fad7fba30c8ba80968a9867a765987b3ffa6cb2 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 7dff4e2578fee54e8244df7c93bf627ce160632d 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 7986ac275e14fa80dc400ac2776b485467a0b2a2 Author: Wang Yan Date: Tue Oct 20 17:09:59 2026 +0800 ALSA: mtpav: restore negation dropped in guard() conversion [ Upstream commit 47c3d5b885a4fcf65238c0cc525dd3c1cc65aa89 ] commit 316e0074ecdc ("ALSA: mtpav: Use guard() for spin locks") claims to be "Merely code refactoring, and no behavior change", but it accidentally dropped the "!" from if (! (portp->mode & MTPAV_MODE_OUTPUT_TRIGGERED)) in snd_mtpav_output_trigger(). Restore the negation. Fixes: 316e0074ecdc ("ALSA: mtpav: Use guard() for spin locks") Signed-off-by: Wang Yan Cc: Link: https://patch.msgid.link/20261020090959.570101-1-wangyan01@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6d379def894e29a93019b5c04412c807f116255d Author: Peter Ujfalusi Date: Mon Oct 19 17:45:33 2026 +0300 ALSA: compress: reject restarting an ACTIVE task via origin_seqno [ Upstream commit 0ade01edd33181b65393cf3864cb2ac7c5eb1487 ] snd_compr_task_start_prepare() only rejects tasks with state >= SND_COMPRESS_TASK_STATE_FINISHED. Since the enum is IDLE(0) < ACTIVE(1) < FINISHED(2), this accepts ACTIVE tasks and rejects FINISHED ones, the opposite of what the origin_seqno mechanism needs: origin_seqno is meant to let a caller reuse a FINISHED task's buffers for a new job, not to restart a task that is still queued with the driver. The seqno lookup path in snd_compr_task_start() has its own explicit "task->state != IDLE" guard, but the origin_seqno lookup path relies solely on this function, so it can restart an ACTIVE task, causing ops->task_start() to be called twice for the same task and runtime->active_tasks to be incremented twice without a matching finish/stop. Accept IDLE and FINISHED, reject ACTIVE, on both entry paths. Fixes: 04177158cf98 ("ALSA: compress_offload: introduce accel operation mode") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Acked-by: Vinod Koul Link: https://patch.msgid.link/20261019144533.30665-5-peter.ujfalusi@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 50eb0b68ff6446928588052d2d92274a5c4cb77a 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 bda1fb7c15d9c7a293cc974d0325125ec577992a 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 f82eafe282ea30abb82ca697069a33018de831d9 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 d43792f4263a309705d495bec65496b802cb40e7 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 c59b5fcbc7b777bcf89a976af57f52a95ba42b6f 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 dba86614860210064742fa38ae2db0c9030dba27 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 8126595cc9ab1b2613867c8dbab79005cbe1ff87 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 8803593347710323494c1bbeefe2f0781cee7950 Author: Dmitry Torokhov Date: Sun Oct 11 23:12:40 2026 -0700 Input: always accept EV_SYN in input_event() [ Upstream commit c1d13bfdb9c75c2885d10332174a887349eb0b51 ] Commit 0cd587735205 ("Input: preallocate memory to hold event values") moved allocation of dev->vals into input_allocate_device(), which caused input core to accumulate events reported while seeding initial device state before input_register_device(). However, because EV_SYN is only set in dev->evbit during input_register_device() (and some drivers also overwrite dev->evbit directly before registration), any EV_SYN/SYN_REPORT events sent before registration were dropped by is_event_supported(), leaving those seeded events stuck in dev->vals until the next SYN_REPORT after registration. Always accept EV_SYN in input_event() and input_inject_event() without checking dev->evbit so input_sync() flushes dev->vals as intended. Reported-by: Karlos Abel , Fixes: 0cd587735205 ("Input: preallocate memory to hold event values") Cc: stable@vger.kernel.org Assisted-by: LLM Acked-by: Jiri Kosina Link: https://patch.msgid.link/asx50uz6iafsyAd5@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit fdb8628449f31b54b6b5269dd47242d94ac1c3a4 Author: Armin Wolf Date: Wed Oct 7 01:45:34 2026 +0200 hwmon: (acpi_power_meter) Fix 18.45 TW bug [ Upstream commit 0b6eda22f9ab67ddb2a872b0c3fc578ad9f4e27e ] The ACPI specification says: "If an error occurs while obtaining the meter reading or if the value is not available then an Integer with all bits set is returned" This integer can also be 64-bit wide on ACPI 2.0 and later systems, so we have to check for that too. Compile-tested only. Reported-by: Grant Slater Closes: https://github.com/lm-sensors/lm-sensors/issues/460 Fixes: 1fefca6c57fb ("hwmon: (acpi_power_meter) Fix 4.29 MW bug") Cc: stable@vger.kernel.org Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20261006234618.10943-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 6ffb37e91e6bb8a6e97f75e900d3456d71854c71 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 5cc7fddfce17f86c9267eda1109efba234a156e5 Author: Igor Velkov Date: Sun Oct 4 23:56:53 2026 +0000 rtc: pcf8563: pass the driver data to the alarm interrupt handler [ Upstream commit 5831f5fef10030c175e585d51b0e793dc6fef6ab ] pcf8563_irq() takes its dev_id as struct pcf8563, but probe still registers the interrupt with the i2c client. The handler then takes the regmap pointer from the wrong structure: the first alarm oopses, the level-low INT is never acknowledged, and the interrupt gets disabled as spurious. Only an RTC that has an interrupt (client->irq > 0) reaches this path. Fixes: 00f1bb9b8486 ("rtc: pcf8563: Switch to regmap") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Igor Velkov Reviewed-by: Nobuhiro Iwamtasu Link: https://patch.msgid.link/20261004-pcf8563-irq-data-v1-1-f176763ddf2f@iav.lv Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 45e57ee17b8a588a752f45b2b499756d9ee3d75c 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 5e2b198a238421a44712a014c898e8963593fe9b 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 4b6177c53f05c5dca180d67cb26ec4594ae234b5 Author: Jianyun Gao Date: Thu Oct 15 22:34:25 2026 +0800 dax: fix wrong error code returned from dax_dedupe_file_range_compare() [ Upstream commit 9b036546a02c6c9a5133f9c1e93503896595c6ba ] When dax_range_compare_iter() returns a negative error code (e.g. -EIO), dax_dedupe_file_range_compare() incorrectly returns 'ret' which holds the positive return value from iomap_iter() indicating more iterations remain. This positive value leaks to the caller, where vfs_dedupe_file_range() interprets it as success (bytes_deduped = len), causing userspace to incorrectly believe deduplication completed. Return 'status' instead to propagate the actual error code. Fixes: 0e79e3736d54 ("fsdax: dedupe: iter two files at the same time") Cc: stable@vger.kernel.org Signed-off-by: Jianyun Gao Reviewed-by: Jan Kara Reviewed-by: "Darrick J. Wong" Link: https://patch.msgid.link/20261015143426.17620-1-jianyungao89@gmail.com Signed-off-by: Alison Schofield Signed-off-by: Sasha Levin commit f78eff4218be3dcb34fabc9822164423ce601d05 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 9738228aeaf27ed26b9815b79dde9574e124148d 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 e1db6d1f020ea94f16c3f6149a7c9d4ebcb9fb02 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 9e4af1fa6eb134ab230c0e3788c02f138f3febb7 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 306a7db6aaa192e6ff1bd235bae4613d855af87f 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 c2b9c053512eab7f32e41eea9cadf372fea06aa2 Author: George Christidis Date: Sun Oct 18 18:56:31 2026 +0200 ALSA: hda/realtek: Fix headset mic on ASUS Zenbook 14 UX3402VA [ Upstream commit 40409fa23d32c8ed51e832031daa6decd9d6fd11 ] The UX3402VA (1043:16a3) BIOS leaves pin 0x19 unconfigured, so the headset mic does not work. Use ALC294_FIXUP_ASUS_SPI_HEADSET_MIC like the UX3405MA, it sets up the mic and keeps the CS35L41 speaker fixup. Tested on a UX3402VA: headset mic, internal mic and speakers work. Fixes: 07058dceb038 ("ALSA: hda/realtek: Splitting the UX3402 into two separate models") Cc: stable@vger.kernel.org Signed-off-by: George Christidis Link: https://patch.msgid.link/20261018-for-linus-v1-1-4d8e9ff27d89@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 16777276954753bb06b7e9e338ed08a7a3742557 Author: Adrian Ambrozewicz Date: Fri Oct 16 12:22:58 2026 +0300 gpiolib: cdev: don't set GPIOD_FLAG_IS_OUT [ Upstream commit 974d2712cb15014019595799b3ed68fef5fe9695 ] When a line is requested or reconfigured through the v2 uAPI, gpio_v2_line_config_flags_to_desc_flags() copies the requested configuration into the descriptor flags, GPIOD_FLAG_IS_OUT included, before gpiod_direction_input_nonotify() or gpiod_direction_output_nonotify() asks the driver for the direction. If the driver refuses, for instance with -EOPNOTSUPP from .direction_input() for a line that can only be an output, the ioctl fails but the flag keeps the refused direction. gpiod_free_commit() does not touch GPIOD_FLAG_IS_OUT, so this outlives the failed request, and GPIO_V2_GET_LINEINFO_IOCTL reports the line as an input while the hardware still drives it, until a request without direction flags makes gpiod_request_commit() read the direction back from the driver: GPIO_V2_GET_LINE_IOCTL, line 0, input: -EOPNOTSUPP GPIO_V2_GET_LINEINFO_IOCTL, line 0: input GPIO_V2_GET_LINE_IOCTL, line 0, no direction: ok GPIO_V2_GET_LINEINFO_IOCTL, line 0: output GPIO_V2_LINE_SET_CONFIG_IOCTL updates the flags in the same order. There the line stays requested, and since commit 92ac7de3175e ("gpiolib: don't allow setting values on input lines") GPIO_V2_LINE_SET_VALUES_IOCTL on it then fails with -EPERM, though the line is still an output. A line whose driver refuses to make it an output is likewise reported as one. gpiod_direction_input_nonotify() and gpiod_direction_output_nonotify() set or clear GPIOD_FLAG_IS_OUT themselves once the driver has accepted the direction, emulated open drain and open source included, and nothing between the copy and those calls reads the flag. Leave it to them, as the v1 uAPI already does. The other flags that the helper copies stay as they are. Active low, drive and bias are what gpiod_direction_*() applies, drive and bias possibly before the driver refuses the direction; edges and event clock are the character device's own. None of them is read back from the driver, so there is no earlier state that is more accurate to go back to. A failed request releases the line, which clears them, and a failed reconfiguration leaves the line, like the lines before it, with what was applied up to the failure. Reproduced under QEMU with a test GPIO chip whose line 0 refuses input and line 1 refuses output: both refused requests and both refused reconfigurations leave the line info with the refused direction, and setting the value of the reconfigured output fails with -EPERM. With this change the line info shows the direction of the hardware in all four cases and setting the value works. First seen on real hardware with v6.12. Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Adrian Ambrozewicz Reviewed-by: Kent Gibson Link: https://patch.msgid.link/20261016-gpiolib-cdev-direction-v2-1-aambrozewicz@nvidia.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 78b8738d6656acec8a0d812bf826a9a412f16971 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 2affbfaa1db576a7612ae11d5ca8b97f8fd30bdd 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 6ad77a47904e8e9d8cfecc53a47146fa69b462a9 Author: Baek Kyu, Kim Date: Sun Oct 18 05:52:34 2026 +0900 hwmon: (sht4x) Reject incomplete heater command transfers [ Upstream commit 0e1d292233c83d41530df6ffa4ec5a382f118b12 ] heater_enable_store() treats a zero return from i2c_master_send() as success. It updates the heater state and returns count, so another attempt to enable the heater fails with -EBUSY. i2c-virtio can return zero when the first message fails. Require SHT4X_CMD_LEN before updating the heater state, as sht4x_probe() already does for the reset command. Fixes: 0eed6fc3d2b9 ("hwmon: (sht4x): add heater support") Cc: stable@vger.kernel.org Signed-off-by: Baek Kyu, Kim Link: https://patch.msgid.link/20261017205234.1084949-1-pocj8ur4in@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 580203eaebaa611f43c07793c77c9c97df9d4a72 Author: Tom Verdonck Date: Fri Sep 25 20:23:24 2026 +0200 hwmon: (sht4x) Fix jiffies wraparound in heater-ready check [ Upstream commit ce3ff350c4a3b9466bd67bfe2adb2e3bea732b9e ] sht4x stores in ->heating_complete the jiffies deadline at which the current heater pulse finishes. It is set once at probe (to jiffies) and only updated when the heater is explicitly enabled via sysfs, so in the common case where the heater is never used it stays frozen at its probe value. ->heating_complete is an unsigned long compared with time_before(), whose signed difference is only meaningful while the two values are within LONG_MAX jiffies of each other. Because the deadline is frozen, jiffies keeps advancing away from it, and after 2^31 jiffies the difference flips sign. On a 32-bit HZ=100 kernel that happens ~248.5 days after boot. time_before() in sht4x_read_values() then wrongly reports that heating is still in progress and the read path executes msleep(jiffies_to_msecs(data->heating_complete - curr_jiffies)); with a bogus, huge delta, blocking the temperature read for a very long time instead of returning data. The heater_enable sysfs attributes are affected the same way (spurious -EBUSY and "1" readback). Store the deadline as a 64-bit jiffies value and compare it with get_jiffies_64()/time_before64(), which does not wrap in any practical uptime. Fixes: 0eed6fc3d2b9 ("hwmon: (sht4x): add heater support") Cc: stable@vger.kernel.org Signed-off-by: Tom Verdonck Link: https://patch.msgid.link/7b2087ccb963e097cf3f6333efaec0c46549003b.1790358356.git.tom.verdonck@inspiral.be [groeck: Squashed 'Fix torn read' patch into this one] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 90cc16ecf4a70aad6f8b3ea5af8ec38064b03428 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 ccda4439445c0dcec7665af812ef5806b211b2d6 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 1ded6b545bade7167471e2b3f2d4fe0c6489cd6e 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 7e2ff6da9ecf1e041005fd60caba04bcbea2035d 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 42c4ea22552148c6f2ef93aa80b7657609555434 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 4f2aa02c8865810c9dbeec767e78da9e2bd8ef43 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 8002dacea4708c7092ae4b00927b3861de608873 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 be818ec671dba143030e5924cb44a768114042ca 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 5aa85f90a825b7eb9d4b6d0dd956d652715fa108 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 a26392e2fde8ca95ae4fee99abaa1516c32cab3b 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 07b4cbae2060778e53e4b102f28b042abf1331c5 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 bc958129a57392adff6f2d374bbb0f32bbf9a5de 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 11452dc2e6bb4f42f700eb052dbc700f11b6764f 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 935f03f988830acc83ac889795c15830510d219b Author: Brandon Williams Date: Tue Oct 13 13:34:51 2026 -0400 power: supply: qcom_battmgr: Notify charger supplies of online changes [ Upstream commit 87fd20da8ca8bacdaa9bff5860167f208077dc51 ] On SC8280XP and X1E80100 the AC, USB and wireless supplies take their online state from the charging source in the battery status response. The firmware sends no notification for those supplies when the charging source changes, and the driver only announces the battery, so userspace never learns that the charger was plugged in or out. UPower keeps the state it read at startup: a laptop booted on the charger never goes on battery. Call power_supply_changed() for a supply whose online state changes when a status response is parsed. A supply that is not registered yet, when the battery is read during probe, reports its state when it registers. Tested on a Microsoft Surface Pro 11 (X1E80100): after restarting UPower on the charger, unplugging now sets OnBattery, and plugging in clears it. Fixes: 29e8142b5623 ("power: supply: Introduce Qualcomm PMIC GLINK power supply") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Brandon Williams Link: https://patch.msgid.link/20261013-upstream-battmgr-charger-online-v1-1-731973e133a0@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 7ba7ddbf458cb1c6593da649ac844db6d4979d08 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 b66d83f86183997b58469d571351b89b919475d4 Author: Andrew Pam Date: Mon Oct 5 15:34:18 2026 +1100 power: supply: cros_charge-control: restore EC state on resume [ Upstream commit 1f2a40f954c848dff9d8bb6d81e404f9e47f0e81 ] The EC resets its charge control configuration when the AP powers off, so configured sustainer thresholds and charge behaviour are lost across hibernation. Nothing notices the reset. Commit 4fc88ba435da ("power: supply: cros_charge-control: adopt EC charge state on probe"), in the power-supply tree, made the driver adopt the EC's charge state, but only at probe, and a resume is not a probe. Sysfs therefore keeps reporting the configured values while the EC charges the battery to full. On a Framework Laptop 16 (Ryzen AI 300, charge control command version 3) with charge_control_end_threshold set to 80, a hibernate and resume cycle leaves the attribute still reading 80 while the battery charges past it to 100%. Add a system sleep resume hook that reprograms the EC from the cached state. The same EC behaviour and the same fix already exist for another driver, see commit 2643187ccb86 ("platform/x86: ayaneo-ec: Add suspend hook"). Reprogramming the EC is only strictly required after hibernation, but it is cheap and idempotent, so hook every resume path rather than rely on the EC preserving its state across each kind of sleep transition. Note that re-reading the state from the EC on resume, by reusing cros_chctl_init_state() or otherwise, would be wrong even on the command versions that support GET: the EC has been reset to its defaults by the time the hook runs, so adopting that state would silently discard the configuration the user asked for. The driver's cached state is the only remaining record of it, which is why it is pushed to the EC rather than refreshed from it. Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Andrew Pam Reviewed-by: Tzung-Bi Shih Acked-by: Thomas Weißschuh Link: https://patch.msgid.link/20261005043418.243937-1-andrew@fastmailteam.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 69c4e9c13afa249611bbc2d468b3883de524deff Author: Fabricio Akio Date: Fri Oct 2 22:29:32 2026 -0300 power: supply: qcom_smbx: set the charge enable after software control [ Upstream commit 1fba787142011145e1071cee9448b3677fb2323d ] The init sequence sets CHARGING_ENABLE_CMD before CHGR_CFG2 selects software control of the charge enable. The Motorola Moto X4's bootloader leaves the charger watchdog armed to disable charging when it bites, which it does after a few minutes in fastboot. Charging then stays disabled in the next boot until the cable is replugged. Setting the command after CHGR_CFG2 re-enables it. Fixes: 8648aeb5d7b7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver") Cc: stable@vger.kernel.org Signed-off-by: Fabricio Akio Link: https://patch.msgid.link/20261002-qcom-smbx-enable-order-v1-1-7df92bd809db@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 6c8413f5412d2e8c6b6ceaa930848a825ceeedb9 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 3c4c6b318e7f52fa44a9ae2bfab03b9e9c782be1 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 8975faca8c9d3fb855da5949eebf2030e4d778e2 Author: Paolo Abeni Date: Tue Oct 13 16:29:20 2026 +0200 mptcp: fix subflow bitfield misuse [ Upstream commit 7538fa33bb2f66b8b809ff39d58308be48e197a0 ] The subflow status bitfield is protected by the subflow socket lock, with one notable exception: the `close_event_done` bit is actually under the msk socket lock protection. As reported by Clashiko [1], flipping the latter bit may corrupt other entries in the same bitfield. Move the `close_event_done` outside the bitfield, in a 32bit hole. Link: https://lore.kernel.org/178959153492.22033.1944011998010756543@kernel.org Fixes: d82809b6c5f2 ("mptcp: avoid duplicated SUB_CLOSED events") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni 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-2-932c9b182fc7@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e07db95b63a17250230642acd5c3be84fc2d0e5f 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 ab36779bedcf1d0fcd309976e16f6c203f43bd8f 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 448dba9b2af31f445933a1f3026669619280f20c Author: sonotri Date: Thu Oct 15 21:06:54 2026 +0900 ublk: pin module while release work is pending [ Upstream commit afc9cde716b29ce814798d649a95f9128ba42b43 ] ublk_ch_release() takes a device reference and queues exit_work. The VFS module reference held through the file operations is dropped after ->release() returns. A queued work item does not acquire its own module reference for the callback. Consequently, normal module removal can start while exit_work is pending or executing. In addition to the worker callback itself, the final device put can invoke ublk_cdev_rel(), which is also module code. Take a module reference while ->release() is still covered by the file operations reference and drop it only after the worker has completed its final device put. A rearming worker retains the same reference. Merely canceling exit_work during module exit is insufficient. The worker is the terminal path for the device reference taken by ublk_ch_release(), so its cancellation would strand that reference and skip the associated cleanup. Fixes: c5c5eb24ed61 ("ublk: avoid ublk_io_release() called after ublk char dev is closed") Cc: stable@vger.kernel.org Signed-off-by: sonotri Reviewed-by: Ming Lei Link: https://patch.msgid.link/20261015120654.241354-1-sono7ri@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0e49fbd593ed3c9876d72c0ba481a5e70b3e59b9 Author: Chengfeng Ye Date: Tue Oct 13 17:04:47 2026 +0800 fuse: fix copy_file_range reply handling race [ Upstream commit bf4ccbaad8bdff8c90fd290ed6135b63f89ee8a7 ] __fuse_copy_file_range() selects its request opcode and output buffer using fc->no_copy_file_range_64, then reads the flag again to handle the reply. Copies to different destination inodes can run concurrently on the same connection, so the flag may change while a request is pending. For example, task A submits FUSE_COPY_FILE_RANGE_64 and waits for its reply. Task B submits the same opcode, receives -ENOSYS and sets no_copy_file_range_64. When A receives a successful reply, it reads the uninitialized outarg.size instead of outarg_64.bytes_copied. This can produce an incorrect return value, page cache invalidation range and inode size update, and disclose stack contents if automatic stack initialization is disabled. If A also receives -ENOSYS, it instead mistakes that reply for rejection of the legacy opcode and sets no_copy_file_range, skipping the legacy fallback and unnecessarily disabling copy offload for the connection. KCSAN reported the conflicting accesses: BUG: KCSAN: data-race in __fuse_copy_file_range / __fuse_copy_file_range read to 0xffff8881014a4d4d of 1 bytes by task 123 on cpu 4: __fuse_copy_file_range+0x1a7/0x6e0 fuse_copy_file_range+0x54/0xd0 vfs_copy_file_range+0x290/0x9d0 __do_sys_copy_file_range+0x10f/0x2f0 write to 0xffff8881014a4d4d of 8 bytes by task 119 on cpu 0: __fuse_copy_file_range+0x633/0x6e0 fuse_copy_file_range+0x54/0xd0 vfs_copy_file_range+0x290/0x9d0 __do_sys_copy_file_range+0x10f/0x2f0 The bug can lead to leak kernel base address for KASLR bypass, the corresponding reproducer can be provided per request. Use args.opcode for both -ENOSYS handling and output buffer selection. It records the opcode actually sent and is updated on fallback, keeping each reply tied to its request regardless of concurrent flag updates. Fixes: 7a37f55af7af ("fuse: add COPY_FILE_RANGE_64 that allows large copies") Cc: stable@vger.kernel.org Assisted-by: GPT-6 Astra Signed-off-by: Chengfeng Ye Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 6bbdb8bf46ef3219732a9645fa53e28b37c4df77 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 d75a44d360b6410eb89d0029b3eb1eea0571e2f9 Author: Joanne Koong Date: Tue Oct 6 03:51:36 2026 -0700 fuse: don't launder folios of a bad inode [ Upstream commit 01d0f3d294af126f517d92c11e100525537f8be4 ] fuse_flush() and fuse_writepages() reject writing back dirty data for any inode that has been marked bad, but fuse_launder_folio() doesn't. This can cause the following warning in fuse_write_file_get() to trigger, as reported by syzbot: WARNING: fs/fuse/file.c:2043 at fuse_write_file_get fs/fuse/file.c:2043 [inline] WARNING: fs/fuse/file.c:2043 at fuse_iomap_writeback_range+0x7c8/0x18f0 fs/fuse/file.c:2227 Call Trace: iomap_writeback_folio+0x1526/0x2490 fs/iomap/buffered-io.c:2022 fuse_launder_folio+0x17b/0x240 fs/fuse/file.c:2331 folio_unmap_invalidate+0x4cd/0x830 mm/truncate.c:634 invalidate_inode_pages2_range+0x629/0xb30 mm/truncate.c:726 fuse_open+0x5a6/0x770 fs/fuse/file.c:297 This can be hit on a writeback cache mount: 1) a writeable file is open and a buffered write dirties some pages 2) another thread opens the same file read-only. fuse_open() passes the bad inode check and sends OPEN to the server. 3) a SETATTR reply with the wrong file type marks the inode bad 4) the writeable file is closed. Flush and release skip writeback because the inode is bad. The pages stay dirty but the file gets removed from write_files. 5) server replies to the OPEN. The reply has no FOPEN_KEEP_CACHE, so fuse_open() calls invalidate_inode_pages2(). 6) the invalidation finds the dirty pages and calls fuse_launder_folio(), which finds no wriable file and hits the WARN_ON in fuse_write_file_get(). Instead of trying to write back dirty data for the bad inode, fuse_launder_folio() should return -EIO. Fixes: 5d069dbe8aaf ("fuse: fix bad inode") Reported-by: syzbot+e8200299b0556976e13c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e8200299b0556976e13c Cc: stable@vger.kernel.org Signed-off-by: Joanne Koong Reviewed-by: Horst Birthelmer Tested-by: syzbot+e8200299b0556976e13c@syzkaller.appspotmail.com Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit c51d1779ff5ab43fadb8bbba37bd98aa536ab0bc 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 24288c516442f49f00a2b735419fc1f0629de823 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 e22aba38a54f1c55090151d5cd7868a258b39cc9 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 e4d2571effd19d76387e408e1f3506e9be17a5f4 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 409efb4f12b95e50e2e1f5f04af75a85eef01904 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 4980879032bbc2d63f976f5b7f222105cea20ecb 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 a3203fbd9bf6e9201cae0f846df3e8badbceb814 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 6f511bbaa33b903b1ca360a8e97eb735e3dad25d 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 818fb17d609baf8e9646425c3efea6beba14379b 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 dfa1499fdca9aaad24c7154ee2279045dba04745 Author: Ming Lei Date: Sun Oct 11 01:35:48 2026 -0500 ublk: reset the FETCH round under ub->mutex [ Upstream commit 84824afdb5a4dc127fbd7036142d7611c5e53651 ] The release work resets the FETCH round without ub->mutex, while START_DEV checks it under ub->mutex: START_DEV (ub->mutex) release work all queues ready? yes ublksrv_tgid matches? yes ublk_reset_ch_dev(): io->cmd = NULL, nr_queue_ready = 0 go live: a request then reaches ublk_queue_cmd() with a NULL io->cmd Do the reset under ub->mutex. Then START_DEV sees the round either ready or reset. The work already takes ub->mutex when there is a disk, after it has aborted the requests; nothing holding ub->mutex waits for it. Fixes: 728cbac5fe21 ("ublk: move device reset into ublk_ch_release()") Cc: stable@vger.kernel.org Tested-by: Josef Bacik Signed-off-by: Ming Lei Link: https://patch.msgid.link/20261011063555.1142277-6-tom.leiming@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 44322a7293f15c9a1c1c74380eeb2ede878a6c55 Author: Ming Lei Date: Sun Oct 11 01:35:47 2026 -0500 ublk: reset the FETCH round in release also without a disk [ Upstream commit f06ca594eafcdf58a399a0f92480631192e06032 ] The release of /dev/ublkcN resets the queues only when the device has a disk. Without one it skips ublk_reset_ch_dev(): server fetches, never starts; old server exits or STOP_DEV removed the disk release: no disk → skip reset ios stay ACTIVE / CANCELED, nr_io_ready stays full new server opens /dev/ublkcN FETCH: -EBUSY (still ready), or -EINVAL after a partial round → the device can only be deleted All uring_cmds are done when the release work runs, with or without a disk, so the reset is safe either way. Do it in both cases. Then a new server can fetch and start the device again, as the STOP_DEV entry in Documentation/block/ublk.rst says ("ublk device is ready for the new process"). Fixes: 82a8a30c581b ("ublk: improve detection and handling of ublk server exit") Cc: stable@vger.kernel.org Tested-by: Josef Bacik Signed-off-by: Ming Lei Link: https://patch.msgid.link/20261011063555.1142277-5-tom.leiming@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 50e8c09605b428fbd2305e0eaab05dc1a18c60e6 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 faef48ba428669db18c400e816f66f3446187175 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 2c5a807800b5f3349e16af591c9081a65fb4d23d 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 7fe49d46b305cdd38d2a94b7ed643c3c2f9e99f2 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 01c73963d83b3b85ccce6f273e46da32fb43e70f 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 bf56e0e3cd67806a15dfaf637cd941449ca54a49 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 95b03c926dcce21ba9271ddb4799e372512261b3 Author: Keng-Yu Lin Date: Thu Oct 15 10:08:11 2026 +0800 PCI/PM: Restore BARs after powering up during enumeration [ Upstream commit f043083843cac1105206437d8c58e725b6412fad ] Commit 4d4c10f763d7 ("PCI: Explicitly put devices into D0 when initializing") added pci_pm_power_up_and_verify_state() to pci_pm_init(). The helper ignores pci_power_up()'s return value indicating that BARs need restoring. Its resume callers restore saved configuration afterwards; pci_pm_init() does not. D3hot-to-D0 may reset a device and lose its BARs (PCI PM 1.2, sec 5.4.1). After enumeration powers it up, pci_enable_device() reads D0 and skips the full power-up path. Previously, a device still in D3hot at enable time took that path, including BAR restoration. On AMD Venice SP7, two AMD xHCI controllers [1022:17d2] are in runtime D3hot with No_Soft_Reset clear before kdump. Diagnostic reads on v7.3-rc6-37 show the following for 0000:01:00.4 in the crash kernel: PMCSR BAR0 before the platform power call 0003 f4100004 after the platform power call 0003 f4100004 after native D0 power-up 0000 00000004 The upper BAR DWORD stays zero. pci_power_up() returns 1, but the BAR address remains zero while dev->resource[0] still contains 0xf4100000. Without BAR restoration, the crash kernel hangs during boot. The last console output includes: pci 0000:01:00.4: enabling device (0000 -> 0002) Restoring both controllers' BARs gives matching readbacks and allows kdump to save a vmcore and reboot. An AMD Turin xHCI [1022:1557] shows the same BAR loss; restoring its BAR also allows kdump to complete. Read the initial power state first. Otherwise, pci_power_up() may request a BAR restore based on a cached PCI_UNKNOWN state, even when the device is already in D0. For devices already in D0, only synchronize the platform state so that ACPI calls such as _REG still run. For other states, use pci_set_full_power_state() to power up the device and restore BARs when needed. Fixes: 4d4c10f763d7 ("PCI: Explicitly put devices into D0 when initializing") Suggested-by: Mario Limonciello Suggested-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/CAJZ5v0ie2AvCbdv8-zkpYzHLcTwUPUj+=WWOQjDAPmSepSAQPg@mail.gmail.com/ Signed-off-by: Keng-Yu Lin [bhelgaas: shorten comment] Signed-off-by: Bjorn Helgaas Reviewed-by: Mario Limonciello (AMD) > --- Reviewed-by: Desnes Nunes Reviewed-by: Rafael J. Wysocki (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261015020811.1132314-1-keng-yu.lin@hpe.com Signed-off-by: Sasha Levin commit 67221e6133a92aeabebb1ec4497234643a7b7745 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 258d92898ea3095c7363f646aad82ff7c06c5d0b 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 42e39e25b62e2d0b63e8cf0426b720b486353ecc 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 081e702e1a4aaa9f03a43d576724091b345fc429 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 c4ac68d07c812bf59a62d399a79e8fa4ca3fdf58 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 4a8f333446c10d361782aa4dcb7833d30cf5c154 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 a2045078fe85918054462348c3e3ee9d628a125b 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 cbf52d6ce1d9861b15adc8a5aca90791361c6415 Author: Marc Zyngier Date: Thu Oct 15 11:05:35 2026 +0100 KVM: arm64: Move IN_GUEST_MODE ahead of state being loaded [ Upstream commit 22b6557ad05bf05c73246f62c19af3e04017270e ] IN_GUEST_MODE is advertised too late, when state has already been moved onto CPU registers and cannot be observed by another CPU anymore. Move the IN_GUEST_MODE publication ahead of the state being loaded, and immediately check for pending request. This ensures that there is no window of opportunity for another CPU to observe OUTSIDE_GUEST_MODE and yet for state to be loaded. This also simplifies the "state rollback", which solely amounts to synchronising the timer when no irqchip is present. Cc: stable@vger.kernel.org Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Link: https://patch.msgid.link/20261015100539.1011760-4-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 4c5b129a54498f18d9171e58dbc15e4800387274 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 d93e70dca09ab7ae0d5aab6b4f5e5374a32913a5 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 e9c140e506617e2d71d522ed900f0c9be27faac9 Author: Ard Biesheuvel Date: Thu Oct 15 13:38:58 2026 +0200 efi/libstub: arm64: Don't use the platform register x18 [ Upstream commit 4c86b5f3fa78347fa9cbc9e8ec06615b2f80e397 ] The UEFI specification designates x18, the platform register, as "do not use" on AArch64, so that UEFI code is compatible both with an OS that assigns a fixed role to x18, and with one that uses it as a temporary register. The arm64 EFI stub and the EFI zboot decompressor only avoid x18 if the kernel is built with shadow call stacks, as that is the only case where -ffixed-x18 is added to KBUILD_CFLAGS, which the stub inherits. Otherwise, the compiler is free to use x18 as a temporary register, and it does so. So pass -ffixed-x18 unconditionally when building the stub for arm64, so that the image can be run by loaders that rely on x18 being left alone, such as a kernel that uses it for its shadow call stack. Cc: Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 9c9bbb6a878056447dac471bbe73b4aa93085b01 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 a59760cefb24e186b017e48caa5b71b31b696130 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 443730e39b1b79a68ef9220124fb0bbb0bf1bc6d 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 ce6abad3ea47d8a463f7f3f0de098b7c92f6c4a8 Author: Karl Mehltretter Date: Sat Sep 26 02:41:24 2026 +0200 irqchip/atmel-aic[5]: Disable interrupts in the irq_pm_shutdown() callbacks [ Upstream commit 0ca21fe111457c843624a835641bb490e704bb2f ] irq_gc_shutdown() calls the irq_pm_shutdown() callbacks from syscore_shutdown() with interrupts enabled. aic_pm_shutdown() and aic5_pm_shutdown() take the generic chip lock with raw_spin_lock(), and irq_gc_eoi() takes the same lock from the interrupt handler. An interrupt from the chip while the lock is held spins in irq_gc_eoi() and hangs the reboot. Lockdep reports this on every reboot of a SAM9X75 Curiosity board: WARNING: inconsistent lock state inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. busybox/101 [HC0[0]:SC0[0]:HE1:SE1] takes: c1c2b434 (&gc->lock){?.-.}-{2:2}, at: aic5_pm_shutdown+0x34/0xd8 {IN-HARDIRQ-W} state was registered at: ... irq_gc_eoi+0x28/0x60 handle_fasteoi_irq+0x120/0x214 ... aic5_pm_shutdown from irq_gc_shutdown+0x4c/0x58 irq_gc_shutdown from syscore_shutdown+0x5c/0x9c syscore_shutdown from kernel_restart+0x34/0x78 kernel_restart from sys_reboot+0x180/0x25c Use the irqsave guard, as commit 33517881ede7 ("irqchip/brcmstb-l2: Use _irqsave locking variants in non-interrupt code") did for brcmstb-l2. Fixes: b1479ebb7720 ("irqchip: atmel-aic: Add atmel AIC/AIC5 drivers") Signed-off-by: Karl Mehltretter Signed-off-by: Thomas Gleixner Assisted-by: LLM Reviewed-by: Radu Rendec Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260926004124.88221-1-kmehltretter@gmail.com Signed-off-by: Sasha Levin commit 537b8eabc1c391b3f85509ac41cb2be2cd862a8e 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 aa309d71afdfba9824f1eab87f482a06bf0a3f18 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 d7c633ef352783af346cfe55bbe5410ab7dd737d 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 335a0eaaa0d72197c52ba7230c869ef587904109 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 741ac7c9673e65e5b2c02249ca9cf9c133ff21d6 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 db482904054850558358d920b78ff057b1821575 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 72e298e41885b1c2d029a8075ca82f10dd26c75b Author: Nathan Chancellor Date: Wed Oct 14 16:40:41 2026 -0700 kbuild: AutoFDO: Update split machine function argument for upstream rename [ Upstream commit 2b358510d5cc56164f83110ca1499c95a5a352cd ] A recent LLVM commit [1] renamed the internal LLVM plugin option '-split-machine-functions' to '-function-splitting=all', breaking the AutoFDO + ThinLTO build with: ld.lld: error: -plugin-opt=-: ld.lld: Unknown command line argument '-split-machine-functions'. Try: 'ld.lld --help' The plugin option is needed for in-process ThinLTO, so handle the rename accordingly using ld-option. Cc: stable@vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/2186 Fixes: 2fd65f7afd5a ("AutoFDO: Enable machine function split optimization for AutoFDO") Link: https://github.com/llvm/llvm-project/commit/3e6acc87c58843e551d6e8e4bf06c26712b04622 [1] Link: https://patch.msgid.link/20261014-update-autofdo-split-machine-function-option-v1-1-5c71b3005e89@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 9e9554d3906cea522a437f745fe4b7765b3f27b5 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 c48802c7cc667fe5fd4ff8d1e84fa24d9e10abe8 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 eb86688484688e7626f71f0a98583f9cdf760f13 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 c00719deed5b6245dedeeb8d6d19cb852fe2ac4d 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 ef5743bd6ede07529f0b88f26443a06b8d1c020a 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 967b028e2d39dc207a447603a3fa640b661a066d 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 658da2402f4bb71e321b046d4ec95d90f786add7 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 c63c5e1d19ad030df3dce9460cb935765eeb7a09 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 b60a589783eb939dbd03e7bcd138893f91cc845e Author: Francesco Orlando Date: Sun Oct 11 18:58:21 2026 +0200 Input: xpad - add GameSir Nova Lite support [ Upstream commit 2e6f2e5799f328ca0879dad14d7f3709c7f7496b ] Add vendor and product ID for GameSir Nova Lite (0x3537:0x1040) in XInput mode to enable force feedback rumble support. Signed-off-by: Francesco Orlando Link: https://patch.msgid.link/20261011165821.72698-1-francesco.orlando99@libero.it Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 8073652f5c220dca8bc07c94268a5e15cce921a4 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 9d71a347dcee1652e15b8ff66e4652ae26a9a53e Author: Karl Mehltretter Date: Mon Sep 21 21:46:11 2026 +0100 ARM: 9523/1: topology: allocate the cacheinfo early on the boot CPU [ Upstream commit 2d4234f99900403842b2c031fefb4c5816ac4df8 ] ARM secondary CPUs allocate cacheinfo in detect_cache_attributes(), called from secondary_start_kernel() with interrupts disabled. With PREEMPT_RT, the allocation takes a sleeping lock and triggers "BUG: sleeping function called from invalid context". Call fetch_cache_info() for each possible CPU from init_cpu_topology() on the boot CPU, following commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU"). This supplies the arrays before secondary CPUs populate them. Suppress -ENOENT and -EOPNOTSUPP, which leave cache detection to the existing late path. The CLIDR fallback uses the boot CPU's cache geometry. A secondary CPU with more cache leaves can still require late reallocation and trigger the warning. Assisted-by: LLM Fixes: a9ff94477836 ("ARM: 9433/2: implement cacheinfo support") Cc: stable@vger.kernel.org Tested-by: Sebastian Andrzej Siewior Link: https://lore.kernel.org/r/20260912195552.76673-5-kmehltretter@gmail.com/ Signed-off-by: Karl Mehltretter Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 9c6cd241d67f942dc4cc50be6bb0fcedc8d7b90a Author: Karl Mehltretter Date: Mon Sep 21 21:45:20 2026 +0100 ARM: 9522/1: cacheinfo: guard the CLIDR read in populate_cache_leaves() [ Upstream commit 2315f2c46e0813d010e7b3ea40f2769621453e27 ] ARM1176 and ARM11 MPCore can be reported as ARMv7 by cpu_architecture() even though they lack CLIDR. populate_cache_leaves() therefore needs the CTR-format check used by detect_cache_level(). DT-based early allocation bypasses init_cache_level(), so its check no longer protects populate_cache_leaves(). A combined ARMv6/ARMv7 SMP kernel can reach this path on BCM2835, whose DT describes its caches. Share the CLIDR capability check between detection and population. Return -ENOENT from population when CLIDR is unavailable, preserving the existing absence of cacheinfo and avoiding a new topology warning. Assisted-by: LLM Cc: stable@vger.kernel.org Tested-by: Sebastian Andrzej Siewior Link: https://lore.kernel.org/r/20260912195552.76673-4-kmehltretter@gmail.com/ Signed-off-by: Karl Mehltretter Signed-off-by: Russell King Signed-off-by: Sasha Levin commit d75ac6be6915c38673bdb31f7e07913d742388a4 Author: Karl Mehltretter Date: Mon Sep 21 21:44:33 2026 +0100 ARM: 9521/1: cacheinfo: count external caches in early_cache_level() [ Upstream commit 4fd69e8a9ebc42e292637ec2ebfb6bcf2d2f6c0e ] early_cache_level() counts only caches described by CLIDR. An external PL310 is absent from CLIDR, and its arm,pl310-cache compatible is not accepted by init_of_cache_level(), so early allocation falls back to an incomplete count. init_cache_level() later adds the DT-described L2, forcing reallocation on the secondary CPU with interrupts disabled. This defeats early allocation on PREEMPT_RT. Use init_cache_level() for early sizing too, so the initial allocation includes external caches described by the device tree. Assisted-by: LLM Cc: stable@vger.kernel.org Tested-by: Sebastian Andrzej Siewior Link: https://lore.kernel.org/r/20260912195552.76673-3-kmehltretter@gmail.com/ Signed-off-by: Karl Mehltretter Signed-off-by: Russell King Signed-off-by: Sasha Levin commit e9eb621dc62b51f33539cb70c23ffd495e0eec8b Author: Karl Mehltretter Date: Mon Sep 21 21:36:28 2026 +0100 ARM: 9520/1: cacheinfo: avoid out-of-bounds write in populate_cache_leaves() [ Upstream commit 41a3f4bc3e4ae4722fd24743bf3f286cea14e3dc ] populate_cache_leaves() advances its bounds-checking index once per cache level, but split instruction/data caches consume two entries. CLIDR-based allocation supplies enough entries. Early allocation from the device tree can supply fewer and expose an out-of-bounds write. Count each written leaf and stop before a split level that does not fit. This prepares ARM for DT-based early allocation and matches commit 875d742cf532 ("arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array"). Assisted-by: LLM Fixes: a9ff94477836 ("ARM: 9433/2: implement cacheinfo support") Cc: stable@vger.kernel.org Tested-by: Sebastian Andrzej Siewior Link: https://lore.kernel.org/r/20260912195552.76673-2-kmehltretter@gmail.com/ Signed-off-by: Karl Mehltretter Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 06d167658ab538cfc9653fda92405b651e1c095c 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 014e83749f5e3e5f3419d666c5e0a4803376adb7 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 874ed54f09c608e0e1bb3704ab05cd60949c13d2 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 1927f66f8ca6fbf1ff06e7af1dd5098e2ae69e43 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 5819b86e062406c6c43041875cff6681a3a373fd Author: Matt Fleming Date: Tue Oct 13 13:19:44 2026 +0100 iommu/amd: Don't allocate kdump device table from DMA32 [ Upstream commit bae0d3760661ac77148944e88aafef698cf7b2bf ] Booting a kdump kernel with crashkernel=X,high crashkernel=0,low on an AMD system fails the per-segment device table allocation because there is no memory below 4G: swapper/0: page allocation failure: order:9, mode:0x40104(GFP_DMA32|__GFP_ZERO|__GFP_COMP) iommu_alloc_pages_node_sz+0x7f/0x150 alloc_pci_segment+0x4bd/0x650 iommu_go_to_state+0x213d/0x34e0 amd_iommu_prepare+0x39/0xa0 irq_remapping_prepare+0x83/0xd0 enable_IR_x2apic+0x61/0x370 On our E810 systems, the kdump kernel booted but ice MSI-X interrupts never fired and the TX queues timed out. Commit b336781b82cc ("iommu/amd: Allocate memory below 4G for dev table if translation pre-enabled") allocated device tables below 4G. At the time, the kdump kernel programmed a copy of the old table into the base register with the IOMMU still enabled. The 64-bit register is updated as two 32-bit halves, so the running IOMMU could see a half-written, invalid table pointer. Keeping both tables below 4G leaves the upper half zero throughout the update, so the pointer stays valid. Since commit 38e5f33ee359 ("iommu/amd: Reuse device table for kdump") the kdump kernel reuses the previous kernel's table without writing the base register, so its newly allocated table is discarded when reuse succeeds. If reuse fails, the previous patch programs the new table only after disabling the IOMMU. Either way, the kdump kernel's table doesn't need to be below 4G. The previous kernel still allocates its table from DMA32, so the kdump kernel's check that the old table is below 4G still works. Drop GFP_DMA32 for kdump kernels only. Cc: stable@vger.kernel.org # 6.18.x Reviewed-by: Ashish Kalra Reviewed-by: Ankit Soni Signed-off-by: Matt Fleming Reviewed-by: Vasant Hegde Signed-off-by: Matt Fleming Reviewed-by: Ashish Kalra Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit c043a0aa81253235141509e19c29d2fcfa270a6d Author: Matt Fleming Date: Tue Oct 13 13:19:43 2026 +0100 iommu/amd: Program device table when kdump reuse fails [ Upstream commit 05d62be400f3ae0f6856f6910a1281e67cbaabcf ] Commit 38e5f33ee359 ("iommu/amd: Reuse device table for kdump") made iommu_set_device_table() return early in every kdump kernel. That is needed when the previous kernel's device table is reused: the base register already points at it, and on SNP-enabled systems the register is locked. But if reuse isn't possible, early_enable_iommus() falls back to the freshly allocated table and calls early_enable_iommu(). Because of the early return, that table is never written to the base register. The IOMMU keeps using whatever table the register pointed at before, while the driver writes entries into the new one. Only skip the write when the previous kernel's table was reused. Fixes: 38e5f33ee359 ("iommu/amd: Reuse device table for kdump") Cc: stable@vger.kernel.org Reviewed-by: Ashish Kalra Reviewed-by: Ankit Soni Reviewed-by: Vasant Hegde Signed-off-by: Matt Fleming Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit f69cfb5188bf3a5e618ed83ba093452ace82e5f7 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 b0c1eed0e69dde2cdc5558c49cf58ac521ec6380 Author: Nicolai Buchwitz Date: Mon Oct 12 16:23:50 2026 +0200 serial: amba-pl011: keep transmitter enabled when disabling RS485 [ Upstream commit 97f85204275ae4d7fb530e451f3acc65c1ec1155 ] Disabling RS485 on an open port calls pl011_rs485_tx_stop(), which turns off the transmitter. Only the RS485 TX path turns it back on, so any later output stays queued and tcdrain() hangs until the port is closed. pl011_rs485_tx_stop() also checks only the hardware FIFO. If a DMA transfer has started but has not filled the FIFO yet, the transmitter is turned off under the transfer and the DMA channel never recovers. When leaving RS485 mode, cancel pending deferred starts and stops, leave the transmitter enabled and start any TX that was still waiting for delay_rts_before_send. Fixes: 8d479237727c ("serial: amba-pl011: add RS485 support") Cc: stable@kernel.org Signed-off-by: Nicolai Buchwitz Link: https://patch.msgid.link/20261012-fix-pl011-rs485-txe-v2-1-e9bf7d218389@tipi-net.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 57c22a5b141d9617e0fcd01a08c254df53ee35df Author: Nicolai Buchwitz Date: Sun Oct 11 22:23:44 2026 +0200 serial: amba-pl011: honour delay_rts_before_send for every write [ Upstream commit 8a9750209596be35d109de5aa89623b049855c67 ] While the driver waits out delay_rts_before_send, another write calls pl011_start_tx() again. pl011_rs485_tx_start() then switches straight to SEND, and the data goes out before the delay has passed. Leave the start to the trigger_start_tx timer while it is pending. Fixes: 2c1fd53af21b ("serial: amba-pl011: Fix RTS handling in RS485 mode") Cc: stable@vger.kernel.org Signed-off-by: Nicolai Buchwitz Link: https://patch.msgid.link/20261011-fix-pl011-rs485-rts-delay-v1-1-5078e61bc408@tipi-net.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0517d5fa233b15ff6c355ce5f47ec01b70906ec8 Author: Jiri Slaby (SUSE) Date: Tue Oct 13 08:48:50 2026 +0200 serial: 8250_omap: set priv->line before enabling the IRQ [ Upstream commit 8276a44f0a0b68c07b2331cc0058036ac4c4190d ] omap8250_irq() is requested in omap8250_probe() with IRQ_NOAUTOEN and enabled only in omap_8250_startup(). The handler obtains the port by serial8250_get_port(priv->line), but probe stores priv->line only after serial8250_register_8250_port() returns. The port becomes visible to userspace already inside serial8250_register_8250_port() (uart_add_one_port()). So it can be opened -- and the IRQ enabled -- before probe stores the line. An interrupt in that window makes the handler call serial8250_get_port(-ENODEV) and dereference a pointer outside of serial8250_ports[]. Store the line in omap_8250_startup() before enable_irq(), so the handler never runs with an unset line. Keep the assignment in probe too, as remove and the system PM callbacks rely on it even when the port was never opened. Fixes: fef4f600319e ("serial: 8250: omap: Fix life cycle issues for interrupt handlers") Signed-off-by: Jiri Slaby (SUSE) Assisted-by: LLM Cc: stable@vger.kernel.org Link: https://patch.msgid.link/3b3a642f7df2285f49a7bbbe5d1c23fa442c7d94.1791873876.git.jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fb0e78bacda6bd680db554b084b58970a69bfd2b 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 c04cd1d0818221f7ee35893fe5524865509b1103 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 b4b1bd4e0c1e73f8bb1185a871002b09107e771c 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 3da998f09826f59a21f75b1ab83ae72df4796074 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 341ec94586d093c44bb8fe1974ca8c259d6d651a 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 e7e97446125b7990055a60fe3584996f7579d75c 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 15e36dc9be7b6050045de4b44ab518f3eec8ad3d 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 149024365092678754e10d447494894aaa5c4d2d Author: Aaron Erhardt Date: Wed Oct 7 10:01:50 2026 +0200 platform/x86/tuxedo: Fix keyboard LED map ordering [ Upstream commit 5c9c54dfa28c9a47c9d81322d16585f9a64d4c69 ] The LED mappings in sirius_16_[iso|ansii]_kbl_map did contain a flipped line that caused LEDs to turn on in the wrong order when counting up the Lamp ID. Fixes: cfd84b3f419b ("platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices") Cc: stable@vger.kernel.org Reviewed-by: Werner Sembach Signed-off-by: Aaron Erhardt Link: https://patch.msgid.link/20261007080202.81694-5-aer@tuxedocomputers.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 3648e9257696c8af3b4421c3d3496f5f63053e0e Author: Gergo Koteles Date: Tue Oct 13 15:02:21 2026 +0200 ALSA: hda/tas2781: Skip invalid TAS2563 UEFI calibration data [ Upstream commit a0f0325e92e505db6a6879d79da5aa88e94a36ab ] Some Lenovo 14ARB7 laptops do not have proper calibration data. Skip these zero calibration values and fall back to the calibration data provided by the DSP firmware. Tested-by: Georg Wenzel Fixes: c3ca4458cc2f ("ALSA: hda/tas2781: add TAS2563 support for 14ARB7") Cc: stable@vger.kernel.org # 6.18 Signed-off-by: Gergo Koteles Tested-by: Philipp Oster Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/12a1ab265a1dc0e3a062a54287c8ef48682c4efc.1791895478.git.soyer@irl.hu Signed-off-by: Sasha Levin commit 075a08d5160c13571160c56aebaffb0a8ece7f36 Author: Kazuki Hanai Date: Fri Oct 2 17:13:03 2026 +0900 tmpfs: fix unicode_map leaks in casefold option handling [ Upstream commit f439d79e8cd19f89e04cbb3b532347edacd72c79 ] shmem_parse_opt_casefold() stores the unicode_map returned by utf8_load() in ctx->encoding. A filesystem context can receive the casefold parameter more than once, and a second successful parse overwrites the stored map without releasing it. The map is also leaked when an unmounted filesystem context is freed. This includes the temporary context used for remount, because shmem_reconfigure() does not take ownership of ctx->encoding. Reject a second casefold setting, clear ctx->encoding after transferring ownership to the superblock, and release any remaining map from shmem_free_fc(). An unprivileged user can repeatedly create tmpfs filesystem contexts, set the casefold parameter, and close them from a user namespace. This causes unbounded kernel memory consumption and can result in a local denial of service. Link: https://lore.kernel.org/20261002081306.637148-1-hnkz.64@gmail.com Fixes: 58e55efd6c72 ("tmpfs: Add casefold lookup support") Signed-off-by: Kazuki Hanai Signed-off-by: Andrew Morton Suggested-by: Gabriel Krisman Bertazi Cc: Hugh Dickins Cc: Baolin Wang Cc: André Almeida Cc: Christian Brauner Cc: Signed-off-by: Sasha Levin commit 664ef42230020ddb24cf6e4e791de9e70119ca17 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 0c30c5acdfd98ae3741c1d5daf26abb6ea504f13 Author: Bradley Morgan Date: Wed Sep 16 18:29:53 2026 +0000 panic: flatten nmi_panic control flow [ Upstream commit 75eb687ff2bcec9fba31bbe266e5f91e5c283efe ] panic() is __noreturn, so the else after panic_try_start() is dead. Drop it so the force_cpu path can be added cleanly on top. Link: https://lore.kernel.org/20260916182957.7788-3-brads@mainlining.org Signed-off-by: Bradley Morgan Signed-off-by: Andrew Morton Reviewed-by: Petr Mladek Cc: Guenetr Roeck Cc: Sashiko Cc: Wang Jinchao Cc: Wim Van Sebroeck Cc: Signed-off-by: Sasha Levin commit da262f1e8a4dce4edebc00ca72523d8dea2ed630 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 58e931c3b18e73fb98d8a53187cb7fb907d46d59 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 91ff04f52138627b9bf0b8d402e810003ce4221b 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 3c50eeaf05d5065b0970c1db0c1862a987a6445a 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 5e93214d8ccbf8fd0e955faf4f4070df1f4175e8 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 16cb21f3f99296c2c93da11158d2c6a3577ba370 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 7f050459206298020b028243ce3caef3ed9949b6 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 eb87db3cdf260f1fd7a420d2cf428ca3d2fde610 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 eb9b8c03d260aa76aa868bf9a46ebdc0f6f1efc4 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 d16d2bb0141cd141321ef559024812b5e665b2b8 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 35acdbaaddd2e69882edea445122e484b59a2c1e 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 6a590ce873e056d34cb658b6fb5739408937b104 Author: Geraldo Nascimento Date: Tue Jun 16 12:26:10 2026 -0300 PCI: rockchip: Drive at 2.5 GT/s, error other speeds [ Upstream commit 84d08ff902f1ec01177fef1a21a38934927f5aee ] Configure the core to be driven at 2.5 GT/s Link Speed and ignore any other speed with a warning. Also drop the 5.0 GT/s Link Speed defines from Rockchip PCIe header. The reason is that Shawn Lin from Rockchip has reiterated that there may be danger of "catastrophic failure" in using their PCIe with 5.0 GT/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: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver") 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/7421df7a7b7778ee99363cccfdfabbfa8aa6ab5e.1781622998.git.geraldogabriel@gmail.com Signed-off-by: Sasha Levin commit 2e7f6ad5e0c241c0bd0783074c75d3d722f30e90 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 611201814601677f2743f94dc143e1777c256305 Author: Geraldo Nascimento Date: Tue Jun 16 12:25:28 2026 -0300 PCI: rockchip-ep: Do not attempt 5.0 GT/s retraining [ Upstream commit 7f173bfa6d42742de4ab647e001232c1165ab28e ] Drop the 5.0 GT/s Link Speed retraining code block from Rockchip PCIe EP 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.0 GT/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: bd6e61df4b2e ("PCI: rockchip-ep: Improve link training") 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/d994f8fb3481bbb8f3972f117334a6e8aea383fb.1781622998.git.geraldogabriel@gmail.com Signed-off-by: Sasha Levin commit 1f49d6a95e9599430c69efeaaae55f746f1b89d3 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 124db30f332f644e900cc9d92a9fb4293d63d4f7 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 88d7fce496e65b6904daa7286c42a735fc7765d8 Author: Yehyeong Lee Date: Tue Oct 13 19:28:12 2026 +0900 nvme: bound FDP config log reads to the received buffer [ Upstream commit 3cf6de080d97d0d9641fbdb613d546c0734905dd ] nvme_query_fdp_granularity() parses the FDP Configurations log using sizes the controller returns, without checking that they fit the buffer it was given. The log size is only bounded from above before kvmalloc(), so a size below the log header makes le16_to_cpu(h->numfdpc) read past the allocation, and a size of zero yields ZERO_SIZE_PTR and faults. Each configuration descriptor is then dereferenced (dsze while walking, and nrg and runs on the selected one) without checking that the whole descriptor lies within the buffer, so a descriptor at or past the end is read out of bounds. The out-of-bounds runs value is then exposed to userspace through /sys/block/nvmeXnY/queue/write_stream_granularity. A device-supplied dsze that is not a multiple of eight also leaves the following descriptors unaligned, and the structure is not packed, so reading nrg and runs from one can fault on architectures without efficient unaligned access. A malicious or buggy controller triggers this during namespace scan with a short FDP Configurations log: [ 1.104828] BUG: KASAN: slab-out-of-bounds in nvme_alloc_ns+0x39a6/0x4480 [ 1.104848] Read of size 8 at addr ffff888009fd8fe0 by task kworker/u8:3/52 [ 1.104852] [ 1.104857] CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 7.3.0-rc6-00063-g0c2669a9f4a1 #1 PREEMPT(lazy) [ 1.104862] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 1.104866] Workqueue: async async_run_entry_fn [ 1.104873] Call Trace: [ 1.104876] [ 1.104878] dump_stack_lvl+0x66/0xa0 [ 1.104886] print_report+0xd0/0x630 [ 1.104893] ? nvme_alloc_ns+0x39a6/0x4480 [ 1.104897] ? __virt_addr_valid+0x209/0x3f0 [ 1.104903] ? nvme_alloc_ns+0x39a6/0x4480 [ 1.104907] kasan_report+0xe4/0x120 [ 1.104913] ? nvme_alloc_ns+0x39a6/0x4480 [ 1.104919] nvme_alloc_ns+0x39a6/0x4480 [ 1.104926] ? __pfx_nvme_alloc_ns+0x10/0x10 [ 1.104931] ? check_prev_add+0xfd/0xe80 [ 1.104942] ? lock_acquire+0x18d/0x300 [ 1.104948] ? nvme_find_get_ns+0xbb/0x2e0 [ 1.104952] ? find_held_lock+0x2b/0x80 [ 1.104956] ? nvme_find_get_ns+0x221/0x2e0 [ 1.104962] ? nvme_find_get_ns+0x231/0x2e0 [ 1.104967] ? nvme_scan_ns+0x2e1/0x8d0 [ 1.104971] ? kfree+0x2e5/0x510 [ 1.104976] ? __lock_acquire+0x570/0x1b00 [ 1.104982] nvme_scan_ns+0x56a/0x8d0 [ 1.104987] ? __pfx_nvme_scan_ns+0x10/0x10 [ 1.104994] ? lockdep_hardirqs_on_prepare+0xdc/0x190 [ 1.104999] ? trace_hardirqs_on+0x18/0x160 [ 1.105005] ? kvm_clock_get_cycles+0x19/0x40 [ 1.105011] ? __pfx_nvme_scan_ns_async+0x10/0x10 [ 1.105015] async_run_entry_fn+0x8d/0x290 [ 1.105020] process_one_work+0x8ac/0x1b00 [ 1.105029] ? __pfx_process_one_work+0x10/0x10 [ 1.105034] ? lock_acquire+0x18d/0x300 [ 1.105040] ? lock_is_held_type+0x8f/0x100 [ 1.105046] ? __pfx_async_run_entry_fn+0x10/0x10 [ 1.105050] worker_thread+0x4ee/0xe70 [ 1.105056] ? lockdep_hardirqs_on_prepare+0xdc/0x190 [ 1.105061] ? trace_hardirqs_on+0x18/0x160 [ 1.105066] ? __pfx_worker_thread+0x10/0x10 [ 1.105071] ? __pfx_worker_thread+0x10/0x10 [ 1.105076] kthread+0x2ce/0x3b0 [ 1.105080] ? __pfx_kthread+0x10/0x10 [ 1.105085] ret_from_fork+0x52e/0x780 [ 1.105090] ? __pfx_ret_from_fork+0x10/0x10 [ 1.105094] ? __switch_to+0x572/0xde0 [ 1.105101] ? __pfx_kthread+0x10/0x10 [ 1.105105] ret_from_fork_asm+0x1a/0x30 [ 1.105114] [ 1.105116] [ 1.105117] Allocated by task 52: [ 1.105119] kasan_save_stack+0x33/0x60 [ 1.105123] kasan_save_track+0x14/0x30 [ 1.105126] __kasan_kmalloc+0x8f/0xa0 [ 1.105129] __kvmalloc_node_noprof+0x2e1/0x820 [ 1.105134] nvme_alloc_ns+0x1097/0x4480 [ 1.105138] nvme_scan_ns+0x56a/0x8d0 [ 1.105142] async_run_entry_fn+0x8d/0x290 [ 1.105145] process_one_work+0x8ac/0x1b00 [ 1.105148] worker_thread+0x4ee/0xe70 [ 1.105152] kthread+0x2ce/0x3b0 [ 1.105155] ret_from_fork+0x52e/0x780 [ 1.105159] ret_from_fork_asm+0x1a/0x30 [ 1.105163] [ 1.105164] The buggy address belongs to the object at ffff888009fd8fc0 [ 1.105164] which belongs to the cache kmalloc-32 of size 32 [ 1.105167] The buggy address is located 8 bytes to the right of [ 1.105167] allocated 24-byte region [ffff888009fd8fc0, ffff888009fd8fd8) [ 1.105171] [ 1.105172] The buggy address belongs to the physical page: [ 1.105175] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9fd8 [ 1.105179] flags: 0x100000000000000(node=0|zone=1) [ 1.105183] page_type: f5(slab) [ 1.105188] raw: 0100000000000000 ffff888008c41780 dead000000000100 dead000000000122 [ 1.105192] raw: 0000000000000000 0000000000400040 00000000f5000000 0000000000000000 [ 1.105194] page dumped because: kasan: bad access detected [ 1.105195] [ 1.105196] Memory state around the buggy address: [ 1.105198] ffff888009fd8e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 1.105201] ffff888009fd8f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 1.105203] >ffff888009fd8f80: fc fc fc fc fc fc fc fc 00 00 00 fc fc fc fc fc [ 1.105205] ^ [ 1.105207] ffff888009fd9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 1.105210] ffff888009fd9080: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00 [ 1.105212] ================================================================== Reject a log smaller than its header plus one configuration descriptor, zero the buffer so a short transfer leaves no uninitialized tail to parse, require each descriptor's declared size to be at least a descriptor and to leave room for the next one before walking it, and read the descriptor fields with the unaligned accessors. Fixes: 30b5f20bb2dda ("nvme: register fdp parameters with the block layer") Cc: stable@vger.kernel.org Suggested-by: Kanchan Joshi Reviewed-by: Christoph Hellwig Reviewed-by: Kanchan Joshi Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit b0c652a11e536da6eb133d365bb936b081b6b70f Author: Sung Byeongchan Date: Wed Oct 7 15:30:41 2026 +0900 nvmet: require authentication before property set [ Upstream commit 44512543ff0413031516a02cde67323a55e0f769 ] I/O queues do not perform independent DH-HMAC-CHAP authentication. They instead rely on authentication of the controller's admin queue. Fabrics property commands, however, are dispatched before the general admin command authentication check. An unauthenticated peer can consequently set CC.EN, connect an I/O queue, and access a namespace after admin CONNECT reported that authentication was required. Reject PROPERTY_SET until the admin queue has authenticated. Targets without a configured authentication key are unchanged. This was found by source review with AI assistance. A localhost NVMe/TCP wire reproducer retrieved a known 4 KiB namespace block in two independent boots without completing AUTH_SEND or AUTH_RECEIVE. With this change, PROPERTY_SET returned NVME_SC_AUTH_REQUIRED and the namespace data was not returned; the no-authentication control continued to work. Fixes: c91a20129185 ("nvmet-auth: authenticate on admin queue only") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Christoph Hellwig Signed-off-by: Sung Byeongchan Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit ef062530729f0ddc738ac60a7966567836573e67 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 81b9f59167067b5fbb4f2ae65498194085bbffe3 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 7a4ee76f0e8f47f5eee3f63d8a3ed20f5c672e6a Author: Daejun Park Date: Fri Oct 2 16:03:41 2026 +0900 nvmet: fix preempt of another registrant by the reservation holder [ Upstream commit d9e84d4e19994818b80846bd2abb7b396e4116a9 ] Unless the reservation is of an All Registrants type, nvmet_pr_preempt() treats every Reservation Acquire command with the Preempt or Preempt and Abort action that is sent by the reservation holder as the holder preempting itself. It updates the reservation type to RTYPE and completes the command successfully without looking at PRKEY. NVMe Base Specification 2.1, section 8.1.22.7 makes the action depend on PRKEY for these reservation types, no matter which registrant sends the command: - PRKEY matches the key of the reservation holder: the reservation is preempted. This is how a holder preempts itself. - PRKEY does not match the key of the holder and is not 0h: the registrants whose key matches PRKEY are unregistered. - PRKEY does not match the key of the holder and is 0h: the command is aborted with Invalid Field in Command. With the current code, a holder that preempts with the key of another registrant leaves that registrant registered, changes the reservation type to RTYPE and still gets a successful completion. With hosts A, B and C registered with the keys 0xa, 0xb and 0xc, and A holding an Exclusive Access - Registrants Only reservation, A sends: # nvme resv-acquire /dev/nvme1 -n 1 --crkey=0xa --prkey=0xb \ --rtype=4 --racqa=1 NVME Reservation Acquire success # nvme resv-report /dev/nvme1 -n 1 --eds | grep '^regctl ' regctl : 3 and B can still write to the namespace. Preempt and Abort (--racqa=2) gives the same result. When C sends the preempt instead (--crkey=0xc), B is unregistered and its writes fail with Reservation Conflict. This defeats fencing in the pNFS SCSI layout server. nfsd holds the reservation and fences a client that does not return its layout by calling pr_preempt() with the key of that client and the abort flag, which is the command RFC 9561 section 2.2.3 asks for. On an nvmet namespace the preempt succeeds, nfsd logs the client as fenced, and the client keeps writing to the device. In a test with an nfsd server and two clients on an nvmet-tcp namespace, the namespace still had three registrants after the fence and the fenced client went on writing to it. With this patch two registrants are left and the writes of the fenced client fail with a reservation conflict. Take the self preempt path only when PRKEY is the key of the holder. Any other PRKEY sent by the holder is then handled by the code that already serves a non-holder registrant, for Preempt and for Preempt and Abort. For a host that holds the reservation this changes the following: - A preempt with the key of another registrant unregisters the registrants with that key, sends them the registration preempted notification and leaves the reservation type alone. - A preempt with PRKEY 0h fails with Invalid Field in Command. A holder that changed its reservation type this way has to pass its own key in PRKEY, which works with and without this patch. - A preempt with a PRKEY that matches no registrant fails with Reservation Conflict. The specification defines that status only for the All Registrants types. It is what nvmet already returns to a non-holder registrant in this case and what the SCSI target returns for an unregistered key. nfsd treats it as a successful fence. Not changed: when the holder preempts itself, registrants that share its key stay registered. Fixes: 5a47c2080a73 ("nvmet: support reservation feature") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Daejun Park Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 5564d7a654a7be040d7dd55fd9dd20dd4e0beab2 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 d6c4a5d2cc6ad695bdc89ce6ac028eac17484b9a 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 d8e8a00721a21b2022dedc63afb68beddca71bee 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 deea3afb1aca21300a1701aa8950f3bee8eb7412 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 29d810702de082a48d7afebd86c87d9a15b41ff1 Author: Aamir Ahmed Date: Sat Sep 12 14:09:06 2026 +0100 clk: qcom: ipq-cmn-pll: Assign .num before accessing .hws [ Upstream commit 231bbd135772390522be3656b34b49ea3039eccf ] hw_data->hws[] is annotated with __counted_by(num), so hw_data->num must hold the element count before the array is accessed. ipq_cmn_pll_register_clks() assigns it only after storing the fixed rate output clocks and the CMN PLL, and the unwind loop under unregister_fixed_clk reads .hws[] with .num still zero. Both are out-of-bounds accesses under CONFIG_UBSAN_BOUNDS. Move the assignment to right after the allocation. Fixes: f81715a4c87c ("clk: qcom: Add CMN PLL clock controller driver for IPQ SoC") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Aamir Ahmed Reviewed-by: Luo Jie Reviewed-by: Konrad Dybcio Reviewed-by: Gustavo A. R. Silva Reviewed-by: Abel Vesa Link: https://patch.msgid.link/AS8P251MB000187BDFAD98A21F4C356E9C8BD2@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1a40cbb9d83ad8c669125554fcd73e626a00dc65 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 4180ff5884387adc5a68d582b7808ea4ebf92af8 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 ac188323d33332db8e4aedd123a0383dda9c25b7 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 0f39d51bd5f3d4d9cabd95578a998841ba6ca013 Author: Mikulas Patocka Date: Mon Oct 12 16:07:58 2026 +0200 dm-bufio: fix non-working memory limit [ Upstream commit 1190dbeaeaa026a4879e675b8556a150c36a7ced ] The function evict_old is supposed to loop and evict buffers while the allocated size is above the threshold. However if it hits one bufio client that is empty, it stops and doesn't attempt to scan other clients. This commit fixes it, so that it skips empty clients and retries up to dm_bufio_client_count times. 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 55265c0f41ebe877b00b09a3d0cda796e6737e03 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 df083198ddca2fd4f4214c0cc1bd51ed08fe6f52 Author: Myeonghun Pak Date: Mon Sep 14 20:52:43 2026 -0400 fbdev: kyro: Release WC setup on registration failure [ Upstream commit d3bc005a62945aec57059201092b12b7c955e5a7 ] If register_framebuffer() fails, kyrofb_probe() frees the framebuffer without releasing its write-combining range. Release the range before freeing the framebuffer. Earlier failures still skip this cleanup. The missing cleanup already exists in the initial Git import, before the conversion from mtrr_add() to arch_phys_wc_add(). This issue was identified during our ongoing static-analysis research while reviewing kernel code. 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: Helge Deller Signed-off-by: Sasha Levin commit 8e21bbb7c2ce772ea3d672c1de662c5da1e9fbeb 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 db62efc3ecbd4447d90714a8c613955206179b33 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 b4165e730e7807b90fd1b0e847f7fb826c674027 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 99059dc7ee7bd0f4d9a695a7404e80efac5fdde3 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 51d8437aff718696241a8ba7aaa67a2d0bab2a38 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 2e4f453c3c191a376c1e026224f4f402ff0d4af5 Author: David E. Box Date: Thu Oct 1 15:03:47 2026 -0700 platform/x86/intel/vsec: Fix inverted walk_header() test in get_features() [ Upstream commit 3678e39c6aaeb9aa380c7357b24f7d55955543f8 ] intel_vsec_walk_header() used to return a bool that was true when devices were found. It was converted to return 0 on success and a negative errno on failure, but the boolean test in intel_vsec_get_features() was left unchanged, so its meaning is now inverted. A successful walk returns 0 and leaves found set to false, while a failed walk returns an error that evaluates to true. When no other capabilities are present, intel_vsec_pci_init() then returns -ENODEV even though the auxiliary devices were created, and the driver core tears them back down. This affects platforms that have no DVSEC or VSEC capabilities and describe their features through device_data instead, which today means DG1. Test the return value for success explicitly. Fixes: a6ce8bf3c993 ("platform/x86/intel/vsec: Return real error codes from registration path") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: David E. Box Reviewed-by: Michael J. Ruhl Link: https://patch.msgid.link/20261001220351.1592138-3-david.e.box@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 74eee7cc1aea34e31316f133da4daff05cdd82ae 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 70ef07bf84276694597697c17d439c945084fe61 Author: Mario Limonciello Date: Mon Sep 21 12:04:10 2026 -0500 platform/x86/amd: hfi: Fix out-of-bounds reads when parsing ranking data [ Upstream commit b7b273844b94af9cc64907dccd9e7997c2b60f1a ] amd_hfi_fill_metadata() parses CPU core ranking data out of the firmware-provided PCC shared memory but trusts two values it should not: - n_bitmaps is used to bound the outer loop that reads the APIC ID bitmaps from table_data[], but it is never validated against the size of the shared memory region (pcct_ext->length). A firmware-supplied count larger than the region reads past the end of table_data. - When resolving the base of the ranking data for a processor, the pointer is shifted by an extra "i * nr_class" term, where i is the current bitmap index. The per-processor offset is already applied through apic_index, which uses the running count of active processors (apic_start). The extra shift compounds for every logical processor beyond the first bitmap (APIC ID >= 32), reading out of bounds. Both result in out-of-bounds reads that can corrupt the ranking metrics, oops, or otherwise destabilise the system. Reject an n_bitmaps value that would not fit within the shared memory region, and drop the bogus "i * nr_class" term so the ranking data is addressed only through its correct per-processor offset. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: d4e95ea7a78e ("platform/x86: hfi: Parse CPU core ranking data from shared memory") Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260921170411.1149960-3-mario.limonciello@amd.com Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 4a5b0194b8d8c462e89d286728368f67f4b89ed5 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 5d82777974b152a30d6df63d980cdef90bd6f006 Author: Antheas Kapenekakis Date: Sun Sep 20 21:04:37 2026 +0200 platform/x86: oxpec: Fix Apex charge limit control [ Upstream commit 0ccdf9a1381c7fb6d9e84abeb8e5d6c85dd07059 ] The OneXPlayer Apex uses E5/E6 for battery bypass / charge limit, making it the first device to deviate. This was verified by a user on Windows with BIOS version 2.17 and later by running this kernel patch. Drop X1_ from the MASK variables as they are common in all devices, introduce a board enum for Apex, and make it use the new E5/E6 registers for charge limit / bypass. Apply the same quirks as oxp_fly, since APEX uses the same registers otherwise. Fixes: 3385ea97c14d ("platform/x86: oxpec: Add support for OneXPlayer APEX") Cc: stable@vger.kernel.org Signed-off-by: Antheas Kapenekakis Reviewed-by: Derek J. Clark Link: https://patch.msgid.link/20260920190438.3444923-1-lkml@antheas.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 3857d41c7d4db8ad2a6891e3a88ba6e8ef56e075 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 d904db0a4d32bd49cff2476bf11cf0715c444804 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 b34024fae1d6f6dfaf9812adbe8967082c793c51 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 16114eb40778eb308238d23a2edc215d110d84b1 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 4b003a2ab67752f69bf23184dd3e4b92599fe51e 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 d43e5fc381a9ced73692f754376329df20831412 Author: Mario Limonciello Date: Mon Sep 14 09:17:32 2026 -0500 platform/x86/amd: Stop counting intermediate cycles with metrics table [ Upstream commit 0c2c928ea7d33c8131b0785bda4e26a32dce5caa ] The metrics table doesn't increment for all cases that can cause an intermediate wakeup if the cycle is very fast. This can make the intent from commit 9f5595d5f03fd ("platform/x86/amd: pmc: Require at least 2.5 seconds between HW sleep cycles") not work properly. That commit originally was measured to work properly, but it was accidental due to a logic error. The logic error was fixed in commit 4dbd11796f3a8 ("platform/x86/amd: pmc: Clear metrics table at start of cycle") but this now masked the table doesn't always update. Since that code was introduced, Daniel Gibson added a number of changes to the logic which includes a state variable introduced in commit 037f0b03c663a ("platform/x86/amd/pmc: Don't log during intermediate wakeups"). Utilize that state variable to instead decide if a single sequence has started. Cc: Daniel Gibson Cc: stable@vger.kernel.org # 7.1.y: 037f0b03c663a platform/x86/amd/pmc: Don't log during intermediate wakeups Cc: stable@vger.kernel.org # 6.18.y: 037f0b03c663a platform/x86/amd/pmc: Don't log during intermediate wakeups Fixes: 4dbd11796f3a8 ("platform/x86/amd: pmc: Clear metrics table at start of cycle") Signed-off-by: Mario Limonciello Tested-by: Chia-Lin Kao (AceLan) Link: https://patch.msgid.link/20260914141734.2703545-1-mario.limonciello@amd.com Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 0beb6ba8c6b5b50be88a037392eb4693dd6e44ba 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 42d4192fa904579a94a8172522938c441832e72c 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 528d332bb864a38fa3547a54c66a4c65fe13c054 Author: Hao Ge Date: Wed Sep 16 15:55:57 2026 +0800 mm/alloc_tag: account for reserved tag ids in the kernel tag check [ Upstream commit c6e5c0b9a493891634d0a413c3485930a28a8903 ] The tag ids stored in the page flags include two reserved markers. Id 0 means the page has no tag and id 1 means the tag was cleared, so real tags start at CODETAG_ID_FIRST. The kernel-side check in alloc_tag_sec_init() compared kernel_tags.count alone against the addressable limit, so with the count at or just under the limit the last tag ids wrapped into those markers. Pages allocated through them then look the same as untagged pages on free, nothing is ever subtracted from the real tag and /proc/allocinfo shows that memory as still allocated. Add the missing CODETAG_ID_FIRST, same as tags_addressable(). Link: https://lore.kernel.org/20260916075557.121316-1-hao.ge@linux.dev Fixes: 4835f747d3ed ("alloc_tag: support for page allocation tag compression") Signed-off-by: Hao Ge Signed-off-by: Andrew Morton Acked-by: Suren Baghdasaryan Cc: Signed-off-by: Sasha Levin commit b5b95b5176045583130799e05cdd6d00735536e9 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 08ff60709252d894d6ccb406d839cfdf09998062 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 42dd1e6f1b0902154dda0829c7d388570c46af23 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 a4bd35798a34248b6d14508f0a00d7e4d990908e 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 45555f91acf8a09b630229396aade62cdd1c4537 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 06eebc180008290a042403e66fff2e80542c99a0 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 ebc5521bed8878628998c2ca89d0a5d145bd9512 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 a1aaab4ae87a7584f9b66f2fae5bc294e13062c8 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 85eaf47588492bc75206b27b0c679610e49d2a81 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 aa7065b8c699d6607abd35115687750f30321647 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 d05766991f871d94dd15ec912fd703d09015b9a0 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 caacd77e93d925e2f72d676dc0c563cb822a20b5 Author: Gabor Juhos Date: Mon Sep 28 09:01:53 2026 +0200 mtd: rawnand: qcom: fix read location register usage in config_nand_cw_read() [ Upstream commit 94623942a66e031826756f9c92dbde9a12e2b4d2 ] On QPIC v2 controllers, when the last codeword is being read, the read location values must be programmed into the READ_LOCATION_LAST_CW_* registers. Prior to commit 8c52932da5e6 ("mtd: rawnand: qcom: cleanup qcom_nandc driver"), the config_nand_cw_read() function did it right, but since then it always writes the read location values to the READ_LOCATION_* registers even if the actual codeword is the last one. Change the function to always configure the registers corresponding to the actual codeword to restore the correct behaviour. Cc: stable@vger.kernel.org Fixes: 8c52932da5e6 ("mtd: rawnand: qcom: cleanup qcom_nandc driver") Signed-off-by: Gabor Juhos Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit acc0ad90eefb7056198748b0be3b292a1d8da4b6 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 3c61ac2bec9c92c9114a03c9e76412ed0e750655 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 36e0970b8217d9b1aba6e773070624e337f595af 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 6b84be6acf4a1e0bc33bbe13faa36ac768e7e1e2 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 f5a35fc0dcac6d30aa84fce73b343369e3d7753f 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 f1f969a1903573128ef2cad84cbcaa8e1fed5c96 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 35ee206bdab6cb32e69798da9a29a68bceb1d593 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 9db206e80d084988ff5c58ebd74a26b98335fc85 Author: Florian Fainelli Date: Tue Aug 25 12:16:19 2026 -0700 mailbox: bcm74110: Cap rx_svc_init_list growth to prevent PMC-induced OOM [ Upstream commit eb2ee504757674450a5e03e36e6b9340f064e599 ] bcm74110_rx_push_init_msg() allocates a GFP_ATOMIC struct for every BCM_MSG_SVC_INIT word received from the PMC co-processor and appends it to rx_svc_init_list with no cap on list length. The only consumers of this list (bcm74110_rx_pop_init_msg_block / bcm74110_rx_flush_msg) are called only during probe and at shutdown respectively; after probe completes, PMC firmware can continuously inject BCM_MSG_SVC_INIT words, exhausting GFP_ATOMIC reserves and causing a whole-device denial of service. Add BCM74110_INIT_MSG_MAX (16 entries) as the maximum list depth. bcm74110_rx_push_init_msg() now checks the count under the existing rx_svc_list_lock before allocating; if the cap is reached the message is dropped and a rate-limited warning is emitted. The new rx_svc_init_count field is decremented by bcm74110_rx_pop_init_msg() on successful dequeue and reset to zero by bcm74110_rx_flush_msg() on shutdown. Fixes: 52436007b862 ("mailbox: Add support for bcm74110") Cc: stable@vger.kernel.org Signed-off-by: Florian Fainelli Assisted-by: Anthropic:claude-sonnet-4.6 cursor Signed-off-by: Danesh Petigara Acked-by: Justin Chen Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit e763f0231776056e5c11973ab3923fca0441564d Author: Runyu Xiao Date: Fri Sep 4 14:19:39 2026 +0800 mailbox: altera: shut down RX polling timer on channel teardown [ Upstream commit 0cf10e65639cba32d05994f85e6a8f08dd0ffe08 ] The RX polling callback unconditionally rearms the timer after it processes mailbox data. altera_mbox_shutdown() uses timer_delete_sync(), which waits for a running callback but does not prevent that callback from rearming the timer after the deletion. Use timer_shutdown_sync() for the final polling teardown so the timer cannot be queued again while the mailbox channel is being released. The timer is reinitialized with timer_setup() on a later channel startup, so polling mode remains reusable. Fixes: f62092f6d77d ("mailbox: Add Altera mailbox driver") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit dfe2627f25b1f0785a5e0eb11a28ea75842cb8c1 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 857ba63871a010cd62a3a90ff3d6d401dc769ea4 Author: Mathias Nyman Date: Fri Oct 9 18:16:24 2026 +0300 xhci: Prevent invalid vdev dereference during sideband unregister [ Upstream commit fd616dc74e8f58f351f2b295620027116cd6e92e ] Offloaded USB audio devices using the xhci-sideband API store a pointer to the xhci virtual device (vdev) in the sideband structure when registering. This pointer typically remains valid throughout the lifetime of the USB device. If a configured offloaded device requires a reset, the USB core usually unbinds or notifies the audio driver beforehand, ensuring that the sideband is unregistered before the vdev is freed. An exception occurs when the USB core resets a device to recover from a failed resume, but a subsequent 'address device' request also fails. To recover in this specific scenario, the xHCI driver disables and re-enables the slot, which frees and re-allocates the vdev. xhci_sideband_unregister() later dereferences the stale, previously freed vdev pointer during disconnect, triggering a kernel oops: Unable to handle kernel paging request at virtual address dead000000000122 Call trace: xhci_get_ep_ctx+0x0/0x38 xhci_sideband_unregister+0x68/0xf0 uaudio_disconnect+0x70/0x144 usb_audio_disconnect+0x7c/0x268 usb_unbind_interface+0x13c/0x340 device_release_driver_internal+0x1c4/0x2bc usb_disable_device+0x84/0x190 usb_disconnect+0xe8/0x338 hub_event+0xbd8/0x19ac Fix this by preventing the reallocation of the vdev in this specific error path if the device is registered for sideband use. Just propagate the error directly to the USB core. It should either retry enumeration or detect the disconnected device, and handle it accordingly. Debugging this issue to the dangling vdev pointer, reporting it, testing, and initial patch with different solution by Lianqin Hu Reported-by: Lianqin Hu Closes: https://lore.kernel.org/linux-usb/TYUPR06MB6217000B59003EDF233D7246D2B22@TYUPR06MB6217.apcprd06.prod.outlook.com/ Tested-by: Lianqin Hu Fixes: de66754e9f80 ("xhci: sideband: add initial api to register a secondary interrupter entity") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20261009151624.618967-12-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d0d15d7a11f2a45e5d29ab4780a094992d7a26a2 Author: Michal Pecio Date: Fri Oct 9 18:16:23 2026 +0300 usb: xhci: Fix bounce buffer overflow [ Upstream commit 68c5cb7574c567e83ba95258cb146db95e069a87 ] High-speed devices with out of spec 1024 byte bulk endpoints exist and are allowed by USB core, but xhci-hcd always sets packet size to 512. The exact nature of these devices isn't documented, commit fb5ee84ea72c ("USB: Accept bulk endpoints with 1024-byte maxpacket") only states that they "don't work with xHCI host controllers", whatever it means. But somebody (or a malicious device) can try, and then the driver will allocate a 512 byte bounce buffer for this endpoint and may write up to 1024 bytes into it if particular scatter-gather URBs are used, because xhci_align_td() obtains packet size from the descriptor. Fix this. As a side effect, TRBs will be aligned to the packet size chosen by the driver on all endpoints of all speeds. Alignment serves the xHC, not device, so this is fine. Only out of spec devices are affected anyway. Reported-by: co+fd80bc5967eb22c3@bugs.sh Link: https://lore.kernel.org/linux-usb/D4tcSGerkYkIV1DmaUo1t8TaR5qQElDLkidn@bugs.sh/ Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer") Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20261009151624.618967-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5d254d1e59da5b4bb05025924220faabb255b48f Author: Seungjin Bae Date: Sat Oct 3 17:55:20 2026 -0400 usb: typec: ucsi: ccg: Validate altmode index in GET_CURRENT_CAM response [ Upstream commit 02ee864e8d2142c5648998944c3306ea6a763c26 ] When the PPM reports more than one DisplayPort alternate mode for a connector, ucsi_ccg_update_altmodes() merges them into a single entry in uc->updated[] and sets uc->has_multiple_dp. In that case, ucsi_ccg_update_get_current_cam_cmd() rewrites the response of the GET_CURRENT_CAM command. The response is a single byte holding the index of the currently active alternate mode, and it is provided by the PPM firmware. The function uses this byte directly as an index into uc->orig[], and then uses the linked_idx read from that entry as the translated index into uc->updated[]. Both arrays have UCSI_MAX_ALTMODES entries, but neither index is checked against that size. If a malicious or buggy PPM reports a value of UCSI_MAX_ALTMODES or larger, e.g. 0xFF, uc->orig[cam].linked_idx reads over the end of uc->orig[]. The byte read from there is then used as the index for writing cam into uc->updated[new_cam].active_idx, so the out-of-bounds read is followed by an out-of-bounds write. This happens without any userspace action, since the UCSI core issues GET_CURRENT_CAM on its own when handling connector changes. Fix this by rejecting responses whose index is out of range, printing an error and returning -EPROTO, so that the caller cannot accept this. Also check linked_idx before using it as an index, so that the write into uc->updated[] is always within bounds. The response is now only processed when the command completed without an error. ucsi_sync_control_common() only reads the response when the CCI reports command completion, so otherwise the buffer is not filled and must not be mistaken for an invalid index. This bug was found with a Python script that traces where firmware input is used. Fixes: 170a6726d0e2 ("usb: typec: ucsi: add support for separate DP altmode devices") Cc: stable Reported-by: Nathan Rebello Assisted-by: LLM Signed-off-by: Seungjin Bae Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20261003215520.611083-2-eeodqql09@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a0234e0c052c32c22b7d5ecd6376c968d80cca9f Author: Ali Resool Tuama Date: Fri Oct 2 20:42:12 2026 +0300 USB: quirks: add USB_QUIRK_WINDOWS_CONFIG_REQ_SIZE for GameSir G7 SE [ Upstream commit 40224df29729618ecd88c5c0077e71b1e82c7a3a ] The GameSir G7 SE wired controller first enumerates as 3537:10a0 and then re-enumerates in a mode it picks from how the host enumerated it. When the configuration descriptor is fetched the Linux way, 9 bytes followed by the full 80, the controller disconnects about 1 ms after its string descriptors have been read, before SET_CONFIGURATION, and comes back as 3537:1082, a generic HID gamepad without force feedback. When the configuration descriptor is fetched in one 255-byte request, as Windows does, it comes back as 3537:1010 in Xbox One (GIP) mode, which xpad already supports, including rumble. Skipping the device qualifier requests (USB_QUIRK_DEVICE_QUALIFIER) makes no difference; the configuration descriptor request size alone decides the mode. Add USB_QUIRK_WINDOWS_CONFIG_REQ_SIZE for the 10a0 identity, as is already done for the ShanWan Wireless Gamepad. Cc: stable Assisted-by: claude-opus-5-5 Signed-off-by: Ali Resool Tuama Link: https://patch.msgid.link/20261002-master-v2-1-24b05d8792b5@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d585cf76296c9cb0a1ba7b2a1983f9a21927cac1 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 6c3de683d73d721568f82ea7a839c6ddcf2210a3 Author: Adam Harshbarger Date: Thu Sep 3 17:24:56 2026 -0500 lib/plist: fix plist_requeue() corrupting order in the last bucket [ Upstream commit 43c91b1522435429a63d175f5a953e6f727a4f88 ] plist_requeue() is meant to move a node to the end of its own priority run. When the node heads the *last* priority bucket it is instead placed at the head of the whole list, leaving the plist unsorted: built: A(prio 0) B(prio 1) C(prio 1) requeue(B): B(prio 1) A(prio 0) C(prio 1) expected: A(prio 0) C(prio 1) B(prio 1) prio_list is a *headless* circular ring of the nodes that lead each priority bucket. The shortcut added by commit 95d4b3450ebe ("lib/plist.c: add shortcut for plist_requeue()") takes iter = list_entry(iter->prio_list.next, struct plist_node, prio_list); node_next = &iter->node_list; which from the last bucket wraps round to the *first* bucket, so node_next ends up pointing at the head of the list rather than at its end. The plist_for_each_continue() loop immediately below it computes the correct answer (&head->node_list) for that case. With any bucket after it the shortcut is correct, which is why this went unnoticed: the benchmark in that commit measured elapsed time and never checked the resulting order. Keep the shortcut -- it is a real win -- but exclude the case where iter's bucket is the last one, which is exactly when its ring successor is the first bucket again. Reachable from mm/swapfile.c, which rotates swap_avail_heads[] with plist_requeue(). It takes three or more swap devices: at least two distinct priorities, so that a later bucket exists for the ring to wrap round from, and two or more devices sharing the lowest priority, so that plist_requeue() does not return early. One device per priority returns early at the node->prio != iter->prio test. A single priority is also safe, but for a different reason worth stating: with one bucket no node is ever linked onto prio_list at all -- plist_add() skips it for the first node and for every node whose predecessor shares its priority -- so list_empty(&iter->prio_list) holds and the shortcut is never entered. Tested by driving three implementations -- the pre-95d4b3450ebe code, current mainline, and this patch -- through 1,084,492 identical random add/del/requeue operations over 24 nodes and 1..5 distinct priorities, comparing the resulting node_list node for node after every operation: variant differs from pre-95d4b3450ebe left list unsorted pre-95d4b3450ebe -- (reference) 0 mainline 289,297 276,660 this patch 0 0 Link: https://lore.kernel.org/20260903222456.1881786-1-handyhandyman.adam@gmail.com Fixes: 95d4b3450ebe ("lib/plist.c: add shortcut for plist_requeue()") Signed-off-by: Adam Harshbarger Signed-off-by: Andrew Morton Reviewed-by: Nickolai Zeldovich Assisted-by: Claude:claude-opus-5 Cc: I Hsin Cheng Cc: # v6.15+ Signed-off-by: Sasha Levin commit 97c37dff8da731e662cf6a3016084ddffca68982 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 e5ab68567bcf62011dbb318957c220a55f84fe47 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 f4b79f221d62326ccec4d68cfd4400dcbf20ab5f 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 93658e949bcaaf277d57b0ff82f16c257f9d9e21 Author: Guixin Liu Date: Thu Oct 8 11:46:13 2026 +0800 cxl/pci: Program the Port GPF timeouts before caching the DVSEC [ Upstream commit ec2e30a682945616d194d7999cf96606b7ee5a88 ] cxl_gpf_port_setup() caches the Port GPF DVSEC offset in the dport before programming the phase timeouts, and ignores the return value of both update_gpf_port_dvsec() calls: the function always reports success. A failing config write is therefore not only silent, it is also permanent: the timeouts stay at the hardware defaults instead of the maximum flush window the kernel is asking for, and the cached offset keeps any later endpoint attach from retrying the update. Propagate the errors and cache the offset only after both phases are programmed, so the next endpoint attach retries the setup. Fixes: 6af941db6a60 ("cxl/pci: Update Port GPF timeout only when the first EP attaching") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Guixin Liu Reviewed-by: Jonathan Cameron Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20261008034619.28059-3-kanie@linux.alibaba.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 03c8debe85948e3950cda38b737777f9d7acdee1 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 bb8ff1e7c85a7712bfff442a53458a1ad6c98cbb 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 24f7f97d3051299bc58f5366182662a7e31a5a24 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 f307ab1738e77d7e7c8b23406ceecce584de5d49 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 778aa24d400eaebcad7bebbc69c496e126e99348 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 1a95eef28e3a053ca3369807d26ecd9250998784 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 f8b51537bad341024a406fd2ebe5ff5d8564792d 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 6a206ea1cfce608a0373de5e35badf0fa8ac9373 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 ada2a9bcb9c49bce7091a30a6bb4e4551fbdd0d9 Author: Jiale Yao Date: Sat Oct 3 18:19:43 2026 +0800 wifi: ath12k: validate MAC/PHY capability count before saving [ Upstream commit 86f2537877d6029487811bc3e0cd9e086a196000 ] Firmware supplies the hardware mode count and the PHY bitmap for each mode in the service-ready-ext event. ath12k_wmi_save_all_mac_phy_info() uses those bitmaps to populate svc_ext_info->mac_phy_info, but the destination is a fixed array of ATH12K_MAX_MAC_PHY_CAP elements. If the total number of advertised PHY entries exceeds that limit, the loop writes beyond mac_phy_info and corrupts adjacent memory. ath12k_wmi_mac_phy_caps_parse() allocates the source array for tot_phy_id entries and rejects excess capability TLVs. However, if the event contains fewer capability TLVs than advertised, the remaining allocated entries stay zeroed and are saved as invalid PHY information. After parsing the MAC/PHY capability TLVs, validate the destination capacity and reject an incomplete capability list before saving any entries. Fixes: 062ade23991e ("wifi: ath12k: parse and save hardware mode info from WMI_SERVICE_READY_EXT_EVENTID event for later use") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20261003101944.596546-1-yaojiale02@163.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit c2cbf1f5c5350b99bebb8062baa613f9900c0712 Author: Olivier Kaloudoff Date: Fri Oct 9 01:08:44 2026 +0200 ALSA: usb-audio: Add mic resolution quirk for Logitech Webcam C200 [ Upstream commit 874323b68c93c6808e034dc0113681e822e6fb42 ] The C200 (046d:0802) reports a mic capture volume range of 1536..7680 with a resolution of 1 (6144 steps), triggering "Warning! Unlikely big volume step count (=6144), linear volume or wrong cval->res?" at probe and exposing a uselessly fine-grained mixer control. This is the same firmware behavior as the other UVC-era Logitech webcams already carrying QUIRK_FLAG_MIC_RES_384 (C500, C600, C210, C270, C310, C510, C525, ...), so apply the same quirk: CTL_MSG_DELAY_1M (which the Logitech VENDOR_FLG would provide if the device-specific entry did not short-circuit the lookup) plus MIC_RES_384. Verified on real hardware: with the quirk the warning disappears and the driver logs "set resolution quirk: cval->res = 384". Signed-off-by: Olivier Kaloudoff Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261008230844.11246-1-olivier.kaloudoff@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 428eeed252ba1dfc84ad10354ac27118a6bf84f2 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 0ec1d83baa7b319374e3071f48946240149efb74 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 8ddf9f17929def10bb465ec7c56c50383c570d2b 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 01ed474a52876987c60689af1501a5824e87836d 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 b766cd114640acf06d7589232a23ba456478c073 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 c3575058ef57d31dc12c544cee9653289b851036 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 e3b89306967275b927d7812cd9ab5bd6bc0e189e 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 7bc4323b464d134ded51822fb5b9930c8f682e46 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 a0e83ac1d99e923a01a00fbe6cd000ee9646e62d 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 2b637d3f1d2238f426b571424f352774556ef63f 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 e5a02a186b4618d703ccda1151f9864e4e906036 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 fac98d283c77acc9649b65164ae65982f9505e79 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 18223e4783fe08229e489b766c13d5abbd648b2a Author: Longlong Xia Date: Tue Sep 8 09:28:01 2026 +0800 mm/zswap: publish the initial pool with list_add_rcu() [ Upstream commit c1dd5e24a82d19bff8eef50ba8205d4776584aff ] zswap_setup() publishes the pool on the zswap_pools list with a plain list_add(), but the list is walked by concurrent RCU readers holding nothing but rcu_read_lock() through zswap_total_pages(), e.g. /proc/meminfo and the shrinker count path. CPU 0 (writer) CPU 1 (reader) -------------- -------------- zswap_pool_create(): pool->zs_pool = zs_create_pool(); (1) list_add() -> __list_add(): WRITE_ONCE(zswap_pools.next, &pool->list); (2) zswap_total_pages(): pool = READ_ONCE( (a) zswap_pools.next); zs_get_total_pages( (b) pool->zs_pool); If (2) becomes visible to CPU 1 before (1), CPU 1 finds the pool at (a) but dereferences a wild pointer at (b). Publish the node with list_add_rcu(). Link: https://lore.kernel.org/20260908012801.1864430-1-xialonglong2025@163.com Fixes: 91cdcd8d624b ("mm: zswap: optimize zswap pool size tracking") Signed-off-by: Longlong Xia Signed-off-by: Andrew Morton Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260906133601.3563324-1-xialonglong2025%40163.com Acked-by: Yosry Ahmed Acked-by: Nhat Pham Assisted-by: Zcode:GLM-5.3 Cc: Chengming Zhou Cc: Johannes Weiner Cc: Signed-off-by: Sasha Levin commit 4b10d04a68b8e17bb805df65f81a36a9041dd7bd Author: Jinmeng Zhou Date: Mon Sep 7 21:20:55 2026 +0800 mm/hugetlb: fix subpool minimum reservation rollback [ Upstream commit e4949a80f3b07e52dca76c34ce353633927a28a5 ] When a reservation request is partially covered by a subpool minimum and the remaining global reservation fails, the error path first calls hugepage_subpool_put_pages() for the subpool-backed portion. It removes the failed global portion from used_hpages only afterwards. hugepage_subpool_put_pages() uses used_hpages to decide whether rsv_hpages should be restored. Since used_hpages still includes the global portion, it can remain at or above min_hpages and prevent that restoration. It then reports the subpool reservation as releasable, causing hugetlb_acct_memory() to incorrectly decrement h->resv_huge_pages. This was reproduced with four 2 MB huge pages and a hugetlbfs mount with size=10M,min_size=8M. After a successful three-page reservation, a two-page reservation which needed one subpool page and one global page failed with -ENOMEM. HugePages_Rsvd incorrectly dropped from four to three even though the subpool minimum was still four pages. Roll back the failed global portion from used_hpages first, so that hugepage_subpool_put_pages() evaluates the minimum reservation against the current usage and returns the correct global adjustment. Link: https://lore.kernel.org/20260907132055.26696-1-zhoujinmeng@bytedance.com Fixes: a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") Signed-off-by: Jinmeng Zhou Signed-off-by: Andrew Morton Acked-by: Muchun Song Tested-by: Ackerley Tng Cc: David Hildenbrand Cc: Ma Wupeng Cc: Oscar Salvador Cc: Signed-off-by: Sasha Levin commit 67c5a7bef45e14b41c971ef6d715d1eec53cd0fd 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 e4dcde9709a25f5301f0a1cc5f6f76485aea2c48 Author: Mike Rapoport (Microsoft) Date: Thu Sep 3 18:49:58 2026 +0300 mm/execmem: free ROX cache chunks only when they span an entire vm area [ Upstream commit 52d95a55a0113408acd2d4ce0294a72c527f5092 ] Patch series "mm/execmem: fixes and cleanups for the ROX cache". Sashiko review of the ROX cache refill path asked what happens when the PMD_SIZE allocation fails there. Pulling that thread uncovered a bit more than the fallback. Patch 1 fixes a real bug, although rare bug: execmem_cache_clean() can free a chunk that is still partially in use, because a PMD sized and PMD aligned free range in the middle of a larger chunk looks exactly like a chunk that nobody uses. Patch 2 handles maple tree allocation failures in the cache. They are unlikely, but silently dropping an area from the tree is not a great way to deal with them. Patch 3 deals with the fallback that started all this. The cache exists to keep the direct map free of unnecessary splits, and the fallback happily filled it with base page mapped areas that could never be freed from the cache again. Ask vmalloc for a huge mapping or nothing, and serve whatever does not fit outside the cache. Patches 4 and 5 convert the ROX cache to scope based cleanup. The series was tested on x86 with module load/unload cycles, with PTDUMP confirming that the cache is using 2M mappings, and with nohugevmalloc to exercise the uncached fallback. This patch (of 5): When execmem refills the ROX cache, it vmalloc()s multiples of PMD_SIZE aligned to PMD_SIZE. For every such allocation vmalloc creates a vm area. The first part of the vmalloc()ed chunk is returned to the allocation that triggered the cache refill and the remaining part is added to the cache and handed out for subsequent allocations with execmem_alloc(). When only the first part is freed, the entire vm area remains in the ROX cache and can be handed out again. In the case when the first allocation is larger than PMD_SIZE and the second allocation from the freed first part of the chunk is exactly PMD_SIZE, execmem_cache_clean() will free the entire chunk while part of it is still in use. For example: /* * vmalloc(4M), return p0 to the caller * add [p0 + 3M, p0 + 4M) to the cache */ p0 = execmem_alloc(3M); /* return p0 + 3M from the cache to the caller */ p1 = execmem_alloc(1M); /* put [p0, p0 + 3M) back into the cache */ execmem_free(p0); /* return p0 from the cache to the caller */ p2 = execmem_alloc(2M); /* return p0 + 2M from the cache to the caller */ p3 = execmem_alloc(1M); /* bah! execmem_cache_clean() frees the entire 4M chunk */ execmem_free(p2); Make sure that the ranges that execmem_cache_clean() frees cover the entire vm area. Link: https://lore.kernel.org/20260903-execmem-rox-cache-pmd-v1-v1-0-11beb2a3d249@kernel.org Link: https://lore.kernel.org/20260903-execmem-rox-cache-pmd-v1-v1-1-11beb2a3d249@kernel.org Fixes: 2e45474ab14f ("execmem: add support for cache of large ROX pages") Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Andrew Morton Assisted-by: copilot:claude-opus-5 Cc: Benjamin Tissoires Cc: Jiri Kosina Cc: Luis Chamberalin Cc: "Uladzislau Rezki (Sony)" Cc: Signed-off-by: Sasha Levin commit 61b405ef3e35b5890365090ab6a377855e9a9b71 Author: Luxiao Xu Date: Thu Sep 10 11:42:50 2026 +0800 mm/memory: constrain generic_access_phys() to page boundary [ Upstream commit ae0298a5fbeff32951c0d31398ccec97ec6aa0ea ] This patch addresses an issue in generic_access_phys() where accessing memory across page boundaries in PFNMAP VMAs assumes physical pages are contiguous, which can lead to accessing unintended physical memory or exceeding VMA boundaries. generic_access_phys() improperly validates the memory access range: it only validates the start address using follow_pfnmap_start() and passes PAGE_ALIGN(len + offset) to ioremap_prot(). This poses two problems: 1. In PFNMAP VMAs, consecutive virtual pages are not guaranteed to be physically contiguous, and individual PTEs may have different access permissions or writability. 2. The mapping may cross VMA boundaries if len extends beyond vma->vm_end. Constrain the access in generic_access_phys() to at most the current page boundary (PAGE_SIZE - offset) and map only a single PAGE_SIZE via ioremap_prot(). Since the caller __access_remote_vm() already loops over the requested length and handles partial transfers, it will naturally iterate over the remaining pages. Also add a missing (resource_size_t) cast during PFN re-validation to avoid truncation on 32-bit PAE systems. Link: https://lore.kernel.org/e06e28a46c2a176238f03b5740df0913e57c2861.1788842306.git.rakukuip@gmail.com Fixes: 9cb12d7b4cca ("mm/memory.c: actually remap enough memory") Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei Signed-off-by: Andrew Morton Reported-by: Vega Suggested-by: David Hildenbrand Acked-by: David Hildenbrand (Arm) Assisted-by: LLM Cc: Grazvydas Ignotas Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Sasha Levin commit 49f6bd347a7b7da90aabc213b58eec620c295d64 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 7bcffd24502d637b348a2e460093a0cabad4554e 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 02eea74948bda0409d7e359969218a814238a42a 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 eb69dba4610f68465b95c1045716580f42f8c8ba 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 16c511466a87d53efab5fe100aa645e8633c7eda 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 2de6fe2980963a1b23676bff90e4def80646d162 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 ab41325c105db07cebc9cd7ba2716a93b6946426 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 d8c47fba16b9822f623d7131eed17c52c5b60b32 Author: guzebing Date: Fri Aug 14 11:48:55 2026 +0800 ext4: reject delalloc to nodelalloc before applying remount options [ Upstream commit 26a3ff309c91986dbedb05d0e0f0050ea0aa629c ] Commit 97f5ec3b166d ("ext4: prevent delalloc to nodelalloc on remount") rejects switching a mounted filesystem from delalloc to nodelalloc. However, it performs the check after ext4_apply_options() has already cleared EXT4_MOUNT_DELALLOC in the live superblock. The failure path eventually restores the bit, but leaves a window where other CPUs can observe nodelalloc. test_opt() reads s_mount_opt directly without a lock shared with remount. If a concurrent truncate's __es_remove_extent() hits this window and observes nodelalloc, it sets count_reserved to false. Delayed extent status entries are then removed without calculating their cluster reservations, leaving reserved at zero. ext4_es_remove_extent() therefore calls ext4_da_release_space() with zero, leaving i_reserved_data_blocks and s_dirtyclusters_counter elevated. When the inode is later evicted after unlink, ext4_destroy_inode() reports: i_reserved_data_blocks (...) not cleared! CPU 0 CPU 1 ksys_truncate() ... ext4_es_remove_extent() ext4_reconfigure() ext4_check_opt_consistency() __ext4_remount() ext4_apply_options() clear EXT4_MOUNT_DELALLOC __es_remove_extent() test_opt() sees !DELALLOC count_reserved = false reject delalloc -> nodelalloc restore EXT4_MOUNT_DELALLOC remove delayed ES ext4_da_release_space(0) Follow the pre-apply validation approach used by ext4_check_quota_consistency() and reject the transition in ext4_check_opt_consistency(), before ext4_apply_options() changes live state. Use mask_s_mount_opt to determine whether delalloc/nodelalloc was specified and ctx_test_mount_opt() to check the final parsed value. Fixes: 97f5ec3b166d ("ext4: prevent delalloc to nodelalloc on remount") Cc: stable@vger.kernel.org Signed-off-by: guzebing Reviewed-by: Ojaswin Mujoo Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260814034855.1573759-1-guzebing1612@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 9e7b9a6cb744844559911a5c8ff6e627aa9de9c6 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 c8835d955dc6b3c4493c7139cd2afd4f880e3da1 Author: guzebing Date: Mon Aug 10 23:12:00 2026 +0800 ext4: only update tune mount options when requested [ Upstream commit 981eec6c300bd4e84ffac8f3c28b762d00f13e9c ] EXT4_IOC_SET_TUNE_SB_PARAM uses set_flags to indicate which superblock fields the caller wants to update. ext4_sb_setparams() checks set_flags before updating the other supported fields, but always copied mount_opts into the on-disk s_mount_opts field. As a result, callers that do not set EXT4_TUNE_FL_MOUNT_OPTS can still clear or alter the on-disk default mount options through their unused mount_opts buffer. This can affect subsequent mounts by changing the filesystem's stored default mount options. Only copy mount_opts into s_mount_opts when EXT4_TUNE_FL_MOUNT_OPTS is set, matching the set_flags semantics used by the other tuneable superblock fields. Cc: stable@kernel.org Fixes: 04a91570ac67 ("ext4: implemet new ioctls to set and get superblock parameters") Signed-off-by: guzebing Reviewed-by: "Darrick J. Wong" Link: https://patch.msgid.link/20260810151200.1405562-1-guzebing1612@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 82c9bc868b49d87893ef3ce8c09ff21300dcb50e 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 4bc8cef2303f0a3097ddbf30e037e9b93a2be4b3 Author: Peter Ujfalusi Date: Thu Oct 8 11:51:33 2026 +0300 ALSA: hda/hdmi: clamp sad_count in ELD proc write handler [ Upstream commit b3e7ddd694f8429217ba509b55b910a0e4361dfb ] snd_hdmi_write_eld_info() parses a "sad_count N" line from the root-writable ELD proc interface and assigns N directly to e->sad_count with no upper bound, unlike the per-index "sadN_*" lines a few lines below which are already bounded to ELD_MAX_SAD. snd_hdmi_eld_update_pcm_info() later iterates "for (i = 0; i < e->sad_count; i++)" over the fixed e->sad[ELD_MAX_SAD] array, so an oversized sad_count read from the proc file causes it to walk past the array. Reject sad_count values above ELD_MAX_SAD, matching the existing per-index guard. Fixes: acb059938810 ("ALSA: hda - ELD proc interface write updates") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20261008085133.9528-1-peter.ujfalusi@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d37861288c5de3c3041ef1890e22a0fab70d0b8f Author: Peter Ujfalusi Date: Thu Oct 8 11:51:22 2026 +0300 ALSA: hda/hdmi: clamp num_cvts against cvt_nids[] in hdmi_read_pin_conn [ Upstream commit 6cf3ab38b0d53d41f00fe594b2986849bdf994ae ] hdmi_add_cvt() stores each converter's NID into the fixed-size spec->cvt_nids[] array (used only by the Intel Haswell pin-connection fixup), but only when spec->num_cvts is still within ARRAY_SIZE(cvt_nids); the num_cvts counter itself is incremented unconditionally regardless of whether the store happened. A codec that reports more converters than cvt_nids[] can hold therefore ends up with num_cvts > ARRAY_SIZE(cvt_nids). hdmi_read_pin_conn(), on the intel_hsw_fixup path, copies num_cvts elements from cvt_nids[] with memcpy(), so once num_cvts exceeds the array size this reads past cvt_nids[] and writes the resulting garbage NIDs into per_pin->mux_nids[]. Clamp the copy length to the actual size of cvt_nids[] instead of trusting num_cvts, which is also used unbounded as the size of the separate, dynamically-sized spec->cvts array and must not be truncated at the source. Fixes: bce0d2a80e42 ("ALSA: hda - Allow unlimited pins and converters in patch_hdmi.c") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20261008085122.9442-1-peter.ujfalusi@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ca4d514d32a9c4c293d742f7091c49d4d016cd11 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 92eb10d78d07b64788575d2fb347664aedf96be4 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 3d1e0085b5d24cb1053cf9ccb915376f15f6a4b2 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 deea0b755ccba3491ccb957aa7343888c73ecfce 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 66cb7a60e0aa81c3426895ca1f98deb33411c47d Author: Pin-Hao Chen Date: Tue Oct 6 06:05:28 2026 +0800 spi: stm32: fix double free of SRAM buffer on MDMA fallback [ Upstream commit 0c5b0c3eb1d6daa1117dacd32589196f52109cab ] When the "rxm2m" MDMA channel cannot be obtained, the driver frees the SRAM buffer and falls back to DMA-only mode. However, sram_rx_buf is left pointing to the freed buffer. As a result, stm32_spi_unprepare_msg() may clear the released SRAM area, while stm32_spi_remove() or a later probe error path may free the buffer again, triggering BUG_ON() in gen_pool_free_owner(). The probe error path also checks sram_pool instead of sram_rx_buf. If the SRAM allocation failed and a later probe step fails, gen_pool_free() may therefore be called with an unallocated buffer. Clear sram_rx_buf after freeing it on the MDMA fallback path and use the buffer pointer to determine whether cleanup is needed. Fixes: d17dd2f1d8a1 ("spi: stm32: use STM32 DMA with STM32 MDMA to enhance DDR use") Cc: stable@vger.kernel.org Signed-off-by: Pin-Hao Chen Link: https://patch.msgid.link/20261005220528.7199-1-billy920225@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5dc170af53674ccebfc36a2a03dbd19e4ef86634 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 61cde0b5c12743ad672d928e57ac99cbb725ef6d 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 b63fac9e76caf2586609d6728882254962cf7672 Author: Linlin Yang Date: Mon Aug 24 17:29:37 2026 +0800 wifi: mt76: mt7996: fix PCI device reference leak in mt7996_pci_init_hif2() [ Upstream commit d92bac6b6af2602516ee82ae112709c71af27cf6 ] pci_get_device() increments the reference count on the returned struct pci_dev. In mt7996_pci_init_hif2(), three pci_get_device() calls are made but their return values are only checked for NULL and then discarded. pci_dev_put() is never called, causing a PCI device reference count leak. Fix this by storing the return value and calling pci_dev_put() before returning, following the same pattern already used in the sibling driver mt7915/pci.c. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Cc: stable@vger.kernel.org Signed-off-by: Linlin Yang Link: https://patch.msgid.link/20260824092937.683240-1-yanglinlin@kylinos.cn Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 79bebd5637d4a7503eb6edae7cf61841251ab238 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 de7a5fdb25861a51ffaa13647c539129318b51a8 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 ff57cd58c75d7d32b9b6fea5fdf04e78c321e29f Author: Devin Wittmayer Date: Sat Oct 3 16:49:44 2026 -0700 wifi: mt76: mt7925: cancel mlo_pm_work on the USB stop path [ Upstream commit 9f299215d1d835aeeee8b269dad09e1be06f856e ] Every other teardown path cancels this work, PCIe unbind included. USB unbind does not: PCIe has its own unregister hook for it, while USB shares a generic one and the stop callback that would have covered it is replaced in probe. That cancel came in commit 81faf578320d ("wifi: mt76: mt7925: cancel mlo_pm_work on stop"), whose last line says it covers both buses. That's mine and it's a boo-boo. Give the USB path its own stop that cancels the work first. Two-link MLO on a Netgear A9000, work armed then the interface down: stock patched stop ran 3/3 3/3 work still ran 3/3 0/3 Skipping the stop entirely leaves both builds running it, so the zero is the cancel. Fixes: 276a56883257 ("wifi: mt76: mt7925: update the power-saving flow") Cc: stable@vger.kernel.org Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20261003234944.96066-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 09c14715c6c2241ca6d7b808f048b0d2cd639394 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 001c88ed4a17ea6705b7c00cf00cdd73d60078e7 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 2fff1ca283f1e4a49a259befdcc23bbbac4b45f7 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 9d67b9bf659ffb1eeb2b429a3b999b4a3c36b72d 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 ffbb00ff33fe7399362dbbb23f34ef0c3e7704e0 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 8463ea8d471edec1e9431fb6a955c476a17f5db4 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 de648cd4c54e659d5d212bdbe158f135569161cb Author: Joseph Qi Date: Tue Sep 1 20:52:18 2026 +0800 ocfs2: restrict OCFS2_INVALID_SLOT suballoc slot to system inodes [ Upstream commit 25bf9e549360b656a6763232e0e9e58a00c3aff7 ] Patch series "ocfs2: validate suballoc slot and bit of metadata blocks", v3. The ocfs2 metadata validators trust the on-disk suballoc slot and bit without checking them against the slot range of the mounted filesystem and the capacity of the block group bitmap. A corrupted image can carry OCFS2_INVALID_SLOT or another out-of-range slot, or a suballoc bit beyond the bitmap, and once the corresponding inode, extent block, xattr block, dir index root or refcount block gets freed, the bad value goes straight into ocfs2_get_system_file_inode() or _ocfs2_free_suballoc_bits() and hits a BUG_ON() or runs off the end of local_system_inodes[]. This series rejects such values at read time, in the existing validators, so corrupted objects fail with -EROFS (and a read-only remount) instead of crashing: patch 1 restricts OCFS2_INVALID_SLOT dinodes to system inodes, completing fe7a283b3916 ("ocfs2: add suballoc slot check in ocfs2_validate_inode_block()"), and turns the "system file state is ambiguous" BUG_ON() in ocfs2_read_locked_inode() into an ocfs2_error(); patch 2 rejects oversized dinode suballoc bits; patch 3 validates the suballoc slot and bit of xattr and dir index blocks; patch 4 validates the suballoc slot and bit of extent and refcount blocks. The checks only enforce what the kernel and mkfs.ocfs2 already write: a valid slot from meta_ac->ac_alloc_slot and a bit within the block group bitmap, with system inodes carrying OCFS2_INVALID_SLOT plus OCFS2_SYSTEM_FL and extent blocks using slot 0. Nothing changes for healthy filesystems. Each new check was exercised under QEMU by corrupting the field in question with an out-of-range value; with the series applied the access fails with -EROFS and the filesystem remounts read-only instead of hitting the BUG_ON(). This patch (of 4): ocfs2_validate_inode_block() currently permits i_suballoc_slot to be OCFS2_INVALID_SLOT for any dinode. Only system inodes created by mkfs.ocfs2 are allocated from the global allocator and thus legitimately carry this value; regular inodes are always allocated from a per-slot suballocator and hence must have a valid slot. If a corrupted regular inode with OCFS2_INVALID_SLOT is accepted, ocfs2_remove_inode() will pass the slot to ocfs2_get_system_file_inode() and get_local_system_inode() will hit BUG_ON(slot == OCFS2_INVALID_SLOT) when the inode is deleted. This can be triggered by an unprivileged user unlinking such a corrupted file. Reject OCFS2_INVALID_SLOT for non-system dinodes during validation, while still accepting it for system inodes. Note that a crafted dinode carrying OCFS2_SYSTEM_FL passes the check above, yet a plain lookup of it still used to BUG() in ocfs2_read_locked_inode() ("system file state is ambiguous"). Since i_flags comes from disk, handle that mismatch with ocfs2_error() instead of BUG_ON() as well. Link: https://lore.kernel.org/20260901125221.1634686-1-joseph.qi@linux.alibaba.com Link: https://lore.kernel.org/20260901125221.1634686-2-joseph.qi@linux.alibaba.com Fixes: fe7a283b3916 ("ocfs2: add suballoc slot check in ocfs2_validate_inode_block()") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Cc: Changwei Ge Cc: Heming Zhao Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Signed-off-by: Sasha Levin commit 68bcb60fcbba3a60517ddce226c8d30a09fff4c9 Author: Karl Mehltretter Date: Fri Jul 10 14:39:57 2026 +0200 fork: honor task_struct's declared alignment [ Upstream commit 9decb604dc064099a6249150f0c4909525ed657c ] Since commit cb7ca40a3882 ("x86/fpu: Make task_struct::thread constant size"), struct task_struct is declared __attribute__((aligned(64))) on all architectures. But fork_init() still sets the task_struct slab cache's alignment to align = max(L1_CACHE_BYTES, ARCH_MIN_TASKALIGN) which is smaller than 64 on architectures whose cache lines are below 64 bytes: e.g. 32 on ARMv5. In practice plain SLUB happens to hand out 64-byte-aligned objects anyway. With CONFIG_SLUB_DEBUG_ON the red-zone padding shifts objects to the requested alignment. With CONFIG_UBSAN_ALIGNMENT=y a boot on QEMU versatilepb (ARM926EJ-S, v7.2-rc2, gcc 13.3) floods the console with reports like: UBSAN: misaligned-access in include/linux/sched.h:2087:9 member access within misaligned address c295d7e0 for type 'struct task_struct' which requires 64 byte alignment CPU: 0 UID: 0 PID: 15 Comm: pr/ttyAMA-1 Not tainted 7.2.0-rc2 #1 VOLUNTARY Set the slab alignment to at least the type's declared alignment. Link: https://lore.kernel.org/20260710123957.31774-1-kmehltretter@gmail.com Fixes: cb7ca40a3882 ("x86/fpu: Make task_struct::thread constant size") Signed-off-by: Karl Mehltretter Signed-off-by: Andrew Morton Reviewed-by: Bradley Morgan Assisted-by: Claude:claude-fable-5 Cc: Ingo Molnar Cc: Kees Cook Cc: Peter Zijlstra Cc: Vlastimil Babka Cc: Signed-off-by: Sasha Levin commit 70ba414a149b74728e5debe71a6e5ac4f71d4152 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 407e148354ac954f70a1b54077b4a6ea0f669dbe 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 4db84320615453cf205febbc59a715ace31f9782 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 46e0c9c62927b0dbef2d284d2aa770eab588ebb1 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 afc4b63805254c0c1ae515e69383567c8b57d6ac 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 de69081c154e85db8f80ff260344881636e969a8 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 50f237e8fcf93c174848be346d11167c51b1eb5c 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 a1b937d0e196b32a6a99022b764f2c986e961838 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 4a73bd9f0b78a97c91389dc8c356079e6085894d Author: SJ Park Date: Tue Sep 1 17:27:23 2026 -0700 mm/damon/sysfs: set next refresh jiffies per sysfs context [ Upstream commit b9100ecb5411d2de79175ed534df72ec41e94998 ] When 'refresh_ms' is set, DAMON sysfs interface periodically updates auto-tuned parameters and DAMOS stats. The timestamp for the next refresh is initialized when a DAMON context starts, and updated in its damon_call() callback function. That is, each DAMON context updates it. However, the timestamp is a global variable that is shared with all the contexts. When there are multiple DAMON contexts having different refresh_ms, the update frequency will be changed, depending on the order of the contexts. When there are multiple kdamonds, it will be even more chaotic. Fix the problem by having the timestamp per each context. The user impact is not very critical. It does not leak, corrupt or crash. The update will not be faster or slower than the lowest and largest refresh_ms values of the contexts, respectively. The user can also manually ask the updates on demand using kdamond state commands. That said, clearly this is a bug and can easily be reproduced. Link: https://lore.kernel.org/20260902002725.108635-5-sj@kernel.org Fixes: 9fd7bb5083d1 ("mm/damon/sysfs: change next_update_jiffies to a global variable") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Reviewed-by: Lian Wang Tested-by: Lian Wang Reviewed-by: Kunwu Chan Cc: Brendan Higgins Cc: David Gow Cc: Quanmin Yan Cc: # 6.18.x Signed-off-by: Sasha Levin commit 34902f2cbcc8d218f64f0ff827c131f26ba01630 Author: SJ Park Date: Tue Sep 1 06:18:47 2026 -0700 mm/damon/core: handle extreme memory state in damon_get_node_mem_bp() [ Upstream commit 485a9149ad406e00949327a3231b9084d7073706 ] In an extreme and unlikely situation, si_meminfo_node() might let the caller show zero total ram. That could cause a divide by zero in damon_get_node_mem_bp(). It could also show free memory larger than the total memory. This could cause underflow and make DAMOS temporarily make unexpected behavior. Thanks to safety guards in the auto-tuning feedback loop, that should not be a real problem, though. Fix the problems by respectively returning 100% and 0% for used and free memory queries in the corner cases. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260901131850.98037-7-sj@kernel.org Link: https://lore.kernel.org/20260328133216.9697-1-sj@kernel.org [1] Fixes: 0e1c773b501f ("mm/damon/core: introduce damos quota goal metrics for memory node utilization") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: Usama Arif Cc: # 6.16.x Signed-off-by: Sasha Levin commit eea4e41924e88163d4ae72dff91736ab99fbec7c Author: SJ Park Date: Tue Sep 1 06:18:45 2026 -0700 mm/damon/vaddr: respect folio end for DAMOS_STAT [ Upstream commit 946351a5fc5d4e3afec2bdf735935d17d6c9ceb2 ] For applying DAMOS_STAT action to a region, DAMON virtual address space operation set (vaddr) calls walk_page_range[_vma]() for the region. The pmd walk entry function, namely damon_va_stat_pmd_entry(), applies DAMOS filters to folios of addresses of the region in the pmd. It starts from the walking address and advances the address by the size of the folio of the address until it goes out of the pmd or the region. Let's suppose it is for the first pmd of the region, and the region start address is in the middle of a large folio. Also, the next folios are small. Then, some of the next folios could be skipped. Fix the issue by advancing the address to exactly the start address of the next folio. The user impact is that the DAMOS_STAT-based page level monitoring results become inaccurate. Since the page level monitoring is supposed to provide relatively high precision, this is definitely a problem. It is arguably not critical since it is only monitoring quality degradation. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260901131850.98037-5-sj@kernel.org Link: https://lore.kernel.org/20260514015053.149396-1-sj@kernel.org [1] Fixes: 63f39737d1e3 ("mm/damon/vaddr: support stat-purpose DAMOS filters") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: Usama Arif Cc: # 6.18.x Signed-off-by: Sasha Levin commit 9511b63a1f0df7aadf9e06247f66c8dd069bd0e3 Author: SJ Park Date: Tue Sep 1 06:18:44 2026 -0700 mm/damon/paddr: respect folio end for DAMOS actions except STAT [ Upstream commit 1613ac9edf385c35f171a25610e2706a7e6afad6 ] A few functions for applying DAMOS actions including pageout, lru_[de]prio and migrate_{hot,cold} in DAMON physical address space operation set (paddr) collect folios of the given region by getting the folios of region-internal addresses. Then, those functions apply the action to the collected folios at once. The collection starts from the region start address and advances the address by the size of the folio of the address until it goes out of the region. If the start address is in the middle of a large folio, and if the next folios are small, some of the next folios could be skipped. Fix the issue by advancing the address to exactly the start address of the next folio. The user impact is that DAMOS action is applied to less than expected amount of memory. Given the best effort nature of DAMON, it is no big problem, but it is clearly a bug that is better to be fixed. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260901131850.98037-4-sj@kernel.org Link: https://lore.kernel.org/20260517234112.89245-1-sj@kernel.org [1] Fixes: 3a06696305e7 ("mm/damon/ops: have damon_get_folio return folio even for tail pages") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: Usama Arif Cc: # 6.15.x Signed-off-by: Sasha Levin commit 3f70cd14b0aa2d1f2162a2e072edad2ebe1e14de Author: SJ Park Date: Tue Sep 1 06:18:43 2026 -0700 mm/damon/paddr: respect folio end for DAMOS_STAT [ Upstream commit ac733f921d4fc02da70a98b175a6055a206b2a36 ] The function for applying DAMOS_STAT in DAMON physical address space operation set (paddr), namely damon_pa_stat(), applies DAMOS filters to folios of the given region. For that, it gets folios of addresses in the region. It starts from the region start address and advances the address by the size of the folio of the address until it goes out of the region. If the start address is in the middle of a large folio, and if the next folios are small, some of the next folios could be skipped. Fix the issue by advancing the address to exactly the start address of the next folio. The user impact is that the DAMOS_STAT-based page level monitoring results become inaccurate. Since the page level monitoring is supposed to provide relatively high precision, this is definitely a problem. It is arguably not critical since it is only monitoring quality degradation. Link: https://lore.kernel.org/20260901131850.98037-3-sj@kernel.org Fixes: bdbe1d7bc325 ("mm/damon/paddr: increment pa_stat damon address range by folio size") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: Usama Arif Cc: # 6.14.x Signed-off-by: Sasha Levin commit 5025b3035b74cba1bdd3a7d753338dc6cdaea47d Author: Zhiling Zou Date: Tue Jul 21 23:56:38 2026 +0800 mm/page_table_check: skip zero pages [ Upstream commit 33afd07412a1efe5b750a3fd5eb0272ebdd12761 ] page_table_check_set() accounts pages by whether they are PageAnon(). The shared zero page is a special page, not an ordinary file-backed page. Read faults on private anonymous mappings can install many read-only PTEs that point at the zero page, but page_table_check currently accounts them in file_map_count. That lets an unprivileged process populate enough zero-page mappings to overflow file_map_count and trip the BUG_ON() in page_table_check_set(). Skip zero pages in page_table_check accounting. They do not need the anonymous/file mapping conflict checks that page_table_check performs for ordinary pages, and this keeps the existing counter size and page_ext layout unchanged. Link: https://lore.kernel.org/1f8848512d2e3ded944f8d595c29faee8fdaeab0.1784645969.git.roxy520tt@gmail.com Fixes: df4e817b7108 ("mm: page table check") Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Signed-off-by: Andrew Morton Reported-by: Vega Assisted-by: Codex:gpt-5.4 Cc: Ye Liu Cc: Signed-off-by: Sasha Levin commit da32aae509221f877a7df222e572c4ed28818288 Author: Joe Damato Date: Mon Aug 31 10:48:35 2026 -0700 mm: memcontrol: raise MEMCG_MAX for charges that fail without reclaiming [ Upstream commit 374f65b1481992eb6b9c6bffd53f3afa5c2e94cf ] Charges that exceed memory.max and return through the nomem label can raise no event and simply return -ENOMEM. A non-blocking charge can hit the limit, get rejected, but is not visible in memory.events. This was noticed in a production setting where bpf_mem_alloc() attempted to refill its per-cpu freelists, which triggered a non-blocking charge while at the limit. Commit d6e103a757fa ("mm: memcontrol: do not miss MEMCG_MAX events for enforced allocations") added raised_max_event to cover charges that are force charged without ever reaching reclaim, but charges that are rejected outright were left out. Getting an allocation failure without the corresponding MEMCG_MAX event is unexpected and makes debugging and monitoring harder. Raise the event on the way out for rejected charges as well, by routing the -ENOMEM return through the same exit path that already covers forced charges. The existing behavior of raising a MEMCG_MAX event on every charge/reclaim/retry iteration is left unchanged. Tested with a module that performs accounted GFP_NOWAIT page allocations from a task in a cgroup at its memory.max, and measures the resulting memory.events:max delta. Without this patch the rejected charges raise no event at all; with it the delta matches the number of rejected charges exactly. A GFP_KERNEL|__GFP_NORETRY control, which reaches reclaim, raises the same two events per failed charge before and after, confirming the existing charge/reclaim/retry accounting is unchanged. Link: https://lore.kernel.org/20260831174836.3102406-1-joe@dama.to Fixes: d6e103a757fa ("mm: memcontrol: do not miss MEMCG_MAX events for enforced allocations") Signed-off-by: Joe Damato Signed-off-by: Andrew Morton Suggested-by: Shakeel Butt Acked-by: Shakeel Butt Cc: Johannes Weiner Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Sasha Levin commit 1140b3a60d9d8a4ad32381077a8e3d3fa8f4d0bf 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 21550a58fa0269949d2204be890e76c69ff8d065 Author: Qi Xi Date: Tue Aug 25 20:05:49 2026 +0800 mm/page_isolation: guard compound_order() against racing [ Upstream commit 4c767c5dd9bc3521fed11e6fe1d52621fe5abf7b ] The PageCompound branch reads compound_head() without holding a reference. A racing split or free can cause compound_head() to return a stale pointer, and compound_nr() reads the order from that stale head, leading to out-of-range shifts and making the skip distance meaningless. Read the order explicitly with compound_order() and validate it is within MAX_FOLIO_ORDER before shifting. Also verify the derived head_pfn against the legitimate pfn: the head must not be past pfn, must be aligned to nr_pages, and pfn must fall within the compound page. Bail out with -EBUSY if any check fails. Link: https://lore.kernel.org/20260825120549.966271-3-xiqi2@huawei.com Fixes: b2c9e2fbba32 ("mm: make alloc_contig_range work at pageblock granularity") Signed-off-by: Qi Xi Signed-off-by: Andrew Morton Suggested-by: Zi Yan Reviewed-by: Zi Yan Cc: Brendan Jackman Cc: Johannes Weiner Cc: Kefeng Wang Cc: Michal Hocko Cc: Nanyong Sun Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Sasha Levin commit a793ea58f4a0f4797dabc8d57d92a143e02a9267 Author: Qi Xi Date: Tue Aug 25 20:05:48 2026 +0800 mm/page_isolation: fix UBSAN shift-out-of-bounds warning [ Upstream commit eba0e6297edd60a85bc96ff5cfb734d066af62dd ] Patch series "mm/page_isolation: fix UBSAN shift-out-of-bounds in isolate_single_pageblock", v3. Patch 1 fixes a UBSAN shift-out-of-bounds warning in the PageBuddy branch of isolate_single_pageblock() triggered by concurrent buddy allocation. Patch 2 addresses the same class of issue in the PageCompound branch, where racy compound_order() and compound_head() reads could lead to out-of-range shifts or incorrect page skipping. This patch (of 2): A contig-range allocation racing with buddy allocation on the adjacent pageblock can trigger: UBSAN: shift-out-of-bounds in mm/page_isolation.c:393:15 shift exponent -749042176 is negative Call trace: isolate_single_pageblock start_isolate_page_range alloc_contig_frozen_range_noprof alloc_contig_range_noprof isolate_single_pageblock() first calls set_migratetype_isolate() with zone->lock held, which marks the pageblock MIGRATE_ISOLATE and moves any free page straddling the boundary out of the way. Once the lock is dropped, it scans the MAX_ORDER_NR_PAGES-aligned window [start_pfn, boundary_pfn) locklessly, only to skip the free pages already handled above and to detect in-use pages straddling the boundary. Since this scan only reads page state to decide how far to skip and returns -EBUSY on a straddling in-use page, it does not take the lock. The window also covers the adjacent pageblock, whose free pages stay on the normal movable/CMA freelist and can be allocated concurrently. So after the scan observes PageBuddy(page), another CPU can allocate the page, leaving a stale value in page->private that makes "1 << order" shift out of range. Use buddy_order_unsafe() with READ_ONCE to read the order, and validate it is within MAX_PAGE_ORDER before shifting to prevent UBSAN warnings. Since pageblock_isolate_and_move_free_pages() already handles free pages straddling boundary_pfn under zone->lock, bail out with -EBUSY instead of VM_WARN_ON_ONCE() when a PageBuddy page appears to cross the boundary during the lockless scan. Link: https://lore.kernel.org/20260825120549.966271-2-xiqi2@huawei.com Fixes: b2c9e2fbba32 ("mm: make alloc_contig_range work at pageblock granularity") Signed-off-by: Qi Xi Signed-off-by: Andrew Morton Reviewed-by: Zi Yan Cc: Johannes Weiner Cc: Kefeng Wang Cc: Michal Hocko Cc: Nanyong Sun Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Brendan Jackman Cc: Signed-off-by: Sasha Levin commit ad72cc6babdd6d60774f1edcc8faf0e85c5e9de9 Author: Chengfeng Ye Date: Mon Aug 24 19:24:33 2026 +0800 mm/ksm: mark migration stores with WRITE_ONCE() [ Upstream commit d3863210464f69c18615cbe400d48a6e53e770d4 ] ksm_get_folio() deliberately samples stable_node->kpfn and folio->mapping without taking the folio lock because the KSM folio may be migrated concurrently. folio_migrate_ksm() updates the same state using plain assignments. The reader can load the old kpfn, then the migrator can store the new kpfn, execute smp_wmb(), and clear the old folio's mapping before the reader checks that mapping. Thus the initial kpfn load can overlap its update and the subsequent mapping load can overlap the clear, with no common lock. This leaves marked READ_ONCE() accesses racing with plain stores. The kernel reported: BUG: KCSAN: data-race in folio_migrate_ksm / ksm_get_folio read (marked) to 0xffff8ce401421330 of 8 bytes by task 48 on cpu 3: ksm_get_folio+0x7f/0x2a0 ksm_scan_thread+0x1635/0x3330 kthread+0x1af/0x1f0 write to 0xffff8ce401421330 of 8 bytes by task 102 on cpu 1: folio_migrate_ksm+0x6a/0xd0 folio_migrate_flags+0x193/0x420 __migrate_folio.isra.0+0x162/0x1a0 migrate_folio+0x4c/0x70 move_to_new_folio+0xd6/0x170 Use WRITE_ONCE() for both stores to pair them with the existing lockless reads. This preserves the existing smp_wmb()/smp_rmb() migration protocol and control flow while preventing compiler transformations of the shared accesses. Link: https://lore.kernel.org/20260824112433.191301-1-nicoyip.dev@gmail.com Fixes: c8d6553b9580 ("ksm: make KSM page migration possible") Signed-off-by: Chengfeng Ye Signed-off-by: Andrew Morton Acked-by: Xu Xin Acked-by: David Hildenbrand (Arm) Cc: Hugh Dickins Cc: Signed-off-by: Sasha Levin commit 9c925a7c4dcda91581a6170880ad5af24732d0d9 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 bbcd20a342158243d66a8c898515aac049ace138 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 5ed7a6aed407e83d7a5b4972bd553d764544b7ab Author: Donggeun Yoo Date: Sat Oct 3 19:22:21 2026 +0900 PCI/DOE: Fix double free of a duplicate feature's sysfs name [ Upstream commit 624ee129620a054466b6a29d98cd7a40ccc239cd ] When a DOE feature is reported twice, sysfs_add_file_to_group() fails with -EEXIST for the second copy and pci_doe_sysfs_feature_populate() frees that attribute's name, but leaves the pointer in place. pci_doe_sysfs_feature_remove() frees every name again when the device is removed, or when a later feature fails to register, so the name is freed twice: BUG: KASAN: double-free in pci_doe_sysfs_feature_remove+0x117/0x1b0 Call Trace: kfree+0x11a/0x420 pci_doe_sysfs_feature_remove+0x117/0x1b0 pci_doe_sysfs_teardown+0x90/0xf0 pci_remove_bus_device+0x128/0x2e0 pci_stop_and_remove_bus_device_locked+0x1d/0x30 remove_store+0xd2/0xf0 Clear the pointer after freeing the name. Fixes: 2311ab1820fe ("PCI/DOE: Expose DOE features via sysfs") Suggested-by: Alistair Francis Assisted-by: LLM Signed-off-by: Donggeun Yoo Signed-off-by: Bjorn Helgaas Reviewed-by: Alistair Francis Reviewed-by: Jonathan Cameron Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261003102221.59894-1-donggeunyoo.kernel@gmail.com Signed-off-by: Sasha Levin commit dabc4681985f5ddaee8f3088e46c91733c99f3c5 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 6bf6bf2db6e29233fc06a004db602ca290e190af 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 79c9a5bb4b3c504ddf494f8dfaaeba86c7222464 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 097a336a2dcd0a93842b7a80bbe2fc0745b78941 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 8e7e5b7b10da25341798c2b76648f2abc07409f9 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 59ab22bedd52783497ff1a2a509890679747271d 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 3eeae9c6d55ed130a31cf4added4004eeda6bf13 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 8bc833472436ac215caa1bbe501d2cad3a21a543 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 c1c3af4603375255a22960d1b7aa981adec8d4b2 Author: Henrik Enquist Date: Sat Oct 3 15:26:11 2026 +0200 ALSA: aloop: Don't constrain playback params in notify mode [ Upstream commit ded106036984a9dd766e7e1451b02e2d15c81438 ] With notify enabled (the pcm_notify module parameter or the "PCM Notify" control), the playback side of a cable may change format, rate and channels while a capture is running. loopback_check_format() then stops the capture and notifies the "PCM Slave" controls, so that the capture application can reopen with the new parameters. For this reason loopback_open() still gives a notify mode playback the unconstrained loopback_pcm_hardware. Since commit 898dfe4687f4 ("ALSA: aloop: Fix racy hw constraints adjustment") the hw rules refine against the shared cable->hw instead of the substream's own runtime->hw. This pins the playback side to the parameters of an open capture whatever the notify setting is. A player probing the device sees only the capture's rate, format and channels, and the format change path in loopback_check_format() can't be reached by a new playback. Skip the format, rate and channels rules for the playback substream when notify is enabled. Skip the period bytes rule as well: with a sound timer source, params_change() already takes the period size from a notify mode playback, and keeping the old capture's period bytes leaves a playback at another rate with a period that doesn't match the timer. The capture side stays constrained to the cable parameters. The capture stop this makes reachable again was hardened by commit 826af7fa62e3 ("ALSA: aloop: Fix racy access at PCM trigger") and commit e5c33cdc6f40 ("ALSA: aloop: Fix peer runtime UAF during format-change stop"), which need to be applied first when backporting. Reproducer, with notify enabled on the cable: arecord -D hw:Loopback,1,0 -r 44100 -f S32_LE -c 2 /dev/null & aplay -D hw:Loopback,0,0 96k.wav Before: aplay is forced to 44100 Hz and the capture keeps running. After: aplay runs at 96000 Hz, the capture is stopped and "PCM Slave Rate" reports 96000. Fixes: 898dfe4687f4 ("ALSA: aloop: Fix racy hw constraints adjustment") Reported-by: Pavel Hofman Closes: https://lore.kernel.org/all/b4af9071-f8d7-5b47-4d7a-c5743bd67394@ivitera.com/ Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Henrik Enquist Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20261003-aloop-notify-fix-v1-1-ba5dfb831bf5@gmail.com Signed-off-by: Sasha Levin commit 35af27e6cdefe33f0fdd7ff226f4967af3bc8e6e 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 a99338df4ab9c32c297374017402df22e4de7afa Author: Maurizio Casciano Date: Fri Sep 25 00:51:52 2026 +0200 power: supply: core: Honor supplied-from with CONFIG_OF=y [ Upstream commit 6bd80f22c764fe8c56c62c118387f86a3ca98cff ] The supplied-from device property is the name-based counterpart to firmware-node power-supplies references. It was added for non-DT platforms, but its parser is compiled only when CONFIG_OF is disabled. CONFIG_OF is a global kernel option, so x86 systems commonly enable it even when individual power supplies are described by software nodes. Consequently, these consumers never populate supplied_from and supplier notifications do not reach their external_power_changed() callbacks. On a Lenovo Yoga Book YB1-X91L, ftrace showed the Whiskey Cove supplier notification running without invoking the BQ25892 callback, leaving the input current limit at its boot-time value. Use a single power_supply_check_supplies() implementation for all configurations. Preserve firmware-node power-supplies references as the preferred firmware description and use the name-based supplied-from property only when no references are specified. Continue to honor an explicitly provided supplied_from list first and propagate errors from specified firmware references. With the fix, ftrace shows the BQ25892 callback on hotplug. A boot-offline test changes its input current limit from 500 mA to 2 A. Fixes: 58a36bb06891 ("power: supply: core: Add support for supplied-from device-property") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Maurizio Casciano Link: https://patch.msgid.link/20260924225152.985489-1-mauriziocasciano7@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 6c01b58b23f95bd4ce98ff01e1a07b88ecd683f6 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 48969667d004244035ee3e02ec50557e920414cb 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 b7dcd99be024c99a35e6919c3a4058773f40bf2c 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 855012e5e1bb64b7f7e50422c02b2ebdcd872657 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 b747b30491bf43e281fa44c857a01084b4c962fb 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 1c1507214f15d0047d248e0e8207595546f676c6 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 7251a4a129f3aa3d1cd1264ece2908ad7fc9b06c 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 2ebeb7f74276b0ef18cd8d096b645f80193a35fa 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 f3cef7132743d49e831cccfb9990bf9dbc4becc3 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 a210840ed70921f04e7c74074950a3da1bbc5e2f 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 5a603c6e1a8736c7a17e6dd718c0123df6f741e2 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 bf8913279f3ea5901ca6ca7e25d24adf7ce49de5 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 eb0a592ae6629ced47a52b3bb8b03f17f7b66103 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 4fc56ebae1e1f58f2e49a736e67dc7b0944f796c 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 b186accb1d7d8f9aa7b5183d7eb9ff26ac568ce3 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 bdc3f5859be5a2bf8862ca175708762b74fece08 Author: Guangshuo Li Date: Sat Jul 18 21:00:36 2026 +0800 media: chips-media: wave5: Check decoder qbuf runtime resume [ Upstream commit 158b39a0f7d198454a1fb34dcca5c25de588d54f ] wave5_vpu_dec_buf_queue_dst() resumes the VPU before it may clear a decoder display flag. This is needed because clearing the display flag accesses VPU registers. However, the return value from pm_runtime_resume_and_get() is ignored. If the resume fails, pm_runtime_resume_and_get() returns without holding a runtime PM usage reference. The unconditional pm_runtime_put_autosuspend() at the end of the function then drops an unmatched reference. The failed resume path can also continue into wave5_vpu_dec_clr_disp_flag() while the device is still suspended. Check the return value. If the resume fails, complete the queued buffer with an error and return without touching the hardware or dropping an unmatched runtime PM reference. Fixes: cbb9c0d50e47 ("media: chips-media: wave5: Fix SError of kernel panic when closed") 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 df569382cf48e3de2aae00d2d6a0c47a06695b51 Author: Linmao Li Date: Fri Jul 17 15:57:14 2026 +0800 media: chips-media: wave5: Balance runtime PM on encoder close errors [ Upstream commit 4009daa5d9a72a67dd497bb4546632b2506a3650 ] wave5_vpu_enc_close() resumes the device before taking the hardware lock. Its three error paths call pm_runtime_resume_and_get() again instead of dropping that reference. Each failure therefore increments the runtime PM usage count twice and can prevent the device from suspending afterward. Replace the extra resume calls with pm_runtime_put_sync() to balance the reference acquired on entry, matching the successful close path. This aligns wave5_vpu_enc_close() with wave5_vpu_dec_close(), which already releases the reference on its error paths. Fixes: 2092b3833487 ("media: chips-media: wave5: Support runtime suspend/resume") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b683d0501f8b74f705d776c0b6551a7d8f24f381 Author: Linmao Li Date: Fri Jul 17 15:13:15 2026 +0800 media: chips-media: wave5: Handle polling IRQ thread failure [ Upstream commit 1d563e3d718a1c7c16355843374fbdd4c798ac66 ] When falling back to polling mode, wave5_vpu_probe() does not check the return value of kthread_run(). On failure, dev->irq_thread holds an error pointer instead of a valid task pointer. Both the probe error path and the remove path only check dev->irq_thread against NULL before calling kthread_stop() on it, so an error pointer passes the check and kthread_stop() crashes on it. Check the kthread_run() result, clear dev->irq_thread and unwind the probe on failure. Fixes: e66ff2b08e4e ("media: chips-media: wave5: Fix Null reference while testing fluster") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 11b788b55f9248794f556c46ad6ff9a0246a9b4d 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 aaa44163b04f024a98123a66b4555652e8bfd2fb 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 22f5872567c51b8e7522a47a8a24bdaac6705672 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 6d8da67c1c0e673b3e25efaa0d7bd97842edd40e 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 513f62c104189eb6a9e028a21766df280f68a75d Author: Alexey Klimov Date: Wed Sep 30 00:50:31 2026 +0100 soc: samsung: exynos-pmu: fix error paths in cpuhotplug/idle states setup [ Upstream commit f7b2b6acf658be412b0c4746d07d210a9e18f13b ] The setup_cpuhp_and_cpuidle() initialisation sequence currently ignores the return values of cpuhp_setup_state(), cpu_pm_register_notifier(), and register_reboot_notifier(). If any of these registrations fail during probe() routine, the driver returns 0, leaving the driver partially configured. Furthermore, if anything after setup_cpuhp_and_cpuidle() fails in probe() routine, for instance devm_mfd_add_devices(), the probe() lacks an error path and leaves notifiers and cpu hotplug states registered. Introduce variables for the cpu hotplug state IDs in exynos_pmu_context struct, that should be initialised to CPUHP_INVALID by default. Check all return codes in setup_cpuhp_and_cpuidle(), and add an error path to remove registered states on failure. Finally, add destroy_cpuhp_and_cpuidle() helper to safely tear down notifiers and cpu hotplug states. Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org?part=3 Fixes: 78b72897a5c8 ("soc: samsung: exynos-pmu: Enable CPU Idle for gs101") Cc: stable@vger.kernel.org Signed-off-by: Alexey Klimov Link: https://patch.msgid.link/20260930-exynos-pmu-cpuhp-idle-fixes-v3-1-4269d8425978@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 94829b1235137abeec22e27018b0a4f86cea2cd2 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 8f8319e45493fe7af0e558d9026b5099650bcd09 Author: Kim Phillips Date: Mon Aug 31 16:09:16 2026 -0500 x86/bugs: Fix CONFIG_MITIGATION_RETPOLINE=n mitigation reporting [ Upstream commit 1847c80537891baead3975f3ca969233ff7b2a11 ] When the kernel lacks retpoline support, spectre_v2_select_retpoline() emits "Kernel not compiled with retpoline; no mitigation available!" before returning SPECTRE_V2_NONE to its callers. SPECTRE_V2_NONE is not the final answer, though: spectre_v2_update_mitigation() runs afterwards and can still upgrade the mitigation. On an Intel CPU affected by RETBleed, built with CONFIG_MITIGATION_IBRS_ENTRY=y and CONFIG_MITIGATION_RETPOLINE=n, and booted with spectre_v2=auto, retbleed_select_mitigation() picks RETBLEED_MITIGATION_IBRS, and spectre_v2_update_mitigation() then promotes SPECTRE_V2_NONE to SPECTRE_V2_IBRS. The boot log claims no mitigation is available immediately before reporting "Spectre V2 : Mitigation: IBRS", and sysfs reports the machine as mitigated. The message is alarming and simply wrong. Drop "no mitigation available!" because the final mitigation state is printed afterwards in spectre_v2_update_mitigation() anyway. [ bp: Drop CC:stable, massage commit message. ] Fixes: 480e803dacf8 ("x86/bugs: Restructure spectre_v2 mitigation") Suggested-by: Pawan Gupta Assisted-by: LLM Signed-off-by: Kim Phillips Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Pawan Gupta Link: https://patch.msgid.link/20260831210916.987152-1-kim.phillips@amd.com Signed-off-by: Sasha Levin commit 21b1af61dafd5e7c8583a38860babe768f5f5536 Author: Fuad Tabba Date: Thu Oct 1 14:56:55 2026 +0100 KVM: arm64: Validate the host vCPU's VM before reading it under pKVM [ Upstream commit cf533b4d3630b229d78ad55567c5db2f365052a2 ] On an MTE-capable host under pKVM, enter_exception64() reads the VM's MTE flag through vcpu->kvm, which for a host vCPU is a host-writable pointer nothing validates. The host can point it at any address in the hyp linear map and read back bit 1 of that word through PSR_TCO in the vCPU's CPSR, or panic the hypervisor with an unmapped one. Get the VM through a get/put pair around the read: a loaded vCPU's is the hyp VM, an unloaded host vCPU's is read once and pinned, and a pointer the host never shared leaves TCO clear. Fixes: ea7fc1bb1cd1b ("KVM: arm64: Introduce MTE VM feature") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260914070536.877D91F000FF@smtp.kernel.org/ Reviewed-by: Vincent Donnefort Reviewed-by: Joey Gouly Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20261001135711.1640520-3-fuad.tabba@linux.dev Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 8e9628f42c7c91c973420ec90f2ce7930f7bac68 Author: Jérémy Jean Date: Sat Sep 26 20:43:26 2026 +0000 crypto: ecc - Handle exceptional points in Shamir multiplication [ Upstream commit 6fd70bc8bc01a578c7728b7bd1cb5689c62cc5b7 ] Shamir multiplication mishandles equal points, opposite points and the point at infinity. This rejects valid ECDSA signatures and can accept invalid digest/signature tuples when the public key is G or -G. The kernel incorrectly rejects 16 valid signatures from Wycheproof. Handle doubling, cancellation and the point at infinity in precomputation and accumulation. Add regression tests for P-256 ECDSA and 256/512-bit EC-RDSA. The valid vectors are Wycheproof P1363 secp256r1/SHA-256 cases 60 and 210 converted to X9.62, two constructed ECDSA signatures for Q = +/-G with k = 2, and six constructed EC-RDSA signatures for Q = G, -G and -2G. Also add two invalid P-256 digest/signature tuples for Q = +/-G that must return -EKEYREJECTED. Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Jérémy Jean Reviewed-by: Ignat Korchagin Reviewed-by: Stefan Berger Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5ecd94581c322d6998f50c32e4fa00f935847059 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 5393887ab975d2bfcda12283613bc4e03f1f7d0b 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 99cfdc3715846ce5ba03441decfce1eb83dade17 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 987b7053bde1769caef4816ddedf68ffe84f4711 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 f3e503a31d3cfdc8fae1baeb0ad5ba8471ceea9d 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 72af96b39afd6faa77d037080a15405336acd05c 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 3c379310c8b80e0f753d4cc1755919441f626f5a 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 59e69a73f9b2ac2599218a9e16884c3fdf879275 Author: Runyu Xiao Date: Wed Sep 30 14:59:51 2026 +0800 block: amiflop: synchronize flush timer before track flush [ Upstream commit 9690943353cec1690a715e000ba6a74e5139f530 ] The amiflop track buffer is shared with the timer callback. timer_delete() does not wait for an in-flight callback, and that callback can rearm itself when it cannot acquire the floppy controller. A synchronous track flush can therefore race with the callback. Stop the timer before synchronous track writes and use timer_delete_sync() to wait for any callback already running. Keep callback rearming disabled until the write is complete. Apply this to the FDFMTTRK path as well. FDFLUSH, FDFMTTRK and close-time flushes run outside the blk-mq request callback. Freeze their queues so an in-flight request cannot change the shared track buffer while it is encoded and written. Restart the timer if a track remains dirty after a failed flush. 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/20260930065951.2932739-1-runyu.xiao@seu.edu.cn Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9a3288b2380d5904c1a9f0352bdee4b4ef452460 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 aaed8f7c2a65319745bd969e2e2dbbd13a2e45dc Author: Danish Khateeb Date: Tue Sep 29 07:49:36 2026 -0500 pps: generators: stop the generator on unregister [ Upstream commit 3e75af9f41c7509884d0955245dec2b791287e8c ] Both generator drivers stop their timer and then call pps_gen_unregister_source(): pps_gen_tio_remove() cancels its hrtimer and disables the TIO, and pps_gen_dummy_exit() deletes its timer. But /dev/pps-genN and the sysfs "enable" attribute are still there until the unregister, and a PPS_GEN_SETENABLE or a write to "enable" in between starts the timer again. Nothing stops it after that: TIO's hrtimer keeps running in the devm memory freed by the unbind, and the dummy's timer is left in the unloaded module. The drivers can't avoid this by unregistering first, as TIO's timer callback uses pps_gen, which the unregister may free. Stop the generator in pps_gen_unregister_cdev() instead, under info_lock after the device and its sysfs files are gone, when nothing can enable it again. pps_gen_unregister_source() then also does what its kernel-doc says: "it disables the generator so no pulses are generated anymore". Fixes: 86b525bed275 ("drivers pps: add PPS generators support") Cc: stable@vger.kernel.org Suggested-by: Rodolfo Giometti Assisted-by: LLM Signed-off-by: Danish Khateeb Acked-by: Rodolfo Giometti Link: https://patch.msgid.link/20260929124937.51114-4-danishkhateeb03@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2ea73c70014ff7839549a5eda350b00ecddba4c4 Author: Vincent Donnefort Date: Mon Sep 28 10:54:50 2026 +0100 KVM: arm64: Fix MMFR0 TGRAN advertisement for pVMs [ Upstream commit 6c29285e78b5e4811145ebda382ac0ba732ce56a ] Protected VM ID register emulation leaves unlisted fields at 0. This creates two issues for TGRAN: * TGRAN16: 0 means non-implemented. It prevents 16KB protected VMs from booting even when the hardware supports it. * TGRAN4|TGRAN64: 0 means implemented. This may falsely advertise the feature even when the hardware does not support it. Advertise all the TGRAN fields in pvmid_aa64mmfr0 so that the hardware support is properly propagated. Cc: stable@vger.kernel.org Fixes: 6c30bfb18d0b ("KVM: arm64: Add handlers for protected VM System Registers") Signed-off-by: Vincent Donnefort Tested-by: Fuad Tabba Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Reviewed-by: Fuad Tabba Link: https://patch.msgid.link/20260928095454.3255918-2-vdonnefort@google.com Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit bfef7c3b8be1f1838177df659643a82400d29b14 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 33fedef97da9691dbadda81df8becad84033ae21 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 6f3e29d421deb09aa8a8819fd62fd8dda9cac78e 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 8b8734f39f524ed792d7f4a01f5a4ffe57ace9b7 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 a05de3e14079f75fbe56f0e8401c42b63b0dc187 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 affc1ebd65f517897f1c092fb87f2c42f0fc41f5 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 ecf511b8157e0648080bdae37f4f2eb98328c4b2 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 84ec201511634bc04fe850c9552211d2ef4f2662 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 e4686b15bb97fe56231b12dcc309b68d1e586775 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 f8f37e179859d95a6dbd2c867d99125a2e5cbd74 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 c1b1e81ed8b2bae7299243c5722332451b0c3338 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 07a1b080c5a514449406f4c5842e6dd0d7b8b0df 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 d28f100d9975ecb74cd9dd3651251d52c2821873 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 c4a692585615f76c8ac421015285cfd13a2f0969 Author: Wentao Liang Date: Wed Sep 16 17:57:38 2026 +0000 drm/msm/dsi: Fix VM leak in dsi_tx_buf_alloc_6g() [ Upstream commit ab91ba61871a896ca2ecc6e048d80a152136da44 ] dsi_tx_buf_alloc_6g() takes a reference to the kms VM with drm_gpuvm_get() and stores it in msm_host->vm. If msm_gem_kernel_new() fails, the function returns early without dropping that reference. Since msm_host->tx_gem_obj is cleared on the error path, msm_dsi_tx_buf_free() will never see a non-NULL tx_gem_obj and thus never calls drm_gpuvm_put(), leaking the VM reference. Drop the VM reference and clear msm_host->vm on the error path. Fixes: 5e05be782645 ("drm/msm/dsi: free TX buffer in unbind") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/754332/ Link: https://lore.kernel.org/r/20260916175738.2089950-1-vulab@iscas.ac.cn Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit fd021c57e2c6a673ef9b66a54605a988d8925213 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 96c66a1ef82384ea302fc571509a3c5bf3bb2280 Author: Krzysztof Kozlowski Date: Fri Sep 11 12:29:35 2026 +0200 drm/msm/hdmi: Handle msm_hdmi_power_on() errors during .atomic_pre_enable() [ Upstream commit dd6ecace57851878e62367a6f1a26dd5b9aa217f ] Properly handle power up failures during .atomic_pre_enable() by aborting the .atomic_pre_enable() to avoid accessing registers why blocks did not bring up. Otherwise this could lead to imprecise aborts when accessing MMIO while entire power domain is off. Cc: Fixes: ba3d7bf3a7ab ("drm/msm/hdmi: Convert PHY files according to new design") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/752652/ Link: https://lore.kernel.org/r/20260911-drm-msm-hdmi-fixes-before-eliza-v4-2-87bdb9f1987f@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 41f7b9cd503ebc6bd624e5200ab7d2f03d1ad7a2 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 d4e9b82ddc6fded1bbcc0b7453fce6b06738ff0b Author: Fan Wu Date: Wed Sep 23 08:53:40 2026 +0000 i3c: master: adi: free the IRQ before unregistering the master [ Upstream commit 1c1e2d90aa452764df66bb1dd774aa0d06d89cc8 ] adi_i3c_master_irq() is requested with devm_request_irq(), so it stays registered when adi_i3c_master_remove() runs, and the writes masking the controller IRQ sources do not synchronize with a handler that is already running on another CPU. i3c_master_unregister() then frees the struct i3c_dev_desc objects that master->ibi.slots[] still point to, so the IBI path in adi_i3c_master_handle_ibi() can dereference freed memory. Fix this by storing the IRQ number in the private structure and calling devm_free_irq() after the IRQ sources are masked, so a running handler is finished before the master is torn down. This issue was found by an in-house static analysis tool. Fixes: a79ac2cdc91d ("i3c: master: Add driver for Analog Devices I3C Controller IP") Cc: stable@vger.kernel.org Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Frank Li Link: https://patch.msgid.link/20260923085340.490776-1-fanwu01@zju.edu.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 6266517f52b61a7e522fd2e5bae7ddb1bd8c0a42 Author: Runyu Xiao Date: Wed Sep 30 15:04:55 2026 +0800 IB/hfi1: Shutdown self-rearming timers before freeing [ Upstream commit 9d3259e41ccd5016cd2c6d013232b89df6d73011 ] The HFI1 receive error and synthetic counter timers rearm themselves from their callbacks. Their cleanup paths use timer_delete_sync(), which only waits for a running callback and does not prevent a concurrent or subsequent rearm. Use timer_shutdown_sync() when releasing these timers. This prevents a callback from enqueueing either timer after cleanup begins, before the containing hfi1_devdata is freed. Preserve the existing work cancellation and workqueue destruction ordering for synthetic counters. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260930070455.2934286-1-runyu.xiao@seu.edu.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9313727ad7f02c6e73af625c17758be7df027f77 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 5906e880cdf55ab7ebc2bf6446c543c7cfef2a89 Author: Ryusuke Konishi Date: Wed Sep 30 03:26:54 2026 +0900 nilfs2: ignore non-fatal signals during synchronous log write wait [ Upstream commit 7131aaa74bcc7c9da1f1d1c8724da75c775557a0 ] Based on a syzbot report, Wang Jianjian pointed out that following a successful directory operation in nilfs_rename(), a synchronous write requested within nilfs_transaction_commit(), triggered by a sync flag set by nilfs_commit_chunk(), could be interrupted by a user signal. This interruption leaves in-memory metadata updates intact while returning an error, causing inconsistency with the VFS dentry cache and ultimately triggering a kernel warning. According to "signal(7)", local disks are not classified as "slow devices" (such as terminals, FIFOs, or pipes) and their I/O operations on disk devices are not interrupted by signals. In kernel space, waiting for such disk I/O should therefore not be aborted by ordinary (non-fatal) signals. Suppress this issue by modifying nilfs_segctor_sync(), which waits for the log writer thread to complete synchronous writes, to catch only fatal signals via fatal_signal_pending() and return -EINTR rather than -ERESTARTSYS. To complement this change and prevent the wait loop from busy-looping when schedule() returns immediately due to a pending non-fatal signal, switch the wait state from TASK_INTERRUPTIBLE to TASK_KILLABLE. This serves as an effective interim stabilization measure without structural changes until a comprehensive fix for metadata consistency is implemented. Reported-by: syzbot+f6c7e1f1809f235eeb90@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f6c7e1f1809f235eeb90 Fixes: 9ff05123e3bf ("nilfs2: segment constructor") Tested-by: syzbot+f6c7e1f1809f235eeb90@syzkaller.appspotmail.com Cc: Wang Jianjian Cc: stable@vger.kernel.org Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 1a84e432d44262c36ae3dcc2aa6331a879ba1612 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 be094322526a406419180cc74967d441d59ef346 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 19f0f175168ef8b670dabbb14092e82b6a3542bc 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 7e149d7105694503921ba29be5bef2beb507cc6f 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 7a7140990a00482e5f58a86c7b2848f028614e5d 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 3cc77e135802aa41181eb3f4c080f3675b814f93 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 4e535f89527546014be998cbac602dc937de8fea 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 77f1aeef96b91de1a94b5a014ad9dcfc1ef913df 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 35530d26230b1ed9f2a1fbd082f8855d2d4a5ed7 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 a14c5fffca888f55b518260492370bd93eb71aee 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 e6bceb2fb629d582b96d54eaf5b7f40877608a22 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 6aa325b8aea61a8421a972fed49323ea44da8d2f Author: Vishnu Reddy Date: Tue Aug 18 21:24:18 2026 +0530 media: iris: Fix frame interval enumeration for non-divisor framerates [ Upstream commit 3ad393b701dd99274f09403185f71ec7a93135bd ] iris_enum_frameintervals() advertised frame intervals using V4L2_FRMIVAL_TYPE_STEPWISE with step=1/MAXIMUM_FPS where MAXIMUM_FPS is 480. This caused client to enumerate only framerates of the form MAXIMUM_FPS/n (where n is a positive integer), restricting support to exact divisors of MAXIMUM_FPS (e.g., 480, 240, 160, 120, 96, 80, 60, 30, 24, 1). Framerates that are not exact divisors of MAXIMUM_FPS, such as 29 fps, 25 fps, were excluded from the enumerated list. There is no hardware restriction to framerates that are exact divisors of MAXIMUM_FPS. This caused GStreamer caps negotiation to fail with an "internal data stream error" when encoding content at such framerates. Fix this by using V4L2_FRMIVAL_TYPE_CONTINUOUS. With CONTINUOUS type, GStreamer creates a continuous framerate range [1, max_fps], allowing any integer framerate within the range to pass caps negotiation. The step field is set to 1/1 as required by the V4L2 specification for continuous frame intervals. Fixes: a6882431a138 ("media: iris: Add support for ENUM_FRAMESIZES/FRAMEINTERVALS for encoder") Cc: stable@vger.kernel.org Reviewed-by: Bryan O'Donoghue Signed-off-by: Vishnu Reddy Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit 4b1e1db849f7542a1896da1f35f26da72475c709 Author: Vishnu Reddy Date: Tue Aug 18 21:43:51 2026 +0530 media: iris: Fix bus_info prefix in VIDIOC_QUERYCAP [ Upstream commit 1facae9bc3c1cfcabc77184754d64c349831cbc5 ] The bus_info field returned by VIDIOC_QUERYCAP used the abbreviated prefix "plat:" instead of the standard "platform:" prefix expected for platform devices. v4l2-compliance validates that bus_info for platform devices starts with "platform:", and fails otherwise: fail: ../utils/v4l2-compliance/v4l2-compliance.cpp(671): missing bus_info prefix ('plat:aa00000.video-codec:dec') Update the format string in iris_querycap() to use "platform:" so that v4l2-compliance bus_info check passes. Fixes: 94ef75095d5e ("media: iris: Enumerate cap->bus_info to differentiate between encoder and decoder") Cc: stable@vger.kernel.org Signed-off-by: Vishnu Reddy Reviewed-by: Vikash Garodia Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit 5880a91e8119488d4e6f788eb4f1f7cec62ff3a5 Author: Vishnu Reddy Date: Tue Aug 18 20:43:23 2026 +0530 media: venus: Fix iova allocation from restrict region [ Upstream commit 953439251b596cee039fbfeaffeb1d88a4b40f43 ] The VPU issues DMA through several SMMU streams, and the hardware does not give every stream the same addressable range. The non-pixel stream cannot address the low 600MB of IOVA space, while the pixel stream can address the full range: +-----------------------------------------------------------+ | non-pixel stream addressable range (600 MB - 3.5 GB) | | 0x25800000 - 0xe0000000 | +-----------------------------------------------------------+ | pixel stream addressable range (0 - 3.5 GB) | | 0x00000000 - 0xe0000000 | +-----------------------------------------------------------+ A single "iommus" property on the video-codec node puts every stream in one IOMMU domain sharing one IOVA space, so nothing stops a non-pixel buffer from landing below 600MB. Once an allocation lands below that boundary the hardware faults, which shows up as unhandled SMMU page faults and spontaneous reboots. https://gitlab.freedesktop.org/drm/msm/-/work_items/100 Fix this by reserving the 0-600MB range, below the boundary the non-pixel stream cannot address, using dma_iova_try_alloc() so the IOMMU-DMA core never hands that range out to a real DMA mapping. This reserves only IOVA space, it does not allocate any physical memory. Since sub-nodes for non-pixel, pixel, and secure streams do not exist yet and only a single device is available, the restriction is applied to both non-pixel and pixel stream IDs. Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") Cc: stable@vger.kernel.org Reviewed-by: Vikash Garodia Reviewed-by: Dmitry Baryshkov Signed-off-by: Vishnu Reddy [bod: took iova_state description from iris and applied to venus in core.h] Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit 8e1efcccc8284d20ce70ac158e8c6b095c6439a8 Author: Hans de Goede Date: Thu Jul 23 13:09:50 2026 +0200 media: qcom: camss: Add "gcc_axi_hf" to 8775p VFE lite clock lists [ Upstream commit 583b27edfe669fe27c631b4ac77c0ce0250f7bba ] The "gcc_axi_hf" clock is correctly listed in the clock list of the 8775p 2 main VFE-s, but it is missing from all the VFE-lite clock lists, causing these to not work on platforms where the firmware allows turning off "gcc_axi_hf". Add the missing "gcc_axi_hf" to fix the VFE-lite blocks not working on these platforms. Fixes: 924f45e58b1fe ("media: qcom: camss: Add missing clocks for VFE lite on sa8775p") Cc: stable@vger.kernel.org Suggested-by: Wenmeng Liu Reviewed-by: Bryan O'Donoghue Signed-off-by: Hans de Goede Tested-by: Cory Keitz Reviewed-by: Loic Poulain Reviewed-by: Vladimir Zapolskiy Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit f73b13bd811b876f9481697e9b197f28ad11e646 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 eef4734a50d6c9145999f17b391c81e7ae1bc1c1 Author: Hitesh Patel Date: Mon Sep 28 17:45:04 2026 +0530 media: qcom: camss: vfe-17x: Fix write master selection for RDI lines [ Upstream commit fc02156a3efb747b724a490cc50e1ad8c28a3b23 ] On the gen2 VFE bus there is no crossbar between the RDI paths and the bus write masters: RDI n is served by write master n. The common vfe_get_output_v2() reflects this by mapping line->id to write master line->id, and every gen2 VFE except 17x uses it. The 17x code kept its own vfe_get_output(), which reserves whichever write master is free first. That happens to be the right one as long as a single line streams and it is RDI0. As soon as two lines of the same VFE stream, for instance two virtual channels demultiplexed by the CSID to RDI0 and RDI1, the second line to start is given the write master of the other RDI. Both write masters are then programmed with the buffer address and frame size of the wrong line. The frames are truncated to the smaller of the two buffers and the SMMU faults on the larger one. Use vfe_get_output_v2() on 17x like the other gen2 VFEs and drop the duplicate. This also removes an error path that released output->wm_idx[0] before it had been assigned. The gen1 VFEs are not affected: they have a bus crossbar and any write master can serve any line, so vfe_reserve_wm() is correct there. 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 01cc89543a136c799fa5ca36dd71b7d3b0cd83ee 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 b0f54c804cc0f8ea47ffef685de9c01666233e43 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 5352e7447219bf7777aa0cffe0752f655d9a0060 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 6cea6cc1731b00b2879ec64a6dd6f2e7dc03ae45 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 621cb2fe38d5a2ba3c833b1d96607e089a144fba 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 f5977b1359625cdc6dd9130243af2019ca630992 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 5381f1c9be61b7da2844ba118978959e5fd1694b 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 8953416b6218474aaaf61f2ff38b50ad32a7d64e 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 e5290017ad1c046554705c0b22dec97796dad02e 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 3c35aa8d9ead9906b8f4a04d15416e36f3302743 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 f4ca846273cfe403f2907215e85c4db21b00ffbd Author: Jiale Yao Date: Fri Sep 25 20:57:40 2026 +0800 iio: adc: ad7606: reject devices without match data [ Upstream commit 7830650d5293a0f412a869225262ca51b661e49f ] 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. ad7606_spi_probe() dereferences the returned bus information to pass the chip information and bus operations to the core, 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 entering the core. Fixes: bc69e9fffde4 ("iio: adc: ad7606: Add compatibility to fw_nodes") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 2d3d960463e0c0778faf242f64e49506eaa9952d 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 b46ccd625f991caf8d47929c1c2aebae4ada9754 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 aafccd547ea2a330120ade63677a06dccd138282 Author: Jiale Yao Date: Fri Sep 25 21:17:34 2026 +0800 iio: imu: adis16400: validate SPI match data [ Upstream commit 2c01a0a1c5550b4f502c7747c06d2e57a240cd87 ] 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 adis16400_probe() immediately dereferences the result. Validate the match data before it is used. Fixes: 2ef920e0e5c0 ("iio: imu: adis16400: Use separate structures rather than an array for chip info") Signed-off-by: Jiale Yao Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit a3978818956647cea11dd12cede3c6c008a63edf 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 1b8bf087120529f811d2691b21fa35fc15f08dca 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 757e0634790ea7745b95097a7658c8fedc90e2eb 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 ef6d993762b2198a098f2a82a0da7c29418aad5b Author: Runyu Xiao Date: Sun Sep 27 17:38:09 2026 +0800 ALSA: mpu401: shut down timer before freeing MPU [ Upstream commit 9332af5220d42341bb1446a62c545c0518e990ef ] When an MPU401 interface has no usable IRQ, the driver polls raw-MIDI input and output with a timer. During raw-MIDI teardown, the timer callback can already be running when snd_mpu401_uart_remove_timer() clears the last mode bit and calls timer_delete(). That API neither waits for a running callback nor prevents it from rearming the timer, and free_irq() does not synchronize timer callbacks. snd_mpu401_uart_free() can therefore release mpu while the timer callback still uses it. Initialize the timer once when the MPU object is created and only rearm it while a timer mode is active. Shut it down synchronously after freeing the IRQ so an in-flight callback completes before mpu and its resources are released. 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/20260927093809.681726-1-runyu.xiao@seu.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e8168221d3c7d05b6533a36d9395aa27c578cba8 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 ae75a827b6fdaac38d52981632c019121c3c1b4f Author: Kathiravan Thirumoorthy Date: Mon Sep 21 11:49:37 2026 +0530 arm64: dts: qcom: ipq9574: Wire up USB3 PHY PIPE clock to GCC [ Upstream commit 117d8d40be1ded4f35f3252efa83607a7134d5e0 ] Connect the QMP PHY USB3 output to GCC so the USB3 PHY pipe clock can propagate to the USB controller. Cc: stable@vger.kernel.org Fixes: a98bfb31f676 ("arm64: dts: qcom: ipq9574: Add USB related nodes") Reviewed-by: Konrad Dybcio Signed-off-by: Kathiravan Thirumoorthy Reviewed-by: Abel Vesa Link: https://patch.msgid.link/20260921-ipq_clk_changes-v1-4-d242e3d49648@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2597827c1f9b240e55280ed581dc1fa3438a33d9 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 36c5520124515babba0615c2c8748206d3dc47bc 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 f373581d54225fa09196bd3d907c83820aeb4955 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 6407390b5aa1303536508c37a054696bdd30598f 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 b37f9d7dbb25d71f16bae7f38197db4abb7a4ba7 Author: Orgad Shaneh Date: Tue Sep 15 07:13:24 2026 +0000 MIPS: mm: align hugetlb mappings in arch_get_unmapped_area() [ Upstream commit 975d4a6a6d4d23a39e2f49cafcc082d937960bc4 ] Since hugetlb mappings were made to go through the architecture's arch_get_unmapped_area{,_topdown}(), every architecture that implements those has to align hugetlb files itself. The generic implementation and loongarch do it with huge_page_mask_align(); MIPS was left out. A non-MAP_FIXED mmap() of a hugetlbfs file therefore returns an address that is only SHMLBA aligned, and the kernel then installs 2 MB PMDs for a VMA that starts in the middle of a PMD. The consequences on an Octeon (CN63XX) board running a process that links libhugetlbfs with HUGETLB_ELFMAP=R and HUGETLB_MORECORE=yes, all within a minute of start: the neighbouring 4 KB page table is clobbered, the TLB ends up with overlapping entries ("Caught Machine Check exception - caused by multiple matching entries in the TLB"), process exit trips BUG_ON(start & ~huge_page_mask(h)) in __unmap_hugepage_range(), and freed pages leak into unrelated kernel structures (oopses in the irq maple tree, in pte_offset_map, ...). Do what loongarch does in commit 3109d5ff484b ("LoongArch: Set hugetlb mmap base address aligned with pmd size"): when the file is a hugetlb file, use its page mask as the search alignment instead of the cache colour mask. Fixes: 7bd3f1e1a9ae ("mm: make hugetlb mappings go through mm_get_unmapped_area_vmflags") Cc: stable@vger.kernel.org # 6.13+ Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 22ab7528546668f06a9c1b5ec1360ce197dc2da4 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 730424642a1719e3b5f080ffecb0aa2bdffbfce7 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 10867cbc902e6bd568063767abbb1f940c497aa4 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 e2f717de9bf3673306a4a4ec36c3856bbf1ffbb1 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 07d54cfeba41db246bf72642fc8516aa5f265c0e 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 08e9f9476a80574a5053f4b12bb64d514e949f59 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 2b8b388320fa3cacbf0444ec2eccf7534b96cd4b 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 23852ad0f72a62ab1cf20a69c35cbf00f792f364 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 9544576610d5d5aa20f41239040aaf7dc1cfb4c9 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 433fe9882befbe12e8f560b5818799651654bcba 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 9975c8d2d03e1e5317430d4d87386965d471869f 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 b0d4ff46a2195320957de9e8981313fe7da9c988 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 d977046bcfbfab830b3e8b92f3f11ffdbaf54e68 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 42e84c6ec7a1c9b78ef09cc7b75e481c1dc15775 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 b93e351abe15eacc578d7401dc9738f2b6c62bf6 Author: Guangshuo Li Date: Wed Sep 16 00:45:37 2026 +0800 mtd: rawnand: nuvoton: fix clock cleanup on probe failure [ Upstream commit 8a485a40f45a19c5fcafb5cbee7387c2762af7c4 ] ma35_nand_probe() gets and enables the NAND clock with devm_clk_get_enabled(), but the ma35_nand_chips_init() failure path also calls clk_disable() before returning. devm_clk_get_enabled() registers a managed cleanup that calls clk_disable_unprepare() on probe failure and driver removal. Calling clk_disable() explicitly first drops the clock enable count, so the managed cleanup attempts to disable the clock again and triggers the clock framework warning for an already disabled clock. Remove the redundant clk_disable() and let the managed clock cleanup handle the clock state. This issue was found by manual code inspection. Fixes: 5abb5d414d55 ("mtd: rawnand: nuvoton: add new driver for the Nuvoton MA35 SoC") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 1cf4c1c5ab6ea5502c3f1bfd96dabc8484d720ba 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 81f311ccfd77de3596e841af149dd06183a832ec Author: Joanne Koong Date: Tue Sep 15 16:53:41 2026 -0700 fuse: don't drop destination page cache on a zero byte copy reply [ Upstream commit f7585e1ce3418ec282485854b3d8d31c6a961e37 ] __fuse_copy_file_range() clears the destination page cache after the server replies: truncate_inode_pages_range(inode_out->i_mapping, ALIGN_DOWN(pos_out, PAGE_SIZE), ALIGN(pos_out + bytes_copied, PAGE_SIZE) - 1); A server may legitimately reply that it copied nothing, eg if the source file turns out to be shorter than the size the kernel has cached for it. If pos_out is 0 as well, the end of the range is ALIGN(0, PAGE_SIZE) - 1, which is -1. lend is a uoff_t and truncate_inode_pages_range() takes -1 as its end of file sentinel, so rather than clearing nothing it drops every folio in the destination mapping. That is not only a cache drop. truncate_cleanup_folio() calls folio_cancel_dirty(), and fuse_writeback_range() only wrote back [pos_out, pos_out + len - 1], so dirty data elsewhere in the destination file is discarded without ever reaching the server. Skip the call when the server copied nothing, since there is nothing stale to clear in that case. Fixes: 9b46418c40fe ("fuse: copy_file_range should truncate cache") Cc: stable@vger.kernel.org Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 7350d86fe19877d95233867dec28b5321c27bce0 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 07909b53a81ea6ec1b6e1e212f33659acd8d1eb6 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 aba82b403719fca667b031d3154164cb5f694647 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 e043acd7535f59ff58fe02caeba30930796478d3 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 9ce18befc89449b92b48a12bea2c26dd03ab8ad6 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 f622c427fab09a106b6b1208a31802c9138b614d 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 582a0631a00df91e6fc3bbdfc21dfbc77c9bb825 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 239d333dedc263083734af7cdd635fb21d64a4b4 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 f2a360ec9f6c316dbd3bf1da00328d2ee618b4ad 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 845d3107c2fa1b04f70e624c597d78114d5d3094 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 95e47d590f04afd734dd1aa2cb81b09c1534a0ed Author: David Heidelberg Date: Thu Aug 27 16:27:41 2026 +0200 mfd: Fix MAX77705 dependency on regmap [ Upstream commit 2fdae2d590a0a5ad4cd60bf8e7a6ecba7265f268 ] The max77705 uses devm_regmap_add_irq_chip(), so add REGMAP_IRQ and REGMAP_I2C to what the core driver selects in order to provide these APIs. This fixes a build error: drivers/mfd/max77705.o: in function `max77705_i2c_probe': max77705.c:(.text+0x250): undefined reference to `devm_regmap_add_irq_chip' Cc: stable@vger.kernel.org Fixes: c8d50f029748 ("mfd: Add new driver for MAX77705 PMIC") Signed-off-by: David Heidelberg Link: https://patch.msgid.link/20260827-deps-reg-max77705-v1-1-c83a74d3d428@ixit.cz Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 7990fad78c398883b22128ea104c561ba53603e9 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 eea47a6e5b84944938e009197a0f44387204a714 Author: Casey Connolly Date: Tue Sep 8 14:45:02 2026 +0200 drm/panel: ebbg-ft8719: Set prepare_prev_first [ Upstream commit 4eeeac9d7c3600a6cae75b2a7bc9c5b67530923c ] This corrects the host initialisation sequence so that we can send DSI/DCS commands in prepare(). Cc: stable@vger.kernel.org Fixes: b00de0e237da ("drm/panel: introduce ebbg,ft8719 panel") Signed-off-by: Casey Connolly Tested-by: Marco Mattiolo Reviewed-by: Neil Armstrong Signed-off-by: David Heidelberg Reviewed-by: Linus Walleij Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260908-ebbg-ft8719-fixups-v2-1-5454ae1f5581@ixit.cz Signed-off-by: Sasha Levin commit 23091956b96971f0628afb176dc35b6d7b38dd9a 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 bdd8930eb7414de2f85a54c43ef501c12b1e2c30 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 0d1d31a3e35cb79c89de121134825796808143f3 Author: Francesco Dolcini Date: Tue Sep 15 22:14:10 2026 +0200 arm64: dts: freescale: imx8mp-toradex-smarc: fix SMARC_SLEEP# gpio-line-names typo [ Upstream commit 90bc5a53c7f0733ec37a5c041b4e1aefa3d8d965 ] gpio3's gpio-line-names has "SLEEP#" instead of "SMARC_SLEEP#" for the SMARC SLEEP# connector signal, while the gpio-keys node driven by the very same GPIO line already labels it "SMARC_SLEEP#", and the imx95 Toradex SMARC variant names the equivalent line "SMARC_SLEEP#" too. GPIO line names are meant to be stable across the whole Toradex SMARC family, using the official SMARC-connector signal names from the SMARC specification and the SoM datasheet's pin assignment table, so userspace GPIO tooling that looks up a line by name works the same on any Toradex SMARC board. Fixes: 97dc91c04558 ("arm64: dts: freescale: add Toradex SMARC iMX8MP") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Francesco Dolcini Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit f2c6b74e201d3997a454f59bb94e471df5a22cef Author: Francesco Dolcini Date: Wed Sep 16 10:40:23 2026 +0200 arm64: dts: freescale: imx8mp-verdin-ivy: fix DIGI_1/DIGI_2 gpio-line-names [ Upstream commit cb45264c27fad31f7c58fbb1a5c2f7ec16018dae ] gpio3's gpio-line-names names the two Ivy digital inputs "DIG_1" and "DIG_2", while the official Ivy Carrier Board datasheet (Section 2.10, Table 12) names them DIGI_1 and DIGI_2, matching the k3-am62-verdin-ivy.dtsi variant for the same carrier board pins. GPIO line names are meant to be stable across the whole Verdin family and its carrier boards, so userspace GPIO tooling that looks up a line by name works the same regardless of which Verdin SoM is fitted on Ivy. Fixes: b98948b04295 ("arm64: dts: freescale: imx8mp-verdin: Add Ivy carrier board") Cc: stable@vger.kernel.org Link: https://docs.toradex.com/116799-ivy_carrier_board_datasheet.pdf Assisted-by: LLM Signed-off-by: Francesco Dolcini Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit f9077408c7653299199da84788da25c80e604341 Author: Francesco Dolcini Date: Wed Sep 16 10:40:22 2026 +0200 arm64: dts: freescale: imx8mm-verdin-ivy: fix DIGI_1/DIGI_2 gpio-line-names [ Upstream commit 28cec01a2be2cf1e20aabd435f250f665ce24c8e ] gpio3's gpio-line-names names the two Ivy digital inputs "DIG_1" and "DIG_2", while the official Ivy Carrier Board datasheet (Section 2.10, Table 12) names them DIGI_1 and DIGI_2, matching the k3-am62-verdin-ivy.dtsi variant for the same carrier board pins. GPIO line names are meant to be stable across the whole Verdin family and its carrier boards, so userspace GPIO tooling that looks up a line by name works the same regardless of which Verdin SoM is fitted on Ivy. Fixes: adca46171ff7 ("arm64: dts: freescale: imx8mm-verdin: Add Ivy carrier board") Cc: stable@vger.kernel.org Link: https://docs.toradex.com/116799-ivy_carrier_board_datasheet.pdf Assisted-by: LLM Signed-off-by: Francesco Dolcini Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 423c58547179873f708b962122fa47308769fcb8 Author: Diego Fernando Mancera Gomez Date: Thu Sep 17 17:59:25 2026 -0600 memory: stm32_omm: fix child clock leak on set_amcr() error path [ Upstream commit a22355280361d2a376a2020059a2bae11e6cea10 ] When the mux is enabled, stm32_omm_configure() enables the two OSPI child clocks via stm32_omm_toggle_child_clock(dev, true); they are meant to stay enabled for the device's lifetime and are disabled again in stm32_omm_remove() and on the devm_of_platform_populate() error path. However, if the subsequent stm32_omm_set_amcr() call fails, the function jumps to the "error:" label which only calls pm_runtime_put_sync_suspend() before returning, leaving the two child clocks enabled. As this happens during probe, the error is propagated and .remove() is never called, so the clock enable references are leaked. devm_clk_bulk_get() only releases the clock handles on unwind, it does not undo clk_prepare_enable(). Disable the child clocks on the set_amcr() error path, mirroring the cleanup already done on the devm_of_platform_populate() failure path. Fixes: 8181d061dcff ("memory: Add STM32 Octo Memory Manager driver") Cc: stable@vger.kernel.org Signed-off-by: Diego Fernando Mancera Gomez Link: https://patch.msgid.link/20260917235925.44185-1-diegomancera.dev@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit d0e4425481132ee2fc4f13c44755106513ee9299 Author: Myeonghun Pak Date: Wed Sep 23 01:40:17 2026 -0400 ASoC: fsl_xcvr: free IRQ before canceling reset work [ Upstream commit 83701fdb2d8d644c547773791da48d6ecb3a5e1d ] irq0_isr() schedules work_rst on a preamble error, and reset_rx_work() touches regmap. remove() cancels that work while the IRQ is still registered, so the handler can queue it again during teardown. The IRQ is also requested before INIT_WORK() and spin_lock_init(). Probe failure does not call remove(), so freeing the IRQ leaves queued work running, and an earlier interrupt schedules uninitialized work. Initialize the lock and devm_work_autocancel() before the IRQ. Failed probe then frees the IRQ and cancels the work. Unbind frees the IRQ before cancel_work_sync() and pm_runtime_disable(). Fixes: 1e5d0f106164 ("ASoC: fsl_xcvr: reset RX dpath after wrong preamble") Cc: stable@vger.kernel.org # 6.13+ Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Shengjiu Wang Link: https://patch.msgid.link/20260923054017.93553-1-mhun512@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4f5219843098889ac4013e8a47873e98270b7041 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 76e42a29a8b520ef806b67ae99c1e76027a9aa84 Author: Lucas Sinn Date: Mon Sep 21 09:15:33 2026 +0200 media: synopsys: hdmirx: fetch colordepth before calculating pixelclock [ Upstream commit e8554ac860356f1f4cd9bce454271dce1ed35fc1 ] hdmirx_get_detected_timings() divides the TMDS clock by hdmirx_dev->color_depth, but nothing on its own path ever sets it. The only producer is hdmirx_get_colordepth(), reached solely from hdmirx_format_change() at the tail of hdmirx_wait_signal_lock(). VIDIOC_QUERY_DV_TIMINGS does not come through there. It only refuses to proceed while signal_not_lock() is true, and that reads the lock state straight out of the hardware, so it can already be false while the work ending in hdmirx_format_change() has yet to run. Query the timings in that window, on the first lock after a boot, and color_depth is still zero from devm_kzalloc(). The division does not fault. do_div() is plain C on 64 bit and arm64 compiles it to udiv, which returns zero for a zero divisor. What comes out is a pixelclock of zero, and a stitched output frame. Read the colordepth where it is used instead. Assisted-by: Claude:claude-opus-5 Signed-off-by: Lucas Sinn Signed-off-by: Sascha Hauer Fixes: 7b59b132ad43 ("media: platform: synopsys: Add support for HDMI input driver") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Osipenko Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 38a49d04e16f932f2ab08e70adbe5425d96653b7 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 163306dbd27e1c35dbaefb2f3289d47caa73bc07 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 638d1d3b9d619a74e5a0527a707e73e9d5aac7e1 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 fe100b9f57a6a5ba65d7418527d1c16452de4f55 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 dafdecfc883d4f266dc8128a640a32bcd14440ab 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 3f87db958c388c0ba2b6c06a9d8ea4ea11b04682 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 50983f1424034fed18dde43b84f69f7d64f5729a 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 d7a14af8ba0f538ba1e4d7fe42e75b7685036494 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 90379d750ee6146b8ccaf28d00e98f7708b074fd 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 5c474f8dea049c9566c37412a6dd1d57bf438e5d 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 dd443f07c3fdfbdc1a02bda1648089a51d05e123 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 97be63f3e99e53a861fb7e40a6c3bb3923c4c10b 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 ccfb1d79e90d56217d7c466184c6ba99747504a4 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 d6612d2b94c49f7d7e46942bb8cd9c1d0d20c544 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 2ea0ae7e51226694f7437a2a1853b1be43a42441 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 4b13c56f7896907e9b4e854ea376dcd1654472d7 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 15357a5ca07231c31f58b8b7f60dff0bd30433be Author: Suman Kumar Chakraborty Date: Wed Sep 16 07:55:36 2026 +0000 crypto: qat - fix error source for QAT GEN6 transmit interface faults [ Upstream commit eeaf1ccd4c05d9c6ad67345862b36670e8e4dfc2 ] TI_CD_PAR_STS faults were being decoded under ERRSOU1, which is incorrect for QAT GEN6 devices. They are actually raised on ERRSOU3. Move the handling of TI_CD_PAR_STS faults as part of the ERRSOU3 logic and split the status bits by their actual source: - Bits 0-18 (TI_INT_ERR_DEVHALT) handled when a DEVHALT is signalled and are counted once as ADF_RAS_FATAL. - Bit 19 (TIMISCSTS) handled separately and counted as ADF_RAS_UNCORR. Previously, a TI_INT_ERR_DEVHALT fault also incremented ADF_RAS_UNCORR in addition to ADF_RAS_FATAL. Since a DEVHALT is already fatal, remove the redundant increment. Bits 20-25 of TI_CD_PAR_STS are unused/reserved on QAT GEN6. Remove them from the mask. Cc: stable@vger.kernel.org Fixes: 7f3401d0a506 ("crypto: qat - enable RAS support for GEN6 devices") Signed-off-by: Suman Kumar Chakraborty Reviewed-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 750960f85f5467d7271b54ddc215e5800b0a08db 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 91559a37ab89ab6677972cc823b271414a94a4ee 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 435a2d476c0f1a78eb3eb18af8a86346c3c62ac4 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 e35f9b354d97cd5d4cfbba1e8eeb7204eb71f3e7 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 f49376986b09d9734fa6c6754f6f4b62a8382b83 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 2014f2ee032b5c60ded5263944ed3e1c6ade2e04 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 2b7e78230f3205f33fdbd04eac7b4f1619478383 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 87b48de7876bfec44bdd2e798d1b2c6e49e379c9 Author: Judith Mendez Date: Wed Sep 9 16:47:38 2026 -0500 arm64: dts: ti: k3-am625-sk-common: Set eMMC clock pin as OUTPUT [ Upstream commit 8ef8a0e38d1377c6d51c06f95c64d87641b2c717 ] 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-11-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 7a78d631d33afe4ec01a70e2086540111f670507 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 8f4c662782775f01029f8f465cb987790960c577 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 a4506f5cdcaf5e30bccb5ab10b210e9b7e0f27f4 Author: Judith Mendez Date: Wed Sep 9 16:47:35 2026 -0500 arm64: dts: ti: k3-am62-pocketbeagle2: Set SD clock pin as OUTPUT [ Upstream commit 843c4d171975059eaa1436c8403d9a29f677a75c ] 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: 92d8c028aa92 ("arm64: dts: ti: Add k3-am62-pocketbeagle2") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260909214743.899477-8-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 76d64e229e8d4a649ff1c066580bc9ebf5b225f0 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 a1af1d48b4e8f25e369296a01627e8e4c1a89272 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 91b895087d4f54f2dd765bdae292d5925960da68 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 9fec0d09d72ca30ae23dc5efaff6df62f018f30d 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 2cd49b55c4a5801806307632d2d5d31ca527ebf6 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 a8c3c92d4ad454bf3c0a143f81ce44f111f483a1 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 979378aa62727f97e0f42793fa822da14875a6ed 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 ea6f38bc01df0ca4f7a209c23b27424fe125fb2a 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 2c10ecb1205c11da58c0b15251e9b56f3f2af73d Author: Sean Young Date: Tue Sep 1 16:20:18 2026 +0100 media: serial_ir: Fix race condition where timer can be re-armed [ Upstream commit d74ac4016ba64cb3b20f395511d0b18025ca0ba9 ] Ensure the timer cannot be re-armed. Fixes: 2940c7e49775 ("[media] serial_ir: generate timeout") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Sasha Levin commit dee5160991876c183962a21ba5d186980c3547dc Author: Sean Young Date: Tue Sep 1 11:29:02 2026 +0100 media: ene_ir: Ensure teardown is done in the correct order [ Upstream commit ae6cfbad7ca346b78f4cdac38438bbfaed8c18a0 ] The timer can be re-armed from the irq, so ensure that the timers are deleted after the irq and that we only free the rc device once we are sure that the irq has been silenced. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Cc: stable@vger.kernel.org Signed-off-by: Sean Young Acked-by: Hans Verkuil Signed-off-by: Sasha Levin commit 63e6c760dab0a59772e55cd7268fdbf4b9025421 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 cf46d521bcb9df867c269f9fa454a353b9655111 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 872bd917485f9332469a793a10c164a450813d6a 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 c94b8c634a50ba19b7e14c41da7bbe7b37187969 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 8c5f9461559f55bcf93207028f206bea6da92c3b Author: Adrian Hunter Date: Sun Sep 20 18:12:32 2026 +0300 i3c: mipi-i3c-hci: Bounce short reads irrespective of the IOMMU [ Upstream commit b1a25e8e143ef880450e6399fb0733b66a1c29f0 ] The controller writes whole DWORDs, so a read whose length is not a multiple of 4 overwrites up to 3 bytes past the end of the destination buffer. That is a property of the controller, not of the IOMMU, but the bounce buffer that works around it was used only when the device was IOMMU mapped. Everywhere else the buffer is left unprotected. Drop the device_iommu_mapped() condition. The overrun is easily seen with CONFIG_SLUB_DEBUG=y and kernel command line options intel_iommu=off slub_debug=FZPU, which reports it as a kmalloc redzone overwrite, like: [kmalloc Redzone overwritten] 0xffff8a354561570e-0xffff8a354561570f @offset=1806. First byte 0x15 instead of 0xcc ============================================================================= BUG kmalloc-8 (Not tainted): Object corrupt Allocated in i3c_master_retrieve_dev_info+0xc1/0x760 age=40 cpu=6 pid=1 ... Freed in i3c_master_enec_disec_locked+0xeb/0x140 age=40 cpu=6 pid=1 ... WARNING: mm/slub.c:1233 at object_err+0x1c1/0x1cf, CPU#6: swapper/0/1 ... Fixes: 9e23897bca62 ("i3c: mipi-i3c-hci: Use physical device pointer with DMA API") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260920151248.46936-3-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 2f6a32c7a313e7d826642a57343cbba0ab202494 Author: Adrian Hunter Date: Sun Sep 20 18:12:31 2026 +0300 i3c: master: Fix out-of-bounds read in DMA bounce buffer setup [ Upstream commit 35b028b25451e17d63b2cd36a11a86c5e18df1b9 ] When a bounce buffer is required for DMA_TO_DEVICE transfers, i3c_master_dma_map_single() rounds the DMA mapping length up to a cache-line boundary: map_len = ALIGN(len, cache_line_size()); It then allocates the bounce buffer with: kmemdup(buf, map_len, GFP_KERNEL); kmemdup() copies the full allocation size, causing it to read map_len bytes from buf even though only len bytes are valid. This results in an out-of-bounds read of up to cache_line_size() - 1 bytes past the end of the caller's buffer. Fix the issue by allocating the bounce buffer with kzalloc() and copying only len bytes from the original buffer. The remaining bytes up to map_len stay zero-filled, avoiding both the out-of-bounds read and exposure of unrelated memory contents to the DMA engine. Fixes: f8d9e56aeb87 ("i3c: master: Add helpers for DMA mapping and bounce buffer handling") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260920151248.46936-2-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 97bc751cfc38f3bccfd3716590decec9c7d7943b 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 2c4be2b6248f94e3163ce9634db8112d8b9a93fa 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 7cec392ed369c45fa7216666d36292d6be706535 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 dbdd30ac4a41751906ba4d06cde9eaa25238c995 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 00080c627a74133ebe95200717d1fe54ec3e76f7 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 5f3092b2fa08297b0eeaf4d360c7c2d73d494566 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 af9a4f6f57917b206e314ac72e651ff051242d52 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 a8d2a980f12a651df9fa8d78379fe7730a19d0a6 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 dc6d28fd849c984a8e96a3f7a27a63a090be06f6 Author: Guangshuo Li Date: Sat Sep 12 22:41:16 2026 +0800 crypto: omap-des - fix crypto engine cleanup [ Upstream commit 5d69ed4cd4f9c68ff9a6ebb2e8a1079223a4ec6e ] omap_des_probe() allocates and starts a crypto engine, but the remove path does not call the matching crypto_engine_exit(). The probe failure path already performs this cleanup. crypto_engine_alloc_init() creates a kthread worker for processing requests. Without crypto_engine_exit() during driver removal, the worker is left running after the device is removed. Call crypto_engine_exit() after unregistering the algorithms and before tearing down the remaining request handling resources. This stops the engine and destroys its worker. This issue was found by manual code inspection. Fixes: f1b77aaca85a ("crypto: omap-des - Integrate with the crypto engine framework") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 27c110a6bed20c95eca16ddc7857e3002a58e68f Author: Thorsten Blum Date: Tue Sep 8 09:53:40 2026 +0200 crypto: zynqmp-sha - fix NULL pointer dereference in init_tfm [ Upstream commit 016f22d2268e02df705868110fe4e402b51bfffc ] zynqmp_sha_init_tfm() checks crypto_shash_statesize(tfm_ctx->fbk_tfm) before assigning the fallback transform to it, which dereferences a NULL pointer since the transform context is zero-initialized. Use the local fallback_tfm pointer for the size check instead. Fixes: c1dd353d18e5 ("crypto: zynqmp-sha - Make descsize an algorithm attribute") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a3048a0145db4d1c0e2624cfd3f07fe768f5eac2 Author: Maciej W. Rozycki Date: Sat Aug 1 22:11:48 2026 +0200 PCI: Skip Target Speed quirk on clamped ports with no link [ Upstream commit ff8a969f7dc8e79ea6113abcfa983e070b2b585a ] Since commit 72780f796468 ("PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining") the Target Speed quirk lifts a firmware-imposed 2.5GT/s restriction on any downstream port, without checking whether the link is up. Where nothing is plugged in, the retraining that follows can never complete, so each attempt costs PCIE_LINK_RETRAIN_TIMEOUT_MS. The quirk makes two of them -- the initial one and the restore on the error path -- adding a fixed 2 s to every boot. On an MSI PRO Z690-A WIFI DDR4 (Intel 600 Series PCH) with one empty x1 slot, running v7.2-rc5: 0.541 pci 0000:00:1c.0: removing 2.5GT/s downstream link speed restriction 1.541 pci 0000:00:1c.0: retraining failed 2.541 pci 0000:00:1c.2: [8086:7aba] type 01 class 0x060400 Where the Link Speed has already been clamped at 2.5GT/s and no link has been established there is nothing worth doing, which is what the kerneldoc for the quirk already describes: the restriction is to be lifted where firmware arranged it "and the port reports its link already being up". Bail out early in that case, before either the ASM2824 workaround or the removal of the restriction is considered. Ports whose link is up are unaffected, and so is the ASM2824 workaround, which is reached with the Target Link Speed not clamped. With this applied the quirk returns without touching the port: both messages are gone, enumeration proceeds from 0000:00:1c.0 to 0000:00:1c.2 in 1 ms rather than 2 s, and the systemd "kernel" boot phase goes from 3.011 s to 1.036 s. Fixes: 72780f796468 ("PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining") Reported-by: Andreas Wild Closes: https://lore.kernel.org/lkml/20260801092152.5643-1-andiwild@gmail.com/ Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221801 Signed-off-by: Maciej W. Rozycki Signed-off-by: Andreas Wild Signed-off-by: Bjorn Helgaas Tested-by: Andreas Wild Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260801201244.4421-1-andiwild@gmail.com Signed-off-by: Sasha Levin commit 973f2d4bc9befa26b53fd05afed0d1c9eb81ae51 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 48381e8b82b715be66ea24d257381ae5eb912eef 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 4811e90d8e25b6520ff91451765f6f6b3b4e077b Author: Jiaming Zhang Date: Wed Sep 2 19:21:21 2026 +0800 nilfs2: force clear dirty state when restoring from the shadow map [ Upstream commit cb6702e63e0a16afd83875294e5ce53becdd1b1f ] When garbage collection fails, nilfs2 rolls the DAT metadata file's page cache back to a shadow copy taken before GC started. nilfs_clear_dirty_pages() drops the dirty state of the folios in the DAT cache, then nilfs_copy_back_pages() overwrites them with the saved contents and warns if one is still dirty: /* overwrite existing folio in the destination cache */ WARN_ON(folio_test_dirty(dfolio)); nilfs_clear_dirty_pages() used to clear the dirty state unconditionally, which is safe here because the rollback runs with the log writer stopped, so nothing else can dirty the cache while it runs. The same helper is also used when writeback finds dirty folios after the filesystem has degraded to read-only, where it does run concurrently with the log writer, so commit ca76bb226bf4 ("nilfs2: do not force clear folio if buffer is referenced") made nilfs_clear_folio_dirty() skip a folio if any of its buffer heads is busy. The rollback caller shares that helper, so its clearing step can now return with a folio still dirty. A DAT folio can hold a busy buffer head without anyone modifying the folio: nilfs_mdt_read_block() submits read-ahead for the blocks following the one it was asked for and waits only for the first, so the read-ahead buffers are still locked when it returns. With a block size smaller than the page size, a locked read-ahead buffer can share a folio with a block that GC dirtied and keep the whole folio dirty past the clearing step. Add a force flag to nilfs_clear_dirty_pages() and nilfs_clear_folio_dirty() that skips the busy buffer check, and set it in the two calls from nilfs_mdt_restore_from_shadow_map(). The read-only fallback callers keep passing false, so that commit still protects them and the WARN_ON() is left alone. Fixes: ca76bb226bf4 ("nilfs2: do not force clear folio if buffer is referenced") Closes: https://lore.kernel.org/lkml/CANypQFZSYrtcshnUzOPiqatyLd-M8_OReOewQoAi_V5yY0dTtg@mail.gmail.com/ Cc: stable@vger.kernel.org Suggested-by: Ryusuke Konishi Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Jiaming Zhang Acked-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 2c2b173c873b8bb803f99b7a2992600b9c069db9 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 fc00ea2413ee6b3743e341c588360c5b3a5ec6b8 Author: Johan Alvarado Date: Fri Sep 11 13:44:15 2026 -0500 spi: spi-qpic-snand: publish the ECC context to snandc->qspi [ Upstream commit f94c9b68bb5fdbef9f841da493d5305ff634ebb5 ] qcom_spi_ooblayout_ecc() and qcom_spi_ooblayout_free() read the ECC configuration through snandc->qspi->ecc. qcom_spi_probe() points it at a zeroed scratch struct and only qcom_spi_ecc_prepare_io_req_pipelined(), which runs on page I/O, ever updates it. qcom_spi_ecc_init_ctx_pipelined() installs the ooblayout but does not publish the context it just allocated, and qcom_spi_ecc_cleanup_ctx_pipelined() frees that context without clearing the pointer. spinand_init() calls mtd_ooblayout_count_freebytes() right after the ECC context is created and before any page I/O, so the ooblayout always runs against a pointer that does not describe the current context: - On a first probe it reads the zeroed struct from qcom_spi_probe(), so steps, bytes and bbm_size are 0. The count then returns 0 rather than an error, so the probe continues with mtd->oobavail set to 0. - On a probe retry it reads the ecc_cfg the previous attempt freed. A retry is easy to hit. On IPQ5018 with the qcom,smem-part parser the partition parse returns -EPROBE_DEFER until SMEM has probed, so the first spi-nand probe defers. It defers inside mtd_device_parse_register(), after mtd_otp_nvmem_add() has already read the factory OTP - that read goes through prepare_io_req and leaves snandc->qspi->ecc pointing at the context that spinand_cleanup() then frees. The second probe allocates a new context, never publishes it, and computes the OOB layout from the freed one. Once the slab has been reused, qecc->steps holds garbage and oobregion->length = qecc->steps * 4; goes negative. qcom_spi_ooblayout_free() only reports -ERANGE for section 1 and later, so mtd_ooblayout_count_bytes() sums the regions and returns that negative length as the byte count. The -512 below is steps * 4 with steps == -128. It is a byte count that happens to collide with -ERESTARTSYS, not an error the driver returned. spinand_init() takes it as an error, and because it is not -EPROBE_DEFER the driver core never retries and the NAND never appears: spi-nand spi0.0: ESMT SPI NAND was found. spi-nand spi0.0: probe with driver spi-nand failed with error -512 UBI error: cannot open mtd rootfs, error -2 Waiting for root device /dev/ubiblock0_1... On a Mercusys MR80X (IPQ5018, ESMT F50D1G41LB) about half of the boots failed to mount the rootfs, the outcome depending on whether the freed memory had been overwritten yet. Publish the context when it is created and clear the pointer when it is destroyed. Clearing leaves snandc->qspi->ecc NULL after cleanup, which is safe: the mtd is unregistered before cleanup_ctx runs, so no ooblayout callback can follow. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Cc: stable@vger.kernel.org Tested-by: Gabor Juhos Signed-off-by: Johan Alvarado Link: https://patch.msgid.link/20260911184416.109790-2-contact@c127.dev Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c7683b4db5a2c034c7cfe2971d906299040f2a17 Author: Thomas Zimmermann Date: Fri Sep 11 14:43:55 2026 +0200 drm/panic: Test address from kmap op for NULL [ Upstream commit 6a6304ec3ceee879e3a2545b217eb11c8b7870e5 ] Do nothing if kmap_local_page_try_from_panic() returns NULL. This is not likely to hapen, as the previous page from the same memory area has been mapped successfully. Signed-off-by: Thomas Zimmermann Fixes: 23437509a694 ("drm/panic: Fix 24bit pixel crossing page boundaries") Cc: Javier Martinez Canillas Cc: Jocelyn Falempe Cc: dri-devel@lists.freedesktop.org Cc: # v6.18+ Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260911124540.279841-3-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 1bf651ae05d024728a629d5987a7b5e2381022aa Author: Thomas Zimmermann Date: Fri Sep 11 14:43:54 2026 +0200 drm/panic: Do not use un-escaped URL as format string [ Upstream commit 6596aae25585b183ebd528206bde6f12efaf8db1 ] Replace the direct use of DRM_PANIC_SCREEN_QR_CODE_URL in snprintf() with a %s conversion specifier. Avoids a possible vulnerabilty from a crafted URL string. As the attacker needs to control the kernel at the Kconfig level, the potential for an exploit is likely low. Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen") Cc: Javier Martinez Canillas Cc: Jocelyn Falempe Cc: dri-devel@lists.freedesktop.org Cc: # v6.12+ Link: https://patch.msgid.link/20260911124540.279841-2-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 9e2913245294f1b8390b8b5ecee67485f18cb432 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 45ceac48961d92e1d056457a5690cd95d2f25450 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 e4e9104f9ce463b6876144bae6d1e4484ceb3325 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 ca766a199f45d2c423820ad4ed1e109cf66af623 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 de73e70146b16a3409cca37aa3cc2ff440792e10 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 615dfc9c1094c4ee449570723d19379e6d15ff97 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 da2591872e9a6c3b26de2b68524b4e225e8753ea 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 4b67a0a7615b055a3df2830e42a18851f5e07fb9 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 9e1878d7f4c66db8eaba2ac0cf8882c80af5d550 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 0d9e9643b93d6f6f8c2b4bb07037815de7065411 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 800e6b3394f547085e79a7ae7f95d46425f10f40 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 c51c7e46b98c083ca7651c18e4e56357e5fb5c5a 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 a7e2d7c8aef36cfa6042c9152756c89ca2f853ff 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 daa8a3cde7c8546b88c45443b886ea3352517eb1 Author: Guangshuo Li Date: Tue Sep 15 16:50:31 2026 +0800 media: i2c: ov2735: fix power cleanup on remove [ Upstream commit 06d4f202f007b160e650e8dd861a5fc223024f34 ] ov2735_probe() explicitly powers on the sensor before enabling runtime PM. The probe failure paths call ov2735_power_off(), but the remove path does not perform the corresponding power-off operation. The managed runtime PM helpers only clean up the runtime PM state. devm_pm_runtime_set_active_enabled() disables runtime PM and restores the suspended state during device resource release, while devm_pm_runtime_get_noresume() drops the runtime PM usage reference. Neither helper invokes ov2735_power_off(). As a result, removing the driver after a successful probe can leave the sensor clock and regulators enabled and the GPIOs in the powered state. Call ov2735_power_off() from ov2735_remove() to match the successful ov2735_power_on() performed during probe. This issue was found by manual code inspection. Fixes: fa9e6df636fb ("media: i2c: add ov2735 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 1f5409c10ffa56e7c4fd13d4e3ff2dccb4fe746c 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 1b2d819c09f0bea5cff5c53ff7dcb4df47da6efd 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 6fe2e3756522e0a505fdd87016f5ab739b86e32d 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 9135a4ba98db1d3d0d326dca84eb0faf914642bf 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 225230b9069823324b3ff5cac2784caa7ba4c75f 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 c0d77acef537dd3f0b1dcf94c9d0a265936d4ba6 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 241fcc1d7f9868992510a41fb0427c593440805c 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 9e6fc70c7ad4fa8dcc912e1b4fd4220bbca19c27 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 1af45c0daaff688e1bcd276ad04752521a713d14 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 dc4724be77c93c2d067aad80525437979c662832 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 58492634b0438c183df97b8a70bc66d2a74b6781 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 a1bcadec1debdbdb43b1cc84e11e8d6ee2bc8a0d 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 ec3bb0b9bb79787d47292544bec1b9f0ab814942 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 a7c9d73df0489afb3b92a23ea326189237d5df67 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 05c0ae1f3d3cd158f55fffcc5a78f75eea37a5ca 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 f3e35f116d69875a5d1e6615acb16bad47bf0061 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 f82d80f7b6f7c537f3047330940300117aebb8e1 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 f16b697c94756db9a3bddc41c30f00b3b2332977 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 876ba0c13671407f7bd48791b84d5013a21188b0 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 00dd4a5c2b8c7391367c047ad79158043116723c 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 946aa222b49d7015fc37e36af5b73915bdcea841 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 90093af6a0b4ab03277ac553c05fe0dc6c70a9ff 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 63181ae0a49b52dfcb30f41bfef45aa004177e39 Author: Fan Wu Date: Thu Sep 3 08:13:12 2026 +0000 power: supply: bq27xxx: Ensure poll work is cancelled on remove [ Upstream commit db560f4b1c5253853f978385db066220e0c218dc ] The di->work poll work is queued from the poll callback itself and from bq27xxx_external_power_changed(). The cancel_delayed_work_sync() in bq27xxx_battery_teardown() runs while the power_supply is still registered, so external_power_changed() can re-arm the work after the cancel, and it runs after the driver data has been freed. Register a devm_delayed_work_autocancel() before devm_power_supply_register(), so on unwind the power_supply is unregistered first, after which no new external_power_changed() callback can be dispatched, and the poll work is cancelled only then. Drop the now-redundant cancel from bq27xxx_battery_teardown(). This issue was found by an in-house static analysis tool. Fixes: 740b755a3b34 ("bq27x00: Poll battery state") 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 Link: https://patch.msgid.link/20260903081312.225535-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 4f2e159190dd54431de795adacfbbbf01c817b6f 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 29601cf266cac59cc5111618643076f722db3f2a 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 3a476ea9a2f42b2f9f04f833bdde6c55d72ed7f9 Author: Robin Snyders Date: Wed Aug 12 01:30:01 2026 +0200 power: supply: qcom_smbx: validate battery float voltage [ Upstream commit a2d7dc538da2cb4a7426f0742197e762cb635f38 ] power_supply_get_battery_info() leaves absent optional properties at -EINVAL. The driver uses voltage_max_design_uv without checking it, so a missing or out-of-range value can become an invalid float-voltage selector. Prefer the constant-charge voltage because it describes the charger's CV target, then fall back to the battery design voltage. Both properties are optional in the simple-battery binding, so preserve the hardware setting when neither is present. Reject a supplied target outside the SMB2 range. smb_init_hw() enables charging before battery data is parsed and before the remaining fallible probe steps. Save the initial charging-enable bit and install a managed rollback before initialization. Keep the rollback active across battery-info, voltage, IRQ and wake-IRQ setup, then remove it only after probe can no longer fail. 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-4-eb48246be599@snyders.xyz Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 29aeb5ac799010358dfb225e480b799d1ee8dc9f 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 287619a6cd07da5b210e306f06a6f358806ef5b6 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 8e91b6b73f18cce4dca38a374068870ad98d9558 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 9b26d77f89cab299cb1bf457fa7d46340a11191f Author: Runyu Xiao Date: Fri Sep 4 14:11:37 2026 +0800 hte: tegra194-test: shut down timer before GPIO release [ Upstream commit 30167fadbf87fa901a2fee49c30a5c5a506a43e8 ] tegra_hte_test_remove() releases GPIO descriptors before stopping hte.timer. gpio_timer_cb() accesses hte.gpio_out and rearms the timer, so a callback concurrent with remove can use a released descriptor and rearm after teardown. Shut down the timer before releasing the GPIO descriptors. timer_shutdown_sync() waits for a running callback and prevents it from being rearmed. Fixes: 9a75a7cd03c9 ("hte: Add Tegra HTE test driver") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Acked-by: Dipen Patel Signed-off-by: Dipen Patel Signed-off-by: Sasha Levin commit 2cb1b55431ae5eab6efe0135b489a2f03f396540 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 d56c604bae3a923b83f462e4d34d4dd97016f142 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 0b39ce62d9226a8e09dda11a4f886b5bb15515ce 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 79800ff17a5f487c8cb75481eb71f14ab949eaa4 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 8b25a49e4bd7d33f57d22ebd9439005a0072d891 Author: Alexander Shiyan Date: Fri Jul 3 10:00:29 2026 +0300 media: synopsys: hdmirx: use request_any_context_irq() for 5V detection IRQ [ Upstream commit fce1e4fa3867c0ff19a31f9977741696710855a6 ] Replace devm_request_irq() with devm_request_any_context_irq() for the 5V detection interrupt handler. This allows the kernel to choose the appropriate execution context (hardirq or threaded) depending on the underlying interrupt controller. On some platforms, the interrupt may be nested or require a threaded handler, and using the fixed hardirq version can cause probe failures. Switching to the more flexible function improves driver portability without affecting functionality. Fixes: 7b59b132ad43 ("media: platform: synopsys: Add support for HDMI input driver") Cc: stable@kernel.org Signed-off-by: Alexander Shiyan Reviewed-by: Dmitry Osipenko Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 8018d370be35e9f9ad9193a785b44179d4d55251 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 de92aa70a36a4f01b6007f8792ca89c6d6993185 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 486eccf2f4bed764904353ae30403619a7ac1c1c 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 d2606c2c6d490828c8e052028d2dcfa7a5c3d16f 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 ea3a418d73b0ccf15e6b60efee1606484acf91de Author: Myeonghun Pak Date: Wed Jul 29 11:18:34 2026 +0900 media: stm32: csi: unregister async notifier on cleanup [ Upstream commit 4957d480a0c87cf3d024e6ff1f57d1222f9212cb ] stm32_csi_parse_dt() registers the async notifier before probe finishes. If a later operation fails, the error path only cleans up the notifier's connections. It does not unregister the notifier, leaving its entry on the global notifier list after the devm-allocated csidev is freed. The remove path has the same problem. A later async operation can then walk the stale notifier entry and access freed memory. Unregister the notifier before cleaning up its resources on both paths. Fixes: dcb0f4c16be5 ("media: stm32: csi: addition of the STM32 CSI driver") Cc: stable@vger.kernel.org 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 de26b77e6e3acffc3c017aa594db0963ed9f5b6f Author: Alain Volmat Date: Tue Jul 21 21:01:19 2026 +0200 media: stm32: csi: correct remote pad retrieval [ Upstream commit b83651d321d4fd07979a59f359dcb0266391f17a ] The function media_entity_get_fwnode_pad is called in order to retrieve the remote pad, which is the source of the CSI. However this function is expecting the sensor endpoint fwnode and not sensor device fwnode as it is currently given. Correct this by properly relying on the notified matched fwnode data instead of the subdev entity fwnode. Cc: stable@kernel.org Fixes: dcb0f4c16be5 ("media: stm32: csi: addition of the STM32 CSI driver") Signed-off-by: Alain Volmat Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 79058f6929412847262ab3ea2955debd5f8f3261 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 da7a07ad6fe000e1869c835603f26cc53f44715c 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 a517178cce67bb52562300d41cf648f4c5a23777 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 6dc8e17c26a9042291f7b6e70042c1499a20929a 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 d1d04f10ad77feb94f7b85be27b355727c5b0c45 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 bd676daa63715c270eef21dea7ae71477450d2c4 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 d1dbcb4346875598c6ee1652d3fc522c25bd1043 Author: Wang Yan Date: Mon Aug 24 10:55:53 2026 +0800 perf powerpc-vpadtl: Fix off-by-one in auxtrace_info minimum size check [ Upstream commit d9c7e2ede92ce258a5d4a6cbc55f75acd379c97d ] min_sz is set to sizeof(u64) * POWERPC_VPADTL_TYPE, but the code reads auxtrace_info->priv[POWERPC_VPADTL_TYPE], which needs at least POWERPC_VPADTL_TYPE + 1 elements. POWERPC_VPADTL_TYPE is the first enumerator of the priv index enum (0), so min_sz evaluates to 0 and the check validates only the perf_record_auxtrace_info header itself. A PERF_RECORD_AUXTRACE_INFO event carrying a zero-length priv array then passes the size check, and the subsequent priv[POWERPC_VPADTL_TYPE] read runs one u64 past the validated region. This is the same off-by-one fixed for Intel PT by commit c4362d5e1a5e ("perf intel-pt: Fix off-by-one in auxtrace_info minimum size check") and for Intel BTS by commit b9fb8225951c ("perf intel-bts: Fix off-by-one in auxtrace_info minimum size check"). Use sizeof(u64) * (POWERPC_VPADTL_TYPE + 1) so the highest accessed priv index is covered by the minimum-size validation. Fixes: c4bbd4ec2e50a9ed ("perf powerpc: Process auxtrace events and display in 'perf report -D'") Reviewed-by: Adrian Hunter Signed-off-by: Wang Yan Cc: Athira Rajeev Cc: stable@vger.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 82cbf1a3e91aea21f901b8dc179b1eee28a9507e 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 02b1ca9a3793b84da5bff1ae777ab45611ed723c 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 17de34822aeb26f531f71ea57f319b13d55fdd50 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 228b1b7be79d17aa1aa4f3f8867b12601d02e71f 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 f01bdf7f3fc2353fdb2f2468a76bd7bfefb639e4 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 b60a01c63970755090eeac0ba4f8246efad77995 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 b0f8a0f8058e2e5811ed975cc24757f64c2962ce 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 72b9c63beb0151c917bdc538daaefb636f442b17 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 1b317507238bbee272de232a11b6585d35166db1 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 b64ea8c8e00850c067bb6f20bcee5b9b45dd72b0 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 0b0fbacea9a0e9f26bbf997a91b2a9814e5123bb 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 d208c267148f61a041a1927fec5f48c793e5d975 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 2cdba0da8c13dbc29dbb7a98fe5955588c585a8b 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 5bb8c5b1727ca8593df5711c186e6a9263436c27 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 3fcfab4339c8ecdadbc7a33033a6973d8fdd1e71 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 c7091528ab213890694dada122a3f75a63c735e3 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 5c8ecd9ebc95523c950b3616703d4c19ee5e8b33 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 ced0704d1e0cb404ef2068789953fa6fd0d4563d 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 ec0ec28012816a9e3b6904a9b89a9c71c7d61414 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 0a0fef460f20766febf4b7a9d36814b8c1b27a14 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 cb93d82e206c0ee10288a62b394b492939e0e670 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 781364a1fb9dd60067d72b09bcf4e5f4b24a1b02 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 ced6f89824f84baeb80a1775e72776978e641808 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 3c21a1feaf89cda986bd2d74199a070688bd2b1e 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 1545217ceadc604730ae4fcc6221a7fea07ca7ef 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 7317c31a54bb84decb5b25d1bc03b11e0f63af6a 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 8cbeaea4d325f0fc980736b44a06dd1a30e177ff 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 06b4dabdc67a0abcdb92b3882196a9d2dfcf4858 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 c42a610d574265e5a0dde85a303328008af5379e Author: Serin Yeh Date: Thu Aug 6 14:18:04 2026 +0800 media: i2c: ov8856 : remove ACPI node bypass mechanism [ Upstream commit 609a71568664acb7ee57b42de002ca782e3769e8 ] On Intel platforms the sensor is enumerated via ACPI, and an INT3472 "discrete" companion device (the power-logic-control driver under drivers/platform/x86/intel/int3472) registers the sensor's reset/powerdown GPIOs and the regulator supply. These resources are therefore discoverable and usable through the standard gpiod/regulator lookups at probe time. However, the driver guarded both the GPIO/regulator acquisition in ov8856_get_hwcfg() and the whole power-on/off sequence with is_acpi_node() and skipped them on ACPI. As a result the sensor was never powered or reset by the driver, and probe failed when reading the chip ID in ov8856_identify_module(). Remove the is_acpi_node() checks so the GPIO/regulator resources are acquired and the full power sequence runs regardless of the firmware interface. The driver now behaves consistently across DT and ACPI platforms and initialises the hardware correctly. Tested on Intel platforms with kernel 6.17 and 7.0. Fixes: d2fa1134a48b ("media: i2c: ov8856: Use V4L2 legacy sensor clock helper") Cc: stable@vger.kernel.org Signed-off-by: Serin Yeh Reviewed-by: Bryan O'Donoghue Reviewed-by: Kieran Bingham Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit c99e574764c339ccbb7dc391fe8106b9323cfb68 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 bef63213e20824fd594a95dc40514ee6241550f5 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 f1f18007989bb359802623c6deebba8a31090f6e 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 6922b35cb2bbbe0522031cd811796adc1693180c Author: Yo'av Moshe Date: Sun Aug 30 17:51:00 2026 +0200 ARM: imx: Fix suspend/resume crash with Clang CFI [ Upstream commit 242757d109bd5c9b8fb7194fb4d44625be0b859a ] The suspend code that runs from OCRAM is copied there with fncpy(), which does not copy the kCFI type hash preceding the function. With CONFIG_CFI=y the indirect call through imx6_suspend_in_ocram_fn therefore panics. Keep the call covered by CFI instead of exempting it: - Add SYM_TYPED_FUNC_START_ALIGNED(), a variant of SYM_TYPED_FUNC_START() that aligns the function entry rather than the type hash preceding it, and use it to declare imx6_suspend(): fncpy() requires the entry point of the function it copies to be 8-byte aligned. The macro lives in arch/arm/include/asm/linkage.h since the requirement comes from arm's fncpy(). - Add a cfi_type member at the end of struct imx6_cpu_pm_info, which directly precedes the OCRAM copy of the function. It fits in the struct's tail padding, so no sizes or offsets change. Fill it using cfi_get_func_hash(), putting the hash where the caller's CFI check expects it: four bytes before the function entry. Also mark ccm_base, suspend_ocram_base and imx6_suspend_in_ocram_fn as __ro_after_init: they are only written during __init, and the function pointer in particular should not be writable afterwards. Suggested-by: Nick Desaulniers Cc: stable@vger.kernel.org Signed-off-by: Yo'av Moshe Reviewed-by: Nick Desaulniers Reviewed-by: Sami Tolvanen Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit cfe382cbabf6d5be415009cad6c58a2cf4f6a8b8 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 2c1fdcbb95bd67e2abfa5e194c0aed287527d079 Author: Sakari Ailus Date: Thu Aug 20 23:19:01 2026 +0300 platform/x86: int3472: Fix uninitialised variable warning [ Upstream commit 70e6384fe0f4cf9768944f81924f6c1478b0ce43 ] Fix a compiler warning about an uninitialised err_msg variable by printing the error where it is handled: drivers/platform/x86/intel/int3472/discrete.c:440:24: warning: ‘err_msg’ may be used uninitialized [-Wmaybe-uninitialized] 440 | return dev_err_probe(int3472->dev, ret, err_msg); Fixes: 5de691bffe57 ("platform/x86: Add intel_skl_int3472 driver") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Ricardo Ribalda Acked-by: Rafael J. Wysocki (Intel) Reviewed-by: Daniel Scally Signed-off-by: Sasha Levin commit 2bab8fa4826bda9e1960bf820bc31f1b1de15da0 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 a83e3e33b781c15587ffaae5e860ace96a2d3c7c 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 aa26d4a75f2c85e062270bc5e68ce9d495fa12f9 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 c408ff204a86f62e51a3558b108a2b87bccfd8a2 Author: Lad Prabhakar Date: Mon Jul 27 11:34:44 2026 +0100 memory: renesas-rpc-if: Mark XSPI_CDD1BUF0 as volatile [ Upstream commit 3db1fb5e1bb4c9eefc554f985f6f3316fa1292e5 ] Add XSPI_CDD1BUF0 to the xSPI regmap volatile register table. XSPI_CDD1BUF0 is a data buffer register used during manual transfers and, like XSPI_CDD0BUF0, its contents are transient and should not be cached by regmap. Mark it as volatile so reads always access the hardware register. Fixes: 687cac9559d8 ("memory: renesas-rpc-if: Add RZ/G3E xSPI support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Link: https://patch.msgid.link/20260727103449.3188105-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 77b641503dddf57e0dcee9202edb60d3f1a985fd 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 5aca21d188570b8b86356a562c7a668a51b1d088 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 1f8722a7053ffe11eff0ee402b7c5150dc808089 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 8237cd3e2fc24e2227c38a730ff29ad1009f48a7 Author: Ramin Moussavi Date: Fri Aug 21 17:18:08 2026 +0200 microblaze: restore the ABI argument home area below pt_regs (PTO) [ Upstream commit c35d40a3efd2e575ef51a761e983f2bf7113be6c ] The MicroBlaze ABI has the caller reserve stack space for the arguments it passes in registers: REG_PARM_STACK_SPACE is 24 and OUTGOING_REG_PARM_STACK_SPACE is 1 in the gcc backend, so a callee may write to [caller_sp + 4, caller_sp + 28). The kernel calls C functions from entry.S with r1 pointing at pt_regs, handing the callee license to spill its incoming arguments over the saved registers -- the syscall dispatch is the worst case, where the first argument slot is PT_R1, the saved user stack pointer. This was latent until GCC 15: since 3b9b8d6cfdf5 ("ira: Scale save/restore costs of callee save registers with block frequency") the allocator prefers spilling incoming arguments over copying them into callee-saved registers, and a kernel built with gcc >= 15 (without the TARGET_CALLEE_SAVE_COST workaround some distributions carry) corrupts PT_R1 on the first syscall: init takes SIGSEGV and the kernel panics. The kernel had exactly this reservation until 2011: commit 6e83557c38b4 ("microblaze: Remove r0_ram pointer and PTO alignment") removed STATE_SAVE_ARG_SPACE and with it the PTO offset, as part of cleaning up what was thought to be copied-from-v850 leftovers. Restore it: the frame is STATE_SAVE_SIZE = PT_SIZE + PTO, r1 stays at the frame base through every asm-to-C call, and the saved registers are reached at r1 + PTO + PT_*. PTO is 28 rather than the historic 24, which was one word short: FIRST_PARM_OFFSET is 4 and REG_PARM_STACK_SPACE is 24, so the area spans [sp+4, sp+28) and needs 28 bytes. With 24 the last argument slot overlapped pt_regs' r0 -- harmless only because r0 is the constant-zero register. STACK_BOUNDARY is 32 bits, so 28 needs no further rounding. Two places deliberately keep their mainline addressing. hw_exception_handler.S needs no offset change: its real-mode handler saves into the standalone pt_pool_space buffer rather than a stack frame, and _unaligned_data_exception works through a pointer to pt_regs in r7, where plain PT_* offsets are already right. And the user-SP reload after popping the frame keeps PT_R1 - PT_SIZE because PTO cancels there: (PTO + PT_R1) - (PT_SIZE + PTO) = PT_R1 - PT_SIZE. Both are exactly as the pre-2011 code had them. The instruction count is unchanged -- the same instructions with different immediates, no per-call reservation and no trampolines. The cost is 28 bytes more kernel stack per saved frame. Fixes: 6e83557c38b4 ("microblaze: Remove r0_ram pointer and PTO alignment") 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-5-ramin.moussavi@yacoub.de Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit 87f78edf4b3deb58a8405d7eb401312aca7229c8 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 ba4121a804ada22bef4b35adfef5b7198c6e1b86 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 ed48f8b0ec58dd970acb5ab8cedb29f11dd8a576 Author: Viken Dadhaniya Date: Fri Aug 21 12:06:20 2026 +0530 soc: qcom: geni-se: Fix write to read-only firmware buffer [ Upstream commit 28b9c15f1829fff7b26db0dbbbde1c6b466cb156 ] geni_find_protocol_fw() casts fw->data to a non-const struct se_fw_hdr pointer and writes back the rounded-up fw_size value: sefw->fw_size_in_items = cpu_to_le16(fw_size); The firmware subsystem maps the firmware blob read-only. Writing through the cast pointer causes a level-3 permission fault on AArch64 and crashes the kernel during driver probe. The write-back is no longer necessary: geni_find_protocol_fw() now propagates the rounded size to the caller via fw_size_out. Remove the write-back and make sefw (and the hdr pointer in the caller) const-correct. Fixes: d4bf06592ad6 ("soc: qcom: geni-se: Add support to load QUP SE Firmware via Linux subsystem") Cc: stable@vger.kernel.org Reviewed-by: Konrad Dybcio Signed-off-by: Viken Dadhaniya Link: https://lore.kernel.org/r/20260821-fix-write-to-read-only-firmware-buffer-v3-4-43e6a3abd651@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bb6277d4f59e2e91fb236cbece000dc0ba3c443c Author: Viken Dadhaniya Date: Fri Aug 21 12:06:19 2026 +0530 soc: qcom: geni-se: Fix fw_end computed before round-up; propagate size to caller [ Upstream commit d1750c530e9b9b75c8d1b29d3c76e052a049f51f ] fw_end was computed from the raw fw_size_in_items, before the odd-word round-up. A segment with an odd word count could pass the bounds check at the unrounded value but then be copied one word past the validated limit. Move fw_end (and the cfg_{idx,val}_end) calculations to after the round-up so they always reflect the true copy extent. The caller geni_load_se_fw() re-read hdr->fw_size_in_items for the memcpy_toio() length, bypassing the validated and rounded value established by geni_find_protocol_fw(). Add a fw_size_out output parameter and use it in the caller. Fixes: d4bf06592ad6 ("soc: qcom: geni-se: Add support to load QUP SE Firmware via Linux subsystem") Cc: stable@vger.kernel.org Reviewed-by: Konrad Dybcio Signed-off-by: Viken Dadhaniya Link: https://lore.kernel.org/r/20260821-fix-write-to-read-only-firmware-buffer-v3-3-43e6a3abd651@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 73c7e00cea7bd6b9df062c6852e6aed9ee69f657 Author: Viken Dadhaniya Date: Fri Aug 21 12:06:18 2026 +0530 soc: qcom: geni-se: Widen fw_size to u32 to prevent wrap-around [ Upstream commit e976c865bf31b562ab3908f0f1e2160da77fa156 ] fw_size is read from the 16-bit fw_size_in_items field and incremented when the count is odd. If fw_size_in_items == 0xffff the increment wraps to 0 as a u16, making the bounds check below pass for a firmware segment whose actual size was not validated. Widen fw_size to u32 so the increment never wraps. Fixes: d4bf06592ad6 ("soc: qcom: geni-se: Add support to load QUP SE Firmware via Linux subsystem") Cc: stable@vger.kernel.org Reviewed-by: Konrad Dybcio Signed-off-by: Viken Dadhaniya Link: https://lore.kernel.org/r/20260821-fix-write-to-read-only-firmware-buffer-v3-2-43e6a3abd651@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 211532d38f7b513d666970991006169759670c9f Author: Viken Dadhaniya Date: Fri Aug 21 12:06:17 2026 +0530 soc: qcom: geni-se: Fix endian conversion for serial_protocol comparison [ Upstream commit 0231382f070df26a8b267f9e68c5440928b87c89 ] serial_protocol is declared as __le16 in struct se_fw_hdr, but was decoded with le32_to_cpu(). On big-endian systems the extra byte swap causes the field to always compare unequal to the protocol argument, so no firmware segment is ever selected. Use le16_to_cpu() to match the field width. Fixes: d4bf06592ad6 ("soc: qcom: geni-se: Add support to load QUP SE Firmware via Linux subsystem") Cc: stable@vger.kernel.org Reviewed-by: Konrad Dybcio Signed-off-by: Viken Dadhaniya Link: https://lore.kernel.org/r/20260821-fix-write-to-read-only-firmware-buffer-v3-1-43e6a3abd651@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 078cbede4db36844b9ac256fdc1f4b1c4c668546 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 58291947b70a132144e1ed6fd6a4d9e043061a34 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 96540793dd7e55b81e0724e9efa024bbd26dbfaa 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 7b6d1a6763e6acbb99f12c16244b3016c865eb2e 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 ae3bdd1941d7686fef6c411e6e7141dd5295dcda 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 52f216b8784f8ee32972d05b7d4827d3426b8413 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 eae391f3821000c84cb78163080c200d132b3466 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 7f8cd3cfcba75ce80cabf346c6227a189cdd6f81 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 36c95ef77d4343cdd403f8b8ba8b8b8bab6b15a8 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 a842af958b4e870783f566dd5758474552beadf5 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 ddaf428a0f8a163ab60fb7101a5533fe5a63e9e4 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 7d7521a954adb036e38cd353c595d527fd37c891 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 4c443c088a37a346a1cd4894e8b0523a9bf5cef1 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 5f475e1c007bd33bb54900a6eacd48abcf2317cf 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 fc075bead27062522e26c74a7e719ccd031b558d Author: Daniel Schwierzeck Date: Fri Aug 21 10:45:39 2026 +0200 cpufreq: airoha: fix probe failure with correct error check [ Upstream commit 801ade22c4fc078ea9b11e1f3fe3aae8b8bef886 ] dev_pm_domain_attach_list() returns the number of attached PM domains on success (a positive count), or a negative error code on failure. The driver checks "if (ret)" which treats a successful attachment of one or more PM domains as an error, causing the probe to fail with return code 1. Fix by checking "if (ret < 0)" like all other users of this API. Cc: stable@vger.kernel.org Fixes: 84cf9e541ccc ("cpufreq: airoha: Add EN7581 CPUFreq SMCCC driver") Signed-off-by: Daniel Schwierzeck Signed-off-by: Christian Marangi Reviewed-by: Zhongqiu Han Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit b59e31d1145d195bcfba2ed7b3e1138da1cb3115 Author: Jakub Szczudlo Date: Tue Aug 4 21:28:38 2026 +0200 iio: adc: ti-ads1100: Fix incorrect reading when datarate changed in single mode [ Upstream commit 38dbf24dfbd0a73b89fa2871a7148429aef05531 ] When device is suspended and it is in single mode then changing datarate doesn't make it actually wait for new measurement, so to be sure that read after change is correct, functions that changes datarate and gain will wait for a new data. Fixes: 541880542f2b ("iio: adc: Add TI ADS1100 and ADS1000") Signed-off-by: Jakub Szczudlo Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 57a52158ca8cc8207ce957dbac8ec5ccbf33aedc 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 dc715d660d9255ed016b41a624e5dee69c0840a4 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 ddae760f399709fdfbf295a06f8eea557302ad9a 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 3ea6031d2625fd93ee17994f65140c321de46a83 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 f688ffe4a23ae12d2947e68b10225b208c36022c 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 e8c6be50fcae43997eac73781894aeda2e43d1cb Author: Marek Czernohous Date: Sun Aug 16 15:09:04 2026 +0200 drm/nouveau/pci: use config-space MSI rearm on MCP79/MCP7A (NVAC) [ Upstream commit 354d47fb3f35461b7f942831c1b2a7105e92b57f ] NVAC (MCP79/MCP7A) uses g94_pci_func, whose .msi_rearm is nv40_pci_msi_rearm(): a re-arm write through the MMIO mirror of PCI config space. On this IGP that path is unreliable; when a re-arm is missed the interrupt line stays dead, command submission times out and the GPU appears hung until reboot. On an Apple Mac mini (early 2009, MCP79, boot0 0x0ac080b1) this showed as sporadic fifo timeouts and GPU hangs under load unless MSI was disabled via config=NvMSI=0. Give NVAC its own pci func that re-arms through real PCI config space (nv46_pci_msi_rearm) instead. This follows existing precedent: nv46.c documents the MMIO-mirror re-arm as broken on several related parts, and commit 5112abc6a433 ("drm/nouveau/pci/g92: Fix rearm") fixed g92 the same way while moving the remaining chipsets, NVAC included, into the newly added shared g94 table, where NVAC stayed on the MMIO path. This change completes that fix for NVAC. The sibling IGP NVAA (MCP77/MCP78) has MSI disabled entirely as "reported broken" in nvkm_pci_new_(); NVAC works correctly once the re-arm goes through config space, so disabling MSI is not necessary. Only NVAC is switched: that is the hardware this has been validated on. The other users of g94_pci_func (G94/G96/G98/GT2xx and the MCP77/MCP89 IGPs) keep their current behavior; MCP77 and MCP89 plausibly want the same treatment but were not tested. Tested on the Mac mini as a daily driver for two months with MSI enabled and zero fifo timeouts. Independently confirmed stable on an iMac9,1 (MCP79) running 6.12.90 with the v1 form of this change (the same one-line functional switch, applied to that kernel's g94 implementation). Fixes: 5112abc6a433 ("drm/nouveau/pci/g92: Fix rearm") Cc: # v6.16+ Tested-by: Fab Stz Assisted-by: Claude:claude-opus-4-7 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Marek Czernohous Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/178688574401.522643.12812428444459119913@gmail.com Signed-off-by: Sasha Levin commit 812500ab5bb8100003bbae1391c0ef16c9c3df7d 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 c518337e597df7204244b5a174277286eb6e14fa 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 c04b888b3955123931cee3652499c16734a46c4e Author: Miguel Ojeda Date: Fri Nov 6 07:37:45 2026 +0100 rust: bitmap: fix intra-doc link `BitmapVec::MAX_LEN` does not exist in 6.18.y, so `rustdoc` warns: warning: unresolved link to `BitmapVec::MAX_LEN` --> rust/kernel/bitmap.rs:24:25 | 24 | /// This also matches [`BitmapVec::MAX_LEN`]. | ^^^^^^^^^^^^^^^^^^ the struct `BitmapVec` has no field or associated item named `MAX_LEN` | = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default Thus link to `BitmapVec::new()` instead. Fixes: 37f45fe068e0 ("rust: bitmap: restrict bitmap length to at most i32::MAX") Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit c4252273ead984541eb9313667f2924f2ff8d0e0 Author: Vernon Yang Date: Wed Nov 4 18:12:29 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: Retained int result instead of enum scan_result in hpage_collapse_scan_file(). ] Signed-off-by: Sasha Levin commit a3dc612f05f4084b766428fb05963410aa7d8a5f Author: Sami Tolvanen Date: Fri Nov 6 15:47:21 2026 +0100 rust: dma: declare cfi_encoding for dma_data_direction commit 7d109178cd644268326cd31702ed46c7ac8bb300 upstream. bindgen generates bindings::dma_data_direction as an integer by default, while C callback tables such as dma_buf_ops declare the parameter as enum dma_data_direction. kCFI encodes enum types by name even with integer normalization, so the type ids would not match when C calls into a Rust callback taking bindings::dma_data_direction. Generate dma_data_direction as a newtype with a cfi_encoding, as is done for lru_status, and convert DataDirection through the newtype's constants. Signed-off-by: Sami Tolvanen Reviewed-by: Alice Ryhl Reviewed-by: Gary Guo Acked-by: Danilo Krummrich Cc: stable@vger.kernel.org Fixes: c2437c43cfb1 ("rust: dma: implement DataDirection") Link: https://patch.msgid.link/20261019-rust-cfi-fixes-v1-3-9503472ba738@google.com Signed-off-by: Miguel Ojeda [ Replaced bindgen's custom enum attribute option with sed post-processing to support older bindgen. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 5a13e8528e0b11f0e53031998854335687046197 Author: Sami Tolvanen Date: Fri Nov 6 15:47:20 2026 +0100 rust: hrtimer: declare cfi_encoding for hrtimer_restart commit 39fe6892fd52faed6325ff7f13a92da01ab35727 upstream. The hrtimer callbacks return bindings::hrtimer_restart, which bindgen generates as c_uint. C calls them through hrtimer->function, which returns enum hrtimer_restart. kCFI encodes enum types by name even with integer normalization, so the type ids never match and every call fails the CFI check. Generate hrtimer_restart as a newtype with a cfi_encoding, as is done for lru_status, and adapt HrTimerRestart to the newtype. Fixes: 8a8afe9349fb ("rust: hrtimer: introduce hrtimer support") Signed-off-by: Sami Tolvanen Reviewed-by: Alice Ryhl Reviewed-by: FUJITA Tomonori Tested-by: FUJITA Tomonori Acked-by: Andreas Hindborg Reviewed-by: Gary Guo Acked-by: Danilo Krummrich Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261019-rust-cfi-fixes-v1-2-9503472ba738@google.com Signed-off-by: Miguel Ojeda [ Replaced bindgen's custom enum attribute option with sed post-processing to support older bindgen. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 3809bde861d7a2b236a53fbe0227e01f44f4136e Author: Sami Tolvanen Date: Wed Nov 4 17:36:48 2026 -0500 rust: irq: declare cfi_encoding for irqreturn [ Upstream commit 01f3e6b4b1c8c1748e59ba53631ab1f5d9ad0ea4 ] The IRQ callbacks return c_uint. C calls them through irq_handler_t, which returns enum irqreturn. kCFI encodes enum types by name even with integer normalization, so the type ids never match and every call fails the CFI check. Generate irqreturn as a newtype with a cfi_encoding, as is done for lru_status, and return bindings::irqreturn_t from the callbacks. Fixes: 0851d34a8cc3 ("rust: irq: add support for non-threaded IRQs and handlers") Fixes: 135d40523244 ("rust: irq: add support for threaded IRQs and handlers") Signed-off-by: Sami Tolvanen Reviewed-by: Alice Ryhl Reviewed-by: Gary Guo Acked-by: Danilo Krummrich Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261019-rust-cfi-fixes-v1-1-9503472ba738@google.com Signed-off-by: Miguel Ojeda [ sashal: replaced bindgen's custom enum attribute option with sed post-processing to support older bindgen ] Signed-off-by: Sasha Levin commit edb4f7bcffdb768103c561c588de310f34dd26ba Author: Jérémy Jean Date: Wed Nov 4 19:54:00 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 10dc8299d1ff5bcf3523ebb324145fb776563f36 Author: Marco Crivellari Date: Wed Nov 4 19:53:59 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 a7ba1a5a0c16d3aad161681b01933703419fd52d Author: Danish Khateeb Date: Wed Nov 4 19:38:10 2026 -0500 pps: generators: don't use the driver's info after unregister [ Upstream commit 4e8063cae337cb7328e6856235cf4de5d165516e ] A file that was opened before pps_gen_unregister_source() keeps pps_gen, and with it the pointer to the driver's pps_gen_source_info. PPS_GEN_SETENABLE and PPS_GEN_USESYSTEMCLOCK keep using that pointer after the driver has gone: - pps_gen_tio allocates its info with devm_kzalloc(), so after an unbind both ioctls read freed memory, and SETENABLE calls the driver's enable() with its freed private data. - pps_gen-dummy does not set info->owner, so it can be unloaded while the file is open, and the ioctls then read the unloaded module's data and call its code. TIO can't probe in a VM, as it needs ART. A test driver that registers its info in devm memory like TIO does, unbound while /dev/pps-gen0 is open, gives: BUG: KASAN: slab-use-after-free in pps_gen_cdev_ioctl+0x4c1/0x580 Read of size 1 at addr ffff88800e647f38 by task ppsgen64/145 ... Freed by task 146: kfree+0x25a/0x6d0 release_nodes+0xd1/0x140 devres_release_all+0x10e/0x1a0 device_unbind_cleanup+0x71/0x250 device_release_driver_internal+0x41b/0x570 unbind_store+0xd9/0x100 and unloading pps_gen-dummy while its file is open oopses: BUG: unable to handle page fault for address: ffffffffa0203040 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pps_gen_cdev_ioctl+0x372/0x580 Protect info in the ioctl handler with a mutex, and clear it under the mutex on unregister, so that unregister waits for the ioctls using it and later ones fail with -ENODEV. PPS_KC_BIND does the same for a removed PPS device since commit 3649f9a6b897 ("pps: don't allow PPS_KC_BIND on removed devices"). The sysfs attributes need nothing new: they are removed, and their callbacks drained, before info is cleared. Fixes: 86b525bed275 ("drivers pps: add PPS generators support") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Danish Khateeb Acked-by: Rodolfo Giometti Link: https://patch.msgid.link/20260929124937.51114-3-danishkhateeb03@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c05c367e7a99521cd654b56042757979968b5644 Author: Weiming Shi Date: Wed Nov 4 19:16:18 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 preserve existing refill handling and restore error paths. ] Signed-off-by: Sasha Levin commit c290f8641e41c535c8201e40d6c903f40c6d6e94 Author: Ruide Cao Date: Wed Nov 4 18:46:56 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 Signed-off-by: Sasha Levin commit fb3f7101fec5ce9de523d8227811625a2e8ab9f8 Author: Chia-Yu Chang Date: Wed Nov 4 18:46:55 2026 -0500 tcp: accecn: unset ECT if receive or send ACE=0 in AccECN negotiaion [ Upstream commit 4024081feb87fb11ac7bd36d8c397ccdd81ed302 ] Based on specification: https://tools.ietf.org/id/draft-ietf-tcpm-accurate-ecn-28.txt Based on Section 3.1.5 of AccECN spec (RFC9768), a TCP Server in AccECN mode MUST NOT set ECT on any packet for the rest of the connection, if it has received or sent at least one valid SYN or Acceptable SYN/ACK with (AE,CWR,ECE) = (0,0,0) during the handshake. In addition, a host in AccECN mode that is feeding back the IP-ECN field on a SYN or SYN/ACK MUST feed back the IP-ECN field on the latest valid SYN or acceptable SYN/ACK to arrive. Signed-off-by: Chia-Yu Chang Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260131222515.8485-11-chia-yu.chang@nokia-bell-labs.com Signed-off-by: Paolo Abeni Stable-dep-of: c9c90cf437a9 ("mptcp: hold MP_JOIN msk ref when cloning reqsk") Signed-off-by: Sasha Levin commit 6cc288d84ef286e2ff80e80948f72ff1ddf4f131 Author: Kuniyuki Iwashima Date: Wed Nov 4 18:46:54 2026 -0500 tcp: Remove timeout arg from reqsk_timeout(). [ Upstream commit 207ce0f6bc131812c96cf4f6db328af5396cebac ] reqsk_timeout() is always called with @timeout being TCP_RTO_MAX. Let's remove the arg. As a prep for the next patch, reqsk_timeout() is moved to tcp.h and renamed to tcp_reqsk_timeout(). Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20251106003357.273403-5-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: c9c90cf437a9 ("mptcp: hold MP_JOIN msk ref when cloning reqsk") Signed-off-by: Sasha Levin commit 33e8f5740319996788395d85a4c100f61593cb75 Author: Tianchu Chen Date: Wed Nov 4 18:46:27 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 aaaf89f4bca97080e7297265d6e1bf486e1e5741 Author: Khasar Munkh-Erdene <02khasar@gmail.com> Date: Wed Nov 4 18:46:26 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 Stable-dep-of: 495cb31c791b ("staging: rtl8723bs: fix protected RX frame validation in decrypt path") Signed-off-by: Sasha Levin commit 0fab93d241cfb6f3aae29530a9a214157bb64087 Author: Zhang Yi Date: Wed Nov 4 18:24:09 2026 -0500 mm/truncate: look up the end-edge straddler by index [ Upstream commit f47dee903b9f0f1e4e7181e8a398a7678cabf0a5 ] In truncate_inode_partial_folio(), after the first split at the start edge, folio_split() unlocks and drops the refcount of the after-split sub-folios. The sub-folio straddling the end of the truncation range is therefore unlocked and only transiently ref'd in the page cache while the code still derives it from a page pointer inside the original folio. Between the first split finishing and page_folio() resolving split_at2, that tail page can be reclaimed, freed and reallocated as a new large folio in the same mapping at a different file offset. folio2 then points at a folio that does not cover the end boundary, yet folio2->mapping == folio->mapping still holds, so the stale pointer passes the mapping check and folio_split_or_unmap() splits a folio at a wrong position (or, with a transient refcount, a use-after-free window opens between try_get and the split). __folio_split()'s own folio != page_folio(split_at) check cannot catch this either since split_at2 has been reallocated as part of the new folio, so page_folio(split_at2) resolves back to folio2. Look the straddler up by its page index instead. __filemap_get_folio() returns the folio currently covering the boundary, ref'd and locked, with the mapping validated under the lock, so the split target is always the real folio at the end edge. Link: https://lore.kernel.org/20260928120833.3440834-3-yi.zhang@huaweicloud.com Link: https://lore.kernel.org/linux-mm/DLGXT0ERY79Z.3C5DYVJVX6S9Z@nvidia.com/ Fixes: 7460b470a131 ("mm/truncate: use folio_split() in truncate operation") Signed-off-by: Zhang Yi Signed-off-by: Andrew Morton Reported-by: Sashiko Closes: https://sashiko.dev/#/message/20260916094500.C30061F00893%40smtp.kernel.org Suggested-by: Jan Kara Suggested-by: Zi Yan Reviewed-by: Jan Kara Reviewed-by: Brian Foster Acked-by: Zi Yan Cc: David Hildenbrand Cc: Lorenzo Stoakes Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Hugh Dickins Cc: Baolin Wang Cc: Matthew Wilcox (Oracle) Cc: Joanne Koong Cc: Darrick J. Wong Cc: Cc: Yang Erkun Cc: Zhihao Cheng Cc: Kefeng Wang Cc: Cc: [ sashal: Retained try_folio_split_or_unmap() instead of folio_split_or_unmap() to preserve the uniform-split fallback. ] Signed-off-by: Sasha Levin commit 1706461eb1af814366b6d0ab413edd0876bd8033 Author: Sean Christopherson Date: Wed Nov 4 17:36:02 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: Changed the two &f->bindings references to &gmem->bindings to match the existing variable name. ] Signed-off-by: Sasha Levin commit e8660dc5713f8d5104c78bf6fe5a9825addd838b 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: Adjusted the declaration context: this tree allocates hmm_range with kzalloc() as a plain pointer rather than embedding it, so only the timeout declaration was dropped. ] Signed-off-by: Sasha Levin commit 8e5172cbd227fae32f3313cba1f3e1b9edb5c4fd 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 a37727a99d00923768932c9ee81e7dfef5f37cf8 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 f960356fa9eea57cb2237ccbe738d8fa7b7ff4df Author: Sean Christopherson Date: Thu Nov 5 12:02:08 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 de5b233cfc33e0e8355599a487a69dbbeba2150c 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