commit 98ed74f6f890c99308fe595a9aa61d139cb58495 Author: Alexandre Frade Date: Tue Nov 10 22:21:03 2026 +0000 Linux 7.3.4-xanmod1 Signed-off-by: Alexandre Frade commit 38d72a3b07ecca20999bc2d146967c9e24f23b3d Author: Masahito S Date: Mon Mar 23 02:11:53 2026 +0900 mm: Add working set protection for anon and clean file pages [v7.3.4+] sysctl vm.workingset_protection=1 by default. Fixed for merge with Linux 7.3.4 (updated shrink_one context after mem_cgroup_calculate_protection_path change). Signed-off-by: Alexandre Frade commit 84c2e20fff38932b68ae66501ef4fd832f30cd67 Merge: b911362a187c 7595a62d45ee Author: Alexandre Frade Date: Tue Nov 10 21:38:53 2026 +0000 Merge tag 'v7.3.4' into 7.3 This is the 7.3.4 stable release commit b911362a187ceddd68e2c225391772c924636952 Author: Alexandre Frade Date: Tue Nov 10 21:38:24 2026 +0000 Revert "mm: Add working set protection for anon and clean file pages" This reverts commit 93cdaac8e292ce22d01adade38913578657e27f6. commit 7595a62d45ee1a2297eafa5f2ef5d0a45142d84d Author: Greg Kroah-Hartman Date: Tue Nov 10 13:10:10 2026 -0500 Linux 7.3.4 Link: https://lore.kernel.org/r/20261107134939.434104957@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Ronald Warsow Tested-by: Salvatore Bonaccorso Tested-by: Markus Reichelt Tested-by: Joungmin Lee Tested-by: Takeshi Ogasawara Tested-by: Miguel Ojeda Tested-by: Justin M. Forbes Tested-by: Ron Economos Tested-by: Pavel Machek (CIP) Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit e7ba61734d6ad6adfd5bf617052e590743211669 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 07aca7d25ce8578fedde49855983a01c537a782b 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 5de6a41199e2e5c3e9e44aec8dcdeb325b666ea0 Author: Borislav Petkov (AMD) Date: Wed Nov 5 20:16:52 2025 +0100 x86/bugs: Mitigate TSA on AMD Zen5 commit cf27412f19c9cc5909b9107cd1b3f4ab7608e362 upstream. Zen5 is affected by TSA too, along with a third variant called TSA_FILL. Detect the vuln there and mitigate it. For Zen5, a table of microcode revisions is not needed because appropriate microcode sets the VERW_CLEAR CPUID bit, which simplifies mitigation detection considerably. Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Greg Kroah-Hartman commit 768e47c0b7b78565ef258cb8963873f8599ff6a4 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 95aa24bcb760ca8c0f1c75b1aa6d29b5d9af7011 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 91eecb7d1cd3f518667fd8e760f64a4ed0e5e2ec 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 8086088f21380ce3caf81d22ed1ff482e92527cd 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 269fee7c58a1a129c023ce218e11a16f1b044fb7 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 e0efb02fd551fe5e76e959a3112f55a612fa20e0 Author: Christian Brauner Date: Fri Oct 30 16:50:07 2026 +0100 ns: don't add init_ipc_ns and init_net without namespace support [ Upstream commit 82f1c815aaef1905c5c6c386c8a0d74f6ff70a54 ] When CONFIG_IPC_NS or CONFIG_NET_NS are turned off we still add the initial ipc and network namespace to the namespace trees. ipc_ns_init() calls ns_tree_add(&init_ipc_ns) whenever CONFIG_SYSVIPC is set and setup_net() calls ns_tree_add_raw() on init_net whenever CONFIG_NET is set. But without CONFIG_IPC_NS and CONFIG_NET_NS these aren't namespaces userspace can do anything with. They don't have proc_ns_operations so there's no /proc//ns/{ipc,net} for them, nsfs_fh_to_dentry() refuses them with -EOPNOTSUPP, and since ns->ops is NULL __ns_tree_add_raw() doesn't add them to the owner list of init_user_ns either. So they end up half registered. That's also not how we treat any of the other namespace types. Without CONFIG_UTS_NS, CONFIG_PID_NS, CONFIG_TIME_NS or CONFIG_USER_NS the initial namespace is never added to the tree. listns() walks the unified tree and calls is_current_namespace() for every namespace it finds via may_list_ns(). But is_current_namespace() only knows about CLONE_NEWIPC and CLONE_NEWNET if CONFIG_IPC_NS and CONFIG_NET_NS are set. Otherwise we end up in the default case and its VFS_WARN_ON_ONCE(). Any unprivileged caller can trigger that with a plain listns() call: WARNING: CPU: 0 PID: 526 at fs/nsfs.c:508 is_current_namespace+0x12f/0x440 Call Trace: legitimize_ns+0x25f/0x4c0 do_listns+0x185/0x5c0 __do_sys_listns+0x13b/0x300 Instead of teaching is_current_namespace() about namespaces that can't be opened, only add the initial namespaces to the tree if their namespace type is enabled. Move the registration of init_ipc_ns into ipc/namespace.c which is only built with CONFIG_IPC_NS. That also fixes CONFIG_SYSVIPC=n, CONFIG_POSIX_MQUEUE=y, CONFIG_IPC_NS=y where ipc/shm.c isn't built and init_ipc_ns was never added at all. For the network namespace only call ns_tree_add_raw() if CONFIG_NET_NS is set. Without CONFIG_NET_NS cleanup_net() isn't built and init_net is never removed so there's nothing to balance. Fixes: 74b24a582e1f ("ipc: support ns lookup") Fixes: 195f7422298d ("net: support ns lookup") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202610260917.6248e316-lkp@intel.com Cc: stable@vger.kernel.org # v6.18+ Link: https://patch.msgid.link/20261030-work-nsfs-init_ns_tree-v1-1-7ec0adb47c54@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 0cb46288f23b2d3a3c062b21b80fad9783cae8d5 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 cee09adbabd1a15e6f22b421f836a55782ab0707 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 9802608232a65e6054bad9def7d3df03c567bf58 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 501ed625cdd25d5a264e1a553439963f9a810b63 Author: Chris Mason Date: Thu Oct 29 19:03:19 2026 +0100 backing-file: always end a queued write [ Upstream commit 627cdcbc2a2eceb0452078a0c14370f9f1f17a91 ] Writes to a loop device with direct I/O on an overlay file make the next freeze of the upper filesystem hang for ever. Every kiocb_start_write() needs a kiocb_end_write(). For a write that is queued, vfs_iocb_iter_write() leaves the end to the completion, and backing_aio_rw_complete() only calls kiocb_end_write() when IOCB_WRITE is set in the flags copied from the submitter. In-kernel submitters such as loop do not set that flag, so each queued write keeps the freeze protection of the backing filesystem. Direct writes to a loop device with direct I/O backed by an overlay file left fsfreeze of the ext4 upper filesystem, and a later touch there, blocked in D state. It takes write access to the node of the loop device, which root has by default, to attach the file and to write. The fix used here is to mark a write in struct backing_aio and to call kiocb_end_write() on completion of every marked write. Reproduced under qemu without KVM, on v7.3-rc6-21-g602042bf29f6 with earlier fixes of this series applied, with and without this change, once each. The kernel was not changed for the run. With this change fsfreeze finished in about a second. Not run: the nvmet and LIO file backends, which do not set IOCB_WRITE either, FUSE passthrough, and an xfs upper filesystem. Fixes: 2406a307ac7d ("ovl: implement async IO routines") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason [amir: use aio->is_write to explicitly mark a write aio] Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/20261029180319.2852090-1-amir73il@gmail.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 5c38de5f536e286264be35a71c2290f5bf947bab 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 6e68116a8559a7d181c836043d357e9c9b20b6a5 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 e1f58c0f5b89863e300e290187a2bb000719f5bf 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 9af2f7e0994af496755bf5142607d36f258df214 Author: Iván Ezequiel Rodriguez Date: Wed Oct 28 12:43:12 2026 -0300 arm64/gcs: release GCS on failed fork [ Upstream commit 078e122f3bf000dd45965997b66deac10ee580fa ] copy_thread() can map a CLONE_VM GCS and still return 0. A later copy_process() failure calls exit_thread(), but arm64 did not implement it, so the VMA stayed in the parent's mm. Wire HAVE_EXIT_THREAD to gcs_free(). Kernel threads created with CLONE_VM (io_uring and vhost workers) inherit the parent's gcs_base/gcs_size from arch_dup_task_struct() without allocating their own GCS. When such a thread exits, exit_mm() -> mm_release() -> deactivate_mm() -> gcs_free() unmaps the parent's GCS. With the new exit_thread(), a failed copy_process() for one of these threads would do the same. Clear these fields in copy_thread(). Fixes: 506496bcbb42 ("arm64/gcs: Ensure that new threads have a GCS") Cc: stable@vger.kernel.org Cc: Mark Brown Assisted-by: LLM Signed-off-by: Iván Ezequiel Rodriguez Reviewed-by: Mark Brown Tested-by: Mark Brown Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 2390625ee60eb12b6ffd9834511df250c1634bb3 Author: Georgia Garcia Date: Wed Oct 14 19:08:21 2026 -0300 apparmor: fix profile leak when a policy load fails [ Upstream commit ce94927fa4173fcc1eca27bdc65a140064c8f1e6 ] The error paths of aa_replace_profiles() and aa_unpack() do not break the refcount cycle between label and proxy. They just aa_put_profile() the new profiles, which drops the label refcount from 2 to 1, and the proxy keeps the profile alive. Every failed atomic policy load (e.g. "profile can not be replaced", or a later profile in the blob failing to unpack) leaks every new profile in the set, along with its proxy, rules and its loaddata reference. The leak is usually not visible from userspace, because the raw_data directory for a failed load is not created, but it becomes visible when the blob is deduplicated onto an existing loaddata, which then keeps its policy/raw_data/ directory forever. Add aa_put_unpublished_profile(), which drops the profile's own proxy before putting the profile, and use it on those error paths. The proxy of an unpacked profile is always freshly allocated and not referenced by anything else before the profile is published, so putting it is safe. Fixes: 637f688dc3dc ("apparmor: switch from profiles to using labels on contexts") Cc: stable@vger.kernel.org Signed-off-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 1ef534f49b193036fff65a8270b7afd990cb57c3 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 64d601ac18874892cb96bf81dab1fedfe77f41df Author: Cen Zhang (Microsoft) Date: Mon Oct 12 17:57:03 2026 -0400 apparmor: fix query_data() output overlapping the lookup key [ Upstream commit d30844001360a403a511cf24fc75ecaa6a7a7544 ] In query_data(), buf and query point into the same multi_transaction buffer: buf at the start, query a few bytes in, and the lookup key right after the label string that query points to. Reusing the buffer is by design and is safe as long as the query is fully parsed before buf is written to, but the key is not: it is dereferenced on every iteration of label_for_each_confined(), after output has already been written. So when the label has more than one profile with a data table, the data of the first matching profile is written to buf while the key is still needed, and overwrites it if the data is large enough. The later lookups then run on a corrupted key. Besides, if the data has no NUL byte from the key's position to the end of the allocation, strhash() -> strlen() -> jhash() reads past the 4096-byte slab object, triggering an out-of-bound read: BUG: KASAN: slab-out-of-bounds in jhash+0x595/0x5e0 Read of size 1 at addr ff1100001159d000 by task exploit/155 CPU: 0 UID: 1000 PID: 155 Comm: exploit Not tainted 7.3.0-rc7 #1 Call Trace: jhash+0x595/0x5e0 aa_write_access+0x880/0x1400 vfs_write+0x26f/0xd20 ksys_write+0x115/0x210 Writing to the .access file is unprivileged (0666), but triggering this requires loaded profiles that carry a data table, which needs CAP_MAC_ADMIN and is not the case on default distribution policies. Fix by copying the key with kstrdup() before writing any output to buf, so the key stays valid across all loop iterations regardless of what gets written to the overlapping buffer. Fixes: 317d9a054e1c ("apparmor: update query interface to support label queries") Cc: stable@vger.kernel.org # v4.13+ Cc: Francis Perron Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft) Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 7653d28a1b7d93d886906c6c088de5d77a788031 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 a7b2e3bac0e1bcde13810f6b9b20408a89117deb 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 92ab39831d6931bdd1a669c513baafdb9cf1c22d 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 8d41718618ed58bab0cce12811c6a62491988f45 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 dabd6ac70acaa838e011df72286734faa318f99b 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 830ff89b391e561b16e195bb2d92fded2d8c0456 Author: Josef Bacik Date: Sun Oct 4 15:00:12 2026 +0000 pidfs: don't let PIDFD_GET_INFO miss a reaped task [ Upstream commit 172658cf600904ff6121e240f69a0ccb36e65d6b ] PIDFD_GET_INFO describes the task while there is one, and with PIDFD_INFO_EXIT its exit status once it has been reaped. pidfd_info() looks at the two in the wrong order and can miss both: pidfd_info() release_task() PIDFS_ATTR_BIT_EXIT is not set pidfs_exit() __unhash_process() get_pid_task() == NULL goto copy_out The ioctl succeeds with neither PIDFD_INFO_PID nor PIDFD_INFO_EXIT in the mask. If the task is unhashed a little later, after get_pid_task(), its pid reads as 0 and the ioctl fails with -ESRCH, although the caller asked for the exit information and it is available by now. The second case does not even need an exit. When a sub-thread execs, de_thread() hands the leader's pid over to it and releases the old leader. A caller that got hold of the old leader reports the tid of the sub-thread as the pid, or -ESRCH for a process that is alive. Look up the task first. pidfs_exit() runs before the task is unhashed, so a caller that finds no task finds the exit information; this needs a barrier on both sides because taking tasklist_lock does not order the store in pidfs_exit() against the one in detach_pid(). And start over if the task no longer owns the pid when all the fields have been read: then there is either exit information or another task. Go by the pid for that check and for the pid we report, not by ->thread_pid of the task. exchange_tids() moves the pid to the exec'ing thread before it updates ->thread_pid of either task. A caller that finds the new leader in between would read the old tid of the sub-thread from ->thread_pid, and a check of ->thread_pid would restart until the exec'ing thread gets to its store. On PREEMPT_RT that thread can be preempted with tasklist_lock held and can't move to another CPU. If the RT task that preempted it calls PIDFD_GET_INFO, the ioctl spins until the exec'ing thread gets the CPU back, and that never happens if the exec'ing thread is an RT task of lower priority. Christian Brauner says: Go by @pid instead of ->thread_pid of the task for the reported pid and for the restart check. Fixes: 7477d7dce48a ("pidfs: allow to retrieve exit information") Fixes: cdda1f26e74b ("pidfd: add ioctl to retrieve pid info") Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 5ceae3d2c5e4d7975c29d5a2dd65dd6cfb5f77a4 Author: Josef Bacik Date: Sun Oct 4 00:10:59 2026 +0000 nstree: don't end listns() at an inactive namespace [ Upstream commit da29ac46d34a19e8cc328ad17cb88713fd4563fa ] listns() resumes after the last returned id by looking up the first namespace with a larger id with lookup_ns_id_after(), or with lookup_ns_owner_after() when filtering by owner. Both also take a reference with ns_get_unless_inactive(). If that namespace is inactive, e.g. a network namespace that is only pinned by a socket or a user namespace that is only pinned by a file's credentials, or if it is being torn down, the lookup returns NULL and listns() fails with -ENOENT. Userspace takes that as the end of the list, so every namespace after it is silently missed: ids 10 (active), 11 (inactive), 12 (active) listns(ns_id = 0, nr = 1) -> 10 listns(ns_id = 10, nr = 1) -> lookup_ns_id_after(10) -> NULL, -ENOENT 12 is never listed A call without a cursor doesn't have this problem because the loop just skips the namespaces that legitimize_ns() rejects. The reference only kept the starting point valid until the RCU walk began. Look it up under rcu_read_lock() instead, without taking a reference. The namespace can't be freed before the RCU read-side section ends, and if it is unlinked in the meantime its ->next still leads back into the list, which the walk already relies on for every other entry. The starting namespace then goes through legitimize_ns() like every other one, and kls->first_ns isn't needed anymore. Reported-by: shaos Link: https://lore.kernel.org/r/20261020110746.959806-1-shawnq1@163.com Fixes: 76b6f5dfb3fd ("nstree: add listns()") Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 2dea9ba94bc286f7b4f754642eabd71b8b92e7ac 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 aece5f74f1e4a112f52adcc2af9b888ab2072562 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 4c24ed7a2653db137297fe8120daab7a84854290 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 a0da1ee51f1dfa7c3ddac48bdb04858264b56539 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 06ec699318fe3a1747bd49ccd8af577db2fd8419 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 3ace65e1001ea5fa82a178a1d3178fef1f6da3a2 Author: Josef Bacik Date: Thu Oct 29 11:34:49 2026 +0100 iomap: keep large chunks from defeating the bio cap [ Upstream commit eb8ab8c23e71c6ae77dedc45de2a57a61558e5d5 ] For integrity I/O a bio must not grow beyond max_integrity_io_size() because the integrity buffer is a single allocation of at most 2 MiB. Writeback and buffered reads check that before adding to a bio: bio->bi_iter.bi_size > iomap_max_bio_size(iomap) - len The subtraction is done in size_t and wraps if len alone is above the limit. The check then never fires and the bio grows until it runs out of bio_vecs. That's easy to hit. The limit is also capped by the maximum segment size which is 64 KiB for SCSI hosts that don't set it, such as lpfc and qla2xxx, and XFS uses folios of up to 2 MiB. Writeback of a preallocated 300 MiB file then builds a single bio that needs 4.7 MiB of PI with 512 byte sectors and 8 byte tuples. That's more than kmalloc() can do, so bio_integrity_alloc_buf() falls back to a 2 MiB mempool element and generating the PI writes 2.7 MiB past its end. Check the length on its own first. A chunk above the limit still gets a bio of its own which is never larger than a folio. Fixes: 0b10a370529c ("iomap: support T10 protection information") Cc: stable@vger.kernel.org # v7.1+ Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261029-work-iomap-ai-fixes-v1-2-7eda63bc1b13@kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 526d31b2b579b5c93efc2863caf92fae0638cbcb Author: Christian Brauner Date: Thu Oct 29 11:34:48 2026 +0100 iomap: don't mark unwritten parts of a folio uptodate [ Upstream commit a4193b4af359db84b2cdf3a040752861984c636b ] For a buffered write into a hole, an unwritten or new extent, or past EOF __iomap_write_begin() zeroes the parts of the blocks outside of the write and then marks the blocks uptodate. That includes the range of the write itself which still holds whatever was in the folio before. It only becomes valid once the copy from userspace has filled it in. But the copy can come up short and __iomap_write_end() only rejects a short copy if the folio isn't uptodate. If the zeroed blocks were all that was missing the folio is uptodate by then, the short copy is accepted, and the rest of the range is exposed to readers and can end up on disk. A source buffer that ends in an unmapped page is enough: ftruncate(fd, 4096); pwrite(fd, p, 3000, 100); /* 16 bytes at p, then PROT_NONE */ pread(fd, buf, 4096, 0); The write returns 16 and the read returns 2984 bytes of whatever was in that page before. If other blocks of the folio aren't uptodate the short copy is rejected but the zeroed blocks keep their uptodate bits and the retry with the copied length leaves the same bytes behind. Only mark blocks uptodate in __iomap_write_begin() after reading them. __iomap_write_end() marks the zeroed blocks uptodate once the copy has succeeded and rejects a short copy. Willy reported this back in 2024 (cf. [1]) and Zhang Yi posted the same fix (cf. [2]) but it never got merged. [1]: https://lore.kernel.org/all/ZqsN5ouQTEc1KAzV@casper.infradead.org [2]: https://lore.kernel.org/all/20240812121159.3775074-6-yi.zhang@huaweicloud.com Fixes: 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O without buffer heads") Reported-by: Josef Bacik Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261029-work-iomap-ai-fixes-v1-1-7eda63bc1b13@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 84c85fd001b8f0176246900584687db626b8435b Author: Noam D. Eliyahu Date: Tue Oct 27 00:09:56 2026 +0200 tg3: Invert restart quirk logic to restrict SNP power-down bypass [ Upstream commit d7314b51341c037973ce022f12c6009fd07b021e ] Commit 9fc3bc764334 ("tg3: power down device only on SYSTEM_POWER_OFF") bypassed `tg3_power_down()` on system restarts to prevent reboot hangs and NMIs on servers where NICs were initialized via SNP (such as Dell PowerEdge R650 and R750). However, skipping the power-down flow globally causes the ACPI _PTS method to trigger fatal PCIe AER events and hangs on other models. Commit e0efe83ed325 ("tg3: Disable tg3 PCIe AER on system reboot") attempted to mitigate this by adding an AER-disable DMI quirk table. Maintaining a growing list of models for a secondary symptom misses the root cause, leaving systems like the PowerEdge T440 (sharing the BCM5720 NIC) exposed. Fix this by inverting the quirk logic: 1. Restrict SNP power-down avoidance strictly to `tg3_restart_snp_quirk_table` for the specific systems requiring it (Dell PowerEdge R650 and R750). 2. Restore standard power-down behavior for all other systems, eliminating the separate AER-disable quirk table. For systems affected by the original SNP restart issue, their shutdown flow remains completely untouched. Link: https://lore.kernel.org/netdev/20251221175050.14089-1-noam.d.eliyahu@gmail.com/T/#u Fixes: 9fc3bc764334 ("tg3: power down device only on SYSTEM_POWER_OFF") Fixes: e0efe83ed325 ("tg3: Disable tg3 PCIe AER on system reboot") Cc: stable@vger.kernel.org Signed-off-by: Noam D. Eliyahu Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/20261026220955.473247-1-noam.d.eliyahu@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 82117f3e6680320f8b94a0b8ccb17f80b029c8e5 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 43aba2eeaa34e045bdd73abfe66c8bd3fed97852 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 0968d98e72356652aaf0ac029a16a36e5f4d46b2 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 a9e81456067456911da0de41c51f59ff807dc45e 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 13ee3f157a463b8186f0a6027e253f0c8a2884e2 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 8c754fe997144edada4ed2853fb6f8b73aae5e04 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 5f0436428b871b2cc800228837ea49a44d5169ec Author: Eric Biggers Date: Sun Oct 25 13:45:34 2026 -0700 fsverity: Tell LSMs about signature only after verity is enabled [ Upstream commit 28d74059fddbd8ae83c7715056b303c402071f6f ] FS_IOC_ENABLE_VERITY calls security_inode_setintegrity() before verity has finished being enabled. That's broken because enabling verity can still fail at that point, e.g. due to insufficient xattr space. Afterwards, arbitrary contents can be written to the file, which doesn't actually have verity enabled. The in-core inode stays the same, so the LSM considers it to have verity enabled with a valid signature. (Or rather, in the case of IPE, which is the only LSM that implements security_inode_setintegrity(), it also checks IS_VERITY(), which can be bypassed by enabling verity with no signature after the file writes.) Fix this by moving the call to security_inode_setintegrity() out of fsverity_verify_signature() and into a new function that is called from the appropriate places. Fixes: 7c373e4f1445 ("fsverity: expose verified fsverity built-in signatures to LSMs") Cc: stable@vger.kernel.org Reviewed-by: Fan Wu Tested-by: Fan Wu Link: https://patch.msgid.link/20261025204534.122506-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit 1ea9efcbeb49f0a61ff1143ed40be72e3bc53914 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 c4b9b5e0cac400c13d02ea71b44525d68170e7bc Author: Eric Biggers Date: Thu Oct 22 21:15:22 2026 +0000 fsverity: Explicitly require FMODE_READ to retrieve hashes [ Upstream commit 1acb4fd2d011c4bd6cc961095ae17361c71ff61a ] The comment in fsverity_ioctl_read_metadata(), which justifies not checking for FMODE_READ, doesn't consider that the nonstandard access mode 3 (ioctl-only) exists. Opening an ioctl-only fd generally requires read (and write) permission. However, there are gaps with certain LSMs: an ioctl-only fd requests read (and write) permission via security_inode_permission, but not security_file_open. With certain LSMs relying on the latter, such as Landlock and AppArmor, an ioctl-only fd can be opened without the LSM granting read (and write) permission. Since FS_IOC_READ_VERITY_METADATA returns hashes of file contents blocks, it should require read permission. This also applies to FS_IOC_MEASURE_VERITY, which returns a hash for the whole file. Meanwhile, ioctl-only fds are a rarely-used feature, not known to be used with either ioctl. Therefore, just disallow these ioctls on ioctl-only file descriptors, similar to what was already done with FS_IOC_ENABLE_VERITY. More specifically, explicitly check for FMODE_READ. This also covers write-only fds to non-verity files which otherwise would have failed with ENODATA. This change in error code for write-only fds should be fine too, as these ioctls cannot be usefully used with write-only fds anyway, but it's worth noting as another technicality. Fixes: 4dd893d832cf ("fs-verity: implement FS_IOC_MEASURE_VERITY ioctl") Fixes: e17fe6579de0 ("fs-verity: add FS_IOC_READ_VERITY_METADATA ioctl") Cc: stable@vger.kernel.org Reviewed-by: Andrey Albershteyn Link: https://patch.msgid.link/20261022211522.1489943-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit 3da6acf8387e699f142d0bb723e921f2cca529da 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 73649d488e6efb9f6e40add1a0405b2e7853e632 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 61485a6e004eaf84d5ee4d7eb27501247ce77524 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 d8dfde4f7a7b77c3583eb123a50949e16259baac Author: Yingjie Wang <1075151112@qq.com> Date: Wed Oct 28 19:57:20 2026 +0800 nvme-tcp: validate the TLS handshake timeout [ Upstream commit 799203afd298b1f8e9ee49815eb38f775f211299 ] tls_handshake_timeout is writable but stored as a signed int. Multiplying the value by MSEC_PER_SEC and HZ therefore uses signed arithmetic. With HZ=1000, setting it to 2147484 overflows both multiplications. If the handshake request is accepted and its completion remains pending, schedule_timeout() reports a wrong timeout value with a stack dump and returns zero. The handshake then fails immediately with -ETIMEDOUT, while the handshake agent was given about 24.9 days. Negative values such as -1 have the same kernel-side effect. Store the parameter as an unsigned int and reject values that cannot be represented both by tls_handshake_args::ta_timeout_ms and by a safe jiffies delay. Take one snapshot so a concurrent parameter update cannot give the handshake agent and completion wait different timeouts. Document the accepted range for built-in use. wait_for_completion_interruptible_timeout() returns the remaining jiffies as a long after a successful completion. Keep that result in a long because an accepted timeout can exceed INT_MAX jiffies on 64-bit systems. Negative and oversized values now fail with -EINVAL. Keep zero valid, preserving the existing immediate-timeout behavior. Fixes: be8e82caa685 ("nvme-tcp: enable TLS handshake upcall") Cc: stable@vger.kernel.org Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Signed-off-by: Yingjie Wang <1075151112@qq.com> Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 4e24e3f249234887e16bee2275234e3bbe8ce04d Author: Yingjie Wang <1075151112@qq.com> Date: Wed Oct 28 19:57:19 2026 +0800 nvmet-tcp: validate the TLS handshake timeout [ Upstream commit e3e7a85730a4b17efa1e2ff4088443c4753be683 ] tls_handshake_timeout is writable but stored as a signed int. Multiplying the value by MSEC_PER_SEC and HZ therefore uses signed arithmetic. With HZ=1000, setting it to 2147484 overflows both multiplications. If the handshake request is accepted and remains pending, the timer wheel treats the jiffies delay as already expired and queues the timeout work on its next advance, while the handshake agent was given about 24.9 days. Negative values such as -1 cause the same immediate kernel-side timeout. Store the parameter as an unsigned int and reject values that cannot be represented both by tls_handshake_args::ta_timeout_ms and by a safe jiffies delay. Take one snapshot so a concurrent parameter update cannot give the handshake agent and delayed work different timeouts. Document the accepted range for built-in use. Negative and oversized values now fail with -EINVAL. Keep zero valid, preserving the existing immediate-timeout behavior. Fixes: 675b453e0241 ("nvmet-tcp: enable TLS handshake upcall") Cc: stable@vger.kernel.org Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Signed-off-by: Yingjie Wang <1075151112@qq.com> Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 21a812abcc98ea8f68e22768577dd76ee63d4354 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 c0b4e770ec74f7d3cb3c9961a08ddd4c12997f79 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 6aba58adb5ff9d4b62b820518f409f1ee615021a 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 9998d585bd094bb652376ee7d91d1b8e31eef4e2 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 142aff2ead903d437650b938d9eb0c8c1a19e175 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 9713fd7ca4523e89130b02100e7cce004f7f6eed 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 ca67ea4f835648d931c59cd6f80379468ccc5c07 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 9274d3aa39ddf3cad4836b9ba3ca9759660c31b9 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 c32b169fb13c22a8723db2467a54b6c0079fd84b 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 6ce60c9226ca583b2b94be63728f3612204f9952 Author: Andrew Stellman Date: Wed Oct 21 01:07:48 2026 -0400 nvmet-rdma: fix out-of-bounds write in nvmet_rdma_map_sgl_inline() [ Upstream commit d1512773a0d539669440bd9f6d050b8e12923b5f ] nvmet_rdma_map_sgl_inline() bounds the host-supplied in-capsule SGL offset with "off + len > inline_data_size", evaluated in 64-bit arithmetic. off is taken straight from the host SGL descriptor (le64_to_cpu(sgl->addr)) and len is promoted to 64-bit, so the sum wraps: an off within len of 2^64 makes it small and the check passes. off is then used as page_idx = off / PAGE_SIZE to index the fixed-size rsp->cmd->inline_sg[] array (NVMET_RDMA_MAX_INLINE_SGE entries), so a crafted offset yields an out-of-bounds scatterlist index that is written through in nvmet_rdma_use_inline_sg(). The mapping runs while handling a received capsule, before the command executes, so a remote RDMA peer can reach it (the Connect capsule is a write and takes this path on a queue that has no controller yet). The host controls only the low bits of the resulting displacement, so the expected impact is an out-of-bounds write that faults the target (remote denial of service). This wrap was reported, with a KASAN reproduction, on linux-nvme in May, and the check below was suggested in that thread. The fix that was applied, 48c0162f647b, reworked how the offset is mapped but kept the original check, and its page index turns a wrapped offset into an out-of-bounds index into inline_sg[]. Reject the offset before it can wrap. Found independently by static analysis with AI assistance, not reproduced at runtime. Fixes: 0d5ee2b2ab4f ("nvmet-rdma: support max(16KB, PAGE_SIZE) inline data") Fixes: 48c0162f647b ("nvmet-rdma: handle inline data with a nonzero offset") Reported-by: Bryam Vargas Closes: https://lore.kernel.org/all/LM21QIR-1-qJb7PViyJKCnGBnUzizeiNJVWQ3wb7ZwGezodjgKg3f-iobqOyequ-sT1jFCKJImfqNO_BKU3KO80xFITnaI5GTV_GxLUNDDc=@proton.me/ Suggested-by: Keith Busch Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Andrew Stellman Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit c17d443d1e984a0c0840692c6435cdc455936160 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 87d9db801d7ab49534458d59b5ed4a2802f582d6 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 191db8421453dbe75b0efd3f37d3046e0016343b Author: Jérémy Jean Date: Fri Oct 23 18:51:19 2026 +0000 inet: frags: prevent acceptance of partially authenticated reassembly [ Upstream commit 6fb4e32f2ce3234ae0c416872e911706a3484430 ] A reassembled skb retains the secpath from its first fragment, which makes it possible for the final policy check to accept bytes that were not covered by the transform recorded on the skb. This can affect IPsec tunnel traffic, including AH and ESP, and allow a packet to be accepted even though only part of its payload was authenticated. Reject a fragment when its secpath differs from the fragments already in the queue, and keep overlap statistics limited to actual overlaps. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Jérémy Jean Reviewed-by: Eric Dumazet Signed-off-by: Dave Miller Signed-off-by: Sasha Levin commit 1bd329d8486fe812c18fc05655fedbc3114f5ed0 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 3fe9fe9e3580e81c6383d39793201fd54e3ac399 Author: Huacai Chen Date: Wed Oct 28 15:09:27 2026 +0800 soc: loongson: loongson2_pm: Fix build warnings for 32BIT [ Upstream commit 48b960ad7057f84a375ae7ec803ea3ba6b038b5c ] Since loongson_sysconf.suspend_addr is unsigned long, use "unsigned long" instead of "u64" for casting, so as to avoid build warnings for 32BIT: drivers/soc/loongson/loongson2_pm.c: In function 'loongson2_pm_probe': >> drivers/soc/loongson/loongson2_pm.c:178:49: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 178 | loongson_sysconf.suspend_addr = (u64)phys_to_virt(suspend_addr); | Cc: stable@vger.kernel.org Fixes: 3d9aba6618d1 ("LoongArch: Adjust build infrastructure for 32BIT/64BIT") Closes: https://lore.kernel.org/oe-kbuild-all/202610190549.WM2PO3vO-lkp@intel.com/ Reported-by: kernel test robot Reviewed-by: Arnd Bergmann Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 77edec56cd5c9e8bcb105a43a953e3fca091f119 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 81e354bc1e5568fd56ebe1caf1a828df67294d93 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 119ab8d9dd61c24a604be6175dc658cebb3a3bbd 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 a89cd92f8a52bb3b60161d672dd55265db8fa742 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 62f5a53cc64386a00a63b9d4ec22bfce2ed1a35e 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 e9e219cc9f542041ab1eb7ac10bf6f01a9d7ed01 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 d014a7a61d19fb23895a6cffcb44c961ef3a9b6b Author: Fangzhi Zuo Date: Mon Oct 5 16:22:39 2026 -0400 drm/amd/display: Poll passive DVI sinks for EDID readiness [ Upstream commit e9ddfb93fafa50f92165d2b48c7728720999b117 ] A passive DP-DVI adapter is identified when the adapter DDC probe does not respond, but the downstream monitor's EDID EEPROM may still need time to become available after resume. Poll the downstream DDC address for passive DP-DVI links before reading and parsing the EDID. Keep the eDP detection optimization without adding a generic EDID retry delay or a deferred connector reprobe. Revert commit 3001d2073d65 ("drm/amd/display: Exit IPS before connector detection on resume") and rely on targeted passive DP-DVI EDID readiness polling instead of the generic pre-detection IPS exit. Fixes: d1d51519bc3b ("drm/amd/display: Skip eDP detection when no sink") Reviewed-by: Roman Li Signed-off-by: Fangzhi Zuo Signed-off-by: Tom Chung Tested-by: Karthikeyan B Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 8297e1c724733fc59027b717df73680eaf03dd56) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit e566ee7fd40a3ae56e85a4004270f2ef187c1c0d 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 c82c35882df4424f28dbcff1605d7211e41de767 Author: Jesse Zhang Date: Thu Oct 15 22:59:25 2026 +0800 drm/amdgpu: drop the gang leader reference when freeing gang jobs [ Upstream commit c1584e10a7deb655438f21867b2b7a356a9aaf9f ] Every job of a gang except the leader holds a reference to the scheduled fence of the leader in job->gang_submit. Only amdgpu_job_free(), used for jobs which never ran, drops it, so for every gang submission which completes the scheduler fence of the leader, and with it its hardware fence, is leaked. amdgpu_job_free() in turn checks for the leader only after drm_sched_job_cleanup() cleared the scheduler fence, so a leader freed there drops a reference it never took. On navi31, 100 submissions of a GFX + COMPUTE gang grow the slab cache drm_sched_fence is merged into by 60 to 180 objects each time, while 100 GFX only submissions don't. Use amdgpu_job_free() for the jobs the scheduler frees too, and check for the gang leader there before drm_sched_job_cleanup() clears the scheduler fence. As the scheduler clears the entity of the jobs it picked up, check for the scheduler fence instead to tell whether the job needs cleaning up. Keep freeing the remaining IBs with amdgpu_job_free_resources() after drm_sched_job_cleanup(), so that it frees them with the hardware fence or right away and not with the scheduler fence, which nobody signals for jobs aborted after drm_sched_job_arm(), like a CS returning -EAGAIN. v2: unify amdgpu_job_free() and amdgpu_job_free_cb() (Christian), don't free the remaining IBs with the scheduler fence v3: drop the comments (Christian) v4: free the IBs with amdgpu_job_free_resources() again (Christian) Fixes: 68ce8b242242 ("drm/amdgpu: add gang submit backend v2") Fixes: f7d66fb2ea43 ("drm/amdgpu: cleanup scheduler job initialization v2") Reviewed-by: Christian König Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit df4d6d404d44bbc8fc850bc7f9f136a25dabf180) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit b1be57298de6f000b4b6fdfb807278ac12a299e6 Author: Jesse Zhang Date: Mon Oct 12 09:27:03 2026 +0800 drm/amdkfd: send SMI process and VM fault events only to allowed clients [ Upstream commit 2e0f334f5c7140b67f16eff9d93c2ca426848664 ] Commit 92a8dba246d3 ("drm/amdkfd: fix SMI event cross-process information leak") made the VMFAULT and PROCESS_START/END SMI events carry the pid of the process they are about, so that kfd_smi_ev_enabled() only passes them to clients of that process and to privileged clients. Commit 1142738572ef ("drm/amdkfd: Fix SMI event PID reporting for containers") then switched kfd_smi_event_add() to take a task and passed NULL for these events, i.e. pid 0, which every client receives again. On navi31, an unprivileged SMI client (uid 1000) subscribed to PROCESS_START/END sees root running rocminfo: event: c 223a9 rocminfo event: d 223a9 rocminfo The same commit also made the filter compare PIDs of different namespaces: the client stores its PID in its own namespace and events use the PID of the task in the task's namespace, so a client that is PID 1 in one container receives the events of PID 1 in another. And an exited task has no PID in its namespace anymore, which gives pid 0 for PROCESS_END. Match clients by global TGID, which is unique and stays valid after the task exited, and keep showing the namespace PID in the event text. Pass the TGID of the process for the process and VM fault events again. With this the unprivileged client gets nothing, a root client still gets both events, and an unprivileged client that is PID 1 in its own PID namespace no longer gets the events of rocminfo running as PID 1 in another one. v2: rename the pid of the clients and of the filter to tgid (Felix) Fixes: 1142738572ef ("drm/amdkfd: Fix SMI event PID reporting for containers") Reviewed-by: Felix Kuehling Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit 77f5f4eae104a96399a5b1003730d5d739368b7d) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 437fa225f646ee74eef462f592160e608b231d74 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 77b5960eed8a2db25068090ffd3397de003c442d Author: Kevin Wang Date: Thu Oct 15 14:02:31 2026 +0800 drm/amd/pm: preserve committed OD features for SMU 14.0.2 [ Upstream commit 9b0890e72d19b0c430fe62bad290c7c79baa78e4 ] PMFW treats FeatureCtrlMask as the complete set of active OD features. Uploads containing only newly edited bits can drop earlier settings. Fix the OD state handling to: - preserve committed features across later commits - keep fan-curve and legacy-fan bits mutually exclusive - keep staged OD settings out of power-cap writes - update cached state only after successful uploads - clear restored features only after they return to defaults - restore PPT for the current AC/DC source after resume Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/3625 Signed-off-by: Kevin Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit 8d4ce79aff1cd1ff4feea4967c30e04eb6be8c2d) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit e4cd2648bd4bac843f85c1e833a78e35518a8e0f Author: Kevin Wang Date: Thu Oct 15 14:02:09 2026 +0800 drm/amd/pm: preserve committed OD features for SMU 13.0.0/13.0.7 [ Upstream commit 6027db7db773714f2e05df82093276f2a52a1fba ] PMFW treats FeatureCtrlMask as the complete set of active OD features. Uploads containing only newly edited bits can drop earlier settings. Fix the OD state handling to: - preserve committed features across later commits - keep staged OD settings out of power-cap writes - update cached state only after successful uploads - clear restored features only after they return to defaults - restore PPT for the current AC/DC source after resume Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/3625 Signed-off-by: Kevin Wang Reviewed-by: Kenneth Feng Tested-by: José Miguel Sarasola Signed-off-by: Alex Deucher (cherry picked from commit adf63026e1fa706de48d986ac6c1a7cb64cbf927) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 761f2c927c3610002e48f302093d7525f8104a25 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 72360c3c34ef95f4ca0b27574c765d67504516c2 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 d2de9c385d5e6de5f27391357359a77c79f22b68 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 bdea56cbdfd91d7c2743a69455a9fd9ba5da506d 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 4a7b3618f6b9b1718da0aed7d237eca13823dcec Author: Olivier Kaloudoff Date: Thu Oct 15 21:30:37 2026 +0200 drm/amdgpu: guard VCE/UVD sched entity teardown on failed probe [ Upstream commit c3fed6272bb4771a849c33c781af99afa90e90ad ] Since commit 037b98a2312e ("drm/amdgpu: move UVD and VCE sched entity init after sched init"), drm_sched_entity_init() for the VCE and UVD kernel entities runs in the scheduler-init phase, well after the IP-block sw_init phase has allocated the vcpu_bos. If probe fails between the two phases, amdgpu_device_fini_sw() still runs the per-IP sw_fini callbacks for blocks that did complete sw_init. Both amdgpu_vce_sw_fini() and amdgpu_uvd_sw_fini() then call drm_sched_entity_destroy() on an entity that was never initialized: entity->rq is NULL and drm_sched_entity_flush() dereferences it, oopsing in whatever context drove the failed probe. The hole was latent-but-safe until commit 2df5efb45425 ("drm/sched: Remove redundant entity->rq initialization and checks") removed the if (!entity->rq) early return that commit 1decbf6bb0b4 ("drm/sched: Fix entities with 0 rqs.") had put in drm_sched_entity_flush(), on the grounds that entity->rq can never be NULL. That holds only for entities that completed drm_sched_entity_init() — not for the never-initialized entity this teardown path reaches. Observed on real hardware: MI50 (Vega20, VCE 4.0 / UVD 7.2) behind a Thunderbolt link — a pciehp presence/link-change event re-probes the device; when the re-probe fails (-EINVAL here), the cleanup path NULL-derefs inside drm_sched_entity_flush() in the pciehp IRQ thread and takes the whole machine down (panic_on_oops, EFI pstore capture). Reproduced twice on 7.3-rc5, 2026-10-06 and 2026-10-09, identical signature; the faulting instruction is `mov (%rax),%r15` on rax = entity->rq == NULL, i.e. `sched = entity->rq->sched`: BUG: kernel NULL pointer dereference RIP: drm_sched_entity_flush+0x34/0x2d0 [gpu_sched] drm_sched_entity_destroy amdgpu_vce_sw_fini vce_v4_0_sw_fini amdgpu_device_fini_sw ... pciehp_configure_device pciehp_handle_presence_or_link_change Guard the entity teardown on entity->rq, which is set only by drm_sched_entity_init(). amdgpu_ring_fini() already self-guards via the rings[] registration, and the vcpu_bo/firmware cleanup still runs as before. v2: retarget Fixes: at commit 2df5efb45425 ("drm/sched: Remove redundant entity->rq initialization and checks") — the !entity->rq check from commit 1decbf6bb0b4 ("drm/sched: Fix entities with 0 rqs.") that Alex pointed to was removed by it in the 7.3 window, so this is a regression there, not a pre-existing hole. Fixes: 2df5efb45425 ("drm/sched: Remove redundant entity->rq initialization and checks") Cc: Tvrtko Ursulin Cc: Philipp Stanner Cc: Alex Deucher Cc: Christian König Signed-off-by: Olivier Kaloudoff Reviewed-by: Tvrtko Ursulin Signed-off-by: Alex Deucher (cherry picked from commit 3ad55d18f468fa81be725301d1e138ecd5148e6a) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 3ffe956b39231b3ee079bef4c9984edf9c536ffb 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 6a0eed6acab0b93df4055548aeae1355dcaf234b Author: Olivier Kaloudoff Date: Tue Oct 13 20:53:11 2026 +0200 drm/amdkfd: tear down KFD processes before early fini_sw on disconnect [ Upstream commit 1233dd17f99c75787a31035656ecfeff80522421 ] On surprise removal, amdgpu_device_fini_hw() calls amdgpu_amdkfd_device_fini_sw() when pci_dev_is_disconnected() is true. fini_sw frees kfd.dev, but KFD processes may still be alive and hold references to it: kfd_process_destroy() dereferences kfd.dev via kfd_processes_remove(), and svm_range_list_fini() / kfd_process_free_outstanding_kfd_bos() touch per-device SVM state. The kfd_processes_count wait only happens later in kgd2kfd_teardown_processes(), called from the top-half remove path well after fini_sw. In the observed failure the killed KFD process (SIGBUS on unplug) stuck in D state on its exit path, so kfd_processes_count never drained and the PCIe removal thread wedged permanently in cond_resched(), producing soft-lockup and hung-task splats. Tear KFD processes down before freeing kfd.dev on the disconnect path, and guard kgd2kfd_teardown_processes() against kfd.dev already being gone when it runs a second time. 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 836f44ba87ed7b1d83e2b7bfc788f8c6437b03a7) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9cfce679d88f6f83d15e99fdba0d5769120f0faf Author: William Palacek Date: Mon Oct 19 15:41:15 2026 -0400 drm/amdkfd: Validate the control stack of a restored queue [ Upstream commit 90d91a192751cd9a7d9d2286299bc72ec1c28179 ] kfd_criu_restore_queue() takes the control stack size from the checkpoint image without the topology check create-queue does in kfd_queue_acquire_buffers(), which restore stopped calling in commit 1cafa8b29e02 ("drm/amdkfd: Don't acquire buffers during CRIU queue restore."). An image size of 0x300000 is accepted and sizes the MQD allocation, and 0xFFFFFFFF trips a page allocator warning in kmalloc(). restore_mqd() also keeps the image's cp_hqd_cntl_stack_size, cp_hqd_cntl_stack_offset and cp_hqd_wg_state_offset. With offset > size or wave state offset < size, get_wave_state() returns wrapped sizes. Take the per-XCC size from topology, 0 for queues without a control stack, and reject larger images. In restore_mqd(), set the size to it and bound both offsets as init_mqd() does. Fixes: 626f7b3190b4 ("drm/amdkfd: CRIU add queues support") Fixes: 42c6c48214b7 ("drm/amdkfd: CRIU checkpoint and restore queue mqds") Signed-off-by: William Palacek Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 92249023caee17bfc6f29c71d6aaa5f2298cf507) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 7035fc8f561e4599e1955fbd9d7f5e8b384d8a56 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 6c4f82c4fb95cf5d34d4dd82d042d30a674f0b3e Author: Karl Mehltretter Date: Mon Oct 26 02:02:00 2026 +0100 clocksource: Prevent immediate watchdog rerun after a delay [ Upstream commit f322d7f7ae56bce728ba03a387e35380bc4ad939 ] The watchdog rewrite made the clocksource check handle long intervals between two measurements, but missed that the timer expiry needs to be rebased after such a delay. When a watchdog invocation is delayed by more than one interval, adding WATCHDOG_INTERVAL to the previous expiry leaves the timer expiry in the past. That causes an immediate second invocation. The resulting short measurement interval can mark a clocksource unstable. Cure this by rearming the timer based on jiffies, which places the next expiry one full watchdog interval into the future. Fixes: 763aacf86f1b ("clocksource: Rewrite watchdog code completely") Signed-off-by: Karl Mehltretter Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261026010200.96371-1-kmehltretter@gmail.com Closes: https://lore.kernel.org/r/20261010065509.72916-1-kmehltretter@gmail.com/ Signed-off-by: Sasha Levin commit 2465a3c31b39f9129539b0f88d28dceb44928fa9 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 c93782c737864bcc89b98a4ba778689b62fbbcb2 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 b1b6de9a02f8f87d5535443603bf2c375b547314 Author: Tiezhu Yang Date: Tue Oct 27 22:51:35 2026 +0800 LoongArch: Fix one-shot limitation for perf hardware breakpoints [ Upstream commit 5e0b00fd000a53a5428fed6c96be74019bd0ad17 ] In breakpoint_handler() and watchpoint_handler(), the code disables the hardware slot by executing update_bp_registers(regs, 0, ...). This design forces the active hardware breakpoint configuration to be wiped out upon its first hit, turning standard perf hardware breakpoints into "one-shot" events. Furthermore, while the ptrace single-step path in do_watch() executes a hardware single-step skip mechanism to advance the PC, the standard perf path lacks any mechanism to bypass the original triggering instruction. To maintain the long-term persistence of hardware breakpoints for perf usage, eliminate the disruptive calls to update_bp_registers() within the handler loops to keep the breakpoint configuration enabled. Concurrently, execute a single, unified register write outside the loop to atomize the state transition and explicitly enforce the hardware skip mechanism once per exception return, ensuring the processor safely steps forward without lockups. Meanwhile, in order to prevent status contamination during single-core context switches or cross-core thread migrations, the hardware register skip state of the previous thread is saved first. Then, the skip state is restored and its software skip flag is also cleared only if the next thread has the skip flag; otherwise, 0 is written to clear the FWPS and MWPS registers, which explicitly clears the skip bit according to the architectural specification. Additionally, explicitly clear hbp_break_skip and hbp_watch_skip inside ptrace_hw_copy_thread() which is called by copy_thread() during the task creation. This guarantees that a newly cloned child task starts with a clean slate. Here is a user-space reproducer to demonstrate the issue. (1) Test program (test_perf_continuous.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"); asm volatile("st.b %1, %0" : "=m"(var) : "r"(22) : "memory"); asm volatile("st.b %1, %0" : "=m"(var) : "r"(33) : "memory"); ioctl(fd, PERF_EVENT_IOC_DISABLE, 0); read(fd, &count, sizeof(size_t)); printf("Watchpoint counts: expected = 3, actual = %zu\n", count); close(fd); return 0; } (2) Test steps: $ gcc test_perf_continuous.c -o test_perf_continuous $ ./test_perf_continuous (3) Test results: Without this patch: Watchpoint counts: expected = 3, actual = 1 With this patch: Watchpoint counts: expected = 3, actual = 3 Cc: stable@vger.kernel.org Fixes: 3eb2a8b23598 ("LoongArch: Fix multiple hardware watchpoint issues") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 27021f37ea7242b357143fbbe253c6d0e6dbd169 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 ab0fb9ea282f5e2a8a15cefd6ad7b6652da7e95a 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 b2561dc6c550222687957318e491c347f83f9da3 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 5f80062adefd34acd4440d76f9095af9b62badfe 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 f7f597c501cddaaf810c0164f8bb72645f1d0bdc 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 0b131557b0e31706bc6e43cf0c986cf0a35a5871 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 bca3689dd637a7cb0913ee6ac71765a3b3126f2c 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 fc880e99148181d1f076fa53da50868e37af5cc6 Author: Huacai Chen Date: Tue Oct 27 22:51:23 2026 +0800 LoongArch: Don't init & online empty nodes [ Upstream commit 87c6d144bc7bbed0c4573848b9c92006edca7848 ] Don't init & online empty nodes without any CPU cores (and memory), in this way "lscpu" will not display confusing empty nodes. Modify fake_numa_init() to make sure at least Node-0 isn't empty for the FDT booting case. Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 5e21c66b352fd580505b3cd1ade3352ea9e6e737 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 0c17a5ac6486dbc99b2854d65cff20836877e60b 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 185c817447feb8314500da338be66b025c397032 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 be351c87b1208ff469163c2627957de1ce655d1a 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 2a66353afb99f52451fd6e4ad86292695b33e221 Author: Sinan Turunc Date: Mon Oct 26 22:36:47 2026 +0000 ALSA: ua101: Bound packet copies by the PCM buffer size [ Upstream commit 493a77a9f20fca07ca5654f61c1b03bef035df25 ] copy_capture_data() and copy_playback_data() wrap the ring buffer position once and split the memcpy() in two at the buffer end, which is only correct when one packet holds at most buffer_size frames. The capture packet size is the device's (actual_length up to wMaxPacketSize, divided by 3 * bNrChannels from its own descriptor), the playback packet size is taken from the capture packets, and set_stream_hw() lets the PCM client pick period_bytes_min 1, periods_min 2 and a period time of 1.5 packet intervals: 9 frames at 44.1 kHz high speed, an 18-frame buffer. A device sending 672-byte mono 24-bit packets delivers 224 frames per packet. After the first packet buffer_pos is 206 and stays beyond buffer_size. On the next packet frames1 = buffer_size - buffer_pos wraps and memcpy() runs away: snd-ua101 2-1:1.0: invalid position: , pos = 206, buffer size = 18, period size = 9 BUG: KASAN: slab-out-of-bounds in capture_urb_complete+0x9eb/0xcb0 Read of size 4294966732 at addr ffff88800d73e7e0 by task vhci_rx/81 and for playback: BUG: KASAN: vmalloc-out-of-bounds in playback_work+0x789/0xac0 Read of size 4294966732 at addr ffffc9000002626a by task kworker/0:1H/80 Clamp the capture copy to buffer_size. On playback, copy at most one buffer and fill the rest of the packet with silence, so the URB length, the delay accounting and the data sent stay consistent. With that bound the single wrap and both memcpy() halves stay inside the buffer. A device whose packets do not fit the buffer never played correctly anyway. Reproduced on 7.3-rc7 with a USB/IP device presenting the UA-101 interface layout and a 672-byte isochronous endpoint. Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support") Cc: stable@vger.kernel.org Signed-off-by: Sinan Turunc Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20261026223543.620-3-enscrpt@pm.me Signed-off-by: Sasha Levin commit 22247f5024684b29d071230b00bc19ae9869bc76 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 6fe40c314fa078f06152f0f1f02c73f2e414de7a 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 47195a2c27d56cccc1ed92271aecaef8d78a05be 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 9e4f9ce581b73c39235ac7478ed88ee84184eb92 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 dc22f1e25852a8f6ba296a0ad3ff0788433590de 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 dd74203cbafaa693ac132d83b7cade4150bf2c8e Author: Zhiling Zou Date: Thu Oct 22 03:01:16 2026 +0800 ipmr: drop packets with unknown ingress VIF [ Upstream commit 09280680f2ea060514be2a39ea84209fb6d721d4 ] A packet can race with VIF publication and make ipmr_find_vif() return -1 even though the VIF device pointer is already visible. The parent VIF device check can then pass with an invalid ingress VIF. For (*,G) entries, this can also let the packet be forwarded back out its ingress VIF. Drop packets whose ingress VIF lookup fails in both IPv4 and IPv6 forwarding, before checking the MFC parent device. This prevents forwarding with an unknown ingress VIF and avoids the (*,G) hairpin. Without the early check, the negative index can reach the IPv4 offload lookup only for an skb marked for L3 forwarding offload, currently done by mlxsw. The race is rare; the supplied PoC reports only the UBSAN negative-index diagnostic. Fixes: 4eadb88244d1 ("ipmr: do not acquire mrt_lock while calling ip_mr_forward()") Fixes: 9b1c21d898fd ("ip6mr: do not acquire mrt_lock while calling ip6_mr_forward()") Cc: stable@vger.kernel.org Reported-by: Vega Link: https://lore.kernel.org/netdev/b966eb102e98f299e45be59ada033a8766e4c6df.1791899747.git.zhilinz@nebusec.ai/ Suggested-by: Ido Schimmel Suggested-by: Naman Gulati Signed-off-by: Zhiling Zou Reviewed-by: Naman Gulati Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/5271fcb94a4d9e697ed64a348e92ea9e74faab1c.1792608753.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1f6cb0614d1783adb0187cf40a3c4f60499731e8 Author: Ido Schimmel Date: Sun Oct 25 09:17:29 2026 +0200 ipmr, ip6mr: validate packets injected into the register vif on xmit [ Upstream commit aa1799e93f5ebb973252aec649d84d12d9c7fd1c ] reg_vif_xmit() passes the packet to ipmr_cache_report() which copies its IP header into the IGMPMSG_WHOLEPKT report that is queued to the mroute socket. Nothing guarantees that the packet contains a full IP header, so when a short packet is injected on the register device (e.g., using AF_PACKET), the copy reads past the end of the packet and a recvmsg() on the mroute socket leaks the uninitialized bytes to user space [1]. IPv6 has the same problem [2]. Its reg_vif_xmit() does call pskb_inet_may_pull(), but the helper keys off skb->protocol and does not pull anything when the protocol is neither IPv4 nor IPv6. Fix by dropping packets whose protocol does not match the address family of the register device or that do not contain a full network header. [1] BUG: KMSAN: kernel-infoleak in _copy_to_iter raw_recvmsg Uninit was stored to memory at: ipmr_cache_report reg_vif_xmit packet_sendmsg Uninit was created at: __alloc_skb sock_alloc_send_pskb packet_sendmsg Bytes 1-3 of 21 are uninitialized [2] BUG: KMSAN: kernel-infoleak in _copy_to_iter rawv6_recvmsg Uninit was stored to memory at: ip6mr_cache_report reg_vif_xmit packet_sendmsg Uninit was created at: __alloc_skb sock_alloc_send_pskb packet_sendmsg Bytes 8-23 of 41 are uninitialized Fixes: 14fb64e1f449 ("[IPV6] MROUTE: Support PIM-SM (SSM).") 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-3-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 17463fef04b15bad67789573df58d1a9d7b96f90 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 46f1631f9ccbcabd0ea569897ecd5b47971caf7d 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 c160b4490d5ed9e4d8fa3c602583858f89cfc80a 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 b63b117492e815c7dded5307a0ca8dc2a23fa583 Author: Srinivas Kandagatla Date: Tue Oct 20 08:38:52 2026 +0100 ASoC: SDCA: drop pm_runtime reference on probe failure path [ Upstream commit 86331b76b32d7a83fb3e64641a5111746bf0f50c ] sdca_class_probe() takes an extra usage count with pm_runtime_get_noresume() to keep the device powered on until the deferred boot work has run. If devm_pm_runtime_enable() then fails, that reference is never dropped. Drop it on the error path. Fixes: 2d877d0659cb ("ASoC: SDCA: Add basic SDCA class driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Srinivas Kandagatla Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20261020073856.1177749-3-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 523e71cccfd8506471e02bd63c425a5564217f2e Author: Srinivas Kandagatla Date: Tue Oct 20 08:38:51 2026 +0100 ASoC: SDCA: propagate sdw_slave_read_prop() failure in class_read_prop [ Upstream commit 79cfb5aebbf0417418c2ac25669fade7f3e58ef2 ] sdw_slave_read_prop() can fail with -ENOMEM; propagate the return instead of leaving slave->prop partially initialised. Fixes: 2d877d0659cb ("ASoC: SDCA: Add basic SDCA class driver") Cc: stable@vger.kernel.org Reviewed-by: Charles Keepax Assisted-by: LLM Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20261020073856.1177749-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 584e73776b197b32642ae7db2d846d474a95e187 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 40826ebf8e12e2b69a4b17e8b4b32c2106ca917f 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 1465af8fcc7c8d6efdd29624b6c2cf6f2e3e8be2 Author: Ravi Hothi Date: Fri Oct 23 18:13:10 2026 +0100 ASoC: qcom: audioreach: fix module cfg blob size handling [ Upstream commit e21fb64a8c4aecae31ec63f994423ac944705c3e ] audioreach_get_module_priv_data() passes mod_array->size, a byte count, as the element count of the __le32 data[] flex array. The allocation and the copy are four times too large, and the memcpy() can read past the end of the topology firmware buffer. The size is also never checked against the private data it must lie within, and a zero size makes the loop spin forever. Convert the size to a word count, bound the blob by the remaining private data and reject a zero size. Also check the returned pointer before storing it in mod->data, as an error pointer there is dereferenced when the graph is opened. Fixes: c7ed4c2debfd ("ASoC: qcom: audioreach: add support for static calibration") Cc: stable@vger.kernel.org Signed-off-by: Ravi Hothi Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20261023171316.819857-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a2c410365bcff62a2bd199c034de452cbf543360 Author: Shawn Guo Date: Wed Oct 21 12:10:44 2026 +0800 ASoC: qcom: q6apm: Unmap DSP buffers before removing the topology [ Upstream commit a51c5dd7f7fc7cdf4ae28fec4a013d8418d1cb53 ] Since buffers are mapped once in pcm_new() and unmapped in pcm_free(), the unmap relies on the graph info still being registered. During card teardown, however, soc_cleanup_card_resources() removes the components before it frees the PCM runtimes. q6apm-audio's remove callback unloads the topology, which frees every audioreach_graph_info, so by the time q6apm_dai_pcm_free() runs the idr lookup fails and the unmap silently returns -ENODEV. The DSP keeps the old mapping. When the card is bound again, for example after unbinding and binding any codec on it, pcm_new() maps the same buffer once more, the DSP rejects it and the front-end PCM is not created: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x0100100c cmd qcom-apm gprsvc:service:2:1: DSP returned error[100100c] 1 q6apm-dai ...: Audio Start: Buffer Allocation failed rc = -22 snd-sc8280xp sound: ASoC: can't create pcm MultiMedia1 Playback :-22 Release the circular and position buffer mappings of all graphs in q6apm_audio_remove() while the graph info still exists. The unmap helper now takes the q6apm instance directly, since it is called from the APM component rather than from a q6apm-dai child device. Fixes: 8ea6e25c8536 ("ASoC: qcom: q6apm: Add support for early buffer mapping on DSP") Cc: stable@vger.kernel.org Reviewed-by: Srinivas Kandagatla Signed-off-by: Shawn Guo Link: https://patch.msgid.link/20261021041044.2080369-4-shengchao.guo@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a99feace2d2f5d82be928b63bb87b67dd6472824 Author: Shawn Guo Date: Wed Oct 21 12:10:43 2026 +0800 ASoC: qcom: q6apm: Clear the right handle on pos buffer unmap [ Upstream commit 43c69604271d8b54c494fde70bd4a9eaab7a974d ] Push/pull graphs map two shared-memory regions per graph, the circular buffer and the position buffer, and keep a separate DSP handle for each. The map path tags its token with APM_MMAP_TOKEN_MAP_TYPE_POS_BUF so the response lands in the right handle, but the unmap path sends a bare graph ID and the response handler always clears mem_map_handle. Unmapping the position buffer therefore wipes the circular buffer's handle and leaves pos_buf_mem_map_handle set. A subsequent unmap of the circular buffer is skipped, leaking that DSP mapping, and a remap of the position buffer is skipped because the stale handle looks valid. Tag the unmap token the same way as the map token and decode it in the response handler to clear the matching handle. Fixes: 7c1ac23b178a ("ASoC: qcom: audioreach: Add support for shared memory push/pull modules") Cc: stable@vger.kernel.org Reviewed-by: Srinivas Kandagatla Signed-off-by: Shawn Guo Link: https://patch.msgid.link/20261021041044.2080369-3-shengchao.guo@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e564eef02b69222e715dc9aca7364f7b856a2f45 Author: Shawn Guo Date: Wed Oct 21 12:10:42 2026 +0800 ASoC: qcom: q6apm: Fix unmap regions response handling [ Upstream commit 4b832a2af523cbf857a977414c0f07d7f90a4c9d ] The DSP acknowledges APM_CMD_SHARED_MEM_UNMAP_REGIONS with a GPR_BASIC_RSP_RESULT packet whose payload carries the acknowledged opcode and the status. apm_callback() stores hdr->opcode, i.e. GPR_BASIC_RSP_RESULT itself, as the result opcode, so audioreach_send_cmd_sync(), which waits for 0x0100100d, never sees a match and gives up after five seconds even though the DSP has already processed the command: qcom-apm gprsvc:service:2:1: CMD timeout for [100100d] opcode Each mapped graph costs a five second stall on unmap, and the forced status of 0 also hides real DSP failures from the caller. Record the opcode and status from the response payload, like the other basic-result commands do, and only drop the cached mapping handle when the DSP reports success. Fixes: 8ea6e25c8536 ("ASoC: qcom: q6apm: Add support for early buffer mapping on DSP") Cc: stable@vger.kernel.org Reviewed-by: Srinivas Kandagatla Signed-off-by: Shawn Guo Link: https://patch.msgid.link/20261021041044.2080369-2-shengchao.guo@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4322459cc7a1e27abca472064ea44b8beaa04eef 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 2018dbba8a5c84e00c6215475719bf1848cf5903 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 d2f96029c08ac0f5298270c227963c4e3ffab3dc 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 4348550560ec3af12b234e447210d71b51738b92 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 1ae16bb199d5e2b3f6e7160d4d5ac34980984ef8 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 bd04d73a0d6e6c52186f3836ad1689080be7f7ed 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 87cba8ebbaa7d2b85f6a4912c1697c0f2642b39a 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 9c0852f3cb02dc11d65900adf4f268375123736b 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 6eaba9183c3504790b545dfe87f7d551d2da999f 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 458e9e2930168757bb387b68cc44206b72bddbf3 Author: Darong Lu Date: Mon Sep 28 01:44:22 2026 +0800 libceph: initialize CRUSH choose argument weights [ Upstream commit c3a995ff0782587789333c621e1f6bd5e574371e ] Initialize the CRUSH choose argument weight-set array before decoding so entries start in a defined state while the decoder fills them. Cc: stable@vger.kernel.org Fixes: 5cf9c4a9959b ("libceph, crush: per-pool crush_choose_arg_map for crush_do_rule()") Reported-by: Vega Assisted-by: LLM Signed-off-by: Darong Lu Signed-off-by: Ren Wei Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 3ac5e7f512efbadfffd2d13888dc23c43754a5dd 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 b898407535b1c5a9caa6b22aa35650e0a99d742e 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 68db0112f3663f53f6848b0ff75b12c9fc089a04 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 dabe2280fa8dd8d84ebaaf5fb5c45b6d778fc6c1 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 25ae51760b751d170e29425b7851ee577e2cd5ba 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 0c0dfc2b238cb6eb24f68406c8655a6a71e877ad 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 cab954c676687e2913b7042bc0cf294ce2e81336 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 dd7efad37e5eacbf9082a8bf12ba56292a1725f7 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 762860805a1414060f232fd74060fc09ec429fbf 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 f7e0d6d3de29ea15daf063a81f6d5fef04681b9e 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 058e1c38722a6d5b0181f38fdec03d5da95c3ad1 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 0574e4aff8e4b28e0d5636204ed4ba2350b8701a 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 0e1bc95bdda8dc382496de11455a627f5a35957c 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 0c162c18a774ab36c090088d2b27ed9ddb095fa4 Author: Jiangshan Yi Date: Tue Sep 8 11:18:23 2026 +0800 ceph: fix longname buffer overflow in ceph_fname_to_usr() [ Upstream commit 71975d6e0db17646102488cf54480fda9de0f7a7 ] Snapshot longname reconstruction formats "__" via snprintf() and memcpy()s the result into oname->name. Checking the length against NAME_MAX only protects the LOOKUPNAME/export callers, whose buffer is allocated with fscrypt_fname_alloc_buffer(NAME_MAX). The readdir path points oname->name straight at the altname in the MDS reply, whose capacity is altname_len; the reconstructed name can exceed that while still fitting under NAME_MAX, overflowing the in-place destination. Save the actual oname->len before the decryption overwrites it, and fail with -ENAMETOOLONG when the reconstructed name would not fit. Cc: stable@vger.kernel.org Fixes: dd66df0053ef ("ceph: add support for encrypted snapshot names") Suggested-by: Alex Markuze Signed-off-by: Jiangshan Yi Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 740fdcbc94f8bfd48121dac42a07c0b87a3fb261 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 e69875c7ec22ca636970249458c18da2c35ca094 Author: Marc Zyngier Date: Tue Oct 20 07:43:06 2026 +0100 KVM: arm64: Sanitise ID_AA64MMFR3_EL1.S1P[IO]E [ Upstream commit 68c11eed4f8097ef1b71c30679e96eb654df29e0 ] KVM uses the VM's ID registers as the source of truth for what the guest has, but userspace can expose S1PIE or S1POE without the features they imply. As per the architecture, both imply TCR2 and ATS1A, and S1POE also implies HPDS. With TCR2 hidden, the world switch skips PIR_EL1, PIRE0_EL1 and POR_EL1 while KVM doesn't trap them, so the guest accesses registers that are neither trapped nor switched. Under VHE, that leaks values between guests. On nVHE and hVHE, pKVM included, the host kernel resumes with the guest's PIR_EL1 and PIRE0_EL1. On first run, clear S1PIE and S1POE from the VM's ID registers when the features they imply are missing, before anything derives state from them. The guest and userspace then see neither feature, and the guest's accesses to their registers UNDEF. Fixes: 70ed7238297fb ("KVM: arm64: Sanitise ID_AA64MMFR3_EL1") Fixes: d4a89e5aee23e ("KVM: arm64: Expose S1PIE to guests") Reported-by: Mark Brown Link: https://lore.kernel.org/r/20260930-arm64-gcs-v21-2-3556644cd927@kernel.org Link: https://lore.kernel.org/r/8633u229lq.wl-maz@kernel.org Cc: stable@vger.kernel.org Co-developed-by: Fuad Tabba Signed-off-by: Fuad Tabba Reviewed-by: Mark Brown Reviewed-by: Lorenzo Stoakes (ARM) Link: https://patch.msgid.link/20261020064306.1542865-1-fuad.tabba@linux.dev Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 4e4a3ec623ad5a46d945a7de1bedc20b8699fcf5 Author: Vincent Donnefort Date: Thu Oct 15 12:28:14 2026 +0100 tracing/remotes: Fix TRACE_REMOTE build when TRACING=n [ Upstream commit 3bb853ad84244f0b86ab12f029bc4a0c9c7100e8 ] TRACE_REMOTE relies on tracefs, eventfs and ring-buffer which are only built and declared when TRACING is enabled. It is however possible for a config to have FTRACE=y TRACING=n and TRACE_REMOTE=y. To fix this configuration, have TRACE_REMOTE select TRACING directly, just like other FTRACE options do and drop the TRACING dependency from NVHE_EL2_TRACING to avoid a circular Kconfig dependency. Cc: stable@vger.kernel.org Fixes: ea908a2b79c8 ("tracing: Add a trace remote module for testing") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202610142301.GBepPVmS-lkp@intel.com/ Signed-off-by: Vincent Donnefort Acked-by: Steven Rostedt Link: https://patch.msgid.link/20261015112814.332084-1-vdonnefort@google.com Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 9dde819b182c88817a5cc899e5a4e3215176d6e6 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 6da98212658b7cb5f31126923b016ec8efff40d8 Author: Peng Wang Date: Fri Oct 23 22:51:00 2026 +0800 tick/nohz: Reevaluate the tick for kicks flushed outside hardirq [ Upstream commit e389ae428847a2e6a3b698b5967df68ccf90361c ] The nohz full kick relies on interrupt exit to reevaluate the tick. However, a remote kick can also be flushed from task context without an interrupt exit guaranteed to follow. If a tick dependency is set or an earlier timer is queued after the idle-exit reevaluation, the required tick update can be delayed until another interrupt. Reevaluate the tick directly from the callback outside hardirq context. Keep the existing interrupt exit handling for hardirq callbacks. The offline flush remains harmless because tick_sched_timer_dying() has already cleared TS_FLAG_NOHZ. Fixes: 4b44a21dd640 ("irq_work, smp: Allow irq_work on call_single_queue") Fixes: a5183862e76f ("tick/nohz: Conditionally restart tick on idle exit") Suggested-by: Frederic Weisbecker Co-developed-by: He Rongguang Signed-off-by: He Rongguang Signed-off-by: Peng Wang Signed-off-by: Thomas Gleixner Reviewed-by: Frederic Weisbecker Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261023145101.8217-1-peng_wang@linux.alibaba.com Signed-off-by: Sasha Levin commit fbfee2e29499d4265ebf5c1ace9ecd469aa4d88d Author: Hung-Jui Lin Date: Fri Oct 23 23:14:10 2026 +0800 posix-timers: Report zero remaining time for disarmed SIGEV_NONE timers [ Upstream commit 141a27750ec3d91ad9d1ad1764ebb5e51b963478 ] SIGEV_NONE timers are never queued. common_timer_get() emulates their expiry by computing the remaining time from the stored expiry value. Because an armed SIGEV_NONE oneshot timer is not queued, its it_status stays POSIX_TIMER_DISARMED. So common_timer_get() cannot use it_status to skip a disarmed SIGEV_NONE timer and evaluates the stored expiry value for all SIGEV_NONE timers. Disarming a timer with timer_settime() and a zero it_value cancels the timer and sets it_status to POSIX_TIMER_DISARMED, but leaves the expiry value unchanged. As a consequence, timer_gettime() on a disarmed SIGEV_NONE timer reports the remaining time of the previous arming until that time has passed, instead of zero as POSIX requires for a disarmed timer. Example with a CLOCK_MONOTONIC timer armed with it_value = 10ms and it_interval = 100ms, then disarmed with an all-zero itimerspec: armed: it_value = 0.009999000 it_interval = 0.100000000 disarmed: it_value = 0.008700792 it_interval = 0.000000000 SIGEV_SIGNAL timers and SIGEV_NONE CPU timers report zero in the same situation. All clocks which use common_timer_get() are affected, including the alarm timer clocks. Mark SIGEV_NONE timers as POSIX_TIMER_ARMED when they are armed, so that common_timer_get() returns early for every disarmed timer. Forward SIGEV_NONE interval timers in common_timer_get() regardless of it_status, as they are never queued and therefore never forwarded by the expiry code. After the change the disarmed timer above reports zero. Armed SIGEV_NONE oneshot and interval timers on CLOCK_MONOTONIC, CLOCK_REALTIME, CLOCK_BOOTTIME and CLOCK_BOOTTIME_ALARM still report their remaining time, and the posix_timers selftest passes. Fixes: becf8b5d00f4 ("[PATCH] hrtimer: convert posix timers completely") Signed-off-by: Hung-Jui Lin Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261023151411.28685-1-alex.lin.programmer@gmail.com Signed-off-by: Sasha Levin commit 6d1d9b7ec6d0a498b9d5b6609c9d58f21fc490fc 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 d60dc9a450cb3aea44515a26c1a789d01cff31f9 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 654aea6cb1f776dc849e100d28b05ea01a907a75 Author: Hungyu Lin Date: Tue Oct 20 16:11:21 2026 +0000 posix-timers: Accept NULL clock_getres() output in stubs [ Upstream commit 5b819071e4346256c4edbae5cc2095dff25694fc ] With CONFIG_POSIX_TIMERS disabled, clock_getres() returns -EFAULT for a supported clock when the result pointer is NULL. POSIX permits a NULL result pointer to suppress returning the clock resolution. Only copy the result when a destination is provided, in both the native and time32 stubs. This matches the full POSIX timer implementation and preserves clock ID validation. Fixes: baa73d9e478f ("posix-timers: Make them configurable") Fixes: d822cdcce43f ("posix-timers: Move compat versions of clock_gettime/settime/getres") Signed-off-by: Hungyu Lin Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261020161121.85042-1-dennylin0707@gmail.com Signed-off-by: Sasha Levin commit 6d522543220915cbe36948730d006c88d993fa45 Author: Gao Xiang Date: Sat Oct 24 21:20:28 2026 +0200 erofs: hold real inodes for shared files [ Upstream commit 7259fb011c14977661b7a4680886b466a3089ea7 ] EROFS page cache sharing uses shared inodes. However, a mmaped VMA keeps the shared file even after the corresponding fd is closed, while currently the real inode is never held by any reference associated with the shared file. As a result, the real inode could be evicted and removed from the shared inode's list while the page fault can still invoke on the shared inode's address space, which causes no candidate is successfully acquired by erofs_real_inode(). Fix this by simply keeping the original inode in the shared backing file's private data. Also replace confusing "realfile"/"rf" names with "sf" (sharedfile) to unify the terms as well as nullify realinode in erofs_real_inode() to avoid returning an uninitialized pointer. Fixes: 5ef3208e3be5 ("erofs: introduce the page cache share feature") Reported-by: YoungWoo Rim Closes: https://lore.kernel.org/r/atzSVuvqYKgmvDmO@MacBookPro Cc: stable@vger.kernel.org # 7.0+ Reviewed-by: Chao Yu Signed-off-by: Gao Xiang (Docker) Signed-off-by: Sasha Levin commit ebb6525ee7df342afb5d7fcb996294c8a40c444b 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 cb98da5dff7b3232026ce37eb6163f6f46c21d69 Author: Alberto Garcia Date: Fri Sep 25 16:19:19 2026 +0200 ext4: reject encrypted inodes when block size > page size [ Upstream commit a5e894bc87b76fd980075892ba77e6bdeeb5e4d0 ] Encryption is not supported when a filesystem's block size is larger than the page size. ext4_check_large_folio() refuses to mount a filesystem like that if the "encrypt" feature is already enabled, and ext4_set_context() refuses to create encrypted inodes if the feature is enabled after mounting. However, a corrupted or hand-crafted filesystem can still have encrypted inodes even if the "encrypt" feature is not set, and those inodes can be unlocked if they're using v1 policies. Check this in __ext4_iget() and reject them as corrupted. Fixes: 709f0f1f1bf5 ("ext4: add checks for large folio incompatibilities when BS > PS") Suggested-by: Eric Biggers Cc: stable@vger.kernel.org # v6.19+ Signed-off-by: Alberto Garcia Reviewed-by: Baokun Li Reviewed-by: Eric Biggers Link: https://patch.msgid.link/aeb8efa8beb72721fb4b13cffe6eb22c795ec33f.1790343958.git.berto@igalia.com Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit 1541e7eb656d19f99eab8037e495f2b7d60ad404 Author: Alberto Garcia Date: Fri Sep 25 16:19:18 2026 +0200 ext4: refuse encryption when block size > page size [ Upstream commit 0e341d1d29db11c29211d2b8870a515c26589d5a ] Encryption is not supported when a filesystem's block size is larger than the page size, and commit 709f0f1f1bf5 ("ext4: add checks for large folio incompatibilities when BS > PS") added a check to refuse mounting such a filesystem. However, it is also possible to enable the "encrypt" feature on a filesystem that is already mounted (with tune2fs -O encrypt). Once that happens it won't be possible to mount the filesystem again in the future, but there is nothing preventing the user from setting an encryption policy while the filesystem is still mounted. Fix this by refusing to set an fscrypt context in ext4_set_context() when the block size is larger than the page size. Fixes: 709f0f1f1bf5 ("ext4: add checks for large folio incompatibilities when BS > PS") Cc: stable@vger.kernel.org # v6.19+ Signed-off-by: Alberto Garcia Reviewed-by: Baokun Li Reviewed-by: Eric Biggers Link: https://patch.msgid.link/093b40e9df29fc102907092f4ff73461f4cfcbfd.1790343958.git.berto@igalia.com Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit e9520ef59b30c85b9e27503853202c3674eb3e04 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 27afd2719525a4bf9cd36e874e229506736d0262 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 682104ab8ef8432b9a4b06cb5834498ce7f7ebca Author: Lorenzo Stoakes (ARM) Date: Tue Oct 20 15:55:30 2026 +0100 mm/vma: avoid broken uffd merge on mremap [ Upstream commit 68cb098eadda190783f8f8bdf9fe764df59f7d32 ] Userfaultfd often causes unexpected interactions within mm, and does so at the intersection of uffd, mremap() and VMA merging. When an mremap of a VMA occurs, copy_vma_and_data() calls mremap_userfaultfd_prep() to notify uffd of this. However, mremap_userfaultfd_prep() simply drops the UFFD context for the VMA if the user did not register it for remap, i.e. didn't specify the UFFD_FEATURE_EVENT_REMAP flag. This is OK for the VMA itself, as upon page table move, move_ptes() clears UFFD page table flags, using vma_has_uffd_without_event_remap() to determine whether to do so. However, this doesn't account for merging with adjacent VMAs, whose page tables won't have received this treatment, and thus latent UFFD markers will be left around. Worse, it'll break UFFD for any VMAs it is merged with. This is very surprising behaviour for a user, who will then simply not receive UFFD events for VMAs they ought to. Resolve the issue by explicitly checking for this case via vma_has_uffd_without_event_remap() in vma_merge_copied_range(), the merge function explicitly designated for mremap() operations. Also update the userland VMA tests accordingly. Link: https://lore.kernel.org/20261020-uffd-remap-fix-v1-1-0f34fc181f0a@kernel.org Fixes: 3cfd22be0ad6 ("userfaultfd: clear flag if remap event not enabled") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Reported-by: shaos Closes: https://lore.kernel.org/all/20261020110748.959870-1-shawnq1@163.com/ Reviewed-by: Kiryl Shutsemau (Meta) Reviewed-by: Gregory Price (Meta) Reviewed-by: Xueyuan Chen Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Mike Rapoport Cc: Peter Xu Cc: David Hildenbrand Cc: Signed-off-by: Sasha Levin commit d1078b473e559875f1d2aeec1ef9792b89e35209 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 f87e72ed8ab1bdc7f6ed774a9f5868eb6dc47b84 Author: SJ Park Date: Mon Oct 19 17:41:18 2026 -0700 mm/damon/core: filter out damos address filter-split failed region [ Upstream commit bbeec2d8324d7aac438bb12dd2d22b184e0a8d43 ] When an address type DAMOS filter is configured, DAMOS tries to split the region for the filter range, and apply DAMOS action to the filter-in region. The split operation (damon_split_region_at()) could fail from allocation failure under extreme memory pressure. In the case, DAMOS action could be applied more or less than expected, ignoring the address filter. The issue only rarely happens under extreme memory pressure. No crash or leak happens. Occasionally not applying the action to a few regions shouldn't be a real problem. But applying the action to a region that the user has excluded via address filter could be a surprise depending on the use case. It is only theoretical. No such real case is found yet. Filter out the entire region if the split is failed. Update damos_filter_match() signature to receive the error from split. Also update kunit tests for the updated signature. The issue was discovered [1] by sashiko. Link: https://lore.kernel.org/20261020004119.106690-1-sj@kernel.org Link: https://lore.kernel.org/20260801203121.117449-1-sj@kernel.org [1] Fixes: ab9bda001b68 ("mm/damon/core: introduce address range type damos filter") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: # 6.6.x Signed-off-by: Sasha Levin commit b2f3840012e106e64ab1d910a802d6a74155101d 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 dcd875496a3229e1ed695d72fa99bc8bfa4da085 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 22464b99348bde3a3804a26e0a30878358c3dd94 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 b6d9bee0f6b9d3bf46329ca6fb49be364d1adb9a 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 d067e7b3728c0fb28e5b45a48922a00075c5ca1c Author: Kyle Zeng Date: Thu Oct 15 18:15:49 2026 -0700 mm/page_vma_mapped: continue past nonmatching huge PMDs [ Upstream commit 1a2993227e8a27fc4cdea305bbdae82d290bc885 ] A PTE-mapped large folio can straddle PMD boundaries after an unaligned mremap(). If the first part is discarded and replaced with an unrelated huge PMD, page_vma_mapped_walk() stops instead of looking for the rest of the folio in subsequent PMDs. This also affects migration entries. A walk that stops at an unrelated huge PMD can leave migration PTEs behind when migration or an anonymous folio split restores the mappings. Those entries do not hold mapping references and can outlive the source folio. This issue can lead to memory corruption and I have a reproducer for it. Skip the current PMD rather than ending the walk on a flag or PFN mismatch. Do the same if the PMD became nonpresent before the locked recheck. Release the PMD lock, clear the per-PMD state and advance with step_forward(), so the existing range limit controls termination. This covers present, migration and device-private huge PMDs while preserving the matching-PMD and split-to-PTE paths. Link: https://lore.kernel.org/20261016011549.61146-1-kylebot@openai.com Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()") Signed-off-by: Kyle Zeng Signed-off-by: Andrew Morton Acked-by: David Hildenbrand (Arm) Assisted-by: LLM Cc: Lorenzo Stoakes Cc: Rik van Riel Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Harry Yoo Cc: Jann Horn Cc: Lance Yang Cc: Signed-off-by: Sasha Levin commit f899e3c62666840d2dfe142b812651c60ed7942d 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 41e679a7e71969539b38ff388694a39eee624ff5 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 5368a82b7c4d0c9ea9486ae7706917589909dd0c 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 8d2d328892cd462fb45bdeb2ca1e976e3ac51d28 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 37be8c5c4c188d17dfb0d528ed52dc9a69f02f81 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 5a4d557c02049f75c260dd5492c6e1961e49e77e 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 64e9e983605f9987636687da24c39c9afb2aa71a 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 285b62e0b489ffb54f9d501da48ccb3020a99351 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 b0f3684537dde69781dcb1887443fe4256052bbb 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 8ef19c9bdc29bba6cf337f27542db16e70f3d027 Author: Kiryl Shutsemau (Meta) Date: Tue Oct 13 18:37:20 2026 +0100 mm: page_alloc: make defrag_mode retries follow the promoted order [ Upstream commit 4cd78a2dcfbb13f049f841b98763896a3d1d7750 ] Since commit 7e8756d7ad22 ("mm: page_alloc: fix non-movable reclaim storm in defrag_mode"), direct reclaim and compaction for non-movable requests under defrag_mode run at pageblock_order, to produce the whole blocks that ALLOC_NOFRAGMENT needs. The retry decisions that follow still use the request order. An order-0 request can therefore retry indefinitely without ever reaching the ALLOC_NOFRAGMENT fallback: - Reclaim at pageblock_order gives up after one pass as soon as a zone looks compaction_ready(), and do_try_to_free_pages() then returns 1 even though nothing was reclaimed. It returns before the retry that would reclaim memory.low-protected cgroups, so when most memory is protected, the pass that did run finds next to nothing. - Compaction at pageblock_order fails or is deferred. - should_reclaim_retry() takes the reported progress as progress for the order-0 request and resets no_progress_loops. The request retries. Order 1-3 requests loop the same way, and should_compact_retry() also checks their pageblock_order compaction result against the request order. On a production host (64G, defrag_mode, memory.low covering most of the workload), 95% of direct reclaim runs were order-9 runs that returned 1 with nothing reclaimed, at up to 60k runs per second. Across ~200M should_reclaim_retry() calls in a day, no_progress_loops never left 0. The spinning allocations were SLUB slab refills for inode and dentry caches. The time spent registers as memory pressure, and pressure-based OOM killing takes down both workloads and system services. For promoted requests: - Reclaim progress does not reset no_progress_loops, as for costly orders. - should_compact_retry() checks the compaction result at the promoted order and does not retry COMPACT_SKIPPED, since the request can fall back. The compaction priority floor and the COMPACT_SUCCESS retry limit stay those of the request order, so a non-costly request still gets its COMPACT_PRIO_SYNC_FULL pass before it falls back. When a promoted request takes the fallback, reset the retry counters, so that the fallback attempt gets a full retry budget before the OOM killer is considered. A request whose reclaim was not promoted spent its budget on the request itself and keeps its counters, as Usama Arif pointed out. __alloc_pages_slowpath() computes the promoted order once per iteration and keeps it in alloc_context for direct reclaim, direct compaction and the two retry helpers, so no callee has to recompute it. Harry Yoo asked for the promoted order to be explicit rather than derived in each callee, and Vlastimil Babka suggested alloc_context over new function parameters. In a VM reproducer (32G, defrag_mode, inode churn under memory.low): before after should_reclaim_retry() calls 63M 293k peak memory pressure (PSI some avg10) 99% 12% File creation runs 5.7x faster. [kas@kernel.org: s/order_nofrag_promoted/order_defrag_promoted/, per hannes] Link: https://lore.kernel.org/atDL-nSFP2KVU7cI@thinkstation Link: https://lore.kernel.org/as5q14OsbK2CmOrh@thinkstation Fixes: 7e8756d7ad22 ("mm: page_alloc: fix non-movable reclaim storm in defrag_mode") Signed-off-by: Kiryl Shutsemau (Meta) Signed-off-by: Andrew Morton Reviewed-by: Vlastimil Babka (SUSE) Assisted-by: LLM Cc: Johannes Weiner Cc: David Hildenbrand Cc: Harry Yoo Cc: Usama Arif Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Brendan Jackman Cc: Zi Yan Cc: Shakeel Butt Cc: Signed-off-by: Sasha Levin commit 6a63aa1580ce7ed7c4e68f210ca6bb70aaff8b97 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 90f2f099e69bfb341c714751369c36cf3a420f6c Author: Hongfu Li Date: Thu Sep 3 11:01:34 2026 +0800 mm/memfd: fix hugetlb reservation accounting in error paths [ Upstream commit 50ee565c1e900e247e439e4139839b060c968343 ] If hugetlb_add_to_page_cache() in memfd_alloc_folio() fails with -EEXIST, a concurrent fault has already instantiated the folio in the page cache, and the reservation now belongs to that folio. Calling hugetlb_unreserve_pages() in that case incorrectly removes the region backing the cached folio and releases one reservation more than it should, leaving that folio in the page cache with no region recording it. That leaves resv_huge_pages one page short until that folio is removed from the page cache, so available_huge_pages() reports a page that is not actually free and the pool can grant one reservation more than it can back. Applications using hugetlb memfds can then fail to allocate or fault in a page they already reserved. They see -ENOMEM or -ENOSPC from the allocation or fault path even though the reservation and HugePages_Free still look healthy. So hold the hugetlb fault mutex from hugetlb_reserve_pages() until the error-path unreserve completes to make the reserve, allocate and instantiate steps atomic against concurrent faults. With the mutex held from the start, a concurrent fault can no longer consume the reservation between reserve and allocate/instantiate. If a fault completed before the mutex was taken, it has already added the region for that index, so hugetlb_reserve_pages() returns 0 and the error path leaves the region in place. Link: https://lore.kernel.org/20260927094757.31665-1-hongfu.li@linux.dev Link: https://lore.kernel.org/20260903030134.7407-1-hongfu.li@linux.dev Fixes: 717cf9357325 ("mm/memfd: reserve hugetlb folios before allocation") Signed-off-by: Hongfu Li Signed-off-by: Andrew Morton Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Hugh Dickins Cc: Muchun Song Cc: Oscar Salvador Cc: Vivek Kasireddy Cc: Signed-off-by: Sasha Levin commit 2e88c42d7d3e96dc23b3ac9eead173f3dff8f816 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 f5db3a1025c53654e61e7ac613f1413ccd46775d Author: Donggeun Yoo Date: Mon Sep 28 01:48:14 2026 -0700 mm/damon/core: prevent size quota overflow in the temporal goal tuner [ Upstream commit 4293c54b72e75a9d8d2e79b1498cbc782267a4db ] Patch series "mm/damon: fix the temporal goal tuner's size quota conversion", v5. damos_goal_tune_esz_bp_temporal() hands the size quota to damos_set_effective_quota() through quota->esz_bp in basis points, and the multiply that gets it there is unchecked. On 32-bit it wraps above 429496 bytes, and a wrapped product below 10000 divides to a zero effective quota. damos_quota_is_full() is then true on the first test of every charge window, so the scheme makes no progress for as long as the goal is unachieved. Patch 1 bounds the conversion. Patch 2 pins the boundary in the core kunit suite, where the new test would fail without patch 1 on any word size. This patch (of 2): damos_goal_tune_esz_bp_temporal() converts the scheme's size quota into basis points with "quota->esz_bp = quota->sz * 10000", both unsigned long, and damos_set_effective_quota() divides the result back by 10000. quotas/bytes is unbounded; bytes_store() hands it to kstrtoul() as is. On 32-bit the product wraps for any size quota above ULONG_MAX / 10000, that is 429496 bytes. A wrapped product below 10000 divides to a zero effective quota: 429497 gives 0. damos_quota_is_full() is then true on the first test of every charge window. Other wrapped values are wrong without being zero: 500000 gives 70503. Triggering this needs a scheme with a quota goal, the temporal goal tuner, and a size quota above ULONG_MAX / 10000 -- 429496 bytes on 32-bit, 1844674407370955 on 64-bit. The scheme then makes no progress for as long as the goal is unachieved, which is easy to notice, and writing a smaller size quota restores it. Nothing is corrupted and nothing leaks. This is unlikely to be hit on a tested setup. addr_unit does not cover this. It only scales the numbers a paddr context writes to quotas/bytes, so a large enough scaled value wraps just the same, and vaddr and fvaddr contexts take raw byte values. Bound the multiply. Link: https://lore.kernel.org/20260928084816.5575-1-sj@kernel.org Link: https://lore.kernel.org/20260928084816.5575-2-sj@kernel.org Fixes: af738a6a00c1 ("mm/damon/core: introduce DAMOS_QUOTA_GOAL_TUNER_TEMPORAL") Signed-off-by: Donggeun Yoo Signed-off-by: SJ Park Signed-off-by: Andrew Morton Reviewed-by: SJ Park Cc: # 7.1.x Signed-off-by: Sasha Levin commit 23b6d1098a22c5916aaeb93045c73953e010c531 Author: Karl Mehltretter Date: Mon Sep 28 01:58:33 2026 -0700 mm/damon/core: preserve the quota passed to damon_new_scheme() [ Upstream commit f73ecbc0589c8df8f18e444f5f633de01ebb0d98 ] Patch series "mm/damon/core: preserve quota state when constructing schemes", v3. damon_commit_ctx() first commits the running context's parameters to a temporary context for validating proposed updates. Constructing the temporary schemes clears the running schemes' quota state because damon_new_scheme() initializes the quota passed as a parameter before copying it to the new scheme. Even an update later rejected with -EINVAL loses the running quota state. Initialize the new scheme's copy instead, and add KUnit tests for the constructor and for accepted and rejected context updates. Note: below are test results and changelogs that could be removed from the final commit log. In the v1 live test with damo, a scheme with a plain 64 KiB size quota and a 60-second reset interval uses its quota, and a full "damo tune" with unchanged parameters then lets it try another 64 KiB within the same window. With the fix, sz_tried stays at 64 KiB. KUnit was rerun after the rebase on x86-64 and i386. With only patch 2 applied, the two new tests fail. With the fix, all 46 DAMON KUnit tests pass on both architectures. The v1 DAMON selftests showed no new failures (QEMU TCG guest; the wss_estimation test missed its accuracy bounds with and without the fix). This patch (of 2): damon_commit_ctx() first commits the running context's parameters to a temporary context for validating proposed updates. When damon_commit_schemes() creates the temporary schemes, it passes the running scheme's quota as the quota parameter of damon_new_scheme(). damon_new_scheme() calls damos_quota_init() on that quota before copying it to the new scheme. This clears the running scheme's effective quota, feedback input and charging state. Even an update rejected with -EINVAL loses the running quota state. For a size quota, this discards the bytes already charged and allows the scheme to use a fresh quota before the reset interval has elapsed. For a goal-driven quota, the consist tuner loses its accumulated input and restarts from its minimum input. A time quota loses its throughput estimate and falls back to the initial estimate. The end users will show DAMOS works more or less aggressively than expected for online-commit updates of quotas. DAMON provides best efforts by default. DAMON parameters online commit is supposed to be executed only occasionally. Hence, the issue wouldn't be critical on sane setups. For user_input type quota goals, online commit of the user input score is expected to be frequent. But, for the case commit_schemes_quota_goals command is recommended for optimal execution, and it doesn't have this bug. Commit 60bd24f272d0 ("mm/damon/sysfs: test commit input against realistic destination") introduced this problem in v6.19 when sysfs validation began committing the running context's parameters to a temporary context. Commit b90408ef1163 ("mm/damon/core: safely validate src on damon_commit_ctx()") later moved that validation into the core API, exposing other callers including DAMON_RECLAIM and DAMON_LRU_SORT. Sashiko reported the same side effect [1] on the RFC of the core API change. Copy the quota to the new scheme first, then initialize that copy. Make damos_quota_init() return void, since its return value is no longer needed. Link: https://lore.kernel.org/20260928085835.7675-1-sj@kernel.org Link: https://lore.kernel.org/20260928085835.7675-2-sj@kernel.org Link: https://lore.kernel.org/r/20260702212143.0CB6D1F00A3D@smtp.kernel.org/ [1] Fixes: 60bd24f272d0 ("mm/damon/sysfs: test commit input against realistic destination") Signed-off-by: Karl Mehltretter Signed-off-by: SJ Park Signed-off-by: Andrew Morton Reviewed-by: SJ Park Assisted-by: LLM Cc: Bijan Tabatabai Cc: only occasionally. Hence, the issue wouldn't be critical on sane setups. For user_input type quota goals, online commit of the user input score is expected to be frequent. But, for the case commit_schemes_quota_goals command is recommended for optimal execution, and it doesn't have this bug. Commit 60bd24f272d0 ("mm/damon/sysfs: test commit input against realistic destination") introduced this problem in v6.19 when sysfs validation began committing the running context's parameters to a temporary context. Signed-off-by: Sasha Levin commit 85bea4ef391562b91f49bf4e44212c367dc57e07 Author: Hongfu Li Date: Wed Sep 23 10:05:16 2026 +0800 mm/memcg: migrate per-node hugetlb lruvec stat together with hugetlb folio [ Upstream commit 02e0c8cc2815f0082b5b5aabafe3b46688082adc ] memory.numa_stat exposes per-node hugetlb counters from per-node lruvec stats. These stats are accounted against folio_nid(): incremented on the folio's node when handed to a user, decremented when the folio is returned to the pool. During hugetlb folio migration, mem_cgroup_migrate() moves the charge to the new folio and drops the memcg data of the old one, so the free of the old folio right after the migration skips the memcg per-node lruvec decrement. The hugetlb count stays attributed to the old node for the rest of the life of the charge, while the target folio gets no increment on the new node; its later free decrements a counter that was never incremented. Migrate the per-node lruvec accounting alongside migration. Global memcg totals remain balanced because they track resource consumption, not node placement. Link: https://lore.kernel.org/20260923-for-hugetlb_state3-v2-2-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 Reviewed-by: Oscar Salvador Acked-by: Muchun Song 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 576134c74c968c60ee76f04e68c86d7b3308ec02 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 f240a59a02f75c537568423da72a581dd9886ffa 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 3269ad108e9fa176a5ef4f47d0ddb6385bd82af2 Author: Josef Bacik Date: Thu Oct 15 18:07:15 2026 +0200 mm/hugetlb: don't leave a uffd-wp marker when zapping an RWP entry [ Upstream commit f6605fc6b14bd5fc0fea90fc8226573adcec352b ] An entry that is protected with UFFDIO_RWPROTECT is PAGE_NONE with the uffd bit set, the bit that userfaultfd write protection uses too. When __unmap_hugepage_range() zaps an entry with that bit it leaves a PTE_MARKER_UFFD_WP behind, whatever the VMA is registered for. In a VMA registered with UFFDIO_REGISTER_MODE_RWP that marker means nothing. The next fault has hugetlb_no_page() turn it into a present, read-only entry with the uffd bit. That is not an RWP entry, since it is not PAGE_NONE, and the VMA has no VM_UFFD_WP (the two modes can not be registered together). An earlier fix solved some side effects, now just stop the zap from wrongly installing a marker. Leave a marker only if the VMA is registered for write protection, both for present and for non-present entries. The zap of ordinary page tables has the same test, in cond_install_uffd_wp_ptes(), and hugetlb_change_protection() says that "uffd_rwp does not install markers". After a zap the range of an RWP VMA is simply empty, as it is for anonymous memory and shmem. Nothing changes for VMAs with VM_UFFD_WP. In a VMA that is not registered at all a leftover uffd bit or marker is now dropped by the zap and no longer kept alive. Original fix generated by an LLM and sent in private by Josef. [david@kernel.org: a bit of description overhaul+simplification] Link: https://lore.kernel.org/20261015-urgent_fixes-v1-9-42796911043b@kernel.org Fixes: 2d427bb01639 ("mm/userfaultfd: add RWP fault delivery and expose UFFDIO_REGISTER_MODE_RWP") Signed-off-by: Josef Bacik Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Reported-by: Chris Mason Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Lance Yang Acked-by: Kiryl Shutsemau (Meta) Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Muchun Song Cc: Oscar Salvador Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Adam Litke Cc: Mel Gorman Cc: Rik van Riel Cc: Peter Xu Cc: Mike Rapoport Cc: Signed-off-by: Sasha Levin commit cb0565e375d2cfc60b5f35a4bda02504f839be54 Author: David Hildenbrand (Arm) Date: Thu Oct 15 18:07:14 2026 +0200 mm/hugetlb: tolerate UFFD_WP markers outside uffd-wp VMAs [ Upstream commit c37e9d9411a12240a60ca3796d3cbb496e6258a2 ] UFFD PTE bit handling is a bit like swiss cheese, in particular with recently added RWP mode. Having uffd-wp markers outside uffd-wp VMAs already confused this code in the past and resulted in uffd-pte bits confusing other code later. Let's play safe and just ignore these markers in hugetlb_no_page(), not silently propagating the uffd-wp PTE bit. Link: https://lore.kernel.org/20261015-urgent_fixes-v1-8-42796911043b@kernel.org Fixes: 2d427bb01639 ("mm/userfaultfd: add RWP fault delivery and expose UFFDIO_REGISTER_MODE_RWP") Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Lance Yang Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Muchun Song 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 49e58b223494d7d1895073e63c8273ecb93b0f0c Author: David Hildenbrand (Arm) Date: Thu Oct 15 18:07:13 2026 +0200 mm/hugetlb: tolerate uffd bits set without uffd for PROT_NONE PTEs [ Upstream commit 811777d82038d4fd3f5d3bf986f682df463b6f21 ] The whole uffd handling when a VMA is unregistered from UFFD is shaky: there are still some scenarios where we might have stale uffd PTE bits in VMAs no longer registered for UFFD, which confuses other code. Let's just tolerate that for now and simply clear the PTE bit. Add a TODO to really clean up any uffd leftovers when unregistering a VMA from userfaultfd. The handling is now more similar to what we have in handle_pte_fault(). Link: https://lore.kernel.org/20261015-urgent_fixes-v1-7-42796911043b@kernel.org Fixes: 2d427bb01639 ("mm/userfaultfd: add RWP fault delivery and expose UFFDIO_REGISTER_MODE_RWP") Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Lance Yang Acked-by: Kiryl Shutsemau (Meta) Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Muchun Song Cc: Oscar Salvador Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Adam Litke Cc: Mel Gorman Cc: Rik van Riel Cc: Peter Xu Cc: Mike Rapoport Cc: Josef Bacik Cc: Signed-off-by: Sasha Levin commit 746a3094ec2a2fc70cf73447b20c355b57b893fd Author: Josef Bacik Date: Thu Oct 15 18:07:12 2026 +0200 mm/hugetlb: fix endless write fault on a leftover uffd bit [ Upstream commit f61e1cf15fb44f9cf89d43d8ef01f926322bb1c4 ] hugetlb_fault() resolves the uffd bit on a write fault only if the VMA is registered for userfaultfd write protection, and hugetlb_wp() bails out for any entry with the uffd bit set assuming hugetlb_fault() has already resolved it. When a read-only hugetlb entry with the uffd bit set is mapped in a VMA that is not registered for uffd-wp, a write fault to it never makes progress. If the access comes from the kernel, e.g. read(2) from /dev/zero into such page, the task spins in the page fault handler, ignores SIGKILL and keeps holding the locks taken by the system call. Such entries should not exist, but an unprivileged user can create them, for example with MADV_DONTNEED of a page protected with UFFDIO_RWPROTECT or with UFFDIO_COPY in MODE_WP racing with UFFDIO_UNREGISTER. Clear the uffd bit when the VMA is not registered for uffd-wp and let the fault proceed to hugetlb_wp(), like do_wp_page() does for regular pages. Note that a FOLL_FORCE write to a page protected with UFFDIO_RWPROTECT in a private VMA that was made PROT_NONE now drops the RWP protection of that page. Original fix generated by an LLM and sent in private by Josef. [rppt@kernel.org: massage commit message] [david@kernel.org: convert comment into a TODO] Link: https://lore.kernel.org/20261015-urgent_fixes-v1-6-42796911043b@kernel.org Fixes: 60d5b473d61b ("mm/hugetlb: fix uffd wr-protection for CoW optimization path") Signed-off-by: Josef Bacik Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Andrew Morton Reported-by: Chris Mason Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Lance Yang Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Muchun Song 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: Signed-off-by: Sasha Levin commit 090e028cd37ac0fe8510867f3b5c28996fcd318b 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 681592e5d7de934f2f411ad1395139b226d3f4e1 Author: Josef Bacik Date: Thu Oct 15 18:07:10 2026 +0200 mm/hugetlb: unmap the page where the other VMA maps it [ Upstream commit ae99c503eb362b42cd5d24d80bc6cba669acc4c2 ] If the owner of a MAP_PRIVATE hugetlb mapping fails to allocate a page for CoW, unmap_ref_private() unmaps the old page from all other private VMAs that have no reservation of their own. It finds them by the offset in the file, but then zaps each of them at the address of the faulting VMA. Nothing says that another VMA maps the offset at that address: a child can have moved its copy of the VMA with mremap(), and a second mapping of the file is wherever mmap() has put it. So __unmap_hugepage_range() walks the page tables of the other mm at an address outside of iter_vma, where i_mmap_rwsem of this file protects nothing and where anything can be mapped, and the page stays mapped where it really is. All of the following was seen on v7.3-rc6+ (g6c377d19d4a5) in KVM guests, as a user without any privilege. It takes a pool of 2 MiB pages with no free page that is not reserved, so that the allocation fails: the user can take or reserve what is free itself. - The child moves its VMA away. The page is never unmapped, the mapcount stays 2, and the owner goes round retry_avoidcopy in hugetlb_wp() until the child is gone or a page becomes free. SIGKILL to the owner does not end it. 5 of 5 runs. - The owner's mm has a second private mapping of the offset, made with MAP_NORESERVE. The owner zaps its own entry and reads zeroes where its data was. 5 of 5 runs. - The child moves its VMA away and maps a 1 GiB hugetlb page at the old address, so this one takes a pool with a 1 GiB page as well. huge_pte_offset() for the 2 MiB size steps through the PUD leaf, so the "PMD table" is the 1 GiB page itself and its "page table lock" is folio->private of that page, which holds 2. Kernels with lock debugging oops in __unmap_hugepage_range(), 7 of 7 runs. Others spin on that word for ever with preemption disabled, 5 of 5 runs: watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [u_det3:130] RIP: 0010:queued_spin_lock_slowpath+0x8a/0x290 RAX: 0000000000000002 RBX: ffffea0001000028 Call Trace: __unmap_hugepage_range+0x154/0x6d0 unmap_hugepage_range+0xc1/0x140 hugetlb_wp+0x55c/0x700 hugetlb_fault+0x5f3/0x8f0 RCU stalls follow, and killing all tasks of the user changes nothing. Four such owners, whose children share a single 1 GiB page, took down the whole guest with its four CPUs, 2 of 2 runs: one reported soft lockups on all four, the other gave no sign of life any more. i_mmap_rwsem stays write locked. With a MAP_PRIVATE mapping of a hugetlbfs file that belongs to another user, and that the attacker can only read, the next mmap() of that file by its owner sleeps uninterruptibly in __mmap_region(), 4 of 4 runs. Compute the address from the offset for each VMA. The tree walk returns only VMAs that cover pgoff, and vm_start, vm_end and vm_pgoff of a hugetlb VMA are aligned to the huge page size, as pgoff is, so the whole range lies inside iter_vma. Its page tables can not go away there, since the VMA is unlinked from the file under i_mmap_rwsem first. With the right address the page is unmapped from all VMAs but the owner's, so the retry in hugetlb_wp() finds a mapcount of 1 and reuses the page. A child that has moved its copy of the VMA now loses the page, and gets SIGBUS when it faults on a missing page of that VMA. That is what the comment above the function has always promised to those who do not own the reservation, and what already happens to a child that has left the VMA in place. The address has been wrong from the start, and the second case needs only mmap() and fork(). mremap() of hugetlb VMAs, which the other cases use, came with commit 550a7d60bd5e ("mm, hugepages: add mremap() support for hugepage backed vma") in v5.16. Original fix generated by an LLM and sent in private by Josef. [david@kernel.org: switch to vma_filebacked_address, add VM_WARN_ON_ONCE, refine comments] Link: https://lore.kernel.org/20261015-urgent_fixes-v1-4-42796911043b@kernel.org Fixes: 04f2cbe35699 ("hugetlb: guarantee that COW faults for a process that called mmap(MAP_PRIVATE) on hugetlbfs will succeed") 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 ff9df387ea19c1707cd1a60c9245f35e5405229d Author: Josef Bacik Date: Thu Oct 15 18:07:07 2026 +0200 mm/vma: don't leak the commit charge on mmap failure [ Upstream commit aa09311c40f6d3aa6037065e17d257ffa48b9402 ] Patch series "mm: various (urgent?) fixes", v1. Here are various MM fixes. The majority was reported by Josef at Anthrophic, the remainder was found while reviewing/overhauling them. Two issues/fixes reported are not included, as we are discussing (better) alternatives on the list already. I left most of the original commit messages as schloppy as they are: I don't particularly care as long as the code is in good shape and as long as they are not actively wrong. But I (and Mike) could not be stopped from overhauling at least some of them. While I don't think there is anything too critical in here, I think this is a good opportunity to see how fast we can get pre-screened/pre-reviewed fixes upstream that might be security-related. The majority are hugetlb + uffd issues, that are not actually that relevant for most installations. But all things that should just get fixed. Some uffd fixes need proper follow ups to fix some more of the root causes of leftover UFFD PTE bits (or proof that there are none remaining). This patch (of 10): When an accountable mapping replaces existing mappings (MAP_FIXED), __mmap_setup() only charges the difference between the size of the new mapping and the VM_ACCOUNT pages it replaces. It then zeroes vms->nr_accounted so that unmapping the old VMAs does not return their charge, which now backs the new mapping. If the operation fails after that point, the error path returns map->charged, i.e. only the difference. By then vms_clean_up_area() has zapped the page tables and closed the old VMAs, so vms_abort_munmap_vmas() cannot reattach them. It leaves a gap and finishes the unmap with vms_complete_munmap_vmas(), which uncharges vms->nr_accounted == 0 pages. The old VMAs are gone, the new one was never created, and the charge of the old ones is never returned, not even when the process exits. No privilege is needed to hit this, only a file whose mmap hook fails, for example a socket (sock_no_mmap() returns -ENODEV): p = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); mmap(p, len, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_FIXED, socket_fd, 0); Every iteration adds len to Committed_AS for good. With vm.overcommit_memory=2 this lets any user make all further accountable allocations in the system fail with -ENOMEM. Once the new mapping has taken over the charge of the mappings it replaces, it owns the charge for all of its pages. Record that in map->charged, so that the error path returns all of it. A failure in __mmap_setup() itself is not affected: it happens before the charge is taken over and the old VMAs are reattached with their charge intact. Original fix generated by an LLM and sent in private by Josef. [david@kernel.org: call variable "uncharged" and make it const, adjust/simplify comments] Link: https://lore.kernel.org/20261015-urgent_fixes-v1-0-42796911043b@kernel.org Link: https://lore.kernel.org/20261015-urgent_fixes-v1-1-42796911043b@kernel.org Fixes: 4f87153e82c4 ("mm: change failure of MAP_FIXED to restoring the gap on failure") Signed-off-by: Josef Bacik Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Pedro Falcato Reviewed-by: Jose A. Perez de Azpillaga Reviewed-by: Lance Yang Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Muchun Song 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 b0aa8efbcaa80293de872ce90b0dcd8d2fbfb5c6 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 65312c458b2d9ae66eb08093ca1f41f0d4ffc5d2 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 b727f18ccc4396f231a0379ca0e53f165a38e333 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 b26799167322655140ad2cf16b1709aa8bc39cb3 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 53d975c6dc843d65245dc2846ea97cd9e050fdb4 Author: Stanley Jhu Date: Thu Oct 22 11:44:43 2026 +0800 scsi: ufs: core: Do not release a reserved request in ufshcd_abort() [ Upstream commit eb2c4847a1cb2f426cfc702364df7a38ebbf730b ] In SDB mode, aborting a timed-out device management request drops a clock hold that the request never took: 1. ufshcd_dev_man_lock() takes one ufshcd_hold() for the whole device management command. ufshcd_queue_reserved_command() submits the request without taking a hold of its own. 2. The request times out and ufshcd_abort() clears its slot with ufshcd_clear_cmd(). 3. ufshcd_abort() claims BIT(tag) in hba->outstanding_reqs and calls ufshcd_release_scsi_cmd(), which calls ufshcd_release() for a hold the request never took. 4. When ufshcd_dev_man_unlock() drops the hold from step 1, hba->clk_gating.active_reqs goes below zero. Release the command only if it is a SCSI command. Fixes: 08b12cda6c44 ("scsi: ufs: core: Switch to scsi_get_internal_cmd()") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/2060a8da-581b-46d1-a510-779f4df716cd@acm.org Reviewed-by: Bart Van Assche Reviewed-by: Peter Wang Signed-off-by: Stanley Jhu Reviewed-by: Bean Huo Link: https://patch.msgid.link/20261022034443.3034432-7-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 2edb62384a06a9efcafc2c47135d4cdb948b2085 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 d57db743a4a52cbac8fe074287e35757926075b7 Author: Stanley Jhu Date: Thu Oct 22 11:44:41 2026 +0800 scsi: ufs: core: Fix double release in ufshcd_eh_timed_out() [ Upstream commit 3a7e551ae4bcc53f271fc15ab8e930598e28dad8 ] In SDB mode, a command that times out during a power management operation can be released twice: 1. The command times out while its normal completion is running. 2. The completion path clears BIT(rq->tag) in hba->outstanding_reqs and releases the command. It has not called scsi_done() yet, so SCMD_STATE_COMPLETE is still clear. 3. ufshcd_eh_timed_out() recovers the link, sees SCMD_STATE_COMPLETE clear, clears BIT(rq->tag) in hba->outstanding_reqs without checking whether it was still set, and releases the same command a second time. Return SCSI_EH_DONE when ufshcd_clear_outstanding_reqs() returns 0, as another path has already claimed the command. Fixes: 01d5e237b339 ("scsi: ufs: core: Handle PM commands timeout before SCSI EH") Cc: stable@vger.kernel.org Reviewed-by: Peter Wang Signed-off-by: Stanley Jhu Reviewed-by: Bean Huo Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20261022034443.3034432-5-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit e320bbd2a26fc495e54cde7c4711fe0a8dad9a5d Author: Stanley Jhu Date: Thu Oct 22 11:44:40 2026 +0800 scsi: ufs: core: Fix double completion in ufshcd_clear_lu_cmds() [ Upstream commit 6b9c1f49971e4dfe8b8916f0527d30e97c15f234 ] In SDB mode, ufshcd_clear_lu_cmds() clears the request slot in the controller and completes the request, but leaves its bit set in hba->outstanding_reqs. ufshcd_poll() treats a request whose bit is set in hba->outstanding_reqs and clear in the doorbell register as finished, so the next ufshcd_poll() completes the same request again and unmaps its DMA buffers twice. Clear the bit with ufshcd_clear_outstanding_reqs() before completing the request, and complete it only if the bit was still set. If ufshcd_poll() has already completed the request, the bit is already clear and ufshcd_clear_lu_cmds() skips it. Fixes: f18fac1e2b72 ("scsi: ufs: core: Rework ufshcd_eh_device_reset_handler()") 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-4-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 44f4b65877f91e30b0e68e5f6fbd54ca87200903 Author: Stanley Jhu Date: Thu Oct 22 11:44:39 2026 +0800 scsi: ufs: core: Add a helper for clearing hba->outstanding_reqs [ Upstream commit 22d14117ec1845a81acb3a5c4be325f7e8332f70 ] ufshcd_poll() and ufshcd_abort() each have their own copy of the code that clears bits in hba->outstanding_reqs under hba->outstanding_lock. Move that code into ufshcd_clear_outstanding_reqs() and its locked variant __ufshcd_clear_outstanding_reqs(), and use them in both functions. No functional change. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/3779e125-9acc-42c8-9489-51b9e3c6716d@acm.org Suggested-by: Bart Van Assche Reviewed-by: Bean Huo Reviewed-by: Peter Wang Signed-off-by: Stanley Jhu Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20261022034443.3034432-3-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 5b2f8086523ff9e0c8b4aa6992fa49f3eb17916b 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 5855ed19d78db577c757ba2c68107fbbbee3f510 Author: Yingjie Wang Date: Thu Oct 22 02:55:11 2026 +0000 scsi: handle out-of-range SG_SET_TIMEOUT values [ Upstream commit 9a6cb1da4f3bc4633bf6669faed25a361834b1b9 ] SG_SET_TIMEOUT accepts a signed int in USER_HZ units. The sg character device rejects negative values and limits positive values so the converted timeout fits its destination field. The block SCSI and BSG paths instead pass the value to clock_t_to_jiffies(), which accepts an unsigned long, and store the result in an unsigned int. Negative values are converted into large unsigned timeouts. On 64-bit systems, large positive values can also exceed UINT_MAX after conversion and are truncated on assignment. With HZ=1000 and USER_HZ=100, for example, 429496730 clock ticks become 4294967300 jiffies and are stored as 4 jiffies. On 32-bit systems, an overflowing conversion becomes ULONG_MAX, which is an unsafe relative interval for the block timer comparisons. Reject negative values with -EIO, matching drivers/scsi/sg.c. Saturate the converted value at the smaller of the destination field limit and MAX_JIFFY_OFFSET. This preserves successful ioctl behavior while avoiding both narrowing wraparound and an unsafe 32-bit timer interval. The block SCSI behavior predates Git history. BSG has exposed the same behavior since it was introduced. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 3d6392cfbd7d ("bsg: support for full generic block layer SG v3") Cc: stable@vger.kernel.org Reported-by: Bart Van Assche Link: https://lore.kernel.org/r/9321a59c-c560-4742-8b71-5b0ec1f30c2f@acm.org Signed-off-by: Yingjie Wang Link: https://patch.msgid.link/20261022025508.294713-1-x-professor@outlook.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 5276c3501f8762151a8aa87a1ada24ecfd4b5109 Author: Bart Van Assche Date: Mon Oct 19 14:55:32 2026 -0700 scsi: sd: Mark the disk dead if runtime resume fails in sd_remove() [ Upstream commit 085bb18a0b91007f04ddca13af30277c78040157 ] If a SCSI disk is unplugged while runtime suspended, its request queue is still in the pm-only state when sd_remove() is called. The runtime resume attempted by scsi_autopm_get_device() fails because the parent device, e.g. a USB device in the USB_STATE_NOTATTACHED state, cannot be resumed. Hence, sdev_runtime_resume() is not called and the pm-only state is not cleared. Next, del_gendisk() calls blk_report_disk_dead(disk, false), which calls sync_filesystem(). Any bio submitted by the filesystem waits forever in __bio_queue_enter() because the queue will never leave the pm-only state and because GD_DEAD has not yet been set: __bio_queue_enter+0xb8/0x174 blk_mq_submit_bio+0x640/0x7e4 [ ... ] exfat_sync_fs+0xa4/0xe0 sync_filesystem+0xa8/0xdc fs_bdev_mark_dead+0x30/0x88 bdev_mark_dead+0x54/0xc4 blk_report_disk_dead+0x8c/0xd4 del_gendisk+0xa0/0x2f8 sd_remove+0x30/0x60 [ ... ] scsi_remove_host+0x88/0x18c usb_stor_disconnect+0x68/0xf4 Fix this hang by calling blk_mark_disk_dead() if runtime resume fails. This sets GD_DEAD, tells the filesystem that the disk has been removed without attempting to sync it, and wakes up any bios that are waiting in __bio_queue_enter(). Syncing the filesystem is not possible anyway if runtime resume failed, so no data is lost that could otherwise have been written. If runtime resume succeeds, behavior is not changed. Please note that this patch converts temporary runtime resume failures into permanent failures. Before this patch, if runtime resume fails temporarily, a filesytem sync would be postponed until a later resume succeeds. Cc: Christoph Hellwig Tested-by: Lianqin Hu Reported-by: Lianqin Hu Closes: https://lore.kernel.org/all/TYUPR06MB6217DD31B1B3CD09E431CC12D2922@TYUPR06MB6217.apcprd06.prod.outlook.com/ Fixes: 6f8191fdf41d ("block: simplify disk shutdown") Cc: stable@vger.kernel.org Signed-off-by: Bart Van Assche Reviewed-by: John Garry Link: https://patch.msgid.link/2c0c76d70f0fe197932836b9bcf8496095135d1b.1792446921.git.bvanassche@acm.org Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 9a6aa08dccb428d9f0ea40d9fce8debdac317c89 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 c378d4fdb6c7244c3458af886e2bab61f8f56d13 Author: Joonhoe Kim <26rote@gmail.com> Date: Fri Oct 16 21:46:08 2026 +0900 scsi: ufs: core: Fix a deadlock between clock scaling and device commands [ Upstream commit 2327df6d2a290af62a6da21b2ad301848bb86002 ] Since commit 08b12cda6c44 ("scsi: ufs: core: Switch to scsi_get_internal_cmd()"), device management commands go through blk_execute_rq() on the pseudo SCSI device, which shares the tagset with the logical units, while ufshcd_dev_man_lock() holds clk_scaling_lock for reading. ufshcd_clock_scaling_prepare() and ufshcd_pause_command_processing() quiesce the tagset before taking clk_scaling_lock for writing. A device management command holding the lock for reading at that point is never dispatched and never times out, so the writer waits forever with all logical units quiesced. On a Lenovo Legion Tab Y700 Gen 5 this ended in a hung task panic. Take clk_scaling_lock before quiescing the tagset, and in ufshcd_clock_scaling_prepare() also wb_mutex, which is always taken before clk_scaling_lock. Release them in the reverse order. Commit b52d695d0620 ("scsi: ufs: core: Keep internal commands dispatchable during error handling") fixed the same problem in the error handler. Fixes: 08b12cda6c44 ("scsi: ufs: core: Switch to scsi_get_internal_cmd()") Fixes: dc5dcac53278 ("scsi: ufs: core: Add helpers to pause and resume command processing") Cc: stable@vger.kernel.org Signed-off-by: Joonhoe Kim <26rote@gmail.com> Reviewed-by: Peter Wang Link: https://patch.msgid.link/20261016124608.46-1-26rote@gmail.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit c86ad7924cdba279e6d079aaf04048f3d237780e 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 fab642b4b94e195052562ae21737acd6d4d303bf Author: Stanley Jhu Date: Thu Oct 15 08:18:54 2026 +0800 scsi: ufs: bsg: Reject UIC commands with a non-zero result byte [ Upstream commit 1ae42513205a38b811afedb6797f9f9c4de37b90 ] ufs_bsg_request() passes the user-supplied UIC argument2 unchanged, including the result byte (bits 7:0) that only the host controller writes. A non-zero value triggers the WARN_ON_ONCE() in ufshcd_dispatch_uic_cmd() and corrupts the reported result. Found by syzkaller. Reject UIC commands that have the result byte set with -EINVAL. Fixes: e77044c5a842 ("scsi: ufs-bsg: Add support for uic commands in ufs_bsg_request()") Fixes: 9fb4c793223b ("scsi: ufs: core: Complain if UIC argument 2 is invalid") 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-5-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 0fcf2c7ace5fdab641a81aa2455e2dc56d4a6a20 Author: Stanley Jhu Date: Thu Oct 15 08:18:53 2026 +0800 scsi: ufs: bsg: Validate request_len before accessing request [ Upstream commit 42aa443718104d10dbdb6f258810b425eb2451f8 ] ufs_bsg_request() and ufs_bsg_exec_advanced_rpmb_req() read the request buffer without checking job->request_len, which userspace controls. A short request causes an out-of-bounds read. Found by syzkaller. Reject requests shorter than the structure each path reads. Fixes: 64d4864714c2 ("scsi: ufs: bsg: Remove unnecessary length checkup") Fixes: 6ff265fc5ef6 ("scsi: ufs: core: bsg: Add advanced RPMB support in ufs_bsg") 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-4-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 230b5c5c36216cbc6876e702c96bbe601249a1a5 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 b75af28847a4cd6eb1275beb49cfb9da322926e6 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 e6d4b73a20b9c7bcb7f900d9d57b6f2043d28d91 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 11ea17b41670badb30f1acb937f2bb1f957a4ca9 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 3b90249fcec9fd3727f2c6ac973410a13bf273d8 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 91139c72c3e07e6b02f1250bc42c053d133bbae9 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 ab32bad9df6f64339eb403bd23e1448bf6424ba7 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 427810d79c66a006c78417cb272072df9a13dd8a Author: Daehyeon Ko <4ncienth@gmail.com> Date: Mon Oct 19 17:03:24 2026 +0900 timekeeping: Require permission to set auxiliary clocks [ Upstream commit 524d95c8a2000cba6cb80a173d76cb746c561244 ] The generic clock_settime() entry point delegates permission checks to each clock-specific callback. aux_clock_set() does not perform one. Once an administrator enables an auxiliary clock, any local process can therefore change the global clock offset. A test process running as UID and GID 65534 with no effective, permitted, inheritable, or ambient capabilities set CLOCK_AUX0 successfully, and a separate process observed the new value. The same process was denied by clock_adjtime(). An AppArmor profile denying sys_time also blocked CLOCK_REALTIME changes but did not see the auxiliary clock operation. Call security_settime64() before mutating the auxiliary timekeeper. This matches CLOCK_REALTIME's permission model, enforces initial-user-namespace CAP_SYS_TIME, and gives LSMs the settime hook while preserving authorized clock changes. Fixes: 60ecc26ec5af ("timekeeping: Provide time setter for auxiliary clocks") Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Signed-off-by: Thomas Gleixner Tested-by: shaos Acked-by: John Stultz Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261019080324.4147815-1-4ncienth@gmail.com Signed-off-by: Sasha Levin commit 5f80c43b1eee4635493a308c0805fb2a1a24ad51 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 936d3aa096a9308603aec9a03a8d2e90bdf1509b Author: Zhiling Zou Date: Tue Oct 20 14:39:36 2026 +0800 ipmr: only copy pktinfo to cache reports [ Upstream commit 94a6736bb5abe6b2ef38490d0cab19c1c6a7c71f ] ipmr_cache_report() prepares IP_PKTINFO on the original skb. The ipv4_pktinfo_prepare() helper updates skb->cb and clears the pktinfo fields when packet info is disabled. Since the skb can continue through the data path, preserve and restore its original control block around the helper. The original implementation copies the entire control block to the report skb. For synthetic RTM_GETROUTE packets, NETLINK_CB data is interpreted as IPCB by the raw IPv4 receive path. With IP_RECVOPTS or IP_RETOPTS enabled, corrupted option offsets cause out-of-bounds reads or a stack buffer overflow. WHOLEPKT and WRVIFWHOLE reports also inherit stale IP option offsets when their header is prepended. Clear the report skb control block. Only prepare and copy pktinfo when the input skb has an IPv4 header. Synthetic route-query skbs use NETLINK_CB, not IPCB, so leave their report control block zeroed. Restore pkt->cb after preparing pktinfo for regular IPv4 packets. Fixes: bb7403655b3c ("ipmr: support IP_PKTINFO on cache report IGMP msg") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega Link: https://lore.kernel.org/netdev/20260903113055.GA90787@shredder/ Suggested-by: Ido Schimmel Suggested-by: Eric Dumazet Signed-off-by: Zhiling Zou Reviewed-by: Ido Schimmel Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/0545f0c83f5ee2f6696210f87268e811ef655715.1792476357.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 37c51b2e26582e767479a344e105a717f713299c 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 983c8aa696c0bee3a5a7f0aba17338d619030b66 Author: Yafang Shao Date: Fri Oct 23 10:31:04 2026 +0800 sched: fix stale get_pref_llc() stub for !CONFIG_SCHED_CACHE [ Upstream commit cac037a85c1971ec75c4d3edf5a28af9ec2a089c ] Commit b636fef85bda ("sched/cache: Introduce task_struct->sched_cache_grp to fix UAF") switched get_pref_llc() from taking a struct mm_struct * to taking the task's struct sched_cache_group *, but only updated the CONFIG_SCHED_CACHE definition and its caller: the stub in the !CONFIG_SCHED_CACHE branch kept the old mm_struct parameter. Fixes: b636fef85bda ("sched/cache: Introduce task_struct->sched_cache_grp to fix UAF") Signed-off-by: Yafang Shao Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Gregory Price (Meta) Reviewed-by: Chen Yu Reviewed-by: Tim Chen Cc: #v7.2.x Link: https://patch.msgid.link/20261023023105.28829-2-laoar.shao@gmail.com Signed-off-by: Sasha Levin commit f237a79af83375ec3e64f4fde0162c854d406a00 Author: Tim Chen Date: Wed Oct 7 10:25:30 2026 -0700 sched/cache: Honor asym packing over cache aware scheduling on hybrid systems [ Upstream commit ee92b7ef4c1e271b3c1ea2a8b13034bdc62422a7 ] A regression was reported on an AMD Ryzen AI HX 370 running a cache intensive Clang full-LTO link. The little cores run at a much lower frequency (3.3 GHz vs 5.1 GHz) and have only half of the L3 cache (8 MB vs 16 MB), so pinning such a task to the little-core LLC hurts twice, and full-LTO builds slow down dramatically compared to pre-cache-aware-scheduling kernels. Asym packing and cache aware scheduling express conflicting placement strategies. Asym packing wants a task to run on the highest priority CPU, whereas cache aware scheduling wants to co-locate the tasks of a process on one LLC regardless of the priority of CPUs in that LLC. When asym packing tries to migrate task to an idle core that has higher priority than source cpu, let asym packing win. Moving tasks to a higher performing idle core will buy more performance than cache co-location. Prioritize asym packing over LLC balancing for regular and active load balancing. Fixes: 23b2b5ccc45c ("sched/cache: Introduce helper functions to enforce LLC migration policy") Closes: https://lore.kernel.org/lkml/2180ea5a-eb28-4152-8d4d-cd00b0c24b2e@computerix.info/ Reported-by: Klaus Kusche Suggested-by: Kayra Cizmeci Signed-off-by: Tim Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kayra Cizmeci Tested-by: Klaus Kusche Tested-by: Ricardo Neri Tested-by: Chen Yu Cc: stable@vger.kernel.org Cc: stable@vger.kernel.org # 7.2.x Link: https://patch.msgid.link/b29badede27bb6bfb4a759e06754cb19657f0778.1791308631.git.tim.c.chen@linux.intel.com Signed-off-by: Sasha Levin commit 3172b2bddc32bf2c9ab19cabc25b9a2e30046668 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 bef087dd545340aaa4e8db619b48573e268fee94 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 ca12eac24875176507c99c937cd6e61180cc73bb 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 ed99cc40d65a23c2294fb022b020efd57c2c8b07 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 29807241a05f4b2614bd7580ca28537a39234a9f 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 d94fa66c1b9f0885abe3557f323ee7e2aa6695c8 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 8e1a34694effdb49724fea5cbf282353fef3b19c 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 f43962764569ef0db566fe391f0072f9c70811b3 Author: Alexander Sverdlin Date: Thu Oct 1 08:01:11 2026 +0200 tpm: tpm2_probe: propagate transport errors [ Upstream commit 7d4f1cbfe063af5581dac66abe9e9c965e1031cc ] tpm2_probe() reads the protocol version from the response tag and is documented to return -errno on failure, but it always returns 0. A transport error (tpm_transmit_cmd() < 0) is thus swallowed together with the intentionally ignored TPM response code, leaving TPM_CHIP_FLAG_TPM2 unset. A transient bus failure on the first command then misdetects a TPM 2.0 as a 1.2 and the probe fails on the TPM 1.2 path: tpm_tis_i2c 0-002e: 1.2 TPM (device-id 0x1C, rev-id 22) tpm tpm0: A TPM error (-62) occurred attempting to determine the timeouts Return the transport error instead; rc >= 0 still means a valid header was received and the TPM's own response code is still ignored. Fixes: 94e266ba1fa3 ("tpm: migrate tpm2_probe() to use struct tpm_buf") Cc: stable@vger.kernel.org Signed-off-by: Alexander Sverdlin Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20261001060114.1582092-1-alexander.sverdlin@siemens.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 963db85cbe0aa9385d73a76aafda8869f39f015a 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 14f3be0ba056e696dbd3c21bbd10a144aca15c62 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 0588052542ab6cd29e1b05dd483a9bdab69c9332 Author: Karl Mehltretter Date: Thu Sep 10 22:52:34 2026 +0200 PM: EM: allocate the cpumask for every perf domain [ Upstream commit 6c7a7007c5b7566fba4fbee1d40011fb8f833dc3 ] em_create_pd() allocates space for the trailing cpus[] flexible array only for CPU devices. A performance domain registered for another device therefore has no storage for its cpumask. All performance domains are added to em_pd_list. The netlink interface does not distinguish CPU and non-CPU domains when it calls cpumask_weight() or iterates over pd->cpus. A request for a non-CPU domain reads cpumask_size() bytes beyond the allocation and can report bits from the following memory as CPU attributes. KASAN reports slab-out-of-bounds reads for both dump and by-ID requests against a synthetic non-CPU performance domain. GET_PERF_DOMAINS does not require GENL_ADMIN_PERM, so an unprivileged request can reach this path when a GPU or another devfreq device has registered an energy model. Allocate the cpumask for non-CPU domains too. The zeroed mask remains empty, as required for the documented unused field. Fixes: d8eef0453132 ("PM: EM: Implement em_nl_get_pds_doit()") Cc: All Applicable Signed-off-by: Karl Mehltretter Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/20260910205234.5392-1-kmehltretter@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit bab8c554ad4350c26708fc10afabf214ff6b5ae8 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 98813eecf7555d35031ad8103c6a4eb14836e61c 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 d855919d745ebd8ffdec0e3467669540f362b1c8 Author: Christian Brauner Date: Wed Oct 21 13:46:58 2026 +0200 listns: don't wrap around with a U64_MAX cursor [ Upstream commit 2a1887000e2d4adc8cb3933b53431dea6d5e310b ] do_listns() and do_listns_userns() take the last namespace id the caller saw and look up the first namespace after it by searching the rbtree for last_ns_id + 1. With U64_MAX that wraps around to zero and the search returns the namespace with the smallest id. So a cursor at the largest possible id restarts the listing from the beginning instead of failing with ENOENT like a cursor of U64_MAX - 1 does. That's the case for the unified tree, the type-specific trees and the owner tree alike. No namespace will ever have that id. They come from a counter and a caller that only feeds back ids it got from us can't hit this. It's still wrong. Instead of adding one to the cursor and searching for the smallest id that's greater or equal make the lookup helpers search for the smallest id that's strictly greater than the cursor. That's what both callers want anyway and there's nothing left to overflow. Reproducer, unprivileged: #define _GNU_SOURCE #include #include #include #include #include #ifndef __NR_listns #define __NR_listns 470 #endif #define CLONE_NEWUSER 0x10000000U #define LISTNS_CURRENT_USER 0xffffffffffffffffULL struct ns_id_req { uint32_t size, spare; uint64_t ns_id; uint32_t ns_type, spare2; uint64_t user_ns_id; }; static void list(const char *tree, uint32_t type, uint64_t owner, uint64_t cursor) { struct ns_id_req req = { .size = sizeof(req), .ns_id = cursor, .ns_type = type, .user_ns_id = owner, }; uint64_t ids[8]; long ret; errno = 0; ret = syscall(__NR_listns, &req, ids, 8, 0); printf("%s cursor %llu: ret %ld errno %d", tree, (unsigned long long)cursor, ret, errno); for (long i = 0; i < ret && i < 3; i++) printf("%s%llu", i ? "," : " ids ", (unsigned long long)ids[i]); printf("%s\n", ret > 3 ? ",..." : ""); } int main(void) { static const uint64_t cursors[] = { 0, UINT64_MAX - 1, UINT64_MAX }; for (int i = 0; i < 3; i++) list("unified", 0, 0, cursors[i]); for (int i = 0; i < 3; i++) list("userns", CLONE_NEWUSER, 0, cursors[i]); for (int i = 0; i < 3; i++) list("owner", 0, LISTNS_CURRENT_USER, cursors[i]); return 0; } Before, on 7.3.0-rc7-00252-g4e3259b08c54 (vfs.fixes) in a VM: unified cursor 0: ret 8 errno 0 ids 1,2,3,... unified cursor 18446744073709551614: ret -1 errno 2 unified cursor 18446744073709551615: ret 8 errno 0 ids 1,2,3,... userns cursor 0: ret 1 errno 0 ids 3 userns cursor 18446744073709551614: ret -1 errno 2 userns cursor 18446744073709551615: ret 1 errno 0 ids 3 owner cursor 0: ret 8 errno 0 ids 1,2,4,... owner cursor 18446744073709551614: ret -1 errno 2 owner cursor 18446744073709551615: ret 8 errno 0 ids 1,2,4,... After: unified cursor 0: ret 8 errno 0 ids 1,2,3,... unified cursor 18446744073709551614: ret -1 errno 2 unified cursor 18446744073709551615: ret -1 errno 2 userns cursor 0: ret 1 errno 0 ids 3 userns cursor 18446744073709551614: ret -1 errno 2 userns cursor 18446744073709551615: ret -1 errno 2 owner cursor 0: ret 8 errno 0 ids 1,2,4,... owner cursor 18446744073709551614: ret -1 errno 2 owner cursor 18446744073709551615: ret -1 errno 2 Reported-by: shaos Link: https://lore.kernel.org/r/20261020110732.959552-1-shawnq1@163.com Fixes: 76b6f5dfb3fd ("nstree: add listns()") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261021-work-mount-statmount_listns_fixes-v1-5-8917a4c1bd14@kernel.org Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit cd0e590ad13a0f2e2d1b7c47ca1c4ce2bb6deb60 Author: Nikolaos Karaolidis Date: Fri Oct 9 14:24:31 2026 +0000 fs: don't lose inodes that another LRU walker is isolating [ Upstream commit 8dc4116041e2b377e5e1b62ba98b37636f9f3968 ] When inode_lru_isolate() finds an unused inode that still has page cache, it sets I_LRU_ISOLATING, drops i_lock and the list_lru lock, invalidates the page cache, clears the flag again and returns LRU_RETRY so that the restarted walk can free the inode. Another walker of the same list can reach the inode in that window. It sees a non-zero i_state and takes the inode off the LRU, as it would an inode that is in use. Page cache deletion requeues the inode once the mapping is shrinkable, so this is harmless if it happens before the last deletion. If it happens after, nothing puts the inode back: it stays in memory, unused, clean and without page cache, out of reach of the shrinker and of drop_caches, until it is looked up again or the filesystem is unmounted. Before commit 2a0629834cd8 ("vfs: Don't evict inode under the inode lru traversing context") the pin was an i_count reference, and the final iput() put the inode back on the LRU. Skip inodes that are being isolated and leave them to the walker that pinned them, which restarts its walk once it has unpinned them. The window is reached by any unused inode with page cache on CONFIG_HIGHMEM kernels, and otherwise by inodes whose page cache is a single shadow entry at index 0. On an i386 HIGHMEM guest, eight concurrent "echo 2 > /proc/sys/vm/drop_caches" over 2000 freshly read one-page ext4 files leave roughly 400 of the inodes off the LRU per round; on x86_64, with the files' pages first evicted through memory.reclaim, 3 to 4 per round. With this patch, none in either case. Fixes: 2a0629834cd8 ("vfs: Don't evict inode under the inode lru traversing context") Cc: stable@vger.kernel.org Signed-off-by: Nikolaos Karaolidis Link: https://patch.msgid.link/20261009142431.713875-1-nick@karaolidis.com Reviewed-by: Zhihao Cheng Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit b399a48c1ee794c678dd365e6365dd37db078d0b 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 a522c991eb26a8b011793fa41659596e6f444f67 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 0242cf173e417d2aa89ade31f107b5d620c4db0d 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 791bbd305155e6dc5bab5b740a1b85e7877c3fd3 Author: Liz Fong-Jones Date: Sat Oct 17 04:07:11 2026 +0000 writeback: keep cleanup_offline_cgwb()'s scan out of syncs [ Upstream commit 90c96612460e6accddbda5a195e6ddaa391ecde0 ] On a filesystem mounted with lazytime, sync() and syncfs() can return without persisting timestamp updates of inodes attached to a dying cgroup wb, so a crash after the sync loses them. File data and sizes are not affected. Since commit f6988c90671e ("writeback: bound cleanup_offline_cgwb() rescans by rotating scanned inodes"), isw_prepare_wbs_switch() moves the inodes it walks to the newest end of the list. When a pass fills its isw before reaching an inode that got its lazytime update after a sync's cutoff, the walked inodes land past it on b_dirty_time, and the sync's queue_io(), which stops at the first inode dirtied after the cutoff, misses them. The late inode has to be one without a pending lazytime update; one already on b_dirty_time keeps its position. The window is narrow. cleanup_offline_cgwbs_workfn() skips wbs with anything on b_dirty, b_io or b_more_io, so the scan has to land between wb_writeback() fixing dirtied_before and taking list_lock for its first queue_io(), unless a multi-pass drain started before the wb got dirty IO. Take wb_switch_rwsem for read across the scan, as process_inode_switch_wbs() does for the switches. Fixes: f6988c90671e ("writeback: bound cleanup_offline_cgwb() rescans by rotating scanned inodes") Cc: stable@vger.kernel.org Suggested-by: Tejun Heo Link: https://lore.kernel.org/all/0bc5d58533f10b4841807be3025daa11@kernel.org/ Acked-by: Tejun Heo Signed-off-by: Liz Fong-Jones Link: https://patch.msgid.link/20261017040710.1174009-1-lizf@honeycomb.io Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 4005fb67dee0cd88b5a1e3f6ef66859bc0517c06 Author: Nikolaos Karaolidis Date: Fri Oct 16 10:25:15 2026 +0000 fs: rotate inodes whose page cache could not be dropped [ Upstream commit 8ee09f597763acfd31c62a578ba88b792fc41b24 ] When inode_lru_isolate() drops the page cache of an unused inode, it has to unlock the list, so it returns LRU_RETRY and the walk restarts at the head of the list, where the inode still is. If invalidate_mapping_pages() could not empty the mapping, the restarted walk strips the same inode again, and so on until nr_to_walk runs out. Every walk of that list then ends on this inode, and nothing behind it is reclaimed for as long as its cache stays. Before commit 2a0629834cd8 ("vfs: Don't evict inode under the inode lru traversing context") the walker pinned the inode with a reference, and dropping it in iput_final() set I_REFERENCED, so the restarted walk rotated the inode to the tail. Set I_REFERENCED again when the mapping is still populated after the invalidation, in the same i_lock section that clears I_LRU_ISOLATING. inode_unpin_lru_isolating() now expects i_lock to be held, like inode_pin_lru_isolating(). On CONFIG_HIGHMEM kernels this can happen to any unused inode: a folio is left behind if it is locked, under writeback, spliced into a pipe, or still in another CPU's LRU-add batch after being read. Without HIGHMEM it happens to DAX inodes whose only entry is at index 0, which mapping_shrinkable() lets onto the LRU and invalidate_mapping_pages() never removes. Fixes: 2a0629834cd8 ("vfs: Don't evict inode under the inode lru traversing context") Cc: stable@vger.kernel.org Signed-off-by: Nikolaos Karaolidis Link: https://patch.msgid.link/20261016102515.111285-1-nick@karaolidis.com Reviewed-by: Jan Kara Reviewed-by: Zhihao Cheng Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 9626137bb92929ce7438feae3ecff9d5f000013f Author: Guopeng Zhang Date: Tue Oct 20 21:36:15 2026 +0800 cgroup/cpuset: Fix task checking when enabling a partition [ Upstream commit f5b5cf2be574df6f25cbf1b000960340bff9a0bb ] Creating a child partition can fail when tasks are present in its descendants, even though the parent has no tasks of its own. On a cgroup v2 system with CPUs 0-7 online: cd /sys/fs/cgroup echo +cpuset > cgroup.subtree_control mkdir A echo 1-2 > A/cpuset.cpus echo root > A/cpuset.cpus.partition echo +cpuset > A/cgroup.subtree_control mkdir A/B echo 1-2 > A/B/cpuset.cpus echo +cpuset > A/B/cgroup.subtree_control mkdir A/B/C echo 1-2 > A/B/C/cpuset.cpus echo $$ > A/B/C/cgroup.procs echo root > A/B/cpuset.cpus.partition cat A/B/cpuset.cpus.partition root invalid (Parent unable to distribute cpu downstream) cat A/cpuset.cpus.effective 1-2 B should be a valid root, leaving A with an empty effective CPU list. The task in C belongs to B's partition and does not need CPUs in A. partition_is_populated() is called with B as excluded_child, but continue only skips B in the pre-order walk. The walk still visits C and finds the task there, so A is considered populated. Fix this by skipping the whole excluded subtree with css_rightmost_descendant(), as is already done for valid child partitions. Also add a test case to test_cpuset_prs.sh with a task in a grandchild cpuset. Fixes: b1bcaed1e39a ("cpuset: Treat cpusets in attaching as populated") Cc: stable@vger.kernel.org # v6.19+ Signed-off-by: Guopeng Zhang Reviewed-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 3fd5792b3ddc0fe440c2eac1646b86c1eb4b38df 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 6ff5288c7a5da4cd792383144f91e584d291ca2f Author: Niklas Cassel Date: Tue Oct 20 12:11:08 2026 +0200 ata: libata-sff: fix race between IRQ deferral and ata_sff_flush_pio_task() [ Upstream commit 69be770908ae57354a41d7e1cc99ab46278d2e86 ] Commit 4a2e5409472e ("ata: libata-sff: don't busy-wait for PIO data-in command completion") allowed the interrupt handler to queue ap->sff_pio_task from ata_sff_hsm_move() when a PIO data-in command is still busy after its final data block. ata_sff_flush_pio_task(), however, was written under the assumption that cancel_delayed_work_sync() is enough to prevent sff_pio_task from being queued again before the HSM state is reset to HSM_ST_IDLE and sff_pio_task_link is cleared. The flush runs early during error handling, at a point where the timed out command is still active, the port is not frozen yet, and interrupts are still being serviced. If the final data-block interrupt of a PIO data-in command is serviced in the window between cancel_delayed_work_sync() and the reset of hsm_task_state, the interrupt handler queues sff_pio_task after the cancel has completed. When that work item then executes on ata_sff_wq after the flush cleared ap->sff_pio_task_link, ata_sff_pio_task() hits BUG_ON(ap->sff_pio_task_link == NULL) while holding the host lock with interrupts disabled; alternatively it proceeds on a stale link while error handling owns the port. Fix this by resetting hsm_task_state to HSM_ST_IDLE before cancelling the work item. Once the state is IDLE, __ata_sff_port_intr() can no longer enter ata_sff_hsm_move(), so the interrupt handler can no longer queue the pio task, and cancel_delayed_work_sync() drains whatever was queued before the reset. Also make ata_sff_pio_task() bail out quietly when the HSM state was marked idle by the flush, both at entry and after re-acquiring the port lock following ata_msleep(), since a work item can already be running when the flush resets the state. Reported-by: sashiko-bot Link: https://lore.kernel.org/linux-ide/sashiko-outbox-177477@kernel.org/ Fixes: 4a2e5409472e ("ata: libata-sff: don't busy-wait for PIO data-in command completion") Cc: stable@vger.kernel.org Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20261020101107.1449635-2-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 3f57fc88f13d89e1e7a24af5a46c0e6ab680ce56 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 a49133d06bd2d1425c6d497f1699e2ce8cd56695 Author: Qingfang Deng Date: Tue Oct 20 17:21:11 2026 +0800 pppoe: delete session hash entries by pointer match [ Upstream commit b5b8c81836e2bec7b444dfa2b14fd14e912e9d63 ] pppoe_connect() copies the requested PPPoE address to a socket before attempting to insert the socket into the session hash table. If the tuple already exists, __set_item() returns -EALREADY, but the copied address and ifindex remain set on the failed socket. Closing that socket then deletes the existing socket's hash entry through pppoe_release(), preventing it from receiving further session traffic. An unprivileged process in the same network namespace can trigger this through a duplicate connection attempt. To avoid the accidental delete, pass the pppox_sock to __delete_item(), and unlink only an entry whose pointer matches the requested socket. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Qingfang Deng Link: https://patch.msgid.link/20261020092118.47416-1-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ff6db2332643e5d4332b3acba5e2e98c13496848 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Mon Oct 19 17:43:49 2026 +0900 mshv_vtl: reject poll files with multiple waitqueues [ Upstream commit 70cd4623f3e5068a72c72791b96f2dcb4c991131 ] MSHV_SET_POLL_FILE invokes a file descriptor poll callback with a poll table backed by a single embedded wait entry. A poll callback may, however, register the table with more than one waitqueue. pipe_poll() does this naturally for an O_RDWR FIFO. The second registration currently warns but then inserts the same list node into another list. The new insertion overwrites the entry links while the first waitqueue still points at it, corrupting the first waitqueue and causing an invalid callback traversal when that queue wakes. Reject a second distinct waitqueue, remove the first registration through the common removal helper, and return -EINVAL from the ioctl. Repeated registration of the same waitqueue is treated as a no-op. A rejected replacement leaves the CPU slot unregistered, consistent with the existing remove-before-register ordering. Single-waitqueue users such as the OpenHCL io_uring poll file keep their existing behavior. An LLM assisted the source audit, fix development, and validation of this issue. Fixes: 7bfe3b8ea6e3 ("Drivers: hv: Introduce mshv_vtl driver") Cc: stable@vger.kernel.org Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Naman Jain Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 7aa18e5dbc2929d5792a037af73eeb99545c2156 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 d994a3768b2bf1a037991592664c0d544aea232d Author: Shawn Lin Date: Thu Oct 8 16:05:00 2026 +0800 PCI/pwrctrl: Only destroy devices created by pwrctrl core [ Upstream commit 7bf2ebcb7ca1e8814d3d0e35214a8e4b2193a619 ] pci_pwrctrl_create_device() only creates platform devices for OF nodes that pci_pwrctrl_is_required() accepts, but pci_pwrctrl_destroy_device() unregisters the platform device of every available child node without that check. Nodes under a PCI host controller that are not pwrctrl devices may have been populated by another mechanism. Destroying them here would tear down devices owned by other code. Mirror the check done at creation time so that only devices created by the pwrctrl core are removed. Fixes: 4c4132489201 ("PCI/pwrctrl: Add APIs to create, destroy pwrctrl devices") Signed-off-by: Shawn Lin Signed-off-by: Bjorn Helgaas Reviewed-by: Bartosz Golaszewski Cc: stable@vger.kernel.org Link: https://patch.msgid.link/1791446700-100166-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Sasha Levin commit a888975330ad83322283823bea78306c0c195aaf Author: Alexey Charkov Date: Wed Sep 30 20:07:45 2026 +0400 PCI/pwrctrl: generic: Fix leaking array from of_regulator_bulk_get_all() [ Upstream commit ee450e3a2d334c7e6383d8a55ad2d53b3822bacc ] of_regulator_bulk_get_all() allocates the consumers array and returns it to the caller, who is expected to free it at an appropriate time. PCI pwrctrl never did, leading to a memory leak. Add an explicit kfree() for the consumers array. Fixes: 75996c92f4de ("PCI/pwrctrl: Add pwrctrl driver for PCI slots") Signed-off-by: Alexey Charkov Signed-off-by: Bjorn Helgaas Reviewed-by: Bartosz Golaszewski Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260930-pci-pwrctrl-kfree-v1-1-f09bbffd8da3@flipper.net Signed-off-by: Sasha Levin commit 734c6cd3b2537e0475e5cc15e643af686f066107 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 171b31ca995278c39036cc0e0caac1578db88986 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 7d9c3b7098ed6d7564ccbeae7fa98f759d6ef24c 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 0a42e7a1927fc4aa3387efa102362de1fd286b10 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 b5b3ac5af0e9bb4745b50f92ea32f21d64b0f0f9 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 66ebb38d832e917ba5e761da232f5826429c2971 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 6ac797d3f55b9ebd56638169623e39d7a0d2a6a4 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 d4297b169d5ca23a7355d80e397b808232e79731 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 0b245e3609a7247e291df057ecb0bb4a46c914af 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 e765826749429cf95bfdfa2679f48649fbe645b4 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 e7d7b75ed16199e8e34d7da7e17fcfe9fcd2bb4b Author: Armaan Sandhu Date: Mon Oct 5 17:39:45 2026 -0400 lib/cmdline: fix get_options() count and overflow with large ranges [ Upstream commit 5d72266218b1c4dd2917f1df2b86f3b0e0a605c9 ] get_range() stops writing once the array is full, but get_options() still advances its index by the whole range. So "1-100" parsed into four ints reports 99 numbers, and a range like "0-2147483647" wraps the index negative and writes outside the array. Stop once a range fills the array, bail out in validation mode before the count overflows, and saturate the range length in get_range(). Add KUnit cases; without the fix "0-2147483647" panics the test kernel. Only root can supply this input, so this is a robustness fix. [akpm@linux-foundation.org: add additional test case from Leizhen] Link: https://lore.kernel.org/20261005213945.359905-1-armaan.sandhu0504@gmail.com Fixes: 22f2e2801799 ("[PATCH] get_options to allow a hypenated range for isolcpus") Signed-off-by: Armaan Sandhu Signed-off-by: Andrew Morton Reported-by: Leizhen Zhang Reviewed-by: Leizhen Zhang Cc: Andy Shevchenko Cc: Signed-off-by: Sasha Levin commit 38c3894b287317b39decc4ff97288e0a1145464e 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 a12657044a3181fa5801ac1f7a55d053594cd0a7 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 32416509150f365bc2d4e59a78061dc8ff02083a 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 1a27709c1ea07fb2a2918b84cf2ffc48834ba171 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 4ba9402fd010cd41893a2b4db3833efbc2e4aff5 Author: Hengyu Liang Date: Thu Oct 15 10:49:34 2026 -0400 exfat: fix reading a directory whose FAT chain is longer than its size [ Upstream commit 8534eb11ac056dc2ca08007cf76d3ae7cbe42684 ] Commit 08cf4a8181b4 ("exfat: use exfat_chain_advance helper") made the directory code walk the clusters of a directory with exfat_chain_advance(). However, exfat_chain_advance() returns -EIO once it has walked as many clusters as the size of the directory says. The FAT chain of a directory can be longer than that, because some cameras stop updating the size, see commit 1e5654de0f51 ("exfat: handle wrong stream entry size in exfat_readdir()"). As of now, opening such a directory fails with EIO as soon as the chain is two clusters longer than the size. Reading a directory that has a FAT chain after a seek past its end fails with EIO too. The issue can be reproduced with an image in which the size of a directory with 200 files and 7 clusters is lowered to 2 clusters: mount -o loop exfat.img /mnt ls /mnt/d | wc -l Before commit 08cf4a8181b4 ("exfat: use exfat_chain_advance helper"), the result is: 200 After that commit, ls fails with "Input/output error" and the result is: 0 This patch will make exfat_chain_advance() follow the FAT to its end when the directory has a FAT chain, as the code did before, and keep the size check for a directory without one. Fixes: 08cf4a8181b4 ("exfat: use exfat_chain_advance helper") Cc: stable@vger.kernel.org Signed-off-by: Hengyu Liang Reviewed-by: Chi Zhiling Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit ea6fbcebee22a96387314341f4b9386873d91e39 Author: Hengyu Liang Date: Mon Oct 12 05:40:46 2026 -0400 exfat: free clusters beyond EOF when a write fails or is short [ Upstream commit b4c282c0d82e8715ea9ed0b35813a3f365e3f952 ] Commit 82a81a7352bc ("exfat: add iomap buffered I/O support") and commit 867b9c96dc83 ("exfat: add iomap direct I/O support") made a write allocate the clusters for its whole range in one step. They also dropped exfat_write_failed(), which freed the clusters beyond the end of the file after a failed or short write. However, a write can stop early, for example when the process is killed or when a part of the buffer cannot be read. As of now, the clusters for the part that was not written stay allocated beyond the end of the file. exfat_cont_expand() does not expect them, so a later write or truncate that extends the file fails with ENOSPC. The directory entry records only the size of the file, so the space can be lost for good once the volume is unmounted. The issue can be reproduced on a 64M volume made by mkfs.exfat and mounted on /mnt, with a write of 1M from a buffer that has only its first 4K mapped: #include #include #include #include #include int main(void) { char *p = mmap(NULL, 8192, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); int fd = open("/mnt/f", O_CREAT | O_WRONLY, 0644); struct stat st; munmap(p + 4096, 4096); printf("write: %zd\n", write(fd, p, 1 << 20)); fstat(fd, &st); printf("blocks: %ld\n", (long)st.st_blocks); printf("ftruncate: %d\n", ftruncate(fd, 1 << 16)); return 0; } Before commit 82a81a7352bc ("exfat: add iomap buffered I/O support"), the result is: write: 4096 blocks: 8 ftruncate: 0 After that commit, the result is: write: 4096 blocks: 2048 ftruncate: -1 This patch will bring back exfat_write_failed() and call it when a write ends before the end of its range, so that the clusters beyond the end of the file are freed again. It waits for direct I/O in flight first, as exfat_setattr() does before it frees clusters. Fixes: 82a81a7352bc ("exfat: add iomap buffered I/O support") Fixes: 867b9c96dc83 ("exfat: add iomap direct I/O support") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Hengyu Liang Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit c071f2bb3887d69ac3416ab9eea2719be990c33e Author: Yuezhang Mo Date: Sat Oct 10 18:12:01 2026 +0800 exfat: mark straddling folio RO and zero the post-EOF range [ Upstream commit 1043264c3cfa43b0668f7472a749868c1e21749b ] When extending a file across a non-page-aligned EOF, the folio containing the old EOF must be marked RO so that subsequent mmap writes trigger ->page_mkwrite() and update valid_size. The straddling folio remains mapped to the same filesystem block after the file is extended. As a result, the existing writable PTE may remain in place, allowing mmap writes to bypass ->page_mkwrite() and leave valid_size unchanged. Furthermore, writes to the post-EOF range may occur between truncate_pagecache() and locking the folio. So the post-EOF range should be zeroed after marking the straddling folio RO, and using truncate_pagecache() to zero out the post-EOF range is redundant. Introduce exfat_pagecache_isize_extended() to mark the straddling folio RO and zero the post-EOF range after clearing writable mapping. This ensures that data written beyond the old EOF before the extension is not exposed as valid file data, and that subsequent mmap writes trigger ->page_mkwrite() to update valid_size. Fixes: 82a81a7352bc ("exfat: add iomap buffered I/O support") Cc: stable@vger.kernel.org Signed-off-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 498931762569638fb9eb1e1fc0120bb98d89e9fa Author: Hengyu Liang Date: Sat Oct 10 00:44:20 2026 -0400 exfat: fix a large buffered write failing when the volume is nearly full [ Upstream commit 73cababf93cb371e2e9d06da5261ca6ddd2404b6 ] Commit 82a81a7352bc ("exfat: add iomap buffered I/O support") made a buffered write map the whole range of the write in one step, so the clusters for all of it are allocated at once. However, exfat_alloc_cluster() returns -ENOSPC when fewer clusters are free than it is asked for. As of now, a write() that is larger than the free space writes nothing and fails with ENOSPC, while it used to write as much as fits and return a short count. The issue can be reproduced with a 16M image made by mkfs.exfat that is filled except for 256K: mount -o loop /img /mnt dd if=/dev/zero of=/mnt/hole bs=256k count=1 dd if=/dev/zero of=/mnt/fill bs=4k rm /mnt/hole dd if=/dev/zero of=/mnt/f bs=1M count=1 wc -c < /mnt/f Before commit 82a81a7352bc ("exfat: add iomap buffered I/O support"), the result is: 262144 After that commit, the result is: 0 This patch will map a single cluster when the clusters for the whole range cannot be allocated, so that the write goes on until the volume is full. Direct I/O is not changed, it still fails without writing as it did before that commit. Fixes: 82a81a7352bc ("exfat: add iomap buffered I/O support") Cc: stable@vger.kernel.org Signed-off-by: Hengyu Liang Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit bdada3fb46d61ec503ea993feb98629a4320c069 Author: Namjae Jeon Date: Tue Oct 6 13:06:39 2026 +0900 exfat: zero invalid tail on partial overwrites [ Upstream commit 748ad4ba13cd14163ed7262c6ac304c380804167 ] Buffered overwrite that ends before valid_size in the same filesystem block reads the entire block without IOMAP_F_ZERO_TAIL. If an existing cluster contains stale bytes beyond valid_size, the synchronous read loads them into the page cache and marks the block uptodate. Subsequent buffered reads can return these bytes while i_size exceeds valid_size. For example, with 512-byte blocks, valid_size of 1000 and i_size of 2048, a cold-cache overwrite of [900, 950) exposes stale data in [1000, 1024). Setting ZERO_TAIL for this write would also erase valid data in [950, 1000). Use iomap_truncate_page() to zero only the invalid tail at valid_size before preparing such buffered overwrites. Call it after dropping s_lock and before iomap locks the write folio. The inode lock held by buffered writes serializes valid_size against truncation and page_mkwrite. Skip direct I/O, fault mappings and new allocations. Writes that reach valid_size continue to use IOMAP_F_ZERO_TAIL. Fixes: 82a81a7352bc ("exfat: add iomap buffered I/O support") Cc: stable@vger.kernel.org Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 5ef4adf964ad0da0b45e876f8b2ea4b4177bd774 Author: Jiale Yao Date: Sat Oct 3 17:30:35 2026 +0800 exfat: drain in-flight DIO before buffered writes [ Upstream commit acea17f0f4c7742118375e96d3f876be34e449a5 ] An asynchronous direct write can remain in flight after the inode lock is released. If a buffered operation dirties page cache while the direct write is still pending, the direct write's post-I/O invalidation can find the dirty pages, report a page cache invalidation failure, and record -EIO in the mapping error sequence. A later fsync() therefore returns -EIO. Commit 15cdefd0c0522f9d5e12d947fa04f4c11649b699 ("ext4: drain in-flight DIO before buffered write fallback") fixed the same race in ext4. ExFAT does not drain in-flight DIO before a regular buffered write, the buffered fallback after iomap_dio_rw() returns -ENOTBLK or a short write, or the page-cache operations used to extend valid_size. Wait for in-flight DIO before these paths can dirty page cache. A reproducer using concurrent AIO direct writes and buffered fallback triggered the following warning and made a subsequent fsync() return -EIO: Page cache invalidation failure on direct I/O. Possible data corruption due to collision with buffered I/O! Fixes: 867b9c96dc83 ("exfat: add iomap direct I/O support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260629113827.4074335-3-libaokun@linux.alibaba.com Signed-off-by: Jiale Yao Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 6192bc0a98ecd97723f3985f71ad3cf6ba0e67c5 Author: Chi Zhiling Date: Sun Oct 4 18:19:33 2026 +0800 exfat: make valid_size and zeroed_size atomic [ Upstream commit 6bb112f5d90a78461648e3bd89093ea299196be5 ] ei->valid_size and ei->zeroed_size are 64-bit fields read from bio completion context (exfat_iomap_read_end_io()) and from ->iomap_begin without i_rwsem, while writers update them under i_rwsem. On 32-bit these loads can tear, and the "if (x < new) x = new" read-modify-write can lose an update or regress the value when two writers race. Convert both to atomic64_t and funnel updates through a cmpxchg-based monotonic advance helper so the value only moves forward; plain reads use exfat_get_*(), and the few shrink/init paths (truncate, inode fill, create) use exfat_set_*(). This is a prerequisite for taking exfat_page_mkwrite() out from under i_rwsem. Fixes: 82a81a7352bc ("exfat: add iomap buffered I/O support") Cc: stable@vger.kernel.org Signed-off-by: Chi Zhiling Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 8f37990a1a23381fab5e101a322b9ee9377858fa Author: Chi Zhiling Date: Sun Oct 4 18:19:32 2026 +0800 exfat: dirty all new pages when extending valid_size [ Upstream commit 03ac97285b699954fa7bc24f8b6cdc1830c94d28 ] In the current code, exfat_zero_new_range() does not mark non-uptodate pages as dirty, which may cause some blocks within a page to not be written back. This commit no longer checks each block in a non-uptodate page individually. Instead, it reads the entire page back into the cache and then writes it back as a whole. This allows concurrent writes and zeroing operations to be synchronized using the folio lock. Fixes: 1135704ed22f ("exfat: fix valid_size extension over a shared writable mapping") Cc: stable@vger.kernel.org Signed-off-by: Chi Zhiling Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 9c8d01c802b8c50ce66518cb85bb140dfbb6fde0 Author: Chi Zhiling Date: Sun Oct 4 18:19:31 2026 +0800 exfat: hold the invalidate lock while truncating [ Upstream commit 646df471c37483eb31548d76a1b062775db71d60 ] truncate_setsize() ends in truncate_inode_pages(), which is documented as being "Called under (and serialised by) inode->i_rwsem and mapping->invalidate_lock". Hold invalidate_lock while executing truncate_setsize() to ensure that truncate and mmap writes are mutually exclusive. This can simplify the handling in exfat_page_mkwrite(). Fixes: 82a81a7352bc ("exfat: add iomap buffered I/O support") Cc: stable@vger.kernel.org Signed-off-by: Chi Zhiling Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 8aecb67c8a89f68bb49dc8407b5d932ee36a565b Author: Chi Zhiling Date: Sun Oct 4 18:19:30 2026 +0800 exfat: advance valid_size to EOF for append writes [ Upstream commit b70ab407503706289163dd59f1ac3e942bacc37d ] For an append write, the write position is recalculated by generic_write_checks(). Therefore, the write position must be obtained after generic_write_checks() returns. Using the original write position to advance valid_size may cause the valid_size update to be skipped, potentially exposing stale data. Also move the truncate_pagecache() check below the recalculated position, so that pos is never read before it is assigned. Fixes: 11a347fb6cef ("exfat: change to get file size from DataLength") Cc: stable@vger.kernel.org Signed-off-by: Chi Zhiling Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit bf71eb3b19d12d21b3a0e2eed1a7782b270335f5 Author: Til Kaiser Date: Wed Oct 14 19:31:17 2026 +0200 mlxsw: Initialize register query payloads [ Upstream commit 15b7a86a8888dc6a8fd19e181757e32389de9064 ] MFGD register queries can exhaust EMAD retries and leave Mellanox Spectrum switches stuck during boot or shutdown when running OpenWrt built with GCC 15. An example failure is shown below with the second line wrapped: EMAD retries (5/5) (tid=9b544fc100001f35) EMAD reg access failed (tid=9b544fc100001f35,reg_id=90f0(mfgd), type=query,status=0(operation performed)) On an SN2100, the failure occurs during driver teardown on reboot. On an SN3420, it occurs while probing mlxsw_spectrum during boot. The register query API transmits the supplied payload to the device before replacing it with the response. Both MFGD callers pass an uninitialized stack buffer, so the request contains arbitrary register field values and reserved bits. This makes the request depend on stack contents and compiler code generation. Initialize both MFGD query buffers in the firmware fatal event configuration and reporter test paths. The initialization has been confirmed to eliminate the boot and shutdown hangs on both switches. The subsequent read-modify-write still preserves the other fields returned by the device. Also initialize the FORE fan fault query and the MOGCR mirroring policer base query, which pass entirely uninitialized payloads. Restore the MTMP query initialization in the temperature history reset path, where only the slot and sensor index fields are set before querying the register. This follows commit 5b0907407e7f ("mlxsw: core: Zero payload buffers for couple of registers"), which initialized other query payloads after a firmware field length bug caused firmware to consume uninitialized data. Tested with firmware 2020.1148 and with 2016.3900 from linux-firmware. Fixes: 7d83ee111008 ("mlxsw: core: Introduce fw_fatal health reporter") Fixes: 2c6a33cd334b ("mlxsw: core: Extend hwmon interface with fan fault attribute") Fixes: 4039504e6a0c ("mlxsw: spectrum_span: Allow setting policer on a SPAN agent") Fixes: b890ad418e1f ("mlxsw: core_hwmon: Extend internal structures to support multi hwmon objects") Cc: stable@vger.kernel.org Signed-off-by: Til Kaiser Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20261014173117.26305-1-mail@tk154.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2e40fd8049527db15a0a32ca8ac7f430ef90be46 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 cae22ada1f145191866678c675eb511edc4ef4b5 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 a41b466056626b2fb24186d8c6ec1fbff2132ddd 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 d0626a2bbc00f42bb4a49fb47e38973660c12566 Author: Yao Yiqi Date: Mon Oct 19 17:43:31 2026 +0800 fbcon: Retry rotated font allocation after failure [ Upstream commit 7935db1a4a0f83a63590a222500e5016e2f6c85e ] fbcon_rotate_font() records the font, its geometry and the rotation in par->rotated before calling font_data_rotate(). If the allocation fails, the error path clears par->rotated.buf, but the recorded key already looks up to date, so the next call takes the early-out and never retries. The rotated putcs/cursor ops keep returning early on the NULL buffer, and the console stays blank even after memory is available again. Also test par->rotated.buf in the early-out, so a failed allocation is retried on the next call: at the next fbcon_switch(), fbcon_modechanged() or font change. Fixes: e4ef723d8975 ("fbcon: Avoid OOB font access if console rotation fails") Cc: stable@vger.kernel.org Signed-off-by: Yao Yiqi Acked-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit e1f7e1f9e7399c2d3d6fe8ba57608e0c157dbe69 Author: Yao Yiqi Date: Mon Oct 19 17:43:30 2026 +0800 fbcon: Rebuild rotated font buffer on font change [ Upstream commit e4b6b865d45d8dafb6c6f28c8a993a5b4431d25a ] fbcon_rotate_font() caches a rotated copy of the console font in par->rotated.buf. The buffer is sized from the font's width, height and charcount, and is rebuilt in fbcon_init(), fbcon_switch() and fbcon_modechanged(), but not in fbcon_do_set_font(). When the font is changed through KDFONTOP, the new geometry is installed and vc_resize() redraws before the buffer is rebuilt. The rotated putcs/cursor ops then index the old buffer with the new cell size; KASAN reports a slab-out-of-bounds read in soft_cursor(). Rebuild the buffer for the visible console before the redraw, as the other callers do: select the console's blitting state with set_blitting_type() (which also uploads the new font's map on tile-blitting hardware), then rebuild. Background consoles keep their rebuild at fbcon_switch() time, as the buffer is shared per framebuffer and must not be updated for a console that is not being displayed. To ensure a correct rollback when the rebuild or the following vc_resize() fails, save the rotated font state, clear it before rebuilding, and restore it in the error path of fbcon_do_set_font(). Fixes: 6cc50e1c5b57 ("[PATCH] fbcon: Console Rotation - Add support to rotate font bitmap") Cc: stable@vger.kernel.org Signed-off-by: Yao Yiqi Acked-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit e19f246141af0c3f4d6f0b267793f39723413199 Author: Yao Yiqi Date: Mon Oct 19 17:43:29 2026 +0800 fbcon: Include font geometry in the rotated font cache [ Upstream commit 10463bcd43495fb88ff667b2c5348200860f6bdc ] fbcon_rotate_font() caches a rotated copy of the console font and skips the rebuild when the fontdata pointer and the rotation match. Raw font data carries no geometry, though: width, height and charcount live in vc->vc_font. fbcon_set_font() deduplicates uploads by byte equality, so the same bytes re-uploaded with different dimensions keep the fontdata pointer while the geometry changes, and the early-out skips the rebuild. The rotated cell size depends on the geometry (rotation swaps width and height), so the stale buffer is indexed with the new cell size. Re-uploading a 4x16 font as 16x8 on a CW-rotated console, for example, doubles the rotated cell size and reads past the end of the old buffer. Record the geometry the buffer was built from and compare it in the early-out. The pointer-only key used to be backed by an explicit width check in the deduplication, which commit 1e3c49aa03fb ("lib/fonts: Compare font data for equality with font_data_is_equal()") dropped. Fixes: 6cc50e1c5b57 ("[PATCH] fbcon: Console Rotation - Add support to rotate font bitmap") Cc: stable@vger.kernel.org Signed-off-by: Yao Yiqi Acked-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit e5e13dd6dc04789de2986fd6fecf99876271d789 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 6c90b7568b4178250ee3c4a853ffb4f0831ddc04 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 d4e3ab19ddd232850ad6a28fa95a6501be2373a1 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 65dc6b153b65f094697123befb78554ecd33b54c 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 310a2a825a9166b58578dd2ae4e63392b068b0f3 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 964b693376ff329071575dadd9dd531d989d12e5 Author: Kees Cook Date: Thu Oct 15 10:00:03 2026 -0700 netdev: Hide the netdev_priv() origin from GCC in netdev_from_priv() [ Upstream commit 56f8d919739b588e2ad8cb9fb9eff704f32afaab ] GCC 15.1 and later can compute an object size of 0 for a pointer that container_of() derives from a pointer into a __counted_by flexible array member[1]; Clang gets it right. netdev_from_priv() does this with struct net_device's "priv" array, so when GCC can see that its argument came from netdev_priv(), FORTIFY_SOURCE sees a zero-sized net_device. Since commit 9027497a25e3c ("team: use netdev_from_priv()"), adding a port of another type to a team device can then fail the memcpy() to "dev->broadcast" in team_setup_by_port(), which GCC sees through after inlining team_port_add() into team_add_slave(): memcpy: detected buffer overflow: 4 byte write of buffer size 0 ... kernel BUG at lib/string_helpers.c:1044! ... Call Trace: team_add_slave.cold+0x88/0x201 do_set_master+0x11c/0x180 do_setlink.isra.0+0x3a4/0x1410 Whether GCC inlines that far depends on the architecture and the configuration. It does on ppc64le, where this was reported, and on x86_64 with defconfig plus hardening.config or with Debian's configuration, but not with allmodconfig. Hide where "priv" came from with OPTIMIZER_HIDE_VAR(), so GCC sees a net_device of unknown size whose members have their declared sizes. (An "unknown" size is considered uncheckable by FORTIFY.) FORTIFY still bounds writes to members; only the whole-object size becomes unknown, as it already is for any net_device pointer GCC can't trace to its allocation. In an extracted PoC, the __builtin_dynamic_object_size() of "dev->broadcast" for the two types FORTIFY sees, before and after this patch: GCC 16.2.0 Clang 22 and 24 before after plain pointer, whole object unknown unknown 44 container_of(), whole object 0 unknown 44 container_of(), member 0 32 32 In addition to getting the bogus "0" fixed in GCC, I'll be following up to solve the whole-object visiblity disparity as well. Build tested with GCC 16.2.0: ARCH=x86_64 defconfig with hardening.config, CONFIG_NET_TEAM=y, and CONFIG_NET_IPGRE=y; ARCH=arm64 defconfig with hardening.config, CONFIG_NET_TEAM=y, CONFIG_PPP=y, and CONFIG_NET_AIROHA=m; and drivers/net/team/, drivers/net/ppp/, and drivers/net/ethernet/airoha/ in ARCH=x86_64 allmodconfig. Under QEMU, the x86_64 kernel hits the BUG above when adding the GRE fallback device "gre0" as a port of a new team device without this patch, and adds it with the patch. Reported-by: Yeswanth Krishna Tellakula Closes: https://lore.kernel.org/all/3ad19e86-234c-408f-896e-0d6c774fea49@linux.ibm.com/ Fixes: 9027497a25e3c ("team: use netdev_from_priv()") Cc: stable@vger.kernel.org Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127875 [1] Signed-off-by: Kees Cook Link: https://patch.msgid.link/20261015165959.i.798-kees@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 677ecf5c4a940a898030c607c91ec65c068f6a79 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 e6a0acabf6c18881ba1098f88dea037ff9cf4611 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 3ae32ed4d83e780fb548a1eb84f407f4d786ce3c Author: Kenneth Feng Date: Fri Oct 16 15:17:43 2026 +0800 drm/amd/pm:restate all customized OD features on every table upload for smu 13.0.0/smu 14.0.2 [ Upstream commit 44d0d3031e47973ed65fd327669d5e2eaaf6c565 ] PMFW interprets OverDriveTable.FeatureCtrlMask as the complete set of overdrive features that are currently overridden, not as a delta describing the operation at hand. On import it resets every feature whose bit is clear back to its default value - for the VF curve that means zeroing VoltageOffsetPerZoneBoundary[] outright. The driver assumed the opposite. smu_v14_0_2_od_edit_dpm_table() clears the mask after a successful commit, so a subsequent above-default power1_cap write goes through smu_v14_0_2_set_ppt_limit() and uploads a table carrying only PP_OD_FEATURE_PPT_BIT. PMFW then drops the user's voltage offset and reverts to the stock V/F curve, while the driver's cached user table still reports the offset through pp_od_clk_voltage. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5935 Signed-off-by: Kenneth Feng Reviewed-by: Kevin Wang Signed-off-by: Alex Deucher (cherry picked from commit 1b63bb397db208a8f84778a9d9cafc93da9373eb) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit eb8cfa911806bd379949271335ef8246f89d330f 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 96da420b053ba050e4e43c3e54d469043c35f73d 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 dbe6b6663634b9ecaa50c17914de183fcad5a208 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 fedc363a2b6796cc27efc4e2a06a719ef0e8fe4a 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 b01c68b7f1ec75af84d9d62ea61cf1202cd8952e Author: Harish Kasiviswanathan Date: Mon Aug 31 18:09:12 2026 -0400 drm/amdkfd: fix NULL deref in SDMA HQD debugfs dump on GC 12.1 [ Upstream commit 0fe236afa2b9b28540fa1f8c789ef5d499c5d0ee ] Reading the KFD HQD debugfs node (dqm_debugfs_hqds) on a gc_12_1_0 part oopses with a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: hqd_sdma_dump_v12_1+0x6a [amdgpu] Call Trace: dqm_debugfs_hqds+0x2da/0x360 [amdgpu] kfd_debugfs_hqds_by_device+0x74/0xa0 [amdgpu] seq_read ... __x64_sys_read get_sdma_rlc_reg_offset() assumes an interleaved layout where the second SDMA per XCC lives in a separate SDMA1_HWIP register aperture. On gc_12_1_0 that aperture does not exist. Rewrite get_sdma_rlc_reg_offset() to mirror sdma_v7_1_get_reg_offset(): base the offset on adev->reg_offset[GC_HWIP][xcc_id][0] and add the per-instance SDMA1 offset for the odd instance. Fixes: 7bd5d763b8e1 ("drm/amdkfd: Add gfx_v12_1_kfd2kgd interface for GFX12_1") Signed-off-by: Harish Kasiviswanathan Reviewed-by: Mukul Joshi Signed-off-by: Alex Deucher (cherry picked from commit 94b2c5b06d37adc0e9a23138252758657b64b58a) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 861337bf1a6a0fb64daffdfbc5bb165c1d6ce3aa 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 f7022f6de3133963a464d68839f33f25e2467a38 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 6555c8d7b2a070a07d3d94c992748b24590e5ebc 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 bbfdf51b12908be615287a7fab5bead8cade346a 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 84d62591d343e1aa2c045cf4c5f079eee4500da7 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 cebd4f1c3870ae18b271372661220155d4d178d2 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 5464462de927726e844f0e6d93b35358d834f89c 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 291d1ff1745400c09ec6d025877545ed94417edc 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 2b0762c47cce8529f794263138c5633c7fea7338 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 d4f7d5aeb0913d7842b171a45ae69a3fe5e3f8cb Author: Daeho Jeong Date: Thu Oct 15 16:17:14 2026 +0000 f2fs: don't use truncate_inode_pages_final() on live inodes [ Upstream commit 74bbd6ada01f91fcad60608e0417bf45a9fa99e6 ] truncate_inode_pages_final() is meant to be called from ->evict_inode. It sets AS_EXITING on the mapping, and nothing ever clears it, to tell the VM that the inode is going away. f2fs calls it in two places where the inode stays live: - F2FS_IOC_START_ATOMIC_REPLACE uses it to drop the page cache of the original inode before setting i_size to 0. The atomic write then goes on through this inode. - f2fs_abort_atomic_write() uses it to drop the uncommitted data. It is called on eviction, but also on the last writer's close in f2fs_release_file(), from f2fs_file_flush() when the atomic writer exits, from F2FS_IOC_ABORT_ATOMIC_WRITE and when F2FS_IOC_COMMIT_ATOMIC_WRITE fails. Other processes may still have the file open or mapped in all of these cases. The mapping then stays marked as exiting for as long as the inode is in memory. This stops reclaim from storing workingset shadow entries for it and breaks any code that assumes an exiting mapping has no users left. All we need in both places is to drop the page cache, so use truncate_inode_pages(mapping, 0) instead. The eviction path is not affected, because f2fs_pre_evict_inode() still calls truncate_inode_pages_final() after f2fs_abort_atomic_write(). Cc: stable@kernel.org Fixes: 3db1de0e582c ("f2fs: change the current atomic write way") Fixes: 41e8f85a75fc ("f2fs: introduce F2FS_IOC_START_ATOMIC_REPLACE") Signed-off-by: Daeho Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 8cd2d8c0a98b55c7beba2b79c6824335bf314311 Author: Wang Yan Date: Fri Jun 26 15:00:16 2026 +0800 selftests/landlock: Fix snprintf truncation checks in test files [ Upstream commit 8e4c736cffdd6b133f6498e0d40ba60dc6819d43 ] Commit b566f7a4f0e4 ("selftests/landlock: Fix snprintf truncation checks in audit helpers") fixed the truncation detection in audit.h by changing the comparison from ">" to ">=" to correctly handle the edge case where snprintf returns a value equal to the buffer size. However, the same pattern exists in ptrace_test.c, audit_test.c, and net_test.c and was not fixed. snprintf() returns the number of characters that would have been written, excluding the terminating NUL byte. When the output is truncated, this return value equals or exceeds the buffer size. The existing ">" check therefore fails to detect truncation when the return value equals the buffer size. Fix these remaining instances to use ">=" for truncation detection, matching the fix in audit.h. Fixes: 6a500b22971c ("selftests/landlock: Add tests for audit flags and domain IDs") Signed-off-by: Haofeng Li Signed-off-by: Wang Yan Reviewed-by: Günther Noack Link: https://patch.msgid.link/20260626070016.61049-1-wangyan01@kylinos.cn Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin commit 70e33cc6ae56d93818464e0c01767d7683c8ae8e 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 6f16dd733d54ef78973d31bc1cd64730319fbcc3 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 6aeb8ae969319217318dbf84a50e7da2123b4ff1 Author: Sahaj Chaudhari Date: Sun Oct 18 21:40:42 2026 +0530 gpio: pca953x: Preserve wakeup accounting on parent IRQ failure [ Upstream commit a38bf551726a21c9bcc001b02164f30378b64b64 ] pca953x_irq_set_wake() updates wakeup_path before asking the parent IRQ controller to change its wake state. If irq_set_irq_wake() fails, the IRQ core rolls back its wake state but the driver's counter remains changed. A failed enable can therefore leave the expander marked as part of the wakeup path when no child IRQ has successfully enabled wakeup. A failed disable can make the driver stop retaining power even though wakeup is still enabled. The suspend and resume paths use this counter to decide whether to disable or enable the regulator. Update wakeup_path only after the parent operation succeeds, leaving it unchanged on error. Fixes: f70fbc15bae2 ("gpio: pca953x: Configure wake-up path when wake-up is enabled") Cc: stable@vger.kernel.org Signed-off-by: Sahaj Chaudhari Fixes: f70fbc15bae2c89f ("gpio: pca953x: Configure wake-up path when wake-up is enabled") Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20261018161042.3298045-1-sahaj123.sc@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit cb6078432fab2027037756206e69e100ecdab4ca 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 43baee8a998b405470055013eded21a67b916e47 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 63f3307bc2901fc5a149027de718c0a78a92554f 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 b3538947880c1fb51334288f05229e29e9088e9d Author: Rong Zhang Date: Mon Oct 19 23:02:24 2026 +0800 platform/x86: lenovo-wmi-capdata: Do not stop the AC notifier chain on error [ Upstream commit 3b53e691e907086672b72d0544e4bf27efd4250d ] Returning NOTIFY_BAD to the AC notifier chain stops it by preventing later notifier blocks from being called, but our error is non-fatal for other AC notifier blocks, which should continue to consume the event. Return NOTIFY_DONE and add a dev_warn() on error, so that the AC notifier chain continues. This also aligns with hp-wmi. The function documentation was copied from elsewhere and makes no sense here, so correct it as well. Fixes: e1a5fe662b59 ("platform/x86: Add Lenovo Capability Data 01 WMI Driver") Cc: stable@vger.kernel.org Tested-by: Navon John Lukose Reviewed-by: Derek J. Clark Reviewed-by: Mark Pearson Signed-off-by: Rong Zhang Link: https://patch.msgid.link/20261019-lwmi-wmi-new-api-v5-2-71557d28d058@rong.moe Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 16a74918f183297579e35d5de66ce5f426023bb6 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 c0634d1a159121a617fab26e9b220c5b796b9f0b 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 bcc90f9fe12a2fb777262cfaa581fd73dee33592 Author: Hongling Zeng Date: Tue Oct 13 09:56:52 2026 +0800 ntfs: roll back the ACL xattr commit when the WSL mode update fails [ Upstream commit 89467388e8afc6b55ea7cd38bc1f469df7747db0 ] ntfs_set_acl_ex() commits the ACL xattr before it rewrites the WSL mode EA, and removes it again when the rewrite fails. That only undoes a set that created the xattr: when the update replaced or removed an existing one, the old ACL is discarded along with the failed update. No error is recorded when the undo fails, so the new, typically more permissive, ACL is left on disk while i_mode, the mode EA and the cached ACL keep the old values. After a remount, a chmod 0640 -> 0777 that reported failure leaves the file accessible to the relaxed ACL while stat() still reports 0640. Save the previous xattr before committing the update, and restore it when the mode EA rewrite fails. A removed xattr is created again, since XATTR_REPLACE fails with -ENODATA once the removal dropped the entry. Remove the new xattr only when there was no previous one, and skip the undo when the commit changed nothing. A failed rollback is recorded: NVolSetErrors(), which the next persistence point persists as VOLUME_IS_DIRTY, and a log message the errors= policy acts on. The flag cannot be written to disk here directly: the target inode's mrec_lock is held and the $Volume mrec_lock cannot be nested under it. Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Cc: stable@vger.kernel.org Suggested-by: Hyunchul Lee Signed-off-by: Hongling Zeng Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 4858bf00a628acf1911966470b3d243502e69382 Author: DaeMyung Kang Date: Tue Oct 13 23:58:46 2026 +0900 ntfs: flush the block device when syncing a directory [ Upstream commit 569f514f0ec74c4162241e10b7893bff109f8aca ] ntfs_dir_fsync() writes directory metadata and calls sync_blockdev(), but does not flush the block device write cache. A successful fsync() can therefore leave the directory's metadata in a volatile device cache. Issue a cache flush after successful writeback and return any flush error. This matches the regular-file fsync and syncfs paths. With QEMU blkdebug injecting -EIO for flush_to_disk, fsync() on an NTFS directory returned 0 before this change while syncfs() returned -EIO. After this change, both return -EIO. A kretprobe confirmed the flush error in the directory fsync path. Fixes: 1e9ea7e04472 ("Revert "fs: Remove NTFS classic"") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 656ba7ff3757620bf3caefae4ff98cbf926b673c Author: DaeMyung Kang Date: Tue Oct 13 23:58:45 2026 +0900 ntfs: report block device flush failures from fsync [ Upstream commit 9b32a74f4ef52d26d68ceb3f5e492d5eac26f5fc ] ntfs_file_fsync() calls blkdev_issue_flush() after writeback but discards its return value. If the device cannot flush its write cache, fsync() reports success even though the file is not guaranteed to be durable. Reproduce this with QEMU blkdebug failing flush_to_disk with -EIO. On ntfs-next at 04fb910da2c8, a kretprobe recorded -EIO from blkdev_issue_flush() while fsync() returned 0. With this change, fsync() returns -EIO and logs the failure. The syncfs() path already reports this error. Fixes: 9c87959601e8 ("ntfs: update file operations") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit f45b6993d70d5eda419f1a95534d5a6b2c86954f Author: Karl Mehltretter Date: Tue Oct 6 06:51:36 2026 +0200 ntfs: fix kmap_local leak in ntfs_check_logfile() [ Upstream commit a5ec71084996aec76d07e0e530a345cdd202dc1a ] ntfs_check_logfile() calls kmap_local_folio() on every iteration of its search loop but kunmap_local() only once per folio. The loop visits positions 0, 512, 1024, 2048, 4096 and so on. With 4 KiB pages the first four are in one page, so a mount whose first LogFile folio is in highmem leaves three entries on the kmap_local stack of the mounting task. Kernels without HIGHMEM are not affected. The leaked entries keep migration disabled. nr_pinned of the runqueue the mount ran on stays raised after the task exits, so taking that CPU offline blocks forever in balance_hotplug_wait(). The fifth mount in one task reaches KM_MAX_IDX (12 leaked entries plus 4 in the loop) and hits the BUG_ON() in kmap_local_idx_push(): kernel BUG at mm/highmem.c:480! On x86-32 the generic entry code also warns on return to user space: DEBUG_LOCKS_WARN_ON(current->kmap_ctrl.idx) WARNING: include/linux/highmem-internal.h:17 at __do_fast_syscall_32+0x21e/0x550 Map each page once, when it is read, and unmap that address. Fixes: 5218cd102aec ("ntfs: update misc operations") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit a441c72351cc38b98ee7a099793a225d16924f4a Author: Karl Mehltretter Date: Tue Oct 6 06:51:35 2026 +0200 ntfs: fix kunmap_local() of advanced pointers in check_mft_mirror() [ Upstream commit 16fcb1c446f17c11c104bd4e631b841946d180aa ] check_mft_mirror() compares the mft records of a page with the mirror records by advancing kmft and kmirr by the record size for every record. It then passes the advanced pointers to kunmap_local(). After the last record of a page they point one page past the mapping. With HIGHMEM kunmap_local() warns that the address does not match the top of the kmap_local stack. What it does next depends on how the architecture finds the page table entry: - 32-bit ARM looks the entry up by that address. It clears the entry of the neighbouring fixmap slot and leaves the real mapping in place. The next kmap_local() on that CPU that reaches the slot hits the BUG_ON(!pte_none()) in __kmap_local_pfn_prot(). - x86-32 takes the entry from the stack index, so the wrong address does not select a wrong entry. In QEMU the mount carried on after the warning. With 4 KiB pages and 1 KiB mft records the four mirror records fill exactly one page, so every mount whose $MFT and $MFTMirr folios are in highmem hits it. A fresh mkntfs volume on 32-bit ARM (multi_v7_defconfig, 256 MiB of highmem) fails on the first mount: WARNING: mm/highmem.c:623 at kunmap_local_indexed+0x254/0x26c, CPU#1: mount/85 kunmap_local_indexed from ntfs_fill_super+0x224c/0x35a0 ntfs_fill_super from get_tree_bdev_flags+0x1d8/0x2a4 ntfs: volume version 3.1, dev loop0, cluster size 4096 kernel BUG at mm/highmem.c:565! PC is at __kmap_local_pfn_prot+0x210/0x214 __kmap_local_page_prot from ntfs_check_logfile+0x1fc/0x1210 Found with syzkaller. Kernels without HIGHMEM do not show it. kmap_local_folio() returns the direct map address there and kunmap_local() has no mapping to remove. Keep the addresses returned by kmap_local_folio() and unmap with those. Fixes: 6251f0b0de7d ("ntfs: update super block operations") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 68879bf28ba6e48d9c07edac49ad62e1f820b5a6 Author: Matthias Goergens Date: Fri Oct 2 12:34:59 2026 +0800 ntfs: balance the $MFT runlist lock in data extension error paths [ Upstream commit 69ba74e8a5dfc6fd7ba3588e81d53e965566f3a4 ] ntfs_mft_data_extend_allocation_nolock() drops the $MFT runlist lock before allocating clusters, and every path into undo_alloc arrives without it, except a map_mft_record() failure, which takes it first. undo_alloc never releases it, so the lock leaks and the next $MFT extension and $MFT writeback hang. The restore_undo_alloc failure path, on the other hand, releases the lock without holding it. And undo_alloc frees the clusters with ntfs_cluster_free() and truncates the runlist without the lock, although both require it. Enter undo_alloc without the lock on every path. Merge the new clusters with ntfs_runlists_merge_keep_src() and keep the runlist that ntfs_cluster_alloc() returned until the extension is complete. On failure, undo_alloc truncates $MFT's runlist under the lock and, after dropping it, frees the clusters from the kept runlist with ntfs_cluster_free_from_rl(). That keeps lcnbmp_lock outside the runlist lock, the order given by the comment before the cluster allocation. Unlike ntfs_cluster_free() on a volume mounted with -o discard, this does not issue discards for the clusters, which were never written; the runlist merge failure path already frees them the same way. If the truncation fails, the runlist may still reference the clusters, so they stay allocated and the volume is marked for chkdsk; at this call site the truncation only shrinks the runlist and cannot fail today. A shorter fix would keep calling ntfs_cluster_free() on the live runlist without the lock, relying on $MFT's runlist being fully mapped and changed only by this function under mrec_lock. That breaks ntfs_cluster_free()'s documented locking rule on an argument about the rest of the driver, so this patch does not do that. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Cc: stable@vger.kernel.org Signed-off-by: Matthias Goergens Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 0b81032b9273a895d8c093cbb08fef8024ac3128 Author: Matthias Goergens Date: Fri Oct 2 12:34:58 2026 +0800 ntfs: add a runlist merge that leaves the source runlist to the caller [ Upstream commit c6ee0986b80715c44d547e9cbdc1a72ad855071c ] ntfs_runlists_merge() frees the source runlist once its runs are in the destination. A caller that may have to undo the merge then has to work out its runs again from the merged runlist, where the first and the last of them may have been coalesced with neighbouring runs. Add ntfs_runlists_merge_keep_src(), which neither modifies nor frees the source runlist. For that, ntfs_rl_append() and ntfs_rl_replace() now merge the right-hand end into the copied run in the destination instead of into the last source run before copying it, and the merge helpers take the source as const, so the compiler checks that none of them writes to it. The merged runlist is the same as before. For every caller, a source runlist without any mapped run, which the merge already warns about, now fails with -EINVAL instead of carrying on with nothing to insert: with no run copied, the right-hand merge into the destination would index before the insertion point. The next patch uses ntfs_runlists_merge_keep_src() to free exactly the clusters it allocated when it has to undo an $MFT data extension. Suggested-by: Hyunchul Lee Cc: stable@vger.kernel.org # needed by the next patch Signed-off-by: Matthias Goergens Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 387a7e579d841ff45b3010edc91d8bc043f0ffd5 Author: Matthias Goergens Date: Fri Oct 2 12:34:57 2026 +0800 ntfs: do not use a stale runlist pointer when undoing $MFT extension [ Upstream commit 258239e79b842e5246fb7f50758d9d15430f4102 ] When ntfs_mft_data_extend_allocation_nolock() fails after it has rebuilt the mapping pairs of the last $MFT data extent, undo_alloc truncates the runlist and then rebuilds the old mapping pairs from rl2, a pointer into the runlist taken before the truncation. ntfs_rl_truncate_nolock() can reallocate the runlist, and KASAN then reports a use-after-free in ntfs_mapping_pairs_build(). Pass the start of the runlist instead, and hold the runlist lock for reading while the mapping pairs are built from it. ntfs_mapping_pairs_build() skips to the element containing the first vcn by itself. Fixes: 1e9ea7e04472 ("Revert "fs: Remove NTFS classic"") Cc: stable@vger.kernel.org Reviewed-by: Baolin Liu Signed-off-by: Matthias Goergens Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit bebc7db05867fd84349843df5c650054f580044c Author: Matthias Goergens Date: Thu Oct 1 23:05:58 2026 +0800 ntfs: hold the runlist lock while expanding a non-resident attribute [ Upstream commit 768c6f5fab58cefa65509dd34b946fdd1071746e ] ntfs_non_resident_attr_expand() changes ni->runlist.rl while it allocates clusters: ntfs_attr_map_whole_runlist(), the compressed branch's ntfs_rl_realloc() and ntfs_runlists_merge() can each kvfree() the old array. Unless the caller already holds ni->runlist.lock, none of this happens under it; only the rollback takes it. Callers without it include the write path, fallocate, ntfs_inode_attr_pwrite() and ntfs_resident_attr_resize(). Those callers hold mrec_lock, and the write path also inode_lock, but the iomap read side takes neither: FIEMAP, page faults, readahead and splice read reach ntfs_read_iomap_begin_non_resident(), which takes only ni->runlist.lock. A FIEMAP running while write(2) extends the same file can walk the array that ntfs_runlists_merge() has just freed: BUG: KASAN: slab-use-after-free in ntfs_attr_vcn_to_rl+0x19b/0x200 A reader that finds a vcn unmapped in the stale array also maps it from disk into the runlist the writer is changing, which shows up as "Run lists overlap. Cannot merge!". Take ni->runlist.lock for writing around the part of the expansion that changes the runlist and allocated_size, up to and including the mapping pairs update, as ntfs_non_resident_attr_shrink() does since commit 91709ba5d6d7 ("ntfs: protect runlist updates with the runlist lock"), and hold it throughout the rollback, where ntfs_cluster_free() requires it. The lock nests inside mrec_lock, as on the truncate-up path, which already calls this function with the runlist lock held. Where the caller says it holds the lock (locked_ni == ni), assert that it holds it for writing. For an $ATTRIBUTE_LIST whose lock the caller does not hold, drop the lock again before the mapping pairs update: that update can resize the same list through ntfs_attrlist_update_locked(), which returns -ENOSPC when told that the list's lock is held. Holding it there made punching holes into a large fragmented file fail with -ENOSPC. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Cc: stable@vger.kernel.org Signed-off-by: Matthias Goergens Reviewed-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 6aa650510f6607b6df8b0626f6370ca47da68eee Author: Matthias Goergens Date: Wed Sep 30 11:48:34 2026 +0800 ntfs: fail the mount when $MFT's data size exceeds its allocation [ Upstream commit 82a5e003ef09113c10b791d687297ef455bb1552 ] ntfs_read_inode_mount() takes $MFT's i_size from data_size without checking it against allocated_size, unlike the resident case in ntfs_read_locked_inode(). mft records between the two are not on disk. On a crafted volume with 512-byte clusters whose $MFT is cut to 4 clusters while data_size still says 27 records, reading the folio holding records 0-3 finds the end of the runlist at vcn 4. An unpatched kernel hangs there on the folio lock, as in "ntfs: fail the mount when $MFT needs its own extent records". With the previous patch vcn 4-7 are past the allocation and so read as a hole: records 2 and 3 come back as zeros and the mount carries on until check_mft_mirror() finds the zeroed record 2. Refuse such a $MFT before anything is read through it. The mount now fails with: ntfs: (device vda): ntfs_read_inode_mount(): $MFT data size 27648 exceeds its allocated size 2048. $MFT is corrupt. Run chkdsk. fs/ntfs3 rejects any non-resident attribute whose data_size exceeds its allocated size. This patch checks only $MFT; the next one covers the other non-resident attributes. Fixes: b041ca562526 ("ntfs: update iomap and address space operations") Cc: stable@vger.kernel.org Signed-off-by: Matthias Goergens Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit ce91fe5137a448d6ed0debb7493ff5a32d3bd5eb Author: Matthias Goergens Date: Wed Sep 30 11:48:33 2026 +0800 ntfs: do not map a vcn as a hole when its runlist lookup failed [ Upstream commit e727ea7fc4e36b3d14b7bb304e82918aa6e2024a ] ntfs_attr_vcn_to_rl() retries ntfs_map_runlist_nolock() for any lcn up to LCN_RL_NOT_MAPPED, which includes LCN_ENOENT, but turns a failed retry into an error only for LCN_RL_NOT_MAPPED. For LCN_ENOENT the error is dropped and the read path maps the range as a hole. An LCN_ENOENT below allocated_size comes from a base extent with a highest_vcn of 0, which ntfs_mapping_pairs_decompress() takes to map the whole attribute, so the runlist ends after its last mapping pair. If the pairs end early, the retry finds the same extent and fails with -ENOENT. On a crafted volume with 4 KiB clusters, a 64-cluster file whose mapping pairs stop after 16 clusters reads 48 clusters of zeros, with no error. The same layout gets a crafted $MFT past the check from "ntfs: fail the mount when $MFT needs its own extent records". With 512-byte clusters and $MFT's mapping pairs ending at vcn 4, an unpatched kernel hangs on the folio lock reading records 0-3. With the check alone, the -EIO is dropped, records 2 and 3 read as zeros and the mount carries on until check_mft_mirror() finds the zeroed record 2. Fail the lookup whenever the retry leaves @vcn unmapped below allocated_size, -ENOENT included. At or beyond allocated_size the end of the runlist is still returned as it is. A failed expansion in ntfs_non_resident_attr_expand() or ntfs_attrlist_repack() truncates the runlist under the runlist lock but restores allocated_size only after dropping it. A lookup in between would now fail, so restore allocated_size before dropping the lock in both, under size_lock, which ntfs_attr_vcn_to_rl() takes to read it. The crafted file now fails from vcn 16 on with -EIO, and the crafted volume fails to mount with the check's message. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Cc: stable@vger.kernel.org Signed-off-by: Matthias Goergens Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit ccdb67f6bd08242bf98002db6a98e2efc7228ff3 Author: Matthias Goergens Date: Wed Sep 30 11:48:32 2026 +0800 ntfs: fail the mount when $MFT needs its own extent records [ Upstream commit 5562eaecdaf9deb3f750441c95a5f2c440b3293b ] Mounting a crafted image hangs the mount process forever, unkillable at 0% CPU. Only the hung-task detector reports it: INFO: task mount:74 blocked in I/O wait for more than 30 seconds. folio_wait_bit_common <- waits forever filemap_read_folio map_mft_record_folio map_mft_record ntfs_map_runlist_nolock ntfs_attr_vcn_to_rl __ntfs_read_iomap_begin iomap_read_folio ntfs_read_folio <- already holds that folio's lock ntfs_read_inode_mount ntfs_fill_super ntfs_read_inode_mount() assembles $MFT's runlist one $DATA extent at a time, hoping, as its comment says, that it never needs a part of $MFT it has not decoded yet. If $MFT's attribute list puts one of its attributes or later $DATA extents in an extent record outside the runlist decoded so far, reading that record re-enters ntfs_map_runlist_nolock() for $MFT. Depending on the layout, that waits on the folio lock it already holds, as above, blocks on $MFT's runlist lock, or dereferences NULL in map_extent_mft_record(). Mark the volume for the whole $DATA enumeration and have ntfs_map_runlist_nolock() refuse $MFT with -EIO while the mark is set. The enumeration decodes each extent itself with ntfs_mapping_pairs_decompress(), so it does not need that path. A validly placed record can trip the check too. The driver puts an extent record for $MFT's own mapping pairs before the first vcn it describes, but with clusters smaller than a page, the folio holding it can still run past the decoded runlist. An unpatched kernel hangs on that layout as well; with the check the mount fails. The check then refuses only the folio's tail, so this patch needs "ntfs: do not map an unmappable runlist fragment as a hole": without it the tail is zero-filled and the mount serves an all-zero mft record. The mount now fails instead of hanging: ntfs: (device vda): ntfs_map_runlist_nolock(): $MFT needs its own extent records to describe itself; cannot mount. Tested under qemu with KASAN, PROVE_LOCKING and the hung-task detector on ntfs-next, with and without the whole series: six crafted images that hang or crash an unpatched kernel fail to mount with the series, and nine images that mount without it still mount, three of them with the same file listing and contents, among them a volume written by ntfs-3g whose $MFT has its $DATA in three extent records. Fixes: b041ca562526 ("ntfs: update iomap and address space operations") Suggested-by: Hyunchul Lee Cc: stable@vger.kernel.org Signed-off-by: Matthias Goergens Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 6b956c9b8553e6824019c47abe3f7a672652fe87 Author: Matthias Goergens Date: Wed Sep 30 11:48:31 2026 +0800 ntfs: do not turn an unmappable runlist fragment into delalloc on write [ Upstream commit 26e51efbcb60b2eeddc3e7488fd214a02586851a ] ntfs_write_simple_iomap_begin_non_resident() has the same unchecked retry. LCN_RL_NOT_MAPPED passes its "lcn <= LCN_HOLE" test, so a buffered write into a range whose extent record cannot be read is merged into the runlist as LCN_DELALLOC over clusters that are already allocated on disk, and write() succeeds. If the record stays unreadable, writeback fails too and the data never reaches the disk; the error only shows up at a later fsync() or a synchronous write. On the volume from the previous patch, after a read of the file, an 8 KiB pwrite() at vcn 1000 returns 8192, fsync() returns -EIO, and after remount the range is unchanged. Fail the lookup here too, with -ENOMEM or -EIO. That pwrite() now fails with -EIO. Writes whose range can be mapped are unaffected. Fixes: b041ca562526 ("ntfs: update iomap and address space operations") Cc: stable@vger.kernel.org Signed-off-by: Matthias Goergens Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 7721a5eacab2fbf677ae03b2bd5cc2f355064556 Author: Matthias Goergens Date: Wed Sep 30 11:48:30 2026 +0800 ntfs: do not map an unmappable runlist fragment as a hole [ Upstream commit 2b451a65658fb44017480be8818ab93e9115b420 ] When the extent mft record holding part of a file's runlist cannot be read, ntfs_attr_vcn_to_rl() ignores the failed ntfs_map_runlist_nolock() retry and returns with *lcn == LCN_RL_NOT_MAPPED. The iomap read path only rejects lcn < LCN_ENOENT, so it maps the range as a hole and read() returns zeros with no error. The first read already does this: ntfs_attr_map_whole_runlist() keeps the fragments it could read, readahead drops its error, and the next lookup finds the unmapped tail. On a file whose runlist is split between its base record (vcn 0-214) and one extent record (vcn 215-1499), breaking only the extent record's FILE magic makes the kernel log "Failed to map extent mft record", yet read() returns 1285 clusters of zeros for vcn 215-1499. A damaged attribute list entry, which makes the retry fail with -ENOENT, gives the same zeros. Return -ENOMEM if the retry ran out of memory and -EIO otherwise. Both callers already handle an ERR_PTR; other negative lcns, including LCN_ENOENT, are returned as before, and so is LCN_RL_NOT_MAPPED at or beyond allocated_size, where nothing is mapped: the runlist ends there with LCN_RL_NOT_MAPPED when only the last extent is mapped, as after a write into it, and with clusters smaller than a page every read of a file's last folio looks up such vcns. Reads of vcn 215-1499 now fail with -EIO. An intact volume exercised with buffered, mmap and O_DIRECT I/O, fallocate, truncate, sparse and compressed files behaves as before. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Cc: stable@vger.kernel.org Signed-off-by: Matthias Goergens Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit b5bd03b9ca1db8ee5cb1ff1119dc291b2264490d Author: Hyunchul Lee Date: Tue Sep 22 15:18:33 2026 +0900 ntfs: validate attribute-list sizes before allocation [ Upstream commit ca43660672050337f4b845e36f732e3af1e308ca ] The NULL point dereference could occur when an on-disk $ATTRIBUTE_LIST size was truncated before it was validated and allocated. To fix this issue and prevent excessive memory allocation, limit the $ATTRIBUTE_LIST size to 256 KiB. The following existing implementation and Windows test provide evidence for this 256 KiB compatibility limit: NTFS already treats 256 KiB as the $ATTRIBUTE_LIST limit in its attribute-size checks and $MFT attribute list repack/expand paths. For additional Windows testing, when $MFT's attribute-list data_size was above 256 KiB, Windows attached the disk partition but did not mount a NTFS volume and target access failed. Fixes: af0db57d4293 ("ntfs: update inode operations") Link: https://lore.kernel.org/ntfs/88468.1790006025@30-10-12.wireless.csail.mit.edu/T/#u Cc: stable@vger.kernel.org Cc: Robert Morris Signed-off-by: Hyunchul Lee Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit b0a4eefbb2a16a60026948b71e8541186d8f06b9 Author: Hongling Zeng Date: Tue Sep 22 18:11:17 2026 +0800 ntfs: mount hibernated volumes read-only regardless of errors= [ Upstream commit 749357bd48c16c4cdc09093450deca609492f012 ] The hibernation check in load_system_files() only converts the superblock to read-only under errors=remount-ro. With the default errors=continue (and with errors=panic), a hibernated volume is mounted read-write and the mount-time $LogFile emptying writes to it, although a hibernated volume must not be written to at all. Drop the on_errors term so that a hibernated volume, or a volume whose hibernation state cannot be determined, always mounts read-only. NVolErrors() is still recorded, so ntfs_reconfigure() keeps refusing remounts to read-write, and the $LogFile emptying is skipped by its !sb_rdonly() check. The check itself must not apply the errors= policy either: it runs before SB_RDONLY is set, and ntfs_lookup_inode_by_name() and ntfs_iget() call ntfs_error() internally on corruption or I/O errors, which under errors=panic would panic the machine before the read-only fallback has made its decision. Temporarily substitute errors=remount-ro for errors=panic around the check: nested ntfs_error() calls then fall back to read-only, and any read-only transition they trigger is preserved even when the error is not propagated to the check's return value or recorded in NVolErrors(). This is safe during initial mount, before the super block is published. If the check reports hibernation or fails, set SB_RDONLY and record NVolErrors() unconditionally: hibernation safety takes precedence over the errors= policy. A volume with errors recorded during the check or earlier in the mount, e.g. when loading the LogFile, also stays read-only, matching what ntfs_reconfigure() enforces for remounts. Fixes: 6251f0b0de7d ("ntfs: update super block operations") Cc: stable@vger.kernel.org Suggested-by: Baolin Liu Reviewed-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Hongling Zeng Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit bc3c7da859f215868a42def63bfc605a982a3076 Author: Karl Mehltretter Date: Tue Sep 22 06:33:01 2026 +0200 ntfs: include the final partial cluster in sync writes [ Upstream commit fa5489ebc8bc7c663311b0f35943fe7edd0dfe56 ] ntfs_attrlist_repack() synchronously writes the replacement attribute list before updating its mapping pairs and freeing the old run. With 512-byte clusters, a 544-byte list submits a 512-byte bio, but the write returns 544 and repack accepts it as complete. If the later buffered update does not reach disk, the replacement list lacks its final 32 bytes. __ntfs_inode_non_resident_attr_pwrite() converts attr_len to clusters with ntfs_bytes_to_cluster(), which rounds down. Before repack, its synchronous callers used either cluster-aligned lengths or lengths smaller than one cluster, where max_t() selects one. Round attr_len up so repack writes the final partial cluster before publishing the new mapping pairs. Fixes: b1d732e62a5b ("ntfs: repack $MFT/$ATTRIBUTE LIST") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit a3ac83cb22988f812f7b695728c1e09bbb401a44 Author: Hongling Zeng Date: Tue Sep 15 16:32:52 2026 +0800 ntfs: fail remount on sync errors and keep the dirty bit on SB_FORCE [ Upstream commit 17a1edda75fd371f36085b1568e0b70baff99969 ] ntfs_reconfigure() currently ignores sync_filesystem() errors, allowing a regular read-only remount to succeed even when dirty data was not synced. Check the error and fail regular remounts, leaving the superblock read-write so ntfs_put_super() can retry at unmount. SB_FORCE does not wait for writers already in progress, so it must not clear the on-disk dirty bit. Warn and continue on sync errors for SB_FORCE. A forced remount updates the dirty state only when errors have been recorded, and never clears the dirty bit. Skip the commit if that state update fails, since the in-memory flags may be inconsistent. Reported-by: Hyunchul Lee Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Reviewed-by: Hyunchul Lee Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 12b699af6679407bfdf415694c1c0d14a5ec115e Author: Hongling Zeng Date: Tue Sep 15 16:32:51 2026 +0800 ntfs: check the dirty-state commit on remount and unmount [ Upstream commit 1a3883b3685cc4c8bc41927cc9df539239d7c961 ] The remount-to-read-only path commits the updated volume flags with ntfs_commit_inode(), a void wrapper around __ntfs_write_inode(), and ignores the blkdev_issue_flush() return value, so a failed commit or flush is reported as success. Once the remount has succeeded no persistence point is ever reached again: ntfs_put_super() skips read-only superblocks and the VFS never syncs one, so fail the remount unless the commit and the flush succeed. The superblock then stays read-write and ntfs_put_super() retries the persistence at unmount. The errors=remount-ro downgrade does not go through ntfs_reconfigure() and is unchanged. A zero-return commit is not trusted blindly: write_mft_record() redirties the record on allocation failure and reports success, so the $Volume inode is required to be clean afterwards. ntfs_put_super() discards the same commit error. Call __ntfs_write_inode() there with the same dirty re-check and warn on failure, as put_super() cannot return an error. The commit is skipped when the dirty-state sync itself failed, as that could write back an inconsistent flag state; a record left dirty by an earlier update is still committed at evict time. NVolErrors() is deliberately not used to detect the failure: it is sticky for the lifetime of the mount, so it cannot distinguish a fresh commit failure from errors recorded before the remount. Hibernated volumes: ntfs_sync_volume_dirty_state() is a no-op for them and never dirties the $Volume inode on such a mount, since the on-disk flags are already dirty and ntfs_set_volume_flags() has nothing to change. The commit only runs if something dirtied the inode independently, as before this patch; mounting hibernated volumes read-only removes even that. Reported-by: Baolin Liu Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Reviewed-by: Hyunchul Lee Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 02d032b552c52b467094f2f4f4307fc4f90bc463 Author: Hongling Zeng Date: Tue Sep 15 16:32:50 2026 +0800 ntfs: do not clear the volume dirty bit during sync [ Upstream commit 4a1bb54f571cbef67a7c470a3139ffec1a15a8e4 ] ntfs_sync_fs() clears VOLUME_IS_DIRTY while the volume is still mounted read-write, so a sync running concurrently with an in-flight metadata modification can clear and persist a bit that was just set: the modification then lands on a volume that is clean on disk, and a crash does not run chkdsk. Stop clearing the bit in ntfs_sync_fs() and leave the clearing to the remount-to-read-only path, which the VFS reaches only after sb_prepare_remount_readonly() has drained in-flight writers, and to ntfs_put_super(), which runs after evict_inodes() on a quiesced filesystem. A mounted read-write volume now keeps the dirty bit until it is dismounted cleanly, which matches the NTFS semantics; the cost is a needless chkdsk if the machine crashes between a sync and the unmount. A recorded error state is still persisted right away when the filesystem is synced: with NVolErrors() set, ntfs_sync_volume_dirty_state() can only set the bit, never clear it, so it cannot lose a modification the way the old unconditional call did. This keeps the error report from being lost to a crash on a volume that has seen no modification; an error recorded after the last sync is still only persisted at the next quiescent transition. sync_blockdev() and blkdev_issue_flush() are both called and the first error is returned, so a writeback failure neither hides a flush failure nor skips it. A RWF_NOWAIT write still blocks in the marking when the volume looks clean, as it already did on the base; a non-blocking marking is follow-up work. Reported-by: Baolin Liu Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Reviewed-by: Hyunchul Lee Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 05cedea3e1d982dd84c4a5b43e59f74088e2e51d Author: Hongling Zeng Date: Tue Sep 15 16:32:49 2026 +0800 ntfs: persist the dirty state after the final put_super() commits [ Upstream commit 5d0e57ea8e37db3e32d1b1b7fa4f3c7a94ff8e56 ] The just-in-case mftmirr/mft commits and the final write_inode_now() in ntfs_put_super() can record NVolErrors() after the dirty state has been persisted, so errors from those points would leave the volume unmounted with a clean on-disk dirty bit - contradicting the "cannot unmount clean" guarantee ntfs_sync_volume_dirty_state() is meant to provide. Move the persistence to the end of ntfs_put_super(): keep the gated re-commits and the tail commits where they are, run ntfs_sync_volume_dirty_state() and the $Volume commit after the last write_inode_now(), and release vol->vol_ino only after the sync. The release order of the special inodes matters for the $Volume commit: writing the $Volume record mirrors it through ntfs_sync_mft_mirror() (record number 3 is below vol->mftmirr_size), which fails with -EIO and leaves the mirror stale once vol->mftmirr_ino is gone, so the mirror inode is released only after that commit. vol->vol_ino is then put before vol->mft_ino is dropped: if the commit failed before it could clear the dirty flag, ntfs_evict_big_inode() commits the inode again on its way out, and __ntfs_write_inode() resolves the runlist through vol->mft_ino. Reported-by: Baolin Liu Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Reviewed-by: Hyunchul Lee Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 2254d06b1795e0ca1ed977bd604d5c5e633937d9 Author: Hongling Zeng Date: Tue Sep 15 16:32:48 2026 +0800 ntfs: sync the volume dirty bit with the recorded error state [ Upstream commit 521978c4f4441953d67297286e5804485ae05698 ] The runtime metadata-corruption paths in fs/ntfs only record the in-memory NVolErrors() flag; whether VOLUME_IS_DIRTY ever reaches disk depends on ntfs_set_volume_flags() being called by some other path, which for most error sites never happens. A volume can therefore unmount with a clean on-disk flag despite recorded corruption, and chkdsk will not run on the next mount. Persisting the dirty bit from the error paths themselves does not work: they run under a wide variety of ntfs locks, and the dirty-bit write takes the $Volume mrec_lock and maps the $Volume mft record, which on an $MFT page-cache miss takes the $MFT runlist lock for writing. That is enough to self-deadlock or form ABBA cycles from several of them: the $MFT extend undo paths hold the $MFT runlist lock and then take vol->lcnbmp_lock inside ntfs_cluster_free(); the cluster allocation and free rollback paths hold vol->lcnbmp_lock; and the whole mft record allocation tree is reachable from ntfs_write_volume_label()'s attribute-list maintenance while it holds the $Volume mrec_lock itself. Instead, make the persistence a property of the sync paths, which run without ntfs locks held. The new ntfs_sync_volume_dirty_state() sets VOLUME_IS_DIRTY when NVolErrors() is recorded and clears it otherwise, evaluating the error flag under the $Volume mrec_lock. It is called from ntfs_sync_fs(), from the remount-to-read-only path of ntfs_reconfigure(), and from ntfs_put_super(), which previously evaluated NVolErrors() outside the lock before clearing the dirty bit unconditionally, and which now also persists the dirty bit for volumes with recorded errors so they unmount with chkdsk scheduled. The ntfs_clear_volume_flags() wrapper, whose last callers this patch replaces, has no users left and is removed. The guarantee this provides is eventual, not instantaneous: the error paths record NVolErrors() with a lock-free set_bit(), so a persistence point that evaluates the flag just before an error is recorded can still leave the on-disk bit clean until the next one. This is sound because NVolErrors() is sticky for the lifetime of the mount and every persistence point re-derives the on-disk bit from it; the last one, ntfs_put_super(), runs after evict_inodes() on a quiesced filesystem, so a volume that is read-write at unmount time cannot unmount clean. A volume that is already read-only when the error is recorded (errors=remount-ro flips the superblock on the first error, as does an earlier remount-ro) has no persistence point left and keeps whatever on-disk bit it had; that behaviour is unchanged. The residual window is a crash between the error and the next persistence point. The persistence paths never write a hibernated volume: resuming Windows from a modified image corrupts it. Record the mount-time hibernation verdict in the new NV_Hibernated volume flag and make ntfs_sync_volume_dirty_state() a no-op while it is set, so the dirty bit is left exactly as it is on disk and only the in-memory error state is kept. Without this, an rw mount of a hibernated volume with the default errors=continue would gain a filesystem-internal write on the first sync, remount or unmount. Other writes to such a mount, like the mount-time logfile emptying, are pre-existing and unchanged. Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Reviewed-by: Hyunchul Lee Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 6d39bee71241792d4d3130f80916b8160bf5d010 Author: Hongling Zeng Date: Mon Sep 21 23:13:19 2026 +0900 ntfs: set the volume dirty bit unconditionally on metadata changes [ Upstream commit 55af94ca0ee3512c08d12ffbbb948229da4e1565 ] The callers in file.c and namei.c skip ntfs_set_volume_flags() when the in-memory vol_flags already show VOLUME_IS_DIRTY, but that check runs without any lock: if it observes the bit set and ntfs_sync_fs() clears it under the mrec_lock before the caller's metadata update completes, the set is skipped and the volume can end up clean on disk despite the modification, so chkdsk will not run on the next mount. Drop the caller-side checks and call ntfs_set_volume_flags() unconditionally: ntfs_write_volume_flags() already skips the write under the mrec_lock when the combined value is unchanged. That unconditional call costs one mrec_lock acquisition per metadata operation even in the already-dirty steady state; it cannot be avoided, because deciding to skip the call without the lock is itself what allows a concurrent ntfs_sync_fs() clear to lose the set. The IOCB_NOWAIT path in ntfs_file_write_iter() goes through the same sleeping call: a RWF_NOWAIT write can block in the marking, as it already could before this change whenever the volume appeared clean. Giving that path a non-blocking variant is left as follow-up work. The callers keep the pre-existing behavior of proceeding when the marking fails, so the dirty bit remains best-effort. This closes the variant where the set is skipped outright. A clear for a concurrent, error-free sync can still land between the set and the end of the metadata operation; that mark-at-start lifecycle is pre-existing and is not changed by this patch. Reported-by: Baolin Liu Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Reviewed-by: Hyunchul Lee Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit a3f524d243100c952a44fdcd1382916609b49b03 Author: Hongling Zeng Date: Tue Sep 15 16:32:46 2026 +0800 ntfs: fix volume flag update races [ Upstream commit 56a64ee0f99d4ca1756cf743f951c110d39401e5 ] ntfs_set_volume_flags() and ntfs_clear_volume_flags() both read vol->vol_flags outside any lock to compute the new value before handing it to ntfs_write_volume_flags(), which only takes ni->mrec_lock around the actual write. The read-modify-write is therefore not atomic, and two concurrent callers can lose an update: ntfs_sync_fs() may derive a "clean" value from vol->vol_flags while a writer concurrently records an error and sets VOLUME_IS_DIRTY; the locked write then silently overwrites the freshly-set dirty bit. The on-disk volume looks clean despite the recorded errors, so chkdsk will not run on the next mount and corrupted metadata can persist. Fix by moving the read-modify-write inside the mrec_lock: pass the bits to set and to clear separately, and combine them with the current flag state under the lock inside ntfs_write_volume_flags(). The set/clear helpers pass only the bits to modify, not the complete flag state. The bit manipulation is done on CPU-endian values, and the result is converted back to little-endian before storing it. The wrappers keep their signatures so callers are unchanged. Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Reviewed-by: Hyunchul Lee Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit e24ee790c71ed74422a851dfb5962098d1d705c6 Author: Hyunchul Lee Date: Tue Sep 15 00:19:15 2026 +0900 ntfs: avoid truncate and writeback deadlock [ Upstream commit fca746064d56329cd81b4f2b1961a3b928c3fe5a ] ntfs_non_resident_attr_shrink() drops page-cache folios after freeing clusters and truncating the runlist. The VFS truncate path calls it with mrec_lock held. A folio writeback can need the same lock to resolve its iomap mapping, so truncate can wait for writeback while writeback waits for mrec_lock. A hung-task call stack: truncate: mrec_lock -> truncate_inode_pages() -> folio lock/writeback writeback: folio lock/writeback -> ntfs_write_iomap_begin() -> mrec_lock ntfs_setattr_size() already calls truncate_setsize() before ntfs_truncate_vfs() acquires mrec_lock. Reuse that page-cache truncation in the VFS path and skip the duplicate truncation under mrec_lock. Keep the cleanup for internal attribute callers, which do not call truncate_setsize(). This avoids synchronously flushing the whole discarded tail while preserving page-cache correctness. Fixes: 4e646ecd4475 ("ntfs: drop stale page-cache when shrinking a non-resident attr") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit aa80108cac4dc66be8fdbc01e1c82c4b1b76b23f Author: Hongling Zeng Date: Mon Sep 7 11:57:26 2026 +0800 ntfs: use fatal_signal_pending() for fallocate interruption checks [ Upstream commit 338abaf0dc9230a6627de1a532b7fea5f13623eb ] The fallocate implementation uses signal checks to let a long allocation loop abort early. However, signal_pending() also returns true for TIF_NOTIFY_SIGNAL, which io_uring uses to deliver task_work completions to the submitting task. generic/616 is an io_uring fsx soak test that issues fsx-style read/write requests through io_uring and calls fallocate() directly in between. A pending io_uring task_work notification can therefore make signal_pending() true inside ntfs_attr_fallocate() even though no real signal was delivered. That caused the previous signal-interruption patch to return -EINTR for an io_uring notification, which fsx treats as a fatal failure. Switch both checks to fatal_signal_pending() so only fatal signals interrupt the allocation loop. A real fatal signal still returns -EINTR, and any other error still takes precedence. Fixes: 4dc8f4ee2d46 ("ntfs: handle signal interruption in fallocate") Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Reviewed-by: Baolin Liu Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit afc851c95939f6d0b4a977cda4cce04d590ad741 Author: Hongling Zeng Date: Mon Sep 7 15:08:52 2026 +0800 ntfs: NULL vol->vol_ino in the load_system_files() error teardown [ Upstream commit a0c022c1da5b0fa30c61bd5b28db9f639ace5bf5 ] The error unwind of load_system_files() drops vol->vol_ino on two paths but leaves the stale pointer in place while it keeps iput()ing the remaining system inodes ($Bitmap, $MFT bitmap, $MFTMirr; $MFT itself is dropped by the caller, ntfs_fill_super()). A third path carried an iput() that can never execute: it sits inside the IS_ERR(vol->vol_ino) branch guarded by !IS_ERR(vol->vol_ino), and is removed along with the stale pointers. Nothing in the teardown dereferences vol_ino today, so this is pure hygiene, but a stale pointer to a freed inode surviving the unwind is a trap for any future code walking the volume during teardown. ntfs_put_super() and the ntfs_fill_super() error path already NULL it after their iput(); do the same here. Cc: stable@vger.kernel.org Signed-off-by: Hongling Zeng Reviewed-by: Baolin Liu Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit e867437ea95f1af5d0fafafeeaa455aa763bc419 Author: Hyunchul Lee Date: Mon Sep 21 15:44:12 2026 +0900 ntfs: wait for attribute folio writeback before update [ Upstream commit 418452b43d722b3c1e9a711c9f49f3dbe2afaf34 ] ntfs_inode_attr_pwrite() locks an attribute folio before copying a new attribute image into it, but taking the folio lock does not wait for an already-running writeback BIO to complete. The writeback path can unlock the folio while PG_writeback remains set and the BIO still references the folio memory. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 5771ee7e31180bcc5e8243b5301bfac27efe2ca5 Author: Hyunchul Lee Date: Mon Sep 21 22:40:16 2026 +0900 ntfs: trigger page_mkwrite for native 4Kn size extension [ Upstream commit 7823d72305f03928f3093e91cd7159542981162b ] On native 4Kn volumes, pagecache_isize_extended() can leave a writable mapping for a partial old-EOF page. A subsequent shared mmap write can then bypass ntfs_filemap_page_mkwrite(), leaving NTFS initialized_size at the old EOF. Invalidate the partial old-EOF page after size extension, independent of the filesystem block size, so the next mmap write enters the NTFS page_mkwrite path. Apply the same helper to zero-fill fallocate extensions and compare the actual new size after the operation so extensions overlapping the old EOF are handled as well. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 824e32d5616f1cd956c0276b3f943f343fb3ac5f Author: Hyunchul Lee Date: Mon Sep 21 15:44:10 2026 +0900 ntfs: use sync flag for direct MFT writes [ Upstream commit 43e2fff9f4ec9ff5a9731bf874327eca21259867 ] Use the supplied sync flag for direct MFT writes instead of forcing containing-unit writes to complete synchronously. Pass sync=1 from ntfs_mft_record_free() so the MFT bitmap entry is not released until the record write completes. Other direct-write callers keep the completion mode requested by their caller. The folio lock serializes write preparation, and PG_writeback keeps the whole unit stable until all chained BIOs complete, so asynchronous containing-unit writes remain safe. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 121ab44b9deeb2c810b94b51459f3cf7bde9b819 Author: Hyunchul Lee Date: Mon Sep 21 15:44:09 2026 +0900 ntfs: write MFT records through containing I/O units [ Upstream commit 4437d9d787185520c4798a942de9b5ef986d2141 ] Use the configured MFT I/O unit for direct writes, mirror updates, and generic folio writeback. On native 4Kn devices, multiple MFT records can share a device block, so submit complete containing units while preserving unselected neighboring records. Track selected records separately from records owned by direct inode writeback, and retain the existing runlist and cluster-boundary checks. Force direct MFT writes to complete synchronously when the I/O unit is larger than an individual record. the following patch restores caller-controlled completion. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 1581461a0b4fa2f02ccfdb90c87c42102c792648 Author: Hyunchul Lee Date: Mon Sep 21 15:44:08 2026 +0900 ntfs: write MFT folios through mapped I/O units [ Upstream commit 1df655bcddc212fc1e38b44c3172b6172c11b77a ] Replace the legacy MFT folio writeback loop with a mapped I/O-unit writeback path. Map the I/O units covering selected records under the runlist lock and submit them through an aggregate parent BIO with optional chained child BIOs. Defer transient mapping failures, preserve partial-progress redirty semantics, and complete folio writeback from aggregate parent completion. Do not set defer for records that generic writeback does not own. Dirty FILE records remain under direct inode writeback. other rejected records and the special $MFT extent are skipped rather than treated as transient failures. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 84a59367a7b19872eab9385eeb578dd47ab20c57 Author: Hyunchul Lee Date: Mon Sep 21 15:44:07 2026 +0900 ntfs: track direct MFT writes until BIO completion [ Upstream commit 4576ffbded9ad1dd4216f4f2a18a2efa12aeea58 ] Use an aggregate parent BIO, with optional chained child BIOs, for direct MFT record writes. Keep the folio reference and PG_writeback set until all physical segments complete. For asynchronous writes, release the parent BIO embedded in the write context before ending folio writeback. Synchronous callers retain ownership of the parent BIO after waiting. Wait for any prior folio writeback before modifying a direct MFT record. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 4a224bbb67f1c49d71b30b8b240b1074d0ece3df Author: Hyunchul Lee Date: Mon Sep 21 15:44:06 2026 +0900 ntfs: serialize raw MFT updates against folio writeback [ Upstream commit ec0a5dd2e385e11839e8846dabe1f9f7042ac202 ] Because MFT folio writeback can remain active until its asynchronous BIO completes, raw MFT record formatting and allocation must not modify the folio while it is still used as a BIO source. Wait for existing folio writeback after taking the folio lock in both raw MFT update paths. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 85a1c6cb240140fbd9233e5bf69962f8e5eed2a9 Author: Hyunchul Lee Date: Mon Sep 21 15:44:05 2026 +0900 ntfs: write MFT mirror data in mapped I/O units [ Upstream commit b9fa884a39874091a10706fca69483ca957138f3 ] Replace the record-specific mirror writer with a unit-based helper and use a stack-allocated BIO for synchronous mirror writes. Route write_mft_record_nolock() and ntfs_write_mft_block() through the common mirror primitive. The helper only returns errors, So callers handle volume error reporting and retry policy. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit ca97bf19490d7c4abe42f070d0d7d3a05c4146e7 Author: Hyunchul Lee Date: Mon Sep 21 15:44:04 2026 +0900 ntfs: validate the MFT I/O geometry [ Upstream commit dfe7ed335b686d53e4441a15382024058b664d3a ] MFT writes must consider both the device logical block size and the NTFS record geometry. Validate those values at mount time, then cache the MFT I/O unit used by all MFT write paths. Use the larger of the device logical block and MFT record sizes as the MFT I/O unit. Keep valid geometries that the current write paths cannot safely handle read-only until their mapping support is generalized. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit aaecfeddac072f1ad156f9268ce23153bb17705c Author: Hyunchul Lee Date: Mon Sep 21 15:44:03 2026 +0900 ntfs: read MFT writeback bounds under size_lock [ Upstream commit 50ed298b6a4be68cac85801d21a5e25555f64668 ] Read the MFT inode size and allocated size under the size_lock critical section before deriving the folio writeback limits. This prevents writeback from combining an old allocation boundary with a concurrently updated file size while the MFT is extended. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 69effda293ebbffe2a19fef3b2b0ba12ac55694c Author: Chengfeng Ye Date: Tue Oct 13 17:05:00 2026 +0800 l2tp: snapshot sequencing state when building transmit headers [ Upstream commit d06ae66516e1aaf023808912af6292aef09d46c3 ] Updates to send_seq from netlink, PPP setsockopt and receive-side negotiation race with packet transmission. The header length is updated separately, while transmit reads both fields repeatedly without synchronization. For example, transmit can push a ten-byte L2TPv2 header, then a concurrent writer clears send_seq before the header builder reads it. The builder writes only six bytes, leaving four bytes of uninitialized skb headroom in the outgoing packet. The reverse mismatch overwrites the beginning of the payload. A later hdr_len read can also make the UDP length disagree with the skb length. KCSAN reported: BUG: KCSAN: data-race in l2tp_session_set_header_len / l2tp_xmit_skb write to 0xffff888100d0944a of 2 bytes by task 116 on cpu 1: l2tp_session_set_header_len+0x81/0xc0 l2tp_nl_cmd_session_modify+0x122/0x2c0 genl_family_rcv_msg_doit+0x170/0x1d0 read to 0xffff888100d0944a of 2 bytes by task 115 on cpu 0: l2tp_xmit_skb+0x9c/0xc80 pppol2tp_sendmsg+0x21c/0x2a0 __sys_sendto+0x28c/0x2a0 The bug can lead to leak kernel base address for KASLR bypass, the corresponding reproducer can be provided per request. Initialize hdr_len to the maximum header size and leave it unchanged when sequencing is toggled. Snapshot send_seq once per packet and use that snapshot for the actual header length and header construction, including the sequence flag. Use the same length for headroom, the header push and the UDP length. PPP callers can safely reserve the maximum size; L2TPv3 header sizes do not depend on sequencing. Make send_seq a separate bool so READ_ONCE() and WRITE_ONCE() can be used without sharing a bitfield storage unit with other configuration flags. Preserve the netlink attribute's existing low-bit truncation. Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core") Cc: stable@vger.kernel.org Assisted-by: GPT-6 Astra Signed-off-by: Chengfeng Ye Link: https://patch.msgid.link/20261013090500.1180376-1-nicoyip.dev@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8b6d5f144ce91816b12e24d93c8845f9d5d3dde2 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 673808c5c093943fcbc8b7b70bf077ebcb8f3712 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 eadf0118ab295a5a2556388f13df6bec1615e556 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 612109762a807b63653d04e029dc69553990c2d5 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 b732d57875d8f519af555b073bfb210facfaa395 Author: Thomas Nemer Date: Mon Oct 19 22:49:44 2026 +0200 ALSA: usb-audio: Skip sample-rate read-back on PreSonus AudioBox USB [ Upstream commit 20b9cae98ddcff87828d033e35b31f9e6a14dd6a ] The AudioBox USB stalls the UAC1 GET_CUR SAMPLING_FREQ request on both streaming endpoints. After the sample rate is set, the read-back verification in set_sample_rate_v1() fails and logs usb 1-3.1.2: 2:1: cannot get freq at ep 0x1 usb 1-3.1.2: 3:1: cannot get freq at ep 0x82 on each endpoint configuration until the sample_rate_read_error counter gives up. Set QUIRK_FLAG_GET_SAMPLE_RATE to skip the read-back on this device. Fixes: 1869c47e5d59 ("ALSA: usb-audio: Fix missing sample-rate control for PreSonus AudioBox USB") Cc: stable@vger.kernel.org Signed-off-by: Thomas Nemer Link: https://patch.msgid.link/20261019204944.28302-1-thomas.nemer@fortytwo.fr Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 15257bdfbdc25cad12674aa3f56cf19e963ecf11 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 6b48deba1968a573eba8a26981c8431366779518 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 d148bc1f49ac73ca9ad75cd44bbf71f9806cf635 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 73f7fd0f75dd9f37063377a29a6f33250e921dd7 Author: Michal Blaszczyk Date: Mon Oct 19 12:41:45 2026 +0000 sched_ext: Reset runnable_at when a task leaves its scheduler [ Upstream commit 993e8fbfecbbf284b9644c6f10741b28fb914094 ] The watchdog measures how long a task has been waiting from p->scx.runnable_at, which set_task_runnable() resets when the task becomes runnable after it last ran. ops_dequeue() never asks for a reset, as the dequeue of a waiting task is temporary, e.g. for a migration or an attribute change. Leaving the scheduler isn't temporary. A task which is switched out of SCHED_EXT while it's waiting keeps its runnable_at. When it's switched back and becomes runnable, its wait appears to have started before it left, and the time it spent in another class counts towards the timeout. If the watchdog checks before the task runs, it aborts the scheduler: sched_ext: class_switch_stall: runner[418] failed to run for 3.010s Here, the task waited for a few milliseconds before it was switched to SCHED_OTHER, slept outside of SCHED_EXT for three seconds, and was charged for all of it as soon as it woke up on SCHED_EXT again. The same happens when scx_sub_enable_workfn() hands a waiting task over to a new sub-scheduler, which can then be blamed for time the task waited under the parent. scx_rehome_task() isn't affected, as it moves the task through SCX_TASK_INIT, which resets runnable_at. The stale runnable_at also skews the default core-sched ordering in scx_prio_less(). Reset runnable_at in scx_disable_task(), when the task leaves the control of its scheduler. Fixes: 8a010b81b3a5 ("sched_ext: Implement runnable task stall watchdog") Cc: stable@vger.kernel.org # v6.12+ Assisted-by: LLM Signed-off-by: Michal Blaszczyk Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit fe067d394fbe80ac7cc934e7e997d5dfcc024e4d 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 523b2387d7869b277fba5e15987a199f4df0d602 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 2d500347683ed9cbb98a4f2aa9b48bfe84764e94 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 2c80a9f2f233f47e871b670826825e4fb1730e73 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 e4b6095ced8f87a200e69716f554186c1200f36b Author: Baek Kyu, Kim Date: Sun Oct 18 14:57:50 2026 +0900 hwmon: (mcp9982) Update the interval cache only after successful writes [ Upstream commit fcf9aa9beb773bed9d2183bf34f822de12b2c91c ] mcp9982_write() updates interval_idx before writing the conversion-rate register. If the write fails without changing the register, subsequent update_interval reads report the requested interval instead of the previous setting. Update interval_idx only after regmap_write() succeeds, leaving the previous cached interval in place on error. Fixes: e2fe950f34e5 ("hwmon: add support for MCP998X") Cc: stable@vger.kernel.org Signed-off-by: Baek Kyu, Kim Acked-by: Duicu Victor Link: https://patch.msgid.link/20261018055750.1318723-1-pocj8ur4in@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit f711f8f5af0bede8881c85220cacde601774af4e 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 6565df5ee31b8089f644df92e5f924c62b105622 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 0732fb95a1dc167a467c079b182de35f5e6afa4a Author: Gregory Price Date: Thu Oct 15 13:30:29 2026 -0400 rtc: cmos: Honor explicit use_acpi_alarm parameter value [ Upstream commit 3c7acb209e1d630b734a2ec72bd988f5da2ac55c ] An explicit rtc_cmos.use_acpi_alarm=0 command-line argument is ignored on systems where use_acpi_alarm_quirks() enables ACPI RTC alarms. The argument appears in /proc/cmdline, but the read-only parameter reports Y. The boolean parameter defaults to false, so the driver cannot distinguish an omitted argument from an explicit false value. Use a custom setter to record whether parsing occurred and skip automatic selection when it did. Preserve the bool parameter type metadata. Automatic selection remains unchanged when the parameter is omitted. On the affected system, the explicit false value reports N after this change. The HPET-emulated path completed 100 test runs without a failure while the ACPI RTC event counter remained at zero. Fixes: 36d91a4d401c ("rtc: cmos: introduce quirks to enable use_acpi_alarm mode") Cc: stable@vger.kernel.org Signed-off-by: Gregory Price (Meta) Link: https://patch.msgid.link/20261015173029.3091872-3-gourry@gourry.net Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit ad59f4c708dacef3bbcec81f24a6f9a28e44c094 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 720e0cabd0c8049bf75e53179eb472dbba123256 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 8404b970efa3d156e321eec36509c3ac20d35434 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 01632055d9671ee367f28c518be32b91df7e5b05 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 04ffad0d08eb55c6b2d458c861d9f912444ebbfd Author: Vaibhav Nagare Date: Mon Oct 12 12:58:02 2026 +0530 bnxt_en: don't leave an XDP program installed when the open fails [ Upstream commit 78731b46967e3e7102b5cd5062bef185f3404b5c ] bnxt_xdp_set() stores the new program and drops the reference on the old one before reopening the NIC. If bnxt_open_nic() then fails, ndo_bpf() returns an error with the new program still in bp->xdp_prog. The caller treats the error as "nothing was installed" and drops its own reference, so bp->xdp_prog is left pointing at a freed program and the next XDP update dereferences it: BUG: unable to handle page fault for address: ff78ecc80ddd1038 RIP: 0010:__bpf_prog_put+0x5/0x80 Call Trace: bnxt_xdp_set+0xad/0x1b0 [bnxt_en] dev_xdp_propagate+0x36/0xa0 bond_xdp_set+0xeb/0x2d0 [bonding] dev_xdp_install+0x1b1/0x350 bpf_xdp_link_update+0xc5/0x1b0 link_update+0x104/0x1e0 __sys_bpf+0x662/0xcf0 Seen on a 6.12 based kernel after bnxt_alloc_mem() failed an order-4 allocation on a fragmented host: bnxt_en 0000:a0:00.1 ens4f1np1: nic open fail (rc: fffffff4) bond1: (slave ens4f1np1): Error -12 calling ndo_bpf Bonding is not required to hit this; a plain XDP attach on a bnxt interface takes the same path. Restore the previous program when an attach or a replace fails, and recompute the page-mode and XDP TX ring configuration from it. The configuration matters because bnxt_init_one_rx_ring() only assigns rxr->xdp_prog in page mode, and __bnxt_set_rx_skb_mode() derives dev->max_mtu from the installed program. Release the old program only once the change has been committed. A detach is not undone. dev_xdp_detach_link() clears the core's record of the program even when the driver returns an error, so putting the program back would leave the driver running a program the core has already dropped. If the reopen fails during a detach, bnxt_xdp_set() therefore returns 0 with the device closed; bnxt_open_nic() has already logged the failure. Found in a crash dump; the change was not tested on hardware. Fixes: c6d30e8391b8 ("bnxt_en: Add basic XDP support.") Cc: stable@vger.kernel.org Signed-off-by: Vaibhav Nagare Reviewed-by: Simon Horman Link: https://patch.msgid.link/20261012072802.2153706-1-vnagare@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 92cd44de2d261356dfcf5988a77fa8e766c7d777 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 521f00ac9ed282fe056aef53274856783029f268 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 b5ed456d3b474204e3152b36abe2e8035025f026 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 60a352da1064de30dd4358f3dd3e501fe2ac2297 Author: Thomas Nemer Date: Sun Oct 18 13:15:19 2026 +0200 ALSA: usb-audio: Fix missing sample-rate control for PreSonus AudioBox USB [ Upstream commit 1869c47e5d59c6940823a58d58b647645cb69017 ] The fixed audio formats for the PreSonus AudioBox USB declare .attributes = 0, dropping UAC_EP_CS_ATTR_SAMPLE_RATE that the device advertises in its class-specific endpoint descriptors (EP_GENERAL bmAttributes 0x01 on both EP 0x01 and EP 0x82). As a result set_sample_rate_v1() bails out and the kernel never sends the UAC1 SET_CUR SAMPLING_FREQ request, leaving the device on its power-on default clock. Playback and capture then run distorted whenever the stream rate differs from that default. The device keeps the last rate set by a host as long as it stays powered, which made the regression look intermittent (e.g. it disappears after the device was initialized by a host running a kernel without this quirk entry). Restore the sample-rate attribute on both streams. Fixes: 34fe4a9df247 ("ALSA: usb-audio: Add quirk for PreSonus AudioBox USB") Cc: stable@vger.kernel.org Signed-off-by: Thomas Nemer Link: https://patch.msgid.link/20261018111519.191844-1-thomas.nemer@fortytwo.fr Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7c0b34f98b0a34c6d53cea48f080ff4c8dc7edd0 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 efd613a43c275a412ee0af1ef4d4b32f0ba8ab50 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 34bd3e5f44a327e15c1a6513bae8267bda19b43f 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 11e2624fff7a12c82d48679d64d560729c342172 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 9690846c8981567c10dcef154b9249f56d6b6ba7 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 27ea77509ce8ba121a6d34a76cd90e5bfb7411d3 Author: Ricardo Neri Date: Tue Oct 6 06:04:56 2026 -0700 hwmon: (coretemp) Return -ENODATA for invalid temperature readings [ Upstream commit f63aaa529cbc73146ff0d52235e5479042285cae ] IA32_THERM_STATUS and IA32_PACKAGE_THERM_STATUS have a valid bit, bit 31. The Intel SDM documents it only for the former, but the package register implements it too: x86_pkg_temp_thermal has required it since commit f1a18a105660 ("Thermal: CPU Package temperature thermal"). This driver checked the bit for both registers as well, until commit bf6ea084ebb5 ("hwmon: (coretemp) Do not return -EAGAIN for low temperatures") made it ignore the bit because some CPUs clear it while the temperature is too low to be measured. Since then, temp%d_input reports such a reading as a real temperature. Userspace cannot tell it apart from a genuinely low one. Fail the read with -ENODATA while the CPU reports the reading as invalid. On a CPU that clears the bit, reading temp%d_input now fails where it used to return a low value. sensors(1) shows N/A in its place. Cc: stable@vger.kernel.org Suggested-by: Guenter Roeck Link: https://lore.kernel.org/all/46f9f319-de71-412f-a424-6cb801478456@roeck-us.net/ Signed-off-by: Ricardo Neri Link: https://patch.msgid.link/20261006-coretemp-enodata-v2-1-64e788acc7dc@linux.intel.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 979ebd599c5ce68066baa30601596220b85dce58 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 f1e1d3a1014aee93bc33e8cb4994123684f1cf38 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 28435e18a0dc1316e7b4bd702bfe10457f729c8e Author: Deep Shah Date: Thu Oct 15 08:36:36 2026 +0000 RDMA/uverbs: Fix uobject leak in DMABUF release [ Upstream commit 4a953ee228f5544a3e5515eed88bf09d1a5adb94 ] uverbs_dmabuf_release() treats a NULL uobj->context as an aborted allocation, but normal ufile cleanup also clears it. Closing the uverbs FD before the dma-buf FD therefore skips uverbs_uobject_release() and leaks the uobject and ufile references. Clear dmabuf->priv before dma_buf_put() on allocation failure and use that NULL pointer to identify an abort. Otherwise, always call uverbs_uobject_release(). This also avoids reading a freed uobject if release is deferred until after the allocation has been aborted. Fixes: 0ac6f4056c4a ("RDMA/uverbs: Add DMABUF object type and operations") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Deep Shah Link: https://patch.msgid.link/20261015083637.200958-2-deepshah146@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d5e8a40ea93d9ed52e891cb7f5205625ba17946f 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 643c1e5912592d14de28643f0d30fdef5a85bd23 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 e4134f6fd00560ce22f90c5b3d5b9cb4d7cba154 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 f624f3506ce93a8a8512a59617512e187f865d30 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 f763165bb711567c18ede8f3cc20943b37b2b82e 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 023d39b78a8864013aedba08d5fa9934c72170d3 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 8f7524673fcd6a8d854f99b9a317481c475100f1 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 393cdca8e239b50ab2fc237cdbc5adfee14eab0a 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 3726ffa1e710509131c460d415cec71628a2cbb4 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 1460d772e2f28bf87f49414bc15886a26c15933c 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 1af35afb40a355e5e50678792463509e0405d1a6 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 8685a6e72d1f9171e652673fa12c4c413eb1ff02 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 eb1460c71da2ce9a0d295df71b0e1ced2cf7a5b1 Author: Andrea Righi Date: Sat Oct 17 22:05:14 2026 +0200 sched_ext: Don't queue balance callbacks from a core-sched pick [ Upstream commit 680edc7f23ad71e0ecce8a2364af3ae7f30dd11a ] Commit ff0545e0c263 ("sched_ext: Don't leave balance callbacks queued across a pick retry") queues the deferred work as a balance callback only when do_pick_task_scx() returns a final pick. However, under core scheduling, a pick that returns a task isn't final either: pick_next_task() goes on to pick the SMT siblings, and their dispatch can release the shared rq lock with the callback still queued, triggering the rq_pin_lock() warning. Moreover, dispatch_core_pick() returns early when another dispatch is in flight on the rq, and do_pick_task_scx() then consumes %SCX_RQ_BAL_CB_PENDING set by that dispatch while it's still running. This can be reproduced running scx_qmap -I on SMT siblings with coresched-tagged workloads that frequently sleep, mixed with untagged CPU-bound tasks. Fix this by always deferring the pending work to the irq_work path from dispatch_core_pick() under core scheduling, for both the local and the sibling picks, and by leaving %SCX_RQ_BAL_CB_PENDING alone in do_pick_task_scx(), so that it's handled by the dispatch that set it. Sample the core scheduling state once at the start of the pick, since core scheduling can get enabled while a non-core dispatch has the rq lock released, and the follow-up work must match the dispatch path that ran. Fixes: 4c95380701f5 ("sched/ext: Fold balance_scx() into pick_task_scx()") Cc: stable@vger.kernel.org # v6.19+ Signed-off-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit af22b4f7f60a14b6d96196dbb9899b750c0ce887 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 ba9c850c647e7773c908b69c5474645ec0e350af 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 cf4fb2083cac5f6e87ade52d27c4a12f03788fa9 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 01cff42c34b213f2e0edf6813608a94dbd808495 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 35bf00f2356f4d5f5c26967c1581dbcecf10f40f Author: Andrea Righi Date: Sat Oct 17 17:22:26 2026 +0200 sched_ext: Don't leave balance callbacks queued across a pick retry [ Upstream commit ff0545e0c263727b200f60af47d0364e4d041bde ] The dispatch path can request deferred work to be run from a balance callback and pick_task_scx() queues rq->scx.deferred_bal_cb right after dispatching. However, a balance callback must be consumed before the rq lock is released and pick_task_scx() is not necessarily the end of the pick: - it returns RETRY_TASK when a higher priority class task has been enqueued while the dispatch had the rq lock released; - the dl_server pick can return NULL, in which case the lower classes are picked next. In both cases the callback stays queued while the core keeps picking, and the rq lock can be released again, either by prev_balance() or by another dispatch. For example, with an RT task as prev: __schedule() __pick_next_task() pick_task_scx() dispatch_pick() maybe_queue_balance_callback() <- deferred_bal_cb queued return RETRY_TASK prev_balance() balance_rt() pull_rt_task() double_lock_balance() <- rq lock released Any CPU acquiring the rq lock in that window finds a pending balance callback and triggers the following warning in rq_pin_lock(): WARNING: kernel/sched/sched.h:1919 at rq_lock+0x7f/0xe0, CPU#10: stress-ng-sleep/533 CPU: 10 UID: 0 PID: 533 Comm: stress-ng-sleep Not tainted 7.2.0-rc6-virtme #61 PREEMPT(full) Sched_ext: qmap (enabled+all) Call Trace: try_to_wake_up+0x2c1/0x5c0 hrtimer_wakeup+0x22/0x30 __hrtimer_run_queues+0x1d5/0x350 hrtimer_interrupt+0x106/0x1e0 __sysvec_apic_timer_interrupt+0x6f/0x210 sysvec_apic_timer_interrupt+0x71/0x90 This can be reproduced running scx_qmap -I together with a SCHED_FIFO workload that frequently sleeps, e.g.: $ vng -v --cpus 16 --memory 4G -- \ 'tools/sched_ext/build/bin/scx_qmap -I >/dev/null & \ stress-ng --sleep 4 --sched fifo --sched-prio 1 -t 30 -q' Fix this by queueing the balance callbacks only when the pick is final. Otherwise, defer the pending work to the irq_work path, which doesn't depend on the current rq lock section, and leave the kick sync wait pending for the next pick. Fixes: 4c95380701f5 ("sched/ext: Fold balance_scx() into pick_task_scx()") Cc: stable@vger.kernel.org # v6.19+ Signed-off-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit ba69d35dfdf6c79a102d5ec7de25ab8b18e6a680 Author: Arnaldo Carvalho de Melo Date: Thu Oct 15 22:06:19 2026 -0300 perf python: Free the parse error entries when parsing fails [ Upstream commit 39e0022c89abcdc1a811dfc0aeec2a2b9010b660 ] pyrf__parse_events() prints the entries parse_events_error__print() receives with the details of a failed parse, but returns without freeing them, leaking whatever parse_events_error__handle() allocated, so call parse_events_error__exit() on both paths, as the other parse_events() callers do. The perf test attr core PMU probe takes this failure path on machines without a core PMU, where the leak then happens on every test run. Fixes: f081defccd93 ("perf python: Add parse_events function") Reported-by: Sashiko Closes: https://lore.kernel.org/r/sashiko-outbox-173525@kernel.org Reviewed-by: Ian Rogers Tested-by: Ian Rogers Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5d8167f64801ada091f3275553e394f453d0f1a1 Author: Fuad Tabba Date: Tue Oct 13 09:16:45 2026 +0100 KVM: arm64: vgic-its: Don't map an LPI from more than one event [ Upstream commit de81b28f0b83b22163d7d9a9b708d7aa912e0ef7 ] KVM keeps one vgic_irq per LPI. A MAPTI of an LPI whose vgic_irq already exists reuses it for the new ITE and leaves its target vCPU as it was. Mapping one LPI from two events is UNPREDICTABLE (IHI 0069H.b, 5.2.10), but nothing stops a guest from doing it. If the first MAPTI names a collection the guest never maps and the second a mapped one, the LPI translates through the second event with a NULL target vCPU. When the VMM routes an assigned device's MSI to that event on a host with GICv4 enabled, kvm_vgic_v4_set_forwarding() takes the vPE from the NULL target vCPU and the host oopses: Unable to handle kernel paging request at virtual address 0000000000001980 [...] Call trace: its_build_vmapti_cmd (drivers/irqchip/irq-gic-v3-its.c:943) (P) its_irq_set_vcpu_affinity (drivers/irqchip/irq-gic-v3-its.c:1380) irq_set_vcpu_affinity (kernel/irq/manage.c:670) its_map_vlpi (drivers/irqchip/irq-gic-v4.c:326) kvm_vgic_v4_set_forwarding (arch/arm64/kvm/vgic/vgic-v4.c:485) kvm_arch_irq_bypass_add_producer (arch/arm64/kvm/arm.c:2977) irq_bypass_register_consumer (virt/lib/irqbypass.c:44) kvm_irqfd (arch/arm64/kvm/../../../virt/kvm/eventfd.c:496) kvm_vm_ioctl (arch/arm64/kvm/../../../virt/kvm/kvm_main.c:5270) Track in each vgic_irq whether an ITE maps it. Drop a MAPTI of an LPI that is already mapped, as a failed MAPTI already is. Restoring the ITS tables keeps the first ITE it reads for each LPI and drops any later one, so a guest saved with a double mapping still restores. Key the check on the mapping, not on the vgic_irq. A vgic_irq outlives its ITE while anything holds a reference to it, such as the vCPU it was last queued on. A later MAPTI of such an LPI succeeds as before, and now retargets it to its collection. Fixes: 196b136498b35 ("KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass") Suggested-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Reviewed-by: Oliver Upton Link: https://patch.msgid.link/20261013081646.933312-2-fuad.tabba@linux.dev Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 4d7046b68b9cb14807cccdcc3e3701dadd7c67b6 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 be792ac5a63eba9b4c88104c201cb3644ff1b9b5 Author: José Miguel Castellanos Valladolid Date: Fri Oct 16 23:06:15 2026 -0600 ALSA: hda/realtek: Enable mute LEDs on HP OmniBook X Flip 14-fm0xxx [ Upstream commit c80286aaa4acd52f9bd0b0d4914d2069fe6ba3a8 ] The HP OmniBook X Flip Laptop 14-fm0xxx (subsystem ID 0x103c8d9f, ALC245 with two CS35L41 amplifiers over I2C) is currently handled by ALC287_FIXUP_CS35L41_I2C_2. That binds the amplifiers but does not set up the mute LEDs, so neither the speaker mute key LED nor the microphone mute key LED lights up under Linux. With that fixup the codec GPIOs stay disabled (IO[0..2] enable=0). Switch the entry to ALC287_FIXUP_CS35L41_I2C_2_HP_MUTE_LEDS, which chains cs35l41_fixup_i2c_two with ALC245_FIXUP_HP_X360_MUTE_LEDS. This keeps the amplifier setup and adds the speaker mute LED through the ALC245 COEF register and the mic mute LED through codec GPIO2. It is the same fixup already used for the 17 Turbine OmniBook 7 DIS (0x103c8d9c). Tested on the affected laptop with v7.2.11 using the equivalent ALC245_FIXUP_HP_ENVY_X360_15_FH0XXX fixup, which has the identical cs35l41_fixup_i2c_two + ALC245_FIXUP_HP_X360_MUTE_LEDS chain: hda::mute and hda::micmute LED class devices appear and both key LEDs light up when muting. Fixes: 29951021367f ("ALSA: hda/realtek: Add support for various HP Laptops using CS35L41 HDA") Cc: stable@vger.kernel.org Signed-off-by: José Miguel Castellanos Valladolid Link: https://patch.msgid.link/20261017050615.14481-1-josstamy@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit fe221b7537a7be45b71c07e11b2900e774cd03e4 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 0bbd666d019bc2f32210ccdd90fc1795db9aa85c 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 fe046bec178748cb0fa242bb9c9a3d2b501a57f3 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 9aa68be2b1981a7645872bbab6ef6c9e1e0c213e 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 20b5467b12954359dd65120cbccb63b4083b9931 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 0d503ae692491cfeb09050ea5680ea08f0e9fe54 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 19f130156940d8bcaf8e41aa64a51844abc460da Author: Art O Cathain Date: Fri Oct 16 11:29:30 2026 +0200 ASoC: amd: acp-config: force SoundWire probe on Dell 14S DS14265 [ Upstream commit 38cb2ef26b6411277826da54c6bcf94523541058 ] The BIOS on the Dell 14S DS14265 (ACP PCI revision 0x72) reports acp-audio-config-flag = FLAG_AMD_LEGACY_ONLY_DMIC. As a result snd_pci_ps returns early and the SoundWire links are never scanned, while the legacy snd_acp_pci driver probes the device, finds no matching machine driver ("No matching ASoC machine driver found") and no internal sound card is created. The CS42L45 headset codec on link 0 and the two CS35L63 speaker amplifiers on link 1 never enumerate. Add a DMI entry for the model to the ACP70 ACPI flag override table so the firmware-provided flag is overridden and snd_pci_ps probes instead. Match on the product name rather than the board name, as the same symptom has been reported on several boards of this model (09PVND, 0M0J65, 0C7F12). Tested on a DS14265 (board 09PVND, BIOS 1.5.3) with Debian's 7.2.6 kernel, with and without this entry. With it, snd_pci_ps binds, both SoundWire links come up, the CS42L45 and both CS35L63 enumerate, the existing CS42L45 + 2x CS35L63 machine entry matches, the amplifiers load their firmware and calibration, and the amd-soundwire card plays through both the internal speakers and the headphone jack. Also build-tested on asoc-next with W=1. Developed with AI assistance. Claude read the ACP driver source, identified the BIOS flag as the cause and the override table as the fix, wrote the DMI entry and the out-of-tree test module, and drafted this changelog. All hardware testing was done by the submitter, who has reviewed the change, understands it and takes responsibility for it. Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Art O Cathain Reviewed-by: Vijendar Mukunda Link: https://patch.msgid.link/20261016-dell-14s-acp-v1-1-89b40d95720c@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0602ba498ff402df87f51f779885b8590a1deae9 Author: Sung Byeongchan Date: Wed Oct 7 15:19:49 2026 +0900 virtiofs: validate fixed-output response length [ Upstream commit 5364d081125a34e90851fbb46ecc93f79339ce78 ] A short successful virtiofs response can leave the fixed-output portion of the request argument buffer unwritten. The completion path nevertheless copies the full declared output to the request destination, allowing stale allocator contents to reach callers such as fuse_statfs(). Require successful fixed-output responses to contain their complete declared output. Continue to permit a shorter final argument only for out_argvar requests. Reject positive and internal restart error values and require valid error replies to be header-only. The error already stored in the FUSE output header is returned by fuse_request_end(), so do not copy output arguments from an error reply. This was found by source review with AI assistance. A header-only successful FUSE_STATFS reply returned stale fields in nine of nine calls across three boots. The fixed kernel rejected the short response and preserved complete replies, valid negative-error replies, and variable-output replies. Fixes: a62a8ef9d97d ("virtio-fs: add virtiofs filesystem") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Sung Byeongchan Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 378807887efc5ea53930908c019035c7ff8065c3 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 5f8b531d751ca2998df4fbabf70855408cee5d01 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 1e2420644db8e063944be57365838bca3758bb0f 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 4f3dd4bf2350b11cd44b86b990bcaeb9796cd8c8 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 adc736adbbb6f0675cc67665efab705ff1168334 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 8dab06f17af467d342c86497ffcc81944013dcb0 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 99da78307bfbaf1fca4738175664bd5b1914d346 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 f11bd78beaaa8a01c9bf37c3155cf7f6191ab70c Author: Rosen Penev Date: Sat Oct 10 00:00:11 2026 -0700 net: bgmac: enable interrupts only after NAPI is ready [ Upstream commit ac1f6e58cb77bb66b8811f7d98703e0f076a8f65 ] bgmac_open() calls bgmac_chip_init(), which unmasks the interrupts and enables the MAC receiver, before request_irq() and napi_enable(). bgmac_enet_resume() also enables NAPI only after bgmac_chip_init(). When frames arrive in that window, the first RX interrupt masks all interrupts in bgmac_interrupt() and calls napi_schedule() on a NAPI instance that is still disabled, so nothing is scheduled. Nothing unmasks the interrupts again, the RX ring fills up and the interface stays deaf until it is brought down and up without traffic. On an Asus RT-N16 (BCM4716) a single "ip link set eth0 down/up" while a host sends UDP to the router left INT_MASK at 0, INT_STATUS with RX pending and the RX DMA idle on a full ring, with the RX packet and interrupt counters no longer moving. With this change, 10 of 10 such cycles recovered on their own. Request the IRQ and enable NAPI before the chip is initialized. Fixes: dd4544f05469 ("bgmac: driver for GBit MAC core on BCMA bus") Fixes: f3537b3494c0 ("net: ethernet: bgmac: driver power manangement") Cc: stable@vger.kernel.org Signed-off-by: Rosen Penev Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20261010070011.60403-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c6adad6d0e4daed47728e1e683122833ef476c67 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 98cafb9310ee0e8ad2c72f34f2484dbcb6f5e423 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 230fc648e85bea394e6b7b7e12102308438f82f4 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 1402ffd54f2f338b91f4f1765b43e33d107892a3 Author: Henry Martin Date: Mon Oct 12 10:53:36 2026 +0800 rds: fix out-of-bounds conn_path walks via handshake exthdrs [ Upstream commit 50f2103fce43922b6e562937b2d2fc62089ff7ec ] Both the lane and the connection-generation negotiation are driven by extension headers in handshake packets, and both are processed unconditionally, even on transports that are not multipath capable. A non-MP connection (t_mp_capable unset) owns exactly one rds_conn_path slot, so a peer claiming up to RDS_MPATH_WORKERS lanes makes every subsequent fan-out walk conn->c_path[0..7] at 504-byte strides past the single allocated slot (KASAN: "Read of size 8 in rds_conn_path_connect_if_down"); the generation negotiation opens a similar out-of-bounds walk on the same array. Only process handshake extension headers when the connection's transport is multipath capable, so a peer can never make us walk lanes that do not exist. Both call sites in rds_recv_incoming() are gated. This is a port of the Oracle UEK fix for the same issue, picked up where Paula's series of the same change left off. This issue was discovered by Tencent CodeBuddy Security. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/netdev/20260825120132.51636-1-pamoutafpro@gmail.com/ Link: https://github.com/oracle/linux-uek/commit/2fdeb0513f18 Fixes: 840df162b3eb ("rds: reduce memory footprint for RDS when transport is RDMA") Fixes: 905dd4184e07 ("RDS: TCP: Track peer's connection generation number") Signed-off-by: Henry Martin Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20261012025336.54756-1-bsdhenrymartin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5fe6757584ab7fdeeb2bbd3b82120769dcdbacd9 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 301e34ccf9a63705a197904ccc03e9eaaf442a37 Author: Ming Lei Date: Sun Oct 11 01:35:50 2026 -0500 ublk: let STOP_DEV cancel the server's commands before its release [ Upstream commit c8b349f9daf6d88ff21033028167d00e819dafb6 ] STOP_DEV cancels the fetched commands after dropping ub->mutex, so START_DEV and FETCH can run in between: STOP_DEV START_DEV / FETCH lock ub->mutex ublk_stop_dev_unlocked() (not started: does nothing) unlock ub->mutex START_DEV goes live, schedules scan FETCH publishes a new command cancel_work_sync(scan) cancels the new disk's scan ublk_cancel_dev() takes the new command: NULL io->cmd on a queue which isn't canceling A START_DEV after STOP_DEV also goes live over the canceled commands. Hold a reference on the server's /dev/ublkcN while canceling: STOP_DEV lock ub->mutex ublk_stop_dev_unlocked() cancel_work_sync(scan) server attached: take a reference on its file, set STOPPING unlock ub->mutex ublk_cancel_dev() drop the reference - STOPPING makes FETCH and PREP get UBLK_IO_RES_ABORT and START_DEV -EBUSY; a START_DEV or END_USER_RECOVERY waiting for the device to get ready wakes up too; the reset in the server's release clears it - the release can't run before the reference is dropped, so no new server can attach, and the cancel only meets this server's commands - the cancel still runs after the unlock: io_uring_cmd_done() may take uring_lock, under which FETCH takes ub->mutex ublk_ch_open() saves the file in ->ch_file and ublk_ch_release() clears it, under cancel_mutex. The release runs after the last reference is gone, so take ours with file_ref_get(). Drop it with __fput_sync(): if it is the last one, fput() would defer the release to this task, which DEL_DEV then makes wait for the device to be freed. A server which opened the device but hasn't fetched is stopped too. Document what a server sees after STOP_DEV in ublk.rst. Fixes: 85248d670b71 ("ublk: move ublk_cancel_dev() out of ub->mutex") Cc: stable@vger.kernel.org Reported-by: Josef Bacik Closes: https://lore.kernel.org/linux-block/20260928-b4-ublk-cancel-stop-v1-0-4a4360232a46@toxicpanda.com/ Tested-by: Josef Bacik Signed-off-by: Ming Lei Link: https://patch.msgid.link/20261011063555.1142277-8-tom.leiming@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f6dca20655bf1638dc27b0ed90bd6079e99028c8 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 30638a05c1639f7a57807d228c914b1f5c099de7 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 de0967c9aa6bb63d30e835c79fd935310f30402b Author: Ming Lei Date: Sun Oct 11 01:35:46 2026 -0500 ublk: mark the batch fetch command cancelable before linking it [ Upstream commit b59e96011d22e322fbf4d5d1d1124de538c278ed ] UBLK_U_IO_FETCH_IO_CMDS has the same order problem as the per-io commands: ublk_batch_attach() links the fetch command into fcmd_head and marks it cancelable only after dropping evts_lock. A cancel from the control path (ublk_batch_cancel_queue()) can take it in between and complete it, and the later mark puts a completed request on io_uring's cancelable list. Mark it before linking it. evts_lock orders the mark before the link, which is where the cancel finds it. Batch commands are not bounced to task work, so they can run from io-wq without uring_lock, and io_uring's cancel walk can now find a fetch command before it is linked. Two things make that safe: - initialize fcmd->node: it came from kzalloc(), so list_empty() saw a linked node and ublk_batch_cancel_cmd() would list_del_init() NULL pointers - on the -ENODEV path, complete the command with io_uring_cmd_done() before freeing fcmd: that removes it from the cancelable list under uring_lock, after which nothing can see fcmd Also use data->cmd instead of fcmd->cmd after dropping evts_lock: once fcmd is linked and not the active one, a control-path cancel may complete and free it. Fixes: a4d883755399 ("ublk: add UBLK_U_IO_FETCH_IO_CMDS for batch I/O processing") Cc: stable@vger.kernel.org # v7.0+ Tested-by: Josef Bacik Signed-off-by: Ming Lei Link: https://patch.msgid.link/20261011063555.1142277-4-tom.leiming@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9a735ee97f7f381374cf10e53acc4c97829c8939 Author: Ming Lei Date: Sun Oct 11 01:35:45 2026 -0500 ublk: mark the io command cancelable before publishing it [ Upstream commit a261f0cacacc022e4fab5b8e38c59f74ce4942e8 ] FETCH, COMMIT_AND_FETCH and NEED_GET_DATA publish the command in io->cmd before marking it cancelable. A cancel from the control path (STOP_DEV, QUIESCE_DEV) can complete it in between: issue path control-path cancel io->cmd = C take C, io_uring_cmd_done(C): C not marked, nothing to unlink ublk_prep_cancel(C) the completed C is linked on the cancelable list ring exit: the cancel walk hits it → GPF (KASAN, with a delay added) Mark the command before ublk_fill_io_cmd() publishes it. The handlers run with uring_lock held, as io_uring's cancel walk does, so marking takes no lock and the walk can't see a marked command before it is published. smp_wmb() orders the mark before the io->cmd store; the cancel loads cmd with READ_ONCE(io->cmd) before reading cmd->flags. A marked command has to be completed by io_uring_cmd_done(), so a failed FETCH and the inline UBLK_IO_RES_OK of NEED_GET_DATA now do that. The CQE is the same. Fixes: 216c8f5ef0f2 ("ublk: replace monitor with cancelable uring_cmd") Cc: stable@vger.kernel.org Tested-by: Josef Bacik Signed-off-by: Ming Lei Link: https://patch.msgid.link/20261011063555.1142277-3-tom.leiming@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1f866a06b65ec13d37767843d2e991df2dcd1a00 Author: Ming Lei Date: Sun Oct 11 01:35:44 2026 -0500 ublk: keep a canceled FETCH round canceling until the server is gone [ Upstream commit 4c454b5b2634d982caf797fbe477770c3edfc983 ] A cancel completes a fetched io command and sets io->cmd to NULL, but the io still counts as ready. Only ubq->canceling stops ublk_queue_rq() from using the NULL io->cmd. Two paths clear that flag too early: partial FETCH round recovery, two queues ------------------- -------------------- task A: FETCH tags 0-2 q0 ready: q0->canceling = false task A exits: q0 task exits: start_cancel(): mark queues start_cancel(): ub->canceling tags 0-2: io->cmd = NULL is still set -> q0 not marked task B: FETCH tag 3 q0: io->cmd = NULL queue ready: canceling = false q1 ready START_DEV END_USER_RECOVERY read -> ublk_queue_cmd(NULL) read on q0 -> ublk_queue_cmd(NULL) A FETCH round runs from the open of /dev/ublkcN until ublk_reset_ch_dev() resets the queues. A canceled command can't be fetched again in the same round. So the ready check only needs one fact: did this round see a cancel? ub->canceling already records it: ublk_start_cancel() sets it under cancel_mutex before any command is taken. It is only cleared too early, when all queues are ready. Fix: - clear ub->canceling only in ublk_reset_ch_dev() - when a queue gets ready, clear ubq->canceling only if ub->canceling is not set, and check it under cancel_mutex The check and the marking are ordered by cancel_mutex: check first: queue cleared -> start_cancel() marks it again -> command taken cancel first: check sees ub->canceling -> queue stays canceling While ub->canceling is set, no queue clears its flag. So the "all queues marked" shortcut in ublk_start_cancel() is correct again. UBLK_F_BATCH_IO follows the same rule. It does not dispatch through io->cmd, so it never hit the oops, but a round which lost a fetch command is treated the same way: it has to start over. Fixes: 728cbac5fe21 ("ublk: move device reset into ublk_ch_release()") Fixes: 3f3850785594 ("ublk: fix batch I/O recovery -ENODEV error") Cc: stable@vger.kernel.org # v6.17+: needs cancel_mutex Reported-by: Josef Bacik Closes: https://lore.kernel.org/linux-block/20260928-b4-ublk-cancel-stop-v1-0-4a4360232a46@toxicpanda.com/ Tested-by: Josef Bacik Signed-off-by: Ming Lei Link: https://patch.msgid.link/20261011063555.1142277-2-tom.leiming@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 60a8dd118843c329d6142fb72a836f6b3dd25ebf Author: Yun Zhou Date: Thu Oct 8 17:38:24 2026 +0800 net: erspan: set lltx to avoid sch_direct_xmit deadlock [ Upstream commit 2d36ec73836e83175deb467fd494c61006107e5d ] The ERSPAN xmit path re-enters the network stack, causing nested acquisition of _xmit_lock on the underlay device while already holding the ERSPAN device's _xmit_lock, creating an ABBA deadlock. This happens for both IPv4 ERSPAN (erspan_xmit() -> ip_tunnel_xmit()) and IPv6 ERSPAN (ip6erspan_tunnel_xmit() -> ip6_tnl_xmit()): sch_direct_xmit [lock erspan] -> erspan_xmit -> ip_tunnel_xmit -> ip_output -> __dev_queue_xmit -> sch_direct_xmit [lock underlay] sch_direct_xmit [lock erspan] -> ip6erspan_tunnel_xmit -> ip6_tnl_xmit -> ip6_output -> __dev_queue_xmit -> sch_direct_xmit [lock underlay] Set dev->lltx = true so HARD_TX_LOCK() skips the spinlock for ERSPAN. This is safe as the ERSPAN xmit path has no shared mutable state: o_seqno is atomic, TX stats are per-CPU u64_stats, dst_cache is per-CPU, and o_flags is no longer modified in the xmit path since commit 9958e69b9893 ("gre: fix ERSPAN o_flags race/corruption in xmit and fill_info"). GRETAP, the sibling device with identical xmit structure, already sets lltx. Reported-by: syzbot+9bda1b9fbb7fbdf9b62b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9bda1b9fbb7fbdf9b62b Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN") Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support") Cc: stable@vger.kernel.org # 9958e69b9893 ("gre: fix ERSPAN o_flags race/corruption in xmit and fill_info") Cc: stable@vger.kernel.org Signed-off-by: Yun Zhou Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20261008093824.119453-1-yun.zhou@windriver.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 672edf91f76002a871849acd8303d4f9713b1245 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 5f5800d075bf4a8fbc0eca136b47373b5bb1b7a9 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 04162e64f014b90acc5745b28d194eaf596da168 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 f6ce7362b698927e35ed3c3fcf52f0b982201676 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 aed497051d5cf8e0a6b0afa18211e8d7c19c97e1 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 f64e8fccdf73e03a9a42e548a2f894e4c689c5c3 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 2be7a1a3af0680691f195dd8a3e0d08c8dfed223 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 25ce0404c9f72295aef347f6c071cf8378f5b679 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 b81d6ed1e542dbe7204138fd0acf502aa8299b02 Author: Jason Gunthorpe Date: Wed Oct 14 21:38:40 2026 -0300 iommupt: Do not allow PTEs to be split when dirty logging [ Upstream commit 04bcf84613346b973a8cc0c59238b6b5bc902688 ] If a single PTE cannot be stored in the current bitmap that should be a failure and reported back to userspace. Allowing a PTE to be split creates a possibility that dirty memory will be reported as clean. The gather must also cover the entire PTE that is being cleaned, not just the part that fits within the bitmap. Fix both issues by computing the full IOVA range of every PTE and using that to update the bitmap and the gather. The bitmap code now rejects ranges that don't fit in it, and the gather always combined ranges. The selftest quietly relied on a bug where the CONT was split, that is why the half page size for the mock domain saw alternating dirties. Increase the dirty test page size to PAGE_SIZE so it still works as intended. Cc: stable@vger.kernel.org Fixes: 4a00f9434891 ("iommupt: Add read_and_clear_dirty op") Reported-by: Samarth Narang Closes: https://lore.kernel.org/all/20261013165814.309255 Link: https://patch.msgid.link/r/0-v1-5bb926ff73ec+576-iommufd_dirty_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 833cfd0e4a7b75928391c5a7c13ed84eb8095ba4 Author: Vladyslav Tymoshchuk Date: Wed Oct 14 19:27:02 2026 +0300 ASoC: qcom: q6asm-dai: wrap the position of a full ring to 0 [ Upstream commit 222d04cf55bc5b4b63602454014619c78deda89a ] Commit 44432315444c ("ASoC: qcom: q6asm-dai: use q6asm_get_hw_pointer") took the position from the number of period buffers the DSP has returned in the current lap, 1..periods, and reports one frame less than that, as q6apm-dai does. One frame short, a playback stream whose application stops feeding it never reaches the stop threshold: the DSP returns the last queued buffer, the position stops at appl_ptr - 1 and no period interrupt comes any more, so ALSA never detects the underrun, the stream stays RUNNING and drain only ends on its timeout. On capture, the last frame of each period is held back until the next one. Before that commit the position wrapped to 0 at the end of the ring. Do that again, as for q6apm-dai. Fixes: 44432315444c ("ASoC: qcom: q6asm-dai: use q6asm_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-4-tvlad744@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit de31979f3169960fc8f2bf57547fcddca15cc6f8 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 b009e247f27d7d831fc05c814be80992efef0fd1 Author: Vladyslav Tymoshchuk Date: Wed Oct 14 19:27:00 2026 +0300 ASoC: qcom: q6apm-dai: wrap the position of a full ring to 0 [ Upstream commit 0ea3e0b196f9dcc17b40ac881a6efef06459975b ] q6apm_dai_pointer() turns the number of period buffers the DSP has returned in the current lap, 1..periods, into a position and reports one frame less than that. Commit a93dad6f4e6a ("ASoC: q6apm-dai: make use of q6apm_get_hw_pointer") added the "- 1" so that the end of the ring is not reported as a position equal to the buffer size. One frame short has a cost once the application stops feeding the stream. The DSP returns the last queued buffer and the position stops at appl_ptr - 1, so avail stays at buffer_size - 1, below the default stop_threshold. The DSP sends nothing more as its queue is empty, so no period interrupt comes either: ALSA never detects the underrun and the stream stays RUNNING. A poll-driven application that missed its last wakeup waits forever, and drain only ends on its timeout, with -EIO. On capture, the last frame of each period is held back until the next one. Before that commit the position wrapped to 0 at the end of the ring. Do that again. A full lap is the start of the ring, and snd_pcm_update_hw_ptr0() accounts for the wrap: the position cannot move by more than one lap between two updates, as each returned buffer calls snd_pcm_period_elapsed() and the DSP holds at most periods buffers. Seen on a OnePlus Pad 3 (SM8750) with PipeWire in interrupt-driven scheduling: after a stall the PCM sat at hw_ptr 78239, appl_ptr 78240 (avail 3839 of 3840) for two hours. 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-2-tvlad744@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9be904fdb42eec5cde37587958f585e76be6f487 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 afa8760725ff9fa22125e4461a8564a3d58e715c 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 63d3cd4810577cb5c84816c3a1397a9acbf4e6fe 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 f000f7c016e87e14700b552106c111da1167d42e Author: Guixin Liu Date: Tue Sep 22 16:22:14 2026 +0800 cxl/events: Test CME counter expiry with equality, not bitwise AND [ Upstream commit b94ba9a1f2d5c57f2eec67d502bb8fdd1e53c87a ] The Memory Event Type field in the General Media and DRAM event records is an enumeration, not a bitmask. The validity checks for the advanced programmable CME counter expiration event (05h) test the field with a bitwise AND, so types 01h, 03h, 04h and 06h match it as well. A device reporting one of those types trips WARN_ON_ONCE once the general media or DRAM tracepoint is enabled, which is the case anywhere rasdaemon collects CXL events. Under panic_on_warn=1 that kills the machine. Compare the type field for equality instead. Type 05h records that do violate the spec conditions still warn. Fixes: cd3b36cfc659 ("cxl/events: Add extra validity checks for corrected memory error count in General Media Event Record") Fixes: d8145bb8af5c ("cxl/events: Add extra validity checks for CVME count in DRAM Event Record") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Guixin Liu Reviewed-by: Dave Jiang Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260922082214.3526355-1-kanie@linux.alibaba.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 0f4e9b6b9013b33cd3566fb8ff0c2372a37d63fd Author: Alexey Charkov Date: Thu Oct 1 17:30:23 2026 +0400 mfd: bq257xx: Mark self-modifying BQ25792 registers volatile [ Upstream commit 56d974f3ad074a60bf877d131eab8b1df5b4f069 ] Some BQ25792 configuration registers change without being written: input source detection sets VINDPM and IINDPM at plug-in, plug-in also clears EN_HIZ, the FORCE_* bits clear once their operation starts or completes, EN_ACDRV1/2 follow input path changes, and ADC_EN clears after a one-shot conversion. Reading them from the cache returns stale values. Mark these registers volatile, keeping the cache for the rest. Cc: stable@vger.kernel.org Fixes: 9adbe53e32cd ("mfd: bq257xx: Add BQ25792 support") Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20261001-bq25792-volatile-v1-1-cb3d4ec8a414@flipper.net Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 07b9c1c9c9cac5e80725e1822631091d2a31681f 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 ce46af845eb296dbc9f451376932d026587c3eaf 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 38f27e0f70f8676ab1ed05c89de61c7d0cdcf52a 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 da4d9aecba3ce30f3e5b1ff26fc905d2c819a754 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 8a5f8c37e2421a3b32bb46215ab1d810e728ac3f Author: Marc Zyngier Date: Thu Oct 15 11:05:33 2026 +0100 KVM: arm64: nv: Move L2->L1 switch on interrupt early [ Upstream commit 21d3b33234ebbb675c2a2a0fa7b12d2d83953d7a ] NV request generation to switch from L2 to L1 on interrupt is buried into the vgic flush code, while we should be able to deliver requests as early as possible. Similarly, MI generation happens *after* the need for a request has been evaluated, which means we potentially delay the maintenance interrupt by a full exit/entry cycle. Move these two things to happen much earlier in the entry code, and make sure the MI generation and PMU interrupt serve as input to the request switching back from L2 to L1. Cc: stable@vger.kernel.org Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Link: https://patch.msgid.link/20261015100539.1011760-2-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 9c3e64f218565bf292c21ae60cd35dd724baf0eb 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 5e6191a21eb452d5cb52c4736ac2217f3664fea8 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 1b8f9d14d2961f894035e3246307cf32fca52c30 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 128ddc3d25fbc8c1827767f9f89440e6b365404e 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 d6c8accea384d3ab39593104c1d55ed29a732dfd 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 a2a15ed9442aeea03f69be404a58cac4ac1407ef Author: Au Dang Date: Wed Oct 14 11:59:22 2026 +0200 irqchip/renesas-rzv2h: Preserve TIEN state in rzv2h_tint_set_type() [ Upstream commit 42bedd4af8cd50c32a1560d8744bd22d25be79cc ] rzv2h_tint_set_type() clears TIEN while switching the TINT source and then unconditionally sets it again, enabling the interrupt even if it was disabled before the call. Restore the previous TIEN state instead of forcing it on. Fixes: 0d7605e75ac2 ("irqchip: Add RZ/V2H(P) Interrupt Control Unit (ICU) driver") Signed-off-by: Au Dang Signed-off-by: Tommaso Merciai Signed-off-by: Thomas Gleixner Reviewed-by: Biju Das Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261014095927.635132-1-tommaso.merciai.xr@bp.renesas.com Signed-off-by: Sasha Levin commit 7c34aa8067faefc29a11b65a41660c5b45b4fd02 Author: Karl Mehltretter Date: Mon Sep 28 05:54:08 2026 +0200 irqchip/jcore-aic: Fix lost IPIs on SMP [ Upstream commit f556f008f704a8777c73fb3a4177dc57c0dbe769 ] Since commit bdf4e2ac295fe ("genirq: Allow per-cpu interrupt sharing for non-overlapping affinities"), handle_percpu_devid_irq() only runs an action whose affinity mask contains the current CPU. Only actions set up through the percpu_devid request functions have such a mask. handle_jcore_irq() passes every per-CPU interrupt to handle_percpu_devid_irq(). The J2 IPI is not a percpu_devid interrupt. j2_prepare_cpus() requests it with request_irq() and IRQF_PERCPU, so its action has no affinity mask and cpumask_test_cpu() reads through a NULL pointer. J2 has no MMU to catch this. The read returns whatever is at address 0, the action is not found, and IPIs are dropped as spurious ("Spurious percpu IRQ20 on CPU1", printed once). Pass only percpu_devid interrupts (the PIT) to handle_percpu_devid_irq() and the other per-CPU interrupts to handle_percpu_irq() again, as before commit d7e3fd658248f ("irqchip/jcore-aic, clocksource/drivers/jcore: Fix jcore-pit interrupt request"). Found with a two-CPU J2 model simulated from the J-Core RTL. Without this change the boot stalls with both CPUs idle shortly after "smp: Brought up 1 node, 2 CPUs". With it, the boot reaches userspace. Fixes: bdf4e2ac295fe ("genirq: Allow per-cpu interrupt sharing for non-overlapping affinities") Signed-off-by: Karl Mehltretter Signed-off-by: Thomas Gleixner Assisted-by: LLM Tested-by: John Paul Adrian Glaubitz Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260928035408.25871-1-kmehltretter@gmail.com Signed-off-by: Sasha Levin commit 508cb3b25e0d0ffa6075539954743e55a0befce8 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 4f650d3593cf547904f6678d9495932e88b55a13 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 75badbcc1d85260b187a2e0cddf2e7a19555755d 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 46b4c2e599cafa95448e60ce74f4d57d19ca29df 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 0ef0d14f1b2641e274599c82e639f50facac2d8d 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 486ed582d83aa64c4f7c25823944ea761c5d0036 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 e23a825dcd530dd00142013c8ff4c8911075dd53 Author: Zhang Heng Date: Thu Oct 15 14:56:40 2026 +0800 ALSA: hda/realtek: Fix quirk for HP Laptop 15-fc0xxx [ Upstream commit 044d41b43ee19aa29cb0c9b7b8e77fd113336522 ] The HP Laptop 15-fc0xxx is based on an AMD platform where the digital microphone is provided by the snd-soc-acp6x-mach driver, not by the HDA codec. The ALC236_FIXUP_HP_DMIC quirk configures pin 0x12 as an internal DMIC, which is a misconfiguration for this machine: the pin is not wired to a codec DMIC and the setting has no effect on the actual microphone path (which works via ACP6x). Replace ALC236_FIXUP_HP_DMIC with ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO, the standard quirk used by the closely related HP Laptop 15-fd0xxx and other ALC236 HP machines. This removes the misleading DMIC pin config and adds proper mute LED and micmute LED support that was missing from the original quirk. Fixes: 720460722310 ("ALSA: hda/realtek: add quirk for HP Laptop 15-fc0xxx") Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221233 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222044 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20261015065640.377466-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ea425c0036977ce0a7d73fc183af787f17a7e011 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 41a4026054ceed3539efa18e92cf6ac6282d5c7b Author: Andrea Parri Date: Thu Oct 8 14:52:03 2026 +0200 iommufd: Keep dmabuf PFNs MMIO when filling another domain [ Upstream commit 769f2cd9226c96619d77fa16af84de74cae41b6b ] A VFIO PCI dmabuf mapped into an IOAS is mapped with IOMMU_MMIO only in the domains present when it is mapped. A domain added later, or a copy of the area into another IOAS, maps the same BAR as cacheable CPU memory: IOMMU_CACHE set and IOMMU_MMIO clear. Once the area is in pages->domains_itree, pfn_reader_fill_span() reads its PFNs back from the storage domain through batch_from_domain(), which adds them with batch_add_pfn() as BATCH_CPU_MEMORY. Only a hole in the span reaches pfn_reader_fill_dmabuf() and gets BATCH_MMIO, so batch_to_domain() programs the later domain with the wrong prot. The effect depends on the page table format. io-pgtable-arm maps the BAR as Normal cacheable instead of Device memory, the AMDv1 and x86_64 generic_pt formats set the SME C-bit on it when the tables are encrypted, and the RISC-V format with Svpbmt maps it as normal memory instead of IO. Read dmabuf PFNs from the recorded phys for every span, before the xarray and domain paths. The phys range is always available, and the read-back from a domain only serves to avoid re-pinning user pages. Sashiko pointed this out while reviewing an RFC that plumbs the dma-buf memory type through pfn_reader_fill_dmabuf(). Fixes: 74014a4b55f5 ("iommufd: Have pfn_reader process DMABUF iopt_pages") Reported-by: Sashiko Link: https://lore.kernel.org/all/20260716154123.32DC01F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Andrea Parri Link: https://patch.msgid.link/20261008125206.11990-2-parri.andrea@gmail.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ac7f472073dca70f8417914cf4771c95a5603ec1 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 ed418a016661619c2a91fbf5e4e8599a5c7fbadf 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 0edbb8c8f86b9468de3004e3209c0d7eed6df61e 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 ad9fe095e539f2f2d76a2bc49dd7662596997973 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 a6a8d864fc7106aa997cb3ef4adc1ff9c5ea6a79 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 9d4586b143573de4c40db1036cb23a560f149473 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 cd90c2ddfb097d3d9bbeae9e5eb30ef6aff86e14 Author: Bui Viet Dung Date: Thu Oct 8 12:18:03 2026 +0700 Bluetooth: selftest: Pin module for selftest debugfs file operations [ Upstream commit 64aabf94ecccb1120a63b4ee5a6761871a181a41 ] An open debugfs file retains its file_operations pointer in the debugfs proxy state. However, test_smp_fops in net/bluetooth/smp.c and test_ecdh_fops in net/bluetooth/selftest.c have no .owner set to THIS_MODULE. As a result, full_proxy_open_regular() calls fops_get() which succeeds without taking a reference to the bluetooth module. When CONFIG_BT=m and selftests are enabled, a userspace process can open either /sys/kernel/debug/bluetooth/selftest_smp or /sys/kernel/debug/bluetooth/selftest_ecdh and keep the file descriptor open while the module is unloaded (rmmod bluetooth). 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/smp.c and net/bluetooth/selftest.c. Set .owner = THIS_MODULE on test_smp_fops and test_ecdh_fops so that debugfs keeps the module pinned until the file descriptors are closed. Fixes: 64dd374eac15 ("Bluetooth: Export SMP selftest result in debugfs") Fixes: 6de50f9fdb60 ("Bluetooth: Export ECDH selftest result in 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 a7bfa8581b164d70a53f59f52ffd3c14e47a5d28 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 84b394b08479967219bfd5a3544599912333a947 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 5e0ac62635fe2edd1b6de06ebe548810a2944184 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 9364131a08b4a60b05bd471ef268cd2e960ee2a9 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 c0b372282f98d50ed63d692e557d2b18b68878a4 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 2c5e9d8f59b7b3e72a3c967feea8da867f2d399a 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 15af74af69b33491b57834f5fbdf9a0614a1a5e0 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 3bf57313aff0b36d738f9e361e10c0161d8554a0 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 5f30d03459766088a58fbfbb7a087fdcc2db63f0 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 20b0685790775cd5152288405226bc8282a5f756 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 574b38e228032bbb8aea210e47347a5d64fcd498 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 6dd268f4d8f36cc20da6ce81408c5ddd046cd849 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 3e66dd2aafe80e63b62a57285a89b55d6c98fa63 Author: Weibin Liu Date: Tue Sep 29 16:11:44 2026 +0800 spi: cadence-xspi: reject SDMA transfers larger than the requested length [ Upstream commit ea9854a169e9c1437df8829bea21c2f2e80b137c ] The XSPI controller reports the size of the slave-DMA transaction through SDMA_SIZE_REG. Both SDMA handlers take this register at face value and copy the reported number of bytes between the SDMA FIFO and the transfer buffers, without checking it against the length of the transfer that was actually requested. While cdns_xspi_adjust_mem_op_size() clamps the size of the operations issued by the SPI core, the device can still report a bigger SDMA size than what was programmed, which makes the handlers read from or write to memory beyond the end of the transfer buffers. Track the number of bytes requested for the current data phase in a new sdma_xfer_len field, set by cdns_xspi_send_stig_command() and by the Marvell b0 transfer path, and reject any SDMA size that exceeds it. Fixes: a16cc8077627 ("spi: cadence: add support for Cadence XSPI controller") Cc: stable@vger.kernel.org # 5.16+ Signed-off-by: Weibin Liu Link: https://patch.msgid.link/20260929081146.41041-2-liuwb@xiaopeng.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4d99432f944bb1947a1d7a90b39e6cad13f0fb31 Author: Guangshuo Li Date: Thu Sep 24 22:43:55 2026 +0800 mfd: ab8500: Fix child device leaks on probe failure [ Upstream commit 5bf2ae8b131d4ae9c0ed5f7aa02532645f512022 ] ab8500_probe() registers MFD child devices before completing the remaining device initialization. If a later MFD registration or sysfs group creation fails, previously registered child devices are not removed. Use devm_mfd_add_devices() so registered MFD child devices are removed when probe fails. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: cca69b67b3ba ("mfd: Export ab8500 chip id to sysfs") Fixes: 9c717cf3fa16 ("mfd: ab8500-core: Add device for new RTC version for AB8540 cut2") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260924144355.1604369-1-lgs201920130244@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit d13aa384a56ed261d9ffa713e4e7a3085a0deac4 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 9e76fa6165f4e4fe0bbca41c9f60ffa52dee0ba5 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 f165d50c106fc6d97bb1288a6b89948bfb949796 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 3f1195712274f45ee5cd03d23c056d042e78b007 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 7a74f375e55dbe9d505a0ac274bfda670322142c 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 86e5bd2e911ad9aeb0c2d87d275a671a405d1faa 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 37fcc4cb3620bbeaa48c345845e835f356780644 Author: Ferry Toth Date: Sat Oct 10 21:37:56 2026 +0200 Revert "serial: 8250_port: Drop duplicate NULL check" [ Upstream commit 6ae994d513a6ace5462137e1025a4e7086b87348 ] This reverts commit 7885af04df6e4efd72910200c1bfc079d61202e4. Commit 7885af04df6e ("serial: 8250_port: Drop duplicate NULL check") added `up->dma = NULL;` to serial8250_release_dma(), with the stated intent of making sure DMA would not be used again after release. However, up->dma is assigned once at probe time. serial8250_do_startup() only calls serial8250_request_dma() when up->dma is non-NULL, so after the first close the pointer stays NULL and DMA is never re-acquired. On Intel Tangier (Edison) with HSU DMA this causes a regression: the first port open uses TX DMA, the second and later opens transmit in PIO mode, producing 64-byte FIFO bursts with ~50us gaps between them. Fixes: 7885af04df6e ("serial: 8250_port: Drop duplicate NULL check") Cc: stable@kernel.org Signed-off-by: Ferry Toth Acked-by: Andy Shevchenko Link: https://patch.msgid.link/20261010193755.187706-2-ftoth@exalondelft.nl Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3a58b317d7f38484339391050a575c423dd255c8 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 3d213f8b4d01b29cbca789a13bdf6d0a6fd34b19 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 16ca1aac1c3dbfb77633fee2b7fe2c206f332e64 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 fc919c299012965110fd989d6a0d44aed24a0070 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 7050557f467b62d7573b8125d21c5bfb6f6b5b7d 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 05d4e475dd20bcc3b50c243f30e8177b15e4656a 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 c32fadf0c7b371fc9874f4799e0787a948b94288 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 7f0c621d6a94dcf65c9af9af37063f5235170714 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 8c3b84ec054568a457fcdf8780ff2cc8af55e481 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 bbdfd2dbb2e4b2b7eaea52ba08113be1b87450db Author: Rudi Heitbaum Date: Mon Sep 14 12:35:31 2026 +0000 PCI: imx6: Avoid dereferencing a NULL clock name [ Upstream commit e60d0d4dfddfac3058753a1c2255251401c92dad ] of_clk_bulk_get() leaves 'clk_bulk_data->id' as NULL for every clock that has no matching entry in "clock-names", which is legal: a node may list more "clocks" phandles than it names. Both scans of the bulk array dereference that id unconditionally, so such a node oopses during probe. The loop in imx_pcie_probe() has been wrong since it was written. The loop in imx_setup_phy_mpll() was not: it read a fixed clks[] whose ids came from the driver's own clk_names[] and were never NULL, and only became wrong when the driver moved to the bulk array. Check 'clk_bulk_data->id' before dereferencing it in both. Fixes: f6a1fdfc78e2 ("PCI: imx6: Use devm_clk_bulk_get_all() to fetch clocks") Fixes: d8574ce57d76 ("PCI: imx6: Add external reference clock input mode support") Signed-off-by: Rudi Heitbaum Signed-off-by: Manivannan Sadhasivam Acked-by: Richard Zhu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/am8iBwJSEhYhWTqk@6cfee64030a6/ Link: https://patch.msgid.link/aqfqE4OLhnN4a1lW@b65e9c1eb12f Signed-off-by: Sasha Levin commit f380b4b0765fa984c74ba550ab238c82dbbe9d48 Author: Iván Ezequiel Rodriguez Date: Tue Oct 13 17:42:19 2026 -0300 ALSA: hda/realtek: keep headset mic on Acer SSID 0x1640 [ Upstream commit b23012149ca8e7a9c7c72e93b7639ca2a282d6b1 ] The micmute-LED quirk for the Aspire A315-44P matches PCI SSID 1025:1640 before the Acer ALC256 pin fallback. The Aspire Go 15 AG15-42P shares that SSID and leaves nid 0x19 as 0x411111f0, so selecting the LED-only fixup drops the headset-mic pin remap that the fallback would have applied. Chain ALC2XX_FIXUP_HEADSET_MIC before the GPIO3 micmute LED on that SSID. Leave the Swift SFG16 entry (0x169a) unchanged. Tested on Acer Aspire AG15-42P (Callisto_BCU): PCI pick 1025:1640, Headset Mic=0x19, GPIO3 enabled with no physical micmute LED, speaker and capture paths functional. Fixes: d830631a128b ("ALSA: hda/realtek: Add micmute LED quirk for Acer Aspire A315-44P") Cc: stable@vger.kernel.org Signed-off-by: Iván Ezequiel Rodriguez Link: https://patch.msgid.link/20261013204219.9649-1-ivanrwcm25@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c5df526d244ac04311509609daaad1ed141e040a 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 94fdb7fd31f95467fbba9770ce3a5812ec03c645 Author: Gergo Koteles Date: Tue Oct 13 15:02:20 2026 +0200 ALSA: hda/tas2781: Assign total_sz at the end of the function [ Upstream commit 35911ab70c41957b4a8ac972af137a8e5ccbe259 ] In the tas2563_save_calibration() function, cd->total_sz is assigned in several error paths. Move the assignment to the end of the function. Fixes: b6016332b889 ("ALSA: hda/tas2781: clear cali_data.total_sz when calibration read fails") 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/4b357778dce1b70a647e7e47b5ab3f0a6b2fc0cc.1791895478.git.soyer@irl.hu Signed-off-by: Sasha Levin commit 543c0f3386e41326f1b1f4a3b52f97bad3663487 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 bf8a21fb049f55804d9a5ad7cf864e71697df0cc Author: Giorgi Kobakhia Date: Tue Sep 22 13:21:59 2026 -0700 ocfs2: fix array out of bound access in __ocfs2_find_path() [ Upstream commit 6193ce7896afb52a321a0063c8b6a45e477a84e2 ] __ocfs2_find_path() walks down the extent tree and records path by calling find_path_ins(), which appends entry to path->p_node[]. It only has 5 spots. A corrupted ocfs2 image whose extent block is pointing to itself causes __ocfs2_find_path() descent endlessly, writing past the end of path->p_node[] array. UBSAN: array-index-out-of-bounds in fs/ocfs2/alloc.c:677:14 index 5 is out of range for type 'ocfs2_path_item [5]' Call Trace: find_path_ins (fs/ocfs2/alloc.c:677 fs/ocfs2/alloc.c:1914) __ocfs2_find_path.constprop.0 (fs/ocfs2/alloc.c:1882) ocfs2_commit_truncate (fs/ocfs2/alloc.c:1924 fs/ocfs2/alloc.c:7286) ocfs2_truncate_file (fs/ocfs2/file.c:515) ocfs2_setattr (fs/ocfs2/file.c:1224) notify_change (fs/attr.c:556) do_truncate (fs/open.c:68) do_ftruncate (fs/open.c:194 (discriminator 1)) ksys_ftruncate (fs/open.c:206) __x64_sys_ftruncate (fs/open.c:211 fs/open.c:209 fs/open.c:209) Commit a406aff8c051 ("ocfs2: validate l_tree_depth to avoid out-of-bounds access") already restricts el->l_tree_depth to be less than OCFS2_MAX_PATH_DEPTH, which is equal to 5. However, does not handle the infinite descent case. Check if the el->l_tree_depth decreases on each descent. Maximum descents are restricted to 4 and the path->p_node[] array does not overflow. Link: https://lore.kernel.org/20260922202159.2421642-1-gkobakhi@asu.edu Fixes: dcd0538ff4e8 ("ocfs2: sparse b-tree support") Signed-off-by: Giorgi Kobakhia Signed-off-by: Andrew Morton Tested-by: Xiang Mei Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Signed-off-by: Sasha Levin commit ff2d64cb1fc1356b9be95d0aa220776edb393cc6 Author: Su Yue Date: Wed Sep 16 10:47:50 2026 +0800 ocfs2: update xattr count before moving bucket entries [ Upstream commit cd6920b6f3e5c6402d49e1128d0e53ee1c7c9b55 ] Since commit 2f26f58df041 ("ocfs2: annotate flexible array members with __counted_by_le()"), the xh_entries array is annotated with __counted_by_le(xh_count), so FORTIFY uses xh_count to determine its bounds. When inserting an entry into a bucket, ocfs2_xa_bucket_add_entry() shifts existing entries before incrementing xh_count. The destination therefore extends one entry past the bounds described by the old count. With CONFIG_CC_HAS_COUNTED_BY and CONFIG_FORTIFY_SOURCE enabled, ocfs2-test: single_run-WIP.sh -t reflink triggers the following failure while adding an extended attribute: [ 150.156484] memmove: detected buffer overflow: 352 byte write of buffer size 336 [ 150.156487] WARNING: lib/string_helpers.c:1036 at __fortify_report+0x3d/0x50, CPU#15: reflink_test/2336 [ 150.160496] RIP: 0010:__fortify_report+0x40/0x50 [ 150.164031] Call Trace: [ 150.164141] [ 150.164232] __fortify_panic+0x9/0xb [ 150.164383] ocfs2_xa_bucket_add_entry.cold+0x17/0x28 [ocfs2] [ 150.164661] ocfs2_xa_set+0x8fb/0xf40 [ocfs2] Increment xh_count before memmove() so the destination bounds include the new entry. Keep the local count unchanged to calculate the insertion position and move length from the original number of entries. The caller has already checked that there is enough space for the new entry. Link: https://lore.kernel.org/20260916024750.9450-1-glass.su@suse.com Fixes: 2f26f58df041 ("ocfs2: annotate flexible array members with __counted_by_le()") Signed-off-by: Su Yue Signed-off-by: Andrew Morton Reviewed-by: Heming Zhao Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Signed-off-by: Sasha Levin commit f79c63b27cb657f990b29c02b7c0ae67392d1663 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 7197e6716813cfc9a4f40a8aafa433f8f3510d6c Author: Bradley Morgan Date: Wed Sep 16 18:29:57 2026 +0000 panic: kill the "buffer unavailable" redirect fallback [ Upstream commit 68d956e9e235c2e125f77a9e98831e297b624a75 ] The redirect buffer is a disgusting terrible hack. panic_force_buf is kmalloc'ed in a late_initcall, and until then the redirect delivers this as the panic message: Redirected panic (buffer unavailable) The whole point of the redirect is to hand the panic message to the target CPU, so the crash kernel boots knowing it panicked and not why. And that window is the entire boot, from the early_param to the late_initcall, which is exactly when you most want the message. Make it a static 1KB buffer and kill the initcall. The cost is 1KB of .bss in SMP crash dump builds, and it is only ever touched when panic_force_cpu= is set anyway. The local msg variable is gone too, the buffer goes directly to panic_smp_redirect_cpu(). Link: https://lore.kernel.org/20260916182957.7788-7-brads@mainlining.org Signed-off-by: Bradley Morgan Signed-off-by: Andrew Morton Suggested-by: Petr Mladek Reviewed-by: Petr Mladek Cc: Guenetr Roeck Cc: Sashiko Cc: Wang Jinchao Cc: Wim Van Sebroeck Cc: Signed-off-by: Sasha Levin commit f56c76fb74d915daebbe13f08b1f272abdc2e5f7 Author: Bradley Morgan Date: Wed Sep 16 18:29:56 2026 +0000 panic: allow force_cpu redirect from an NMI [ Upstream commit 36c55a9625bb9ab7eb428ff8facc6d3d0a743180 ] nmi_panic() claims panic_cpu via panic_try_start() before calling panic(). When the panic later reaches panic_try_force_cpu(), the panic_in_progress() check sees panic_cpu set and refuses to redirect. The crash kernel runs on the CPU that took the NMI instead of the CPU requested with panic_force_cpu=: nmi_panic() panic_try_start() wins, panic_cpu = X panic("%s", msg) vpanic() panic_try_force_cpu() panic_in_progress() true, panic_cpu is X return false redirect bypassed panic_try_start() already won __crash_kexec() on X, not the requested CPU Try the redirect before claiming panic_cpu instead, as suggested by Petr Mladek. nmi_panic() now calls panic_try_force_cpu() first and claims panic_cpu only when no redirect happened. The requested CPU claims panic_cpu itself when it runs panic(), so panic_cpu does not need to be handed off. panic_try_force_cpu() copies the arguments before formatting (patch 3), so nmi_panic() can pass them to vpanic() again when no redirect happens. The redirect IPI is sent with smp_call_function_single_async(), which is not guaranteed to work from NMI context. Treat it as best effort. It is worth the risk because the redirection is only used when the crash kernel would not work on the panicking CPU anyway. Keep returning when the panic is already running on this CPU. A nested NMI, for example with unknown_nmi_panic while this CPU is inside panic(), must return and let the interrupted panic() continue instead of parking the CPU in nmi_panic_self_stop(). Mark the redirecting CPU offline before stopping it, like vpanic() does, so that panic_other_cpus_shutdown() on the target CPU does not wait for it. Link: https://lore.kernel.org/20260916182957.7788-6-brads@mainlining.org Fixes: 2e171ab29f91 ("panic: add panic_force_cpu= parameter to redirect panic to a specific CPU") Signed-off-by: Bradley Morgan Signed-off-by: Andrew Morton Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260708164312.19044-1-include@grrlz.net Reviewed-by: Petr Mladek Cc: Guenetr Roeck Cc: Wang Jinchao Cc: Wim Van Sebroeck Cc: Signed-off-by: Sasha Levin commit 912204859fba7cb882cdc63aca4aca1db6a30801 Author: Bradley Morgan Date: Wed Sep 16 18:29:55 2026 +0000 panic: restore variable arguments to nmi_panic() [ Upstream commit ed9e4c1ff15d5b935f467811541ca0aa6e49c5d0 ] nmi_panic() used to accept variable arguments until commit ebc41f20d77f ("panic: change nmi_panic from macro to function") flattened it to a final message string. vpanic() did not exist back then, so the function had to format through panic("%s", msg). Bring the variable arguments back and format with vpanic() directly. The next patch makes nmi_panic() try the panic_force_cpu= redirect before claiming panic_cpu. panic_try_force_cpu() needs to print the message but it is used also by panic() which accepts variable argument list. The string could be formatted only when a CPU gets assigned to process the redirection. Otherwise, there might be a race when writing to the `panic_force_buf`. No current caller passes a string with format specifiers. The closest one is hpwdt_pretimeout(), which builds panic_msg with hex_byte_pack() and has only two variants, both plain strings. But the new __printf() annotation on nmi_panic() would warn with -Wformat-security there because the buffer is passed directly as the format argument, so switch it to nmi_panic(regs, "%s", panic_msg). [pmladek@suse.com: changelog fix] Link: https://lore.kernel.org/arJxFybmtD7OBIcL@pathway.suse.cz Link: https://lore.kernel.org/20260916182957.7788-5-brads@mainlining.org Signed-off-by: Bradley Morgan Signed-off-by: Andrew Morton Suggested-by: Petr Mladek Reviewed-by: Petr Mladek Cc: Guenetr Roeck Cc: Sashiko Cc: Wang Jinchao Cc: Wim Van Sebroeck Cc: Signed-off-by: Sasha Levin commit 0c3771d172c1b3f1f2cc9e3981dd05cc8613f413 Author: Bradley Morgan Date: Wed Sep 16 18:29:54 2026 +0000 panic: fix va_list reuse in panic_try_force_cpu() [ Upstream commit 245001a347f1effc09c233d1712e1efeedab59ee ] vsnprintf() consumes the caller's va_list. When the redirect fails, vpanic() reuses it for the panic message, which is undefined behavior. Use va_copy(). Link: https://lore.kernel.org/20260916182957.7788-4-brads@mainlining.org Fixes: 2e171ab29f91 ("panic: add panic_force_cpu= parameter to redirect panic to a specific CPU") 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 433d9ba7cac185e272a7a97365b7ef91cb68ffb3 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 1a694b4ad42d289191a38e188af4f34495b11f1e Author: Bradley Morgan Date: Wed Sep 16 18:29:52 2026 +0000 panic: fix redirect CPU race in panic_try_force_cpu() [ Upstream commit 73554d8db4951d2a486405a2759cc0ffd282c0b2 ] Patch series "panic: fix panic_force_cpu= redirect races and NMI bypass", v7. The panic_force_cpu= parameter redirects a panic to a specific CPU so the crash kernel runs there. The redirect code in panic_try_force_cpu() had two races and an NMI bypass, all found by Sashiko. This series closes them and kills one more hack that the rework turned up. Panic from NMI still goes through the redirect path first, so the crash kernel ends up on the CPU the admin asked for. The redirect buffer is a static 1KB now, no initcall, no fallback message. This patch (of 6): The cmpxchg() in panic_try_force_cpu() makes sure that only one CPU tries to redirect panic() to the requested CPU. It is similar to the cmpxchg() in panic_try_start() which makes sure that only one CPU does the panic(). In both situations, only the winner of cmpxchg() should proceed further. Other CPUs should go offline. There is a bug because the cmpxchg loser returns false and falls through into vpanic(). Two non-target CPUs A and B panic, the requested CPU is C: cpu A cpu B ---------- ---------- panic() panic() vpanic() vpanic() panic_try_force_cpu() panic_try_force_cpu() cmpxchg wins cmpxchg fails redirect = A old_cpu = A IPI -> C return false <- BUG return true panic_try_start() wins panic_smp_self_stop() __crash_kexec() on B (A stops) (target C bypassed) The loser must stop, not fall through. It cannot just return true, though. A CPU that already won the redirect cmpxchg can reenter panic_try_force_cpu() on the same CPU, for example a nested NMI during the message formatting, before the IPI is sent: cpu A (1st) cpu A (nested) ---------- ---------- panic() vpanic() panic_try_force_cpu() cmpxchg wins (redirect = A) vsnprintf(msg) ... <-- NMI, nested panic --> panic() vpanic() panic_try_force_cpu() cmpxchg fails old_cpu == A (this CPU) return true <- would halt panic_smp_self_stop() (IPI never sent, panic abandoned) Check old_cpu against this_cpu so a second call from the same CPU returns false and falls through to panic_try_start() instead. Also fix the panic_in_progress() check. We must not redirect when panic_cpu is already assigned. Return true to stop when the panic is on another CPU, false to proceed when it is this one. Update the panic_try_force_cpu() doc comment for the new return value semantics. Link: https://lore.kernel.org/20260916182957.7788-1-brads@mainlining.org Link: https://lore.kernel.org/20260916182957.7788-2-brads@mainlining.org Fixes: 2e171ab29f91 ("panic: add panic_force_cpu= parameter to redirect panic to a specific CPU") Signed-off-by: Bradley Morgan Signed-off-by: Andrew Morton Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260705164123.18746-1-include@grrlz.net Closes: https://sashiko.dev/#/patchset/20260707172252.4842-1-include@grrlz.net Reviewed-by: Petr Mladek Cc: Guenetr Roeck Cc: Wang Jinchao Cc: Wim Van Sebroeck Cc: Signed-off-by: Sasha Levin commit 2470ce3d321d04e87ca435615bd7c4e1a571b3a2 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 f7c1d0411335b995161a82ea131bbd378ddb5f6f 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 a8eed441fdeeda9e40102e06d7884a8bfe1d4f6d 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 baea448d490090499cc49f35f10a8b8be85ab92f 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 f0abf244bcbb361b0d00a2ae4606294694c0e424 Author: Chao Yu Date: Sat Oct 10 14:55:46 2026 +0800 f2fs: fix to use bio_in_atomic() in f2fs_read_end_io() [ Upstream commit a605d5d71a6d280c43c7ede9778dda63fb5c3f22 ] f2fs_read_end_io() uses "in_task() && !irqs_disabled()" to decide whether it is safe to sleep, the result is passed down as @in_task to: - f2fs_put_dic() -> f2fs_free_dic() -> f2fs_release_decomp_mem() -> vm_unmap_ram(), which may sleep. - f2fs_end_read_compressed_page() -> f2fs_cache_compressed_page() -> f2fs_grab_cache() -> f2fs_lock_cache(), which may sleep in wait_on_bit_lock(). However, the check still treats below task contexts as sleepable: - with spinlock held via spin_lock(), i.e. preempt count != 0 while irqs are enabled. - with BH disabled via local_bh_disable(). - inside an RCU read lock on kernels with CONFIG_PREEMPTION. - with any spinlock held on kernels without CONFIG_PREEMPT_COUNT. So the "sleeping function called from invalid context" issue fixed by commit 08a7efc5b02a ("f2fs: vm_unmap_ram() may be called from an invalid context") can still be triggered. The block layer provides bio_in_atomic() for exactly this purpose, it checks rcu_preempt_depth() and preemptible(), and conservatively returns true if CONFIG_PREEMPT_COUNT is disabled, let's use it instead. The difference is as below: old: intask = in_task() && !irqs_disabled() new: intask = !bio_in_atomic() Context | old intask | new intask -------------------------------------+----------------+---------------- Hard IRQ / softirq | false | false IRQs disabled | false | false spin_lock() held, IRQs enabled | true (wrong) | false BH disabled by local_bh_disable() | true (wrong) | false RCU read lock (CONFIG_PREEMPTION) | true (wrong) | false Spinlock held, w/o PREEMPT_COUNT | true (wrong) | false Note that on kernels without CONFIG_PREEMPT_COUNT, bio_in_atomic() always returns true, so dic freeing will always be offloaded to sbi->wq, and compressed pages will not be cached in f2fs_read_end_io(); this is the price of correctness, since there is no way to tell whether the current context can sleep. Cc: stable@kernel.org Fixes: 08a7efc5b02a ("f2fs: vm_unmap_ram() may be called from an invalid context") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 41f17fbbd2199e6cfc6edcbce6f7e33885c1aea8 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 ff39a2d5d66e6cd74f04d40ac36db5952a302271 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 a6b2c74ca75549a53d301c1411549d739940da45 Author: Hengyu Liang Date: Sat Oct 10 12:57:50 2026 -0400 f2fs: allow empty strings for journaled quota options [ Upstream commit 0354a04b8c34e26cc66d0f43785d388163b6bacc ] Commit 2a3db1e02ce0 ("f2fs: allow empty mount string for Opt_usr|grp|projjquota") added support for passing usrjquota, grpjquota and prjjquota as flags to disable journaled quotas. However, it also replaced fsparam_string_empty() with fsparam_string(), which rejects an empty string. As of now, mount(2) and fsconfig(FSCONFIG_SET_STRING) reject usrjquota=, grpjquota= and prjjquota= with EINVAL, although these forms are still documented in Documentation/filesystems/f2fs.rst. The issue can be reproduced on an F2FS device with: mount -t f2fs -o usrjquota= /dev/loop5 /mnt/f Before this commit, the command succeeds. Afterwards, it fails with EINVAL and logs "f2fs: Bad value for 'usrjquota'". The same failure occurs when remounting to clear a quota file name. This patch will restore fsparam_string_empty() for the three options while retaining the flag entries, so both forms are accepted. Fixes: 2a3db1e02ce0 ("f2fs: allow empty mount string for Opt_usr|grp|projjquota") Cc: stable@vger.kernel.org # 7.1+ Signed-off-by: Hengyu Liang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 2061dcbb7750a00247eec17eccd6241365f99b7e 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 cfdb4aee913ca0675eeae4a6326c0ddfab4c82ef 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 a985443275a028a6fb32c97eecb5aaa728168d57 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 6b63eb440a191c038de79dac980fe6df6b21b17f 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 64e80d187ccfc3aecf7c5d405463e7a4abcf566c Author: Myeonghun Pak Date: Thu Sep 17 15:25:12 2026 -0400 accel/qaic: Cancel Sahara read data work on removal [ Upstream commit 018e5a021904707b91cecd77e7f759937ec04643 ] Sahara removal cancels fw_work and dump_work, but leaves read_data_work pending or running. The latter accesses the firmware and the device-managed context and transfer buffer, which are released during removal. Cancel read_data_work after fw_work, which can schedule it, and before releasing the firmware. The MHI core suspends and resets the channels before invoking the driver's remove callback. This issue was identified during our ongoing static-analysis research while reviewing kernel code. The same omission was also reported by the Sashiko bot while reviewing the Sahara relocation series. Fixes: 7fb19ea1ec6a ("accel/qaic: Support the new READ_DATA implementation") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260701105055.8D4371F00A3A@smtp.kernel.org/ Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Jeff Hugo [jhugo: reorder cancel_work_sync() calls] Signed-off-by: Jeff Hugo Link: https://patch.msgid.link/20260917192512.56205-1-mhun512@gmail.com Signed-off-by: Sasha Levin commit b46e228b2a1096fcae61bbf4eedffe1349cee788 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 2f85b0f394a08ccf4fc4a03390698eef0df94adf 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 83ff55c3bae1054a904d5edaa2f568affd02ae87 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 f27fdfd4c4144650752c9f79f3d106e4bcb4bf45 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 e14dbb9eda4a4bd9edc09f26b5edb3f760617c7a 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 06afe122a65a326e068751bf525f39ac64f68b7b 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 bd85055ca4cddffb13b638c021f92dd9cb05a8f3 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 68f15bd32d74a9836e1dce756ed03b6c4a5899f5 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 19c237734e1f83f4fd7fbf29eb817f8f0c831d99 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 fba302332547210e81c7d26778bad245de580e8f 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 53e5b0b2a2be40d09ed2a3e413e3ab9ed60b7cf2 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 08e4d674c109f4a4002efdb1b3066430abe62404 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 289dd8db5fdbfc61a796d5063bb0f95c31477666 Author: Andrea Parri Date: Mon Sep 28 10:48:09 2026 +0200 iomap: don't lose a failed direct I/O bio's error when zeroing the tail [ Upstream commit a9fd24bcbe690ed4a5b8ea6a7516fa297fae9360 ] iomap_dio_bio_iter() falls through to the sub-block tail zeroing when the data bio submission fails, so that the rest of the block is still zeroed and stale data is not exposed. The zeroing result was assigned to ret, which overwrote the submission error with the successful zeroing result (zero) and the failed write was reported as success. iomap_dio_zero() can only return an error from a can't-happen WARN_ON_ONCE() (nr_vecs exceeding BIO_MAX_VECS, which the existing comment there says "shall never be reached" for any in-tree filesystem), so it isn't a real runtime failure worth reporting to userspace, let alone one worth losing the actual submission error for. Make iomap_dio_zero() return void and drop the error handling at both call sites instead of threading the result through a separate variable. Fixes: 10553a91652d ("iomap: fix iomap_dio_zero() for fs bs > system page size") Cc: stable@vger.kernel.org # v6.12 Reviewed-by: Darrick J. Wong Reviewed-by: Pankaj Raghav Signed-off-by: Andrea Parri Link: https://patch.msgid.link/0cbce1012f5333690be36a9adafb3e190fe2ca77.1790342457.git.parri.andrea@gmail.com Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 5d6f21538389fa2b9fa143afdebb4cbe170ec900 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 61ec383a943abc5770e11fa65fb1629ca990bff1 Author: Kathiravan Thirumoorthy Date: Mon Sep 21 11:49:36 2026 +0530 clk: qcom: ipq5210: add 24MHz rate for USB UTMI clock [ Upstream commit 4d61492b5fa910ed59c4cbc699d2e5a03a5777d3 ] 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: 844be6e24afd ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5210 SoC") Signed-off-by: Kathiravan Thirumoorthy Reviewed-by: Abel Vesa Link: https://patch.msgid.link/20260921-ipq_clk_changes-v1-3-d242e3d49648@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 09cab610763675d6052d192d5f3b4e927289b61b 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 5c4b9317d159ede45f9559552b19edfb42f8d091 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 324cc3d6fafeebbad8892e25c23e018a98909ec5 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 cb1b95b98b63f10f38fb96a2ba17a9919017f916 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 fd8690793882084a329d5aa9223faf0c55ed148d 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 f1e465275afb9a09bb0f552b3cdaae051c7ffcaa Author: Joshua Mulloy Date: Sun Oct 4 06:25:25 2026 -0400 misc: tifm: don't clear dev->driver in tifm_device_remove() [ Upstream commit 2b23952d70d43321a90dd8a06bcaab04a1a73118 ] tifm_device_remove() sets sock->dev.driver to NULL after calling the driver's remove() callback. Since commit a995fe1a3aa7 ("rust: driver: drop device private data post unbind"), device_unbind_cleanup() dereferences dev->driver after the bus remove() callback has returned, so removing a card from a TI FlashMedia reader oopses: BUG: kernel NULL pointer dereference, address: 0000000000000090 Workqueue: tifm tifm_7xx1_switch_media [tifm_7xx1] RIP: 0010:device_unbind_cleanup+0x16/0xb0 Call Trace: device_release_driver_internal+0x220/0x260 device_release_driver+0x12/0x20 bus_remove_device+0xf9/0x1c0 device_del+0x161/0x3b0 device_unregister+0x17/0x70 tifm_7xx1_switch_media.cold+0x6b/0xbd [tifm_7xx1] process_one_work+0x1ac/0x3d0 worker_thread+0x1b8/0x360 kthread+0xf7/0x130 ret_from_fork+0x195/0x2a0 ret_from_fork_asm+0x1a/0x30 The driver core clears dev->driver itself in device_unbind_cleanup(), so there is no need for the bus code to do it. Remove the assignment. The problem was found and the fix written with the help of an AI coding assistant. Tested on a Dell Precision M6500 (TI PCIxx12 FlashMedia, 104c:803b) running a 7.0 kernel: removing an SD card oopsed every time without the fix; with it, insert, read and remove work. Fixes: a995fe1a3aa7 ("rust: driver: drop device private data post unbind") Cc: stable@kernel.org Assisted-by: LLM Signed-off-by: Joshua Mulloy Link: https://patch.msgid.link/20261004102525.34356-1-joshuamulloy@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ddc98a9d40966b227f2880a51f081b81d48fe0af Author: Peter Robinson Date: Sat Oct 3 16:04:28 2026 +0100 misc: issei: Fix issei architecture deps [ Upstream commit a8af929e9d751a85e9f46e8515cbe266249465a2 ] The issei driver is Intel specific and hence x86 only. Fixes: 65f0ecb9ec85c ("issei: initial driver skeleton") Cc: stable Signed-off-by: Peter Robinson Link: https://patch.msgid.link/20261003150433.1369234-1-pbrobinson@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 22f893e03317ba7dd6d4ffb3ca815d30f87f7130 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 700f670ddbdc1d1f2ff54b54e0d8ca9f0b7a2508 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 3279fe10b300a97eac23a192088491b6a99cdbd1 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 6db03320399ae802c50a989ea641d91d13d49bc1 Author: Hugo Villeneuve Date: Tue Oct 6 15:25:37 2026 -0400 serial: sc16is7xx: declare MCR and IER as volatile registers [ Upstream commit 1c41d09dcd07ee9648e20aa8238e404c2e6a12fb ] MCR register has the same address as XON1 register. IER register has the same address as DLH register. Which register is accessed depends on bits configuration in some other registers. To prevent potential access errors, declare MCR and IER as volatile registers. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable@kernel.org Signed-off-by: Hugo Villeneuve Link: https://patch.msgid.link/20261006192540.234402-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e99f04fe63fa250667930c71cb7c5fd29953f887 Author: Martin Fuzzey Date: Thu Oct 1 10:05:35 2026 +0000 serial: sc16is7xx: fix data corruption due to unexpected xon/xoff [ Upstream commit 8bb50e95c0abd44607bc60a43032c1dbf7470d5a ] The hardware supports automatically sending XON/OFF based on the FIFO status and that is already implemented by the driver. However that capability was not announced with the UPF_SOFT_FLOW bit. When the port is opened with the default of XON enabled the driver configures that in the hardware. If userspace does not want XON/OFF (which is normally the case) it will use TCSETS to disactivate it. However the serial core optimises this to only notify the driver if someting imporant has changed, and for XON/XOFF thit is only if the driver declares UPF_SOFT_FLOW. So we end up with unwanted XON/XOFF in the data stream. The problem only occurs if nothing else needed to be set by termios, ie if the user space requested values are the same as the default values, except for XON/XOFF. Since the default speed is 9600 this means that the problem only occurs when requesting 9600, otherwise the call to the driver will be made to change the speed, and that will also clear the XON/XOFF. As 9600 is quite rare these days that probably explains why this hasn't already been seen. It also only occurs on the first port open after boot since the subsequent opens will use the "logical state" set by TCSETS but not communicated to the driver the first time. Signed-off-by: Martin Fuzzey Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable@kernel.org Link: https://patch.msgid.link/20261001100534.1225894-1-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3fa143a890e0c374818b14e100baabc58ef6093c Author: Sasha Levin Date: Sun Oct 11 18:33:32 2026 -0400 tools/dma: fix building from the top level with O= [ Upstream commit 352665c55877368854f87724698dad0b453444eb ] "make O= tools/dma" fails: Makefile:27: /tools/build/Makefile.include: No such file or directory tools/Makefile clears srctree, and the dma Makefile only works it out again when building_out_of_srctree is not set, which the top-level Makefile sets for O= builds. Also work out srctree when it is empty, as tools/bpf/Makefile does since commit a89b2cbf71d64 ("tools, bpf: Fix build for 'make -s tools/bpf O='"). Fixes: f74ee32963f1b ("tools/dma: move dma_map_benchmark from selftests to tools/dma") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Sasha Levin Acked-by: Qinxin Xia Link: https://lore.kernel.org/r/20261011223358.2327625-4-sashal@kernel.org Signed-off-by: Marek Szyprowski Signed-off-by: Sasha Levin commit 542651d0ad028b034b649d44656180efba47f0b2 Author: Ard Biesheuvel Date: Tue Oct 13 09:30:08 2026 +0200 arm64/mm: Treat faults taken by EFI runtime firmware as kernel faults [ Upstream commit 171be684bfa3020f81bf0b85bc7ac42024575fbf ] When EFI runtime services are invoked from a preemptible kthread, the kthread runs with efi_mm installed via kthread_use_mm() and preemption enabled, so neither faulthandler_disabled() nor !mm applies in do_page_fault(). A permission fault taken by the firmware on one of its own (TTBR0) mappings then hits the 'access to user memory outside uaccess routines' check and oopses, without efi_runtime_fixup_exception() ever being consulted. efi_mm has no VMAs, so there is nothing for the mm to resolve. Send such faults to no_context directly, so that __do_kernel_fault() can recover from them as it does when the call is made with preemption disabled. Fixes: a5baf582f4c0 ("arm64/efi: Call EFI runtime services without disabling preemption") Cc: Signed-off-by: Ard Biesheuvel Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 5252ad294556a7916b6256d7d1d2b995bd548bf3 Author: Myeonghun Pak Date: Mon Sep 14 20:54:47 2026 -0400 fbdev: nvidia: Release write-combining handle on probe failure [ Upstream commit 8710af6a35201a6d01b5af8f7e4bad29cc40467f ] Failures in nvidia_set_fbinfo() or register_framebuffer() leave the handle from arch_phys_wc_add() allocated. Release it in the shared error path, as nvidiafb_remove() already does on normal removal. The missing cleanup was already present in the initial Git import, when the driver used mtrr_add() directly. 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 bd6e0222a85b40342e77aa50eda0e03582dcb72a 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 3ec236beefafd91734f5539f12e1918a1392a60f 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 4310425b130e4b66c4a8e02e9ed2e88afb265622 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 b8d058d9520315db836b07c4d0ef04d170b9f9a5 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 4f511fa01d682c50f6c9e1c71fe5c98efa113cdd 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 a760b504abf3d82e4698c89865194f8fc2f863d5 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 439dcd4dce386c304fa7c1b56635195366c843a2 Author: Andrey Misiurov Date: Mon Oct 12 19:53:38 2026 +0200 fbdev: core: Initialize modelist in framebuffer_alloc() [ Upstream commit 0c9cb9321cb3863b52bdea4b8ae5a27705762c9e ] framebuffer_alloc() returns zeroed memory, so info->modelist starts out with NULL next and prev pointers. The list head is initialized only later, by fb_videomode_to_modelist() or by do_register_framebuffer(). The "fix potential memory leak" commits listed below added fb_destroy_modelist(&info->modelist) to the probe error paths of s3fb, tdfxfb, tridentfb, i740fb and carminefb. These paths can run before the list head is initialized: - s3fb, tdfxfb, tridentfb and i740fb call fb_videomode_to_modelist() only after a successful EDID read, and tridentfb can also hit the error path on an ioremap() or kmalloc() failure before that; - carminefb jumps to the error path when fb_find_mode() fails, before its fb_videomode_to_modelist() call. fb_destroy_modelist() then dereferences the NULL head. Reproduced on Debian 12 (6.1.180) by binding s3fb to a VGA device without EDID and forcing fb_alloc_cmap() to fail: s3fb 0000:00:03.0: cannot allocate colormap BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:fb_destroy_modelist+0x10/0x80 Call Trace: s3_pci_probe.cold+0x12b/0x2bf [s3fb] local_pci_probe+0x41/0x80 pci_device_probe+0xc3/0x240 really_probe+0xde/0x380 __driver_probe_device+0x84/0x150 driver_probe_device+0x1f/0x90 __driver_attach+0xce/0x1c0 bus_for_each_dev+0x87/0xd0 bus_add_driver+0x1ae/0x200 driver_register+0x89/0xe0 do_one_initcall+0x59/0x220 do_init_module+0x4a/0x1f0 Initialize the list head in framebuffer_alloc(), so info->modelist is always a valid, possibly empty, list and fb_destroy_modelist() is safe on every error path. Keep the lazy initialization in do_register_framebuffer(), as drivers that embed struct fb_info rather than calling framebuffer_alloc() still depend on it. Fixes: 3b0ed04bc852 ("fbdev: s3fb: fix potential memory leak in s3_pci_probe()") Fixes: bb019d755366 ("fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()") Fixes: 7a35ec619d9a ("fbdev: tridentfb: fix potential memory leak in trident_pci_probe()") Fixes: 5936063409af ("fbdev: i740fb: fix potential memory leak in i740fb_probe()") Fixes: 6fcca16a2b19 ("fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()") Cc: stable@vger.kernel.org Signed-off-by: Andrey Misiurov Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 0fa0e681da02ff63dfffd033279b792b8b2e7cb0 Author: Karl Mehltretter Date: Sat Sep 12 12:21:52 2026 +0200 fbdev: sh_mobile_lcdcfb: Restore the per-overlay sysfs attributes [ Upstream commit 317a8be730919177956be32422ebe00cf7e46710 ] The ovl_* files documented in Documentation/ABI/testing/sysfs-devices-platform-sh_mobile_lcdc_fb no longer exist. Commit a979182a2453 ("fbdev: lcdcfb: Register sysfs groups through driver core") moved the attributes from each overlay's framebuffer device to the platform driver's dev_groups and renamed them overlay_*. There is now only one set of attributes for the whole LCDC. The callbacks still expect dev_get_drvdata() to return a struct fb_info, but the platform device holds struct sh_mobile_lcdc_priv, so they access the wrong structure. Restore the documented names and register the group on each overlay's framebuffer device with device_add_groups(). Remove it with device_remove_groups() before unregistering the framebuffer. Skip creation when dev_of_fbinfo(info) is NULL, as the old device_create_file() calls did. Drop the CONFIG_FB_DEVICE guard, since the driver already depends on it. Fixes: a979182a2453 ("fbdev: lcdcfb: Register sysfs groups through driver core") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 1f48406c1d94daa45f06ab80056a83e46d705132 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 27171859d5c573a252e2959fefff295c20776e69 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 2a70ce6a31689b3c4c1b6ffba81742a0c6336d35 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 0f2d5dac7b6d052df23674022c66211909622382 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 8b6c2c832b99fad845223199de26ea9d4fe879d3 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 7fb5483040ab3fb4ceccc3f5542d5844981f5530 Author: Marco Scardovi Date: Fri Sep 18 11:14:59 2026 +0200 platform/x86: asus-wmi: Serialize WMI method evaluations with a mutex [ Upstream commit b9428edaf4109e86a97254228d831767d0acc1f8 ] Concurrent evaluations of ASUS WMI management methods (from ACPI notify, HID, userspace daemons, and debugfs) enter the BIOS ACPI/SMM interface simultaneously, triggering re-entrant SMIs or EC mailbox buffer corruption. Fix this at the root by introducing a centralized evaluation helper (asus_wmi_evaluate_method_locked()) protected by a global mutex (asus_wmi_eval_lock) using guard(mutex). Route all evaluations of ASUS_WMI_MGMT_GUID (method3, method5, method_buf, and show_call) through this helper. A static mutex is required because asus_wmi_evaluate_method() is an exported symbol used by external modules (such as hid-asus and asus-armoury) that lack access to struct asus_wmi drvdata, and the underlying ASUS ACPI/EC management method is a single physical platform resource. The mutex is non-recursive: nested ACPI/WMI notify handlers must not call back into evaluate on the same task (defer via workqueue, as asus_rfkill_notify already does). The sysfs-versus-notify race predates the later export of asus_wmi_evaluate_method(), so Fixes points at the original shared evaluate helper rather than that export. Link: https://github.com/OpenGamingCollective/asusctl/issues/328 Fixes: d33da3b68669 ("asus-wmi: factorise wmi_evaluate_method call") Cc: stable@vger.kernel.org Signed-off-by: Marco Scardovi Reviewed-by: Denis Benato Reviewed-by: Armin Wolf Link: https://patch.msgid.link/b6a1981777e63f0c28bd719d8203ebbda57d6957.1789722252.git.scardracs@disroot.org Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 7e24cff8bb8147ddc4ca401255e3bfa6bbf1dea4 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 d2f87a7eb3de026deb7ddc859758a0ca27cc88ed 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 6d5ff41da9f79c2cae13c16b8b6c12dc3aed0173 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 d3d7755af4b7779f67836731a9c8c71eb268959e 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 20f8b615d98c1434ee54c1b8ae2ab861ff658b6d 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 dbbf052832f1b618bbb77b08194e5908e7a51107 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 c83b7320a4a35697847cc1fd11a24986d4061628 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 8fa8bffe087951757d794922a2a97b9d5c03de73 Author: Mario Limonciello Date: Wed Aug 26 11:36:11 2026 -0500 platform/x86/amd/pmf: Add AMDI0112 ACPI ID [ Upstream commit 325bcc126cf7a512a0e2da0efddad665f69badac ] The AMDI0112 ID is used to bind the PMF driver to some platforms. It doesn't have any Linux side code changes relative to the most similar AMDI0105. Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260826163611.2268377-1-mario.limonciello@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 40edd83f22aac79fa75a9907a9959998da8c581e 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 477c6e65a18a13b38b3036f65465bbcc9264b38f Author: David Carlier Date: Sun Sep 20 16:50:02 2026 +0100 mm/shmem: don't release a swapin-error marker as a swap entry [ Upstream commit e4b92891aaca0d37b5973362dd14747a65406650 ] A failed shmem swapin (eg, EIO) frees the swap slot and leaves a PTE_MARKER_POISONED entry in the page cache. On truncate or eviction shmem_free_swap() passes that marker to swap_put_entries_direct(), which warns because it is not a swap entry. There is nothing left to release either way. Skip the release for non-swap entries, as every other caller already does. Link: https://lore.kernel.org/20260920155002.1030454-1-devnexen@gmail.com Fixes: ac2d3268284b ("mm/swapfile.c: remove the unneeded checking") Signed-off-by: David Carlier Signed-off-by: Andrew Morton Reported-by: syzbot+23b25ba3c6bf971f9c57@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=23b25ba3c6bf971f9c57 Reviewed-by: Baolin Wang Cc: Baoquan he Cc: Barry Song Cc: Chis Li (Google) Cc: Hugh Dickens Cc: Kairui Song Cc: Kemeng Shi Cc: Nhat Pham Cc: Signed-off-by: Sasha Levin commit dd14cc2bb8085ed897a662eb90f918b34f9280d6 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 9f8f6a2df0f9d3ce5406e4003da62f0a56771536 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 7cce1d49123b2940bb0c54c815723b4ec7b86046 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 71c389c2dc0ce40ee25a29ba10107284b6695bc5 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 5b0b34b6958b17e1c7354bebaf43672291bc3412 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 898226bf9794bba5e0511a4659b485ef144d3bb5 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 380fbb3a43228a3f439d64549a9d854a23d336b8 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 ce52ddfe06174e90bf79cbf5ad591edb3c8ce938 Author: Gregory Price Date: Sat Sep 12 08:28:22 2026 -0400 proc/task_mmu: handle special PMDs in clear_refs and pagemap [ Upstream commit d350956d829f4b620faf294c86116de640f1518c ] mshv_vtl_low can install a special PMD from a PFN supplied in the mmap file offset. That PFN need not have a memmap entry. Reading /proc/PID/pagemap or writing /proc/PID/clear_refs for such a mapping oopses the kernel. With a test driver mapping the PFN at the 1 TiB mark: echo 1 > /proc/self/clear_refs BUG: unable to handle page fault for address: fffffb5b80000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page RIP: 0010:clear_refs_pte_range+0xb1/0x1e0 Call Trace: walk_pgd_range+0x50a/0xad0 __walk_page_range+0x6a/0x1d0 walk_page_range_mm_unsafe+0x193/0x230 clear_refs_write+0x18e/0x3f0 pread(pagemap_fd, buf, 512 * 8, addr / PAGE_SIZE * 8) BUG: unable to handle page fault for address: fffff57840000008 RIP: 0010:pagemap_pmd_range+0x3cf/0x6b0 Call Trace: walk_pgd_range+0x50a/0xad0 __walk_page_range+0x6a/0x1d0 walk_page_range_mm_unsafe+0x193/0x230 pagemap_read+0x1dc/0x350 clear_refs_pte_range() passes the PMD to pmd_folio(), while pagemap_pmd_range_thp() uses pmd_page() followed by page_folio(). Both paths assume the PFN has a struct page and dereference bad address. Use vm_normal_folio_pmd() and vm_normal_page_pmd() so clear_refs skips folio operations and pagemap skips folio-derived flags for special PMDs. This matches the PTE paths, which already use vm_normal_folio() and vm_normal_page(). User-facing notes: - Pagemap still reports PM_PRESENT and the PFN to a CAP_SYS_ADMIN reader. - For a special PMD backed by a valid memmap entry and for the huge zero PMD, PM_FILE changes from set to clear. - PM_MMAP_EXCLUSIVE is already clear in both cases. - The output for an anonymous THP is unchanged. Tested in QEMU with the test driver on broken and fixed kernels. Both proc operations oops before the fix and return 0 after it. This is technically reachable via mshv_vtl_low, so I tagged it stable. Link: https://lore.kernel.org/20260912122822.3348978-1-gourry@gourry.net Fixes: 3c8e44c9b369 ("mm: mark special bits for huge pfn mappings when inject") Signed-off-by: Gregory Price Signed-off-by: Andrew Morton Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260912034833.2952750-1-gourry%40gourry.net Acked-by: David Hildenbrand (Arm) Assisted-by: LLM Cc: Jann Horn Cc: Jason Gunthorpe Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Pedro Falcato Cc: Peter Xu Cc: Vlastimil Babka Cc: # v6.19+ Signed-off-by: Sasha Levin commit 1a0ef02d9f5a6d121cdecc80ec8ee45c8816f6af 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 2254b01bbac767e8aa434e7663c0e8d241f6943d Author: Vladimir Nedoshivin Date: Fri Sep 11 00:05:39 2026 +0400 PCI: vmd: Flush DMA writes before handling MSI on Arrow Lake [ Upstream commit 2c88c2dc18528489b403fe95741f5731e292f7ba ] Per the Intel Core Ultra Processors (Series 2) Specification Update (ID 834774 of 9/1/2026), the Arrow Lake VMD device 0xad0b is affected by an MSI erratum: ARL004: MSI from VMD-Owned Device May Pass Memory Write Problem When the storage subsystem is configured to operate in RAID 0 or 1 mode, a Message Signaled Interrupt (MSI) from an Intel® Volume Management Device (Intel® VMD) owned device may interrupt a core before a previous write from the device is completed. Workaround None identified. The VMD MSI interrupt-handler should initially perform a dummy register read to the MSI initiator device prior to any writes to ensure proper PCIe ordering. The existing VMD_FEAT_INTERRUPT_QUIRK implements Intel's documented workaround by issuing a configuration-space read to the MSI initiator before dispatching the interrupt. Enable the existing quirk for 0xad0b as well as 0x7d0b and make the comments describe both MTL016 and ARL004. Tested on an MSI Vector 17 HX AI with Intel VMD 8086:ad0b and an NVMe device behind VMD. With the quirk enabled, the NVMe completion stalls observed without the workaround are no longer reproduced. Link: https://bugs.launchpad.net/bugs/2166325 Signed-off-by: Vladimir Nedoshivin [bhelgaas: include erratum source and text, cc: stable] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260910200539.10862-1-gvozd188@mail.ru Signed-off-by: Sasha Levin commit fd7042aee0b738d0cc5d4c55e80732cd4496fea0 Author: Rickey Bartlett Date: Mon Aug 24 21:32:20 2026 -0700 PCI: vmd: Flush DMA writes before handling MSI on Meteor Lake [ Upstream commit 7307899e381cb0c16245793a4adde7491d73a2b3 ] Per the Intel Core Ultra Processor Specification Update (ID 792254 of 9/1/2026), the Meteor Lake VMD (8086:7d0b) is affected by an MSI erratum: MTL016: MSI from VMD-Owned Device May Pass Memory Write Problem When the storage subsystem is configured to operate in RAID 0 or 1 mode, a Message Signaled Interrupt (MSI) from an Intel® Volume Management Device (Intel® VMD) owned device may interrupt a core before a previous write from the device is completed. Workaround None identified. The VMD MSI interrupt-handler should initially perform a dummy register read to the MSI initiator device prior to any writes to ensure proper PCIe ordering. The VMD can signal its MSI before the posted writes carrying a child device's DMA data have landed in memory. vmd_irq() then demuxes to the child handler while the child's completion queue is not yet coherent, so the handler observes no completion and returns without consuming it. The I/O is only recovered when the block layer timeout expires and polls the queue: nvme nvme0: I/O tag 253 (50fd) QID 1 timeout, completion polled The practical effect is therefore not a lost I/O but a 30 second stall of the entire storage stack, repeated under any sustained read load. This was originally diagnosed and fixed by Kai-Heng Feng in September 2024 [1]. That patch used udelay(4); Keith Busch objected that the delay is merely a side effect of the read, and that flushing the pending device-to-host writes is what the erratum actually requires. Kai-Heng agreed to respin with a dummy register read. The thread then stalled on an open question from Manivannan Sadhasivam [2]: whether the read must target the child device (the "MSI initiator" named by the erratum) rather than the VMD, and whether the workaround belongs in the NVMe driver instead. No revision followed, and the erratum has remained unmitigated in mainline since. This implements the flush read Keith asked for, and answers the open question empirically: the read MUST complete at the initiating child device. A read of the VMD's own config BAR was tried first and does not help - it terminates at the VMD and never traverses the downstream link, so it does not order against the child's posted writes (measured: timeout rate unchanged). Reading the initiator's config space does order correctly: per PCIe ordering rules the read completion cannot pass the device's earlier posted writes, so returning from the read guarantees the completion queue entry is visible. The initiator's config address is captured per-IRQ at MSI allocation time from the requesting device, so the hot path adds one config read only on affected parts, and only for vectors owned by a child device. The read is serialized with cfg_lock like all other VMD config access. No NVMe driver change is needed. Measured on a Dell Pro Max 14 MC14250 (Meteor Lake, VMD 8086:7d0b, KIOXIA BG6 512GB, 7.0.0-30-generic). The drive is healthy (46C, 0 media errors, 2% used) and ASPM is disabled on the link with all L1 substates off, so neither ASPM nor APST is involved. Dropping caches and reading 3000 shared libraries, measuring /proc/pressure/io "full" (every task on the system blocked on I/O), with nvme_core.io_timeout=5: unpatched: round 1 wall 37.4s full I/O stall 32.6s timeouts 0 round 2 wall 30.6s full I/O stall 28.7s timeouts 1 round 3 wall 30.3s full I/O stall 27.4s timeouts 1 VMD-BAR read: round 1 wall 44.8s full I/O stall 38.6s timeouts 8 (insufficient) round 2 wall 234.8s full I/O stall 207.9s timeouts 37 round 3 wall 3.6s full I/O stall 0.8s timeouts 0 this patch: round 1 wall 3.6s full I/O stall 1.3s timeouts 0 round 2 wall 3.6s full I/O stall 1.3s timeouts 0 round 3 wall 3.6s full I/O stall 1.4s timeouts 0 Before any workaround, 208 seconds of total-system I/O stall accumulated in the first 13 minutes of uptime, roughly 27% of wall clock. Userspace experiences this as GUI applications taking 30-60+ seconds to start while throughput between stalls looks entirely normal (1.9 GB/s QD1) - which is what makes the fault easy to misattribute to ASPM or to the drive. [1] https://lore.kernel.org/20240903025544.286223-1-kai.heng.feng@canonical.com/ [2] https://lore.kernel.org/20240913111142.4cgrmirofhhgrbqm@thinkpad/ Reported-by: Kai-Heng Feng Suggested-by: Keith Busch Assisted-by: LLM Signed-off-by: Rickey Bartlett Signed-off-by: Manivannan Sadhasivam [bhelgaas: include erratum source and text, update URLs, cc: stable] Signed-off-by: Bjorn Helgaas Tested-by: Varsh Satti Acked-by: Keith Busch Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260825043220.9047-1-subtexel@gmail.com Signed-off-by: Sasha Levin commit dce23938b5aa467a3ba55e041ee140de03a0f6cf 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 7589b3a3d006813f4192b122123e46a9339ba06c 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 15d285b15e15cfce30439cc27119f9db614cccac 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 3c58952202b77d55a20010d00b5e1ae8db188036 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 542963c2c0c542abdeeb815ed44110680d318c68 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 d8235db8427d64644af461f54433b372d73cf9bd 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 58e2a11eaa2a688712f77125bad8237f735acc92 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 74a80eab32bc51de0a99256f2ccec5ef2e475e27 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 2fff1193c6994bf178bff67acf27a2d419fe9adf Author: Breno Leitao Date: Fri Sep 25 08:09:11 2026 -0700 ACPI: APEI: accumulate the queued flag across error sections [ Upstream commit f341307a14895e5da056fb419a31ef7fb534ab18 ] ghes_do_proc() walks every error section of a CPER record, and ghes_handle_arm_hw_error() walks every error-info entry of an ARM processor section. Both assign to "queued" instead of OR-ing into it, so only the last iteration counts: a later section or entry that queues no memory-failure work clears the flag an earlier one set. Instead of reassigning the variable at every time, just do an `OR`, so, if there was a single match, it will return "queued" as set. The comment above the check says "If no memory failure work is queued", which is the semantics this patch implements. I.e, only SIGBUS if there are queue was not handled at all. If we want to SIGBUS if any event was not handled/queued at all, we will need something more sophisticated. Fixes: 7f17b4a121d0 ("ACPI: APEI: Kick the memory_failure() queue for synchronous errors") Fixes: ccb5ecdc2dde ("ACPI: APEI: fix synchronous external aborts in user-mode") Cc: All applicable Signed-off-by: Breno Leitao Reviewed-by: Shuai Xue Link: https://patch.msgid.link/20260925-ghes-queued-accumulate-v1-1-df50553957d4@debian.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit aeb3f73ece04fcb44e331ffa80652ed261e967d1 Author: Ma Ke Date: Mon Oct 12 16:41:52 2026 +0800 ALSA: hda: cs35l41: Fix ACPI device reference leak on probe failure [ Upstream commit 8d70e364e866bdfca81eee24d0688fac9472cfb9 ] cs35l41_hda_probe() takes an acpi_device through cs35l41_hda_read_acpi() and stores it in cs35l41->dacpi. Only the failures that happen later reach the err: label, which is where that reference and cs35l41->acpi_subsystem_id are released, so the early return taken when cs35l41_hda_read_acpi() fails leaves both behind. Keep the ownership in the caller instead of dropping the reference inside cs35l41_hda_read_acpi(). That removes the need to work out whether a given failure path has already released it, and with it the double put that cs35l41_hda_parse_acpi() would otherwise cause when it fails after having released the device itself. cs35l41_hda_parse_acpi() and the !physdev path no longer put the reference, and the early failure enters the existing err: cleanup tail through a new err_acpi label. The label sits between the reset of the codec and the gpio cleanup, so an early failure also releases the reset and chip-select descriptors that cs35l41_hda_parse_acpi() may already have taken, while still skipping cs35l41_safe_reset() on a codec that was never brought up. cs35l41->dacpi comes from devm_kzalloc() and is only assigned once the ACPI device has been found, so the put is a no-op when the lookup itself failed. Found by code review. Fixes: 447106e92a0c ("ALSA: hda: cs35l41: Support mute notifications for CS35L41 HDA") Cc: stable@vger.kernel.org Signed-off-by: Ma Ke Link: https://patch.msgid.link/20261012084152.3740340-1-make_ruc2021@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e7729f8e7f7773604b8b3003101f9fa392109a71 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 38b4b9fb1183b5410db0da0926a9dde11f345e1e Author: Bjoern Doebel Date: Thu Oct 1 08:24:11 2026 +0000 selftests/filesystems: Fix idmapped_tmpfile layer dir ownership [ Upstream commit 9ba6627ef6b12debd1c54443939718db63234274 ] The recent idmapped_tmpfile selftest creates a new directory in tmpfs owned by user ID 0. It then idmaps the mount as caller [0,10000) to disk [10000,20000). The original uid 0 owner does not exist in the mapped range. As a result, mapped_caller_creates_and_links fails at the O_TMPFILE open because inode_permission() rejects MAY_WRITE access: idmapped_tmpfile.c:145:mapped_caller_creates_and_links: Expected fd (-1) >= 0 (0) Chown the directory into the mapped range to satisfy the UID requirement. Fixes: d943e68edc5cb ("selftests/filesystems: test O_TMPFILE creation on idmapped mounts") Cc: stable@vger.kernel.org # 7.2+ Signed-off-by: Bjoern Doebel Link: https://patch.msgid.link/20261001082411.1493072-1-doebel@amazon.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 57cfd597be44e83221ef39e2583651e25b93453c 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 faf008eaf133a667923d33a6dbc282fec2a4cdce Author: Christopher Lusk Date: Sun Sep 13 09:17:53 2026 -0400 m68k: Fix seccomp filtering on ColdFire and 68000 [ Upstream commit 48859f8018d93bd93ef35f7430fdf5b97f2f9715 ] m68k selects HAVE_ARCH_SECCOMP_FILTER for all configurations, but the ColdFire and 68000 syscall entry paths only branch to syscall_trace_enter() for TIF_SYSCALL_TRACE. TIF_SECCOMP alone falls through to syscall dispatch, leaving installed filters ineffective. Test the combined TIF_SYSCALL_TRACE and TIF_SECCOMP mask in both paths and route either flag through the existing slow path. Leave the classic MMU syscall entry implementation unchanged. Validated the combined test under QEMU mcf5208evb (ColdFire): filters denying getpid, openat, unlinkat, and reboot each returned -EPERM. A classic-MMU control (q800) denied the filtered getpid syscall both before and after this change. The 68000 path shares the same source-level omission and receives the identical masked test but was not separately emulated. Compile-tested W=1 with CONFIG_SECCOMP_FILTER=y on both m5208evb_defconfig and a custom no-MMU UCSIMM configuration; the latter built arch/m68k/68000/entry.o and vmlinux. Fixes: 6baaade15594 ("m68k: Add kernel seccomp support") Cc: stable@vger.kernel.org # v6.3+ Suggested-by: Andreas Schwab Assisted-by: Claude:claude-opus-4-8 Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Christopher Lusk Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit 6cfb1529c5398c8f68ed79f03c3c409436555286 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 b840ba611e00cea98d0fa64b0d645b7ccabcd3e6 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 a0fff512d8fceed8274d526837eda2e2e90aa271 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 1e61a7ac9e2dcd85508fde23e89143912e2e53d5 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 cce884b10b81ec23ff8a467aadcd1615c334c529 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 06da0cdf23461db720374a6d39fdfa544e2cda8d Author: Stephen Horvath Date: Sun Oct 4 02:27:31 2026 +0200 usb: xhci-pci: Add AMD 600 series to xhci-pci-prom21 [ Upstream commit 29381088ac50a4910d18a5f8079d9bd505f839be ] It seems the xhci-pci-prom21 module only has IDs for the 800 series chipsets. However, the 600 series chipsets also have Promontory 21 chips, so we should add their IDs to the list as well. I have tested this on my X670 board featuring DID `0x43f7`. `1022:43f7` also appears on the PCI ID database (https://pci-ids.ucw.cz/read/PC/1022/43f7). Device IDs `0x43f9` (B665) & `0x43fa` (A620) were suggested by Shyam. Also list the new IDs in Documentation/hwmon/prom21-xhci.rst. Cc: stable@vger.kernel.org # 7.2.x Cc: Shyam Sundar S K Cc: Jihong Min Signed-off-by: Stephen Horvath Tested-by: Mirko Jechow [mirko.jechow@gmx.de: add new IDs to prom21-xhci.rst] Signed-off-by: Mirko Jechow Link: https://patch.msgid.link/20261004002731.49927-1-mirko.jechow@gmx.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9428026a1e82d2237cdb099f71e10ea92dee6845 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 e95ace4abebd564b50b856513e24853d35be06cd 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 8e3cb6de2c5108cad19541055b60fc4400f97dde 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 9082097814c7d2ef6b6b10e19bcd597862d91e8c Author: Gris Ge Date: Thu Oct 1 07:46:08 2026 +0800 usb: typec: ucsi: Skip CAM query when partner has no alt modes [ Upstream commit 7c590f0716ed3c9ae9809dbc6d488d76c19fdf52 ] Since Thunderbolt alternate mode support was added, `ucsi_altmode_update_active()` is called on every Connector Partner Changed event. This made the driver send `UCSI_GET_CURRENT_CAM` to PPMs even when the partner had no alternate modes registered. Firmware that does not support the optional alternate mode details answered Not Supported, which produced a spurious error on every partner change: ``` ucsi_acpi USBC000:00: GET_CURRENT_CAM command failed ``` Fixed by skipping the command when there is nothing to update. Fixes: da87d45b1951 ("usb: typec: ucsi: Add Thunderbolt alternate mode support") Assisted-by: Codex:deepseek-v4.1-flash Cc: stable Signed-off-by: Gris Ge Reviewed-by: Andrei Kuchynski Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260930234611.468765-2-cnfourt@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8129086877692a0274df116e941f3e93dae02d2a 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 f47dc077510d137bfdc7dff98b9248b0957504d7 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 c9b60cda84fad32def1047a99ad030a90e5c8bbc Author: Orgad Shaneh Date: Sun Oct 11 08:05:06 2026 +0000 usb: octeon-hcd: keep SOF interrupts while a pipe needs them [ Upstream commit 68ee2f70d0257aa327ebf8406cd28475574585f2 ] cvmx_usb_schedule() now sleeps on an hrtimer until the nearest future periodic deadline instead of counting frames down on every SOF. The scan that finds that deadline only looks at pipes with next_tx_frame > usb->frame_number which is right for picking the deadline, but two kinds of pipe that need a SOF to make progress are invisible to the decision: - A periodic pipe that is due and was *not* started: no idle hardware channel this round, its split window is closed (cvmx_usb_find_ready_pipe() rejects both), or another pipe owns usb->active_split. cvmx_usb_next_pipe() looks at the isochronous and interrupt lists only when is_sof is true. - Any pipe that has sent its start split and waits for the frame its split complete may go out in (split_sc_frame, also checked by cvmx_usb_find_ready_pipe()). A control or bulk pipe on a full or low speed device behind a hub is in this state between its two halves, and with SOF masked nothing guarantees an interrupt that brings frame_number there. When some other periodic pipe sets a far deadline - a hub's status pipe, whenever a hub is attached - the driver masks SOF, arms the timer for that deadline and these pipes wait for it. That is hundreds of frames; the code allows up to 8000 (one second) before it falls back to SOF. Before the hrtimer this could not happen: any pipe with a future deadline set need_sof, so SOF stayed enabled every frame and the pipe was retried on the next one. Note such a pipe and keep SOF enabled while there is one, whether or not another pipe has a future deadline. Nothing changes when there is none, which is the case the timer was added for. Other control and bulk pipes are excluded deliberately: their next_tx_frame is not updated on completion, so they are almost always "due" and would keep SOF enabled permanently. Fixes: aebbc7d63407 ("usb: octeon-hcd: sleep on an hrtimer for far-off periodic transfers") Cc: stable Assisted-by: LLM Signed-off-by: Orgad Shaneh Link: https://patch.msgid.link/20261011080506.2394708-1-orgads@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 19c5bf57355c133c57b5e55696eeafe2d5ad3e28 Author: Orgad Shaneh Date: Sun Oct 11 07:22:38 2026 +0000 usb: octeon-hcd: release the USB block when initialization fails [ Upstream commit b8c063059f304abebc11039195f5b28298aeddbb ] cvmx_usb_initialize() gets as far as selecting the reference clock, enabling USBN_CLK_CTL and taking the PHY out of reset (steps 2b-2e) before anything can go wrong, and its only caller frees the HCD and returns without touching the hardware. Both of its error returns therefore leave the USB block clocked and out of reset on a failed probe. Release it on the way out with cvmx_usb_shutdown(), which is the undo the retry path a few lines above already uses. It cannot refuse with -EBUSY here: the pipe lists it checks are initialised by octeon_usb_probe() before cvmx_usb_initialize() is called, and no pipe can have been opened yet. Fixes: 22bce6d2b3fd ("usb: octeon-hcd: fail the probe when the USB core does not respond") Cc: stable Assisted-by: LLM Signed-off-by: Orgad Shaneh Link: https://patch.msgid.link/20261011072238.2381564-1-orgads@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c460161d08103ee44c670e94da8c3c70ae82f4be Author: Danilo Krummrich Date: Sat Oct 10 15:50:49 2026 +0200 usb: core: don't set drvdata to NULL in usb_unbind_interface() [ Upstream commit 8f0d16174102863936d583c90258ea02bf06205c ] usb_unbind_interface() serves as the remove() callback of struct usb_driver and calls usb_set_intfdata(intf, NULL) to clear the bus device private data pointer. However, the driver core code already sets the bus device private data pointer to NULL in device_unbind_cleanup() *after* devres_release_all(), which makes the call redundant. In addition, it can create unexpected NULL pointer dereference scenarios when drivers use managed APIs. int probe(struct usb_interface *intf, const struct usb_device_id *id) { struct data *data; int ret; data = devm_kzalloc(&intf->dev, sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; ret = devm_device_add_group(&intf->dev, &foo_attr_group); if (ret) return ret; ... } ssize_t foo_value_show(struct device *dev, struct device_attribute *attr, char *buf) { struct usb_interface *intf = to_usb_interface(dev); struct data *data = usb_get_intfdata(intf); /* Potential NULL pointer dereference */ return sysfs_emit(buf, "%u\n", data->value); } Nothing prevents usb_unbind_interface() to race with foo_value_show() and set usb_set_intfdata(intf, NULL). The same applies to the unwind path of usb_probe_interface(), which also calls usb_set_intfdata(intf, NULL). Besides that, the Rust driver core code manages a driver's bus device private data and destroys it in device_unbind_cleanup(). If usb_unbind_interface() sets the pointer to NULL prematurely, the Rust driver core code sees NULL, and hence skips the destructor of the bus device private data, which leaks all its resources. Thus, drop usb_set_intfdata(intf, NULL) from usb_probe_interface() and usb_unbind_interface(), and move it to usb_driver_release_interface(), which manually calls the remove() callback of struct usb_driver and hence can't rely on the driver core. Cc: stable@kernel.org Fixes: a995fe1a3aa7 ("rust: driver: drop device private data post unbind") Reviewed-by: Johan Hovold Acked-by: Alan Stern Signed-off-by: Danilo Krummrich Link: https://patch.msgid.link/20261010135131.286498-1-dakr@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 65f1c9838921ca0a7d58a134cf1dd721add5b966 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 3391418509d1ae2346719daa45bba822a364046b Author: Vincent Donnefort Date: Thu Oct 8 11:42:11 2026 +0100 KVM: arm64: Prevent 64-bit overflow when computing hyp clock rate [ Upstream commit 6164ce3491bcc3a27a2e2e9260a286eb2df2301e ] The hypervisor clock rate is delta_cycles * NSEC_PER_SEC / delta_boot. It is computed whenever a deviation occurs. If the delta between two rate updates is big enough, delta_cycles * NSEC_PER_SEC will overflow. Prevent overflow with mul_u64_u64_div_u64(). And as a bonus, simplify the clock estimation with mul_u64_u32_shr(). Fixes: b22888917fa4 ("KVM: arm64: Sync boot clock with the nVHE/pKVM hyp") Cc: stable@vger.kernel.org Signed-off-by: Vincent Donnefort Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Link: https://patch.msgid.link/20261008104212.3134550-2-vdonnefort@google.com Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 04bdd085d674fad7d8a66158fde1f6d85c73bdd8 Author: Evgeny Akhtimirov Date: Fri Oct 9 20:02:37 2026 +0400 ALSA: hda/realtek: Enable all four speaker amps on Lenovo ThinkBook X G2 IAH [ Upstream commit f2293e7b2ddd803b1461e0490f9b2f32089c1dd0 ] The Lenovo ThinkBook X G2 IAH (MTM 21TU) has an ALC287 codec with four CS35L41 amplifiers on I2C (CSC3551). It reports codec SSID 17aa:3929, which it shares with the ThinkBook 13x Gen 5, and PCI SSID 17aa:3842. Since PCI SSID 17aa:3842 has no quirk entry, the codec SSID matches ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD. That fixup binds only two amps (cs35l41-hda.0 and .1), while the CS35L41 configuration table describes four for 17AA3929. Amps .2 and .3 probe and load firmware, but they are never bound to the codec, so half of the speakers stay silent. Add a ThinkPad-style fixup chain that binds four I2C amps, and match the laptop by its PCI SSID so the ThinkBook 13x Gen 5 is not affected. Tested with hda_model=1028:0c4d (alias to ALC287_FIXUP_CS35L41_I2C_4): all four amps bind, apply their calibration and are runtime-active during playback. Cc: stable@vger.kernel.org Signed-off-by: Evgeny Akhtimirov Link: https://patch.msgid.link/20261009-thinkbook-x-g2-iah-v1-1-56012188aee0@devduty.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3fd39ef87eeef1c558d78492254f6ae5dbc79a61 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 44a4aca21bd78c25614afc7282d81ae46bcf038f 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 2a943b8c4613c90699cd0398d8b6034db16ee199 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 251c71e0d06fc96974b04c99b3d648a3c7b828a8 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 993809012afa39ff7a18c4851dfcd9513bbee941 Author: Guixin Liu Date: Thu Oct 8 11:46:12 2026 +0800 cxl/pci: Use the Device GPF DVSEC for restricted endpoints [ Upstream commit d2654fa0d841fa36ffa76577f83a2810d643ae19 ] cxl_gpf_get_dvsec() picks between the Port and the Device GPF DVSEC from the PCIe type of the given device, and only a plain endpoint counts as a device. A restricted CXL device is an endpoint too, but it falls into the port case and is probed for the Port GPF DVSEC instead of the Device GPF DVSEC. On an RCD, dirty shutdown tracking therefore never arms: the DVSEC lookup in cxl_nvdimm_arm_dirty_shutdown_tracking() fails, the dirty shutdown count stays invalid, and the warning complains about a missing Port GPF DVSEC on a device. Treat restricted endpoints as devices. Fixes: 36aace15d9bd ("cxl/pci: Drop the parameter is_port of cxl_gpf_get_dvsec()") 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-2-kanie@linux.alibaba.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 988997e24b4f4680bf5f9eefd4c8e805474db318 Author: Dave Jiang Date: Thu Oct 1 08:47:42 2026 -0700 cxl/port: Clear cached dport pointers when a dport is removed [ Upstream commit 019560d23450a320f4060ff235563a5277ea8033 ] Switch decoders cache dport pointers in cxlsd->target[], and nothing clears them when a dport is freed. Readers then dereference freed memory. KASAN caught it under a cxl_test load/unload loop with concurrent sysfs reads (abbreviated). Clear the matching slots from cxl_dport_remove(), walking the port's decoders the way cxl_port_update_decoder_targets() does on the add side. Scan all nr_targets slots, the target[] allocation size, and clear every hit. Fixes: 8330671c57c7 ("cxl: Add helper to delete dport") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Jonathan Cameron Reviewed-by: Li Ming Reviewed-by: Gregory Price (Meta) Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20261001154744.1095902-2-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 283fd5c240c0972fb8739c07522d82ae7188cb7c 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 0ca20b815b762420a8d2a12c8b967f1de2454ad3 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 5522da98153e39a9ddd0a59a41604a14114b63b4 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 fd3c45407873f0ec4c939eada01615b158676286 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 287d09b1911b14ab6daaa4f4cb48212484f8f8ec Author: Alexey Charkov Date: Fri Oct 2 11:13:26 2026 +0100 nvmem: rockchip-otp: Serialize reads [ Upstream commit 9fc6a1592d844c0397f115ee8cbd935169b9a71e ] The OTP controller is driven through a single set of registers holding a state machine which has to be stepped through for every word read, yet nothing keeps two readers out of each other's way. Concurrent reads interleave, and the outcome is either a reader bailing out: rockchip-otp 2a580000.otp: timeout during read setup or, worse, one of them silently taking delivery of the other's data. Reading two cells in parallel from userspace on RK3576 reproduces both within 150 iterations - 53 read errors and 9 corrupted results, the latter either losing their first word or, in one case, ending in the two bytes which belong to the other reader's cell - whereas the same reads issued sequentially never fail. Concurrency is not hypothetical here, as six thermal sensors source their trim values from the OTP and reach the driver straight from asynchronous driver probing. Guard the read path with a mutex. Reads are the only way into the hardware, as the driver registers no write callback, and they always run in process context, so a plain mutex spanning the whole clock-enable, read, clock-disable sequence is enough. Fixes: 755864feb729 ("nvmem: add Rockchip OTP driver") Cc: stable@vger.kernel.org Reviewed-by: Miquel Raynal Signed-off-by: Alexey Charkov Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20261002101329.1084348-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 827cf4797be48722c06d25771d32a42e1cecfad2 Author: Jianping Li Date: Fri Oct 2 11:12:20 2026 +0100 misc: fastrpc: Allocate entire reserved memory for Audio PD in probe [ Upstream commit 9e47ad9c562e82cabfbb9afa6c2b0dcdf2702a39 ] Allocating and freeing Audio PD memory from userspace is unsafe because the kernel cannot reliably determine when the DSP has finished using the memory. Userspace may free buffers while they are still in use by the DSP, and remote free requests cannot be safely trusted. Additionally, the current implementation allows userspace to repeatedly grow the Audio PD heap, but does not support shrinking it. This can lead to unbounded memory usage over time, effectively causing a memory leak. Fix this by allocating the entire Audio PD reserved-memory region during rpmsg probe and tying its lifetime to the rpmsg channel. This removes userspace-controlled alloc/free and ensures that memory is reclaimed only when the DSP process is torn down. The reserved-memory region is now mandatory for the Audio PD domain. Rather than failing rpmsg probe when it is missing, validate it in fastrpc_init_create_static_process() and reject only the static-process creation. This keeps the fastrpc device probing for all other domains even on a misconfigured device tree. Fixes: 0871561055e66 ("misc: fastrpc: Add support for audiopd") Cc: stable@kernel.org Signed-off-by: Jianping Li Reviewed-by: Ekansh Gupta Link: https://lore.kernel.org/all/20260814101955.234238-1-jianping.li@oss.qualcomm.com/ Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20261002101220.1084101-3-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 51731e49fe9a7359d4dd17e77189a21b29115233 Author: Yifei Gao Date: Fri Oct 2 11:12:19 2026 +0100 misc: fastrpc: fix double-free in fastrpc_map_attach() error path [ Upstream commit 09fa66ec1b4896ab841da085ca58b6433f28f07f ] map->table is assigned right after dma_buf_map_attachment_unlocked() succeeds. The two failure checks that follow, the len > map->size test and, where subsystem VMIDs are configured, a failed qcom_scm_assign_mem(), jump to map_err with map->table already set. map_err manually calls dma_buf_detach() and dma_buf_put() and then falls through to fastrpc_map_put(). Since that change the error path tail is fastrpc_map_put() -> fastrpc_free_map(), and fastrpc_free_map() already unmaps, detaches and puts the dma-buf whenever map->table is set. The two operations therefore run twice: the second dma_buf_put() drops an extra reference on map->buf, and dma_buf_unmap_attachment_unlocked() dereferences the map->attach already freed by the manual dma_buf_detach(). kref_init() sets the refcount to 1 with no intervening get, so the final fastrpc_map_put() frees the map synchronously and the redundant cleanup is deterministic. The len > map->size branch is reachable by an unprivileged process via FASTRPC_IOCTL_MEM_MAP with an fd whose dma-buf is smaller than the requested length, before any DSP invocation. Route both map->table-is-set failure branches to get_err instead of map_err, so fastrpc_free_map() is the single owner of the unmap/detach/put sequence. map_err is retained for the dma_buf_map_attachment_unlocked() failure, which is reached with map->table still NULL and an attachment that fastrpc_free_map() will not clean up, so its dma_buf_detach()/dma_buf_put() must still run manually. Fixes: 334f1a1cbe03 ("misc: fastrpc: Use fastrpc_map_put in fastrpc_map_create on fail") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yifei Gao Reviewed-by: Ekansh Gupta Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20261002101220.1084101-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d67122a7a4ebbaf7dc4d6b799c4d27335ebb28b3 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 ed81b5ad59038dd201464a84e2908e3a9211fabf 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 a73f8b6f08df8af70e6f4ef67a15331ce7b8e7a7 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 62e8367b36e911778329b89df5295bc0ee11d818 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 3ba642864653dbcece500b510e330abec42fc128 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 658109ba39303a4d4562baa93a344d6d6042522f 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 5c1cbd955faeffc4809da80bfd2b1c567337baf9 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 621e1976d48b2b345e1e2cee8efb21efe4a43487 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 1f5d212c5cec40d471a6e1c0a009c58007ee0b11 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 5e3df51d4699300f8cf5f30c84ee5944a4b87e40 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 90aa20dcd08586be5b57bbc8db3a80a46c1990e6 Author: Wentao Liang Date: Wed Sep 16 17:09:56 2026 +0000 xen/gntdev: Fix gntdev_dmabuf ref leak in dmabuf_exp_wait_released() [ Upstream commit 6f165abe2b40ede71c98956cd74cd17c18505e75 ] dmabuf_exp_wait_released() takes a reference on the exported gntdev_dmabuf with dmabuf_exp_wait_obj_get_dmabuf() and passes it to dmabuf_exp_wait_obj_new(), which drops that reference after adding the wait object to the wait list. When the wait object allocation fails, dmabuf_exp_wait_obj_new() returns ERR_PTR(-ENOMEM) early and the reference is never dropped, leaking a reference to the exported gntdev_dmabuf. Drop the reference on the allocation failure path so the reference is consumed whether the wait object is created or not. Fixes: 932d6562179e ("xen/gntdev: Add initial support for dma-buf UAPI") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260916170956.2086505-1-vulab@iscas.ac.cn> Signed-off-by: Sasha Levin commit 085c0bf53f3071e01f4cdc530cbc0f35760897b1 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 bf413f565ad9bef90ebfb91668de3ae28d3965a6 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 49ae55c52765cd38c08964e144bd99ced978f35f 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 c074497c77c10504dd25702d660784147ff9d4c7 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 f4a35345d97e9007028693ee32058c956dc3b09f 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 8dc1c898dc8d8ddb9a0ae9870bd161f58a6eb6ff 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 68beb72a47e77e3a775da17081138ebb5110a27a 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 2f1fb19b350643058d4b285beac1291842b1848c Author: Gregory Price Date: Sat Sep 26 06:51:10 2026 -0400 mm/madvise: use vm_normal_folio_pmd() in cold/pageout PMD range [ Upstream commit 0bd719cb607ef14bcd554e044bbd80dd901b9996 ] mmap a VM_MIXEDMAP region whose ->huge_fault installs a PMD through vmf_insert_pfn_pmd() - mshv_vtl_low does this, and needs CAP_SYS_ADMIN to open - then: madvise(p, PMD_SIZE, MADV_PAGEOUT); With a stand-in module for the driver: BUG: unable to handle page fault for address: fffff587c0000008 RIP: 0010:madvise_cold_or_pageout_pte_range+0x410/0x9b0 walk_pgd_range+0x52b/0xaf0 __walk_page_range+0x6a/0x1d0 walk_page_range_vma_unsafe+0x8e/0x120 madvise_pageout+0xb2/0x180 madvise_vma_behavior+0x46b/0xa90 do_madvise+0x108/0x190 __x64_sys_madvise+0x26/0x30 Nothing validates the pfn on the way in: can_madv_lru_vma() rejects VM_PFNMAP, but not VM_MIXEDMAP can_fault() *pfn = vmf->pgoff & ~(mask >> PAGE_SHIFT); vmf_insert_pfn_pmd() no pfn_valid() check pmd_folio() pfn_to_page() -> unpopulated vmemmap Even with a valid pfn the path is wrong. The mapping carries no rmap, so folio_maybe_mapped_shared() sees mapcount 0, and the walker goes on to folio_deactivate(), or folio_isolate_lru() plus reclaim_pages(), against a folio this mapping does not own. Use vm_normal_folio_pmd() and skip on NULL, as the PTE half of this same walker already does with vm_normal_folio(). This also filters the huge zero PMD, so its separate check is no longer needed. Link: https://lore.kernel.org/20260926105110.2156652-3-gourry@gourry.net Fixes: 3c8e44c9b369 ("mm: mark special bits for huge pfn mappings when inject") 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 Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Reviewed-by: Zi Yan Assisted-by: LLM Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Joshua Hahn Cc: Rakie Kim Cc: Ying Huang Cc: Peter Xu Cc: Jason Gunthorpe Cc: # v6.19+ Signed-off-by: Sasha Levin commit 8565957d9047029904b7541ba87f08a9e860b59e Author: Gregory Price Date: Sat Sep 26 06:51:09 2026 -0400 mm/mempolicy: use vm_normal_folio_pmd() in queue_folios_pmd() [ Upstream commit 9057170a941f0c5f4058f6fb9ab5d5fc9fcc9e83 ] Patch series "mm: stop calling pmd_folio() on special PMDs", v3. Two page table walkers resolve the folio behind a PMD with pmd_folio(), which is only valid for a PMD mapping a refcounted struct page: madvise_cold_or_pageout_pte_range() mm/madvise.c queue_folios_pmd() mm/mempolicy.c vmf_insert_pfn_pmd() installs special PMDs holding a raw pfn that need not have a memmap entry at all. Both walkers can reach one and fault on the first folio field read. The PTE halves of both already use vm_normal_folio(); these two patches make the PMD halves match. The four callers of vmf_insert_pfn_pmd(), and which walker each reaches: drivers/vfio/pci/vfio_pci_core.c VM_PFNMAP mempolicy drivers/gpu/drm/drm_gem_shmem_helper.c VM_PFNMAP mempolicy drivers/gpu/drm/panthor/panthor_gem.c VM_PFNMAP mempolicy drivers/hv/mshv_vtl_main.c VM_MIXEDMAP both can_madv_lru_vma() rejects VM_PFNMAP, so only mshv_vtl_low reaches the madvise walker, and that needs CAP_SYS_ADMIN. queue_pages_walk_ops supplies its own ->test_walk, so walk_page_test()'s generic VM_PFNMAP skip never runs and vfio-pci is reachable by any process holding the device fd. Hence the different stable tags. One behaviour change: mbind(MPOL_MF_STRICT) over a PMD mapped VM_PFNMAP region now returns 0 rather than -EIO. The PTE loop already returned 0 there. drm_gem_shmem and panthor are where this is observable, since they PMD map pages that do have a memmap entry and so never faulted. Reproducer ========== No hardware needed. An out of tree module stands in for the drivers above: three misc devices, each with a ->huge_fault calling vmf_insert_pfn_pmd(), plus VM_HUGEPAGE so the fault path takes the PMD branch. /dev/pmdspec_mixed VM_MIXEDMAP, pfn at the 1 TiB mark, no memmap /dev/pmdspec_pfnmap VM_PFNMAP, pfn at the 1 TiB mark, no memmap /dev/pmdspec_real VM_PFNMAP, real alloc_pages(PMD_ORDER) on node 0 Userspace maps the device into a PMD aligned window, reads one byte to fault the PMD in, checks a module parameter to confirm it went in, then issues the operation. vng --run --user root --memory 4G --verbose \ --append "numa=fake=2" \ --exec "insmod pmdspec.ko && ./pmdspec_test " numa=fake=2 gives a node 1 to bind to; the module allocates its real page on node 0, which is what makes queue_folio_required() true. subtest operation parent series -------------------------------------------------------------------- madv_cold madvise(MADV_COLD) oops ret=0 madv_pageout madvise(MADV_PAGEOUT) oops ret=0 mbind_mixed mbind(MPOL_BIND, n1, MPOL_MF_MOVE) oops ret=0 mbind_pfnmap mbind(MPOL_BIND, n1, MPOL_MF_STRICT) oops ret=0 mbind_real mbind(MPOL_BIND, n1, MPOL_MF_STRICT) -EIO ret=0 Two things the table shows that are easy to miss in the code: - mbind_mixed passes only MPOL_MF_MOVE. MPOL_MF_STRICT is not needed for a VM_MIXEDMAP vma: walk_page_test() only skips VM_PFNMAP, and vma_migratable() is true for VM_MIXEDMAP. - mbind_real demonstrates the user visible change (-EIO -> 0) This patch (of 2): mmap a VM_PFNMAP region whose ->huge_fault installs a PMD through vmf_insert_pfn_pmd() - a vfio-pci MMIO BAR does this - then mbind(p, len, MPOL_BIND, &mask, maxnode, MPOL_MF_STRICT); With a stand-in module for the driver: BUG: unable to handle page fault for address: fffff96dc0000008 RIP: 0010:queue_folios_pte_range+0xaf/0x440 walk_pgd_range+0x52b/0xaf0 __walk_page_range+0x6a/0x1d0 walk_page_range_mm_unsafe+0x193/0x230 queue_pages_range+0x64/0xa0 do_mbind+0x25e/0x640 queue_folios_pmd(), inlined above, calls pmd_folio() on that PMD. The pfn is raw MMIO with no memmap entry, so the folio lands in unpopulated vmemmap. Neither guard stops the walk: walk_page_test() skips VM_PFNMAP, but queue_pages_walk_ops supplies ->test_walk, so it never runs queue_pages_test_walk() honours vma_migratable(), but only while MPOL_MF_STRICT is clear A VM_MIXEDMAP vma needs neither flag, being vma_migratable(), so plain mbind(MPOL_MF_MOVE) reaches this too - and there the bad folio carries on into migrate_folio_add() and folio_isolate_lru(). mshv_vtl_low is such a mapping. Use vm_normal_folio_pmd() and skip on NULL, as the PTE loop in queue_folios_pte_range() already does with vm_normal_folio(). This also filters the huge zero PMD, so its separate check is no longer needed. mbind(MPOL_MF_STRICT) over a PMD mapped VM_PFNMAP region now returns 0 rather than -EIO. The PTE loop already returned 0 there. Link: https://lore.kernel.org/20260926105110.2156652-1-gourry@gourry.net Link: https://lore.kernel.org/20260926105110.2156652-2-gourry@gourry.net Fixes: 3c8e44c9b369 ("mm: mark special bits for huge pfn mappings when inject") 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: David Hildenbrand (Arm) Reviewed-by: Zi Yan Assisted-by: LLM Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Vlastimil Babka Cc: Jann Horn Cc: Joshua Hahn Cc: Rakie Kim Cc: Ying Huang Cc: Peter Xu Cc: Jason Gunthorpe Cc: Signed-off-by: Sasha Levin commit 189f030cf8e2eee47b8f53f1dd2be43b898adc21 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 269a9370df2c39f741a2dd673358af397c47078a Author: Ridong Chen Date: Mon Sep 7 10:54:45 2026 +0800 mm/mglru: fix ineffective memory protection for non-kswapd reclaim [ Upstream commit 15da1e4978dd4ea8f5faa6e15ee967ba4ad9a30a ] For MGLRU, memory.min/low is not honored during global proactive reclaim (writing to the root memory.reclaim) and global direct reclaim, because these paths shrink memcgs using stale protection (emin/elow). It can be reproduced as follows: # echo 7 > /sys/kernel/mm/lru_gen/enabled # cd /sys/fs/cgroup # mkdir -p a/b # echo 100M > a/memory.min # echo +memory > a/cgroup.subtree_control # echo 100M > a/b/memory.min # echo $$ > a/b/cgroup.procs # dd if=/dev/zero of=/tmp/testfile bs=1M count=200 # cat a/b/memory.current 222650368 # echo 500M > memory.reclaim -bash: echo: write error: Resource temporarily unavailable # cat a/b/memory.current 6070272 memory.min is 100M, yet reclaim drops a/b down to 6M, breaking the protection. The traditional LRU path is not affected because shrink_node() calls mem_cgroup_calculate_protection() for each memcg it visits during a top-down tree walk. Commit 30d77b7eef01 ("mm/mglru: fix ineffective protection calculation") moved the protection computation into lru_gen_age_node(), which only runs for kswapd. Non-kswapd global reclaim reaches shrink_one() through lru_gen_shrink_node() -> shrink_many() without any protection computation, so emin/elow are whatever a previous kswapd run left behind - or zero if kswapd never ran on this node. Relying on a prior kswapd pass is not correct either: a memcg's emin/elow are derived from its ancestors' memory.min/low settings and from children_min_usage, both of which change over time, so emin/elow go stale even after kswapd has run and must be recomputed at the point of reclaim. Introduce mem_cgroup_calculate_protection_path() which computes emin/elow along the root-to-target path only, by iterating through the cgroup ancestors array top-down. This avoids the full tree traversal that would be needed with mem_cgroup_calculate_protection(), limiting the cost to O(depth) per memcg - typically 3-5 levels. Call it from shrink_one() for the non-kswapd path so that each memcg about to be shrunk has correct protection values. Link: https://lore.kernel.org/20260907025445.1836238-3-ridong.chen@linux.dev Fixes: e4dde56cd208 ("mm: multi-gen LRU: per-node lru_gen_folio lists") Signed-off-by: Ridong Chen Signed-off-by: Andrew Morton Reviewed-by: Barry Song Reviewed-by: Johannes Weiner Assisted-by: Claude:claude-opus-4-8 Cc: Axel Rasmussen Cc: Chris Down Cc: David Hildenbrand Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Tejun Heo Cc: Wei Xu Cc: Yuanchu Xie Cc: Yu Zhao Cc: Signed-off-by: Sasha Levin commit 2748bfeb1c12aa99670c08a34f5ff07ba6945c89 Author: Ridong Chen Date: Mon Sep 7 10:54:44 2026 +0800 mm/page_counter: avoid integer overflow in effective_protection() [ Upstream commit 7809ce47b05671e1fa6d74bead892d6ad6c1403b ] Patch series "mm/mglru: fix ineffective memory protection for non-kswapd reclaim", v4. For MGLRU, memory.min/low is not honored during non-kswapd global reclaim (global direct reclaim and root-level memory.reclaim), because these paths shrink memcgs using stale protection (emin/elow). Patch 2 is the actual fix. Patch 1 is a prerequisite: an integer overflow in effective_protection(), spotted by the sashiko review tool, which patch 2's new caller would also be exposed to. This patch (of 2): effective_protection() scales a parent's protection by a ratio of page counts, e.g. for recursive protection: (parent_effective - siblings_protected) * (usage - protected) / (parent_usage - siblings_protected) The multiply is done at unsigned long width before dividing. On systems with >= 16TB RAM the product can exceed 2^64 and wrap, giving a bogus protection value and silently breaking memory.min/low enforcement. Use mul_u64_u64_div_u64() to multiply in a 128-bit intermediate. Because usage and parent_usage are not read atomically (a child is charged before its parent), usage - protected can briefly exceed the divisor, making the quotient overflow 64 bits and trap (#DE on x86). Cap it so the ratio stays <= 1. Reported by the sashiko review tool [1]. Link: https://lore.kernel.org/20260907025445.1836238-1-ridong.chen@linux.dev Link: https://lore.kernel.org/20260907025445.1836238-2-ridong.chen@linux.dev Link: https://sashiko.dev/#/patchset/20260826133054.88529-1-ridong.chen@linux.dev?part=1 [1] Fixes: bc50bcc6e00b ("mm: memcontrol: clean up and document effective low/min calculations") Fixes: 8a931f801340 ("mm: memcontrol: recursive memory.low protection") Reviewed-by: Barry Song Reviewed-by: Johannes Weiner Signed-off-by: Ridong Chen Signed-off-by: Andrew Morton Assisted-by: Claude:claude-opus-4-8 Cc: Axel Rasmussen Cc: Chris Down Cc: David Hildenbrand Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Tejun Heo Cc: Wei Xu Cc: Yuanchu Xie Cc: Yu Zhao Cc: Signed-off-by: Sasha Levin commit 49f45ab6369617ac7195c6c2a38d78e601a99bfb Author: Bingfang Guo Date: Thu Sep 10 11:46:58 2026 +0800 mm/memcg: clear folio memcg after changing per memcg stats [ Upstream commit 0b1b457ecc4f636d85e1a0fade05f3dee264f59a ] I notice extremely high swapcached count in the per memcg level memory.stat when running tests with cgroupv1 setup by swapping pages in and out. It seems that the counter never gets decreased so the value is rather useless and confusing to users reading it. So I think fixing it so that the value can reflect the actual swapcache usage correctly could be helpful. __memcg1_swapout() transfers the memsw charge of a folio to its swap entry and clears folio->memcg_data as part of that. In the vmscan swapout path it runs before __swap_cache_del_folio(), which then decrements the swapcache stats through lruvec_stat_mod_folio(). Since folio->memcg_data has already been cleared, folio_memcg() returns NULL and the NR_SWAPCACHE decrement only updates the node-level counter instead of the memcg's lruvec, leaking the per-memcg swapcache count. Users using swaps will read totally meaningless swapcache value from per memcg memory.stat, like 200GB of swapcache on a 64GB setup, which is quite confusing and may trigger monitoring alerts, if any. Move the __memcg1_swapout() call into __swap_cache_del_folio(), after the NR_FILE_PAGES and NR_SWAPCACHE updates but before __swap_cache_do_del_folio() removes the folio from the swap cache. This keeps the stats attributed to the folio's memcg while still recording the swap cgroup with a valid folio->swap. Add a swapout parameter so the plain swap_cache_del_folio() path is left unchanged. Link: https://lore.kernel.org/20260910-memcg-swapcache-stats-fix-v5-1-033f510ba748@tencent.com Fixes: 2732acda82c9 ("mm, swap: use swap cache as the swap in synchronize layer") Signed-off-by: Bingfang Guo Signed-off-by: Andrew Morton Acked-by: Kairui Song Cc: Axel Rasmussen Cc: Baoquan He Cc: Barry Song Cc: Chris Li Cc: David Hildenbrand Cc: Johannes Weiner Cc: Kemeng Shi Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Nhat Pham Cc: Shakeel Butt Cc: Wei Xu Cc: Yuanchu Xie Cc: Signed-off-by: Sasha Levin commit be83045ebb7d2dbda4657e837d6c418d200ace39 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 156cd6874ed93737820d7818f09aff59ae50f6c7 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 0f92664251dd850a63ea604e21559b24a6e952de 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 8c60564f03e0f83dfe4ee4484a3adcd4426f1594 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 427a41a9363b830518659280d3e2c54239bad098 Author: Hui Zhu Date: Fri Sep 11 16:00:51 2026 +0800 mm: memcg: reparent non-hierarchical lruvec stats on cgroup v2 [ Upstream commit 154c16a783b75105347cf5ed7731afc887308120 ] On cgroup v2, reparent_state_local() returns early and never moves the dying memcg's non-hierarchical state_local base counts to its parent. Meanwhile memcg_reparent_objcgs() rewrites objcg->memcg to the parent, so when the reparented folios are freed later, the negative deltas land on the parent's lruvec. The parent therefore receives the uncharges without ever having received the matching charges, and its state_local (NR_LRU_BASE + lru, MEMCG_SOCK, NR_SLAB_RECLAIMABLE_B, NR_SLAB_UNRECLAIMABLE_B) permanently underflows. Since lruvec_page_state_local() clamps negative values to zero, the underflow masks the parent's own legitimate pages. count_shadow_nodes() is the only reader of these non-hierarchical state_locals on cgroup v2, so the underflow directly distorts the workingset shadow node budget. Fix this by reparenting the lruvec state_locals on cgroup v2 as well, mirroring what cgroup v1 already does. Only the lruvec stats consumed by count_shadow_nodes() are moved; the memcg-level stats are left alone because on v2 they are exposed through the rstat hierarchical tree and are not read from state_local. Link: https://lore.kernel.org/4a7a64eed2b145ad535fedaea3624f8310c29d5b.1789096175.git.zhuhui@kylinos.cn Fixes: 8285917d6f38 ("mm: memcontrol: prepare for reparenting non-hierarchical stats") Signed-off-by: Hui Zhu Signed-off-by: Andrew Morton Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Johannes Weiner Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Wei Xu Cc: Yuanchu Xie Cc: Signed-off-by: Sasha Levin commit 268d1c7fbbca2f103d8eac97d08c49f1ff8a42c5 Author: Hui Zhu Date: Fri Sep 11 16:00:50 2026 +0800 mm: memcg: skip the RCU lock when the memcg is not dying [ Upstream commit 7c0a645068deaf4c3a8c619ddbb8b84c477f9a9a ] get_non_dying_memcg_start() takes rcu_read_lock() on every stat update, but the lock only protects the upward walk to a non-dying ancestor, which happens solely while a memcg is being offlined. The dying check itself reads the CSS_DYING flag of a memcg the caller already holds a reference to, so it is safe without the lock. Check memcg_is_dying() first and return immediately when the memcg is alive, taking the RCU lock only on the rare dying path. On an anon fault/charge churn workload in a memcg this recovers the ~0.6% overhead added by the previous patch (4368077 vs 4343159 pages/s before, back to ~4377000 pages/s after). Link: https://lore.kernel.org/9ffdbdfc96312e3e13cb8f056bfe26649492d949.1789096175.git.zhuhui@kylinos.cn Fixes: 7404bd37cfbe ("mm: workingset: use lruvec_lru_size() to get the number of lru pages") Signed-off-by: Hui Zhu Signed-off-by: Andrew Morton Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Johannes Weiner Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Wei Xu Cc: Yuanchu Xie Cc: Signed-off-by: Sasha Levin commit d008e783d7eb2fd8c93336460772172c812fc21d Author: Hui Zhu Date: Fri Sep 11 16:00:49 2026 +0800 mm: workingset: use lruvec_page_state_local() to count lru pages [ Upstream commit c7a37bac3ccc2732993705d3c3488b278b422ec6 ] Commit 7404bd37cfbe ("mm: workingset: use lruvec_lru_size() to get the number of lru pages") switched count_shadow_nodes() to lruvec_lru_size(). With CONFIG_MEMCG enabled, lruvec_lru_size() reads mz->lru_zone_size, which only the classic LRU paths maintain. MGLRU accounts its pages through __update_lru_size(), which skips that array, so with MGLRU on the four evictable LRU lists are always seen as empty. The shadow node budget (pages >> 3) then collapses to slab plus unevictable pages, and the workingset shadow shrinker reclaims eviction tokens almost as fast as they are created, losing thrashing protection. lruvec_page_state_local() reads lruvec_stats->state_local instead, which both classic LRU and MGLRU maintain. Switch back to it. The reparenting race this re-exposes on cgroup v2 is closed by the preceding patch that redirects dying-memcg stat updates for all hierarchies. Link: https://lore.kernel.org/2ed42f96aca124856ea30f774afb55cbe6d8ba58.1789096175.git.zhuhui@kylinos.cn Fixes: 7404bd37cfbe ("mm: workingset: use lruvec_lru_size() to get the number of lru pages") Signed-off-by: Hui Zhu Signed-off-by: Andrew Morton Acked-by: Shakeel Butt Reviewed-by: Barry Song Reviewed-by: Kairui Song Cc: Axel Rasmussen Cc: David Hildenbrand Cc: Johannes Weiner Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Wei Xu Cc: Yuanchu Xie Cc: Signed-off-by: Sasha Levin commit 3b0734f7924031128534696279da426d2d378470 Author: Hui Zhu Date: Fri Sep 11 16:00:48 2026 +0800 mm: memcg: redirect stats updates of dying memcgs for all hierarchies [ Upstream commit 7ee68fff2ba6740558cab195925b3a7ff7a1480f ] Patch series "mm: workingset: fix the shadow node budget under MGLRU", v5. Commit 7404bd37cfbe ("mm: workingset: use lruvec_lru_size() to get the number of lru pages") broke the workingset shadow node budget under MGLRU: lruvec_lru_size() reads mz->lru_zone_size, which MGLRU never maintains, so count_shadow_nodes() sees the evictable LRU lists as empty and the shadow shrinker reclaims eviction tokens almost as fast as they are created, losing thrashing protection. Patch 1 extends the dying-mcg stat redirection (previously cgroup v1 only) to all hierarchies, addressing the reparenting race that motivated 7404bd37cfbe. Patch 2 then switches count_shadow_nodes() back to lruvec_page_state_local(), which both classic LRU and MGLRU maintain. Patch 3 recovers the performance. Patch 1 added an unconditional rcu_read_lock() to the stat update fast path; patch 3 checks memcg_is_dying() first and takes the RCU lock only on the rare dying path. Patch 4 closes an accounting gap that patch 2 makes visible: on cgroup v2, reparent_state_local() never moves the dying memcg's non-hierarchical lruvec stats to the parent, so the parent receives the uncharges without the matching charges and its state_local underflows. Patch 4 reparents those stats, mirroring cgroup v1. Performance testing =================== The test script and the raw results are available at [1]. Environment: 10-vCPU QEMU guest, 8 GiB RAM, cgroup v2; 7 runs per configuration, medians reported. Workloads: w1-anon-churn: single-threaded anon fault/charge loop in a memcg (MADV_DONTNEED + re-fault, no reclaim). Every touch is a real fault with charge and memcg stat updates, so it stresses exactly the fast path patch 1 changes. This is the meaningful signal: it is not reclaim-bound, so the small fast-path overhead is not drowned out. w2-file-churn: file read loop under memory.high pressure (reclaim-bound; the differences below are within run-to-run noise and are shown for completeness only). w3-reparent: reparent accounting sanity check. w1-anon-churn (pages/s): classic LRU MGLRU base 4393028 4377122 patches 1-2 4385996 (-0.2%) 4352887 (-0.6%) patches 1-3 4381832 (-0.3%) 4377053 (+0.0%) w2-file-churn (MB/s): classic LRU MGLRU base 8277 8226 patches 1-2 8226 (-0.6%) 8123 (-1.3%) patches 1-3 8157 (-1.4%) 8294 (+0.8%) w3-reparent passed on all kernels. The small overhead visible with patches 1-2 comes from the redirection added by patch 1; patch 3 brings w1 back to the base level in both LRU configurations. The w2-file-churn differences are within run-to-run noise: that workload is reclaim-bound and too noisy to expose the small fast-path overhead, so w1-anon-churn is the meaningful signal. Patch 4 only touches the memcg offline path and is not exercised by these workloads. This patch (of 4): get_non_dying_memcg_start() redirects the stat updates of a dying memcg to its closest non-dying ancestor, but only on cgroup v1; on cgroup v2 the stats keep being accounted to the dying memcg itself. A later patch in this series restores lruvec_page_state_local() in count_shadow_nodes() to fix the broken workingset shadow node budget under MGLRU. count_shadow_nodes() is the only reader of those non-hierarchical state_locals on cgroup v2: when a memcg is offlined, its pages are reparented to the ancestor but their stat updates keep being accounted to the dying memcg, so count_shadow_nodes() computes a wrong shadow node budget and workingset thrashing protection is lost. This is user visible as premature reclaim of hot page cache and degraded performance under memory pressure. Apply the redirection to all hierarchies to fix this. Offlining is rare, so the added cost on the stat update fast path is limited to an rcu_read_lock() and a css_is_dying() check; the upward walk happens only while a memcg is dying. Link: https://lore.kernel.org/cover.1789096175.git.zhuhui@kylinos.cn Link: https://lore.kernel.org/c1ef4ef6a84cac479e573f4423b734dc8176f7d5.1789096175.git.zhuhui@kylinos.cn Link: https://gist.github.com/teawater/32f373ec41d185d840455eb167321a5a [1] Fixes: 7404bd37cfbe ("mm: workingset: use lruvec_lru_size() to get the number of lru pages") Signed-off-by: Hui Zhu Signed-off-by: Andrew Morton Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Johannes Weiner Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Wei Xu Cc: Yuanchu Xie Cc: Signed-off-by: Sasha Levin commit 94a138ce5baed8233c0d541fd14ac6d58bf1da8c 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 ce8381ddd3877529d28b42b11b43ed214b0f5452 Author: Jinmeng Zhou Date: Thu Sep 3 15:50:48 2026 +0800 mm/hugetlb: charge folios to the target mm's memcg [ Upstream commit c2deb1356d82c9d54bd2fcf1241cc97eb66fd81f ] HugeTLB folios are currently charged to the memcg of the allocating task. This gives the wrong result when a userfaultfd handler populates a HugeTLB VMA that belongs to another process. The UFFDIO_COPY ioctl operates on the userfaultfd context's mm, but get_mem_cgroup_from_current() charges the folio to the handler's memcg instead. This can be reproduced by placing the faulting process and its userfaultfd handler in different memory cgroups. Have the target process register a HugeTLB mapping with userfaultfd, trigger a missing fault, and let the handler resolve it with UFFDIO_COPY. The hugepage usage is then reported in the handler's memory.current instead of the target's. The generic userfaultfd population path avoids this problem by charging folios to dst_vma->vm_mm. Pass the target mm through hugetlb_alloc_folio() and charge the folio by using get_mem_cgroup_from_mm(). This preserves the existing charge timing and error handling while making HugeTLB userfaultfd population consistent with the generic path. Link: https://lore.kernel.org/20260903075048.3316-1-zhoujinmeng@bytedance.com Fixes: 8cba9576df60 ("hugetlb: memcg: account hugetlb-backed memory in memory controller") Signed-off-by: Jinmeng Zhou Signed-off-by: Andrew Morton Reviewed-by: Muchun Song Reviewed-by: Hongfu Li Cc: David Hildenbrand Cc: Johannes Weiner Cc: Michal Hocko Cc: Nhat Pham Cc: Oscar Salvador Cc: Roman Gushchin Cc: Shakeel Butt Cc: Signed-off-by: Sasha Levin commit 147a2a108156ca807b6ffc823faf1804cd6a11c5 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 029c47cc4762d04fc9ec8b32822ab47c891e5ac9 Author: Samuel Holland Date: Wed Oct 7 08:57:41 2026 -0700 riscv: cfi: Only write envcfg CSR when task is current [ Upstream commit ca47e289113552fcbd7ab9268cee1f0c27d35590 ] set_shstk_status() and set_indir_lp_status() take a task argument, which lets them operate on tasks other than current, but they always write the envcfg CSR for the current task. Fix this with the envcfg_update_bits() helper, which only writes the envcfg CSR when operating on current. Fixes: 61a0200211d31e ("riscv: Implement arch-agnostic shadow stack prctls") Fixes: 8a9e22d2ca5855 ("riscv: Implement indirect branch tracking prctls") Signed-off-by: Samuel Holland Link: https://patch.msgid.link/20261007155748.291814-2-samuel.holland@sifive.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 34dbcdd0562461805f2fd276593517794b41e487 Author: Samuel Holland Date: Wed Oct 7 08:57:40 2026 -0700 riscv: cfi: Bounds check restore token before swap [ Upstream commit df333b72c0e14d6cffec72ce9a00503f12d1e28d ] Currently the user-provided shadow stack restore token is not checked before being used as the address in ssamoswap.d. While an invalid restore token will be caught and raise SIGSEGV, this happens after writing 4 bytes of zeroes anywhere in the address space. Check that the restore token is at least a valid user address before the swap to ensure we do not scribble over kernel memory. Fixes: 66c9c713de59 ("riscv/signal: save and restore the shadow stack on a signal") Signed-off-by: Samuel Holland Link: https://patch.msgid.link/20261007155748.291814-1-samuel.holland@sifive.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit fbcbb54a4898984192b16764943af1be262bdb4d 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 425add03ad9a2fd539bcb02a62b892e19ff0600d 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 6a6a991a34ec7dc58fa3d5ba1190978dbe9c45aa 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 aca0862b91dd5a8a25518b6f56b7547651307d50 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 ec3c1b42566e6a66f643cadbfd14bdb250c4bf02 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 8c2401753d2ccad29807d249946f4b4482196f9b 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 6c0bb2ad0894673c8d3f1d6cb955bee810294bde 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 33a29d9cdf7dd89ed61295ce32ee4fe8db023ec9 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 1a1a6773c96bc0f976a736399ab3104a7a46ef4e 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 dba1adf68bc63649994e0e45e74fa6d97416013b 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 dcdfd7ae6ad12886fbdf8027304a8b38e0a32749 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 d68390d9859cc5dc91eb26a1570ce3a86a5d88c0 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 6bc3e7aa73fbdcf6cd48435d9a944d84594c53fc 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 7fb9168a25c406786b6dfe9b62ccb8ef8e3b7093 Author: Matej Sochan Date: Wed Oct 7 22:37:46 2026 +0200 ALSA: hda/realtek: Fix silent speakers on Lenovo Legion S7 15IMH05 [ Upstream commit 1c36207da79455402d981125fa09716991364e66 ] The speakers on the Legion S7 15IMH05 (PCI SSID 17aa:3811, ALC287) stay silent after a cold boot with the current quirk, which applies ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS. They only start working after a suspend/resume cycle. The amplifier setup is sent through COEF 0x24/0x26 on NID 0x20. On this machine the first pass of that sequence appears to only wake the amplifiers. Sending the identical sequence a second time makes both speakers work, provided the second write comes a few milliseconds after the first: back-to-back writes leave the speakers silent, a 7 ms gap makes only the right speaker work, and 8 ms or more is reliable. A dump of all COEF registers of NID 0x20 taken before and after the second write shows no difference. Add a dedicated fixup that writes the sequence, waits 20 ms to keep a margin over the measured minimum, and writes it again on every codec init. It chains to the same AUTOMUTE fixup as before. To share the sequence, move the verbs of ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS into a named array; this has no functional change for the other users of that fixup. Fixes: 67f4c61a73e9 ("ALSA: hda/realtek: Add quirk for Legion S7 15IMH") Cc: stable@vger.kernel.org Link: https://github.com/CachyOS/linux-cachyos/issues/792 Signed-off-by: Matej Sochan Link: https://patch.msgid.link/20261007-legion-s7-v1-1-8ea7fb7ee766@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 074a1738f21d076a514335e276ec623afd74cc25 Author: Devin Wittmayer Date: Wed Oct 7 14:09:58 2026 -0700 wifi: rtw89: usb: shorten the RX aggregation hold on RTL8922AU over USB 3 [ Upstream commit 83de3a16c7b37064a59305040ba9b0f93b832794 ] The RTL8922AU holds received frames for up to a millisecond before handing them to the host, a value carried over from the RTL8852CU. On USB 3 that adds up to a millisecond of round trip, and under load at 160 MHz the access point drops to lower rates and download suffers. Shorten the hold on USB 3 only. On USB 2 the bus is the limit, and a slow host needs the long hold to keep up. RTL8922AU on USB 3 at 160 MHz, power save off for the round trip: x86, 6 GHz x86, 5 GHz Pi 5, 6 GHz before after before after before after TCP down, 1 flow 613 1002 579 948 587 1010 Mbps TCP down, 8 flows 656 1187 629 1080 605 1122 Mbps round trip 2.33 1.29 2.25 1.18 1.42 0.84 ms busiest core, UDP 200M 8.4 12.8 8.3 12.9 2.1 3.3 % RTL8922AU on USB 2, Raspberry Pi 1 B+ at 5 GHz, 80 MHz: long hold short hold TCP up, 1 flow 102.3 87.7 Mbps CPU, UDP 20M 50.5 77.4 % loss, UDP 50M 3.8 85.7 % Fixes: 32cee8a9bb66 ("wifi: rtw89: usb: Enable RX aggregation for RTL8922AU") Reported-by: Nick Morrow Cc: stable@vger.kernel.org Signed-off-by: Devin Wittmayer Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20261007210958.56528-1-lucid_duck@justthetip.ca Signed-off-by: Sasha Levin commit 1d8cd3c8de8ca2715ebbc00158a1cd399bd21bde 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 f014772e79ccf8e8f3fa7d6047c93aa0bb8b7271 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 4b47d1c4af6bc4564943080332f69bce9ec3349f 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 fa00fa501717427bd4335ec7261f7e668bdbb4ff 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 b361082ce275966427d5fd6589dc02ca76ce14f2 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 abd42823f88c9008b76f4310fd28e748df8c9962 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 efd6cb0f3c91ddb28847b7f9ea6a7cf3503d3109 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 8275a14a338454930cfc005735af556e53a0ef2f Author: Yi Cong Date: Mon Aug 24 10:14:29 2026 +0800 wifi: mt76: mt792x: fix negative errno truncation in offload capability [ Upstream commit d0115096429ca090a592770c7645f9553a839954 ] Returning a negative errno as u8 turned -ENOENT into 0xfe, wrongly enabling CNM and NAN caps. Return int and default to no caps on error. Fixes: e8a264ccd2de ("wifi: mt76: mt7921: move init shared code in mt792x-lib module") Cc: stable@vger.kernel.org Signed-off-by: Yi Cong Link: https://patch.msgid.link/20260824021429.43761-1-cong.yi@linux.dev Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3db878dff2c59f410132db21fde2a321265d1590 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 c48e280d1000c4c2b1f7f4df4631031955c59b5b 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 d681a3aee651e95fa6daf6fdb44f3eacfc85a320 Author: Devin Wittmayer Date: Wed Sep 30 17:35:01 2026 -0700 wifi: mt76: move the channel survey when the channel changes [ Upstream commit 68342a7bd7e5e273e2969e3c0f4c62ee3d006ce8 ] mt7921 and mt7925 report every survey counter against one channel and never mark the one in use. With firmware channel management, both use channel contexts and never call __mt76_set_channel(), so phy->chan_state, phy->chandef and phy->main_chandef keep the first channel of the band. Update them when a context is assigned or changed, after booking the time spent on the old channel. This also makes the legacy rate lookup in mt76_connac2_mac_fill_txs() and mt7925_mac_add_txs_skb() use the band of the current channel. With two channel contexts (multi-channel or MLO), the survey follows the context that was assigned or changed last, since the driver reads the band 0 counters only. Tested on MT7922 over PCIe, MT7921AU and MT7925 over USB. Fixes: 41ac53c899bd ("wifi: mt76: mt7921: introduce chanctx support") Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Cc: stable@vger.kernel.org Reported-by: Chris Closes: https://lore.kernel.org/linux-wireless/CAHaeJsT8O8Nhq351hFp3NAL8e0iU85N-LBdYZ9nYHFHVy7t_hQ@mail.gmail.com/ Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20261001003501.2425492-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f3bc13045e36d180e5558bf556df1a3abfdbd5d3 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 e31af818bf5bc66b2d170a4ed9c28175890c8f7b Author: Devin Wittmayer Date: Sat Oct 3 16:30:56 2026 -0700 wifi: mt76: take rcu_read_lock in the USB/SDIO tx completion path [ Upstream commit a7871a7ae5a8625f0ba0a89454ac734c383dd538 ] The USB and SDIO completion path reads a station pointer that RCU protects, without holding the read lock. Lockdep catches it on the first association: mt76.h:1305 suspicious rcu_dereference_check() usage! no locks held by mt76-usb-status/1254. mt7925_usb_sdio_tx_complete_skb+0x119/0x130 [mt7925_common] mt76_queue_tx_complete+0x27/0x60 [mt76] mt76u_status_worker+0xed/0x1e0 [mt76_usb] mt7925/mac.c:856 suspicious rcu_dereference_check() usage! mt7925_tx_check_aggr.part.0+0xc2/0xe0 [mt7925_common] mt7925_usb_sdio_tx_complete_skb+0xa0/0x130 [mt7925_common] mt7921 does the same, and warns once instead of twice because its aggregation check reads the default link directly. The DMA path makes the same reads but completes from softirq, so it stays quiet. Take the read lock around the lookup and the check. Tested on 7.2-rc5 with lockdep, fresh module load per arm, 4000 packets each and no change to the link: splats before after MT7925 Netgear A9000 2 0 MT7921 Alfa 1 0 mt7921e same kernel 0 0 Fixes: dc66a129adf1 ("wifi: mt76: add a wrapper for wcid access with validation") Fixes: c22769de2509 ("wifi: mt76: mt7925u: use connac3 tx aggr check in tx complete") Cc: stable@vger.kernel.org Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20261003233056.94497-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ef03f7b02d5dd7915584697c7baa0393b8a257ef 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 ad626a35bd7884de79d6a3c27e70089490787838 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 ec6d03d8b21c3af9cfe94543e59a889caba171d0 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 ec2f830e698bc00eca117dfe0965089929ae7b21 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 ba6e31ad27f0acad5e2433adfed0fafaad54bedb 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 f1a53935d5bca2830d4a25e1aadaf6e724e7f427 Author: Fuad Tabba Date: Wed Oct 7 08:43:41 2026 +0100 KVM: arm64: timers: Compute an offset-applied CVAL from the current count [ Upstream commit 49930b1b557ceb698e0ab7f985ea41c99dc8bf22 ] When the hardware won't apply a timer's offset, KVM programs CVAL + offset and lets it compare that against the raw counter. The compare is unsigned (IsTimerConditionMet, DDI0487M_c J1.4.3.29): condition_met = (UInt(PhysicalCountInt() - offset) - UInt(compare_value)) >= 0; so adding the offset to both sides holds only while both sums wrap or neither does. A guest whose counter is ahead of the host's by more than CVAL has an expired timer that never fires, and one behind it can have a far-future timer fire at once. On a CNTPOFF_EL2 host the first case livelocks: each entry reloads the guest's CVAL, the timer fires, and the exit rewrites it as CVAL + offset before the host can take the interrupt. Without CNTPOFF_EL2 the timer hangs until the vCPU is next loaded, which is what Zenghui reported on a Kunpeng920. Program the value from the current count instead: CVAL + offset while the deadline is ahead, 0 once the timer has expired for the guest, ~0 past the counter's wrap. KVM recomputes it at load, at exit and on a trapped CVAL write, and an expired timer stays expired in between. The value can't be inverted, so with an offset timer_save_state() keeps the memory copy, and kvm_hyp_handle_timer() returns that copy for a guest hypervisor's read of its physical CVAL rather than subtracting the offset back out. Fixes: c605ee245097 ("KVM: arm64: timers: Allow physical offset without CNTPOFF_EL2") Fixes: 9404673293b0 ("KVM: arm64: timers: Correctly handle TGE flip with CNTPOFF_EL2") Fixes: 0bc9a9e85fcf ("KVM: arm64: Work around x1e's CNTVOFF_EL2 bogosity") Reported-by: Zenghui Yu Closes: https://lore.kernel.org/r/460258be-0102-e922-c342-4e87cd94b9e5@huawei.com Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20261007074343.324269-2-fuad.tabba@linux.dev Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 6b8252034796f8ad7da274a70f65d401a55ead1d 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 c55809688e4abbc4474f28849deea6e5cee2684c 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 7d1dee2239503ed378c9e76611febe62a2d4b3f4 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 ef96efd3fc90e673209ca5075bb359f5717448d8 Author: Eric Biggers Date: Mon Aug 31 14:23:16 2026 -0700 raid6: add missing vzeroupper to AVX-512 code [ Upstream commit b82cf9e49c1be7cf1fd8e1bd806b0cdd25ab8127 ] Since the AVX-512 optimized RAID6 code uses ZMM registers, execute vzeroupper before returning from it. This is needed to avoid degrading the performance of any later SSE code that may happen to be executed. Link: https://lore.kernel.org/20260831212316.213896-1-ebiggers@kernel.org Fixes: e0a491c12968 ("lib/raid6: Add AVX512 optimized gen_syndrome functions") Fixes: 13c520b2993c ("lib/raid6: Add AVX512 optimized recovery functions") Signed-off-by: Eric Biggers Signed-off-by: Andrew Morton Cc: Christoph Hellwig Cc: Signed-off-by: Sasha Levin commit 2b5dcbb815934eac89cdc62c6d4c49bbc89f2ece Author: Eric Biggers Date: Mon Aug 31 14:23:08 2026 -0700 raid6: add missing vzeroupper to AVX2 code [ Upstream commit 24f1241cdb056fd630e6710a916e0f7c8c910a70 ] Since the AVX2 optimized RAID6 code uses YMM registers, execute vzeroupper before returning from it. This is needed to avoid degrading the performance of any later SSE code that may happen to be executed. Link: https://lore.kernel.org/20260831212308.213855-1-ebiggers@kernel.org Fixes: 2c935842bdb4 ("lib/raid6: Add AVX2 optimized gen_syndrome functions") Fixes: 7056741fd9fc ("lib/raid6: Add AVX2 optimized recovery functions") Signed-off-by: Eric Biggers Signed-off-by: Andrew Morton Cc: Christoph Hellwig Cc: Signed-off-by: Sasha Levin commit 2b90fb34550499866c76a0f3d929e6c087cb0856 Author: Eric Biggers Date: Mon Aug 31 14:22:48 2026 -0700 xor: add missing vzeroupper to AVX code [ Upstream commit 7b8fc26c40d6cf4c6751a045c9e42bbb7e78d81b ] Since the AVX optimized XOR code uses YMM registers, execute vzeroupper before returning from it. This is needed to avoid degrading the performance of any later SSE code that may happen to be executed. Link: https://lore.kernel.org/20260831212248.213805-1-ebiggers@kernel.org Fixes: ea4d26ae24e5 ("raid5: add AVX optimized RAID5 checksumming") Signed-off-by: Eric Biggers Signed-off-by: Andrew Morton Cc: Christoph Hellwig Cc: Signed-off-by: Sasha Levin commit 38e26bd35926cbc90236112a5acfccabee7752d5 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 13c2a268eac34b044847cc3da9c1f85204a3deda 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 0cd83f04e3404be310a3b90b4a992de24c5df7f4 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 4b935a9de79e18130add24cd324d0c16ea15bd0c 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 1e482527aeb0cb45c923248961b82513801b64d4 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 0237ca9810cf9b999c9b787726e62d3bdf634f24 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 4f0fb378416eb6d059fd541de46245b258969d3c 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 60ea6ea084c60bb31c4980bf34b398e5ab35d3d9 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 3f87063217efc3b0198e49ec1a9b262ff81ac406 Author: Ackerley Tng Date: Wed Sep 9 10:11:01 2026 -0700 mm: hugetlb: drop refcount before freeing on memcg charge failure [ Upstream commit e95d29c5df84f19881cd30b491fc81aa98f44b45 ] When mem_cgroup_charge_hugetlb(folio, gfp) returns -ENOMEM, the folio has its refcount set to 1 via folio_ref_unfreeze(folio, 1). The error path calls free_huge_folio(folio) directly, which expects a refcount of 0. Hence, VM_BUG_ON_FOLIO(folio_ref_count(folio), folio) is triggered. Even with CONFIG_DEBUG_VM disabled, returning a folio with refcount 1 to the freelist can corrupt allocator state later. Use folio_put(folio) instead of free_huge_folio(folio) to properly drop the reference before freeing it. Link: https://lore.kernel.org/20260909-hugetlb-alloc-folio-memcg-charge-error-handling-v2-2-4b4a8a19a7f7@google.com Fixes: 991135774c0e ("memcg/hugetlb: introduce mem_cgroup_charge_hugetlb") Signed-off-by: Ackerley Tng Signed-off-by: Andrew Morton Reviewed-by: Muchun Song Reviewed-by: Joshua Hahn Cc: Alex Shi Cc: David Hildenbrand Cc: David Rientjes Cc: Dongliang Mu Cc: Frank van der Linden Cc: Hongxiang Lou Cc: James Houghton Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Ma Wupeng Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Nhat Pham Cc: Oscar Salvador Cc: Peter Xu Cc: Roman Gushchin Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Vishal Annapurve Cc: Vlastimil Babka Cc: Yanteng Si Cc: Signed-off-by: Sasha Levin commit 11afc840288ab10a95b41ce5e298ce415fef0204 Author: Ackerley Tng Date: Wed Sep 9 10:11:00 2026 -0700 mm: hugetlb: return -ENOSPC on memcg charge failure [ Upstream commit 956aeff185e7e16b989202bde0bb29859adba99d ] Patch series "Fix bugs in HugeTLB allocation when mem_cgroup_charge_hugetlb() fails", v2. In hugetlb_alloc_folio(), when mem_cgroup_charge_hugetlb() fails, there are 2 issues: 1. free_huge_folio() expects a non-refcounted folio and will VM_BUG_ON_FOLIO(). 2. -ENOMEM is returned, causing an infinite loop retrying the fault. This patch (of 2): When mem_cgroup_charge_hugetlb() fails with -ENOMEM, alloc_hugetlb_folio() currently propagates this error. This results in the page fault handler returning VM_FAULT_OOM. Because HugeTLB allocations are high-order and use __GFP_RETRY_MAYFAIL, they bypass the OOM killer. Returning VM_FAULT_OOM to the #PF handler without triggering the OOM killer (or having it make progress) leads to an infinite loop of retrying the fault. Avoid this loop by returning -ENOSPC when charging fails, which maps to VM_FAULT_SIGBUS, terminating the process cleanly. Make mem_cgroup_charge_hugetlb() fault handling use a common error handling path, the same handling used for hugetlb_cgroup_uncharge_cgroup{,_rsvd}(), which also don't trigger the OOM killer and hence opt to terminate the process with a SIGBUS. Link: https://lore.kernel.org/20260909-hugetlb-alloc-folio-memcg-charge-error-handling-v2-1-4b4a8a19a7f7@google.com Fixes: 991135774c0e ("memcg/hugetlb: introduce mem_cgroup_charge_hugetlb") Signed-off-by: Ackerley Tng Signed-off-by: Andrew Morton Reviewed-by: Muchun Song Reviewed-by: Joshua Hahn Cc: Alex Shi Cc: David Hildenbrand Cc: David Rientjes Cc: Dongliang Mu Cc: Frank van der Linden Cc: Hongxiang Lou Cc: James Houghton Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Ma Wupeng Cc: Miaohe Lin Cc: Michal Hocko Cc: Mike Rapoport Cc: Nhat Pham Cc: Oscar Salvador Cc: Peter Xu Cc: Roman Gushchin Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Vishal Annapurve Cc: Vlastimil Babka Cc: Yanteng Si Cc: Signed-off-by: Sasha Levin commit 211d4a6f1767a3ed44bcf3689d6788889959c926 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 cf2193daffa793607188eededf05c58bbaff0098 Author: SJ Park Date: Tue Sep 1 17:27:22 2026 -0700 mm/damon/core: copy nid for eligible_mem_bp damos quota goal commit [ Upstream commit d4a8b5ac2ec28f55bba9fad07b69bf375cd42704 ] damos_commit_quota_goal_union() is not updating the ->nid union field when the goal metric is DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP. Hence, if a DAMOS quota goal of the type is online committed in a way that it will reuse other quota goal's memory space, the new goal will work with a garbage nid value. As a result, the DAMOS scheme can show unexpected aggressiveness. Do the update. The user impact is not catastrophic. No leak or crash happens. Doing the quota goal online commit that can reproduce the issue is expected to be not common. This issue was not found by real users but the AI review. That said, the issue can reliably be reproduced. This issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260902002725.108635-4-sj@kernel.org Link: https://lore.kernel.org/20260827045035.94611-1-sj@kernel.org [1] Fixes: 9138e27a3bc3 ("mm/damon: add node_eligible_mem_bp goal metric") 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: # 7.2.x value. As a result, the DAMOS scheme can show unexpected aggressiveness. Do the update. The user impact is not catastrophic. No leak or crash happens. Doing the quota goal online commit that can reproduce the issue is expected to be not common. This issue was not found by real users but the AI review. Signed-off-by: Sasha Levin commit 6ce4f6041f0a3c0ea135a71f25c06e79c9b2530c Author: Karl Mehltretter Date: Tue Sep 22 22:51:37 2026 -0700 mm/damon/core: keep the temporal tuner quota over an unmeasured PSI round [ Upstream commit df7d9a0f8d916eeea375430ae3360724afecde15 ] The patch in mm-unstable of subject "mm/damon/core: handle uninitialized damos_quota_goal->last_psi_total" scores a PSI quota goal without a previous sample as achieved. This leaves the consist tuner's input unchanged, but the temporal tuner sets its quota to zero for an achieved goal. A running scheme with a nonzero temporal quota therefore loses a charge window after a quota-goal commit. Use the effective quota to preserve the temporal tuner's previous goal-achievement state during an unmeasured round, as SJ suggested [1]. Score the goal as achieved when the effective quota is zero and as not achieved otherwise. A new scheme's initially zero quota stays zero, and the consist tuner's behavior is unchanged. Move the PSI current-value calculation and last_psi_total update into a helper that takes the current PSI total. This lets a unit test cover the unmeasured and measured rounds without depending on system memory pressure. Link: https://lore.kernel.org/20260923055139.2982-1-sj@kernel.org Link: https://lore.kernel.org/damon/20260916001311.101024-1-sj@kernel.org/ [1] Fixes: 2dbb60f789cb ("mm/damon/core: implement PSI metric DAMOS quota goal") Signed-off-by: Karl Mehltretter Signed-off-by: SJ Park Signed-off-by: Andrew Morton Suggested-by: SJ Park Reviewed-by: SJ Park Reviewed-by: Kunwu Chan Assisted-by: LLM Cc: Lian Wang Cc: # 6.9.x Signed-off-by: Sasha Levin commit 02ec9946b0604ee54b5570f4c91e1413ef9ad219 Author: SJ Park Date: Tue Sep 1 17:27:21 2026 -0700 mm/damon/core: handle uninitialized damos_quota_goal->last_psi_total [ Upstream commit 29c6084658af41b5b1fefd873d26d441830ced34 ] When DAMOS_QUOTA_SOME_MEM_PSI_US metric damos quota goal is set, the PSI delta for the feedback loop is calculated using damos_quota_goal->last_psi_total. However, it is initialized only after the first feedback loop. The first iteration of the loop uses the uninitialized value. As a result, the feedback loop can change the effective quota in an unexpected way at the first iteration. The user impact of the issue is not big, because the issue impacts only the first iteration of the feedback loop. The feedback loop also has an internal cap of the quota adjustment. The wrong adjustment will soon be corrected over a few iterations. For this reason, doing no initialization at commit time was intentional. It is also explicitly commented. That said, nobody likes behaviors that are unexpected or difficult to be expected. Check last_psi_total initialization and skip the tuning round when it is not initialized. For this, initialize last_psi_total with U64_MAX in the goal creation and the goal commit time. U64_MAX means the field is not initialized. The tuning round shows the value and adjusts it to guarantee the current quota is maintained for the round, and last_psi_total is correctly initialized on the next round. Before this change, committing a new PSI goal on an existing PSI goal with goal-only DAMON sysfs command (commit_schemes_quota_goals) just worked. After this change, the tuning round right after the commit will be unnecessarily skipped, because last_psi_total is unconditionally marked as not initialized in the damos_commit_quota_goal_union(). This is an intended tradeoff for simplicity. Skipping just one round of tuning is no problem. Meanwhile it makes both the code and the behavior simple to understand. Also update the quota goal commit unit test for changed last_psi_total setup behavior. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260902002725.108635-3-sj@kernel.org Link: https://lore.kernel.org/20260718005316.89585-1-sj@kernel.org [1] Fixes: 2dbb60f789cb ("mm/damon/core: implement PSI metric DAMOS quota goal") 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.9.x Signed-off-by: Sasha Levin commit f1cd1c0a363f558a5e3de197bd49f375453f68d7 Author: SJ Park Date: Tue Sep 1 17:27:20 2026 -0700 mm/damon/tests/core-kunit: test committing psi goal to psi goal [ Upstream commit 938d5db367967e7dec5db0a6fd189112deafb8b6 ] Patch series "mm/damon: fix misc bugs in kunit, quota goals and sysfs refresh_ms". DAMOS quota goals commit unit test is mistakenly not testing a test case that was designed to test. DAMOS quota goals and DAMON sysfs refresh_ms file have bugs that can produce non critical but still unexpected behaviors. Fix the bugs. Patch 1 fixes the DAMOS quota goals commit unit test to cover a mistakenly uncovered case. Patches 2 and 3 fix the bugs in DAMOS PSI goal initialization and eligible_mem_bp online commit, respectively. Patch 4 fixes the bug in DAMON sysfs refresh_ms file handling. This patch (of 4): damon_test_commit_quota_goal_for() is set to test committing a new psi goal on an existing psi goal. However, damon_test_commit_quota_goal() is mistakenly not covering the test case. Add the test case. Link: https://lore.kernel.org/20260902002725.108635-1-sj@kernel.org Link: https://lore.kernel.org/20260902002725.108635-2-sj@kernel.org Fixes: 99f89debafc5 ("mm/damon/tests/core-kunit: add damos_commit_quota_goal() test") 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.19.x Signed-off-by: Sasha Levin commit 83584cc1f14d9102b612529fd26182f050f2cfad Author: Qinyun Tan Date: Tue Sep 1 19:51:04 2026 +0800 mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers [ Upstream commit 6a100811c7c5fa39d452ff2e380bd14efbc0208e ] With cgroup.memory=nokmem, shrinker_memcg_alloc() fails with -ENOSYS for shrinkers without SHRINKER_NONSLAB, and shrinker_alloc() falls back to a non-memcg-aware shrinker. On this fallback path, shrinker->id is never assigned and keeps 0 from kzalloc(), which is a valid id belonging to whichever memcg-aware shrinker registers first. __list_lru_init() copies shrinker->id unconditionally, so every list_lru backed by such a fallback shrinker (thp-deferred_split, zswap-shrinker, workingset shadow nodes, superblock lrus, ...) ends up with lru->shrinker_id == 0 instead of -1. Under nokmem the list_lru collapses to the shared per-node lists, but __list_lru_add() still calls set_shrinker_bit() against the memcg of the added object. Most list_lru users are unaffected because their objects resolve to a NULL memcg without kmem accounting, but the THP deferred split queue holds user folios, which are charged regardless of nokmem. On a system where no SHRINKER_NONSLAB shrinker registers, shrinker_nr_max stays 0 and every memcg's shrinker_info has map_nr_max == 0, so the first folio added by khugepaged triggers on every boot: WARNING: mm/shrinker.c:212 at set_shrinker_bit+0x99/0xa0 On systems where a SHRINKER_NONSLAB shrinker (btrfs, xfs) did register and expand the maps, there is no warning; instead bit 0 is set spuriously for an unrelated shrinker. shrinker->id is only meaningful while SHRINKER_MEMCG_AWARE is set, and all readers inside mm/shrinker.c already check the flag before using the id. Make __list_lru_init() do the same and fall back to -1, so set_shrinker_bit() is never reached with a bogus id. The stale shrinker->id itself is left as is; cleaning that up is a separate topic. Verified on a machine booting with cgroup.memory=nokmem and CONFIG_TRANSPARENT_HUGEPAGE=y: the warning fires once per boot from khugepaged, disappears when nokmem is removed from the command line, and no longer triggers with this fix applied and nokmem set. Link: https://lore.kernel.org/20260901115104.2944996-1-qinyuntan@linux.alibaba.com Fixes: fafaeceb89a5e ("mm: switch deferred split shrinker to list_lru") Signed-off-by: Qinyun Tan Signed-off-by: Andrew Morton Acked-by: Muchun Song Reviewed-by: Baolin Wang Reported-by: Wentao Guan Closes: https://lore.kernel.org/linux-mm/20260904190028.21542-1-guanwentao@uniontech.com/ Tested-by: Wentao Guan Cc: Michal Hocko Cc: Roman Gushchin Cc: Johannes Weiner Cc: Shakeel Butt Cc: Dave Chinner Cc: David Hildenbrand Cc: Lance Yang Cc: Michal Koutný Cc: Xunlei Pang Cc: Signed-off-by: Sasha Levin commit 181d9c05e1f32139008d72d05888e1bf3a2a41ba Author: SJ Park Date: Tue Sep 1 06:18:49 2026 -0700 mm/damon/core: handle extreme memory state in get_in_active_mem_bp() [ Upstream commit d9e43f46fb324e0a311146f937f0d214f023dc63 ] damos_get_in_active_mem_bp() uses the sum of the active and inactive memory amount as a denominator. In an extreme and unlikely environment, active and inactive memory might be zero. In this case, hence, it results in a divide by zero problem. Avoid it by changing the denominator to one if it is zero, before it is being used. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260901131850.98037-9-sj@kernel.org Link: https://lore.kernel.org/20260721034756.147011-1-sj@kernel.org [1] Fixes: 4835e2871321 ("mm/damon/core: introduce [in]active memory ratio damos quota goal metric") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: Usama Arif Cc: # 7.0.x Signed-off-by: Sasha Levin commit 6bc8eabed3cc6006a0088586851b4c93c18eda76 Author: SJ Park Date: Tue Sep 1 06:18:48 2026 -0700 mm/damon/core: handle extreme memory state in get_node_memcg_used_bp() [ Upstream commit c4b1ae3837ff381795f1fcc18d827fce48c4e89b ] In extreme unlikely situations, total memory might be zero. In less extreme but still very unlikely situations, lruvec_page_state() calls might let the caller show used memory larger than total memory. In the two cases, damos_get_node_memcg_used_bp() could cause division by zero, or return underflowed value, respectively. Handle the cases by respectively returning 100% and 0% for used and free memory queries in the corner cases. This issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260901131850.98037-8-sj@kernel.org Link: https://lore.kernel.org/20260329154813.47382-1-sj@kernel.org [1] Fixes: b74a120bcf50 ("mm/damon/core: implement DAMOS_QUOTA_NODE_MEMCG_USED_BP") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: Usama Arif Cc: # 6.19.x Signed-off-by: Sasha Levin commit dd5f656874190a4d4590cb741fec6f7b14cedf08 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 d846270bcf4cca2c3e728570db94179c904c106b Author: SJ Park Date: Tue Sep 1 06:18:46 2026 -0700 mm/damon/vaddr: respect folio end for DAMOS_MIGRATE_{HOT,COLD} [ Upstream commit 359093bdffbb3bd4d46d2d76d4a4dd273242c6d1 ] For applying DAMOS_MIGRATE_{HOT,COLD} actions 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_migrate_pmd_entry(), collects 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 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-6-sj@kernel.org Link: https://lore.kernel.org/20260514015053.149396-1-sj@kernel.org [1] Fixes: 09efc56a3b1c ("mm/damon/vaddr: consistently use only pmd_entry for damos_migrate") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: Usama Arif Cc: # 6.19.x Signed-off-by: Sasha Levin commit 96ebab42a7356bb8f201be3f68ae539cd82ee93b 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 fb83418139f5f48bec2eb2ccbbbf16c5045d228d 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 b627fe68f02d4d9434dce448ec61ea437218101d 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 ae1231a513082b73a0a91bb1f960f8d8e37610ce Author: SJ Park Date: Tue Sep 1 06:18:42 2026 -0700 mm/damon/core: skip applying scheme if region split for quota fails [ Upstream commit 90c2fa6adfed7abe0935506a43cdff3a05c1fff0 ] Patch series "mm/damon: fix DAMOS bugs in core, paddr and vaddr". Fix misc bugs of DAMOS. Patch 1 makes DAMOS less stress memory allocator under extreme situation. Patches 2 and 3 fix wrong folios walking in DAMON_PADDR. Patches 4 and 5 fix wrong folios walking in DAMON_VADDR. Patches 6-8 handle extreme and unlikely memory situations that can cause divide by zero and underflow. All bugs are discovered by Sashiko. This patch (of 8): damos_apply_scheme() splits a region and apply the action to the subregion if it is needed for not violating the quota. The split operation (damon_split_region_at()) could fail for allocation failure. In the case, the quota could be violated. From the user's perspective, DAMOS becomes more aggressive than expected under the extreme situation. Handle the failure. The user impact is not critical. The failure of damon_split_region_at() is unlikely since it is arguably too small to fail. Also DAMOS being aggressive is limited to the single region. Users can set min_nr_regions to set the maximum size of each region. If it is reasonably set, the transient overhead shouldn't be critical. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260901131850.98037-1-sj@kernel.org Link: https://lore.kernel.org/20260901131850.98037-2-sj@kernel.org Link: https://lore.kernel.org/20260718171523.87547-1-sj@kernel.org [1] Fixes: 2b8a248d5873 ("mm/damon/schemes: implement size quota for schemes application speed control") Signed-off-by: SJ Park Signed-off-by: Andrew Morton Cc: Usama Arif Cc: # 5.16.x Signed-off-by: Sasha Levin commit 85acfd8dba81887ad17ef32d4531b2c896843d50 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 b12effba7f01e03c61bc4dc49f40eb0896eb1bd7 Author: Kiryl Shutsemau (Meta) Date: Mon Aug 31 10:15:13 2026 +0100 mm/huge_memory: do not touch frozen folios in deferred_split_isolate() [ Upstream commit 5da8ec3262bbb40f057f3b0dacc18f37bda06f95 ] Patch series "Fix deferred_split_isolate() and drop the split workaround", v2. deferred_split_isolate() probes each queued folio with folio_try_get(). folio_try_get() failure is treated as a lost race with folio_put(). It leads to wrong results when !folio_try_get() was not caused by folio_put(): for a frozen folio, PG_partially_mapped gets wrongfully cleared and the folio dropped from the queue. It came up in the review of my collapse RFC series: https://lore.kernel.org/all/20260824131224.73344-1-lance.yang@linux.dev/ The bug is inert in upstream code: - __folio_split() works around it; - __folio_migrate_mapping() freezes a folio it is about to replace; - reclaim freezes only what try_to_unmap() already unmapped. No cc:stable needed. But my collapse rework steps on it, so it is worth fixing. The branch the first patch removes also hid an inert, pre-existing bug in the zone device path: https://lore.kernel.org/all/20260827163838.1813081-1-usama.arif@linux.dev/ The first patch fixes deferred_split_isolate(). The second patch removes the workaround for this deferred_split_isolate() behaviour from __folio_freeze_and_split_unmapped(). Tested in a VM: split_huge_page_test, folio_split_race_test and cow pass. Also ran a test that leaves 16 partially mapped THPs on the deferred split queue and drives thp-deferred_split through debugfs, checking nr_anon_partially_mapped. This patch (of 2): deferred_split_isolate() probes each queued folio with folio_try_get(). folio_try_get() failure is treated as a lost race with folio_put(): clear PG_partially_mapped, correct MTHP_STAT_NR_ANON_PARTIALLY_MAPPED, take the folio off the queue. The folio_put() race is the most common case for !folio_try_get(), but it is not the only option. Another scenario is folio_ref_freeze(). A zero refcount in such cases does not mean the folio is going away. It means "don't touch me" and current deferred_split_isolate() doesn't respect it. It can lead to unqueueing folios from the deferred list for no reason: CPU 0 CPU 1 --------------------------- ------------------------------ freeze a mapped folio deferred_split_scan() folio_ref_freeze() folio_try_get() fails folio_clear_partially_mapped() NR_ANON_PARTIALLY_MAPPED-- folio off the queue give up, put it back folio_ref_unfreeze() The folio is still partially mapped, but it is no longer a split candidate. Nothing queues it again until part of it is unmapped once more. Skip the folio instead: whoever freezes the folio, owns it and owner is responsible for its fate. It also covers the folio_put() case: __folio_put() unqueues the folio via folio_unqueue_deferred_split(). Nothing is lost by skipping. Everything that frees a queued folio unqueues it first, and folio_unqueue_deferred_split() clears PG_partially_mapped and brings MTHP_STAT_NR_ANON_PARTIALLY_MAPPED down on the way: __folio_put(), folios_put_refs() mm/folio.c __folio_migrate_mapping() mm/migrate.c shrink_folio_list() mm/vmscan.c __folio_freeze_and_split_unmapped() does the same by hand, under the list_lru lock it holds across the freeze. A freeze that ends in folio_ref_unfreeze() leaves a folio that is still partially mapped and still belongs on the queue. Link: https://lore.kernel.org/20260831091514.1879786-1-kirill@shutemov.name Link: https://lore.kernel.org/20260831091514.1879786-2-kirill@shutemov.name Fixes: 8422acdc97ed ("mm: introduce a pageflag for partially mapped folios") Signed-off-by: Kiryl Shutsemau (Meta) Signed-off-by: Andrew Morton Reported-by: Lance Yang Closes: https://lore.kernel.org/all/20260824131224.73344-1-lance.yang@linux.dev/ Reviewed-by: Zi Yan Reviewed-by: Johannes Weiner Reviewed-by: Lance Yang Acked-by: Usama Arif Reviewed-by: Baolin Wang Acked-by: David Hildenbrand (Arm) Assisted-by: Claude-Code:claude-opus-5 Cc: Balbir Singh Cc: Barry Song Cc: Dev Jain Cc: Hugh Dickins Cc: Kairui Song Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Ryan Roberts deferred_split_isolate() probes each queued folio with folio_try_get(). folio_try_get() failure is treated as a lost race with folio_put(). It leads to wrong results when !folio_try_get() was not caused by folio_put(): for a frozen folio, PG_partially_mapped gets wrongfully cleared and the folio dropped from the queue. It came up in the review of my collapse RFC series: https://lore.kernel.org/all/20260824131224.73344-1-lance.yang@linux.dev/ The bug is inert in upstream code: - __folio_split() works around it; - __folio_migrate_mapping() freezes a folio it is about to replace; - reclaim freezes only what try_to_unmap() already unmapped. No cc:stable needed. But my collapse rework steps on it, so it is worth fixing. The branch the first patch removes also hid an inert, pre-existing bug in the zone device path: https://lore.kernel.org/all/20260827163838.1813081-1-usama.arif@linux.dev/ The first patch fixes deferred_split_isolate(). The second patch removes the workaround for this deferred_split_isolate() behaviour from __folio_freeze_and_split_unmapped(). Tested in a VM: split_huge_page_test, folio_split_race_test and cow pass. Also ran a test that leaves 16 partially mapped THPs on the deferred split queue and drives thp-deferred_split through debugfs, checking nr_anon_partially_mapped. This patch (of 2): deferred_split_isolate() probes each queued folio with folio_try_get(). Signed-off-by: Sasha Levin commit f1a578ad1d0ca089fd297c6d1b22959790df582f 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 5972c107438a594d598835fe0dd7de05ee8829b9 Author: Gregory Price Date: Mon Aug 17 18:08:10 2026 -0400 mm/mempolicy: skip zone device folios when queueing folios [ Upstream commit 1f834ba9b42e3f3c298c7e8ef1df21b9947c92b4 ] queue_folios_pte_range() already pairs vm_normal_folio() with an explicit folio_is_zone_device() check before adding folios to the migration pagelist. vm_normal_folio() alone does not reject zone device memory (a present device-coherent page in a normal VMA is returned as "normal"). Mirror the explicit check in queue_folios_pmd() as well. queue_folios_pmd() uses pmd_folio() directly and can encounter a present zone device PMD - e.g. a device-coherent THP. This is not filtered by existing checks: !pmd_present() - only rejects non-present device-private and migration entries vma_migratable() - excludes DAX and VM_PFNMAP. The early return also means such a folio is no longer counted in qp->nr_failed under MPOL_MF_STRICT. This is the same pattern used by queue_folios_pte_range() (skipping zone device without failing). Link: https://lore.kernel.org/20260817220810.1175596-4-gourry@gourry.net Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages") Signed-off-by: Gregory Price (Meta) Signed-off-by: Andrew Morton Reviewed-by: Balbir Singh Acked-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Tested-by: Lance Yang Cc: Alistair Popple Cc: Baolin Wang Cc: Barry Song Cc: Byungchul Park Cc: Dev Jain Cc: "Huang, Ying" Cc: Jann Horn Cc: Joshua Hahn Cc: Liam R. Howlett Cc: Matthew Brost Cc: Rakie Kim Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Zi Yan Cc: Signed-off-by: Sasha Levin commit c30bf2e8df833c5a8d235f31f90b695cbd6f3101 Author: Gregory Price Date: Mon Aug 17 18:08:09 2026 -0400 mm/madvise: skip zone device folios in cold/pageout PMD range [ Upstream commit ab7ace574f3da7f167fe1883116480a00c52150c ] madvise_cold_or_pageout_pte_range() resolves the folio backing a PMD via pmd_folio() and ages or reclaims it without checking for zone device memory. The surrounding guards do not cover every zone device case: - can_madv_lru_vma() excludes VM_PFNMAP and VM_HUGETLB VMAs (so device DAX is filtered) - !pmd_present() branch above rejects device-private and migration entries, which are non-present. - A present zone device PMD - e.g. a device-coherent THP - is not filtered by any of these, nor by pmd_folio() (unlike vm_normal_page_pmd(), it performs no special/pfnmap check), and would be aged or paged out here. Skip ZONE_DEVICE folios explicitly during MADV_COLD/PAGEOUT. Link: https://lore.kernel.org/20260817220810.1175596-3-gourry@gourry.net Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages") Signed-off-by: Gregory Price (Meta) Signed-off-by: Andrew Morton Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Balbir Singh Tested-by: Lance Yang Cc: Alistair Popple Cc: Baolin Wang Cc: Barry Song Cc: Byungchul Park Cc: Dev Jain Cc: "Huang, Ying" Cc: Jann Horn Cc: Joshua Hahn Cc: Liam R. Howlett Cc: Matthew Brost Cc: Rakie Kim Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Zi Yan Cc: Signed-off-by: Sasha Levin commit 79b8838922c0f2eb2a7e58b5b4185d9d92992fed Author: Gregory Price Date: Mon Aug 17 18:08:08 2026 -0400 mm/huge_memory: skip zone device folios in madvise_free_huge_pmd() [ Upstream commit 3a09df924fa2ba75ac80acb9bce4eed79be218fa ] Patch series "mm: reject zone device folios in more folio walkers", v2. Several LRU-oriented mm walkers resolve the folio backing a PMD entry (or a physical pfn) and then reclaim, age, migrate, or lazyfree it without ever checking for ZONE_DEVICE memory. This series adds missing folio_is_zone_device() rejections, matching the checks that comparable walkers already perform. - mm/huge_memory, mm/madvise: the !pmd_present branch above these sites only filters device-private entries (which are non-present). A present zone device PMD (e.g. device-coherent) would still reach the folio and be lazyfreed / aged / paged out. Add an explicit check. - mm/mempolicy: queue_folios_pmd() can see a present zone device PMD (e.g. device-coherent) and queue it for migration. No crash reproducer - this is a correctness/hardening cleanup found by inspection. All checks are placed after the folio is resolved and before it is acted upon, on paths that already hold the relevant page-table lock, so no locking or refcount changes are involved. This patch (of 3): madvise_free_huge_pmd() resolves the folio backing a PMD via pmd_folio() and marks it lazyfree without checking for zone device memory. The surrounding guards do not cover every zone device case: - MADV_FREE only operates on anonymous VMAs (DAX mappings are excluded) - !pmd_present() branch rejects device-private and migration entries - present zone device PMD (device coherent THP) is not filtered. Unlike vm_normal_page_pmd(), it performs no special/pfnmap check, and would be marked lazyfree here. Bail out when the folio is a zone device folio. Link: https://lore.kernel.org/20260817220810.1175596-1-gourry@gourry.net Link: https://lore.kernel.org/20260817220810.1175596-2-gourry@gourry.net Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages") Signed-off-by: Gregory Price (Meta) Signed-off-by: Andrew Morton Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Tested-by: Lance Yang Cc: Alistair Popple Cc: Balbir Singh Cc: Baolin Wang Cc: Barry Song Cc: Byungchul Park Cc: Dev Jain Cc: "Huang, Ying" Cc: Jann Horn Cc: Joshua Hahn Cc: Liam R. Howlett Cc: Matthew Brost Cc: Rakie Kim Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Zi Yan Cc: Signed-off-by: Sasha Levin commit 8645813dad5bb05e2ef57eda0f195f2a2072b831 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 736429415fbdc0fcf3bf11af0c697b78887256d6 Author: Rik van Riel Date: Fri Aug 28 13:50:36 2026 -0400 mm/memcontrol: fix stuck FLUSHING_CACHED_CHARGE bit on isolated cpus [ Upstream commit d2f28a1a652e0a43f6f63de9b4e4d8d5f2716803 ] When drain_all_stock() sets FLUSHING_CACHED_CHARGE before checking isolation, schedule_drain_work() can drop the work in a separate RCU critical section, and housekeeping_update()'s synchronize_rcu() can race that second check, leaving the flag set. drain_local_stock() only clears the bit for work that ran, so the flag remains set and the stock is never drained again. Have schedule_drain_work() return whether the work was queued, and clear FLUSHING_CACHED_CHARGE in drain_all_stock() when the remote CPU is isolated, so future drains can retry. Link: https://lore.kernel.org/20260828135036.7d44361f@fangorn Fixes: 6a792697a53a ("memcg: do not drain charge pcp caches on remote isolated cpus") Suggested-by: Michal Hocko Suggested-by: Shakeel Butt Signed-off-by: Rik van Riel Signed-off-by: Andrew Morton Acked-by: Shakeel Butt Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Sasha Levin commit be590f68f4c60a4a9c5427956390d5803dd41ae7 Author: Hao Jia Date: Fri Aug 28 16:31:49 2026 +0800 zram: fix idle age_sec underflow in idle_store() [ Upstream commit 59042a88efe1d5ddc457f192f4c6368909693133 ] After commit 2e8ff2f51dde ("zram: use u32 for entry ac_time tracking"), idle_store() computes the idle cutoff as: cutoff = ktime_sub((u32)ktime_get_boottime_seconds(), age_sec); Because the left operand is cast to u32, when age_sec exceeds the current uptime the subtraction wraps modulo 2^32 and the huge result is zero-extended into the s64 cutoff. mark_idle() then marks every entry as idle instead of matching nothing. For instance, running echo 86400 > /sys/block/zramX/idle on a machine up for only two minutes marks all newly written pages idle and hands them to idle writeback and recompression. No slot can have been accessed before the system booted, so an age_sec that reaches back past uptime cannot match any slot. Return early in that case, without walking the table or taking any slot locks. Track the cutoff as time64_t rather than ktime_t. Both cutoff and ac_time are boot-time values in seconds, so a plain arithmetic comparison against ac_time in mark_idle() is correct and no ktime helpers are needed. Link: https://lore.kernel.org/20260828083149.45760-1-jiahao.kernel@gmail.com Fixes: 2e8ff2f51dde ("zram: use u32 for entry ac_time tracking") Signed-off-by: Hao Jia Signed-off-by: Andrew Morton Suggested-by: Sergey Senozhatsky Cc: Brian Geffon Cc: Jens Axboe Cc: Minchan Kim Cc: Signed-off-by: Sasha Levin commit 129d1347b47617b663e36f12d207fe21a905f1fd 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 ff51185900dd9accc8842a3f1bf85530ce501496 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 5c7804c729dfa89beea0b7424deff4abe60094d4 Author: Jiayuan Chen Date: Thu Aug 27 10:54:56 2026 +0800 mm/memcontrol: fix data-race on reading jiffies_64 [ Upstream commit c20cf1c3c8cdd98618d6fcc794003a0e003ae858 ] KCSAN reported a data-race between tick_do_update_jiffies64() updating jiffies_64 and mem_cgroup_flush_stats_ratelimited() reading it directly. Unlike jiffies, jiffies_64 is not volatile, so raw reads are plain accesses and can even be torn on 32-bit. Use get_jiffies_64() instead, and fix the same pattern in mem_cgroup_flush_foreign(). Link: https://lore.kernel.org/20260827025457.116191-1-jiayuan.chen@linux.dev Fixes: 508bed884767 ("mm: memcg: change flush_next_time to flush_last_time") Fixes: 97b27821b485 ("writeback, memcg: Implement foreign dirty flushing") Signed-off-by: Jiayuan Chen Signed-off-by: Andrew Morton Reported-by: syzbot+ced4d9a8cadb5ef3adae@syzkaller.appspotmail.com Acked-by: Muchun Song Acked-by: Johannes Weiner Acked-by: Michal Hocko Cc: Chris Li Cc: Jan Kara Cc: Jens Axboe Cc: Roman Gushchin Cc: Shakeel Butt Cc: Tejun Heo Cc: Signed-off-by: Sasha Levin commit ccc0b9d03b5c14d6f5a5ce96785745e19b9cf540 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 d3467070187d01d1dc24ea6cf1e5ee2743c75fd5 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 6c0948bbd244adbb1e72a01b1c9e5fa14ffbb12e 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 5ad79778884bb2a69378e5a03c51a4d334d68350 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 14291f4c2599b7683c8da3a030f8659c99146c86 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 a78ce86d1300887b3628648c929b105c58e785ab Author: Tommaso Merciai Date: Tue Sep 22 12:20:37 2026 +0300 dmaengine: sh: rz-dmac: Fix off-by-one in residue lmdesc lookup [ Upstream commit 9db8e502b34bc1df8078abd0169a4fa0624de3bb ] lmdesc->nxla is the address of the next descriptor, so comparing it against CRLA, which is the address of the current descriptor, finds the descriptor before the active one, not the active one. The residue loops below then summed one lmdesc too many on top of that. Compare each descriptor's own address to CRLA instead, and add tb after advancing to the next lmdesc. Fixes: 21323b118c16 ("dmaengine: sh: rz-dmac: Add device_tx_status() callback") Fixes: 172bfb57481c ("dmaengine: sh: rz-dmac: Add cyclic DMA support") Cc: stable@vger.kernel.org Suggested-by: Claudiu Beznea Signed-off-by: Tommaso Merciai Signed-off-by: Claudiu Beznea Reviewed-by: Frank Li Link: https://patch.msgid.link/20260922092037.224884-1-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f7bdf4668a70ab16a24afb0ebd33209b4644b8c5 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 74319a568e8e2dfe8ea029acce7c975de11f3412 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 0532109cf4b51fb95b71a44b3709d04e53cf67da Author: Diego Fernando Mancera Gomez Date: Sat Sep 5 00:28:33 2026 -0600 dmaengine: loongson2-apb-cmc: fix descriptor leak in prep_slave_sg() [ Upstream commit 4bbfc1d7e56134336dd1f792f51ee88a600a27ad ] loongson2_cmc_dma_prep_slave_sg() allocates the descriptor with kzalloc_flex() before iterating over the scatterlist. If loongson2_cmc_dma_set_xfer_param() fails inside the loop, the function returns ERR_PTR(ret) without freeing the descriptor. At this point the descriptor has not been handed to vchan_tx_prep() yet, so nothing else will ever free it, leaking it on every failed ->device_prep_slave_sg() call (e.g. an unsupported transfer direction or bus width). The neighbouring error path for the num_items check already frees the descriptor before returning; do the same on the set_xfer_param() failure path. Fixes: 1c0028e725f1 ("dmaengine: loongson: New driver for the Loongson Multi-Channel DMA controller") Link: https://lore.kernel.org/all/20260818094957.7D2221F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Diego Fernando Mancera Gomez Co-authored-by: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_012bUV3WshMSfTq61n1cgh1i Reviewed-by: Frank Li Link: https://patch.msgid.link/20260905062833.272484-1-diegomancera.dev@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4771f7d61e0691861aba4ae85b9dc2b5c0f6f449 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 72bde69388e8fa956776699162418d9b06c764fe Author: Myeonghun Pak Date: Sun Oct 4 00:34:51 2026 -0400 ASoC: stm: stm32_i2s: request IRQ after regmap initialization [ Upstream commit 1b207c85551fd74854d632116849295b2305245f ] The ISR accesses the managed regmap, but probe requests the IRQ before creating it. An early interrupt can reach an uninitialized regmap. Reverse-order cleanup can free the regmap while the IRQ remains active. Request the IRQ after regmap initialization so probe unwind and removal free and synchronize it before releasing the regmap. The teardown ordering issue was found by static analysis. Fixes: e4e6ec7b127c ("ASoC: stm32: Add I2S driver") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20261004043451.1138613-1-mhun512@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 04123ffb185934183944befdc5cbbb67ec8bb5b1 Author: Darrick J. Wong Date: Tue Sep 22 22:59:42 2026 -0700 xfarray: don't crash when sorting if array element crosses a folio [ Upstream commit 329750292e9dfbb594b375d7b30cf5ddb58b7bb9 ] LOLLM points out that if an array element crosses a folio boundary, xfile_get_folio returns a NULL folio pointer. If this happens, si->folio is also set to NULL, and calling folio_pos/folio_address will just crash the kernel. Teach this function to handle this condition by falling back to reading the array element into scratchpad memory. Cc: stable@vger.kernel.org # v6.6 Fixes: cf36f4f64c2d4e ("xfs: cache pages used for xfarray quicksort convergence") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit e99f09c7bc152844e728c963ebc2a0af7850d16c 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 f06ab53fbb196637d977d82473a24c0635987c98 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 9241db627f3a5ba923f4626ce2995644a35300d5 Author: Karl Mehltretter Date: Wed Sep 23 03:29:50 2026 +0200 spi: atmel-quadspi: balance runtime PM and pclk across system sleep [ Upstream commit 717e45f97246d1070cdf86ccd7a0fb872b45933a ] On the controllers with a generic clock (SAMA7G5, SAMA7D65, SAM9X7 and LAN969x), atmel_qspi_suspend() takes a runtime PM reference and returns without dropping it or suspending the device. It disables the peripheral clock directly. atmel_qspi_resume() only prepares the peripheral clock and then reinitializes the controller with that clock still off. On a SAM9X75 Curiosity board, the tested standby and mem resumes failed: atmel_qspi f0014000.spi: PM: failed to resume: error -110 spi-nor spi0.0: resume() failed Reading the flash afterwards returned no data. The runtime usage count grew by one with each cycle, and the second suspend disabled the peripheral clock again: WARNING: drivers/clk/clk.c:1257 at clk_core_disable+0x6c/0xcc qspi_clk already disabled Use the same runtime PM sequence as the other variants. Suspend disables the controller and forces a runtime suspend. Resume forces a runtime resume, which enables the peripheral clock, before it runs the init callback, and drops the reference afterwards. With this change the tested resumes succeed on the board in both modes, the controller returns to runtime suspend, and the flash reads back. Fixes: 5af42209a4d2 ("spi: atmel-quadspi: Add support for sama7g5 QSPI") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260709112006.390742-1-robert.marko%40sartura.hr?part=3 Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260923012950.15651-1-kmehltretter@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c26641b4d0469aea086c78fd3488b11ff4069b63 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 dac7ab558329574448526d5f7c6fbaf350096f47 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 116e2d03da1e50c18c1aa16e6225c21e27e0a567 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 7583b4cffa9ce0a767f595a47730d136e7a3c268 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 396a98fa8213d9da2343ab90138e220d86840e3b Author: Wentao Liang Date: Thu Sep 17 14:21:27 2026 +0000 power: supply: ltc2941: Fix of_node reference leak in ltc294x_i2c_probe() [ Upstream commit 09a29213bf15630e85a375478832b074b2cfc5c8 ] ltc294x_i2c_probe() takes a reference on the device node with of_node_get(), but never drops it, so the reference leaks on every return path, including the success path. The node is only used to read the battery properties and to set info->supply_desc.name, so release it after its last use and also on the lltc,resistor-sense error path. Fixes: 085bc24d1553 ("Add LTC2941/LTC2943 Battery Gauge Driver") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260917142127.2156568-1-vulab@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 8d9c49185c1f14ca2ec1c236a50d31bfab40e322 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 670d40b2461230cece418a87b399d1a2c69f583c 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 d1c1f7ed7f5d52344cb4cc90c777f44e1d2c6cf0 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 90896a3a833e070a93b9b2e3625d7c73568c84e2 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 b6f62366bc014a3a20fa0a3c42e51cadd198fb41 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 43ab03caf3784010f5d65547a65721c6abefa70d 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 4e7f4f372e0b214b567569bb9e6b1a6f6f54ba25 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 a2455ad533b121bf256392c6cd7cf205457a001e Author: Kazuki Hanai Date: Wed Sep 2 20:22:28 2026 +0900 media: mediatek: jpeg: Avoid context access after job finish [ Upstream commit 7c7f31405b76acd95a628c834ee8a2d6da439782 ] v4l2_m2m_job_finish() publishes job completion and wakes waiters before it returns. A concurrent file release can therefore finish v4l2_m2m_ctx_release() and free the context while the single-core IRQ handler continues with its tail. Both handlers only need the device for the matching runtime PM put. Use the IRQ-owned jpeg pointer instead of dereferencing ctx after completion has been published. This preserves the get/put pairing and removes the post-completion context access. Fixes: 45f13a57d813 ("media: platform: Add jpeg enc feature") Fixes: 5827e4b14ee7 ("media: platform: Improve power on and power off flow") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5 Signed-off-by: Kazuki Hanai Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9a308be404209c45c04318b936f99852d2d47813 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 5fcb8302045bca7c4ff851356ff54bb1a2897cf1 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 54e5aa1854d2c22cb6a95d40e6d5af675e5008ff Author: Guangshuo Li Date: Tue Sep 15 22:05:11 2026 +0800 media: rkvdec: do not destroy borrowed SRAM pool [ Upstream commit 19449e913cf0cb866957fe7ddc9b357f7244d079 ] rkvdec_probe() obtains a provider-owned SRAM pool with of_gen_pool_get(), but its error path incorrectly destroys the borrowed pool with gen_pool_destroy(). of_gen_pool_get() returns a pool managed by the SRAM provider. The pool is not created or owned by the rkvdec driver and is destroyed by the provider when its own managed resources are released. Destroying it when rkvdec_v4l2_init() fails can invalidate the pool while the provider and other consumers still reference it, and can also result in the provider attempting to destroy it again later. Remove the incorrect gen_pool_destroy() call from the probe failure path. This issue was found by manual code inspection. Fixes: e5640dbb991c ("media: rkvdec: Add RCB and SRAM support") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Detlev Casanova Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f760e5c5e83846aaf2a79649b4828ea40279d6b5 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 be02c5649ce74d701cf8dacfe850700c0ee3b5b3 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 7c7c65f48ca8c4fc94492c96ab81b13d9b2d097a 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 df79221ab69e8a08ecc7efc9455c6df28347ef33 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 70e8f46a3af1e5562ed1a9c2d6b5ff145d8caaa1 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 8124688da2569df407b5ae460e34f7add4c0170f 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 4f3eddcb5d594804b510d2eeaa55e2d16afc9a74 Author: John Keeping Date: Tue Sep 29 10:41:42 2026 +0100 media: rockchip: rga: fix rotation on rev0 hardware [ Upstream commit a67578c0179850e80cf08b1e0b8b1eb857f0fc46 ] On RK3288 where the RGA reports version zero [1], rotating a buffer gives corrupt output where one edge will be truncated. This is a result of some adjustment done specifically for hardware revision zero. But it seems this is not necessary and there is no evidence for why this adjustment should be applied on these hardware revisions. Comparing the TRMs between RK3288 with revision zero and RK3588 with revision 3.2 there is evidence of new features supported by later hardware, but nothing indicating any difference in behaviour for rotation which is supported by all hardware revisions. The logic here looks wrong anyway, since it's bizarre that minor revision zero would need the adjustment for _all_ major revisions. This was added with the initial version of the driver in commit f7e7b48e6d796 ("[media] rockchip/rga: v4l2 m2m support") so there is no detail in the Git history to indicate why this special-case might be needed. [1] Comparing with the vendor code, it seems this is actually 1.3 with the hardware reporting zero more by coincidence than design since the version register is not defined for RK3288. Fixes: f7e7b48e6d796 ("[media] rockchip/rga: v4l2 m2m support") Cc: stable@vger.kernel.org Signed-off-by: John Keeping Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2f643182e4feef3a41bec2dd98c1294750392326 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 cc038c90213d6ecd8cee8e28488fa6e5766c13e3 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 7c67c2c59d81f152f23df8b68989a68c2429b303 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 b981241852228f15e6f5c598ffa32074a7af1d21 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 9c8fb069ed9779a59b3966ff4c608c0fc183a7dd Author: Fan Wu Date: Sat Jul 4 08:46:59 2026 +0000 media: rockchip: rga: quiesce IRQ before releasing m2m state [ Upstream commit a875c43dd95ee4f9c4e3e5ae1cb8362cc6d7817d ] rga_remove() releases the m2m state before the IRQ is freed. The IRQ is devm-managed and is only released once rga_remove() returns, so rga_isr() can still run while the m2m device state is being torn down. Store the IRQ number in struct rockchip_rga, unregister the video device first, and free the IRQ before releasing the m2m state so the handler cannot run against the freed state. Fixes: f7e7b48e6d79 ("[media] rockchip/rga: v4l2 m2m support") Cc: stable@vger.kernel.org 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 5af696ab3427d5383b26c485b378199c66983f11 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 541d9baaaddda4f6a52abcebdb265f5ccbcc65e5 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 da167462dc9eccb0518fb372ff39cc18b946986d 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 e1c9b86e9b19088cda3ca23d592e3db6988257ae 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 6bc133d64056fbe0a9386d36913bb55b42028f4b Author: Sven Peter Date: Fri Aug 21 15:50:27 2026 +0200 phy: apple: atc: Support DUMMY PIPEHANDLER state in configure_pipehandler [ Upstream commit a2fd3d1f4db720ac1deb477ce4811c5e4e60e5f8 ] For both Thunderbolt and DisplayPort atcphy_configure_pipehandler is reached with a request to switch to the DUMMY state (i.e. usb2 only). With the current code this breaks USB2 when all four SS lanes are used for DisplayPort AltMode because the -EINVAL is passed all the way back to the phy_set_mode() call which results in tearing down xhci and dwc3 again. Let's actually handle that case correctly and also drop the default from the switch such that we get a compiler warning if another pipehandler state is ever added and forgotten here. Reported-by: Paul Cristian Closes: https://github.com/AsahiLinux/linux/pull/515 Fixes: 8e98ca1e74db ("phy: apple: Add Apple Type-C PHY") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter Reviewed-by: Janne Grunau Link: https://patch.msgid.link/20260821-b4-atcphy-usb4-v1-1-45c0b741e0c0@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 577f30068f40d5ba38da1e3cb38c514e9d610a56 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 55dff8c5cc0a57c4b90638843400a0596b078253 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 813bda74277ef6d8e2ccf3690295ec5ca2a9c0cc 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 cc87321f8a139cde8aa72f9bbbbed20c4c6104fa Author: Fuad Tabba Date: Thu Oct 1 14:56:56 2026 +0100 KVM: arm64: Pin the host vCPU before adjusting its PC under pKVM [ Upstream commit a2bb5f5c67a95ac97fcd6859dab51be421cf26fe ] Under pKVM, a page the host shares with EL2 is mapped at EL2 only while it's pinned, and the host vCPU is pinned at its first KVM_RUN. KVM_SET_VCPU_EVENTS with ext_dabt_pending reaches __kvm_adjust_pc() at EL2 before that, and dereferencing the unmapped host vCPU panics the hypervisor. Any process holding /dev/kvm on a pKVM host can trigger it. Pin the host vCPU around the adjustment when no hyp vCPU is loaded for it. A loaded hyp vCPU implies it's pinned. A pin fails only for memory the host isn't sharing, and the request is then dropped like any other bad host pointer. Fixes: efa1368ba9f4b ("KVM: arm64: Commit exceptions from KVM_SET_VCPU_EVENTS immediately") 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-4-fuad.tabba@linux.dev Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 71b0d6f368401cc1627b06ba2cb89c9a8d296e78 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 bc810c2401e5a2ab0544a2cc397f009b936b340c Author: Fabio Estevam Date: Wed Sep 9 17:13:46 2026 -0300 drm/panel: simple: Add Raystar RFF500F-AWH-DNN enable delay [ Upstream commit a92ed345422cd66329b5e9d4e82b0452e185f36f ] The RFF500F-AWH-DNN datasheet requires a minimum delay of 250 ms between display signal output and backlight power-on. Without this delay, the backlight can expose unsettled panel contents during display startup, resulting in a brief bright flash. Set the panel enable delay to the datasheet-specified minimum. Cc: stable@vger.kernel.org Fixes: 1b2a9ec82099 ("drm/panel: simple: Add Raystar RFF500F-AWH-DNN panel entry") Signed-off-by: Fabio Estevam Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260909201346.937343-1-festevam@gmail.com Signed-off-by: Sasha Levin commit 52ff769d770ed2352596396eaea59f71b3c3942b 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 043e094c5550a8b0d4073d4f531f5f403a423e2c 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 39f06c168e6e772fae37fa7fa3728bf592d03d01 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 0b9f7ad25e722e20bcb27c208320453f3425ce21 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 3b3310d34e227856b9f4d227d856be40b581aa63 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 523eb58df5c11531a99f2e75d08e10f20cc28565 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 09da3a7fe7951e7659ee924d79db38812064d666 Author: Eric Biggers Date: Tue Sep 22 22:11:16 2026 -0700 crypto: sa2ul - Fix HMAC key preparation [ Upstream commit 780cd10c8e78f97ed768be229acff0ffd5483477 ] sa_prepare_iopads() has multiple bugs, as discussed at https://lore.kernel.org/linux-crypto/20260831055141.1632832-1-s-vadapalli@ti.com/T/#u - Commit 3bf533787910 ("crypto: sha256 - Use the partial block API") introduced a 1-byte buffer overflow in the SHA-256 case by making the crypto_shash_export() write 1 more than sizeof(struct sha256_state). - It never worked for HMAC keys longer than 64 bytes in the first place. Fix both of these bugs by just using the crypto library to prepare the key, like what the chelsio and qat drivers do. Also remove the pointless use of an indirect call. Fixes: 3bf533787910 ("crypto: sha256 - Use the partial block API") Fixes: d2c8ac187fc9 ("crypto: sa2ul - Add AEAD algorithm support") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2de2a3831765bdbae600057f9ac0ea6ee795d4cc 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 866538c3129625fffbb91735ff93a3d31b0d3ce8 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 3e24599daf61a5c253c52933d6b2e47375b11668 Author: Anandu Krishnan E Date: Tue Sep 29 09:45:18 2026 +0530 arm64: dts: qcom: shikra: Remove cdsp compute-cb@9 [ Upstream commit 90ae3eb55ad64dc05ab7ad4a667c921d0504ccc4 ] Remove the context bank compute-cb@9 as it is a secure context bank used for secure use cases. Secure use case support is not currently implemented upstream, and allowing other use cases to be offloaded onto this context bank results in an SMMU fault. Fixes: 8b6f81f7801a ("arm64: dts: qcom: shikra: Add CDSP, LPAICP, MPSS remoteproc PAS nodes") Cc: stable@kernel.org Signed-off-by: Anandu Krishnan E Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260929-shikra-dts-cdsp-compute-cb-fix-v1-1-90e4abb873d6@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f1cfbb02bf8d91ad64643ba4e5867cde5b2c4eee 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 ddcd471e8a917d797c54337d2365dd1ad0663371 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 de19ed83caaa891a8e2ff8b658003650bcea7691 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 60656af31876dcac26fb38e333af67a1ffeba044 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 73e821b4b5ee9b6000b25a5d375fe416cbb2fa88 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 2a064e7057efe5ea0d8709822914ea2114700fe9 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 8625014a393b8e6cff9ad3b40094be84e62f7045 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 465428dd89a7770bb1aa4a804a74f94b3f6c246f 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 3a8d9af96642c7d9175a04542288711beda5d3fb 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 16802c8e3d7f63833f8bb96d159450544c529e50 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 d4855cfbaf1c41a35a5fc54d6245d7924934e14b Author: Christopher Snowhill Date: Tue Sep 29 19:00:06 2026 -0700 media: em28xx: fix inverted tuner capability check for VBI device [ Upstream commit a8296bfabd1112e690aad9acc7de3c431f39d0e6 ] Commit 8e53399c63c3 ("media: em28xx: Add support for Empia em2828X bridge") changed the condition for setting V4L2_CAP_TUNER on the VBI device from "dev->tuner_type != TUNER_ABSENT" to a check of the video device's capabilities, but inverted it: the VBI node now advertises a tuner only when the video node does not have one. On boards without a tuner (e.g. the MyGica iGrabber, card=105) the VBI device's device_caps therefore contain V4L2_CAP_TUNER, while the shared vidioc_querycap() correctly omits it from cap->capabilities. This trips the sanity check in v4l_querycap() whenever the VBI node is queried, for example by udev's v4l_id on every hotplug: WARNING: drivers/media/v4l2-core/v4l2-ioctl.c:1119 at v4l_querycap+0xff/0x110 [videodev] (cap->capabilities & (vfd->device_caps | V4L2_CAP_DEVICE_CAPS)) != (vfd->device_caps | V4L2_CAP_DEVICE_CAPS) It also leaves the tuner ioctls enabled on the VBI node of tuner-less boards and disables them on boards that do have a tuner. Restore the intended logic so the VBI device has V4L2_CAP_TUNER exactly when the video device does. Fixes: 8e53399c63c3 ("media: em28xx: Add support for Empia em2828X bridge") Assisted-by: LLM Signed-off-by: Christopher Snowhill Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 660c91b3100c949a0c33faf9d659d1c786ccd1ee 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 7eafaaf044f508bc60cf09082fc402265bd198ac 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 dd3af412de04c5253ff863c295ff53cd7628d4dd 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 158c67f31448316a64bcead55c5ed6736482f958 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 546536807ad441e63c92ee902860318e245182c1 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 f037f88eedce6dd8f5d84a2827ea9b8714b9243d Author: Linus Walleij Date: Wed Sep 23 23:10:33 2026 +0200 media: mali-c55: Ignore disconnected queues when checking readiness [ Upstream commit 9cfc1aca0781ce08e307b6c9dd617d37021544a8 ] mali_c55_pipeline_ready() waits for every video queue to enter its start_streaming callback, regardless of whether its media link is enabled. When libcamera uses the TPG, it disables the statistics and parameters links and queues only image buffers. Although STREAMON succeeds on the metadata nodes, videobuf2 never invokes their callbacks without queued buffers. The ISP and TPG are therefore never enabled and capture hangs. An unused full-resolution or downscaled output can similarly prevent the pipeline from starting. Only require queues connected through enabled media links to have started. Use media_pad_remote_pad_first() to check the video node pads, retaining the capability check before accessing the optional downscale device. The shared readiness check also keeps stream-off consistent: the first active queue to stop disables the ISP. Fixes: d5f281f3dd29 ("media: mali-c55: Add Mali-C55 ISP driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Linus Walleij Reviewed-by: Jacopo Mondi Signed-off-by: Jacopo Mondi Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit fe430842befe6f995b3017aae71a417434b6af50 Author: David Carlier Date: Sun Sep 6 10:24:25 2026 +0100 media: mali-c55: Check the statistics buffer address before filling [ Upstream commit 907273d00dabc60494a691907cfb9bb9bb50ab2f ] mali_c55_stats_cpu_read() copies the metering registers into the buffer returned by vb2_plane_vaddr() without checking it. As for the parameters queue, a DMABUF whose exporter cannot be vmapped yields NULL, and the memcpy_fromio() then dereferences it from the threaded interrupt handler. Report the failure to mali_c55_stats_fill_buffer() and complete the buffer with VB2_BUF_STATE_ERROR. Fixes: d5f281f3dd29 ("media: mali-c55: Add Mali-C55 ISP driver") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Reviewed-by: Jacopo Mondi Signed-off-by: Jacopo Mondi Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d9be08094c526cedb05f8068889c6bbfc757fe2a Author: David Carlier Date: Sun Sep 6 10:24:24 2026 +0100 media: mali-c55: Check the parameters buffer address before copying [ Upstream commit 901d72d26b6dc135a41e3901b4690de124665d18 ] mali_c55_params_buf_prepare() copies the parameters buffer supplied by userspace into the driver's scratch buffer, using the result of vb2_plane_vaddr() as the source without checking it. The queue accepts VB2_DMABUF, and vb2_dc_vaddr() returns NULL for an exporter that cannot be vmapped, so the memcpy() dereferences NULL. Reject the buffer at prepare time instead. Fixes: d5f281f3dd29 ("media: mali-c55: Add Mali-C55 ISP driver") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Reviewed-by: Jacopo Mondi Signed-off-by: Jacopo Mondi Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 60ce0c7ad6661577e2f3c6bbd5c5061a492b6f44 Author: David Carlier Date: Sun Sep 6 08:10:30 2026 +0100 media: mali-c55: Free the ISP control handler on unregister [ Upstream commit 5f09aaf3fbc0d592df65c1aaa2ad113e56940070 ] mali_c55_isp_init_controls() initialises isp->handler and adds the capabilities control, but mali_c55_unregister_isp() never frees it. Neither v4l2_device_unregister_subdev() nor v4l2_subdev_cleanup() touches sd->ctrl_handler, so the handler and its control are leaked on every unbind or module removal. The probe error path already frees it, and the TPG subdevice does so in its own unregister function. Fixes: d5f281f3dd29 ("media: mali-c55: Add Mali-C55 ISP driver") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Reviewed-by: Jacopo Mondi Signed-off-by: Jacopo Mondi Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a899494a8f6ef7f78a78635aef6103e9ce0c974c Author: Pengpeng Hou Date: Sun Aug 30 21:46:09 2026 +0800 media: mali-c55: fail power-on when safe stop times out [ Upstream commit 73d3d5c97c9c0d71ef9ac6bc72520fb1dc547702 ] The power-on path requests safe stop to establish a non-streaming state but ignores the polling result and publishes runtime resume success. Power the block back off and propagate a safe-stop timeout. Fixes: d5f281f3dd29 ("media: mali-c55: Add Mali-C55 ISP driver") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Reviewed-by: Jacopo Mondi Signed-off-by: Jacopo Mondi Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit db7fce6eb2a7699cb583ba07ad4e78dbd23d750a Author: David Carlier Date: Thu Aug 20 21:25:44 2026 +0100 media: v4l2-isp: reject zero-sized parameter blocks [ Upstream commit 43ba38e1e02bbfbe99d3c4145df3c24797586c97 ] v4l2_isp_params_validate_buffer() walks the blocks of a parameters buffer by adding block->size to the current offset. A block whose type_info[] entry is an uninitialised hole passes every check on the way there: a size of 0 is not caught by the block->size > buffer_size test, and the match against the type info size compares 0 with the hole's own 0 and passes as well. The walk then makes no forward progress and loops forever. Drivers build their type_info[] arrays with designated initialisers indexed by their block type enumeration, so an enumerator left without an entry leaves a zeroed hole rather than failing the build. Drivers call the validator from vb2 .buf_prepare, so such a hole turns a VIDIOC_QBUF on the parameters video device into an unkillable task spinning with the queue mutex held. Reject a block whose type info entry is empty. The driver does not implement the type, so it cannot tell whether the block content is meaningful, and accepting it silently would leave that content unconstrained until a later kernel implements the type and starts validating it. The size match then always runs against a non-zero size, and no block can advance the walk by zero. Fixes: 3cb6de6fafb8 ("media: v4l2-core: Introduce v4l2-isp.c") Cc: stable@vger.kernel.org Suggested-by: Jacopo Mondi Signed-off-by: David Carlier Reviewed-by: Jacopo Mondi Signed-off-by: Jacopo Mondi Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 29f8b5142ef6126400cc1e13dfd5bba267eaacc1 Author: Myeonghun Pak Date: Tue Aug 4 23:11:04 2026 +0900 media: renesas: rzv2h-ivc: manage runtime PM with devres [ Upstream commit 64e07ebcb3d054672cff678edb5344586d2d3286 ] Runtime PM is enabled before the IRQ is looked up. If that lookup fails, probe returns without disabling runtime PM. The subdevice initialization error path disables runtime PM but leaves autosuspend enabled, while the remove path does neither. Use devm_pm_runtime_enable() so the driver core disables autosuspend and runtime PM on every failed probe and after remove. This also makes the manual subdevice error unwind unnecessary. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: f0b3984d821b ("media: platform: Add Renesas Input Video Control block driver") Cc: stable@vger.kernel.org Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Jacopo Mondi Signed-off-by: Jacopo Mondi Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2fa18d965e228a303b75afec433ed8e6105add32 Author: Arnd Bergmann Date: Tue Sep 15 22:24:48 2026 +0200 media: mali-c55: add padding to mali_c55_params_ccm structure [ Upstream commit 2d3873cadda8537d8991abb24484bc590001fcbe ] The newly added structure has extra padding on the on some architectures, which triggers a pedantic uapi check: ./usr/include/linux/media/arm/mali-c55-config.h:807:1: error: padding struct size to alignment boundary with 2 bytes [-Werror=padded] Add explicit padding here to avoid risking information leaks and incompatibilities between architectures. Fixes: bb401df68c06 ("media: mali-c55: Add support for CCM") Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Reviewed-by: Vincenzo Frascino Reviewed-by: Linus Walleij Reviewed-by: Jacopo Mondi Signed-off-by: Jacopo Mondi Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ced1565397ddc42cb324d4d616698f494049eafc 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 c3ada827db09df4fcca54bd487e00f19ea241ef5 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 419c7a3d1dcbfb9fee0c9c0ad5b9cff281e0b470 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 86765e3827c5f4883fc5485e66fb730fbba8ddc6 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 a659248c3312bc7f85246673d0217e2fffb1be36 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 b06d407817052387507102f40832cc2933387fb7 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 1d9f1c71725d3e18ee4f2351bde68fff1d0c3f57 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 2c7e53207f48453e6185e1eda26160a63a0ec551 Author: Franz Schnyder Date: Mon Sep 28 17:00:46 2026 +0200 arm64: dts: freescale: imx95-aquila: Enable I2C_3_DSI1 on Clover board [ Upstream commit cffbc25c212bd41885094648918a935da0115a0e ] Enable lpi2c8, which is used for the I2C_3_DSI1 signals on the Clover carrier board. It was left disabled by mistake in the initial commit. Fixes: 3f519121e120 ("arm64: dts: freescale: imx95-aquila: Add Clover carrier board") Cc: stable@vger.kernel.org Signed-off-by: Franz Schnyder Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit baa8b3891a6225072e27370ff0abf1e2a1898771 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 9dbe5fe5c24355445bed55c961c9e8a05efda163 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 ed5ef3f88c235d06c438678a641eb0ec5fdc8801 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 2edc057609a080fcc1d7669455e111f173eb4825 Author: Li RongQing Date: Tue Sep 22 12:00:13 2026 +0800 vfio/pci: Restore 8-byte ioeventfd support [ Upstream commit b30b52c2fb82e6d38ee2845a4d85e8254b44f3d8 ] Commit b44a06bd28f2 ("vfio/pci: Remove #ifdef iowrite64 and #ifdef ioread64") inadvertently converted a conditional 8-byte rejection into an unconditional one. Originally, 'count == 8' was rejected only if iowrite64 was undefined (#ifndef iowrite64). When iowrite64 became globally available via generic fallbacks, this rejection became dead code, allowing 8-byte ioeventfds. However, b44a06bd28f2 removed the #ifndef wrappers but left the nested 'if (count == 8) return -EINVAL;' intact, breaking all 8-byte registrations. Drop the unconditional check to restore 8-byte ioeventfd support, matching the original intent. Fixes: b44a06bd28f2 ("vfio/pci: Remove #ifdef iowrite64 and #ifdef ioread64") Cc: stable@vger.kernel.org Signed-off-by: Li RongQing Link: https://lore.kernel.org/r/20260922040013.2188-1-lirongqing@baidu.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 5265aef398cfd4de4c8cd29cbac99b8d602992aa Author: Anirudh Srinivasan Date: Thu Sep 24 10:31:51 2026 -0500 clk: tenstorrent: Fix refcount leak on shared gate clk enable failure [ Upstream commit 3f0655b51eb01dad30d61ced0a81718211f2776e ] atlantis_clk_gate_shared_enable() increments the refcount for the number of clks requesting the shared gate clk to be enabled always. It should only do this when the enable for the gate took effect in hardware. It's possible to end up in a situation where the gate enable failed, but the refcount is incremented anyway, so subsequent requests by other clks that share the same refcount get ignored and the gate enable is never retried. Update this function so that the refcount is not incremented when the gate clk enable fails in hardware. Fixes: 23c8ebc95284 ("clk: tenstorrent: Add Atlantis clock controller driver") Cc: stable@vger.kernel.org Reported-by: Sashiko Link: https://sashiko.dev/#/patchset/AS8P251MB00013BD9A093C06D2D60E10EC8B42%40AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Signed-off-by: Anirudh Srinivasan Reviewed-by: Drew Fustini (Tenstorrent) Link: https://patch.msgid.link/20260924-atlantis_gate_shared_enable_fix-v1-1-303f925b8a3d@oss.tenstorrent.com Signed-off-by: Drew Fustini (Tenstorrent) Signed-off-by: Sasha Levin commit 46a0b522242d53852ec64b3c0875c9982bbf4fd0 Author: Aamir Ahmed Date: Sat Sep 5 21:48:35 2026 +0100 clk: tenstorrent: Assign .num before accessing .hws [ Upstream commit da9f1312b06e4c03d43d21494fb5beea7f9e096d ] 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 atlantis_prcm_clocks_register() due to .num being assigned only after every clock has been stored in .hws[]. 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, and with CONFIG_UBSAN_TRAP the first store traps so the clock provider never registers. Move the .num initialization to right after the allocation. Fixes: 23c8ebc95284 ("clk: tenstorrent: Add Atlantis clock controller driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Aamir Ahmed Reviewed-by: Gustavo A. R. Silva Reviewed-by: Anirudh Srinivasan Reviewed-by: Drew Fustini (Tenstorrent) Link: https://patch.msgid.link/AS8P251MB00013BD9A093C06D2D60E10EC8B42@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM [fustini: drop num_clks, use data->num per Gustavo] Signed-off-by: Drew Fustini (Tenstorrent) Signed-off-by: Sasha Levin commit 4dfa8994b7082ee56deccbc33ba508089d420f6f 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 02cb989b106625c38d953dd98533fb86f321941e 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 71a98fc0691dffbce0157fec31a0ea310552bde0 Author: Gaurav Batra Date: Thu Aug 6 15:50:27 2026 -0500 powerpc/pseries/iommu: Add TCEs for 16GB pages when RAM is pre-mapped [ Upstream commit 0b8b0c17a8998709ecb2852d56442ea981102941 ] In powerPC, if Dynamic DMA Window is big enough, RAM is pre-mapped. To determine the size of RAM, a PAPR+ property "ibm,lrdr-capacity" is used. This OF property dictates what is the max size of RAM an LPAR can have, including DR added memory. In PowerPC, 16GB pages can be allocated at machine level and then assigned to LPARs. These 16GB pages are added to LPAR memory at the time of boot. The address range for these 16GB pages is above MAX RAM an LPAR can have (ibm,lrdr-capacity). In the current implementation, these 16GB pages are being excluded from pre-mapped TCEs. A driver can have DMA buffers allocated from 16GB pages. This results in platform to raise an EEH when DMA is attempted on buffers in 16GB memory range. commit 6aa989ab2bd0 ("powerpc/pseries/iommu: memory notifier incorrectly adds TCEs for pmemory") Prior to the above patch, memblock_end_of_DRAM() was being used to determine the MAX memory of an LPAR. This included 16GB pages as well. The issue with using memblock_end_of_DRAM() is that when pmemory is converted to RAM via daxctl command, the DDW engine will incorrectly try to add TCEs for pmemory as well. Below is the address distribution of RAM, 16GB pages and pmemory for an LPAR with max memory of 256GB, memory allocated 64GB, 2 16GB pages and assigned pmemory of 8GB. RANGE SIZE STATE REMOVABLE BLOCK 0x0000000000000000-0x0000000fffffffff 64G online yes 0-255 0x0000004000000000-0x00000047ffffffff 32G online yes 1024-1151 cat /sys/bus/nd/devices/region0/resource 0x40100000000 cat /sys/bus/nd/devices/region0/size 8589934592 The approach to fix this problem is to revert back the code changes introduced by the above patch and to stash away the MAX memory of an LPAR, including 16GB pages, at the LPAR boot time. This value is then used whenever TCEs are needed to be pre-mapped - enable_DDW() or, iommu_mem_notifier() Fixes: 6aa989ab2bd0 ("powerpc/pseries/iommu: memory notifier incorrectly adds TCEs for pmemory") Cc: stable@vger.kernel.org Signed-off-by: Gaurav Batra Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260806205027.86428-1-gbatra@linux.ibm.com Signed-off-by: Sasha Levin commit bd366a8cd94a4e64a06fb4510d960725e25af7eb Author: Srish Srinivasan Date: Wed Sep 23 23:58:13 2026 +0530 pseries/plpks: hide wrapping_features when unsupported [ Upstream commit 46b8411b2ee948b1786bc4af76e7feede0c2ddff ] The PLPKS wrapping features config is only valid on systems that support the "Key Wrapping" feature. Currently the config is always exposed, even when the feature is unavailable. Add an is_visible() callback to suppress the wrapping_features sysfs attribute when the "Key Wrapping" feature is not supported. Declare the attribute group static const, as it is not modified after initialization. Fixes: 447eb1d5ef00 ("pseries/plpks: expose PowerVM wrapping features via the sysfs") Cc: stable@vger.kernel.org # 7.0 Signed-off-by: Srish Srinivasan Tested-by: R Nageswara Sastry Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260923182816.151451-10-ssrish@linux.ibm.com Signed-off-by: Sasha Levin commit a9ac83078b2adb1774feeef19e1e622e16e91d32 Author: Srish Srinivasan Date: Wed Sep 23 23:58:12 2026 +0530 pseries/plpks: fix self-reference in plpks_var initializer [ Upstream commit abcccecf4aa4b681f50eb7d7de93fc9a0a61c181 ] In plpks_gen_wrapping_key() and plpks_wrap_object(), strlen(var.name) is used to initialize var.namelen within the same struct initializer. This references a member of var before initialization of var is complete. Use the compile-time length of PLPKS_WRAPKEY_NAME instead. Reported-by: R Nageswara Sastry Fixes: 133aa79e211d ("pseries/plpks: add HCALLs for PowerVM Key Wrapping Module") Cc: stable@vger.kernel.org # 7.0 Signed-off-by: Srish Srinivasan Tested-by: R Nageswara Sastry Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260923182816.151451-9-ssrish@linux.ibm.com Signed-off-by: Sasha Levin commit d16d652ff50dd27686eeec7e903b20f363fc7e27 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 cffc9fee6df5ed4760d0b6c1c13ac1ec7249c201 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 d4d9c131624d4204b4e9faf5df01af18ace14a7d Author: Srish Srinivasan Date: Wed Sep 23 23:58:09 2026 +0530 pseries/plpks: clear sensitive buffers in wrapping operations [ Upstream commit 203695c109e37d8fe3531844218f75b98eef8e1f ] PLPKS wrapping key generation, object wrapping, and object unwrapping use authentication buffers that contain passwords. An object unwrapping failure also frees an output buffer that may 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: 133aa79e211d ("pseries/plpks: add HCALLs for PowerVM Key Wrapping Module") Cc: stable@vger.kernel.org # 7.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-6-ssrish@linux.ibm.com Signed-off-by: Sasha Levin commit 995849e64c032d147880e4adf00fdf264214ce83 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 29ea547fa05ea09fc40ada2c873f0f8a37282b07 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 53f960a9523ad428dc83e66061b84981e80a3040 Author: Srish Srinivasan Date: Wed Sep 23 23:58:06 2026 +0530 pseries/plpks: fix error code for wrapping key reads [ Upstream commit 0d0eafedcaf4939819d38ede6ad355ea37acd978 ] PLPKS variables with the PLPKS_WRAPPINGKEY policy bit set are not readable. Return -EPERM instead of -EINVAL in this case to better reflect the access restriction being enforced. Fixes: 133aa79e211d ("pseries/plpks: add HCALLs for PowerVM Key Wrapping Module") Cc: stable@vger.kernel.org # 7.0 Signed-off-by: Srish Srinivasan Tested-by: R Nageswara Sastry Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260923182816.151451-3-ssrish@linux.ibm.com Signed-off-by: Sasha Levin commit f6af47c9b04f78b9b992522e33d57a18466d290b 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 764eaae4a779009ef24e7803f09cb29877e213cb Author: Abhishek Dubey Date: Mon Sep 28 10:43:53 2026 +0530 powerpc/bpf: fix alignment of long branch trampoline address [ Upstream commit 04001e8ddb979f463f1c3ca8ac4d6ac59fb48921 ] Ensure the dummy trampoline address field present between the OOL stub and the long branch stub is 4/8-byte aligned, for memory compatibility when content loaded to a register. Reported-by: Hari Bathini Fixes: d243b62b7bd3 ("powerpc64/bpf: Add support for bpf trampolines") Cc: stable@vger.kernel.org Signed-off-by: Abhishek Dubey Signed-off-by: Saket Kumar Bhaskar Tested-by: Yeswanth Krishna Tellakula Tested-by: R Nageswara Sastry Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/a8257022057cbb71928c960be589e10b89fc0899.1789982239.git.skb99@linux.ibm.com Signed-off-by: Sasha Levin commit 0e7ec5fe2fc914e611cd0f9cfeb76a17ffbf5d6f Author: Abhishek Dubey Date: Mon Sep 28 10:43:52 2026 +0530 powerpc/bpf: fix buffer overflow in JIT for large BPF programs [ Upstream commit 78ce55b7913a78e1687306668e078b86bc6508ee ] During size calculation in pass-0, exit_addr is 0 since addrs[fp->len] is not yet populated. bpf_jit_emit_exit_insn() treats a zero exit_addr as in-range and skips bpf_jit_build_epilogue(), so the alternate inline epilogue instructions are not counted in alloclen. In later passes, if the real exit_addr falls outside the 32MB branch range, the full inline epilogue is emitted into the already-allocated buffer, writing past its end and corrupting adjacent memory. Fix by ensuring exit_addr is non-zero before treating it as in-range, so pass-0 always falls through to bpf_jit_build_epilogue() and conservatively accounts for all epilogue instructions in alloclen. Also range check alt_exit_addr directly in the else-if condition. Since exit_addr handling now falls through to the epilogue, two related issues in bpf_int_jit_compile() must also be addressed: 1. Reset cgctx.alt_exit_addr before the second size-calculation pass. Without this, a stale alt_exit_addr from the first pass causes the second pass to emit a single jump instead of the full epilogue, undercounting alloclen and reintroducing the overflow. 2. Recompute addrs[fp->len] at the end of each code-generation pass. The larger pass-0 body can shrink in later passes as out-of-range exits settle into in-range jumps; a stale addrs[fp->len] would leave exit branches targeting past the real (shrunken) epilogue. Because shrinkage in a later pass can move the epilogue offset, the fixed two-pass loop is no longer sufficient: an exit that was out of range in an earlier pass may fall in range once the epilogue offset shrinks, shrinking the body further and overwriting the start of the epilogue. Convert the code-generation loop to iterate until the program size converges, bounded by CODEGEN_MAX_PASSES, and fail the JIT if it does not converge. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/bpf/20260529015855.364704-2-adubey@linux.ibm.com/T/#mfcb23909d977b949727cca4f59ee56a13fd69b92 Fixes: 0ffdbce6f4a8 ("powerpc/bpf: Handle large branch ranges with BPF_EXIT") Cc: stable@vger.kernel.org Signed-off-by: Hari Bathini Signed-off-by: Abhishek Dubey Signed-off-by: Saket Kumar Bhaskar Tested-by: Yeswanth Krishna Tellakula Tested-by: R Nageswara Sastry Link: https://lore.kernel.org/bpf/20260529015855.364704-2-adubey@linux.ibm.com/T/#mfcb23909d977b949727cca4f59ee56a13fd69b92 Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/eebffa997e07781b384c4480e2b03c5b87c1aeb1.1789982239.git.skb99@linux.ibm.com Signed-off-by: Sasha Levin commit 67511cced5a1b9e4f1787b0ea1e53ca076f42639 Author: Abhishek Dubey Date: Mon Sep 28 10:43:51 2026 +0530 powerpc64/bpf: fix percpu private stack leak on JIT failure [ Upstream commit 24affb84d98e6b37b276aa57e5dd25ad93458cea ] The existing conditional statement in bpf_int_jit_compile() frees the percpu private stack at out_addrs only when the image buffer was never allocated. If bpf_jit_build_body() fails during a code-generation pass, the image buffer has already been allocated, so !image is false and the percpu stack is not freed. Because JIT compilation failed, fp->jited remains at 0. The subsequent bpf_jit_free() path only frees priv_stack_ptr when fp->jited is set, so freeing is skipped here too, leaking the percpu allocation. Fix implements freeing the private stack whenever fp->jited was not set, i.e. compilation did not succeed, instead of keying off !image. !fp->jited already covers the !image case, since image is only NULL on early-failure paths where fp->jited is likewise 0. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/bpf/20260616135426.A06B71F000E9@smtp.kernel.org Fixes: 156d985123b6 ("powerpc64/bpf: Implement JIT support for private stack") Cc: stable@vger.kernel.org Signed-off-by: Abhishek Dubey Signed-off-by: Saket Kumar Bhaskar Tested-by: Yeswanth Krishna Tellakula Tested-by: R Nageswara Sastry Acked-by: Hari Bathini Link: https://lore.kernel.org/bpf/20260616135426.A06B71F000E9@smtp.kernel.org Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/a827e3ef81cd43f2aee7e9bdfe8683f2c77065da.1789982239.git.skb99@linux.ibm.com Signed-off-by: Sasha Levin commit 1dca563f49b2a15ce26689d2d19d8bb7d3975d11 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 730c62d68cbc8905f348f99e7b74287f10c37e13 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 014c2c79599b09f4f5d87d2d5b3e7d880f2ba92d 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 3d481c056453fca8e10aa30f398eb7195ca009ba 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 f9a8f00bdd6de4c2217ba7074f10b6b9527e95c2 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 212eac2cbb2be397ea8f90f32b0e09cca8d4d2a4 Author: Vishnu Reddy Date: Tue Aug 18 21:24:17 2026 +0530 media: iris: Fix power-off ordering to disable power domain after clocks [ Upstream commit 9cfae7726a9a9f526e8905dbddde355be2674e3d ] In iris_vpu_power_off_hw(), iris_disable_power_domains() was called before the associated clocks (IRIS_BSE_HW_CLK, IRIS_HW_AHB_CLK, IRIS_HW_CLK) were disabled and unprepared. This reverses the correct power-down sequence: with the power domain already removed, the subsequent clk_disable_unprepare() calls end up operating on clock-controller hardware that is no longer powered, which can hang or behave unpredictably. Reorder the calls so iris_disable_power_domains() runs after all three clocks are disabled, ensuring clocks are always turned off while their power domain is still active, and mirroring the reverse of the power-on sequence. Fixes: bb8a95aa038e ("media: iris: implement power management") 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 b1f044531d9c7e84833ed28339296203250bad8c 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 190082e89a42776d653df54a59937b02b6bce52b Author: Vishnu Reddy Date: Tue Aug 18 20:43:22 2026 +0530 media: iris: Fix iova allocation from restrict region [ Upstream commit 200473c198b201c308dfb916fb3233074d9407fa ] 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: d7378f84e94e ("media: iris: introduce iris core state management with shared queues") Cc: stable@vger.kernel.org Reviewed-by: Vikash Garodia Reviewed-by: Dmitry Baryshkov Signed-off-by: Vishnu Reddy Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit be3d96d7e6fad161af5a8a8272f50424fa038d11 Author: Vishnu Reddy Date: Fri Jul 10 08:24:03 2026 +0530 media: iris: avoid bit depth validation for capture formats [ Upstream commit 40e9c3b3e35c6d65a3a0d3b1483716ad48b046bd ] When validating a capture format, check_format() compares the requested pixel format against inst->fw_caps[BIT_DEPTH]. However, the bit depth capability is not available at this stage and it contains the default value of BIT_DEPTH_8. The actual bit depth is updated later after the firmware reports stream capabilities through read_input_subcr_params(). Because of this, a valid client request of QC10C format request is rejected during the initial format negotiation. The driver then falls back to the default capture format (NV12) and stores it as capture format. Later, when the firmware reports that the stream is 10-bit, the driver sees NV12 as the selected capture format and switches to the default 10-bit format (P010). As a result, the original QC10C format requested by userspace is lost and QC10C decoding cannot work correctly. The bit depth information is not reliable during the initial format setup, so it should not be used to validate capture formats. Remove the bit-depth checks from check_format() and only verify that the requested pixel format is supported. This allows the format requested by userspace is handled correctly. Fixes: 20c3ef4c7cae ("media: qcom: iris: vdec: update find_format to handle 8bit and 10bit formats") 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 5bc84a24b90d278541b87d0fab0df56654b89442 Author: Vikash Garodia Date: Thu Sep 24 20:00:54 2026 +0530 media: iris: reset AHB bridge before enabling HW mode [ Upstream commit cc330f5589965bcf99307ee9c66deb8a0a53e0ee ] When video power domain is switched from software-controlled mode to hardware-controlled mode, the core may be powered down without the AHB bridge going through the required reset sequence. This may leave the bridge FIFO in a stale state. Reset the CPU-to-VPU AHB bridge before switching the power domain to hardware-controlled mode. This ensures that the bridge FIFO are in reset state before going for mode switch. Reported-by: Birk Skyum Link: https://lore.kernel.org/all/20260913194707.91885-1-birk.skyum@pm.me Fixes: 95a337f92f0a ("media: iris: switch to hardware mode after firmware boot") Cc: stable@vger.kernel.org Co-developed-by: Renjiang Han Signed-off-by: Renjiang Han Signed-off-by: Vikash Garodia Reviewed-by: Vishnu Reddy Tested-by: Birk Skyum # Lenovo Yoga Slim 7x Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin commit c2ffe9ae9db1382ac59274eaffbed2f493698d41 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 07f3f2b69bf7108eb98622c33bca6d6f6e800857 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 bb1d103df3c398f7775f488f85f0aa94060a4b94 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 71ae636d274ff2210318836cf62c51915db7e41b 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 270868567f879e0beff0579aefbf3f1acc0db355 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 416531e8b3fef9c9206ecb30c6b6fa19955dc438 Author: Danish Khateeb Date: Mon Sep 28 13:23:52 2026 -0500 ALSA: timer: Handle userspace-driven timer ioctls from 32-bit tasks [ Upstream commit 1bbc033983b76f41d51d4a48838bf94c5e6b6f50 ] 32-bit tasks on a 64-bit kernel can't use userspace-driven timers. The compat handler for /dev/snd/timer doesn't list SNDRV_TIMER_IOCTL_CREATE, so creating a timer fails with -ENOTTY. The file returned for a timer has no .compat_ioctl either, so SNDRV_TIMER_IOCTL_TRIGGER fails with -ENOTTY too. struct snd_timer_uinfo has the same layout for 32-bit and 64-bit tasks, and SNDRV_TIMER_IOCTL_TRIGGER takes no argument, so both commands can be passed through unchanged. The utimer selftest doesn't catch this when built with -m32: it takes -ENOTTY from SNDRV_TIMER_IOCTL_CREATE to mean CONFIG_SND_UTIMER=n and skips. Fixes: 37745918e0e7 ("ALSA: timer: Introduce virtual userspace-driven timers") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Danish Khateeb Link: https://patch.msgid.link/20260928182352.309457-1-danishkhateeb03@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f0dd015ed8ced512f64b1fa320600b24c5161712 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 69945942b1221a15a468748046de93947596dee4 Author: Michael Bommarito Date: Sat Jul 11 11:26:30 2026 -0400 fs/ntfs3: reject an oversized resident attribute on the inline iomap path [ Upstream commit 456189f9c714dee6716c2a3aad908e63830cac66 ] attr_data_get_block_locked() maps a resident attribute as a one-page IOMAP_INLINE extent: it allocates a single page, copies the resident value into it with memcpy(), and hands that page to ntfs_iomap_begin() as the inline data. The copy length is the on-disk resident value length (res.data_size), and mi_enum_attr() only bounds that length against the MFT record size. A corrupted volume with MFT records larger than a page can therefore present a resident $DATA whose length exceeds PAGE_SIZE, and the memcpy() then writes past the single destination page. Impact: reading or writing a resident file on a mounted crafted NTFS volume whose MFT records are larger than a page overflows the one-page inline buffer in attr_data_get_block_locked() with attacker-controlled bytes. Reject such an attribute in attr_data_get_block_locked(), before the page is allocated and the copy is made. Fixes: 099ef9ab9203 ("fs/ntfs3: implement iomap-based file operations") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 3d5dbe7706a9d58b8356731aaafefb8053711b27 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 1b72aab9d658195460c4525729f090fbda26c098 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 8e98d2c933de71af6b449679f53ec23a21a28fce Author: Rupesh Majhi Date: Mon Sep 21 21:31:23 2026 +0300 iio: pressure: dps310: fix CFG_REG bit definitions [ Upstream commit 4334dc4092c271e6cd010c2ee70b7f4415c4c199 ] Driver defines them as BIT(4), BIT(5) and BIT(6). Per datasheet P_SHIFT is bit 2, FIFO_EN is bit 1 and SPI_MODE is bit 0. Only P_SHIFT has a user. dps310_set_pres_precision() sets it at oversampling 16 or above, so with wrong bit the result register is never shifted and stops matching the scale factor compensation divides by. in_pressure_input returns -ERANGE at oversampling 16, 32 and 64. FIFO_EN needed by FIFO support later in this series. Fixes: ba6ec48e76bc ("iio: Add driver for Infineon DPS310") Fixes: d711a3c7dc82 ("iio: dps310: Add pressure sensing capability") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Rupesh Majhi Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 58d5c8c7df8d94caca5e3c0dbe41c2f7ce42816c 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 dcb2e7ad23acb8729b2b9ebaf391cc9793023353 Author: Ariana Lazar Date: Thu Sep 24 15:59:19 2026 +0300 iio: dac: mcp47feb02: Avoid unjustified probe error on missing label [ Upstream commit bce5b7e29e72538ba61f76c6d534a58ab3838438 ] Fix unjustified probe error on missing optional 'label' property by replacing dev_err_probe() with dev_warn_probe(). Correct %pfw usage by passing the child fwnode handle directly in the error message. Besides the probe warning a read error is returned at the attempt of reading a null label. Fixes: bf394cc80369 ("iio: dac: adding support for Microchip MCP47FEB02") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260804134616.1D8A21F00A3E@smtp.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Ariana Lazar Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 250a6a02dd7636ed84d7077cc13a184d9badf367 Author: Jiale Yao Date: Fri Sep 25 20:43:31 2026 +0800 iio: accel: sca3000: reject devices without match data [ Upstream commit bee629c18a9389cfbbe182df954cf49a9066b383 ] 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. sca3000_probe() immediately dereferences the returned chip information to set the IIO device name and channel layout, 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: d6ae9f202f61 ("iio: sca3000: 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 e5f828765e23541a120450ed7ac757292029f444 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 003b5a5bf03127f104ec643eb35fd8604bf3bd6a Author: Jiale Yao Date: Fri Sep 25 20:43:29 2026 +0800 iio: accel: adxl372: reject devices without match data [ Upstream commit c72144098fa9205e9b1d08545e7d9b54a2e0aaf3 ] 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. adxl372_spi_probe() passes the result to adxl372_probe(), which dereferences chip_info to set the IIO device name and capabilities, 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: 23d742859a2d ("iio: accel: adxl372: introduce chip_info structure") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 30dc79cebd92896dd9f0ea8525811d27e7a8b6e6 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 ca56df9fda43636854df6110ccb1aba1f6acb857 Author: Jiale Yao Date: Fri Sep 25 20:57:47 2026 +0800 iio: adc: ti-ads7950: validate SPI match data [ Upstream commit 6bdeaf23ef8062f4c38c025c50e524f1e4d59647 ] 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. ti_ads7950_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 dereferencing the chip information. 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: ff0843ceb1fb ("iio: adc: ti-ads7950: remove chip_info[]") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 3a34bf7c1fa8bc344a37259cc4d1edf91e160b01 Author: Jiale Yao Date: Fri Sep 25 20:57:46 2026 +0800 iio: adc: ti-ads131m02: reject devices without match data [ Upstream commit 9f0e96713033e5fe5a7a232e2c3aa994a8d2862f ] 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. ads131m_probe() immediately dereferences the returned configuration to initialize the IIO device, 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 configuration. Fixes: 4aa91223fd6c ("iio: adc: Add TI ADS131M0x ADC driver") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit a98835b8d3660a669f97d6ad17e2a2e44d1254be Author: Jiale Yao Date: Fri Sep 25 20:57:45 2026 +0800 iio: adc: ti-ads1018: reject devices without match data [ Upstream commit 156898c0f91aa731821d54fff910242f60b12e17 ] 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. ads1018_spi_probe() immediately dereferences the returned chip information to initialize the IIO device, 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 allocating the IIO device. Fixes: bf0bba486b5b ("iio: adc: Add ti-ads1018 driver") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Reviewed-by: Kurt Borja Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 5db6a2fda705dea0fa4ecac8bacfab5a53057ada 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 f3a10618b0b3795f8a056b7fd2fad35d85e99d5a 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 fac39c779d144cfcf7977b115f6f67492232d877 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 38702d00195c5f2aedc474d06b5c5e4e2052198e Author: Jiale Yao Date: Fri Sep 25 20:57:41 2026 +0800 iio: adc: ad7768-1: reject devices without match data [ Upstream commit e29630bd463eb40e2e86fe45a565fb1d636ac822 ] 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. ad7768_probe() later dereferences the returned chip information to initialize the IIO channels and 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 continuing the probe. Fixes: fa087f5babbc ("iio: adc: ad7768-1: introduce chip info for future multidevice support") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 864f9a04801aa997ca170384f8ef9690128a665a 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 30e229f0e12b91188966b7ffd1a20b9a182fca65 Author: Jiale Yao Date: Fri Sep 25 20:57:39 2026 +0800 iio: adc: ad7192: reject devices without match data [ Upstream commit 7f7a119a370ecf6c8d4ab9e9ee0a8cdd77afedd3 ] 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. ad7192_probe() immediately dereferences the returned chip information to initialize the IIO device, 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: c3708c829a06 ("iio: adc: ad7192: Convert from of specific to fwnode property handling") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b1720412284543b9573b76b9f06d1bbf2e527823 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 83fd3f6d2899dc1c0aa18310001466473de235da 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 d0bca431e4884e3c46f7996f9847d4a2e6ae11bf 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 8b3c634781f95e3d0212dd2ab241c07245b617a9 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 d694eabcc913d37ea370242e1de0ee0b226ba10f Author: Jiale Yao Date: Fri Sep 25 21:17:32 2026 +0800 iio: dac: mcp4821: reject devices without match data [ Upstream commit 6ac1faf4de61dcf27ffe8f2c25d96fe5f4b2886d ] 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 mcp4821_probe() dereferences the result while configuring the IIO device. Reject devices without match data before using the chip information. Fixes: cdf3ecb0d8d0 ("iio: dac: driver for MCP4821") Signed-off-by: Jiale Yao Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit d1b39462450a4fbd976f7d960b342e1b91704cec 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 718f33eb441d36658ddc9346ee3f0704a664e68d Author: Jiale Yao Date: Fri Sep 25 21:17:30 2026 +0800 iio: amplifiers: ad8366: reject devices without match data [ Upstream commit a3f438368c596040efbc44aa8a65e4e5ef2f3847 ] 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 ad8366_probe() later dereferences the result while setting up the IIO device. Reject devices without match data before using the chip information. Fixes: d5e02d0d00b9 ("iio: amplifiers: ad8366: add device tree support") Signed-off-by: Jiale Yao Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit dcffada9bf322c6fd95dd6b6356c280ab26f3b37 Author: Antoniu Miclaus Date: Tue Sep 22 14:09:58 2026 +0300 iio: adc: ad4080: enable address ascension for chip identification [ Upstream commit c051d08d98771132868abf0cb95b6de95ab3060a ] The two byte bulk read at AD4080_REG_PRODUCT_ID_L expects PRODUCT_ID_L followed by PRODUCT_ID_H. After a software reset the AD408x defaults to descending address mode, so the second byte comes from CHIP_TYPE (0x03) instead. CHIP_TYPE reads 0x07 on all AD408x parts, so an AD4080 reports 0x0750 rather than 0x0050 and every part logs "Unrecognized CHIP_ID". Set ADDR_ASC along with SDO_ENABLE before the read. This is the only multi byte transfer in the driver, so no other access is affected. Fixes: b66cddc8be72 ("iio: adc: ad4080: fix chip identification") Signed-off-by: Antoniu Miclaus Reviewed-by: Nuno Sá Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9705fdc22edb1cc5ed25e92b5e69d0639bff94f1 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 80d81ab3f0195763831c6507affac77ea2835f16 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 2d49843e7f37e76bcae297162fa95b01943d2034 Author: Karl Mehltretter Date: Tue Aug 11 21:57:33 2026 +0200 fuse: fix GCC 8 build with CONFIG_PROFILE_ALL_BRANCHES [ Upstream commit 6e887377a63f670d79f3d8a107f29e745e9ddf43 ] Commit 25307ca50b815 ("fuse: simplify logic in fuse_notify_store() and fuse_retrieve()") introduced a loff_t cursor and used it in place of outarg's offset field. In the min() expression this changed the second operand from unsigned to signed. With CONFIG_PROFILE_ALL_BRANCHES, GCC 8 does not propagate the range established by the preceding MAX_LFS_FILESIZE check through the branch profiling code. Consequently, min() cannot prove that the signed operand is nonnegative and rejects the mixed-signedness comparison: min(outarg.size, ((loff_t)((long long)(~0ULL >> 1))) - pos) signedness error This happens with GCC 8.1 on x86-64 and GCC 8.5 on arm and s390. GCC 8.1 remains the minimum supported compiler. Use umin(), which is intended for comparing an unsigned value with a signed value that is known to be nonnegative. The preceding bounds check guarantees that MAX_LFS_FILESIZE - pos is nonnegative, and outarg.size bounds the result to unsigned int. Fixes: 25307ca50b815 ("fuse: simplify logic in fuse_notify_store() and fuse_retrieve()") Cc: stable@vger.kernel.org # v7.1 Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Karl Mehltretter Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 675c26291463079931a076c06be111759574b3e0 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 2c843edd0e071c2fb068c0e7114e8b5c94c5ec4c 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 3300a0eb3a39092696fca74bff412b0eb64d9231 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 d680391e05307171a01874b29737ede4015f986a 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 034f2d8d18a225dbc3f5921b05ce6c904030806c 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 0a75547e19098e276f9fec563ceaee694b9610fe 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 93ed028d8fbd19c9c984dfbc01af2baf783ee4a9 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 4fd207f60873aa9ecaef63ebd4cd56fd981925a3 Author: Tom Verdonck Date: Fri Sep 25 20:23:23 2026 +0200 hwmon: (tmp108) Fix jiffies wraparound in conversion-ready check [ Upstream commit 6b8b1d1d7bc7e579b53fc7c3293b787d68de702a ] tmp108 records a one-shot deadline in ->ready_time at probe (and resume) and, on every temperature read, refuses the read with -EAGAIN while time_before(jiffies, ready_time) is true, in order to skip the initial conversion. ->ready_time 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 ->ready_time is set once and never refreshed, 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() then permanently reports "not ready" and the driver returns -EAGAIN on every read, without ever touching the sensor, until the next reboot. The continuous-mode path, which sets ->ready_time to jiffies with no added conversion delay, wraps the same way. 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: 66e1c9171339 ("hwmon: Add Texas Instruments TMP108 temperature sensor driver.") Cc: stable@vger.kernel.org Signed-off-by: Tom Verdonck Link: https://patch.msgid.link/525fa49d8c50922344fa53e22be5e6133c9bbb62.1790358356.git.tom.verdonck@inspiral.be Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit d6675d774a968fd5a6786c39095637736fa3b1da Author: Tom Verdonck Date: Fri Sep 25 20:23:22 2026 +0200 hwmon: (tmp102) Fix jiffies wraparound in conversion-ready check [ Upstream commit 56c1d32323e773b8b927316f8beeae9238576335 ] tmp102 records a one-shot deadline in ->ready_time at probe (and resume) and, on every temperature read, refuses the read with -EAGAIN while time_before(jiffies, ready_time) is true, in order to skip the first ~35 ms conversion. ->ready_time 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 ->ready_time is set once and never refreshed, 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() then permanently reports "not ready" and the driver returns -EAGAIN on every read, without ever touching the sensor, until the next reboot. 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: 3d8f7a89a197 ("hwmon: (tmp102) Improve handling of initial read delay") Cc: stable@vger.kernel.org Signed-off-by: Tom Verdonck Link: https://patch.msgid.link/2952f070f82913aea96eec25d28008d3b9058656.1790358356.git.tom.verdonck@inspiral.be Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 4ae66b04206f25235fcfe472fa49a6e2c0090ef6 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 8b5d12700e23de8cc7496973c51805b6d6c4764f 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 92047ab3be6878fb1815b6cbc960aecd9226ba1f 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 1a75ff14062d015305de5c2e85ccc01afe0adb49 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 e8bcf91b79298ba1d30da616b70cb1c1fcc7b2e7 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 08a8c59e5c4f665bb7dd9eb7cd9876eb16c821f6 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 da78982c1b06eed3267822ece0c306544418ab00 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 9b0f176126b99d7df1fd86af92e4e4bab61ec2c6 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 2a22243c1247634ad8f0622759a1f0cf52d68285 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 c312ee756e7472bfdc6c17904a62bff01be20410 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 6195e15f44805e79f58b0b5eff65d0e914514263 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 7ac5b43cc863321d787b44d45757ca6036eee88b 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 0ae6ab2bfeba26cbf6dcdb6116e18242d9ef9c65 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 e352c29fbdcdced1f822b7516408ffb6958f18d7 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 b75a082e860d15b2f207f5088fd779d5ec1169ac 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 a85fffa362446416a56cbc1ea53fe7716dd782af 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 ac8661910ebee46daafa4be0b4da057fbe7d026b 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 5b3da0a784f8f515c75a534b5878b563a57a1eb0 Author: Joanne Koong Date: Thu Sep 3 21:56:50 2026 -0700 fuse: don't shorten the folio descriptor at LLONG_MAX [ Upstream commit 4c72635f913850512d5fa74bf3eb7db3670398cf ] fuse_send_readpages() and fuse_do_readfolio() both decrement the folio descriptor length when handling the overflow case where a read would exceed LLONG_MAX after incrementing the file position by the number of bytes that need to be read in. Shortening it is unnecessary (and for the virtio-fs paths, a bug), and with fuse using iomap for handling reads, shortening it is buggy. For fuse_send_readpages(), ap->descs[] is also what fuse_readpages_end() reports back to iomap_finish_folio_read(). iomap accounted the full length when the range was submitted, so the lengths reported on completion have to add up to what was submitted. Reporting one byte less leaves ifs->read_bytes_pending nonzero, folio_end_read() is never called, and the folio stays locked. This is currently reachable on fuseblk mounts configured with block sizes smaller than the page size. Fix this by leaving the descriptor length untouched. The reply will then be one byte shorter than what the descriptor lengths add up to, and the last byte will be zeroed in fuse_copy_folios(). This also fixes a bug in virtio-fs that existed before any iomap changes were added to fuse. For virtio-fs, data there arrives by DMA rather than through fuse_copy_folios(), so the only zeroing is in virtio_fs_request_complete(), which compares the reply size against the descriptor length. With the descriptor length shortened, the two are equal and nothing gets zeroed, which means the unrequested byte is left holding whatever was in the folio, when the folio is marked uptodate. This is both in the fuse_do_readfolio() and fuse_send_readpages() paths. This dates back to commit 2f1398291bf3 ("fuse: don't overflow LLONG_MAX with end offset"). Fixes: 4ea907108a5c ("fuse: use iomap for readahead") Reported-by: Sashiko Cc: stable@vger.kernel.org Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 127a22646c872ca3e1a598e423b8efbcbaaf3f2d Author: Ridham Khurana Date: Thu Sep 24 20:53:23 2026 +0000 hwmon: (lm70) Fix rounding of negative temperatures [ Upstream commit eddb0aaacce4baa9d8176eb2f4bd9e99e867f8fc ] temp1_input_show() drops the low bits of the temperature register by dividing the raw value (raw / 32 on the LM70). These bits are not part of the temperature: the LM70, LM71, LM74 and TMP122/TMP124 always return some of them as 1, and the TMP125 fills them with copies of the temperature LSB. Division rounds toward zero, so a negative temperature with any of these bits set is reported one LSB too high. For example, the TMP122 returns 0xffff for -0.0625 degrees C, which the driver reports as 0. The LM70 returns 0xf39f for -25 degrees C, which the driver reports as -24750. Use an arithmetic right shift instead, which drops the low bits and rounds down. Fixes: e1a8e913f97e ("[PATCH] lm70: New hardware monitoring driver") Fixes: a86e94dc946d ("hwmon: (lm70) Add support for LM71 and LM74") Fixes: cd929672a9ef ("hwmon: (lm70) Add ti,tmp125 support") Cc: stable@vger.kernel.org Signed-off-by: Ridham Khurana Link: https://patch.msgid.link/20260924205326.1739229-1-khurana.ridham222@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit c9e68bc75465803638aa02a5235d3dd113d6d867 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 53b3a80c7169203f9ec38669f8444232bd9dc008 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 99193298f592c545a93d4365042aa28d9626e052 Author: Wei-Lin Chang Date: Thu Sep 24 10:49:51 2026 +0100 KVM: arm64: ptdump: Fix shadow ptdump sleep-in-atomic-context problem [ Upstream commit b1cc219eb21ab5f31fe4caa32be8057159e42db5 ] Previously we exposed shadow page tables by creating a debugfs ptdump file whenever a nested mmu instance gets bound to a new context, and deleting the debugfs file whose context was getting unbound. This turned out to be buggy, as the instance<->context binding process is done with the mmu_lock held, and debugfs creation/deletion can sleep. Change the approach and create a shadow ptdump file for each nested mmu instead during kvm_vcpu_init_nested(), in a sleepable context. The files will be named nested_mmu, and reading it will return the nested context's VTTBR, VTCR, and s2 enabled or not before dumping the shadow page tables, given the nested mmu is valid. Fixes: 19e15dc73f0f ("KVM: arm64: nv: Expose shadow page tables in debugfs") Reported-by: Itaru Kitayama Closes: https://lore.kernel.org/kvmarm/aiuF0KSvvv-ZozI1@sm-arm-grace07/ Tested-by: Itaru Kitayama Signed-off-by: Wei-Lin Chang Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260924094951.727352-3-weilin.chang@arm.com Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 942fdac99284d08d6079a0979d00a76402cff08e Author: Wei-Lin Chang Date: Thu Sep 24 10:49:50 2026 +0100 KVM: arm64: ptdump: Check the page tables aren't freed when accessing [ Upstream commit 7d7199bdf77a3a6ed74d0037133f435a7febe97c ] An open debugfs file keeps the KVM structure alive, but does not prevent mmu notifier release from freeing the stage-2 page tables when the VMM’s address space is torn down. Therefore page tables belonging to the mmus could have been freed when a thread opens or reads the ptdump files. Take the mmu_lock and check mmu->pgt is still alive before accessing the page tables. Also for the ipa_range file and stage2_levels file, switch from keeping the pointer to the page tables to keeping the pointer to the mmu. Fixes: 7c4f73548ed1 ("KVM: arm64: Register ptdump with debugfs on guest creation") Reported-by: Sashiko AI Closes: https://lore.kernel.org/kvmarm/20260623144054.B91D21F000E9@smtp.kernel.org/ Reviewed-by: Vincent Donnefort Tested-by: Vincent Donnefort Tested-by: Itaru Kitayama Signed-off-by: Wei-Lin Chang Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260924094951.727352-2-weilin.chang@arm.com Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 604f050c77c30893af5bf4113aca922d1fa1f891 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 7aa3c1063c917b70214ea8d0e5aafb115fe2d4a1 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 8642f08c3286c7962be101ed5e6bae11ff6e96c0 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 b72dc670cbbced183fabc68ac8d2473ef99c7364 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 d0613a385afd4891383540edecf5a9072820ed78 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 96c3e4bd194ded10c8e314531eb3f844d3690df0 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 5b172740c73fc91209aa610cd21427984257093b Author: Myeonghun Pak Date: Sun Sep 13 16:50:12 2026 -0400 mfd: twl-core: Unregister the auxiliary platform device on unbind [ Upstream commit 3c5c55d979ddcb0765ce531bc7ba173c87c8712a ] twl_probe() registers a standalone platform device named "twl", but keeps its pointer only in a local variable. Probe errors unregister the device, while successful probe leaves no way for twl_remove() to release it. The platform device therefore remains registered after the I2C driver unbinds. Register a managed action on the I2C device immediately after adding the platform device. This unregisters it on probe failure and driver unbind, and also handles failure to register the action itself. Remove the manual error-path unregister to avoid releasing the device twice. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: defa6be1c821 ("mfd: Fix compile for twl-core.c by removing cpu_is_omap usage") 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 Link: https://patch.msgid.link/20260913205013.54777-1-mhun512@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 8c2eaff3553bed57f43783d86ce107c116e67d2c 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 e7976a539c060f2fc8048a28718adceeb5e2cb45 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 86063f89c7db5042f4f67596074ae166f8ba8bf1 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 2f76c8c74f30091f3c142941ce64929c2346a28c 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 0a08168d2ddba29152e7e427185b322a78d9860a 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 02f2d78510dc028c7549d9c937b180574529b18c 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 863b476122a5adfc9f8488dca2fa45cf5be09e4c Author: Francesco Dolcini Date: Mon Sep 14 19:50:26 2026 +0200 arm64: dts: freescale: imx95-toradex-smarc: enable Wi-Fi SD interface [ Upstream commit b91cb164517d6cfbccd8bedad11827d8ea3bcb97 ] Enable usdhc3, used for the on-module u-blox MAYA-W260 Wi-Fi/BT module, it was left disabled by mistake in the initial commit. Fixes: 90bbe88e0ea6 ("arm64: dts: freescale: add Toradex SMARC iMX95") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 998e99e7fe1279f5ee834b106019c9f09dd73cf2 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 ee7178d53d0746477e37251088682578a3faa2ff 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 a2a803455cfd3410f417cc29323443de595542d8 Author: Francesco Dolcini Date: Tue Sep 15 22:18:24 2026 +0200 arm64: dts: freescale: imx95-aquila: fix gpio-line-names padding [ Upstream commit 66a5b2bf9d217668ae683eecfaba38bcd61cfe94 ] som_gpio_expander_1's gpio-line-names use "AQUILA_C1".."AQUILA_C4" instead of the zero-padded "AQUILA_C01".."AQUILA_C04" used by every other Cxx entry in this file and by k3-am69-aquila.dtsi, a different board implementing the same Aquila Family Specification. The zero-padded form is the official pin naming per the Aquila Family Specification and the Aquila iMX95 module datasheet. GPIO line names are meant to be stable across the whole Aquila family, so userspace GPIO tooling that looks up a line by name works the same on any Aquila SoM. Fixes: d5c082ba23db ("arm64: dts: freescale: add Aquila iMX95 support") Cc: stable@vger.kernel.org Link: https://docs.toradex.com/116801-aquila_family_specification.pdf Link: https://docs.toradex.com/117671-aquila_imx95_datasheet.pdf Assisted-by: LLM Signed-off-by: Francesco Dolcini Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 021ef9b57a4cadc313c76f86ab8332d1abb3e8d7 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 018529140ef974745623cba040e68e3d54b1d8fa 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 efd624f5a1e2dbd4f4652c0b29c33bd87fd0ec62 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 e6b68b789b165d1851b330ab11aa33e7031c69f2 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 fc317f0e7d6a148ed4ece0f24d64b0cb9cf2af48 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 38034c83a1b253a74bba92cf3f3b95799902a3e7 Author: Guangshuo Li Date: Tue Sep 22 16:40:09 2026 +0800 media: i2c: ov5647: fix power cleanup on remove [ Upstream commit 6e81cfc38548109021ab761b94ecdd01f8753154 ] ov5647_remove() disables runtime PM without powering off the sensor if it is still runtime active. pm_runtime_disable() does not invoke the runtime suspend callback, so the sensor can remain powered on. If the device is not already runtime suspended, call ov5647_power_off() and mark the runtime PM state as suspended. This issue was found by manual code inspection. Fixes: 089b7c70f0d8 ("media: ov5647: Use pm_runtime infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Dave Stevenson Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit d054be8f786052aa376e48b5c02f28f6a8ee9f0f 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 d277c0545b06124ebefc8396d146ceb5d74dbd43 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 52d2e75c912d823931b5f3b78f946d0b60e8d005 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 463aa906b957b333cbe4e765b72fa933b660e261 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 d46312123b01d894ad1c846cec78439da5abcbe2 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 067dea99ed1d0b76ae05a2e183f7a1a249131dd7 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 a6d5137091c19473261113f053287dad0fa9b5b5 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 b00698d4ad648f78eab1e1912ca58a243575c707 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 660a415b17e2cd8ab51701627daf09ff5f1b03c1 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 f96d56761c93ad00bd6ac41adb8b5387b5363309 Author: Ruoyu Wang Date: Fri Sep 11 09:56:40 2026 +0800 media: adv748x: Fix endpoint reference leaks on probe failure [ Upstream commit 359db09cf055497075a668b192f4578a0ed00955 ] adv748x_parse_dt() takes an extra reference for every endpoint saved in state->endpoints. If parsing later fails, adv748x_probe() skips adv748x_dt_cleanup(), so the saved references remain held. A CSI-2 lane parsing error also returns from for_each_endpoint_of_node() without dropping the iterator's reference. Save the endpoint reference only after lane parsing succeeds. Drop the iterator reference before returning a lane parsing error and route all parse failures through the endpoint cleanup path to release any saved references. This retains the endpoints only for a successful probe. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 6a18865da8e3 ("media: i2c: adv748x: store number of CSI-2 lanes described in device tree") Fixes: eccf442ce156 ("media: i2c: adv748x: Support probing a single output") Cc: stable@vger.kernel.org Suggested-by: Hans Verkuil Signed-off-by: Ruoyu Wang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e6f3ebe63ce84cb5a7bccc00f5e70b2f29133fc2 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 3a56392d3d930061d8c2149ad35114ca92079b2e 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 ee68976efd5b9d242e7d41608fb65aa539138a1d 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 431c925a7c7e389fd0416fc63e83e14eb7c4372d 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 b0bfde2bdc71ac27f8027a27bbb992a37453506f 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 f54f23bff0b1c4015a669fc59c74a64742227885 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 e766903726a12d8426728fb56d01566cf59580be 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 66a509b34f4faf45e75c6ead8eedea0ce1890116 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 2638b5133af49e5c82f890c9f3701386262d7227 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 ed89d13541c89246fd410b2d95861096ad3d43c1 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 5a68359865e7f79f04e44185fded3dd48df52b19 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 ae118e79c6a2b0a29ed6e26516aa2050b61c1492 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 1aa28cba80ce3008c1466eedc9a4ac9fa623236a 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 f0292aae74b2c0af105e7e4fd9f9512436d17906 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 f1d57fa2f7557bda83d23cb3fe7c3d70f1a19907 Author: Francesco Dolcini Date: Mon Sep 14 19:46:50 2026 +0200 arm64: dts: ti: k3-am62p5-verdin: build zinnia dtbs [ Upstream commit 237fda81c2b4984c2212f0d3f510405aad8b25db ] Add the zinnia dtbs to the Makefile, they were forgotten when zinnia support was added and were therefore never built. Fixes: 71c2a8124527 ("arm64: dts: ti: k3-am62p-verdin: Add Zinnia") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini Link: https://patch.msgid.link/20260914174651.6195-1-francesco@dolcini.it Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 06ea36bcbff2ce545b59755275cb106c945fe326 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 b9562a46769cf921e5309c7756c44b9bb08b801f Author: Judith Mendez Date: Wed Sep 9 16:47:42 2026 -0500 arm64: dts: ti: k3-am625-var-som: Set MMC clock pins as OUTPUT [ Upstream commit b489fa1808ea807c4467def7947c83d896dfc355 ] 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: 887d9e03c487 ("arm64: dts: ti: Add support for Variscite VAR-SOM-AM62") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Stefano Radaelli Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260909214743.899477-15-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 109c4367e24ca346638f0c9a4a7ad20922c5331f Author: Judith Mendez Date: Wed Sep 9 16:47:41 2026 -0500 arm64: dts: ti: k3-am625-var-som-symphony: Set SD clock pins as OUTPUT [ Upstream commit dbe55d5f2930b27e9a3ce71f0c9b1bb0ad91a012 ] 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: acb4cd35dbd2 ("arm64: dts: ti: var-som-am62: Add support for Variscite Symphony Board") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Stefano Radaelli Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260909214743.899477-14-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 94a4963c18bdda02ea4f49f6680fac2ea214e6b6 Author: Judith Mendez Date: Wed Sep 9 16:47:40 2026 -0500 arm64: dts: ti: k3-am625-tqma62xx: Set MMC clock pins as OUTPUT [ Upstream commit f9a93fe78d8737860a8fb786d17c9dff20782b7d ] 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: 5b36d8c72c91 ("arm64: dts: ti: Add TQ-Systems TQMa62xx SoM and MBa62xx carrier board Device Trees") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260909214743.899477-13-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit e29d4dfb6cca9d027f5607df9a847a0518b7deb2 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 804fa0c3ade52682f225742a93853a5f5ab6c7fb 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 0405573349c8b41ce69664d36bc5e25917e88bab 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 fdb974fb485d568cbcaa8c1ee61beb408d35305c 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 389fc38db3e9bb709b25344d0fa0029af9aafa69 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 707a64f15ea585f58f83e52de4c3e56c35ff1403 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 4a3dad68fa35ff66340f01ed80527824ef8d70da 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 784d076fb722886c2d64a5c7ae8df52ac94490af 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 0dbb4a8fe98c9f85b83dff070f3ccdbc1ff0a139 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 451df5ff928757531840ae2f1917a2b29903b315 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 448975bdced1ae777f06cc4363674a070d86805f 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 474270892ac83e5595a7709a754d469a25c07921 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 926abc5ff3306cb1e98d41163a1eb24f68cb5b30 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 0dff83de4fd689ed6040e249d7e0c34c3312b01d 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 555f1af1e2a95bbc9cfa7877a5de836f289fb320 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 ae1b1eb10dcf4be87f859a38d1ec06d691308232 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 8539a01b302144d295deead762177c0cdb461d63 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 71a0eaa2ac84e20a9bf0fd40edd1eddd36181e6a 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 bd3a2fe8da2365b1464e7a36fcf482d01407ce5b 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 d68766d1592ec2eaf99f16879137bca1919c2bc5 Author: Adrian Hunter Date: Sun Sep 20 18:12:33 2026 +0300 i3c: mipi-i3c-hci-pci: Set drvdata before creating LTR sysfs attribute [ Upstream commit 2bc2b1b89f65b5b75ffae0cf3d67d2415611004c ] intel_i3c_init() creates the pm_qos_latency_tolerance_us sysfs attribute before probe calls pci_set_drvdata(). A userspace write to the attribute can therefore invoke intel_ltr_set(), which uses pci_get_drvdata(), before drvdata has been initialized. Move pci_set_drvdata() before hci->info->init() so drvdata is available before the sysfs attribute becomes accessible. Fixes: 884a33131f2a ("i3c: mipi-i3c-hci-pci: Add LTR support for Intel controllers") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260920151248.46936-4-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit d8fedfe669a5877caf87b087fbc3ba263f081431 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 3ce1ae37eeb6a2f9206d2a0d1b6c29cdfd8a4e14 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 ee58af5c816bb1f9ff0d0735e40d631aaaaf81ff 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 ce74798da24b35c68b5c2affc78ab3ccec5e0464 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 d86aa60c14282a43467e7e24cb68d17d3a5be0e1 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 9d73c672e278724045c71473a3738ec00f2c494a 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 5a2aa105da1a108fd3b531ac623d341989ff5691 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 d724b9a358cdd8d7a74f9b2dcd9a085b47494ae8 Author: Ariana Lazar Date: Fri Sep 18 12:06:31 2026 +0300 iio: dac: mcp47feb02: Increase EEPROM Programming Write Cycle Time [ Upstream commit 77f5e4bd63db9be9978a6d2ac821a249a3d5fd82 ] Increase the EEPROM write polling timeout to prevent -ETIMEDOUT errors and incomplete nonvolatile write cycle, according to the time specified in the datasheets (11-16 ms). Fixes: bf394cc80369 ("iio: dac: adding support for Microchip MCP47FEB02") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260819125300.6B9211F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Ariana Lazar Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 248ce16dc1d0c1b6b70bea227783fa887b993241 Author: Ariana Lazar Date: Fri Sep 18 12:06:30 2026 +0300 iio: dac: mcp47feb02: Return len when disabling EEPROM store [ Upstream commit 6d96f5a03ebdcc664f5d2fe0a170ca0ea513e3a5 ] When state is false, return the number of bytes (len) the buffer has instead of 0 to properly signal that the input buffer was fully consumed, preventing unnecessary write retries. Fixes: bf394cc80369 ("iio: dac: adding support for Microchip MCP47FEB02") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260804134616.1D8A21F00A3E@smtp.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Ariana Lazar Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 5bba34c8b853909a090266595685e77e662cf838 Author: Ariana Lazar Date: Fri Sep 18 12:06:28 2026 +0300 iio: dac: mcp47feb02: Fix gain field initialization for active channels [ Upstream commit 29491c675c2babb9a4a8cf9b33b38347e4565dee ] As per MCP47FXBX48 Datasheet, in the format of the Gain Control and System Status Register each DAC channel has one bit to control its gain, starting at bit 8, while bits 0-7 contain status or unimplemented bits. The previous formula didn't initialize correctly all channels, being replaced by using field_get() with the already defined macro used in write operations where needed in the rest of the driver implementation. DAC_GAIN_MASK(i) extracts the gain control bit for each active channel correctly in one step. Fixes: bf394cc80369 ("iio: dac: adding support for Microchip MCP47FEB02") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260804134616.1D8A21F00A3E@smtp.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Ariana Lazar Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit d8bc148275a8578daf70462650bac6ad31035da6 Author: Ariana Lazar Date: Fri Sep 18 12:06:27 2026 +0300 iio: dac: mcp47feb02: initialize dac_data field in channel data struct at probe [ Upstream commit fc8d14d75345cb6f43d836be6b32cbc714c19b6b ] Prevent operations which use cache from overwriting default hardware values with zeros by reading active DAC registers during probe to correctly initialize the channel struct DAC values. Fixes: bf394cc80369 ("iio: dac: adding support for Microchip MCP47FEB02") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260804134616.1D8A21F00A3E@smtp.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Ariana Lazar Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 4cffc04b7afadc3f2cebdd0e98db3d63435aa12a 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 00828bbe72a85dd11c0d52957f0133afc5953826 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 0cd432165ad7b679bcb69fedb89255a2f6050c1d 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 9f76d748fcda1a07dc9db750d019f1f2082e7a6f Author: Christian Loehle Date: Wed Sep 16 17:28:05 2026 +0100 cpufreq: CPPC: Create the FIE worker before enabling PCC callbacks [ Upstream commit 995e7d4680706e47154adb68f0b682485ea8d873 ] cppc_freq_invariance_init() creates the PCC worker only if an online CPU currently has PCC counters. A shared policy can also initialize an offline PCC member. When that CPU comes online, its callback queues work through the missing kworker_fie and dereferences NULL. A later hot-added PCC policy can encounter the same missing worker. Create the worker when policy initialization encounters PCC counters, before initializing their work and publishing any callbacks. Serialize creation and reuse the worker until driver teardown. This covers offline policy members and later PCC policies without creating an unused deadline worker on direct-counter-only systems. If worker allocation or scheduling setup fails, leave FIE unregistered for that policy. Keep the global FIE setting unchanged so direct-counter policies remain independent of worker setup and existing policies still drain their initialized work during teardown. Publish kworker_fie only after successful setup, allowing a later policy initialization to retry. Fixes: 997c021abc6e ("cpufreq: CPPC: Update FIE arch_freq_scale in ticks for non-PCC regs") Cc: All applicable Signed-off-by: Christian Loehle Tested-by: Sumit Gupta Link: https://patch.msgid.link/20260916162805.1039247-21-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 011569ece30d46ab0715c0ae41b93eb224e141fe Author: Christian Loehle Date: Wed Sep 16 17:28:02 2026 +0100 ACPI: CPPC: Propagate errors from cross-CPU FFH calls [ Upstream commit 36e96b469da24868f727b4cd168d7cf01cbd163d ] The arm64 and RISC-V CPPC FFH accessors ignore the return value of smp_call_function_single(). If the target CPU is offline, the call can return -ENXIO without running the callback. The accessors then consume callback output which was never initialized and may report success. CPU offlining leaves the CPU's CPPC sysfs attributes present. On arm64, the AMU feature mask does not exclude an offline CPU, so a paired counter read can expose uninitialized stack values through feedback_ctrs. RISC-V has the same problem in both SBI and CSR reads, and its write paths also inspect an uninitialized callback status after a failed cross-CPU call. Return the SMP call error before using callback output. The arm64 single and paired counter readers already check the helper's return value. For RISC-V, also check the callback status before copying a read value: an unsupported CSR sets the error but does not initialize the value. Fixes: 68c5debcc06d ("arm64: implement CPPC FFH support using AMUs") Fixes: 30f3ffbee86b ("ACPI: RISC-V: Add CPPC driver") Cc: All applicable Signed-off-by: Christian Loehle Tested-by: Sumit Gupta Link: https://patch.msgid.link/20260916162805.1039247-18-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 0e791eeb12dfc8b9802c40c3191bc7fc42eb5233 Author: Guangshuo Li Date: Sat Sep 12 22:46:08 2026 +0800 crypto: omap-sham - fix crypto engine cleanup [ Upstream commit be51ea091c6563158531e8c74e040552fdb1e28c ] omap_sham_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: 133c3d434d91 ("crypto: omap-sham - convert to use crypto engine") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 05f3200e0b4bd4282124719b41eda014f769aca4 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 9ff83aa428050bfa4a6965ae78f1231b49217578 Author: Thorsten Blum Date: Tue Sep 8 21:16:06 2026 +0200 crypto: xilinx - clear AES key buffer before freeing it [ Upstream commit 1e4d31c4eb86982319245d8973473a621a256842 ] In xilinx_aes_aead_exit(), the AES key buffer is freed without being cleared, which allows key material to remain in memory. Use kfree_sensitive() to clear the buffer before freeing it. Fixes: c315cb0005be ("crypto: xilinx - Change coherent DMA to streaming DMA API") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Reviewed-by: Thomas Huth Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1f0575f4fc4f3b0c5da42bcbc87ca70ed545ef13 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 6ef8cc5c344173ba910b4e6a778a8947fcef698c 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 446caa07b43b440138efa91a46938245e150af26 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 e01ebf57f3f201d23e4f93ea2092605f5e0d7c2f 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 09a47eb430d1eb5fe99d846ff830d4fa0b18bd2e 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 9c57e2e7976a13c6158ba1f303bb7286deefc8ca 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 432fd21eec8b3199e3fc06332b8c081b8a8a6ba9 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 3817e6da1b05675d6ddefa7660671d804d683782 Author: Sakari Ailus Date: Mon Jun 22 14:23:40 2026 +0300 media: imx219: The horizontal blanking step is 8 [ Upstream commit 47576c541e9b473841742bd0686d4940f5c93564 ] The step for the LINE_LENGTH_A register on imx219 is 8. Take this into account in creating and modifying the horizontal blanking control. The minimum line length in pixels as well as the horizontal blanking values are already divisible by 8. Fixes: cd5e2fd89923 ("media: i2c: imx219: make HBLANK r/w to allow longer exposures") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Dave Stevenson Reviewed-by: Laurent Pinchart Signed-off-by: Sasha Levin commit d9aed4d3e1fa76f18fd3325b0db4d75be9e90f5b Author: Sakari Ailus Date: Mon Jun 22 14:16:45 2026 +0300 media: imx219: Account for rate_factor in control steps [ Upstream commit 57043aef0a04bd96d97881422590e71c1e4c45b1 ] The controls that are divided by the rate_factor before writing them to the registers have the step of the value of the rate_factor. Take this into account when the control's range is modified. The controls are created in a configuration where rate_factor is always 1, hence there's no need to change the code adding new controls. Fixes: f513997119f4 ("media: i2c: imx219: Scale the pixel rate for analog binning") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Dave Stevenson Reviewed-by: Laurent Pinchart Signed-off-by: Sasha Levin commit 17ac52e0c02dde7f1500534ee75a15f6d9d12a73 Author: Sakari Ailus Date: Mon Apr 20 20:31:49 2026 +0300 media: imx219: Account rate_factor in setting upper exposure limit [ Upstream commit db111b66f2db7f3f79d9359f4a9762e832d6fde9 ] The rate_factor multiplier is used to multiply a few values in the sensor's timing configuration and the exposure time is one of them. This also needs to be taken into account in exposure time margin: multiply it by rate_factor so that sensor's exposure time margin is respected. Fixes: f513997119f4 ("media: i2c: imx219: Scale the pixel rate for analog binning") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Dave Stevenson Reviewed-by: Laurent Pinchart Signed-off-by: Sasha Levin commit fe3dcbd26122a5c41a47434311cc2966fa981842 Author: Junjie Cao Date: Sun Sep 13 21:30:17 2026 +0800 media: i2c: cvs: Get the wake IRQ without claiming the GPIO [ Upstream commit ed447e2b1da9bfe7d076e12cde496f3f689f7fdd ] The wake line is only used as an IRQ source, yet the driver requests it with devm_gpiod_get(). On the Dell XPS 14 DA14260 (Panther Lake) that request lands on the pin the four CS35L57 amplifiers read their speaker ID from. Each amplifier's _CRS carries GpioIo (Shared, PullNone, 0, 0, IoRestrictionInputOnly, "\_SB.GPI1", 0, ResourceConsumer,,) {20} and INTC10E1 builds its _CRS at runtime from pad numbers kept in NVS: a GpioInt (Edge, ActiveLow, Shared) first, then an Exclusive output-only GpioIo for reset and two lines on the USB GPIO expander. The driver maps index 0 to "wake". While it holds the line, cs35l56 fails and does not retry: cs35l56 sdw:0:2:01fa:3557:01:2: error -EBUSY: Failed to get spk-id-gpios All four fail and no card is registered. Fedora 7.1.13 is the first Fedora kernel with the driver enabled; 7.1.12 on the same board creates the card, and 7.2.4 creates it again with intel_cvs blacklisted. Where ipu-bridge does not expose the CSI endpoints, CSI init returns -EPROBE_DEFER and every retry claims the line again for the length of the handshake, which is how 7.1 fails as well. Take the IRQ from the GpioInt entry with acpi_dev_gpio_irq_get_by(), as the I2C core does for client->irq; this also applies the trigger type from _CRS. The vendor driver in intel/vision-drivers does the same. The driver binds as a platform device too, hence the explicit lookup. A DKMS build of the patched driver on a DA14260 running 7.2.4 binds with all four amplifiers probing and the camera working (third link). Fixes: 8e2b43d2c10b ("media: i2c: cvs: Add driver of Intel Computer Vision Sensing Controller(CVS)") Cc: stable@vger.kernel.org Reported-by: jan p. springer Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2529031 Link: https://github.com/thesofproject/sof/issues/11152 Link: https://github.com/omacom/omarchy-pkgs/pull/419 Signed-off-by: Junjie Cao Tested-by: Manuel Knitza Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 8b9494dc0f4aaaacf6cd06c486ed3c61b8da3836 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 d167818266d27a847bb7503a3332d8873a9e3cb7 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 708060d87b092e107504df4390aa83c4687c445f 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 8b8435630e45636664fb9bb0da7f0822be955464 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 a0401d7e0aa3f36501a868ec8b1e6bcfaa7dcd35 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 0c985959028176677494849fd464521f2bf35357 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 6ee8dc4fcc38138b3e5bf4bfe6ac5b28062d9522 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 23043237c339fff701ef1518e986bae88d3e4908 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 d492d0b5ae0f6748e4d57185f152ffe0611eb29d 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 a564237d4e8d6d4ecf60d7a2998fd83f2996850e 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 45b3faff00615773a8adfdc74be7c49cfb19aa67 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 90140d30ee7bbd5e7c2e9e0d685c72991598c58b 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 5047bb843a03ea4cf4eb85fc7278fcfb7426a7c4 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 5b57b7aaddd9cfb81ae011c69757457d1b9d11ed 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 9868246e63233914504accd565ff7f5141cadf04 Author: Yousef Alhouseen Date: Tue Jun 30 23:17:43 2026 +0200 ntfs3: reject empty iomap before reading its LCN [ Upstream commit 666af227b12fcc3f4ac9827d449ee0910f7bcf9f ] attr_data_get_block() can return success with a zero run length when no cached or on-disk mapping covers a read VCN. In that case it does not initialize the LCN output. Check the returned length before comparing the LCN against the special mapping values. This preserves the existing -EINVAL result for an empty mapping without passing an uninitialized LCN to the comparisons. Fixes: ecbb433f9a8e ("fs/ntfs3: fold file size handling into ntfs_set_size()") Reported-by: syzbot+4b4ec878e25fafefa70f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4b4ec878e25fafefa70f Cc: stable@vger.kernel.org Signed-off-by: Yousef Alhouseen Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 43562e40e0b2c70bffbd7cada5a176891a49da9d 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 5306d8b45013c0fa7b58a0b275e7162f5a7d35b8 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 2d771a3f71783d3e77841b22cf1358f43de35aad Author: Guangshuo Li Date: Tue Sep 15 16:35:34 2026 +0800 media: i2c: og01a1b: power off sensor on remove [ Upstream commit a26c5ac46191ae34b3413f7a45d6241f63e15d42 ] og01a1b_probe() powers the sensor on explicitly before identifying and initializing it. After a successful probe, runtime PM is enabled and pm_runtime_idle() is used to allow the runtime suspend callback to power the sensor off. The probe error path explicitly calls og01a1b_power_off(), but the normal remove path only disables runtime PM. pm_runtime_disable() does not guarantee that an active device is runtime suspended, so the sensor can remain powered when the driver is removed. This also leaves the xvclk enable performed by og01a1b_power_on() unbalanced. After disabling runtime PM, check whether the device is already suspended. If it is still active, power the sensor off explicitly and update the runtime PM state accordingly. Avoid powering it off again when runtime suspend has already done so. This issue was found by manual code inspection. Fixes: a95ffde28783 ("media: i2c: og01a1b: Add support of xvclk supply clock in power management") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit fbc832800bc8c62adf5ed40760e1af4387310432 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 1a27d5b8124ad852857d4080fa9271084f1d503e 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 2a17652b34500fd1de65cfb1b0c7adaa3abafad1 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 c051f39412cbf1b55aef7b16f47b8a6b0caca56d 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 f7ca8124dc2ab52fc56420943f4b7685eba37d71 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 6291e4900ae073839980c29c4a6508d44d20fd57 Author: Cosmin Tanislav Date: Sun Sep 13 22:56:52 2026 +0300 pinctrl: renesas: rzt2h: Fix reading pin value in IRQ function [ Upstream commit 55297a587c3748f320485a3b37fcccfe6f0440bb ] rzt2h_gpio_get() only reports a level for pins in input or output mode and returns -EINVAL otherwise. When a pin is requested as an interrupt it is switched to IRQ function and its I/O mode is set to Hi-Z, so its value can no longer be read. gpiolib calls gpiod_get_value_cansleep() to determine the edge's direction when a line is watched with GPIO_V2_LINE_FLAG_EDGE_BOTH. Non-zero values are translated to a rising edge, zero to a falling edge. Since gpiod_get_value_cansleep() ends up calling rzt2h_gpio_get() which returns -EINVAL when the pin is in IRQ function, every edge is reported as rising. When using the IRQ function, the input buffers are enabled and the PINm registers reflect the live state of the input. Report the input level even when the pin is used as an IRQ. Cc: stable@kernel.org Fixes: 829dde3369a9 ("pinctrl: renesas: rzt2h: Add GPIO IRQ chip to handle interrupts") Signed-off-by: Cosmin Tanislav Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260913195654.3371385-4-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 7942009b3bcd16d4caca2b827740456efb1bee3e Author: Cosmin Tanislav Date: Sun Sep 13 22:56:51 2026 +0300 pinctrl: renesas: rzt2h: Setup IRQ in .irq_{request,release}_resources() [ Upstream commit d9980f93cef0f90a11f26296c68ed16b61a95ced ] When exporting a GPIO using the deprecated sysfs GPIO API, gpio_is_visible() calls gpiod_to_irq() to determine whether a GPIO is IRQ-capable, which ends up using struct gpio_irq_chip::child_to_parent_hwirq(). When using the GPIO character device, it is possible to request a line and to dynamically switch between using it as an IRQ or as a GPIO, by updating the edge detector. The current struct gpio_irq_chip::child_to_parent_hwirq() implementation makes the assumption that it will only be called with the intention of setting up the IRQ permanently, and that it will only be released when the IRQ domain is freed. Since we now know that this is not the case, take the following steps in order to properly handle that case. Implement struct irq_chip::irq_{request,release}_resources() based on the default GPIOCHIP_IRQ_RESOURCE_HELPERS implementations. Move the IRQ setup and release logic inside them. Keep the mapping logic inside ::child_to_parent_hwirq() to be able to provide a proper HW IRQ number, but do not actually setup the IRQ. Remove rzt2h_gpio_irq_domain_free() as its only purpose was to free the acquired IRQs. irq_domain_free_irqs_common() will still be set up as struct gpio_irq_chip::child_irq_domain_ops::free by gpiochip_hierarchy_setup_domain_ops(). Cc: stable@kernel.org Fixes: 829dde3369a9 ("pinctrl: renesas: rzt2h: Add GPIO IRQ chip to handle interrupts") Signed-off-by: Cosmin Tanislav Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260913195654.3371385-3-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 74d45cfc027b1fc2eff2931669be0e573a1bf58e Author: Cosmin Tanislav Date: Sun Sep 13 22:56:50 2026 +0300 pinctrl: renesas: rzt2h: Restore correct pin mode on IRQ free [ Upstream commit 7df755632142e59a5aec5f85f2654add49220102 ] rzt2h_gpio_irq_domain_free() calls rzt2h_pinctrl_set_gpio_en() with false leaving the pin in interrupt function instead of returning it to GPIO mode. Pass true to rzt2h_pinctrl_set_gpio_en() to take the pin out of interrupt function after we're done using it as an IRQ. rzt2h_pinctrl_set_pfc_mode() switches the pin to Hi-Z, losing the previous PM value. Save the PM value before switching to Hi-Z, and restore it after the IRQ is freed. Cc: stable@kernel.org Fixes: 829dde3369a9 ("pinctrl: renesas: rzt2h: Add GPIO IRQ chip to handle interrupts") Signed-off-by: Cosmin Tanislav Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260913195654.3371385-2-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 8f736095da82fa1d41451e0866514a0b3e38354d Author: Ethan Nelson-Moore Date: Mon Sep 14 18:47:09 2026 -0700 ata: sata_inic162x: remove dangerous broken driver [ Upstream commit 96fdeb7e3fd8d937f8351ed90824c9d904e590a1 ] The sata_inic162x driver was labeled as "very experimental" in commit bb9696192826 ("libata: make it clear that sata_inic162x is experimental") due to data corruption issues, but not marked as broken. Since then, no changes have been made to it that could fix these issues. Since the driver was not marked as broken, and the message about potential data corruption is only visible in the code and dmesg, it is possible that someone could enable the driver without realizing its potential for data corruption. Remove the driver to protect users' data. Fixes: 1fd7a697a37b ("sata_inic162x: finally, driver for initio 162x SATA controllers, take #2") Cc: stable@vger.kernel.org Signed-off-by: Ethan Nelson-Moore Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20260915014714.41274-1-enelsonmoore@gmail.com Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 95eb501ca34540176b8cc9d1ddf7cea1d62b172e Author: Guangshuo Li Date: Sat Sep 12 19:33:55 2026 +0800 ACPI: SBS: Fix NULL pointer dereference on allocation failure [ Upstream commit 2b30842e52d9a364428b598f5edd4b12fa772f5a ] acpi_sbs_probe() jumps to the common error path when kzalloc_obj() fails, but platform_set_drvdata() is only called after the allocation succeeds. The error path calls acpi_sbs_remove(), which retrieves the unset driver data and dereferences the resulting NULL pointer when locking sbs->lock, causing a NULL pointer dereference. Return -ENOMEM directly when the allocation fails, since no resources have been initialized at that point and there is nothing to clean up. This issue was found by manual code inspection. Fixes: 9460eaae2ee42 ("ACPI: SBS: Convert the driver to a platform one") Cc: All applicable Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260912113355.644238-1-lgs201920130244@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 3e82f85a40e71c0023408994f600fe862b83688d 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 1af1d75f3cf0aa8c7d4a3536e6053f1c4f49c31b 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 2702225f565ac1272e529545b12a15cd75ed2531 Author: Daeho Jeong Date: Thu Sep 3 09:10:31 2026 -0700 f2fs: drop pending discard commands before reserving device alias [ Upstream commit 5d37f99e4d25eaf42efe2dda8b947585478168f6 ] When reserving a device alias via f2fs_ioc_reserve_dev_alias(), f2fs_reserve_device_alias() bulk-marks all blocks in the target device range as valid in SIT. However, if the device was previously in the released state, stale pending discard commands covering that range may still exist in dcc->root. When f2fs_issue_discard_thread later processes those commands, __check_sit_bitmap() detects valid blocks in the discard range and triggers a kernel BUG(). To fix this: 1. Introduce f2fs_drop_discard_cmd_range() to traverse the discard rbtree, drop all pending D_PREP discard commands in the range, and wait for any in-flight discard bios under dcc->cmd_lock. 2. Call f2fs_drop_discard_cmd_range() in f2fs_ioc_reserve_dev_alias() before f2fs_reserve_device_alias(). Reported-by: Wenjie Qi Fixes: eae3faf210bd ("f2fs: support dynamic reserve/release for device aliasing") Cc: stable@vger.kernel.org Signed-off-by: Daeho Jeong Reviewed-by: Chao Yu Reviewed-by: Wenjie Qi Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit c43b7bede95ed36173dd2caf68007369885857a5 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 519fb5f02e84f851743735444babee80e000fccf 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 9a79e3a2753fa5988af94c641d5ab06d21c8f262 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 80137a68e77a5b7cefc184f41ca8e1b2f86945d5 Author: Joshua Crofts Date: Wed Sep 9 13:03:04 2026 +0000 iio: adc: max14001: add missing MODULE_DEVICE_TABLE macro [ Upstream commit ed6179c3c2b2545fa1c7174604ecfed55c9ddd6e ] The MAX14001 has an SPI ID table, but does not export it with the MODULE_DEVICE_TABLE(spi, ...) macro. Because of this, SPI-based module autoloading fails on systems that don't use devicetree (e.g. via spi_board_info). Add the missing macro to export the alias information. Fixes: 59795109fa67 ("iio: adc: max14001: New driver") Cc: stable@vger.kernel.org Signed-off-by: Joshua Crofts Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 49d318ee82d0782fa8b99168985ce891e5557249 Author: Fabio Cesari Date: Thu Sep 10 08:24:35 2026 +0200 iio: light: isl29028: fix runtime PM reference leak on error paths [ Upstream commit 0e30d15b15647df786e60022650613e16dd70645 ] isl29028_read_raw() and isl29028_write_raw() take a runtime PM reference with pm_runtime_resume_and_get() but return directly on their error paths without dropping it. The usage count never balances again and the device stops entering autosuspend for good. In isl29028_read_raw() this needs a regmap access to fail; in isl29028_write_raw() one rejected sysfs write is enough, for example echo 200 > in_proximity_sampling_frequency which is outside the [1:100] range and returns -EINVAL with the reference still held. Take the reference with PM_RUNTIME_ACQUIRE_AUTOSUSPEND() instead, so it is released on every return path. This also stops the return value of pm_runtime_put_autosuspend() from reaching userspace. That value only says whether the device could be suspended right away, so -EAGAIN or -EPERM turns a successful access into a failure, and with CONFIG_PM=n the stub returns -ENOSYS on every access. Fixes: 2db5054ac28d ("staging: iio: isl29028: add runtime power management support") Suggested-by: Joshua Crofts Cc: stable@vger.kernel.org Assisted-by: LLM coccinelle Signed-off-by: Fabio Cesari Reviewed-by: Joshua Crofts Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit df46b452097bfe046e6c522b0b0e035259cbf8dc Author: Koichiro Den Date: Tue Sep 1 15:32:38 2026 +0900 PCI: endpoint: pci-epf-vntb: Manage virtual NTB and PCI bus lifetime [ Upstream commit 5cdbd6d3a3a147fa9975e35f2602cbec9a72a932 ] The virtual PCI driver registers an ntb_dev but has no remove callback. Unbinding the endpoint function can therefore free BARs while the NTB device and its client still use them. It also leaves the virtual PCI devices and root bus allocated. Allocate an ntb_dev for each virtual PCI probe and unregister it from the matching remove callback. Start command processing only after registration. Publish the device for doorbell IRQs at the same point. During remove, stop the command work and drain IRQ handlers before unregistering the device. Retain the root bus returned by pci_scan_bus() so it can be removed on unbind. Unregister the virtual PCI driver before releasing endpoint resources. Stop and remove the root bus under the PCI rescan/remove lock, then release its host bridge. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Cc: stable@vger.kernel.org # 6.0+ Link: https://patch.msgid.link/20260901063238.631166-3-den@valinux.co.jp Signed-off-by: Sasha Levin commit 27c2ecf6c2e3411c6e6fcdaabcbb303e6da0d752 Author: Nicolin Chen Date: Sun Aug 30 15:26:38 2026 -0700 iommu/arm-smmu-v3-iommufd: Reject unsupported bits in invalidation commands [ Upstream commit 26564d25cd814dfd72a21a2c52b81e678cf02bae ] The arm_vsmmu_cache_invalidate() op hands a guest's invalidation commands to the trusted main command queue after enforcing only the VMID or the SID, and passes the rest of the command through to the queue unchanged. That lets a guest set bits the host never meant to forward: a reserved or undefined bit makes a command malformed; per the Arm SMMUv3 specification, in its section 4.1.3 "Command errors", a CERROR_ILL is raised, among other cases, when: A valid command opcode is used and a Reserved or undefined field is optionally detected as non-zero, which results in the command being treated as malformed. Restrict each opcode to the fields that the driver supports and reject the command with -EIO if it sets any other bit, before the command reaches the queue. This stops the host from forwarding any bit whose meaning it does not control. Document this contract in the uAPI header, so user space must take the responsibility to forward valid commands only. Some fields and whole opcodes are legal only on an SMMU that implements the matching feature, so accept them conditionally: - NUM, SCALE, TG and TTL need FEAT_RANGE_INV. - SCALE bit 25, for values above 31, and TTL == 0b01 with a 16KB TG need SMMU_IDR5.DS, gated on ARM_SMMU_FEAT_DS so that a VMM exposing DS from the reported IDR5 register keeps working. - ASID is limited to asid_bits, since its upper 8 bits are RES0 on an SMMU that only supports 8-bit ASIDs. - ATC_INV needs FEAT_ATS. Per the specification's section 4.5 "ATS and PRI", CMD_ATC_INV is ILLEGAL when: SMMU_IDR0.ATS == 0 and this command is issued on a Non-secure or Secure Command queue. - SSV, SSID and Global need a non-zero ssid_bits. Without it, setting them is not illegal but CONSTRAINED UNPREDICTABLE, which a guest should not be able to provoke. Global also takes effect only when SSV == 1, broadening the invalidation from the one SSID to all the PASIDs of the single device that the SID field addresses. Some values inside the accepted fields are Reserved too: - NUM == 0, SCALE == 0 and TTL == 0 together are a Reserved combination and cause a CERROR_ILL. - NUM, SCALE and TTL turn RES0 when TG == 0. - An ATC_INV Size above 52, the invalidate-all span, is permitted to raise a CERROR_ILL. Reject these Reserved values the same way. In contrast, an out-of-range address or ID value is defined as CONSTRAINED UNPREDICTABLE that would be scoped to the guest itself, so it does not deserve a check. Fixes: d68beb276ba2 ("iommu/arm-smmu-v3: Support IOMMU_HWPT_INVALIDATE using a VIOMMU object") Cc: stable@vger.kernel.org Reviewed-by: Jason Gunthorpe Reviewed-by: Pranjal Shrivastava Assisted-by: Claude:claude-fable-5 Signed-off-by: Nicolin Chen Link: https://patch.msgid.link/40f4aabf98e434d6ac9f42a8d278b92200f202ca.1788127877.git.nicolinc@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 0a24ad2b5024d8dc9d6df8b936b006be1a8a809c 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 3f749d1755c1b82f7c102bd9522ea3b5039d3171 Author: Jiaming Zhang Date: Mon Aug 31 18:54:25 2026 +0800 gfs2: reject invalid inode sizes [ Upstream commit 33ed0a0567e0abe66ea65e89dad2e35082890fbe ] A corrupted GFS2 image can store a dinode size that is larger than what VFS i_size can represent. gfs2_dinode_in() reads the on-disk di_size as a u64 and writes it directly into inode->i_size. If the value is larger than S64_MAX, the incore i_size becomes negative. That negative value can bypass the existing stuffed inode size check: inode->i_size > gfs2_max_stuffed_size(ip) Later, gfs2_quotad may try to sync the quota file and unstuff the quota inode. gfs2_unstuffer_folio() reads the negative i_size into an unsigned length and passes it to memcpy(), turning it into a huge copy size and triggering a out-of-bound issue. Reject dinodes whose size exceeds sb->s_maxbytes before storing the value in inode->i_size. Also make the stuffed inode check use the raw on-disk size while it is still unsigned. Fixes: 70376c7ff312 ("gfs2: Always check inode size of inline inodes") Closes: https://lore.kernel.org/lkml/CANypQFaF6bvORKKbRALvEL0k_epFaneFiOQqco4gjdmKVbdURg@mail.gmail.com/ Assisted-by: Codex:gpt-5.5-xhigh Cc: stable@vger.kernel.org Signed-off-by: Jiaming Zhang Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 21b865ea576e9c2a988c31f05c381e5410a4584a 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 4919ab024e02133b12c2d3a35d31cbd9ff4dc5ea 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 b9652248b8d7142293edad46799dc80b56d29c04 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 14e874b971ad8d0932a3328f472b1867b2e9338f 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 150c8b52be2af864c39718c3b8e0cc4812024125 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 f56fab89da7300a3f4556516c4ab1c4b0a2419cb 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 8ae62dd7e3b933862b34216c3f832a0c278f4be3 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 af77a46d2303eeb6536701e76f5996ce53bd7972 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 e9115c139cad53919457a179d81964430dfdae32 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 e17d9c889b6abf0955607df07813ffef5a2d6468 Author: Lad Prabhakar Date: Tue Aug 11 21:00:13 2026 +0100 PCI: rzg3s: Fix IRQ domain initialization error handling [ Upstream commit 5d9e9b3a27994a2fadce283801b7104a68ea4c48 ] rzg3s_pcie_init_irqdomain() installs chained handlers for the INTx parent interrupts before creating the INTx irqdomain and initializing MSI support. If any subsequent step fails, such as obtaining an INTx IRQ, creating the irqdomain, or initializing MSI, the error path returns without removing any chained handlers that were already installed. This leaves stale handler and data pointers attached to the parent interrupts. Add a helper to tear down the INTx IRQ setup, including removing the IRQ domain and clearing the chained handlers. Use it to unwind partially completed initialization and from the normal IRQ domain teardown path. Fixes: 7ef502fb35b28 ("PCI: Add Renesas RZ/G3S host controller driver") Signed-off-by: Lad Prabhakar Signed-off-by: Manivannan Sadhasivam Reviewed-by: Claudiu Beznea Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260811200013.185956-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Sasha Levin commit 975ed11492bfffc48ec0d7c325b24c8bbd0a6371 Author: Lad Prabhakar Date: Tue Aug 11 21:00:12 2026 +0100 PCI: rzg3s: Propagate platform_get_irq_byname() errors [ Upstream commit 49daf16c881bc91a55355a3e7f03471c2b213255 ] platform_get_irq_byname() may return specific error codes such as -EPROBE_DEFER, but rzg3s_pcie_init_irqdomain() replaces all failures with -EINVAL. This breaks probe deferral by preventing the driver core from retrying probe once the interrupt provider becomes available. Propagate the original error code instead. Fixes: 7ef502fb35b28 ("PCI: Add Renesas RZ/G3S host controller driver") Signed-off-by: Lad Prabhakar Signed-off-by: Manivannan Sadhasivam Reviewed-by: Claudiu Beznea Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260811200013.185956-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Sasha Levin commit 9f5b2652f779b4da9c8e7fffbe5e239767161dfe Author: Lad Prabhakar Date: Tue Aug 11 21:00:11 2026 +0100 PCI: rzg3s: Disable refclk on probe failure [ Upstream commit f03f56f21ce0770f38f3251924a0ca98699c38ed ] rzg3s_pcie_host_init_port() enables the PCIe reference clock using clk_prepare_enable(), but if rzg3s_pcie_probe() subsequently fails, for example because pci_host_probe() returns an error, the probe error path only releases the clock handle with clk_put(). Balance clk_prepare_enable() by calling clk_disable_unprepare() in the probe cleanup path before releasing the clock, ensuring the reference clock is properly disabled on probe failure. Fixes: 7ef502fb35b28 ("PCI: Add Renesas RZ/G3S host controller driver") Signed-off-by: Lad Prabhakar Signed-off-by: Manivannan Sadhasivam Reviewed-by: Claudiu Beznea Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260811200013.185956-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Sasha Levin commit c6da20a6466f8a9bd192c843d84e16f75c965354 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 e1de95a73d3d2838733642c3fc399cabfa32eaa9 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 bc717d870fb6b6e15e386ea80ec9356a15d36792 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 a5ed5aa7236f3dbdd65e255953000102805ff53e 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 3c1d17a81462c6a9d9e53522e8beb21ca70eba04 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 6c20971609a7967e519f3422efcf1870e142e5a0 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 e85d38ecc6aa1a4bd0f7ae445ef5ad98b24cd1d9 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 7a2194be2ab6061ea920ce743147a8dfb9df47b3 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 509735e930c8a325bb6d706feef3fdfb6d332375 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 a3919fa30c2ee4215ed426ae19c51dba5bab98a7 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 76701b325e424f29558230a9340b23f0548550d3 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 25329f2b10cf931aec67a8e570624dec14ef8d85 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 e89c7b08cffc1665eb7ce359c00639497c1fda9a 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 1bdc4854b6b01f84f9ae05177c256c4a8c5456bd Author: Pengpeng Hou Date: Fri Aug 14 16:08:02 2026 +0800 media: require two-byte Cypress type 04 records [ Upstream commit e22872703386c3885d8c6bd595124587bc4e5081 ] Both Cypress Intel HEX parsers read two address bytes from type 04 records. Generic record framing permits any record length, so a short record can make the parser consume the checksum or bytes beyond the firmware record. A longer record also violates the Intel HEX type 04 layout. Require the type 04 payload length to be exactly two bytes in both implementations. Fixes: 79a63c60a6a2 ("[media] media: move dvb-usb-v2/cypress_firmware.c to media/common") Fixes: 776338e121b9 ("[PATCH] dvb: Add generalized dvb-usb driver") Cc: stable@kernel.org Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a8e3008909235894435d0e19746d0ffe6e916e05 Author: Tharit Tangkijwanichakul Date: Tue Aug 11 17:04:14 2026 +0000 media: v4l2-ctrls: default HEVC SPS chroma format to 4:2:0 [ Upstream commit 4f4b6a9220f0401ae84bd2644aabd7221930c1c5 ] The default value of a compound control is zero initialized when no explicit default is provided. For V4L2_CTRL_TYPE_HEVC_SPS this results in chroma_format_idc being set to 0, which represents monochrome video. Most stateless HEVC decoders do not support monochrome video. In particular, the VDPU38x variant of rkvdec fails v4l2-compliance in two tests related to V4L2_CID_STATELESS_HEVC_SPS. The Control ioctls test reads the control with GET_EXT_CTRLS and writes the same value back; TRY_EXT_CTRLS then returns -EINVAL because the VDPU38x rkvdec_hevc_validate_sps() rejects sps->chroma_format_idc == 0. v4l2-compliance 1.33.0-5491, 64 bits, 64-bit time_t v4l2-compliance SHA: b32589c51481 2026-07-16 08:51:38 Control ioctls: fail: v4l2-test-controls.cpp(942): try_ext_ctrls returned an error (22) test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL Buffer ioctls: fail: v4l2-test-buffers.cpp(3102): node->streamon(q.g_type()) fail: v4l2-test-buffers.cpp(3157): testBlockingDQBuf(node, m2m_q) test blocking wait: FAIL Set the common HEVC SPS compound control default to chroma_format_idc = 1, corresponding to 4:2:0. Fixes: c9a59dc2acc7 ("media: rkvdec: Add HEVC support for the VDPU381 variant") Cc: stable@kernel.org Signed-off-by: Tharit Tangkijwanichakul Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit c39241f34edf70e5150e69c71597651e168f3946 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 ecb28e53fe8548216072a04107130d0e6450dc3b 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 d8dbd8de9334c079c90cfdc2bac081e3b62c0d8d 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 02d9c31a3f6476333b590c4e30407e75309020f7 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 8e8b1298193e7af06a8743e07068f466e627500f 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 d58472758df8383b8c410518e99dd26308f88128 Author: Cosmin Tanislav Date: Mon Aug 17 21:56:54 2026 +0300 pinctrl: renesas: rzt2h: Fix used_irqs indexing in clear path [ Upstream commit c0de88659b68402ed7e53fb998a058ef430c787b ] struct rzt2h_pinctrl::used_irqs is supposed to be indexed based on the parent IRQ number. Do the translation using rzt2h_gpio_irq_map and clear it properly. Cc: stable@kernel.org Fixes: 829dde3369a9 ("pinctrl: renesas: rzt2h: Add GPIO IRQ chip to handle interrupts") Signed-off-by: Cosmin Tanislav Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260817185700.322370-2-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit a9a1b36f05c1c99b076d0431e2a097ba16ca3763 Author: James Hilliard Date: Fri Sep 4 16:17:58 2026 -0600 mtd: rawnand: sunxi: fix free OOB section offsets [ Upstream commit c56d52865624ca236c44838ef9366a8597b6af6c ] The sunxi hardware ECC OOB layout places protected user data before the ECC bytes for every step. Since variable user-data lengths were introduced, free sections after the first use sunxi_get_ecc_offset(), which skips the protected user data and points at the ECC bytes instead. As a result, the MTD free-OOB interface addresses ECC bytes rather than the protected user data for those sections. Use sunxi_get_oob_offset() to point each free section at the beginning of its protected user data. Keep the special two-byte offset for section zero to reserve the bad block marker. Fixes: 54dcd6aa69db ("mtd: rawnand: sunxi: introduce maximize variable user data length") Cc: stable@vger.kernel.org Signed-off-by: James Hilliard Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 4915c08a122aa3ff3d64ff86b93d20a25cc93b34 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 979d7a2f16eb311f9fe809a024e004232d8ecd8c 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 fa24f2f62d16464354b8d352031b855c77b384d0 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 d04353654fabc56213154b712fb14b9ed7552563 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 bc2589c917ebf9df2406c360653b28c3dca374aa 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 3954e37821eb997694e55d8a6b2ae5211e193445 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 77496797f854d0a74621ed1b8fafc4d63a2b9666 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 040debc495399a102bf5b4c4386c56bcfccddfd8 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 14a0532b2044c290773f6b4228909c90d38e886b 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 2930780b2fa594497a7f5fc4dac387a1f7c37a2d 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 95931666f5430a77cb071cbcf199318cf73924d6 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 b62486881df481704c4a24106b6c5206d8ead7a5 Author: Stanislaw Gruszka Date: Tue Sep 8 14:46:51 2026 +0200 wifi: mac80211: queue frames while off-channel [ Upstream commit 13e51269b6656768dc595ed6025e4974f2026543 ] Drivers without FAST_XMIT and hardware scan support currently drop TX frames during software scanning while being off-channel. This happens in ieee80211_tx_h_check_assoc() before frames reach internal TX queue. Move the off-channel check to invoke_tx_handlers_late(), after ieee80211_queue_skb(). Frames can then remain queued and be transmitted when the interface returns on-channel. This how TX works currently when code goes via ieee80211_xmit_fast() path. Below is rt2x00 driver ping output example while scanning, before and after the fix. After the fix, packets are no longer lost. Some have increased latency, what is expected behavior. BEFORE: 64 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=3.61 ms 64 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=3.33 ms # Missed 30 64 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=4.03 ms 64 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=3.10 ms # Missed 33 64 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=3.04 ms # Missed 35 64 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=3.05 ms # Missed 37 64 bytes from 192.168.0.1: icmp_seq=40 ttl=64 time=4.14 ms # Missed 39 64 bytes from 192.168.0.1: icmp_seq=41 ttl=64 time=4.50 ms AFTER: 64 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=3.40 ms 64 bytes from 192.168.0.1: icmp_seq=30 ttl=64 time=6.10 ms 64 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=4.69 ms 64 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=4.49 ms 64 bytes from 192.168.0.1: icmp_seq=33 ttl=64 time=148 ms 64 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=6.83 ms 64 bytes from 192.168.0.1: icmp_seq=35 ttl=64 time=8.66 ms 64 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=13.0 ms 64 bytes from 192.168.0.1: icmp_seq=37 ttl=64 time=4.78 ms 64 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=3.85 ms Cc: Signed-off-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260908124651.2995-1-stf_xl@wp.pl Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit bc06ead5badf52279c12f3f6afdaebae243ca552 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 8c7a8fc987cd8a59d73e96e30d6ef6bafa080733 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 e2e7fe5b1102b84c0335d2d197927a7a47830785 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 a3db968f1741d21202a25c57a24cfc913316b0ee 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 7368f8cc360057f1ca10119eaa7c5ffac79045e3 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 f438de68eb13e77b616f8e6373695d17598fbc7c 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 f4bb5d4f446b6ae00a954003a0d9b7797a1b4197 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 805d4167f7cc419fac6687da3f0fcab96d1955d0 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 fcabdb0364c25da8ffe090ea9b5ef242b80192ce Author: Faizel K B Date: Mon Jul 27 17:15:45 2026 -0700 media: vimc: sensor: fix pixel_rate type to resolve do_div() warning [ Upstream commit bbc952491f5f05f2274c811d34174d5b88632103 ] vsensor->pixel_rate->val is a plain s32 field. Declaring the local "pixel_rate" variable as u64 misrepresented its actual range and made do_div()'s divisor look wider than the 32-bit division it actually performs, which is exactly what the do_div() coccinelle check warns. Revert pixel_rate back to its original s32 type to match vsensor->pixel_rate->val, resolving the warning correctly. Fixes: ec1e620b2454 ("media: vimc: sensor: Add pixel_rate,vblank and hblank configuration") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202604191731.10nxGZ92-lkp@intel.com/ Link: https://lore.kernel.org/lkml/CANiDSCs9s03DUjKwcPgDtZt2QJ4i0FGwab4zpEP+wCawagSC2Q@mail.gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Faizel K B Reviewed-by: Ricardo Ribalda Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e511ec0459c5b0381fe089db9514d1fcac0b2aa3 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 a711436838b4b8a409a6f6353bac4ce5e6a43495 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 37630129efa1f356d5266476bbeadcb929790d3a 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 370da00b000230944466896c5f5c8cd0c3c23890 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 c6225311418caf83c09f3f9424a82ddbbc8c6093 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 bef138010dad7f448878a3577d32bb278b59d9d2 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 617b0c1115217fed876c9fddea4a527a50d2ec5a 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 450f37994eb36e006ebfd075e8fdc27b9465ca22 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 079615bb524a3f118b1c82fdf49c2596eae6f340 Author: Linkai Gong Date: Wed Aug 19 14:33:51 2026 +0800 media: pci: hws: only init channels the device actually has [ Upstream commit ad5390c35ccf98cec66ef1009351305f25b5a757 ] hws_probe() initializes max_channels (always 4) control handlers, but register/unregister only walk cur_max_video_ch (1 or 2 on smaller chips). The extra handlers are never freed. Initialize the same number of channels that cleanup uses. Fixes: ba07fd2f5742 ("media: pci: add AVMatrix HWS capture driver") Cc: stable@vger.kernel.org Signed-off-by: Linkai Gong Reviewed-by: Ben Hoff Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9be75b4b0b37f6720cf7255c5c3ad021ca08ee3b Author: Hao-Qun Huang Date: Sat Aug 8 23:08:46 2026 +0800 media: hws: Wait for IRQ handler before returning buffers [ Upstream commit 1ba17b5a54187e8bb251ff9636ed65c84719b013 ] hws_stop_streaming() disables capture and then collects the active and queued buffers straight away. Clearing cap_active and setting stop_requested only stops a VDONE handler that has not checked them yet; one already running on another CPU has passed those checks and cannot be recalled. That handler snapshots v->active into a local pointer and drops irq_lock before it touches the buffer, so stop_streaming can run in between. Without a next_prepared buffer both paths complete the same buffer, and the second vb2_buffer_done() hits the WARN_ON for a buffer that is no longer active. With a next_prepared buffer the snapshot is the only remaining reference to the old active buffer, so stop_streaming returns without it and vb2 reports "stop_streaming operation is leaving buffer %u in active state" before completing it with an error. Either way the driver breaks the vb2 rule that stop_streaming has to give back every buffer it owns before it returns. Wait for the handler once the hardware is disabled and before the buffers are collected. The live mode change and the channel cleanup paths already do this around the same collect helper. Fixes: ba07fd2f5742 ("media: pci: add AVMatrix HWS capture driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Hao-Qun Huang Reviewed-by: Ben Hoff Tested-by: Ben Hoff Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ce6b17de65f817c63544ebf5bc00740ae1ac15d3 Author: Ben Hoff Date: Fri Aug 7 03:46:47 2026 -0400 media: hws: report measured colorimetry [ Upstream commit 4d28f97400376d4064c69e2c194ce18eeb69f3e5 ] At 1920x1080, the driver advertises V4L2_COLORSPACE_REC709 with V4L2_YCBCR_ENC_DEFAULT. The default maps to a Rec.709 matrix, but controlled A/B captures using the in-tree and baseline drivers show that both produce YUYV samples using a BT.601 matrix and full-range quantization. The captures differ by at most one code value, whereas a 601-to-709 conversion would move primary luma values by roughly 11 to 33 codes. Set the Y'CbCr encoding explicitly to V4L2_YCBCR_ENC_601 at every resolution. Keep the resolution-based colorspace so HD retains presumed Rec.709 primaries and transfer characteristics while SD continues to use SMPTE 170M. Refresh the colorspace on detected geometry changes so an SD/HD transition does not leave stale metadata. The decoder mode register is undocumented. Stop claiming that value 0x13 selects BT.709; both drivers use that value while producing the measured output. Fixes: ba07fd2f5742 ("media: pci: add AVMatrix HWS capture driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Ben Hoff Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 08f76235edcfe47c281d23244c7ddd85e6da8463 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 fc00d3bf8edfc381afeb87fda3b4bed7d473700a 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 f6cdb40f4b2fa3db2ef4578566907052dce2a7fd Author: GUO Ren (XuanTie) Date: Mon Aug 17 03:30:38 2026 +0000 riscv: dts: spacemit: k3: fix IMSIC num-guest-ids [ Upstream commit 69f95409f0053f787ad60175944080621a8b7d95 ] The initial K3 device tree used generic/placeholder values for the IMSIC guest configuration: riscv,num-guest-ids = <511>; According to the SpacemiT K3 User Manual this values is incorrect for the X100 cores: - Advanced Interrupt Architecture (AIA): - M-mode MSI: 512 - S-mode MSI: 512 - VS-mode MSI: 64 Therefore, S-mode IMSIC (simsic) needs num-guest-ids = 63. Fixes: 56f37e391a62 ("riscv: dts: spacemit: add initial support for K3 SoC") Cc: stable@vger.kernel.org Cc: Guodong Xu Cc: Yixun Lan Signed-off-by: GUO Ren (XuanTie) Reviewed-by: Yixun Lan Reviewed-by: Junhui Liu Link: https://patch.msgid.link/20260817033038.2286436-1-guoren@kernel.org Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit c72b7b9cf0736a1e135a9c7d5869d5ad39dfc5ca Author: Rosen Penev Date: Mon Aug 24 13:21:20 2026 -0700 mtd: rawnand: ndfc: use devm_platform_ioremap_resource() [ Upstream commit 0d66f9895f286d2fab396a71e6efeb95c4a7e5a6 ] Replace the open-coded of_iomap()/iounmap() with the managed devm_platform_ioremap_resource() helper. This fixes a mapping leak on driver remove (the old code never called iounmap()) and simplifies the error path by dropping the manual cleanup in ndfc_probe(). There is no overlapping memory-region concern introduced by this change: each supported board DT describes a single ndfc node with a unique 0x2000 register region, and the EBC parent uses dcr-reg rather than a MEM reg resource, so the newly added request_mem_region() cannot conflict with an existing reservation. Distinct chip selects map to distinct 64-bit physical addresses, so CS instances do not overlap. Fixes: a808ad3b0d28 ("[MTD] [NAND] ndfc driver") Cc: stable@vger.kernel.org Assisted-by: opencode:hy3-free Signed-off-by: Rosen Penev Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 88797cada29023f2f27809dbb38cf9c140ecdd12 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 bb999fc09e473e84bd8e7cf9899f855ccaf9ee54 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 a5c2fd5d1ad0d7ddc83adb5952cddd4f3abec4d1 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 18ba0295bd43fc086408f3cf515bc57491dbbe3c 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 cc980ef537d4be2c4efd7fbda0af95565fd638b3 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 3cc28e51ea3cc4f551be314e56f6ee3b9d2cf567 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 db4a2da55ca42156acc2f53a5055f7282f2775d4 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 a5de200ac41bede9ef7f7f173e76f50fe6d5ca71 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 f44903fd54634e5b81bda4b90b6b583cd75d7157 Author: Marek Vasut Date: Fri Aug 21 04:05:51 2026 +0200 PCI: rcar-gen4: Limit Max_Read_Request_Size to 256 Bytes [ Upstream commit f0a5c6bd797c2b9900034983a1118d27eb2f2f16 ] R-Car Gen4 PCIe controller has a hardware limitation of 256 Bytes Max_Payload_Size (MPS). PCIe specification indicates that the MPS must not exceed minimum MPS of any element along the packet path. The PCI core already enforces this, but add a check to warn if MPS is ever set larger than 256. R-Car Gen4 Reference Manual, chapter 104.4.8 Usage notes for MRRS (Max Read Request Size) states: Please set "Max Read Request Size" to 128 bytes or 256 bytes. If "Max Read Request Size" is set to anything other than the above, the transferred data will not match the expected value. This limitation also seems to apply to devices doing DMA reads, i.e., issuing MRd TLPs. This limitation can be triggered by using non-HMB NVMe SSD with Max_Read_Request_Size 512 Bytes, for example Crucial P5 Plus. Any write to the SSD (MRd TLP issued by the SSD controller) longer than 256 Bytes wraps around at the 256 Byte boundary, and the same data are written to the SSD starting at offset 0 and at 256 Bytes. Limit Max_Read_Request_Size to at most 256 Bytes for each device connected to this PCIe controller to avoid this behavior. A non-HMB (Host Memory Buffer) NVMe SSD can be identified using the following command. Affected SSD reports 'hmpre' field as 0: $ nvme id-ctrl /dev/nvme0 | grep hmpre hmpre : 0 The symptom is a read from the SSD which wraps around at 256 Byte boundary. The test for this symptom can be implemented by writing 512 Byte of random data into the SSD and reading the data back. If the read back data repeat after 256 Bytes, the device is affected. $ dd if=/dev/urandom of=/tmp/data.bin bs=256 count=2 ; \ dd if=/tmp/data.bin of=/dev/nvme0n1 bs=256 count=2 ; \ dd if=/dev/nvme0n1 bs=256 count=2 of=/tmp/readback.bin Expected data: $ hexdump -vC /tmp/data.bin 00000000 97 81 b7 3b 0e 38 2b 4d a7 d3 e0 47 ff c2 4b ca 00000010 c1 85 98 f0 4a ac 03 a0 3b ab f3 19 44 dd 06 8b ... 00000100 7a ce 3c b2 e1 d5 d9 11 88 63 10 59 76 3c dc 32 <-- random 00000110 72 32 2a 7d a3 e1 aa 13 7c da 58 a1 7b 21 11 50 <-- data Faulty readback, collected without this change in place: $ hexdump -vC /tmp/readback.bin 00000000 97 81 b7 3b 0e 38 2b 4d a7 d3 e0 47 ff c2 4b ca <---. 00000010 c1 85 98 f0 4a ac 03 a0 3b ab f3 19 44 dd 06 8b <-. | ... | | 00000100 97 81 b7 3b 0e 38 2b 4d a7 d3 e0 47 ff c2 4b ca <-:-+- repeated 00000110 c1 85 98 f0 4a ac 03 a0 3b ab f3 19 44 dd 06 8b <-+--- data ^^^ | '--- Repeat starts at offset 0x100 = 256 Bytes Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode") Signed-off-by: Marek Vasut Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260821020636.111719-1-marek.vasut+renesas@mailbox.org Signed-off-by: Sasha Levin commit 3943cc7b64009111488ecaf7e086eadd3dd06f68 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 c30905f0a53abac8c4170eff688e9997cb885aea 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 5d48c1959ced217445315d9b453d19756c3de717 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 200418136724a7ae54ae1aefe2501ebe06f1b8a0 Author: Ricardo Ribalda Date: Mon Aug 31 08:50:56 2026 +0000 clk: mediatek: Add missing depend for COMMON_CLK_MT8173 [ Upstream commit 84964d0ce3faed815e1b8e048ce5ce1c93badb18 ] PM_GENERIC_DOMAINS_OF depends on OF, by adding a select to it without adding a depend on OF, the following warning is triggered: WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS_OF Depends on [n]: PM_GENERIC_DOMAINS [=y] && OF [=n] Selected by [y]: - COMMON_CLK_MT8173_MFGTOP [=y] && COMMON_CLK [=y] && (ARCH_MEDIATEK || COMPILE_TEST [=y]) && COMMON_CLK_MT8173 [=y] && PM [=y] This patch explicitly adds a dependency on OF to solve this issue. Cc: stable@vger.kernel.org Fixes: ebd0b73d2137 ("clk: mediatek: Add mt8173-mfgtop driver") Signed-off-by: Ricardo Ribalda Reviewed-by: Chen-Yu Tsai Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 89d1e9ef79d6d3af68c45b6ed14b3313af6f3276 Author: David Heidelberg Date: Wed Sep 2 22:59:12 2026 +0200 arm64: dts: qcom: sdm845-google: Set i2c3 frequency to 400 kHz [ Upstream commit a317bee7cd894188d99b4edd841744f70ed9cd8c ] The Device Tree found in the downstream kernel for this device doesn't explicitly set a bus frequency, resulting in 400 kHz being chosen. This upstream DT also lacks it, however that results in a different default value of 100 kHz. Set it to 400 explicitly to match the downstream kernel. Cc: stable@vger.kernel.org Fixes: 10f91b0dfaf6 ("arm64: dts: qcom: sdm845-google-common: Enable NFC") Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20260902-sdm670-sargo-nfc-v1-1-bed1cbbffc46@ixit.cz [bjorn: Updated commit message based on suggestion from Konrad] Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 706f6ad40abe290d3164cb1d4aecce2b921ef334 Author: Antti Laakso Date: Thu Sep 3 13:07:53 2026 +0300 media: i2c: cvs: Add sensor node in bound callback [ Upstream commit 7456b40bc992a3fc34b587545716729923d507b9 ] Sensor device nodes are created in the complete callback, which is only called when all devices are successfully registered. If any device fails to register, e.g. due to a missing driver, the complete callback is never invoked and sensor nodes are not created. Create sensor device nodes in the bound callback instead, ensuring they are available as soon as sensor is bound regardless of other devices registration status. Fixes: 8e2b43d2c10b ("media: i2c: cvs: Add driver of Intel Computer Vision Sensing Controller(CVS)") Cc: stable@vger.kernel.org Signed-off-by: Antti Laakso Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 6c0c04f4b5c5c00ad9fef5dbfcabd9219533696b 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 53ac20d3abe7d95d384d87cbf8bdcd27fa051ca7 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 bc439f8c590e5b90473a48b39dcbc07259ce9327 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 698119b61439da00f6148b43fb96e76d6492ddd0 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 aa6c2e1ab3b4a872ae9e59918124058b9d43bcdb Author: Hans de Goede Date: Tue Aug 18 14:28:21 2026 +0200 platform/x86: int3472: Increase handshake GPIO delay to 200 ms [ Upstream commit 844982d3b99340c21dd2125f44e1ad04ace6a38e ] There have been several reports of the sensor not properly powering on, on laptops where an INT3472 handshake GPIO is used. Both with ov08x40 and hi556 sensors. Testing has shown that a delay of 200 ms is necessary in some cases. The handshake GPIO is typically used to signal an extra bridge or other IC with that IC running the full sensor power sequence based on the handshake signal and also possible controlling I2C pass-through. It seems that in some cases that extra IC takes up to 200 ms to before the sensor is fully powered up and ready for I2C communication. With the default handshake signal delay increased to 200 ms the quirk to increase it to 45 ms for the ov08x40 is no longer necessary and is actually undesirable since some ov08x40 setups also need the longer delay, drop it. Fixes: 30359c239ba8 ("platform/x86: int3472: Increase ov08x40 handshake GPIO delay to 45 ms") Closes: https://lore.kernel.org/platform-driver-x86/20260816204247.2844986-1-opensource@inspiredexperts.com/ Reported-by: James Alexander Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2333331 Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2333647 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 18be38d3ac80c2c9e1816109b617358db1aa6e6f 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 05900047061ff42110ee2052e9d37d8d7fa3eb76 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 d7ba97ea9e4f65184aee292f03fddb600484fd33 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 aa33d8dae0b47d87dc886642a709e1fd41266463 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 d6ac588011cf1c87aabeeef2c6a2f09d5cab6e76 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 621858d077608515c043dedc1ee2847d35a20e14 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 d0e60dcada94dec8aa390974d47e39b3a14677a7 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 daf124d46c9b667969e100d7e2c2eacab26c17c3 Author: Liu Zhenlong Date: Mon Aug 17 01:16:33 2026 +0800 PCI: aspeed: Fix clk and PHY leak in aspeed_pcie_port_init() error paths [ Upstream commit a54ac2eb6eca8baa86b89494b8a0d9439a0f72ee ] aspeed_pcie_port_init() calls clk_prepare_enable() to enable the port clock, but if phy_init() or phy_set_mode_ext() fails afterwards, the function returns without calling clk_disable_unprepare(), leaking the clock reference on every probe failure. Additionally, when phy_set_mode_ext() fails, phy_init() has already succeeded, so phy_exit() is also missing, leaking the PHY reference. Add the matching clk_disable_unprepare() to both error paths, and phy_exit() to the phy_set_mode_ext() failure path, mirroring the cleanup pattern in pci-aardvark. Compile-tested with gcc on arm64 defconfig using COMPILE_TEST. Fixes: 9aa0cb68fcc1 ("PCI: aspeed: Add ASPEED PCIe RC driver") Signed-off-by: Liu Zhenlong Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Assisted-by: LLM Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260816171633.15025-1-dragonliu2018@gmail.com Signed-off-by: Sasha Levin commit 560fb159ad7bb7765686da8d10d568f9f7270e88 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 60fa983bcf4e19fd1bbeb6f30821e57bfd632f33 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 3f11e9ef8441e039c635b7acdbad992c1e27f644 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 60351dccca23099bf3279b093ce9dd4b5ec01e86 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 2959cb1fceb465db85cff47f8159375eb721570b Author: Yunpeng Tian Date: Mon Aug 31 17:31:16 2026 +0200 udf: validate the device specification EA before using it [ Upstream commit 9a2390959685ac35a58c80c8016120849a2babf6 ] udf_get_extendedattr() bounds an extended attribute only against struct genericFormat, which is 12 bytes. A type-12 device specification is struct deviceSpec, which is 24 bytes plus a flexible impUse array. Thus a corrupted filesystem can contain extended attribute that is accepted by udf_get_extendedattr() but udf_write_inode() or udf_read_inode() may access beyond the end of provided buffer. Provide a udf_device_spec_valid() check to validate correctness of extended attribute that is a deviceSpec. While here, check the result of udf_add_extendedattr() before dereferencing it as it can return NULL in case of error. [JK: Removed duplicated validity checks] Reported-by: Yunpeng Tian Reported-by: Gongming Wang Reported-by: Mingda Zhang Reported-by: Qinrun Dai Cc: stable@vger.kernel.org Signed-off-by: Yunpeng Tian Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 0965f82b99bb8b6c8aecbaeb98cbd66aad4c95d1 Author: Christopher Obbard Date: Sat Aug 29 11:36:00 2026 +0100 PCI: qcom: Only check bridge nodes for PERST# GPIOs [ Upstream commit 1b3b0bc2b3672e928e06997444528f8797579eb2 ] qcom_pcie_parse_perst() walks the PCIe hierarchy described in the device tree below its Root Port and collects the PERST# GPIOs from each bridge node so all PERST# lines can be driven in unison during controller bring-up, reset and power sequencing. However, the recursive device tree walk currently visits every available child node without checking that it is a PCI bridge. This allows the walk to leave the PCI hierarchy and collect reset lines from children of PCI Endpoint nodes, where those reset lines belong to other drivers. This is reproducible on the Qualcomm RB3Gen2, where a Renesas uPD720201 USB host controller sits behind a PCIe switch downstream port. A Genesys GL3590 USB hub connected to that controller is described as a child of the PCI endpoint: pcie@2,0 { device_type = "pci"; usb-controller@0,0 { compatible = "pci1912,0014"; hub@1 { compatible = "usb5e3,610"; reset-gpios = <&tlmm 162 GPIO_ACTIVE_HIGH>; }; }; }; The USB controller is a PCI Endpoint, and not a bridge, but the PERST# walk descends through it and incorrectly claims the hub's reset GPIO: $ gpioinfo line 162: unnamed output consumer=PERST# As a result, the onboard-usb-dev driver cannot acquire its reset GPIO during probe: onboard-usb-dev 1c08000.pcie:...:usb-controller@0,0:hub@1: \ error -EBUSY: failed to get reset GPIO onboard-usb-dev 1c08000.pcie:...:usb-controller@0,0:hub@1: \ probe with driver onboard-usb-dev failed with error -16 The GPIO is also added to the root port's PERST# list and is asserted and deasserted as part of PCIe reset sequencing. On the RB3Gen2 this causes the USB hub to repeatedly re-enumerate: [ 116.479598] hub 2-1:1.0: USB hub found [ 116.488601] hub 2-1:1.0: USB hub found [ 116.496971] hub 2-1:1.0: USB hub found ... This disrupts the hub and devices connected to it. Restrict the recursive walk to children with device_type "pci", so PERST# GPIOs are collected only from PCI bridge nodes and the walk does not descend through endpoints. qocm_pcie_parse_ports() has made the same distinction since commit 45df22935bdc ("PCI: qcom: Restrict port parsing only to PCIe bridge child nodes"), but the PERST# walk added later did not carry over that check. This bug is distinct from commit 3edb3a038d42 ("PCI: qcom: Skip PERST# GPIOs provided by downstream PCIe devices"), which filters PERST# GPIOs based on their provider. Here the GPIO is provided by the SoC TLMM; the bug is that reset-gpios is consumed from a non-bridge node at all. Fixes: 2fd60a2edb83 ("PCI: qcom: Parse PERST# from all PCIe bridge nodes") Signed-off-by: Christopher Obbard Signed-off-by: Manivannan Sadhasivam Reviewed-by: Krishna Chaitanya Chundru Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260829-wip-obbardc-drivers-pcie-qcom-rb3gen2-usb-fix-v1-1-337821131a99@oss.qualcomm.com Signed-off-by: Sasha Levin commit 608664dfb2a3ebef8caa5d15e9150fdb3c7c3399 Author: Abel Vesa Date: Wed Aug 19 10:23:28 2026 +0300 soc: qcom: pmic_glink: Fix device access from worker during suspend [ Upstream commit 7d0767c5cd878707fd6711023731549c83563840 ] For historical reasons, the GLINK smem interrupt is registered with IRRQF_NO_SUSPEND flag set, which is the underlying problem here, since the incoming messages can be delivered during late suspend and early resume. In this specific case, the pmic_glink_altmode_worker() currently gets scheduled on the system_wq which can be scheduled to run while devices are still suspended. This proves to be a problem when a Type-C retimer, switch or mux that is controlled over a bus like I2C, because the I2C controller is suspended. This has been proven to be the case on the X Elite boards where such retimers (ParadeTech PS8830) are used in order to handle Type-C orientation and altmode configuration. The following warning is thrown: [ 35.134876] i2c i2c-4: Transfer while suspended [ 35.143865] WARNING: CPU: 0 PID: 99 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xb4/0x57c [i2c_core] [ 35.352879] Workqueue: events pmic_glink_altmode_worker [pmic_glink_altmode] [ 35.360179] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 35.455242] Call trace: [ 35.457826] __i2c_transfer+0xb4/0x57c [i2c_core] (P) [ 35.463086] i2c_transfer+0x98/0xf0 [i2c_core] [ 35.467713] i2c_transfer_buffer_flags+0x54/0x88 [i2c_core] [ 35.473502] regmap_i2c_write+0x20/0x48 [regmap_i2c] [ 35.478659] _regmap_raw_write_impl+0x780/0x944 [ 35.483401] _regmap_bus_raw_write+0x60/0x7c [ 35.487848] _regmap_write+0x134/0x184 [ 35.491773] regmap_write+0x54/0x78 [ 35.495418] ps883x_set+0x58/0xec [ps883x] [ 35.499688] ps883x_sw_set+0x60/0x84 [ps883x] [ 35.504223] typec_switch_set+0x48/0x74 [typec] [ 35.508952] pmic_glink_altmode_worker+0x44/0x1fc [pmic_glink_altmode] [ 35.515712] process_scheduled_works+0x1a0/0x2d0 [ 35.520525] worker_thread+0x2a8/0x3c8 [ 35.524449] kthread+0xfc/0x184 [ 35.527749] ret_from_fork+0x10/0x20 The proper solution here should be to not deliver these kind of messages during system suspend at all, or at least make it configurable per glink client. But simply dropping the IRQF_NO_SUSPEND flag entirely will break other clients. The final shape of the rework of the pmic glink driver in order to fulfill both the filtering of the messages that need to be able to wake-up the system and the queueing of these messages until the system has properly resumed is still being discussed and it is planned as a future effort. Meanwhile, the stop-gap fix here is to schedule the pmic glink altmode worker on the system_freezable_wq instead of the system_wq. This will result in the altmode worker not being scheduled to run until the devices are resumed first, which will give the controllers like I2C a chance to resume before the transfer is requested. Reported-by: Johan Hovold Closes: https://lore.kernel.org/lkml/Z1CCVjEZMQ6hJ-wK@hovoldconsulting.com/ Fixes: 080b4e24852b ("soc: qcom: pmic_glink: Introduce altmode support") Cc: stable@vger.kernel.org # 6.3 Reviewed-by: Caleb Connolly Reviewed-by: Bjorn Andersson Signed-off-by: Abel Vesa Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20260819-b4-soc-qcom-pmic-glink-fix-device-access-on-worker-while-suspended-v3-1-169b00e0d9d4@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f2bc9dc41b5a4ce5fd535e50d8bc31cfd3130be7 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 8337359748cc070e0c95bcc544b17762b066bd7e 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 d1709448962f896d79583bce2844b28afb295669 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 fb684c428c8ae8609421ff8812a033faa11e9c54 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 fe4a7f89cbf2474d0fecc35a820757b04cfa0c1e 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 fd1fa7d85f5b71ddcb3c7fb02088d0cdeaeddd69 Author: Maxi Saparov Date: Tue Aug 11 12:18:57 2026 -0400 kho: do not reserve scratch memory in the kdump kernel [ Upstream commit 48be325089e15077411785d0c41ddb9071a61081 ] If a kernel with CONFIG_KEXEC_HANDOVER_ENABLE_DEFAULT=y (or kho=on) does not receive a handover FDT, it reserves KHO scratch memory in kho_reserve_scratch(). The kdump kernel always takes this path. Since commit a6715d7ec472 ("kho: skip KHO for crash kernel"), the kernel does not add KHO metadata to the crash kimage. As a result, the kdump kernel never receives a handover FDT and always reserves scratch memory. The kdump kernel boots in the small crashkernel= memory reservation. On our x86 hosts, the kernel and initramfs make approximately 176 MB of early reservations. The scratch areas then use approximately 650 MB more of the crashkernel memory. When a large early allocation fails, the kdump kernel panics: bio: can't create integrity buf pool A kdump kernel has nothing to hand over: its only task is to dump the memory of the old kernel and reboot. Fix is to disable KHO at the top of kho_memory_init() so that the kdump kernel does not reserve scratch memory. Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers") Cc: stable@vger.kernel.org Signed-off-by: Maxi Saparov Link: https://patch.msgid.link/20260811161857.3096-1-maxi.saparov@gmail.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit abdce0f17b8b6c2adff399fd79929bab584b436e 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 75484c58a1b75518f405e61cd20bf67afc245a7d 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 51f8743fc79597a16ff054481d4d9ae59abfd7f4 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 6cd03176a1c870c4e25ee4e4e4296fcb8ff5ee1c Author: Eric Sandeen Date: Wed Aug 12 16:44:38 2026 -0500 devtmpfs: restore mount option reconfiguration on get_tree [ Upstream commit 1c7df6fa838a46f0d5090ef134f67511f0592f33 ] commit cb0e0a8bf4e1 ("devtmpfs: replace ->mount with ->get_tree in public instance") converted the public devtmpfs instance to the new mount API but broke the ability to reconfigure the shared superblock options via subsequent mount() calls, as had been fixed once in a6097180d884 ("devtmpfs regression fix: reconfigure on each mount") This makes boot-time defaults permanent. Fix this using an approach suggested by Al Viro: at init_fs_context time, create a reconfigure-mode context via fs_context_for_reconfigure() and save it in fc->fs_private. The devtmpfs parse ops can then use this context to parse options appropriately for the underlying filesystem. This also removes the devtmpfs_configure_context() one-time ops-copying approach and the global mutable ops table it required. Fixes: cb0e0a8bf4e1 ("devtmpfs: replace ->mount with ->get_tree in public instance") Reported-by: Simon Liebold Cc: stable@vger.kernel.org Suggested-by: Al Viro Signed-off-by: Eric Sandeen Link: https://patch.msgid.link/b1bd3b15-78ea-4487-b6a8-aad0b05dd3bb@redhat.com Tested-by: Simon Liebold Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 3813a3a89ce037de462fb14efe44f71d9bb02745 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 301b5e14f18e8d74aae2938b7fbe95f4d7894e2d 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 f47ae8023820385c749a5fe5c991fd31950f135c 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 9b01eb250056db712af25ffff822b3e80331a9b3 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 ff7c717383390db99ecb52c1017381ae92426124 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 ef9a0883b7e9a1987e1d18075cf0f2aca9d8c985 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 9ef05df576544fa4d3d683f1c30e9073596d4930 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 70bb00b16ce428fca36d875d8cd3d783b05ed12a Author: Sean Young Date: Mon Jul 13 13:08:40 2026 +0100 media: redrat3: Error path leaves device in transmitting state [ Upstream commit 8024d5e84531d828535365718278f1cf0ce67db0 ] In the allocation failure error path, the transmitting boolean is not cleared. If this error path is followed the transmitter cannot be used again until the device is replugged or the module reloaded. Fix the error path by moving the assignment statement. Remove the check for the transmitting state in transmit, since rc-core ensures there is never a reentrant call to the driver transmit function; the transmit function is always called with dev->lock held. The transmitting boolean is only used for interpretting firmware errors. Fixes: fac59136bc22 ("[media] RedRat3: Return directly after a failed kcalloc() in redrat3_transmit_ir()")" Signed-off-by: Sean Young Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Sasha Levin commit a3eb5aa54ec7fe303cb9357cf7f62d17f1ab2aa4 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 6c13445133b61f643f6db56f23db4bbd1bdb3bdd 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 44414b196a0c84bc50adb2a96f42027203e47dec 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 f3253b91ef0b198e7c44746d0d79de327aeaddda 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 1852374816e00dd21ee7f73631f2288f553b0f6c Author: Esben Haabendal Date: Mon Aug 17 19:08:53 2026 +0200 iio: light: ltr501: Power down chip if request irq fails [ Upstream commit 8a9bcd587d7d768e6c8e9fff88bb89645e412731 ] In case devm_request_threaded_irq() failed, we were leaving the chip powered instead of powering it down again. Power down the chip switching ALS and PS modes to standby. Fixes: 7ac702b3144b ("iio: ltr501: Add interrupt support") Cc: stable@vger.kernel.org Acked-by: Kuppuswamy Sathyanarayanan Reviewed-by: Andy Shevchenko Signed-off-by: Esben Haabendal Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 74536340dbd2153d0342979234841f6c4846f733 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 db4b7b8f92337b2269d2529ef264848ccc5492bc 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 ec67981c87d574d584406ce341ab72067590069d 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 998378828857cc20856049b0d1fe6f5b32131659 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 16fd45596851eb1b14d5c9ea30aa044395ebe288 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 bf09cf3e05011b77d00c7dd4abca760dd8fff4f4 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 878556222f10dce4ec8f007e4bff6a86568c400f 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 08d221ba875629f92018de668c3c06ca82769b16 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 f1ef16495b494249ece0ae037121a6ed04015c8e 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 d690c7847212d4a8495d6ff0513bcec11acb021e Author: Matt Turner Date: Thu Nov 5 18:39:32 2026 -0500 alpha: honor force_successful_syscall_return() again This fix is for 7.1.y, 7.2.y and 7.3.y only. Mainline is not affected since commit 83bd31c2840b ("alpha: enable GENERIC_ENTRY") in v7.4-rc1, which replaced the saved-r0 check with a flag in thread_info. That conversion is far too large for stable, so this patch fixes the old entry code instead. Syscalls that return data rather than a status, such as PTRACE_PEEKUSR, PTRACE_PEEKTEXT/PEEKDATA, osf_sigprocmask and shmat, call force_successful_syscall_return() so that a result with the top bit set is not mistaken for an error. On alpha that clears the saved r0, and $syscall_error and $strace_error used to check for this and take the success path. Commit 55b22075f784 ("alpha: add support for SECCOMP and SECCOMP_FILTER") moved the restart syscall number to r2 and dropped both checks, so any negative result now comes back to userspace as an error with a3 set. PTRACE_PEEKUSR of a register holding -1 fails with EPERM, which makes sandbox abort when it traces static binaries during Gentoo package builds, and PTRACE_PEEKUSR of a register holding 0xffffffffffffe000 fails with errno 8192, which breaks unwinding of a ptrace-stopped thread in elfutils (run-backtrace-native.sh). Restore the checks on both exit paths. On the traced path the success path also has to stop falling through into SYSCALL_SKIP_RETURN_RESTART_GATE, which is meant for skipped syscalls and would turn a forced-success result of -1 into ENOSYS. Link: https://bugs.gentoo.org/985765 Fixes: 55b22075f784 ("alpha: add support for SECCOMP and SECCOMP_FILTER") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Matt Turner Signed-off-by: Sasha Levin commit 77a3708e5ca3cf460fc25f2d07caf828eb440162 Author: Sean Young Date: Wed Nov 4 21:00:56 2026 -0500 media: rc: Add missing locking for keymap [ Upstream commit ab9567336171e46ce9e03ee126902b3fd7901baa ] When the rc_map for an rc_dev gets updated, locking is required but is missing in places. A concurrent scancode lookup and a call to rc_{register,unregistered}_device() could result in a use-after-free; this could happen if IR is decoded during those function calls. Add lockdep assertions where locks are required. ir_free_table() should only be called for non-TX devices else we will use a spinlock without iniitializing it. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Sasha Levin commit 843cb5580911d0907b57bfe1a618b8b2adc255a7 Author: Sean Young Date: Wed Nov 4 21:00:55 2026 -0500 media: rc: Replace open coded krealloc() for keymap [ Upstream commit e4b4aa413cc2e48a261c8c513ced964a3390c0cf ] Replace open coded krealloc() and remove superfluous member of struct rc_map - we don't need to track both the size in bytes and entries. Signed-off-by: Sean Young Acked-by: Hans Verkuil Stable-dep-of: ab9567336171 ("media: rc: Add missing locking for keymap") Signed-off-by: Sasha Levin commit 8b2b6e138f206a61328deb54d89e3e6e6a846f54 Author: Sami Tolvanen Date: Fri Nov 6 15:38:02 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 [ Adjusted insertion context. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 996cf1b7115fbc40e6c54f3ded3fc938055c3ab4 Author: Sami Tolvanen Date: Fri Nov 6 15:38:01 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 [ Adjusted insertion context. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 08fafee643dc6fbd4ea3aeca477462cefa8eec3b Author: Sami Tolvanen Date: Wed Nov 4 15:17:58 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: Adjusted insertion context to preserve existing fwctl_rpc_scope CFI declarations. ] Signed-off-by: Sasha Levin commit eb8a2d156f2c1d862fffdfd1b3432bfbcd939879 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 733a4f28a88c0eddeaf65eb5d3a3b4ca4e219a93 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 7f3ea4dc421718f51b9b123df8bffeeed1aab4b4 Author: Ruide Cao Date: Tue Oct 13 16:29:22 2026 +0200 mptcp: fix MP_CAPABLE token migration when cloning reqsk [ Upstream commit 2093bc7fa50056fef8620d2b82bcb2e9a0a5575d ] TCP request migration clones pending request sockets with inet_reqsk_clone(). For MPTCP MP_CAPABLE requests this byte-copies the token_node hlist state into the clone even though the token table still names the original request, and the following warning can be seen: WARNING: net/mptcp/token.c:364 at mptcp_token_destroy_request+0x2b0/0x330, CPU#2: swapper/2/0 CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 7.2.0-rc5-00353-gc27e36054537 #10 PREEMPT(full) RIP: 0010:mptcp_token_destroy_request (net/mptcp/token.c:364 (discriminator 1)) Call Trace: 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) call_timer_fn (kernel/time/timer.c:1748) Move token request ownership from the original request to the clone under the token bucket lock. Make mptcp_token_accept() and mptcp_token_destroy_request() re-check token_node under the same lock and treat an already moved or removed request as a normal race instead of warning. This also keeps token bucket chain_len accounting balanced. If a passive MP_CAPABLE socket cannot claim the token, destroy the provisional MPTCP socket and let the subflow fall back rather than installing a socket with mismatched token ownership. Mark that path as a passive handshake fallback so MPCapableFallbackACK records the downgrade. If the speculative clone later loses the inet_ehash_insert() ownership arbitration, the original request may find that its token was already moved and fall back to plain TCP. The clone destructor then releases the token reservation and keeps chain_len balanced. This trades an exceptionally rare fallback for eliminating the warning and persistent accounting drift. Fixes: c905dee62232 ("tcp: Migrate TCP_NEW_SYN_RECV requests at retransmitting SYN+ACKs.") Cc: stable@vger.kernel.org Reported-by: Vega Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/86e2514b533bf4d55d4aa2fdbf1404022e8c9430.1776149210.git.caoruide123%40gmail.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-4-932c9b182fc7@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a79d563900e4fc4966e6666e663e2c5338c98d6f Author: Sean Young Date: Wed Jul 22 17:13:12 2026 +0100 media: saa7134: Specify rc type at rc_allocate_type() [ Upstream commit 33154da9f78041edd93f0895a7d697c67994d75b ] Changing the type of the rc device after allocation is ugly and this will also break in a future commit. Ensure that the allocation happens with the correct type in the first place. Signed-off-by: Sean Young Reviewed-by: Hans Verkuil Signed-off-by: Sasha Levin commit 46dcd5184da235d0c88c902673a0d7f2f796098c Author: Sean Young Date: Wed Jul 22 17:08:09 2026 +0100 media: cx88: Specify rc type at rc_allocate_type() [ Upstream commit a127f5e9f9ea0470ee3bf83fab82441ae11af208 ] Changing the type of the rc device after allocation is ugly and this will also break in a future commit. Ensure that the allocation happens with the correct type in the first place. Signed-off-by: Sean Young Reviewed-by: Hans Verkuil Signed-off-by: Sasha Levin commit c760e6b0cb7ce13bf53402582d2b7b11275fd95a Author: Tales A. Mendonça Date: Tue Sep 22 11:46:34 2026 -0300 drm/xe: Implement Wa_22016122933 [ Upstream commit d5b0bf3f37f152583a884c696cf6caa152aa7ed5 ] On platforms with a standalone media GT and media version 13.00 (MTL/ARL), memory shared between the CPU and the media GT's GuC must not be mapped cached on the CPU side: the CPU can otherwise read stale cache lines for data the GuC has already written. i915 implements this as Wa_22016122933 (see intel_gt_needs_wa_22016122933(), used by intel_guc_allocate_vma() and intel_gt_coherent_map_type()); xe never inherited it. The visible symptom on ARL is TLB invalidation acks stalling for a near-constant ~2.3s: the GuC writes the G2H ack in time, but the CPU keeps reading a stale (empty) view of the G2H CTB until the line is naturally evicted, so the fence timeout at 2.25s fires first. GuC log decode confirmed all invalidations were handled promptly by the firmware, and only the media GT was affected. See Link for the full investigation (three machines affected: 7d51, 7dd1, Arc Pro 130T). Making the mapping coherent instead of uncached does not help: with a GGTT PAT entry repurposed to WB|COH_2WAY the driver comes up and the media GT GuC runs, but the stalls remain (request-to-ack 2290ms). Uncached really is required here. Note that 2-way coherency is not normally reachable from a GGTT PTE (only 2 PAT bits), so that experiment needed a modified PAT table and may not reflect a supported configuration. Add the OOB workaround scoped like i915 (media version 13.00, media GT only - MEDIA_VERSION() OOB rules only match the media GT on standalone media platforms) and apply XE_BO_FLAG_NEEDS_UC to the GuC-shared allocations the CPU reads from: the CTBs, the GuC log, ADS, the SLPC shared data and the engine activity buffers. hwconfig and the G2G buffer are allocated on the primary GT only, where the workaround does not apply. Note that XE_BO_FLAG_NEEDS_UC drives both the CPU mapping (uncached) and the GGTT cache mode (XE_CACHE_NONE instead of XE_CACHE_WB), which is stricter than i915: i915 documents the workaround as WC on the CPU side and UC on the GPU side. A CPU-WC variant with the GGTT side kept at XE_CACHE_NONE was measured to be equally effective, but expressing it would require either a new BO flag or decoupling the GGTT cache-mode selection from XE_BO_FLAG_NEEDS_UC - simply swapping in XE_BO_FLAG_FORCE_WC silently relaxes the GPU side back to WB and the stalls return. The stricter mapping is kept here since it is the tested configuration and no throughput difference between the two was measurable; the extra plumbing can be added later if parity with i915 is preferred. Scope is limited to the GuC-shared allocations, which is where the failures were observed. i915 additionally covers media-GT LRC/ring state; extending xe to match can be done as a follow-up if wanted. Validation on two ARL machines (7d51 and 7dd1): before, 20-60 TLB invalidation ack stalls per day, every day, for weeks, on every kernel and on two GuC firmware versions (70.53.0 and 70.72.1). After: zero stalls in six weeks of combined runtime, over 10M TLB invalidations processed under the same workloads, across kernels 7.1.6, 7.1.8 and 7.2. The 7dd1 machine, which could not survive a day of media workloads on xe without a platform freeze, has been running xe full time since 11 August, including days with heavy video transcoding, with zero stalls and zero freezes. The coherency experiment, the CPU-WC measurements and the engine activity coverage gap were found by Navon John Lukose while A/B testing v2 on an ARL 7d51. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8678 Suggested-by: Daniele Ceraolo Spurio Signed-off-by: Tales A. Mendonça Tested-by: Navon John Lukose Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260922144634.55130-4-talesam@gmail.com Signed-off-by: Sasha Levin