commit f6388029ea9e2c9e807d73827658738ea131faee Author: Greg Kroah-Hartman Date: Fri Sep 11 11:49:46 2026 +0200 Linux 6.18.51 Link: https://lore.kernel.org/r/20260909134237.773280130@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Wentao Guan Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Peter Schneider Signed-off-by: Greg Kroah-Hartman commit d83a9de7cecd401c3d3e00ed6371194dcd7313e4 Author: Namjae Jeon Date: Tue Aug 25 09:31:35 2026 +0900 ksmbd: zero pipe read compound padding commit 73f860489e3be2245598d1819226304fc5b87291 upstream. Compound response handling extends the last response iov to an eight-byte boundary. smb2_read_pipe() allocates only the payload size, so the alignment padding can expose up to seven bytes of uninitialized kernel heap memory. Allocate the aligned size and clear the unused tail before pinning the response buffer. Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Reported-by: Cheryl Babcock Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 75640976cf474eb41682a13f2dbe9534ac26ca50 Author: Frank Sorenson Date: Sat Jul 25 21:04:44 2026 +0000 cifs: add fscache_resize_cookie() to cifs_setsize() commit fa724e235cfdb0fb0bb427d0f9dfe864ae27403e upstream. Several code paths update the VFS inode size by calling netfs_resize_file() and cifs_setsize(), but omit the corresponding fscache_resize_cookie() call, leaving the fscache cookie out of sync with the actual file size: - cifs_file_set_size() in inode.c: server-side truncation via setattr - cifs_do_truncate() in file.c: truncates to zero on O_TRUNC open - smb2_duplicate_extents() in smb2ops.c: file clone extending EOF - smb3_simple_falloc() in smb2ops.c: two branches that extend EOF via write-range and SMB2_set_eof respectively Since every caller of cifs_setsize() must resize the fscache cookie, add the call to cifs_setsize() itself, consistent with how truncate_pagecache() is already consolidated there. Fixes: 70431bfd825d ("cifs: Support fscache indexing rewrite") Fixes: 93a43155127f ("cifs: Fix missing set of remote_i_size") Fixes: 110fee6b9bb5 ("smb: client: fix missing timestamp updates with O_TRUNC") Fixes: 7a06d3b816d7 ("smb/client: emulate small EOF-extending mode 0 fallocate ranges") Cc: stable@vger.kernel.org Cc: David Howells Cc: Paulo Alcantara Cc: Huiwen He Signed-off-by: Frank Sorenson Reviewed-by: Paulo Alcantara Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d73f79d1a2c26a8cdf0558d9a0203ee64d9b4f51 Author: Muchun Song Date: Mon May 25 10:52:13 2026 +0800 mm/hugetlb_vmemmap: fix incorrect vmemmap restore in rollback commit c7bde43f6daf70e05a64fbca7efdf6fa93e057dc upstream. vmemmap_restore_pte() rebuilds restored vmemmap pages from a tail-page template derived from compound_head(). This is wrong when the current PTE already maps a page whose contents are not tail-page metadata. In the rollback path of vmemmap_remap_free(), the first restored PTE is backed by vmemmap_head and contains head-page metadata. Reconstructing that page from a tail-page template overwrites the head-page state and corrupts the restored vmemmap page. Fix this by copying the full page from the page currently mapped by the PTE. Also pass vmemmap_tail to the rollback walk so only PTEs backed by the shared tail page are restored, while the head PTE remains mapped to vmemmap_head. Add VM_WARN_ON_ONCE() checks for unexpected cases. Link: https://lore.kernel.org/20260525025213.2229628-1-songmuchun@bytedance.com Fixes: c0b495b91a47 ("mm/hugetlb: refactor code around vmemmap_walk") Signed-off-by: Muchun Song Acked-by: Kiryl Shutsemau Acked-by: Oscar Salvador (SUSE) Cc: David Hildenbrand Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 15803e2276067529faa6bb46eb4d2c67bf053cfd Author: Christian Brauner Date: Wed Dec 24 13:00:24 2025 +0100 pidfs: protect PIDFD_GET_* ioctls() via ifdef commit 75ddaa4ddc86d31edb15e50152adf4ddee77a6ba upstream. We originally protected PIDFD_GET__NAMESPACE ioctls() through ifdefs and recent rework made it possible to drop them. There was an oversight though. When the relevant namespace is turned off ns->ops will be NULL so even though opening a file descriptor is perfectly legitimate it would fail during inode eviction when the file was closed. The simple fix would be to check ns->ops for NULL and continue allow to retrieve namespace fds from pidfds but we don't allow retrieving them when the relevant namespace type is turned off. So keep the simplification but add the ifdefs back in. Link: https://lore.kernel.org/20251222214907.GA189632@quark Link: https://patch.msgid.link/20251224-ununterbrochen-gagen-ea949b83f8f2@brauner Fixes: a71e4f103aed ("pidfs: simplify PIDFD_GET__NAMESPACE ioctls") Tested-by: Brendan Jackman Tested-by: Eric Biggers Reported-by: Eric Biggers Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit ed7380f4621f61e4293c0265d035c0f70f7750e4 Author: Zi Yan Date: Thu Sep 3 14:26:50 2026 -0400 mm/huge_memory: use folio's memcg inside __folio_split() [ Upstream commit c299a2285d9d8bda4da024455de65e3d00de6f17 ] Patch series "Honor XA_FLAGS_ACCOUNT in xas_split_alloc() and charge to folio's memcg", v3. __GFP_ACCOUNT is needed for xarray node allocation accounting when XA_FLAGS_ACCOUNT is set. Commit 7b785645e8f13 ("mm: fix page cache convergence regression") fixed a workingset regression with it. xas_split_alloc() does not have it and needs to be fixed. In addition, based on Sashiko's review[1] and Johannes' confirmation[2], to charge the right memcg, folio's memcg needs to be active during folio split. Add that before adding __GFP_ACCOUNT. There is no workingset convergence regression related to missing __GFP_ACCOUNT in xas_split_alloc() and the impact to userspace should be minor. This patch (of 2): During a pagecache folio split, an xarray node allocation can happen and needs to charge at folio's memcg instead of folio split invoker's memcg, because for example folio split can happen during reclaim and reclaim's active memcg might not be folio's memcg. Switch to folio's memcg at the beginning and switch back afterwards. Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-0-38cb3ff325c5@nvidia.com Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-1-38cb3ff325c5@nvidia.com Link: https://sashiko.dev/#/patchset/20260727-add-gfp_account-to-xas_split_alloc-v1-1-9fae6bf64838%40nvidia.com?part=1 [1] Link: https://lore.kernel.org/all/amtcBZ-_QVRgCd6b@cmpxchg.org/ [2] Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache") Signed-off-by: Zi Yan Suggested-by: Johannes Weiner Reviewed-by: Baolin Wang Acked-by: Lorenzo Stoakes (ARM) Acked-by: Johannes Weiner Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Matthew Wilcox (Oracle) Cc: Ryan Roberts Cc: William Kucharski Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 80656031dfcd4ea8d9fda2913859efde9832edb5 Author: Matthew Wilcox (Oracle) Date: Thu Sep 3 14:26:49 2026 -0400 migrate: replace RMP_ flags with TTU_ flags [ Upstream commit 832d95b5314eea558cf4cc9ca40db10122ce8f63 ] Instead of translating between RMP_ and TTU_ flags, remove the RMP_ flags and just use the TTU_ flag space; there's plenty available. Possibly we should rename these to RMAP_ flags, and maybe even pass them in through rmap_walk_arg, but that can be done later. Link: https://lkml.kernel.org/r/20260109041345.3863089-3-willy@infradead.org Signed-off-by: Matthew Wilcox (Oracle) Acked-by: David Hildenbrand (Red Hat) Reviewed-by: Lorenzo Stoakes Reviewed-by: Zi Yan Cc: Alistair Popple Cc: Byungchul Park Cc: Gregory Price Cc: Jann Horn Cc: Joshua Hahn Cc: Lance Yang Cc: Liam Howlett Cc: Matthew Brost Cc: Rakie Kim Cc: Rik van Riel Cc: Vlastimil Babka Cc: Ying Huang Signed-off-by: Andrew Morton Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e4307837d92cac760519a7048c0ca83a10ed86f3 Author: Zi Yan Date: Thu Sep 3 14:26:48 2026 -0400 mm/huge_memory: replace can_split_folio() with direct refcount calculation [ Upstream commit 5842bcbfc316738cbfcbdb4def5a7592aa03ebf2 ] can_split_folio() is just a refcount comparison, making sure only the split caller holds an extra pin. Open code it with folio_expected_ref_count() != folio_ref_count() - 1. For the extra_pins used by folio_ref_freeze(), add folio_cache_ref_count() to calculate it. Also replace folio_expected_ref_count() with folio_cache_ref_count() used by folio_ref_unfreeze(), since they are returning the same values when a folio is frozen and folio_cache_ref_count() does not have unnecessary folio_mapcount() in its implementation. Link: https://lkml.kernel.org/r/20251126210618.1971206-3-ziy@nvidia.com Signed-off-by: Zi Yan Suggested-by: David Hildenbrand (Red Hat) Reviewed-by: Wei Yang Acked-by: David Hildenbrand (Red Hat) Cc: Balbir Singh Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Signed-off-by: Andrew Morton Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f07c94cd3cc203dcae79311b51bcd4bb4cd04c55 Author: Zi Yan Date: Thu Sep 3 14:26:47 2026 -0400 mm/huge_memory: change folio_split_supported() to folio_check_splittable() [ Upstream commit bdd0d69a32c2aa6437d23e35acc705758b835a75 ] Patch series "Improve folio split related functions", v4. This patchset improves several folio split related functions to avoid future misuse. The changes are: 1. Consolidated folio splittable checks by moving truncated folio check, huge zero folio check, and writeback folio check into folio_split_supported(). Changed the function return type. Renamed it to folio_check_splittable() for clarification. 2. Replaced can_split_folio() with open coded folio_expected_ref_count() and folio_ref_count() and introduced folio_cache_ref_count(). 3. Changed min_order_for_split() to always return an order. 4. Fixed folio split stats counting. Motivation ========== This is based on Wei's observation[1] and solves several potential issues: 1. Dereferencing NULL folio->mapping in try_folio_split_to_order() if it is called on truncated folios. 2. Not handling of negative return value of min_order_for_split() in mm/memory-failure.c There is no bug in the current code. This patch (of 4): folio_split_supported() used in try_folio_split_to_order() requires folio->mapping to be non NULL, but current try_folio_split_to_order() does not check it. There is no issue in the current code, since try_folio_split_to_order() is only used in truncate_inode_partial_folio(), where folio->mapping is not NULL. To prevent future misuse, move folio->mapping NULL check (i.e., folio is truncated) into folio_split_supported(). Since folio->mapping NULL check returns -EBUSY and folio_split_supported() == false means -EINVAL, change folio_split_supported() return type from bool to int and return error numbers accordingly. Rename folio_split_supported() to folio_check_splittable() to match the return type change. While at it, move is_huge_zero_folio() check and folio_test_writeback() check into folio_check_splittable() and add kernel-doc. Remove all warnings inside folio_check_splittable() and give warnings in __folio_split() instead, so that bool warns parameter can be removed. Link: https://lkml.kernel.org/r/20251126210618.1971206-1-ziy@nvidia.com Link: https://lkml.kernel.org/r/20251126210618.1971206-2-ziy@nvidia.com Signed-off-by: Zi Yan Reviewed-by: Wei Yang Acked-by: Balbir Singh Acked-by: David Hildenbrand (Red Hat) Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Signed-off-by: Andrew Morton Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 305f9b6eb8a06a9c0663f69fae65e0c51227dd4a Author: Muchun Song Date: Thu Sep 3 14:26:46 2026 -0400 mm: thp: use folio_batch to handle THP splitting in deferred_split_scan() [ Upstream commit 776bde7caf80f6af72b087cafe7d9f607b14716d ] The maintenance of the folio->_deferred_list is intricate because it's reused in a local list. Here are some peculiarities: 1) When a folio is removed from its split queue and added to a local on-stack list in deferred_split_scan(), the ->split_queue_len isn't updated, leading to an inconsistency between it and the actual number of folios in the split queue. 2) When the folio is split via split_folio() later, it's removed from the local list while holding the split queue lock. At this time, the lock is not needed as it is not protecting anything. 3) To handle the race condition with a third-party freeing or migrating the preceding folio, we must ensure there's always one safe (with raised refcount) folio before by delaying its folio_put(). More details can be found in commit e66f3185fa04 ("mm/thp: fix deferred split queue not partially_mapped"). It's rather tricky. We can use the folio_batch infrastructure to handle this clearly. In this case, ->split_queue_len will be consistent with the real number of folios in the split queue. If list_empty(&folio->_deferred_list) returns false, it's clear the folio must be in its split queue (not in a local list anymore). In the future, we will reparent LRU folios during memcg offline to eliminate dying memory cgroups, which requires reparenting the split queue to its parent first. So this patch prepares for using folio_split_queue_lock_irqsave() as the memcg may change then. Link: https://lkml.kernel.org/r/59cb6b6fb5ffcff9d23b81890b252960139ad8e7.1762762324.git.zhengqi.arch@bytedance.com Signed-off-by: Muchun Song Signed-off-by: Qi Zheng Reviewed-by: Zi Yan Acked-by: David Hildenbrand Acked-by: Shakeel Butt Reviewed-by: Wei Yang Reviewed-by: Harry Yoo Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Hugh Dickins Cc: Johannes Weiner Cc: Lance Yang Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Nico Pache Cc: Roman Gushchin Cc: Ryan Roberts Signed-off-by: Andrew Morton Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0a4a3d7202640d1d0e4dc696322d69a0a3800670 Author: Muchun Song Date: Thu Sep 3 14:26:45 2026 -0400 mm: thp: introduce folio_split_queue_lock and its variants [ Upstream commit ad7c7f4576a5977b4ec4ac5dd090ab3f81ca7c6f ] In future memcg removal, the binding between a folio and a memcg may change, making the split lock within the memcg unstable when held. A new approach is required to reparent the split queue to its parent. This patch starts introducing a unified way to acquire the split lock for future work. It's a code-only refactoring with no functional changes. Link: https://lkml.kernel.org/r/a31a90bcac04dc754f775e87ae3205be3170b571.1762762324.git.zhengqi.arch@bytedance.com Signed-off-by: Muchun Song Signed-off-by: Qi Zheng Acked-by: Johannes Weiner Reviewed-by: Zi Yan Acked-by: Shakeel Butt Acked-by: David Hildenbrand Reviewed-by: Harry Yoo Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Hugh Dickins Cc: Lance Yang Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Nico Pache Cc: Roman Gushchin Cc: Ryan Roberts Cc: Wei Yang Signed-off-by: Andrew Morton Stable-dep-of: c299a2285d9d ("mm/huge_memory: use folio's memcg inside __folio_split()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d913a85cc5f7abe7d41ce37d877f7b2cd6e6ac67 Author: SJ Park Date: Fri Jul 17 17:14:35 2026 -0700 mm/damon/core: initialize damos->last_applied commit af5f76aeb9c9aa9c77d5e1d94e0ee4618c805239 upstream. Patch series "mm/damon: fix uninitialized DAMOS field and kunit exec expectation bugs". Fix a few Sashiko-found unurgent bugs. Patch 1 fixes use of uninitialized damos->last_applied field. Patches 2-7 fix DAMON kunit tests that do invalid memory access under test failures. The bugs are better to be fixed and eventually merged into stable@ kernel. That said, the fixes are arguably not urgent. Patch 1 only introduces negligible DAMOS efficiency degradation in occasional cases. Kunit fixes could introduce quite bad consequences but those are test code that affect only test run setups. This patch (of 7): Multiple DAMON regions could exist across a folio. If they fulfill the condition to apply a DAMOS scheme, the scheme could be applied multiple times to the folio. To avoid this, each DAMOS scheme stores the folio that the scheme was applied to last time in the damos->last_applied field and skips repeatedly applying the same scheme to the same folio. The field is being used without initialization, though. Hence, the mechanism could wrongly skip applying a scheme to a folio at the very first time of DAMOS run. The user impact is trivial. DAMON might unexpectedly skip applying DAMOS action for one folio for the first time per scheme. In the DAMON's best-effort world, this is never a real problem. No critical consequences such as kernel panic or memory corruption happen. It is a clear bug, though, and the fix is straightforward. Fix the issue by initializing the field in DAMOS scheme creation function, damon_new_scheme(). The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-1-sj@kernel.org Link: https://lore.kernel.org/20260718001442.87129-2-sj@kernel.org Link: https://lore.kernel.org/20260714055436.120034-1-sj@kernel.org [1] Fixes: 94ba17adaba0 ("mm/damon: avoid applying DAMOS action to same entity multiple times") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.15.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 05bdb7b867bef9d931d5e9ca6166c75d30d835df Author: SJ Park Date: Fri Jul 17 17:14:38 2026 -0700 mm/damon/core-kunit: handle region split failure in filter_out() commit 3423fe70395210e2f0cd795270292f6a27cd57b5 upstream. damos_test_filter_out() test checks if damos_filter_match() of an address filter splits the region as expected under a given condition. But, the test continued regardless of the split successes. As a result, the later part of the test could dereference invalid pointers that returned from damon_next_region(). Further, it could corrupt memory from damon_destroy_region(). The consequent user impact (memory corruption) is quite bad. The realistic user impact would be limited, though. It would affect only test run setups. Fix it by exiting early for the number of regions test failure. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-5-sj@kernel.org Link: https://lore.kernel.org/20260714142352.100478-1-sj@kernel.org [1] Fixes: 26713c890875 ("mm/damon/core-test: add a unit test for __damos_filter_out()") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.6.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7d4ecfb507f338de5b9c4b54a73f02a00e6a3557 Author: SJ Park Date: Tue Jul 14 20:10:00 2026 -0700 mm/damon/sysfs: read addr_unit only once in damon_sysfs_apply_inputs() commit ab4d9358e32316fa39b5f1f5360292135978c3d9 upstream. damon_sysfs_apply_inputs() reads addr_unit twice. It could race with addr_unit_store(). As a result, the min_region_sz could wrongly be set up. Read it once. The user impact is trivial. Sane users ain't update the parameter in parallel. Even if it happens, the DAMON core layer handles the wrong min_region_sz (!is_power_of_2()). Even if somehow the race ended up making a min_region_sz that is different from the user's intention but still valid, only monitoring itself runs differently than expected. No critical consequences like kernel panic or memory corruption happen. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-6-sj@kernel.org Link: https://lore.kernel.org/20260714142950.100711-1-sj@kernel.org [1] Fixes: 540a2aebc657 ("mm/damon/sysfs: implement addr_unit file under context dir") Signed-off-by: SJ Park Cc: # 6.18.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit cd6d7f45abc825002343801f6b621dc254e07ada Author: SJ Park Date: Sun Jul 12 09:54:30 2026 -0700 mm/damon/core: skip aging from repeated aggressive merging commit 0250dbe08c730d003ef9f484da56ae09a1ea0c4c upstream. The number of DAMON regions could temporarily exceed the user-defined maximum number of regions limit for corner cases. For example, users could lower the limit via runtime parameters update. For such a case, kdamond_merge_regions() repeats merging regions in the case doubling the merge threshold. The repeated merge operation could update the age of regions multiple times. This corrupts the monitoring results. Fix the issue by asking the merge operation to skip aging for the corner case. The user impact is degradation of the monitoring quality. The impact should be mild, since the degradation is only temporal, and it is not common to happen in realistic setups. The issue was discovered [1,2] by Sashiko. Link: https://lore.kernel.org/20260712165432.87609-1-sj@kernel.org Link: https://lore.kernel.org/20260621203548.10718-1-sj@kernel.org [1] Link: https://lore.kernel.org/20260709145425.96247-1-sj@kernel.org [2] Fixes: 310d6c15e910 ("mm/damon/core: merge regions aggressively when max_nr_regions is unmet") Signed-off-by: SJ Park Cc: # 6.10 Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 081ee85b430968fffa449e7213b1bb09dba328a3 Author: SJ Park Date: Sun Jul 19 09:11:33 2026 -0700 mm/damon/ops-common: use nr_accesses moving sum for quota score commit 6c25083f7ae7e2660d766169e5b4d3e96010503f upstream. Since commit 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval"), DAMOS scheme can be applied at any time. At that time, nr_accesses may not be fully aggregated. But the quota prioritization score is calculated using the not fully aggregated count. As a result, the performance of DAMOS could be degraded. Fix by using damon_nr_accesses_mvsum() instead. The user impact of the issue is suboptimum DAMOS performance under certain setups. Nonetheless, the bug was there from the beginning of the setup availability. In other words, the suboptimum performance is the baseline of the setup and hence it didn't cause regression. Also the extent of the suboptimality was not big enough to be found from users and testers. Still, this is a clear bug that is better to be fixed, and can be easily fixed. Link: https://lore.kernel.org/20260719161136.90191-1-sj@kernel.org Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval") Signed-off-by: SJ Park Cc: # 6.7.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit cf94a9043f4a64bae68a14e4ab2e7e16cca03798 Author: SJ Park Date: Tue Jul 14 20:09:59 2026 -0700 mm/damon/paddr: drop last same folio access check reuse optimization commit f23f0aa62b2f32c2b12f95959fc4603ef81678b2 upstream. It can race when multiple kdamonds are being used. The problem from the race is doubtful, but the gain from the optimization is also doubtful. Simply drop the optimization in favor of code simplicity. The user impact is doubtfully trivial. After all, this kind of interference can happen only by intentional user setup. Even if it happens, it will be rare, and the consequence is degradation of the best-effort monitoring results. No critical consequences like kernel panic or memory corruption happen. The race was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-5-sj@kernel.org Link: https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org [1] Fixes: a28397beb55b ("mm/damon: implement primitives for physical address space monitoring") Signed-off-by: SJ Park Cc: # 5.16.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 11e4859ec0d8bbc0cfdd32e189187cfbc1ce4cbf Author: SJ Park Date: Tue Jul 14 20:09:58 2026 -0700 mm/damon/vaddr: drop last same folio access check optimization commit 831846078caa14b7d00b2ccca8b8fe522afe3204 upstream. The optimization can race when multiple kdamonds are running. Meanwhile, the impact of the optimization is quite doubtful. Just remove it. The user impact of the issue should be quite trivial. After all, the race can happen only when the user intentionally setup DAMON in the way. Even if it happens, it would be rare and only degrade the best-effort monitoring results. No critical consequences like kernel panic or memory corruption happen. The race possibility was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-4-sj@kernel.org Link: https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org [1] Fixes: 3f49584b262c ("mm/damon: implement primitives for the virtual memory address spaces") Signed-off-by: SJ Park Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 4c7275444ac65692c6a9c9b3c3367c789f891978 Author: SJ Park Date: Tue Jul 14 20:09:57 2026 -0700 mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of() commit b640708929aa956235866bf7717d89018c661083 upstream. KUNIT_EXPECT_EQ() does not abort the execution of test code when the expectation is not met. But damon_test_merge_regions_of() code after its initial KUNIT_EXPECT_EQ() call assumes the expectation is met. It does a per-region test with a hard-coded number of regions that is correct only if the expectation was met. As a result, __nth_region_of() could return NULL, and the test code can dereference NULL pointers. Fix the issue by catching the expectation failure and skip the per-region tests. The user impact on realistic setups should be negligible, as it is a unit test. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-3-sj@kernel.org Link: https://lore.kernel.org/20260710144937.26981-1-sj@kernel.org [1] Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests") Signed-off-by: SJ Park Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 05dc22d5c4fac2469c0ea23c9bde36aa415cff9f Author: Robin Murphy Date: Wed Sep 9 07:48:02 2026 -0400 iommu/arm-smmu-v3: Add HAFT support for SVA [ Upstream commit f99d3b4bb095c4966cf58154077e8bb69ee4827f ] Since table access flags cannot be software-managed, if process pagetables are using HAFT then SVA must require the SMMU to support and enable it too, otherwise page aging is liable to get out of whack. For unbinding, we can't disable HAFT atomically with HA as might be desired, but luckily we can get away with just not disabling HA either. Cc: stable@vger.kernel.org Fixes: 62df5870ebf7 ("arm64: Enable ARCH_HAS_NONLEAF_PMD_YOUNG") Signed-off-by: Robin Murphy Reviewed-by: Jason Gunthorpe Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c660c017dec1fd7cd88e1103c5ae1aae6ce636bf Author: Fan Wu Date: Wed Sep 9 07:31:01 2026 -0400 power: supply: ab8500_fg: fix use-after-free on remove [ Upstream commit 75b1e88d34254f4fb7753345e21bfee47abddd7f ] ab8500_fg_remove() destroys the driver workqueue while the threaded interrupt handlers are still armed; they are devm-managed and freed only after ->remove() returns, so a handler that fires in that window queues work on the freed workqueue. Tear the workqueue down through devm instead, registering its cleanup after the power supply and before the interrupt requests. devm then frees the interrupts first, so the handlers can no longer queue work, before disabling the delayed and plain work items and destroying the workqueue. Disabling the items, rather than cancelling them, keeps them disabled so no producer (including the power-supply external_power_changed callback) can requeue them. Found by an in-house static analysis tool. Fixes: 13151631b5bd ("ab8500-fg: A8500 fuel gauge driver") Cc: stable@vger.kernel.org # v6.10+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260802020316.417757-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 68916940332d17ee4e36bc0903576da994df1330 Author: Pan Chuang Date: Wed Sep 9 07:31:00 2026 -0400 power: supply: ab8500_fg: Remove redundant dev_err()/dev_err_probe() [ Upstream commit aa5f4decedfb4fc5cd0fe49ab256ad4304d192e4 ] The devm_request_threaded_irq() and devm_request_irq() now automatically log detailed error messages on failure. This eliminates the need for driver-specific dev_err() and dev_err_probe() calls that previously printed generic messages. Signed-off-by: Pan Chuang Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260709033428.362970-7-panchuang@vivo.com Signed-off-by: Sebastian Reichel Stable-dep-of: 75b1e88d3425 ("power: supply: ab8500_fg: fix use-after-free on remove") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 62fb3124bf7405094264302b6c3a5d2b3988ae9a Author: Song Hu Date: Tue Jul 14 07:01:13 2026 -0700 Docs/ABI/damon: fix typo in intervals_goal sysfs path commit 1b492fc82368399123413c937f13da6ed312ee4d upstream. Patch series "Docs/ABI/damon: sysfs ABI document fixes and additions", v2. This series fixes typos and fills in missing entries in the DAMON sysfs ABI document (Documentation/ABI/testing/sysfs-kernel-mm-damon). Patch 1 fixes a path typo, "intrvals_goal" -> "intervals_goal", in four What: entries; the documented path points to a non-existent directory, so it is Cc'ed to stable. Patch 2 fixes two further typos ("WDate:", "manimum"). Patches 3 and 4 add ABI entries that exist in the kernel and are already described in usage.rst but are missing from the canonical ABI document: the 'update_tuned_intervals' state command (patch 3) and the 'tried_regions//probes/

/hits' file (patch 4). This patch (of 4): The ABI document spells the DAMON sysfs directory as "intrvals_goal" (missing 'e') in four What: entries, but the kernel creates it as "intervals_goal" (mm/damon/sysfs.c). Following the documented path therefore yields a non-existent directory. Link: https://lore.kernel.org/20260714140117.94147-1-sj@kernel.org Link: https://lore.kernel.org/20260714140117.94147-2-sj@kernel.org Fixes: e2b23dc62369 ("Docs/ABI/damon: document intervals auto-tuning ABI") Signed-off-by: Song Hu Reviewed-by: SJ Park Signed-off-by: SJ Park Cc: David Hildenbrand Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Jonathan Corbet Cc: Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 1811bd8792ee10193b2d3d9ea7625d7ba7f5cc69 Author: Muchun Song Date: Thu Sep 3 12:59:14 2026 -0400 mm/hugetlb_vmemmap: fix __hugetlb_vmemmap_optimize_folios() [ Upstream commit 6e25c6a9c7eff141ecfc966ecdb7801db2a8810e ] __hugetlb_vmemmap_optimize_folios() uses incorrect arguments when handling bootmem HugeTLB folios. The section number passed to register_page_bootmem_memmap() is derived from the vmemmap virtual address of folio->page instead of the folio PFN, so the bootmem memmap metadata can be registered against the wrong section. The helper is also given HUGETLB_VMEMMAP_RESERVE_SIZE even though it expects a page count, not a size in bytes. In addition, the write-protect range is based on pages_per_huge_page(h), which does not cover the full HugeTLB vmemmap area and can leave part of the shared tail vmemmap mapping writable. Fix the section lookup to use folio_pfn(folio), use HUGETLB_VMEMMAP_RESERVE_PAGES when registering the reserved memmap pages, and use hugetlb_vmemmap_size(h) for the write-protect range. Link: https://lore.kernel.org/20260612035903.2468601-3-songmuchun@bytedance.com Fixes: 752fe17af693 ("mm/hugetlb: add pre-HVO framework") Signed-off-by: Muchun Song Acked-by: Oscar Salvador Reviewed-by: Frank van der Linden Cc: "Aneesh Kumar K.V" Cc: David Hildenbrand Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Mike Rapoport (Microsoft) Cc: Nicholas Piggin Cc: Oscar Salvador (SUSE) Cc: "Ritesh Harjani (IBM)" Cc: Usama Arif Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dba93b8cceb0048071389352fc29dcb0a7fe666f Author: Kiryl Shutsemau Date: Thu Sep 3 12:59:13 2026 -0400 hugetlb: remove VMEMMAP_SYNCHRONIZE_RCU [ Upstream commit 01b1d0ffb6f7f37f466033cf167959946309ed3d ] The VMEMMAP_SYNCHRONIZE_RCU flag triggered synchronize_rcu() calls to prevent a race between HVO remapping and page_ref_add_unless(). The race could occur when a speculative PFN walker tried to modify the refcount on a struct page that was in the process of being remapped to a fake head. With fake heads eliminated, page_ref_add_unless() no longer needs RCU protection. Remove the flag and synchronize_rcu() calls. Link: https://lkml.kernel.org/r/20260227194302.274384-15-kas@kernel.org Signed-off-by: Kiryl Shutsemau Reviewed-by: Muchun Song Reviewed-by: David Hildenbrand (Arm) Cc: Albert Ou Cc: Alexandre Ghiti Cc: Baoquan He Cc: Christoph Lameter Cc: David Rientjes Cc: Frank van der Linden Cc: Harry Yoo Cc: Huacai Chen Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Oscar Salvador Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Roman Gushchin Cc: Usama Arif Cc: Vlastimil Babka Cc: WANG Xuerui Cc: Zi Yan Signed-off-by: Andrew Morton Stable-dep-of: 6e25c6a9c7ef ("mm/hugetlb_vmemmap: fix __hugetlb_vmemmap_optimize_folios()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e4d1300b457e2dc4cca89daa76231487faf9fd35 Author: Kiryl Shutsemau Date: Thu Sep 3 12:59:10 2026 -0400 mm: rework compound_head() for power-of-2 sizeof(struct page) [ Upstream commit 8c846c879e226c312c2c7a7bc1e323779903530f ] For tail pages, the kernel uses the 'compound_info' field to get to the head page. The bit 0 of the field indicates whether the page is a tail page, and if set, the remaining bits represent a pointer to the head page. For cases when size of struct page is power-of-2, change the encoding of compound_info to store a mask that can be applied to the virtual address of the tail page in order to access the head page. It is possible because struct page of the head page is naturally aligned with regards to order of the page. The significant impact of this modification is that all tail pages of the same order will now have identical 'compound_info', regardless of the compound page they are associated with. This paves the way for eliminating fake heads. The HugeTLB Vmemmap Optimization (HVO) creates fake heads and it is only applied when the sizeof(struct page) is power-of-2. Having identical tail pages allows the same page to be mapped into the vmemmap of all pages, maintaining memory savings without fake heads. If sizeof(struct page) is not power-of-2, there is no functional changes. Limit mask usage to HugeTLB vmemmap optimization (HVO) where it makes a difference. The approach with mask would work in the wider set of conditions, but it requires validating that struct pages are naturally aligned for all orders up to the MAX_FOLIO_ORDER, which can be tricky. Link: https://lkml.kernel.org/r/20260227194302.274384-8-kas@kernel.org Signed-off-by: Kiryl Shutsemau Reviewed-by: Muchun Song Reviewed-by: Zi Yan Acked-by: David Hildenbrand (Arm) Acked-by: Usama Arif Reviewed-by: Vlastimil Babka Cc: Albert Ou Cc: Alexandre Ghiti Cc: Baoquan He Cc: Christoph Lameter Cc: David Rientjes Cc: Frank van der Linden Cc: Harry Yoo Cc: Huacai Chen Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Oscar Salvador Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Roman Gushchin Cc: WANG Xuerui Signed-off-by: Andrew Morton [ stable: Drop the original compound_info conversion, which depends on preparatory interface changes absent from this tree and is not needed by the target fix. Move the stable-only HVO static-key increment ahead of the target's context without changing its behavior. ] For tail pages, the kernel uses the 'compound_info' field to get to the head page. The bit 0 of the field indicates whether the page is a tail page, and if set, the remaining bits represent a pointer to the head page. For cases when size of struct page is power-of-2, change the encoding of compound_info to store a mask that can be applied to the virtual address of the tail page in order to access the head page. It is possible because struct page of the head page is naturally aligned with regards to order of the page. The significant impact of this modification is that all tail pages of the same order will now have identical 'compound_info', regardless of the compound page they are associated with. This paves the way for eliminating fake heads. The HugeTLB Vmemmap Optimization (HVO) creates fake heads and it is only applied when the sizeof(struct page) is power-of-2. Having identical tail pages allows the same page to be mapped into the vmemmap of all pages, maintaining memory savings without fake heads. If sizeof(struct page) is not power-of-2, there is no functional changes. Limit mask usage to HugeTLB vmemmap optimization (HVO) where it makes a difference. The approach with mask would work in the wider set of conditions, but it requires validating that struct pages are naturally aligned for all orders up to the MAX_FOLIO_ORDER, which can be tricky. [ sashal: Reduced backport -- upstream 8c846c879e226 touches 3 file(s), this backport carries 1. Not backported here: include/linux/page-flags.h mm/slab.h mm/util.c This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 6e25c6a9c7ef ("mm/hugetlb_vmemmap: fix __hugetlb_vmemmap_optimize_folios()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5cec3e60e9f2d1324179df3aa91656f90095cf8f Author: Sergey Senozhatsky Date: Fri Sep 4 16:32:11 2026 -0400 zram: set default primary compressor in zram_destroy_comps() [ Upstream commit dde75313eed0b014c437f48dd75c0308b592cbf9 ] Patch series "zram: fix zram issues reported by sashiko". Sashiko drove by and reported [1] a couple of zram issues: a possible BUG_ON() in zlib code due to missing winbits range validation and one possible NULL-ptr dereference in zcomp. Both are low risk yet still worth fixing. This patch (of 2): zram_destroy_comps() resets all compressors and leaves them set to NULL, including the primary one, which is invalid device state, as now comp_algorithm_show()->strcmp() can be called on a NULL compressor. Set default primary compressor in zram_destroy_comps(). Link: https://lore.kernel.org/20260729045745.775973-2-senozhatsky@chromium.org Fixes: 486fd58af7ac ("zram: don't free statically defined names") Link: https://sashiko.dev/#/patchset/20260728092935.31139-1-haoqinhuang7@gmail.com [1] Signed-off-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Haoqin Huang Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fb0e9ecffae59d5479f26500972eea87160d32a9 Author: Yuwen Chen Date: Fri Sep 4 16:32:10 2026 -0400 zram: fix the issue that the write - back limits might overflow [ Upstream commit 04d31610a7221cca624646241b1f6b3edd6c99fd ] When the page size exceeds 4KB, if bd_wb_limit is set to a value that is not aligned with the page size, it will cause a numerical wrap-around issue for bd_wb_limit. For example, when the page size is set to 16KB and bd_wb_limit is set to 3, after one write-back operation, the value of bd_wb_limit will become -1. More seriously, since bd_wb_limit is an unsigned number, its value may become as large as 2^64 - 1. The core reason for this problem is that the unit of bd_wb_limit is 4KB. For example, when a write-back occurs on a system with a page size of 16KB, 4 needs to be subtracted from bd_wb_limit. This operation takes place in the zram_account_writeback_submit function. This patch fixes the issue by limiting bd_wb_limit to be an integer multiple of PAGE_SIZE / 4096. Link: https://lkml.kernel.org/r/tencent_5936CFE72BAB2BA76887BB69DCC1B5E67C05@qq.com Fixes: 1d69a3f8ae77 ("zram: idle writeback fixes and cleanup") Signed-off-by: Yuwen Chen Acked-by: Sergey Senozhatsky Cc: Brian Geffon Cc: Minchan Kim Cc: Richard Chang Signed-off-by: Andrew Morton Stable-dep-of: dde75313eed0 ("zram: set default primary compressor in zram_destroy_comps()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9a78de3befad667bf8ef7318dec319493549e2c6 Author: Sergey Senozhatsky Date: Fri Sep 4 16:32:09 2026 -0400 zram: read slot block idx under slot lock [ Upstream commit 1b1a4e4d6797a57fefa40569fc920ce573bbf75b ] Read slot's block id under slot-lock. We release the slot-lock for bdev read so, technically, slot still can get freed in the meantime, but at least we will read bdev block (page) that holds previous know slot data, not from slot->handle bdev block, which can be anything at that point. Link: https://lkml.kernel.org/r/20251122074029.3948921-7-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Cc: Brian Geffon Cc: Minchan Kim Cc: Richard Chang Cc: Yuwen Chen Signed-off-by: Andrew Morton Stable-dep-of: dde75313eed0 ("zram: set default primary compressor in zram_destroy_comps()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fcd467124b19fd355b3752c87f0ff7e99c04645e Author: Sergey Senozhatsky Date: Fri Sep 4 16:32:08 2026 -0400 zram: drop wb_limit_lock [ Upstream commit a4f506c569e1320c2db4a32955e47961fcf02b05 ] We don't need wb_limit_lock. Writeback limit setters take an exclusive write zram init_lock, while wb_limit modifications happen only from a single task and under zram read init_lock. No concurrent wb_limit modifications are possible (we permit only one post-processing task at a time). Add lockdep assertions to wb_limit mutators. While at it, fixup coding styles. Link: https://lkml.kernel.org/r/20251122074029.3948921-5-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Reviewed-by: Brian Geffon Cc: Minchan Kim Cc: Richard Chang Cc: Yuwen Chen Signed-off-by: Andrew Morton Stable-dep-of: dde75313eed0 ("zram: set default primary compressor in zram_destroy_comps()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d1743ec2dd2c8a3a701277fab82492c67a48f3d5 Author: Sergey Senozhatsky Date: Fri Sep 4 16:32:07 2026 -0400 zram: take write lock in wb limit store handlers [ Upstream commit 7c929664fddfdaaa4afe5ae833d0f3044709d95c ] Write device attrs handlers should take write zram init_lock. While at it, fixup coding styles. Link: https://lkml.kernel.org/r/20251122074029.3948921-4-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Reviewed-by: Brian Geffon Cc: Minchan Kim Cc: Richard Chang Cc: Yuwen Chen Signed-off-by: Andrew Morton Stable-dep-of: dde75313eed0 ("zram: set default primary compressor in zram_destroy_comps()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e7dbcb7a561a21e9a8f5b5fa90bb95aefbd0739d Author: Longlong Xia Date: Fri Sep 4 11:58:52 2026 -0400 zram: fix out-of-bounds access in read_block_state() [ Upstream commit 391f057f44a51cc9418da5cba78b014324174264 ] read_block_state() calculates nr_pages before taking dev_lock. If the device is reset and reinitialized with a smaller disksize before lock acquisition, nr_pages still describes the old table. The subsequent loop can then call slot_lock() past the end of the newly allocated table. Read disksize after acquiring dev_lock and checking that the device is initialized. The read lock then keeps the table and its bound stable for the duration of the scan. Link: https://lore.kernel.org/20260804065919.3970386-3-xialonglong2025@163.com Fixes: c0265342bff4 ("zram: introduce zram memory tracking") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Longlong Xia Reviewed-by: Sergey Senozhatsky Cc: Jens Axboe Cc: Minchan Kim Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 878edb39ecf481b76f3e51ab533ff2c4a8332b74 Author: Sergey Senozhatsky Date: Fri Sep 4 11:58:51 2026 -0400 zram: fixup read_block_state() [ Upstream commit 8b05d2d8af817c6a1e23032df51e7ad83030d543 ] ac_time is now in seconds, do not use ktime_to_timespec64() [akpm@linux-foundation.org: remove now-unused local `ts'] [akpm@linux-foundation.org: fix build] Link: https://lkml.kernel.org/r/20260115033031.3818977-1-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Reported-by: Chris Mason Closes: https://lkml.kernel.org/r/20260114124522.1326519-1-clm@meta.com Cc: Brian Geffon Cc: David Stevens Cc: Minchan Kim Cc: Richard Chang Signed-off-by: Andrew Morton [ Stable tree note: The ac_time conversion described above is not present here, so retain the ktime_t conversion and microsecond output. Move the timespec64 temporary into the scan loop instead, allowing the follow-up bounds fix to move nr_pages initialization under init_lock cleanly. ] Stable-dep-of: 391f057f44a5 ("zram: fix out-of-bounds access in read_block_state()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 83dd59ac1c3455c2c7d8ddb582d980a13199b9b3 Author: Chuck Lever Date: Mon Sep 7 18:59:27 2026 -0400 NFSD: Prevent client use-after-free during close_lru reaping [ Upstream commit 2330b788d732f43668b965b3105b37ceb276dfea ] An nfs4_openowner left on nn->close_lru after its final CLOSE keeps its last closed stateid in oo_last_closed_stid, holding only a raw pointer to its nfs4_client. The laundromat reaps timed-out entries, drops nn->client_lock, and calls nfs4_put_stid(), which dereferences the client through cl_lock. Nothing pins the client across that window, so a concurrent force_expire_client() can free it and nfs4_put_stid() reads freed memory. __destroy_client() hits the same race, walking clp->cl_openowners without cl_lock. Pin the client with cl_rpc_users before dropping client_lock, and skip clients already expiring. __destroy_client() then cleans up its own close_lru entries through release_last_closed_stateid(), so teardown no longer races the laundromat. Fixes: 217526e7ecc9 ("nfsd: protect the close_lru list and oo_last_closed_stid with client_lock") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-8-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cd489b03587378645fe0d20142a33f1ed60bac98 Author: Chuck Lever Date: Mon Sep 7 18:46:03 2026 -0400 NFSD: Prevent client use-after-free during blocked-lock reaping [ Upstream commit 9026932ac8be4d0ae01db47f23619a98cc57b671 ] A bare lock owner -- its only remaining reference a blocked lock on nn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but no reference keeping the client alive. When the per-net laundromat reaps such a lock, freeing the nbl drops the owner reference held through flc_owner, and the final nfs4_put_stateowner() takes the client's cl_lock. Because the laundromat detaches the nbl first, __destroy_client() no longer finds it, so a concurrent force_expire_client() can free the client before nfs4_put_stateowner() runs, dereferencing cl_lock in freed memory. Pin the client with cl_rpc_users before dropping nn->blocked_locks_lock, and skip clients already expiring, whose blocked locks __destroy_client() frees while holding an owner reference. Take nn->client_lock outside nn->blocked_locks_lock. Every other site holds nn->blocked_locks_lock as a leaf, acquiring no further lock, so placing nn->client_lock outside it cannot form a lock-order cycle. Fixes: 7919d0a27f1e ("nfsd: add a LRU list for blocked locks") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-7-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7f1abc50ce2537050a62acfabd07de14e49f63a9 Author: Chuck Lever Date: Mon Sep 7 18:46:02 2026 -0400 NFSD: Consolidate the revocation-path client unpin [ Upstream commit 3308cf3f11ed23c79f9f3f90b34bbbad3e3a6ea9 ] The client use-after-free fixes in the state-revocation paths left four open-coded copies of one idiom: drop a cl_rpc_users pin without renewing the client's lease, waking force_expire_client() when the last pin drops on a client it is tearing down. The accompanying "do not renew" rationale was documented at only one of the four sites. put_client_renew_locked() and put_client_renew() already carry the same pin-drop logic, but they renew a non-expired client's lease and so would resurrect the client whose state is being revoked. Factor the common pin-drop into __put_client_locked(), parameterized by whether to renew. The renew helpers pass true; the new put_client_no_renew_locked() and put_client_no_renew() pass false and carry the revocation paths, which must not revive the client they are tearing down. No change in behavior. Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-6-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Stable-dep-of: 9026932ac8be ("NFSD: Prevent client use-after-free during blocked-lock reaping") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3be89e8039a85fa3b6cd5f9dcc4c1459eb356c2d Author: Bryam Vargas Date: Mon Sep 7 11:14:49 2026 -0400 smb: client: reject a tree connect response whose byte count is too small [ Upstream commit 65deb18359341141d37dc86fc7853511be3c87a7 ] CIFSTCon() bounds its strnlen() over the byte area with the server's ByteCount minus two, which for ByteCount 0 or 1 goes negative as an int and converts to a huge size_t. The later subtraction wraps the __u16 bytes_left, and that is what bounds cifs_strndup_from_utf16(): a bound of up to 65535 against a ~16 KB cifs_req_poolp object runs off the end of the slab object, and the bytes reach userspace through tcon->nativeFileSystem in /proc/fs/cifs/DebugData. Reject a byte area too small for what the parser consumes. Two bytes is the least it can consume, and no conformant response carries fewer. The new trace point is the 129th smb_eio_trace entry, which __mode(byte) cannot represent, so the attribute goes with it. Fixes: cc20c031bb06 ("cifs: convert CIFSTCon to use new unicode helper functions") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b7e74bccf58879fdfb6eb787c26551a55f1690f6 Author: David Howells Date: Mon Sep 7 11:14:46 2026 -0400 cifs: Do some preparation prior to organising the function declarations [ Upstream commit 32a60868093aed5ccaa5e57f3b57f791f22ac133 ] Make some preparatory cleanups prior to running a script to organise the function declarations within the fs/smb/client/ headers. These include: (1) Remove "inline" from the dummy cifs_proc_init/clean() functions as they are in a .c file. (2) Move should_compress()'s kdoc comment to the .c file and remove kdoc markers from the comments. (3) Rename CIFS_ALLOW_INSECURE_LEGACY in #endif comments to have CONFIG_ on the front to allow the script to recognise it. (4) Don't let comments have bare words at the left margin as that confused the simplistic function detection code in the script. (5) Adjust some argument lists so that when and if the cleanup script is run they don't end up over 100 chars. (6) Fix a few comments to have missing '*' added or the "*/" moved to their own lines so that checkpatch doesn't moan over the cleanup script patch. (7) Move struct cifs_calc_sig_ctx to cifsglob.h. (8) Remove some __KERNEL__ conditionals. Signed-off-by: David Howells Reviewed-by: Paulo Alcantara (Red Hat) cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French Stable-dep-of: 65deb1835934 ("smb: client: reject a tree connect response whose byte count is too small") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 672cf86aa6aa0fb4012ce4c3b3498df42ad67a4e Author: Frank Sorenson Date: Mon Sep 7 07:47:27 2026 -0400 smb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2() [ Upstream commit 6343c1da561962688f203362d80d6a3bfa39fa1b ] coalesce_t2() computes data pointers directly from server-supplied DataOffset fields with no validation against buffer bounds: data_area_of_tgt = (char *)&pSMBt->hdr.Protocol + get_unaligned_le16(&pSMBt->t2_rsp.DataOffset); data_area_of_src = (char *)&pSMBs->hdr.Protocol + get_unaligned_le16(&pSMBs->t2_rsp.DataOffset); data_area_of_tgt += total_in_tgt; ... memcpy(data_area_of_tgt, data_area_of_src, total_in_src); A small DataOffset can push a pointer below the actual byte area, overwriting header fields; a large one can push it past the buffer end, causing out-of-bounds heap reads (source) or writes (target). The BCC overflow guard does not prevent this: BCC reflects how much data is present, while DataOffset controls where in the buffer it starts. The "validate target area" comment present since the function was first written in 2005 was a placeholder that was never implemented. Add lower- and upper-bound checks for both data pointers before the memcpy, and before any target header fields are modified. Fixes: e4eb295d38b5 ("[PATCH] cifs: Handle multiple response transact2 part 1 of 2") Cc: stable@vger.kernel.org Reported-by: Shen Yongchao Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9eed72e9534b10a6d9f8f5146feff3db53aebdba Author: Frank Sorenson Date: Mon Sep 7 07:47:14 2026 -0400 smb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2 [ Upstream commit 730d0bb19507b9e19c2fe5343109ac618e2fbce5 ] When a valid primary TRANSACT2 response has been received (mid->resp_buf set, mid->multiRsp true) and a subsequent secondary response causes cifs_check_trans2() to return false -- either because the SMB header is invalid (malformed != 0) or because check2ndT2() rejects the PDU -- handle_mid() overwrites mid->resp_buf with the new buffer (leaking the primary buffer) and, because mid->multiRsp is set, skips the server->smallbuf/bigbuf NULL-out. When the user thread frees mid->resp_buf, server->smallbuf or server->bigbuf is left dangling; the demux thread reuses it for the next packet, resulting in a use-after-free. Combine both early-exit conditions and, when mid->multiRsp is already set, abort the pending transaction inline: set multiEnd, call dequeue_mid() with malformed=true, and return true so handle_mid() exits without touching mid->resp_buf or the server buffer pointers. Fixes: 316cf94a910f ("CIFS: Move trans2 processing to ops struct") Cc: stable@vger.kernel.org # cifs_check_trans2() is in smb1ops.c on kernels < 7.0 Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara [ changed dequeue_mid(server, mid, true) to the older dequeue_mid(mid, true) API ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 31307a05ed827fcabfcf8941b33269bf1b1f8bd6 Author: David Howells Date: Mon Sep 7 07:47:13 2026 -0400 cifs: SMB1 split: Separate out SMB1 decls into smb1proto.h [ Upstream commit 645427b7a6c59e0074df29bf939aec2e9d6f2819 ] Separate out SMB1 declarations scriptedly into smb1proto.h. Script below: #!/usr/bin/perl -w use strict; unless (@ARGV) { die "Usage: $0 [ ...]\n"; } # Data tracking my %funcs = (); # Func name => { func prototype } my %headers = (); # Header filename => { header content } my %c_files = (); # C filename => { ordered func list, header pref } my %cmarkers = (); # C filename marker => { header filename it's in } # Parse state my $pathname = "-"; my $lineno = 0; sub error(@) { print STDERR $pathname, ":", $lineno, ": ", @_, "\n"; exit(1); } sub pad($) { # Reindent the function arguments to line the arguments up with the char # after the opening bracket on the func argument list my ($lines) = @_; return $lines if ($#{$lines} <= 0); my $has_empty = 0; for (my $i = 0; $i <= $#{$lines}; $i++) { $lines->[$i] =~ s/^[ \t]+//; $has_empty = 1 if ($lines->[$i] eq ""); } if ($has_empty) { my @clean = grep /.+/, @{$lines}; $lines = \@clean; } my $indlen = index($lines->[0], "("); return $lines if ($indlen < 0); my $indent = ""; $indlen++; $indent .= "\t" x ($indlen / 8); $indent .= " " x ($indlen % 8); my @padded = (); my $acc = ""; my $len = -$indlen; for (my $i = 0; $i <= $#{$lines}; $i++) { my $argument = $lines->[$i]; my $arglen = length($argument); my $last = ($i == $#{$lines} ? 1 : 0); if ($i == 0 || $i == 1) { $acc .= $argument; $acc .= ";" if ($last); $len += $arglen + $last; next; } if (!$acc) { $acc = $indent . $argument; $acc .= ";" if ($last); $len += $arglen + $last; next; } if ($indlen + $len + 1 + $arglen + $last > 79) { push @padded, $acc; $acc = $indent . $argument; $acc .= ";" if ($last); $len = $arglen + $last; next; } $acc .= " " . $argument; $acc .= ";" if ($last); $len += 1 + $arglen + $last; } push @padded, $acc if ($acc); return \@padded; } sub earliest(@) { my $ret = -1; foreach (@_) { $ret = $_ if ($ret < 0 || ($_ >= 0 && $_ < $ret)); } return $ret; } foreach my $file (@ARGV) { # Open the file for reading. next if $file =~ /trace[.]h$/; next if $file =~ /smbdirect[.][ch]$/; open my $fh, "<$file" or die "Could not open file '$file'"; $pathname = $file; $lineno = 0; my $filename; my @file_content = (); my @copy = (); my $state = 0; my $qual = ""; my $type = ""; my $funcname = ""; my @funcdef = (); my $bracket = 0; my $comment = 0; my $smb1 = 0; my $header = 0; my $inline = 0; my $file_marker = ""; my $config = ""; my $c_file = 0; $filename = $pathname; $filename =~ s!.*/!!; if ($file =~ m!.h$!) { my %new_h_file = ( path => $pathname, fname => $filename, content => [], ); $header = \%new_h_file; $headers{$filename} = \%new_h_file; } elsif ($file =~ m!.c$!) { my %new_c_file = ( path => $pathname, fname => $filename, funcs => [], ); $c_file = \%new_c_file; $c_files{$filename} = \%new_c_file; } else { warn("Ignoring unexpected file $file\n"); next; } $smb1 = 1 if ($file =~ m!/smb1ops.c|/cifssmb.c|/cifstransport.c!); foreach my $line (<$fh>) { $lineno++; chomp($line); push @copy, $line; if (!$line) { # Blank line push @file_content, @copy; @copy = (); next; } # Handle continuation or end of block comment. Look for C file # prototype insertion point markers. if ($comment) { if ($line =~ m![*]/!) { if ($comment == 2 && $file_marker) { $cmarkers{$file_marker} = $file_marker; push @copy, "#C_MARKER " . $file_marker; $file_marker = 0; } $comment = 0; } else { $comment++; if ($comment == 2 && $line =~ m! [*] ([a-z][a-z_0-9]*[.][c])$!) { $file_marker = $1; print("Found file marker ", $file_marker, " in ", $filename, "\n"); } } push @file_content, @copy; @copy = (); next; } # Check cpp directives, particularly looking for SMB1 bits if ($line =~ /^[#]/) { if ($header) { if ($line =~ /ifdef.*(CONFIG_[A-Z0-9_])/) { error("multiconfig") if $config; $config = $1; $smb1++ if ($config eq "CONFIG_CIFS_ALLOW_INSECURE_LEGACY"); } elsif ($line =~ /endif/) { $smb1-- if ($config eq "CONFIG_CIFS_ALLOW_INSECURE_LEGACY"); $config = ""; } } push @file_content, @copy; @copy = (); next; } # Exclude interference in finding func names and return types if ($line =~ /^[{]/ || $line =~ /##/ || $line =~ /^[_a-z0-9A-Z]+:$/ || # goto label $line =~ /^do [{]/ || $line =~ m!^//!) { push @file_content, @copy; @copy = (); next; } # Start of a block comment if ($line =~ m!^/[*]!) { $comment = 1 unless ($line =~ m![*]/!); push @file_content, @copy; @copy = (); next; } # End of a braced section, such as a function implementation if ($line =~ /^[}]/) { $type = ""; $qual = ""; $funcname = ""; @funcdef = (); push @file_content, @copy; @copy = (); next; } if ($line =~ /^typedef/) { $type = ""; $qual = ""; $funcname = ""; @funcdef = (); push @file_content, @copy; @copy = (); next; } # Extract function qualifiers. There may be multiple of these in more # or less any order. Some of them cause the func to be skipped (e.g. inline). if ($line =~ /^(static|extern|inline|noinline|noinline_for_stack|__always_inline)\W/ || $line =~ /^(static|extern|inline|noinline|noinline_for_stack|__always_inline)$/) { error("Unexpected qualifier '$1'") if ($state != 0); while ($line =~ /^(static|extern|inline|noinline|noinline_for_stack|__always_inline)\W/ || $line =~ /^(static|extern|inline|noinline|noinline_for_stack|__always_inline)$/) { $qual .= " " if ($qual); $qual .= $1; $inline = 1 if ($1 eq "inline"); $inline = 1 if ($1 eq "__always_inline"); $line = substr($line, length($1)); $line =~ s/^\s+//; } } if ($state == 0) { # Extract what we assume to be the return type if ($line =~ /^\s/) { push @file_content, @copy; @copy = (); next; } while ($line =~ /^(unsigned|signed|bool|char|short|int|long|void|const|volatile|(struct|union|enum)\s+[_a-zA-Z][_a-zA-Z0-9]*|[*]|__init|__exit|__le16|__le32|__le64|__be16|__be32|__be64)/) { $type .= " " if $type; $type .= $1; $line = substr($line, length($1)); $line =~ s/^\s+//; } if ($line =~ /^struct [{]/) { # Ignore structure definitions $type = ""; $qual = ""; $funcname = ""; @funcdef = (); push @file_content, @copy; @copy = (); next; } if (index($line, "=") >= 0) { # Ignore assignments $type = ""; $qual = ""; $funcname = ""; @funcdef = ""; push @file_content, @copy; @copy = (); next; } # Try and extract a function's type and name while ($line =~ /(^[_a-zA-Z][_a-zA-Z0-9]*)/) { my $name = $1; $line = substr($line, length($name)); next if ($line =~ /^[{]/); $line =~ s/^\s+//; my $ch = substr($line, 0, 1); last if ($ch eq "[" || $ch eq ";"); # Global variables if ($ch eq "(") { # Found the function name $state = 1; $line = substr($line, 1); $funcname = $name; my $tmp = $qual . $type . " " . $funcname . "("; $tmp =~ s/[*] /*/; push @funcdef, $tmp; $bracket = 1; last; } if ($type) { last if (index($line, ";") >= 0 && index($line, "(") == -1); error("Unexpected name '$name' after '$type'"); } $type .= " " if $type; $type .= $name; if ($line =~ /^(\s*[*]+)/) { my $ptr = $1; $type .= $ptr; $line = substr($line, length($ptr)); } } } # Try and extract a function's argument list my $from = 0; if ($state == 1) { while (1) { my $o = index($line, "(", $from); my $c = index($line, ")", $from); my $m = index($line, ",", $from); my $b = earliest($o, $c, $m); if ($b < 0) { push @funcdef, $line unless ($line eq ""); last; } my $ch = substr($line, $b, 1); # Push the arguments separately on to the list if ($ch eq ",") { push @funcdef, substr($line, 0, $b + 1); $line = substr($line, $b + 1); $from = 0; } elsif ($ch eq "(") { # Handle brackets in the argument list (e.g. function # pointers) $bracket++; $from = $b + 1; } elsif ($ch eq ")") { $bracket--; if ($bracket == 0) { push @funcdef, substr($line, 0, $b + 1); $line = substr($line, $b + 1); $state = 2; last; } $from = $b + 1; } } } if ($state == 2) { $inline = 1 if ($qual =~ /inline/); #print("QUAL $qual $type $funcname $inline ", $#funcdef, "\n"); if (!$header && $qual !~ /static/ && $funcname ne "__acquires" && $funcname ne "__releases" && $funcname ne "module_init" && $funcname ne "module_exit" && $funcname ne "module_param" && $funcname ne "module_param_call" && $funcname ne "PROC_FILE_DEFINE" && $funcname !~ /MODULE_/ && $funcname !~ /DEFINE_/) { # Okay, we appear to have a function implementation my $func; my $dup = 0; if (exists($funcs{$funcname})) { $func = $funcs{$funcname}; if (exists $func->{body}) { print("dup $funcname\n"); $dup = 1; } } else { my %new_func = ( name => $funcname, cond => "", legacy => 0, ); $func = \%new_func; $funcs{$funcname} = $func; $func->{body} = pad(\@funcdef); } $func->{body} = pad(\@funcdef); $func->{legacy} = 1 if $smb1; if ($funcname eq "cifs_inval_name_dfs_link_error") { $func->{cond} = "#ifdef CONFIG_CIFS_DFS_UPCALL"; } elsif ($funcname eq "cifs_listxattr") { $func->{cond} = "#ifdef CONFIG_CIFS_XATTR"; } push @{$c_file->{funcs}}, $func unless $dup; } elsif (!$header || $inline) { # Ignore inline function implementations and other weirdies push @file_content, @copy; } elsif ($header && !$inline) { push @file_content, "#FUNCPROTO " . $funcname; my $func; if (exists($funcs{$funcname})) { $func = $funcs{$funcname}; $func->{lineno} = $lineno; $func->{pathname} = $pathname; } else { my %new_func = ( name => $funcname, cond => "", lineno => $lineno, pathname => $pathname, legacy => 0, ); $func = \%new_func; $funcs{$funcname} = $func; } $func->{legacy} = 1 if $smb1; } @funcdef = (); $type = ""; $qual = ""; $funcname = ""; $inline = 0; $state = 0; @copy = (); } if ($line =~ /;/) { $type = ""; $qual = ""; $funcname = ""; @funcdef = (); $state = 0; push @file_content, @copy; @copy = (); } } close($fh); if ($header) { $header->{content} = \@file_content; } } sub write_header($) { my ($header) = @_; my $path = $header->{path}; my $legacy = 0; $legacy = 1 if ($path =~ m!smb1proto[.]h!); my @output = (); foreach my $line (@{$header->{content}}) { if ($line =~ "^[#]C_MARKER (.*)") { my $file_marker = $cmarkers{$1}; my $c_file = $c_files{$file_marker}; print("Found $line\n"); foreach my $func (@{$c_file->{funcs}}) { print("func ", $func->{name}, "\n"); push @output, @{$func->{body}}; } next; } elsif ($line =~ "^[#]FUNCPROTO ([_a-zA-Z0-9]+)") { my $funcname = $1; my $func = $funcs{$funcname}; if (!$func->{body}) { print($func->{pathname}, ":", $func->{lineno}, ": '", $funcname, "' dead prototype\n"); next; } if ($func->{legacy} == $legacy) { #push @output, $line; push @output, @{$func->{body}}; } } else { push @output, $line; } } open my $fh, ">$path" or die "Could not open file '$path' for writing"; foreach my $f (@output) { print($fh $f, "\n") or die $path; } close($fh) or die $path; } foreach my $h (keys(%headers)) { write_header($headers{$h}); } Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya Signed-off-by: Steve French [ sashal: Reduced backport -- upstream 645427b7a6c59 touches 3 file(s), this backport carries 3. Not backported here: fs/smb/client/cifsproto.h fs/smb/client/fscache.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 730d0bb19507 ("smb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6493277a52b2446fe318d2aa794bbcd8d6c5aed4 Author: David Howells Date: Mon Sep 7 07:47:12 2026 -0400 cifs: SMB1 split: Create smb1proto.h for SMB1 declarations [ Upstream commit 86c666506ea2c42649879eeac7f29e7bedef2f23 ] Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya Signed-off-by: Steve French Stable-dep-of: 730d0bb19507 ("smb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e7779c9f7e7f991777a06d4a52b77054b4a95776 Author: David Howells Date: Mon Sep 7 07:47:10 2026 -0400 cifs: Remove dead function prototypes [ Upstream commit 9146c7e53fa8e5024e0f61d67129afd45a179a3b ] Remove a bunch of dead function prototypes. Signed-off-by: David Howells cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Stable-dep-of: 730d0bb19507 ("smb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b10015807e4c628095d1d1d1c9307efc8cdd9e1b Author: Jiangshan Yi Date: Sun Sep 6 21:03:02 2026 -0400 smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions [ Upstream commit b8e5dc4f95e5484159b343903f302eb6d783f2e6 ] When a file has the setuid or setgid bit set and is written to, the VFS strips those bits and issues a setattr with ATTR_KILL_SUID/ATTR_KILL_SGID together with an ATTR_MODE carrying the already-cleared mode. Both cifs_setattr_unix() and cifs_setattr_nounix() unconditionally dropped ATTR_MODE in that case: /* skip mode change if it's just for clearing setuid/setgid */ if (attrs->ia_valid & (ATTR_KILL_SUID|ATTR_KILL_SGID)) attrs->ia_valid &= ~ATTR_MODE; This is fine for the default mount, where the mode is only emulated via the DOS read-only attribute and cannot represent the setuid/setgid bits anyway. However, with the "cifsacl" or "modefromsid" mount options the mode is stored on the server through an ACL (id_mode_to_cifs_acl()), with the SMB3.1.1 POSIX extensions the mode is sent to the server directly, and with the SMB1 Unix extensions (cifs_setattr_unix) the mode is sent via CIFSSMBUnixSetPathInfo(). In all those cases dropping ATTR_MODE means the cleared mode is never pushed to the server, so the setuid/setgid bit survives the write. This is a security issue: on local filesystems the setuid bit is stripped when a file is written, but over these cifs.ko mounts the bit persists on the server, potentially allowing an unexpected privilege escalation on subsequent execution. Fix this in two places: 1. cifs_setattr_nounix(): only take the "skip mode change" shortcut when the mode is emulated via the DOS read-only attribute (i.e. neither cifsacl/modefromsid nor the SMB3.1.1 POSIX extensions are in effect), so that the cleared mode is propagated to the server in the ACL / POSIX cases. 2. cifs_setattr_unix(): this function is only called when Unix extensions are in effect, so the mode is always stored on the server. Remove the shortcut entirely so that the cleared mode is always pushed. Fixes: d32c4f2626ac ("CIFS: ignore mode change if it's just for clearing setuid/setgid bits") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a3e8b98c823d51b230c9ff60e538d4dcb7616920 Author: David Howells Date: Sun Sep 6 21:03:01 2026 -0400 cifs: Scripted clean up fs/smb/client/smb2proto.h [ Upstream commit 1e009e3346db230787685a3989fd9c346fb412fb ] Remove externs, correct argument names and reformat declarations. Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya Signed-off-by: Steve French For the stable backport, drop the original smb2proto.h cleanup because the stable header has gained and changed declarations that make the scripted rewrite conflict, while the target does not touch or depend on the header. Instead, carry only behavior-preserving context preparation in inode.c: use the type-safe kmalloc_obj() spelling and the existing local sbflags snapshot, and brace the adjacent else-if. This allows both target hunks to apply cleanly without pre-applying the target's behavioral change. [ sashal: Reduced backport -- upstream 1e009e3346db touches 1 file(s), this backport carries 1. Not backported here: fs/smb/client/smb2proto.h This note is generated from the file lists only; see the resolution record for the reasoning. ] [ sashal: Reduced backport -- upstream 1e009e3346db2 touches 1 file(s), this backport carries 1. Not backported here: fs/smb/client/smb2proto.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: b8e5dc4f95e5 ("smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 72796c2ec6e90f0ec9a1bf7fe215650bee6ef710 Author: David Howells Date: Sun Sep 6 21:03:00 2026 -0400 cifs: Scripted clean up fs/smb/client/fs_context.h [ Upstream commit 047e504766a357ab751f76ccdec7a2e824e75e6d ] Remove externs, correct argument names and reformat declarations. Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya Signed-off-by: Steve French Stable-dep-of: b8e5dc4f95e5 ("smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4fb5a561866c495849d28d42e47f2e40c6d6f935 Author: David Howells Date: Sun Sep 6 21:02:59 2026 -0400 cifs: Scripted clean up fs/smb/client/fscache.h [ Upstream commit bc3de356aae666de5d8b5131545be87cf7754431 ] Remove externs, correct argument names and reformat declarations. Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya Signed-off-by: Steve French Stable-dep-of: b8e5dc4f95e5 ("smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1537c6c675104f00813100d9e8ea4e67cc0458cc Author: David Howells Date: Sun Sep 6 21:02:58 2026 -0400 cifs: Scripted clean up fs/smb/client/cifs_unicode.h [ Upstream commit 696ca7d95658224ba807813101d0d5714d1d8aa4 ] Remove externs, correct argument names and reformat declarations. Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya Signed-off-by: Steve French For the stable backport, drop the original header cleanup because the stable-only __KERNEL__ guard makes it conflict and the target does not touch or depend on those declarations. Instead, carry only a behavior-preserving local snapshot of mnt_cifs_flags in cifs_setattr_nounix(); the target patch refers to that snapshot in its new setuid/setgid condition. cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org [ sashal: Reduced backport -- upstream 696ca7d956582 touches 1 file(s), this backport carries 1. Not backported here: fs/smb/client/cifs_unicode.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: b8e5dc4f95e5 ("smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 549bd9868e9d77b07ea94870940d64342829c6ad Author: Chuck Lever Date: Sat Sep 5 22:13:30 2026 -0400 NFSD: Prevent client use-after-free during admin state revocation [ Upstream commit e270e5a0778e5bff852c8862ce9576ce70359393 ] A stateid holds only a bare pointer to its nfs4_client; a stateid reference does not pin it. The client survives only because __destroy_client() drains its stateids before free_client() runs. nfsd4_revoke_states() drops nn->client_lock across revoke_one_stid(), which dereferences the client to revoke a stateid and read clp->cl_minorversion. A teardown racing the dropped lock can free the client first. Pinning cl_rpc_users under client_lock blocks the DESTROY_CLIENTID and EXCHANGE_ID teardown, which refuses while cl_rpc_users is non-zero. force_expire_client() ignores it: once its wait for cl_rpc_users to reach zero has passed, a later pin goes unnoticed. Under client_lock, skip a client whose cl_time is already zero -- force_expire_client() clears it there before waiting -- otherwise pin cl_rpc_users before dropping the lock. The walk then either sees the expiry and skips, or pins in time for that wait to cover the revoke. Fixes: 1c13bf9f2e3c ("nfsd: allow lock state ids to be revoked and then freed") Cc: stable@vger.kernel.org Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-3-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever [ adapted revoke_one_stid() calls to the branch’s inline revocation logic ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3c0a53ee0b442348d8d2286d6960d3f07bb3a3d3 Author: Chuck Lever Date: Sat Sep 5 22:13:33 2026 -0400 NFSD: Prevent client use-after-free during delegation revoke [ Upstream commit 4683ca76b3b7e5808338491c6eb3c20e6b4894d5 ] A delegation stateid holds only a bare pointer to its owning nfs4_client and does not keep it alive. The client survives its stateids only because __destroy_client() drains cl_delegations and cl_revoked before free_client() runs. nfs4_laundromat() breaks that invariant: it unhashes an expired delegation from cl_delegations, drops deleg_lock, then revoke_delegation() relinks it onto cl_revoked under cl_lock. In that window the delegation is on neither list, so client_has_state() can report no remaining state. Every teardown path first requires cl_rpc_users to be zero, but the laundromat holds no such reference. A client whose recalled delegation has just timed out can therefore reach free_client() while revoke_delegation() is still about to dereference cl_lock, a use-after-free. Pin the client with cl_rpc_users across the revoke so teardown blocks until it completes, then reap the delegation from cl_revoked. A client already expiring reaps its own, so skip it and leave the delegation on del_recall_lru. Fixes: 3bd64a5ba171 ("nfsd4: implement SEQ4_STATUS_RECALLABLE_STATE_REVOKED") Cc: stable@vger.kernel.org Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-2-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 969b1fefb07d16a2a51669229893f2757c82174c Author: Jeff Layton Date: Sat Sep 5 22:13:32 2026 -0400 nfsd: convert global state_lock to per-net deleg_lock [ Upstream commit 8be12e0cf21110f1e0b7fd21711ff13fb75bee72 ] Replace the global state_lock spinlock with a per-nfsd_net deleg_lock. The state_lock was only used to protect delegation lifecycle operations (the del_recall_lru list and delegation hash/unhash), all of which are scoped to a single network namespace. Making the lock per-net removes a source of unnecessary contention between containers. Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Stable-dep-of: 4683ca76b3b7 ("NFSD: Prevent client use-after-free during delegation revoke") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6d6b9f6a75c3767250e9c23ace4e384ab8f7843e Author: Jeff Layton Date: Sat Sep 5 16:05:38 2026 -0400 nfsd: close shrinker/GC/fsnotify vs per-net shutdown race in filecache [ Upstream commit 40162cfea79b9510380decfdd1795b754dc9f972 ] The shrinker, GC worker, and fsnotify/lease callbacks can unhash an nfsd_file from the rhashtable and then call nfsd_file_dispose_list_delayed() to move it to the per-net dispose list. If nfsd_file_cache_shutdown_net() runs concurrently, its rhashtable walk misses the already-unhashed file, and its drain of the per-net dispose list can run before the file has been queued. The file then sits on the per-net list with no thread to drain it, leaking both the file and its associated state. The GC worker and shrinker already hold nfsd_gc_lock while walking the LRU, but in the original code they release it before calling nfsd_file_dispose_list_delayed(). The fsnotify/lease path (nfsd_file_close_inode) has no synchronization at all. Fix this by: 1. Widening nfsd_gc_lock in both nfsd_file_gc() and nfsd_file_lru_scan() to cover the nfsd_file_dispose_list_delayed() call. 2. Wrapping nfsd_file_close_inode() in nfsd_gc_lock so that all three callers of nfsd_file_dispose_list_delayed() hold the lock. 3. Adding a spin_lock/unlock(nfsd_gc_lock) barrier in nfsd_file_cache_shutdown_net() after the purge, so that any in-progress disposal has fully completed before the per-net list is drained. All operations inside the lock are non-sleeping (rhashtable lookups, atomic bit/refcount ops, list moves, svc_wake_up), so the spinlock is appropriate. Fixes: ffb402596147 ("nfsd: Don't leave work of closing files to a work queue") Cc: stable@vger.kernel.org # v6.15+ Signed-off-by: Jeff Layton Assisted-by: Claude:claude-opus-4-8 Link: https://patch.msgid.link/20260604-nfsd-testing-v4-1-3aeb1479c5bb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9031493ef7369d5c59c4bacc96f0c85965f09a98 Author: Jeff Layton Date: Sat Sep 5 16:05:31 2026 -0400 nfsd: fix UAF in async copy cancel and shutdown [ Upstream commit 62c0f6eaf050bb9284c1f9cac6ed1770092e6b95 ] An async copy could be freed or used after free while a teardown caller (OFFLOAD_CANCEL, nfsd4_shutdown_copy, nfsd4_cancel_copy_by_sb) raced the copy kthread: - find_async_copy() bumped copy->refcount but left the copy on clp->async_copies, so the reaper's cleanup_async_copy() could run release_copy_files() concurrently with a cancel/shutdown caller. Both put and NULL nf_src/nf_dst without a common lock, double-putting the nfsd_file and freeing it early. - nfsd4_do_async_copy() set NFSD4_COPY_F_STOPPED before its final uses of the copy (nfsd_update_cmtime_attr() on copy->nf_dst, nfsd4_send_cb_offload()). nfsd4_stop_copy() treats a set STOPPED bit as "kthread done, skip kthread_stop()", so a teardown caller ran release_copy_files() -- which puts and NULLs nf_dst -- while the kthread still dereferenced it (NULL/UAF). - copy->copy_task was never pinned. The one-shot kthread self-reaps on return, so kthread_stop()'s get_task_struct() could touch a freed task_struct. - co_cb is embedded in the copy, but nfsd4_send_cb_offload() held a reference only on the client, so a concurrent teardown could free the copy while the CB_OFFLOAD callback was in flight. Fix the teardown lifetime as a whole: - find_async_copy() unlinks the copy (clear cp_clp, list_del_init) under async_lock; the cancel, shutdown, and sb-cancel paths drop the list-membership reference via nfs4_put_copy() after nfsd4_stop_copy(). Drop the now-redundant list_del fixup from cleanup_async_copy(). - Because unlinking hides the copy from the reaper, its cleanup_async_copy() can no longer remove the copy's s2s_cp_stateids entry; the cancel/shutdown/sb-cancel paths now call nfs4_free_copy_state() themselves (while cp_clp is still valid) so the entry does not dangle at freed memory for the laundromat and manage_cpntf_state() to dereference. - Give the kthread its own reference, taken in nfsd4_copy() before wake_up_process() and dropped at the end of nfsd4_do_async_copy(); call wake_up_process() before list_add(). - Pin the task_struct with get_task_struct() in nfsd4_copy(), released in nfs4_put_copy(), so kthread_stop() is safe whenever the kthread exits. Set NFSD4_COPY_F_STOPPED only in nfsd4_stop_copy(), which now always kthread_stop()s before release_copy_files(); completion is still reported via NFSD4_COPY_F_COMPLETED, so nfsd4_has_active_async_copies() is unaffected. Each teardown caller removes the copy from clp->async_copies first, so kthread_stop() runs exactly once. - Take a copy reference in nfsd4_send_cb_offload(), dropped in nfsd4_cb_offload_release(). The kthread still holds its own reference there, so the refcount_inc() cannot race the final free. - Read cp_clp with smp_load_acquire() to pair with the unordered set_bit()/clear_bit() writers (Documentation/atomic_bitops.rst). Fixes: e0639dc5805a ("NFSD introduce async copy feature") Cc: stable@vger.kernel.org Fixes: ac0514f4d198 ("NFSD: Add a laundromat reaper for async copy state") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260710-nfsd-testing-v3-2-a0ff7db6aa3e@kernel.org Signed-off-by: Chuck Lever [ omitted superblock-wide copy cancellation and related client/error helpers absent in v6.18. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba0ee9e04b7a0356c28d5a2fe445db675d24e572 Author: Jeff Layton Date: Sat Sep 5 11:46:28 2026 -0400 nfsd: fix fcache_disposal UAF by inlining dispose state into nfsd_net [ Upstream commit bbf13732f74351d21c5e0e8dd9bd8e1c48dc35d4 ] nfsd_file_dispose_list_delayed() defers fput() to nfsd service threads via a per-net freeme queue, preventing the shrinker and GC worker from bearing the cost of closing files (see ffb402596147). However, the queue lives in a separately-allocated struct nfsd_fcache_disposal that is freed by nfsd_free_fcache_disposal_net() during per-net teardown. The global shrinker, laundrette, and fsnotify callbacks can still be inside nfsd_file_dispose_list_delayed() dereferencing that pointer, causing a use-after-free. Inline the spinlock and freeme list directly into struct nfsd_net (as fcache_dispose_lock and fcache_dispose_list), eliminating the separately allocated struct nfsd_fcache_disposal entirely. These fields now have the same lifetime as the net namespace itself, so there is no dangling pointer to chase. nfsd_file_cache_start_net() now just initializes the inline fields and cannot fail due to allocation. nfsd_file_cache_shutdown_net() drains the inline list directly instead of freeing a separate struct. The alloc/free helpers are removed. Fixes: 1463b38e7cf3 ("NFSD: simplify per-net file cache management") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260602-nfsd-testing-v2-7-e4ea62e3cd5c@kernel.org Signed-off-by: Chuck Lever [ adapted removal of kmalloc_obj() allocator to older kmalloc() implementation ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f9cec313efb2fd18d962aad738a4892bce806016 Author: Jeff Layton Date: Sat Sep 5 07:02:45 2026 -0400 nfsd: fix clock domain mismatch in clients_still_reclaiming() [ Upstream commit 09ea3eb9a518565f5bca386e81b993ed8825f5e8 ] clients_still_reclaiming() computes a deadline from nn->boot_time (CLOCK_REALTIME, ~1.7 billion) but compares it against ktime_get_boottime_seconds() (CLOCK_BOOTTIME, seconds since boot). The comparison is always false — it would take ~54 years of uptime for BOOTTIME to exceed the REALTIME-derived deadline. This means any client can hold the server in grace indefinitely by sending CLAIM_PREVIOUS OPEN requests, blocking all non-reclaim operations for all other clients. Add boot_time_bt (CLOCK_BOOTTIME) alongside the existing boot_time and use it for the deadline computation. boot_time (CLOCK_REALTIME) is preserved for its cl_boot clientid-nonce role. Fixes: 20b7d86f29d3 ("nfsd: use boottime for lease expiry calculation") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-12-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever [ preserved the branch’s boolean fields instead of the upstream flags bitmap ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 03c512f22d3fbe7a3767d6df5e3d88b8e7c105e5 Author: Jeff Layton Date: Tue Jun 2 12:23:17 2026 -0400 nfsd: widen nfsd_genl_rqstp address fields to sockaddr_storage commit a99d720ed2a5258564e5e9d5f39f3184a030d354 upstream. struct nfsd_genl_rqstp declares rq_daddr and rq_saddr as plain "struct sockaddr" (16 bytes). When an IPv6 NFS client is connected, nfsd_genl_rpc_status_compose_msg() casts these fields to "struct sockaddr_in6 *" (28 bytes) and reads sin6_addr at offset 8..24, which extends 8 bytes past the end of the 16-byte sockaddr field into the adjacent rq_flags member. The 16-byte nla_put_in6_addr then ships 8 bytes of truncated IPv6 address followed by 8 bytes of rq_flags to userspace via the NFSD_A_RPC_STATUS_SADDR6/DADDR6 netlink attributes. This is reachable by any unprivileged process in the network namespace because NFSD_CMD_RPC_STATUS_GET uses GENL_CMD_CAP_DUMP without GENL_ADMIN_PERM. Fix by widening rq_daddr and rq_saddr to struct sockaddr_storage so the IPv6 casts operate within bounds, copying sizeof(struct sockaddr_storage) bytes in the memcpy calls so the full address is captured, and zero-initializing the genl_rqstp stack variable to prevent leaking uninitialized tail bytes through netlink. Fixes: bd9d6a3efa97 ("NFSD: add rpc_status netlink support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260602-nfsd-testing-v2-5-e4ea62e3cd5c@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ccc069d5c47cd727717ac910e10783d5585d0d8e Author: Jeff Layton Date: Wed Mar 25 10:40:22 2026 -0400 nfsd: move struct nfsd_genl_rqstp to nfsctl.c commit 1ed3df33bdbda5fd639571afe9c7cd282ff82cd9 upstream. It's not used outside of that file. Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Stable-dep-of: a99d720ed2a5 ("nfsd: widen nfsd_genl_rqstp address fields to sockaddr_storage") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 430ed49a16cf9ca249d0fb51490582090bc4848b Author: Jeff Layton Date: Thu Jun 11 16:00:48 2026 -0400 nfsd: check nfsd4_acl_to_attr() return value in nfsd4_create() commit 2c7912732184773dbd371a411da87af1cc080b86 upstream. nfsd4_create() stores the return value of nfsd4_acl_to_attr() in status, but the switch(create->cr_type) block unconditionally overwrites it in every branch. ACL translation errors are silently discarded, and the CREATE proceeds without the requested ACL. Add an early exit check after nfsd4_acl_to_attr(), matching the pattern already used in nfsd4_setattr(). Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton [ cel: prefer NFS4ERR_BADTYPE over NFS4ERR_ATTRNOTSUPP ] Link: https://patch.msgid.link/20260611-nfsd-testing-v2-5-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever [ retained unconditional ACL conversion because the older helper already handles null ACLs ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 380d138a6b086b4fa33013b46b0fb155faf98d88 Author: Jiayuan Chen Date: Sat Aug 15 15:03:36 2026 +0800 net: advertise TCP MSS from the configured MTU, not the learned PMTU commit 2640e64195948a601430d230c9864f5426574cde upstream. The MSS a host puts in its SYN tells the peer how big a segment it may send us. Right now we can shrink it with a PMTU we learned on our own send path, which is the wrong direction entirely. On asymmetric paths this bites - think DSR load balancers, where the request side goes through a smaller-MTU overlay. We learn a small PMTU going out, then advertise a small MSS, and the peer stays capped for the whole connection even though its path back to us is wide. MSS only shows up in the SYN and never grows back. On symmetric paths we lose nothing by dropping it either: the peer runs its own PMTU discovery and usually already knows the real path MTU. So work out the advertised MSS from the configured route or device MTU and ignore the learned PMTU. Our send side is unchanged, still clamped by tcp_current_mss(). Add ip_dst_mtu_configured()/ip6_dst_mtu_configured() and use them from the two default_advmss() paths. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 164a5e7ad531 ("ipv4: ipv4_default_advmss() should use route mtu") Cc: stable@vger.kernel.org Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260815070413.294559-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cfb44c6028e6f979720315e0772bbd0d4d33ed61 Author: Yong Wang Date: Mon Aug 31 20:20:57 2026 -0400 tcp: clamp route advmss to TCP_MIN_MSS [ Upstream commit 870a9e42ecc6fe1b8c25d87af043cb0d9c178fe1 ] tcp_select_initial_window() assumes that callers never pass an MSS smaller than 1, but route-derived advmss values can violate that assumption. A too-small explicit RTAX_ADVMSS is one way to get there, but it is not the only one. The same divide-by-zero can also be reached through the "default advmss" path when RTAX_ADVMSS is left at 0 and the effective advmss is later driven down by route MTU and min_adv_mss. Introduce a tcp_dst_advmss() helper that clamps route advmss to TCP_MIN_MSS before TCP consumes it, and use it in the TCP paths that derive advmss from dst metrics. This keeps the effective MSS from dropping to zero before tcp_select_initial_window() rounds the receive window. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Yong Wang Signed-off-by: Ren Wei Link: https://patch.msgid.link/251eaf8277fa7c66364c9815c5da01662d269181.1787074852.git.edragain@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ea44679bc7d218f5e27f609bf3a6ba97009df42b Author: Eric Dumazet Date: Mon Aug 31 20:20:56 2026 -0400 ipv4: use dst4_mtu() instead of dst_mtu() [ Upstream commit fe8570186f100b6cc499b2f7705946baf1388cde ] When we expect an IPv4 dst, use dst4_mtu() instead of dst_mtu() to save some code space. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260130210303.3888261-8-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 870a9e42ecc6 ("tcp: clamp route advmss to TCP_MIN_MSS") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a615a2c8c30629065edd53573d4a86d438f32589 Author: Eric Dumazet Date: Mon Aug 31 20:20:55 2026 -0400 ipv6: use dst6_mtu() instead of dst_mtu() [ Upstream commit b40f0130a23b6bab8b359e158a40af81f11f14be ] When we expect an IPv6 dst, use dst6_mtu() instead of dst_mtu() to save some code space. Due to current dst6_mtu() implementation, only convert users in IPv6 stack. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260130210303.3888261-7-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 870a9e42ecc6 ("tcp: clamp route advmss to TCP_MIN_MSS") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 920dacce8734db1de0a641cda961fc869ac456d8 Author: Eric Dumazet Date: Mon Aug 31 20:20:54 2026 -0400 inet: add dst4_mtu() and dst6_mtu() helpers [ Upstream commit 8776c4ef3ab22b95f55713f00a7a576e6402507d ] With CONFIG_MITIGATION_RETPOLINE=y dst_mtu() is a bit fat, because it is generic. Indeed, clang does not always inline it. Add dst4_mtu() and dst6_mtu() helpers for callers that expect either ipv4_mtu() or ip6_mtu() to be called. These helpers are always inlined. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260130210303.3888261-6-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 870a9e42ecc6 ("tcp: clamp route advmss to TCP_MIN_MSS") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b650560c5ee21b7dc74c46434350142bb08304ff Author: Eric Dumazet Date: Mon Aug 31 20:20:53 2026 -0400 ipv6: add some unlikely()/likely() clauses in ip6_output.c [ Upstream commit 2855e4925416c5900a9c6cece11f4a2e56bf6e63 ] 1) daddr is unlikely a multicast in ip6_finish_output2(). 2) ip6_finish_output_gso_slowpath_drop() should not be called often. 3) ip6_fragment() should not be called often. 4) opt is unlikely to be set. 5) ip6_xmit() and ip6_forward() mostly sends not too big packets. 6) Most __ip6_make_skb() calls are for UDP packets, not ICMPV6 ones. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260130210303.3888261-3-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 870a9e42ecc6 ("tcp: clamp route advmss to TCP_MIN_MSS") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a294168185fe8e5b4688e1f1763d078734e4a0a8 Author: Eric Dumazet Date: Mon Aug 31 20:20:52 2026 -0400 ipv6: pass proto by value to ipv6_push_nfrag_opts() and ipv6_push_frag_opts() [ Upstream commit 1bc46dd209667346c5aa56c351995e7c260696d0 ] With CONFIG_STACKPROTECTOR_STRONG=y, it is better to avoid passing a pointer to an automatic variable. Change these exported functions to return 'u8 proto' instead of void. - ipv6_push_nfrag_opts() - ipv6_push_frag_opts() For instance, replace ipv6_push_frag_opts(skb, opt, &proto); with: proto = ipv6_push_frag_opts(skb, opt, proto); Note that even after this change, ip6_xmit() has to use a stack canary because of @first_hop variable. Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260130210303.3888261-2-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 870a9e42ecc6 ("tcp: clamp route advmss to TCP_MIN_MSS") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 194d0fb0ea4720535ff3168c9d04c7632cec7071 Author: Xiang Mei Date: Mon Aug 31 18:20:04 2026 -0400 fuse: copy request headers via a stack buffer for io-uring [ Upstream commit fd10f40af314f07b6d6e028b1ca25c8b49903aab ] The fuse-io-uring transport copies req->in.h out to the ring in fuse_uring_copy_to_ring() and req->out.h back in fuse_uring_commit(). Both headers live inside the fuse_request slab object, whose cache (fuse_req_cachep) is created without a usercopy whitelist, so copying them directly to/from userspace trips CONFIG_HARDENED_USERCOPY and panics: usercopy: Kernel memory exposure attempt detected from SLUB object 'fuse_request' (offset 56, size 40)! kernel BUG at mm/usercopy.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:usercopy_abort (mm/usercopy.c:90) Call Trace: __check_heap_object (mm/slub.c:8268) __check_object_size (mm/usercopy.c:197 mm/usercopy.c:258 mm/usercopy.c:223) copy_header_to_ring (fs/fuse/dev_uring.c:618) fuse_uring_prepare_send (fs/fuse/dev_uring.c:776 fs/fuse/dev_uring.c:785) fuse_uring_send_in_task (fs/fuse/dev_uring.c:1306) tctx_task_work_run (io_uring/tw.c:96) task_work_run (kernel/task_work.c:233) io_run_task_work (io_uring/tw.h:84) io_cqring_wait (io_uring/wait.c:278) __do_sys_io_uring_enter (io_uring/io_uring.c:2685) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Bounce both headers through an on-stack copy so the usercopy touches stack memory, not the slab object. Fixes: c090c8abae4b ("fuse: Add io-uring sqe commit and fetch support") Cc: stable@vger.kernel.org Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Reviewed-by: Bernd Schubert Reviewed-by: Joanne Koong Signed-off-by: Miklos Szeredi [ merged declaration of `in_header`/`out_header` alongside pre-existing `ring`/`fc` locals introduced by prior refactors ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b96b0d2c25d141103a1b78c574dbf6b88f91ddbd Author: Joanne Koong Date: Mon Aug 31 18:20:03 2026 -0400 fuse-uring: use named constants for io-uring iovec indices [ Upstream commit 8bbb2ad1f687633a991839bd3efae04ccfb29e19 ] Replace magic indices 0 and 1 for the iovec array with named constants FUSE_URING_IOV_HEADERS and FUSE_URING_IOV_PAYLOAD. This makes the usages self-documenting and prepares for buffer ring support which will also reference these iovec slots by index. Reviewed-by: Bernd Schubert Reviewed-by: Jeff Layton Reviewed-by: Baokun Li Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Stable-dep-of: fd10f40af314 ("fuse: copy request headers via a stack buffer for io-uring") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f12ebb0a3ed7d45521d1535dfc5d272cd8c65618 Author: Joanne Koong Date: Mon Aug 31 18:20:02 2026 -0400 fuse-uring: refactor setting up copy state for payload copying [ Upstream commit c0f9203732fc70de8d20697270bfe405481eac14 ] Add a new helper function setup_fuse_copy_state() to contain the logic for setting up the copy state for payload copying. Reviewed-by: Bernd Schubert Reviewed-by: Jeff Layton Reviewed-by: Baokun Li Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Stable-dep-of: fd10f40af314 ("fuse: copy request headers via a stack buffer for io-uring") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 121fc8edf583226e02f351ea3d6ca3b94c3440e3 Author: Joanne Koong Date: Mon Aug 31 18:20:01 2026 -0400 fuse-uring: use enum types for header copying [ Upstream commit b2bbd7dcd2433e29b7e9a726aaa9571a78fa8d5f ] Use enum types to identify which part of the header needs to be copied. This improves the interface and will simplify both kernel-space and user-space header addresses copying when buffer rings are added. Reviewed-by: Bernd Schubert Reviewed-by: Jeff Layton Reviewed-by: Baokun Li Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Stable-dep-of: fd10f40af314 ("fuse: copy request headers via a stack buffer for io-uring") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c46805193fbefe25d642ed69bc7b9807a0c2f846 Author: Joanne Koong Date: Mon Aug 31 18:20:00 2026 -0400 fuse-uring: refactor io-uring header copying from ring [ Upstream commit ba7d47897fd895533c19af436ca7fc4f6b171238 ] Move header copying from ring logic into a new copy_header_from_ring() function. This makes the copy_from_user() logic more clear and centralizes error handling / rate-limited logging. Reviewed-by: Bernd Schubert Reviewed-by: Jeff Layton Reviewed-by: Baokun Li Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Stable-dep-of: fd10f40af314 ("fuse: copy request headers via a stack buffer for io-uring") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6bb5347e9f8aa3c9bdd4785315a17b2d857feb69 Author: Joanne Koong Date: Mon Aug 31 18:19:59 2026 -0400 fuse-uring: refactor io-uring header copying to ring [ Upstream commit 6582f8a06698403dccf8a01b7eef176b2c6dd7ff ] Move header copying to ring logic into a new copy_header_to_ring() function. This makes the copy_to_user() logic more clear and centralizes error handling / rate-limited logging. Reviewed-by: Bernd Schubert Reviewed-by: Jeff Layton Reviewed-by: Baokun Li Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Stable-dep-of: fd10f40af314 ("fuse: copy request headers via a stack buffer for io-uring") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8974575898cd7a4c818088f102b2e7a0286d3302 Author: Joanne Koong Date: Thu Jul 16 11:31:42 2026 -0700 fuse: fix missing barrier when checking io-uring readiness commit edb310bc27f0ad83e7fd558a3caf1a94ca511654 upstream. fuse_block_alloc() reads fch->initialized and then fch->io_uring. fch->io_uring is set before fch->initialized, ordered by the smp_wmb() in fuse_chan_set_intialized(), but fuse_block_alloc() has no matching read barrier between the two loads. This may lead a CPU to observe fch->initialized=1 but fch->io_uring=0, and skip the check that blocks request allocation until the io-uring queues are ready. This can reintroduce the lock-order inversion deadlock that commit 3393ff964e0f prevents. Add an smp_rmb() barrier to pair with the smp_wmb() in fuse_chan_set_initialized() to prevent this. Fixes: 3393ff964e0f ("fuse: block request allocation until io-uring init is complete") Cc: stable@vger.kernel.org Reviewed-by: Bernd Schubert Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi [ renamed `fch`/`struct fuse_chan` to `fc`/`struct fuse_conn` and `fuse_chan_set_initialized()` to `fuse_set_initialized()` in the comment ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f1c91222188be68df7e29429dfd52b36b11f4158 Author: Ali Tariq Date: Wed Sep 9 07:40:43 2026 -0400 PCI: starfive: Fix resource leaks on error paths in host_init() [ Upstream commit 22877a061f81c5d58041e384b3131684bec636b9 ] starfive_pcie_host_init() acquires the PHY, clocks/resets, and an optional regulator in sequence, but does not correctly unwind these resources when a later step fails. If starfive_pcie_clk_rst_init() fails after the PHY has already been successfully enabled, the function returns directly without disabling the PHY, leaking it and leaving it powered. If regulator_enable() fails for the optional vpcie3v3 regulator, the failure is only logged; the function falls through and returns success, leaving the driver believing the regulator is enabled while continuing to configure PCIe hardware that may be unpowered. This also leaves the clocks and PHY enabled with nothing to clean them up. Disable the PHY on the clk/reset failure path, and disable the clocks/resets and PHY, then return the error, if the regulator fails to enable. Build-tested and boot-tested on StarFive VisionFive 2 v1.2A Fixes: 05a75df4182e ("PCI: starfive: Use regulator APIs to control the 3v3 power supply of PCIe slots") Fixes: 39b91eb40c6a ("PCI: starfive: Add JH7110 PCIe controller") Signed-off-by: Ali Tariq Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260716102053.185276-1-alitariq45892@gmail.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e5c1d10003b4de27485ed0b11b01c4c471cd2a8d Author: Hal Feng Date: Wed Sep 9 07:40:42 2026 -0400 PCI: starfive: Use regulator APIs to control the 3v3 power supply of PCIe slots [ Upstream commit 05a75df4182e301a1b0059606f77b65c74deaa9b ] The driver has been using the "enable-gpios" property to control the 3v3 power supply of PCIe slots. But it is not documented in the dt-bindings and also using GPIO APIs is not a standard way to control PCIe slot power, so use the documented "vpcie3v3-supply" property and regulator APIs to control the slot supply. This change will break the DTs which used "enable-gpio" or "enable-gpios" property under the controller node. Since these properties were not defined in the bindings, it is safe to switch to "vpcie3v3-supply". Any out-of-tree DTS impacted by this change should migrate to "vpcie3v3-supply" instead. Signed-off-by: Hal Feng [mani: reworded description] Signed-off-by: Manivannan Sadhasivam Acked-by: Kevin Xie Link: https://patch.msgid.link/20251218102149.28062-1-hal.feng@starfivetech.com Stable-dep-of: 22877a061f81 ("PCI: starfive: Fix resource leaks on error paths in host_init()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0d72e78c9d38d5377a059a4837f82b65b91cdcf6 Author: Oscar Ou Date: Wed Sep 9 06:34:31 2026 -0400 lockd: fix swapped arguments in nlmsvc_match_ip() [ Upstream commit b9060689f49dc663e9a3d069c4a65ff63a836e66 ] When releasing locks by server IP address via /proc/fs/nfsd/unlock_ip, nlmsvc_unlock_all_by_ip() calls nlm_traverse_files() with the server sockaddr as the opaque @data argument: nlm_traverse_files(server_addr, nlmsvc_match_ip, NULL); The match callback is later invoked from nlm_traverse_locks() as: match(lockhost, host); where the first argument is the nlm_host that owns the lock, and the second argument is the @data that was originally passed down (here the server sockaddr). This is the convention every other match callback relies on (nlmsvc_mark_host(), nlmsvc_same_host(), nlmsvc_is_client()): arg1 is the real nlm_host, arg2 is the caller-supplied reference value. nlmsvc_match_ip() has had these two arguments reversed ever since the unlock-by-IP feature was introduced in commit 4373ea84c84d ("lockd: unlock lockd locks associated with a given server ip"): return rpc_cmp_addr(nlm_srcaddr(host), datap); Here @host is actually the server sockaddr, so nlm_srcaddr(host) dereferences a struct sockaddr as a struct nlm_host and reads garbage at the offset of h_srcaddr; meanwhile @datap is actually the lock owner's nlm_host but is compared as a sockaddr. As a result the comparison practically never matches and locks are not released for the requested IP. Swap the arguments so the lock owner's source address is compared against the requested server address: return rpc_cmp_addr(nlm_srcaddr(datap), (struct sockaddr *)host); Fixes: 4373ea84c84d ("lockd: unlock lockd locks associated with a given server ip") Cc: stable@vger.kernel.org Signed-off-by: Oscar Ou [ cel: fix the misleading typedef parameter names too ] Link: https://patch.msgid.link/20260617075738.1151797-1-oscarou@synology.com Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fcfcba8fe17dbf2c8805690b8cc25e32d81249a4 Author: Doruk Tan Ozturk Date: Wed Sep 9 06:11:43 2026 -0400 ocfs2: validate directory-index entry counts when reading metadata [ Upstream commit bc70726ddad53c7e9a9a85915bf2415b0d4f42f9 ] ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() check the ECC and signature of an indexed-directory block before it reaches higher-level callers, but neither validator bounds the ocfs2_dx_entry_list counts against the capacity of the block that holds them. ocfs2_dx_dir_search() then walks for (i = 0; i < le16_to_cpu(entry_list->de_num_used); i++) dx_entry = &entry_list->de_entries[i]; over de_num_used entries with no bounds check. entry_list is either dx_leaf->dl_list (from ocfs2_read_dx_leaf) or, for an inline root, dx_root->dr_entries. A crafted on-disk image can set de_num_used (and de_count, which is the __counted_by_le() bound of de_entries) to 0xffff and make the walk read far past the end of the 4KB metadata block, giving a slab out-of-bounds read reachable from any path lookup, stat() or open() on an indexed directory once the image is mounted. Commit 775c17386a6f ("ocfs2: validate dx_root extent list fields during block read") already bounds dr_list for the non-inline dx_root, but left the inline dr_entries path and the dx_leaf dl_list unchecked. Add the same read-time validation for both entry lists: de_count must equal the capacity of the block (ocfs2_dx_entries_per_leaf()/per_root()) and de_num_used must not exceed de_count, rejecting corrupted metadata with -EFSCORRUPTED before ocfs2_dx_dir_search() can walk an out-of-range entry array. de_count is always written as exactly the block capacity when a leaf or inline root is formatted, so the equality check does not reject any valid image. Found by 0sec automated security-research tooling (https://0sec.ai). Link: https://lore.kernel.org/20260713205625.92391-1-doruk@0sec.ai Fixes: 9b7895efac90 ("ocfs2: Add a name indexed b-tree to directory inodes") Fixes: 4ed8a6bb083b ("ocfs2: Store dir index records inline") Assisted-by: 0sec:claude-opus-4-8 Signed-off-by: Doruk Tan Ozturk Reviewed-by: Joseph Qi Cc: Joel Becker Cc: Kees Cook Cc: Mark Fasheh Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 625e00fd25ef55bd14ce5d60f43ce1640c5bdd4d Author: Joseph Qi Date: Wed Sep 9 06:11:42 2026 -0400 ocfs2: validate dx_root extent list fields during block read [ Upstream commit 775c17386a6fd695f999d4cda90e3931386570dd ] Patch series "ocfs2: consolidate extent list validation into block read callbacks". ocfs2 validates extent list fields (l_count, l_next_free_rec) at various points during extent tree traversal. This is fragile because each caller must remember to check for corrupted on-disk data before using it. This series moves those checks into the block read validation callbacks (ocfs2_validate_dx_root and ocfs2_validate_extent_block), so corrupted fields are caught early at block read time. Redundant post-read checks are then removed. This patch (of 4): Move the extent list l_count validation from ocfs2_dx_dir_lookup_rec() into ocfs2_validate_dx_root(), so that corrupted on-disk fields are caught early at block read time rather than during directory lookups. Additionally, add a l_next_free_rec <= l_count check to prevent out-of-bounds access when iterating over extent records. Both checks are skipped for inline dx roots (OCFS2_DX_FLAG_INLINE), which use dr_entries instead of dr_list. Link: https://lkml.kernel.org/r/20260403090803.3860971-1-joseph.qi@linux.alibaba.com Link: https://lkml.kernel.org/r/20260403090803.3860971-2-joseph.qi@linux.alibaba.com Signed-off-by: Joseph Qi Reviewed-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Signed-off-by: Andrew Morton Stable-dep-of: bc70726ddad5 ("ocfs2: validate directory-index entry counts when reading metadata") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a1dabe68fb53730bc0be60c5dbfd3f4c560084e7 Author: Vincent Donnefort Date: Wed Sep 9 06:11:35 2026 -0400 ring-buffer: Make cpu_buffer::free_page a buffer_data_read_page [ Upstream commit 7a1fb95de5404134f8758c1295ce88986bdf117c ] Discarding a cached reader page after a concurrent ring buffer resize uses the new global subbuf_order for the free_pages() call. This mismatched order may crashes the kernel or leaks memory because the cached page was allocated under the old size. Save the actual free_page order alongside the page address to ensure we always refer to the correct value and do not rely on the potentially stalled cpu_buffer->subbuf_order value. The simplest is to make free_page a buffer_data_read_page which already covers exactly what we need: a page address and a page order. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260813131152.3589632-4-vdonnefort@google.com Fixes: 8e7b58c27b3c ("ring-buffer: Just update the subbuffers when changing their allocation order") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt [ Changed upstream’s dpage variable to bpage in ring_buffer_free_read_page(). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a6f3b8dfbdf4f43182b4544e8bfd007f1591fe99 Author: Jorijn van der Graaf Date: Wed Sep 9 06:11:03 2026 -0400 ASoC: codecs: aw88261: only check PLL and clock state at power-up [ Upstream commit 06b6f1245567a4be862c3e1cc74577922ceb05fb ] The SYSST check performed during device start requires SWS (amplifier switching, bit 8) and BSTS (boost finished, bit 9) on top of PLL lock and clock stability. Those bits cannot be asserted at this point in the sequence: the check runs after amppd release but before the hmute/ULS-hmute release, and the amplifier neither switches nor finishes ramping its boost converter while it is still muted. With the Fairphone (Gen. 6) firmware profile, aw88261_dev_start() therefore always fails with check sysst fail, reg_val=0x0011, check:0x311 and playback aborts, even though the amplifier is fine and PLL lock and stable clocks are present. Check only PLL lock and clock stability, for which a definition already exists; this still re-validates the clocks after amppd release (aw88261_dev_check_syspll() checked them before it). This matches the vendor aw882xx driver, which only validates PLL lock and clock stability at this stage, and the in-tree aw88399 driver, which skips the SWS check whenever the amplifier may legitimately not be switching (AW88399_BIT_SYSST_NOSWS_CHECK). Fixes: 028a2ae25691 ("ASoC: codecs: Add aw88261 amplifier driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Jorijn van der Graaf Link: https://patch.msgid.link/20260704192857.88366-1-jorijnvdgraaf@catcrafts.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0ac722e964cdc80ecd36402f554d2a55ab30caa9 Author: Val Packett Date: Wed Sep 9 06:11:02 2026 -0400 ASoC: codecs: aw88261: reduce log spam [ Upstream commit d90c361af215a9fa2a986d9f47d554d0cf3401dd ] This driver would create a wall of logspam during initialization due to e.g. the PLL not being ready while waiting for it to stabilize. Change intermediate dev_err() calls to dev_dbg() to reduce the noise. While here, log the detected chip ID when that check fails. Signed-off-by: Val Packett Tested-by: Luca Weiss Link: https://patch.msgid.link/20260529200550.529719-4-val@packett.cool Signed-off-by: Mark Brown Stable-dep-of: 06b6f1245567 ("ASoC: codecs: aw88261: only check PLL and clock state at power-up") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d013b7de4dccfde73d7c004b4d5338300103c4a2 Author: Mukesh Ojha Date: Wed Sep 9 06:10:56 2026 -0400 remoteproc: qcom: pas: Guard dtb metadata release with dtb_pas_id check [ Upstream commit c06c5ab4945392d2c2aded6d832ab6b58cabe351 ] All other call sites of qcom_scm_pas_metadata_release() for the DTB context are guarded by a check on pas->dtb_pas_id, but the call inside qcom_pas_load() was not. Fix this by moving the call to the guarded block. Reviewed-by: Konrad Dybcio Fixes: 29814986b82e ("remoteproc: qcom_q6v5_pas: add support for dtb co-firmware loading") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260724182858.1868271-3-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson [ adapted DTB cleanup to the older separate initialization and loading APIs. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d6eab9066be0f2aba5528535dd45a39a47d8b4e6 Author: Mukesh Ojha Date: Wed Sep 9 06:10:55 2026 -0400 firmware: qcom_scm: Rename peripheral as pas_id [ Upstream commit 69054348cc1c2d87acad90aec5e6e0d191012aff ] Peripheral and pas_id refers to unique id for a subsystem and used only when peripheral authentication service from secure world is utilized. Lets rename peripheral to pas_id to reflect closer to its meaning. Reviewed-by: Bryan O'Donoghue Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-3-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: c06c5ab49453 ("remoteproc: qcom: pas: Guard dtb metadata release with dtb_pas_id check") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9d69422ddaa13526c2223444e237d948d6e44728 Author: Tejun Heo Date: Wed Sep 9 05:26:31 2026 -0400 sched/core: Make core-sched flips wait for in-flight selections [ Upstream commit f3629c63a4af3e491381780bc6c123cb498c4c40 ] Core scheduling's pick_next_task() operates on all sibling rqs under one acquisition of the shared core-wide lock. A ->pick_task() that releases the rq lock leaves every sibling __lock momentarily free, letting __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under it. The selection resumes on the split locks, touching sibling state it no longer protects, and __schedule() finally releases a lock that was never taken while leaking the one that was. Count in-flight core-wide selections in the leader's rq->core_pick_in_flight and make __sched_core_flip() wait for the count to drain. The count only changes under the shared lock, which the flip holds while sampling, so no other ordering is needed. The wait can repeat while selections overlap, but the flip backs off between samples and flips are rare cookie-lifetime events. sched_core_cpu_deactivate() moves the count to the new leader - a stale copy left behind would bias it forever if that CPU later returns as its own leader. Fixes: 539f65125d20 ("sched: Add core wide task selection and scheduling") Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Tejun Heo Acked-by: Peter Zijlstra (Intel) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fef4b8f17e1c54522957b873ed81e6a60897625d Author: John Stultz Date: Wed Sep 9 05:26:30 2026 -0400 sched: Rework prev_balance() to avoid stale prev references [ Upstream commit 7a3a6bfbd62a2ba3e0ef1e92d6b71abb66890825 ] Historically, the prev value from __schedule() was the rq->curr. This prev value is passed down through numerous functions, and used in the class scheduler implementations. The fact that prev was on_cpu until the end of __schedule(), meant it was stable across the rq lock drops that the class->balance() implementations often do. However, with proxy-exec, the prev passed to functions called by __schedule() is rq->donor, which may not be the same as rq->curr and may not be on_cpu, this makes the prev value potentially unstable across rq lock drops. A recently found issue with proxy-exec, is when we begin doing return migration from try_to_wake_up(), its possible we may be waking up the rq->donor. When we do this, we proxy_resched_idle() to put_prev_set_next() setting the rq->donor to rq->idle, allowing the rq->donor to be return migrated and allowed to run. This however runs into trouble, as on another cpu we might be in the middle of calling __schedule(). Conceptually the rq lock is held for the majority of the time, but in calling prev_balance() its possible the class->balance() handler call may briefly drop the rq lock. This opens a window for try_to_wake_up() to wake and return migrate the rq->donor before the class logic reacquires the rq lock. Unfortunately prev_balance() pass in a prev argument, to which we pass rq->donor. However this prev value can now become stale and incorrect across a rq lock drop. So, to correct this, rework the prev_balance() call so that it does not take a "prev" argument. Signed-off-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260512025635.2840817-2-jstultz@google.com Backport adaptation for 6.18: Keep the existing sched_class::pick_next_task callbacks, pick_task interfaces, SCX balancing setup and proxy-execution flow. The later upstream scheduler refactors and lock annotations are not prerequisites for this dependency. Convert all six balance callbacks, including the fair and SCX callbacks still present here, to the new signature. Read rq->donor at the existing selection and balance call sites, and refresh prev after new-idle balancing in pick_next_task_fair() because that path still drops the rq lock inside the stable pick_next_task implementation. This preserves the existing functions and supplies the selection context needed for f3629c63a4af (sched/core: Make core-sched flips wait for in-flight selections) to apply without changes. Stable-dep-of: f3629c63a4af ("sched/core: Make core-sched flips wait for in-flight selections") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c522333c35d483123e365ed0ae4ea34ff5e6c06f Author: John Stultz Date: Wed Sep 9 05:26:29 2026 -0400 sched: Add assert_balance_callbacks_empty helper [ Upstream commit f9530b3183358bbf945f7c20d4a6e2048061ec50 ] With proxy-exec utilizing pick-again logic, we can end up having balance callbacks set by the preivous pick_next_task() call left on the list. So pull the warning out into a helper function, and make sure we check it when we pick again. Suggested-by: Peter Zijlstra Signed-off-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: K Prateek Nayak Link: https://patch.msgid.link/20260324191337.1841376-8-jstultz@google.com Stable-dep-of: f3629c63a4af ("sched/core: Make core-sched flips wait for in-flight selections") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c97be9d5ab04c7e26bc1671c551289b0d951d6c0 Author: Tejun Heo Date: Wed Sep 9 05:26:27 2026 -0400 sched_ext: Fix inverted ops.core_sched_before() invocation [ Upstream commit f7b6d128dd49a6eec09066ecfd29095f12588786 ] scx_prio_less() implements prio_less() semantics - %true means that @a is the lower priority and should run after @b. ops.core_sched_before() is documented to return %true when @a should run before @b. scx_prio_less() returns the op's value as-is, inverting the documented semantics at runtime. Call the op with the arguments swapped. scx_qmap followed the wiring instead of the documentation and returned %true for the younger task, so the two inversions canceled out and it behaved as intended. Flip its comparison to match. scx_qmap is likely the only current user in or out of the kernel tree. Any scheduler written the same way needs the same flip, while schedulers following the documentation are fixed by this change. Fixes: 7b0888b7cc19 ("sched_ext: Implement core-sched support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Tejun Heo [ adapted kernel/sched/ext/ext.c changes to the older kernel/sched/ext.c layout ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c4ade059aaeb51fdb3f4ae71e1ea3e2019b85178 Author: Linkai Gong Date: Wed Sep 9 05:26:10 2026 -0400 scsi: fnic: Use GFP_ATOMIC for VLAN alloc under spinlock [ Upstream commit 9639c6324524ea3f934908bd51f02430000954ab ] fnic_fcoe_process_vlan_resp() allocates a VLAN descriptor with kzalloc_obj() (default GFP_KERNEL) while holding vlans_lock via spin_lock_irqsave(). GFP_KERNEL may sleep, which is not allowed in this atomic context and can trigger a sleeping-from-invalid-context warning or deadlock. Pass GFP_ATOMIC so the allocation is safe under the IRQ-safe spinlock. Fixes: 098585aa8aca ("scsi: fnic: Add and integrate support for FIP") Cc: stable@vger.kernel.org Signed-off-by: Linkai Gong Reviewed-by: Karan Tilak Kumar Link: https://patch.msgid.link/20260731073820.16449-1-gonglinkai@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) [ adapted kzalloc_obj(*vlan, GFP_ATOMIC) to kzalloc(sizeof(*vlan), GFP_ATOMIC). ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c98197ee3cd28288da13dc9881bb9e74daa7cbbc Author: Abhijit Gangurde Date: Wed Sep 9 05:25:57 2026 -0400 RDMA/ionic: Embed counter driver data in rdma_counter allocation [ Upstream commit cf3ebd89e754015625fee90aa938f6bc79a2c974 ] Commit 7e53b31acc7f ("RDMA/core: Create and destroy rdma_counter using rdma_zalloc_drv_obj()") requires drivers implementing counter ops to embed struct rdma_counter in a driver-specific struct, register its size via INIT_RDMA_OBJ_SIZE, and provide a counter_init callback. The ionic driver was merged without this adaptation, causing a NULL pointer dereference in alloc_and_bind() since rdma_zalloc_drv_obj() allocates zero bytes when size_rdma_counter is unset. Consolidate struct ionic_counter into a new struct ionic_rdma_counter that embeds struct rdma_counter, replace the xarray with a lightweight ida for ID allocation, and add the required counter_init and INIT_RDMA_OBJ_SIZE declarations. Fixes: ea4c399642b8 ("RDMA/ionic: Implement device stats ops") Cc: stable@vger.kernel.org # 6.18 Signed-off-by: Abhijit Gangurde Link: https://patch.msgid.link/20260805053254.4023262-2-abhijit.gangurde@amd.com Signed-off-by: Leon Romanovsky [ adapted kzalloc_obj(*cntr) removal to the older kzalloc(sizeof(*cntr), GFP_KERNEL) allocation. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 27b7b0dacae79ab0476d7b32abd023b46e34cd93 Author: fangqiurong Date: Tue Sep 8 21:53:44 2026 -0400 sched_ext: Fix exit_task leak on fork failure during enable [ Upstream commit 03506edca637a8465dba9f635c50e9884fbcaf4e ] scx_fork() initializes tasks when scx_init_task_enabled is set, but scx_cancel_fork() only exits them when scx_enabled() is true. A fork that fails in the enable window (between releasing scx_fork_rwsem and setting __scx_enabled) runs ops.init_task() but never ops.exit_task(). Gate scx_cancel_fork() on scx_init_task_enabled. Fixes: 4269c603cc26 ("sched_ext: Enable scx_ops_init_task() separately") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: fangqiurong Signed-off-by: Tejun Heo [ Adjusted the target file path from kernel/sched/ext/ext.c to kernel/sched/ext.c. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1a3af2262cb384112ef38632de4690682be528b4 Author: Chuck Lever Date: Tue Sep 8 20:52:01 2026 -0400 svcrdma: Reject Read lists that exceed the page budget [ Upstream commit 0ca487abb3bdf581851664b5db21f364caf57682 ] Individual Read segment lengths are validated at decode time, but nothing prevents a requester from sending multiple segments whose cumulative length exceeds the rq_pages array budget. When one segment fills the page array exactly, the runtime guard in svc_rdma_build_read_segment() is bypassed because len reaches zero. A subsequent segment then accesses the NULL sentinel slot at rq_pages[rq_maxpages], resulting in a NULL pointer dereference during DMA mapping. Accumulate pages across all Read segments and reject the message at decode time when the total would overflow the page budget. Fixes: 026d958b38c6 ("svcrdma: Add recvfrom helpers to svc_rdma_rw.c") Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 59bcf1b38f89879e0a41aecb152f1b076c4b6ac6 Author: Chuck Lever Date: Tue Sep 8 20:52:00 2026 -0400 svcrdma: Reject oversized Read segments at decode time [ Upstream commit af6f0e06bed818ee7fc8b869915964410020a1c5 ] The RPC/RDMA Read list decoder stores wire-supplied segment lengths without validation. xdr_count_read_segments() checks 4-byte alignment for non-zero position values but does not cap the segment length. An oversized rs_length reaches svc_rdma_build_read_segment(), which derives nr_bvec from it and can drive a large dynamic bvec allocation before verifying that enough rq_pages remain. If the post-allocation page-overrun guard fires, the freshly acquired rw context is not returned, leaking the resource. Reject any segment whose length exceeds the receive context's page budget during Read list decoding, consistent with how xdr_check_write_chunk() bounds Write segment counts against rc_maxpages. Also return the rw context on the existing post-allocation overrun path in svc_rdma_build_read_segment(), keeping that defensive guard balanced. Fixes: 5ee62b4a9113 ("svcrdma: use bvec-based RDMA read/write API") Cc: stable@vger.kernel.org Acked-by: Jeff Layton Link: https://patch.msgid.link/20260526-rpc-kernel-bugs-v1-3-e251306ccca9@oracle.com Signed-off-by: Chuck Lever Stable-dep-of: 0ca487abb3bd ("svcrdma: Reject Read lists that exceed the page budget") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3c97b8e76ca2bba9e8770571413aed694068e78e Author: Chuck Lever Date: Tue Sep 8 19:21:09 2026 -0400 rpcrdma: arm rn_done before publishing the notification [ Upstream commit 5b06f706374c37375bdff9d21cc10e61df925a92 ] rpcrdma_rn_register() inserts @rn into rd_xa with xa_alloc() before storing the caller's callback in rn->rn_done. The xarray makes @rn reachable to rpcrdma_remove_one(), which walks rd_xa and invokes rn->rn_done(rn) for every registered notification. A device removal that races a fresh registration can therefore observe @rn with rn_done still NULL, because the notification objects are zero allocated by their owners, and call through a NULL function pointer. Store rn->rn_done before xa_alloc() publishes @rn. The xarray's store-side and load-side ordering then guarantees that any CPU which finds @rn in rd_xa also observes the armed callback. rpcrdma_rn_unregister() treats a non-NULL rn_done as the sentinel for a completed registration, so the early store must not survive a failed registration. Clear rn_done again when xa_alloc() fails. Were it left set, the failed-accept cleanup path would call rpcrdma_rn_unregister() on an @rn that was never inserted, erasing an unrelated rd_xa slot and underflowing rd_kref. Fixes: 7e86845a0346 ("rpcrdma: Implement generic device removal") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260601201703.46078-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9f2f5d0999364c7070306cd422d8babc2621070d Author: Chuck Lever Date: Tue Sep 8 19:19:28 2026 -0400 svcrdma: Reorder rpcrdma_rn_unregister before rdma_destroy_id [ Upstream commit 4488e912973773d64368828acf3b8e39d93650ae ] svc_rdma_free() caches rdma->sc_cm_id->device before teardown, then calls rdma_destroy_id(sc_cm_id) which frees the cm_id. rpcrdma_rn_unregister() follows, but between those two calls the transport's sc_rn entry is still installed in the device's rd_xa. A concurrent ib_unregister_device walk can dispatch svc_rdma_xprt_done() against the now-freed sc_cm_id. Move rpcrdma_rn_unregister() before rdma_destroy_id() so the transport's notification entry is removed from the xarray before the cm_id it references is destroyed. Also guard the sc_cm_id dereference with a NULL check: the following patches introduce paths that reach svc_rdma_free() with sc_cm_id == NULL (listener create failure, ADDR_CHANGE replacement failure). Fixes: c4de97f7c454 ("svcrdma: Handle device removal outside of the CM event handler") Cc: stable@vger.kernel.org Acked-by: Jeff Layton Link: https://patch.msgid.link/20260527-rdma-follow-on-v1-2-1b09bd87b6cd@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ee7f6e5600ae163b08e825185d9cd488e7d5b4be Author: Chuck Lever Date: Tue Sep 8 19:19:27 2026 -0400 svcrdma: Release transport resources synchronously [ Upstream commit bf94dea7fd4e6708d1a784be23db65eff84d82f1 ] NFSD has always supported added network listeners. The new netlink protocol now enables the removal of listeners. Olga noticed that if an RDMA listener is removed and immediately re-added, the deferred __svc_rdma_free() function might not have run yet, so some or all of the old listener's RDMA resources linger, which prevents a new listener on the same address from being created. Also, svc_xprt_free() does a module_put() just after calling ->xpo_free(). That means if there is deferred work going on, the module could be unloaded before that work is even started, resulting in a UAF. Neil asks: > What particular part of __svc_rdma_free() needs to run in order for a > subsequent registration to succeed? > Can that bit be run directory from svc_rdma_free() rather than be > delayed? > (I know almost nothing about rdma so forgive me if the answers to these > questions seems obvious) The reasons I can recall are: - Some of the transport tear-down work can sleep - Releasing a cm_id is tricky and can deadlock We might be able to mitigate the second issue with judicious application of transport reference counting. Reported-by: Olga Kornievskaia Closes: https://lore.kernel.org/linux-nfs/20250821204328.89218-1-okorniev@redhat.com/ Suggested-by: NeilBrown Signed-off-by: Chuck Lever Stable-dep-of: 4488e9129737 ("svcrdma: Reorder rpcrdma_rn_unregister before rdma_destroy_id") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3ff45361e9469e85c0f86b8e7b82c63e50bab8ef Author: Chris Mason Date: Tue Sep 8 15:28:25 2026 -0400 SUNRPC: fix gssx_dec_option_array error path bugs [ Upstream commit 5e9a94539b1ec17a89177d952badfd0d844d694a ] Four coupled defects in the gssx XDR option-array decoder make the error paths unsafe: a NULL deref in the caller, a refcount leak on the decoded group_info, and a latent use-after-free that the leak fix would otherwise expose. gssx_dec_option_array() sets oa->count = 1 before allocating oa->data. If that allocation fails, -ENOMEM is returned with oa->count == 1 and oa->data == NULL. All other error paths jump to free_oa: which frees oa->data and NULLs it but also leaves oa->count == 1. The caller trusts the count: gssp_accept_sec_context_upcall() gssx_dec_accept_sec_context() gssx_dec_option_array() /* fails, count=1 data=NULL */ data = res.options.data[0].value /* NULL deref */ Independently, free_creds: releases the partially decoded svc_cred with a bare kfree(creds). gssx_dec_linux_creds() installs a groups_alloc() result into creds->cr_group_info; that object is kvmalloc-backed and refcounted, and only put_group_info() reaches kvfree(). A plain kfree(creds) drops the wrapper and leaks the group_info allocation. The natural fix for the leak is to call free_svc_cred(creds) before kfree(creds), but free_svc_cred() invokes put_group_info() on creds->cr_group_info unconditionally when non-NULL. The existing out_free_groups: path in gssx_dec_linux_creds() already called groups_free() on that pointer without clearing it, so once free_svc_cred() is wired in, the subsequent put_group_info() would touch freed memory. Fix all four together: - Move the oa->count = 1 assignment below the oa->data allocation so it is never set when oa->data is NULL. - Reset oa->count to 0 at free_oa: so count and data stay coherent and the caller sees an empty option array. - Call free_svc_cred(creds) before kfree(creds) at free_creds: so the refcounted cr_group_info is released. free_svc_cred() either NULL-guards each field explicitly (cr_group_info has an if() check) or delegates to a helper that is NULL-safe itself (kfree for the string fields, gss_mech_put() which guards with if(gm) at gss_mech_switch.c:342), so it is safe to call on a partially decoded svc_cred where only cr_uid/cr_gid/cr_group_info have been written and everything else is zero from kzalloc. - In gssx_dec_linux_creds()'s out_free_groups: path, release cr_group_info with put_group_info() rather than groups_free() so the teardown matches free_svc_cred()'s refcount-aware path, and clear the pointer so a later free_svc_cred() on the same creds does not release it a second time. Fixes: 3cfcfc102a5e ("SUNRPC: fix some memleaks in gssx_dec_option_array") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260528-tier2-v1-2-d026a1415e0b@oracle.com Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5563db13c9528a56c7161260ec75ec8690dc5608 Author: Dave Jiang Date: Tue Sep 8 12:01:37 2026 -0400 cxl/mce: Make the MCE notifier per-region [ Upstream commit 775d0f4558f4cec0ee0c8966595d1add1791f36e ] Flavien Solt reported lifetime issues with the CXL MCE notifier, which can lead to NULL dereferences and use-after-free in the MCE handler. The notifier was registered per memory device and stored in 'struct cxl_memdev_state', even though it only needs the region state (the region's SPA range and its extended linear cache size). Instead of keeping the memory device and endpoint alive, the correct fix is to move the notifier into 'struct cxl_region' and register it from cxl_region_probe() as it should be a per-region notifier. Setup the registration to only happen for regions that have an extended linear cache as that is the only current usage. Remove cxl_port_get_spa_cache_alias() as it is now dead code. [ dj: Update dev_warn() when notifier fails due to kconfig. (Ben) ] Reported-by: Flavien Solt Suggested-by: Dan Williams Fixes: 516e5bd0b6bf ("cxl: Add mce notifier to emit aliased address for extended linear cache") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Alison Schofield Reviewed-by: Ben Cheatham Link: https://patch.msgid.link/20260616224912.2567474-1-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 513a9613f7a638f31afbabea1ac809bfc8bb0437 Author: Smita Koralahalli Date: Tue Sep 8 12:01:36 2026 -0400 cxl/region: Add helper to check Soft Reserved containment by CXL regions [ Upstream commit 8e65f99b525b3f49b87db0db0d0e0fc1a0c53e40 ] Add a helper to determine whether a given Soft Reserved memory range is fully contained within the committed CXL region. This helper provides a primitive for policy decisions in subsequent patches such as co-ordination with dax_hmem to determine whether CXL has fully claimed ownership of Soft Reserved memory ranges. Signed-off-by: Smita Koralahalli Reviewed-by: Jonathan Cameron Reviewed-by: Dave Jiang Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260322195343.206900-8-Smita.KoralahalliChannabasappa@amd.com Signed-off-by: Dan Williams Signed-off-by: Dave Jiang [ sashal: Reduced backport -- upstream 8e65f99b525b3 touches 2 file(s), this backport carries 2. Not backported here: include/cxl/cxl.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 775d0f4558f4 ("cxl/mce: Make the MCE notifier per-region") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 040cface98ffd8b397943ca10ad8e6ee1c5a5624 Author: Dan Williams Date: Tue Sep 8 12:01:35 2026 -0400 dax/cxl, hmem: Initialize hmem early and defer dax_cxl binding [ Upstream commit 39aa1d4be12bf9f685adaa06aa2d997c1c611b16 ] Move hmem/ earlier in the dax Makefile so that hmem_init() runs before dax_cxl. In addition, defer registration of the dax_cxl driver to a workqueue instead of using module_cxl_driver(). This ensures that dax_hmem has an opportunity to initialize and register its deferred callback and make ownership decisions before dax_cxl begins probing and claiming Soft Reserved ranges. Mark the dax_cxl driver as PROBE_PREFER_ASYNCHRONOUS so its probe runs out of line from other synchronous probing avoiding ordering dependencies while coordinating ownership decisions with dax_hmem. Signed-off-by: Smita Koralahalli Reviewed-by: Dave Jiang Reviewed-by: Jonathan Cameron Tested-by: Tomasz Wolski Link: https://patch.msgid.link/20260322195343.206900-6-Smita.KoralahalliChannabasappa@amd.com Signed-off-by: Dan Williams Signed-off-by: Dave Jiang Stable-dep-of: 775d0f4558f4 ("cxl/mce: Make the MCE notifier per-region") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dfc86b0c2698e0a48acb050fc1cb18d83a763f83 Author: Terry Bowman Date: Tue Sep 8 09:26:31 2026 -0400 cxl/ras: Fix cxl_rch_get_aer_severity() wrong severity register [ Upstream commit 9d399526128bae184b153deab42b49f5f3eea2ed ] cxl_rch_get_aer_severity() classifies RCH Downstream Port uncorrectable errors as fatal or non-fatal by ANDing uncorrectable status with PCI_ERR_ROOT_FATAL_RCV. This is wrong because PCI_ERR_ROOT_FATAL_RCV is a Root Error Status register bit (bit 6), not a severity bit. ANDing it against uncorrectable status tests a reserved bit and produces incorrect severity classification. Fix by ANDing the unmasked uncor_status against uncor_severity. Per PCIe Base Spec r6.0 Section 7.8.4.4, each bit in the Uncorrectable Error Severity register indicates whether the corresponding error is fatal (1) or non-fatal (0). Fixes: 6ac07883dbb5 ("cxl/pci: Add RCH downstream port error logging") Cc: stable@vger.kernel.org Signed-off-by: Terry Bowman Reviewed-by: Jonathan Cameron Reviewed-by: Dave Jiang Reviewed-by: Richard Cheng Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260803221810.3685703-3-terry.bowman@amd.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ccf481d73bce6e851cec364fe831c86fe66877cf Author: Jiri Olsa Date: Tue Sep 8 09:12:09 2026 -0400 bpf: Disable preemption in bpf_get_stackid [ Upstream commit 15f1bd8574662f1b7b26aaa2e23ebf4066f0117d ] The get_perf_callchain call needs disabled preemption plus we need it disabled as long as we access its returned trace entries buffer. Note the bpf_get_stackid_pe function is executed already with preemption disabled. Fixes: d5a3b1f69186 ("bpf: introduce BPF_MAP_TYPE_STACK_TRACE") Reported-by: Tao Chen Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260803210149.296496-6-jolsa@kernel.org Closes: https://lore.kernel.org/bpf/20260206090653.1336687-2-chen.dylane@linux.dev/ [ adapted get_perf_callchain() to the older six-argument form ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b466ff95324f8fd093bb2127c4b89fa34a5473f7 Author: Jiri Olsa Date: Tue Sep 8 09:12:08 2026 -0400 bpf: Use stack id functions instead of __bpf_get_stackid [ Upstream commit 09b3fd6caa0b57f8a39254ee5db3af30bdd53c18 ] Replacing __bpf_get_stackid calls with sequence of following functions: stackid_fastpath stackid_new_bucket stackid_install This makes code more structured and allows us to easily disable preemption only in bpf_get_stackid in following changes. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-5-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 73ebef25aec4936743d647bde0649563eddc7914 Author: Jiri Olsa Date: Tue Sep 8 09:12:07 2026 -0400 bpf: Factor stackid_new_bucket from __bpf_get_stackid [ Upstream commit bb4e6f4e1b68fe60c04ca04c564c6624e837dbf4 ] The new stackid_new_bucket allocates the new bucket and initializes it with the trace data. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-4-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba1e22a224c39fcbfb5e40070455ed69b9e2d561 Author: Jiri Olsa Date: Tue Sep 8 09:12:06 2026 -0400 bpf: Factor stackid_fastpath function from __bpf_get_stackid [ Upstream commit 0ca56befcffec3a6c9d1842eae06c74e1cf41f11 ] The new stackid_fastpath does the fast stack hash and trace check, that does not need new bucket allocation. It covers both just-ip and buildid code paths. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-3-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 201a381bef3ac4e2b2d36acbb0db25b8feb701e8 Author: Jiri Olsa Date: Tue Sep 8 09:12:05 2026 -0400 bpf: Factor stackid_init function from __bpf_get_stackid [ Upstream commit 15b837759a97237d647962f9943afe0d55af615a ] The new stackid_init function stores all the necessary bits for stackid trace and it will be used by other functions in following changes. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-2-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7c19b94c625dc7042b0a7dff4c8da158358ffa2c Author: Haoxiang Li Date: Tue Sep 8 08:58:56 2026 -0400 cpufreq: apple-soc: Fix OPP table cleanup [ Upstream commit d87cb889dc7ab1f2deecadf2a5e9023184bd7900 ] apple_soc_cpufreq_init() adds OPP tables from firmware, but some failure paths do not remove them. The driver also uses dev_pm_opp_remove_all_dynamic(), which is not the right cleanup helper for OPP tables loaded from firmware. Use the cpumask OPP helper after the policy CPU mask has been populated. Pair it with the matching cpumask remove helper on failure paths and in apple_soc_cpufreq_exit(). This also removes the separate dev_pm_opp_set_sharing_cpus() call, as the cpumask helper loads the DT OPP tables for all CPUs in the policy. Fixes: 6286bbb40576 ("cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Viresh Kumar [ retained kzalloc(sizeof(*priv), GFP_KERNEL) instead of upstream kzalloc_obj(*priv) ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e989cede44392262d0560413558b9c6a71313387 Author: Rafael J. Wysocki Date: Tue Sep 8 08:20:04 2026 -0400 ACPI: TAD: Add locking around AML evaluations [ Upstream commit a3df8bbe0a704fa5c1609b9666b594f350558fe0 ] In the ACPI TAD driver, there are hidden assumptions that the ACPI control methods used by it will not be evaluated concurrently due to ACPICA namespace and interpreter locking. However, that may not be the case since ACPICA may drop and re-acquire the namespace and interpreter locks during the evaluation of a given object in a few cases, including the one in which the AML in question sleeps causing acpi_ex_system_do_sleep() to be called. In that case, the evaluation of one control method may be started while the evaluation of another one is still in progress. For this reason, add a global lock to the ACPI TAD driver and acquire it every time before evaluating an ACPI control method, except for the initial evaluation of _GCP in acpi_tad_probe(). Fixes: 95c513ec84f7 ("ACPI: Add Time and Alarm Device (TAD) driver") Cc: All applicable Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/12951141.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dd440f6a2e67f807c8a76c2d57d922e5c5ac6f0b Author: Rafael J. Wysocki Date: Tue Sep 8 08:20:03 2026 -0400 ACPI: TAD: Rearrange RT data validation checking [ Upstream commit 3329a1416c3350449081ca5daaa94802a65b2992 ] Move RT data validation checks from acpi_tad_set_real_time() to a separate function called acpi_tad_rt_is_invalid() and use it also in acpi_tad_get_real_time() to validate data coming from the platform firmware. Also make acpi_tad_set_real_time() return -EINVAL when the RT data passed to it is invalid (instead of -ERANGE which is somewhat confusing) and introduce ACPI_TAD_TZ_UNSPEC to represent the "unspecified timezone" value. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3409319.aeNJFYEL58@rafael.j.wysocki Stable-dep-of: a3df8bbe0a70 ("ACPI: TAD: Add locking around AML evaluations") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0a7a192862232983322f5aaf0b934ae952570d65 Author: Rafael J. Wysocki Date: Tue Sep 8 08:20:02 2026 -0400 ACPI: x86/rtc-cmos: Use platform device for driver binding [ Upstream commit 2a78e42104444f948698f1225deaf515e9b7224d ] Modify the rtc-cmos driver to bind to a platform device on systems with ACPI via acpi_match_table and advertise the CMOST RTC ACPI device IDs for driver auto-loading. Note that adding the requisite device IDs to it and exposing them via MODULE_DEVICE_TABLE() is sufficient for this purpose. Since the ACPI device IDs in question are the same as for the CMOS RTC ACPI scan handler, put them into a common header file and use the definition from there in both places. Additionally, to prevent a PNP device from being created for the CMOS RTC if a platform one is present already, make is_cmos_rtc_device() check cmos_rtc_platform_device_present introduced previously. Signed-off-by: Rafael J. Wysocki Acked-by: Alexandre Belloni Link: https://patch.msgid.link/13969123.uLZWGnKmhe@rafael.j.wysocki Stable-dep-of: a3df8bbe0a70 ("ACPI: TAD: Add locking around AML evaluations") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ec2d81115485de3f604f86edc4d9119a213a59bf Author: Rafael J. Wysocki Date: Tue Sep 8 08:20:01 2026 -0400 ACPI: x86: cmos_rtc: Create a CMOS RTC platform device [ Upstream commit 1ae2f435350ec05224a39995c3a680aa6fdae5a5 ] Make the CMOS RTC ACPI scan handler create a platform device that will be used subsequently by rtc-cmos for driver binding on x86 systems with ACPI and update add_rtc_cmos() to skip registering a fallback platform device for the CMOS RTC when the above one has been registered. Signed-off-by: Rafael J. Wysocki Acked-by: Dave Hansen # x86 Link: https://patch.msgid.link/1962427.tdWV9SEqCh@rafael.j.wysocki Stable-dep-of: a3df8bbe0a70 ("ACPI: TAD: Add locking around AML evaluations") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f2e08c3f994c9c342cb13270c3a8a5d92efd983e Author: Christian Loehle Date: Mon Sep 7 21:38:44 2026 -0400 ACPI: CPPC: Reject desired_perf reads on _CPC revision 4+ [ Upstream commit df5a1d4a8cdfda20eb2581a85e81c7d436866534 ] When CPPC feedback counters cannot provide a usable sample, cppc-cpufreq calls cppc_get_desired_perf() because some platforms repurpose Desired Performance to report actual delivered performance. ACPI 6.5 defines _CPC revision 3 and lists Read/Write as the Optional Attribute of Desired Performance. ACPI 6.6 advances _CPC to revision 4 and lists only Write, so invoking that workaround for revision 4 or later would require a register read that the interface no longer specifies. Make cppc_get_desired_perf() return -EOPNOTSUPP for _CPC revision 4 or later. Use the revision retained in the per-CPU CPC descriptor rather than the platform-wide FADT revision. The _CPC revision may still not accurately describe the implemented register semantics. If a nominally revision 3 platform implements a non-readable Desired Performance register, a read may return zero and make cppc_cpufreq_get_rate() report 0 kHz. Treat a zero read as unusable and fall back to the cached OSPM request, just as for a failed read. Fixes: c47195631960 ("cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged") Cc: stable@vger.kernel.org Suggested-by: Sumit Gupta Signed-off-by: Christian Loehle Link: https://patch.msgid.link/20260803203531.1268651-2-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki [ preserved the raw firmware revision while limiting parsing to the v3-sized register prefix ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7267557ce98ccd07faaf3bc86382448950cc4ff6 Author: Nikhil Gurudasani Date: Mon Sep 7 21:01:03 2026 -0400 erofs: skip sufficiently large global buffers when resizing [ Upstream commit a7d097cf01301c5da37927c8f26123d006f0fd8a ] z_erofs_gbuf_nrpages is advanced only after every global buffer has been grown. If a resize fails after some buffers were enlarged, a retry revisits those enlarged buffers. Retrying the same size then returns -ENOMEM because alloc_pages_bulk() has no pages to add and the unchanged return value is treated as a failure. Retrying an intermediate size allocates a temporary pointer array smaller than gbuf->nrpages and copies more existing pointers than the array can hold. Skip buffers that already satisfy the request. Once all remaining buffers have caught up, advancing z_erofs_gbuf_nrpages again describes the guaranteed minimum size across the pool. Fixes: d6db47e571dc ("erofs: do not use pagepool in z_erofs_gbuf_growsize()") Cc: stable@vger.kernel.org # 6.10+ Signed-off-by: Nikhil Gurudasani Reviewed-by: Gao Xiang Reviewed-by: Chao Yu Signed-off-by: Gao Xiang [ preserved the existing kcalloc() allocation instead of upstream kzalloc_objs() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 03c34309eb1bce1b3b5f7c4a94b703f419120383 Author: Jiangshan Yi Date: Mon Sep 7 17:36:33 2026 -0400 HID: mcp2221: clear rxbuf after I2C/SMBus transfer completes [ Upstream commit db2333f88729c8aae062cb171ed058725ff5c901 ] mcp_i2c_smbus_read() stores the caller-supplied buffer pointer in mcp->rxbuf for the duration of a transfer but never clears it when the transfer finishes or times out. Once the caller frees or reuses the buffer, mcp->rxbuf becomes a dangling pointer. A delayed or spurious MCP2221_I2C_GET_DATA report can then drive mcp2221_raw_event() to memcpy device data into the freed memory, causing a write use-after-free. Route all return paths through a single exit point that clears mcp->rxbuf and mcp->rxbuf_size, so that the existing !mcp->rxbuf guard in the raw_event handler can reject any report arriving after the transfer has ended. Fixes: 67a95c21463d ("HID: mcp2221: add usb to i2c-smbus host bridge") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1a503fbb116dae0e73fcb4f904b1fb6b19cd3377 Author: Florian Pradines Date: Mon Sep 7 17:36:32 2026 -0400 HID: mcp2221: fix OOB write in mcp2221_raw_event() [ Upstream commit f097d246677b03db814c5862f368cea341b76a00 ] mcp2221_raw_event() copies device-supplied data into mcp->rxbuf at offset rxbuf_idx without checking that the copy fits within the destination buffer. A device responding with up to 60 bytes to a small I2C/SMBus read can overflow the buffer. Add a rxbuf_size field to struct mcp2221, set it alongside rxbuf in mcp_i2c_smbus_read(), and check rxbuf_idx + data[3] <= rxbuf_size before the memcpy. Reported-by: Benoît Sevens Signed-off-by: Florian Pradines Signed-off-by: Jiri Kosina Stable-dep-of: db2333f88729 ("HID: mcp2221: clear rxbuf after I2C/SMBus transfer completes") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3b4709e4864908bb06c48c500cc8db8d3d55d139 Author: Doruk Tan Ozturk Date: Mon Sep 7 16:00:36 2026 -0400 HID: sony: clean up device list on probe failure [ Upstream commit 7c65699a3a311198a07659a614fe64d45924839e ] sony_input_configured() adds some controllers to sony_device_list before HID core registers their input devices. input_register_device() can fail after the callback returns successfully. sony_probe() then observes that HID_CLAIMED_INPUT is clear and unwinds, but only stops the HID hardware. The devres-managed sony_sc is freed while its list node remains linked, so the next matching controller traverses freed memory. Initialize the list node and device ID to inactive states. Make list removal idempotent and run the driver-private cleanup on every probe failure path. This also makes a second cleanup safe when sony_input_configured() already unwound a partial initialization before sony_probe() handles the missing input claim. Found by 0sec (https://0sec.ai) using automated source analysis; verified against the HID input registration and probe unwind paths. Fixes: 4f967f6d7374 ("HID: sony: Fix memory issue when connecting device using both Bluetooth and USB") Cc: stable@vger.kernel.org Reported-by: Doruk Tan Ozturk Link: https://lore.kernel.org/linux-input/20260724143925.007D61F00A3A@smtp.kernel.org/ Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a15def9a6311e85a01fa41dddbb255ce2eddb581 Author: Rosalie Wanders Date: Mon Sep 7 16:00:35 2026 -0400 HID: sony: use guard() and scoped_guard() [ Upstream commit da4f817ad273bca9aefd8636d347a8c101069111 ] This replaces the spin_lock_irqsave() and spin_unlock_irqrestore() calls with the RAII guard() and scoped_guard(). Signed-off-by: Rosalie Wanders Signed-off-by: Jiri Kosina Stable-dep-of: 7c65699a3a31 ("HID: sony: clean up device list on probe failure") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d2dd2cced65bc4b0523b19070d5811123ffdd350 Author: Frank Sorenson Date: Sun Sep 6 15:30:52 2026 -0400 cifs: add cifs_resize_file_locked() to guard fscache_resize_cookie() under i_rwsem [ Upstream commit 32a7af68df7361fe7cf153cf36124d04b94aec00 ] cifs_setsize() calls fscache_resize_cookie() without holding i_rwsem. When the fscache cookie is active (FSCACHE_COOKIE_IS_CACHING is set), fscache_resize_cookie() performs a real resize that requires i_rwsem held exclusively. If another file descriptor has the same inode open, fscache_use_cookie() was already called from that cifs_open(), making the cookie active. In that case, calling cifs_setsize() from cifs_do_truncate() (invoked from cifs_open() without i_rwsem) races against concurrent fscache I/O. Strip fscache_resize_cookie() from cifs_setsize(), making it a pure size/page-cache helper. Add cifs_resize_file_locked() for callers that already hold i_rwsem: it calls netfs_resize_file() and cifs_setsize(), then temporarily activates the cookie with fscache_use_cookie() to perform the resize under the lock, then deactivates it with cifs_fscache_unuse_inode_cookie(). Using fscache_use_cookie() before the resize ensures correctness whether or not another fd already holds the cookie active. Switch cifs_file_set_size(), smb2_duplicate_extents(), and both size- extension branches of smb3_simple_falloc() to the new wrapper; those paths already hold i_rwsem via VFS setattr, lock_two_nondirectories(), or cifs_fallocate() respectively. cifs_do_truncate() continues to call cifs_setsize() followed by cifs_invalidate_cache(), since it runs without i_rwsem. Fixes: fa724e235cfd ("cifs: add fscache_resize_cookie() to cifs_setsize()") Cc: stable@vger.kernel.org Cc: David Howells Cc: Paulo Alcantara Signed-off-by: Frank Sorenson Signed-off-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 85d239160dc1b9ad7cae64aad760fb926ec9e33c Author: Huiwen He Date: Sun Sep 6 15:30:51 2026 -0400 smb/client: emulate small EOF-extending mode 0 fallocate ranges [ Upstream commit 7a06d3b816d73448b4e38b83d65049f090b7b201 ] When a mode 0 fallocate extends EOF from 1G to 2G + 1M, the client currently sends SetEOF for 2G + 1M. This can make fallocate return success without allocating the requested range, or allocate extra space before that range. For example, on a fresh file: xfs_io -f \ -c "falloc 0 1G" \ -c "falloc 2G 1M" \ -c "truncate 3G" test The second fallocate should allocate [2G, 2G + 1M), leaving [1G, 2G) as a hole. Before this change, the result depended on the server allocation policy. With Samba "strict allocate = no", SetEOF could return success without allocating [2G, 2G + 1M). With "strict allocate = yes": # filefrag -v test [0, 1G) allocated [1G, 2G) allocated unexpectedly [2G, 2G + 1M) allocated SMB cannot allocate that arbitrary range, so write zeroes to small EOF-extending ranges instead. Limit this to 1 MiB to bound the client-side I/O cost. With "strict allocate = no", the requested range [2G, 2G + 1M) is allocated by the writes. With "strict allocate = yes": # filefrag -v test [0, 1G) allocated [1G, 2G) hole [2G, 2G + 1M) allocated This fixes the small EOF-extending range case exercised by generic/213. Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Stable-dep-of: 32a7af68df73 ("cifs: add cifs_resize_file_locked() to guard fscache_resize_cookie() under i_rwsem") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 41f4c997873988e3d184bb1328410ef9423880df Author: Huiwen He Date: Sun Sep 6 15:30:50 2026 -0400 smb/client: reduce fallocate zero buffer allocation [ Upstream commit 9e4ec3be67af41ab859302d7109b34976efd9258 ] The fallocate emulation allocates a 1 MiB zero-filled buffer even though each SMB2_write request is limited to SMB2_MAX_BUFFER_SIZE, which is 64 KiB. A high-order 1 MiB allocation is more likely to fail on a fragmented system. Allocate only the smaller of the requested range and SMB2_MAX_BUFFER_SIZE, and reuse that zero-filled buffer for every write request. Also reject a successful write that makes no progress to avoid looping indefinitely. This reduces the contiguous allocation required by fallocate emulation without changing the written data or range semantics. Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Stable-dep-of: 32a7af68df73 ("cifs: add cifs_resize_file_locked() to guard fscache_resize_cookie() under i_rwsem") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c2ae13662137c822c9192be902b942393e28524b Author: ZhangGuoDong Date: Sun Sep 6 15:30:49 2026 -0400 smb: move some definitions from common/smb2pdu.h into common/fscc.h [ Upstream commit a5e581093b1d9321cbb627dd8c209d0d4e0a988a ] These definitions are specified in MS-FSCC, so move them into fscc.h. Only add some documentation references, no other changes. Signed-off-by: ZhangGuoDong Reviewed-by: ChenXiaoSong Reviewed-by: Steve French Acked-by: Namjae Jeon Signed-off-by: Steve French The original header relocation is not applicable to this stable tree: fscc.h is absent and the relevant definitions are already kept in smb2pdu.h. For this stable-only dependency adaptation, prepare the existing fallocate paths for EOF-extending ranges and allocation metadata refresh, and align the cifs declarations with the target patch context. This lets the fscache resize locking fix apply without adding its new helper in the dependency. [ sashal: Reduced backport -- upstream a5e581093b1d9 touches 2 file(s), this backport carries 2. Not backported here: fs/smb/common/fscc.h fs/smb/common/smb2pdu.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: 32a7af68df73 ("cifs: add cifs_resize_file_locked() to guard fscache_resize_cookie() under i_rwsem") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 110747ff535e3d98ac17d68dbd056bb6ef000e23 Author: Sam Edwards Date: Sun Sep 6 13:42:14 2026 -0400 ceph: properly decrypt filenames in vmalloc() buffers [ Upstream commit e939fc6a7bd969a58a150b7f188c1047138403e3 ] The fscrypt subsystem uses the scatterlist crypto API, inheriting its requirement that any buffers are in the linear mapping region. However, the messenger client uses kvmalloc() to create buffers for messages, which will occasionally place those buffers in the vmalloc() region when physical memory fragmentation doesn't permit a large enough kmalloc(). The various callers of ceph_fname_to_usr() directly pass (slices of) raw messages from the MDS without considering that the messages may be in vmalloc() buffers, resulting in oopses especially on non-x86 platforms (see 'Closes:' for more details and a reproducer). Make ceph_fname_to_usr() explicitly tolerant of vmalloc()-allocated fname->ctext, fname->name, and/or oname->name buffers, using `tname` (which, when non-null, must be a linear address; when null, is briefly allocated as necessary) as a bounce buffer to avoid passing any inappropriate addresses to fscrypt_fname_disk_to_usr(). Additionally change parse_reply_info_readdir() -- the only function to supply its own `tname` -- to follow the new "tname must never come from vmalloc()" rule by passing NULL when the message is not in the linear region. Though this causes a per-dentry kmalloc()+kfree(), this overhead exists only when processing the minority of messages that spill into vmalloc(). My (crude) testing puts this at only about 1 in 8,000 readdir messages. Still, if the overhead proves unreasonable in the future, it is easy enough to mitigate: a future change could allocate a bounce buffer in parse_reply_info_readdir() and use that as `tname` instead. Cc: stable@vger.kernel.org # 888d33b208bd: ceph: pass fscrypt `tname` buffers directly Cc: stable@vger.kernel.org Fixes: 457117f077c6 ("ceph: add helpers for converting names for userland presentation") Closes: https://lore.kernel.org/ceph-devel/20260415034020.11530-1-CFSworks@gmail.com/ Signed-off-by: Sam Edwards Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov [ adapted raw tname buffer accesses to the legacy tname->name interface ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 104a51265042b4424085741c963cb858ac29ec0b Author: Chuck Lever Date: Sun Sep 6 11:04:40 2026 -0400 NFSD: Guard admin state-revocation walks with NFSD_NET_UP [ Upstream commit 2f3e6638aebc0ab8afb8b4e9816ea9a1cad85378 ] Writing to /proc/fs/nfsd/unlock_filesystem, or sending the NFSD_CMD_UNLOCK_FILESYSTEM or NFSD_CMD_UNLOCK_EXPORT netlink command, walks the NFSv4 client hash tables to revoke open state and cancel async COPY operations. All three handlers gate that walk on nn->nfsd_serv, but a listener added via portlist or netlink listener_set sets nn->nfsd_serv before any nfsd thread starts. nfsd_startup_net() has not yet allocated nn->conf_id_hashtbl, so the walkers dereference a NULL table. A local administrator with CAP_SYS_ADMIN can crash the kernel this way without ever starting the server. nn->nfsd_serv is set when the service is created, which precedes table allocation. NFSD_NET_UP instead brackets the window where the tables are live: set at the end of nfsd_startup_net() and cleared in nfsd_shutdown_net() after they are freed, both under nfsd_mutex. Gating the three unlock paths on NFSD_NET_UP fixes the startup-time NULL dereference while preserving the earlier post-shutdown use-after-free fix. Reported-by: XIAO WU Fixes: 1ac3629bf012 ("nfsd: prepare for supporting admin-revocation of state") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260621162551.2469460-1-cel@kernel.org Signed-off-by: Chuck Lever [ adapted NFSD_NET_UP flag check to the older nfsd_net_up boolean ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0e763ab306a81b5a1d65c14e9a9119a0eefea155 Author: Max Kellermann Date: Sun Sep 6 10:22:18 2026 -0400 ceph: force a cap message when a deferred revoke can't be acked immediately [ Upstream commit 8fdf946445732c2bcd685abc8bd0e509d2ebc158 ] When the MDS revokes capabilities, handle_cap_grant() normally guarantees a response by setting `CHECK_CAPS_FLUSH_FORCE` (see commit 31634d7597d8 ("ceph: force sending a cap update msg back to MDS for revoke op")), so ceph_check_caps() sends a cap message even if the client would otherwise decide it has nothing to do. That guarantee is skipped whenever the revoke has to be deferred (via revoke_wait): revoking Fb while dirty data is still buffered (writeback is queued first) or revoking Fc while pages are cached (async invalidation is queued first). In those cases, the ack is left to the deferred completion (ceph_put_wrbuffer_cap_refs() after writeback, or the invalidate worker after invalidation); both of which call ceph_check_caps(ci,0) i.e. without `CHECK_CAPS_FLUSH_FORCE`. Nothing gets sent under one of the following conditions: - the inode is retaining caps because the file was used recently (file_wanted != 0; retain |= CEPH_CAP_ANY) - the revoked cap is still used because the page was re-cached (e.g. a file being re-read) - the MDS has meanwhile re-granted, so `issued==implemented` and the client sees nothing being revoked The client then never emits the cap message which the MDS is waiting for. The MDS blocks on the revoke indefinitely and logs, for minutes or hours: client.NNN isn't responding to mclientcaps(revoke), ino 0x... pending pAsxLsXsxFsxcrwb issued pAsxLsXsxFsxcrwb, sent 964.899182 seconds ago The client-side state at that point shows the full cap set still issued, nothing in the revoking/flushing sets. Thus nothing gets sent. This patch fixes it by remembering that a forced response is expected. When a revoke is deferred, set `CEPH_I_FLUSH_FORCE` on the inode. ceph_check_caps() replays it as `CHECK_CAPS_FLUSH_FORCE`, so whichever path re-checks the inode next (the writeback/invalidate completion, the delayed worker, or any other caller) is guaranteed to send a cap message to the MDS. __prep_cap() clears the flag once a message is actually built. This is the deferred-path counterpart of the existing `CHECK_CAPS_FLUSH_FORCE` handling; a normal (non-deferred) revoke still forces the response inline as before. Cc: stable@vger.kernel.org Fixes: 31634d7597d8 ("ceph: force sending a cap update msg back to MDS for revoke op") Fixes: 257e6172ab36 ("ceph: don't let check_caps skip sending responses for revoke msgs") Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov [ adapted named atomic Ceph inode flag operations to lock-protected mask operations ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c040e139f1a629b767f900bbbc3f9892c290ed85 Author: Michael Bommarito Date: Sun Sep 6 10:22:14 2026 -0400 ceph: cap delegated inode count in ceph_parse_deleg_inos() [ Upstream commit 4bd3158bd62466d57ed72a3f7bc5f205fedd6919 ] ceph_parse_deleg_inos() decodes interval sets of delegated inode numbers from an MDS create-with-delegation reply. For each set it reads a 64-bit start and a 64-bit len with ceph_decode_64_safe(), which only validates that the eight bytes are present in the message, not the value, and then loops over len while inserting entries into s_delegated_inos. len is fully attacker controlled. A malicious or compromised MDS can send one huge interval, many intervals in one reply, duplicate intervals, or repeated replies that accumulate delegated inodes on the same session. The original code bounded none of these and could spin the insert loop or grow the xarray without limit. Bound both dimensions with a single enforcement point. Track the number of delegated inodes held by each MDS session in an atomic counter and grow it only in ceph_insert_deleg_ino(), which uses atomic_add_unless() to refuse to push the count past CEPH_MAX_DELEG_INOS. Because that helper is the only place the counter grows, the per-session population can never exceed the cap, so no separate per-session pre-check is needed. The counter is decremented when async create consumes a delegated inode or when an insert fails, incremented when a delegated inode is restored, initialized with the session xarray, and reset when reconnect destroys the xarray. A per-session cap alone still lets one reply spin the insert loop on duplicate ranges without growing the counter, so also cap the aggregate interval length accepted from a single reply. Together these bound both the loop trip count per reply and the xarray population across replies. The cap is a fixed, client-chosen constant rather than a value derived from the MDS. mds_client_prealloc_inos is a userspace MDS configuration option; it is never sent to the kernel client on the wire, and a server-supplied bound could not be trusted for a defensive limit in any case. The constant is set well above that option's documented default of 1000 (a generous multiple), so legitimate refill behavior is unaffected while the CPU and xarray memory a malformed delegation stream can consume stays bounded. Impact: a malicious or compromised Ceph MDS can no longer make a client spin through an unbounded delegated-inode interval or grow one session's delegated-inode xarray without limit. Cc: stable@vger.kernel.org Fixes: d48464878708 ("ceph: decode interval_sets for delegated inos") Suggested-by: Viacheslav Dubeyko Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov [ adapted counter reset placement to the older reconnect control flow ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8bd3523df1319edc61cd391e695c84a4618516df Author: Terry Bowman Date: Fri Sep 4 10:32:46 2026 -0400 cxl/ras: Fix cxl_rch_get_aer_info() out-of-bounds AER register read [ Upstream commit 29458e62d0829cbc99435f3e44fd560f9bbf1da7 ] cxl_rch_get_aer_info() copies the RCH Downstream Port AER capability from the RCRB MMIO block using a readl() loop bounded by sizeof(struct aer_capability_regs). This struct is a software layout and its embedded struct pcie_tlp_log is larger than the on-wire AER capability. As a result the loop reads past the mapped AER register block. The over-read also populates the software-only tail fields including header_log.header_len. An out-of-range header_len passed to pcie_print_tlp_log() can then loop past the header log buffer and cause a second out-of-bounds read. The read was correct when introduced, but struct pcie_tlp_log has since grown (Header Log and TLP Prefix Log sizes, header_len and flit fields), so sizeof(struct aer_capability_regs) no longer matches the physical AER capability. Bound the read to the physical AER registers, header through the 16 byte Header Log. Zero the destination first so the software-only fields are deterministic. Fixes: 6ac07883dbb5 ("cxl/pci: Add RCH downstream port error logging") Reported-by: Sashiko Cc: stable@vger.kernel.org Signed-off-by: Terry Bowman Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260803221810.3685703-2-terry.bowman@amd.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6f9b62687a3832528d60d50bf914b99695c8c893 Author: Terry Bowman Date: Fri Sep 4 10:32:45 2026 -0400 cxl/pci: Move CXL driver's RCH error handling into core/ras_rch.c [ Upstream commit 0ff60f2ec3e4043a442e805f80f8a2445113ec8f ] Restricted CXL Host (RCH) protocol error handling uses a procedure distinct from the CXL Virtual Hierarchy (VH) handling. This is because of the differences in the RCH and VH topologies. Improve the maintainability and add ability to enable/disable RCH handling. Move and combine the RCH handling code into a single block conditionally compiled with the CONFIG_CXL_RCH_RAS kernel config. Signed-off-by: Terry Bowman Reviewed-by: Jonathan Cameron Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260114182055.46029-9-terry.bowman@amd.com Signed-off-by: Dan Williams Signed-off-by: Dave Jiang Stable-dep-of: 29458e62d082 ("cxl/ras: Fix cxl_rch_get_aer_info() out-of-bounds AER register read") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 153b5ecd29ed055562400bc17c91df3fd869b0ce Author: Neill Kapron Date: Fri Sep 4 10:29:39 2026 -0400 usb: gadget: f_fs: Fix Use-After-Free in AIO error path [ Upstream commit e78dcb1f7ec271449c54984dc90c62a5ba272de7 ] In ffs_epfile_write_iter() and ffs_epfile_read_iter(), when ffs_epfile_io() fails with an error other than -EIOCBQUEUED, the io_data structure (`p`) is freed. However, for AIO operations, the kiocb cancel function was already armed and kiocb->private was set to `p`. If a concurrent cancel operation (such as sys_io_cancel()) executes after ffs_epfile_io() fails but before the function frees `p`, a Use-After-Free can occur when the cancellation handler accesses the freed pointer. To securely fix this race condition, we must properly un-arm the cancellation. Invoking `kiocb->ki_complete()` does exactly this by acquiring `ctx->ctx_lock` and safely removing the kiocb from the active sequence. In doing so, it ensures that a parallel io_cancel can no longer discover the kiocb, effectively closing the race window. We then return -EIOCBQUEUED to notify the VFS layer that the kiocb has been consumed and it should avoid attempting to complete the request again or triggering subsequent completion handlers. Fixes: de2080d41b5d ("gadget/function/f_fs.c: close leaks") Cc: stable@vger.kernel.org Reported-by: Xingyu Jin Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Neill Kapron Link: https://patch.msgid.link/20260724235100.106011-1-nkapron@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f3d31484b3f26d63c09e5569ebfaa1079a17f171 Author: Gabriel Prostitis Date: Fri Sep 4 10:29:38 2026 -0400 USB: gadget: ffs: fix mm lifetime handling [ Upstream commit 5eb5c72c72fef76cb765ef1669b62b6a3ba1bfc8 ] io_data stores a pointer to the submitting task's mm_struct, but does not currently hold a reference to it while async requests are pending. This can result in a use-after-free if the task exits before completion handling finishes. Take a reference with mmgrab() when queuing the read request and release it with mmdrop() on request completion. Reported-by: Gabriel Prostitis Signed-off-by: Gabriel Prostitis Link: https://patch.msgid.link/20260601-mm-uaf-fix-v2-1-3c942a707bce@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: e78dcb1f7ec2 ("usb: gadget: f_fs: Fix Use-After-Free in AIO error path") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 06c76d3c389ff504052f64b1acee44651bd847fa Author: Brendan Jackman Date: Fri Sep 4 09:50:25 2026 -0400 mm/page_alloc: don't spin_trylock() in NMI on UP [ Upstream commit 3105ae628fb785d48b49256468be4f21a7b3cfc0 ] Patch series "mm/page_alloc: fixes for free_pages_nolock() on RT/UP". Pre-existing bugs found by Sashiko during review of this other series: https://lore.kernel.org/all/20260703-alloc-trylock-v5-0-c87b714e19d3@google.com/ I have not reproduced these bugs, and I suspect there is no real-world user that is affected by them. This patch (of 2): As noted in can_spin_trylock(), using this is unsafe in this context. commit 620b46ed6ae17 ("mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP") fixed this on the alloc side but missed the free side. Impact: If BPF programs using these features in NMI (probably tracing) are present on non-SMP builds this might crash the kernel and is probably exploitable by local attackers for privilege escalation. Link: https://lore.kernel.org/20260715-alloc-nolock-fixes-v1-0-fadc49952dda@google.com Link: https://lore.kernel.org/20260715-alloc-nolock-fixes-v1-1-fadc49952dda@google.com Fixes: 8c57b687e833 ("mm, bpf: Introduce free_pages_nolock()") Signed-off-by: Brendan Jackman Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260703-alloc-trylock-v5-0-c87b714e19d3%40google.com?part=18 Reviewed-by: Vlastimil Babka (SUSE) Reviewed-by: Harry Yoo (Oracle) Cc: Brendan Jackman Cc: Alexei Starovoitov Cc: Johannes Weiner Cc: Michal Hocko Cc: Sebastian Andrzej Siewior Cc: Shakeel Butt Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 22bbde1960d1d90f21530a06e8fd1f2b357688db Author: Roger Pau Monne Date: Fri Sep 4 06:30:47 2026 -0400 x86/xen: fix init of balloon stats again [ Upstream commit 5d00a11d484e7b31a358cd81afebccb4602dbe8c ] The handling of extra memory regions done in balloon_add_regions() is not correct for PV guests, since the initial target is set to reflect the real memory the system has, not what's described on the memory map, which can be higher if memory != maxmem. Introduce separate logic for addition vs subtraction in balloon_add_regions() and handle extra regions correctly by adding them to the total amount of pages, instead of subtracting from the current and target pages amounts. In the common case PV domU/dom0 and PVH dom0 will use the addition path, since the initial target reflects the real assigned memory. HVM and PVH domUs use the subtraction path, since the target is set based on the amount of memory reported in the memory map, without accounting for released regions. Fixes: 87af633689ce ("x86/xen: fix balloon target initialization for PVH dom0") Fixes: 0949c646d646 ("Partial revert "x86/xen: fix balloon target initialization for PVH dom0"") Signed-off-by: Roger Pau Monné Cc: stable@vger.kernel.org Reviewed-by: Juergen Gross Tested-by: Matthias Goergens Signed-off-by: Juergen Gross Message-ID: <20260805094008.95778-1-roger@xenproject.org> Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6f53c64a880ff353512c1a8b89e8ac4c2f5b0322 Author: Roger Pau Monne Date: Fri Sep 4 06:30:46 2026 -0400 xen/balloon: improve accuracy of initial balloon target for dom0 [ Upstream commit b13cd24c15d74f6dfcddf0d53ae6efb58d3f0461 ] The dom0 balloon target set by the toolstack is the value returned by XENMEM_current_reservation. Do the same in the kernel balloon driver and set the current allocation to the value returned by XENMEM_current_reservation. On my test system this causes the kernel balloon driver target to exactly match the value set by the toolstack in xenstore. Note this approach can be used by both PV and PVH dom0s, as the toolstack always uses XENMEM_current_reservation to set the initial target regardless of the dom0 type. Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260128110510.46425-3-roger.pau@citrix.com> Stable-dep-of: 5d00a11d484e ("x86/xen: fix init of balloon stats again") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b4a6050bde9ec93e2cee2a1c8189b9b20e9dc12f Author: Li Xiasong Date: Thu Sep 3 20:20:22 2026 -0400 mm/slub: fix missing debugfs entries for caches created before sysfs init [ Upstream commit 7e98f856395618011c517f767fb80ac3fe90de2b ] slab_debugfs_init() creates the slab debugfs root at device initcall time, while slab_sysfs_init() moves slab_state to FULL at late initcall time. SLAB_STORE_USER caches created in this window miss their debugfs entries because do_kmem_cache_create() skips debugfs_slab_add() when slab_state <= UP. This was observed with MPTCP's request_sock_subflow_v6 cache, whose slab debugfs directory was missing. The affected window is: slab_debugfs_init() slab_debugfs_root = debugfs_create_dir(...) list_for_each_entry(s, &slab_caches, list) debugfs_slab_add(s) kmem_cache_create(..., SLAB_STORE_USER, ...) do_kmem_cache_create() if (slab_state <= UP) return without debugfs entries slab_sysfs_init() slab_state = FULL Initialize the debugfs root and add debugfs entries while holding slab_mutex, walking slab_caches exactly once and handling both sysfs and debugfs entries in the same pass. This gives the sysfs and debugfs initialization an explicit order and prevents caches from being created between the debugfs scan and slab_state reaching FULL. Gate the new slab_late_init() on either sysfs or debugfs being enabled, with the slab_kset creation and alias_list processing factored into helpers that have empty no-sysfs variants, as suggested by Vlastimil Babka. On slab_kset_init() failure, slab_state stays below FULL so kmem_cache_create() keeps taking the early-boot path, matching prior behavior. Guard debugfs_slab_release() against an uninitialized debugfs root, since the root is now created later and a cache may be released before it exists. Fixes: 1a5ad30b89b4 ("mm: slub: make slab_sysfs_init() a late_initcall") Cc: stable@vger.kernel.org Suggested-by: Vlastimil Babka Signed-off-by: Li Xiasong Link: https://patch.msgid.link/20260729101849.3734287-1-lixiasong1@huawei.com Reviewed-by: Harry Yoo (Oracle) Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d08ea0fd703868c714fee3a2e842bcc776ccdf99 Author: Vlastimil Babka Date: Thu Sep 3 20:20:21 2026 -0400 mm/slab: move and refactor __kmem_cache_alias() [ Upstream commit 8598351edc42f38d2a1eaed9abca39c98e7b0bbf ] Move __kmem_cache_alias() to slab_common.c since it's called by __kmem_cache_create_args() and calls find_mergeable() that both are in this file. We can remove two slab.h declarations and make them static. Instead declare sysfs_slab_alias() from slub.c so that __kmem_cache_alias() can keep calling it. Add args parameter to __kmem_cache_alias() and find_mergeable() instead of align and ctor. With that we can also move the checks for usersize and sheaf_capacity there from __kmem_cache_create_args() and make the result more symmetric with slab_unmergeable(). No functional changes intended. Reviewed-by: Harry Yoo Reviewed-by: Suren Baghdasaryan Reviewed-by: Liam R. Howlett Signed-off-by: Vlastimil Babka Stable-dep-of: 7e98f8563956 ("mm/slub: fix missing debugfs entries for caches created before sysfs init") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e7bd804e3c7194c8a19732e64cb6dd9f46de9c6a Author: Dev Jain Date: Thu Sep 3 20:13:42 2026 -0400 mm/rmap: use huge_ptep_get() in try_to_migrate_one() [ Upstream commit 9be12ffa78cd087d41086f937a156435d4e588e9 ] try_to_migrate_one() is used by folio migration to replace a present mapping with a migration entry. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads the huge pte entry with ptep_get(). On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave. It is not clear whether this has a trivially visible effect to userspace. Use huge_ptep_get() to dereference a huge pte pointer. Commit a98a2f0c8ce1 copied the bug from try_to_unmap_one into try_to_migrate_one. [akpm@linux-foundation.org: coding-style cleanups] Link: https://lore.kernel.org/20260703114202.365553-4-dev.jain@arm.com Fixes: a98a2f0c8ce1 ("mm/rmap: split migration into its own function") Signed-off-by: Dev Jain Acked-by: Muchun Song Acked-by: David Hildenbrand (Arm) Cc: Alistair Popple Cc: Andi Kleen Cc: Anshuman Khandual Cc: Byungchul Park Cc: Catalin Marinas Cc: Dave Hansen Cc: Gregory Price Cc: Harry Yoo Cc: "Huang, Ying" Cc: Jann Horn Cc: Josh Poimboeuf Cc: Joshua Hahn Cc: Jun'ichi "Nick" Nomura Cc: Kiryl Shutsemau Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Mel Gorman Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Pedro Falcato Cc: Rakie Kim Cc: Ralph Campbell Cc: Rik van Riel Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Will Deacon Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 54a58d6656dd403b686b247f0bad8507cbfb45df Author: Kairui Song Date: Thu Sep 3 13:31:51 2026 -0400 mm/mglru: fix and remove redundant unevictable folio handling [ Upstream commit f7e698e326b239a91ea15844817551921209e826 ] sort_folio() has a shortcut for moving folios that are no longer evictable but are still sitting on a generation list. However, this shortcut is buggy. It does not follow the PG_lru usage convention, and it has a more serious issue. Unevictable folios are not threaded on lists[LRU_UNEVICTABLE], so that folio->lru can be reused to hold folio->mlock_count (see the comment in lruvec_init()). Hence lruvec_add_folio() skips the list_add() for them, and every other place that turns a folio unevictable initialises mlock_count explicitly: lru_add() sets it to 0, __mlock_folio() and __mlock_new_folio() set it to !!folio_test_mlocked(folio). sort_folio() sets nothing, and the lru_gen_del_folio() right above it may have already poisoned folio->lru via list_del(), so mlock_count ends up aliasing LIST_POISON2, which reads as 0x122, i.e. 290. The result is user visible. On munlock, __munlock_folio() decrements that bogus count, finds it still non-zero and bails out before clearing PG_mlocked, so the folio remains unevictable and the Mlocked accounting stays inflated until the folio is freed. The shortcut also touches the LRU flags in the wrong order. It calls lru_gen_del_folio() while PG_lru is still set, so a concurrent folio_test_clear_lru() (e.g. compaction, folio_isolate_lru()) can succeed on a folio that has already been taken off the generation list, which may lead to unexpected behavior. So fix it by isolating them as common folios and letting the generic shrink path cull them. This matches the classical LRU behavior, and there should be no visible effect on the generic eviction or isolation behavior. There is no performance concern either, such a folio goes through this once, and then it is off the generation lists for good. Link: https://lore.kernel.org/20260812-mglru-mlock-fix-v2-1-a3fec5853c08@tencent.com Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation") Signed-off-by: Kairui Song Reviewed-by: Barry Song Reviewed-by: Baolin Wang Cc: Axel Rasmussen Cc: Brian Geffon Cc: David Hildenbrand Cc: Jan Alexander Steffens (heftig) Cc: Johannes Weiner Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Oleksandr Natalenko Cc: Shakeel Butt Cc: Steven Barrett Cc: Suleiman Souhlal Cc: Wei Xu Cc: Yuanchu Xie Cc: Yu Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d4812d21689f1fa7d88a132e7f57cd6ebc245c0c Author: Kairui Song Date: Thu Sep 3 13:31:50 2026 -0400 mm/mglru: use the common routine for dirty/writeback reactivation [ Upstream commit 75d4c3f5fb980de1b620adede47e43dff4d6a5f3 ] Currently MGLRU will move the dirty writeback folios to the second oldest gen instead of reactivate them like the classical LRU. This might help to reduce the LRU contention as it skipped the isolation. But as a result we will see these folios at the LRU tail more frequently leading to inefficient reclaim. Besides, the dirty / writeback check after isolation in shrink_folio_list is more accurate and covers more cases. So instead, just drop the special handling for dirty writeback, use the common routine and re-activate it like the classical LRU. This should in theory improve the scan efficiency. These folios will be rotated back to LRU tail once writeback is done so there is no risk of hotness inversion. And now each reclaim loop will have a higher success rate. This also prepares for unifying the writeback and throttling mechanism with classical LRU, we keep these folios far from tail so detecting the tail batch will have a similar pattern with classical LRU. The micro optimization that avoids LRU contention by skipping the isolation is gone, which should be fine. Compared to IO and writeback cost, the isolation overhead is trivial. And using the common routine also keeps the folio's referenced bits (tier bits), which could improve metrics in the long term. Also no more need to clean reclaim bit as the common routine will make use of it. Note the common routine updates a few throttling and writeback counters, which are not used, and never have been for the MGLRU case. We will start making use of these in later commits. Link: https://lore.kernel.org/20260428-mglru-reclaim-v7-10-02fabb92dc43@tencent.com Signed-off-by: Kairui Song Reviewed-by: Axel Rasmussen Reviewed-by: Barry Song Reviewed-by: Baolin Wang Cc: Chen Ridong Cc: Chris Li Cc: David Hildenbrand Cc: David Stevens Cc: Johannes Weiner Cc: Kalesh Singh Cc: Leno Hou Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Vernon Yang Cc: Wei Xu Cc: Yafang Cc: Yuanchu Xie Cc: Yu Zhao Signed-off-by: Andrew Morton Stable-dep-of: f7e698e326b2 ("mm/mglru: fix and remove redundant unevictable folio handling") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 09505232eced5f1c42902d8f28740f070c3fc6dc Author: Muchun Song Date: Thu Sep 3 12:33:47 2026 -0400 mm/hugetlb: initialize gigantic bootmem hugepage struct pages earlier [ Upstream commit b1b7c045e808c761b1cc8c19b3040fadedda3fef ] Gigantic bootmem HugeTLB pages are currently initialized from hugetlb_init(), but page_alloc_init_late() runs earlier and walks pageblocks to determine zone contiguity. If a bootmem HugeTLB region is marked noinit, set_zone_contiguous() can observe still-uninitialized struct pages through __pageblock_pfn_to_page(). This may not trigger an immediate failure, but it can make set_zone_contiguous() compute the wrong zone contiguity state. If extra poisoned-page checks are added in this path, such as PF_POISONED_CHECK() in page_zone_id(), it can also trigger an early boot panic. Initialize gigantic bootmem HugeTLB struct pages from page_alloc_init_late(), before zone contiguity is evaluated, so later page allocator setup only sees valid struct page state. This also makes the initialization order more natural, as struct pages should be initialized before later code inspects them. Link: https://lore.kernel.org/20260612035903.2468601-5-songmuchun@bytedance.com Fixes: fde1c4ecf916 ("mm: hugetlb: skip initialization of gigantic tail struct pages if freed by HVO") Signed-off-by: Muchun Song Acked-by: Mike Rapoport (Microsoft) Acked-by: Oscar Salvador Cc: "Aneesh Kumar K.V" Cc: David Hildenbrand Cc: Frank van der Linden Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Oscar Salvador (SUSE) Cc: "Ritesh Harjani (IBM)" Cc: Usama Arif Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton [ adapted the header context and omitted a comment update for an absent HVO helper. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit daeffb841bb966a64bca893dce9ecc392f1d09aa Author: Kiryl Shutsemau Date: Thu Sep 3 12:33:46 2026 -0400 mm/hugetlb: refactor code around vmemmap_walk [ Upstream commit c0b495b91a47b6c5ee54cf00e620dbadeb884253 ] To prepare for removing fake head pages, the vmemmap_walk code is being reworked. The reuse_page and reuse_addr variables are being eliminated. There will no longer be an expectation regarding the reuse address in relation to the operated range. Instead, the caller will provide head and tail vmemmap pages. Currently, vmemmap_head and vmemmap_tail are set to the same page, but this will change in the future. The only functional change is that __hugetlb_vmemmap_optimize_folio() will abandon optimization if memory allocation fails. Link: https://lkml.kernel.org/r/20260227194302.274384-11-kas@kernel.org Signed-off-by: Kiryl Shutsemau Reviewed-by: Muchun Song Cc: Albert Ou Cc: Alexandre Ghiti Cc: Baoquan He Cc: Christoph Lameter Cc: David Hildenbrand (arm) Cc: David Rientjes Cc: Frank van der Linden Cc: Harry Yoo Cc: Huacai Chen Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Oscar Salvador Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Roman Gushchin Cc: Usama Arif Cc: Vlastimil Babka Cc: WANG Xuerui Cc: Zi Yan Signed-off-by: Andrew Morton Stable-dep-of: b1b7c045e808 ("mm/hugetlb: initialize gigantic bootmem hugepage struct pages earlier") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b662d7bcb5ecde2257ca2594512803aa77f983df Author: Kiryl Shutsemau (Meta) Date: Thu Sep 3 12:33:45 2026 -0400 mm/hugetlb: defer vmemmap population for bootmem hugepages [ Upstream commit 209e6d9eb13aaf1b6e0fc6f76afc00d055e5ba12 ] Currently, the vmemmap for bootmem-allocated gigantic pages is populated early in hugetlb_vmemmap_init_early(). However, the zone information is only available after zones are initialized. If it is later discovered that a page spans multiple zones, the HVO mapping must be undone and replaced with a normal mapping using vmemmap_undo_hvo(). Defer the actual vmemmap population to hugetlb_vmemmap_init_late(). At this stage, zones are already initialized, so it can be checked if the page is valid for HVO before deciding how to populate the vmemmap. This allows us to remove vmemmap_undo_hvo() and the complex logic required to rollback HVO mappings. In hugetlb_vmemmap_init_late(), if HVO population fails or if the zones are invalid, fall back to a normal vmemmap population. Postponing population until hugetlb_vmemmap_init_late() also makes zone information available from within vmemmap_populate_hvo(). Link: https://lkml.kernel.org/r/20260227194302.274384-10-kas@kernel.org Signed-off-by: Kiryl Shutsemau (Meta) Acked-by: David Hildenbrand (Arm) Cc: Albert Ou Cc: Alexandre Ghiti Cc: Baoquan He Cc: Christoph Lameter Cc: David Rientjes Cc: Frank van der Linden Cc: Harry Yoo Cc: Huacai Chen Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Oscar Salvador Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Roman Gushchin Cc: Usama Arif Cc: Vlastimil Babka Cc: WANG Xuerui Cc: Zi Yan Signed-off-by: Andrew Morton Stable-dep-of: b1b7c045e808 ("mm/hugetlb: initialize gigantic bootmem hugepage struct pages earlier") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit edc017be82664226bbbf0af8c8d61873380249db Author: FUJITA Tomonori Date: Thu Sep 3 11:01:02 2026 -0400 rust: bug: prevent dead_code warning from warn_on!'s flags constant [ Upstream commit e66cfc29e0d06fec34c06bb40d4d281f595677b1 ] Fix the following dead_code warning on some configurations in an atomic development branch: warning: constant `WARN_ON_FLAGS` is never used --> linux/rust/kernel/bug.rs:126:19 | 126 | const WARN_ON_FLAGS: u32 = $crate::bug::bugflag_taint($crate::bindings::TAINT_WARN); | ^^^^^^^^^^^^^ | ::: linux/rust/kernel/sync/srcu.rs:106:12 | 106 | if crate::warn_on!( | ____________- 107 | | // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct` 108 | | // and `srcu_readers_active()` only checks the active reader count. 109 | | unsafe { bindings::srcu_readers_active(ptr) } 110 | | ) { | |_________- in this macro invocation | = note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default = note: this warning originates in the macro `crate::warn_on` (in Nightly builds, run with -Z macro-backtrace for more info) The warn_on! macro always defines a WARN_ON_FLAGS constant and hands it to warn_flags!. On configurations where warn_flags! does not reference its flags argument (the LOONGARCH/ARM variant, which only calls WARN_ON(), and the !CONFIG_BUG no-op variant), the constant is left unused and triggers a dead_code warning. warn_flags! is the macro that accepts (and here discards) the flags argument, so make it responsible for the argument it drops. Also rename `_COND_STR` to `COND_STR` and consume `$file` for consistency. Fixes: dff64b072708 ("rust: Add warn_on macro") Signed-off-by: FUJITA Tomonori Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260801024841.786664-1-tomo@flapping.org [ Added newlines. - Miguel ] Signed-off-by: Miguel Ojeda [ adapted unreachable flag consumption to the older one-argument warn_flags! interface. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cf24ce48d60225fdbee68ed2058763a1fd172ff3 Author: Chen Linxuan Date: Thu Sep 3 08:22:36 2026 -0400 pidfd: hold exec_update_lock around namespace ioctl [ Upstream commit 9688a46802939da28f00cb40e8129615d5d4af39 ] The PIDFD_GET_*_NAMESPACE ioctls in pidfd_ioctl() perform a filesystem credentials ptrace access check before handing out a namespace file descriptor. The accompanying comment states that the code "mirrors nsfs behavior", but, unlike the corresponding procfs paths, it does so without holding the target task's exec_update_lock. proc_ns_get_link() and proc_ns_readlink() both take exec_update_lock for reading around the ptrace check and the namespace lookup, so that the credentials used for the access decision match those of the task when its namespace is read. Without it, a caller can pass the check against the target's old credentials and then read the namespace after the target has execve()'d a setuid binary and committed new credentials -- accessing namespace information it should have been denied. Hold exec_update_lock for reading around the ptrace check and the namespace lookup so that pidfd truly mirrors nsfs behavior, as the comment already claims. open_namespace() itself runs outside the lock: once a namespace reference is obtained it carries its own refcount and is opened with the caller's own credentials, so a concurrent execve() on the target can no longer affect the outcome. Fixes: 5b08bd408534 ("pidfs: allow retrieval of namespace file descriptors") Cc: stable@vger.kernel.org Signed-off-by: Chen Linxuan Link: https://patch.msgid.link/20260731-pidfd-exec-update-lock-v1-1-b388f2f3a8b0@black-desk.cn Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7aa9ab5321589ac80dbb05857de9082eeb8ed01a Author: Christian Brauner Date: Thu Sep 3 08:22:35 2026 -0400 pidfs: simplify PIDFD_GET__NAMESPACE ioctls [ Upstream commit a71e4f103aed69e7a11ea913312726bb194c76ee ] We have reworked namespaces sufficiently that all this special-casing shouldn't be needed anymore Link: https://patch.msgid.link/20251117-eidesstattlich-apotheke-36d2e644079f@brauner Signed-off-by: Christian Brauner Stable-dep-of: 9688a4680293 ("pidfd: hold exec_update_lock around namespace ioctl") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2fa220bc0f84597cb6de665e5b5021c5901ddf00 Author: Vivek Parikh Date: Thu Sep 3 08:22:32 2026 -0400 ovl: fix double end_creating() on the casefold-mismatch path [ Upstream commit 077ab8985ee278c3d8618182d335b0f0cd919e16 ] ovl_create_real() releases the new dentry twice when the casefold consistency check fails. The S_IFDIR branch calls end_creating() and sets err, then falls through to the common out: label which calls end_creating() on the same dentry again: case S_IFDIR: newdentry = ovl_do_mkdir(ofs, dir, newdentry, attr->mode); err = PTR_ERR_OR_ZERO(newdentry); if (!err && ofs->casefold != ovl_dentry_casefolded(newdentry)) { pr_warn_ratelimited(...); end_creating(newdentry); /* first */ err = -EINVAL; } break; ... if (err) goto out; ... out: if (err) { end_creating(newdentry); /* second, same dentry */ return ERR_PTR(err); } end_creating() is end_dirop(), which does inode_unlock() on the parent and dput() on the dentry, so the parent directory's i_rwsem is unlocked twice and the dentry is put twice. The second unlock releases a lock that is not held, which is what wedges every later creation under that parent, and the second dput() drops a reference that was never taken. The branch was added by commit dfc7da402ccc ("ovl: Check for casefold consistency when creating new dentries") as a bare dput(), which already released the reference twice; commit fe497f0759e0 ("VFS: change vfs_mkdir() to unlock on failure.") converted both sites to end_creating(), adding the double unlock. This is reachable by an unprivileged user. The casefold consistency of the layers is validated at mount time in ovl_parse_layer(), and again on every lookup in ovl_lookup_single(), but ofs->workdir is the internal "work" subdirectory created inside the user-supplied workdir, and that subdirectory is not re-checked. Marking it casefolded after the mount therefore makes every ovl_create_temp() inherit the wrong state - and that path reaches ovl_create_real() through ovl_start_creating_temp(), which uses start_creating() with a generated name and so never runs the lookup-time check. unshare -Urm mount -t tmpfs -o casefold=utf8-12.1.0 tmpfs mnt mkdir -p mnt/lower/d mnt/upper mnt/work mnt/merged mount -t overlay ovl -o lowerdir=mnt/lower,\ upperdir=mnt/upper,workdir=mnt/work mnt/merged chattr +F mnt/work/work mkdir mnt/merged/d/sub # directory copy-up overlayfs: wrong inherited casefold (work/#5) and the next copy-up blocks forever on the parent's i_rwsem: mkdir D start_creating+0x65/0xb0 ovl_start_creating_temp+0xb0/0xe0 [overlay] ovl_create_temp+0xa3/0x1d0 [overlay] ovl_copy_up_one+0x1f1c/0x21c0 [overlay] ovl_copy_up_flags+0xf5/0x140 [overlay] ovl_create_object+0xb7/0x220 [overlay] ovl_mkdir+0x23/0x40 [overlay] Drop the end_creating() from the branch and let out: own the cleanup, which is what every other error path in this function already does. Fixes: dfc7da402ccc ("ovl: Check for casefold consistency when creating new dentries") Cc: stable@vger.kernel.org Signed-off-by: Vivek Parikh Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Amutable) [ adapted end_creating() cleanup removal to the older dput() API ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1c4b90902c05cc94ef64fa55d0222d8ac36d1401 Author: Thorsten Blum Date: Tue Sep 1 17:44:16 2026 -0400 crypto: atmel-ecc - avoid stale fallback key after set_secret failure [ Upstream commit f07a0d251db7606e4792d2610788fbcc7b2c0d12 ] Clear ->do_fallback before decoding a new ECDH secret and enable it only after the software fallback accepts a caller-provided private key. This avoids using a stale fallback key should crypto_kpp_set_secret() fail. Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5c1e763b713f053c52819c6eca1383951db03190 Author: Thorsten Blum Date: Tue Sep 1 17:44:15 2026 -0400 crypto: atmel-ecc - clean up and improve ECDH comments [ Upstream commit 3e84fb698abada239d3e35ed3d52a24dbfda5f6a ] Improve the kerneldoc for struct atmel_ecdh_ctx by removing the stale "unsupported curves" wording, since the device only supports a single curve (P-256), and move the set_secret() constraint to the description. In atmel_ecdh_set_secret(), clarify that the device generates the private key, and drop the redundant "only supports NIST P256" comment. In atmel_ecdh_done() and atmel_ecdh_generate_public_key(), clarify the truncation comments. Also note that a P-256 public key consists of two 32-byte coordinates in atmel_ecdh_compute_shared_secret(), and remove the unnecessary fall-through comment and other redundant comments. Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Stable-dep-of: f07a0d251db7 ("crypto: atmel-ecc - avoid stale fallback key after set_secret failure") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e39767b9a54d9144e8e534ac5a24053dbee11d26 Author: Thorsten Blum Date: Tue Sep 1 17:44:14 2026 -0400 crypto: atmel-ecc - replace min_t with min [ Upstream commit 5b085b2a038a1458f9398cb3b3b03cba6e38e1e0 ] Use the simpler min() macro since the values are all unsigned and compatible. Signed-off-by: Thorsten Blum Reviewed-by: David Laight Signed-off-by: Herbert Xu Stable-dep-of: f07a0d251db7 ("crypto: atmel-ecc - avoid stale fallback key after set_secret failure") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fc933a4a419ba8a75da28666a018602c44846953 Author: Vinicius Costa Gomes Date: Tue Sep 1 15:43:49 2026 -0400 crypto: iaa - unmap dst before software fallback on decompress [ Upstream commit 94a25930477113730372e0fa2985da4c5ac95c9a ] On a hardware analytics error, decompress retries through the software fallback, which writes req->dst with the CPU while it is still mapped DMA_FROM_DEVICE. With SWIOTLB active the later dma_unmap_sg() copies the stale bounce buffer over req->dst, corrupting the result. Unmap before the fallback runs. The async path unmaps inline; the sync path signals the retry with -EAGAIN so iaa_comp_adecompress() runs the fallback after unmapping. Fixes: 2ec6761df889 ("crypto: iaa - Add support for deflate-iaa compression algorithm") Cc: stable@vger.kernel.org Signed-off-by: Vinicius Costa Gomes Signed-off-by: Herbert Xu [ adapted unavailable iaa_unmap_src() calls to single-entry dma_unmap_sg() calls ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4fcbc9f4082ca622271f213ec664554aca8cab2d Author: Giovanni Cabiddu Date: Tue Sep 1 15:43:48 2026 -0400 crypto: iaa - fall back to software for multi-entry scatterlists [ Upstream commit c7fdfd2bee1cf1448e5244da1a734e680f634b02 ] IAA cannot process source or destination scatterlists with more than one entry directly. Instead of failing these requests, route them through a separate deflate acomp transform and keep the request alive in software. The IAA driver has never handled multi-entry scatterlists, but the limitation was latent until commit e2c3b6b21c77 ("mm: zswap: use SG list decompression APIs from zsmalloc") made zswap pass the raw zsmalloc SG list directly to crypto drivers, so objects spanning multiple pages now reach IAA as multi-entry sources and would otherwise fail decompression. Fallback to the generic DEFLATE implementation for scatterlists with more than one entry. After the multi-entry cases fall back early, simplify the DMA mapping path to a single scatterlist entry and fall back on mapping failure as well. Add counters to track the number of requests processed by the software implementation on the compression direction. Fixes: 2ec6761df889 ("crypto: iaa - Add support for deflate-iaa compression algorithm") Fixes: e2c3b6b21c77 ("mm: zswap: use SG list decompression APIs from zsmalloc") Cc: stable@vger.kernel.org Signed-off-by: Giovanni Cabiddu Signed-off-by: Vinicius Costa Gomes Signed-off-by: Herbert Xu Stable-dep-of: 94a259304771 ("crypto: iaa - unmap dst before software fallback on decompress") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1517d1996b5236fe69eccd9d253f725e06996eb1 Author: Eric Dumazet Date: Tue Sep 1 07:20:04 2026 -0400 vlan: fix skb_under_panic and races when toggling HW VLAN offload [ Upstream commit 447cbe95ebb95392b5d8f6a01c0556826919ce23 ] Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(), which dynamically changed vlandev->hard_header_len. This causes two issues: 1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2) read dev->hard_header_len without holding RTNL lock. Mutating hard_header_len dynamically under RTNL creates a data race where upper layers reserve insufficient headroom based on a stale hard_header_len, resulting in skb_under_panic when vlan_dev_hard_header() is called. 2. In addition, vlan_transfer_features() updated hard_header_len without updating header_ops, causing a mismatch between allocated headroom and header creation. Always setting dev->hard_header_len = real_dev->hard_header_len and dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN unconditionally ensures: - dev->hard_header_len remains 100% static and immutable at real_dev->hard_header_len, eliminating all dynamic runtime updates and data races on hard_header_len. - Upper layers allocating skbs via LL_RESERVED_SPACE() will always reserve sufficient headroom for software VLAN tag insertion (real_dev->hard_header_len + real_dev->needed_headroom + VLAN_HLEN). - vlandev inherits real_dev->needed_tailroom so underlying trailer/padding/ICV requirements are honored. - AF_PACKET SOCK_RAW network header offsets remain correctly aligned at real_dev->hard_header_len. - vlan_header_ops is used unconditionally. Note to stable teams: Make sure to backport these commits: e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") cef51860becd ("macvlan: inherit needed_headroom and needed_tailroom from lowerdev") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Tangxin Xie Closes: https://lore.kernel.org/netdev/99d678ae-c7b2-4b44-b534-b8320679deb3@h-partners.com/ Cc: # 3.19: e16e960d55a4: ipvlan: inherit needed_headroom and needed_tailroom from phy_dev Cc: # 3.19: cef51860becd: macvlan: inherit needed_headroom and needed_tailroom from lowerdev Cc: # 3.19 Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260811085246.2267779-1-edumazet@google.com Signed-off-by: Jakub Kicinski [ moved the vlan_transfer_features() hunk to its pre-refactor location in vlan.c ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ed25ed29034ddc3dbe451ccbaa58ab9932f99d8b Author: Kyle Zeng Date: Tue Sep 1 07:11:07 2026 -0400 net/packet: defer vmalloc TX_RING free until skbs finish [ Upstream commit 992cc9f94ca924089a506ba9b327caa9af797529 ] AF_PACKET TX_RING skbs keep a raw pointer to their ring frame. The skb page references preserve page-backed ring blocks after pg_vec is freed, but they do not preserve a vmalloc mapping. tpacket_destruct_skb() currently drops the pending reference before writing the timestamp and TP_STATUS_AVAILABLE to the frame. Move the decrement after those stores. The smp_wmb() in __packet_set_status() orders the frame stores before the decrement. Also recheck pending TX frames under pg_vec_lock before non-closing ring replacement, so a racing send cannot add a pending skb between the initial check and the ring swap. Ring allocation can produce a mixture of page-backed and vmalloc-backed blocks. Allocate deferred-work storage during TX ring setup when the first vmalloc-backed block is encountered, and keep its pointer in the pg_vec allocation header. If allocation fails, return -ENOMEM from ring setup. On socket close, a non-NULL pointer identifies a vmalloc-backed vector without a scan. If TX skbs remain, defer the whole vector to system_long_wq. After pg_vec is detached, a late destructor can skip the pending decrement. Use socket write-memory accounting as the deferred lifetime gate instead: an skb remains charged through its final sock_wfree(), after all ring-frame accesses. The delayed work retains a socket reference and reschedules itself until no TX skbs remain. Move pending_refcnt release to packet_sock_destruct() so late skb destructors and deferred cleanup can safely use it after packet_release(). Page-backed teardown remains synchronous, and no lock is added to the TX completion hot path. Fixes: b013840810c2 ("packet: use percpu mmap tx frame pending refcount") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/netdev/20260721015824.45829-1-kylebot@openai.com/ Suggested-by: Eric Dumazet Suggested-by: Willem de Bruijn Reviewed-by: Willem de Bruijn Signed-off-by: Kyle Zeng Link: https://patch.msgid.link/20260816235646.76500-1-kylebot@openai.com Signed-off-by: Jakub Kicinski [ adapted the kzalloc_objs() allocation context to the older kcalloc() form ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0f930904452945f409eeeb0c9afa08bf27185cb1 Author: Miklos Szeredi Date: Mon Aug 31 12:43:13 2026 -0400 fuse: fix race between interrupt and resend [ Upstream commit ed9c881f3b498383f73c42712b359419da42a7b0 ] After commit f8fce75fedf7 ("fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req") the WARN_ON(!list_empty(&req->intr_entry)) in fuse_request_free() still triggers due to the following race: In request_wait_answer() if (test_bit(FR_SENT, &req->flags)) -> returns true In fuse_chan_resend() clear_bit(FR_SENT, &req->flags) In request_wait_answer() queue_interrupt(req) Fix by: - move clearing FR_SENT inside fpq->lock - move setting FR_PENDING inside fiq->lock - recheck FR_SENT after acquiring fiq->lock in fuse_dev_queue_interrupt() Reported-by: zdi-disclosures@trendmicro.com Fixes: f8fce75fedf7 ("fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req") Cc: stable@vger.kernel.org # 6.9 Signed-off-by: Miklos Szeredi [ adjusted context to use `fc->iq` in `fuse_resend()` since `struct fuse_chan` doesn't exist in this tree ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f98640c27cde35fdc516f6144063ff28eaf21f2c Author: Miklos Szeredi Date: Mon Aug 31 12:43:12 2026 -0400 fuse: remove fm arg of args->end callback [ Upstream commit a697d95fcdbb3bbe25cdc29db5542ddcebb831c1 ] Only used by FUSE_INIT and CUSE_INIT, these can store the relevant pointer in their structs derived from fuse_args. Signed-off-by: Miklos Szeredi Stable-dep-of: ed9c881f3b49 ("fuse: fix race between interrupt and resend") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 952f7a6d392b824d1fafd38d2d3321ec931718bd Author: Miklos Szeredi Date: Mon Aug 31 12:43:11 2026 -0400 fuse: split off fuse_args and related definitions into a separate header [ Upstream commit 229f9b9b66ab5be9e015422cf30b97740cfbdc8d ] This is going to be used by both layers (transport and filesystem) Signed-off-by: Miklos Szeredi Stable-dep-of: ed9c881f3b49 ("fuse: fix race between interrupt and resend") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a5bb215dbc34b4c6a5e144ea1416bf66450d519f Author: Joanne Koong Date: Mon Aug 31 12:43:03 2026 -0400 fuse: publish io-uring queues with release semantics [ Upstream commit 42df916e5a5f8fb4b60c8cefb54318d1ec02c580 ] fuse_uring_create_queue() initializes a fuse_ring_queue and then publishes the pointer into ring->queues[qid] with WRITE_ONCE() under the fch->lock. There are several readers that may concurrently be fetching that pointer locklessly and then deferencing it. WRITE_ONCE() doesn't ensure ordering of the queue's field initialization before the ring->queues[qid] pointer assignment. The queue must be published with smp_store_release() so the field initialization is guaranteed to happen before. Readers in paths where the read may happen concurrently with the store need to use READ_ONCE() because any race involving a plain access is undefined. Fixes: 24fe962c86f5 ("fuse: {io-uring} Handle SQEs - register commands") Cc: stable@vger.kernel.org Reviewed-by: Bernd Schubert Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi [ renamed `fch->lock` to `fc->lock` since this tree lacks `struct fuse_chan` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c051f66b621695ad7c8438a9497d79e1f4f05edb Author: Breno Leitao Date: Mon Aug 31 09:27:09 2026 -0400 usb: xhci: bail out of setup if the controller is inaccessible [ Upstream commit 78203d5b54a40f0e36196ebf31c9c7a380fc8811 ] xhci_gen_setup() locates the operational registers using the capability length read from the very first register: xhci->op_regs = hcd->regs + HC_LENGTH(readl(&xhci->cap_regs->hc_capbase)); If the controller is dead or has dropped off the bus, that read returns ~0, HC_LENGTH() truncates it to 0xff, and op_regs ends up 0xff bytes past the page-aligned MMIO base, i.e. unaligned. The first access through it, xhci_halt() -> xhci_handshake() reading op_regs->status, is then an unaligned readl() on device memory. arm64 faults on unaligned device accesses, so instead of xhci_handshake() catching the all-ones value and returning -ENODEV, setup oopses: xhci-pci-renesas 0005:08:00.0: Unable to change power state from D3cold to D0, device inaccessible xhci-pci-renesas 0005:08:00.0: xHCI Host Controller xhci-pci-renesas 0005:08:00.0: new USB bus registered, assigned bus number 1 Unable to handle kernel paging request at virtual address ffff80030a770103 ESR = 0x0000000096000021 FSC = 0x21: alignment fault Internal error: Oops: 0000000096000021 [#1] SMP pc : xhci_halt [xhci_hcd] Call trace: xhci_halt xhci_gen_setup xhci_pci_setup usb_add_hcd usb_hcd_pci_probe xhci_pci_common_probe xhci_pci_renesas_probe This was hit with a Renesas uPD720201 that failed to power up ("Unable to change power state from D3cold to D0, device inaccessible") yet still reached the HCD probe path. Read the capability register once, and if it reads back the all-ones value (as xhci_handshake() and xhci_reset() already test for), abort setup with -ENODEV before op_regs is derived from it. Reading it once also avoids re-reading a register that may change under a concurrent hot-removal. Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260806142113.2436238-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f0ccc2d323d06a9b9124988fcbf18143d4157941 Author: Niklas Neronin Date: Mon Aug 31 09:27:08 2026 -0400 usb: xhci: simplify handling of Structural Parameters 1 values [ Upstream commit df08973556851b29bd78e79db696d992ed1b43f0 ] The 32-bit read-only HCSPARAMS1 register contains the following fields: Bits 7:0 - Number of Device Slots (MaxSlots) Bits 18:8 - Number of Interrupters (MaxIntrs) Bits 23:19 - Reserved Bits 31:24 - Number of Ports (MaxPorts) Since the register value is constant for the lifetime of the controller, it is cached in 'xhci->hcs_params1'. However, platform drivers may override the number of interrupters through a separate variable, 'xhci->max_interrupters', leaving only the maximum slots and ports values still derived from the cached register. To simplify the code and improve readability, replace 'xhci->hcs_params1' with two dedicated 'u8' fields: 'xhci->max_slots' and 'xhci->max_ports'. These values are initialized once and used directly instead of calling 'HCS_MAX_SLOTS()' and 'HCS_MAX_PORTS()' macros. This change reduces code clutter without increasing memory usage. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-16-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman [ Sasha: context conflict in xhci_gen_setup() only. 6.18.y carries fe7892d46921 ("usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits") out of order -- it landed upstream after this commit -- so the "xhci->dma_mask_bits = 64;" line sits exactly where the new max_slots and max_ports assignments are inserted. Kept both, with dma_mask_bits first, which matches the resulting upstream ordering. No functional change; every other hunk is verbatim. ] Stable-dep-of: 78203d5b54a4 ("usb: xhci: bail out of setup if the controller is inaccessible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 46fb722a3bcf0d75fc4dac7a8e2d0493cd7762dc Author: Niklas Neronin Date: Mon Aug 31 09:27:07 2026 -0400 usb: xhci: use cached HCSPARAMS1 value [ Upstream commit 70651cc3f5a4c7cec529f121e36ea3b45ea84778 ] The Structural Parameters 1 (HCSPARAMS1) register is read and cached in 'xhci->hcs_params1' during host controller initialization. Since this register is read-only and its value remains constant for the lifetime of the controller, re-reading it later is unnecessary. Replace subsequent register reads with the cached 'xhci->hcs_params1' value to avoid redundant MMIO access. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-15-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 78203d5b54a4 ("usb: xhci: bail out of setup if the controller is inaccessible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4e141571d0257f4406312a9e5b7cc53511c7d535 Author: Niklas Neronin Date: Mon Aug 31 09:27:06 2026 -0400 usb: xhci: implement USB Port Register Set struct [ Upstream commit f2469d89a70cc6eb3d8141770995a3b251afa6ff ] Previously, each port's 'addr' field pointed to the base of the Host Controller USB Port Register Set, and specific registers were accessed using macros such as (port->addr + PORTPMSC). This patch replaces the raw '__le32 __iomem *addr' pointer with a typed 'struct xhci_port_regs __iomem *port_reg' pointer. With this change, individual registers can be accessed directly through the structure fields: Before: port->addr port->addr + PORTPMSC port->addr + PORTLI port->addr + PORTHLPMC After: port->port_reg->portsc port->port_reg->portpmsc port->port_reg->portli port->port_reg->porthlpmc This improves code readability and makes register access more intuitive by using named struct members instead of pointer arithmetic and macros. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 78203d5b54a4 ("usb: xhci: bail out of setup if the controller is inaccessible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8dbc9c86c3186b342d3c66b83fa991350838dc56 Author: Niklas Neronin Date: Mon Aug 31 09:27:05 2026 -0400 usb: xhci: add USB Port Register Set struct [ Upstream commit 377a91594e008848363641d07f51d2e48f4bdde5 ] Introduce a new struct for the Host Controller USB Port Register Set to enhance readability and maintainability. The Host Controller Operational Registers (struct 'xhci_op_regs') span from offset 0x0 to 0x3FF and consist of fixed fields. Following these fixed fields are the Host Controller USB Port Register Sets, which are dynamic and repeat from 1 to MaxPorts, as defined by HCSPARAMS1. Currently, the struct 'xhci_op_regs' includes: __le32 port_status_base; The first PORTSC __le32 port_power_base; The first PORTPMSC __le32 port_link_base; The first PORTLI __le32 reserved5; The first PORTHLPMC, not reserved __le32 reserved6[NUM_PORT_REGS*254]; Port registers 2 to MaxPorts Replace this with the simpler: struct xhci_port_regs port_regs[]; Port registers 1 to MaxPorts Host Controller USB Port Register Set: | Offset | Mnemonic | Register Name -------------------------------------------------------------------------- | 0x0 | PORTSC | Port Status and Control | 0x4 | PORTPMSC | Port Power Management Status and Control | 0x8 | PORTLI | Port Link Info | 0xC | PORTHLPMC | Port Hardware LPM Control Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 78203d5b54a4 ("usb: xhci: bail out of setup if the controller is inaccessible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8b7ca0029e94b3febc64da0eacba59285fb79ee2 Author: Niklas Neronin Date: Mon Aug 31 09:27:04 2026 -0400 usb: xhci: add helper to read PORTSC register [ Upstream commit 511afe80b82d2b21086e459906e6c97b4eaeed20 ] Add a dedicated helper function to read the USB Port Status and Control (PORTSC) register. This complements xhci_portsc_writel() and improves code clarity by providing a clear counterpart for reading the register. Suggested-by: Peter Chen Reviewed-by: Peter Chen Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 78203d5b54a4 ("usb: xhci: bail out of setup if the controller is inaccessible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a363197790a87f892ee10cbc18c77c1ecbf8705f Author: Niklas Neronin Date: Mon Aug 31 09:27:03 2026 -0400 usb: xhci: add tracing for PORTSC register writes [ Upstream commit 829738e59f1fad90ef7b63d6a1a4de9d5d22544a ] Introduce a dedicated write function for the USB Port Register Set (PORTSC) that includes tracing capabilities for values written to the PORTSC register. This enhancement minimizes code duplication and improves debugging. The PORTSC register is part of the Host Controller USB Port Register Set, comprising 4 x 32-bit registers. As the first register, PORTSC is accessed directly via 'port->addr'. Future commits will introduce a dedicated Port register struct to further streamline access. By adding the xhci_portsc_writel() function prior to these changes, we significantly reduce the number of same line modifications required. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 78203d5b54a4 ("usb: xhci: bail out of setup if the controller is inaccessible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 78e8ee25a5e8f2eb85bbabbeb15c8a2445b4a67f Author: David Howells Date: Mon Jun 22 10:08:50 2026 +0100 afs: Fix leak of ungot volume commit d672c276f685a540ed2b2a8bafaed4650a89022c upstream. Fix afs_lookup_volume_rcu() so that it doesn't leak a dying volume if afs_try_get_volume() fails. Fixes: 32222f09782f ("afs: Apply server breaks to mmap'd files in the call processor") Closes: https://sashiko.dev/#/patchset/20260609081738.770127-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260622090856.2746629-17-dhowells@redhat.com cc: Marc Dionne cc: Deepakkumar Karn cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Alexander Martyniuk Signed-off-by: Greg Kroah-Hartman commit c8279ae8df68cce9cd3b785e85f7a86c80a46e78 Author: Abdifatah Suruur Date: Sat Aug 29 18:40:22 2026 +0300 ksmbd: fix use-after-free in oplock break notification commit 0e753899627b5e28a9fea8bca98262a6f65a2452 upstream. smb2_oplock_break_noti() reads opinfo->conn without any lock and dereferences it after two allocations which may sleep. When the durable handle owning the oplock is disconnected, session_fd_check() clears opinfo->conn and drops its conn reference under ci->m_lock, and the last ksmbd_conn_put() frees the connection. A break triggered by another connection that races with the teardown can then resurrect the freed connection: ksmbd_conn_get() is a plain atomic_inc, and the queued break work later dereferences the stale conn via ksmbd_conn_write(), a use-after-free reachable by any authenticated client holding a durable batch oplock. Thread the caller's inode into the notification path instead of taking a new reference on it. Every caller of oplock_break() already holds a live ksmbd_file (or an explicit ksmbd_inode_lookup_lock() reference, in the parent lease break paths) on the inode that owns the break target's oplock list, so ci cannot be freed during the call, and its lock can be taken without dereferencing opinfo->o_fp, which a concurrent close may free. Select and pin the connection under ci->m_lock, the same lock session_fd_check() and ksmbd_reopen_durable_fd() use to update opinfo->conn, so a concurrent detach either loses the race to the clear or keeps the connection alive until the notification work releases it. Transfer the reference to the work item and release it on allocation failures. Fixes: b003086d7696 ("ksmbd: fix NULL-deref of opinfo->conn in oplock/lease break notifiers") Cc: stable@vger.kernel.org Signed-off-by: Abdifatah Suruur Signed-off-by: Namjae Jeon Signed-off-by: Abdifatah Suruur Signed-off-by: Greg Kroah-Hartman commit e5e7a61fa9e82c008e0be6eba59d9cc8e66760cc Author: Mohamed Ahmed Date: Tue Aug 25 04:14:06 2026 +0400 drm/nouveau/gsp: fix vblank interrupts on GB20x commit 5bb489b333237c1bf63a891a4362986253a0060a upstream. The GSP path programs per-head timing (vblank) interrupts the same way on every generation. NVD5.0 (GB20x) reworked the FE interrupt frontend around four message-based kernel vectors (high latency, low latency, PMU, and GSP) and moved RM head-timing interrupts to the dedicated low-latency vector: - The enable is NV_PDISP_FE_RM_INTR_EN1_HEAD_TIMING, 0x611ef0 + head*4 (570.144 kernel_head_0501.c, renamed kernel_head_0502.c from 575.51.02 on, and v05_01 dev_disp.h). - The vector is reported as a separate interrupt table entry, MC_ENGINE_IDX_DISP_LOW (intr_gb202.c, intrCacheDispIntrVectors). - The vector must be re-armed through NV_PDISP_FE_INTR_RETRIGGER(1) at 0x611f34 after servicing (kdispServiceInterrupt -> kdispIntrRetrigger_v05_01). The event latch (0x611800), per-head status (0x611c00), and dispatch summary (0x611ec0) the interrupt handler uses are unchanged on GB20x (kheadReadPendingVblank_v03_00 and kheadResetPendingLastData_v03_00 remain for DISPv0502+). On GB20x the old code enables head timing onto the legacy vector, leaves its handler there, and never re-arms the message-based vectors. Page flips still complete (nv50 sends those events from the commit path), so the desktop looks fine while DRM vblank waits and vblank sequence queries are affected. Supply GB20x vblank enables and an interrupt handler that re-arms the vector after servicing through gb202_gsp_disp, translate the low-latency interrupt table entry as a second NVKM_ENGINE_DISP instance, and add a gsp.intr_low_latency flag so r535_disp_oneinit() attaches the handler to that instance. GB20x was the last cross-file user of the TU1xx vblank enables, so make those static and drop their head.h prototypes. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-9-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit dc7c40ffaa1b6ed09e4d056e7d0a8db9b078b4de Author: Mohamed Ahmed Date: Tue Aug 25 04:14:05 2026 +0400 drm/nouveau/disp: fix head state readback on GB20x commit 9421dfe912e55360e6b9301a110acb00df7e7320 upstream. The GSP path reads armed head state and the RG scanout position through gv100_head_state() and gv100_head_rgpos() on every generation. gv100_head_state() reads the core channel's state mirror at a 0x400 per-head stride, which NVD5.0 (GB20x) doubled. Per NVIDIA's published CA7D class header every HEAD_SET method sits at 0x2000 + head * 0x800, while the mirror bases are unchanged (assembly at 0x680000, armed at +0x8000, per OpenRM's v03_00 channel-user-base HAL which is still used on DISPv0502). Add gb202_head_state(), the same readback at the 0x800 stride, and a gb202_gsp_head table to supply it. gv100_head_rgpos() is kept. The RG registers keep their per-head 0x800 stride on NVD5.0, and OpenRM's kdispReadRgLineCountAndFrameCount_v03_00 still reads NV_PDISP_RG_DPCA on DISPv0502. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-8-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0e346b65a413045fa87123c7956a98712350980b Author: Mohamed Ahmed Date: Tue Aug 25 04:14:03 2026 +0400 drm/nouveau/disp: fix HDMI GCP AVMute register offsets on GB20x commit 764deff8450c9a83e335c17c32ea258ec25bb71e upstream. The GSP path brackets audio enablement with a General Control Packet AVMute toggle. r535_sor_hdmi_audio() calls the gsp.hdmi_gcp hook, which every chip so far serves with tu102_sor_hdmi_gcp() and the legacy GCP unit at 0x6f00c0/0x6f00cc. On GB20x the SF packet units were compacted and the old generic and VSI units are gone (ACR keeps slot 2) and the GCP unit moved from slot 3 to slot 1 (control 0x6f0040 and subpack 0x6f004c from NVIDIA's published clc971.h. The same offsets are also used by OpenRM's hdmiWriteGeneralCtrlPacketC871() on these chips). The old addresses are reserved on GB20x, so the AVMute writes were silent no-ops and mitigated only by the equivalent GCP r535_sor_hdmi_audio() already sends through the SET_OD_PACKET RM control. Add a GB20x GCP writer using the new offsets and hook it into gb202_gsp_disp, keeping the direct MMIO path in sync with the hardware as on earlier chips. Only SB0 (the AVMute bit) is written. On NVD5.0 the subpack register also carries SB1_CTRL (bit 24), which selects where the deep-color CD/PP fields are generated (hardware or from the driver, with the default being HW). hdmiWriteGeneralCtrlPacketC871() likewise writes only SB0-SB2. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-6-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit ecb110991bc9431ebb6c4a9edcc7b154a2149bde Author: Mohamed Ahmed Date: Tue Aug 25 04:14:02 2026 +0400 drm/nouveau/disp: fix HDMI vendor infoframes on GB20x commit 92f09dcb4e8473ab25764e950994ab7b6abce6dd upstream. The GSP path reuses the GV100 direct-MMIO infoframe writers on every chip. On GB20x that is only half right as while the legacy SF AVI unit is unchanged, the legacy VSI unit at 0x6f0100 was removed, so gv100_sor_hdmi_infoframe_vsi() writes into a reserved area and no vendor infoframe ever reaches the HW. This affects HDMI-VIC signalling which can impact some 4K modes for legacy HDMI 1.4 sinks. GB20x (NVDisplay 5.0+) reorganised the SF HDMI packet units. Per NVIDIA's published C971/CA71 DISP_SF_USER class headers, only three legacy units remain (AVI at +0x000, GCP at +0x040, ACR at +0x080), and vendor infoframes must instead be sent through the shared generic infoframe units at +0x130, whose 9-dword packet slots are loaded through the shared data port at +0x3f0/+0x3f4. Add a VSI writer using the same programming sequence OpenRM uses on these chips (nvhdmipkt_C971.c, programAdvancedInfoframeC971()): disable the unit and wait for it to idle, clear the SENT status, write the packet through the data port with a zero inserted in HB3 after the three header bytes, then enable the unit for every-frame transmission during vblank. Generic unit 1 is used for the VSI, matching the slot assignment in NVIDIA's nvkms (NVHDMIPKT_TYPE_SHARED_GENERIC2, unit 0 is reserved for extended metadata packets and unit 2 for the HDR DRM infoframe, if those are wired up later). GB20x so far shared GA10x's display entry point. Give it its own, gb202_disp_new(), with a gb202_gsp_disp table that supplies the VSI writer to the GSP path and otherwise carries the same hooks as GA10x. The following fixes fill in the rest of the GB20x differences there. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-5-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 4739d519def725d749b0794652c9117c2e3aaa88 Author: Mohamed Ahmed Date: Tue Aug 25 04:14:01 2026 +0400 drm/nouveau/disp: route GSP-RM display MMIO through nvkm_disp_func hooks commit 9886aad51f4b5e7082209a153e404bcd8101356c upstream. The GSP-RM display code in rm/r535/disp.c borrows a few register-programming routines from engine/disp (the head-timing interrupt handler, vblank enables, armed head state and scanout position readback, the AVI/VSI infoframe writers and the GCP AVMute write) and so far picked them by name, which means it has to know which chip it runs on the moment a generation changes any of them. Give nvkm_disp_func a .gsp table that each chip fills with exactly those hooks, add tu102_gsp_disp (TU1xx) and ga102_gsp_disp (GA10x onwards) carrying the current functions, hand them to r535_disp_new() instead of the full hardware tables, and make rm/r535/disp.c call through the hooks. The head hooks are a whole nvkm_head_func, so r535_head goes away and the chip's own table is handed to nvkm_head_new_(). r535_sor_hdmi gets infoframe forwarders, r535_sor_hdmi_audio() calls the GCP hook, and the interrupt handler comes from the table. The tables are per chip even though the two currently coincide, so a generation that changes a hook only touches its own file. rm/r535/disp.c no longer contains chip-specific register code, and a new display generation only has to provide its own table. No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-4-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 94d8195eb41854c154ea3d3bc49059c5e98b7423 Author: Mohamed Ahmed Date: Tue Aug 25 04:14:00 2026 +0400 drm/nouveau/disp: move the GSP HDMI GCP AVMute write to engine/disp commit eb1ffc3dc72d379a41e367a44b99fb61a15bf8ba upstream. r535_sor_hdmi_audio() pairs two RM controls (a SET_OD_PACKET carrying the same General Control Packet, and the audio mute-stream toggle) with a direct write of the GCP AVMute bit through the SF GCP unit. The controls are RM and stay, but the direct write is register programming and moves next to the other per-chip display code as tu102_sor_hdmi_gcp(). No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-3-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit a046e789ab66e65f77f296cb9c5c1e2cfc16e933 Author: Mohamed Ahmed Date: Tue Aug 25 04:13:59 2026 +0400 drm/nouveau/disp: move GSP head-timing ISR and vblank helpers to tu102.c commit c6659e0ffc19b4ef0b3273c185cb8409a154eada upstream. The GSP-RM display code in rm/r535/disp.c owns a handful of direct MMIO routines: the head-timing (vblank) interrupt handler and the per-head vblank enable/disable. They program display registers, not RM, so they belong with the rest of the per-chip register code in engine/disp/. Move them to tu102.c (Turing is the first GSP-capable generation) as tu102_disp_intr() and tu102_head_vblank_get()/put(), exported for rm/r535/disp.c, which keeps calling them by name for now. No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-2-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 1101cbfe7f342e5eaaf7444965d4f1215abdac4c Author: Zhenhao Wan Date: Tue Aug 11 16:46:30 2026 +0800 drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE commit 38a62306c4266bcb3cd89e33c7111ee33096ebb3 upstream. A successful OP_UNMAP_SPARSE marks its region dirty with nouveau_uvma_region_dirty() and defers the teardown to nouveau_uvmm_bind_job_cleanup(); it does not remove the region from uvmm->region_mt. If a later op in the job fails, the unwind path never clears reg->dirty (set in one place, cleared nowhere) and sets op->reg = NULL, so cleanup skips the teardown. The region is left in the tree with dirty set and its completion never signalled. Later binds over that range then fail permanently -- -ENOENT or -EINVAL from the dirty checks, or an unkillable wait_for_completion() in bind_validate_region() -- for the lifetime of the uvmm. Clear reg->dirty when the unwind reverts the sparse unmap, restoring the region to the state it was found in. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-3-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 24c25b182d17d1bdfde0088c96bdf6f93e8f46bc Author: Zhenhao Wan Date: Tue Aug 11 16:46:29 2026 +0800 drm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSE commit ccf930812f23b8259ef64fd3394d53b093e4651a upstream. In nouveau_uvmm_bind_job_submit()'s OP_UNMAP_SPARSE arm, op->reg is set from nouveau_uvma_region_find(), which only looks the region up and takes no reference; a region's sole reference is its membership in uvmm->region_mt. Two failure paths leave op->reg set: the -ENOENT check when the region is busy, and the drm_gpuvm_sm_unmap_ops_create() failure. The sibling nouveau_uvmm_sm_unmap_prepare() failure just below clears op->reg; these two do not. unwind_continue steps back one op, so the failing op is skipped by the unwind loop and its op->reg stays set. nouveau_uvmm_bind_job_cleanup() then enters its if (op->reg) branch and calls nouveau_uvma_region_remove() and nouveau_uvma_region_put() on it, dropping the tree's sole reference and freeing a region this job never created. The comment above the cleanup loop documents the broken invariant: op->reg must be NULL on submit failure. This frees a live region on an unrelated failure, reachable single-job when drm_gpuvm_sm_unmap_ops_create() returns -ENOMEM; if another job owns the same region, its cleanup then removes and puts the freed region, a use-after-free. Clear op->reg on both failure paths. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-2-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit b7dc03e09313d22a6d230b759de3b05d504c008f Author: Zhenhao Wan Date: Tue Aug 11 16:46:28 2026 +0800 drm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE op commit 412a6ceb56d501ef2f8202e26ab4b5d4dfbca566 upstream. Each bind_job_op is zeroed by kzalloc_obj() in bind_job_op_from_uop(), and the OP_MAP_SPARSE case in nouveau_uvmm_bind_job_submit() only creates a region, so op->ops stays NULL for a successfully processed sparse map. If a later op in the same job fails, the reverse unwind loop revisits that op and calls drm_gpuva_ops_free(&uvmm->base, op->ops) unconditionally. drm_gpuva_ops_free() dereferences its argument right away (list_for_each_entry_safe on &ops->list), so a NULL op->ops oopses. The path is reachable by any render-node fd holder, since NOUVEAU_VM_BIND is DRM_RENDER_ALLOW. Guard the free with IS_ERR_OR_NULL(), as nouveau_uvmm_bind_job_cleanup() already does for the identical free. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-1-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 4cf436de06ca9970a00adcbace96ac8f8e402c2b Author: Faith Ekstrand Date: Fri Aug 21 23:42:59 2026 -0500 drm/nouveau: Use write-combined maps for coherent commit 774b73428e6eabb4f0382aeeb76e569c7b106a29 upstream. On Tegra devices, uncached maps translate to device memory, causing unaligned accesses by userspace resulting in a SIGBUS. Instead, use write-combined maps to ensure proper access. This would also affect discrete cards on any Arm device. It was determined that discrete cards regardless of cpu arch should use write-combined maps for coherent anyways. Thus this change is made for all gpu types. Cc: stable@vger.kernel.org Signed-off-by: Faith Ekstrand Co-developed-by: Aaron Kling Signed-off-by: Aaron Kling Fixes: 1b4ea4c5980f ("drm/ttm: set the tt caching state at creation time") Link: https://patch.msgid.link/20260821-tegra-coherent-wc-v2-1-2b1ddb67bf18@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit f3830fdd6930e233d727f29eee1617f7e6a0e9e5 Author: Marek Czernohous Date: Thu Aug 13 01:13:27 2026 +0200 drm/nouveau: unsubscribe the channel-kill event before the fence context commit 511585987d27d8cb668acebd399fc4deda23404c upstream. nouveau_channel_del() tears the fence context down first and only drops the channel-kill subscription later, in the middle of the nvif object teardown: if (chan->fence) nouveau_fence(chan->cli->drm)->context_del(chan); ... nvif_object_dtor(&chan->vram); nvif_event_dtor(&chan->kill); The subscribed handler is nouveau_channel_killed(), which calls nouveau_channel_kill() and from there nouveau_fence_context_kill() on chan->fence. A kill event delivered in that window takes fctx->lock and walks fctx->pending on a fence context that context_del() has already freed. Nothing reaches this below Fermi today, because the subscription is gated on FERMI_CHANNEL_GPFIFO and nothing kills a channel there. On Fermi and newer the window is real but narrow, since a kill has to land exactly while the channel is being destroyed. That is reason enough on its own, which is why this carries a Fixes: tag. The last patch in this series subscribes Tesla channels as well; nothing kills those today, so it does not widen the exposure now, but it is the groundwork for a recovery path that would, and the ordering is better fixed before that lands than alongside it. Drop the subscription before anything it depends on is torn down. Fixes: ea13e5abf807 ("drm/nouveau: signal pending fences when channel has been killed") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Marek Czernohous Fixes: ea13e5abf807 ("drm/nouveau: signal pending fences when channel has been killed") Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260812231330.705425-2-mczernohous@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5ba4bcb3b96cda05f3c283fda3842580b8e84590 Author: Mohamed Ahmed Date: Tue Aug 25 04:14:04 2026 +0400 drm/nouveau/gsp: use per-version DP_CONFIG_STREAM params on r570 firmware commit 39fd4b742720c68da8695ee1ffa85c5fea4f8e11 upstream. NVIDIA removed the deprecated actualPclkHz/linkClkFreqHz fields and the whole Legacy{activeCnt, activeFrac, activePolarity, mvidWarEnabled, MvidWarParams} block from the SST sub-struct of NV0073_CTRL_CMD_DP_CONFIG_STREAM_PARAMS between the 535 and 570 releases (compared in OpenRM tags 535.113.01 vs 570.144), shrinking the struct. Everything nouveau writes sits at identical offsets in both layouts except the trailing SST.bEnableAudioOverRightPanel (written as zero), but the size is wrong on r570, which means r535_sor_dp_sst() and r535_sor_dp_vcpi() are sent with an incorrect size. Route the .sst/.vcpi IOR functions through nvkm_rm_api_disp the same way bl_ctrl and dp.get_caps/set_indexed_link_rates already are. Keep the existing implementation for r535 and add an r570 implementation built against the 570.144 layout, which already exists in r570/nvrm/disp.h but was unused until now. Also add the NV0073_CTRL_CMD_DP_CONFIG_STREAM define that was missing from the layout. Other DP controls sent through shared r535 code did not change layout between the tags. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-7-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 859d8b6c5b274c79f8b2122a384a9d11a347dd29 Author: Shixiong Ou Date: Fri Jul 31 19:17:29 2026 +0800 drm/sysfb: ofdrm: Fix is_avivo() constant comparison bug commit 958f35cbb8955ca3fa439cd9f2092cb42414aa8c upstream. The is_avivo() function has a logic error where it compares a constant to another constant instead of checking the device parameter: (PCI_VENDOR_ID_ATI_R600 >= 0x9400) Signed-off-by: Shixiong Ou Reviewed-by: Thomas Zimmermann Fixes: f496834e1674 ("drm/ofdrm: Add per-model device function") Signed-off-by: Thomas Zimmermann Cc: # v6.2+ Link: https://patch.msgid.link/20260731111729.703116-1-oushixiong1025@163.com Signed-off-by: Greg Kroah-Hartman commit ded6ad826fe0fd059333d3a3b3e1742c8e45ff41 Author: Shixiong Ou Date: Tue Aug 25 18:41:34 2026 +0800 drm/sysfb: ofdrm: Fix integer overflow in fb_size calculation commit c6f48e59ece0123f6a11527ad4d89b21c2d65b87 upstream. The framebuffer size calculation `fb_size = linebytes * height` can overflow when both values are large (e.g., 46341 * 46341 > INT_MAX). Since linebytes and height are both int types, the multiplication is performed as int * int, which results in undefined behavior on overflow. Use check_mul_overflow() to detect and prevent this overflow, consistent with the approach used in simpledrm.c and corebootdrm.c. Signed-off-by: Shixiong Ou Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Fixes: c8a17756c425 ("drm/ofdrm: Add ofdrm for Open Firmware framebuffers") Cc: # v6.2+ Link: https://patch.msgid.link/20260825104134.669676-1-oushixiong1025@163.com Signed-off-by: Greg Kroah-Hartman commit 6892f0a2f6b5990b9572ba043dd14dd4df6bb3f0 Author: Thomas Zimmermann Date: Thu Jun 25 11:39:36 2026 +0200 drm/sysfb: simpledrm: Improve stride validation commit df6533f11688aa30be3bb883c7637f4ffdbb7cbd upstream. Validate the computed stride against the maximum value INT_MAX. Signed-off-by: Thomas Zimmermann Reviewed-by: Thierry Reding Reviewed-by: Maxime Ripard Reviewed-by: Javier Martinez Canillas Fixes: 7bfa5c7b28d6 ("drm/simpledrm: Compute linestride with drm_format_info_min_pitch()") Cc: # v6.1+ Link: https://patch.msgid.link/20260625094509.157581-5-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 54e32ad5e0c74c7087a4a508f9274057fcdb4a2f Author: Thomas Zimmermann Date: Thu Jun 25 11:39:34 2026 +0200 drm/sysfb: simpledrm: Improve panel-size validation commit 3a75a0761914d01c7362adf1f906cc1d1762c189 upstream. Validate the panel size from the device-tree node against the limitations of struct drm_display_mode. The type only stores sizes in 16-bit fields. Fail transparently on errors; do not warn. v3: - move comments to a more prominent place (Thierry) v2: - only use initialized values in debugging output (Sashiko) Signed-off-by: Thomas Zimmermann Reviewed-by: Thierry Reding Reviewed-by: Maxime Ripard Reviewed-by: Javier Martinez Canillas Fixes: 2a6d731a8f16 ("drm/simpledrm: Allow physical width and height configuration via panel node") Cc: Rayyan Ansari Cc: # v6.4+ Link: https://patch.msgid.link/20260625094509.157581-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 8d65b8d1722d8db40c7d41eecc7cb8e081b86a35 Author: Thomas Zimmermann Date: Thu Jun 25 11:39:33 2026 +0200 drm/sysfb: simpledrm: Improve framebuffer-size validation commit 03f1a3545b721fa7fdadd00080e237519a286a97 upstream. Validate the framebuffer size from the firmware against the limitations of struct drm_display_mode. The type only stores sizes in 16-bit fields. Fail probing on errors. v2: - remove unused function simplefb_get_validated_int0() (Sashiko) Signed-off-by: Thomas Zimmermann Reviewed-by: Thierry Reding Reviewed-by: Maxime Ripard Reviewed-by: Javier Martinez Canillas Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Cc: # v5.14+ Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Link: https://patch.msgid.link/20260625094509.157581-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit fd3462acf6590687ec1f2e062109723a76a49cbc Author: Sunday Clement Date: Thu Aug 6 10:59:34 2026 -0400 drm/amdkfd: Reject zero-sized AQL queue allocations after size halving commit 40ba09e11188d1b7f79d51fc28aca5ea45e0c138 upstream. KFD_IOC_ALLOC_MEMORY_OF_GPU with flag KFD_IOC_ALLOC_MEM_FLAGS_AQL_QUEUE_MEM and size=1 triggers the AQL wraparound workaround (size >>= 1), reducing size to 0. The resulting zero passes through PAGE_ALIGN(0) = 0 without validation, bypassing the per-process VRAM quota check in reserve_mem_limit() (vram_used + 0 > vram_available is always false). The fix adds post-halving zero-size validation in the primary allocation path (amdgpu_amdkfd_gpuvm.c). The check happens after size halving but before reserve_mem_limit(), and uses err_alignment_size error path to properly clean up the allocated kgd_mem structure and mutex. Cc: stable@vger.kernel.org Signed-off-by: Sunday Clement Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ebffa44e7a21ead59ac4b4264e8fc2cbb44c4a21 Author: Vladimir Marioukhine Date: Wed Aug 12 12:58:12 2026 -0400 drm/amdkfd: guard against NULL restore_mqd in CRIU queue restore commit 6aa530642f95d5c48aa336416f94a35e7949b647 upstream. Both create_queue_cpsch() and create_queue_nocpsch() unconditionally call mqd_mgr->restore_mqd() when a CRIU restore is in progress (qd != NULL), with no NULL guard. On any system where restore_mqd is not implemented for the given queue type, a user holding CAP_CHECKPOINT_RESTORE can trigger a kernel NULL pointer dereference and panic the machine by issuing KFD_IOC_CRIU_OP_RESTORE with a crafted queue restore object. Note that checkpoint_mqd is likewise unimplemented on GFX12, so no legitimate CRIU image can reach this path — only a hand-crafted restore payload. Add a NULL guard for restore_mqd immediately after mqd_mgr is resolved, unwinding via the existing error labels and returning -EOPNOTSUPP if the callback is not implemented. This mirrors the existing checkpoint_mqd guard in checkpoint_mqd(). Fixes: 48f0bdf4e38e ("drm/amdkfd: Added MQD manager files for GFX12.") Cc: stable@vger.kernel.org Signed-off-by: Vladimir Marioukhine Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ae806a95b28fcecb913430cfa45a252e91a945d6 Author: Xiaogang Chen Date: Sun Aug 23 15:47:15 2026 -0500 drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram commit 520e345ffe05aabef1db82beda4288afb1757ff2 upstream. When migration vm range is hole at cpu side(MIGRATE_PFN_MIGRATE set + MIGRATE_PFN_VALID unset) driver still allocates device pages. There is no dma map of src pages and migration. j is 0 and svm_migrate_copy_memory_gart() will return an uninitialized r. That can trigger out_free_vram_pages to drop all VRAM just set up. Initialize r and only call the last svm_migrate_copy_memory_gart if j > 0. Current code postponed the last page to the final copy. This patch flushes on the last page when reach to the end of current drm_buddy_block; avoids another svm_migrate_copy_memory_gart. Cc: stable@vger.kernel.org Signed-off-by: Xiaogang Chen Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit da87bcad1f781d822e7ced6d1de9dbc6d381c72e Author: Xiaogang Chen Date: Sun Aug 23 15:22:54 2026 -0500 drm/amdkfd: Fix error path at svm_migrate_copy_to_ram commit 960c4a8069bfd352c48cc88592618f1ebe24c69e upstream. If page migration from device to sys ram fails for some reasons driver needs release and unlock allocated system pages. To do that driver should use page physical address, or pfn, then get struct page*. Current driver uses dma address(for adev) that is not correct with IOMMU enabled, or even in general. The patch releases and unlocks allocated system pages based on where migration failed by struct page* of sys ram pages. Also dma_unmap correspodent system ram pages at error path. Cc: stable@vger.kernel.org Signed-off-by: Xiaogang Chen Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e230c546ed93741833ab5babb0b202f9c2052b45 Author: Priya Hosur Date: Thu Aug 27 15:02:46 2026 +0530 drm/amdkfd: Add TLB flush after MES queue eviction/suspension commit 94e25cb6ab7f4f025bcdcd8ea79fda30f12843a4 upstream. MES (Micro Engine Scheduler) does not perform heavy-weight TLB invalidation after unmapping queues, unlike HWS which does this automatically. This causes a race condition where in-flight DMA descriptors can access memory that has been unmapped, leading to page faults and GPU queue hangs during SVM page migration. The issue manifests as KFDSVMRangeTest.MultiThreadMigrationTest failures on gfx1151 (Strix Point) with XNACK mode 1 enabled - the GPU compute queue hangs with packets submitted but never consumed. Add kfd_flush_tlb() calls after MES queue removal in two locations: - evict_process_queues_cpsch(): after all queues removed during eviction - suspend_queues(): after debug/criu queue suspension (with mem_fence barrier) This ensures all in-flight memory accesses from unmapped queues are flushed before memory is freed or migrated. Signed-off-by: Priya Hosur Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2e4b909fab96c557e43f661a8944d979db6dada9 Author: Sunil Khatri Date: Thu Aug 27 20:33:35 2026 +0530 drm/amdgpu: use AMDGPU_GPU_PAGE_SHIFT instead of PAGE_SHIFT commit d6e16df7df4d2c39e2b04b355d0434fb90e2d62c upstream. For different address types the variable PAGE_SHIFT might not work well and it's better to use the GPU specific one Signed-off-by: Sunil Khatri Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 3494b77d10375e0f9ab784e9b20763339844b55b) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 65e643703f1509f12395843f264782f1f7e60d7d Author: Sunil Khatri Date: Mon Aug 31 20:18:31 2026 +0530 drm/amdgpu: update the fw version for gfx12 userqueues commit 49a74a2388528c1a2e96f01114c4513e635605fe upstream. Update to the latest stable fw versions where userqueues is working as it is expected with major fixes. Signed-off-by: Sunil Khatri Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 69fa36e3ac92f2544ee7a1b719ec212b8247a2da) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b7cb1b66961371bd565d85773d5a679c8428d6f3 Author: Sunil Khatri Date: Mon Aug 31 20:17:17 2026 +0530 drm/amdgpu: update the fw version for gfx11 userqueues commit c748dd03df33360549ad60cdccee13570e9c0f90 upstream. Update to the latest stable fw versions where userqueues is working as it is expected with major fixes. Signed-off-by: Sunil Khatri Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit d50201b891604ab97f305d4a20d888ba93305b48) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8de8b4e11ce487bccde37cc23c350f5084a86818 Author: Kanala Ramalingeswara Reddy Date: Mon Aug 31 19:59:11 2026 +0530 drm/amdgpu: Skip accessing psp rum time db for APUs commit a26301203a196a991527f7b1ab884d4dd0e7c95e upstream. Psp runtime DB is for dGPUs only. Signed-off-by: Kanala Ramalingeswara Reddy Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit dce8195027f146467c9378efb2bb1b0859cb735e) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 492dbf832964c30e7e837773ecc7ac6bf152f3f0 Author: Guangshuo Li Date: Sat Aug 8 20:09:34 2026 +0800 drm/amdgpu: fix autosuspend cleanup during removal commit ef5fcf2a6c320676bf8be2dadac93d9023b468b7 upstream. amdgpu_pci_probe() calls pm_runtime_use_autosuspend(), but amdgpu_pci_remove() does not call the matching pm_runtime_dont_use_autosuspend(). If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to the remove path. This issue was found by manual code inspection. Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260808120934.2813010-1-lgs201920130244@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 812c406f752914d8897da37c8fb2e86488054623 Author: Yang Wang Date: Wed Aug 5 11:44:54 2026 +0800 drm/amdgpu: Disable runtime PM for externally attached dGPUs commit c52feb4365396b6a881b5e8a95540517ffabb3b7 upstream. pci_is_thunderbolt_attached() requires an upstream PCI bridge with is_thunderbolt set from an Intel Thunderbolt VSEC. This does not cover the affected ASM4242 USB4 PCI hierarchy: 00:02.2 \- 0f:00.0 [1b21:2421] +- 10:01.0 [1b21:2423] -> 45:00.0 -> 46:00.0 | -> 47:00.0 -> 48:00.0 -> 49:00.0 [1002:7590] \- 10:03.0 -> 76:00.0 [1b21:2425] USB4 Host Router The host router is outside the GPU upstream bridge chain, leaving no ancestor with is_thunderbolt set. PCI core propagates DEVICE_REMOVABLE below the external-facing PCIe tunnel. Disable Runtime PM when either pci_is_thunderbolt_attached() or dev_is_removable() is true. Cc: stable@vger.kernel.org Signed-off-by: Yang Wang Reviewed-by: Candice Li Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 964de255497ffd7cb8a86e405b8ac6d927e7e177 Author: Xiang Liu Date: Fri Aug 21 17:41:57 2026 +0800 drm/amdgpu: clamp the isolation index for rings outside a partition commit b30900566642ceb2c9e12b56c2afec28d0fd91a0 upstream. adev->isolation[] has one slot per partition, but a ring that is not assigned to one keeps AMDGPU_XCP_NO_PARTITION, which is ~0, so indexing the array with it is out of bounds. SDMA submissions hit this on both the isolation enforcement and the VM flush path and trip UBSAN. Fall back to the first slot the way the cleaner shader path already does, and stop taking the address before the ring type check that makes it relevant. Cc: stable@vger.kernel.org Signed-off-by: Xiang Liu Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b3a7e0b69903e76415abb057119640e1398ab2e8 Author: Yang Wang Date: Wed Aug 12 11:08:40 2026 +0800 drm/amdgpu: check thunderbolt before switcheroo registration commit 8587d48d694da5aca580f92461658ec14470592b upstream. Introduce a helper to consolidate the vga_switcheroo registration condition used by the init and fini paths. Keep the explicit pci_is_thunderbolt_attached() check, as dev_is_removable() does not provide equivalent coverage for Thunderbolt-attached GPUs. This ensures such devices remain excluded from switcheroo registration while preserving the existing PX and Apple gmux handling. Cc: stable@vger.kernel.org Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 66b1b309886337745d395bbc158440ab196305ce Author: Thadeu Lima de Souza Cascardo Date: Mon Jul 27 17:45:49 2026 -0300 drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used commit 4d4be202165e832d74849b4a68e289a2a377039c upstream. Commit 1c6ceeee6ebb ("drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms. Fixes: 24835e442f28 ("drm: reference count event->completion") Cc: stable@vger.kernel.org Signed-off-by: Thadeu Lima de Souza Cascardo Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patch.msgid.link/20260727-drm_crtc_atomic_commit_leak-v1-1-23d9948a9d7c@igalia.com Signed-off-by: Greg Kroah-Hartman commit acd2dd6ecd89e9c2af43397b47e5c60deec4be51 Author: Kavan Smith Date: Mon Jul 6 18:32:40 2026 -0700 drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value commit 6cd33b6f4155efc20485929fd0b56bb704641db9 upstream. MSM8916 runtime DSI commands still go through msm_dsi_host_xfer_prepare(), which re-applies the link clock rate before enabling the link clocks. That is fine in principle, but on DSI 6G the requested byte clock rate often does not exactly match the DSI PHY PLL's realizable rate. For example, the driver can request 56250000 Hz while the PLL actually runs at 56246337 Hz. Because the requested and actual rates differ slightly, every later link_clk_set_rate() call is treated as a real clock change and re-locks the PLL. On a video-mode panel without an internal timing generator, such as samsung,s6d7aa0 / lsl080al03 on MSM8916, that live-clock glitch makes the panel lose pixel lock and visibly corrupts scanout on each runtime DCS command, including backlight writes. Fix this by rounding the computed 6G byte clock rate up front, before it is stored in msm_host->byte_clk_rate and reused by later transfers. Once the host carries the PLL-achievable rate instead of the idealized one, repeated link_clk_set_rate() calls become no-ops in the common clock framework and no longer re-lock the PLL. This keeps the normal transfer callback sequencing intact, preserves the OPP vote path in link_clk_set_rate(), and matches the fix direction suggested in the original 2018 discussion. Reported-by: Daniel Mack Closes: https://lore.kernel.org/all/1a682c5b-7fc9-3aaa-120b-64b239a355a3@zonque.org/ Fixes: 6b16f05aa39f ("drm/msm/dsi: Split clk rate setting and enable") Cc: stable@vger.kernel.org Signed-off-by: Kavan Smith Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/738234/ Link: https://lore.kernel.org/r/20260707013240.681012-1-kavansmith82@gmail.com [DB: dropped extra chunk from the patch] Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit 72a95df6bbc7d20c7af1e39d86b3e910cccd01ad Author: Tao Yu Date: Wed Aug 19 15:28:35 2026 +0800 drm/gud: validate TV mode names before creating enum property commit da1ea35fea67ad841f4ada28dd61b41be65e5437 upstream. The GUD protocol returns TV mode names as fixed-size GUD_CONNECTOR_TV_MODE_NAME_LEN entries and requires each name to be NUL-terminated. gud_connector_add_tv_mode() currently passes each fixed-size entry directly to drm_mode_create_tv_properties_legacy(), which eventually reaches drm_property_add_enum() and strlen(). If a device returns an entry without a terminating NUL byte, strlen() reads past the end of the slot and can run beyond the allocated buffer, triggering an out-of-bounds read. Validate that each returned TV mode name contains a NUL terminator within its fixed-size slot before passing it to the DRM property code. If a malformed entry is found, reject the device response with -EIO. This fixes the out-of-bounds read without changing the handling of valid devices, and avoids silently truncating malformed protocol data. Reported-by: syzbot+9ae8e7884e451eaed5b4@syzkaller.appspotmail.com Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Signed-off-by: Tao Yu Reviewed-by: Ruben Wauters Cc: Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260819072835.4074130-1-tao1.yu@intel.com Signed-off-by: Greg Kroah-Hartman commit b86438a5c6b0250ccb07dd380184d1e70e0dea6c Author: Deepanshu Kartikey Date: Sun Aug 16 14:22:34 2026 +0530 drm/gud: NUL-terminate TV mode names read from the device commit 500cb24cd61bad8a2747ddfc49b7034899c82d94 upstream. gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use. Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Reported-by: syzbot+916c888ba5f1a54c9526@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=916c888ba5f1a54c9526 Tested-by: syzbot+916c888ba5f1a54c9526@syzkaller.appspotmail.com Signed-off-by: Deepanshu Kartikey Acked-by: Ruben Wauters Cc: Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260816085234.22053-1-kartikey406@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7e28853c78c20bb8ba4c1dba702430cd05e09f76 Author: David (Ming Qiang) Wu Date: Fri Aug 7 15:12:14 2026 -0400 drm/amdgpu/vcn: fix integer overflow in dec_msg buffer count check commit 4d7390530853eb7befda9cc786e4c86e8ad7ac9e upstream. If the supplied msg[2] (num_buffers) is 0x3FFFFFFF, the expression 6 + num_buffers * 4 wraps to 2 and the bounds check passes, letting the parser loop far past the end of the message BO. Triggering it additionally requires a ~4GiB mapping so that msg[1] survives the earlier "header does not fit in BO" check. Rewrite the test in division form, which is overflow-free by construction. Also update the message to reflect that msg is invalid. Fixes: b193019860d6 ("drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg") Fixes: 0a78f2bac142 ("drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg") Cc: stable@vger.kernel.org Signed-off-by: David (Ming Qiang) Wu Reviewed-by: Leo Liu Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 0b2615b8b54f58bbdf986dffb38cbc35214a5cc5 Author: Harry Wentland Date: Tue Aug 4 17:04:05 2026 -0400 drm/amd/display: validate plane degamma LUT size for private color prop commit e4c3ab59021e7c146a84b6671f0d530972bd58b4 upstream. Unlike the CRTC degamma path, which is guarded by amdgpu_dm_verify_lut_sizes(), the per-plane degamma LUT size was never validated before use. __set_dm_plane_degamma() passed the user-supplied size straight into __is_lut_linear() and, for a non-linear LUT, into __set_input_tf() -> __drm_lut_to_dc_gamma(), the latter always iterating MAX_COLOR_LUT_ENTRIES entries regardless of the actual LUT size. A malformed AMD_PLANE_DEGAMMA_LUT blob (e.g. a single entry) could thus trigger a divide-by-zero in __is_lut_linear() or an out-of-bounds read in __drm_lut_to_dc_gamma(). Reject any plane degamma LUT whose size does not match MAX_COLOR_LUT_ENTRIES, mirroring the invariant the code already asserts a few lines below (and which the CRTC path enforces). The AMD_PLANE_DEGAMMA_LUT property is only exposed on builds with AMD_PRIVATE_COLOR defined. Fixes: 980f8710075a ("drm/amd/display: add plane degamma TF and LUT support") Cc: stable@vger.kernel.org Signed-off-by: Harry Wentland Reviewed-by: Melissa Wen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 295d2bf42061db490254e748f9344545bb7faf19 Author: Linkai Gong Date: Wed Aug 19 13:47:42 2026 +0800 drm/amd/display: fix dc_lock leak on GPU reset error paths commit 92a9eebd2a1f892fe482154d83f9f1626bc73d3b upstream. On GPU reset, dm_suspend() takes dc_lock and leaves it for dm_resume() to drop. If amdgpu_dm_commit_zero_streams() or dm_dmub_hw_init() fails, the function returns with the lock still held. The matching resume path is then skipped, so every later dc_lock take hangs. Release the cached DC state and unlock before returning the error. Fixes: 3cf7a0bc87f0 ("drm/amd/display: Catch failures for amdgpu_dm_commit_zero_streams()") Fixes: 2b6943df5413 ("drm/amd/display: Pass up errors for reset GPU that fails to init HW") Cc: stable@vger.kernel.org Signed-off-by: Linkai Gong Reviewed-by: Mario Limonciello Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ee28fafb50f58b847509b5240b431ddec673bdfe Author: Harry Wentland Date: Tue Aug 4 17:04:04 2026 -0400 drm/amd/display: avoid divide-by-zero in __is_lut_linear() commit 4f40873f8a4107df2b9c8e68c947c4fd0cd519d2 upstream. __is_lut_linear() computes the expected value of each entry with expected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero. Fixes: 086247a4b2fb ("drm/amd/display: Use 4096 lut entries") Cc: stable@vger.kernel.org Signed-off-by: Harry Wentland Reviewed-by: Melissa Wen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4ac7677221754f4e0b3054bc9e8d23b9e12486d3 Author: Thomas Zimmermann Date: Thu Jun 18 14:28:39 2026 +0200 drm/hibmc: Use drm_atomic_helper_check_plane_state() commit 715c5db68bdbd4a524b79ebf20fb61e880fffea0 upstream. Call drm_atomic_helper_check_plane_state() from the primary plane's atomic-check helper and replace the custom implementation. All plane's implementations of atomic_check should call the shared _check_plane_state() helper first. It adjusts the plane state for correct positioning, rotation and scaling of the plane. Do this even if the plane's CRTC has been disabled by setting the parameter can_update_disabled. The original code returned early in this case, but it's safe to so and cleaner to have all plane state initialized. As we don't set can_position, drm_atomic_helper_check_plane_state()'s visibility check tests if the plane covers all of the CRTC. This is a small change from the original code, which tested if the plane is exactly the size of the CRTC. With the new test, the plane still has to cover all of the CRTC, but can be larger than the CRTC's size. A later patch can fully implement this feature in hibmc. If the plane is disabled, the helper clears the visibility flag in the plane state. On errors or if the plane is not visible, the atomic-check helper can return early. Implement all this in hibmc and drop the custom code that does some of it. v2: - extend the commit description (Yongbang) Signed-off-by: Thomas Zimmermann Fixes: da52605eea8f ("drm/hisilicon/hibmc: Add support for display engine") Reviewed-by: Yongbang Shi Cc: Rongrong Zou Cc: Sean Paul Cc: Xinliang Liu Cc: Dmitry Baryshkov Cc: Baihan Li Cc: Yongbang Shi Cc: # v4.10+ Link: https://patch.msgid.link/20260618123142.92298-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit ed38f0be5b61d96cfd16311db22b022277866b23 Author: Thomas Zimmermann Date: Thu Jun 18 14:28:40 2026 +0200 drm/hibmc: Fix list of formats on the primary plane commit 0e682e136c466ae37c62f18099f591c096260ee0 upstream. Remove all formats from the primary plane that are unsupported for various reasons. * Formats with alpha channel: planes should not announce alpha channels unless they support transparency. There's no transparency support in the primary plane's implementation. * Formats with BGR order. The common format is in RGB channel order. There's no BGR support in the primary plane's implementation. * RGB888: atomic_update programs the format from cpp[0] * 8 / 16. For RGB888's cpp value of 3 this returns 1.5; rounded to 1. Programming the value of 1 to HIBMC_CRT_DISP_CTL_FORMAT sets up RGB565. Hence, the output is distorted. This can be tested by booting with video=1024x768-24. Removing all unsupported formats leaves XRGB8888 and RGB565. Both of which are supported and work correctly. Signed-off-by: Thomas Zimmermann Fixes: da52605eea8f ("drm/hisilicon/hibmc: Add support for display engine") Reviewed-by: Yongbang Shi Cc: Rongrong Zou Cc: Sean Paul Cc: Xinliang Liu Cc: Dmitry Baryshkov Cc: Yongbang Shi Cc: Baihan Li Cc: # v4.10+ Link: https://patch.msgid.link/20260618123142.92298-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit f5acd8f48cacc6e4b682c384317d11ef5c33bc8d Author: Lyude Paul Date: Tue Apr 28 23:03:40 2026 -0400 drm/nouveau/disp/r535: Add scanline position support + head state support commit 804cb093b245c752f15d17186e0d404f10303593 upstream. That's right! It looks like this never actually got finished, something which I just noticed today when I saw this fun message spamming one of my test machine's kernel logs when enabling display debug output for nouveau: [drm:drm_crtc_vblank_helper_get_vblank_timestamp_internal] crtc 0 : scanoutpos query failed. So it looks like we've been falling back to DRM's core fallback for a while now, whoops. So, while it seems that we do have the option of doing this through GSP - that doesn't seem like a great idea. Mainly because reading this from GSP would involve a lot more latency then we should have for vblank handling due to the RPC communication. So instead of implementing that, just use gv100_head_state and gv100_head_rgpos for implementing .state and .rgpos. It seems to work perfectly fine! Fixes: 9e9944449023 ("drm/nouveau/disp/r535: initial support") Cc: Ben Skeggs Cc: Dave Airlie Cc: Timur Tabi Cc: Ben Skeggs Cc: James Jones Cc: Faith Ekstrand Cc: Suraj Kandpal Cc: Lyude Paul Cc: Aaron Kling Cc: Danilo Krummrich Cc: Zhang Enpei Cc: # v6.7+ Signed-off-by: Lyude Paul Signed-off-by: Dave Airlie Link: https://patch.msgid.link/20260429030348.3930866-1-lyude@redhat.com Signed-off-by: Greg Kroah-Hartman commit 6f9bdbe713fdfc2bbe74708993fa371d851358df Author: Amit Barzilai Date: Mon Jun 22 15:26:04 2026 +0300 drm/ssd130x: fix column and row end address in partial updates in ssd133x commit b7fcb70162acd7f15ed20bc64a14c150db34256f upstream. On partial screen updates, SSD133X controllers expect to get the rectangle addresses as arguments of the "Set Column Address" and "Set Row Address" commands. Each command expects the start address and end address of the row/column in absolute format, however the end addresses were being sent in a relative format (relative to the start address). The relative end addresses work only when the start address is 0. In those situations, there is no value difference between relative and absolute addresses. Fixes: b4299c936d8fd ("drm/ssd130x: Add support for the SSD133x OLED controller family") Cc: stable@vger.kernel.org Signed-off-by: Amit Barzilai Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260622122604.32500-4-amit.barzilai22@gmail.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Greg Kroah-Hartman commit 6f776d0e43e041ab737225b2d46d5c5ec08dadfd Author: Wentao Liang Date: Sun Jun 7 03:09:50 2026 +0000 drm/sun4i: fix refcount leak in sun4i_backend_init_sat() commit f7a56ff6240e6fd0cb36a3c0a911a1cd54789ce2 upstream. When sun4i_backend_init_sat() calls reset_control_deassert() it increments the deassert_count of the reset controller, and must pair that with a reset_control_assert() call to decrement it. In the error path where clk_prepare_enable() fails, the function returns immediately without calling reset_control_assert(), leaking the reference count. Other error paths, like the devm_clk_get() failure, correctly jump to the err_assert_reset label which performs the missing assert. Fix the leak by using the existing err_assert_reset label in the clk_prepare_enable error path instead of returning directly. Cc: stable@vger.kernel.org Fixes: 440d2c7b127a ("drm/sun4i: backend: Handle the SAT") Signed-off-by: Wentao Liang Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260607030950.83636-1-vulab@iscas.ac.cn Signed-off-by: Chen-Yu Tsai Signed-off-by: Greg Kroah-Hartman commit 63c70e292e6b491bdcad3afdab519900c9ec66f4 Author: Amit Barzilai Date: Mon Jun 22 15:26:02 2026 +0300 drm/ssd130x: fix column and row end address in partial updates for ssd132x commit 99e9c09358195454ecd200b9c6aba6b7d209fad4 upstream. On partial screen updates, SSD132X controllers expect to get the rectangle addresses as arguments of the "Set Column Address" and "Set Row Address" commands. Each command expects the start address and end address of the row/column in absolute format, however the end addresses were being sent in a relative format (relative to the start address). The relative end addresses work only when the start address is 0. In those situations, there is no value difference between relative and absolute addresses. Fixes: fdd591e00a9c9 ("drm/ssd130x: Add support for the SSD132x OLED controller family") Cc: stable@vger.kernel.org Signed-off-by: Amit Barzilai Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260622122604.32500-2-amit.barzilai22@gmail.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Greg Kroah-Hartman commit 18b3433f10ee9c69e3252046028aa2be421f2d4d Author: Deepanshu Kartikey Date: Thu Aug 13 12:19:02 2026 +0530 drm/i915: Guard against NULL driver_data in i915_pci_probe() commit 3785d40831ba5601296283e0197e10e089392757 upstream. pci_match_device() can return the dummy pci_device_id_any entry when a device is force-bound via sysfs driver_override, in which case ->driver_data is unset (NULL). i915_pci_probe() casts it to struct intel_device_info * unconditionally and dereferences intel_info->require_force_probe, causing a NULL-ptr-deref. Reported-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=db96c5ff032f4292a8dc Tested-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260813064902.367504-1-kartikey406@gmail.com Signed-off-by: Jani Nikula (cherry picked from commit 2727922084672cc274ecea726ea00363c2893731) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 79d09cfe90304ff4f195e47d569800f5e0f8b854 Author: Danilo Krummrich Date: Sun Jun 28 16:53:36 2026 +0200 drm: fix race between partial drm_dev_register() failure and ioctl commit eb197f7d60f00d0f5b1b3505dfc86a7e36045a3e upstream. If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register(). Fixes: bee330f3d672 ("drm: Use srcu to protect drm_device.unplugged") Cc: stable@vger.kernel.org Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260620190648.2E9F61F000E9@smtp.kernel.org/ Reviewed-by: Alexandre Courbot Reviewed-by: Lyude Paul Tested-by: Deborah Brouwer Link: https://patch.msgid.link/20260628145406.2107056-17-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 0259846b15a665c6762a86b3fa0eb8b674b35d1c Author: Johan Hovold Date: Fri Jul 17 16:31:18 2026 +0200 drm/panel-edp: fix i2c adapter leak on probe failure commit e2a9e291275a74e309a21cbb1def6296a72d6aed upstream. Make sure to drop the i2c adapter reference on probe failure (e.g. probe deferral) and on driver unbind also if a devicetree redundantly uses the 'ddc-i2c-bus' property to point to the aux ddc bus. Fixes: cc5a3fc041f0 ("drm/panel: panel-simple: Stash DP AUX bus; allow using it for DDC") Cc: stable@vger.kernel.org # 5.15 Reported-by: Douglas Anderson Link: https://lore.kernel.org/r/CAD=FV=VZPhzHU+Pet2m3L+Pqc7mOPfZC-f5p0OuNL79wNZPxRg@mail.gmail.com Signed-off-by: Johan Hovold Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260717143119.1815106-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit b51d8fb5e58c2a272bdf40f2170ebae25116ce87 Author: Johan Hovold Date: Fri Jul 17 11:08:19 2026 +0200 drm/bridge: dw-hdmi: fix i2c adapter leak on probe failure commit 09b195a7bb23df56269cd2a95d01ba3a5533af13 upstream. Make sure to drop the i2c adapter device and module references before returning when detecting a malformed devicetree during probe. Fixes: 80e2f97968b5 ("drm: bridge: dw-hdmi: Switch to regmap for register access") Cc: stable@vger.kernel.org # 4.12 Cc: Neil Armstrong Signed-off-by: Johan Hovold Reviewed-by: Luca Ceresoli Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260717090819.1630965-1-johan@kernel.org Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 80c9528661c774f899281c9a72011208ff39929e Author: Osama Abdelkader Date: Mon Jul 20 15:44:35 2026 +0200 drm/panthor: fix firmware control interface bounds checks commit 6a47f9fd2d970674ed9dedc52fc7ab76fd015785 upstream. panthor_init_cs_iface() and panthor_init_csg_iface() validate firmware control interface offsets with 32-bit arithmetic and the size of the host wrapper structures. The offsets are derived from firmware-provided strides, so the arithmetic can wrap before the bounds check, and the host wrapper size is not the size of the firmware control interface being mapped. Use 64-bit arithmetic for the computed offsets and validate against the actual firmware control interface structure sizes with subtraction-based bounds checks. Also validate that the shared section is large enough for the global control interface before using it. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Steven Price Reviewed-by: Liviu Dudau Link: https://patch.msgid.link/20260720134435.13377-1-osama.abdelkader@gmail.com Signed-off-by: Steven Price Signed-off-by: Greg Kroah-Hartman commit 5516f1acfd07564361cf306cc90a8e513df0f096 Author: Osama Abdelkader Date: Mon Jul 20 13:32:11 2026 +0200 drm/panthor: harden firmware build-info bounds checks commit 8321b093fa6c297b80586460ce6914d9655df170 upstream. panthor_fw_read_build_info() checks whether the metadata range fits in the firmware image with hdr.meta_start + hdr.meta_size. Both fields are u32, so the addition can wrap and let an out-of-bounds range pass validation. The function also reads the "git_sha: " prefix without first checking that the metadata is long enough, and meta_size == 0 can underflow the NULL terminator index. Use subtraction-based bounds checking and reject metadata that is too short to contain the expected prefix and trailing NULL byte. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patch.msgid.link/20260720113212.11981-1-osama.abdelkader@gmail.com Signed-off-by: Greg Kroah-Hartman commit ef41e8e4ae5b737861db2dfdb540485affb3b753 Author: Matthew Auld Date: Wed Sep 2 13:41:20 2026 +0100 drm/xe/vram: report FLAT_CCS base misalignment commit 0e68c74e44da81a4599c52437ee1f63a2c234470 upstream. So we can easily check if a machine had the CCS bug, when looking back over bug reports where we have the same machine with newer kernel. Example print for a machine with the CCS bug: FLAT_CCS base:27bbff800, aligned:no v2 (Matt B): - Unconditionally print the base + alignment Fixes: 37173392741c ("drm/xe/vram: fix ccs offset calculation") Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: Rodrigo Vivi Cc: stable@kernel.org Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260902124117.918018-9-matthew.auld@intel.com (cherry picked from commit d00b7f4f03bbeb2efad872f1686130e18c2b4141) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit e184e46ca1ba652ab8053a10a51b39aad06d3f5c Author: Thomas Hellström Date: Sat Jul 25 12:00:31 2026 +0200 drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init() commit e773798e14ac0aea54ca9676083b91f445e5bc59 upstream. drmm_cgroup_register_region() is called before INIT_LIST_HEAD() and gpu_buddy_init() in amdgpu_vram_mgr_init(). If it fails, the function returns early and bypasses those initializations. Since adev->mman.initialized is set to true before amdgpu_vram_mgr_init() is called, a failure triggers amdgpu_ttm_fini(), which calls amdgpu_vram_mgr_fini(), which then: - Calls list_for_each_entry_safe() on reservations_pending and reserved_pages, whose list_head::next pointers are zero-initialized (NULL). The loop does not recognize them as empty and dereferences NULL. - Calls gpu_buddy_fini(), which iterates free_trees[] unconditionally via for_each_free_tree(). Since mm->free_trees is NULL (never allocated), this dereferences NULL. Both result in a kernel panic on the module load error path. Fix by moving drmm_cgroup_register_region() to after the list and buddy allocator are fully initialized, so the teardown path is safe to run. Reported-by: Sashiko-bot Closes: https://sashiko.dev/#/patchset/20260428073116.15687-1-thomas.hellstrom@linux.intel.com?part=4 Fixes: 2b624a2c1865 ("drm/ttm: Handle cgroup based eviction in TTM") Cc: Friedrich Vock Cc: Maarten Lankhorst Cc: Tejun Heo Cc: Maxime Ripard Cc: Christian König Cc: Alex Deucher Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org # v6.14+ Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström Reviewed-by: Arunpravin Paneer Selvam Reviewed-By: Maarten Lankhorst Tested-by: Thadeu Lima de Souza Cascardo Link: https://patch.msgid.link/20260725100036.2372-2-thomas.hellstrom@linux.intel.com Acked-by: Christian König Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit 91ec55ddc097ccddd25ffb95a3d079b2ef362372 Author: Chao Yu Date: Tue Aug 11 15:16:37 2026 +0800 f2fs: fix to zero post-EOF data when extending file size commit 5eced87b7d19dbc76ebdddaf322046f9ac582fcb upstream. generic/794 4s ... - output mismatch (see /share/git/fstests/results//generic/794.out.bad) # --- tests/generic/794.out 2026-06-12 08:46:32.766426241 +0800 # +++ /share/git/fstests/results//generic/794.out.bad 2026-07-05 18:32:55.000000000 +0800 # @@ -1,4 +1,16 @@ # QA output created by 794 # append_write # +FAIL: non-zero data in gap [4080,4096) after shutdown+remount # +000000 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a >ZZZZZZZZZZZZZZZZ< # +* # +001000 # truncate_up # ... # (Run 'diff -u /share/git/fstests/tests/generic/794.out /share/git/fstests/results//generic/794.out.bad' to see the entire diff) Ran: generic/794 Failures: generic/794 Failed 1 of 1 tests Steps of generic/794: 1. write 4096 bytes to file w/ 0x5a 2. use fiemap to get PBA of first block in file 3. truncate file to 4080 4. umount; write 4096 bytes to file w/ 0x5a directly via PBA; mount 5. extend filesize via a) append 4096 from offset 4096, or b) truncate 8192, or c) fallocate 4096 from offset 4096 6. verify the gap is zeroed in memory [4080,4096) 7. sync range 4096 from offset 4096; shutdown -f (flush meta before shutdown) 8. umount; mount; verify [4080,4096) is zeroed or not. When extending file size (e.g. via truncate, fallocate, or write) across an unaligned EOF boundary, we need to ensure that post-EOF data in the partial page is zeroed out in pagecache and marked dirty, then writeback the cache to persist zeroed data before committing inode w/ updated i_size. This help to prevent stale disk data beyond the previous EOF from being exposed after remounting or crash recovery. Since f2fs is a LFS filesystem, we only support direct write via PBA in pinfile, and pinfile has section-aligned filesize, so in Android, there should no problem, but for other usage in different environment, let's fix this w/ fsync_mode=strict mount option. Cc: stable@kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit a984446aa9d5b787afa3023fc7b44017b80fe3bc Author: Chao Yu Date: Thu Aug 6 20:35:37 2026 +0800 f2fs: fix to pass folio->index to f2fs_sanity_check_node_footer() commit 7e188e9f9437ab47c3237d609f1b26348d6fea1a upstream. Otherwise in f2fs_sanity_check_node_footer(), it will check the same nid incorrectly. Cc: stable@kernel.org Fixes: 0a736109c9d2 ("f2fs: fix to do sanity check on node footer in __write_node_folio()") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit dde99df5a9d3b0ca6ac0a86f98799685f7399432 Author: Chen Changcheng Date: Tue Aug 4 08:54:02 2026 +0800 f2fs: fix valid block count leak on data block allocation failure commit 0f9af07ecc1ab486038373db6ae0436c5d674b19 upstream. In __allocate_data_block(), when allocating a new data block (dn->data_blkaddr == NULL_ADDR), inc_valid_block_count() is called first to increment total_valid_block_count and i_blocks. If the subsequent f2fs_allocate_data_block() fails, the function returns the error directly without rolling back the already-incremented block counts, causing a permanent leak. Fix this by calling dec_valid_block_count() to undo the increment before returning the error. The condition old_blkaddr == NULL_ADDR precisely identifies the case where inc_valid_block_count() was called. Fixes: 7d009e048d7c ("f2fs: fix to handle segment allocation failure correctly") Cc: Reviewed-by: Chao Yu Signed-off-by: Chen Changcheng Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit ab35ae07f2b5b4e118ea47b88577fc7d0e797b17 Author: Chao Yu Date: Wed Aug 5 12:29:20 2026 +0000 f2fs: fix to clear dirty flag on folio in error path commit 5b86eab84ac8e9289b5afc52ef88ab18ba5bacab upstream. If node block is corrupted due to chksum mismatch or inconsistent footer info, it needs to drop clear flag of node folio, in order to persist inconsistent node data to storage. Cc: stable@kernel.org Fixes: b42b179bda9f ("f2fs: fix to do checksum even if inode page is uptodate") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit c16cc4622e4b6619f62ac270a24036478f91a998 Author: Chao Yu Date: Tue Aug 11 15:16:36 2026 +0800 f2fs: fix to off-by-one issue in f2fs_zero_post_eof_page() commit b2205d3cfd6c76fd5c5443ee9fdb498cfb0e1c66 upstream. Otherwise, it will drop one more page after new_size which is not necessary. Cc: stable@kernel.org Fixes: ba8dac350faf ("f2fs: fix to zero post-eof page") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit f6c49fae98f0fc98d4b62f388ade84a11bc1673f Author: Zhan Xusheng Date: Tue Aug 18 22:55:35 2026 +0800 f2fs: fix i_size when pinned fallocate partially fails commit 0f448bb3767ef6119f5cdeabcae3f10d6e75aed6 upstream. From: Zhan Xusheng Commit 4275b59673eb ("f2fs: fix to round down start offset of fallocate for pin file") moved the allocation loop's start down to a section boundary, but the error path still converts @expanded against @pg_start, which holds the unrounded start. @pg_start exists for that conversion: commit 88f2cfc5fa90 ("f2fs: fix to update last i_size if fallocate partially succeeds") added it as an immutable base because map.m_lblk moves every round. Each round now maps exactly sec_blks blocks starting from rounddown(pg_start, sec_blks), so pg_start + expanded overshoots the last allocated block by pg_start % sec_blks, and a partial failure leaves i_size covering a tail that was never allocated. Nothing corrects that afterwards either, since file_dont_truncate() has already cleared FADVISE_TRUNC_BIT. It needs a start offset that is not section aligned plus a fallocate that hits ENOSPC partway, so the error path runs with expanded > 0. On an 80 MiB image with 2 MiB sections: truncate -s 80M img mkfs.f2fs -s 1 -f img mount -o loop img /mnt touch /mnt/pinned f2fs_io pinfile set /mnt/pinned # 2093056 = block 511, so pg_start % sec_blks = 511 f2fs_io fallocate 0 2093056 536870912 /mnt/pinned stat -c %s /mnt/pinned filefrag -v /mnt/pinned The last extent ends at block 10737 either way. Before, i_size is 46075904, block 11249, so 511 blocks of it were never allocated, and filefrag does not mark the last extent eof. After, i_size is 43982848, block 10738, and eof is back. A kernel from before that commit also shows no overshoot. Keep @pg_start pointing at where allocation actually begins. Fixes: 4275b59673eb ("f2fs: fix to round down start offset of fallocate for pin file") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 161513f53e4ac90fd356433bdf8e31e6adeb92af Author: Chao Yu Date: Mon Aug 24 21:17:29 2026 +0800 f2fs: fix to avoid potential deadloop in f2fs_fsync_node_pages() commit ce366bfa821ec81dd45bde547ee31e659306cc61 upstream. There is potential deadloop in race condition: Thread A Thread B - fsync - f2fs_do_sync_file - f2fs_fsync_node_pages - last_fsync_dnode - folio_get(last_folio) - f2fs_setattr - f2fs_truncate - f2fs_truncate_blocks - f2fs_do_truncate_blocks - f2fs_truncate_inode_blocks - truncate_dnode - truncate_node - invalidate_mapping_pages - folio->mapping = NULL - is_node_folio alwasy return false - atomic && !marked is always true, then goto retry Cc: stable@kernel.org Fixes: 608514deba38 ("f2fs: set fsync mark only for the last dnode") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit b8ae1228c153622afa71a179c9d4dc268117e0f0 Author: Daeho Jeong Date: Wed Aug 19 11:06:35 2026 -0700 f2fs: fix to migrate all curseg types during free_segment_range commit 8ec06f50ddd8d201bd7e55b896ae28ed9d4cb7d1 upstream. In free_segment_range(), the curseg evacuation loop only iterates up to NR_CURSEG_PERSIST_TYPE (0..5), missing non-persistent in-memory curseg types such as CURSEG_COLD_DATA_PINNED and CURSEG_ALL_DATA_ATGC. Even though these in-memory curseg types are not saved in the on-disk checkpoint header, they still occupy active physical segments at runtime. If an active in-memory curseg happens to be allocated within the segment range being truncated during filesystem shrink, failing to evacuate it will cause subsequent writes to the curseg attempting out-of-bounds I/O on the truncated storage range. Fix this by expanding the curseg evacuation loop upper bound to NR_CURSEG_TYPE to ensure all active curseg types are safely migrated out of the target range. Fixes: d0b9e42ab615 ("f2fs: introduce inmem curseg") Cc: stable@vger.kernel.org Signed-off-by: Daeho Jeong Signed-off-by: Sunmin Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit aefcec3bebdeed2bff444378122300763325ba23 Author: Wenjie Qi Date: Tue Aug 4 09:48:48 2026 +0800 f2fs: avoid NULL checkpoint thread access in sysfs commit 5cb33b00c8fbb6e8f1fa3d281c3036d5f7c7c41f upstream. checkpoint_merge can be enabled even when no checkpoint merge thread is running. A read-only mount is one case: f2fs does not start f2fs_issue_ckpt there, but ckpt_thread_ioprio is still writable through sysfs. The ckpt_thread_ioprio store path updates the saved ioprio value and, when checkpoint_merge is enabled, calls set_task_ioprio() for the checkpoint thread. If cprc->f2fs_issue_ckpt is NULL, that dereferences a NULL task pointer. Protect ckpt_thread_ioprio sysfs writes with s_umount as well, so the checkpoint thread cannot disappear under the store path while updating its ioprio. Fixes: e65920661708 ("f2fs: add ckpt_thread_ioprio sysfs node") Cc: stable@kernel.org Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit aefb4b0f465b6f95fe02b52d1822a3fb4a9ae922 Author: Guanghui Yang <3497809730@qq.com> Date: Sun Jul 19 16:45:14 2026 +0800 f2fs: fix dentry folio leak in find_in_level commit cca7d3e30bf30333314e31bc70b9a739f1342167 upstream. find_in_level() gets a dentry folio with f2fs_find_data_folio() before calling find_in_block(). If find_in_block() returns an error, the function stores the error in res_folio and breaks out of the loop without dropping the dentry folio. This leaks the folio reference on the find_in_block() error path. Drop the dentry folio before returning the error to the caller. Fixes: 7ad08a58bf67 ("f2fs: Handle casefolding with Encryption") Cc: stable@vger.kernel.org Reviewed-by: Chao Yu Signed-off-by: Guanghui Yang <3497809730@qq.com> Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 94917ffab3a9446da46ff494c609c4be287944bc Author: Chao Yu Date: Mon Jun 29 11:49:18 2026 +0000 f2fs: fix to avoid potential section-unaligned pinfile commit d0a481fad5c7a3a56ecf54a099651216869f4d0a upstream. Blocks of pinfile may not aligned to section size due to wrong use on pinfile, result in heavy overhead of GC, let avoid this by adding additional check condition in f2fs_setattr(). - truncate -s 8mb pinfile : random checkpoint may persist filesize w/ inode - fallocate -o 0 -l 8mb pinfile - f2fs_fallocate - f2fs_expand_inode_data - f2fs_allocate_pinning_section - f2fs_map_blocks - f2fs_map_lock - __allocate_data_block - file_need_truncate : w/ FADVISE_TRUNC_BIT, we can expect unaligned mapping can be truncated while open() if f2fs is not umount abnormally - f2fs_map_unlock : following f2fs checkpoint and sudden power-cut - mount - open pinfile - f2fs_file_open - finish_preallocate_blocks - truncate_setsize : filesize is 8mb - f2fs_truncate : can only truncate block outside filesize, rather than truncating unaligned blocks inside filesize Fixes: f5a53edcf01e ("f2fs: support aligned pinned file") Cc: stable@kernel.org Cc: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 3e61c3944b83c1a278220a30a7b63e28ee33b205 Author: Wenjie Qi Date: Mon Jul 27 15:49:10 2026 +0800 f2fs: return writeback error from collapse range commit f8a4108800254d6f7b2755515fbbd9d0caac561e upstream. f2fs_collapse_range() writes back pages moved by f2fs_do_collapse(), but ignores the return value. If writeback fails, the ioctl can still truncate page cache, shrink blocks, and report success. Return the error before truncating page cache or updating the file size. Fixes: b4ace3370324 ("f2fs: support FALLOC_FL_COLLAPSE_RANGE") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 3b681229e9f8fb1dd29bc65983bf3c87779e4ca3 Author: Zhan Xusheng Date: Thu Jul 16 10:59:08 2026 +0800 f2fs: use the mount idmap for the owner check in f2fs_xattr_advise_set() commit a54ffce4637acb0db8e695188a6c7f99f14c3576 upstream. f2fs_xattr_advise_set() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing the "system.advise" xattr to be set, instead of the idmap that the VFS passes to the ->set() handler. f2fs supports idmapped mounts, so on such a mount this checks the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EPERM and an unrelated caller wrongly allowed. Pass the handler's idmap instead. Fixes: 01beba7957a2 ("fs: port inode_owner_or_capable() to mnt_idmap") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Reviewed-by: Chao Yu Acked-by: Christian Brauner (Amutable) Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit db504781ea9b0f08855d342919129a1f6b32c4aa Author: Joanne Chang Date: Tue Jun 23 06:34:28 2026 +0000 f2fs: dirty directory inodes on mtime/ctime update commit 9ec09d5f4b317a417c8655c14056f70cbe71eb6c upstream. Xfstests generic/547 sometimes fail with mismatched directory metadata before and after a power failure. This happens because when a directory entry is added, renamed, or deleted, its mtime and ctime are updated and the inode is marked dirty via f2fs_mark_inode_dirty_sync(dir, sync=false). The sync=false flag means the dirty inode is not added to the global DIRTY_META list. Therefore, subsequent checkpoints skip flushing these updated directory blocks, causing directory timestamps to revert to stale values after a sudden power failure. Address this by changing the dirtying parameter to sync=true during directory entry mutations and renames. This forces F2FS to immediately queue the updated directory blocks on the global DIRTY_META list, ensuring timestamps are committed to checkpoints. Fixes: 7c45729a4d6d ("f2fs: keep dirty inodes selectively for checkpoint") Cc: stable@vger.kernel.org Signed-off-by: Joanne Chang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit dc652b2fe916cbcb3ed215c576444f8132dc27c0 Author: Chao Yu Date: Tue Jun 23 20:48:23 2026 +0800 f2fs: fix to avoid move_range and defragment on device_alias file commit 1b4db09b7f10895dc1a0bc32704c7de05188fb1d upstream. It's forbidden to migrate blocks of device alias file. Cc: stable@kernel.org Fixes: 128d333f0dff ("f2fs: introduce device aliasing file") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 445e4a1e6025ecd5312e9a95c1b234192c976ca1 Author: Wenjie Qi Date: Mon Jul 27 21:04:29 2026 +0800 f2fs: only redirty pinned folios in redirty_blocks commit 85171332742e741ccd6f401c69b6e0d698119e72 upstream. redirty_blocks() pins folios with read_cache_folio() and then walks the same range again with filemap_lock_folio() to redirty them and drop the references it took. Commit 5951fee46bef ("f2fs: Use a folio in redirty_blocks()") changed the second pass to a do/while loop. If read_cache_folio() fails before anything is pinned, page_idx does not advance but the cleanup loop still runs once. If readahead has already populated the failed folio in page cache, that extra iteration finds it and folio_put_refs(folio, 2) drops one reference too many. Later drop_caches or reclaim can then report "BUG: Bad page state". Only redirty the range that was pinned successfully. Fixes: 5951fee46bef ("f2fs: Use a folio in redirty_blocks()") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 7f89e2775d5bb8d49cea8560489cad25c778f740 Author: Hao-Qun Huang Date: Wed Jul 8 14:54:39 2026 +0800 f2fs: reject overlapping move range after len expansion commit 28c1ef094e7c86977d9bf570dc0362fc54e36437 upstream. F2FS_IOC_MOVE_RANGE treats a zero length as a request to move data from pos_in to EOF. However, the same-file overlap check runs before that expansion, so a request with len == 0 bypasses the overlap rejection added for same-file moves. For example, with a four-block file, moving from block 0 to block 1 with len == 0 is accepted by the old check because pos_in + len is still pos_in at that point. The code then expands len to cover the rest of the file and calls __exchange_data_block() on overlapping source and destination ranges in the same inode, which is the data-corruption case the overlap check was meant to reject. Move the overlap check after the source range has been validated and len == 0 has been expanded, so it sees the effective length. This is a no-op for non-zero len (the value is unchanged there) and keeps the existing early return for identical positions. Fixes: d95fd91c1ac1 ("f2fs: exclude special cases for f2fs_move_file_range") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Hao-Qun Huang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 95d5975c9d1c5629684668e0098a72946ed9d07d Author: Wenjie Qi Date: Mon Aug 10 21:38:32 2026 +0800 f2fs: return symlink writeback errors commit a2c73a7a677afdaa8b16d775188f9ef5cfbfd8b2 upstream. F2FS writes long symlink data with page_symlink() and then flushes the symlink mapping to reduce the chance of exposing a broken symlink. That flush result is currently ignored. If the writeback fails, symlink() still returns success even though the symlink is not durable and the same operation can already surface -EIO through syncfs(). Return the writeback error to userspace and skip the dirsync flush once the symlink data flush has failed. Fixes: d0cae97cb600 ("f2fs: flush symlink path to avoid broken symlink after POR") Cc: stable@kernel.org Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit ac4b019ac07844d3f67ea5e48b1d982b2170d1a7 Author: Nilesh Javali Date: Thu Jul 30 21:28:30 2026 +0530 scsi: qla2xxx: Skip NVMe LS reject IOCB when FW not started commit f7e46ebffc5781aab3f1f5a5d4350addbb5833f4 upstream. qla_nvme_xmt_ls_rsp() bails out to the out: label when firmware is not started (!ha->flags.fw_started), but the out: path unconditionally calls qla_nvme_ls_reject_iocb(), which ends in qla2x00_start_iocbs() and an unconditional doorbell write to the request queue in-pointer register. This rings the firmware doorbell and queues an IOCB that stopped or resetting firmware cannot consume, and touches MMIO during the reset/EEH window where fw_started is also clear. Only emit the LS reject IOCB (and ring the doorbell) when fw_started is set; otherwise just clean up and return. The post-allocation failure cases (SRB alloc / qla2x00_start_sp() failure) run with firmware started and still send the reject. Apply the same guard to the reject emission in qla2xxx_process_purls_pkt(). Fixes: 875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-26-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 4fe5790674097897a1af1367d1e384f7e5a62fb7 Author: Nilesh Javali Date: Thu Jul 30 21:28:34 2026 +0530 scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak commit b93d3bb3afe1b44489927de1eb4e66e8536a5935 upstream. Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory. Fixes: 697a4bc69159 ("[SCSI] qla2xxx: Provide method for updating I2C attached VPD.") Fixes: 9ebb5d9c69f1 ("[SCSI] qla2xxx: Add I2C BSG interface.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-30-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 0bdd0f7a1094a75c892e9c63997863e8c9aa3296 Author: Nilesh Javali Date: Thu Jul 30 21:28:33 2026 +0530 scsi: qla2xxx: Use coherent DMA buffer for D_Port diagnostics commit 7c4f3f50d83af4545efaa99b3d0d46fb8d52031e upstream. qla26xx_dport_diagnostics() streaming-maps the caller's result buffer with dma_map_single(). The bsg path passes &dd->buf from the __packed struct qla_dport_diag, where buf lands at a 2-byte offset and shares cachelines with the surrounding options/unused fields. Mapping such a misaligned sub-buffer violates the DMA API requirement that streaming buffers be cacheline aligned and not share a cacheline with other data, and can corrupt data on non-DMA-coherent architectures. Allocate a dedicated DMA-coherent buffer inside qla26xx_dport_diagnostics() for the mailbox command and copy the result back into the caller's buffer. This removes the streaming map of the misaligned sub-buffer entirely; the caller's buffer is now only a plain CPU buffer, so its packing no longer matters. Fixes: ec89146215d1 ("qla2xxx: Add bsg interface to support D_Port Diagnostics.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-29-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 776e4e8cbcf155302f430ce9793d1502e3c113a0 Author: Nilesh Javali Date: Thu Jul 30 21:28:28 2026 +0530 scsi: qla2xxx: Hold vport_slock for host map update in report ID acquisition commit 7944039ba9cb5c3a935d17c91004e3b8649ff58e upstream. qla24xx_report_id_acquisition() format-1 handling drops vport_slock after taking the vport reference and then calls qla_update_host_map() without the lock. That reaches qla_update_vp_map(), which mutates the ha->host_map btree via btree_insert32()/btree_update32()/btree_remove32() and is documented to require vport_slock to be held by the caller. Running it unlocked can race concurrent host_map updates and corrupt the btree. The format-2 path in the same function already wraps its host_map update (SET_AL_PA) in vport_slock; the format-1 path is the lone outlier. Hold vport_slock across the format-1 qla_update_host_map() call to honor the documented locking contract. The vref_count taken in the loop keeps the vport valid, so this only adds the missing host_map serialization. Fixes: 430eef03a763 ("scsi: qla2xxx: Relocate/rename vp map") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-24-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 16c731c4f296180d708f94125fbc4f76725a4398 Author: Nilesh Javali Date: Thu Jul 30 21:28:27 2026 +0530 scsi: qla2xxx: Drop vport reference under lock in report ID acquisition commit 1154b16439ffc562f9461494c4508c63446eb684 upstream. qla24xx_report_id_acquisition() format-1 handling takes the vport reference under vport_slock but drops it outside the lock, after setting vp->vp_flags and vp->dpc_flags: set_bit(VP_IDX_ACQUIRED, &vp->vp_flags); set_bit(REGISTER_FC4_NEEDED, &vp->dpc_flags); set_bit(REGISTER_FDMI_NEEDED, &vp->dpc_flags); atomic_dec(&vp->vref_count); Neither set_bit() nor atomic_dec() imply a memory barrier, so on a weakly ordered architecture the decrement can become visible before the flag stores. qla24xx_deallocate_vp_id() polls vref_count under vport_slock and unlinks the vport once it reads zero, after which qla24xx_vport_delete() frees it via scsi_host_put(). The poller could therefore observe vref_count == 0 early and tear the vport down while the pending vp_flags/ dpc_flags stores land on freed memory. Drop the reference under vport_slock, as is done for the matching increment and by every other vref_count user. The unlock release pairs with the deallocate poller's lock acquire so the flag stores are ordered before vref_count == 0 can be observed. Fixes: 793cedee296f ("scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition()") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-23-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 17fb63c1d0fcd121b766389bf673338b3185a8c7 Author: Nilesh Javali Date: Thu Jul 30 21:28:29 2026 +0530 scsi: qla2xxx: Fix NVMe abort reference leak on repeated abort commit 06b5b2a5d499323f1c3256ead35798e8e3d15e60 upstream. qla_nvme_ls_abort() and qla_nvme_fcp_abort() take a command reference with kref_get_unless_zero() and then call schedule_work() on priv->abort_work, ignoring its return value. qla_nvme_abort_work() runs once and drops exactly one reference via kref_put(&sp->cmd_kref, sp->put_fn). Since the per-abort INIT_WORK() was moved to submission time, schedule_work() now returns false when the work is already pending, for example on a concurrent transport teardown and timeout-driven abort of the same command. In that case the reference taken for the second abort is never released because the work still executes only once, leaking a reference. The command is then never returned to the NVMe-FC transport, which can hang the port. Drop the reference when schedule_work() returns false, so each kref_get_unless_zero() is balanced regardless of whether the work was newly queued. The held reference keeps priv->sp valid for the put. Fixes: 7e85f6dbc856 ("scsi: qla2xxx: Initialize NVMe abort_work once at submission") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-25-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 5dd9bec8004ba93cee8b689bf54ce294f59e5e3c Author: Nilesh Javali Date: Thu Jul 30 21:28:21 2026 +0530 scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() commit deb8abde83a799d2501f3977f6d6051000253f5e upstream. qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference. Fixes: a6fe35c052c4 ("[SCSI] qla2xxx: Avoid invalid request queue dereference for bad response packets.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-17-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit d7f7746ff031ae45724881261804f4bf5317c985 Author: Nilesh Javali Date: Thu Jul 30 21:28:20 2026 +0530 scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read commit ca6d880d6c70cb7946e7b3e05d7285f271b6d99e upstream. In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: if (IS_FWI2_CAPABLE(ha)) { sense_data += rsp_info_len; par_sense_len -= rsp_info_len; } rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): if (sense_len > par_sense_len) sense_len = par_sense_len; memcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites. Fixes: 5544213be7b4 ("[SCSI] qla2xxx: Correct extended sense-data handling.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-16-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 9fa1d71233a82416492d9c9de9756ebe140fe714 Author: Nilesh Javali Date: Thu Jul 30 21:28:25 2026 +0530 scsi: qla2xxx: Avoid double completion in async IOCB timeout commit bb45bc4bd53c95a7bf6f782577b5ede94c0f8aa8 upstream. qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates "if (sp->comp) complete(sp->comp)"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout(). Fixes: f6145e86d21f ("scsi: qla2xxx: Fix race between switch cmd completion and timeout") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-21-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 10e9f05f7fd0a103886a867ec8afe621fe4b906a Author: Nilesh Javali Date: Thu Jul 30 21:28:22 2026 +0530 scsi: qla2xxx: Quiesce response IRQ before freeing request queue commit 505753ec2594c6af09a601f0dd60be7d840c1d2d upstream. qla2xxx_delete_qpair() deletes the request queue before the response queue. qla25xx_delete_req_que() frees the request queue memory (kfree(req) in qla25xx_free_req_que()), but the response-queue MSI-X is only released later, in qla25xx_free_rsp_que(). In that window the response interrupt can still fire, qla2xxx_msix_rsp_q() queues qpair->q_work, and qla_do_work() -> qla24xx_process_response_queue() dereferences the now-freed rsp->req (LOGINOUT/CT/ELS entries and the status path), a use-after-free. The cancel_work_sync() added for the qpair teardown lives in the response free path, which runs after the request queue is already freed, so it does not protect rsp->req. Release the response-queue interrupt and flush qpair->q_work before deleting the request queue, so no late completion can reach the freed request queue. Clearing have_irq makes the subsequent qla25xx_free_rsp_que() skip its free_irq(), and the firmware queue-delete order (request then response) is preserved; the request-delete mailbox completes on the default vector and is unaffected by dropping the qpair response interrupt early. Fixes: d74595278f4a ("scsi: qla2xxx: Add multiple queue pair functionality.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-18-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 31715d1e1cbf3a37ce3452635c5602f73fd7abd4 Author: Nilesh Javali Date: Thu Jul 30 21:28:18 2026 +0530 scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb() commit 3ba019bdd89d931499d9476456b5d9c7ab7fa753 upstream. qla24xx_process_response_queue() advances ring_ptr past the head IOCB before dispatching, so by the time __qla_consume_iocb() runs, ring_ptr already points at the first continuation IOCB. The function however looped purex->entry_count times starting at ring_ptr. As entry_count includes the head, this consumed one entry too many: it stamped RESPONSE_PROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked. Mark the head processed and account for it, then consume only the entry_count - 1 continuation IOCBs, matching __qla_copy_purex_to_buffer(). Fixes: fac2807946c1 ("scsi: qla2xxx: edif: Add extraction of auth_els from the wire") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-14-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit e93aa3c5125d9a4352ac0fa8ba4a7f8f87881805 Author: Nilesh Javali Date: Thu Jul 30 21:28:23 2026 +0530 scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path commit 0f41d07d72f2245208c45374ca8d0a1846cad667 upstream. qla2x00_status_entry() filters out non-TYPE_SRB entries and the SRB_NVME_CMD, SRB_BIDI_CMD and SRB_TM_CMD types, then falls through to a SCSI fast path that assumes the command is an SRB_SCSI_CMD. The first thing on that path, qla_chk_edif_rx_sa_delete_pending(), and the subsequent handling both evaluate GET_CMD_SP(sp), i.e. sp->u.scmd.cmd. The srb u union overlays the SCSI command pointer with other command layouts (bsg_job, iocb_cmd). If firmware delivers an unexpected STATUS_TYPE IOCB for a non-SCSI handle, sp->u.scmd.cmd can read as a non-NULL garbage pointer, bypassing the NULL checks in qla_chk_edif_rx_sa_delete_pending() and at the cp == NULL test, and leading to a wild pointer dereference. Reject any SRB whose type is not SRB_SCSI_CMD before entering the fast path. The outstanding_cmds slot is left untouched so a genuinely non-SCSI command still completes through its proper handler. Fixes: dd30706e73b7 ("scsi: qla2xxx: edif: Add key update") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-19-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit a194684853dceaa1d6b7a9a02bc12f479232ad9b Author: Nilesh Javali Date: Thu Jul 30 21:28:12 2026 +0530 scsi: qla2xxx: Don't query firmware state while chip is down commit e0cebe20dcffbed9c078fe30e2d18cd5046d9eff upstream. qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy. Fixes: b6faaaf796d7 ("scsi: qla2xxx: Serialize mailbox request") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-8-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 7203d4aed8f444e7376c2dee8d93577b37cf9989 Author: Nilesh Javali Date: Thu Jul 30 21:28:14 2026 +0530 scsi: qla2xxx: Fix FCE trace enable parsing in debugfs commit b7368687e3d11f51392d3c4774ec0263d5fbf31f upstream. qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as "disable" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace. Fixes: 841df27d619e ("scsi: qla2xxx: Move FCE Trace buffer allocation to user control") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-10-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit e6cfb1ee18336aab41a0941d6d3ea5009aaafc05 Author: Nilesh Javali Date: Thu Jul 30 21:28:13 2026 +0530 scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() commit 9efaa782845b4d5fb3e01242be0d06ebc7428d8f upstream. The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents. Fixes: 4d4df1932b6b ("[SCSI] qla2xxx: Add ISP84XX support.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-9-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 8e7a26931b6111583cfeaf49c068f26524dc3af2 Author: Nilesh Javali Date: Thu Jul 30 21:28:15 2026 +0530 scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump commit 53298efcbbb0f0438366d45cb7ed7e6d93dd5531 upstream. qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it. Fixes: 841df27d619e ("scsi: qla2xxx: Move FCE Trace buffer allocation to user control") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-11-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 8286a9095fb59751fba171afa2b4f590271c87d5 Author: Nilesh Javali Date: Thu Jul 30 21:28:11 2026 +0530 scsi: qla2xxx: Fix cs84xx use-after-free on host teardown commit 33d102102d925357c5fd172dd6672a27d74b3215 upstream. qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed. Fixes: fe1b806f4f71 ("[SCSI] qla2xxx: Refactor shutdown code so some functionality can be reused.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-7-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 8d116137119371349fb09685fe05413d8fc92efe Author: Nilesh Javali Date: Thu Jul 30 21:28:08 2026 +0530 scsi: qla2xxx: Serialize flash version read in reset handler commit f606ed93de0c4f1e7e3618779e9fad731455314a upstream. The "update cache versions without reset" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path. Fixes: 8c2cf7d4e387 ("[SCSI] qla2xxx: Add a new interface to update versions.") Reported-by: Sashiko Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-4-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 7a448f5ed0b283dbde4e9183dd1e98c221432dab Author: Nilesh Javali Date: Thu Jul 30 21:28:06 2026 +0530 scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation commit ebfd35c64433821bd5619a6d07ccc2df8b5b1de3 upstream. ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as "ha->max_req_queues = ha->msix_count - 1" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent "ha->max_req_queues--" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following "ha->req_q_map[0] = req" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs). Fixes: d74595278f4a ("scsi: qla2xxx: Add multiple queue pair functionality.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-2-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 11834e5773e20fd3742d7eb900876e66b9e7d029 Author: Nilesh Javali Date: Thu Jul 23 10:34:09 2026 +0530 scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject commit f743488e4a203049f27ec5d8cd0caccc483af01e upstream. qla_nvme_ls_reject_iocb() allocates from and advances the request ring through __qla2x00_alloc_iocbs() (which assumes the hardware_lock is held) and qla2x00_start_iocbs() (which advances the ring and rings the request-in doorbell), but takes no lock itself. Two of its callers invoke it without the producer lock held: - qla_nvme_xmt_ls_rsp(), the NVMe-FC .xmt_ls_rsp transport callback, on its error path, and - qla2xxx_process_purls_pkt(), run from the purex work/DPC context. Both use ha->base_qpair, whose qp_lock_ptr is hardware_lock, so they can run concurrently with normal I/O submission on the base ring and corrupt the ring producer state, leading to duplicated or dropped commands. The third caller, qla2xxx_process_purls_iocb(), runs inside qla24xx_process_response_queue() with the qpair lock already held and is safe; that is also why the lock cannot be taken inside the helper itself (it would recursively re-acquire hardware_lock on the response path). Take qp_lock_ptr around the two unlocked callers and document the helper as caller-locked. Both run in process context, so spin_lock_irqsave() is used and nothing in the locked region sleeps. Fixes: 875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-53-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 7b22b4cb8822805cef7ba618da6f76e1474d68bd Author: Nilesh Javali Date: Thu Jul 23 10:34:12 2026 +0530 scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() commit de62cf265dbe309f34f144a6cdbca9240317727e upstream. qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer. Fixes: 697a4bc69159 ("[SCSI] qla2xxx: Provide method for updating I2C attached VPD.") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-56-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 5ecdb336df2a9df3b4a6d2b1c74271f8765619e7 Author: Nilesh Javali Date: Thu Jul 23 10:34:06 2026 +0530 scsi: qla2xxx: Check entry_status in qla24xx_modify_vp_config() commit 9101c51649f5b6773a97bf5271785c948589ea1d upstream. The Modify VP Config completion handler labelled its first error branch "error status" but tested vpmod->comp_status instead of vpmod->entry_status. Because CS_COMPLETE is 0, the following "comp_status != CS_COMPLETE" branch duplicated that test and was dead code, and entry_status was never examined at all. When firmware rejects the IOCB early it sets entry_status while leaving comp_status zero. As the IOCB is allocated with dma_pool_zalloc(), both comp_status branches evaluate false and the handler falls through to the success path, calling fc_vport_set_state(FC_VPORT_INITIALIZING) for a configuration the firmware never accepted. This can leave the virtual port enabled on top of an invalid config and surface later as login timeouts or follow-on firmware errors. Test entry_status in the first branch, matching qla_ctrlvp_completed() and the login/logout/abort/reset IOCB handlers; the comp_status branch then becomes the live completion-status check. Fixes: 2c3dfe3f6ad8 ("[SCSI] qla2xxx: add support for NPIV") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-50-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 67f0d5187c29360388f7e1e503c627ec45d01089 Author: Nilesh Javali Date: Thu Jul 23 10:34:08 2026 +0530 scsi: qla2xxx: Initialize NVMe abort_work once at submission commit 7e85f6dbc85616de2172bce8eaf84b387a723cd1 upstream. qla_nvme_fcp_abort() and qla_nvme_ls_abort() ran INIT_WORK() on priv->abort_work immediately before schedule_work(). INIT_WORK() reinitializes the work_struct, resetting its list head and clearing the pending bit. If an abort is issued more than once for the same command (for example, concurrent transport teardown and a timeout-driven abort), the second INIT_WORK() reinitializes a work item that is already queued, which can corrupt the workqueue list and lead to crashes or a looping worker. Initialize priv->abort_work once at command submission, next to the existing per-command spin_lock_init(&priv->cmd_lock), and leave only schedule_work() in the abort paths. schedule_work() already does nothing when the work item is still pending, so a repeated abort no longer disturbs an in-flight work item. The command is not returned to the transport until the final kref_put()/release callback runs after abort_work has completed, so the work item is idle before priv is reused and the single submission-time INIT_WORK() is safe. Fixes: e473b3074104 ("scsi: qla2xxx: Add FC-NVMe abort processing") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-52-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 47272152a13d202d98496208f9bf382c1cf4d4fb Author: Nilesh Javali Date: Thu Jul 23 10:34:07 2026 +0530 scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() commit 793cedee296fd819bfadc2a7ec4d52faf9c09a0a upstream. In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals. Fixes: 2c3dfe3f6ad8 ("[SCSI] qla2xxx: add support for NPIV") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-51-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 206df5ffa72dc850fea700e7ba448701f81829b9 Author: Nilesh Javali Date: Thu Jul 23 10:34:04 2026 +0530 scsi: qla2xxx: Fix Name Server logout detection on FWI2 adapters commit eb137255fd7aa834c4d639ae7b5e9e8ecf3a4fb2 upstream. In the CS_PORT_LOGGED_OUT case of qla2x00_chk_ms_status(), the FWI2-capable branch compared ms_pkt->loop_id.extended against NPH_SNS to decide whether the Name Server had logged out. On FWI2 and later adapters the response is a ct_entry_24xx / ct_entry_24xx_ext, where loop_id.extended (via the legacy ms_iocb_entry_t view) aliases offset 8, which is comp_status, not nport_handle (offset 10). As this code runs under CS_PORT_LOGGED_OUT, the field read back 0x29 (CS_PORT_LOGGED_OUT) and the comparison against NPH_SNS (0x7fc) was always false. As a result the driver never recognized a Name Server logout on FWI2/ 29xx adapters: it returned the generic QLA_FUNCTION_FAILED instead of QLA_NOT_LOGGED_IN and skipped setting LOOP_RESYNC_NEEDED / LOCAL_LOOP_UPDATE, so the fabric rediscovery triggered by an SNS logout did not happen. Read nport_handle from the ct_entry_24xx layout (offset 10) instead. nport_handle is at the same offset in ct_entry_24xx and ct_entry_24xx_ext, so a single cast covers 24xx-class and 29xx. The non-FWI2 branch keeps using loop_id.extended, which is correct for the ms_iocb_entry_t response on those adapters. Fixes: b98ae0d748db ("scsi: qla2xxx: Fix name server relogin") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-48-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 94bfb61478bcb207d27f8cd24fd231421059519f Author: Nilesh Javali Date: Thu Jul 23 10:34:03 2026 +0530 scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check commit c20ee380ca59c5a8646750c4849969a815924e2e upstream. qla_chk_edif_rx_sa_delete_pending() obtains the SCSI command via GET_CMD_SP(sp) and immediately dereferences cmd->sc_data_direction. That command pointer can be NULL: the firmware may post a status completion for a command that has already been returned or aborted. The caller qla2x00_status_entry() acknowledges this on the very same status path, re-fetching GET_CMD_SP(sp) and bailing out with the "Command already returned" message when it is NULL -- but that check runs only after qla_chk_edif_rx_sa_delete_pending() has already dereferenced the pointer, so a NULL cmd crashes the kernel in interrupt context. Return early when cmd is NULL, before touching cmd->sc_data_direction. Fixes: dd30706e73b7 ("scsi: qla2xxx: edif: Add key update") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-47-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 97ca58b0fb026799b99e3d552d5f69cf9a3113ad Author: Nilesh Javali Date: Thu Jul 30 21:28:37 2026 +0530 scsi: qla2xxx: Bound i2c->length in I2C bsg handlers commit 0918ee2c0eeb4d7f45b82b3dc11e65c2d9b7ad59 upstream. struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: struct qla_i2c_access { uint16_t device, offset, option, length; uint8_t buffer[0x40]; } __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers. Fixes: 9ebb5d9c69f1 ("[SCSI] qla2xxx: Add I2C BSG interface.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-33-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit b157256c28086c434afd70cc78bf9b4d8caf1276 Author: Nilesh Javali Date: Thu Jul 30 21:28:36 2026 +0530 scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers commit b47d4a1547d9ef21b2e9d1a739fe2204d4be05dc upstream. The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: if (len == 1) opt |= BIT_0; if (opt & BIT_0) len = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents. Fixes: 697a4bc69159 ("[SCSI] qla2xxx: Provide method for updating I2C attached VPD.") Fixes: 9ebb5d9c69f1 ("[SCSI] qla2xxx: Add I2C BSG interface.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-32-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit dec5624a3f8cb2bd1a0354038151294f4259d8bd Author: Jackson Lee Date: Fri Jun 26 10:22:27 2026 +0900 media: chips-media: wave5: Set inst->std during default format initialization commit cfcefc5a996f6a00b310c963b5f811430f28a30a upstream. When the encoder is opened, wave5_set_default_format() sets up the default capture format (e.g. H.264) but does not initialize inst->std. As a result, inst->std remains zero, which does not match any valid encoder codec. If STREAMON is called before the user explicitly calls S_FMT on the capture queue — as v4l2-compliance does in testBlockingDQBuf — the codec/product check in wave5_vpu_enc_init_seq() fails with "Unsupported encoder-codec & product combination" because inst->std is neither W_HEVC_ENC nor W_AVC_ENC, returning -EOPNOTSUPP. Fix this by setting inst->std via wave5_to_vpu_std() in wave5_set_default_format(), so that the codec type is always consistent with the default capture pixel format from the moment the instance is opened. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a0506198a77b9e2063b30d718b786cb0203e9061 Author: Jackson Lee Date: Fri Jun 26 10:22:26 2026 +0900 media: chips-media: wave5: Guard bit depth check with initial_info_obtained commit 1551386934ad43d934c3bb7317929207e1edcd6a upstream. When CAPTURE STREAMON is called before the VPU has completed sequence initialization (initial_info_obtained == false), the initial_info fields contain uninitialized data. The driver checks luma_bitdepth and rejects anything other than 8-bit, so garbage values (e.g. 15) cause STREAMON to fail spuriously. This is reproducible with the following multi-threaded test scenario: 1. Allocate 2 CAPTURE buffers. 2. Call STREAMON on the CAPTURE queue. 3. Call DQBUF, which blocks waiting for a decoded frame. 4. A second thread calls STREAMOFF on the CAPTURE queue. 5. The blocked DQBUF should be released, allowing graceful termination. At step 2, STREAMON reads uninitialized luma_bitdepth and rejects the stream, causing the test to fail. Fix this by checking initial_info_obtained before accessing the bit depth fields, so the validation is only performed when the sequence info has actually been parsed by the VPU. Fixes: 035371c9e509 ("media: chips-media: wave5: Fix timeout while testing 10bit hevc fluster") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ff98cd2b8b54cf96bccace2f7b7e4775cdccaf02 Author: Hungyu Lin Date: Tue Jun 30 15:26:17 2026 +0000 media: qcom: iris: use disable_irq() during power-off commit b9c2215bdedc9c532a7e9d57ec49ee1b6381f863 upstream. The IRQ is registered as a threaded IRQ. Using disable_irq_nosync() in iris_vpu_power_off() does not wait for an already queued threaded IRQ handler to complete before returning. As a result, a threaded IRQ handler may still run after the VPU has been powered down and access hardware registers after power-off. Replace disable_irq_nosync() with disable_irq() so the power-off path waits for any in-flight threaded IRQ handler to complete before returning. Fixes: bb8a95aa038e ("media: iris: implement power management") Cc: stable@vger.kernel.org Suggested-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Hungyu Lin Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit ab6f088a44ef79a7c52f026a89cbb40315ccd211 Author: Dikshita Agarwal Date: Sun May 31 11:20:36 2026 +0530 media: qcom: iris: fix state-change debug log printing stale value commit 460d3257a6dffc7f0bf58009daeb7e0b6eb2d9d3 upstream. The state‑change debug log in iris_inst_change_state() always prints the same value for the old and new state, rendering it useless for debugging. This happens because the state is updated before the log is emitted. Log the transition before updating the state so the previous value is preserved, consistent with the existing sub‑state handling. Fixes: 11712ce70f8e ("media: iris: implement vb2 streaming ops") Reviewed-by: Bryan O'Donoghue Reviewed-by: Konrad Dybcio Signed-off-by: Dikshita Agarwal Signed-off-by: Vishnu Reddy Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit f1c4f3885df1f09bcab5296d86834d104f865e86 Author: Ruoyu Wang Date: Wed Jul 8 22:33:49 2026 +0800 media: zoran: Avoid freeing a registered video_device twice commit 0735e0b5a96761a9ce277a238e834008ad92a0a5 upstream. zoran_init_video_device() installs zoran_vdev_release() as the video_device release callback through zoran_template. After video_register_device() succeeds, video_unregister_device() drops the registered video_device reference and the V4L2 core eventually invokes that release callback, which kfree()s the video_device. zoran_exit_video_devices() called video_unregister_device() and then kfree(zr->video_dev), so device teardown could free the same video_device twice. Remove the direct kfree() and clear the cached pointer after unregistering. The pre-registration failure path keeps its manual free because the video_device was not registered there. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 82e3a496eb56 ("media: staging: media: zoran: move videodev alloc") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit dc005cb7ccb0c551992d59bbb3e8def48521caec Author: Arash Golgol Date: Wed Jul 22 20:14:51 2026 +0330 media: vimc: fix pixel format lookup in enum_framesizes commit ad4c65fa30cfb00e2e06adae9a8eb407086eaa66 upstream. vimc_capture_enum_framesizes() looks up the requested format using vimc_pix_map_by_code(), which searches the pix map table by media bus code (MEDIA_BUS_FMT_*). However, v4l2_frmsizeenum::pixel_format holds a V4L2 pixel format (V4L2_PIX_FMT_*), not a media bus code, so valid pixel formats end up being rejected with -EINVAL. Fix this by using vimc_pix_map_by_pixelformat() instead, which performs the lookup by pixel format as the ioctl expects. Fixes: 09c41a23a2e2 ("media: Revert "media: vimc: propagate pixel format in the stream"") Cc: stable@vger.kernel.org Signed-off-by: Arash Golgol Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 52fd9d80c0cea7bf09e7ee36cad316e5c39b7fe6 Author: Uday Khare Date: Mon Jul 6 20:58:33 2026 +0530 media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure commit 76e379754ba618989f6215be608d5c04774a611d upstream. kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path. Fixes: 5cebaac60974 ("media: video-i2c: add video-i2c driver") Cc: stable@vger.kernel.org Signed-off-by: Uday Khare Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4a187d94438457d2d99aa0770c8b9baa1c8387b6 Author: Mohammed EL Kadiri Date: Wed Jun 10 13:56:55 2026 +0100 media: venus: fix payload size calculation in parse_raw_formats() commit bd595b745eb770e80347c31ffc25351046935305 upstream. The consumed size is computed after the loop using the num_planes value from the last iteration for all entries. When entries have different plane counts, this produces an incorrect total. Accumulate the actual size during the loop instead. Fixes: 9edaaa8e3e15 ("media: venus: hfi_parser: refactor hfi packet parsing logic") Cc: stable@vger.kernel.org Signed-off-by: Mohammed EL Kadiri Reviewed-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit d031b5ecc4b39a909842a377dc665faa0926f692 Author: Mohammed EL Kadiri Date: Wed Jun 10 13:56:54 2026 +0100 media: venus: fix payload size returned by parse_caps() and parse_alloc_mode() commit a51cea23e409278f6e2ea072280aba93cc1dd75e upstream. parse_caps() and parse_alloc_mode() return only the size of their fixed header fields, excluding the flexible array payload. hfi_parser() uses this return value to advance through the firmware response buffer, so underreporting causes parser desynchronization. Return the full consumed size (header + entries), matching the correct pattern used by parse_profile_level(). Fixes: 9edaaa8e3e15 ("media: venus: hfi_parser: refactor hfi packet parsing logic") Cc: stable@vger.kernel.org Signed-off-by: Mohammed EL Kadiri Reviewed-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit 3ced388b7908270529e5aa6d221840114b6c33bc Author: Biren Pandya Date: Fri Jun 19 13:41:30 2026 +0530 media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link commit a6e86efd7f85e519bf48417f41923f8bd51f1597 upstream. In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. Signed-off-by: Biren Pandya Fixes: ca50c197bd96 ("[media] v4l: fwnode: Support generic fwnode for parsing standardised properties") Cc: stable@vger.kernel.org [Sakari Ailus: Fix subject prefix and coding style a little.] Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 331f22dd63bf97643c0569cc988448e01acd330d Author: Ming Qian Date: Mon Jul 20 18:17:26 2026 +0900 media: v4l2-ctrls: Allow unknown HDR10 white point and luminance commit 49af0c7cad889f7dabe5cf080b019392066122a3 upstream. SMPTE ST 2086 defines the nominal ranges for mastering display chromaticity and luminance values. Its Annex A also documents that CTA 861-G uses zero maximum and minimum luminance values to signal that the corresponding values are unknown, and the xy chromaticity coordinate (0, 0) to signal that the white point chromaticity is unknown. The V4L2 HDR10 mastering display compound control currently rejects these values. Consequently, an unknown white point or luminance value prevents the entire compound control from being updated, making the other valid mastering display metadata unavailable to userspace. Accept (0, 0) as an unknown white point and zero as an unknown maximum or minimum mastering luminance. Continue to reject partially zero white point coordinates and non-zero values outside the nominal ranges. Display primary validation remains unchanged. Document the newly accepted unknown values in the V4L2 userspace API. Fixes: 1ad0de78e794 ("media: v4l: Add HDR10 static metadata controls") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 3345746e0957bce6c53644838e4955710a82a962 Author: Xu Rao Date: Mon Aug 10 17:50:12 2026 +0800 media: v4l2-async: avoid deleting unlinked ASC entry on link error commit 47d82b605351c0e04f6365e42c8ffe2fcfdba615 upstream. v4l2_async_match_notify() creates ancillary media links before adding asc->asc_subdev_entry to sd->asc_list. If ancillary link creation fails, the function jumps to err_call_unbind while asc_subdev_entry has not been linked yet. Async connections are zero-allocated, so the list entry still has NULL next and prev pointers on this path. Calling list_del() on it can therefore dereference NULL instead of returning the original link creation error. Do not delete asc_subdev_entry from err_call_unbind. There is no list insertion to undo on this path; the bound callback and sub-device registration are the operations that need to be rolled back. Fixes: 28a1295795d8 ("media: v4l: async: Allow multiple connections between entities") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 7c62bd653563939ff0d0fdfd4b8c73c4f97a1dcc Author: Ilya Krutskih Date: Sun Jul 19 13:08:35 2026 +0000 media: tda18250: fix possible integer overflow commit 6dd8e257f7cafda7fbf10d81b3c55c9bba4825f4 upstream. Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior. Fixes: 148abd3b5b14 ("media: tda18250: support for new silicon tuner") Cc: stable@vger.kernel.org Signed-off-by: Ilya Krutskih Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4d2048466af9e2c960c5be6dcd317e3b657d268b Author: Guangshuo Li Date: Sat Jul 18 14:10:11 2026 +0800 media: saa7164: fix cleanup on resource allocation failure commit 28e84c6e2e6753ed238ea097b2842a32a6a6879b upstream. saa7164_dev_setup() adds the device to the global saa7164_devlist before requesting the PCI BAR memory regions. If get_resources() fails, saa7164_dev_setup() decrements the device count and returns an error, but leaves the device on saa7164_devlist. The probe error path then frees the device, leaving a dangling entry on the global list. Reuse the existing MMIO mapping error path to remove the device from saa7164_devlist and decrement the device count before returning. Also release BAR0 if it was successfully requested but the BAR2 request fails. Fixes: 443c1228d505 ("V4L/DVB (12923): SAA7164: Add support for the NXP SAA7164 silicon") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 342632a4d8ba3fafc1556deee0b7a48dd7860336 Author: Lei Huang Date: Tue Jul 14 14:52:02 2026 +0800 media: s2255: check firmware size before reading trailing marker commit 330f2936ab768c7215322a476f033143e8891d28 upstream. s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing. Fixes: 14d962602c8b ("V4L/DVB (8752): s2255drv: firmware improvement patch") Cc: stable@vger.kernel.org Signed-off-by: Lei Huang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 68d664f1b4efe525e99154b7058fcb0378bdaff7 Author: HyeongJun An Date: Wed Jul 1 20:45:36 2026 +0900 media: s2255: bound JPEG frame size before copying into the buffer commit e504cc888f42999dd76b6a43788c422610f2aad2 upstream. s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: payload = le32_to_cpu(pdword[3]); if (payload > vc->req_image_size) /* payload is checked ... */ return -EINVAL; vc->pkt_size = payload; vc->jpg_size = le32_to_cpu(pdword[4]); /* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it. Fixes: 38f993ad8b1f ("V4L/DVB (8125): This driver adds support for the Sensoray 2255 devices.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 93e6ed88f508448faaa8aeba9da9869a6f4bed78 Author: Tommaso Merciai Date: Wed Jul 29 12:55:46 2026 +0200 media: rzg2l-cru: Align bytesperline to hardware DMA stride requirement commit 56c29fa3ee666197516a231e75aed789ae9c530d upstream. The RZ/G3E CRU programs the line stride via the AMnIS register, whose IS field encodes the value in units of 128 bytes. If bytesperline is not a multiple of 128, the division truncates and the hardware uses a wrong stride, causing horizontal banding. Commit ace92ccef0c9 ("media: platform: rzg2l-cru: Use v4l2_fill_pixfmt()") replaced the open-coded aligned calculation with v4l2_fill_pixfmt(), which sets no alignment, reintroducing the issue. Round bytesperline up to RZG2L_CRU_STRIDE_ALIGN and recompute sizeimage when info->has_stride is set. RZ/G2L has no AMnIS register and keeps the values from v4l2_fill_pixfmt() unchanged. Fixes: ace92ccef0c9 ("media: platform: rzg2l-cru: Use v4l2_fill_pixfmt()") Cc: stable@vger.kernel.org Signed-off-by: Tommaso Merciai Reviewed-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 26a2a985bbeee3eaa6f80ff7de732161a171ec9f Author: Valery Borovsky Date: Sat May 23 19:53:58 2026 +0300 media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure commit fe50cdaebf12cd32ff9a44d92bfd6fbc2300dbd4 upstream. rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module") Cc: stable@vger.kernel.org Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7443b16b6dd8889a3b9c5236a09e7c58f0d11dae Author: Valery Borovsky Date: Sat May 23 19:53:37 2026 +0300 media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak commit dabb047c62668f280998e29117c55e41aabac336 upstream. rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module") Cc: stable@vger.kernel.org Suggested-by: Hans Verkuil Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 12b88016c199ef5665462396095cc92811b63857 Author: Narasimharao Vadlamudi Date: Wed Jul 1 16:42:03 2026 +0530 media: rkvdec: Propagate platform_get_irq() errors commit c37aca64206fafe938119e801a3fd10a537a051f upstream. platform_get_irq() returns a positive IRQ number on success and a negative error code on failure. It no longer returns zero. The driver currently returns -ENXIO for all failures, which loses useful errors such as -EPROBE_DEFER. Return the error from platform_get_irq() directly. Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Cc: stable@vger.kernel.org Signed-off-by: Narasimharao Vadlamudi Reviewed-by: Detlev Casanova Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5b58d8c206f37525c8217171e1f3e91dd2fa55e5 Author: Myeonghun Pak Date: Wed May 13 16:11:03 2026 +0900 media: rc: sunxi-cir: Unregister rc device on probe failure commit 479aa6fa8c50f1052f1451326ef7d4d586d340c3 upstream. After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds. Fixes: b4e3e59fb59c ("[media] rc: add sunxi-ir driver") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Sean Young Signed-off-by: Greg Kroah-Hartman commit 8281acf5d70498edde19def67320b9f5d23f7d94 Author: Guoniu Zhou Date: Tue Jul 28 14:58:56 2026 +0800 media: nxp: imx8-isi: Use BIT_ULL() for 64-bit stream masks commit 77e60a2c5d824ad2d493f53dc17137ae065753fe upstream. Use BIT_ULL() instead of BIT() for u64 stream masks to avoid incorrect results on 32-bit architectures when stream IDs are 32 or greater. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Reviewed-by: Laurent Pinchart Reviewed-by: Frank Li Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20260728-isi-v5-1-1d22ab91602a@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9392375dd4c01544ca2779b158b3c3e0092dc74f Author: Guoniu Zhou Date: Mon Jul 20 11:34:07 2026 +0800 media: nxp: imx8-isi: Correct color map between V4L2 and ISI commit 4640ec1cb0121473867e7a6850c7449340dcd428 upstream. Fix the ISI input format for the color map V4L2_PIX_FMT_XBGR32 in memory-to-memory mode. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Tested-by: Laurent Pinchart Reviewed-by: Laurent Pinchart Reviewed-by: Frank Li Link: https://patch.msgid.link/20260720-isi-v2-5-45845bc5d4fa@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2f9b2768d5ceb6eae6966dad58d29ec0a494165a Author: Guoniu Zhou Date: Mon Jul 20 11:34:03 2026 +0800 media: nxp: imx8-isi: Fix stream ID validation bypass in crossbar routing commit 795bd2863591f2fee33fab8f10cf9c383c94342e upstream. The crossbar routing validation has a critical bug where it validates the wrong routing table, allowing userspace to bypass validation entirely. The __mxc_isi_crossbar_set_routing() function is called to validate and apply a new routing table from userspace. However, the validation loop iterates over state->routing (the currently active routing table) instead of the routing parameter (the new table being validated): for_each_active_route(&state->routing, route) { This means userspace can submit any invalid routing configuration and it will pass validation as long as the currently active routing is valid. This is a security issue as it allows userspace to configure routes that violate hardware constraints, potentially causing undefined hardware behavior. Fix by validating the routing table that will actually be applied. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Reviewed-by: Laurent Pinchart Reviewed-by: Frank Li Link: https://patch.msgid.link/20260720-isi-v2-1-45845bc5d4fa@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5026f927ef4150ba12da6f1098cf7952d77b14b6 Author: Johan Hovold Date: Mon Jul 6 08:59:27 2026 +0200 media: platform: mtk-mdp3: fix NULL deref on failed SCP lookup commit 90368323fb244da0504e3da37a182f8e89bcc3b9 upstream. Add the missing sanity check after looking up the SCP to avoid dereferencing a NULL-pointer in case its driver has not yet been bound. Fixes: 61890ccaefaf ("media: platform: mtk-mdp3: add MediaTek MDP3 driver") Cc: stable@vger.kernel.org # 6.1 Cc: Moudy Ho Signed-off-by: Johan Hovold Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 252850653569fdb1a259937e02325cf32c8f0970 Author: Guangshuo Li Date: Sun Jul 5 01:31:19 2026 +0800 media: platform: mtk-mdp3: Fix SCP device refcounting commit 55793e4665b7f15151e6f5ab51ca980e73abed5d upstream. mdp_probe() first tries to get the SCP handle with scp_get(). When that fails, it falls back to looking up the SCP platform device with __get_pdev_by_id() and then reads its driver data. The fallback lookup returns the platform device with a reference, just like scp_get() does. However, the fallback path currently drops that reference immediately after platform_get_drvdata(). The driver later still calls scp_put(mdp->scp) unconditionally from the probe error path and from mdp_video_device_release(), which drops the SCP device reference again. Keep the fallback reference until the existing scp_put() call, so that the fallback path follows the same ownership rules as the scp_get() path. Fixes: 8f6f3aa21517 ("media: platform: mtk-mdp3: fix device leaks at probe") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Johan Hovold Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 96dafbae77f50bfe2228bcfedcd8652c5e5f08e8 Author: Christian Hewitt Date: Wed Jun 24 06:58:08 2026 +0000 media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common commit 20aa934ace6917262ff579a73ec018d06a7bad1c upstream. When VIDIOC_TRY_FMT is called with an unsupported pixel format on the OUTPUT queue, vdec_try_fmt_common() falls back to V4L2_PIX_FMT_MPEG2. However, if a distro has locally patched MPEG2 support out (as it has been broken for some time) the platform format table does not contain MPEG2 so find_format() returns NULL and the subsequent dereference of fmt_out->max_width triggers a NULL pointer dereference. Fix this by falling back to the first format in the platform's format array instead of hardcoding V4L2_PIX_FMT_MPEG2. This is always valid since every platform defines at least one format. Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver") Cc: stable@vger.kernel.org Signed-off-by: Christian Hewitt Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 24aca883903880a7840f5ba4441ec32dc0d82063 Author: Bryan O'Donoghue Date: Tue Jun 2 14:59:21 2026 +0100 media: iris: Enumerate cap->bus_info to differentiate between encoder and decoder commit 94ef75095d5e76df848a2e5508d71a4532a6ce23 upstream. commit 66c744e28b69 ("media: venus: assign unique bus_info strings for encoder and decoder") introduced the naming convention plat:node-addr:video-codec{enc|dec}. Right now Iris does not replicate this naming convention. When we do v4l2-ctrl --list -devices we see: Iris Decoder (platform:aa00000.video-codec): /dev/video0 /dev/video1 Enumerate the bus_info field of the capabilities structure for namespace parity and appropriate differentiation: Iris Decoder (plat:aa00000.video-codec:dec): /dev/video0 Iris Encoder (plat:aa00000.video-codec:enc): /dev/video1 Fixes: 5ad964ad5656 ("media: iris: Initialize and deinitialize encoder instance structure") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Reviewed-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit 27b7997be552ee37b3e01beacfeb4131f1bebb5f Author: Cong Nguyen Date: Sat Aug 8 16:10:02 2026 +0700 media: intel/ipu6: fix async notifier cleanup leak on parse error commit abb1f808ceab5a3275f8a6b4e37cff17f9f781c1 upstream. isys_notifier_init() calls v4l2_async_nf_init() and then adds fwnode remote subdevs in a loop with v4l2_async_nf_add_fwnode_remote(). If an endpoint parse or add fails partway through the loop, it jumps to err_parse and returns without calling v4l2_async_nf_cleanup(), leaking every v4l2_async_connection already added to the notifier's waiting list. The register-failure path just below already cleans up correctly, and the caller only tears the notifier down (isys_notifier_cleanup()) once isys_notifier_init() has returned success. Clean up the notifier on the parse error path too. Fixes: f50c4ca0a820 ("media: intel/ipu6: add the main input system driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 1d59c5254c33aacd7cb0ec5f998a8b68542b8388 Author: Dave Stevenson Date: Wed Jul 15 12:43:14 2026 +0100 media: imx355: Avoid calling imx355_power_off twice in error path commit ee737bc3ccae7dc713ccaa83ffa46080c6031b3e upstream. If v4l2_async_register_subdev_sensor failed, then the sensor had already been powered down by pm_runtime_idle, but the error path then also explicitly called imx355_power_off as well. That left an imbalance in the regulator and clock calls. Call pm_runtime_idle only after v4l2_async_register_subdev_sensor succeeds to avoid this. Fixes: efa5fe19c0a9 ("media: imx355: Enable runtime PM before registering async sub-device") Cc: stable@vger.kernel.org Signed-off-by: Dave Stevenson Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit af81f35e4f429e769b784754e1aa4d7a922470ac Author: Biren Pandya Date: Wed Jul 8 18:27:23 2026 +0530 media: i2c: ov7740: fix use-after-destroy in remove commit 5d1b3dea5a44124bab6c14a2d71b977dabed54e7 upstream. The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order. Fixes: 39c5c4471b8d ("media: i2c: Add the ov7740 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Biren Pandya Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 90f9b421fc6d4f2edab7521efdb1e58571468d33 Author: Biren Pandya Date: Wed Jul 8 18:35:33 2026 +0530 media: i2c: ov02a10: fix endpoint parsing use-after-free commit 94971ba0592ca77ec99b292226a4b398763315b8 upstream. The ov02a10_check_hwcfg() function calls fwnode_handle_put(ep) immediately after allocating and parsing the endpoint. However, it subsequently calls fwnode_property_read_u32() using the same 'ep' handle, leading to a potential use-after-free. Additionally, reading the optional 'ovti,mipi-clock-voltage' property used to overwrite the 'ret' variable. If the property was missing, 'ret' would become negative, and this failure code would be incorrectly returned at the end of the function, causing probe to fail entirely. Fix the use-after-free by moving fwnode_property_read_u32() before the endpoint is parsed and freed. Avoid the error leak by not assigning the result of fwnode_property_read_u32() to 'ret'. Fixes: 91807efbe8ec ("media: i2c: add OV02A10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Biren Pandya Reviewed-by: Vladimir Zapolskiy Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 4f8fd40b39bf7d8299c92e0758eb682306a8c500 Author: Narasimharao Vadlamudi Date: Wed Aug 5 19:26:34 2026 +0530 media: i2c: imx415: Return test pattern write errors commit 8cd5735b88d76dda80b089031747b6f18ee0bca2 upstream. imx415_set_testpattern() accumulates failures from cci_write(), but drops the value and always returns success. Return the accumulated error so V4L2 reports failures to userspace. Fixes: d5df1c7f3f83 ("media: i2c: imx415: Convert to new CCI register access helpers") Cc: stable@vger.kernel.org Reviewed-by: Michael Riesch Signed-off-by: Narasimharao Vadlamudi Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 1aa66bb3ba440aabb3bfe65ba5f19bef86a0f823 Author: Narasimharao Vadlamudi Date: Wed Aug 5 19:26:35 2026 +0530 media: i2c: imx415: Release runtime PM reference on VBLANK error commit bea3001e0f32527a291444e527e84a7ea9b546d4 upstream. The VBLANK path returned immediately when programming VMAX failed after pm_runtime_get_if_in_use() had taken a runtime PM reference. Break out of the switch instead so the common pm_runtime_put() path is used. Fixes: 3bcae55ab96a ("media: i2c: imx415: Add read/write control of VBLANK") Cc: stable@vger.kernel.org Reviewed-by: Michael Riesch Signed-off-by: Narasimharao Vadlamudi Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 312c68e9ed8a4f765f7231f6fd51c8dd3deef2c2 Author: Martin Hecht Date: Fri May 22 13:41:12 2026 +0200 media: i2c: alvium: Fix: Correct name of register in alvium_set_ctrl_auto_exposure commit 58ca8a0bff9e78841a39863474b96e59ef60da19 upstream. Write value for auto-exposure into correct register REG_BCRM_EXPOSURE_AUTO_RW instead of wrong register REG_BCRM_WHITE_BALANCE_AUTO_RW. Fixes: 0a7af872915e ("media: i2c: Add support for alvium camera") Cc: stable@vger.kernel.org Signed-off-by: Martin Hecht Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 0745a59945d927652d892437f9647ed6e87c0677 Author: Shuangpeng Bai Date: Mon Jul 6 16:50:15 2026 -0400 media: go7007: defer the ALSA v4l2 put until card release commit 1bd456afeb8a515137e567967069fce6f8fcd23e upstream. go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime. Closes: https://lore.kernel.org/r/178144969601.60470.6005237146425573205@gmail.com Fixes: d5d3a7cc127d ("[media] go7007: fix unregister/disconnect handling") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0782807552b6aff41b4656c6c9076a3231d3e79d Author: Jiangong.Han Date: Tue Jun 30 22:54:34 2026 +0800 media: em28xx: fix use-after-free of dev_next->devlist on disconnect commit 826915b6b65e2d3251e7248ea54289a22d748c84 upstream. When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 ("USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed. Fixes: f410b4093fdd ("media: em28xx: split up em28xx_dvb_init to reduce stack size") Cc: stable@vger.kernel.org Reported-by: syzbot+99d6c66dbbc484f50e1c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=99d6c66dbbc484f50e1c Signed-off-by: Jiangong.Han Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f9322ac9f862961d7f377b87ec26c8565af7e073 Author: Diego Fernando Mancera Gomez Date: Thu Jul 23 12:22:42 2026 -0600 media: em28xx: defer audio-only extension registration commit 95f76f51937fdfb0fc1e14cae606b1ef574a56f3 upstream. The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next. Fixes: 4a089668ef22 ("media: em28xx-cards: rework the em28xx probing code") Cc: stable@vger.kernel.org Reported-by: syzbot+a11c46f37ee083a73deb@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/66ec3c83.050a0220.29194.002f.GAE@google.com/T/ Suggested-by: Fedor Pchelkin Signed-off-by: Diego Fernando Mancera Gomez Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit bf3f49273d5bf6acbdad18ff44c01ffcf7a7a146 Author: Fan Wu Date: Mon Jul 20 13:17:08 2026 +0000 media: cx23885: cancel NetUP CI work before teardown commit 4e143d662ca94888b494b2427fc9e34494eb933a upstream. netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool. Fixes: c184dcd28233 ("V4L/DVB (10798): Add CIMax(R) SP2 Common Interface code for NetUP Dual DVB-S2 CI card") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7087bef6510c7df5df0b19192633b8ecc0f33a6f Author: Bryam Vargas Date: Mon Jun 15 18:40:48 2026 -0500 media: cx231xx: reject geometry changes while the VBI queue is busy commit 627a121c15fe05a541f44d86016294b80bada75d upstream. vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: offset = lines_completed * (dev->width << 1) + ...; if (dma_q->current_field == 2) offset += dev->width * 2 * dma_q->lines_per_field; memcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer. Fixes: 7c617138b825 ("media: cx231xx: convert to the vb2 framework") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit cb1218da234ea15fa14d90e2d049d686874d7aa3 Author: Ruoyu Wang Date: Wed Jul 8 22:33:38 2026 +0800 media: cobalt: Avoid freeing ALSA private data twice commit 3a7d6b9c4cb5ac18cbd3f1c7f8c7b159c42ba0b1 upstream. snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 85756a069c55 ("[media] cobalt: add new driver") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f78cf36cabf911da348ea80e4e9f430d74f6905c Author: Dawei Feng Date: Wed Jun 24 16:59:20 2026 +0800 media: cedrus: fix memory leak in cedrus_init_ctrls() commit 9df2fbe563194da1967a5db083442186c1323efe upstream. In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed. Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng Acked-by: Jernej Skrabec Reviewed-by: Dan Carpenter Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5c62095acc2a952099688774513c4a637bcdb2b5 Author: Ruoyu Wang Date: Wed Jul 8 11:01:02 2026 +0800 media: cec: Serialize exclusive follower delivery commit 1924d0788caa6c66fd320dd4704fae99487fd2c7 upstream. cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release. Fixes: 9881fe0ca187 ("[media] cec: add HDMI CEC framework (adapter)") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 38c14532adb3463632ec275f7b0cbb4cc191488e Author: Yi Ding Date: Thu May 28 23:00:05 2026 -0700 media: cec: meson: ao-cec-g12a: name the CEC core regmap to avoid debugfs clash commit 172c5a7d81deb922ddedd1bc920751c7fed6c43c upstream. The driver registers two regmaps on the same platform device: an MMIO regmap for the AO CEC registers, and an indirect regmap (using reg_read()/reg_write() callbacks) for the CEC controller core registers. Neither regmap_config sets a .name, so both default their debugfs directory to the device name and collide: debugfs: 'ff800280.cec' already exists in 'regmap' Because of the clash the second regmap's debugfs directory fails to register, so its registers can no longer be inspected via debugfs. Give the indirect CEC core regmap a distinct name. The two debugfs directories then become ".cec" and ".cec-core". This only affects debugfs naming; register access is unchanged. Tested on an ODROID-N2 (Amlogic S922X): the warning is gone and both /sys/kernel/debug/regmap/ff800280.cec and ff800280.cec-core are present. Fixes: b7778c46683c ("media: platform: meson: Add Amlogic Meson G12A AO CEC Controller driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yi Ding Reviewed-by: Neil Armstrong Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 673611cc2ab9769929644ce879f7ea34932a3011 Author: Hans Verkuil Date: Thu Jun 18 13:03:19 2026 +0200 media: cec: extron-da-hd-4k-plus: add sanity check commit abac9820b26b5cfcb01eb79efe2abdd0ac7e07c3 upstream. Add check to prevent overflowing msg.msg[] in case the incoming data is malformed. Signed-off-by: Hans Verkuil Reviewed-by: Sean Young Fixes: 056f2821b631 ("media: cec: extron-da-hd-4k-plus: add the Extron DA HD 4K Plus CEC driver") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a3adb63b121937b97f7fdc51e96564c7c799538b Author: Biren Pandya Date: Sun Jun 21 10:04:37 2026 +0530 media: cec: disable delayed work before freeing an interrupted transmit commit 0fbd5c2327020858c45b2d1c65775d64cdeca523 upstream. cec_transmit_msg_fh() drops adap->lock to wait for a blocking transmit in wait_for_completion_killable(). If that wait is interrupted by a signal, cancel_delayed_work_sync() can run before the CEC kthread arms the reply timeout via schedule_delayed_work(&data->work) in cec_transmit_done_ts(). The work is then armed after the cancel, and the data is freed with its delayed_work still pending: ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout Use disable_delayed_work_sync(): it cancels the work and disables it, so the later schedule_delayed_work() becomes a no-op and the work cannot be re-armed. The data is freed right after, so it need not be re-enabled. Fixes: 490d84f6d73c ("media: cec: forgot to cancel delayed work") Reported-by: syzbot+051024d603432b4ab395@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=051024d603432b4ab395 Suggested-by: Hillf Danton Cc: stable@vger.kernel.org Signed-off-by: Biren Pandya Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 695063fc57574dd117b1bc750ca189cf03a2caad Author: Jonas Karlman Date: Fri May 29 09:59:26 2026 +0000 media: cec: core: Fix kmemleak due to missed rc_free_device() call commit a24ba0653f7154e671dc8d2bf64682ab2d042792 upstream. The commit dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") removed the implicit call to rc_free_device() from rc_unregister_device(). However, the commit missed to remove the NULL assignment of adap->rc that is now causing rc_free_device() to never be called on an allocated rc device. kmemleak reports following after e.g. dw-hdmi unbind: unreferenced object 0xffff00010ac10000 (size 4096): comm "kworker/u16:1", pid 39, jiffies 4294897739 hex dump (first 32 bytes): 20 23 4b 0a 01 00 ff ff 08 00 c1 0a 01 00 ff ff #K............. 08 00 c1 0a 01 00 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc e11baccc): kmemleak_alloc+0x38/0x44 __kmalloc_cache_noprof+0x4a8/0x5e0 rc_allocate_device+0x48/0x2a0 cec_allocate_adapter+0x3ac/0x800 dw_hdmi_cec_probe+0x264/0x634 platform_probe+0xc0/0x188 really_probe+0x4a4/0x8e0 __driver_probe_device+0x2f8/0x440 driver_probe_device+0x60/0x160 __device_attach_driver+0x1a0/0x2a0 bus_for_each_drv+0x100/0x1a0 __device_attach+0x174/0x350 device_initial_probe+0x90/0xb0 bus_probe_device+0x4c/0x120 device_add+0xdec/0x116c platform_device_add+0x354/0x598 Remove the assignment of adap->rc to NULL to let cec_delete_adapter() free the allocated rc device after last user of the cec device exits to fix the kmemleak. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Cc: stable@vger.kernel.org Signed-off-by: Jonas Karlman Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit cb7a4cf63fa20a83172b1126cd600148f759eccd Author: Ming Qian Date: Thu Jun 11 17:17:00 2026 +0900 media: amphion: Remove obsolete frame_count check in venc_start_session commit 2be6ee86385badab95b1bace984735bde6e0fec0 upstream. The dev_err() log warning about no input when starting was originally meaningful when min_queued_buffers was set, as it indicated an abnormal condition. However, since commit 5633ec763a2a ("media: amphion: Drop min_queued_buffers assignment") removed the min_queued_buffers assignment, having frame_count == 0 at start is a normal condition. Remove this misleading log that no longer serves any purpose. Fixes: 5633ec763a2a ("media: amphion: Drop min_queued_buffers assignment") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Frank Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 297fee023f46d771a844520675692ea089d80d9d Author: Valery Borovsky Date: Sat May 23 19:53:49 2026 +0300 media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref commit 2f378dc45e685fc825d2dd08e7864666d6fcc009 upstream. airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 634fe5033951 ("[media] airspy: AirSpy SDR driver") Cc: stable@vger.kernel.org Suggested-by: Hans Verkuil Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 347e9d2246b898be53a93a10e997754d543f77b7 Author: Danilo Krummrich Date: Sun Jun 28 16:53:21 2026 +0200 rust: drm: ioctl: fix unbounded lifetimes in ioctl handler arguments commit 68b151bc6145dea3db5598ebaf4b776cd205e395 upstream. References to dev, data, and file in the declare_drm_ioctls! macro are created via unsafe pointer dereferences, producing unbounded lifetimes. If an ioctl handler explicitly annotates its parameters with 'static, the compiler accepts this, allowing the handler to stash references that outlive the ioctl call. Fix this by adding a higher-ranked function pointer coercion that enforces the handler accepts universally quantified lifetimes: let _: for<'a> fn(&'a _, &'a mut _, &'a _) -> _ = $func; Since the handler must be coercible to a function pointer accepting any lifetime 'a, it can no longer demand 'static on any parameter. Cc: stable@vger.kernel.org Fixes: 9a69570682b1 ("rust: drm: ioctl: Add DRM ioctl abstraction") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260620011346.A47D01F000E9@smtp.kernel.org/ Suggested-by: Gary Guo Reviewed-by: Alexandre Courbot Reviewed-by: Lyude Paul Tested-by: Deborah Brouwer Link: https://patch.msgid.link/20260628145406.2107056-2-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 76395109a051b53860faaec96522ef08ae9e8e27 Author: Jérémy Jean Date: Fri Sep 4 21:44:43 2026 +0800 LoongArch: Avoid preempt count underflow without probe commit 72ce4b24676e8b3b75376c4c559dd81c1ac52d5a upstream. LoongArch uses break 11 for the breakpoint placed after an instruction that Kprobes executes out of line. Since userspace can issue the same break instruction, do_bp() can reach kprobe_singlestep_handler() when there is no current probe. The handler actually returns false in this case, but it first calls preempt_enable_no_resched(). The corresponding preempt_disable() is done by kprobe_breakpoint_handler() on a real Kprobe hit, so it has not run here. As a result, an ordinary userspace breakpoint (code 11) underflows the current task's preempt count. This also makes in_interrupt() return true until the task schedules. One visible consequence is the socket cgroup attribution: cgroup_sk_alloc() treats the allocation as interrupt context and assigns the socket to the root cgroup. A socket opened from the SIGTRAP handler can then avoid a BPF_CGROUP_INET_SOCK_CREATE policy attached to the task's own cgroup. Return as soon as kprobe_running() reports no active probe. The same check has appeared in [PATCH v10 2/4] of the original LoongArch Kprobes series, but was dropped before the feature reached mainline. Cc: stable@vger.kernel.org Fixes: 6d4cc40fb5f5 ("LoongArch: Add kprobes support") Link: https://lore.kernel.org/loongarch/1670575981-14389-3-git-send-email-yangtiezhu@loongson.cn/ Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 266ffc92e68593759adfe3d58f188773d32782c3 Author: Wentao Guan Date: Fri Sep 4 21:44:43 2026 +0800 LoongArch: Do not save/restore percpu base register in rethook trampoline commit c3f2feace5e4f4b01b68b9f947b19adb4155c32e upstream. The rethook trampoline saves $r21 ($u0), the percpu base, into its frame at entry and restores it at exit. Inbetween rethook_trampoline_handler() may schedule via preempt_enable_notrace(). If the task migrates to another CPU, the frame's $r21 holds the old CPU's percpu base, and restoring it poisons $r21 on the new CPU. Until the next user->kernel transition heals $r21, all this_cpu_*() accesses (runqueues, RCU per-CPU data, timer tick programming, FPU ownership) hit the wrong CPU's percpu area. Under kretprobe-heavy preemptible load this can corrupt scheduler and timer state: scheduling-while-atomic splats, wrong-CPU RCU warnings, WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and CPUs parking in the idle loop with the constant timer never re-armed (hard lockup). Reproduces on a Loongson-3A6000 with kretprobes on VFS paths plus heavy file churn (OS install / unsquashfs). By convention $r21 always holds the current CPU's percpu base in kernel mode: SAVE_SOME() at exception entry reloads it only when coming from user mode, and RESTORE_SOME() restores it only when returning to user mode; the context-switch path never writes it. Therefore the live $r21 at trampoline exit is already correct, and nothing inbetween can change it legitimately (kernel C code cannot write a global register variable). The same flaw existed even in the pre-rethook kretprobe trampoline since v6.3; it was carried over when rethook replaced it. Drop both the save and the restore here. Drop the restore is enough to solve the issue, and drop the save is to keep the code tidy and no need to clear it. Cc: stable@vger.kernel.org # v6.3+ Fixes: 3f5536860086d ("LoongArch: Add kretprobes support") Assisted-by: Kimi:Kimi-K3 # debug and root-cause analysis Signed-off-by: Wentao Guan Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit d692b825dc2461f0d82f689ace01b9e72460f54f Author: Nathan Chancellor Date: Fri Sep 4 21:44:23 2026 +0800 LoongArch: Do not select HAVE_RUST when KASAN is enabled commit 63b6a48c951d63bf39d44603ada48a987ccf66eb upstream. After commit 2625480a1bf7 ("hardening: Default randstruct off with rust for better allmodconfig support"), which allows Rust to be enabled for allmodconfig, ARCH=loongarch allmodconfig starts failing with: error: kernel-address sanitizer is not supported for this target error: aborting due to 1 previous error make[4]: *** [rust/Makefile:741: rust/core.o] Error 1 For the same reason as the commit 84a0f7caafc679f7 ("ARM: Do not select HAVE_RUST when KASAN is enabled"), do not select HAVE_RUST when KASAN is enabled until the loongarch64-unknown-none-softfloat target in rustc supports KASAN. Cc: stable@vger.kernel.org Fixes: 90868ff9cade ("LoongArch: Enable initial Rust support") Acked-by: Miguel Ojeda Signed-off-by: Nathan Chancellor Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit d3fd094c13c6d0b74f246461ca4cf427d539c8e8 Author: Bibo Mao Date: Mon Aug 17 22:07:05 2026 +0800 LoongArch: Fix acpi_package_ids[] array overflow commit 2a2367d46d7a4ee4122b7a86e57125542dbbe963 upstream. With LoongArch virt machine, a typical setting is one core per socket, there will max 256 sockets (packages) on one VM. With PPTT acpi table, array acpi_package_ids[] will be overflowed. Here change the array size of acpi_package_ids[] with the max value of MAX_PACKAGES and KVM_MAX_VCPUS. Cc: stable@vger.kernel.org # 6.7+ Fixes: 4e8f58620f67 ("LoongArch: Retrieve CPU package ID from PPTT when available") Reviewed-by: Tao Cui Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 882b8912b7e92341fdb115ba0e2e5142a28684ff Author: Tiezhu Yang Date: Mon Aug 17 22:07:23 2026 +0800 LoongArch: BPF: Refactor jump offset calculation in tail call commit 37d545d12f21c4d50612ecaebd7ae1e5bf91b2d8 upstream. The old macro-based jmp_offset calculation derives the jump distance from a stale prior-pass code stride, which can lead to wrong branch offsets and soft lockups under extra JIT passes. Fix this by calculating the offset directly on the absolute target: "ctx->offset[insn + 1] - ctx->idx". To avoid a false 16-bit range check abort during size estimation, add a "ctx->image == NULL" guard to inject a safe dummy offset. Cc: stable@vger.kernel.org Fixes: cd39d9e6b7e4 ("LoongArch: BPF: Fix jump offset calculation in tailcall") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 462e6abc8293f9f75b9e5d40d6105cb8edc0ebc0 Author: Tiezhu Yang Date: Mon Aug 17 22:07:23 2026 +0800 LoongArch: BPF: Optimize redundant TCC loads in epilogue commit fd3cb1bfeb9d98618bd709bfee9c1133e9f189e6 upstream. The legacy epilogue implementation pops the tail call counter (TCC) context via a redundant double-load pattern. It first decrements the load_offset by 2 slots to fetch 'tcc_ptr', and then immediately bumps it back up by 1 slot to load the original 'tcc' value into REG_TCC, unnecessarily overwriting the register. Optimize this sequence by adjusting the load_offset by only 1 slot. This aligns the offset directly with the higher stack slot containing the entry TCC counter (or caller state), allowing us to restore the REG_TCC register safely with a single load. This removes one redundant instruction from the epilogue hot path, improves code readability, and ensures the correct TCC register context is handed back cleanly upon normal return. Cc: stable@vger.kernel.org Fixes: c0fcc955ff82 ("LoongArch: BPF: Fix the tailcall hierarchy") Fixes: ef54c517a937 ("LoongArch: BPF: Implement PROBE_MEM32 pseudo instructions") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit ab275a23b4d9f04ca6c2f5f6a3246194e045a761 Author: Han Gao Date: Mon Aug 17 22:07:05 2026 +0800 LoongArch: Add DIRECT_MAP_PHYSMEM_END definition commit 2677f97a67fdbc62a82ce1faa67791f54451d36f upstream. get_free_mem_region() and mhp_get_pluggable_range() bound their search to DIRECT_MAP_PHYSMEM_END. LoongArch does not define it, so the fallback in include/linux/mm.h applies: under CONFIG_SPARSEMEM_VMEMMAP it is (1ULL << MAX_PHYSMEM_BITS) - 1, a compile-time constant that does not adapt to the CPU's physical address space bits (cpu_pabits, probed from CPUCFG1). The vmemmap window only covers physical space below 2^(cpu_pabits+1) (i.e. VMEMMAP_SIZE), so on CPUs with fewer physical address bits than MAX_PHYSMEM_BITS the fallback allows get_free_mem_region() to return a ZONE_DEVICE region outside the vmemmap window; vmemmap_populate() then wraps the memmap range around and maps it into low memory, silently corrupting the page tables. The same search also picked the top-of- address-space region that crashed memmap_init_zone_device() with amdkfd on Loongson-3C6000 in 6.16 [1]; the commit 2969b42c8f99 ("LoongArch/mm: align vmemmap to maximal folio size") keeps that region in bounds on current Loongson-3C6000 configs, but CPUs with smaller cpu_pabits (e.g. the Loongson-2K series) are still affected. Define DIRECT_MAP_PHYSMEM_END as the vmemmap-covered physical range, (1ULL << (cpu_pabits + 1)) - 1, capped at (1ULL << MAX_PHYSMEM_BITS) - 1 under CONFIG_SPARSEMEM, similar to the commit f3336b48cf9d ("riscv: mm: Define DIRECT_MAP_PHYSMEM_END"). [1] https://lore.kernel.org/amd-gfx/20250814032153.227285-1-jeffbai@aosc.io/ Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Han Gao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 4e4dbc341b1581dc512b85d98b768373b0398366 Author: Zeng Chi Date: Fri Sep 4 21:45:13 2026 +0800 LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY commit 27a9bfee3bbcb3cabb77797354f07e0e44e49831 upstream. kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE, only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every other change. But the generic code allocates a zeroed memslot for every change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update, e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active memslot has arch.flags == 0. With both flags clear, fault_supports_huge_mapping() falls through to the alignment check on the HVA range alone, which no longer verifies that the GPA and HVA have the same offset within a PMD. A memslot that was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can then be mapped with PMD entries on read faults, and since kvm_map_page() aligns the gfn and the pfn independently, the guest ends up accessing the wrong host pages, exactly the "d -> f, e -> g" case described in the comment above the check. Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY, as the GPA, HVA and size are guaranteed to be unchanged for that case. Cc: stable@vger.kernel.org Fixes: 7ab6fb505b2a ("LoongArch: KVM: Optimization for memslot hugepage checking") Tested-by: Tao Cui Reviewed-by: Tao Cui Reviewed-by: Bibo Mao Signed-off-by: Zeng Chi Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 6b78786ee7260d9818cf1d7a245b7a655ef83076 Author: Chaithanya Lagisetty Date: Fri Sep 4 21:44:53 2026 +0800 LoongArch: KVM: Free init resources if kvm_init() fails commit f7a1064cce3b100b54780c68529176232d8eb01e upstream. kvm_loongarch_init() calls kvm_loongarch_env_init() to allocate the per-CPU kvm_context (vmcs) and kvm_loongarch_ops and to register the perf callbacks, and then calls kvm_init(). If kvm_init() fails its result is returned directly, but since module_init() does not run the module_exit() stuff on failure, so kvm_loongarch_env_exit() is never called and those resources are leaked. So call kvm_loongarch_env_exit() when kvm_init() fails, matching the teardown-on-failure pattern used by riscv_kvm_init(). Cc: stable@vger.kernel.org Fixes: 2bd6ac687261 ("LoongArch: KVM: Implement kvm module related interface") Reviewed-by: Bibo Mao Signed-off-by: Chaithanya Lagisetty Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 07c3037e45c9414bb97d3f6b50a51be7b69da105 Author: Tao Cui Date: Fri Sep 4 21:45:13 2026 +0800 LoongArch: KVM: Fix TOCTOU race on pv_features commit 9296375902579f9b0e456bbb76e5cf179e5a4e0b upstream. In kvm_loongarch_cpucfg_set_attr() the check-then-set on kvm->arch.pv_features is lockless, so two vCPUs can race past the validation and set different values. Add a spinlock to protect it. Cc: stable@vger.kernel.org Reviewed-by: Bibo Mao Signed-off-by: Tao Cui Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit b7fab314ade26ccb458a1b13e66951aa26dfc7fc Author: Zeng Chi Date: Mon Aug 10 12:21:50 2026 +0800 LoongArch: KVM: Fix PC double advance in kernel MMIO read fast path commit fd4021529faa931818186b6e83bd46f5de7517eb upstream. In the in-kernel MMIO read fast path of kvm_emu_mmio_read(), kvm_complete_mmio_read() already advances the guest PC via update_pc(). The explicit update_pc() call right after it advances the PC a second time, so PC moves forward by 8 bytes instead of 4, and the instruction following the MMIO read is silently skipped. The user space MMIO read completion path in kvm_arch_vcpu_ioctl_run() calls kvm_complete_mmio_read() only once, and the MMIO write fast path advances the PC exactly once as well. Here remove the redundant update_pc() so the kernel MMIO read fast path advances the PC by a single instruction. Cc: stable@vger.kernel.org Fixes: 80edf90831a2 ("LoongArch: KVM: Add sign extension with kernel MMIO read emulation") Reviewed-by: Bibo Mao Reviewed-by: Tao Cui Signed-off-by: Zeng Chi Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 566b1f08d983615f731cc693f2ad59db302c6b57 Author: Marc Zyngier Date: Mon Aug 10 18:06:16 2026 +0100 KVM: arm64: Correctly cap TLBI Range to the architural limit commit 69a598288195947a1662b53de702eb6976af96b7 upstream. TLB Invalidation by Range has a fairly powerful way of encoding pretty large ranges in a small number of bits. This range can be based on an arbitrary VA, which means it is pretty easy for a guest to generate an overflow should the hypervisor be naive enough to add the range to the base... Make sure the range is capped to the limit dictated by the address bit that determines the VA range. For an IPA invalidation, this is further corrected down the line to ignore the upper range. Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Reported-by: Wei-Lin Chang Link: https://lore.kernel.org/r/yifz3wn5gk5sr6mapi32trgk5m5kp33bquctsjmkifebnsnndt@fix6u4rthx4g Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Wei-Lin Chang Link: https://patch.msgid.link/20260810170616.746100-1-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 3d4c26b16a04a084fe0bde08ccdd8086570f8bbe Author: Fuad Tabba Date: Fri Aug 7 11:40:59 2026 +0100 KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save commit c6c156d931c33b92362383cf76f6d6e1291dcbfe upstream. MAPC with V=0 drops ite->collection but leaves the ITE on the device's ITT list, and vgic_its_save_ite() dereferences it unconditionally. A guest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the host when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it. That sequence is UNPREDICTABLE per the architecture, but KVM already handles the resulting state in the translate, MOVI and DISCARD paths. Save a zeroed entry, which vgic_its_restore_ite() reads back as invalid. Skipping the ITE instead would leave the ITT slot holding whatever is in guest memory, and restore rejects an entry naming a collection the restored collection table does not have. Fixes: eff484e0298da ("KVM: arm64: vgic-its: ITT save and restore") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260807104102.2410744-2-fuad.tabba@linux.dev Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 2f1a571af300ea019db33c57e2efdef113950f89 Author: Fuad Tabba Date: Sun Aug 2 16:08:45 2026 +0100 KVM: arm64: vgic: Reset in_kernel on private IRQ allocation failure commit 43347154e7ab642474c886bc54ad090166c0d9c9 upstream. kvm_vgic_create() sets vgic.in_kernel before allocating the per-vCPU private IRQs, but the allocation-failure path resets only vgic_model and leaves in_kernel set. As irqchip_in_kernel() is !!in_kernel, the VM is left with an in-kernel irqchip but no model, and the -EEXIST guard at the top of kvm_vgic_create() rejects every retry, so userspace cannot recover from a transient -ENOMEM. Reset in_kernel alongside vgic_model on the failure path. Fixes: 9435c1e1431003 ("KVM: arm64: gic: Set vgic_model before initing private IRQs") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Acked-by: Marc Zyngier Link: https://patch.msgid.link/20260802150845.3485757-1-fuad.tabba@linux.dev Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit de9b4e8f37ce6b532e1c1ec41598c988f9d408db Author: Kajetan Puchalski Date: Mon Aug 10 11:29:24 2026 +0100 KVM: arm64: vgic: Fix detection of MI on no pending LR commit a342faadc5acbd5d9fd894fd4499d4fd614dfcf6 upstream. As per the ARM GICv3 spec, the maintenance interrupt identified by ICH_MISR_EL2.NP is asserted when it is enabled and no List register is in pending state. This is further described in the document as "no List registers with the State field set to 0b01 (pending)". By checking only the pending bit of the LR (bit 62), KVM currently asserts the MI when there are no LRs in "pending" or "pending and active" states. Fix the detection logic to consider only the "pending" state. Cc: stable@vger.kernel.org Fixes: 96c2f03311de ("KVM: arm64: nv: Plumb handling of GICv3 EL2 accesses") Signed-off-by: Kajetan Puchalski Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260810102923.2426475-2-kajetan.puchalski@arm.com Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 7631f95297560157d3a9283cb999e3be00103348 Author: Qihang Date: Fri Aug 7 10:55:34 2026 +0800 KVM: arm64: vgic-v3: take an LPI reference in vgic_v3_save_pending_tables commit f5b8f203bfc07a5a257dff859e66d2c500f9f509 upstream. vgic_v3_save_pending_tables() iterates dist->lpi_xa using xa_for_each() and dereferences the returned struct vgic_irq in the loop body without holding a reference on the LPI. The xarray iterator only provides temporary RCU coverage while looking up the current entry. That is not sufficient for this loop body, which reads fields from struct vgic_irq and performs guest memory accesses before the iteration completes. A concurrent path can trigger this race: the irqfd cached injection path (vgic_its_inject_cached_translation) obtains a transient LPI reference via vgic_its_check_cache() without holding kvm->lock, vcpu->mutex, config_lock, or its_lock. If guest ITS DISCARD then drops the cache and ITE references under its_lock, the transient inject reference may become the final one. When vgic_put_irq() drops it, the LPI is erased from lpi_xa and freed via kfree_rcu(). Meanwhile, vgic_v3_save_pending_tables() may still hold a stale pointer obtained from the xarray iterator and dereference it after the RCU grace period completes. Fix this by re-fetching each iterated LPI via vgic_get_irq(), which takes a stable reference, and dropping it with vgic_put_irq() on all paths. This matches the pattern already used by other lpi_xa iterators in the vgic ITS code. Cc: stable@vger.kernel.org Signed-off-by: Qihang Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260807025534.34125-1-q.h.hack.winter@gmail.com Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 72bce82c4171bf330919ff1b64dc0a36c254ec7d Author: Marc Zyngier Date: Thu Aug 6 10:10:24 2026 +0100 KVM: arm64: Sign-extend VA for range-based TLBI invalidation commit 2393470085649f0b973ecceb26fe8fc71edde0c1 upstream. When the decode_range_tlbi() helper was moved to be used for S1 TLBIs, the required sign extension was omitted. Add it. As a result, special care must be taken to not overflow PA bits when this is used for S2 invalidation. Fixes: 85bba00425ae0 ("KVM: arm64: nv: Move TLBI range decoding to a helper") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/r/20260801130337.EB2BA1F00AC4@smtp.kernel.org Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-7-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit d8580e7aa189b0c6c5bb4d94b8352728a7c35bbd Author: Marc Zyngier Date: Thu Aug 6 10:10:25 2026 +0100 KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry commit 2b7324f3a0c1072b9d578b8d42f199506753f26e upstream. A VNCR TLB invalidation can occur on one vcpu while another vcpu is faulting in this same page. Without correctly handling this, we can end up with the following scenario: - vcpu A walks the PTs to translate VNCR - before vcpu A is able to grab the MMU lock to insert the TLB, vcpu B updates the S1 PTs with an invalid entry, and issues a TLBI S1E2 for this VA - vcpu A inserts the TLB for something that is now invalid This isn't a new problem, and we manage S2 by having the MMU notifier to bump up mmu_invalidate_seq on invalidation so that the fault can be replayed. We can perform something similar here, and extend invalidate_vncr_va() to update the same counter, clearly indicating that the context has changed under our feet. This is safe as the invalidation always happen while holding the MMU lock for write, and that we sample the sequence number before walking S1. Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/r/20260801130454.5D9F11F00AC4@smtp.kernel.org Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-8-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit ce447651a52ec077694172af10c4fffb11f56c43 Author: Marc Zyngier Date: Thu Aug 6 10:10:22 2026 +0100 KVM: arm64: Correctly handle end of VA space TLBI invalidation commit 34af2c3e31f91a739dc175459fdbd99ed952b457 upstream. Our TLB invalidation by VA code is based on comparing two ranges, one defined by the TLB, and one defined by the TLBI instruction. Each range is defined by a start and a size. However, the way the comparison is done doesn't account for address rollover, as it compares an address with (base + size). This works nicely until this expression represent the last page/block in the TTBR1 VA space, as the result is a big fat 0. And a failed TLB invalidation. Rewrite the comparison in a way that is immune to the address rollover (making the end address inclusive instead of exclusive), and move this into a common helper that is used by both VA and IPA invalidations, as suggested by Hyunwoo Kim (although the IPA version didn't suffer from this particular problem, obviously). Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Reviewed-by: Yuan Yao Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-5-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit be54a70067c7dbe1381157e8a238fa4b16ea9c05 Author: Marc Zyngier Date: Thu Aug 6 10:10:20 2026 +0100 KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation commit 8053393680d4fa3eb962667d2be95dd39f0940e5 upstream. Computing the effects of a TLB invalidation involves looking at the size of the mapping cached by the TLB. For S1 mappings such as VNCR, this is deducted from the combination of the base granule size and the mapping level. However, this implies that the S1 MMU is *on*. When the MMU is off, we indicate this with the level being set to a "creative" value of -127 (S1_MMU_DISABLED). This ends-up being misinterpreted by pgshift_level_to_ttl() as it doesn't handle negative levels at all (the level is immediately cast to a u8 and only the bottom two bits considered), leading to an invalidation size of 0. Not helpful. Tidy-up pgshift_level_to_ttl() to handle these negative levels, and ttl_to_size() to always return SZ_1G when no valid TTL is present. This allows the removal of open-coded checks for similar situations. Note that the check for a negative value not explicitely checking for S1_MMU_DISABLED is deliberate, so that actual negative levels introduced with LVA2 and D128 can take the same path if we ever support them. Fixes: 7270cc9157f47 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers") Reported-by: Hyunwoo Kim Link: https://lore.kernel.org/r/ameGoxbn2wzBq2kL@v4bel Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-3-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 6408605cbd509e6625e4c2145b1467bdd2807e95 Author: Marc Zyngier Date: Thu Aug 6 10:10:21 2026 +0100 KVM: arm64: Consider SCTLR_EL2.M when mapping the L1 VNCR page commit 8c774604b6ecaca495fa3d27c21593269627f48f upstream. We record a VNCR TLB even when SCTLR_EL2.M is 0 in order to make our life easier. But this is not something that the architecture anticipate. As a consequence, a hypervisor is free to set VNCR_EL2 to some PA when SCTLR_EL2.M==0, use it to run a guest which indirectly accesses the VNCR page, then eventually set SCTLR_EL2.M==1 with the same VA. Yes, this is odd, but apparently legal. A common trick in HW is to invalidate the TLBs on SCTLR_ELx.M being flipped. But doing this is a not a good idea for us (we'd need to trap SCTLR accesses), and wouldn't scale as we nest deeper. Instead, use the fact that the S1 MMU being off at the point of translation is cached in our TLB, and if it doesn't match the current MMU state, leave the VNCR unmapped. Fixes: 2a359e072596f ("KVM: arm64: nv: Handle mapping of VNCR_EL2 at EL2") Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-4-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 150c43473dcf02c1b3e1942afaecc538a9e1198c Author: Christian Borntraeger Date: Tue Aug 11 17:37:38 2026 +0200 KVM: s390: Restore sigset on error path commit c44d36d8e6501c4934412d9014e5e02da9efdb8f upstream. kvm_sigset_activate() installs vcpu->sigset via sigprocmask() and stashes the caller's mask in current->real_blocked; only kvm_sigset_deactivate() restores it. For KVM_RUN on a STOPPED vcpu the error path will not restore the userspace mask. Re-arrange the error handling to also restore the signal mask. Fixes: 6352e4d2dd9a3 ("KVM: s390: implement KVM_(S|G)ET_MP_STATE for user space state control") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260811153738.206885-5-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 5ed801685a8a34dfc2745a22157318eb10bdc5d9 Author: Christian Borntraeger Date: Tue Aug 11 17:37:37 2026 +0200 KVM: s390: pv: Fix rc/rrc offset for PVM_DUMP commit 1e3c8e7b3465fb8a49d3623d2d0f449c0b5b48f3 upstream. The rc/rrc value is copied to the cmd location of the cmd in the kvm_pv_cmd structure. Fix the offset. Fixes: 8aba09588d2a ("KVM: s390: Add CPU dump functionality") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260811153738.206885-4-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 6ee52d3af2a1bf70349cf3f860933c8d221e229a Author: Christian Borntraeger Date: Thu Aug 6 16:58:35 2026 +0200 KVM: s390: Fix memory corruption by not reinjecting CK machine checks commit 546dde823a36d7283dcf46127c2f3d093443860f upstream. Channel-subsystem damage machine checks are for the host channel subsystem. The guest channel subsystem is emulated in the userspace VMM. There is no point in forwarding such machine checks into the guest. This also simplifies the machine check reinjection and avoids kfree of a stack variable as reported by sashiko. There might be still machine checks that have the ck bit set with another bit (like instruction damage), mask out the CK bit in s390_backup_mcck_info(), like the CP and ED bits already are. Fixes: 4d62fcc0b692 ("KVM: s390: Inject machine check into the guest") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Acked-by: Heiko Carstens Acked-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260806145835.31818-1-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 3904a3296e40d95918d259f3fe43bf6186aee70e Author: Christian Borntraeger Date: Wed Aug 5 13:04:50 2026 +0200 KVM: s390: Zero initialize irq in reinject_machine_check commit b239410c7653ff6781d4cf1d63cfc52a1bb71788 upstream. kvm_s390_reinject_machine_check() fills cr14, mcic, ext_damage_code and failing_storage_address of the on-stack struct kvm_s390_irq, but struct kvm_s390_mchk_info also has a pad word and a 16 byte fixed_logout array. struct mcck_volatile_info carries no logout data, so there is nothing to copy there and both stay whatever was on the stack. __inject_mchk() then memcpy()s fixed_logout into the vcpu local interrupt state unconditionally. This will reach the guest during deliver and userspace during migration. Reflecting zeroes is the correct behaviour here, as KVM has no logout data for a reinjected machine check. This needs a host machine check while the cpu is in SIE so not trivial to trigger. Fixes: 4d62fcc0b692 ("KVM: s390: Inject machine check into the guest") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-4-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit cc710ee45395efb4937e042960f791d33924e5f6 Author: Christian Borntraeger Date: Wed Aug 5 13:04:53 2026 +0200 KVM: s390: Take srcu when importing watchpoint data commit a4e482def8533ebace517d9f67f1465841b1f982 upstream. __import_wp_info() backs up the original guest memory contents of a watchpoint with read_guest_abs(), which is kvm_read_guest() and therefore resolves the memslot via __kvm_memslots(). That requires kvm->srcu (or kvm->slots_lock) to be held, otherwise a concurrent memslot update can free the memslots array under us once its SRCU grace period has elapsed. As this is not fast path, following lock ordering (mutex first, then srcu) take the big hammer and hold the srcu for the full import. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-7-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit b5acacfdb8966abff91836c1c5bd7da59d8a526e Author: Christian Borntraeger Date: Wed Aug 5 13:04:54 2026 +0200 KVM: s390: Free guest debug data on vcpu destroy commit e7f698b09d4a7c36b299acf680fc50fe868e2bcd upstream. kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-8-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit f55e4d415d95342d5753e528e05a1e8623992c3f Author: Christian Borntraeger Date: Wed Aug 5 13:04:52 2026 +0200 KVM: s390: Fix old_data leak in guest debug error path commit aa9c8e8baf1e765fa65b93212522c636f25d846f upstream. __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-6-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 44bf3792c10f4bb3de507391f1837e020d92eaa2 Author: Christian Borntraeger Date: Wed Aug 5 13:04:51 2026 +0200 KVM: s390: Fix memory leak in guest debug handling commit 121ea1de927c8b9bfdf53c31cad27b86d5de0293 upstream. bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-5-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit beb9c55af609c4c7308259d7191688c75a4e3d4a Author: Christian Borntraeger Date: Wed Aug 5 13:04:55 2026 +0200 KVM: s390: Fix length check __import_wp_info() commit 4c07680a467e2f7697245bcd11691bffb2a6f0ed upstream. struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: wp_info->len = bp_data->len; [...] if (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) return -EINVAL; wp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-9-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 39f7abd5927bf8a53247a43b804401b464bf5785 Author: Sean Christopherson Date: Thu Jul 9 13:49:36 2026 -0700 KVM: x86: Ensure runtime reads of disabled_quirks are resolved once commit ed15cb21999217e549414c128b4a0485debf6278 upstream. Wrap the sole reader of disabled_quirks with READ_ONCE(), and wrap the post-VM-creation write to disabled_quirks with WRITE_ONCE(), to ensure checking the status of a quirk doesn't re-read disabled_quirks *if* the caller needs such a guarantee. This will allow splitting the "fast" MMU zap into front and back halves, without potentially skipping the back half if SLOT_ZAP_ALL were concurrently disabled (which would be "fine" in the current code base, but far from ideal). Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-7-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 929fd2d87851af385df914f4f506ab3a6825b8a2 Author: Sean Christopherson Date: Thu Jul 9 13:49:35 2026 -0700 KVM: x86: Serialize writes to disabled_quirks using kvm->lock commit ba76b23ed36ab230fc2577aba24f65851114902f upstream. Protect writes to disabled_quirks with kvm->lock to ensure KVM doesn't clobber state in the unlikely scenario that userspace disables disparate quirks from multiple tasks. More importantly, this will allow wrapping accesses with {READ,WRITE}_ONCE without "needing" to also guard the writer with a useless and confusing READ_ONCE (since the RMW wouldn't be atomic anyways). Ideally, KVM would disallow disabling quirks once quirks are "live", but that would be a potentially breaking userspace ABI change, and while all existing quirks are fully live only after vCPUs have been created, several MMU-related quirks, IGNORE_GUEST_PAT and SLOT_ZAP_ALL, are partially live at all times. Because populating MMUs requires a vCPU, the guest-visible behavior of IGNORE_GUEST_PAT and SLOT_ZAP_ALL requires a vCPU, but for KVM itself, processing the quirk (or not) has functional impact, i.e. for all intents and purposes, KVM can't prevent those quirks from being disabled after they've been consumed. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-6-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 3097582b73a8ed1cd6f6790fa78706f4a79b5a49 Author: Carlos López Date: Tue Jul 14 15:32:13 2026 +0200 KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock commit 0ca49fbd2883cd53d32d85b50feef17fa04d0fbf upstream. Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d077 R09: 1ffffffff1f87a0e R10: dffffc0000000000 R11: fffffbfff1f87a0f R12: dffffc0000000000 R13: 0000000000000000 R14: ffff8880b8628240 R15: 1ffff92000814e64 hrtimer_start include/linux/hrtimer.h:259 [inline] stimer_start arch/x86/kvm/hyperv.c:682 [inline] kvm_hv_process_stimers+0xd0a/0x16a0 arch/x86/kvm/hyperv.c:893 vcpu_enter_guest arch/x86/kvm/x86.c:11193 [inline] vcpu_run+0x2240/0x76b0 arch/x86/kvm/x86.c:11639 kvm_arch_vcpu_ioctl_run+0x1148/0x1c90 arch/x86/kvm/x86.c:11984 kvm_vcpu_ioctl+0x99a/0xed0 virt/kvm/kvm_main.c:4492 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f635278f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f635365c038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f63529e5fa0 RCX: 00007f635278f749 RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00007f6352813f91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f63529e6038 R14: 00007f63529e5fa0 R15: 00007ffd5b219358 Fix this by clamping the deadline computation to KTIME_MAX, which preserves the intent of arming a timer very far in the future. ktime_add_safe() already does this type of clamping, so use it after checking that that multiplying by the 100ns time tick also does not overflow. Reviewed-by: Vitaly Kuznetsov Reported-by: syzbot+3d5461510f8dc4adfe30@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3d5461510f8dc4adfe30 Fixes: 1f4b34f825e8 ("kvm/x86: Hyper-V SynIC timers") Cc: stable@vger.kernel.org Signed-off-by: Carlos López Link: https://patch.msgid.link/20260714133212.3916611-3-clopez@suse.de [sean: tag for stable] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 41debfc98526c0a95c41a62435aca0a70340a26d Author: Phil Rosenthal Date: Mon Jul 20 13:45:49 2026 -0400 KVM: x86/mmu: Consume the locked rmap value in the lockless rmap walk commit e428f9779a43737d830111238816f1928b07aefb upstream. __kvm_rmap_lock() deliberately elides the rmap lock when it observes an empty rmap. In that case kvm_rmap_lock_readonly() also re-enables preemption and returns zero, so the caller holds neither the rmap lock nor a preemption reference. The elision documents the invariant it relies on: * Elide the lock if the rmap is empty, as lockless walkers (read-only * mode) don't need to (and can't) walk an empty rmap, nor can they add * entries to the rmap. I.e. the only paths that process empty rmaps * do so while holding mmu_lock for write, and are mutually exclusive. kvm_rmap_age_gfn_range() ignores the returned value and unconditionally enters for_each_rmap_spte_lockless(). The iterator started with rmap_get_first(), which re-reads rmap_head->val rather than using the value returned by the lock. If a writer populates the rmap between the lock's read and the iterator's re-read, the aging path walks the newly installed rmap without holding its lock. For a KVM_RMAP_MANY rmap this leaves the walker following a pte_list_desc chain that it never locked. A writer holding mmu_lock for write may free that chain (e.g. kvm_zap_all_rmap_sptes() on the recycle path, or any rmap zap) via kmem_cache_free() while the walk is in progress, giving a slab use-after-free. Nothing serialises the two: the aging path runs without mmu_lock when CONFIG_KVM_MMU_LOCKLESS_AGING=y, and the rmap lock that would otherwise exclude the writer was elided. Because the empty path re-enables preemption, the interval between the two reads can span an arbitrary scheduling delay. Fix the class of bug by having the lockless walk consume the value returned by the lock instead of re-reading the rmap. Split rmap_get_first() into __rmap_get_first(), which starts an iterator from an already-read rmap value, and make for_each_rmap_spte_lockless() take that value and call __rmap_get_first() directly. kvm_rmap_age_gfn_range() passes the value returned by kvm_rmap_lock_readonly(): when the lock was elided the value is zero, __rmap_get_first() returns NULL, and the walk is skipped. No lockless walker re-reads the rmap, so the lock-elision invariant cannot be violated, and no lock()-without-paired-unlock() path is added to the aging code. Fixes: af3b6a9eba48 ("KVM: x86/mmu: Walk rmaps (shadow MMU) without holding mmu_lock when aging gfns") Suggested-by: Sean Christopherson Cc: stable@vger.kernel.org Signed-off-by: Phil Rosenthal Link: https://patch.msgid.link/20260720-rmap-age-elided-submit-v2-1-668973030d47@phil.gs Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 7b2721d66525fda5dd2b9f7547e7f0eea7efc8c1 Author: Sean Christopherson Date: Thu Jul 9 13:49:39 2026 -0700 KVM: x86/mmu: Use split "zap all fast" helpers when invalidating memslot commit db095727ff5739f4f46ee641ee6ef450032886db upstream. Manually invoke the front half and back half of the "zap all fast" flow when invalidating a memslot so that mmu_lock is acquired at function scope in kvm_arch_flush_shadow_memslot(). This will allow putting more code inside the critical section without having to take mmu_lock twice in quick succession. Opportunistically open code checking whether or not to do the fast zap, to discourage removing the local "zap_all" in a future cleanup, i.e. to ensure the SLOT_ZAP_ALL quirk is queried exactly once. Processing the front half but not the back half of the fast zap (if SLOT_ZAP_ALL were disabled concurrently) would result in KVM unnecessarily keeping invalid TDP MMU roots until the VM is destroyed. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-10-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 0a25ee42e7d1a9bff2355884d43677f3eaff3d4a Author: Sean Christopherson Date: Mon Jul 27 17:22:35 2026 -0700 KVM: x86/mmu: Use CMPXCHG when clearing Accessed bit in TDP MMU commit 3d679b7cb31f74bf2303123ce4ee3266eeee999a upstream. Use LOCK CMPXCHG instead of LOCK AND to clear the Accessed bit when aging SPTEs in the TDP MMU, as doing a LOCK AND can corrupt a FROZEN SPTE and allow a third CPU to effectively overwrite the FROZEN SPTE. As pointed out by AI of some kind, because the magic FROZEN_SPTE value is a "full" SPTE, not a single bit, and includes the Accessed bit, clearing the Accessed bit in a FROZEN SPTE will result in is_frozen_spte() getting a false negative. E.g. if CPU0 freezes an SPTE, and CPU1 clears the Accessed bit in the frozen SPTE, then CPU2 could come along and overwrite the frozen SPTE with a shadow-present SPTE. Thankfully, the false negative is largely benign, because outside of TDX, which doesn't support aging, KVM only freezes leaf SPTEs when removing an upper level shadow page. So while KVM could clobber a frozen SPTE back to a shadow-present SPTE, and could even use the new SPTE, the subsequent TLB flush will make the orphaned, shadow-present SPTE unreachable. Failure to ever zap the orphaned leaf SPTE would show up in KVM's stats, but otherwise is benign (because KVM no longer keeps an elevated refcount for leaf SPTEs). Opportunistically add a comment to warn future developers away from using kvm_tdp_mmu_write_spte_atomic() and tdp_mmu_clear_spte_bits_atomic(), as they are generally unsafe. Keep the helpers, e.g. instead of open-coding the atomic64_fetch_and() in tdp_mmu_clear_spte_bits(), as scary warnings usually are more effective deterrent against recidivism than removal of the dangerous code. Alternatively, KVM could use different bits for the magic FROZEN_SPTE value, e.g. setting the Dirty bits (with effective IPAT and Global aliases) would likely be "ok", as IPAT/Global are extremely unlikely to be cleared without doing a full SPTE write, and KVM's clearing of Dirty bits shares logic with Write-Protection, which must do a full SPTE write (via cmpxchg64() in the TDP MMU) to ensure KVM isn't clobbering state. But there is zero reason to carry that risk (beyond stubbornness in wanting to preserve a "cute" idea), as the cost of LOCK CMPXCHG and LOCK AND are within 1-2 uops of each other on modern hardware. Fixes: b146a9b34aed ("KVM: x86/mmu: Age TDP MMU SPTEs without holding mmu_lock") Cc: stable@vger.kernel.org Reviewed-by: Kai Huang Reviewed-by: James Houghton Link: https://patch.msgid.link/20260728002236.869865-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit e29e9a9d81140f52df69bf9faf5b0f80de0eb224 Author: Sean Christopherson Date: Thu Jul 9 13:49:38 2026 -0700 KVM: x86/mmu: Split kvm_mmu_zap_all_fast() into "front" and "back" halves commit b27622c4eeb125814081baaefe9175191be5b94d upstream. Split kvm_mmu_zap_all_fast() into a "front half" and a "back half", where the front half is everything that runs with mmu_lock held for write, and the back half is the code that runs outside of mmu_lock. This will allow putting more code inside kvm_arch_flush_shadow_memslot()'s critical section without having to take mmu_lock twice in quick succession. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-9-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 93b7f6eb76a134f80f904d1981f0ca063d84ca0e Author: Sean Christopherson Date: Thu Jul 9 13:49:37 2026 -0700 KVM: x86/mmu: Fold kvm_mmu_zap_memslot() into kvm_arch_flush_shadow_memslot() commit 06d38eaa78fdac1cc889f261fa420eba8e9caa1a upstream. Fold kvm_mmu_zap_memslot() into its sole caller so that its GFN range structure can be used to trigger guest_memfd invalidations regardless of whether KVM will do a partial or full zap of the MMU. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-8-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 27bdeb5fd19046ffba9ff234e92fe553eb2efb30 Author: Yosry Ahmed Date: Tue Jun 16 21:46:52 2026 +0000 KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU commit 6d00e67326d831e6e610933a3800712f4ffe6ec1 upstream. When emulating INVVPID, KVM executes INVVPID on the physical CPU using vpid02 (instead of the L1 assigned VPID), after doing some validations on the operands. However, it is possible that the physical CPU KVM executes INVVPID on is different from the CPU L2 is running on. For example, in the following scenario: - L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1) - L1 migrates to CPU #2 and executes INVVPID - KVM executes INVVPID on CPU #2 - L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02.cpu=1) The TLB entries on CPU #1 are never invalidated, because INVVPID was executed on CPU #2, and vmcs02 never ran on a different pCPU (i.e. vmx_vcpu_load_vmcs() will *not* request KVM_REQ_TLB_FLUSH). Ensure that INVVPID is being executed on the same pCPU that L2 last ran on, and if not, fallback to clearing last_vpid=0 to trigger a full VPID flush on the next nested VM-Enter (as KVM will detect L1 using a different VPID for L2). If L2 ends up running on a different pCPU, KVM will flush the TLB anyway through vmx_vcpu_load_vmcs(). Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Reviewed-by: Kai Huang Link: https://patch.msgid.link/20260616214652.2157032-4-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit c43563e7518e65ec6ccaa6a65f84c5af5ca5d379 Author: Yosry Ahmed Date: Wed Jul 22 23:01:28 2026 +0000 KVM: nVMX: Service local TLB flushes on failed nested VM-Enter commit 05a0b701d1089fb57beeb8982f23c3bbafe0fa8b upstream. KVM services local TLB flushes on "full" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated. Fixes: 5c614b3583e7 ("KVM: nVMX: nested VPID emulation") Cc: stable@vger.kernel.org Reported-by: Sashiko # Internal review Suggested-by: Sean Christopherson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260722230128.1587363-1-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 674a3244f07f323f21a106a7bdcaebb6db6a5058 Author: Sean Christopherson Date: Thu Jul 23 17:47:52 2026 -0700 KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit commit 11722439fb206c88e6f31be54173efa9880b4ccb upstream. Always check and clear KVM_REQ_GET_NESTED_STATE_PAGES when emulating a nested VM-Exit to ensure the request is cleared, even when KVM was built with CONFIG_KVM_HYPERV=n, as KVM subtly relies on the "check" to clear the flag and thus avoid double-mapping the vmcs12 pages, e.g. if KVM manages to bail from VM-Enter without processing the request, and then emulates VMLAUNCH or VMRESUME. Fixes: b4f69df0f65e ("KVM: x86: Make Hyper-V emulation optional") Cc: stable@vger.kernel.org Reported-by: Yosry Ahmed Reviewed-by: Yosry Ahmed Link: https://patch.msgid.link/20260724004757.131420-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit d689dd4eae48d5a7d91ec3e0dea108c37c1cd899 Author: Sean Christopherson Date: Tue Jun 16 21:46:51 2026 +0000 KVM: nVMX: Decouple INVVPID operand checks from flushing of vpid02 commit 32912404b4b1ee98400744941c78f019a63d6e8f upstream. Separate the INVVPID operand checks from the actual flushing of vpid02 so the flushing can be adjusted to do the right thing when vmcs02 was last loaded on a different pCPU, without having to duplicate the logic across multiple case-statements. Opportunistically let the VM-Fail paths poke out past 80 chars. No functional change intended. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Reviewed-by: Kai Huang Link: https://patch.msgid.link/20260616214652.2157032-3-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 22dfcc22c95e91295119a1c3b469816ce44c4804 Author: Yosry Ahmed Date: Tue Jun 16 21:46:50 2026 +0000 KVM: nVMX: Always flush vpid02 on first use commit f0772389413dce9657c7d6950abf3edbbd511356 upstream. Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Reviewed-by: Kai Huang Reviewed-by: Jim Mattson Link: https://patch.msgid.link/20260616214652.2157032-2-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 5778dda871f15afc0ee56dcc6a28c157b329bb2e Author: Amit Machhiwal Date: Tue Jul 14 23:24:32 2026 +0530 KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode commit 884ea0283f4effac97ee8f451464a7d1be480d7c upstream. On IBM POWER systems, newer processor generations can operate in compatibility modes corresponding to earlier generations. This becomes relevant for nested virtualization, where nested KVM guests may need to run with a specific processor compatibility level. Currently, when running a nested KVM guest (L2) inside a Power11 pSeries logical partition (L1) booted in Power10 compatibility mode, the guest fails to boot while setting 'arch_compat'. This happens because the CPU class is derived from the hardware PVR (via mfspr()), which reflects the physical processor generation (Power11), rather than the effective compatibility mode (Power10). As a result, userspace may request a Power11 arch_compat for the L2 guest. However, the L1 partition, running in Power10 compatibility, has only negotiated support up to Power10 with the Power Hypervisor (L0). When H_GUEST_SET_STATE is invoked with a Power11 Logical PVR, the hypervisor rejects the request, leading to a late guest boot failure: KVM-NESTEDv2: couldn't set guest wide elements [..KVM reg dump..] This situation should be detected earlier and rejected by KVM. Without proper validation, if userspace ignores the error, the guest may continue to boot in Power11 raw mode on a Power10 compatibility host, which should not be allowed. Introduce a validation mechanism that detects unsupported arch_compat values early in the guest initialization path. When an unsupported arch_compat is requested (e.g., Power11 on a Power10 compatibility mode host), kvmppc_set_arch_compat() uses cpu_has_feature(CPU_FTR_P11_PVR) to detect the mismatch and sets arch_compat to PVR_ARCH_INVALID (0xffffffff). This sentinel value is architecturally safe: PAPR specifies that valid logical PVR values must have 0x0f as the first byte, ensuring 0xffffffff lies permanently outside the specification-defined range. Setting this value triggers kvmppc_sanity_check() to mark the vCPU as invalid by setting vcpu->arch.sane to false. On the next vCPU run, kvmppc_vcpu_run_hv() checks this flag and returns -EINVAL, preventing the guest from running with an invalid processor compatibility configuration. With this, when a Power11 arch_compat is requested on a Power10 compatibility mode host, the guest fails early during boot with: error: kvm run failed Invalid argument This provides a much clearer failure mode compared to the previous behavior where the guest could boot in Power11 raw mode (if userspace ignored the error) or fail late during H_GUEST_SET_STATE. Suggested-by: Vaibhav Jain Reviewed-by: Vaibhav Jain Tested-by: Anushree Mathur Acked-by: Gautam Menghani Cc: stable@vger.kernel.org # v6.13+ Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Amit Machhiwal Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260714175432.86388-1-amachhiw@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit c9f2c50bad37d573ef7d2a02e576b6c01fcccd92 Author: Nikhil Gautam Date: Tue Jul 14 17:01:34 2026 +0530 iio: light: opt4001: Fix reversed GENMASK() arguments in fault count mask commit d64bfd9f3352b9d9bdeca06de1a0a1c1bd47b896 upstream. GENMASK(h, l) requires h >= l, but OPT4001_CTRL_FAULT_COUNT is defined as GENMASK(0, 1). The define is currently unused so there is no functional impact, but fix it before anyone builds on it, and add the _MASK suffix for consistency with the neighbouring definitions. Fixes: 9a9608418292 ("iio: light: Add support for TI OPT4001 light sensor") Signed-off-by: Nikhil Gautam Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b6cedf011bd95c752a1dc7bed3be38bd08494221 Author: Nikhil Gautam Date: Tue Jul 14 17:01:33 2026 +0530 iio: light: opt4001: Reject integration times with a non-zero seconds part commit d0f21621f8b2b46661ea066d20705dbf7253db87 upstream. opt4001_write_raw() only looks at val2 when setting the integration time, so a write such as 1.000600 is silently accepted as 600 us. Return -EINVAL if val is non-zero. Fixes: 9a9608418292 ("iio: light: Add support for TI OPT4001 light sensor") Signed-off-by: Nikhil Gautam Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 958d691403936ed317eecb7f9461025d1a1093c6 Author: Nikhil Gautam Date: Tue Jul 14 17:01:32 2026 +0530 iio: light: opt4001: Fix incompatible pointer type passed to div_u64_rem() commit afa28741c9a2cf6edb2e41e25ff146a562160bb3 upstream. div_u64_rem() takes a u32 * for the remainder but is passed val2, which is an int *. There is no functional impact as int and u32 have the same size and representation on all supported architectures and the remainder is always smaller than the divisor, so it fits in the positive range of int. Fix the type mismatch by using a local u32 for the remainder and assigning the result to *val2. Fixes: 9a9608418292 ("iio: light: Add support for TI OPT4001 light sensor") Signed-off-by: Nikhil Gautam Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4a9820aa8ef7e86774152f410d2774e89bc99636 Author: Nikhil Gautam Date: Tue Jul 14 17:01:31 2026 +0530 iio: light: opt4001: Fix power down clearing bits of the wrong register commit 3b2cd82c524c75a2173f2e3f874652a75f81cd1d upstream. opt4001_power_down() intends to clear the operating mode bits in the CTRL register but reads OPT4001_DEVICE_ID instead of OPT4001_CTRL, so the value written back to CTRL contains device ID bits rather than the current configuration. Fix and simplify this by using regmap_clear_bits() on the CTRL register directly in the devm action, and drop opt4001_power_down() which has no other users. Suggested-by: Jonathan Cameron Fixes: 9a9608418292 ("iio: light: Add support for TI OPT4001 light sensor") Signed-off-by: Nikhil Gautam Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6d00b4fec5bf2f8c57d6bf2257d5f8598e0d9264 Author: Vidhu Sarwal Date: Wed Jul 15 06:45:44 2026 +0530 iio: light: opt4060: Fix incorrect register name in threshold read error message commit ad367638212a9f2495ecfa59c886f0cfb7934e9c upstream. opt4060_get_thresholds() correctly reads OPT4060_THRESHOLD_HIGH, but logs "Failed to read THRESHOLD_LOW." if the read fails. This is a copy-and-paste mistake, as the preceding low-threshold read already uses the correct error message. Update the error message to reference OPT4060_THRESHOLD_HIGH. Fixes: 0c6db4506ad0 ("iio: light: Add support for TI OPT4060 color sensor") Signed-off-by: Vidhu Sarwal Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 38f58a02496667d17e1312782d6bc3c2f756bd64 Author: Vidhu Sarwal Date: Wed Jul 15 06:45:42 2026 +0530 iio: light: opt4060: Reject integration times with a non-zero seconds part commit b7e6e9af0d723afdec92364d5e7e064eeef44c8e upstream. When setting the integration time, opt4060_write_raw() only uses val2 and ignores val. As a result, a write such as 1.000600 is accepted and programmed as 600 us, silently discarding the whole seconds part. Since all supported integration times are less than one second, any non-zero val represents an invalid input. Reject such values instead of silently accepting them. Fixes: 0c6db4506ad0 ("iio: light: Add support for TI OPT4060 color sensor") Signed-off-by: Vidhu Sarwal Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit fcddb4da54ab94bb2fc6c45447ec4a940e6e6bd6 Author: Paul Geurts Date: Mon Jul 6 09:48:03 2026 +0200 iio: ti-ads7138: Disable STATS_EN bit while reading conversion results commit bcb721c1bcb02ab225b3937bf131a0bc6fc1fecd upstream. There is a data race in reading the STATS registers, resulting in wrong data being read. When the data in the RECENT register switches between 0x24F0 and 0x2500, occasionally value 0x2400 or 0x25F0 is read. This happens when the value is updated in between reading MSB and LSB. The data sheet says: "Until a new conversion result is available, previous values can be read from the statistics registers. Before reading the statistics registers, set STATS_EN to 0 to prevent any updates to this register block." As the STATS_EN is currently not cleared, the values of the stats registers might change mid read, giving faulty values. Disable the STATS_EN bit before reading one of the statistics registers to make sure the device does not update the register mid read. This is applicable to registers MAX_CHn_xSB, MIN_CHn_xSB and RECENT_CHn_xSB. This means reading one of the statistics registers resets the MAX and MIN registers. This is unfortunate, but necessary to get correct data from the device. Signed-off-by: Paul Geurts Fixes: 024b08fee342 ("iio: adc: Add driver for ADS7128 / ADS7138") Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c0d491c243e70e80fb887b6900fb462be11592ef Author: Sanjay Chitroda Date: Thu Jun 25 17:46:11 2026 +0530 iio: temperature: hid-sensor-temperature: switch to non-devm iio_device_register() commit 967d066f5334740f656577bc51c381a1bb707b61 upstream. Avoid using devm_iio_device_register(), as this driver requires explicit error handling and teardown ordering. With devm_iio_device_register(), IIO device remains registered until the devres cleanup phase. However, driver's remove() callback removes the sensor hub callback and trigger support. This can create a race window where IIO device is still visible and read_raw() requests are issued. These requests might call sensor_hub_input_attr_get_raw_value(), which waits up to 5 seconds for a response from the sensor hub callback that has already been removed. Add an explicit iio_device_unregister() call in the teardown path to ensure deterministic cleanup, so that userspace can no longer access the device once backend resources begin to be dismantled. Fixes: 59d0f2da3569 ("iio: hid: Add temperature sensor support") Cc: stable@vger.kernel.org Reviewed-by: Maxwell Doose Reviewed-by: Andy Shevchenko Signed-off-by: Sanjay Chitroda Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c2d6437663d7c33132956c09f0150104dce111d0 Author: Cong Nguyen Date: Mon Jul 27 22:51:15 2026 +0700 iio: srf04: fix pm_runtime handling on probe error path commit a40b2e7a17f26e38ab054363c9c7cde149588357 upstream. When pm_runtime_set_active() fails during probe, the driver logs the error and unregisters the IIO device, but then falls through and still calls pm_runtime_enable() before returning the error. Since probe returns an error, srf04_remove() is never called, so runtime PM is left enabled without a matching pm_runtime_disable(). This leaks the enable and triggers an "Unbalanced pm_runtime_enable!" warning on a subsequent bind of the device. Return the error right after unregistering the IIO device so that runtime PM is not enabled on the failure path. Fixes: 2251157b335b ("iio: srf04: add power management feature") Cc: stable@vger.kernel.org Signed-off-by: Cong Nguyen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit eef652190b00f68a46215c24004378b083e00dd6 Author: Can Peng Date: Mon Jul 20 10:43:12 2026 +0800 iio: pressure: mpl115: Fix runtime PM cleanup commit 0b5e142ced4bcf20532da051934bd694d1bbd470 upstream. mpl115_probe() enables runtime PM when a shutdown GPIO is present and then returns the result of devm_iio_device_register(). If registration fails, runtime PM remains enabled and autosuspend remains selected. The same unmanaged runtime PM state is also left behind on driver unbind, as the IIO device registration is managed but the runtime PM setup is not. Use devm_pm_runtime_enable() so runtime PM is disabled automatically on probe failure and driver unbind, and check pm_runtime_set_active() so setup errors are reported. Set the autosuspend parameters before enabling runtime PM. Once probe has completed, the driver core queues an idle request for the device, so an explicit pm_runtime_get_noresume()/pm_runtime_put() pair is not needed to start autosuspend. Fixes: 0c3a333524a3 ("iio: pressure: mpl115: Implementing low power mode by shutdown gpio") Cc: stable@vger.kernel.org Suggested-by: jonathan.cameron@oss.qualcomm.com Signed-off-by: Can Peng Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7ded5b76ec2df6a3fb1bfde0d1869cde363fef30 Author: Rupesh Majhi Date: Sun Jul 19 03:07:52 2026 +0300 iio: pressure: dps310: fix NULL pointer dereference on ACPI probe commit 26e9213898fc949923188ef0aeea31fc87708836 upstream. When the device is enumerated through its ACPI HID (IFX3100), i2c_client_get_device_id() returns NULL: the ACPI-derived client name does not match the driver's i2c_device_id table. dps310_probe() then dereferences that NULL pointer in "iio->name = id->name" and crashes the kernel during probe. The IIO device name is always "dps310", so set it directly and drop the now-unused device-id lookup. Fixes: 72ff282819d0 ("iio: pressure: dps310: Add ACPI HID table") Cc: stable@vger.kernel.org Signed-off-by: Rupesh Majhi Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0614928a3eda35bddd8c2f02311e286b59bbe746 Author: Vidhu Sarwal Date: Mon Jul 13 07:58:29 2026 +0530 iio: light: ltrf216a: fix runtime PM reference leak in error path commit c132aef0e757a39036b1d40faf0569f2e343b13e upstream. ltrf216a_get_lux() acquires a runtime PM reference by calling ltrf216a_set_power_state(data, true). However, if ltrf216a_read_data() fails, the function returns immediately without dropping the reference. This leaves the runtime PM usage count unbalanced, preventing the device from autosuspending after a failed read. Fix this by releasing the runtime PM reference before returning from the error path. Fixes: 83f0bcd40d5c ("iio: light: Add support for ltrf216a sensor") Signed-off-by: Vidhu Sarwal Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 1ce47f00e9c00b93714831b5468eed3d64dd7032 Author: Laxman Acharya Padhya Date: Sat Jul 4 14:19:12 2026 +0545 iio: light: gp2ap002: Disable regulators on resume failure commit a41000ba3a230bed1e422f283486ff8f77fe0d30 upstream. If enabling VIO fails after VDD has been enabled, runtime resume returns without disabling VDD. Likewise, if device reinitialization fails, both supplies remain enabled. The runtime PM core keeps the device suspended when its resume callback fails, so the supplies must be restored to the suspended state. Disable the supplies enabled by the callback before returning an error. Fixes: 97d642e23037 ("iio: light: Add a driver for Sharp GP2AP002x00F") Assisted-by: Codex:gpt-5 Signed-off-by: Laxman Acharya Padhya Reviewed-by: Linus Walleij Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9c1b74fdcffa461ba801580a187e42cbb3bedac8 Author: Giorgi Tchankvetadze Date: Fri Jul 31 17:20:48 2026 +0400 iio: light: cm32181: return zero after writing calibscale commit 8756acd30919a3e9f547ea4a1d4b7f7895f4d340 upstream. The write_raw callback is documented to return 0 on success or a negative error code. However, the IIO_CHAN_INFO_CALIBSCALE case returns 'val' (the user-supplied value) instead of 0. Fix it by returning 0 on success, matching the behavior of other calibscale implementations in the subsystem. Fixes: 971672c0b3cc ("iio: add Capella CM32181 ambient light sensor driver.") Signed-off-by: Giorgi Tchankvetadze Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d2b32b71fa5bdaba3711d966faa4c93e3d7e84a2 Author: Cong Nguyen Date: Sun Aug 2 13:55:40 2026 +0700 iio: gyro: mpu3050: fix sign of raw angular velocity readings commit 06fab97602fe400bea843176f485bbac07a668e2 upstream. The MPU-3050 gyroscope output registers hold 16-bit two's complement values; the angular velocity channels are declared with .sign = 's'. When mpu3050_read_raw() handles IIO_CHAN_INFO_RAW it reads the register via a big-endian regmap_bulk_read() and assigns it with: *val = be16_to_cpu(raw_val); be16_to_cpu() yields an unsigned 16-bit quantity, so negative rates (bit 15 set) are reported to userspace as large positive integers (e.g. -1 becomes 65535) instead of the correct negative value. Cast to s16 before the assignment, matching the temperature channel a few lines above which already handles the sign correctly. Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Reviewed-by: Linus Walleij Reviewed-by: Joshua Crofts Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 08ac8d2976d57aa943d64e351c4d0bd8bb0c6de9 Author: Erick Henrique Date: Fri Jul 3 17:52:36 2026 -0300 iio: dac: m62332: Fix regulator reference count imbalance commit a130404ce0b69ca1438126bd81c1985d3b4d2e6f upstream. m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails. Fixes: b87b0c0f81e8 ("iio: add m62332 DAC driver") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260418130322.106769-1-erick.henrique.rodrigues%40usp.br Cc: stable@vger.kernel.org Signed-off-by: Erick Henrique Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit bcc324f3033cd3e6e789b0ee10d934ea335991d9 Author: Babanpreet Singh Date: Sat Jul 18 18:22:36 2026 +0000 iio: dac: ad3552r-hs: fix scnprintf() buffer bound in data source show commit f2c5c76306fadb834dd5ea76cab0b7cd447e6035 upstream. ad3552r_hs_show_data_source_avail() formats the available data source names into a 128-byte stack buffer, but bounds each scnprintf() with PAGE_SIZE instead of the buffer size, so the bound does not protect the destination at all. This cannot overflow today - dbgfs_attr_source[] has two entries, "normal" and "ramp-16bit", 18 bytes formatted - but the bound stops protecting the stack the day the table grows. Use sizeof(buf) so the bound matches the destination. Found by smatch: drivers/iio/dac/ad3552r-hs.c:593 ad3552r_hs_show_data_source_avail() error: scnprintf() 'buf[len]' too small (128 vs 4096) Fixes: b1c5d68ea66e ("iio: dac: ad3552r-hs: add support for internal ramp") Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Babanpreet Singh Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2d386efb4c37a50739db19c7c8e49564fd53a570 Author: Linmao Li Date: Wed Jul 22 15:48:37 2026 +0800 iio: chemical: sgp30: Handle IAQ thread creation failure commit 1135d6875d2dbda3f6ec718f3421a6ce4378bd63 upstream. kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead. Fixes: ce514124161a ("iio: chemical: sgp30: Support Sensirion SGP30/SGPC3 sensors") Signed-off-by: Linmao Li Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2071624c3d0f497ca91da78858e6f30d7112fea6 Author: Fan Wu Date: Sun Aug 2 07:18:58 2026 +0000 iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF commit be61c8c6252671ecf1fee0ad90f87669e0be1e20 upstream. The atlas driver requests its hardware data-ready IRQ with devm_request_threaded_irq(); its threaded handler queues an irq_work, atlas_work_handler(), that calls iio_trigger_poll(data->trig). The IRQ is devm-managed, so free_irq() runs from the devres unwind after atlas_remove() returns without flushing that irq_work. Once a buffer is enabled, conversion-complete IRQs keep firing and queueing it; a pending irq_work can therefore run after the unwind has freed atlas_data/indio_dev and the trigger, when atlas_work_handler() derives the atlas_data pointer via container_of() and dereferences data->trig, a use-after-free. Call iio_trigger_poll_nested() directly from the threaded handler instead of bouncing through irq_work. free_irq() then drains the threaded handler, closing the window; other iio drivers with a threaded data-ready IRQ do the same (e.g. bmi270). This issue was found by an in-house static analysis tool. Fixes: 7103b99b031c ("iio: chemical: atlas-ph-sensor: reorg driver to allow multiple chips") Cc: stable@vger.kernel.org # v6.4+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 43bce901047e95bbf8fb63eb471460642e497604 Author: Moksh Panicker Date: Mon Jul 13 03:00:46 2026 +0000 iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable commit bcd3f72e26314edfce7eaf8d7160b3119c7b7fed upstream. atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference. Fixes: 0e4f336f50de ("iio: chemical: atlas-sensor: Balance runtime pm + pm_runtime_resume_and_get()") Cc: stable@vger.kernel.org Signed-off-by: Moksh Panicker Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 510497e31be4f241103507315a859e2085ccb081 Author: Lars-Peter Clausen Date: Wed Jul 15 08:42:44 2026 -0700 iio: buffer: Tie IIO dma fence lock lifetime to the fence commit f25ec4627d935dedfb5fe83bd2c2678cdcc19611 upstream. The `iio_dma_fence` implementation currently uses a lock embedded in the `iio_dmabuf_priv`. But the `iio_dma_fence` can outlive the `iio_dmabuf_priv`, which can cause a use-after-free. Tie the lifetime of the lock to the lifetime of the fence by embedding them in the same struct. We can't just hold a reference to the `iio_dmabuf_priv` from the `iio_dma_fence` since `iio_buffer_dmabuf_release()` might sleep and the fence release callback is not allowed to sleep. Note that the `dma_fence` framework now has an internal lock that gets used when the passing `NULL` for `lock` in `dma_fence_init()`, but in order to allow this patch to be backportable use an external lock. Reported-by: codex:gpt-5.6 Fixes: 3e26d9f08fbe ("iio: core: Add new DMABUF interface infrastructure") Signed-off-by: Lars-Peter Clausen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 06a9460b8b792e109cbc934a856d02e5cff217ef Author: Lars-Peter Clausen Date: Wed Jul 15 08:42:45 2026 -0700 iio: buffer: Make IIO DMA fence release RCU-safe commit 8662e56c31cf23b61ca3d11b516efb94c35b8026 upstream. The `dma_fence` documentation states that if a custom release implementation is provided, the `dma_fence` object must be freed in an RCU-safe way. The current `iio_dma_fence` implementation uses `kfree()`, which might result in a use-after-free. Remove the custom `release` implementation. This makes the DMA fence core fall back to `dma_fence_free()`, which calls `kfree_rcu()` on the fence. This requires that the fence be the first member of `struct iio_dma_fence`. Using the default release method for extended DMA fence structures is a common pattern. Reported-by: codex:gpt-5.6 Fixes: 3e26d9f08fbe ("iio: core: Add new DMABUF interface infrastructure") Signed-off-by: Lars-Peter Clausen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f1f8f0e8e0af9cae8150658dc7bb51332f984893 Author: Lars-Peter Clausen Date: Wed Jul 15 08:42:43 2026 -0700 iio: buffer: Fix potential use-after-free in anonymous buffer release commit 6288b593e76eb10329326f2cd51e32557203b9e5 upstream. An anonymous buffer handle holds a reference to the underlying IIO device. The reference is dropped in the buffer handle's release function. If the device has been removed, either through unbind or hot-unplug, the buffer handle might hold the last reference. The release function takes the mutex for the buffer using a guard, which means the unlock happens after all the code in the function, including `iio_device_put()`. If the anonymous buffer holds the last reference this might free both the IIO device and the buffer, which contains the mutex, leading to use-after-free when the mutex is unlocked. Fix this by using a scoped guard just around the buffer dmabuf list access, making sure the mutex is unlocked before releasing the IIO device. Version 10 of the patch that introduced this issue used this exact scheme of first unlocking and then dropping the reference [1]. During review it was suggested to use a guard instead, and version 11 made that change [2]. Reported-by: codex:gpt-5.6 Fixes: 3e26d9f08fbe ("iio: core: Add new DMABUF interface infrastructure") Signed-off-by: Lars-Peter Clausen Link: https://lore.kernel.org/linux-iio/20240605110845.86740-4-paul@crapouillou.net #[1] Link: https://lore.kernel.org/linux-iio/20240618100302.72886-4-paul@crapouillou.net #[2] Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8de90e0e0f6d99f086f79683868c806bba8b183d Author: Cong Nguyen Date: Sun Aug 2 14:12:46 2026 +0700 iio: adc: pac1921: fix wrong channel used in trigger handler read commit 3364c56b20c1c496bdb8c8df32f96a9947dbf98e upstream. pac1921_trigger_handler() walks the enabled channels with iio_for_each_active_channel(), which yields the scan index (bit) of each active channel, while ch is a separate counter used to pack the samples contiguously into the scan buffer. The register to read was looked up with the packing counter instead of the scan index: ret = pac1921_read_res(priv, idev->channels[ch].address, &val); pac1921_channels[] is ordered by scan index, so channels[bit] is the channel that is actually enabled, whereas channels[ch] is merely the ch-th array entry. These coincide only when the enabled channels form a contiguous prefix (e.g. all channels enabled). With a sparse scan mask - for example when only the power channel (scan index 3) is enabled - the handler reads the wrong register (VBUS instead of VPOWER) and pushes it to userspace as the enabled channel's data. Index the channel array by the scan index (bit) to read the correct register, keeping ch only for contiguous packing into the scan buffer. Fixes: 371f778b83cd ("iio: adc: add support for pac1921") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Acked-by: Matteo Martelli Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit beec14368c943a1d87d63381d1706b50965b3150 Author: Joshua Crofts Date: Wed Jul 8 07:34:13 2026 +0200 iio: adc: max34408: add missing 'select REGMAP_I2C' to Kconfig commit 947f1079074a260ba200419d5cba6b8549d5ac0c upstream. The Kconfig entry for the MAX34408 is missing a 'select REGMAP_I2C', causing build failures. Fixes: cf27775838c5 ("iio: adc: Add driver support for MAX34408/9") Cc: stable@vger.kernel.org Signed-off-by: Joshua Crofts Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d2ed166c901e954f85518062cdf3080539ae23e3 Author: Antoniu Miclaus Date: Mon Jul 13 11:40:42 2026 +0300 iio: adc: adi-axi-adc: add data size support for AD408X backend commit 60f6f7fd5f89c7f55991c5dc59f3ccc74cd6efd7 upstream. The AD408X AXI core can pack the sample data on the bus using different word widths. Expose this through the data_size_set backend operation so that frontends can program the packet format field (bits 3:2 of the CNTRL_3 register) according to the ADC resolution: 20-bit, 16-bit and 14-bit map to packet format values 0, 1 and 2 respectively. Signed-off-by: Antoniu Miclaus Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e9627244ac0d737efef54459f45d42269a886380 Author: WenTao Liang Date: Sat Jun 27 11:52:51 2026 +0800 ASoC: samsung: aries_audio_probe: double of_node_put due to direct assignment without of_node_get commit fb5d1b1c5f8a920ee697545fa6dee16825085717 upstream. In aries_audio_probe(), aries_dai[0].platforms->of_node is assigned the same pointer as aries_dai[0].cpus->of_node (from of_parse_phandle) without calling of_node_get(). When the sound card is deregistered, the ASoC framework calls of_node_put() on both cpus->of_node and platforms->of_node, causing a double put on the same node and a refcount underflow. Add of_node_get(aries_dai[0].cpus->of_node) before the assignment. Cc: stable@vger.kernel.org Fixes: 7a3a7671fa6c ("ASoC: samsung: Add driver for Aries boards") Signed-off-by: WenTao Liang Link: https://patch.msgid.link/20260627035251.60172-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4e580d84a638f007b5b68d50d7633de502f325e7 Author: Binbin Zhou Date: Fri Jun 26 10:27:03 2026 +0800 ASoC: loongson: Fix error handling in ACPI property parsing commit 0eb0e3c623ac1da8b85d518043fef7660af7805d upstream. In loongson_card_parse_acpi(), the return value of device_property_read_string() for the `codec-dai-name` property was ignored. If the property is missing or invalid, an uninitialized pointer would be used later, potentially leading to undefined behavior. Fix this by checking the return value and propagating the error appropriately. Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/cover.1780538113.git.zhoubinbin@loongson.cn?part=5 Fixes: ddb538a3004b ("ASoC: loongson: Factor out loongson_card_acpi_find_device() function") Signed-off-by: Binbin Zhou Link: https://patch.msgid.link/08e44a54708eae053be148524346bb8dfcd55b03.1782439646.git.zhoubinbin@loongson.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e11b056d69b8c9ff47493d57478d0a90ff4ae854 Author: Haoxiang Li Date: Mon Jun 22 17:16:20 2026 +0800 AsoC: intel: sst: fix PCI device reference leak on probe failure commit 016f29997ebd29d6ab59c8162ce0e7f73bd1e517 upstream. intel_sst_probe() takes a reference to the PCI device with pci_dev_get(). If sst_platform_get_resources() fails afterwards, the probe error path cleans up the driver context but does not drop the PCI device reference. Add a pci_dev_put() error path for failures after pci_dev_get(). Fixes: f533a035e4da ("ASoC: Intel: mrfld - create separate module for pci part") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260622091620.897478-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e8ea01a0457080b0cc7c69c430c0ab65d84dc377 Author: Haoxiang Li Date: Mon Jun 22 22:56:45 2026 +0800 ASoC: hdac_hda: Fix hlink refcount leak on component registration failure commit 6ad4892c4f5cb437a928a02f5b7d37d496aa9268 upstream. hdac_hda_dev_probe() gets the HDA link with snd_hdac_ext_bus_link_get() before registering the ASoC component. If component registration fails, the function returns without dropping the link reference. Always call snd_hdac_ext_bus_link_put() after the registration attempt so the reference taken during probe is balanced on both success and failure. Fixes: 6bae5ea94989 ("ASoC: hdac_hda: add asoc extension for legacy HDA codec drivers") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260622145645.1184986-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0966b76a0e23cc208e1caf3a7690ed56cff24206 Author: wangdicheng Date: Fri Jul 17 17:15:42 2026 +0800 ASoC: fsl_easrc: Use div64_u64 for 64-by-64 division commit a46ccc71877e962783e0fffa105e41615904c511 upstream. Fix a coccinelle warning about do_div() truncating a 64-bit divisor: sound/soc/fsl/fsl_easrc.c:2061:2-8: WARNING: do_div() does a 64-by-32 division, please consider using div64_u64 instead. In fsl_easrc_m2m_calc_out_len(), val1 is computed as: val1 = (u64)in_rate << frac_bits; // frac_bits up to 39 do_div(val1, out_rate); val1 += (s64)ctx_priv->ratio_mod << (frac_bits - 31); val1 = val1 >> 12; In the worst case (in_rate=384000, out_rate=8000, frac_bits=39): val1 = 384000 << 39 / 8000 = 26,388,279,068,672 val1 >> 12 = 6,440,497,829 (33 bits, exceeds 32-bit range) val1 is then used as the divisor in do_div(val2, val1), where do_div() silently truncates it to 32 bits, producing incorrect results. Use div64_u64() to perform a proper 64-by-64 division. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Cc: stable@vger.kernel.org Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260717091542.721877-4-wangdich9700@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5ca4bd7543524a9715205b2fc6251cdeb92a78df Author: Haoxiang Li Date: Mon Jun 22 17:48:22 2026 +0800 ASoC: fsl: mpc5200-i2s: Free DMA resources on probe failure commit 3a89ddcf0c3d9a068631e8c24d5c9e81d1e6512a upstream. mpc5200_audio_dma_create() creates the DMA resources before registering the component. If snd_soc_register_component() fails, the function returns directly and leaves the DMA resources allocated. Call mpc5200_audio_dma_destroy() before returning from this error path. Fixes: f515b67381de ("ASoC: fsl: mpc5200 combine psc_dma platform data") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260622094822.926166-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5a4fe7a87841af23ba80bae31b80355b16926cf4 Author: Runyu Xiao Date: Fri Jun 12 00:15:53 2026 +0800 ASoC: cs35l34: drain threaded IRQ before runtime suspend commit 4105a4c0678b2808fc8046b60321b4f1cc7dae75 upstream. cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it. Fixes: c1124c09e103 ("ASoC: cs35l34: Initial commit of the cs35l34 CODEC driver.") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260611161553.3378721-3-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6e369bc46663b4bfce3d5f8b8ed08e71ecea13a2 Author: Runyu Xiao Date: Fri Jun 12 00:15:52 2026 +0800 ASoC: cs35l33: drain threaded IRQ before runtime suspend commit e074c12c428c633e079154301207a6079a208583 upstream. cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it. Fixes: 3333cb7187b9 ("ASoC: cs35l33: Initial commit of the cs35l33 CODEC driver.") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260611161553.3378721-2-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit eb5d39dd862f5c91c2e2dba384b6d100ee90f05b Author: Linkai Gong Date: Thu Aug 13 17:56:17 2026 +0800 i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure commit 62edb8ca0aa44517cc23cfa26cd8a51f15ea92fe upstream. of_parse_phandle() takes a reference on the parent node. If a later devm_kstrdup() fails, err_rollback only releases nodes for indices 0..i-1, so the current node is leaked. of_node_put() the current parent before rolling back. Fixes: 7c0195fa9a9e ("i2c: mux: demux-pinctrl: check the return value of devm_kstrdup()") Signed-off-by: Linkai Gong Cc: # v6.6+ Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260813095617.2246320-1-gonglinkai@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit b2b87f2e0bb167c1f2996fea436b4afd939365ec Author: Stephan Gerhold Date: Mon Jul 6 17:02:15 2026 +0200 clk: qcom: gcc-mdm9607: Drop incorrect BIMC PLL and related clocks commit e111ddda092ad961870a634e4c9263c10a3e8485 upstream. The gcc-mdm9607 driver was originally based on gcc-msm8916, but a closer match nowadays is gcc-msm8909. Looking at the differences between gcc-mdm9607 and gcc-msm8909, there is quite some confusion around the definitions for the BIMC PLL. It turns out the BIMC PLL on MDM9607 is actually an Alpha PLL just like on MSM8909. We can vote for it using BIT(2), which explains why BIT(3) was used for GPLL2. In practice, the BIMC PLL is exclusively controlled by the RPM firmware and Linux should not touch it. So far, it was defined to model the full clock hierarchy, but even in read-only mode with CLK_GET_RATE_NOCACHE this is problematic since the RPM will silently change the clock parents without notifying Linux about it. The clock framework reads the clock parent only once during boot, so the resulting rates will still be often wrong. Follow the example of more recent SoCs and drop the BIMC PLL and all remaining related clocks to avoid reporting stale status data. This means we cannot determine the rate of these clocks anymore. This is not a big problem in practice, since these are NoC-related clocks that are independently managed through the interconnect subsystem. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Signed-off-by: Stephan Gerhold Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-8-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 4763197c6f344be19ce69c4bae07edbe65e331df Author: Stephan Gerhold Date: Mon Jul 6 17:02:11 2026 +0200 clk: qcom: gcc-mdm9607: Fix halt_reg for gcc_apss_axi_clk commit ca7e6cc30cde4f0cbeff2e205a84bedf431e9156 upstream. gcc_apss_axi_clk specifies a halt_reg of 0x4601c, but this is already used by gcc_apss_ahb_clk. The correct value according to the downstream driver is 0x46020. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Taniya Das Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-4-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit bd326b0c5b3393281dfdf47a9b89578470a67d23 Author: Stephan Gerhold Date: Mon Jul 6 17:02:10 2026 +0200 clk: qcom: gcc-mdm9607: Fix enable_reg for gcc_blsp1_sleep_clk commit 944d0fb38cffe57a1d1ebf82c5c077bad82dcdbb upstream. MDM9607 is similar to MSM8909, where the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-3-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit c67fc2fd713959a744b47ec366c7ffb4f2ed3f31 Author: Stephan Gerhold Date: Mon Jul 6 17:02:14 2026 +0200 clk: qcom: gcc-mdm9607: Drop incorrect system_noc_bfdcd_clk_src commit 17784427df923a0573a7ea83f9198456ff1ec1a5 upstream. This clock does not exist on MDM9607. Reading/writing the registers always results in 0. Presumably, this definition was mistakenly copied from gcc-msm8916. On MSM8916, this root clock is used for multimedia subsystems (camera, display, video). MDM9607 has none of that, so this clock was probably omitted in the hardware. There are no users inside gcc-mdm9607, so we can just drop it. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-7-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 206a6e21a0cf481351acde2d4b29b3e3a11ac683 Author: Stephan Gerhold Date: Mon Jul 6 17:02:13 2026 +0200 clk: qcom: gcc-mdm9607: Drop incorrect apss_tcu_clk_src commit 38d06956f60675f906dc3f5b70b3b52103b86a7d upstream. This clock does not exist on the specified address on MDM9607. Reading/writing the registers always results in 0 or crashes. The math in the frequency table is also broken. GPLL2 on MDM9607 runs at 480 MHz, so: - F(155000000, P_GPLL2, 6, 0, 0), // 480 MHz/6 = 80 MHz, not 155 MHz - F(310000000, P_GPLL2, 3, 0, 0), // 480 MHz/3 = 160 MHz, not 310 MHz Presumably, this definition was mistakenly copied as-is from gcc-msm8916 (which uses 930 MHz for GPLL2). There are no branch consumers of this root clock inside gcc-mdm9607 (notably, gcc_apss_tcu_clk has bimc_ddr_clk_src as parent instead of this clock), so we can just drop it. It seems like this clock does exist on this SoC on a different address, but since there is no user and reference code for it, it is still better to drop it. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-6-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 526b0a71a4d914aed35e9a9b9e987eeaf1c76871 Author: Heiko Stuebner Date: Wed Mar 4 13:14:25 2026 +0100 clk: rockchip: rk3588: Don't change PLL rates when setting dclk_vop2_src commit 13b10571cc353448275365ede1a5396d20dfe839 upstream. dclk_vop2_src currently has the CLK_SET_RATE_PARENT flag set, which is very different from dclk_vop0_src or dclk_vop1_src, which don't have it. With this flag in dclk_vop2_src, actually setting the clock then results in a lot of other peripherals breaking, because setting the rate results in the PLL source getting changed: [ 14.898718] clk_core_set_rate_nolock: setting rate for dclk_vop2 to 152840000 [ 15.155017] clk_change_rate: setting rate for pll_gpll to 1680000000 [ clk adjusting every gpll user ] This includes possibly the other vops, i2s, spdif and even the uarts. Among other possible things, this breaks the uart console on a board I use. Sometimes it recovers later on, but there will be a big block of garbled output for a while at least. Shared PLLs should not be changed by individual users, so drop this flag from dclk_vop2_src. Fixes: f1c506d152ff ("clk: rockchip: add clock controller for the RK3588") Cc: stable@vger.kernel.org Tested-by: Quentin Schulz # RK3588 Tiger w/ DP Signed-off-by: Heiko Stuebner Reviewed-by: Quentin Schulz Tested-by: Chris Morgan Link: https://patch.msgid.link/20260304121426.1184680-2-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit cc2941bc37351dca9e744012d63fc3add645798d Author: Stephan Gerhold Date: Mon Jul 6 17:02:09 2026 +0200 clk: qcom: gcc-msm8939: Fix enable_reg for gcc_blsp1_sleep_clk commit fc611445b021262b0d4ace6f716a360663816287 upstream. MSM8939 is similar to MSM8916, where the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-2-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 51b40cb17c216aaa2904059f01408ea705a622d0 Author: Stephan Gerhold Date: Mon Jul 6 17:02:08 2026 +0200 clk: qcom: gcc-msm8916: Fix enable_reg for gcc_blsp1_sleep_clk commit c5339edc6abb601ea10df910ea0b1592fa1016f3 upstream. According to the APQ8016E TRM, the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-1-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 4582949b7badcb91bb537ca522d69b8a35131e72 Author: Martin Blumenstingl Date: Tue Jun 23 22:19:56 2026 +0200 clk: meson: align gxbb_32k_clk_sel number of parents with actual count commit 628b6fee9fca292f12d07f0f1bcf1edefa949d81 upstream. The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c ("clk: amlogic: gxbb: drop non existing 32k clock parent") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future). Fixes: 7915d7d5407c ("clk: amlogic: gxbb: drop non existing 32k clock parent") Reported-by: Christian Hewitt Cc: stable@vger.kernel.org Tested-by: Christian Hewitt Signed-off-by: Martin Blumenstingl Link: https://patch.msgid.link/20260623201956.1324992-1-martin.blumenstingl@googlemail.com Signed-off-by: Jerome Brunet Signed-off-by: Greg Kroah-Hartman commit 88fe6792be2b35a104527c7cffb3bf8f1f70367b Author: Akari Tsuyukusa Date: Fri May 22 22:30:23 2026 +0900 clk: mediatek: mt8196: Select REGMAP_MMIO for vlpckgen commit f63aecdb45e9dd19c340fd62df698374d95b9024 upstream. The MediaTek MT8196 vlpckgen clock driver uses __devm_regmap_init_mmio_clk() by devm_regmap_init_mmio(), which is defined in drivers/base/regmap/regmap-mmio.c. However, the driver's Kconfig entry does not select REGMAP_MMIO. This causes a linker error when REGMAP_MMIO is not enabled. Fix this by selecting REGMAP_MMIO in the Kconfig entry. Fixes: 2f8b3ae6f0cb ("clk: mediatek: Add MT8196 vlpckgen clock support") Cc: stable@vger.kernel.org Signed-off-by: Akari Tsuyukusa Reviewed-by: Brian Masney Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Brian Masney Signed-off-by: Greg Kroah-Hartman commit 05952e503cf65001313386e0804da90adc4da390 Author: Pavel Löbl Date: Fri Jun 5 15:03:40 2026 +0200 clk: clocking-wizard: fix integer overflow in rate calculation commit 4adf593c6fc5aed4639add011f71a074a1bd3966 upstream. When using driver on Zynq-7000 (32-bit) determine_rate calculation overflows. For instance requesting 32MHz with 100MHz parent clock results in 100000000*(4*1000+0) 32-bit multiplication. Replace the expression with mult_frac which is already used in clk_wzrd_recalc_ratef. Cc: stable@vger.kernel.org Fixes: 7681f64e6404 ("clk: clocking-wizard: calculate dividers fractional parts") Signed-off-by: Pale Löbl Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Greg Kroah-Hartman commit 82f78c2b3af8fc9254cb4999bb4e4bed08c5317a Author: Sven Eckelmann Date: Sun Jul 5 22:21:50 2026 +0200 batman-adv: bla: prevent CRC corruptions after claim flush commit 89f3502ff6878798be96461b2eebd64ba3c3874c upstream. When batadv_bla_del_backbone_claims() tried to remove all claims of a backbone, it sets the CRC to 0. It assumes that the it had the last reference of the claims because batadv_claim_release() (which runs after the last reference was released), is XORing the crc16 of the claim address with the backbone CRC. If there would be a parallel holder of any of these references, it could happen that the backbone CRC is (0 ^ crc16(delayed_released_claim)). Which is the wrong starting point for the new claims it may receive when the remote answers the claim request from batadv_bla_send_request(). This reinitializations can be completely dropped to avoid this problem. batadv_claim_release() will take care of fixing the backbone CRC. Cc: stable@vger.kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 871acdf97f64cee8398f72b88b89e8b4f4816dbe Author: Sven Eckelmann Date: Wed Jul 22 12:08:09 2026 +0200 batman-adv: bla: fix freeing of claims on meshif deletion commit 8d128c932bced74e3b1625ba3d7c78ef122a88a7 upstream. When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 1cfa7d5f70d54cb8c7e82df739430782d1996ee1 Author: Sven Eckelmann Date: Mon Jul 6 19:46:37 2026 +0200 batman-adv: dat: avoid unaligned fault in IP extraction commit 0121afa52cdb88cfb4d5d7bd126a23a9100121d8 upstream. Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 5c3a0e553593 ("batman-adv: Distributed ARP Table - add ARP parsing functions") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit c32e5e25c41201c8c3b796a4ab2c45103187091e Author: Sven Eckelmann Date: Thu Jul 9 21:26:13 2026 +0200 batman-adv: mcast: linearize skbuff for packet generation commit 6a30a59e2660afd03c975f1b8eae6a2301161197 upstream. batadv_mcast_forw_packet() and batadv_mcast_forw_scrape() is not only called (indirectly) by the unsharing+linearizing batadv_recv_mcast_packet() handler. When it is called (indirectly) by batadv_mcast_forw_mcsend() then it will be unshared but not linearized. The SKB_LINEAR_ASSERT() can therefore cause a fatal BUG(). The linearization should happen during the expansion of the head because the scrape function can be hit already during the initial batadv_mcast_forw_mode() selection code: * batadv_interface_tx * batadv_mcast_forw_mode * batadv_mcast_forw_mode_by_count() * batadv_mcast_forw_push() -> calls batadv_mcast_forw_expand_head() before everything else * batadv_mcast_forw_push_tvlvs() * batadv_mcast_forw_push_dests() * batadv_mcast_forw_push_adjust_padding() * batadv_mcast_forw_scrape() Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 90039133221e ("batman-adv: mcast: implement multicast packet generation") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit cedacfecf4b4099f8b6f11c178589e379bb53b17 Author: Sven Eckelmann Date: Thu Jul 9 21:17:08 2026 +0200 batman-adv: mcast: ensure unshared skb for multicast packets commit 82bf207f48ebb7a38157f1d91dac884fc9b8cfd8 upstream. When a packet is transmitted via a batman-adv interface and has already enough room for the header then nothing will make sure that the skbuff is unshared. But it is not allowed to modify a currently shared skbuff. Always make sure that the pskb_expand_head() is not only called for a too small header but also for shared skbuffs. Cc: stable@vger.kernel.org Fixes: 90039133221e ("batman-adv: mcast: implement multicast packet generation") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit e91d2cc7441d89a45bad73ad9789159c7441cb80 Author: Zhiling Zou Date: Fri Jul 31 11:18:49 2026 +0800 batman-adv: fix stale receive device on merged fragments commit ad46c907d7d9975a285c1e89a4adde652eaa93f5 upstream. Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown. Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit c8f86e375b39cada09fd8cb33dd3bb3641e84a62 Author: Pengpeng Hou Date: Mon Jul 20 19:57:25 2026 +0800 mtd: rawnand: validate ONFI extended parameter page sections commit e5e415262330bd70f983e091d8919d9dcd99e475 upstream. nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section. Fixes: 6dcbe0cdd83f ("mtd: get the ECC info from the Extended Parameter Page") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 4b282dc6a9e9644c1dbaebcff72c6bca93222392 Author: Pengpeng Hou Date: Wed Jul 8 09:47:12 2026 +0800 mtd: nand: realtek-ecc: add missing MODULE_DEVICE_TABLE() commit 5b2444b4d575d8117809c57801562ef37ca2d4af upstream. The Realtek external ECC engine driver has an OF match table wired into its platform driver, but the table is not exported with MODULE_DEVICE_TABLE(). When the driver is built as a module, the missing OF module alias prevents automatic module loading from the compatible string. Add the missing MODULE_DEVICE_TABLE() entry. Fixes: 3148d0e5b1c5 ("mtd: nand: realtek-ecc: Add Realtek external ECC engine support") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit d06f91a52af11630c9f7e487f6daf242ac310cb8 Author: Xu Rao Date: Mon Jul 13 13:22:03 2026 +0800 mtd: mtdoops: free page bitmap when the backing MTD is removed commit 956e7da12c114f13c63d126ab1d79c3b6a819060 upstream. mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event. Fixes: be95745f0167 ("mtd: mtdoops: keep track of used/unused pages in an array") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 18916f475057cbd2fb8ea6ae86e6b85884ad1d53 Author: Pengpeng Hou Date: Wed Jul 8 09:49:06 2026 +0800 mtd: afs: validate v2 image info bounds commit e9290031f736e99ad17c25c00311c92c266843b7 upstream. The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries. Fixes: b7cf5e2830bb ("mtd: afs: add v2 partition parsing") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Acked-by: Linus Walleij Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit e8bcb9d54429ba22baa504f665c8f6c89f972ca6 Author: Anthony Krowiak Date: Wed Aug 12 16:02:35 2026 -0400 s390/vfio-ap: Fix required lock not held during update of ap_matrix_mdev object commit 5883528250be57fa92270459b33603ff52de0a91 upstream. In the vfio_ap_mdev_cfg_add function, the apm_add, aqm_add and adm_add fields of an ap_matrix_mdev object fields are modified while not holding the matrix_dev->mdevs_lock. This lock must be held while making these to guard against a race condition with another caller that may be concurrently modifying these fields or any of the fields in the matrix_mdev->matrix. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 6d554f2571e6b4db242593ba561efd6a6d1f99a9 Author: Anthony Krowiak Date: Wed Aug 12 16:02:37 2026 -0400 s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap commit bf09b9d7cd7890bc3a3b7eb63d5ece15f88bfde7 upstream. The DECLARE_BITMAP(apm_filtered, AP_DEVICES) macro allocates the bitmap on the stack without zero-initializing it. In vfio_ap_mdev_hot_plug_cfg(), the vfio_ap_mdev_filter_matrix() function is only called to initialize and populate apm_filtered if either filter_adapters or filter_domains is true. If the hot plug configuration change only adds control domains (meaning filter_cdoms is true, but filter_adapters and filter_domains are both false), vfio_ap_mdev_filter_matrix() is bypassed. Consequently, apm_filtered is passed to reset_queues_for_apids() with uninitialized stack garbage. This can cause reset_queues_for_apids() to interpret arbitrary stack garbage bits as valid APIDs to reset, potentially performing unintended guest hardware queue resets. Fix this by zero-initializing the apm_filtered bitmap at the beginning of vfio_ap_mdev_hot_plug_cfg() using bitmap_zero(). Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 69632952aca04caa71e49953b6949fc04e788e67 Author: Anthony Krowiak Date: Wed Aug 12 16:02:39 2026 -0400 s390/vfio-ap: Fix NULL deref in status_show() during queue probe commit dd6f4ef6f8a37412909ad787c837332fb070159c upstream. When vfio_ap_mdev_probe_queue() creates the sysfs attribute group, the queue's driver data has not yet been set. A concurrent read of the 'status' attribute can therefore call dev_get_drvdata() and get NULL, which is then passed directly to vfio_ap_mdev_for_queue() where q->apqn is unconditionally dereferenced, causing a NULL pointer dereference. Fix this by acquiring the update locks before calling sysfs_create_group(). The status_show() function acquires guests_lock before reading the driver data, so any concurrent read will block until after dev_set_drvdata() has been called and the update locks are released. As a bonus, the APQN no longer needs to be read from the queue struct after allocation — it can be read directly from apdev before allocation and stored in a local variable, which is then assigned to q->apqn once the allocation succeeds. Fixes: 260f3ea141382 ("s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 647916988272fe5ecb4bb30cd02b51af9960618a Author: Anthony Krowiak Date: Wed Aug 12 16:02:34 2026 -0400 s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects commit 7fa61c29850d05e40ca9ed41bfdf57673023f581 upstream. In order to traverse or add/remove ap_matrix_mdev objects in the matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held. There are two functions that access the list without holding the mutex: vfio_ap_mdev_probe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock mutex to guard the add of a newly created ap_matrix_mdev object to the matrix_dev->mdev_list. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an ap_matrix_mdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently. The adding of an ap_matrix_mdev object to matrix_dev->mdev_list is now guarded by the matrix_dev->guests_lock which is the correct way to protect against concurrent mdev_list access. Also removed the following two lines of code because the matrix_mdev is allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger and cfg_chg_trigger are already zero-initialised when the struct is allocated before the call to vfio_register_emulated_iommu_dev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace. matrix_mdev->req_trigger = NULL; matrix_mdev->cfg_chg_trigger = NULL; vfio_ap_mdev_for_queue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The status_show function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue function which iterates the matrix_dev->mdev_list to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrix_dev->guests_lock mutex must be held. To fix this, the guests_lock mutex is taken prior to taking the matrix_dev->mdevs_lock mutex in the status_show function. It is taken there rather than the vfio_ap_mdev_for_queue function - where it is needed - because it must be taken prior to the mdevs_lock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevs_lock is needed there to access fields within the matrix_mdev object in that function. See the vfio-ap-locking.rst in the linux kernel tree. Fixes: 2c1ee8983aa3 ("s390/vfio-ap: prepare for dynamic update of guest's APCB on queue probe/remove") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit c45753c32d452d10d8efaeb52587e9e6e8126e33 Author: Anthony Krowiak Date: Wed Aug 12 16:02:38 2026 -0400 s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed commit 917f509bfb88048094dbb85c4e9dbc4d6fe4a886 upstream. The vfio_ap_mdev_hot_unplug_cfg() function uses the return value of bitmap_andnot() to determine whether the guest APCB needs to be updated. However, bitmap_andnot() returns false when the resulting destination bitmap is empty. This means that if the only adapter, domain or control domain assigned to an mdev is removed from the host's AP configuration, the bit is correctly cleared from the shadow APCB, but bitmap_andnot() returns false because the result is an empty bitmap. Consequently, do_hotplug remains 0 and vfio_ap_mdev_update_guest_apcb() is never called, leaving the KVM guest with stale hardware access to the unplugged AP devices. Fix this by replacing the bitmap_andnot() return value check with bitmap_intersects() to determine whether the shadow APCB actually overlaps with the removal mask. If there is an intersection, call bitmap_andnot() solely for its side effect of clearing the bits, then unconditionally set do_hotplug to trigger the guest APCB update. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 178ea7a1c2c3c0c01d14b8f60aa35f1e0cdc6b78 Author: Anthony Krowiak Date: Wed Aug 12 16:02:33 2026 -0400 s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL commit d50346801b4f144e42b49cd4f1496010498ab114 upstream. The ap_driver structure has two fields which are function pointers to callbacks: * .on_config_changed: called at the start of the AP bus scan function to notify the device driver that the host AP configuration has changed and the associated AP devices will be added or removed accordingly. This gives the implementor a chance to evaluate the configuration changes and respond to them before the associated devices are added or removed. * .on_scan_complete: Called at the end of the AP bus scan function to notify the device driver that the host AP configuration has changed and the AP devices have been added or removed accordingly. This gives the implementor the opportunity to respond to the changes after the associated devices are added or removed. These two callbacks are implemented in the vfio_ap device driver via the vfio_ap_on_cfg_changed and vfio_ap_on_scan_complete functions respectively. Within the call stack of these two callback functions the matrix_mdev->kvm->lock mutex is taken without checking whether matrix_mdev->kvm is NULL or not. If matrix_mdev->kvm has never been set, trying to take the lock will trigger a NULL pointer dereference. This patch adds checks for matrix_mdev->kvm == NULL before taking the matrix_mdev->kvm->lock mutex. Note that the matrix_mdev->kvm->lock mutex taken in the vfio_ap_mdev_hot_plug_config function is moved to the calling function along with the matrix_dev->mdevs_lock which is needed there to access the fields of the matrix_mdev. It makes little sense to make the change the check for matrix_mdev->kvm there before taking the kvm->lock mutex only to have to move it out via another patch, so it is done in this patch. It is important to make note of the following: 1. The matrix_dev->guests_lock is acquired at the start of both callback functions. This ensures that matrix_mdev will not be removed via the vfio_ap_mdev_remove function because it too takes matrix_dev_guests_lock before removing the object; so, matrix_mdev will be available for the duration of the callback functions. 2. The matrix_dev->mdevs_lock mutex must be taken in order to access fields within the matrix_mdev structure 3. matrix_mdev->kvm->lock mutex must be taken before the matrix_dev->mdevs_lock to prevent a lockdep splat. 4: The kvm->lock must be held while plugging the guest's AP configuration into its SIE state description via the vfio_ap_mdev_update_guest_apcb function. 5. The vfio_ap_mdev_update_guest_apcb checks matrix_mdev->kvm to verify it is not NULL before doing the hot plug of the guest's AP configuration. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit f7d66afc34bc6e833c8ebe56973afec35f473bc1 Author: Anthony Krowiak Date: Wed Aug 12 16:02:36 2026 -0400 s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove commit 6b8a02e216f6b520cc029e43ddc83956605135d5 upstream. The vfio_ap_config_remove function uses the bitmap_andnot function to clear bits from the matrix_mdev->matrix.adm bitmap (specifies the control domains assigned to the mdev). This prevents the explicitly unplugged control domains from being removed the KVM guest. The bitmap_and function is used instead. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 3c5f51f257e14d657fe2b37e3547dedf3f744e91 Author: Anthony Krowiak Date: Wed Aug 12 16:02:32 2026 -0400 s390/vfio-ap: Fix stale do_remove flag across iterations in vfio_ap_mdev_cfg_remove commit b1f092d94f621307927f145e3cc31893da51fc08 upstream. The do_remove flag in vfio_ap_mdev_cfg_remove() is initialised to zero before the loop that iterates over the list of matrix mdevs, but is never reset at the start of each iteration. Since do_remove is OR-accumulated across iterations, a positive result from one mdev carries over to subsequent mdevs. The fix is to set the do_remove flag with the first call to bitmap_and; for example: do_remove = bitmap_an rather than do_remove |= bitmap_and. Fixes: eeb386aeb5b7 ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit fc069d00a0dbef40042fd681554d48dcd5a1d524 Author: Anthony Krowiak Date: Thu Aug 6 13:34:35 2026 -0400 s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm() commit 4400270ec0348d05dc0439d8f0130853ce7f9e20 upstream. In vfio_ap_mdev_set_kvm(), kvm->arch.crypto.pqap_hook is set to &matrix_mdev->pqap_hook before the update locks are acquired and the mdev list is checked for a conflicting assignment. If another mdev is already attached to the same KVM instance, the function returns -EPERM without restoring the hook pointer, leaving kvm->arch.crypto.pqap_hook pointing at the failing matrix_mdev instead of the mdev that legitimately owns the KVM. Since matrix_mdev->kvm is never set on this error path, vfio_ap_mdev_unset_kvm() will not clean up the hook when matrix_mdev is later closed. If matrix_mdev is subsequently freed, any PQAP instruction executed by the guest will dereference the stale pointer through pqap_hook_rwsem, resulting in a use-after-free. Since kvm->arch.crypto.pqap_hook is only set in the vfio_ap_mdev_set_kvm() function and is cleared in the vfio_ap_mdev_unset_kvm() function, a check for 'kvm->arch.crypto.pqap_hook != NULL' is all that is needed to determine whether it belongs to another mdev. This will alleviate the need to iterate the matrix_dev->mdev_list list to see if the kvm object is assigned to another mdev.This was introduced in v3 to alleviate the need to take the mdevs_lock while iterating the list; however, this did not prevent a potential race condition. The pqap_hook_rwsem(write) is now performed inside get_update_locks_for_kvm(), which is updated to acquire pqap_hook_rwsem(write) between kvm->lock and mdevs_lock. This ordering is consistent with the PQAP intercept path, which acquires pqap_hook_rwsem in read mode while srcu is held under vcpu->mutex, establishing the dependency: kvm->lock -> vcpu->mutex -> srcu -> pqap_hook_rwsem(read). The pqap_hook_rwsem is now released inside the release_update_locks_for_kvm(), which is updated to release pqap_hook_rwsem(write) between mdevs_lock and kvm->lock. Additionally, kvm_put_kvm() in vfio_ap_mdev_unset_kvm() is moved after release_update_locks_for_kvm(). Previously it was called while kvm->lock was held; if it were ever the last reference, kvm_destroy_vm() would run under kvm->lock, which would deadlock. Fixes: 86956e70761b3 ("s390/vfio-ap: replace open coded locks for VFIO_GROUP_NOTIFY_SET_KVM notification") Cc: stable@vger.kernel.org Co-developed-by: Matthew Rosato Signed-off-by: Matthew Rosato Signed-off-by: Anthony Krowiak Acked-by: Christian Borntraeger Signed-off-by: Claudio Imbrenda Message-ID: <20260806173435.105044-1-akrowiak@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 3b90d769b351a9240a2b97de52638d8839d25b80 Author: Sourabh Jain Date: Mon Jul 27 11:04:16 2026 +0530 powerpc/crash: stop watchdogs before booting kdump kernel commit fb43ba4256543ce18ca0540fc37022bda438a293 upstream. On pseries LPAR systems, watchdog timers configured from userspace can remain active after a kernel panic. When a panic triggers kdump, the crashing kernel jumps directly to the kdump kernel without stopping active watchdogs. As a result, the watchdogs remain active after the kdump kernel starts. If dump capture takes longer than the watchdog timeout, PHYP resets the LPAR before the dump is fully captured, causing dump capture to fail. Fix this by issuing the `H_WATCHDOG` hcall during the crash shutdown sequence to stop all active watchdogs before booting the kdump kernel. Cc: stable@vger.kernel.org Fixes: 69472ffa6575 ("watchdog/pseries-wdt: initial support for H_WATCHDOG-based watchdog timers") Reported-by: Mahesh Kumar G Suggested-by: Ritesh Harjani (IBM) Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727053416.276317-4-sourabhjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 36dcb8c2e3391126bb7c9c41b057a3609ea2d4a8 Author: Sourabh Jain Date: Mon Jul 27 11:04:14 2026 +0530 powerpc/pseries: Move H_WATCHDOG definitions to a common header commit 516a254918453ec99660201263d01189c082332c upstream. The H_WATCHDOG input and output definitions are currently local to the pseries watchdog driver. The next patch in this series also needs these definitions to issue H_WATCHDOG hypercalls outside the watchdog driver. Move the H_WATCHDOG definitions to a new common header, asm/papr-watchdog.h, so they can be shared without duplicating the PAPR watchdog definitions. No functional changes. Cc: stable@vger.kernel.org Suggested-by: Ritesh Harjani (IBM) Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727053416.276317-2-sourabhjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit d2be3dd20e8337dc90451c0f298b2d9aa20f0448 Author: Sourabh Jain Date: Mon Jul 27 11:04:15 2026 +0530 powerpc/pseries: Handle and log pseries-wdt registration failures commit e65b526affa621b50646cafdf6b06505af07032e upstream. The pseries watchdog initialization registers the pseries-wdt platform device using platform_device_register_simple(), but currently ignores its return value. Check the returned pointer for errors, log a descriptive error message when registration fails, and propagate the failure code to the caller. This avoids silently ignoring platform device registration failures. Cc: stable@vger.kernel.org Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727053416.276317-3-sourabhjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 9c914b7a0bd18834505c65f22225ce22c152b2d9 Author: Muchun Song Date: Fri Jun 12 11:58:47 2026 +0800 powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population commit 89a4ae32764172468dea303eb6ae90fe6c859712 upstream. vmemmap_populate_compound_pages() uses addr_pfn to determine the PFN offset within a compound page and to decide whether the current vmemmap slot should be populated as a head page mapping or should reuse a tail page mapping. However, addr_pfn is advanced manually in parallel with addr. The loop itself progresses in vmemmap address space, so each PAGE_SIZE step in addr covers PAGE_SIZE / sizeof(struct page) struct page slots. Since addr_pfn is compared against nr_pages in data-PFN units, it should advance by the same number of PFNs. The existing manual increments do not match that and therefore do not reliably track the PFN corresponding to the current addr. As a result, pfn_offset can be computed from the wrong PFN and the code can make the head/tail decision for the wrong compound-page position. Fix this by deriving addr_pfn directly from the current vmemmap address instead of carrying it as loop state. Link: https://lore.kernel.org/20260612035903.2468601-4-songmuchun@bytedance.com Fixes: f2b79c0d7968 ("powerpc/book3s64/radix: add support for vmemmap optimization for radix") Signed-off-by: Muchun Song Acked-by: Oscar Salvador Reviewed-by: Ritesh Harjani (IBM) Cc: "Aneesh Kumar K.V" Cc: David Hildenbrand Cc: Frank van der Linden Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Mike Rapoport (Microsoft) Cc: Nicholas Piggin Cc: Oscar Salvador (SUSE) Cc: Usama Arif Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit da88a2a2119e4fd0e8919a7a2448682f574e1545 Author: Jinjie Ruan Date: Wed Jul 29 09:29:48 2026 +0800 powerpc/kexec_file: Prevent kexec range truncation commit fa40f9dbdd4af53e7445d9135b5b207eb8adf372 upstream. Sashiko AI review pointed out the following issue. The __merge_memory_ranges() function incorrectly handles overlapping memory ranges when merging them. Although sort_memory_ranges() sorts all ranges by their start address in ascending order beforehand, the merge logic remains defective in two ways: 1. It compares the current range's start against the previous element (i-1) instead of the running target index (idx) 2. It unconditionally overwrites 'ranges[idx].end' with 'ranges[i].end'. This logic flaw leads to critical memory truncation when a larger memory range completely subsumes subsequent smaller ranges. For example, consider a sorted input array with three ranges: Range A (idx=0): [0x1000 - 0x9000] Range B (i=1): [0x2000 - 0x5000] (completely inside Range A) Range C (i=2): [0x6000 - 0x8000] (completely inside Range A) 1. When i=1 (Range B): ranges[1].start (0x2000) <= ranges[0].end + 1 (0x9001) is TRUE. The code executes: ranges[0].end = ranges[1].end, which erroneously shrinks Range A's end from 0x9000 down to 0x5000. 2. When i=2 (Range C): ranges[2].start (0x6000) <= ranges[1].end + 1 (0x5001) is FALSE. The code falls into the else block, creating a broken new range. As a result, valid memory fragments [0x5001 - 0x5fff] and [0x8001 - 0x9000] are completely lost from the kexec exclude lists, potentially allowing the crash kernel to overwrite active memory, causing data corruption or crashes. Fix this by ensuring the start of the current range is compared against the end of the active merged range (idx), and use max() to safely prevent the outer boundary from being truncated. Cc: stable@vger.kernel.org Fixes: 180adfc532a8 ("powerpc/kexec_file: Add helper functions for getting memory ranges") Signed-off-by: Jinjie Ruan Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260729012948.2797865-4-ruanjinjie@huawei.com Signed-off-by: Greg Kroah-Hartman commit df45337587db21c502fe5251d3bcc7887428f4fb Author: Jinjie Ruan Date: Wed Jul 29 09:29:47 2026 +0800 powerpc/kexec_file: Fix null-ptr-def in extra size calculation commit 761eda315a6e1fda3e8e2185b28430771fb1ac29 upstream. A static Sashiko AI review identified a potential NULL pointer dereference in kexec_extra_fdt_size_ppc64(). On platforms without any reserved memory regions, get_reserved_memory_ranges() can return 0 while leaving 'rmem' unallocated as NULL. Passing it directly leads to a kernel panic when evaluating 'rmem->nr_ranges'. Add a NULL check for 'rmem' to prevent this crash. Cc: stable@vger.kernel.org Fixes: 0d3ff067331e ("powerpc/kexec_file: fix extra size calculation for kexec FDT") Signed-off-by: Jinjie Ruan Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260729012948.2797865-3-ruanjinjie@huawei.com Signed-off-by: Greg Kroah-Hartman commit 6ae9306c7598184da7b66fdce3c5f47ffa10c277 Author: Helge Deller Date: Sat Aug 15 11:59:20 2026 +0200 parisc: Fix alignment of asm statements in head.S commit 04cf68c9a76e3c6b67ad056a66a14923abf85925 upstream. All assembler statements need to be 4-byte aligned. Prevent a possible misalignment if someone changes the preceeding string and it's length is then suddenly not a multiple of 4 any longer. Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 3e2691eeee83a819125dba3f42c74e1b6730d5cd Author: Pei Xiao Date: Mon Aug 17 11:29:25 2026 +0800 parisc: eisa: Fix infinite loop when parsing invalid IRQ value commit 8b585431a16cfb9d8f2955a9fa0787ce3dceb3c2 upstream. When an invalid value is passed via the "eisa_irq_edge=" kernel command line parameter (e.g. "eisa_irq_edge=16,5"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally. Signed-off-by: Pei Xiao Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 6b1faf1f099f7060b5f1f2f0d024132581f1726e Author: Bryam Vargas Date: Sat Jun 20 16:41:31 2026 -0500 nvdimm/btt: reject an arena whose nfree is below the lane count commit 6a1f2e5ed9267ca19187038ac635393c165213ac upstream. The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant. Fixes: 5212e11fde4d ("nd_btt: atomic sector updates") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Alison Schofield Tested-by: Alison Schofield Link: https://patch.msgid.link/20260620-b4-disp-88b2514b-v1-1-3834e707d232@proton.me Signed-off-by: Alison Schofield Signed-off-by: Greg Kroah-Hartman commit bdd929e60bc54d7756165088a3e1b4ec13ac513e Author: Narek Jilavyan Date: Mon Aug 17 10:34:33 2026 +0000 mm/hugetlb_cgroup: call page_counter_set_max() outside VM_BUG_ON() commit eedc8474d469a2e88f4dc61f8cfe05c147478b43 upstream. hugetlb_cgroup_css_alloc() rounds the counter limit down to a multiple of the huge page size and then applies it inside an assertion: VM_BUG_ON(page_counter_set_max(fault, limit)); VM_BUG_ON(page_counter_set_max(rsvd, limit)); With CONFIG_DEBUG_VM=n, VM_BUG_ON(cond) is BUILD_BUG_ON_INVALID(cond), i.e. ((void)(sizeof((__force long)(cond)))), whose operand is never evaluated. page_counter_set_max() is not a predicate - it performs xchg(&counter->max, nr_pages) - so on every non-debug kernel the limit is never applied and the counters keep page_counter_init()'s PAGE_COUNTER_MAX. That is user-visible, because hugetlb_cgroup_read_u64_max() recomputes the same rounded value and uses equality as its "unlimited" sentinel. PAGE_COUNTER_MAX is LONG_MAX / PAGE_SIZE = 2251799813685247, which is odd, so round_down() really does change it and the two sides disagree. With CONFIG_DEBUG_VM=n: $ cat /sys/fs/cgroup/t/hugetlb.2MB.max 9223372036854771712 and with this patch: $ cat /sys/fs/cgroup/t/hugetlb.2MB.max max A debug option should not change cgroup output. Call the function, then assert the result, as v6.12 did. Use VM_WARN_ON_ONCE() rather than restoring VM_BUG_ON(): the two are identical under CONFIG_DEBUG_VM=n, and checkpatch asks that new code not use BUG() variants. Link: https://lore.kernel.org/20260817103433.191266-1-njilav@gmail.com Fixes: 0e2759afcaf9 ("page_counter: track failcnt only for legacy cgroups") Signed-off-by: Narek Jilavyan Reviewed-by: Muchun Song Cc: David Hildenbrand Cc: Oscar Salvador Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 631d8f39b33e73672d1ff113061984b64ac4f905 Author: Longlong Xia Date: Fri Aug 14 16:30:27 2026 +0800 mm/hugetlb: keep max_huge_pages when dissolving surplus folios commit 267bede12d3b108ca29997ce280e927a570ec97f upstream. dissolve_free_hugetlb_folio() can remove a free folio as surplus when its node has surplus pages. In that case remove_hugetlb_folio() decrements both nr_huge_pages and surplus_huge_pages, leaving the persistent pool size unchanged. Updating max_huge_pages as if a persistent folio had been removed can therefore corrupt the persistent pool target and underflow it when max_huge_pages is zero. Keep max_huge_pages unchanged for surplus folios, including the vmemmap restoration rollback path. Link: https://lore.kernel.org/20260814083027.1419487-1-xialonglong2025@163.com Fixes: cb402bbdabca ("mm/hugetlb: fix surplus pages in dissolve_free_huge_page()") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Longlong Xia Reviewed-by: Muchun Song Cc: David Hildenbrand Cc: Jinjiang Tu Cc: Longlong Xia Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ae6a8b0c69901927de5c4ee16cf1ba1e5960e0bc Author: Wupeng Ma Date: Tue Jul 7 19:02:54 2026 +0800 mm/hugetlb: fix missing migratable flag on same-node hugetlb migration commit 8ee1ef0f2f8ce29338f4ab00a3d344c010208058 upstream. Commit ba23f58de896 ("mm/migrate: don't call folio_putback_active_hugetlb() on dst hugetlb folio") moved setting of the migratable flag and active-list placement from folio_putback_active_hugetlb(dst) into move_hugetlb_state(), so that the freshly allocated destination folio is handled where allocation is known to have succeeded. Unfortunately, the new code was appended after the existing temporary-folio block in move_hugetlb_state(), which contains an early return added earlier by commit 5af1ab1d24e08 ("mm/hugetlb: optimize the surplus state transfer code in move_hugetlb_state()"): if (folio_test_hugetlb_temporary(new_folio)) { ... if (new_nid == old_nid) return; <-- skips the new code ... } /* added by ba23f58 */ folio_set_hugetlb_migratable(new_folio); list_move_tail(&new_folio->lru, ...&h->hugepage_activelist); When the destination folio is temporary (i.e. the hugetlb pool was exhausted and the migration callback fell back to alloc_migrate_hugetlb_folio()) and the migration does not cross a node -- the common case, and always true on a single-NUMA system -- move_hugetlb_state() returns before setting the migratable flag or adding the new folio to the active list. The destination folio is then installed in the page table but cannot be isolated afterwards, since folio_isolate_hugetlb() rejects folios without the migratable flag; a subsequent soft-offline, hard-offline or memory-hotplug offline of that folio fails with -EBUSY. This was reproduced on a single-NUMA arm64 VM: a second MADV_SOFT_OFFLINE on an already-migrated hugetlb page returned EBUSY and logged "hugepage isolation failed". Keep the surplus adjustment, which is the only part that depends on the node crossing, guarded by `if (new_nid != old_nid)', while making the migratable flag and active-list placement unconditional. This preserves the cleanup intent of ba23f58 and closes the early-return hole. Link: https://lore.kernel.org/20260707110254.3147686-1-mawupeng1@huawei.com Fixes: ba23f58de896 ("mm/migrate: don't call folio_putback_active_hugetlb() on dst hugetlb folio") Signed-off-by: Wupeng Ma Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Muchun Song Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8e287f463fc4fc81f1cc6d66db24293ec10c894b Author: caina Date: Fri Aug 21 17:17:20 2026 +0800 Revert "irqchip/mbigen: Fix mbigen node address layout" commit e67091609cf85962f64391c1b0f93d4cbfcd4e22 upstream. This reverts commit 6be6cba9c4371d27f78d900ccfe34bb880d9ee20. Commit 6be6cba9c437 ("irqchip/mbigen: Fix mbigen node address layout") appears to cause a regression on Hi1616. On-board hns NIC has two ports, enahisic2i0 and enahisic2i1, both behind mbigen-v2. Port 0 works; port 1 cannot pass any traffic. Their interrupt pins fall on different mbigen nodes: enahisic2i0: pins 1152-1198 -> all in node 9 enahisic2i1: pins 1200-1246 -> node 9 (1200-1215) + node 10 (1216-1246) (nid = (hwirq - 64) / 128 + 1; pin 1215 = node 9, pin 1216 = node 10) /proc/interrupts shows the break happens exactly at the node boundary: enahisic2i1-rx0 pin 1200 count 102 <- node 9 enahisic2i1-rx5 pin 1215 count 1 <- node 9, last pin enahisic2i1-tx5 pin 1216 count 0 <- node 10, first pin enahisic2i1-rx6 pin 1218 count 0 <- node 10 ...all node 10 pins stay at zero. Port 0 (entirely node 9) is unaffected. Reverting the commit restores normal operation. The commit assumes CLEAR occupies a full 4 KB page at [0xa000, 0xb000) and collides with node 10, so node 10+ gets shifted by 0x1000. But get_mbigen_clear_reg() uses flat, chip-wide addressing -- it never multiplies by the node ID: *addr = (hwirq / 32) * 4 + REG_MBIGEN_CLEAR_OFFSET; /* 0xa000 */ Over the valid hwirq range [64, 1407], CLEAR only spans 0xa008-0xa0af (168 bytes). Node 10's registers are: TYPE: 0xa000-0xa00f (16 B) overlaps CLEAR by 8 B (0xa008-0xa00f) VEC: 0xa200-0xa3ff (512 B) no overlap with CLEAR Shifting the whole page moves VEC from 0xa200 to 0xb200. The hardware reads the event ID from the fixed silicon address 0xa200 on interrupt firing, but software wrote it to 0xb200 -- so the hardware gets an uninitialised value and the interrupt is lost. The only real overlap is 8 bytes of TYPE. It can only trigger when a single mbigen instance has devices on both node 1 (CLEAR 0xa008) and node 10 (TYPE 0xa008). On Hi1616 those nodes are on separate mbigen instances, so it never triggers. Fixes: 6be6cba9c4371d27f78d900ccfe34bb880d9ee20 ("irqchip/mbigen: Fix mbigen node address layout") Suggested-by: Marc Zyngier Signed-off-by: caina Signed-off-by: Thomas Gleixner Acked-by: Yipeng Zou Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260821091720.16665-1-caina@uniontech.com Signed-off-by: Greg Kroah-Hartman commit 6e96e2bb1065bde4e693787ff84c75867fad2c6f Author: Christian Marangi Date: Fri Aug 21 10:52:15 2026 +0200 pmdomain: airoha: fix unselectable AIROHA_CPU_PM_DOMAIN kconfig commit 6d94c47a2e3a38170a0a141547e4c52fbe232cc3 upstream. The AIROHA_CPU_PM_DOMAIN config was wrongly guarded under the Mediatek PM Domains menu and was unselectable. Move it outside the menu so it's now visible and correctly selectable by default on Airoha SoC. Cc: stable@vger.kernel.org Fixes: 82e703dd438b ("pmdomain: airoha: Add Airoha CPU PM Domain support") Signed-off-by: Christian Marangi Reviewed-by: Abel Vesa Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit cf1484d9a75de6809ef331e16f525aaa41b0e16d Author: Shivam Kumar Date: Thu Aug 27 15:24:55 2026 -0400 nvmet-tcp: reject unsolicited H2CData PDUs commit db62b35cbca052860c519cbcabe7650708528738 upstream. nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the "list_add double add" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Cc: stable@vger.kernel.org Reviewed-by: Sagi Grimberg Signed-off-by: Shivam Kumar Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit dbc4acbdb3ca8c81441368ad7409b8f77d4de8f6 Author: Shivam Kumar Date: Fri Aug 14 15:48:11 2026 -0400 nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU commit 14cc5a7e77731497d5bea70f3bb05df7eda982e4 upstream. nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as queue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Shivam Kumar Cc: stable@vger.kernel.org Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 7555ddd60af72df2862dd8f9b730a9848577edda Author: Kazuki Hanai Date: Sun Aug 30 22:11:05 2026 +0900 nvmet-auth: Synchronize timeout work during SQ teardown commit eaa948c0e19b1bb2d93262207bca0c3d19cc3406 upstream. nvmet_auth_sq_free() cancels auth_expired_work with cancel_delayed_work(). If the work has already started, cancellation does not wait for the callback. Transport teardown can consequently free or reuse the queue containing struct nvmet_sq while nvmet_auth_expired_work() still accesses that SQ. Add a teardown-specific helper that synchronously drains the delayed work before freeing authentication state, and use it from nvmet_sq_destroy(). Keep the non-synchronous helper for in-band authentication state cleanup, where the SQ owner remains alive. Fixes: 1a70200f404a ("nvmet-auth: expire authentication sessions") Cc: stable@vger.kernel.org Signed-off-by: Kazuki Hanai Reviewed-by: Sagi Grimberg Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit d663944dbad81bb0e3635d7090db4713e6300858 Author: Tristan Madani Date: Sat Aug 15 00:14:27 2026 +0000 nvme: add missing SRCU grace period in error path commit ef248d5de4469fb6bbaf8dbe0c4c47800080d648 upstream. nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs. The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path. Fixes: ed754e5deeb1 ("nvme: track shared namespaces") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Reviewed-by: Sagi Grimberg Reviewed-by: John Garry Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit b4af7999a998787d5eb6facb5a333e04a4f1d2d9 Author: Yehyeong Lee Date: Tue Aug 18 20:04:05 2026 +0900 nvme-tcp: check the data direction of a C2HData PDU commit f83af377c148f6ad94b41c0e8313f12adf45e1c1 upstream. nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14 Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 7df913a7ced5d7349f0b23bdcf25ad54fe83a1c1 Author: Niklas Cassel Date: Fri Aug 14 16:38:34 2026 +0200 nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails commit 56e6279266f6962bb2d38a54397e3c605165b0c5 upstream. nvmf_create_ctrl() owns the fabrics options and frees them whenever ->create_ctrl() returns an error, so a transport must not free them on its own error paths. nvme-fc tracks this by testing ctrl->ctrl.opts in nvme_fc_ctrl_free(), which requires nvme_fc_init_ctrl() to clear that pointer on every error exit. The coupling is implicit, and commit 1a9e218195a5 ("nvme: split device add from initialization") broke it by adding a second error exit. When nvme_add_ctrl() fails, nvme_fc_init_ctrl() jumps to out_put_ctrl:, past the "ctrl->ctrl.opts = NULL" that only sits on the fail_ctrl: path, so nvme_fc_ctrl_free() frees the options and nvmf_create_ctrl() frees them a second time: BUG: KASAN: slab-use-after-free in nvmf_free_options+0x30/0x190 nvmf_free_options+0x30/0x190 drivers/nvme/host/fabrics.c:1284 nvmf_create_ctrl drivers/nvme/host/fabrics.c:1374 [inline] Freed by task 5534: nvme_fc_ctrl_free drivers/nvme/host/fc.c:2374 [inline] nvme_fc_init_ctrl+0xe17/0x1450 drivers/nvme/host/fc.c:3605 nvme_add_ctrl() fails when dev_set_name() cannot allocate, so this is reachable under memory pressure or fault injection. Without KASAN the options are freed twice. Rather than clear the pointer on the second exit as well, derive ownership the way nvme-tcp, nvme-rdma and nvme-loop do, from list membership: their free_ctrl leaves the options alone unless the controller made it onto the transport list. The list cannot simply be populated on the success path as it is there. nvme-fc runs the initial connect synchronously via flush_delayed_work(), and the controller has to be reachable on rport->ctrl_list for the whole of it: nvme_fc_unregister_remoteport() needs to find it to signal connectivity loss, nvme_fc_match_disconn_ls() matches an incoming Disconnect Association LS against ctrl->association_id, which is only assigned during that window, nvme_fc_resume_controller() needs it on remoteport re-registration, and nvme_fc_existing_controller() uses it to reject a duplicate connect racing the one in flight. Keep the insertion where it is and add a fail_unlist: label, falling into fail_ctrl:, for the error paths that run after it. The earlier error paths never reach the insertion and keep using fail_ctrl: directly, so the list is only touched where the controller is actually on it. nvme_fc_ctrl_free() cannot use the plain "goto free_ctrl" the other transports use, because it still has to put_device(), release the rport reference and free the ida entry for resources taken before the insertion. Sample list_empty() under rport->lock instead. ctrl->ctrl.opts also stays valid for the whole teardown now. That is not the bug being fixed, but it removes some fragility around the old idiom: nvme_free_ctrl() calls nvme_auth_free() before ->free_ctrl(), and ctrl_max_dhchaps() dereferences ctrl->opts without a NULL check when ctrl->dhchap_ctxs is set, which nvme-fc permits since NVMF_ALLOWED_OPTS allows the dhchap options. The nvme sysfs attributes that dereference ctrl->opts, such as hostnqn and address, evaluate their is_visible() test once at device_add() time and stay readable until cdev_device_del(). Fixes: 1a9e218195a5 ("nvme: split device add from initialization") Cc: stable@vger.kernel.org Reported-by: syzbot+f58e57380a6083c4041d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f58e57380a6083c4041d Signed-off-by: Niklas Cassel Tested-by: Rihyeon Kim Reviewed-by: Hannes Reinecke Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 15d7a35a489287109b5a7c157d53d9b8214f0318 Author: Xu Rao Date: Thu Aug 13 16:31:07 2026 +0800 nvme-fabrics: fix DHCHAP secret leak on parse failure commit afdee49a1b88ed9bb44e2b30e855297c169bcc53 upstream. nvmf_parse_options() duplicates dhchap_secret and dhchap_ctrl_secret with match_strdup() before validating the DHHC-1: representation. If validation fails, the parser returns -EINVAL before the temporary string in p is assigned to opts->dhchap_secret or opts->dhchap_ctrl_secret. nvmf_create_ctrl() subsequently frees opts, but nvmf_free_options() cannot release the unassigned temporary string. Each rejected option therefore leaks one allocation. This is easy to miss because valid secrets transfer ownership to opts and are freed normally, while the malformed-secret path still returns the expected -EINVAL to userspace. With CONFIG_NVME_HOST_AUTH enabled, the leak is reachable before the required-option checks and transport lookup. No NVMe-oF target or working transport connection is required; for example, repeatedly writing dhchap_secret=BAD or dhchap_ctrl_secret=BAD to /dev/nvme-fabrics deterministically takes the leaking parse path. Free the temporary string before leaving both validation error paths. Use kfree_sensitive() because the copied option may contain secret material even when its representation is rejected, matching the sensitive cleanup used for stored DHCHAP secrets. Fixes: f50fff73d620 ("nvme: implement In-Band authentication") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Xu Rao Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 7ad2ea7c10044b08ecf7b04376916faf12e17a99 Author: Takashi Iwai Date: Fri Aug 28 13:55:39 2026 +0200 ALSA: pcm: Fix race between non-atomic ops and trigger-start commit acac7b5e07349a9d10d78873afb4b93cd1dc721f upstream. We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running. Reported-by: syzbot+225231fce6755d40d078@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a8f0de8.1d9ded08.62e62.00b5.GAE@google.com Cc: Link: https://patch.msgid.link/20260828115542.3999-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 89992bda7dfbba7ded2ba4185730453c57fa65bc Author: Runyu Xiao Date: Sun Aug 30 14:34:11 2026 +0800 ALSA: harmony: initialize locks before requesting IRQ commit 33abb7491e89285a41565670945293dda841afc4 upstream. snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260830063411.2215691-1-runyu.xiao@seu.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1e67ad10373ea2112310ec525eecba91a292481f Author: HyeongJun An Date: Wed Sep 2 21:50:58 2026 +0900 ALSA: rawmidi: Return the error from snd_rawmidi_input_params() commit f4a23e17d84fd2a152d9e12369761934e1af0ee8 upstream. The snd_rawmidi_input_params() computes err for the three invalid mode combinations and for resize_runtime_buffer(), applies the new framing and clock type only when err is zero, and then returns 0 anyway. A caller that asked for parameters the kernel rejected is told the change succeeded, and the substream keeps its old buffer. The open_mutex conversion turned the early returns into assignments. It handled the output sibling correctly, which still returns err, and left this one behind. Fixes: 94b98194b62e ("ALSA: rawmidi: Take open_mutex around parameter changes") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260902125058.19499-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cd090af03f5dfa137ef2cb460cd131ce913f053f Author: Khushit Shah Date: Mon Aug 31 10:54:44 2026 +0000 arm64: errata: pass REVIDR when matching target implementation CPUs commit 5541432e09dc2031978188f3e8a00b9fc78cf097 upstream. When target implementation CPUs are provided, is_affected_midr_range() accidentally passed the MIDR as both arguments to __is_affected_midr_range(), so the REVIDR mask check operated on the wrong register. Pass REVIDR as intended. Fixes: 86edf6bdcf05 ("smccc/kvm_guest: Enable errata based on implementation CPUs") Cc: stable@vger.kernel.org Signed-off-by: Khushit Shah Reviewed-by: Zenghui Yu (Huawei) Acked-by: Marc Zyngier Reviewed-by: Shameer Kolothum Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 68cbd70795dd8c06e7ccdc4eb0b74c5b180076c3 Author: Karl Mehltretter Date: Fri Aug 28 19:41:31 2026 +0200 arm64: mm: Fix the lockless page-table walk in show_pte() commit a77644d009dece1104b6fcc6e322b0e4503db0d6 upstream. show_pte() walks page tables locklessly and can run with interrupts enabled. A concurrent teardown can free a table page while it is being walked. It can also clear a parent entry after show_pte() checked it; the regular pXd_offset() helpers then reread the cleared entry and can derive a bogus lower-level pointer and fault again. Use the lockless offset helpers with the saved parent entries, as gup_fast() does, and pass the saved PMD to pte_offset_map(). For task page tables, arm64 selects MMU_GATHER_RCU_TABLE_FREE. Disable local interrupts around the walk to hold off RCU-deferred table frees and block the tlb_remove_table_sync_one() IPI until the walk is finished. Place the IRQ guard after the header print. This does not make the output a consistent snapshot, but prevents the task page-table walk from dereferencing a released table page or deriving a pointer from a different parent value. Fixes: 1d18c47c735e ("arm64: MMU fault handling and page table management") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 2b3b06cb709c4bf75a3fe3da3a0ca368ee3b40e5 Author: Ahmad Byagowi Date: Sun Aug 23 09:34:36 2026 -0700 i2c: mux: Fix channel node leak on adapter add failure commit 385c7af4e3b95d0769fd211831674e83b16a2ebf upstream. i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data. Fixes: bc45449b1444 ("i2c/of: Automatically populate i2c mux busses from device tree data.") Signed-off-by: Ahmad Byagowi Cc: # v3.5+ Acked-by: Peter Rosin Signed-off-by: Andi Shyti Link: https://patch.msgid.link/b3e46bbee781b3cb4029aca9a71316cc5e36dc17.1787502619.git.ahmadexp@gmail.com Signed-off-by: Greg Kroah-Hartman commit 112b3d48084c820bbccf41d9783fd122e3ac4cb0 Author: Vasileios Almpanis Date: Wed Aug 12 11:14:48 2026 +0200 i2c: core: fix debugfs UAF on adapter removal commit b15b548d52b43ba8ac4652bc2c7244a8dd1e9622 upstream. i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left. Fixes: 73febd775bdb ("i2c: create debugfs entry per adapter") Reported-by: syzbot+23ad911c819b923238b7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=23ad911c819b923238b7 Signed-off-by: Vasileios Almpanis Cc: # v6.8+ Tested-by: syzbot+23ad911c819b923238b7@syzkaller.appspotmail.com Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260812-i2c-v2-1-5efaab4c3334@gmail.com Signed-off-by: Greg Kroah-Hartman commit 954f30c8df0a07ea11bb93e6378d9ebb88b44b53 Author: Kathiravan Thirumoorthy Date: Wed Aug 12 14:00:55 2026 +0530 i2c: qcom-geni: update frequency table to fix timing parameters commit a4f3fbccb65de757569686baaf2b72e329096aba upstream. In IPQ5424, to meet the setup and hold timing requirements in the standard mode, update the frequency table with the values recommended by HW design team. Also remove the stray space in the I2C_MAX_FAST_MODE_FREQ entry. Fixes: 85c34532849d ("i2c: qcom-geni: fix I2C frequency table to achieve accurate bus rates") Fixes: 506bb2ab0075 ("i2c: qcom-geni: Support systems with 32MHz serial engine clock") Signed-off-by: Kathiravan Thirumoorthy Cc: # v6.13+ Reviewed-by: Mukesh Savaliya Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260812-ipq5424_i2c_scl_updates-v2-1-e09cd39d01d7@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit c643b6e7852e9fa35ebe258d3a14b2e5cb47cafe Author: Hongbo Yao Date: Wed Aug 26 15:05:47 2026 +0800 i2c: designware: Enable interrupt mask workaround for HJMC3001 commit 77549d01edecc20da73c8599e14648877198ce9b upstream. On HJMicro ARM64 servers, the DesignWare I2C controller does not retrigger a pending interrupt if the interrupt status changes after the current status bits have been cleared. The issue is exposed under heavy system load when the corresponding SPI is routed across sockets to a core in the remote socket. The interrupt is then lost and the I2C transfer times out. Enable ACCESS_INTR_MASK for HJMC3001. This toggles DW_IC_INTR_MASK before returning from the interrupt handler and retriggers any pending interrupt. Fixes: 6816ce57c479 ("i2c: designware: Add a new ACPI HID for HJMC01 I2C controller") Signed-off-by: Hongbo Yao Cc: # v6.13+ Acked-by: Mika Westerberg Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260826070547.268672-1-andy.xu@hj-micro.com Signed-off-by: Greg Kroah-Hartman commit 19d65da9f749785a3a4606583174529113f4f058 Author: Sizhe Liu Date: Thu Jul 30 14:27:07 2026 +0800 perf hisi-ptt: Fix PTT trace TLP header parsing commit 2b8a2e5d424f0b3369054305d0bf6a5b9faee6c1 upstream. TLP Headers traced by HiSilicon PCIe tune and trace device (PTT) in 4DW format are shown in the document as below: bits [31:30] [ 29:25 ][24][23][22][21][ 20:11 ][ 10:0 ] |-----|---------|---|---|---|---|-------------|-------------| DW0 [ Fmt ][ Type ][T9][T8][TH][SO][ Length ][ Time ] DW1 [ Header DW1 ] DW2 [ Header DW2 ] DW3 [ Header DW3 ] Problem: The DW0 bit field layout of the hisi_ptt_4dw union does not match the actual bit ordering in little-endian memory, causing incorrect field decoding. Test on Kunpeng 930 SOC, generating data flow with `iperf` commands: - server side: iperf -s - client side: iperf -c $ip_addr -t 30 Trace the TLP headers with hisi_ptt on server side at the same time: perf record -e hisi_ptt12_0/type=4,filter=0x05101,direction=2,format=0/ \ --max-size 50M -o perf.data & The trace aims to capture completion TLPs, learn more in the document: https://docs.kernel.org/trace/hisi-ptt.html Decode perf.data with hisi_ptt decoder: perf report -D The hisi_ptt decoder produces the following result: [...perf headers and other information] . ... HISI PTT data: size 8388608 bytes . 00000000: 68 87 20 94 Format 3 Type 1a T9 0 T8 1 TH 1 SO 1 Length 10 Time 4a1 . 00000004: 40 00 00 00 Header DW1 . 00000008: 40 00 01 51 Header DW2 . 0000000c: 00 00 00 00 Header DW3 [...other hisi_ptt TLP headers] According to PCIe r5.0 sec 2.2.1, the Fmt & Type of Cpl/CplD is supposed to be 8b'00001010' / 8b'01001010' However, the Format & Type decoder analyzing result is 8b'01111010'. It does not match field encodings of any TLP. Correct decoder result should be: [...perf headers and other information] . ... HISI PTT data: size 8388608 bytes . 00000000: 94 20 87 68 Format 2 Type a T9 0 T8 0 TH 0 SO 1 Length 10 Time 768 . 00000004: 00 00 00 40 Header DW1 . 00000008: 51 01 00 40 Header DW2 . 0000000c: 00 00 00 00 Header DW3 [...other hisi_ptt TLP headers] To solve the problem: 1. Drop the union and C bitfield struct, store the raw DW value in a plain uint32_t, and extract the fields with FIELD_GET() against GENMASK/BIT masks declared in the header so they can be reused by other translation units. The masks are portable across endianness and compilers. 2. Print all DW hex values in big-endian byte order for readability, matching the bit field layout shown in the 4DW format diagram. 3. Read the DW value with get_unaligned_le32() instead of an unaligned pointer cast, avoiding both strict-aliasing violations and alignment hazards on hosts that do not support unaligned access. Cc: stable@vger.kernel.org Fixes: 5e91e57e6809 ("perf auxtrace arm64: Add support for parsing HiSilicon PCIe Trace packet") Reviewed-by: James Clark Signed-off-by: Sizhe Liu Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit 2421389840738c782ab70a36c85c21384b817602 Author: Viktor Malik Date: Tue Jul 7 08:52:47 2026 +0200 perf trace: Refactor augmented_raw_syscalls using bpf_for commit ea6992784d65ef2c01f3525217dbf3a44afa9917 upstream. The loop for processing syscall args in augment_raw_syscalls has a history of breaking with Clang updates, see e.g. commit 013eb043f37b ("perf trace: Fix BPF loading failure (-E2BIG)") from Clang 15 to 16. Now, a similar thing happened between Clang 21 and 22. While the issue is mitigated on the main line by a recent verifier update, it remains broken on the 6.12 and 6.18 stable branches: [linux-6.18.y]# sudo perf trace true libbpf: prog 'sys_enter': BPF program load failed: -E2BIG libbpf: prog 'sys_enter': -- BEGIN PROG LOAD LOG -- [...] BPF program is too large. Processed 1000001 insn processed 1000001 insns (limit 1000000) max_states_per_insn 40 total_states 37941 peak_states 232 mark_read 0 -- END PROG LOAD LOG -- libbpf: prog 'sys_enter': failed to load: -E2BIG libbpf: failed to load object 'augmented_raw_syscalls_bpf' libbpf: failed to load BPF skeleton 'augmented_raw_syscalls_bpf': -E2BIG Error: failed to get syscall or beauty map fd [...] The reason is that the loop is quite complex and the BPF verifier often struggles to prove that it terminates. Fix the issue by replacing the standard for loop with the bpf_for macro, which uses a numeric BPF iterator. This should prevent future breakages of this kind since the verifier has a much easier job proving that the loop terminates. Small adjustments were necessary for the loop to make it work. The main problem is that the verifier sometimes has problems with bpf_for loops that use a carry-over state, such as the `payload_offset` and `output` vars here, since the verifier tries to track their values too precisely and cannot prove loop convergence. To resolve the issue, we (1) explicitly recompute `payload_offset` in every iteration and (2) use a trick with adding a global zero to `output` to help the verifier forget its precise state and use a range instead. Finally, to keep backwards compatibility with older kernel versions that don't have bpf_for (i.e. numeric iterators), fall back to standard loop. Signed-off-by: Viktor Malik Cc: stable@vger.kernel.org Suggested-by: Andrii Nakryiko Fixes: a68fd6a6cdd3 ("perf trace: Collect augmented data using BPF") Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit f3a6663138496a66f90636f6917d42fb19f701b6 Author: Viktor Malik Date: Tue Jul 7 08:52:46 2026 +0200 perf trace: Factor out BPF loop body commit acff3e1a9cc29a6a039b76b81a438c56016bc0e3 upstream. The BPF program in augmented_raw_syscalls uses a for loop to iterate all syscall arguments. The loop body is quite complex and often poses problems for the BPF verifier. As a preparation step for addressing this issue, factor out the loop body into a separate function. Signed-off-by: Viktor Malik Cc: stable@vger.kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit 3c492c8eba02698ca893a9a13388d2adf6dfb839 Author: Dapeng Mi Date: Tue Jun 16 12:46:50 2026 +0800 perf/x86/intel: Fix kernel address leakages in LBR stack commit e2b0575900ff72aa82748af96e7bd564ade5157a upstream. Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks. Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR") Reported-by: Ian Rogers Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260616044654.3468742-5-dapeng1.mi@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 267f0a4fb9fe7fa35fb15f8e1fecc472b2b952d9 Author: Lad Prabhakar Date: Fri Aug 21 22:10:21 2026 +0100 rtc: rzn1: Disable alarm interrupt before reprogramming alarm registers commit 51458d5b0a1cfb1b6013400abc95aadf16ed2a57 upstream. rzn1_rtc_set_alarm() updates RZN1_RTC_ALM, RZN1_RTC_ALH and RZN1_RTC_ALW using separate MMIO writes without first disabling the alarm interrupt. If a previous alarm is still enabled, the interrupt can fire while the alarm registers contain a mixture of old and newly written values. Fix this by disabling the alarm interrupt before reprogramming ALM, ALH and ALW with a call to rzn1_rtc_alarm_irq_enable(). Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-7-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 3a2b79eae5bef7bcf560fee36e4686a0ba27caf6 Author: Lad Prabhakar Date: Fri Aug 21 22:10:19 2026 +0100 rtc: rzn1: Handle unset alarm weekday in rzn1_rtc_read_alarm commit 457b5dbce31209e65e1184716ed3af59cb1c0372 upstream. RZN1_RTC_ALW is a weekday bitmask where bit N represents weekday N. When no alarm has been configured, the register has its power-on-reset value of zero. rzn1_rtc_read_alarm() uses fls() to convert the weekday bitmask into a weekday number. When RZN1_RTC_ALW is zero, fls(0) returns zero and fls(wday) - 1 evaluates to -1. This invalid weekday is then used to calculate the alarm date and can either leave tm_wday set to -1 or produce a fabricated alarm date. Treat a zero RZN1_RTC_ALW value as an unset alarm weekday and return without calculating the alarm date. Move reading RZN1_RTC_CTL1 before this check so that alrm->enabled is updated for both configured and unconfigured alarms. Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit a4d6666a65d6f2ffd0537ec53576aa662e5c84c1 Author: Lad Prabhakar Date: Fri Aug 21 22:10:18 2026 +0100 rtc: rzn1: Fix weekday underflow when alarm crosses month boundary commit 022a2839a52006531804a8db55d3228084400b48 upstream. rzn1_rtc_set_alarm() calculates the alarm weekday from the difference between the alarm day and the current day of the month. When the alarm crosses a month boundary, this difference can become negative. Since days_ahead is unsigned, it underflows and results in an incorrect weekday being programmed into RZN1_RTC_ALW. The RTC core already provides a fully populated struct rtc_time for the alarm, including the correct tm_wday. Use tm->tm_wday directly instead of recalculating the weekday from the day-of-month. This avoids the underflow and ensures alarms scheduled across a month boundary use the correct weekday. Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Suggested-by: Wolfram Sang Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 350cb7821b3d2c4bd1dfcceb64ace82405c25f0f Author: Lad Prabhakar Date: Fri Aug 21 22:10:17 2026 +0100 rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt commit 708546aa39560a11cf44c7ba99492c8395a6c2fb upstream. Check for -EPROBE_DEFER from platform_get_irq_byname_optional() and handle the deferred probe request properly. Although the "pps" interrupt is optional, an error code of -EPROBE_DEFER indicates that the interrupt subsystem is not yet ready. Intercept this specific error condition, assign it to the return value, and jump to the dis_runtime_pm label to avoid ignoring a valid probe deferral. Fixes: eea7791e00f33 ("rtc: rzn1: implement one-second accuracy for alarms") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 0a90e268cce7023f34087bfa4affb42e29ff5f45 Author: Shakeel Butt Date: Tue Aug 11 13:31:55 2026 -0700 memcg: make the v1 soft limit knob inert commit a3417097fb107cea3358b19bcbb4eb655fd67f8c upstream. The v1 soft limit has been deprecated since v6.12 and nobody has reported depending on it. Start the removal by decoupling the interface from the implementation: keep memory.soft_limit_in_bytes, but ignore writes to it and always report the maximum value on read similar to what memory.kmem.limit_in_bytes already does. Writes are still parsed, so malformed input keeps returning -EINVAL. The knob now also behaves the same everywhere: it used to return -EOPNOTSUPP on PREEMPT_RT, where soft limit reclaim has always been disabled. This also fixes the syzbot report linked below. Soft limit reclaim is the only caller that runs shrink_lruvec() from kswapd against a specific memcg, so it is the only way to reach lru_gen_shrink_lruvec() and in turn set_mm_walk(), which warns when called from kswapd. Link: https://lore.kernel.org/20260811203203.3456029-2-shakeel.butt@linux.dev Signed-off-by: Shakeel Butt Reported-by: syzbot+12ee2725d5fde63a9c96@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a7a6929.b50370da.49fe0.005e.GAE@google.com/ Acked-by: Michal Hocko Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Johannes Weiner Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 801bcbdbfd595cc7f0de95f2802b5596c8971315 Author: Shakeel Butt Date: Tue Jul 28 19:46:12 2026 -0700 memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done commit 6b0d1083364fc8e7cc2f7d1f93ee3ee78f4d52f7 upstream. At Meta, we are seeing instances where an OOM killed job is stuck in the exit path for several hours. In one particular case, the job was stuck for more than 8 hours and I had to manually remove the memory.max limits to allow the process to exit. The job was a single process job and had ~55 GiB memory.max and zswap enabled. It had almost 0 anon in memory and ~111 GiB in zswap compressed to ~51 GiB zswap pool (i.e. almost all of memory.current was zswap). Nothing was left on the LRUs to reclaim. On further inspection, I observed ~20k threads of that process stuck with the following stack: [<0>] mem_cgroup_out_of_memory+0x4e/0xa0 [<0>] charge_memcg+0x8bf/0x990 [<0>] mem_cgroup_swapin_charge_folio+0x4e/0x80 [<0>] __read_swap_cache_async+0x10c/0x260 [<0>] swapin_readahead+0x116/0x3f0 [<0>] do_swap_page+0x13c/0x1ce0 [<0>] handle_mm_fault+0x61d/0x11f0 [<0>] do_user_addr_fault+0x3e7/0x6d0 [<0>] exc_page_fault+0x8f/0x110 [<0>] asm_exc_page_fault+0x22/0x30 [<0>] __get_user_8+0x14/0x20 [<0>] futex_cleanup+0x27/0x1c0 [<0>] futex_exit_release+0x47/0x60 [<0>] do_exit+0x107/0x940 [<0>] do_group_exit+0x81/0xa0 [<0>] get_signal+0x2b1/0x6e0 [<0>] arch_do_signal_or_restart+0x1a/0x1c0 [<0>] exit_to_user_mode_loop+0xa8/0x1c0 [<0>] do_syscall_64+0x152/0x250 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 In addition the dmesg was filled with "Out of memory and no killable processes..." messages. I have no idea why oom reaper was not able to reap/unmap the process. My guess is that since oom reaper tries to acquire mmap_lock in read mode limited number of times and then gives up, there might be a thread of that process which had mmap_lock in write mode at that time. My initial suspicion was the futex_cleanup and kernel page fault causing infinite fault and charge retries but that was put to rest in previous discussions happened on similar problem [1]. My current theory is that it is just a simple slow serialization behind the oom_lock. Unlike page allocator, memcg charge code takes the oom_lock without the "try". Though memcg oom code uses mutex_lock_killable(), note that in the call stack get_signal() consumes SIGKILL (or sigdelset(SIGKILL)) before calling do_group_exit(). So this mutex_lock_killable() is just a mutex_lock() here. Therefore 10s of thousands of threads are waiting on oom_lock and one by one they get -EFAULT from get_user() in the futex cleanup code and bails out. Discussion from [1] led to commit a75ffa26122b ("memcg, oom: do not bypass oom killer for dying tasks") which routes dying tasks into the OOM path precisely so the oom_reaper can reap their mm and free the memory asynchronously. But the reaper is best-effort and one-shot: if it cannot take mmap_lock for read (e.g. a sibling thread holds it for write) it sets MMF_OOM_SKIP and never retries, leaving only the glacial oom_lock-serialized synchronous drain. Once MMF_OOM_SKIP is set there is no more asynchronous reclaim coming for the mm, so a dying task charging against it has nothing left to wait for: it frees its memory only once it finishes exiting. Running reclaim and the (no-victim) OOM killer for it is then pointless, and doing it for 10s of thousands of exiting threads is what serializes them behind oom_lock. So before reclaim, if current is an OOM victim whose reaper is done, fail the charge. Reproduced with 20k threads, each parking a robust futex head on its own zswapped page, OOM-group-killed while a sibling holds mmap_lock for write so the reaper gives up and sets MMF_OOM_SKIP. Tested on next-20260728 and baseline show ~90 seconds exit time while with the patch the exit time reduced to ~3 seconds. Link: https://lore.kernel.org/20260729024612.3369005-1-shakeel.butt@linux.dev Link: https://lore.kernel.org/7a4e5591f45df455e6a485fc5400989569d3d22d.camel@surriel.com/ [1] Signed-off-by: Shakeel Butt Acked-by: Johannes Weiner Acked-by: Michal Hocko Cc: David Rientjes Cc: Muchun Song Cc: Nhat Pham Cc: Rik van Riel Cc: Roman Gushchin Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7269bd95d707e26da9ec343ccf20cbdb06d1933e Author: Pengpeng Hou Date: Mon Apr 6 21:52:34 2026 -0700 Input: aiptek - validate raw macro indices before updating state commit 95dffe32a66cbed07fbfa7afed39d56d5014e04f upstream. aiptek_irq() derives macro key indices directly from tablet reports and then uses them to index macroKeyEvents[]. Report types 4 and 5 also save the derived value in aiptek->lastMacro and later use that state to release the previous key. Validate the raw macro index once before it enters that state machine, so lastMacro only ever stores an in-range macro key. Keep direct bounds checks for report type 6, which reads the macro number from the packet body and uses it immediately. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260329001711.88076-1-pengpeng@iscas.ac.cn [dtor: fix macro fallback in report 5s to use -1] Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d07e281f2a7710502985d6f80b95ddac8f4e81d5 Author: HE WEI（ギカク） Date: Wed Jun 10 09:29:29 2026 +0900 fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list() [ Upstream commit 7c4841e2a62794a3bab7c1ff0540580f387e377f ] ni_create_attr_list() allocates a fixed buffer of al_aligned(record_size) (== record_size) bytes and then walks every attribute of the primary MFT record, writing one ATTR_LIST_ENTRY per attribute and advancing the cursor by le_size(name_len), with no check against the end of the buffer; the total size is only computed after the loop. A minimum-size resident attribute occupies SIZEOF_RESIDENT (0x18 = 24) bytes on disk, but an unnamed attribute expands to le_size(0) (0x20 = 32) bytes in the list. Because the number of attributes in a record is not bounded (mi_enum_attr() accepts arbitrarily many equal-type, nameless minimum-size attributes), a crafted record packed with such attributes produces a list larger than record_size and overflows the heap buffer. This is reachable from a crafted, loop-mounted NTFS image: opening the file and adding an attribute (e.g. via setxattr) drives ntfs_set_ea() -> ni_insert_resident() -> ni_insert_attr() -> ni_ins_attr_ext() -> ni_create_attr_list(). BUG: KASAN: slab-out-of-bounds in ni_create_attr_list+0xc48/0x1058 Write of size 4 at addr ffff000008984c00 by task setfattr/345 ni_create_attr_list+0xc48/0x1058 ni_ins_attr_ext+0x510/0x7c0 ni_insert_attr+0x3f8/0x70c ni_insert_resident+0xc8/0x3b0 ntfs_set_ea+0x66c/0xd28 ntfs_setxattr+0x4d8/0x5b0 __arm64_sys_setxattr+0xa4/0x124 Allocated by task 345: ni_create_attr_list+0x188/0x1058 The buggy address belongs to the cache kmalloc-1k of size 1024 (the write lands at object+1024). Size the buffer from the actual attributes instead of assuming a single record_size is always enough. Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: HE WEI（ギカク） Signed-off-by: HE WEI（ギカク） Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 4d6ccd3883df6df1e33229d22d02b8c0dbfcb98a Author: Nirbhay Sharma Date: Tue Oct 7 04:08:04 2025 +0530 fs/ntfs3: fix KMSAN uninit-value in ni_create_attr_list [ Upstream commit 5f33da04e6ceee849e76e6592cc283c72fef7af9 ] The call to kmalloc() to allocate the attribute list buffer is given a size of al_aligned(rs). This size can be larger than the data subsequently copied into the buffer, leaving trailing bytes uninitialized. This can trigger a KMSAN "uninit-value" warning if that memory is later accessed. Fix this by using kzalloc() instead, which ensures the entire allocated buffer is zero-initialized, preventing the warning. Reported-by: syzbot+83c9dd5c0dcf6184fdbf@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=83c9dd5c0dcf6184fdbf Signed-off-by: Nirbhay Sharma Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 0ceda28f371df9e0bbdaa29214f71fe8298f23d8 Author: Eric Dumazet Date: Fri Aug 21 17:04:07 2026 +0000 mm/mempolicy: fix sleeping allocation in alloc_pages_bulk_weighted_interleave() commit 540e583b66d6402bf556fde5e53c817a54c1afe5 upstream. syzbot reported a sleeping function called from invalid context splat in bucket_table_alloc(). When rhashtable_insert_slow() rehashes the table under rcu_read_lock(), it calls bucket_table_alloc(..., GFP_ATOMIC | __GFP_NOWARN). If the bucket table allocation uses vmalloc, __vmalloc_node_range_noprof() invokes vm_area_alloc_pages() -> alloc_pages_bulk_mempolicy_noprof() with the passed GFP_ATOMIC flags. If the current task has an MPOL_WEIGHTED_INTERLEAVE mempolicy, alloc_pages_bulk_weighted_interleave() is called and currently hardcodes GFP_KERNEL when allocating the temporary weights array, triggering a might_alloc() splat in atomic/RCU contexts. Pass the gfp flags (masked with GFP_RECLAIM_MASK to strip page-allocator zone modifiers like __GFP_HIGHMEM) received by alloc_pages_bulk_weighted_interleave() to kmalloc() instead of hardcoding GFP_KERNEL. Since the weights buffer is immediately initialized in full, kmalloc() is sufficient. Link: https://lore.kernel.org/20260821170407.3721004-1-edumazet@google.com Fixes: fa3bea4e1f82 ("mm/mempolicy: introduce MPOL_WEIGHTED_INTERLEAVE for weighted interleaving") Signed-off-by: Eric Dumazet Reported-by: syzbot+0dbf6d295b3350944f0b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/6a88837e.ae6ddae5.3da009.0040.GAE@google.com/T/#u Reviewed-by: Andrew Morton Reviewed-by: Gregory Price (Meta) Acked-by: David Hildenbrand (Arm) Cc: Alistair Popple Cc: Byungchul Park Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5da247e4d1e8661d4d6f997101d59967e8994e32 Author: Masami Hiramatsu (Google) Date: Sun Aug 30 23:27:23 2026 +0900 kprobes: Protect kprobe_blacklist with RCU commit 0c4256196b3a105307e2235fbfd85e768bbcdd0f upstream. __within_kprobe_blacklist() traverses kprobe_blacklist without holding kprobe_mutex. When a module is unloaded, kprobe_remove_area_blacklist() removes blacklist entries and immediately frees them with kfree(). A concurrent call to within_kprobe_blacklist() can therefore dereference freed memory. Furthermore, within_kprobe_blacklist() can be called in atomic or non-preemptible contexts where the sleeping kprobe_mutex cannot be taken. Protect kprobe_blacklist with RCU. Use guard(rcu)() and list_for_each_entry_rcu() for traversal, list_add_tail_rcu() for insertions, list_del_rcu() for deletions, and kfree_rcu() to reclaim entries safely after a grace period. Link: https://lore.kernel.org/all/178810004323.64882.16493230858653316962.stgit@devnote2/ Fixes: 376e242429bf ("kprobes: Introduce NOKPROBE_SYMBOL() macro to maintain kprobes blacklist") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260807155802.F06041F000E9@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.7-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 863f6726a5c02a309b8cfcb1e1be5c8b1dd7b59a Author: Ju Nan Date: Fri Aug 21 10:47:57 2026 +0800 irqchip/stm32mp-exti: Fix the unit of the hwspinlock timeout commit d31fbbade43f880b7e59e2b3a72722fe2725d93f upstream. HWSPNLCK_TIMEOUT is passed to hwspin_lock_timeout_in_atomic(), whose timeout argument is in milliseconds, not microseconds: atomic_delay += HWSPINLOCK_RETRY_DELAY_US; if (atomic_delay > to * 1000) return -ETIMEDOUT; So stm32mp_exti_set_type() asks for a 1 second timeout where the comment next to the macro says it wants 1 millisecond. The semaphore is polled with udelay() from a section that holds chip_data->rlock, a raw_spinlock_t, so preemption stays disabled for the whole wait on every configuration, PREEMPT_RT included. The hwspinlock core documents this explicitly: If the mode is HWLOCK_IN_ATOMIC (called from an atomic context) the timeout is handled with busy-waiting delays, hence shall not exceed few msecs. Fixes: 5257169ade8c ("irqchip/stm32-exti: Use the hwspin_lock_timeout_in_atomic() API") Signed-off-by: Ju Nan Signed-off-by: Thomas Gleixner Reviewed-by: Radu Rendec Reviewed-by: Antonio Borneo Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260821024756.24927-2-junan76@163.com Signed-off-by: Greg Kroah-Hartman commit f8a2f2a4602318eb93d49d27fd0d0fdaab17edde Author: Bradley Morgan Date: Thu Aug 27 17:43:38 2026 +0000 ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() commit 8861f6d5c0678a7c5089c7b272509fc5931b8437 upstream. dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing. Fixes: 4f2946aa0c45 ("IMA: introduce a new policy option func=SETXATTR_CHECK") Cc: stable@vger.kernel.org Reported-by: syzbot+5ebeb3089ea6439c37be@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/6a8f89e5.1d9ded08.62e62.00bf.GAE@google.com/ Signed-off-by: Bradley Morgan Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 685c195fbd7d4c4af3234ac31276640d96888e32 Author: Hajo Noerenberg Date: Mon Aug 31 14:43:03 2026 +0200 ata: ahci: work around lost interrupts on Marvell 88SE61xx commit dc3565a4ae538e584e5e63b3b3cd1eaf502593c1 upstream. ahci_single_level_irq_intr() services the ports first and clears the global HOST_IRQ_STAT afterwards, as recommended by AHCI 1.1 section 10.6.2. The Marvell 88SE6111/6121/6145 family stops reporting interrupts for a port when HOST_IRQ_STAT is cleared while PxIS still holds bits: PxIS keeps its content, HOST_IRQ_STAT reads back as 0, the port is never looked at again, and the command in flight only ends in a timeout. Measured on a Seagate Blackarmor NAS440 (Marvell 88F6281 Kirkwood, 88SE6121 rev B2 behind PCIe) by polling the AHCI registers from userspace while an IDENTIFY was outstanding: t=303.046 irqs 127 PxIS 0x00000000 PxCI 0x00000001 IDENTIFY issued t=303.057 irqs 128 PxIS 0x00000020 PxCI 0x00000000 CI cleared, DPS set, one interrupt taken ... PxIS stays 0x00000020, HOST_IRQ_STAT stays 0 ... t~308.05 qc timeout after 5000 msecs The command had completed - PxCI was clear and PxIS had DPS set - so ahci_qc_complete() would have completed it. It never got the chance because the handler read HOST_IRQ_STAT as 0 and returned IRQ_NONE. Marvell's own driver for these chips clears the two registers in the opposite order and says so ("clear global before channel"), and ahci_xgene handles its broken edge latch the same way. Since the reordering costs at most one spurious interrupt per valid one on conforming controllers, do it in a private interrupt handler selected for board_ahci_mv instead of changing libahci for everyone. With this applied, SATA-2 and SATA-3 disks work at 3.0 Gbps on the 88SE6121 without the drive-side 1.5 Gbps jumper that was needed before. Time from link up to a successful IDENTIFY: WDC WD5000AADS-00S9B0 port 0 7 ms (never identified before) WDC WD3202ABYS-01B7A0 port 1 28 ms WDC WD30EFRX-68EUZN0 port 1 200 ms (3 TB, HPA detection ok) Only the 88SE6121 was tested; board_ahci_mv also covers the 88SE6145, which Marvell's driver treats identically. Fixes: cd70c26617f4 ("[libata] AHCI: Add support for Marvell AHCI-like chips (initially 6145)") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-ide/db6b48b7-d69a-564b-24f0-75fbd6a9e543@noerenberg.de/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=216094 Signed-off-by: Hajo Noerenberg Reviewed-by: Damien Le Moal Acked-by: Pali Rohar Link: https://lore.kernel.org/r/20260831124303.920391-1-hajo-linux-ide@noerenberg.de Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit ca5bfea2045ef2eb3305cf2a9d8da549b76c37d3 Author: Max Kellermann Date: Mon Aug 24 18:47:07 2026 +0200 ceph: lock mutex in ceph_mds_check_access() commit a61c6ae1dae2611082b831b4aaa780878099c012 upstream. MDS session OPEN handling replaces mdsc->s_cap_auths under mdsc->mutex, freeing the previous array and its strings. ceph_mds_check_access() traverses this array without holding the mutex. A concurrent session reopen can therefore free the array while it is being inspected, resulting in a use-after-free like this: Unable to handle kernel paging request at virtual address 003aaad64b2c8bb9 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 56 UID: 2953037534 PID: 1253231 Comm: php-cgi8.4 Not tainted 6.18.45-i2-ampere #1146 NONE [..] pc : ceph_mds_check_access+0xd4/0x550 lr : ceph_mds_check_access+0xc8/0x550 [...] Call trace: ceph_mds_check_access+0xd4/0x550 (P) ceph_atomic_open+0x138/0xbe8 path_openat+0xa24/0xfa8 do_filp_open+0x94/0x158 do_sys_openat2+0x88/0xf8 Cc: stable@vger.kernel.org Fixes: 596afb0b8933 ("ceph: add ceph_mds_check_access() helper") Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit a24a146ae2cb5d9faeea96d10010fcb6579abe1f Author: Hui Su Date: Fri Aug 7 01:56:00 2026 +0800 bpf: Fix infinite loop in pcpu_freelist push with one possible CPU commit efebf6496685c93150df5bb0794363ae70c5f58a upstream. __pcpu_freelist_push() can loop forever when only one CPU is possible and an NMI re-enters pcpu_freelist_push() while the interrupted context holds that CPU's freelist lock. After the current-CPU fast path fails, the fallback loop walks cpu_possible_mask while skipping the current CPU. With CONFIG_SMP=n, or when an SMP kernel is limited to one possible CPU with nr_cpus=1 or possible_cpus=1, there are no other possible CPUs to examine. The loop therefore makes no lock acquisition attempt and can never make progress. The following stack was observed on a UP system: NMI context: pcpu_freelist_push free_htab_elem htab_map_delete_elem [perf-event BPF program] __perf_event_overflow perf_event_nmi_handler exc_nmi Interrupted context: __pcpu_freelist_push pcpu_freelist_push free_htab_elem htab_map_delete_elem [raw_tp/sys_enter BPF program] __bpf_trace_sys_enter do_syscall_64 raw_res_spin_lock() detects the same-CPU recursive acquisition and returns -EDEADLK, but the subsequent fallback loop has no candidate head on a system with one possible CPU. Restore the extra fallback head that existed before the rqspinlock conversion. Keep the current-CPU fast path, then try the other possible CPUs and finally the extra head. The additional head lets a push, which cannot fail without losing a preallocated element, make progress when the only per-CPU head is held by the interrupted context. Also check the extra head from the pop path so that nodes placed there can be reused. Fixes: f2ac0e5d1c4d ("bpf: Convert percpu_freelist.c to rqspinlock") Signed-off-by: Hui Su Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260806175600.1993595-1-sh_def@163.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Greg Kroah-Hartman commit bfb469f20aa9ecad5fc9b42a5046d7ca360a863c Author: Damien Le Moal Date: Mon Aug 31 11:50:50 2026 +0900 block: flag zoned disks with GENHD_FL_NO_PART commit 3f9c7a108c0e8f14425384912017071b71341e3b upstream. Zoned block devices do not support partitions. However, the partition table is nevertheless still inspected, and any partition found ignored with a warning in add_partition(). While this is generally not a problem, and in fact beneficial to the user as it indicates an invalid use of a zoned block device, scanning for a partition table on the device may result in issuing read operations to offline zones (e.g. after a disk head is depopulated for disks that support head management operations). Since partitions are ignored anyway, completely disable partition scanning for zoned gendisks by setting the flag GENHD_FL_NO_PART in __add_disk(). The existing check in add_partition() is left as-is to ensure that we still get a warning if for whatever reason, despite GENHD_FL_NO_PART, we still endup trying to add partitions. Flagging zoned disks with GENHD_FL_NO_PART also has the benefit to expose through sysfs the ext_range attribute with the value of 1 instead of the default DISK_MAX_PARTS, thus correctly advertizing the fact that zoned disks do not support partitions. Fixes: 5eac3eb30c9a ("block: Remove partition support for zoned block devices") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Bart Van Assche Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260831025050.667758-1-dlemoal@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 634e2d23736d4ded7c0667d686d49036b81cb5bf Author: Ulf Hansson Date: Wed Aug 26 10:45:32 2026 +0200 cpuidle: psci: Fix support for probe deferral by dropping the faux device commit 0606f2114e2dc88fe293858fd991cda2688b8c3a upstream. At the conversion to the faux driver/device we broke the support for probe deferral. In hindsight, the move to the faux device seems questionable, as it simply makes the code more complicated and for no good reason. To fix the support for the probe deferral let's therefore restore the old code and drop the faux device. Fixes: af5376a77e87 ("cpuidle: psci: Transition to the faux device interface") Fixes: 5836ebeb4a2b ("cpuidle: psci: Avoid initializing faux device if no DT idle states are present") Fixes: 39cdf87a97fd ("cpuidle: psci: Fix uninitialized variable in dt_idle_state_present()") Cc: stable@vger.kernel.org Reviewed-by: Abel Vesa Signed-off-by: Ulf Hansson Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit b519dfce1998c323e54a56f911cf708d9ba0e076 Author: Linkai Gong Date: Fri Aug 21 15:57:28 2026 +0800 cpuidle: dt_idle_genpd: kfree() the original name allocation commit 2b0ac85512b7f67479127b2713254490662eb13d upstream. dt_idle_pd_alloc() kasprintf()s the full node path, then points pd->name at kbasename() of that string. dt_idle_pd_free() kfree()s pd->name, which is no longer the start of the allocation. Copy the basename instead. Fixes: 9d976d6721df ("cpuidle: Factor-out power domain related code from PSCI domain driver") Signed-off-by: Linkai Gong Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit fac202d73e7a649b7d4010325c6c6dcd9334fe65 Author: Koichiro Den Date: Tue Jul 21 15:28:05 2026 +0900 dmaengine: dw-edma: Initialize IRQ data before requesting IRQs commit 647217abea849d3d45f8cb0b8ee5b78d50f26985 upstream. dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260721062815.4117887-5-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 8fd47ccbba86c283ce1175bb2096df2abfa26586 Author: Koichiro Den Date: Sat Jul 18 03:06:34 2026 +0900 dmaengine: dw-edma: Complete descriptors before pausing commit c154060016a9db2ac889bfdb0a3c1322f9be8ded upstream. If PAUSE is requested while the final burst of a descriptor is in flight, the DONE interrupt takes the PAUSE path without checking whether the descriptor has been depleted. The depleted descriptor remains on the issued list and the channel enters EDMA_ST_PAUSE. On resume, dw_edma_start_transfer() can select that depleted descriptor again even though no burst remains, leaving the channel in an invalid busy state. Check for descriptor completion before acknowledging PAUSE. If there is no work to start on resume, leave the channel idle. Also ignore DONE interrupts while the channel is paused so a stale or repeated interrupt cannot change its state or start queued work. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-5-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 3b313f7a00d146108708631398c85b96b1788789 Author: Koichiro Den Date: Sat Jul 18 03:06:31 2026 +0900 dmaengine: dw-edma: Fix HDMA channel status register access commit ef1b080e03acc83d5bde841da67036985acd50dc upstream. GET_CH_32() takes the direction before the channel ID, but dw_hdma_v0_core_ch_status() passed them in the opposite order. This can make the status callback read another HDMA channel status register. Use the same argument order as the other HDMA register accesses. Fixes: e74c39573d35 ("dmaengine: dw-edma: Add support for native HDMA") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-2-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit d382aaf5fed38c6dd2e0cc710d97cb81d660ffa7 Author: Martin Kaiser Date: Sat Jul 18 14:58:48 2026 +0200 dmaengine: fsl-edma: tracing: no ptr dereference during log output commit 2ea04dca8e627f722caa7a2037cfbae0257f3501 upstream. The fsl edma events store a pointer to a struct fsl_edma_engine in the ringbuffer and dereference it when a log entry is printed. At this time, the pointer may no longer be valid. Event injection can be used to trigger a crash: $ cd /sys/kernel/tracing $ echo 'value = 0' > events/fsl_edma/edma_writeb/inject $ cat trace The log output needs only edma->membase. Add a membase field at the end of the event and use the new field for log output. Keep the existing fields for backward compatibility. Fixes: 11102d0c343b ("dmaengine: fsl-edma: add trace event support") Cc: stable@vger.kernel.org Reviewed-by: Steven Rostedt Signed-off-by: Martin Kaiser Reviewed-by: Frank Li Link: https://patch.msgid.link/20260718130024.341243-1-martin@kaiser.cx Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 408ff2d5bf555bd3f4c84a2edb95c0690bf9edc8 Author: Aneesh Kumar K.V (Arm) Date: Fri Jul 17 23:34:19 2026 +0530 dma-direct: return struct page from dma_direct_alloc_from_pool() commit 94a04ad732c9f8b9554270fc4038a06737de5c22 upstream. Commit 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper") changed dma_direct_alloc_from_pool() to return the CPU address from dma_alloc_from_pool(). That fits dma_direct_alloc(), but dma_direct_alloc_pages() also uses the helper and expects a struct page *. Fix this by making dma_direct_alloc_from_pool() return the struct page * again, and pass the CPU address back through an out-parameter for the dma_direct_alloc() caller. Fixes: 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper") Cc: stable@vger.kernel.org Tested-by: Michael Kelley Tested-by: Mostafa Saleh Reviewed-by: Jason Gunthorpe Signed-off-by: Aneesh Kumar K.V (Arm) Reviewed-by: Mostafa Saleh Link: https://lore.kernel.org/r/20260717180442.110954-2-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski Signed-off-by: Greg Kroah-Hartman commit 36177beff2a9df035991ad8d16ccf8d363ed93ee Author: Mikulas Patocka Date: Mon Jul 27 22:26:36 2026 +0200 dm: fix resume-vs-remove race commit 44b43ec132f1cf3275ecc182d0c82f50c3c4c3d5 upstream. If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit af1f32ccf8051f4691ced11feb452b9d13561727 Author: Mikulas Patocka Date: Mon Jul 27 22:27:07 2026 +0200 dm: fix race when loading and unloading a table commit 5380c7f6335cc6d77eb77d065105e81155c4d9d3 upstream. If the userspace calls two concurrent table load ioctls and one of them succeeds and the other fails, there is a race condition because dm_setup_md_queue walks &md->table_devices without any lock. If the walk races with dm_table_destroy -> free_devices -> dm_put_table_device, there is access to invalid memory. Fix this race by extending the lock over the list walk. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 74ec08f7b81c2726578039ca6dea0fec136c38ea Author: Ibrahim Hashimov Date: Mon Jul 13 11:34:14 2026 +0200 HID: wacom: validate report length in wacom_intuos_pro2_bt_irq commit a8e04f3f894ccb52cfcd7e60125a9f35da4a616d upstream. wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: wacom_intuos_pro2_bt_pen(wacom); if (type == INTUOSP2_BT || type == INTUOSP2S_BT) { wacom_intuos_pro2_bt_touch(wacom); wacom_intuos_pro2_bt_pad(wacom); wacom_intuos_pro2_bt_battery(wacom); } else { wacom_intuos_gen3_bt_pad(wacom); wacom_intuos_gen3_bt_battery(wacom); } Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] (the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT ("gen3"): wacom_intuos_gen3_bt_battery() reads data[45], so the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 ("HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior. Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Acked-by: Jason Gerecke Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit f4cb9c4556dcb593e66dbb855179dbd351dbb053 Author: Wei Jie Law <98lawweijie@gmail.com> Date: Tue Aug 25 18:31:17 2026 +0800 HID: rmi: fix OOB access with undersized RMI reports commit 4956993bb3befdf791d71a4952d8d13bcfd44c7b upstream. The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: data->input_report_size = hid_report_len(input_report); data->output_report_size = hid_report_len(output_report); alloc_size = data->output_report_size + data->input_report_size; data->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); data->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly "this probe validated the reports"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles a reply carrying fewer bytes than requested, and a write longer than the output report was overrunning the buffer already. Verified on v6.12.69 and on v6.12.105 built with CONFIG_KASAN=y and booted kasan_multi_shot, whose hid-rmi.c is identical to mainline here. An emulated RMI4 device driven over /dev/uhid, and the same device again over dummy_hcd plus raw-gadget, give identical results: BUG: KASAN: slab-out-of-bounds in rmi_hid_read_block+0x409/0x750 [hid_rmi] Read of size 21 at addr ffff88800bf33bba by task kworker/0:3/285 __asan_memcpy+0x23/0x60 rmi_hid_read_block+0x409/0x750 [hid_rmi] rmi_f01_probe+0x5dd/0x1dc0 [rmi_core] BUG: KASAN: slab-out-of-bounds in rmi_hid_write_block+0x1a9/0x350 [hid_rmi] Write of size 35 at addr ffff88810a2b24ac by task kworker/1:10/666 __asan_memcpy+0x3c/0x60 rmi_hid_write_block+0x1a9/0x350 [hid_rmi] rmi_driver_set_irq_bits+0x1f6/0x4d0 [rmi_core] rmi_driver_probe+0x636/0xbf0 [rmi_core] rmi_input_configured+0x184/0x2e0 [hid_rmi] rmi_probe+0x952/0xcf0 [hid_rmi] and, for the zero-length reply, a probe worker left in D state in rmi_hid_read_block() after 225 replies at 200 ms intervals. After this change the undersized descriptor is refused at probe with "rmi reports too small (out=2 in=2)", the oversized read and write are both rejected, the zero-length reply fails the read with -EIO while later reads on the same device keep working, and a device declaring reports large enough for a 21-byte register read still probes normally and reports its real product id. A device bound through new_id with RMI_DEVICE in its driver_data no longer reaches rmi_set_page() with an unallocated writeReport either. Link: https://lore.kernel.org/linux-input/20260822121007.153988-1-98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/00a489f38b240624dcb5a4bae36a53fcba9cfb47.1787549195.git.98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/20260824122708.76168-1-98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/20260825060954.104890-1-98lawweijie@gmail.com/ Fixes: 9fb6bf02e3ad ("HID: rmi: introduce RMI driver for Synaptics touchpads") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Assisted-by: GLM:glm-5.3 Signed-off-by: Wei Jie Law <98lawweijie@gmail.com> Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit c7f927aa8b55008ed5ea0814313d5dad771dcf3c Author: Shen Yongchao Date: Mon Aug 3 22:31:57 2026 +0800 HID: bpf: serialize device reference release in struct_ops destroy path commit 9cdc7e6dc7a99ad7311ad5e7c145f2b9ce4e24b0 upstream. __hid_bpf_ops_destroy_device() and hid_bpf_unreg() can race on the same registration reference, double-putting struct hid_device and freeing it while hid_destroy_device() still uses it. Serialize the remove/NULL decision under hdev->bpf.prog_list_lock so exactly one path releases each registration reference: unreg re-checks ops->hdev under the lock and returns without putting when the destroy path already cleared it; all put_device() calls happen after the lock is dropped, which is safe because a concurrent unreg then observes ops->hdev == NULL under the lock. Background: each successful attach (hid_bpf_ops_reg) acquires one device reference (hid_get_device()). Two paths can release it: - device destruction: hid_destroy_device() -> hid_bpf_destroy_device() -> __hid_bpf_ops_destroy_device(), which walks hdev->bpf.prog_list under rcu_read_lock() and drops one reference per attached program; - BPF link release: bpf map delete (no BPF_F_LINK) synchronously calls st_ops->unreg() -> hid_bpf_unreg(), which drops the reference for its own registration. The coordination handshake (e->hdev = NULL on the destroy side vs "if (!hdev) return" on the unreg side) is a TOCTOU check: the two paths run under different lock domains (rcu_read_lock vs prog_list_lock), so a concurrent unreg can read ops->hdev as non-NULL, block on prog_list_lock, and then proceed while the destroy traversal executes - both paths then drop the same reference. The refcount reaches zero legitimately (each decrement is individually valid), so no refcount_t saturation fires: the device is simply freed while the transport is still inside hid_destroy_device(), and subsequent teardown touches freed memory. The fix serializes the remove/NULL decision under prog_list_lock on both sides and moves the destroy-side puts outside the lock. With the lock held, plain reads/writes of ops->hdev are sufficient; no READ_ONCE/WRITE_ONCE are added, keeping the patch minimal. Unlocked-read safety: the unlocked read of ops->hdev at the top of hid_bpf_unreg() cannot touch a freed device, because the unreg path itself still holds this registration's reference (released only by its own hid_put_device() after the lock is dropped), and a destroy traversal that already cleared ops->hdev makes the lock-internal re-check return early without any put. At most one of the two paths releases each registration reference. Fixes: ebc0d8093e8c ("HID: bpf: implement HID-BPF through bpf_struct_ops") Cc: stable@vger.kernel.org Signed-off-by: Shen Yongchao Assisted-by: Hermes:kimi-k3 Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 078adc03f6e603cbf4af6e84aa6c2d189f70e0b1 Author: Steven Rostedt Date: Wed Sep 2 09:55:01 2026 -0400 ftrace: Synchronize the initialization of ftrace_ops commit 4617721c502b2ddaa4e324e86da4997edf738fa5 upstream. There's some internal state that ftrace_ops needs to have set, but since it can be declared outside of the ftrace.c code, it calls ftrace_ops_init() on the ops in every global function. The issue is that if two tasks call it on the same ops at the same time it is possible to have the initialization of one corrupt the initialization of the other call. Create a ops_mutex to use to synchronize every initialization of the ftrace_ops. The mutex is taken within checking the ftrace_ops flag that states it was initializied but the flag is checked again after the mutex has been taken. Checking first outside the mutex allows it to shortcut having to take the mutex. But then the check needs to be done again after the mute is taken in case of races. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260902095501.6b59af20@gandalf.local.home Fixes: f04f24fb7e48d ("ftrace, kprobes: Fix a deadlock on ftrace_regex_lock") Reported-by: sashiko-bot@kernel.org Close: https://lore.kernel.org/all/20260829025528.49A831F000E9@smtp.kernel.org/ Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 7d1559126d86be6e4f6a85663dfbfe85caa47e37 Author: Yao Kai Date: Tue Sep 1 15:54:52 2026 +0200 futex: Prevent rcuwait use-after-free during requeue PI commit a3b8d46fe401cba3a5c46dea610e6eb3dc15370e upstream. On PREEMPT_RT, FUTEX_CMP_REQUEUE_PI can trigger a KASAN report (slab-out-of-bounds) in futex_requeue_pi_complete() invocation of rcuwait_wake_up(). The futex_q used by futex_wait_requeue_pi() is allocated on the waiter's stack. An early wakeup can race with a PI requeue as follows: waiter requeue task ------ ------------ futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS * timeout/ signal wakes waiter * futex_requeue_pi_wakeup_sync() Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT requeue_pi_wake_futex futex_requeue_pi_complete() cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED rcuwait_wait_event() if (atomic_read(&q->requeue_state) != Q_REQUEUE_PI_WAIT) break /* no schedule() */ /* q.pi_state->owner == current */ futex_private_hash_put() /* return from syscall */ rcuwait_wake_up(&q->requeue_wait) /* q is gone */ futex_requeue_pi_complete() publishes Q_REQUEUE_PI_LOCKED before calling rcuwait_wake_up(). The waiter observes this state in rcuwait_wait_event() before invoking schedule() in rcuwait_wait_event(). Here, the waiter is free leave the syscall before requeue task can complete the wake. To address this race skip rcuwait_wake_up() in the Q_REQUEUE_PI_LOCKED case. This state is only published by requeue_pi_wake_futex(), which saves q->task before futex_requeue_pi_complete() and wakes the waiter via wake_up_state(). This wake is intended to wake the waiter from its futex_do_wait() sleep. If the waiter is still sleeping there, it can not get into the Q_REQUEUE_PI_WAIT state (and require this removed wake). Should the waiter be woken up from futex_do_wait() by other means (as in this example) and sleep in futex_requeue_pi_wakeup_sync() then the wake_up_state() from requeue_pi_wake_futex() will wake it, too. Should the waiter task terminate before wake_up_state() had a chance to wake the task then the task pointer does not become invalid because the futex_hash_bucket::lock is held and the task pointer is RCU protected. [bigeasy: Updated comment and commit message] Fixes: 07d91ef510fb1 ("futex: Prevent requeue_pi() lock nesting issue on RT") Signed-off-by: Yao Kai Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Sebastian Andrzej Siewior Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901135453.3121948-3-bigeasy@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 1cd41131bc4b8b1eabe582496145d0a0bc42da15 Author: SJ Park Date: Fri Jul 17 17:14:36 2026 -0700 mm/damon/core-kunit: check region count before testing in split_at() commit 9b18ef3c3aa1ce24176e340061caf15fa2742564 upstream. damon_test_split_at() test next region that is assumed to be created by damon_split_region_at() invocation. But the split might fail. In this case, the succeeding test may dereference invalid pointers returned by damon_next_region(). The invalid pointer may not cause a really bad user impact, because of the implementation detail. It would only read wrong contents in the belonging damon_target struct. Depending on the future change of the offset from the link header to the accessing field, this could also be really dangerous, though. Still, the realistic user impact would be limited. It would affect only test run setups. Fix it by testing if the number of regions was also changed as expected and exit early for the failure. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-3-sj@kernel.org Link: https://lore.kernel.org/20260714142352.100478-1-sj@kernel.org [1] Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 382e58c24eabf1c9a47c9221c75de217eb1db3cb Author: SJ Park Date: Sun Jun 28 15:01:10 2026 -0700 mm/damon/sysfs: kobject_del() target (normal), context and kdamond dirs commit 263af33a72d1995ae6cdc22b08d527e2bda17259 upstream. Patch series "mm/damon/sysfs: kobject_del() directories that users can create/remove". DAMON sysfs interface allows users to create and remove arbitrary number of directories on sysfs, using a few files having 'nr_' prefix. For example, 'nr_kdamonds'. When the user writes a number 'N' to the files, directories having name starting from '0' to 'N - 1' are created in the same directory. The pre-existing number-named directories are removed before creating the new directories. For the removal of the existing directories, DAMON sysfs interface use only kobject_put(). Because DAMON sysfs interface is the only kernel component that manages the directories, there is no problem in normal situations. However, if CONFIG_DEBUG_KOBJECT_RELEASE is enabled, the removal of dirs are delayed. Let's suppose a user writes a non-zero number to the 'nr_*' files while there are pre-existing number-named directories, on the config enabled kernel. DAMON sysfs interface decreases the reference counts of the existing directories and immediately creates new directories. Because the removal of the sysfs directories is delayed, it shows some pre-existing directories of the same names when it tries to create the new directories, and fails. For example, the issue can be triggered like below: # grep DEBUG_KOBJECT_RELEASE /boot/config-$(uname -r) CONFIG_DEBUG_KOBJECT_RELEASE=y # ls nr_kdamonds # echo 1 > nr_kdamonds # echo 1 > nr_kdamonds bash: echo: write error: File exists # dmesg [...] [ 300.880458] kobject: kobject_add_internal failed for 0 with -EEXIST, don't try to register things with the same name in the same directory. [...] Some of the error handling paths of the directories also lack the kobject_del() call. If the user uses nr_* file right after the errors, similar issues can happen. This doesn't cause catastrophic issues like kernel panics or memory corruptions. Users can work around by removing all directories first (write 0 to the nr_* files) and then create new directories after confirming the old directories are gone. But, this is definitely a bug that causes a bad user experience. Fix the issues by calling kobject_del() before creating new directories. This patch (of 11) On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for normal creation paths of target, context and kdamond directories, and error paths of context and kdamond directories by adding kobject_del() calls. Note that this fix for target directories is not complete since it has a similar issue in the damon_sysfs_targets_add_dirs() error path. Because the normal path issue and the error path issue are introduced by different commits, this commit is fixing only the normal path issue. A commit for the error path will be added next. Link: https://lore.kernel.org/20260628220121.97360-1-sj@kernel.org Link: https://lore.kernel.org/20260628220121.97360-2-sj@kernel.org Fixes: c951cd3b8901 ("mm/damon: implement a minimal stub for sysfs-based DAMON interface") Signed-off-by: SJ Park Cc: # 5.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 368f84ec79104761e007ea74380c44c7f3303144 Author: SJ Park Date: Sun Jun 28 15:01:11 2026 -0700 mm/damon/sysfs: kobject_del() region and target (error) dirs commit 2603ef6f6ec3d3f7de2d6a07e7c9a683cebac419 upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for the normal creation path of region directories and the error path of target directories, by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-3-sj@kernel.org Fixes: 2031b14ea757 ("mm/damon/sysfs: support the physical address space monitoring") Signed-off-by: SJ Park Cc: # 5.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 23c7b91895ff0f38ae08f699d50a8744efb8f304 Author: SJ Park Date: Sun Jun 28 15:01:13 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme region dirs commit f3ec3271210781c255e737498b84d5790e8176b4 upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme region directories by adding kobject_del() calls. This issue was discovered [1] by Sashiko, though its analysis was partially incorrect. Link: https://lore.kernel.org/20260628220121.97360-5-sj@kernel.org Link: https://lore.kernel.org/20260517205828.6204-1-sj@kernel.org [1] Fixes: 9277d0367ba1 ("mm/damon/sysfs-schemes: implement scheme region directory") Signed-off-by: SJ Park Cc: # 6.2.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 20a40e7eb5ec37949af9ea65277377212d3d9f90 Author: SJ Park Date: Sun Jun 28 15:01:15 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme quota goal dirs commit 0d4397ca921ceaf80fc3eca4c8194812ff79a979 upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme quota goal directories by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-7-sj@kernel.org Fixes: 7f262da0a30d ("mm/damon/sysfs-schemes: implement files for scheme quota goals setup") Signed-off-by: SJ Park Cc: # 6.8.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e608e7bbe82cb3a817ff68b9374a15e62f0c2265 Author: SJ Park Date: Sun Jun 28 15:01:14 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme filter dirs commit 3c453bddacd4c04ecb38cf79dbfa41e7dfe0531b upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme filter directories by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-6-sj@kernel.org Fixes: 472e2b70eda6 ("mm/damon/sysfs-schemes: connect filter directory and filters directory") Signed-off-by: SJ Park Cc: # 6.3.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8a1ebb241fc708dee1f41c6a92fc6c4147b208ee Author: SJ Park Date: Sun Jun 28 15:01:12 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme dirs commit 05fb6ac98c49be870c5f9ccdfdf95f0107e564ae upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme directories by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-4-sj@kernel.org Fixes: 7e84b1f8212a ("mm/damon/sysfs: support DAMON-based Operation Schemes") Signed-off-by: SJ Park Cc: # 5.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b9847d539b9c884280dca56dae706547fc80d08e Author: SJ Park Date: Sun Jun 28 15:01:16 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme action destination dirs commit 286380c78bc51e6c578621b9ae660bf9e5ad2563 upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme action destination directories by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-8-sj@kernel.org Fixes: 2cd0bf85a203 ("mm/damon/sysfs-schemes: implement DAMOS action destinations directory") Signed-off-by: SJ Park Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cb55606449fd6d929be2d43face0f8e7b173acde Author: SJ Park Date: Sun Jun 28 14:54:44 2026 -0700 samples/damon/wsse: stop and free damon ctx when damon_call() fails commit a2c6fa6c23ad87c61e1379b05dc05cf5fed4bf8d upstream. damon_sample_wsse_start() calls damon_call() right after damon_start() is succeeded. The kdamond that has started by the damon_start() could be terminated by itself before or in the middle of the damon_call() execution. There could be multiple reasons for such a stop including monitoring target process termination and kdamond_fn() internal memory allocation failures. In the case, damon_call() will fail and return an error without cleaning up the DAMON context object. The damon_sample_wsse_start() caller assumes it would clean up the object, though. When the user requests to start DAMON again, damon_sample_wsse_start() is called again, allocates a new DAMON context object and overwrites the pointer for the previous object. As a result, the previous context object is leaked. Safely stop the kdamond and deallocate the context object when the failure is returned. Note that the kdamond should be stopped first, because damon_call() failure means not complete termination of the kdamond but only the fact that the termination process has started. The user impact shouldn't be that significant because the race is not easy to happen, and only up to one DAMON context object can be leaked per race. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-6-sj@kernel.org Link: https://lore.kernel.org/20260610034828.4632-1-sj@kernel.org [1] Fixes: cc9c1b8c205b ("samples/damon/wsse: use damon_call() repeat mode instead of damon_callback") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6179c7f47876d576dfe30efa8fbf1b0b1fdd13c0 Author: SJ Park Date: Sun Jun 28 14:54:40 2026 -0700 samples/damon/wsse: handle damon_start() failure commit e4742be45ea45bf554399ce89a09f71e525d7981 upstream. Patch series "samples/damon: handle damon_{start,stop}() failures". All DAMON sample modules are not correctly handling failures from damon_start(). Among those, mtier also has an additional problem for handling of damon_stop() failures. wsse and prcl also have a problem in their damon_call() failure handling. As a result, memory leaks, next DAMON operation disruptions, and use-after-free can happen. Fix those. Note that only the damon_start() failure caused issues can reliably be reproduced. Reproducing those issues require the admin permission, though. This patch (of 6): damon_sample_wsse_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it leaks the memory for DAMON context. Free the context in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo $$ | sudo tee /sys/module/damon_sample_wsse/parameters/target_pid $ echo Y | sudo tee /sys/module/damon_sample_wsse/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the third command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the third and the fourth commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-2-sj@kernel.org Link: https://lore.kernel.org/20260609145814.70163-1-sj@kernel.org [1] Fixes: b757c6cfc696 ("samples/damon/wsse: start and stop DAMON as the user requests") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.14.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2446d3820cbaf88c386b8836194bdd42464115ec Author: SJ Park Date: Sun Jun 28 14:54:45 2026 -0700 samples/damon/prcl: stop and free damon ctx when damon_call() fails commit a73fa45d3f0f42c446ae55c5799e3d5ef044cd5d upstream. damon_sample_prcl_start() calls damon_call() right after damon_start() is succeeded. The kdamond that has started by the damon_start() could be terminated by itself before or in the middle of the damon_call() execution. There could be multiple reasons for such a stop including monitoring target process termination and kdamond_fn() internal memory allocation failures. In the case, damon_call() will fail and return an error without cleaning up the DAMON context object. The damon_sample_prcl_start() caller assumes it would clean up the object, though. When the user requests to start DAMON again, damon_sample_prcl_start() is called again, allocates a new DAMON context object and overwrites the pointer for the previous object. As a result, the previous context object is leaked. Safely stop the kdamond and deallocate the context object when the failure is returned. Note that the kdamond should be stopped first, because damon_call() failure means not complete termination of the kdamond but only the fact that the termination process has started. The user impact shouldn't be that significant because the race is not easy to happen, and only up to one DAMON context object can be leaked per race. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-7-sj@kernel.org Link: https://lore.kernel.org/20260610035214.4850-1-sj@kernel.org [1] Fixes: a6c33f1054e3 ("samples/damon/prcl: use damon_call() repeat mode instead of damon_callback") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9f370353bba7f4bbe87a1c82fcf9f579ace1e3f1 Author: SJ Park Date: Sun Jun 28 14:54:41 2026 -0700 samples/damon/prcl: handle damon_start() failure commit 8b724349229bb6ebbf781178be011ba9bc2cca57 upstream. damon_sample_prcl_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it leaks the memory for DAMON context. Free the context in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo $$ | sudo tee /sys/module/damon_sample_prcl/parameters/target_pid $ echo Y | sudo tee /sys/module/damon_sample_prcl/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the third command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the third and the fourth commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-3-sj@kernel.org Link: https://lore.kernel.org/20260609145814.70163-1-sj@kernel.org [1] Fixes: 2aca254620a8 ("samples/damon: introduce a skeleton of a smaple DAMON module for proactive reclamation") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.14.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3c07c57b894116ae26f01b84c68e68b538ada7ed Author: SJ Park Date: Sun Jun 28 14:54:43 2026 -0700 samples/damon/mtier: handle damon_stop() failure commit 9dc5b6d66fd51b103eff21ed0df3e292f489ebc0 upstream. damon_sample_mtier_stop() assumes its damon_stop() call will always successfully stops the two DAMON contexts. Hence it deallocates the two DAMON contexts after the damon_stop() call. However, if a given context is already stopped, damon_stop() fails and returns an error while letting the DAMON contexts that have not yet stopped keep running. This kind of unexpected early DAMON context stops could happen due to memory allocation failures in kdamond_fn(). Because damon_sample_mtier_stop() just deallocates all DAMON contexts with damon_target and damon_region objects that are linked to the contexts, the execution of the unstopped DAMON context (kdamond) ends up using the memory that freed (use-after-free). Fix the issue by separating the damon_stop() to be invoked per context. Note that DAMON_SYSFS also allows multiple DAMON contexts execution. But, it calls damon_stop() for each context one by one. Hence this issue is only in mtier. For the long term, it would be better to refactor damon_stop() to always ensure stopping all contexts regardless of the failures in the middle. Make this fix in the current way, though, to keep it simple and easy to backport. I will do the refactoring later. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-5-sj@kernel.org Link: https://lore.kernel.org/20260609014219.3013-1-sj@kernel.org [1] Fixes: 82a08bde3cf7 ("samples/damon: implement a DAMON module for memory tiering") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.16.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f0808262a76165fbde6b4f1c2a8856a1e2b45512 Author: SJ Park Date: Sun Jun 28 14:54:42 2026 -0700 samples/damon/mtier: handle damon_start() failure commit c7230d08ee79b13127bd2b45a3648d361ac912fc upstream. damon_sample_mtier_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it could leak the memory for DAMON context. Also, if damon_start() fails for only the second context, the first context will indefinitely run, and avoid starting other DAMON contexts since it is running in the exclusive mode. Stop possibly started DAMON context and free the contexts in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo Y | sudo tee /sys/module/damon_sample_mtier/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the second command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the second and the third commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-4-sj@kernel.org Link: https://lore.kernel.org/20260608112455.274231F00893@smtp.kernel.org [1] Fixes: 82a08bde3cf7 ("samples/damon: implement a DAMON module for memory tiering") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.16.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 71de5a082d2ca4dcdf48b2f73ff8c6ed5a5f5aeb Author: SJ Park Date: Fri Jul 17 17:14:37 2026 -0700 mm/damon/vaddr-kunit: check region count in three_regions test commit 5fea07e460874c8c7cf00f728efbe22abc62c8d8 upstream. damon_do_test_apply_three_regions() iterates regions after damon_set_regions() call assuming the function would succeed at setting the number of regions the same to the expected one. It might have failed. In this case, __nth_region_of() in the iteration could return NULL and NULL dereference can happen in the test. The consequent user impact (NULL dereference) is quite bad. The realistic user impact would be limited, though. It would affect only test run setups. Fix it by testing if the number of regions was also changed as expected and exit early for the failure. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-4-sj@kernel.org Link: https://lore.kernel.org/20260713144757.39740-1-sj@kernel.org [1] Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit dd817463c9b42a3a9e23d15b86c6c77a6cfb809d Author: Runyu Xiao Date: Mon Aug 24 19:36:18 2026 +0800 scsi: pm8001: Use rollback index when freeing MSI-X vectors commit 3f92a64545165bdbb36dee8fa35626b295463313 upstream. pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop. Fixes: a76037ff3479 ("scsi: pm8001: switch to pci_irq_alloc_vectors") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Acked-by: Jack Wang Link: https://patch.msgid.link/20260824113618.2239100-1-runyu.xiao@seu.edu.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 4bb34769ef44ab3770b89e4055de6af4a458bec9 Author: Thomas Lamprecht Date: Thu Aug 27 19:24:24 2026 +0200 scsi: megaraid_sas: Limit NVMe request size to the PRP chain frame commit af8c27375733fb6a6df9fa484cda77cc3dd0cb80 upstream. megasas_make_prp_nvme() builds a command's PRP list in cmd->sg_frame, a DMA pool buffer of instance->max_chain_frame_sz bytes, spending one entry per NVMe page of the transfer plus one per page of the buffer for the chain pointer. The loop runs until the transfer is described and never checks the buffer bound. max_hw_sectors comes straight from the MDTS the firmware reports for the drive. On drives with a large MDTS the only thing keeping the list inside the buffer was the block layer default of 1280 KiB, which needs 320 entries, which fit into a 4 KiB frame as that holds 512. But since commit 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") that default is 4 MiB, and such a transfer needs 1025 entries, so the list runs a full page past the end of the frame: sd 1:0:1:0: [sdb] tag#630 page boundary ptr_sgl: 0x00000000ba62d13f BUG: unable to handle page fault for address: ff663bcb81e7c000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:megasas_build_and_issue_cmd_fusion+0xeaa/0x1870 [megaraid_sas] If the page after the frame happens to be mapped, the overrun does not fault but silently corrupts the neighbouring pool entry, which is another in-flight command's PRP list. Cap max_hw_sectors at what the chain frame can describe, less one page for transfers that do not start on a page boundary and so need one entry more. This is the megaraid_sas counterpart of commit 04631f55afc5 ("scsi: mpt3sas: Limit NVMe request size to 2 MiB"), but derives the limit from max_chain_frame_sz rather than hardcoding it. Cc: stable@vger.kernel.org Fixes: 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") Reported-by: Lukasz Magiera Closes: https://lore.kernel.org/all/GPhsSM0vkgyIrs0DIZ62qeUZX7X4RxwQXVKiuvMx-lHQVSPDxpztUyQOGS0xikqvJ-Z94hMV-dW_5KN_0CX2hsfV7kTf_t0MTf6vdAAaSEc=@magik.net/ Reported-by: Mira Limbeck Closes: https://lore.kernel.org/all/d171cc76-bf25-48ce-b482-d344669dfc24@proxmox.com/ Suggested-by: Martin K. Petersen Link: https://lore.kernel.org/all/yq17bmzd5jr.fsf@ca-mkp.ca.oracle.com/ Signed-off-by: Thomas Lamprecht Closes: https://lore.kernel.org/linux-scsi/20260827182106.535D61F000E9@smtp.kernel.org Link: https://patch.msgid.link/20260827175743.734593-1-t.lamprecht@proxmox.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 1624bff4c5118ad494d50ad94d44f22064667a7f Author: Sujal Tuladhar Date: Sat Aug 1 21:30:00 2026 +0545 scsi: target: iscsi: Reserve a terminator byte for the login payload commit f4825922d2fb371e2b969697d792077f1b62b62c upstream. iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where padding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated. Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Assisted-by: Claude Opus5 (custom harness) Cc: stable@vger.kernel.org Signed-off-by: Sujal Tuladhar Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit a38051fa2ddedbc8ec15292c55e276880ec5b9a4 Author: Honghui Jiang Date: Fri Aug 14 11:14:15 2026 +0800 spi: Fix DMA mapping ownership on partial map failure commit 367cea239fc93094e5c16a72724800e0358f5c46 upstream. If RX mapping fails after TX mapping succeeds, __spi_map_msg() unmaps TX but leaves tx_sg_mapped set. If TX mapping fails on a later transfer, mappings created for earlier transfers remain active. In both cases, cur_{tx,rx}_dma_dev have not yet been updated because they are assigned only after every transfer has been mapped. The subsequent spi_unmap_msg() may therefore unmap the TX mapping again or release earlier mappings using a NULL or stale device. Using a NULL device can trigger an oops. An empty SG table does not prevent the NULL dereference because dma_unmap_sg_attrs() accesses the device before checking the entry count. Publish both mapping devices before mapping starts and unwind all failures through __spi_unmap_msg(). This clears the mapping flags and releases each mapping once with the device that created it. Publishing the devices before the loop also refreshes them when no transfer needs mapping. No mapping flag is set in that case, so current users do not use the pointers as mapping owners. Fixes: e289df82344f ("spi: Rework per message DMA mapped flag to be per transfer") Cc: stable@vger.kernel.org Signed-off-by: Honghui Jiang Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260814031419.43378-2-jiang_hh2019@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 148a3f03aec892d9a397f095faa087d458fd11ac Author: Can Peng Date: Tue Aug 4 15:19:04 2026 +0800 spi: bcmbca-hsspi: disable clocks on resume failure commit d2f5a606710ad70c341dc609430a20a5645618d5 upstream. bcmbca_hsspi_resume() enables the HSSPI clock, and optionally the PLL clock, before restarting the SPI controller queue. If spi_controller_resume() fails, the function currently reports success and leaves those clocks enabled. Propagate the error and disable the clocks before returning. Fixes: a38a2233f23b ("spi: bcmbca-hsspi: Add driver for newer HSSPI controller") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Reviewed-by: Kursad Oney Link: https://patch.msgid.link/20260804071904.860842-1-pengcan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0acbfd61aee188dc25adac8a2402601fda18f98b Author: Can Peng Date: Tue Aug 4 15:18:31 2026 +0800 spi: bcm63xx: disable clock on resume failure commit 2b62c2c134fa32d9d3a9e7323c8ac74518eeb4ac upstream. bcm63xx_spi_resume() enables the controller clock before restarting the SPI controller queue. If spi_controller_resume() fails, the function currently reports success and leaves the clock enabled. Propagate the error and disable the clock before returning. Fixes: b42dfed83d95 ("spi: add Broadcom BCM63xx SPI controller driver") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Link: https://patch.msgid.link/20260804071831.860784-1-pengcan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b782a7cb0a424c1e25b48eee6564e944eea3750d Author: Can Peng Date: Tue Aug 4 15:20:17 2026 +0800 spi: bcm63xx-hsspi: disable clocks on resume failure commit 3b0cee02664041aea7e4f787c66cb86c82eb4e97 upstream. bcm63xx_hsspi_resume() enables the HSSPI clock, and optionally the PLL clock, before restarting the SPI controller queue. If spi_controller_resume() fails, the function currently reports success and leaves those clocks enabled. Propagate the error and disable the clocks before returning. Fixes: 142168eba9dc ("spi: bcm63xx-hsspi: add bcm63xx HSSPI driver") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Reviewed-by: Kursad Oney Link: https://patch.msgid.link/20260804072017.860974-1-pengcan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 907752a7b64a6b47ad36fc63e924a475335b0f9d Author: Viken Dadhaniya Date: Thu Jul 2 11:12:23 2026 +0530 soc: qcom: geni-se: Use HW PROG_RAM_DEPTH to validate firmware size commit 522bfb4f33c0930b3d14d5c5ee80bc93a883b544 upstream. The hardcoded MAX_GENI_CFG_RAMn_CNT limit is not accurate for all SoCs: some targets have less CFG RAM than the constant implies, while others like QCS615 need more entries than the old limit of 455 allowed, causing valid firmware to be rejected at load time. Rather than hardcoding a constant, read PROG_RAM_DEPTH from SE_HW_PARAM_2 at runtime to get the actual CFG RAM depth of the hardware instance and use that as the upper bound for firmware size validation. 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/20260702-qup-se-increase-ram-cnt-v3-1-80b363373a5b@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit e373c1acdbcf88cec533ece9f589020adaed0a78 Author: Kanishka De Silva Date: Sun Aug 30 12:31:33 2026 +0530 ublk: clear VM_MAYWRITE on read-only ublk char device mmap commit 6e2b571b0a54755b06e092501913e1dfefe75d6c upstream. ublk_ch_mmap() rejects mmap requests with VM_WRITE set, but never clears VM_MAYWRITE on the resulting read-only mapping. This allows a userspace daemon to mmap the per-queue command buffer PROT_READ, then upgrade it to PROT_WRITE via mprotect(), since VM_MAYWRITE was never cleared. The command buffer holds struct ublksrv_io_desc entries that are kernel-written ABI; a writable mapping lets an unprivileged daemon process corrupt fields such as addr, op_flags, nr_sectors, and start_sector. Same bug class as the drm/panthor and drm/vc4 VM_MAYWRITE fixes, and the 2026-08-13 ptp/vmclock fix (a5edadbae57e). Verified via mprotect() PoC: before the fix, a PROT_READ mapping can be upgraded to PROT_READ|PROT_WRITE and a write into the command buffer corrupts io_desc fields (confirmed under KASAN). After the fix, mprotect() returns -EACCES. Fixes: 3fee8d7599e1 ("ublk_drv: add io_uring based userspace block driver") Cc: stable@vger.kernel.org Signed-off-by: Kanishka De Silva Reviewed-by: Ming Lei Link: https://patch.msgid.link/20260830070133.559-1-kpskanna1915@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 89f06342743ca7b54a8f6734bd44533ba8a10638 Author: Bryan Lim Date: Wed Aug 19 10:08:24 2026 +0700 userfaultfd: reset err to be 0 when move_pages_ptes succeeded commit f025ca73decda1f895a4b80b961d3bc88825298a upstream. During move_pages() operation, when move_pages_ptes() returns EAGAIN, the error code is not cleared even after we processed it. This leads to a successful retry but then the same pages are retried again due to the stale error code. This time move fails because pages are already moved, loop is terminated and move_pages() reports a failure. Clear the error code once we processes EAGAIN. Link: https://lore.kernel.org/e1e0b5f8-c3c6-0537-670b-4397f822f980@gmail.com Fixes: 50944692052b ("userfaultfd: opportunistic TLB-flush batching for present pages in MOVE") Assisted-by: ChatGPT:GPT-5.6-Luna Signed-off-by: Bryan Lim Reviewed-by: Suren Baghdasaryan Acked-by: Mike Rapoport (Microsoft) Cc: Peter Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 65c2029f3bbae5cd7f9fff4ce7c7fc3ef7879b25 Author: Can Peng Date: Wed Jul 22 15:56:25 2026 +0800 thermal/drivers/qoriq: Disable clock on resume failure commit fcbf9964b67a6d6704c50ed28daa24c3b164f01c upstream. qoriq_tmu_resume() enables the TMU clock before clearing the power-down bit and enabling monitoring. If either register update fails, the function returns with the clock still enabled. This leaves the clock enable count unbalanced after a failed resume. Disable the clock on those failure paths before returning the error. Fixes: 51904045d4aa ("thermal: qoriq: Add clock operations") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260722075625.452684-1-pengcan@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit ec2db87a0bbb8fa431b43ba9864ad00ce7d8c306 Author: Can Peng Date: Wed Jul 22 16:49:09 2026 +0800 thermal/drivers/imx: Disable clock on runtime resume failure commit bcc6d886e5006a4656901d2d7fb6a215c96068a0 upstream. imx_thermal_runtime_resume() enables the thermal clock before powering up the sensor and enabling measurements. If either regmap_write() fails, the function returns with the clock still enabled. This leaves the clock enable count unbalanced after a failed runtime resume. Disable the clock on those failure paths before returning the error. Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Signed-off-by: Daniel Lezcano Reviewed-by: Frank Li Link: https://patch.msgid.link/20260722084909.463437-1-pengcan@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit efaab8938fb92979be6df359f7d1a43fb7e4717d Author: Arthur Gautier Date: Mon Aug 31 12:04:48 2026 +0300 xhci: fix lost bounce buffers on TDs spanning several ring segments commit ff44dfb03a293bf30e31f98772a1dd316a6071d1 upstream. When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.] Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer") Cc: stable@vger.kernel.org Suggested-by: Michal Pecio Signed-off-by: Arthur Gautier Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260831090448.95644-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit b041e3f35e0d262d42a711094ab594634d72744a Author: Muhammad Bilal Date: Tue Jul 28 17:54:55 2026 +0500 staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() commit ff917923f4fb9c83717ba135ee47d7e4c1567bb7 upstream. rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: const u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); ... c = frame_body[0]; ... a = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260728125456.32359-3-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman commit ff61aa3289355dafa811550a1764691cd1f5d33b Author: Muhammad Bilal Date: Tue Jul 28 17:54:54 2026 +0500 staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() commit 99aa998dec83ba180822f70e6d48a514fc81c20d upstream. rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: if (attr_ptr + 4 > wps_ie + wps_ielen) break; u16 attr_id = get_unaligned_be16(attr_ptr); u16 attr_data_len = get_unaligned_be16(attr_ptr + 2); u16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: memcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack "u8 sr"/"u8 selected_registrar" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The "attr_ptr + 4 > wps_ie + wps_ielen" header check above was added by commit 1463ca3ec6601 ("staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260728125456.32359-2-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit d3a7fa61997db3bf6dadef4c1bd87a4fa782a817 Author: Jeffin Philip Date: Sun Aug 16 11:47:12 2026 +0530 usb: gadget: fix null pointer dereference in usb_put_function_instance() commit 6e74ac5c596fd246e37eadfc354567179ccbe9aa upstream. usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null. Reported-by: syzbot+fd6ef980cf1c722be639@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fd6ef980cf1c722be639 Fixes: 0062f6e56f70 ("usb: gadget: add a forward pointer from usb_function to its "instance"") Cc: stable Signed-off-by: Jeffin Philip Link: https://patch.msgid.link/20260816061712.15547-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit c29a83c1ff3f06d5751f6d365b606c9f81ccc4cb Author: Lovekesh Solanki Date: Tue Aug 25 22:43:43 2026 +0530 USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() commit dd0eed9e165b1a6292f49e622e3dd0b7d99b106d upstream. gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently. Cc: stable Reported-by: Eulgyu Kim Link: https://lore.kernel.org/all/20260824113510.1141236-1-jjy600901@snu.ac.kr/ Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/all/20260824113510.1141236-1-jjy600901@snu.ac.kr/ Signed-off-by: Lovekesh Solanki Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260825171343.459630-1-lovekeshsolanki00@gmail.com Signed-off-by: Greg Kroah-Hartman commit 02ac76f27db23ef652358458c272d9d2d6f51167 Author: Jeffin Philip Date: Sat Aug 15 11:10:06 2026 +0530 usb: gadget: f_midi: initialize work in f_midi_alloc() commit 7e07d3e4c389217d7d7171d80edf2e23ac70f1ea upstream. f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc(). Reported-by: syzbot+d5fa3d224505c8610702@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d5fa3d224505c8610702 Fixes: 8653d71ce376 ("usb/gadget: f_midi: Replace tasklet with work") Cc: stable Signed-off-by: Jeffin Philip Reviewed-by: Takashi Iwai Link: https://patch.msgid.link/20260815054006.102325-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit e89e30f0b5d3004fe5955250bd8b04f3733e32ce Author: Ivy Lopez Date: Sat Aug 15 18:54:33 2026 -0600 usb: gadget: f_midi2: fix use-after-free in string attribute show path commit fed0aa7c6eaedc6c0d4e362fc91724aa47be4a7b upstream. f_midi2_opts_str_show() takes the string lock internally, but its callers dereference the opts->info. pointer before calling it, outside the lock. This races with f_midi2_opts_str_store(), which frees the old string under opts->lock when the attribute is written concurrently, the show path can read a pointer that gets freed before the lock inside str_show() is even taken. Change f_midi2_opts_str_show() to take a pointer to the string field, matching the existing pattern in f_midi2_opts_str_store(), and dereference it only after the lock is held. Update all three callers (iface_name, block name, and the EP string option macro) accordingly. Reported-by: syzbot+2280f1cca5e6b0c353e4@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=2280f1cca5e6b0c353e4 Signed-off-by: Ivy Lopez Reviewed-by: Takashi Iwai Link: https://patch.msgid.link/20260816005434.34018-1-skunkolee@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9c3d5091e3568ed48ac4c5b08a78eb06fad0d70a Author: Aleksandr Nogikh Date: Wed Jul 29 09:04:54 2026 +0000 usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs commit f0efaf1872949e96d213c8e910fd9517f7d7c406 upstream. A null-pointer dereference occurs in f_midi2_free_ep_reqs() when attempting to clean up an endpoint that was never initialized. When configuring the MIDI 2.0 gadget via configfs and setting the block direction to SNDRV_UMP_DIR_INPUT, the initialization of the midi1_ep_out endpoint is explicitly skipped during the gadget bind phase (f_midi2_bind()). As a result, the usb_ep->card field remains NULL. Later, when the host sets the alternate setting, f_midi2_set_alt() unconditionally stops both the IN and OUT endpoints by calling f_midi2_stop_eps(), which in turn calls f_midi2_free_ep_reqs() for both endpoints. When f_midi2_free_ep_reqs() is called for the uninitialized midi1_ep_out, it attempts to dereference usb_ep->card to determine the number of requests to free, leading to a crash. Fix this by using usb_ep->num_reqs instead of usb_ep->card->info.num_reqs in f_midi2_free_ep_reqs(). usb_ep->num_reqs is correctly set during f_midi2_init_ep() and remains 0 if the endpoint was never initialized, safely avoiding the loop. For consistency, apply the same change to f_midi2_alloc_ep_reqs(). Oops: general protection fault, probably for non-canonical address 0xdffffc00000000ee: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000770-0x0000000000000777] ... RIP: 0010:f_midi2_free_ep_reqs drivers/usb/gadget/function/f_midi2.c:1166 [inline] RIP: 0010:f_midi2_stop_eps+0x28e/0x4d0 drivers/usb/gadget/function/f_midi2.c:1246 ... Call Trace: f_midi2_set_alt+0x11c/0xf00 drivers/usb/gadget/function/f_midi2.c:1296 composite_setup+0x1ffd/0x3480 drivers/usb/gadget/composite.c:1933 configfs_composite_setup+0xbd/0x100 drivers/usb/gadget/configfs.c:1877 Fixes: 8b645922b223 ("usb: gadget: Add support for USB MIDI 2.0 function driver") Cc: stable Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+bbb6dad313f4aaa8da6b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bbb6dad313f4aaa8da6b Link: https://syzkaller.appspot.com/ai_job?id=8ce30b1a-8cf7-4e38-bcf7-1f69e6f6313f Signed-off-by: Aleksandr Nogikh Reviewed-by: Takashi Iwai Closes: https://syzkaller.appspot.com/bug?extid=01a17afb30637396955e Link: https://patch.msgid.link/cafe65f4-e1bb-46a3-901d-732814b861b2@mail.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 33a81acd2d1d0667d4eff93cb90339fa53e617e8 Author: Jameson Thies Date: Tue Aug 25 23:45:45 2026 +0000 usb: typec: ucsi: displayport: Fix OOB altmode array index commit 04cec690b1fd9d1c4c314b91a10d8c68a3acfe18 upstream. The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array. Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Cc: stable@vger.kernel.org Signed-off-by: Jameson Thies Reviewed-by: Benson Leung Link: https://patch.msgid.link/20260825234545.2076049-1-jthies@google.com Signed-off-by: Greg Kroah-Hartman commit 6be5169e7615d0e96dc36e084f61cb07211f22bc Author: Sven Peter Date: Thu Aug 13 20:16:15 2026 +0200 usb: typec: tipd: Fix Thunderbolt altmode VDOs for cd321x commit e24e3370356bddb65d667985a332b5f8aeeb5f97 upstream. The Intel VID status register is actually 9 bytes long and doesn't contain the raw VDOs but only the upper 16bits for device mode and enter mode. Shift those two fields into place and reconstruct the cable discover mode VDO from the data status register instead since it's not directly accessible. With this fixed now the correct VDOs are forwarded to the PHY and the to-be-submitted Thunderbolt/USB4 native host interface so that the right mode can be negotiated and the link actually comes up. Link: https://www.ti.com/lit/ug/slvubh2b/slvubh2b.pdf Fixes: 0b31c978935f ("usb: typec: tipd: Read USB4, Thunderbolt and DisplayPort status for cd321x") Fixes: 82432bbfb9e8 ("usb: typec: tipd: Handle mode transitions for CD321x") Cc: stable Signed-off-by: Sven Peter Tested-by: Rafay Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260813-b4-tipd-vdo-fix-v1-1-70317f2cd554@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 42828aeb40b4a2099fc91e181850c106031d1d95 Author: Amit Sunil Dhamne Date: Thu Aug 27 21:16:17 2026 +0000 usb: typec: tcpm: constrain TCPM_SOURCING_VBUS event handling commit cd3b9cea675bbfebc223f007dc2f4e79524fa54c upstream. When a sink detach occurs while waiting for TX send status, the old TCPM_SOURCING_VBUS event along with TCPM_VBUS_EVENT and TCPM_CC_EVENT can be queued in port->pd_events. Because TCPM_SOURCING_VBUS is evaluated after TCPM_VBUS_EVENT and TCPM_CC_EVENT in tcpm_pd_event_handler(), a stale TCPM_SOURCING_VBUS event can override the detach handling and incorrectly set port->vbus_source and port->vbus_present to true. Add a state guard to check that the port is either operating as a Source (tcpm_port_is_source(port)) or in a Fast Role Swap (FRS) state up to FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED before processing TCPM_SOURCING_VBUS. Otherwise, discard and log the event. Log snippet for error condition before fix: [72792.204955] state change SRC_ATTACHED -> SRC_STARTUP [rev3 NONE_AMS] [72792.204960] sourcing vbus [72792.204962] VBUS on [72792.204970] AMS POWER_NEGOTIATION start [72792.204974] cc:=4 [72792.205319] state change SRC_STARTUP -> AMS_START [rev3 POWER_NEGOTIATION] [72792.205325] state change AMS_START -> SRC_SEND_CAPABILITIES [rev3 POWER_NEGOTIATION] [72792.205332] PD TX, header: 0x11a1 [72792.216911] PD TX complete, status: 2 [72792.216957] pending state change SRC_SEND_CAPABILITIES -> SRC_SEND_CAPABILITIES @ 150 ms [rev3 POWER_NEGOTIATION] [72792.218005] VBUS off [72792.218013] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION] [72792.218020] VBUS VSAFE0V [72792.218024] state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED [rev3 POWER_NEGOTIATION] [72792.218458] CC1: 2 -> 0, CC2: 0 -> 0 [state SNK_UNATTACHED, polarity 0, disconnected] [72792.218467] VBUS on --> VBUS left on [72792.218980] disable vbus discharge ret:0 [72792.235193] Start toggling After fix: [ 1195.291691] state change SRC_ATTACHED -> SRC_STARTUP [rev3 NONE_AMS] [ 1195.291698] sourcing vbus [ 1195.291700] VBUS on [ 1195.291707] AMS POWER_NEGOTIATION start [ 1195.291710] cc:=4 [ 1195.291758] state change SRC_STARTUP -> AMS_START [rev3 POWER_NEGOTIATION] [ 1195.291794] state change AMS_START -> SRC_SEND_CAPABILITIES [rev3 POWER_NEGOTIATION] [ 1195.291798] PD TX, header: 0x11a1 [ 1195.297056] PD TX complete, status: 2 [ 1195.297092] pending state change SRC_SEND_CAPABILITIES -> SRC_SEND_CAPABILITIES @ 150 ms [rev3 POWER_NEGOTIATION] [ 1195.297177] VBUS off [ 1195.297184] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION] [ 1195.297227] CC1: 2 -> 0, CC2: 0 -> 0 [state SRC_SEND_CAPABILITIES, polarity 0, disconnected] [ 1195.307469] cc:=2 [ 1195.307544] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION] [ 1195.307555] Discarding sourcing vbus! Invalid state SRC_SEND_CAPABILITIES [ 1195.957636] state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED [delayed 650 ms] [ 1195.957732] disable vbus discharge ret:0 [ 1195.970196] Start toggling [ 1195.970468] VBUS off [ 1196.051637] VBUS off [ 1196.051642] VBUS VSAFE0V Fixes: 8dc4bd073663 ("usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)") Cc: stable Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Amit Sunil Dhamne Reviewed-by: Badhri Jagan Sridharan Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260827-sourcing-vbus-v1-1-9be1aca991a0@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit d4e00a1eb39174e25ef759b8fb1111bba8e87b1e Author: Fan Wu Date: Wed Aug 19 16:14:48 2026 +0000 usb: typec: qcom-pmic: cancel reset_work on stop commit 7b0df6efd143f8085bdb68778a013a46f1349913 upstream. pdphy_stop() disables IRQs but leaves reset_work pending. If the IRQ handler schedules it just before disable_irq(), the work runs after remove() frees the struct via devm. Call cancel_work_sync() after disabling IRQs to close the window. This issue was found by an in-house static analysis tool. Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Cc: stable Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Reviewed-by: Konrad Dybcio Reviewed-by: Bryan O'Donoghue Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260819161448.76597-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 1e4f33f99bfb7ee5df2b76fb5445a8c9e24b8fed Author: Fan Wu Date: Thu Aug 20 13:53:07 2026 +0000 usb: typec: qcom-pmic-typec: drain cc_debounce_dwork if port_start() fails commit c9273c83885835dbd1e8835d5665dfb8503d65e0 upstream. cc_debounce_dwork can be queued before port_start() fails: tcpm_register_port() runs first, and its state machine may invoke set_cc() or start_toggling() from the TCPM worker. The error path then calls tcpm_unregister_port(), whose worker flush may queue the delayed work before devres frees pmic_typec_port. Disable and drain the delayed work directly at port_start()'s error exit. Do not use port_stop() for this path: its IRQs use IRQF_NO_AUTOEN and are enabled only after a successful port_start(). This issue was found by an in-house static analysis tool. Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Cc: stable # v6.10+ Suggested-by: Bryan O'Donoghue Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260820135307.153773-3-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit c614d7c44ca7fb78867ba46b233acdb59287e8c8 Author: Fan Wu Date: Thu Aug 20 13:53:06 2026 +0000 usb: typec: qcom-pmic-typec: disable cc_debounce_dwork on stop commit 263f7d61a4201cde16849b2d016251806e7418be upstream. cc_debounce_dwork is queued from the set_cc() and start_toggling() callbacks, which run from TCPM's kthread worker. port_stop() returns before tcpm_unregister_port() destroys that worker. Flushing the worker during unregister may therefore run a callback which queues the delayed work after port_stop() has returned. The delayed work can then run after devres has freed pmic_typec_port. Use disable_delayed_work_sync() in port_stop() to cancel a pending instance and prevent the TCPM callbacks from queueing another one. This issue was found by an in-house static analysis tool. Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Cc: stable # v6.10+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260820135307.153773-2-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 7c4e2f964c65dea4ea22386799d5fb10ef1e3e54 Author: Myeonghun Pak Date: Mon Jul 27 21:34:14 2026 +0900 usb: storage: realtek_cr: fix use-after-free on disconnect commit 4ffee1aebb0c0ffcda9faffd17834ea9b00d42cc upstream. realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free. Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed. Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor. Found by static analysis. Fixes: e931830bb877 ("Realtek cr: Add autosuspend function.") Cc: stable Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260727123414.44700-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0afe5c31612de3d18cc6d16e616da4a48ba1e5a2 Author: Elson Serrao Date: Thu Aug 13 08:14:56 2026 -0700 usb: dwc3: clear forceRM when issuing EndTransfer commit b58e6200450d350314db0ecda7d6d1bde3281e80 upstream. The forceRM bit of the DEPCMD register controls the behavior of the EndTransfer command used to stop an active transfer. Older DWC3 programming guide revisions recommended setting forceRM=1 when issuing EndTransfer. Newer programming guide revisions recommend issuing EndTransfer with forceRM cleared. With forceRM=1 on DWC_usb31 v2.00a and v2.10a controllers, a transfer aborted through the ep_dequeue path was observed to remain active after EndTransfer completion. A subsequent StartTransfer issued on the same endpoint triggered writes associated with the aborted transfer. This resulted in an SMMU fault because the transfer buffer had already been unmapped during EndTransfer command-completion cleanup. Using forceRM=0 eliminates the issue. Although older DWC3 programming guide revisions recommended setting forceRM=1, no issues are known from using forceRM=0. Clear forceRM when issuing EndTransfer to provide consistent EndTransfer behavior and align with newer programming guide recommendations. Fixes: 1e43c86d84fb ("usb: dwc3: core: Add DWC31 version 2.00a controller") Cc: stable Signed-off-by: Elson Serrao Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260813151456.867008-1-elson.serrao@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 62a8b67960637ae1d9dfbe70503e16ac78264ddd Author: Andy Shevchenko Date: Mon Aug 17 18:11:30 2026 +0200 usb: f_mass_storage: Bump local buffer size in fsg_common_create_luns() commit 9f6f095beec82a80daa666a3b2186a5b95841e9a upstream. GCC (Debian 14.2.0-19) is not happy about the buffer size: drivers/usb/gadget/function/f_mass_storage.c:2970:48: error: ‘%d’ directive output may be truncated writing between 1 and 9 bytes into a region of size 5 [-Werror=format-truncation=] Bump the size to get it enough for all possible values. Note, although cfg->nluns is limited to FSG_MAX_LUNS (16), the compiler doesn't realize this and complains about the buffer size. Also note, the existing comment is wrong as size 8 for the whole buffer doesn't cover 100 mil numbers, hence drop it altogether. Fixes: b27c08c953e9 ("usb: gadget: f_mass_storage: create lun creation helpers for use in fsg_common_init") Cc: stable Acked-by: Alan Stern Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20260817161239.1448582-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 1c67f2ba9c5f7c5ab3670671c0d51c6504bcaf74 Author: Liu Qi Date: Fri Aug 21 17:04:16 2026 +0800 usb-storage: ene_ub6250: fix race between scan work and probe commit 445fc368c6bc73eff0aeb3818cf5f355facfbb16 upstream. ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path. Reported-by: syzbot+22ea20ef3afb6785b122@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=22ea20ef3afb6785b122 Assisted-by: Qwen:Qwen3.6 Signed-off-by: Liu Qi Acked-by: Alan Stern Link: https://patch.msgid.link/20260821090416.1247127-1-liuqi@longcheer.com Signed-off-by: Greg Kroah-Hartman commit 7690a86b193271322cd31ab77349a87aa10858e4 Author: Shuangpeng Bai Date: Mon Jul 6 16:24:06 2026 -0400 media: usbtv: keep device alive while ALSA card exists commit fc530fe168bb2b745a93f553ad21fc25fd9cba3d upstream. The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card. Closes: https://lore.kernel.org/r/178144969601.60470.4852887710381872458@gmail.com Fixes: 63ddf68de52e ("[media] usbtv: add audio support") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 296a884cd6feb070492fa9198a03fec3ffd16c69 Author: Stephan Gerhold Date: Mon Jul 6 17:02:12 2026 +0200 clk: qcom: gcc-mdm9607: Increase delay for USB PHY reset commit c99bc8e83848358bd4a0436e4bdae5b7919babb2 upstream. To conform to the specifications of the USB PHY, the reset signal should be asserted for at least 10us. Guarantee that by increasing the delay for the USB2_HS_PHY_ONLY_BCR reset control similar to commit dcc6c9fb7128 ("clk: qcom: gcc-msm8909: Increase delay for USB PHY reset"). Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-5-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 9392a2c346762ffee8edd1ba8bac50d2e24a2ed7 Author: HyeongJun An Date: Tue Sep 1 18:04:09 2026 +0900 ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() commit e4637ce34607f1733a34a57294966d26b263e626 upstream. The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here. Fixes: 030a07e44129 ("ALSA: Add USB US122L driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260901090409.1478573-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 838455cc8bfe1278150d1d776529edea6cd4c1dd Author: Griffin Kroah-Hartman Date: Wed Aug 19 12:04:25 2026 +0200 usb: image: mdc800: change kmalloc() to kzalloc() commit 2430eb81e44111b30eeb5273bbcf8b24ca517ef9 upstream. Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify() Assisted-by: gkh_clanker_t1000 Cc: stable Signed-off-by: Griffin Kroah-Hartman Link: https://patch.msgid.link/20260819-usb_misc_random-v1-1-43a0dcee3a32@kroah.com Signed-off-by: Greg Kroah-Hartman commit 4814f28c45f58a71a80d09b80a60da6a063b539a Author: Hari Mishal Date: Sat Aug 22 16:57:51 2026 +0200 drm/amd/display: fix division by zero in get_estimated_bw() commit f63de9054da858d57054474c32464106f8375e0d upstream. get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. Fixes: 8e5cfe547bf3 ("drm/amd/display: upstream link_dp_dpia_bw.c") Reviewed-by: Alex Hung Assisted-by: gkh_clanker_t1000 Signed-off-by: Hari Mishal Signed-off-by: Alex Deucher (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 12ee39c2b1d3c99e1eda3b04218676960adebb1a Author: Anton Protopopov Date: Sun Oct 19 20:21:29 2025 +0000 bpf: fix the return value of push_stack commit 6ea5fc92a0fc1cde976cb701db2c1dba4dcab7cf upstream. In [1] Eduard mentioned that on push_stack failure verifier code should return -ENOMEM instead of -EFAULT. After checking with the other call sites I've found that code randomly returns either -ENOMEM or -EFAULT. This patch unifies the return values for the push_stack (and similar push_async_cb) functions such that error codes are always assigned properly. [1] https://lore.kernel.org/bpf/20250615085943.3871208-1-a.s.protopopov@gmail.com Signed-off-by: Anton Protopopov Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20251019202145.3944697-2-a.s.protopopov@gmail.com Signed-off-by: Alexei Starovoitov [ Ajay: Modified to apply on v6.18 ] Signed-off-by: Ajay Kaher Signed-off-by: Greg Kroah-Hartman commit c96477e0cabf55bfbdf078078e9de1c8024f8060 Author: Linus Torvalds Date: Thu Aug 20 20:12:39 2026 -0700 drm/xe: Don't hand out the flat CCS storage as usable VRAM commit 818bebeb63dd6bf5f4e07e145f6cdbace520a34c upstream. get_flat_ccs_offset() reads the base of the flat CCS storage from the hardware, scales it by the number of enabled L3 nodes, and rounds the result up to 128K. Everything below that offset is then handed to the VRAM allocator as usable memory. Rounding a limit that means "usable memory ends here" upwards publishes whatever lies between the real base and the rounded one as free memory, and that memory belongs to the compression hardware. The scaled value has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it is not: flat CCS base: raw 0x3fafff800, rounded 0x3fb000000 so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator's pool. Whatever is allocated there gets that tail overwritten by the compression hardware, which needs no page-table entry, no buffer object and no GPU submission to do it, and does it before userspace exists. On this machine a Mesa VM's level-3 page table landed on that page on every cold boot. It lost the entry covering the compositor's batch-buffer heap, so the compositor's first submission faulted fetching its batch and gdm restarted it forever: a black screen on an otherwise working machine. Restarting gdm cleared it because the next VM's page tables were allocated somewhere else. Round down instead, to the page size the allocator works in. On this machine that excludes exactly one page. Reading the reserved page afterwards shows what had been writing it: [369] 0xcccc000000000000 [371] 0xcc77000000000000 [373] 0xcccc000000000000 [375] 0xcc77000000000000 compression metadata, two bytes per sixteen, sitting where the driver used to hand out memory. The assertion that should have caught this compares the offset against GSMBASE - ccs_size for equality. That value is 128K aligned, so it agrees with the rounded-up offset precisely when the base is not aligned - the check cannot fail in the case it exists to catch, and is compiled out unless CONFIG_DRM_XE_DEBUG is set. Replace it with one that can fail: CCS storage must not run into GSM. [ And this was a debug session from hell, enormously helped by an AI doing much of the grunt-work. I'd like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it. I suspect those things have been trained by people who may not be quite as stubborn as I am. But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above. This is basically a one-liner fixing a bogus "round_up()" to a "round_down()", but there were 24 patches adding more and more debug information to this, and 18 kernel boot to finally narrow it down to this. - Linus ] Fixes: 37173392741c ("drm/xe/vram: fix ccs offset calculation") Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a6b088bee95fdbc698eeb2ea6627e4f789f0ed95 Author: Sun Jian Date: Sun Sep 6 12:08:32 2026 +0900 fsnotify: inotify: pass mark connector to fsnotify_recalc_mask() [ Upstream commit 4520b96b8136ba2465a3f4dc5c3fb8bdf3d92e4e ] fsnotify_recalc_mask() expects a plain struct fsnotify_mark_connector *, but inode->i_fsnotify_marks is an __rcu pointer. Use fsn_mark->connector instead to avoid sparse "different address spaces" warnings. Signed-off-by: Sun Jian Link: https://patch.msgid.link/20260214051217.1381363-1-sun.jian.kdev@gmail.com Signed-off-by: Jan Kara (cherry picked from commit 4520b96b8136ba2465a3f4dc5c3fb8bdf3d92e4e) Signed-off-by: Youngjae Kwon Signed-off-by: Sasha Levin commit 0ec897493ff82b256047f5549e779a9dc3baee59 Author: Mario Limonciello Date: Thu Oct 9 15:59:07 2025 -0500 drm/amd: Drop calls to restore power limit and clock from smu_resume() [ Upstream commit 4b6ec94fdae2407d9b8e69e3ec5f879e72ad667e ] User requested power limits and clock settings are already restored as part of smu_restore_dpm_user_profile(). It's unnecessary to call the same restore as part of smu_resume(). Revert the following commits to drop that extra restore: commit ed4efe426a49 ("drm/amd: Restore cached power limit during resume") commit 796ff8a7e01b ("drm/amd: Restore cached manual clock settings during resume") commit f9b80514a722 ("drm/amd: Only restore cached manual clock settings in restore if OD enabled") Suggested-by: Lijo Lazar Reviewed-by: Lijo Lazar Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0b6680e306397097a97767447368221fac753809 Author: Ali Ahmet Memis Date: Sun Sep 6 13:14:57 2026 +0300 mfd: qnap-mcu: keep the reply buffer alive past a command timeout commit 47504742cea7878ebd1bf1491bbed923df6b90b1 upstream. qnap_mcu_exec() publishes an on-stack buffer to the receive path: unsigned char rx[QNAP_MCU_RX_BUFFER_SIZE]; ... reply->data = rx; reply->length = length; and qnap_mcu_receive_buf() writes into it from the serdev receive path, which runs out of flush_to_ldisc() and is not serialized against qnap_mcu_exec() at all. bus_lock cannot cover it, because qnap_mcu_exec() holds that mutex across wait_for_completion_timeout(). On a timeout qnap_mcu_exec() returns with reply->data still pointing at its own frame. A reply that arrives late, or an unsolicited message from the MCU, is then written into a stack frame that has been left, corrupting whatever runs next on that stack. The same applies when qnap_mcu_write() fails, since that path returns without touching the reply state either. Move the receive buffer into struct qnap_mcu. It is 37 bytes and the structure is devm_kzalloc()ed, so it lives as long as the driver, and a late write lands in memory that is still valid and is reinitialized by the next command. bus_lock keeps commands from sharing it. This deliberately does not clear reply->data or reply->length on the timeout path. Doing so races with qnap_mcu_receive_buf(), which reads both after its if (!reply->length) return size; check: clearing reply->data gives a NULL dereference, and clearing reply->length alone removes the reply->received == reply->length exit condition, so the copy loop runs until the uart chunk is consumed and overruns the buffer. Leaving both set keeps the write bounded by reply->length, which qnap_mcu_exec() has already checked against sizeof(mcu->rx). Fixes: 998f70d1806b ("mfd: Add base driver for qnap-mcu devices") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Link: https://lore.kernel.org/all/20260802132012.537B81F000E9@smtp.kernel.org/ Link: https://patch.msgid.link/20260802135307.31380-1-ali@iusegentoo.com Signed-off-by: Lee Jones (cherry picked from commit 47504742cea7878ebd1bf1491bbed923df6b90b1) [ 6.18 lacks qnap_mcu_verify_checksum() and qnap_mcu_reply_is_any_error(), so the checksum check there still open-codes qnap_mcu_csum(); only its rx references were moved to mcu->rx. The fix itself is unchanged. ] Signed-off-by: Ali Ahmet Memiş Signed-off-by: Sasha Levin commit 617b48fc0baf009dccc844378b4d2d58d9b99689 Author: FUJITA Tomonori Date: Tue Dec 23 20:35:38 2025 +0900 objtool/rust: add one more `noreturn` Rust function [ Upstream commit c18f35e4904920db4c51620ba634e4d175b24741 ] Fix the following warning: rust/kernel.o: warning: objtool: _RNvXNtNtCs1ewLyjEZ7Le_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix14from_str_radix() falls through to next function _RNvXNtNtCs1ewLyjEZ7Le_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix16from_u64_negated() The commit 51d9ee90ea90 ("rust: str: add radix prefixed integer parsing functions") introduces u64::from_str_radix(), whose implementation contains a panic path for out-of-range radix values. The panic helper is core::num::from_ascii_radix_panic(). Note that radix is derived from strip_radix() here and is always within the valid range, so kernel never panics. Fixes: 51d9ee90ea90 ("rust: str: add radix prefixed integer parsing functions") Signed-off-by: FUJITA Tomonori Reviewed-by: Alice Ryhl Tested-by: Alice Ryhl Link: https://patch.msgid.link/20251223113538.1016078-1-fujita.tomonori@gmail.com [ Reworded typo. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 947400af98b9e63841929d079a2c3ea0a8ba227b Author: Youngjae Kwon Date: Sat Sep 5 11:48:00 2026 +0900 fsnotify: Fix stale object mask after concurrent mark updates [ Upstream commit e422777fdd4746de1109575c51e65038d4c5c1be ] When a mark gets a new event bit, fanotify and inotify may avoid recalculating the object mask if the cached aggregate already contains that bit. This is racy with a recalculation triggered by a concurrent update to another mark on the same connector. The concurrent scan can read the mark before the new bit is added, while the updater reads the old aggregate before that scan publishes its result. The updater then skips recalculation and the scan publishes a mask without the bit, leaving the object mask stale after both updates complete. This can be reproduced with two fanotify groups watching the same inode: one thread removes FAN_MODIFY from one existing mark while another thread adds FAN_MODIFY to the other mark. After both fanotify_mark() calls return, writes can fail to produce FAN_MODIFY for the group whose mark now contains the bit. This was reproduced on an unmodified v6.12.95 kernel. The equivalent inotify interleaving loses IN_MODIFY events. For normal fanotify additions, recalculate whenever the raw mark mask changes. The normal mask is not cleared asynchronously, so an unchanged addition cannot introduce missing interest. Always recalculate ignore-mask updates because FS_MODIFY handling may clear the ignore mask without taking mark->lock, making snapshot comparisons unreliable. Always recalculate after updating an existing inotify watch. Its replace path temporarily sets mark->mask to zero, so a concurrent scan can observe zero even when the old and final masks are equal. Assigning the replacement mask directly would avoid the transient zero, but existing-watch updates are infrequent, so unconditional recalculation is simpler. Link: https://lore.kernel.org/all/CACwKKmCZdiZDoFuYm6LZhQ=XvHPk0fNKH=X3LmoXMqakYqJaNw@mail.gmail.com/ Fixes: 63c882a05416 ("inotify: reimplement inotify using fsnotify") Fixes: 912ee3946c5e ("fanotify: do not call fanotify_update_object_mask in fanotify_add_mark") Cc: stable@vger.kernel.org # needs adjustments for <= 7.0 Suggested-by: Jan Kara Suggested-by: Amir Goldstein Signed-off-by: Youngjae Kwon Link: https://patch.msgid.link/20260802015801.2426818-1-yjkwon0026@snu.ac.kr Signed-off-by: Jan Kara (cherry picked from commit e422777fdd4746de1109575c51e65038d4c5c1be) [yjkwon0026: Resolve the inotify conflict by retaining the branch-native inode->i_fsnotify_marks argument to fsnotify_recalc_mask(). This tree lacks 4520b96b8136 ("fsnotify: inotify: pass mark connector to fsnotify_recalc_mask()"). The surrounding conditional is deleted by this patch, so that commit is not a prerequisite for this fix.] Signed-off-by: Youngjae Kwon Signed-off-by: Sasha Levin commit 459f33f82864723a7fa366cf1091d9c6c893b6b2 Author: Jinjie Ruan Date: Fri Sep 4 07:35:53 2026 +0200 entry: Fix seccomp bypass after ptrace with TSYNC commit 4a3591287fb7f808e209b4974ed337f609a2006b upstream. Sashiko review pointed out the following issue. If a thread is stopped in syscall_trace_enter() for ptrace, another thread can install a seccomp filter with SECCOMP_FILTER_FLAG_TSYNC (e.g., via seccomp_attach_filter()). This will successfully set SYSCALL_WORK_SECCOMP on the stopped thread, but syscall_trace_enter() evaluates a cached 'work' variable sampled on entry. Consequently, the subsequent check for SYSCALL_WORK_SECCOMP misses the newly assigned flag, and the filter is silently bypassed. This race condition could allow an unprivileged process to execute a prohibited system call (e.g., execve) that the newly installed filter was intended to block, especially since the tracer might have modified the system call number during the ptrace stop. Fix this by re-reading the syscall_work flags after ptrace handling, so that any new SYSCALL_WORK_SECCOMP flag set by another thread via TSYNC during the ptrace stop is observed before the subsequent seccomp check. Fixes: 142781e108b1 ("entry: Provide generic syscall entry functionality") Signed-off-by: Jinjie Ruan Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260629132914.1135C1F000E9@smtp.kernel.org/ Link: https://patch.msgid.link/20260713025712.416366-1-ruanjinjie@huawei.com Signed-off-by: Sasha Levin commit b5a5d389eee653f7076a16169ca4e57fca722e43 Author: Dev Jain Date: Fri Jul 3 11:41:58 2026 +0000 mm/page_vma_mapped: use huge_ptep_get() for hugetlb [ Upstream commit e87df0d5d6962bde50f55f6d02b779daa394f894 ] check_pte() is the final validation step in page_vma_mapped_walk(). It reads pvmw->pte with ptep_get() to decide whether the entry maps the PFN range being walked. For hugetlb VMAs, that pointer refers to a hugetlb entry. On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave. It is not clear whether this has a trivially visible effect to userspace. Use huge_ptep_get() to dereference a huge pte pointer. Link: https://lore.kernel.org/20260703114202.365553-6-dev.jain@arm.com Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()") Signed-off-by: Dev Jain Acked-by: David Hildenbrand (Arm) Reviewed-by: Muchun Song Cc: Alistair Popple Cc: Andi Kleen Cc: Anshuman Khandual Cc: Byungchul Park Cc: Catalin Marinas Cc: Dave Hansen Cc: Gregory Price Cc: Harry Yoo Cc: "Huang, Ying" Cc: Jann Horn Cc: Josh Poimboeuf Cc: Joshua Hahn Cc: Jun'ichi "Nick" Nomura Cc: Kiryl Shutsemau Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Mel Gorman Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Pedro Falcato Cc: Rakie Kim Cc: Ralph Campbell Cc: Rik van Riel Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Will Deacon Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e15407c3a8a005324f633cd46cd8fb58042c1157 Author: Yuqi Xu Date: Fri Sep 4 11:18:22 2026 +0200 openvswitch: Fix CT limit teardown use-after-free [ Upstream commit 403f96c32c9e24600093d7d0c61c17daeedca957 ] Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state. An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down. Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists. Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization. The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace. Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit") Cc: stable@vger.kernel.org Reported-by: Vega Link: https://lore.kernel.org/all/cover.1784711445.git.xuyuqiabc@gmail.com Co-developed-by: Nan Li Signed-off-by: Nan Li Signed-off-by: Yuqi Xu Reviewed-by: Ren Wei Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/288fbd5459d92b9dd0dcc6faf625f04819161ff3.1787280296.git.xuyuqiabc@gmail.com Signed-off-by: Jakub Kicinski [ 7.0+ uses kmalloc_obj[s] while older versions use kmalloc[_array] ] Signed-off-by: Ilya Maximets Signed-off-by: Sasha Levin commit a13b1e80e5015cd732440b475c0ef443dc4a2157 Author: Norbert Szetei Date: Fri Sep 4 10:59:39 2026 +0200 net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() [ Upstream commit 8ece906150128d5ec2462aabcc978c568433eca4 ] skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers. Fixes: 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors") Cc: stable@vger.kernel.org Suggested-by: Ilya Maximets Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/6E3A780D-FB87-421F-9964-B1D457D7D106@doyensec.com Signed-off-by: Paolo Abeni [ 7.2 and earlier do not have the put_page() call on the error path ] Signed-off-by: Ilya Maximets Signed-off-by: Sasha Levin